WO2001025874A2

WO2001025874A2 - System and methods of providing verified network sessions with visual confirmation

Info

Publication number: WO2001025874A2
Application number: PCT/US2000/027282
Authority: WO
Inventors: Kawika Daguio; Frank Sudia
Original assignee: Os Crypto, Inc.
Priority date: 1999-10-04
Filing date: 2000-10-04
Publication date: 2001-04-12
Also published as: AU7991800A; WO2001025874A3

Abstract

A method for allowing a second server (104) to witness and confirm a transaction between a client (100) and a first server (102) over a computer network.

Description

SYSTEM AND METHODS OF PROVIDING VERIFIED NETWORK SESSIONS

VISUAL CONFIRMATION

This application claims the benefit of U.S. patent application Serial No. 60/157,642 filed

October 4, 1999, the entire disclosure of which, including references and drawings, is incor¬

porated herein by reference.

BACKGROUND OF THE INVENTION

Field of the Invention

The invention is related to the authentication and verification of two party transactions

over a computer network including visual confirmation thereof.

Related Art

On the Internet today, clients and servers often transact in ways that provide less than full

non-repudiation of messages exchanged. In particular, session level security, such as SSL

(secure sockets layer), does not provide non-repudiation and one party could later deny all or

part of a transaction, and the other party would be unable to prove otherwise.

So long as at least one of the parties has an impeccable reputation for honesty and integ¬

rity (e.g., a bank or large well-known merchant), that party can generally be relied upon to

maintain a reliable record of the transaction. However, the Internet enables all potential buy¬

ers and sellers of goods and services to transact with each other, and the potential for bad

conduct, or the fear of such bad conduct, will act as a deterrent to the full potential of online commerce.

One way to increase the level of proof in such transactions is to require all messages ex- changed between the parties, or at least the most legally important ones, to be digitally signed

using an asymmetric public-private key cryptographic system. Such an approach can work to

provide the necessary level of proof, but the digital signing and verification operations needed during such a process can be exceedingly time consuming for a transactional web server. To

maintain any level of volume throughput, it is necessary to invest in costly hardware crypto¬

graphic acceleration boards. However, even such boards can only handle so much volume.

Due to increasing key length requirements, to defend against improved factoring methods, the need for such boards is likely to increase, rather than decrease over time.

Also, it is a formidable task to deploy digital signing and record-keeping capabilities

to individual desktop computer users (whether home or business). While the SSL secure ses¬

sion capability is widely deployed, the market for digital signing technologies remains im¬

mature, and equipping any large percentage of end users to handle a particular type or format of digital signing can be an insurmountable barrier to rapid adoption. In view of these prob¬

lems, such deployments have generally not been attempted, other than at the individual enter¬

prise level, and the problem remains unsolved.

Therefore, it is highly desirable to develop methods for conducting transactions be¬

tween parties that can provide improved levels of non-repudiation without needing to rely

heavily on digital signing and record keeping by individual users as a method of proof.

SUMMARY OF THE INVENTION

To increase the level of confidence and trust, and to allow for greater auditing and re¬

view of transactional content as to fairness and legality, without forcing excessive use of

digital signing, the present invention discloses methods for using available technologies and

protocols to facilitate the witnessing of sessions between two parties, generally a client and a

server, by one or more additional third parties, so that in the event of any problem, dispute, or

loss of the original records, the original parties can consult with one of the third parties to

obtain a verified record of the actual transaction.

The invention also provides a method for generating or providing a visual confirma¬

tion on the screen of the client (end-user), wherein the first server, and an additional third party (also called the "witness"), can collaborate in creating a graphical representation that is

fully displayed only when the second and third parties have agreed between themselves as to

the content of the transaction that is being witnessed. Thereby providing a measure of psy¬

chological comfort to the client / end-user.

Throughout the following discussion, the term "first server" will be used to describe

the primary server or content server with which the end-user is mainly or initially attempting

to perform a transaction. This is also the server that, under the system of the present inven¬

tion, produces the page that is being viewed by the end-user, which contains the embedded

references to the additional witness server(s)

The systems and methods disclosed herein can also allow three or more parties to co¬

ordinate their activities, such as in the case of a multi-part transaction, where two or more different service providers must collaborate to deliver an end result to a client. BRIEF DESCRIPTION OF THE DRAWINGS

Figure 1 is an illustration of the system architecture of the present invention; and

Figure 2 is an illustration of the visual confirmation of a verified session according to the pre¬

sent invention.

DETAIL DESCRIPTION OF THE PREFERRED EMBODIMENTS

Secured socket layer (SSL) is the protocol most commonly used to establish a secure

session between a web server and a web browser (or another type of Internet client user soft¬

ware). An SSL session is most commonly generated using a server public key certificate, and

the clients most commonly authenticate themselves using passwords in a given session.

The client may also provide a client public key certificate. However this is relatively

rare, because (a) major issuers have not developed policies and techniques that are sufficient

to issue and manage (e.g., revoke) large numbers of client SSL certificates, and (b) even if

such client SSL certificates were issued, the processing load on the server to verify the client

SSL certificates from the end users would often be prohibitive, without costly investments in

hardware cryptographic acceleration boards.

In addition, although these points are less well understood a single client may estab¬

lish and maintain two or more simultaneous secure SSL sessions with two or more different

servers. Different servers can write information in defined positions on the same browser

screen as seen by the client / end-user. When a user presses a "button" on a given screen,

data may be transmitted from the users' machine to one or both servers based on commands

embedded into the HTML for a given page.

A cookie is a data record that may be written by a web server to a file on the user's machine. Microsoft Internet Explorer writes each cookie to a separate file, while Netscape

writes all cookies as individual records in a single large file.

The theory and practices relating to browser cookies is covered in detail in Internet

RFC 2109 (Feb 1997). A basic RFC 2109 browser cookie looks roughly like this: serverDomain = .domain.com // period to left is required allSubdomains = TRUE // all within base domain can read? serverPath = / // can restrict to part of a server cookExpireTimeGmt = <time> // defaults to end of session secureAccess = FALSE // must be in secure SSL mode to read? variableName = VAR NAME // one variable name per cookie dataNalue = <server txn data> // optionally 64-bit encoded

Each cookie may contain at most one variable name/value pair, with a total maximum

length of 4,000 bytes. In practice the maximum may be more like 1,200 bytes.

With regard to a single user's machine, (1) a single server can write up to 30 cookies,

(2) all servers can write a maximum of 200 cookies, and (3) when a server attempts to write

more than the number allowed, older cookies are deleted (overwritten) on a least-recently

used basis.

Normally, only the server that wrote a cookie can read it. However, there are two ex¬

ceptions. If the "all sub-domains" flag is set to true, then all web servers representing third

and higher level domains, but within the same second level domain, can also read the cookie.

For example, if the top level domain is .com and the second level domain is ibm.com, then

all lower level domains under ibm.com, such as sales.ibm.com or service.ibm.com or sup-

port.ibm.com, etc. can all read the same cookie from the client browser.

The other exception is if the server domain value in line 1 has a prefix of 3 periods

"..." then any web server in the world can read the cookie. This is sometimes called the "three-dot hack," and its use has been deprecated, but as of now it remains legal. The present invention relies in part on the ability of multiple different web servers to read and write cookie records relating to the client's transaction, using the client's machine as

a routing device through which the various servers can communicate with each other regard¬

ing the pending transaction. Therefore it is necessary that either (a) the 3-dot hack is em¬

ployed, or (b) that all relevant servers share the same second level domain. In the latter case

it may become necessary to create and administer a "master second level" domain, to which

all web servers participating in these interactions would belong. This may become a require¬

ment if the 3-dot hack is outlawed and no longer supported. For the time being, however, the

3-dot hack remains effective and functional, and can provide the functionality we need to

support the inventions disclosed below.

The present invention is based upon the following premises. A client can participate in a plurality of privileged and encrypted sessions with more than one server. Generally the

servers do not share such sessions directly with each other (which would be more difficult to

arrange), but rather each of them shares a different 2-way session simultaneously with the

same client. We may occasionally call this an "N-way session." Data that one of the servers

encrypts and writes back to the client machine can be read and acknowledged by other servers participating in the same session. Such data can be read and acknowledged by a plurality of

additional servers, participating in the same transaction, provided that they can read (and op¬

tionally decrypt, authenticate, etc.) one or more cookies written to the client by the first

server. The client's machine may thus be said to function as a "router" through which the

various servers participating in the session can communicate with each other, to receive, compare, and acknowledge the details of a given transaction. No direct communication be¬

tween servers is necessary and may not be desirable, but it is permitted. In a preferred method involves the use of a standards-compliant Internet web browser

and multiple Internet servers, whereby the first server embeds references to the other servers

using image source commands in the pages it is sending to the client, thereby creating a privileged multiple participant session between the client and all of the servers.

For such commands to be embedded into the web pages sent to the client, the first

server must consent to the choice of the secondary witnessing server(s). However, the choice

could be based on a prior or contemporaneous negotiation with the client, where the client

might submit a list of one or more witness servers it deems acceptable, and the server could select one (or more) and embed the necessary commands into the pages it sends to the client.

To enable reasonable security all of the communications between the client and the

servers shall be established as SSL sessions (which are ordinarily two way secured communi¬

cations).

In the preferred implementation the servers may either be different servers within the

same second level domain (secure 1.daguio.net and secure2. daguio .net) or in completely sepa¬

rate domains (www.daguio.net and www .kawika.net ). Depending on whether they are in the

same second level domain the first server may write either (a) a three dot (...) i.e. domain-

unrestricted cookie or (b) a two dot (..daguio.net) domain-restricted cookie as a means of transmitting data between the servers.

In the preferred case the first server, when beginning to transmit data, would create an

encrypted cookie containing the equivalent of message header data followed by N (where N is

less than 28 i.e. 30-2) other serially numbered and identified cookies containing encrypted

structured data.

The last cookie would contain footer data (such as a checksum, digital signature, DES MAC, or the like) relating to the other cookies in the group of cookies. The sending server generally reads back the browser cookie files it transmits, to ascertain that they were written

correctly.

As shown in Figure 1, under the present invention, the client browser 100, establishes

a session in step 101, with the first server 102, naming a preferred second (witness) server

104. The first server 102, writes back in step 106, a page referencing the second server 104 in

browser screen and program 105. The client 100, establishes a second simultaneous secure

session in step 108, with the second server 104, which writes back to the browser screen 105,

a confirmation in step 110, that it has agreed to participate.

The first server 102, then completes at least the first portion of a transaction with the client 100, and writes in step 112, to the client's cookie storage file 114, one or more cookies

containing a summary of the transaction, which are then read in step 116, by the second

server 104, which confirms their (cookie) contents, including any necessary authentication of

the first server 102, and tests of consistency and legitimacy of the transaction, and writes back

its acknowledgment in step 118, to confirm that the transaction is okay, which is read back in

step 120, and stored by the first server 102, for future reference.

The receiving server would then (a) poll for the footer cookie expected to be written

by the first server, (b) read the entire group of cookies, and (c) write an acknowledgment

cookie message indicating that it had in fact read the group of cookies.

The first server can check (e.g., poll) for this acknowledgment cookie from the witness server, to determine if the witnessing process (or at least the read operation by the wit¬

ness server) was performed successfully.

A desirable feature of this approach is that the voluntary participation of each party is required and each party may independently or cooperatively perform functions in support of

the desired transactional activity. This cooperation, however, must be coordinated in advance

and may not be technically coerced, i.e. by trickery or illegal means. It is an advantage that such witnessing methods require the bona fide knowledge, consent, and cooperation of all

parties to the transaction.

It should be noted that employing browser plug-ins, or other code in the form of Java

or Active-X could provide the same or similar functionality. However, this results in a client

that is no longer zero-thickness (i.e., standard browser only), increases the need for client

desktop administration, and increases certain security risks. Hence, the cookie based data

transfer model is strongly preferred, though not necessarily required to implement the present

invention.

Both static (file spanning oriented model) and dynamic (streaming data) transmissions may be facilitated through the method of the present invention.

For example, if the first server wishes to write a lengthy transaction record ("file")

back to the client, through a numbered series of cookies, with the understanding that this file

will be read, confirmed, and acknowledged (witnessed) by a different server, then the first

server can write a header cookie (which might include the information "cookie 1 of 10"),

followed by 8 data cookies containing the structured data file to be transferred (routed via the

client) to the witness server, followed by a footer cookie, number 10.

Alternatively, under another embodiment, the first server might wish to write a very

lengthy transaction record (potentially of unknown length). In that case it could write a header cookie containing an indication that the transmission (to be routed through the client) is of unknown length, followed by a series of numbered cookies, plus a footer cookie to indi- cate that the transmission was finished.

As a hybrid methodology, the latter method might be made more deterministic, and

easier to coordinate, if the first server would format the stream based transmission as a series

of block transmissions. That is, assuming a maximum of 30 cookies can be written by a

given server, then the first server can indicate in the header cookie that it is about to write a

batch of (say) 30 cookies, the first of an unknown number of such batches. Once the second

(witness) server had read the first batch, and written back an acknowledgment cookie, which

was read by the first server, then the first server could write the second batch of (say) 30

cookies to the client, and so on. At the end of this stream transmission, there would be a final

batch, most likely with an odd number of cookies to round it out. The first server would indi¬

cate in each batch header cookie whether it was the last batch.

The foregoing method of routing data between servers through the client can be

viewed as a standard file or stream data transfer. Accordingly, both symmetric and asymmet¬

ric cryptographic algorithms may be employed to protect and authenticate such data transmis¬

sions, in the same manner as they would be used for ordinary transmissions by other means.

Normally, such transmissions would be both signed and encrypted. If secrecy were unimpor¬

tant, cookie messages could be signed but unencrypted. It is also possible for sessions and

data to be both unsigned a d unencrypted, however this may be undesirable from a security policy perspective. Numerous methods of signing and encrypting data are known in the prior

art, including the use of shared symmetric keys, etc.

Using the foregoing technical means, the following substantive results and objectives

may be achieved. A client user may commence a transaction (e.g., business, financial, or personal, etc.) with a first web server, wherein it is desired for the transaction to be witnessed by a mutually agreed third party witness server.

The client and/or the first server may propose one or more potentially acceptable wit¬

ness servers, and following agreement, the first server will embed instructions into the pages

sent to the client causing the client to establish a simultaneous (preferably) secure session

with the witness server.

The first server and witness server will possess the capability to write information to

different parts of the client's screen, indicating inter alia that they are both participating. As

in the case of the "Site Certain™" methodology employed by the ABA.Ecom web site

(www.abaecom.com). the client may have the ability to click on distinctive icons within each

area (or belonging to each of the servers) to initiate a protocol to demonstrate to himself that he is indeed connected to the servers in question via a secure methodology.

The client will then conduct at least a portion of the desired transaction with the first

server, and according to the present invention, the first server will write back to the client a

series of one or more cookies containing a transaction confirmation. (It will then read back

the cookies it has written, to determine if the operation was performed correctly, and if not it

may undertake a retry, to write the set correctly.)

The witness server will then read the said cookies written by the first server, and con¬

firm that they represent an accurate confirmation of the transaction details. The impetus for

the witness server to initiate this read operation may be an action by the first server to inform

the user that the first part of the operation is completed, that the time has come for the witness to perform its confirming action, and display a button for the user to press, which will send a message to the witness server, telling it to commence its confirmation process.

After the witness server has read the cookies, it may also decrypt them, assemble them back into the structured data file as intended by the first server, and verified a digital signature

on the data, if present, using commonly known encryption and verification algorithms and

data formats.

Once the witness server has decrypted and verified the confirmation data structure, it

then undertakes to re-confirm the substance of the transaction, especially the details such as

price, description of goods and services, account numbers to be debited or credited, etc. and

may display a summary of the transaction on the user's screen, with a request for the user to reconfirm the details as read by the witness server.

Alternatively, the user's request for witness confirmation can merely transmit the en¬

tire contents of the screen, containing the details just displayed by the first server, and the

witness server only needs to compare the contents of the cookie confirmation record with

what is on the screen. Hence an additional user comparison and acceptance would not be

needed.

To facilitate the user's comprehension and psychological reassurance, it is desirable to

provide an unambiguous, easy to read method for the user to be assured that the witness

server has confirmed his transaction.

Therefore, we provide a split visual representation of a logo of the confirmation sys¬

tem, that would be employed by all first servers and witness servers operating jointly under

the system of the present invention.

For example, as shown in Figure 2, the bit mapped graphical image of the system

mark "Nal-ID" can be split into two separate images, along a line drawn through the middle.

The first server can display the left ("Nal") side of the logo, to visually inform the user that the confirmation system was in use, and the witness server can display the right ("ID") side, once it has successfully performed its portion of the confirmation process.

This split visual confirmation method, of a single logo divided into several parts, be¬

ing fully displayed only upon successful completion and confirmation of a transaction, can

provide users with psychological comfort.

In addition, the pieces of the image can also be active icons, such that pressing one (or

another) of the sectors of the image will activate (a) a protocol to prove that the server alleg¬

edly behind that portion of the transaction is authentic (in the manner of "Site Certain"),

and/or (b) a re-confirmation of the details of the current transaction. For example, pressing

either "Nal" or "ID" can initiate a process whereby the first and witness servers either (1) re¬

confirm the entire transaction, or (2) the witness server re-reads the displayed page and the

cookies and reconfirms its aspect of the transaction.

As shown in Figure 2, a split visual representation is provided to give the client a

physical (as well as psychological) confirmation of the transaction status. In an exemplary

embodiment, the first server displays a first portion of the visual representation 200, to the client when the first secure session is established. Then, when the second secure session is

established, the second server signifies its presence and participation by, inter alia, displaying

a matching portion of the representation 210, in a still-disunified form. Then, once the sec¬

ond server has read the transaction details from the client, verified and confirmed them, and

written back the acknowledgment cookie to the client, the second server displays 220 the rep¬

resentation in a completed and integrated form, to provide the client with an unmistakable

visual confirmation that the transaction has been witnessed and recorded as valid.

Alternative means of providing a third-party witnessing capability exist, mainly in the form of diagnostic (or illegal) system management software that can allow a third party to witness the content of a client / end-user's transaction. Such mechanisms may or may not involve the cooperation or notification of the end-user, and generally do not provide any notification or control to the first server.

Two notable examples include Microsoft^® System Management Server (SMS) and

Back Orifice 2000 (BO2K), an illegal program released by the hacker group "Cult of the Dead Cow," which perform nearly identical functions.

SMS and BO2K both utilize a small "server" that is installed, often surreptitiously, on

the client / end-user's computer. Once installed, a remote "client" (controlled by a system

administrator, or a malicious hacker) can send instructions to the implanted "server," asking it

to relay back to the client (often without the end-user's knowledge) information concerning the contents of the user's screen, the contents of any file, and the position of the cursor, etc. Based on remote instructions from the "client," the implanted "server" can also take com¬

mand of the mouse or keyboard and enter any instructions desired by the remote "client."

In this manner, the "client" could be viewed as fulfilling the same, or a similar func¬

tion as the witness server in the present invention. However, under SMS and BO2K there is

no concept that the first server (or even the client) participates in selecting the witness server. In the present invention, the participation of the first server in the selection process is essen¬

tial because the means of involving the witness server are driven by data that must be embed¬

ded into the main page sent to the client by the first server, and activated by the action of the

client, pressing some "button" to continue the transaction. Under SMS and BO2K the first

(content) server, has no role in choosing the remote witness "client," if it is aware of its presence at all.

In another embodiment of the present invention, the client / end-user might make a ar- rangement for a "server" to be implanted on his machine, preferably with functionality lim¬

ited to witnessing transactions and incapable of performing damaging actions, wherein the

remote "client" could be called upon, without the knowledge or consent of the first server, to witness a transaction with the first server. Based upon a pre-arranged signal, the remote

"client" could record the contents of the entire interaction between the client and the first

server. Then in the event of a dispute, the end-user could call upon the remote "client" to

furnish proof of the contents of the transaction, in case the first server denied the transaction

or altered its details.

This evidence has the flavor of "I was looking over his shoulder." This is much less

desirable than the preferred embodiment.

Under the preferred embodiment, (a) the first server has already actively consented to

the witnessing process, so it will be much more inclined to trust the information provided by the witness server, and cooperate with it to resolve any dispute, and (b) by reading and con¬

firming the transaction details, the witness server has been able to assist the client in authenti¬

cating both the identity of the first server and the correctness of the transaction.

In addition, as with the potential use of Java, Active-X, or plug-ins, we are no longer

operating in a zero-thickness mode (i.e., standard browser only). The need for special code

running on the client desktop, especially code that has a high potential for security risks, is a

major disadvantage over the present invention.

As previously noted, the present invention can be used for other purposes beyond

merely witnessing a transaction between an end-user and a first server (or primary server or

content server). It is also possible that there can be more than one additional server, and that said more than one additional server can perform other functions besides witnessing a trans- action. Notably, a second server can also participate in the underlying transaction, where the

first server and second server collaborate to jointly deliver some goods or services to the end-

user.

While collaborating within the transaction, a second server can also perform a secon¬

dary service as a witness to the data flows between the client and the first server. Likewise,

the first server could also serve as a witness to the data flows between the client and the sec¬

ond server, etc.

Some notable examples of multi-participant transactions are as follows. For purposes of this discussion, the witness function is henceforth omitted, and we will focus only on ways

that two or more servers can collaborate to deliver services to a single client, where commu¬

nications pertaining to such collaboration are routed through the client (normally using the

cookie mechanism), the client initiates a secure session with each such server, and the entire

process is negotiated between the client and the first server, which embeds the references to the other server(s) in the primary page it sends to the client.

In a Client-Merchant Bank example, a client contacts a merchant (first server) and

seeks to conduct a credit card transaction to purchase goods or services. By agreement with

the client, the merchant embeds a reference to the merchant's bank into the page, and the cli¬

ent establishes a second secure session with the merchant's bank, according to the present invention. The merchant solicits a credit card number from the client, and then utilizes the client-router methodology to transmit the credit card number and other transaction details to its

own bank, which is directly participating in the session. The bank confirms the client's credit

card number and relays its confirmation back to the merchant via the client.

This methodology has the great advantage that it requires a small software modifica- tion to the merchant's server, to allow it to perform the routing through the client to the bank, and furthermore it can reassure the bank, which is itself participating in the session, that the

transaction is legitimate. The merchant does not need any other special equipment or capa¬

bilities. Hence, this could represent an effective means for banks to enable their merchants to

perform credit card transactions.

In a Car Dealer-Finance-Title-Insurance example, a first server can represent a car

dealer, which with the consent and cooperation of the client, adds other servers to the session

to complete a car sale transaction, such as a bank or finance company, motor vehicle title of¬

fice, and an auto insurance carrier.

In this example, the client selects the make and model of car, and any relevant options,

and confirms the details of the transaction. Then the transaction details are written back to the client browser (as cookies) that can be read by the bank or finance company, which at¬

tempts a transaction to arrange financing for the client to purchase the car. Upon completion

of at least the credit check portion of that transaction, the finance company can then cooperate

with the insurance company to determine whether the client can obtain the necessary insur¬

ance, and if so the state title office can be informed of the transaction details, and issue the necessary documents of title, endorsed with any lien or security interest in favor of the lender,

etc. In each case the relevant parties communicate with each other through the client browser.

In this manner, the parties can cooperate to consummate all elements of this transaction without server-to-server communications, by routing the necessary information through

the client, with the full knowledge and cooperation of the client.

In a Hotel- Airline Frequent Flier (FF) Mile example, a client initiates a session with a

hotel and attempts to reserve a room, paying in part with frequent flyer miles from an airline. At the request of the client, the hotel generates and sends a page to the client, which has the

effect of creating an additional session with the airline. The hotel writes the room reservation

transaction details back to the client, where they are read by the airline. The airline confirms

that the transaction is eligible for FF mile credit, and writes a record back to the client, read¬

able by the hotel, informing the hotel that the FF mile credit is approved.

In a Tax Filing-Bank Payment example, a client initiates a session with a government

tax agency for the purpose of filing an official tax return with the agency. At the request of

the client, the tax agency (state, federal, etc.) adds the client's bank to the session, by writing

back a page that allows the client to invoke an additional simultaneous session with his bank.

Upon completion of the official filing, the tax agency writes the details of the client's

tax obligations back to the client browser, whereupon the client's bank reads and confirms the

details, initiates a process to remit payment to the tax agency, and provides the agency with an advice or confirmation of its actions, again by means of records written back to the client,

which are then read and confirmed by the tax agency. The bank may effect the payment using

a conventional payment system, such as wire or ACH.

In an Inter-Bank Transfer example, many clients, especially businesses and wealthy

individuals, often have bank or financial accounts at two or more financial institutions (FI).

Such accounts may be demand deposit, savings, money market, securities trading, retirement

savings, tax escrow, and so forth. As long as the two accounts are at the same FI, one can use

conventional means to create a session with that FI, and instruct it to move funds from one

account to the other.

However, under the present invention, the client / end-user can establish a first session

with a first FI, and then request that a second FI be added to the session, for purposes of ef- fecting an inter-FI transfer. The first FI writes back a page that causes the client to invoke the second session with the second FI. The client then initiates an instruction to the first FI to

transfer funds to the second FI. The first FI confirms the availability of funds, and then writes

back the details of the proposed transaction to the client browser, whereupon the second FI

reads the detail records, authenticates and confirms them, and agrees to participate in the proposed transaction. The second FI then writes back to the client browser an acknowledgment

of the transaction as proposed by the first FI. The parties can add more confirmation steps as

desired, to assure that there is no mistake and that the transfer is only performed once, etc.

In a Hospital-Drug Company-License Bureau setting, there are some kinds of purchases requiring the purchaser (or seller) to possess a special license. For example a pur¬

chasing agent for a hospital seeking to purchase prescription drugs in quantity must demon¬

strate that he possesses a license from a licensing agency, such as the US Drug Enforcement

Agency (DEA).

Under the present invention, the hospital buyer first establishes a session with the seller of controlled substances, and requests that his relevant licensing agency be added to the

session. The seller writes back a page containing the needed reference to the licensing

agency, and the buyer clicks on the button to activate the additional session. The buyer and

seller then agree on the general terms of the sale, and the seller writes the details back to the

buyer's cookie storage facility, whereupon the cookies containing these details are retrieved and examined by the licensing agency. The licensing agency then approves the transaction

and writes back its consent in the form of an authenticated record, that may span a series of cookies, to the user's machine, whereupon these cookies are then read, verified, and stored by

the seller. The buyer and seller then finalize their transaction and the goods are shipped as requested.

Claims

WHAT IS CLAIMED IS:

1. A method for allowing a second server to witness and confirm a transaction over a

computer network between a client and a first server, comprising the steps of:

the client and the first server agreeing upon the identity of a second server;

the first server writing back to the client a web page that includes an instruction to

establish a session with the second server;

the client establishing said second session with said second server;

the client sending a transaction simultaneously to the first server and to the second

server;

the first server writing a record of the transaction back to the client;

the second server retrieving said record of the transaction and determining if it

conforms to predetermined rules regarding the validity of such transactions;

the second server writing an acknowledgment record back to the client; and the first server retrieving the acknowledgment record from the client and storing

the record.

2. The method for performing a transaction as in claim 1, including the additional steps

of:

after establishing the session with the first server, displaying a visual confirmation

in the form of a partial representation of a validation symbol;

after establishing the session with the second server, displaying an updated visual confirmation in the form of a still-incomplete representation of the said validation symbol; after the confirmation of the transaction by the second server, displaying an up¬

dated visual confirmation in the form of a complete representation of the said valida¬

tion symbol.

3. A system for allowing a second server to witness and confirm a transaction over a computer network between a client and a first server, comprising:

means for the client and the first server agreeing upon the identity of a second

server;

means for the first server writing back to the client a web page that includes an instruction to establish a session with the second server;

means for the client establishing said second session with said second server;

means for the client sending a transaction simultaneously to the first server and to

the second server;

means for the first server writing a record of the transaction back to the client;

means for the second server retrieving said record of the transaction and determining if it conforms to predetermined rules regarding the validity of such transac¬

tions;

means for the second server writing an acknowledgment record back to the client;

and

means for the first server retrieving the acknowledgment record from the client and storing the record.

4. The system according to claim 3 comprising:

means after establishing the session with the first server, displaying a visual con¬

firmation in the form of a partial representation of a validation symbol;

means after establishing the session with the second server, displaying an updated

visual confirmation in the form of a still-incomplete representation of the said validation symbol; and

means after the confirmation of the transaction by the second server, displaying an updated visual confirmation in the form of a complete representation of the said validation symbol.