WO2001071611A2 - Method, system, and program for real-time trading of instruments and goods - Google Patents

Description

TITLE OF THE INVENTION

METHOD, SYSTEM, AND PROGRAM

FOR REAL-TIME TRADING OF INSTRUMENTS AND GOODS

COMPUTER PROGRAM APPENDIX

This application is being filed along with an appendix of computer program listings

consisting of the following exhibits:

Exhibit A: CE Form Source Code, including:

(1) DealsDoneFormScript - Form that displays the confirmed trade ticket.

(2) OrderBookFomiScript - Form that displays the order book deal infomiation. Also

used in conversation.

(3) OutgoingCallsFormScript - Form that is displayed when the user creates an

outgoing call. Exhibit B: CEExpireOrder Source Code: Application on the a server, preferably the SQL

server, that monitors the SQL order book entries and deletes expired entries.

Exhibit C: CEPostCall Source Code: Business object that handles outgoing call,

conversations, and order book management in exchange server.

Exhibit D: Workflow Events Screenshot Source Code, including:

(1) Current Conversation: Picture ofthe workflow, attached to the conversation

folder for a user. Routes items to counterparty. Also handles canceled and confirmed trade

logic.

(2) Order Book: Picture ofthe workflow, attached to the order book folder for a

market. Handles canceled and confirmed trade logic.

(3) Outgoing Calls: Picture ofthe workflow, attached to the outgoing calls folder for

a user. Routes calls to all specified organizations.

Exhibit E: Workflow Events (XML) Source Code:

(1) Current conversation: XML file containing full description ofthe event handler,

attached to the conversation folder for a user. Routes items to counterparty. Also handles

canceled and confirmed trade logic.

(2) Order Book: XML file containing full description ofthe event handler, attached to

the order book folder for a market. Handles canceled and confirmed trade logic. (3) Outgoing Calls: XML file containing full description ofthe event handler,

attached to the outgoing calls folder for a user. Routes calls to all specified organizations.

Exhibit F: Deals Done Folder Update Source Code: Application on the SQL server that

replicates the SQL deals done table into exchange server deals done folder.

Exhibit G: ExtendSP Source Code: Extended stored procedure on the SQL server that sets an

NT event that triggers the deals done folder update and order book folder update applications.

Exhibit H: Order Book Folder Update Source Code: Application on the SQL server that

replicates the SQL order book table into exchange server order book folder.

Exhibit I: SQL Scripts Source Code: Contains the stored procedures and the script for all the

SQL tables.

Exhibit J: Workflow Event Scripts Source Code:

(1) Current conversation: Shared script, attached to the conversation folder for a

user. Routes items to counterparty. Also handles canceled and confirmed trade logic.

(2) Order Book: Shared script, attached to the order book folder for a market.

Handles canceled and confirmed trade logic.^'

(3) Outgoing Calls: Shared script, attached to the outgoing calls folder for a user.

Routes calls to all specified organizations. Exhibit K: Business Object Routine Source Code, including:

(1) DeallD: Business object for generating unique identifier for trade.

(2) KMTCUtils: Business object that creates a unique folder name for logging trades.

(3) KMTServices: Business objects for calculating nettings and positions and creating

log views for users and organizations.

(4) KMTUtils: Business object to allow other business objects access to exchange

store information.

Exhibit L: Event Handler Source Code, including:

BMP file containing picture ofthe workflow.

XML file containing full description ofthe event handler.

Text file comprising shared script aid, as follows:

(1) Accept router, attached to the incoming calls folder for an organization party.

Accepts incoming calls for an organization.

(2) Call router, attached to the outgoing calls folder for a user. Routes calls to all

specified organizations.

(3) Conversation router, attached to the conversation folder for a user. Routes items

to counterparty. Also handles cancel trade, confim trade, and transfer trade logic.

Exhibit M: Form Source Code, including:

(1) ConversationLog: Form that displays log of trade when user clicks on the log

button on the FXDealForm.

(2) FXTicketBlotter or FXTicketForm forms. (3) FXContactForm: Form that is displayed when the user creates an outgoing call.

(4) FXDealForm: Form that is displayed during the trade conversation.

(5) FXTicketForm: Form that is displayed for an agreed trade, before the trade is

confirmed.

(6) FXTicketBlotter: Form that displays the confirmed trade ticket.

The contents of that appendix are incorporated by reference into this

disclosure as if fully set out herein.

A portion ofthe disclosure of this patent document contains material which is

subject to copyright protection. The copyright owner has no objection to the facsimile

production by anyone ofthe document or the patent disclosure, as it appears in the Patent and

Trademark Office patent file or records, but otherwise reserves all rights of copyright

whatsoever.

BACKGROUND OF THE INVENTION

Field ofthe Invention

The present invention relates generally to a method, apparatus, and program

for trading instalments and goods, with the potential for reduced costs for product

development, delivery, and support. Related Background Art

The specialization of labor is an essential aspect of modem society.

Generating goods and services through specialized factors of production allows them to be

produced far more cheaply, and in far greater quantity, than would be the case if each person

needed to produce solely through his or her own skills and resources all that was required or

desired.

An essential feature arising from specialization ofthe factors of production is

the need to trade the goods or services produced by one factor for those produced by others.

This can be done either directly, where the products are traded in bartering transactions, or

more commonly today, by utilizing money as an intermediate medium of exchange. Perhaps

the oldest mechanism for facilitating trading is the market concept, in which buyers and

sellers (or their agents) collect at a single location and negotiate the price at which a purchase

or sale occurs.

Markets are highly efficient for both buyers and sellers, and work particularly

well for the purchase and sale of reasonably fungible items, such as commodities or financial

instruments. For example, under the decades-long practice in the trading of securities, a

prospective purchaser or seller contacts a broker and expresses the desire to buy or sell. The

broker may then conduct the transaction on the floor ofthe securities exchange, in so doing

perhaps utilizing the services of a market maker, such as a trading specialist. The advent of computer technology is having a profound impact on the

practice referred to above. In particular, computer systems have been implemented to

facilitate securities trading in a variety of ways. A recent example of such a system is

described in U.S. Patent No. 5,924,082, which allows buyers and sellers located at remote

computer terminals to engage in buy/sell transactions. The system automatically matches

potential parties to a transaction, based upon ranking information, and then permits the

potential parties to electronically negotiate some or all terms ofthe transaction.

Computerized trading systems such as that described in U.S. Patent No.

5,924,082 speed transactions, potentially accommodate a greater number of simultaneous

traders than would be possible utilizing the traditional floor trading procedure, and allow

trading outside the time of day constraints associated with traditional securities markets. In

addition, these programs have the potential to reduce trading costs through "disinter-

mediation"; the trading system itself becomes the market, thereby eliminating the need in at

least some cases for brokers or specialists.

Despite these advantages, the development of computerized trading systems is

a difficult, time-consuming process. Since each aspect ofthe software is custom-designed, it

can take on the order of man-years to develop a computerized trading program. Not only is

this expensive, but it also impedes the ability to rapidly deploy computerized trading systems

for use with new financial products or circumstances.

SUMMARY OF THE INVENTION The inventors have developed a system that enables trades of instruments,

goods, and other properties and services to be proposed, negotiated, and conducted

electronically. The trading system ofthe present invention advantageously operates with and

exploits the functionality and capabilities of at least some commercially-available

information management software products for personal computers, other desk top devices,

handheld devices, palm devices, server platforms, and other information appliance platforms.

Because the basic functionalities are already provided by the commercially-available

information management software, the present invention can be brought to market much

faster, and at lower costs, than has been possible in the past.

As used herein, the term "infomiation management software" means products

that are mass-marketed and distributed to a wide variety of different users, and which provide

the users with the ability to organize, view and/or share infomiation. For example,

infomiation management software can include e-mail functions, task scheduling, personal or

group calendar functions, contact information presentation and management (such as records

of telephone contacts and persons contacted, their employers, addresses, and personal

information) and information collaboration functions (such as permitting a number of users to

share use of an application and its data in a conference environment). Current commercially

available infomiation management software includes Outlook and Exchange, products of

Microsoft Corporation, Redmond, Washington, as well as other software that provides similar

functionality. Also, because the present system requires less custom-written software than

has been the case for the prior art systems, the present system is also easier and less expensive

to train and maintain a staff to design, test and support, since large portions ofthe software

are the responsibility ofthe information management software provider. Furthermore, the

use of commercially available information management software improves the degree of data

integration and display integration with other applications, which can be offered as part of

larger software suites that include the information management software.

Accordingly, it is an object of this invention to provide a trading system,

method, and program that utilize, and operate in conjunction with, commercially available

infomiation management software products.

It is another object ofthe present invention to provide a system, method, and

program that enable users to propose, negotiate, and conduct transactions.

It is another object ofthe present invention to provide a system, method, and

program that enable users to propose, negotiate, and conduct transactions electronically.

It is another object of this invention is to provide a trading system, method,

and program which pemiit users to initiate and conduct negotiations, and to perform trades of

securities, currencies, or other instruments or goods. It is a further object of this invention to provide a trading system, method, and

program that utilize the functionalities of both customized and existing software.

Additional objects, feature and advantages ofthe present invention will be

appreciated from a consideration ofthe following detailed description ofthe preferred

embodiments, taken in conjunction with the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. la is a block diagram of a communication system that is suitable for

practicing this invention;

Fig. lb is a block diagram of a computer system (also referred to as a

communication system) which is a particular embodiment of communication system 200' of

Fig. la, wherein components 107' and L2 ofthe communication system correspond to a

server 107 and an interface connection 202', respectively, ofthe system of Fig. la, and

wherein component 100 of Fig. lb represents one or more ofthe nodes 200-1 to 200-n ofthe

system of Fig. la;

Fig. lc is a block diagram of a user information appliance ofthe

communication system of Fig. lb;

Fig. 2 shows an exemplary representation of an Exchange folder hierarchical

tree structured in accordance with an embodiment of this invention; Fig. 3a shows an electronic call (contact) form having various information

fields in accordance with this invention;

Fig. 3b is an exemplary data structure of an electronic form according to this

invention;

Fig. 3c shows an electronic deal form having various information fields in

accordance with this invention;

Figs. 3d and 3e show examples of windows that are displayed on a display of a

user infomiation appliance of Fig. lb during the performance of a method in accordance with

this invention;

Fig. 3 f shows an electronic deal fomi having various infomiation fields in

accordance with this invention;

Fig. 3g shows an electronic ticket form having various infomiation fields in

accordance with this invention;

Fig. 3h shows an example of another window that is displayed on a display of

a user infomiation appliance of Fig. lb during the perfomiance of a method in accordance

with this invention; Figs. 3i and 3j show examples of other windows that are displayed on a

display of a user information appliance of Fig. lb during the performance of a method in

accordance with this invention, wherein the windows include nettings and positions summary

information, respectively, that are determined in accordance with an aspect of this invention;

Fig. 3k shows an electronic "Order Entry" form having various information

fields in accordance with this invention;

Fig. 31 shows an exemplary representation of "Deals Done" and "Order Book"

folders stored in an Exchange server and database tables stored on a SQL server, all of which

are employed in an electronic "bulletin board" embodiment of this invention;

Figs. 3m and 3n show electronic "Order Book" forms having various

information fields in accordance with this invention

Figs. 4a-4i show a logical flow diagram of a method for proposing,

negotiating, and conducting an electronic trade in accordance with one embodiment of this

invention;

Fig. 5a shows a logical flow diagram of a procedure for calculating and storing

various transaction-related positions summary infomiation in accordance with an

embodiment of this invention; Fig. 5b shows a logical flow diagram of a procedure for calculating and

storing various transaction-related nettings summary information in accordance with an

embodiment of this invention;

Fig. 5c shows a logical flow diagram of a procedure for electronically

"capturing" an externally negotiated transaction of interest, in accordance with an

embodiment of this invention;

Fig. 6a shows an example ofthe manner in which a Chat COM Add-In lOlf

operates in conjunction with a chat window 101 and Microsoft Outlook software 101g',

during the perfomiance of a chat procedure in accordance with an embodiment of this

invention;

Fig. 6b shows an example of a displayed version ofthe chat window 101 of

Fig. 6a;

Figs. 7a-7d show a logical flow diagram of a method for conducting an

electronic "bulletin board" transaction in accordance with an embodiment of this invention;

Figs. 8a and 8b each show a logical flow diagram of a method for conducting

an electronic "bulletin board" or electronic order book transaction in accordance with another

embodiment of this invention; Figs. 9a-9e show a logical flow diagram of a method for performing a credit

verification check of a party, in accordance with an embodiment of this invention;

Fig. 10 is a flowchart illustrating the technique utilized to capture and provide

dynamic information to a user ofthe communication system of Fig. lb, according to a

preferred embodiment of this invention;

Figs. 11a and 1 lb shows examples of windows that are displayed on a display

of a user infomiation appliance 600 of Fig. 10, during the performance ofthe method shown

in Fig. 13;

Fig. 12 shows a logical flow diagram of a procedure for requesting and

receiving infomiation, such as dynamic data, at the user infomiation appliance 600 of Fig. 10,

in accordance with one embodiment of this invention;

Fig. 13 shows a logical flow diagram of a procedure for retrieving an

electronic spreadsheet and for enabling a user ofthe communication system of Fig. lb to

enter information specifying multiple transaction proposals into the spreadsheet, in

accordance with an embodiment ofthe invention; and Fig. 14a shows an example of an electronic contact form having an electronic

spreadsheet component inserted therein, wherein the spreadsheet component is inserted into

the form in response to a user selecting a multi-deal function in accordance with an

embodiment of this invention;

Fig. 14b shows another example of an electronic contact form having an

electronic spreadsheet component inserted therein, in accordance with an embodiment of this

invention;

Fig. 15 shows an example of displayed contents of a credit folder in

accordance with an embodiment of this invention; and

Fig. 16 shows another exemplary representation of "Deals Done" and "Order

Book" folders stored in an Exchange server and database tables stored on a SQL server, all of

which are employed in an electronic "bulletin board" embodiment of this invention;

Identical portions ofthe various figures have been identified with the same

reference numerals in order to simplify the description ofthe present invention. Certain

components having similar purposes have been designated using the same reference numerals

with at least one prime added. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Fig. la is a block diagram illustrating the basic communication system 200'

that is suitable for practicing this invention. The communication system 200' comprises a

server (e.g., a "server computer") 107 that is bidirectionally coupled to each of a plurality of

nodes 200-1 to 200-n through an interface connection 202', which may be, for example, a

connection provided via a WAN or LAN, an Internet connection, or a wireless interface,

depending on the design and construction ofthe system 200'. Each ofthe nodes 200-1 to

200-n represents, for example, a LAN, a WAN, or a user information appliance that is

associated with a particular party PI to Pn, respectively, where each party PI to Pn may

include, for example, a business organization, trading group, individual, or any other

applicable party that engages in the trading of instruments, goods, and/or services with other

parties, or whose sub-parties (e.g., individuals within an organization) engage in internal

trading of such instmments, goods, and/or services.

In accordance with a preferred embodiment of this invention, each ofthe

nodes 200-1 to 200-n can communicate infomiation, such as trading instractions and other

transaction-related information, bidirectionally with the server 107. The server 107 is a

computer or farm of computers that facilitate the transmission, storage, and reception of such

information and other data between different points, such as between the nodes 200-1 to 200-

n, between sub-party components (e.g., user infomiation appliances) within the nodes, and

between the nodes and external sources/destinations. From a hardware standpoint, a server

computer will typically include one or more components, such as one or more microprocessors (also referred to as "controllers") (not shown), for performing the arithmetic

and/or logical operations required for program execution. A server computer will also

typically include disk storage media (also referred to as a "memory"), such as one or more

disk drives for program and data storage, and a random access memory, for temporary data

and program instruction storage. From a software standpoint, a server computer also contains

server software resident on the disk storage media, which, when executed, directs the server

computer in performing its data transmission and reception functions. The server software

runs on an operating system, for example Windows 2000 Advanced Server, which is also

stored on the disk storage media. As is well known in the art, server computers are offered by

a variety of hardware vendors, can run different operating systems, and can contain different

types of server software, each type devoted to a different function, such as handling and

managing data from a particular source, or transforming data from one format into another

format.

Reference is now made to Fig. lb, which is a block diagram of a computer

system (also referred to as a communication system) 200", which is a particular embodiment

of communication system 200', shown in Fig. la, and which is suitable for practicing this

invention. The communication system 200" comprises a network 100, a server 107' having at

least one associated memory 107a, and, in accordance with one embodiment ofthe invention,

a server 106' having at least one associated memory 106a. Also in accordance with one

embodiment of this invention, the system 200" comprises at least two information sources

140 and 141, which will be described below. In the illustrated embodiment, the information

source 140 is coupled to a network interface 190 ofthe network 100 tlirough the server 107' and links LI and L2, and the information source 141 is coupled to the interface 190 through

the server 106', the server 107', and links LI', LI", and L2.

Server 107' corresponds to server 107 of Fig. la. The network 100 may be, for

example, a WAN, a LAN, or a wireless network, and, in either case, represents one or more

ofthe nodes 200-1 to 200-n ofthe communication system 200' shown in Fig. la, wherein the

link L2 is assumed to be similar to the interface connection 202' described above. In the case

of a LAN, the network 100 may have, for example, a bus, ring, star, or tree topology,

although for convenience the network 100 is depicted in Fig. lb as having a bus topology.

The network 100 preferably includes the network interface 190, and a plurality

of user infomiation appliances, such as worknodes or workstations (e.g., PCs) 120 and 122,

as well as other infomiation appliances generically denoted as 150 and 160, all of which are

coupled to the network interface 190 tlirough a suitable interface. For example, the

worknodes 120, 122 and infomiation appliances 150 each may be coupled to the interfacel90

tlirough a link L3, and the infomiation appliances 160 may be coupled to the interface 190

through a link L3', a respective link L4, transceiving equipment 163 and 167, and an interface

164. The transceiving equipment 163 and 167 may comprise, for example, modems or

wireless transceiving units, and the interface 164 may or may not be a wireless interface,

depending on the types of infomiation appliances 160 employed. Each user information

appliance 120 and 122, and each individual one ofthe user information appliances 150 and

160, may represent, for example, a user infomiation appliance employed in one ofthe nodes

200-1 to 200-n of Fig. la. The individual information appliances 150 may include, for example, portable

PC docking nodes, web TVs, cable system set top boxes, personal digital assistants, and the

like. Correspondingly, the individual information appliances 160 may include, for example,

remote personal computers, handheld personal digital assistants with wireless capability,

cellular phones, pagers, and the like. In addition, information appliances can optionally

obtain access to network components through an Internet connection (not shown), and that

Internet connection can be accessed by the information appliances using telephone, cable, or

other, wireless technologies. The number and variety of user information appliances which

may be communicating tlirough the network 100 can vary widely, depending upon the size of

the enterprise providing network 100, its needs, users' needs and geographic location(s),

applicable design/system operating criteria, etc. In general, the teaching of this invention

may be employed in conjunction with any suitable type of infomiation appliance device that

is capable of communicating with other components of a communication system/network,

and which includes one or more user interfaces for enabling a user to input information, view

or otherwise perceive presented (e.g., displayed) infomiation, and select or otherwise

manipulate such presented information.

Referring to Fig. lc, a preferred embodiment of each user information

appliance 120 and 122, and of each individual one ofthe information appliances 150 and 160,

is shown, and is identified by reference numeral 2. The user infomiation appliance 2

comprises a controller (such as one or more microprocessors and/or logic arrays) 2a for

performing arithmetic and/or logical operations required for program execution, one or more ports 2b for bidirectionally coupling the controller 2a to a respective link L3, L4, one or more

input user-interfaces 2d that are each coupled to the controller 2a, and at least one output

user-interface 2e that also is coupled to the controller 2a. In the case ofthe information

appliances 120, 122, and 150 (Fig. lb), the port(s) 2b enable(s) the controller 2a of those

appliances to communicate bidirectionally with the server 107' and with other appliances

through the respective port(s) 2b, the respective links L3, and the interface 190. Similarly, in

the case ofthe information appliances 160, the port(s) 2b enable(s) the controller 2a of those

information appliances to communicate bidirectionally with the server 107' and with other

infomiation appliances through the respective port(s) 2b, the links L3' and L4, the interface

164, transceivers 163, 167, and the interface 190.

The input user-interface 2d (Fig. lc) may include, for example, a keyboard, a

mouse, a trackball, touch screen, and/or any other suitable type of user-operable input

device(s), and the output user-interface 2e may include, for example, a video display, a liquid

crystal or other flat panel display, a speaker, a printer, and/or any other suitable type of output

device for enabling a user to perceive outputted infomiation. The input user-interface 2d of

each worknode 120, 122 is further identified by reference numeral 120a, 122a, respectively,

in Fig. lb, and the output user-interface 2e of each worknode 120, 122 is further identified by

reference numeral 120b, 122b, respectively, in that figure. For the purposes of this

description, the output user-interfaces 120b and 122b are assumed to be displays. The other

user infomiation appliances 150 and 160 may also include similar input and output user

interfaces, although for convenience, they are not shown in Fig. lb. Referring again to Fig. lc, each user information appliance 2 also comprises

one or more associated memories (e.g., disk drives, read-only memories, and/or random

access memories) 2c that are bidirectionally coupled to the controller 2a. The memory 2c

stores temporary data and instructions, and also stores various routines and operating

programs that are used by the controller 2a for controlling the overall operation ofthe user

information appliance 2. A temporary read- write sub-memory 2c- 1 of the memory 2c stores

infomiation while the infomiation is being presented by the output user-interface 2e,

including corresponding infomiation entered by a user through the input interface 2d.

Preferably, the programs stored in the memory 2c of user information

appliance 2 include Microsoft Outlook 2000 (or later versions thereof), Microsoft Remote

Data Services (MRDS) 2.5 (or later versions thereof), Microsoft Internet Explorer (IE) 5.0 (or

later versions thereof), Microsoft Office 2000 (or later versions thereof), and at least one

spreadsheet component of Microsoft Office Web Components (MOWC) 9.0.2710 (or later

versions thereof). Microsoft Outlook 2000, a type of infomiation management software, is an

HTML-based messaging and collaboration software program, which provides infomiation

management capabilities and facilitates communication and collaboration throughout an

enterprise. The Outlook 2000 software functions as a knowledge-management portal to

pemiit visualization, filtering, organization, customization, and navigation of information,

and the Microsoft Office Web Components provides with Excel 2000 certain electronic

spreadsheet visualization and control capabilities. In addition, memory 2c can also include a

tool to create views of infomiation, referred to as the Dynamic View Manager. The Dynamic

View Manager is described in co-pending U.S. Patent Application No. 09/434,794, filed November 5, 1999, entitled "Method, Apparatus And Program For Delivery And Display Of

Information From Dynamic And Static Data Sources, by Stephen J. Scimone et al., and to the

Computer Program Appendix incorporated by reference therein. The contents of that patent

application and the incorporated Computer Program Appendix are incoφorated by reference

herein in their entireties, as if fully set forth herein.

In one embodiment of this invention, at least some ofthe routines stored in the

memory 2c include various Component Object Model ("COM") Add-ins, which preferably

are a Chat COM Add-In lOlf (Fig. 6a), a Reminder Add-In, a Quote COM Add-In, a

Portfolio COM Add-In, and a Limit Minder COM Add-In. A COM Add-In is an ActiveX

dynamic link library (or .dll) which adds additional functionality to a Microsoft Office

application. COM Add-ins can be built using any COM development software, such as

Visual Basic, Microsoft Visual C++, etc. When these COM Add-ins are executed by the

controller 2a in a user infomiation appliance, they extend the functionality and usefulness of

the Outlook 2000 software, as explained further below. COM Add-ins generally are opened

when the Outlook software is executed and close when the Outlook software closes, although

the COM Add-ins can be configured by one of ordinary skill in the art to open and close at

other points in time or upon the occurrence of other predetermined events. The specifics of

the COM Add-ins described herein are readily apparent to one of ordinary skill in the art

given this disclosure. In addition, as would be readily apparent to one of ordinary skill in the

art, there are functions provided by COM Add-ins herein which can be implemented in other

ways, such as by use of form scripting, and vice versa. According to a preferred embodiment of this invention, the memory 2c ofthe

user information appliance 2 also stores a cache of individual electronic forms. This cache is

created after the individual forms are retrieved for the first time by a user from the server

memory 107a during the course ofthe methods ofthe invention. Those individual forms may

be displayed by the output interface 2e in a known manner, and corresponding information

representing the displayed form is stored in the sub-memory 2c- 1. The electronic forms will

be described in detail below.

Referring again to Fig. lb, the server 107' and the associated memory 107a of

that figure collectively represent the server 107 shown in Fig. la. The memory 107a stores

various operating programs and routines for controlling server operations. In a preferred

embodiment, one ofthe programs stored in memory 107a is web server software, preferably

Microsoft Internet Infomiation Server ("IIS") (or later versions thereof), running on a

Windows platform. Also in the preferred embodiment, another program stored in the memory

107a is Microsoft Exchange 2000 (or later versions thereof), a type of information

management software used by the server 107' for performing messaging and collaboration

functions, and for providing folder functionality, particularly for utilizing folders to organize

database store information. Folder contents are stored within memory 107a, and are

accessible by users ofthe infomiation appliances 120, 122, 150, and 160 through the server

107'. Any suitable known technique may be employed for creating the folders, and for

enabling users ofthe infomiation appliances 120, 122, 150, and 160 to access (i.e., "open"),

store, view, and retrieve infomiation from those folders. Preferably, such

functionalities/capabilities are provided by Microsoft Outlook 2000 (or later versions thereof), operating in conjunction with Microsoft Exchange 2000 (or later versions thereof)

running in server 107'.

An example of a hierarchy of Exchange folders utilized in this invention is

depicted in Fig. 2. The hierarchy includes main folders FI to Fn, which are assumed to

correspond to predetermined parties PI to Pn, respectively. In accordance with one

embodiment ofthe invention, the hierarchy also includes an "Order Book" folder 502, which

can be opened by any user ofthe communication system 200' for viewing the contents

thereof. The folder 502 is employed for storing transaction-related information "posted" in

an electronic "bulletin board" by a sub-party, such as, e.g., an individual (user UI, UI')

within an organization identified as party PI, P2.

In accordance with this invention, a plurality of sub-folders SFl-SFn and SF1'-

SFn' preferably also are included in the folder hierarchy, as contents ofthe main folders FI

and F2, respectively (similar folders are also assumed to be included as contents of main

folders F3-Fn, although for convenience this is not shown in Fig. 2). Sub-folders SFl to SF5-

b, SFl' to SF5-b' are contents of folders FI and F2, respectively, and include a "Nettings"

folder, a "Positions" folder, a "Settings" folder, an "Incoming Calls" folder, and, in

accordance with one embodiment, a "Deals Done" folder, an "Order Book" folder, and a

"Credit" folder, respectively. The "Nettings" folder SFl, SFl' is employed for storing

nettings infomiation representing a sum total (roll up) of completed transactions performed

by the corresponding party PI, P2, on a counter-party and market item (e.g., currency) basis,

the "Positions" folder SF2, SF2' is employed for storing positions information representing a sum total of all transactions performed by a party PI, P2 with all other parties, and "Settings"

folder SF3, SF3¹ is employed for storing user-defined and user-modifiable configuration

(preference) information that can be used to modify the behavior ofthe trading system in a

desired manner. For example, that information may specify that one or more predetermined

procedures be performed in response to the occurrence of one or more predetermined events.

As but one example, the information may specify that a "call forwarding" procedure be

implemented in response to a information being stored in a corresponding "Incoming Calls"

folder SF4, SF4', for causing the infoπnation to be forwarded to one or more other

predetermined folders/mailboxes, etc., such as an "Incoming Calls" folder of another party,

although in other embodiments, other desired procedures may also be implemented.

The "Incoming Calls" folder SF4, SF4' stores transaction information

proposed or "posted" to parties PI, P2, respectively, by another sub-party. Also, the "Deals

Done" folder SF5, SF5' stores information relating to transactions completed using an

electronic "bulletin board" trading embodiment ofthe invention, the "Order Book" folder

SF5-a, SF5-a' stores transaction-related infomiation "posted" in an electronic "bulletin

board" by a sub-party, and "Credit" folder SF5-b, SF5-b' stores credit information defining

various conditions under which the respective parties PI, P2, will engage in a transaction.

Sub-folders SF6-SF11, SF6'-SFn' also are contents of main folders FI, F2,

respectively, and include folders "User UI" to "User Un" and "User Ul"' to "User Un'",

respectively. Each ofthe sub-folders SF6-SFn corresponds to a respective, predetermined

sub-party (e.g., an individual (user UI) within an organization identified as party PI), and each ofthe sub-folders SF6'-SFn' also corresponds to a respective, predetermined sub-party

(e.g., an individual (user UI') within an organization identified as party P2). A plurality of

user sub-folders USFl to USF7 and USFl' to USF7' are also included in the folder hierarchy,

as contents ofthe sub-folders SF6-SFn and SF6'-SFn', respectively (although for

convenience, only those sub-folders USFl to USF7 and USFl' to USF7' of sub-folders SF6

and SF6', respectively, are shown in Fig. 2). Each of those user sub-folders USFl to USF7,

USFl' to USF7' corresponds to the same sub-party UI, UI' to which respective sub-folders

SF6 and SF6' correspond.

User sub-folder USFl, USFl' is a "Current Conversations" folder, and is

employed for storing information representing current transactions being negotiated by the

sub-party UI, UI' corresponding to that folder, and sub-folder USF2, USF2' is a "Log" folder

that is employed for storing infoπnation representing a record of transactions conducted by

the conesponding sub-party UI, UI' (i.e., "Log" folder USF2, USF2' stores a history of

conversational transaction items exchanged between the respective sub-party UI, UI' and

other sub-parties). User sub-folder USF3, USF3' is a "Nettings" folder that is employed for

storing nettings information representing a sum total (roll up) of completed transactions

performed by the conesponding sub-party UI, UI', on a counter-party and market item (e.g.,

cuπency) basis, and user sub-folder USF4, USF4' is an "Outgoing Calls" folder that is

employed for accepting and storing messages representing information transmitted by the

conesponding sub-party UI, UI' to another party. User sub-folder USF5, USF5' is a "Trade

Blotter" (also refened to as a "Ticket Blotter") folder that is employed for storing information

representing a finally-confirmed transaction perforated by the conesponding sub-party Ul,U , and user sub-folder USF6, USF6' is a "Positions" folder that is employed for storing

positions information representing a sum total of all transactions performed by the

conesponding sub-party UI, UI' with other sub-parties. Moreover, user sub-folder USF7,

USF7' is a "Deals Awaiting Review" folder that is employed for storing information relating

to a preliminarily confirmed transaction (which needs to be finally confirmed in order to be

effected) entered into by the conesponding sub-party UI, UI'. The manner in which the

various folders and sub-folders ofthe folder hierarchy shown in Fig. 2 are employed in the

invention will be explained in greater detail below. It should be noted that, although the

foregoing description refers to the individuals (e.g., user UI, UI') associated with parties Pl-

Pn as "sub-parties", throughout the remainder of this description the words "sub-party" and

"party" are used interchangeably to refer to those individuals.

Inclusive ofthe programs stored in the memory 107a are routines for

monitoring for the occunence of one or more predetemiined events, and for performing

predetennined operations and/or invoking other routines in response to a detection of an

occunence of one or more of those events. For example, one such routine is preferably the

Synchronous Event Service (SES) provided by Microsoft Exchange 2000. The SES monitors

for information being stored in or deleted from individual ones ofthe folders SF1-SF5, SF1'-

SF5', USF1-USF7, USF1'-USF7', and 502, described above, and responds to detecting the

occunence of such events by invoking into operation other predetermined routines stored in

the memory 107a, such as "event handler routines" (see, e.g., Event Handler Source Code).

An event handler routine can be implemented in various ways, for example, as a Dynamic

Link Library (.dll) or in a scripting language such as Microsoft's VB Script. An event handler routine performs one or more predetermined operations in response to being invoked

by the SES. For example, each event handler routine is associated with a respective one of

the folders SF1-SF5, SF1'-SF5', USF1-USF7, USF1'-USF7', and 502, and responds to being

invoked by the SES by performing predetermined operations such as, for example, invoking

predetermined business object routines (described below) into operation to enable copying

and routing of information from a conesponding folder, to one or more other predetermined

folders, as will be further described below. Preferably, one or more messaging service

programs are also stored in the memory 107a, to enable various messages, such as, e.g.,

electronic mail or instant messaging messages, to be exchanged between user information

appliances.

Also inclusive ofthe programs stored in the memory 107a are one or more

business object (e.g., Business Object ActiveX.EXE) routines (each of which is also

hereinafter refened to as "the business object routine") that perform various predetermined

operations in response to being invoked, such as, for example, controlling the storage,

retrieval, and transfer, of information to and from the folders, and determining transaction

summary information, as will be described below. In accordance with one embodiment of

this invention, one ofthe business object routines also generates unique identifiers for

respective transactions during the course of performance of a method of this invention.

Preferably, the business object routine generates the unique identifiers by incrementing a

value of a counter variable 107b stored in memory 107a, although in other embodiments,

other suitable techniques for generating such identifiers may also be employed, such as a

technique for generating a Global Unique Identifier (GUID). (see, e.g., Business Object

Routine Source Code). As was previously described, the memory 107a associated with server 107

stores a plurality of electronic forms (templates) that can be retrieved by a user of an

information appliance 120, 122, 150, 160, and temporarily stored and displayed by the

information appliance, during the performance of methods in accordance with this invention.

The electronic forms are preferably Microsoft Outlook 2000 (or later versions thereof)

electronic forms, at least some of which have been modified in accordance with this invention

to include various custom items, such as, for example, various read-only information and

various information fields into which a user can input information and/or modify presented

information. Also, a customized form script in accordance with this invention is associated

with each ofthe electronic forms.

An example of a data structure of an electronic form 34 used in this invention

is shown schematically in Fig. 3b. The fomi 34 includes 1) form code information 36, which

represents the read-only infomiation ofthe fomi, 2) data 38, which represents the user

entered/modified information, and 3) a form script 40. The form script 40 is responsive to an

occunence of one or more predeteπnined events, such as, for example, a user selecting a

predetermined displayed option item ofthe form, for increasing/decreasing values or

otherwise setting states of various flags ofthe form 34, including a "confirm" flag 40a, a

"cancel" flag 40b, and a "most recent post" flag 40c, and a "transfer flag" 40d, or for

performing one or more other predetennined operations (see, e.g., Form Source Code, CE

Form Source Code, CEExpireOrder Source Code, CEPostCall Source Code). The form script

40, flags 40a-40d, and infomiation 34, 38 ofthe various electronic forms 34 employed in this

invention will be described further below. Referring again to Fig. lb, the server 106' and information sources 140 and

141 will now be described. The server 106' has one or more associated memories 106a that

store various operating programs and routines for controlling server operations, and which

also include, in accordance with one embodiment ofthe invention, a database table 500

(hereinafter refened to as an "Order Book" table 500) which stores transaction-related

information "posted" by a party in an electronic "bulleting board", a database table 504

(hereinafter refened to as a "Deals Done" table 504) which stores information relating to

fulfilled ones of those transactions, and at least one "credit" table 910 which stores various

information relating to conditions under which one or more particular parties Pl-Pn will

engage in a transaction with other, predetermined counter-parties Pl-Pn and/or counter sub-

parties (e.g., users UI, UI').

In a prefened embodiment, Microsoft Structured Query Language Server

("SQL Server") is one ofthe programs stored in memory 106a, and is used by the server 106'

for performing database query and other known functions. Predetennined routines for

performing various operations are also stored in the memory 106a, including SQL "stored

procedures" that create, maintain, and list order and deal information in the respective

database tables 500, 502, and 910 in response to the occunence of one or more predetermined

events (see, e.g., SQL Scripts Source Code), and custom programs (hereinafter refened to as

"database synchronizer programs") such as, for example, customized NT services, which,

when invoked by a stored procedure, reproduce infoπnation from database tables 500 and 502

in conesponding ones ofthe (Microsoft Exchange) folders 502 and SF5, SF5', respectively,

stored in memory 107a (see, e.g., Order Book Folder Update Source Code, Deals Done

Folder Update Source Code, ExtendSP Source Code). Although in the prefened embodiment the server 106' and server 107' are separate, a single server can alternatively be utilized that

combines the functions of these servers, which are described herein. Likewise, instead of use

of database query software as in the prefened embodiment, the functionality ofthe

information management software can be utilized to perform the various functions (described

herein) provided by the database query software.

The ability to use and write applications for the Microsoft product suite

(including, e.g., Outlook 2000, IIS, Exchange 2000, and SQL Server), using at least

Microsoft Office Server extensions SDK, Microsoft Visual Development tools, and Back

Office Servers and Server Services, is within the knowledge of one of ordinary skill in the art,

and is assumed for this description. In this regard, reference may be had to the following

publications, each of which is incoφorated by reference herein in its entirety: Programming

Microsoft Outlook and Microsoft Exchange, by Thomas Rizzo, Microsoft Press, 1999; and

Building Applications with Outlook 2000: Technical Reference, Randy Byme, Microsoft

Press, 1999. It should be understood, however, that the invention is not limited to being

implemented using only the Microsoft products refened to above (or products of any

particular organization), but may also be implemented using any suitable type of existing or

later developed software/techniques having similar functionalities. Also, the Exchange 2000

Workflow Engine (or later versions thereof) may advantageously be used to develop and

implement the various event handlers used in this invention to interact with the Exchange

folders, (see, Workflow Events Screenshot Source Code, Workflow Events (SML) Source

Code, Workflow Event Scripts Source Code). The information source 140 employed in one embodiment of this invention

represents a source of real-time information for a wide variety of instruments (e.g., "quotes"),

such as equities, IRS (Interest Rate Swap) fixed rate instruments, IRS floating rate

instmments, Foreign Exchange (FX) instmments, Commodities, Energy, Debt, Bonds, etc.

An example of one source 140 includes IDN, which is Reuters' proprietary backbone

Network. IDN makes available to subscribers trading information and other information

provided by stock exchanges and various other sources throughout the world. The source 140

preferably provides a dynamic data stream for enabling financial information to be reported

in real-time. Apart from this invention, a commercial information provider generally makes

the source 140 available to subscribers by provision of a dedicated data line with suitable

hardware and proprietary software. The manner in which the information source 140 is

employed in this invention will be further described below.

The information source (also refened to as an "infomiation service") 141

represents a service for providing infomiation regarding the creditworthiness of a party and/or

sub-party. More particularly, and in one embodiment of this invention, the information

source 141 is a source of information specifying conditions under which one or more parties

will engage in a transaction with other partiesΛsub-parties, and that information is provided

from the source 141 to the "Credit" table 910 within server memory 106a. In other

embodiments ofthe invention, the information source 141 may be employed in lieu ofthe

table 910, and may provide credit-related infoπnation to a particular destination, such as, for

example, the server 106' or some other destination, in response to receiving a request for such

infomiation. The manner in which the infomiation source 141 is employed in this invention

will be further described below. It should be noted that while this invention is described in the context of

information being provided from the source 140 to the network 100 through the server 107',

in other embodiments the information may be provided to intended network destinations

without passing through the server 107'. For example, depending on applicable network

architecture and/or design requirements, no server 107' need be employed, and the

information from the source 140 may be provided to intended network destinations by way of

other suitable interface components, such as, for example, modems and the like. In other

embodiments, the information sources 140 and 141 each may be provided with their own

servers, or the functionalities of both ofthe servers 106' and 107' may be provided in a single

server that is coupled to the sources 140, 141 and the network interface 100. It should also be

noted that although the servers 106' and 107', memories 106a and 107a, and information

sources 140 and 141 are depicted in Fig. lb as being external to the network (components

above dashed line 90 are assumed to be external to the network 100), in other embodiments

one or more of those components 106', 107', 106a, 107a, 140, and 141 may be included in the

network 100, or the network 100 may have its own dedicated server(s) and information

sources, in addition to those shown in Fig. lb. In the latter case, the above-described folders

and the contents thereof may be replicated in a memory ofthe dedicated server(s). It should

therefore be understood that the present invention is not limited to being implemented only in

a communication system 200" having the particular configuration shown in Fig. lb. D ELECTRONIC TRADING NEGOTIATION EMBODIMENTS

(A) PROPOSING A DEAL

A method in accordance with one embodiment of this invention will now be

described, with reference to the flow diagrams shown in Figs. 4a-4d. In this embodiment of

the invention, users ofthe communication systems 200', 200" can electronically propose,

negotiate, and conduct trades of any types of instmments or goods or services (although for

convenience, the following description is described in the context of a trade of a financial

instrument, e.g., Foreign Exchange).

At step Al of Fig. 4a the method is started, and it is assumed that a user UI of

information appliance 120 desires to propose a transaction to a user UI'. It also is assumed

that the user UI interacts with the display 120b by operating the user interface 120a to cause

an electronic call form (or customized contact fomi) to be downloaded from the server

memory 107a and displayed on the display 120b, by, e.g., Microsoft Outlook 2000 (or later

versions thereof) operating in conjunction with Microsoft Exchange 2000 (or later versions

thereof) running on server 107' (step A2). For example, the user UI can cause the electronic

call form to be displayed by selecting a predetennined displayed option on a predetermined

HTML page (not shown), or by opening a predetennined Exchange folder (not shown) from

memory 107a and selecting a "New" option item (not shown) that is displayed upon the

folder being opened. The call fom is preferably a Microsoft Outlook 2000 (or later versions

thereof) electronic fom that has been modified in accordance with this invention to include various fields. An example of a call form in accordance with a prefened embodiment ofthe

invention is depicted in Fig. 3 a, and is identified by reference numeral 10.

In accordance with a prefened embodiment of this invention, the call form 10

includes various read-only fields, such as a dealer identification field 9, that includes

information identifying the party or organization (e.g., party or organization PI) with which

the user UI who selected the call fonn 10 in step A2 (such information also is refened to as a

"trading company ID (TOD)") is associated. The field 9 is populated in a known manner

based on mapping information, relating to users and their associated parties Pl-Pn, stored in a

particular folder (not shown) in memory 107a. Another read-only field ofthe call form 10 is

field 35, which includes infomiation identifying the date and time at which the form 10 is

retrieved from the memory 107a. That field 35 also is populated in a known manner, based

on time kept by an internal clock (not shown) operating within the server 107. The

infomiation included in fields 9 and 35 is collectively represented by the form code

information 36 of Fig. 3b described above.

The call fonn 10 of Fig. 3a preferably also includes a plurality of user-editable

fields 12-28 into which a user can enter transaction-related information and/or modify

existing transaction-related infomiation appearing in the fields (such field information is

collectively represented by the fonn data 38 of Fig. 3b). For example, field 12 is employed

for enabling a user to specify an identifier (e.g., a TCID) 12a of a party or organization (e.g.,

PI, PI') to whom the user desires the transaction to be proposed, and fields 24 and 26 are

employed for enabling a user to specify respective first and/or second cunency codes (e.g.,

USD, BEF, CAD, DEM, GBP, etc.) which he desires to buy and/or sell, respectively, in the transaction. Also, field 28 is employed for enabling a user to specify a desired volume ofthe

first or second cunency code entered into a respective one ofthe fields 24, 26, and field 16

enables the user to enter a message (e.g., "I propose the following transaction to. . .") he

desires to be provided to the party identified by the information in field 12. The user may

enter information into each individual field 12, 16, 24, 26, and 28 by, for example, selecting

(e.g., pointing a display cursor to a selected field using a mouse, and depressing a

predetermined button on the mouse) the field and entering desired information into the field,

using a user interface (e.g., 120a, 122a). In other embodiments, in response to the call form

10 being retrieved in step A2, a directory of pre-stored identifiers and cunency codes is

accessed, and at least one ofthe pre-stored identifiers and codes is retrieved from memory

107a and displayed, along with the form 10, in a pull-down menu in a conesponding field 12,

24, and 26 ofthe form 10, using a known teclinique (e.g., form scripting). A user UI, UI' can

then select particular ones of those displayed identifiers and/or codes by interacting with the

worknode display 120b, 122b, using the user interface 120a, 122a, respectively.

The field 14 of fomi 10 is employed for enabling a user UI to specify whether

or not the proposed transaction is to be a multi-deal transaction proposal (i.e., the user UI

may propose multiple deals/transactions, as will be described below), and field 18 is

employed for enabling the user to specify whether or not he is proposing to buy the cunency

specified in field 24 in the proposed transaction. Field 20 is employed for enabling a user to

specify whether or not he desires to sell the cunency specified in field 26 in the proposed

transaction, and field 22 is employed for enabling the user to specify whether or not the

proposed transaction is to be a two-way transaction (e.g., a transaction where the user desires

to buy the cunency specified in field 24 and sell the cunency specified in field 26) to make a market. A user UI may toggle between 'selecting' and 'de-selecting' the individual fields 18,

20, and 22 by, for example, operating the user interface 120a, 120b, respectively (although,

only a single one of those fields 18, 20, and 22 may be 'selected' at any given time).

Referring again to Fig. 4a, step A3 will now be described. In step A3 it is

assumed that user UI enters an identifier 12a conesponding to party PI' (PT is the party or

organization with which user UI' is associated ) into the field 12 of form 10, and also enters

appropriate transaction-related information into the fields 24-28 of that form 10 in the above-

described manner, and that, as a result, the entered information is stored in the sub-memory2c

of infomiation appliance 120. Thereafter, the user UI may specify that a transaction proposal

defined by the entered transaction-related information be forwarded for presentation to the

party identified by the identifier 12a by, for example, selecting a "transmit" item 30 ofthe

displayed electronic call fomi 10.

The form script 40 (Fig. 3b) associated with the electronic form 10 responds to

the item 30 being selected in step A3 by causing the fomi infoπnation 36 and 38 (including

the infomiation entered by the user UI in step A3) to be forwarded from the worknode 120 to

the memory 107a, through the network components L3, L2, 190, and 107', and to be stored in

the "Outgoing Calls" folder USF4 associated with the originating sub-party (e.g., UI)

identified by the identifier infoπnation (originally included in field 9) included in the

information 38 (step A4).

In step A5, the SES detects that the infomiation 36 and 38 has been stored in

the folder USF4 in step A4, and responds thereto by invoking the conesponding event handler routine in memory 107a to act on that information 36 and 38. In response to being

invoked by the SES, that event handler routine copies the information 36 and 38 from the

"Outgoing Calls" folder USF4 to the "Incoming Calls" folder SF4' conesponding to the sub-

party (e.g., user UI') identified by the identifier 12a (i.e., the identifier 12a previously entered

into field 12 in step A3), (see, e.g., OutgoingCallsFormScript; Outgoing Calls).

At some time later, it is assumed that user UI' interacts with worknode 122

through interface 122a to cause the "Incoming Calls" folder SF4' to be opened, and the

information stored (in previous step A5) therein displayed on the display 122b (step A6). As

a result, the information is displayed in a manner as shown in, for example, window 46 of

Fig. 3d. In Fig. 3d, the displayed infomiation 9', 18', 20', 26', 28', and 35' is collectively

represented by reference numeral 47, and conesponds to the infomiation previously included

in the fields 9, 18, 20, 26, 28, and 35, respectively, of fonn 10. The information 47 is also

hereinafter refened to as an "information item 47", and a field 9" represents the recipient's

identifier.

In step A7 it is assumed that the user UI' operates the user interface 122a to

cause the information 47 (Fig. 3d) to be selected. In response thereto, an electronic deal form

and a form script 40 associated with that form is invoked (step A8). The electronic deal form

is retrieved from memory 107a. The invoked form script 40 retrieves the information 36 and

38 (conesponding to that entered in earlier step A3) from the "Incoming Calls" folder SF4',

and inserts that infomiation into conesponding fields ofthe retrieved deal form. Thereafter,

the form, including the inserted infomiation, is displayed on the display 122b (step A9 of Fig.

4b). An example of a prefened electronic deal form is identified by reference

numeral 50 in Fig. 3f. Preferably, the deal form 50 includes a plurality of read-only fields 76-

82, and also includes a plurality of user-editable fields 52-66 into which a user can enter

transaction-related information and/or modify transaction-related information presented in the

fields (the information included in fields 52-66 also is collectively represented by the form

data 38 of Fig. 3b). Field 78 is employed for including the retrieved first and/or second

cunency code information, field 82 is employed for including information identifying the

date and time at which the fonn 50 is retrieved from the memory 107a (and is preferably

populated in the above-described manner, based on the time kept by the internal clock (not

shown) within the server 107'), and field 80 is employed for including the TCID identifying

the party ofthe user UI (e.g., party PI) from whom the transaction proposal information was

received in step A5. Also, field 76 is employed for including information identifying a deal

status. Preferably, such deal status infomiation is detemiined by the form script 40, based on

one or more predetermined counter and/or flag values (such as "confirm" flag 40a) that are

controlled in response to the information 47 being selected in step A7, although in other

embodiments, other suitable techniques may also be employed for determined the deal status

infoπnation.

Preferably, the information specifying the volume ofthe cunency specified by

user UI in earlier step A3 is included in the field 66, and fields 62 and 64 are employed for

presenting infomiation specifying a bid (buy) rate and an offer (sell) rate, respectively. The

bid and offer rate infoπnation is preferably detemiined by information received from

infomiation source 140 by the fom script 40 based on the infoπnation entered into the fields

24 and 26 ofthe call fonn 10 in earlier step A3, depending on whether the "buy" item 18 or "sell" item 20 was selected in that step. If, in step A3, the "2-way" transaction field 22 ofthe

form 10 was selected instead, then the fields 62 and 64 are preferably populated in step A9

with real-time reference pricing information retrieved from the information source 140, in a

manner as will be described in further detail below. If in step A3, the "Buy" transaction field

18 ofthe form 10 was selected, then only field 64 is populated with real-time pricing

information. If in step A3, the "Sell" transaction field 20 ofthe form 10 was selected, then

only field 62 is populated with real-time pricing information. Fields 52 and 56 ofthe deal

form 50 are employed for enabling a user to specify payment date instructions (e.g., calender

control information, which can be set to default to an exact date or reference date, such as

"two business days from present date") for the first and second cunencies, respectively, fields

54 and 58 represent (or will represent) payment instructions for the counter party PI (this

information will be later entered by counter sub-party UI) (e.g., information specifying a

bank and a bank location) for those first and second cunencies, respectively, and field 60

includes the message specified by user UI in earlier step A3.

If user UI' desires to modify the information presented in fields 66, 62, and/or

64, and/or enter information into the fields 52, 54 and/or 60, he may do so by operating the

user interface 122a in the above-described manner. In one embodiment, a directory of pre-

stored infoπnation stored in memory 107a is accessed in response to the deal form 50 being

retrieved in step A9, and information conesponding to the respective fields 52 and 54 is

retrieved and displayed in a pull-down menu in respective ones of those fields, using a known

teclinique. For example, in one embodiment ofthe invention, default payment dates or date

references (e.g., "two business days from the cunent date") are retrieved from memory 107a

and displayed in a pull-down menu in conesponding field 52 in step A9, and a list identifying predetermined, pre-approved banks to which payment can be transfened is accessed from

memory 107a and displayed in a pull-down menu in field 54 in that step A9. A user UI, UI¹

can then select particular information from those displayed pull-down menus by interacting

with the worknode display 120b, 122b, using the user interface 120a, 120b, respectively.

( ) ACCEPTING A PROPOSED DEAL (PRELIMINARY CONFIRMATION!

The deal form 50 also preferably includes a plurality of option items 67-74,

including a "transmit" item 67, a "no deal" item 68, a "done" item 70, a "transfer" item 74,

and a "chat" item 72, each of which may be selected by a user to invoke a predetermined

operation, as will be described below. Refening again to Fig. 4b, it is assumed that the user

UI' desires to accept the transaction proposed by user UI, and thus operates user interface

122a to cause the displayed item "done" 70 to be selected ('Y' in step A10), without first

modifying the information included in the fields 52-66 ofthe form 50. Alternatively, if the

user UI desires to modify the teπns ofthe transaction prior to selecting the "done" item 70 in

step AlO, then he may do so by editing the infomiation in selected ones ofthe fields 52-66.

Thereafter, the user UI' may select the displayed "done" item 70 to "accept" the modified

version ofthe transaction ("Y" in step AlO). In either case, the fonn script 40 associated with

the form 50 responds to the "done" item 70 being selected in step AlO by increasing a value

(assumed to be initially '0') ofthe "confiπn" flag 40a (Fig. 3b) ofthe fonn 50 by '1', invoking

the business object routine, and by providing that routine with the information 36 and 38

(representing the displayed deal fonn 50) from the sub-memory 2c-l of infoπnation appliance 122 (step Al 1). Preferably, the form script 40 also sets a "most recent post" flag 40c in the

form 50 in step Al 1 to indicate that the transaction is in a most recent state.

In response to being invoked in step Al 1, the business object routine causes

the value of counter variable 170b in memory 107a to be increased by '1' to assign a unique

identifier to the transaction identified by information 36 and 38 (step A12). Thereafter, in

step A13 the business object routine causes that infoπnation 36, 38, including the values of

flags 40a, 40c and counter variable 170b, to be stored in both the "Cuπent Conversations"

folder USFl associated with identifier information (identifying user UI) from field 80, and

the "Cuπent Conversations" folder USFl' associated with the user UI' (step A13) (see, e.g.,-.

The stored information represents a transaction that has been "accepted" or initially

confirmed by the user UI'.

In step A14, the invoked business object routine retrieves the information

stored in the "Incoming Calls" folder SF4' in previous step A5, and forwards that information

to the "Cuπent Conversations" folder USFl associated with user UI, to provide a record of

the original transaction proposed by the user UI (in earlier step A3) in that folder USFl. As a

result, the original transaction item is removed from the Incoming Calls folder SF4'

associated with user UI'.

At some time later, it is assumed that user UI operates the interface 120a to

cause the "Cuπent Conversations" folder USFl to be opened and the contents thereof to be

displayed on the display 120b (step A15). For example, the information may be displayed in

a manner as shown in window 48 of Fig. 3e, wherein the displayed information 82', 36', 9a', 78a', 78b', 66', 64', 62', and 21' is collectively represented by reference numeral 47', and is

also hereinafter refened to as "information item 47"'. Preferably, the information 47' is

highlighted or otherwise visually distinguished from other displayed information (not shown)

from the folder USFl, to indicate that the information 47' represents a most recent "post"(and

state) ofthe transaction. For example, the information 47' may be highlighted in response the

"most recent post" flag 40c being detected in the folder USFl, after the folder USFl is

opened in step Al 5.

In Fig. 3e, the information 82', 66', 64', and 62' coπesponds to the information

previously included in fields 82, 66, 64, and 62, respectively, of form 50. The information

9a' of Fig. 3e identifies the counter-party (e.g., user UI') from whom the information stored

in folder USFl was received, and the infomiation 78a', 78b' specifies the first and/or second

cunency value(s), respectively, and conesponds to the respective first and second cunency

infomiation previously included in field 78 ofthe deal fonn 50. Also, the infoπnation 36'

specifies the unique identifier (e.g., the value of counter variable 170b) ofthe transaction

defined by the infoπnation stored in folder USFl, and the information 21' identifies the status

ofthe transaction. That infoπnation 21' is preferably determined based on the value ofthe

"confirm" flag 40a stored in the folder USFl. For example, the information 21' may specify

a message such as "Part Complete" in a case where the value of "confirm" flag 40a is '1'.

At some time after the information 47' is displayed in step 15, it is assumed

that the user UI operates the user interface 120a for selecting the collective information 47'.

As a result, an electronic deal fonn 50 is retrieved from the server memory 107a and the

information 36, 38 stored in the "Cuπent Conversations" folder USFl (in earlier step A13) is copied and inserted into conesponding fields ofthe retrieved form 50. The retrieved form 50,

including the inserted information, is then displayed on the display 120b, as shown in, for

example, Fig. 3f (and also is stored in sub-memory 2c-l of worknode 120) (step A16).

Control then passes to step A17 of Fig. 4c.

(C) ACCEPTING A PROPOSED DEAL (SECONDARY CONFIRMATION

In step A17, the user UI may make a secondary confirmation ofthe

transaction defined by the information included in the fields ofthe displayed form 50 by

selecting the "done" item 70 ofthe form 50, either after modifying/entering information in

selected ones ofthe fields 52-66, or without first entering/modifying that information. In

either case, the form script 40 associated with the fonn 50 responds to the "done" item 70

being selected in step A17 ('Y' at step A17) by increasing the value ofthe "confirm" flag 40a

(Fig. 3b) ofthe form 50 by T, and invoking another (second) business object routine for

updating various summary infoπnation for the user UI in the "Nettings" and "Positions"

folders USF3 and USF6, respectively, of user Ul(step A18-a). The manner in which the

summary infomiation is updated will be described in detail below.

The form script 40 also stores the infomiation 36, 38, from sub-memory 2c- 1

of information appliance 120, in the "Cunent Conversations" folder USFl associated with the

user UI (step A18-b). Thereafter, the SES responds to the information being stored in the

folder USFl by invoking the event handler routine conesponding to that folder USFl. The

event handler then responds to being invoked by the SES by copying the information which was stored in folder USFl in earlier step A18-b to the "Cunent Conversations" USFl'

associated with user UI' (step A18-c).

In step A19-a the SES responds to the information 36, 38 being stored in the

folder USFl' by invoking the event handler associated with folder USFl'. The event handler

then examines the value ofthe "confirm" flag 40a included in the infoπnation. Assuming

that the event handler determines that the value ofthe "confirm" flag 40a is '2' (indicating

that both users UI and UI' have confirmed the transaction), then the event handler routine

copies the information (representing the most recent transaction item) which was stored in

folder USFl' in earlier step A18-c to both ofthe "Deals Awaiting Review" folders USF7 and

USF7' associated with the respective users UI and UI' (step A19-b). In accordance with one

embodiment ofthe invention, the invoked event handler routine also conelates the value of

the counter variable 107b (representing the transaction identifier), included in the information

copied from folder USFl', to information items (representing the various stages ofthe

transaction) having a same associated value (identifier), stored in the "Cunent Conversations"

folders USFl and USFl', and then moves the conelated information items from those folders

USFl and USFl' to the "Log" folders USF2 and USF2', respectively, so as to provide an

historical record ofthe transaction therein (step A20).

CD) FINALLY CONFIRMING A DEAL

Each ofthe "Deals Awaiting Review" folders USF7 and USF7' may be opened

subsequently by the respective users UI and UI', for making a final confiπnation ofthe

transaction defined by the information stored therein. For example, it is assumed that at some time after the performance of step A20, the user UI operates the user interface 120a so as to

cause the "Deals Awaiting Review" folder USF7 to be opened. As a result, the information

stored in that folder USF7 is displayed by the display 120b (step A21). As an example, Fig.

3h shows a window 112 which displays information 9a', 62', 64', 66', 78a', 78b', and 82'

(hereinafter also collectively refened to as "information item 47""), and refened to as

"information item 47"") similar to that described above, except that, in this example, the

window 112 also includes TCID information 9b' identifying the party PI of user UI, and the

information 9a' identifies user UI'.

In step A22 it is assumed that the user UI operates the user interface 120a so

as to cause the displayed infomiation item 47" to be selected. In response thereto, an

electronic "ticket" form is retrieved from the server memory 107a, the information from the

"Deals Awaiting Review" folder USF7 is copied therefrom, and the copied information is

inserted into conesponding fields ofthe retrieved form. The fonn, including the inserted

information, is then displayed on the display 120b (and a copy ofthe form and inserted

information is stored in sub-memory 2c-l of worknode 120).

The ticket form is preferably a Microsoft Outlook 2000 (or later versions

thereof) electronic form that has been modified in accordance with this invention to include

various information fields. An example of an electronic ticket form in accordance with a

prefened embodiment of this invention is identified by reference numeral 81 in Fig. 3g. In

the displayed example, the fonn 81 preferably includes a plurality of read-only fields 83-87,

and also includes a plurality of user-editable fields 88-102 into which a user can enter

infoπnation and/or modify information presented in the fields. Field 83 includes the TCID of the counter-party (e.g., counter-party PI for user UI'), field 84 includes information

specifying the type ofthe transaction (e.g., SPOT), field 85 includes information identifying a

date and time at which the ticket form 81 was retrieved from memory 107a, and field 86

includes the information specifying the transaction identification number (defined by, e.g.,

the value of counter variable 170b). Also, field 87 includes the first and/or second cunency

code infoπnation, fields 88 and 96 include infoπnation identifying values (e.g., volumes) of

those respective cunencies, fields 90 and 98 (which are read-only in this example) include

information identifying the payment date for the first and second cunencies, respectively, and

fields 92 and 100 include the payment instructions (e.g., infoπnation specifying a bank and a

bank location) for those respective cunencies. Moreover, field 94 includes information

identifying the value ofthe cunency that is being bought or sold, and field 102 is employed

for including a user message.

In accordance with one embodiment ofthe invention, a directory of pre-stored

information is accessed from server memory 107a in response to the ticket form 81 being

retrieved, and accessed infoπnation conesponding to the respective fields 90 and 92 is

displayed in a pull-down menu in respective ones of those fields, using a known technique.

For example, in one embodiment ofthe invention, default payment dates or date reference

information (e.g., "two business days from the cunent date") are retrieved and displayed in a

pull-down menu in conesponding field 90, and a list identifying predetermined, pre-approved

banks to which payment can be transfened is displayed in a pull-down menu in field 92. A

user UI can then select particular infomiation in the pull-down menus by interacting with the

worknode display 120b using the user interface 120a. If the user UI desires to modify and/or

enter infomiation presented in selected ones ofthe fields 88-102, or fill in information missing from one or more of those fields 88-102, he may do so by operating the user interface

120a in the above-described manner.

The ticket form 81 also includes a plurality of option items 104-108, including

a "confirm" item 104, a "set limit" item 106, and a "log" item 108, each of which may be

selected by a user to invoke a predetermined operation, as will be described below.

Refening again to Fig. 4c, it is assumed that the user UI desires to make a

final confirmation ofthe transaction defined by the information presented on the display

120b. The user UI may finally confirm the transaction by selecting the "confirm" item 104 of

the displayed fonn 81 ('Y' in step A23). In response to the item 104 being selected, the form

script 40 associated with the form 81 stores the transaction infonnation from sub-memory 2c-

1 (representing both the information included in the displayed fomi 81 and the infoπnation

stored in "Deals Awaiting Review' older USF7) in the "Trade Blotter" folder USF5

associated with user UI (step A23-a). The transaction is now considered to be in a finally

confirmed state for UI, and is defined in accordance with that information. At this stage in

the procedure, the terms ofthe transaction cannot be further electronically modified by the

party UI (although user UI' may still modify the terms ofthe transaction if and when he

confinns his own copy ofthe transaction in a ticket form 81).

At some time later, the infomiation defining the confinned transaction may be

accessed from the folder USF5, and be provided to a predetennined destination, such as, for

example, a back office server (not shown), wherein further operations are performed for effecting the confirmed transaction (step A23-b). Thereafter, control passes to block A23-c,

where the method is terminated.

It should be noted that although the invention is described above in the context

ofthe user UI opening the "Deals Awaiting Review" folder USF7 and subsequently

confirming the transaction by selecting the "confirm" item 104 of displayed ticket form 81,

the transaction may also be confirmed by the user UI' in a similar manner as was described

above, except that in step A21 the "Deals Awaiting Review" folder USF7' is opened, in step

A22 the information from that folder is inserted into conesponding fields of retrieved ticket

form 81, and in step A23-a information from the folder USF7' is stored in the "Trade Blotter"

folder USF5' associated with user UI'. Also, in step A23-b the information from that folder

USF5' may be provided to the predetermined destination for effecting the confirmed

transaction. Ideally, both ofthe users UI, UI' confirm the transaction in the above-described

manner (i.e., each user independently finally confirms the transaction). This further ensures

that the transaction will be ultimately effected, especially in a case where proof of both user

confirmations is required to effect the transaction.

As alternatives to selecting the "confirm" item 104 ofthe ticket form 81 when

that form is displayed on the display 120b, 122b ('N' in step A23), a respective user UI, UI'

may select either the "set limit" item 106 or the "log" item 108 ofthe displayed form 81. If,

for example, one ofthe users UI, UI', such as user UI, selects the "set limit" item 106 ('Y' in

step A24), then control passes to block 24-a, where a predetermined contact form (not shown)

is retrieved from the memory 107a and presented on the display 120b. The form preferably is

a Microsoft Outlook 2000 (or later versions thereof) contact form, that has been modified in accordance with this invention to include various custom information fields, such as, for

example, fields for including user-entered information (e.g., fields for including buying and

selling price values of an instrument of interest), fields for including information originated

from a Global Company Directory, and other fields for including market value information

provided (in a "Last" field) by a Quote COM Add-In, and values calculated by a Portfolio

COM Add-In. An "Upper Limit Reminder" field and a "Lower Limit Reminder"field are

also included in the form. Those fields enable the user to set, reset, and cancel limit values

for specified a specified instrument, and be provided with an alert any time a limit value is

exceeded by the specified price. The user can input the limit values either directly into the

fields ofthe fom , or through use of a Limit Minder COM Add-In. A Reminder COM Add-

In monitors the price value included in the "Last" field at predetermined time intervals to

determine if the value has reached one ofthe user-specified limits included in the "Upper

Limit Reminder" and "Lower Limit Reminder'Tields, and responds to determining that one of

those limits has been reached by causing a form (not shown) to be displayed that allows the

user to set new limits, cancel, or ignore the limit reminder. After the user later closes forms,

control passes back to block A23, where the previously displayed screen (displaying form 81)

is again presented on the display 120b, and method then continues in the above-described

manner.

Reference again may be made to the incoφorated co-pending U.S. Patent

Application No. 09/434,794, filed November 5, 1999, entitled "Method, Apparatus And

Program For Delivery And Display Of Infoπnation From Dynamic And Static Data Sources,

by Stephen J. Scimone et al, and to the Computer Program Appendix incoφorated by

reference therein, for a further description ofthe Global Company Directory, Quote COM Add-In, Portfolio COM Add-In, Limit Minder COM Add-In, Reminder COM Add-In, and

the above-described forms (employed in block 24-a).

Another option item that is available for selection by a user while the ticket

form 81 is displayed will now be described. If the user UI does not select the "confirm"item

104 or the "set limit" item 106 in steps A23 and A24, respectively ('N' in steps A23 and

A24), but instead selects the "log" item 108 ('Y' in step A25), then control passes to step

A25-a, where the form script 40 associated with the form 81 responds by causing the "log"

folder USF2 associated with user UI to be opened and the contents thereof displayed on the

display 120b, e.g.,within a window (not shown). Assuming that the user UI thereafter closes

that window, then control passes back to block A23, where the previously displayed screen

(displaying fomi 81) is again presented on the display 120b, and method then continues in the

above-described manner.

(E) PROVIDING A COUNTER PROPOSAL

Having described the various optional items 104-108 that are available for

selection by the users UI, UI' while the ticket form 81 is displayed on the respective displays

120b, 122b, further optional items that are available to the users UI, UI' while the electronic

deal form 50 is displayed on the respective displays 120b, 122b will now be described, with

reference again being made to Figs. 3f, 4b, and 4c. As can be appreciated in view ofthe

foregoing description, in steps AlO (Fig. 4b) and A17 (Fig. 4c), the respective users UI' and

UI may opt to not select the "done" item 70 ofthe electronic deal form 50. For example,

instead of selecting that item 70 in step AlO ('N' in step AlO), the user UI' may opt to provide a counter proposal to the user UI. The user UI' may accomplish this by, for

example, operating the user interface 122a so as to edit the information included in selected

ones ofthe fields 52-66 ofthe form 50, for modifying the terms ofthe transaction as desired,

and by then selecting the "transmit" item 67 ('Y' in step A26, Fig. 4b) ofthe form 50.

Control then passes through connector (C) to step A27 of Fig. 4d, where the form script 40

associated with the form 50 responds by retrieving the information 36 and 38 (conesponding

to that ofthe displayed fonn 50) from the sub-memory 2c- 1 ofthe information appliance 122,

invoking the business object routine, and providing that routine with the retrieved

infoπnation 36 and 38. In accordance with a prefened embodiment ofthe invention, the form

script 40 also responds in step A27 by setting the state of a "most recent post" flag 40c ofthe

form 50 (to indicate that the transaction is in a most recent state).

In response to being invoked in step A27, the business object routine causes

the value ofthe counter variable 107b in memory 107a to be increased by '1', copies that

updated value, and includes the copied value in the infoπnation 36 and 38 provided by the

form script 40 in earlier step A27, to assign a unique identifier to the transaction defined by

the information (step A28). Thereafter, in step A29 the business object routine stores that

information 36, 38, including the value of counter variable 107b, in the "Cunent

Conversations" folder USFl associated with the identifier infomiation (identifying counter¬

party UI) from field 80 of form 50, and in the "Current Conversations" folder USFl'

associated with the user UI' (step A29).

In step A30, the invoked business object routine then retrieves the information

which was stored in the "Incoming Calls" folder SF4' in earlier step A5 (Fig. 4a), and forwards that information to the "Cunent Conversations" folder USFl associated with user

UI, to provide a record ofthe original transaction proposed by the user UI in that folder

USFl. As a result, the original transaction item is removed from the "Incoming Calls" folder

SF4' associated with user UI'.

At some time later, it is assumed that the user UI operates the user interface

120a in the above-described manner to cause the "Cunent Conversations" folder USFl to be

opened and the contents thereof displayed on the display 120b, as shown in, e.g., Fig. 3e (step

A31). Preferably, the information 47' shown in Fig. 3e is highlighted or otherwise visually

distinguished from other displayed information from the folder USFl, in response to the

"most recent post" flag 40c being detected in the folder USFl, after that folder is opened in

step A31.

It is also assumed that the user UI operates the user interfacel20a for selecting

the displayed infoπnation 47' (Fig. 3e) (step A32 of Fig. 4d). As a result, an electronic deal

fonn 50 is retrieved from server memory 107a, and the information 36, 38 which was stored

earlier in step A29 in the "Cunent Conversations" folder USFl is copied and inserted into

conesponding fields ofthe retrieved form 50, in the above-described manner. The retrieved

form 50, including the inserted infomiation 36 and 38, is then displayed on the display 120b

(and stored in sub-memory 2c- 1 of information appliance 120), as shown in, for example,

Fig. 3f (step A33). In this case, the infomiation included in the various fields 52-58, 62-66,

and 78 defines the counter proposal transmitted by the user UI' in earlier step A26 (Fig. 4b). In step 34, the user UI may or may not elect to accept the proposal defined by

the information presented in the displayed deal form 50. If the user UI does not select the

displayed "done" item 70 ('N' in step A34), then control passes through connector (D) to Fig.

4e, where the method proceeds in a manner as will be described below.

Assuming that the user UI does desire to select the transaction proposed by

the user UI', and thus selects the "done" item 70 ofthe displayed deal form 50 in step A34

('Y' in step A34), then the form script 40 associated with that form 50 responds by increasing

the value ofthe "confirm" flag 40a (Fig. 3b) of form 50 by '1' and storing the information 36

and 38 (conesponding to the displayed deal fonn 50) in folder USFl (step A35). Preferably,

the form script also sets a state ofthe "most recent post" flag 40c in the form 50 in step A35,

if that flag was not already set, to indicate that the transaction is in a most recent state.

In response to information 36 and 38 being stored in "Cunent Conversations"

folder USFl, the SES and event handler associated with that folder USFl cause the

information 36 and 38 (including the values of flags 40a and 40c) to be forwarded for storage

in the "Cunent Conversations" folder USFl' associated with the information (identifying

counter-party UI) from field 80 ofthe deal form 50 (step A36). The stored information

represents a transaction that has been "accepted" or initially confirmed by the user UI.

Thereafter, control passes tlirough connector (E) to step A37 of Fig. 4f, where a further step is

performed in a manner as will be described below.

It should be noted that, if desired, the user UI may first enter/modify the

infomiation in one or more selected ones ofthe fields 52-66 ofthe form 50 in step A34 (Fig. 4d) to modify the transaction terms as desired, prior to selecting the "done" item 70 in that

step. In such a case, after the user UI subsequently selects the "done" item 70 in that step,

the steps A35 and A36 are performed in the same manner as was described above, except that

the information stored in the folders USFl, USFl' in steps A35 and A36, respectively,

defines the transaction as modified by the user UI .

Step A37 of Fig. 4f will now be described. In step A37, it is assumed that the

user UP operates the interface 122a to cause the "Cunent Conversations" folder USFl' to be

opened and the contents thereof displayed on the display 122b (step A37). For example, the

information may be displayed in a manner as shown in window 48 of Fig. 3e, and includes a

similar information item 47' as described above, except that in this example the information

9a' identifies the counter-party UI. Preferably, the information item 47' is visually

distinguished from other displayed infoπnation from the folder USFl, based on the "most

recent post" flag 40c being detected in the folder USFl', in the above-described manner.

After the contents of folder USFl' are displayed in step A37, it is assumed that

the user UI' operates the user interfacel22a for selecting the displayed information item 47'

(step A38). As a result, an electronic deal form 50 (previously downloaded from memory

107a in step A9) is retrieved from the memory 2c of infomiation appliance 122, and the

information 36 and 38 stored in the "Cunent Conversations" folder USFl' in earlier step A36

is copied and inserted into conesponding fields ofthe retrieved form 50. The retrieved form

50, including the inserted infoπnation, is then displayed on the display 122b, as shown in, for

example, Fig. 3f (and conesponding infomiation also is stored in sub-memory 2c-l of

information appliance 122 ) (step A39). In step A40 of Fig. 4f, the user UI' may or may not elect to make a secondary

confirmation ofthe transaction defined by the information included in the fields ofthe

displayed form 50. If the user UI' elects to not make such a confirmation, and thus does not

select the "done" item 70 ofthe form 50 in that step ('N' at step A40), then control passes

through connector (D) to step A45 of Fig. 4e, where the method then continues therefrom.

In step A40, the user UI' may make a secondary confirmation ofthe

transaction defined by the information included in the fields ofthe displayed form 50 by

selecting the "done" item 70 ofthe form 50, either after first modifying/entering the

information in selected ones ofthe fields 52-66, or without having first entered/modified that

information. In either case, the fonn script 40 associated with the form 50 responds to the

"done" item 70 being selected in step A40 ('Y' at step A40) by increasing the value ofthe

"confirm" flag 40a (Fig. 3b) ofthe fom 50 by '1' and by invoking a second business object

routine in step A41.

In response to being invoked in step A41, the second business object routine

employs the information 36, 38 (including the form field infoπnation) from sub-memory 2c- 1

to update various summary infoπnation for the user UI' in folders USF3' and USF6' (e.g.,

"Nettings" folder and "Positions", respectively), in a manner as will be described in detail

below. The fonn script 40 then stores the information 36, 38 in the "Cunent Conversations"

folder USFl' associated with the user UI ' (step A42). Thereafter, the SES responds to the

infoπnation being stored in the folder USFl' by invoking the event handler routine

conesponding to that folder USFl'. The invoked event handler then responds by copying the information that was stored in folder USFl' in previous step A42 to the "Cunent

Conversations" USFl associated with user UI (step A43).

In step A44, the SES responds to the information being stored in the folder

USFl in step A43 by invoking the event handler associated with folder USFl. The event

handler then examines the value ofthe "confirm" flag 40a included in that infoπnation to

determine whether or not the value equals '2'. Assuming that the event handler determines

that the value ofthe "confiπn" flag 40a is '2' (indicating that both users UI and UI' have

confirmed the transaction), then the event handler copies the information (representing the

most recent transaction item) which was stored in folder USFl in earlier step A43 to both of

the "Deals Awaiting Review" folders USF7 and USF7' associated with the respective users

UI and UI' (step A44-a). In accordance with one embodiment ofthe invention, the event

handler routine also coπelates the value ofthe counter variable 107b (representing the

transaction identifier), included in the infomiation copied from folder USFl, to information

items (representing the various stages ofthe transaction) having a same associated value

(identifier), stored in the "Cunent Conversations" folders USFl and USFl', and then moves

the conelated infoπnation items from those folders USFl and USFl' to the "Log" folders

USF2 and USF2', respectively, so as to provide an historical record ofthe transaction therein

(step A44-b). Thereafter, control passes tlirough connector (H) back to step A21 of Fig. 4c,

where the method continues in the above-described manner.

Having described an example ofthe various procedures (of Figs. 4d and 4f)

that are perfom ed in response to the user UI' selecting the "transmit" item 67 ofthe

displayed deal fomi 50 in step A26 of Fig. 4b, an example ofthe various procedures that are performed in a case where user UI does not select the "done" item 70 ofthe displayed deal

form 50 in either of steps A17 (Fig. 4c) and A34 (Fig. 4d) will now be described, with

reference being made to Fig. 4e. Step A45 of Fig. 4e is entered in cases in which the user UI

does not elect to select the "done" item 70 in previously described step A17 for confirming

the transaction presented by the deal form 50 displayed in step A16 (Fig. 4b), and also in

cases in which the user UI does not select the "done" item 70 in previously described step

A34 for confirming the counter proposal defined by the information included in the deal fonn

50 displayed in step A33. For example, instead of confirming the transaction by selecting the

"done" item 70 in those steps A17 and A34 ('N' in steps A17 and A34, respectively), the

user UI may opt to provide a counter proposal to the user UI'. The user UI may accomplish

this by editing the information included in selected ones ofthe fields 52-66 ofthe displayed

deal form 50, to modify the tenns ofthe transaction as desired (e.g., changing the price and/or

quantity), and by then selecting the "transmit" item 67 ('Y' in step A45 of Fig. 4e) ofthe

form 50.

The form script 40 associated with the fonn 50 then responds in step A46 by

decreasing the value ofthe associated "confinn" flag 40a by '1', if that value is presently

other than '0', and by storing information 36, 38 (from sub-memory 2c- 1, representing the

displayed infonnation) in "Cunent Conversations" folder USFl. In accordance with a

prefened embodiment ofthe invention, the fonn script 40 also responds in step A46 by

setting the state ofthe "most recent post" flag 40c ofthe fomi 50 to indicate that the

transaction is in a most recent state, if that flag 40c is not already set. In response to information 36, 38 being stored in USFl by form script 40 in

step A46, the SES invokes the event handler associated with folder USFl, which in rum

copies the information (representing the cunent transaction item) to the "Cunent

Conversations" folder USFl' associated with the identifier information (identifying counter¬

party UI') from field 80 of fonn 50 (step A47).

At some time later, it is assumed that the user UI' operates the user interface

122a in the above-described manner to cause the "Cunent Conversations" folder USFl' to be

opened and the contents thereof displayed on the display 122b, as shown in, e.g., Fig. 3e (step

A48). Preferably, the information 47' is visually distinguished from other displayed

information from the folder USFl', based on the set state ofthe "most recent post" flag 40c

being detected in the folder USFl' after the folder is opened, in the above-described manner.

It is also assumed that the user UI' then operates the user interfacel22a for

selecting the displayed infoπnation 47' (Fig. 3e) (step A49). As a result, in step A50 the

electronic deal form 50 (originally downloaded to information appliance 122 from server

memory 107a) is retrieved from the memory 2c ofthe infoπnation appliancel22, and the

information 36 and 38 stored earlier in step A47 in the "Cunent Conversations" folder USFl'

is copied and inserted into conesponding fields ofthe retrieved form 50, in the above-

described manner. The retrieved form 50, including the inserted information 36 and 38, is

then displayed on the display 120b, as shown in, for example, Fig. 3f (step A51). In this case,

the infomiation included in the various fields 52-58, 62-66, and 78 ofthe form 50 defines the

counter proposal transmitted by the user UI in earlier step A45 (Fig. 4e). Thereafter, control passes through connector (G') back to step A31 of Fig. 4d, where the method proceeds in the

above-described manner.

CF) TRANSFERRING A DEAL ITEM TO A PARTY

As was previously described, besides the "done" item 70 and "transmit" item

67, there are other optional items ofthe electronic deal form 50 that are available for selection

by the individual users UI, UI' while viewing the form 50 on the respective displays 120b

and 122b. Those other optional items will now be described. In accordance with one

embodiment ofthe invention, one such optional item is the "transfer" item 74. A user UI,

UI' may elect to select the "transfer" item 74 in a case in which, for example, he desires to

discontinue negotiating the transaction defined by the information included in the form 50,

and also desires to forward information representing an original transaction proposal to the

"Incoming Calls" folder SF4, SF4' associated with a respective party PI, P2, for enabling

another sub-party (e.g., a user U2, U2') associated with that party PI, P2 to subsequently

access and, if desired, further negotiate the transaction. As an example, it is assumed that

rather than selecting the "done" item 70 or the "transmit" item 67 in previous steps AlO and

A26, respectively (e.g., 'N' in steps AlO and A26 of Fig. 4b), the user UI' selects the

"transfer" item 74 ('Y' in step A52 of Fig. 4b) ofthe displayed deal form 50. In response to

the "transfer" item A52 being selected, control passes tlirough connector (I) to step 53 of Fig.

4g, where the form script 40 associated with the fomi 50 responds by incrementing the value

(initially '0') ofthe associated "transfer" flag 40d by '1' and by storing the information 36, 38

in the "Cuπent Conversations" folder USFl' associated with user UI' (step A54). In step A55 the SES detects that the information 36, 38 has been stored in the

folder USFl' in step A54, and responds thereto by invoking the conesponding event handler

routine to act on the information. The invoked event handle routine thereafter copies the

information from the folder USFl' to the "Cunent Conversations" folder USFl associated

with counter-party UI (step A55).

At some time later, it is assumed that the user UI operates the interface 120a

to cause the "Cunent Conversations" folder USFl to be opened and the contents thereof

displayed on the display 120b, as shown in, for example, Fig. 3e. It is also assumed that the

user UI operates the user interfacel20a for selecting the displayed, collective information

item 47' (see, e.g., Fig. 3e) (step A56). As a result, an electronic deal form 50 is again

retrieved from server memory 107a (if not already residing in memory 2c of worknode 120),

and the infomiation 36 and 38 stored previously in step A55 is copied and inserted into

conesponding fields ofthe retrieved form 50, in a similar manner as was described above.

The retrieved fonn 50, including the inserted infomiation 36 and 38, is then displayed on the

display 120b as shown in, e.g., Fig. 3f (step A57). However, in this case the form 50 is

preferably displayed in such a manner that the "transmit", "no deal", and "done" items 67-70,

respectively, are disabled or otherwise non-selectable by a user, as a result ofthe form script

40 recognizing that the value of flag 40d is '1'. Accordingly, in this embodiment the only

displayed option items that are available for selection by the user UI while the form 50 is

displayed in step A57 are the "transfer" and "chat" items 74 and 72, respectively.

Assuming that the user UI selects the "transfer" item 74 ofthe displayed form

50 (step A57a), then the fonn script 40 associated with the fomi 50 responds by further incrementing the value ofthe form's "transfer" flag 40d by '1' (step A58) and by storing the

provided information (i.e., the cunent transaction item represented in the displayed form) in

the "Cunent Conversations" folder USFl associated with user UI (step A58-a).

In step A58-b the SES detects that the information 36, 38 has been stored in

the folder USFl in step A58-a, and responds thereto by invoking the event handler associated

with folder USFl. The event handler responds by examining the value of "transfer" flag 40d

included in the information. Assuming that, after examining that value, the event handler

routine determines that the value is '2', it then copies the information defining the original

transaction proposed by user UI from the Outgoing Calls folder USF4 associated with user

UI, back to the "Incoming Calls" folder SF4' (step A58-c). The invoked event handler routine

also coπelates the value ofthe counter variable 107b (representing the transaction identifier),

included in the copied infomiation, to information items (representing the various stages of

the transaction) having a same associated value (identifier), stored in the "Cunent

Conversations" folders USFl and USFl', and then moves the conelated infoπnation items

from those folders USFl and USFl' to the "Log" folders USF2 and USF2', respectively, so as

to provide an historical record ofthe transaction therein (step A58-d).

Thereafter, a sub-party having access to the "Incoming Calls" folder SF4',

such as, e.g., a user U2', may access and subsequently act on the transaction proposal defined

by the infoπnation stored in folder SF4' in earlier step A58-c, by performing steps similar to

those beginning at step A6 of Fig. 4a described above, except that the sub-party U2', rather

than user UI', perfoπns those steps, and folders (not shown) conesponding to that sub-party

U2' are employed in those steps. As another example, instead of selecting the "done" item 70 or "transmit" item

67 ofthe displayed deal form 50 in steps A17 (Fig. 4c) and A45 (Fig. 4e), respectively (e.g.,

'N' in steps A17 and A45), the user UI may select the "transfer" item 74 ('Y' in step A59,

Fig. 4e). In response to the "transfer" item 74 being selected in step A59, control passes

through connector (I) to back to step A53 of Fig. 4g, where steps are performed in a similar

manner as was described above, except that user UI, rather than user UI', initializes the

transfer procedure in step A53, and folders (not shown) conesponding to the user UI are

employed accordingly.

(G) CANCELING A DEAL

A further optional item ofthe electronic deal form 50 that is available for

selection by a user UI, UI' is the "no deal" item 68. A user UI, UI' may elect to select the

"no deal" item 68 in a case in which, for example, he desires to discontinue the transaction

negotiations and cancel the transaction. As an example, it is assumed that rather than

selecting the "done" item 70, "transmit" item 67, "transfer" item 74, and "chat" item 72 in

steps AlO, A26, A52, and A70, respectively (e.g., 'N' in steps AlO, A26, A52, and A70 of

Fig. 4b), the user UI' selects the "no deal" item 68 ('Y' in step A71of Fig. 4b) ofthe

displayed deal form 50. In response to the "no deal" item 68 being selected, control passes

through connector (K') to step A71-a' of Fig. 4h, where, in the prefened embodiment, the

fonn script 40 associated with the fonn 50 responds by retrieving the information 36, 38

(conesponding to the displayed deal fonn 50), including the "cancel" flag 40b, from the

memory 2c- 1 of user infomiation appliance 122, and by incrementing the value of flag 40b by '1', to indicate that the transaction is in a "canceled" state, although in other embodiments,

other suitable, known techniques for indicating a change in the transaction state may also be

employed. The form script 40 then stores information 36, 38 (including the incremented flag

40b) in the "Cunent Conversations" folder USFl' associated with user UI' (step A71-b').

In step A71-c' the SES detects that the information 36, 38 has been stored in

the folder USFl' in step A71-b', and responds thereto by invoking the conesponding event

handler routine to act on that information. The invoked event handler routine thereafter

responds by copying the infomiation from the folder USFl' to the "Cunent Conversations"

folder USFl associated with user UI (step A71-d').

At some time later, it is assumed that the user UI operates the interface 120a

to cause the "Cunent Conversations" folder USFl to be opened and the contents thereof

displayed on the display 120b, as shown in, for example, Fig. 3e. It is also assumed that the

user UI operates the user interfacel20a for selecting the displayed, collective information

item 47' (see, e.g., Fig. 3e) (step A71-e'). As a result, an electronic deal form 50 is again

retrieved from server memory 107a (if such a form is not already residing in memory 2c of

worknode 120), and the information 36 and 38 stored previously in step A71-d' is copied and

inserted into conesponding fields ofthe retrieved form 50, in a similar manner as was

described above. The retrieved fonn 50, including the inserted information 36 and 38, is then

displayed on the display 120b as shown in, e.g., Fig. 3f (and conesponding infomiation is

stored in sub-memory 2c-l of worknode 120) (step A71-f ). Assuming that the user UI then also selects the "no deal" item 68 ofthe

displayed form 50 ("Y" in step A71-f '), then the form script 40 associated with the form 50

responds by further incrementing the value ofthe "cancel" flag 40b by '1' (step A71-g') and

storing the information 36, 38 (including incremented flag 40b) in the "Cunent

Conversations" folder USFl associated with the user UI (step A71-h'). Otherwise, if "No" in

step A71-f ', then control passes through connector (G') back to Fig. 4d, where the user may

continue transaction negotiations in the manner described above.

In step A71-h' the SES detects that the information 36, 38 has been stored in

the folder USFl in step A71-h', and responds thereto by invoking the event handler routine-

associated with that folder. The invoked event handler responds by examining the value of

"cancel" flag 40b included therein (step A71-i'). Assuming that, upon examining the flag

40b, the event handler routine determines that the value ofthe flag 40b is '2', the routine then

responds by conelating the value ofthe counter variable 107b (representing the transaction

identifier), included in the copied infoπnation, to infoπnation items (representing the various

stages ofthe transaction) having a same associated value (identifier), stored in the "Cunent

Conversations" folders USFl and USFl', and then moves the conelated infoπnation items

from those folders USFl and USFl' to the "Log" folders USF2 and USF2', respectively, so as

to provide an historical record ofthe transaction therein (step A71-J'). Control then passes to

block A71-k' where the method is terminated. It should be noted that the steps shown in Fig.

4h are also performed in a manner similar to that described above in response to the user UI

selecting the "no deal" item 68 ofthe fom 50 in step A61 of Fig. 4e, although, in this

example, the user UI initiates those steps, and those steps are then perfoπned accordingly. ( CONDUCTING AN ELECTRONIC CHAT DURING TRADING NEGOTIATIONS

Referring now to Fig. 4i, a procedure for conducting an electronic chat during

the course of transaction negotiations, in accordance with another aspect of this invention,

will now be described. The procedure enables users to conduct an electronic chat in order to,

for example, propose/negotiate a transaction or otherwise communicate with one another.

The chat procedure may be invoked by the users UI, UP during the course of transaction

negotiations in the following manner. As was previously described, as an alternative to the

"done" item 70 in steps AlO (Fig. 4b) and A17 (Fig. 4c), the "transmit" item 67 in steps A26

(Fig. 4b) and A45 (Fig. 4e), and the "transfer" item 74 in steps A52 (Fig. 4b) and A59 (Fig.

4e), one ofthe optional items that is available for selection by the users UI, UI' while the

electronic deal form 50 is presented on the respective displays 120b, 122b in steps A9 (Fig.

4b) and A35 (Fig. 4d), respectively, is the "chat" item 72 (Fig. 3f). The individual users UI,

UI' can invoke the chat procedure by selecting the "chat" item 72 ofthe displayed electronic

deal form 50 in steps A60 (Fig. 4e) and A70 (Fig. 4b), respectively. Also, in accordance with

a prefened embodiment of this invention, the users UI and UI' can invoke the chat procedure

during the course of any stage of a trade negotiation by selecting a predetermined toolbar

item (not shown) displayed on the respective displays 122a and 122b.

In response to a user, such as user UI, invoking the chat procedure in the

above-described manner (e.g., "Y" in step A60 of Fig. 4e), control passes through connector

(K) to step A26-a' of Fig. 4i, where the Chat COM Add-In lOlf responds by causing a chat

window 101 to be displayed on displayl20b (step A26-a'). An exemplary displayed chat

window 101 is shown in Figs. 6a and 6b, wherem Fig. 6a is an example ofthe manner in which the Chat COM Add-In lOlf operates in conjunction with the chat window 101 and the

Outlook software (identified as 101g') in a user information appliance. The chat window 101

includes information 101b' identifying the other user UI' involved in the transaction being

negotiated, a sub-window 101c' for displaying text of a dialogue conducted during the chat

procedure, and an information field 101d' for enabling the user UI to enter information for

being sent to the other user UI' during the chat procedure.

Assuming that the user UI enters information (e.g., "hello") into the field

101d', and then selects a "send" item 101a' ofthe chat window 101 (step A26-b'), then the

Chat Com Add-In lOlf responds by invoking a predetermined chat protocol 101h'. The

predetermined chat protocol 101h' is a procedure that includes the displaying ofthe user-

entered infoπnation and infoπnation identifying the user UI in the chat window 101 (see,

e.g., reference numeral 101e' of Fig. 6b), the exchanging of various control messages

between the user infomiation appliances 120 and 122 to establish a communication channel

between those infoπnation appliances (step A26-c'), and other steps which will be described

below. The procedure preferably is perfonned in accordance with the Microsoft Coφoration

Chat Protocol, although, in other embodiments, the procedure also may be performed in

accordance with other suitable messaging protocols, such as an instant messaging protocol of

the Microsoft Coφoration.

After the communication channel is established in step A26-c', the

information entered into the field 101d' by the user UI in step A26-b' is communicated to the

infoπnation appliance 122 by way ofthe established communication channel, and is

displayed in the chat window 101 which appears on display 122b (step A26-d'). The user UI' may enter a message into the information field lOld'of that displayed window 101 and select

the "send" option 101a' ofthe window, by operating the user interface 122a, to respond to the

message received from user UI (step A26-e'). For example, the user UI' may enter a

transaction-related message such as one reading "I would like to change last deal...", or some

other desired message, into the field lOld', using the user interface 122a. The worknode 122

responds to receiving the user-entered message by displaying the message in the sub-window

101c' displayed on display 122b, and also responds to the "send" option 101a' being selected

by communicating that message, by way ofthe established communication channel, back to

the worknode 120. The worknode 120 thereafter responds to receiving that message by

displaying the message in the sub-window 101c' ofthe window 101 displayed on display

120b.

The users UI and UI' may then continue to conduct an electronic chat

dialogue in the above-described manner (step A26-f , 'N' in step A26-g') until one of them

elects to discontinue the dialogue by, for example, selecting the 'close' item 101' of window

101 or otherwise disabling the Chat Com Add-In lOlf ('Y' in step A26-g'). In response to

either of those events occuning in step A26-g', the window 101 closes, and control passes

back to, for example, either step AlO or A34 (depending on which portion ofthe procedure

was being performed prior to the user UI invoking the chat procedure) where a previously

displayed window (e.g., deal fonn 50) is again presented on the respective display 120b, 122b

(step A26-h'), and the procedure then continues therefrom. (T) POSITIONS DETERMINATION SUB-EMBODIMENT

In accordance with another aspect of this invention, procedures for calculating,

and subsequently storing, various transaction-related positions information are performed,

after a secondary confirmation of a transaction is made by a user, and for enabling a user to

subsequently access and view that infoπnation. For example, as was previously described,

user UI' may make a secondary confirmation of a transaction by selecting the "done" item 70

ofthe fom 50 in step A40 of Fig. 4f, and user UI may make a secondary confirmation of a

transaction by selecting the "done" item 70 ofthe form 50 in step A17 of Fig. 4c. In either

case, the selection ofthe displayed "done" item 70 ofthe deal form 50 by the respective users

UI, UV ("Y" in steps A17 and A40, respectively) results in the associated form script 40

invoking the second business object routine, and increasing the value ofthe associated

"confiπn" flag 40 by '1' to '2' in subsequent steps Al8-a (Fig. 4c) and A41 (Fig. 4f),

respectively. In accordance with this aspect ofthe invention, and as was previously

described, the invoked second business object routine then determines various positions

summary information. The manner in which the second business object procedure

determines that positions summary information will now be described, with reference to Fig.

5a.

In step A80 of Fig. 5a, the fonn script 40 that increased the value ofthe

"confiπn" flag 40a (in earlier step A18-a or A41) recognizes that the updated value ofthe flag

40a is '2', and thereafter responds by providing the invoked business object routine in server

107' with at least a portion of the infomiation 36, 38 retrieved from the sub-memory 2c-lof

the respective worknode 120,122 in earlier step A18-a (Fig. 4c) or A41 (Fig. 4f), respectively (step A81). Preferably, the information provided by the form script 40 in step A80 includes

(a) the information identifying the respective user UI, UI', (b) information (e.g., TCID)

identifying the party PI, P2 with which the user UI, UI' is associated, (c) the first and second

cunency code infomiation, (d) information specifying the respective amounts those

cunencies (from field 66 of deal form 50), and (e) the information specifying the cunencies

the respective user UI, UI' bought and sold in the transaction.

The business object routine then responds to receiving the information (a)-(e)

from the fonn script 40 in earlier step A80 by coπelating the infoπnation (a) identifying the

respective user UI, UI' to conesponding infoπnation in the "Positions" folder SF2, SF2'

associated with the respective user UI, UI' (step A81), if any such information exists in that

folder SF2, SF2'. An example of a displayed transaction infoπnation item that represents

information in folder SF2, SF2' is represented by a row R2' in Fig. 3j, and will be described

in detail below. The business object routine then perfoπns a predefined algorithm that

employs the infoπnation (c), (d), and (e) and conesponding infoπnation (if any) from the

folder SF2, SF2', to calculate net amounts ofthe respective first and second cunencies that

will either be owed by or owed to the respective user UI, UI', after the transaction is

confirmed in the above-described manner (step A82). The conelated infoπnation stored in

the folder SF2, SF2' is then modified to include the amounts calculated in step A82, or, if no

such information item exists in the folder SF2, SF2', then information representing the

amounts calculated in step A82 are stored in the respective folder SF2, SF2' along with,

according to one embodiment ofthe invention, at least one ofthe information (a) and (c)

described above (step A83). Preferably, the business object routine also performs another calculation that

employs the received information (c), (d), and (e) and information from the folder SF2, SF2'

to calculate cunency totals accounting for all transactions that have been secondarily

confirmed by users associated with the respective party PI, P2 (step A84). A predetermined

transaction information item (from folder SF2, SF2') (see, e.g., row Rn' of Fig. 3j,

representing a displayed version of that item) representing such totals prior to the calculation

being performed in step A84 is then updated (modified) to include the amounts calculated in

earlier step A84 (step A85).

The business object routine also responds to being provided with the

information (a)-(e) from the form script 40 in earlier step A80 by conelating the infoπnation

to existing transaction infomiation items (mail items) from the "Positions" folder USF6,

USF6' associated with the respective user UI, UI', if any such items exist in that folder

USF6, USF6' (step A86). The business object routine then performs a predefined algorithm

that employs the infonnation (c), (d), and (e), and conesponding information from the

conelated transaction infoπnation item(s) (if any) to calculate net amounts ofthe respective

first and second cunencies that will either be owed to or owed by the respective user UI, UI',

after the transaction is confirmed in the above-described manner (step A87). The conelated

information item stored in the folder USF6, USF6' is then modified (updated) to include the

amounts calculated in step A87, or, if no such infomiation item exists in the folder USF6,

USF6', then the amounts calculated in step A87 are stored in the respective folder USF6,

USF6' (step A88). A user associated with the respective party PI, P2, such as user UI, UI', may

subsequently view the contents of individual folder SF2, SF2' by, for example, first entering

information into the user interface 120a, 122a so as to cause a menu 119 to be displayed by

the display 120b, 122b (see, e.g., Fig. 3i), and by thereafter selecting a respective "Positions"

item 117 ofthe displayed menu 119. Assuming that the user UI selects the "Positions" item

117 ofthe displayed menu 119, then the information included in the "Positions" folder SF2 is

copied and inserted into conesponding fields of a window 128, which is then displayed on

the display 120b as shown in, for example, Fig. 3j (step A89).

According to a prefened embodiment ofthe invention, the window 128

includes a plurality of rows of infoπnation fields Rl'-Rn', as shown in Fig. 3j, wherein each

row R2' to Rn-l' (Rn-l' is not shown) represents a transaction information item conesponding

to a respective user associated with the party PI, P2. Each ofthe information fields of row

Rl' is employed for including information (denoted generally by reference numeral 125')

specifying a respective predetennined cunency code (e.g., "USD", "EUR", etc.), and each of

the remaining infomiation fields of each individual row R2' to Rn-l' is employed for

including infomiation (denoted generally by reference numeral 126') specifying a

conesponding amount either owed by or owed to the conesponding. For example, the row

conesponding to user UI (e.g., row R2'), includes the amounts either owed to or owed by the

user UI, calculated in previous step A82. Moreover, information (denoted generally by

reference numeral 127') represents the net amounts, calculated in step A87, owed by or owed

to the collective users associated with the respective party PI, P2 (i.e., the information 127'

represents a sum total ofthe amounts included in conesponding ones ofthe information

fields of rows R2' to Rn-l', although no such amounts are shown). If, in step A89, the user UI opens the "Positions" folder USF6, rather than

"Positions" folder SF2, then the information from the "Positions" folder USF6 is presented

on the display 120b in a similar manner as shown in Fig. 3j, except that in this case, only

rows Rl' and R2' are displayed (rows R3' to Rn' are not displayed), and row Rl' includes the

cunency amounts either owed to or owed by the user UI, calculated in previous step A87.

Preferably, positions information also is updated in the various "Positions"

folders in response to a user selecting "confirm" item 104 (see, e.g., step A23-a of Fig. 4c)of

the ticket form 81, after having first modified the information included in at least one selected

field (e.g., field 94) ofthe form 81. For example, in such a case, the form script 40 responds

to the selection ofthe item 104 by providing the second business object routine stored in the

memory 107a with at least a portion of information 36, 38 (including the user-modified

information) retrieved from sub-memory 2c- 1 ofthe information appliance in which the

infonnation was modified. Preferably, for example, the infoπnation provided by the form

script 40 in step A23-a' includes the information the information (a), (b), (c), (d), and (e)

described above. Thereafter, the business object routine then responds by performing similar

procedures as were described above (e.g., beginning from step A81) to update the information

in the various "Positions" folders in the above-described manner.

( T) NETTINGS DETERMINATION SUB-EMBODIMENT

A further aspect of this invention will now be described. In accordance with

this aspect of this invention, procedures for calculating, and subsequently storing, various

transaction-related nettings infoπnation are perfonned, after a final confirmation of a transaction is made by a user, for enabling a user to subsequently access and view that

information. For example, as was previously described, a user UI, UI may finally confirm a

transaction by selecting the "confirm" item 104 in step A23 of Fig. 4. Thereafter, the form

script 40 responds by causing the transaction information from sub-memory 2c- 1

(representing both the information included in the displayed form 81 and the information

stored in "Deals Awaiting Review"folder USF7) to be stored in the "Trade Blotter" folder

USF5 associated with user UI (step A23-a). In accordance with this aspect ofthe invention,

and refening now to Fig. 5b, in addition to that procedure, the form script 40 also responds

by invoking the operation of a (second) business object routine stored in the memory 107a,

and also by providing that invoked routine with at least a portion of the information 36, 38

retrieved from memory 2c-l (step A23-a' of Fig. 5b). Preferably, the information provided

by the form script 40 in step A23-a' includes (i) the infonnation identifying the respective

user UI, UI', (ii) the infomiation (TCID) identifying the respective party PI, P2 with which

the user UI, UI' is associated, (iii) infomiation (e.g., the TCID) identifying the party PI, P2

with which the counter-party (UI, UI') is associated, (iv) the first and/or second cunency

code infoπnation, (v) infonnation specifying the respective amounts of those cunencies, and

(vi) the infonnation specifying the cunencies the respective user UI, UI' is buying and

selling in the transaction.

The business object routine then responds to receiving the information (i)-(vi)

by conelating the infonnation (i) to conesponding infonnation in the "Nettings" folder SFl,

SFl' associated with the respective user UI, UI¹, if any such information exists in that folder

SFl, SFl'. An example of a displayed version of a transaction infonnation item representing

infoπnation stored in folder SFl, SFl' is represented by a row R2 in Fig. 3i, and will be described in further detail below. The business object routine also responds to receiving the

information (i)-(vi) by conelating the information (iii) to conesponding infoπnation from the

"Nettings" folder USF3, USF3' associated with the respective user UI, UI', if any such

information exists in that folder USF3, USF3', (step A23-b' of Fig. 5b). The business object

routine then performs a predefined algorithm that employs the information (iv), (v), and (vi)

and conesponding infoπnation (if any) from folder SFl, SFl', to calculate net amounts ofthe

respective first and second cunencies that are either owed by the user UI, UI' to the counter¬

party UI', UI, or owed to the user UI, UI' by that counter-party, now that the transaction has

been finally confirmed in the above-described manner (step A23-c'). The conelated

infonnation item stored in the folder SFl, SFl' is then modified to include the amounts

calculated in step A23-c', or, if no such information item exists in that folder, then

information representing the amounts calculated in step A23-c' is stored in the respective

folder SFl, SFl' along with, according to one embodiment ofthe invention, at least one ofthe

information (iii), (iv), and (v) described above (step A23-d').

The business object routine also perfonns another calculation that employs the

infomiation (iv), (v), and (vi) and infomiation from the respective folder SFl, SFl' to

calculate cunency totals accounting for all transactions (with any counter-party) that have

been finally confirmed by users associated with the respective party PI, P2, including the one

confirmed in earlier step A23 (step A23-e'). Predetermined information item from folder

SFl, SFl' (see, e.g., row Rn of Fig. 3i, representing a displayed version of that information),

representing such totals prior to the calculation being perfonned in step A23-e', is then

updated (modified) to include the amounts calculated in the step A23-e'(step A23-f ). The business object routine also performs similar calculations as were

described above, using the information (iv), (v), and (vi) and information from the respective

"Nettings" folder USF3, USF3' (rather than information from folder USFl, USFl') to

calculate net amounts ofthe respective first and second cunencies that are now either owed to

the user UI, UI' by the counter-party PI, P2, or owed by the user UI, UI' to that counter¬

party (step A23-g'). The business object routine also uses the same information to calculate

cunency totals accounting for all transactions (with any counter-party) that have been finally

confirmed by the user UI, UI', including the one finally confirmed in earlier step A23 (step

A23-h'). Conesponding infoπnation stored in the folder USF3, USF3' is then modified to

include the amounts calculated in the respective steps A23-g' and A23-h', or, if no such

information exists in those folders, then infoπnation representing the amounts calculated in

respective steps A23-g' and A23-h' is stored in the folder USF3, USF3', along with,

according to one embodiment ofthe invention, at least one ofthe information (iii), (iv), and

(v) described above (step A23-i').

A user associated with the party PI, P2, such as user UI, may subsequently

view the contents of individual folder SFl, SFl' by, for example, first entering infoπnation

into the user interface 120a, 122a to cause a menu 119 to be displayed by the display 120b

(see, e.g., Fig. 3i), and by thereafter selecting a respective "Nettings" item 118 ofthe

displayed menu 119. Assuming that the user UI selects the "Nettings" item 118 ofthe

displayed menu 119, then the infomiation included in the "Nettings" folder SFl is presented

in conesponding fields of a window 124, which is displayed on the display 120b as shown in,

for example, Fig. 3i (step A23-j'). According to a prefened embodiment ofthe invention, the window 124

includes a plurality of rows of information fields Rl-Rn, as shown in Fig. 3i, wherein each

row represents a transaction information item conesponding to a particular counter-party with

whom the user UI, UI' engaged in a transaction, and who is associated with a different party

than the one (PI, P2) with which the user UI, UI' is associated. A first information field Cl-

1 of row Rl includes information such as, e.g., "Counteφarty TCID", and a first information

field C2-1 of each row R2 to Rn-l (row Rn-l is not shown) includes information identifying

a respective one ofthe counter-parties. Each ofthe remaining information fields of row Rl is

employed for including infomiation (denoted generally by reference numeral 125) specifying

a respective predetermined cunency code (e.g., "USD", "EUR", etc.), and each ofthe

remaining information fields of each row R2 to Rn-l is employed for including information

(denoted generally by reference numeral 126) specifying a conesponding cunency amount.

For example, one of those rows R2 to Rn-l includes information representing the cunency

amounts calculated in previous step A23-c'. Moreover, information (denoted generally by

reference numeral 127) representing the net amounts either owed by the collective users of

the respective party PI, P2 to all counter-parties, or owed by all of those counter-parties to the

users ofthe respective party PI, P2 (calculated in step A23-e'), is included in conesponding

fields of row Rn.

In accordance with another aspect of this invention, a user who is viewing the

display shown in Fig. 3i can invoke the display of further infoπnation representing nettings of

only a particular counter-party, broken down on a user (within party PI, P2) basis. For

example, assuming that user UI, UI' selects one ofthe displayed transaction information

items (rows) R2 to Rn-l described above (relating to a particular counter-party), then one or more associated transaction information sub-items (not shown) are displayed on the display

120a, 122a, depending on the number of users (ofthe respective party PI, P2) with whom the

counter-party engaged in finally confirmed transactions. Each ofthe displayed transaction

information sub-items conesponds to a particular user (e.g., UI, UI') who engaged in one or

more finally confirmed transactions with the counter-party, and includes information

representing net cunency amounts either owed by the counter-party to the user associated

with party PI, P2, or owed by that user to the counter-party, as a result of those finally

confirmed transactions.

A case in which a user UI, UI' opens a conesponding "Nettings" folder USF3,

USF3' will now be described. If the user U1.U1¹ opens the "Nettings" folder USF3,USF3* in

step A23-j, rather than the respective "Nettings" folder SFl, SFl', then the information from

the "Netting" folder USF3, USF3' is presented on the respective display 120b, 122b in a

similar manner as shown in Fig. 3i, except that, in this case, only those transaction

information items (i.e., rows) relating to transactions in which the user UI, UI' was a party

are displayed, on a counter-party basis (not shown). Also in this case, one ofthe displayed

transaction infonnation items relates to the transaction finally confirmed in step A23, and

includes the cunency amounts (now either owed by the user UI, UI' to the counter-party UI',

UI, or owed to the user UI, UI' by that counter-party) calculated in step A23-g', and row Rn

includes the information calculated in step A23-h'.

In accordance with one embodiment of this invention, nettings information

also may be updated in the various "Nettings" folders in response to a user selecting "done"

item 70 (see, e.g., step A40 of Fig. 4f or step A17 of Fig. 4c) ofthe deal form 50, after having first modified the information included in at least one selected field ofthe form 50. For

example, in such a case, the form script 40 responds to the selection ofthe item 70 by

providing the second business object routine stored in the memory 107a with at least a

portion of information 36, 38 (including the user-modified information) retrieved from sub-

memory 2c- 1 ofthe information appliance in which the information was modified.

Preferably, for example, that infoπnation provided by the form script 40 includes the

infoπnation the infoπnation (i), (iii), (iv), (v), and (vi) described above. Thereafter, the

business object routine then responds by performing similar procedures as were described

above (e.g., beginning from step A23-a') to update the information in the various "Nettings"

folders in the above-described manner.

It should be noted that the above-described algorithms/calculations may be

perfonned in any suitable manner known in the art, and that one skilled in the art would

readily appreciate, in view of this description, how to foπnulate such algorithms for enabling

the various positions and nettings summary infoπnation described above to be obtained.

Also, in accordance with a prefened embodiment of this invention, a teclinique may be

employed in the server 107 to protect against potential conflicts that may arise as a result of

more than a single user from a particular party Pl-Pn simultaneously invoking the business

object routine by a confiπning transaction. An example of one such technique that may be

employed is provided by a Win32 synchronization object. ID DEAL CAPTURE EMBODIMENT

Another aspect ofthe invention will now be described. In accordance with

this aspect ofthe invention, users may employ the communication system 200' of this

invention to electronically "capture" a pre-negotiated transaction of interest. For example,

assuming that the users UI and UI' have externally negotiated and agreed to conduct a

particular transaction (through, e.g., a personal or telephone conversation, electronic chat, or

some other fom of communication), then either one ofthe users UI and UI', or both users

independently of one another, may subsequently employ the communication system 200' to

define that transaction electronically, and to finally confirm the transaction, for enabling the

electronically defined transaction to be subsequently provided to the back office for eventual

handling therein. In greater detail, and refening to Fig. 5 c, after externally negotiating a

transaction with, for example, user UI' (step Al 00), the user UI may operate the user

interface 120a to cause an electronic "deal capture" fonn to be retrieved from the memory

107a and displayed on the display 120b (and, thus, to also be stored in sub-memory 2c- 1 of

worknode 120) (step AlOl). For example, the user UI may cause the deal capture form to be

displayed in step AlOl by selecting a predetennined option item (not shown) displayed on a

particular HTML page (not shown), or by opening a predetermined folder (not shown) and

then selecting a displayed "New" option item (not shown).

The deal capture form is preferably a Microsoft Outlook 2000 (or later

versions thereof) electronic fom that has been modified in accordance with this invention to

include various fields. An example of a deal capture fonn in accordance with a prefened embodiment ofthe invention is depicted in Fig. 3c, and is identified by reference numeral 250.

In accordance with a prefened embodiment of this invention, the deal capture

form 250 includes various read-only fields, such as a field 214, which includes information

identifying the date and time at which the form 250 is retrieved, and a field 215, which

includes information uniquely identifying the transaction (e.g., as determined by increasing

counter variable 107b in response to "confirm" item 212 (described below) being selected).

The information included in fields 214 and 215 is collectively represented by the form code

infoπnation 36 of Fig. 3b described above, and may be populated in those respective fields in

the manner described above.

The deal capture form 250 preferably also includes various user-editable fields

200-211 into which a user can enter transaction-related information and/or modify existing

transaction-related information appearing in the fields (such information is collectively

represented by the fom data 38 of Fig. 3b). For example, field 200 is employed for enabling

a user to specify an identifier 200a ofthe counter-party (e.g., UI, UI') involved in the

transaction, field 202 is employed for enabling a user to specify a code (e.g., USD, BEF,

CAD, DEM, GBP, etc.) of a cunency which the counter-party (e.g., user UI') may have

agreed to buy or sell, and field 201 is employed for enabling the user to specify a code (e.g.,

USD, BEF, CAD, DEM, GBP, etc.) ofthe cunency which he (e.g., user UI) may have agreed

to buy or sell. Also, field 203 is employed for enabling the user to specify the amount ofthe

cunency code (entered into field 201) agreed to be bought or sold by the counter-party, field

204 is employed for enabling the user to specify the rate of exchange of cunency in field 201

relative to the cunency in 202 he has agreed to buy or sell, and field 209 enables the user to enter a textual message he desires to be associated with the transaction information included

in the other fields ofthe form 250.

The fields 210 and 211 of form 250 are employed for enabling a user UI, UI'

to specify the type ofthe transaction (i.e., "buy" or "sell"), fields 206 and 207 are employed

for enabling a user to specify payment date instmctions (e.g., a date or date reference such as

"two business from present date") for the cunencies entered into fields 201 and 202,

respectively (i.e., the information in field 206 represents the payment date for user UI and the

information included in field 207 represents the payment date for counteφarty UI'), and

fields 205 and 208 are employed for enabling a user to specify payment instmctions (e.g.,

information specifying a bank and a bank location) for the user and counter-party,

respectively.

In one embodiment ofthe invention, a directory of pre-stored information is

accessed in response to the deal capture form 250 being retrieved from the memory 107a in

step AlOl, and information conesponding to one or more ofthe respective fields 200-211 is

retrieved and displayed in a pull-down menu in respective ones of those fields, in the above-

described manner. The user UI, UI' can then select particular, displayed infoπnation by

interacting with the worknode display 120b, 122b, using the user interface 120a, 122a,^'

respectively, in the above-described manner.

The deal capture fonn 250 also preferably includes a plurality of option items,

including a "confiπn" item 212 and a "cancel" item 213, each of which may be selected by a

user to invoke a predetennined operation, as will be described below. Refening again to Fig. 5b, in step A102 it is assumed that user UI enters an identifier conesponding to counter-party

UV into the field 200 of form 250, and also enters appropriate transaction-related information

into the fields 201-21 lof that form 250, in the manner described above. Thereafter, the user

UI may specify that a transaction defined in accordance with the entered information be

finally confirmed by selecting the "confirm" item 212 ofthe displayed form 250 ("Y" in step

A103). In response to the item 212 being selected, a form script 40 associated with the form

250 calls the business object routine operating in server 107. The business object routine

then responds by storing the information provided by the form script 40 in the "Trade

Blotter" folder USF5 (step A 104). The transaction is now considered to be in a confirmed

state, and is defined in accordance with that infonnation. At this stage in the procedure, the

terms ofthe transaction cannot be further modified by the parties UI and UI'. At some time

later, the information defining the confirmed transaction may be accessed from the folder

USF5, and be provided in the above-described manner to a predetermined destination, such

as, for example, a back office server, wherein further operations may be performed for

effecting the confiπned transaction (step A105), although this step is not necessarily germane

to this invention. Thereafter, control passes to block A106 where the method terminates.

Refening again to step A103, if, after retrieving the form 250, the user UI

changes his mind and decides not to confim the pre-negotiated transaction in the above-

described manner ("N" in step A103), then he may select the "cancel" item 213 ofthe form

250 (step A103'). The fonn script 40 associated with the fonn 250 then responds to the item

213 being selected in step A103' by closing the form 250 (step A103"). Thereafter, control

passes to block A106 where the method is terminated. IIP ELECTRONIC BULLETIN BOARD TRADING EMBODIMENTS < '

( ) FIRM MATCHING SUB-EMBODIMENT

A further aspect of this invention will now be described. In accordance with

this aspect ofthe invention, one or more users ofthe communication system 200' can post a

transaction proposal (also refened to as an "order") on an electronic "bulletin board"

(namely, public "Order Book" Folder 502), for enabling other users ofthe system 200' to

access, review, and possibly conduct an electronic transaction based on the proposal. A

method in accordance with this aspect ofthe invention will now be described, with reference

to the flow diagrams shown in Figs. 7a-7c. At step Al' the method is started, and it is

assumed that a user, such as, for example, user UI, desires to post a transaction proposal

relating to an electrical power trading market in an electronic "bulletin board". The user UI

may accomplish this by operating the user interface 120a to interact with the display 120b so

as to cause an "order entry" electronic contact fonn relating to an electrical power trading

market to be retrieved from server memory 107a and displayed on display 120b (step A2').

The order entry electronic contact form is preferably a Microsoft Outlook 2000 (or later

versions thereof) electronic form that has been modified in accordance with this invention to

include various fields. An example ofthe displayed order entry electronic contact form

according to a prefened embodiment ofthe invention, is shown in Fig. 3k, and is identified

by reference numeral 130.

In this exemplary embodiment, the fonn 130 of Fig. 3k preferably includes at

least one read-only field 314 that includes infomiation identifying the date and time at which the form 130 was retrieved in step A2' (read-only portions ofthe form 130 are represented by

the information 36 shown in Fig. 3b), and a plurality of user-editable fields 301-313 into

which a user can enter transaction-related information and/or modify existing transaction-

related information appearing in the fields (the information in fields 301-313 is collectively

represented by the form data 38 of Fig. 3b). Field 301 is employed for enabling a user to

specify a power-grid delivery point, fields 305, 306, and 307 are employed for enabling a user

to specify a month, day, and year, respectively, that collectively represent a desired power

delivery start date, and fields 309 and 310 are employed for enabling a user to specify desired

starting and ending times, respectively, for the power delivery. The information included in

the fields 301 and 305-310 collectively defines an electrical power trading market

"instrument" which the user UI desires to buy and/or sell. Field 302 of form 130 is

employed for enabling a user to specify a desired quantity of electrical power (e.g., megawatt-

hours (MWHs)), field 311 is employed for enabling the user to specify if he desires the

transaction proposal to remain posted in the "bulletin board" until he cancels the proposal,

field 312 is employed for enabling the user to specify either a time period for which the user

desires the proposal to be posted on the electronic "bulletin board" or a time at which the user

desires the transaction proposal to be removed from the electronic "bulletin board", and fields

303 and 304 are employed for enabling a user to specify respective prices at which he desires

to buy or sell, respectively, the instrument defined by the information included in fields 301

and 305-310. The user may enter infoπnation into one or both of those fields 303 and 304,

depending on the type of transaction he desires. Moreover, field 308 is employed for

enabling the user to specify whether or not the transaction is to be a "spot" transaction, and

field 313 is employed for enabling the user to specify a message he desires to be posted in the

electronic "bulletin board" along with the transaction information. In accordance with one embodiment ofthe invention, in response to the form

130 being retrieved in step A2', a directory of pre-stored information conesponding to one or

more ofthe fields 301, 305-310, and 312 is accessed, and the conesponding information is

retrieved and displayed in a pull-down menu in conesponding ones of those fields, using a

known technique. A user UI, UI' can then select particular, displayed information appearing

in each pull-down menu by interacting with the worknode display 120b, 122b, using the

respective user interface 120a, 122a, in the above-described manner.

The form 130 also preferably includes a plurality of option items, including a

"post" item 315 and a "cancel" item 316, each of which may be selected by a user to invoke a

predetermined operation. For example, the selection ofthe "cancel" item 316 causes the form

130 to close in the manner described above. The procedures that are invoked in response to

the "post" item 315 being selected will be described in detail below.

Refening again to Fig. 7a, step A3' will now be described. In step A3' it is

assumed that user UI enters desired, electrical power-related transaction information into

selected ones ofthe information fields 301-313 ofthe displayed form 130, to thereby define a

transaction proposal, and thereafter selects the "post" item 315 ofthe form 130 for "posting"

the order in the electronic "bulleting board". The form script 40 (Fig. 3b) associated with the

electronic fomi 130 responds to the item 315 being selected in previous step A3' by causing

the infoπnation entered into the fields to be forwarded from the worknode 120 to the memory

107a, tlirough the network components L3, L2, 190, and 107', and to be stored in the

"Outgoing Calls" folder USF4 associated with the user UI (step A4'). Thereafter, the SES detects that the information has been stored in folder

USF4 in step A4', and responds thereto by invoking the conesponding event handler routine

in memory 107a to act on that information. In response to being invoked by the SES, the

event handler routine copies that information from folder USF4, and causes the copied

information to be forwarded to a SQL stored procedure in server 106'(step A5'). The SQL

stored procedure then invokes a predetermined routine (e.g., a known routine for generating a

GUID) in the server 106' to generate a unique identifier for the proposed transaction, and then

includes that unique identifier in the information received from the event handler routine, to

assign the unique identifier to the transaction proposal. The SQL stored procedure then stores

the infonnation, including the unique identifier, in the "Order Book" table 500 in server

memory 106a (step A6').

In accordance with one embodiment of this invention, step A6' also includes a

preliminary sub-step which is perfonned to compare the information to orders already

existing in the'Order Book" table 500 to determine whether or not that information matches

any of those orders, and then subsequent sub-steps are perfom ed based on the results of that

determination. All of these sub-steps are preferably perfomied in accordance with the

procedures-described below in the sub-section entitled "Automatic Matching Sub-

Embodiment", and thus will not now be described in detail.

Refening again to Fig. 7a, in step A7' the SQL stored procedure then signals

the database synchronizer program to indicate that the table 500 has been updated, and the

database synchronizer program then responds by copying (i.e., reproducing) the information included in the table 500 to the server 107' (through link LI'), wherein a business object

routine then stores that information in the "Order Book" folder 502 in memory 107a (see,

e.g., Fig. 31). In this manner, the information defining the transaction (order) proposed by the

user UI in earlier step A3', is "posted" (i.e., the order is "posted") in the "Order Book" folder

502, for subsequent consideration by other users ofthe communication system 200" who may

open that folder 502.

The transaction proposal remains "posted" (i.e., stored) in the "Order Book"

folder 502 until either a controller (not shown) within the server recognizes that the time kept

by the internal clock (not shown) within server 107' has reached the cancel time (or the end of

a cancel time period) specified by the infonnation included in field 312 ofthe fonn 130 (in

the case where field 311 was not 'selected'), or the user UI cancels the proposal (in the case

where the field 311 ofthe "posted" order entry fonn 130 was 'selected'). For example, the

user UI may cancel the order by first interacting with worknode 120 through interface 120a

to open the "Order Book" folder 502, and by then selecting a displayed infonnation item

representing his "posted" order in the folder 502. Thereafter, an electronic "order book" form

130' (Fig. 3n) is retrieved from memory 107a, information relating to the selected transaction

information item is copied from folder 502 and inserted into conesponding fields ofthe

retrieved fom , and then the fonn, including the inserted information, is displayed on the

display 120b, as shown in, e.g., Fig. 3n. As can be seen in Fig. 3n, the fonn 130' includes

information fields 301"- 312" and 314", which conespond to fields 301-312 and 312,

respectively, of order fonn 130 in Fig. 3k. The user UI may specify that the posted order be

canceled by selecting the "delete" item 316" ofthe fonn 130', in which case the fonn script

40 associated with the fonn 130' responds by removing the order from folder 502. The SES thereafter responds to the order being removed from folder 502 by invoking a conesponding

event handler routine, which then operates in conjunction with a SQL stored procedure in

server 106' to cause the order to be removed from the table 500 in server memory 106a.

Referring again to Fig. 7a, it is assumed that the user UI has not yet canceled

the order in the "Order Book" table 500 and folder 502, and that at some time after the

performance of step A7', another sub-party, such as user UV, interacts with worknode 122

through interface 122a to cause the "Order Book" folder 502 to be opened, and the contents

thereof displayed on the display 122b (step A8"). Thereafter, in step A9' (Fig. 7b) it is

assumed that the user UI' operates the user interface 122a so as to cause a displayed

transaction information item to be selected. In response thereto, another type of electronic

"order book" form is retrieved from memory 107a, information relating to the selected

transaction information item is copied from folder 502 and inserted into conesponding fields

ofthe retrieved form, and then the fonn, including the inserted information, is displayed on

the display 122b (and conesponding information is stored in sub-memory 2c-l of worknode

122) (step A10').

The displayed electronic order book form is preferably a Microsoft Outlook

2000 (or later versions thereof) electronic fonn that has been modified in accordance with this

invention to include various fields. An example of a prefened order book form for use in an

electrical power trading market is depicted in Fig. 3m, and is identified by reference numeral

700. In accordance with a prefened embodiment of this invention, the order book

form 700 includes fields 301', 302', 304', 305'-310*, and 313' that include the same

information as was included in the respective fields 301, 302, 304, 305-310, and 313 ofthe

"order entry" form 130 of Fig. 3k, except that, in the form 700, the only field that is user-

editable is field 302' (i.e., the form script 40 rendered the order for negotiation or acceptance).

The form 700 also includes a read-only field 314' that includes infoπnation identifying the

date and time at which the fo m 700 was retrieved in step A10'.

The displayed order book form 700 also includes a number of optional items

that are available for selection by a user, including "transmit" item 67, "no deal" item 68,

"done" item 70, and "chat" item 72, which cause various procedures to be performed in

response to being selected, as will be described below.

The user UI' may accept the transaction proposal defined by the information

included in fields ofthe displayed fonn 700 by selecting the "done" item 70 ofthe fonn 700

('Y' at step Al l' in Fig. 7b). If the user UI' selects the "done" item 70 without first

modifying the infonnation in any ofthe fields, then there is considered to be a firm match of

the transaction proposal. The steps which are performed in response to the "done" item 70

being selected in that case will now be described.

If the "done" item 70 is selected in step Al 1', then control passes through

connector (B') to step Al 1-a' of Fig. 7c, where a form script 40 associated with the order

book fonn 700 responds by retrieving the infoπnation (conesponding to the displayed fonn

700) from the sub-memory 2c-l of worknode 122, setting information in the form 700 to indicate that the transaction is now "complete", and by then storing the retrieved information

in the "Order Book" folder 502 in server memory 107a. Thereafter, in step Al 1-b' the SES

responds to the infoπnation being stored in the folder 502 in previous step Al 1-a' by

invoking the conesponding event handler routine, which, in turn, copies that information,

invokes a SQL stored procedure (e.g., "TakeOrder stored procedure") in server 106', and

provides that procedure with the copied information. In response to being invoked, the SQL

stored procedure removes the infonnation defining the original transaction proposal stored

earlier in step A6' from the "Order Book" table 500, and then stores that removed information

and the information received from the event handler routine in previous step Al 1-b', in the

"Deals Done" table 504 within memory 106a (step Al 1-c'). In this manner, two new entries

are made in the table 504, one of which represents the original transaction proposal posted by

user UI in earlier step A3', and the other of which represents the transaction accepted by user

UI' in earlier step Al l'.

In step Al 1-d', SQL stored procedures respond to the information in the tables

500 and 504 being updated in step Al 1-c' by signaling the database synchronizer program

(e.g., NT service) conesponding to table 504. The database synchronizer program then

responds by copying (i.e., reproducing) the information from the "Order Book" table 500 and

the "Deals Done" table 504 within memory 106a to the "Order Book" folder 502 and "Deals

Done" folder 506, respectively, within memory 107a, to thereby update and synchronize the

information included in folders 502 and 506 in accordance with that stored in the tables 500

and 504, respectively. In step Al 1-e' the SES responds to the information being stored in the folder

506 in previous step Al 1-d' by invoking the conesponding event handler routine, which, in

turn, retrieves the information relating to the original and accepted transaction proposals from

folder 506, and causes a business object routine to store the retrieved information in both of

the "Log" folders USF2 and USF2' associated with the respective users UI and UI'. In this

manner, an historical record ofthe originally-posted transaction proposal and the accepted

transaction proposal is provided in the "Log" folders USF2 and USF2', for subsequent

viewing by the respective users UI and UI'. The invoked event handler routine also invokes

a messaging service employed in the server 107 to cause that service to generate and send an

electronic message to one or more predetermined folders/mailboxes associated with

respective ones ofthe users UI and UI' (based on user identifiers extracted from the retrieved

information), for notifying those users UI and UI' that the transaction has been finally

confirmed (step Al 1-f ). Preferably, the messaging service forwards the message to one or

both of an Exchange mailbox (not shown) and an "Inbox" folder (not shown) associated with

each individual user UI and UI', although in other embodiments, the message may also be

forwarded to other predetermined folders and/or mailboxes or other storage areas associated

with each user UI, UI', such as an "Electricity Deals" folder (not shown). Also, in

accordance with another embodiment of this invention, in step Al 1-f the event handler

routine provides the messaging service with the infoπnation (i.e., a copy of fonn 700)

representing the accepted transaction proposal, retrieved from the folder 506 in earlier step

Al 1-e', and the messaging service thereafter forwards that information to the predetermined

user folder/mailbox in step Al 1-f, for notifying the users UI, UI' ofthe finally confirmed

transaction. At some later time, the information defining the accepted transaction proposal

may be accessed from one of those folders (e.g., "Electricity Deals" folder), and be provided

to a predetermined destination, such as, for example, a back office server, wherein further

operations may be performed for effecting the confirmed transaction (step Al 1-g').

Thereafter, control passes to step Al 1-h' where the method is terminated.

It should be noted that while this invention is described in the context ofthe

messaging service providing an electronic message to only the users UI and UI' for notifying

them ofthe confirmed transaction, it also is within the scope of this invention to provide the

message to one or more other users ofthe communication system 200", or, the message may

be provided to only a single one ofthe users UI of UI' who engaged in the transaction.

Moreover, while this description is described in the context ofthe transaction information

being stored in the "Log" folders USF2 and USF2' in response to the same information being

stored in the "Deals Done" folder 506, in other embodiments ofthe invention, the

information may be stored in the "Log" folders USF2, USF2' folders during other steps ofthe

procedure. For example, in one embodiment ofthe invention, in addition to invoking the

SQL stored procedure in step Al 1-c', the event handler routine also may invoke a business

object routine in server 107', and provide that routine with the information stored in the

"Order Book" folder 502 in earlier steps A7' and Al 1-a'. In this case, the business object

routine then responds by storing the provided infonnation in the "Log" folders USF2 and

USF2' to provide an historical record ofthe transaction therein. (E) SOFT-MATCHING SUB-EMBODIMENT

Referring again to Fig. 7b, in step Al 1' the user UI' may opt to not select the

"done" item 70 ofthe "Order Book" form 700. For example, instead of selecting that item 70

in step Al 1' ('N' in step Al 1'), the user UI' may opt to provide a counter proposal to the user

UI. The user UI' may accomplish this by editing the information included in the field 302' of

the form 700 to modify the quantity term ofthe transaction as desired, and by then selecting

the "transmit" item 67 ('Y' in step A12', Fig.7b) ofthe form 50. In response to the "transmit"

item 67 being selected, control passes through connector (C) to step A12-a' of Fig. 7d, where

a form script 40 associated with the form 700 responds by retrieving the information

(representing the displayed fom 700) from the sub-memory 2c- 1, setting information in the

form 700 to indicate a "Negotiating" deal status, and by storing the retrieved information in

the "Order Book" folder 502, to provide a record ofthe counter proposal in that folder 502.

Thereafter, in step A12-b' the SES responds to the information being stored in the folder 502

by invoking the conesponding event handler routine, which, in turn, copies both that

infoπnation and the infomiation defining the original transaction proposal stored in the folder

502 in earlier step A7', and causes the copied information to be stored in both the "Cunent

Conversations" folder USFl' associated with user UI' and the "Cunent Conversations" folder

USFl associated with user UI, based on user identifiers included in the information.

At some time later, it is assumed that user UI operates the interface 120a to

cause the "Cunent Conversations" folder USFl to be opened and the contents thereof

displayed on the display 120b in the above-described manner (step A12-c'). It is also

assumed that the user UI operates the user interface 120a for selecting a displayed transaction information item relating to the counter proposal forwarded by user UI' (step A12-d'). As a

result, an order book form 700 is again retrieved, and the information defining the counter

proposal stored previously in step Al2-b' is copied from the folder USFl and inserted into

conesponding fields ofthe retrieved form 700, in a similar manner as was described above.

The retrieved form 700, including the inserted information, is then displayed on the display

120b (step A12-e').

As can be appreciated in view of this description, the user UI may select any

one ofthe various option items 67, 70, 68, and 72 included in the form 700 displayed on the

display 120b. For the puφoses of this description, it is assumed that the user UI desires to

further negotiate the transaction counter proposal forwarded from user UI', and thus edits the

information included in selected field(s) of the fonn 700 to modify the tenns ofthe

transaction as desired, and then selects the "transmit" item 67 (step A12-f ). Thereafter,

control passes to block A12-g' where further procedures are perfonned for enabling the users

UI and UI' to further negotiate the transaction in the above-described manner. For example,

those procedures may include, at least in part, steps that are similar to steps A27-A33 of Fig.

4d described above, although slight modifications that would be readily apparent to one

skilled (in the art in view of this description) may be made to those steps as deemed necessary

to conform to the present embodiment (e.g., the counter variable 107b need not be controlled,

and the particular order in which infoπnation is stored in the folders depends on which user

UI, UV invoked the storage of such infomiation). The negotiations performed at block A12-

g' may include the exchange of multiple transaction counter proposals between the users UI

and UV, using the form700 (rather than deal fonn 50), depending on the users' respective

trading criteria. During the course ofthe further trading negotiations performed at block A12-

g', it is assumed that, after one ofthe users UI, UI', such as user UI, forwards a counter

proposal to user UI' (and, as a result, information defining that counter proposal is stored in

the "Cunent Conversations" folder USFl' associated with user UI'), the user UI' opens that

folder USFl' to cause the contents thereof to be displayed on the display 122b. It also is

assumed that the user UI' thereafter selects a displayed transaction information item

identifying that counter proposal. As a result, the form 700, including the field infoπnation

defining the counter proposal, is presented on the display 122b in the above-described

manner. If the user UI' then selects the "done" item 70 ofthe displayed form 700, then the

form script 40 associated with that form 700 responds by copying the information

(conesponding to the displayed fom 700) from the sub-memory 2c- 1 of worknode 122,

setting infoπnation in the fonn 700 to indicate a "complete" deal status, and by storing the

copy ofthe infonnation in the "Cunent Conversations" folder USFl' (step A12-i'). The SES

then detects the storage of that infonnation in the folder USFl' and responds by invoking the

conesponding event handler routine, which, in turn, copies that information, invokes a SQL

stored procedure (e.g., a "TakeOrder" stored procedure) in server 106', and provides the copy

ofthe information to the invoked procedure (step A12-j). Thereafter, control passes through

connector (B") to step Al 1-c' of Fig. 7c, where the method continues in the above-described

manner. However, in accordance with this embodiment ofthe invention, in addition to

causing the information from folder 506 to be moved to the "Log" folders USF2 and USF2' in

step Al 1-e' of that method, the event handler routine operates in conjunction with a business

object routine to cause the contents ofthe "Cunent Conversations" folders USFl, USFl' to

be moved into those "Log" folders USF2, USF2' in that step. Referring again to Fig. 7b, an example of a case in which the user UI' selects

the "chat" 72 in response to the form 700 being displayed on the display 122b in step AlO'

will now be described. Assuming that the user UI' selects the "chat" item 72 ofthe form 700

in step A14' ('Y' in step A14'), rather than the "done" item 70 and "transmit" item 67, then

control passes to block A14-a' where a chat procedure is performed in a similar manner as

was described above (see, e.g., the procedure shown in Fig. 4i), except that in this example,

the procedure is invoked by the user UI' rather than by the user UI, and, after the chat

procedure is terminated and the fonn 700 is again displayed (see, e.g., steps A26-g' and A26-

h' of Fig. 4i), control passes back to step Al l', where the method then continues in the above-

described manner.

If the user UI' selects the "no deal" item 68 ofthe order book form 700 in step

A15' ('Y' in step A15'), rather than the "done" item 70, "transmit" item 67, and "chat" item

72, then control passes to step A15-a' where the fomi script 40 associated with the form 700

responds by setting a flag 40b (Fig. 3b) to cancel the transaction. Then, in step A15-b', the

form script 40 causes the flag 40b and the infoπnation from the "Cunent Conversations"

folders USFl and USFl' to be stored in the "Log" folders USF2 and USF2', respectively, to

provide a record ofthe canceled transaction therein (step A15-b'). Control then passes to step

A 15-c' where the method is terminated.

(C) AUTOMATIC MATCHING SUB-EMBODIMENT

In accordance with still another aspect of this invention, individual users ofthe

communication system 200' can employ the system to propose an electronic transaction in the same manner as was described above (see, e.g., step A3' of Fig. 7a), and information defining

the proposed transaction (also hereinafter refened to as an "order" or "order information") is

then automatically compared with other orders that were previously posted in the electronic

"bulletin board" (e.g., public "Order Book" folder 502) to determine whether or not the

compared orders are of sufficient compatibility for being at least partially fulfilled. Orders

that are determined to be sufficiently compatible with one another are then automatically

"fulfilled", at least in part, depending on the particular terms of those orders.

A method in accordance with this aspect ofthe invention will now be

described, with reference to the flow diagram shown in Fig. 8a. In Fig. 8a, steps Al" to A5"

are identical to steps Al' to A5', respectively, of Fig. 7a described above, and thus will not be

described herein in further detail. In accordance with this aspect ofthe invention, after step

A5" is performed, control passes to step A6", where the SQL stored procedure responds to

the server 106' receiving the information (defining the order originally proposed by user UI

in earlier step A3") provided by the event handler routine operating in server 107' (in earlier

step A5") by invoking a predetennined routine (e.g., an "ob_-ProcessOrder"routine) in the

server 106' (step A6"). The invoked predetermined routine then compares a predetermined

portion ofthe received order infoπnation to conesponding infonnation from other orders

already existing (i.e., previously "posted" orders) in the "Order Book" table 500, to determine

whether or not any ofthe compared orders are compatible (step A7"). In accordance with an

exemplary embodiment of this invention, compared orders are considered to be "compatible"

where respective, predetem ined terms of those orders (i.e., terms defined by information

included in one or more predetennined infomiation fields ofthe fomis) are suitable for

enabling the orders to be fulfilled, at least in part, according to the particular market paradigm of interest. By example only, compared orders may be considered to be compatible where

one ofthe orders specifies a "bid" price that is greater than or equal to an "ask" price

specified by the other order, and where both ofthe orders relate to a same instrument type,

although other predetermined criteria may also be employed for determining whether or not

orders are compatible, depending on the applicable market paradigm of interest. The

comparison performed in step A7" may be performed in accordance with any suitable

technique for determining whether or not order terms are compatible, such as the following

exemplary SQL query, which searches for compatible sell orders:

Select * from OrderBook where

(Instrument = @NewOrderInstrument) AND

PriceUnit = @NewOrderPriceUnit) AND

(IsBid = 0) AND (Price <= @NewOrderPrice)

Order By Price Descending, DateTime Ascending

A similar query example searches for compatible buy orders:

Select * from OrderBook where

Instrument = @NewOrderInstrument) AND

PriceUnit = @NewOrderPriceUnit) AND

(IsBid = 1) AND (Price >= @NewOrderPrice)

Order By Price Descending, DateTime Ascending

In accordance with an exemplary embodiment of this invention, "compatible"

orders are fulfilled in a sequence that is based on some predetennined priority criteria, such

as, e.g., criteria specifying that a highest priority be given to earliest "posted" existing orders (in table 500) having a least expensive price, at any quantity, although in other embodiments,

other suitable priority criteria may also be employed, depending on applicable market

requirements. The manner in which compatible orders are fulfilled will be described below.

If the performance of step A7" results in a determination that the order which

was proposed by the user UI in earlier step A3" is not compatible with any ofthe orders

existing in the "Order Book" table 500 ("No"in step A8"), then control passes to step A12",

where the predetermined routine stores the order originated by user UI in the "Order Book"

table 500. Control then passes to block A13" where further procedures are performed in a

similar manner as shown in, e.g., Figs. 7a-7c, beginning with step A7', except that, to

conform to the present embodiment, it is assumed that the reference numerals having a single

prime in Figs. 7a-7c are replaced with reference numerals having a double prime. The order

stored in the "Order Book" table 500 in step A12" remains in that table, for eventually being

compared with other orders that may be posted in the table 500 during the procedures

performed at block step A13", in the above-described manner.

The manner in which "compatible" orders are fulfilled in this exemplary

embodiment ofthe invention will now be described, with reference again being made to step

A7" of Fig. 8a. If the perfomiance of step A7"results in a determination that the order which

was proposed by the user UI in earlier step A3" and a particular order existing in the "Order

Book" table 500 are compatible ("Yes" in step A8"), then control passes to step A9" where

the predetermined routine perfoπns a calculation that employs both a predetermined variable

that is initialized to equal the quantity value specified by the received user UI order (e.g., the

megawatt-hour value from field 302 of fonn 130), and infoπnation representing the quantity value specified in the existing order (e.g., the megawatt-hour value from field 302 ofthe form

130), to fulfill ("hit") the existing order. For example, the calculation may include choosing

the lesser of either i) the quantity value specified in the exiting order or ii) the quantity value

represented by the predetermined variable, from the quantity value specified in the existing

order.

Thereafter, in step AlO" the predetermined routine reduces the value

represented by the predetermined variable by the amount calculated in step A9". Thereafter,

if the resulting value ofthe predetermined variable is greater than zero ("No" in step Al l"),

then the order from user UI has been completely fulfilled, and control passes back to step

A8" where a decision is made to determine whether to pass control to step A9" or step A12",

depending on whether or not there are other compatible orders in the "Order Book" table 500.

If "Yes" in step A8", then control passes to step A9" where the method proceeds in the

above-described manner. If "No" in step A8", then control passes to step A12" where, in this

case, infonnation included in the order originated by user UI is modified (updated) to

indicate the latest value ofthe predetennined variable (i.e., the quantity value in field 303 of

the order fomi 130 is updated to indicate the remainder value calculated in step AlO"), and

then the order, including the updated information, is stored in the "Order Book" table 500.

Control then passes to block A13" where further procedures are performed in a similar

manner as was described above. The updated version ofthe newly-stored order in the "Order

Book" table 500 remains in that table, for eventually being compared with other orders that

may be posted in the table 500 during the procedures perfonned at block A13", in the above-

described manner. Referring again the step Al l", if it is determined in that step that the quantity

value ofthe predetermined variable resulting from the performance ofthe calculation in

previous step AlO" is equal to zero ("Yes" in step Al l"), then it is recognized that the order

which user UI originated has been completely fulfilled. Control then passes to step A14",

where the information representing the quantity value (field 302) in each ofthe respective

existing orders in the "Order Book" table 500 which were "hit" in step A9" is modified

(updated) to indicate the remaining quantity value calculated for the order in the step A9"

(step A14"). Thereafter, control passes to block A15", where further procedures are

performed in a similar manner as shown in, e.g., Figs. 7a- 7c, beginning with step Al 1-b',

except that, to conform to the present embodiment, it is assumed that the reference numerals

having a single prime in Figs. 7a-7c are replaced with reference numerals having a double

prime. The updated versions ofthe existing orders remain in the "Order Book" table 500 for

eventually being compared with other orders that may be posted in the table 500 during the

procedures perfonned at block step A15", in the above-described manner.

An example of a case in which multiple existing orders from the "Order Book"

table 500 are employed to fulfill the order proposed by user UI will now be described, with

reference being made to Table I shown below, which represents various orders that are

assumed to have been existing (stored) in the "Order Book" table 500 by users UI', U2, and

U3, prior to the time when user UI proposed his order in earlier step A3". The existing

orders are defined in temis of "Type" (e.g., "sell"), "Quantity" (MWH), and "Price" ($). The

time and/or date at which each individual existing order was "posted" (stored) in the table

500 (as detemiined by an internal clock (not shown) within server 106') in this example are

listed under the column entitled "Date/Time". TABLE I

Date/Time Type Ouantity Price User

10:01 Sell 10 MWH $22.00 UI'

10:02 Sell 5 MWH $20.00 U2

10:03 Sell 10 MWH $20.00 U3

Assuming that the order submitted by the user UI in earlier step A3" proposed

to buy 5 MWH at any price up to $22.00, then the performance ofthe procedures depicted in

Fig. 8a results in an automatic fulfillment of that order and an automatic partial fulfillment of

the order posted by user U2, since that latter order has the best price and earliest posting time.

As another example, if the order which was originally submitted by the user UI in earlier step

A3" proposed to buy 10 MWH at any price up to $22.00, then the performance ofthe

procedures depicted in Fig. 8a results in an automatic fulfillment of that order, and an

automatic fulfillment ofthe existing U2 order and then partial (5 MWH) fulfillment of

existing U3 order (the user U2 order is fulfilled before the user U3 order because the U2 order

is again given higher priority owing to its earlier "posting" time). As a result, the "Quantity"

term of 10 MWH from the user U3 order is reduced by the quantity fulfilled. As a further

example, if the order which was originally submitted by the user UI in earlier step A3"

proposed to buy 20 MWH at $20.00, then the performance ofthe procedures depicted in Fig.

8a results in an automatic partial fulfillment of that order, and an automatic fulfillment of

both the U2 order and then the U3 order (the U2 order was posted earlier than the U3 order,

and thus is fulfilled before the U3 order), and also results in there being a remainder of 5

MWH for the user UI order. Furthermore, if the order which was originally proposed by the

user UI in earlier step A3" proposed to buy 20 MWH at $22.00, then the performance ofthe

procedures depicted in Fig. 8a results in that order being fulfilled by the user U2 order and the U3 order at $20.00, and 5MWH ofthe user UI' order at $22.00. The "Quantity" term

(10MWH) ofthe UI' order is then reduced by 5MWH accordingly.

In accordance with an alternate embodiment of this invention, the order which

was originally proposed by the user UI in earlier step A3" of Fig. 8a may include instruction

information (which may or may not be user-generated) specifying that the order must be

either completely fulfilled, or otherwise, not be fulfilled at all. In this embodiment ofthe

invention, and refening now to Fig. 8b, steps Al" to A8" are performed in the same manner

as was described above for Fig. 8a. Thereafter, control passes to step A-9" where the

predetermined routine examines the existing order (from "Order Book" table 500) previously

determined (in step A8") to be compatible with the order originated by user UI, to determine

whether or not the existing order includes instruction information specifying that the order

must be either completely fulfilled or not be fulfilled at all (step A-8a"). If it is determined

in step A-8a" that such instruction information is not included in the existing order ("No" in

step A-8a), then control passes to step A-9", and then eventually to steps A-10", A-ll", and

possibly steps A14" and A15" as well, all of which are perfomied in a similar manner as steps

A9", AlO", Al l", A14", and A15", respectively, of Fig. 8a described above.

If it is detemiined in step A-8a" that the instruction infonnation is included in

the existing order ("Yes" in step A-8a"), then control passes to step A-8b" where the

predetermined routine determines whether or not the value ofthe predetermined variable,

which is initialized to equal the quantity tenn (e.g., included in field 302) from the order

originated by user UI, is at least as large as the quantity value specified in the existing order

(step A-8b"). If "No" in step A-8b", then control passes to step A-l l" where the procedure continues in the above-described manner, and the existing order is not fulfilled by the order

from user UI.

Referring again to step A8", and assuming that the order which the user UI

originally proposed in step A3" was partially fulfilled by one or more respective, existing

orders in earlier step A-10", a case in which it is determined that the order from user UI is not

compatible with any other exiting order in the "Order Book" ("No" in step A8") will now be

described. If "No" in step A8", then control passes to step A-8c" where the predetermined

routine examines the value ofthe predetermined variable to determine whether or not the

value exceeds zero (i.e., to determine whether or not the user UI order has a remainder). If

"No" in step A-8c", then the order is not fulfilled by any ofthe existing orders in the table

500, and control passes to block A- 16" where the method is terminated. If "Yes" in step A-

8c", then control passes to step A-8d" where the predetermined routine examines the user UI

order to determine whether or not the order includes instruction information specifying that

the order must be either completely fulfilled or not be fulfilled at all (step A-8d"). If it is

determined in step A-8d" that the instruction information is not included in the existing order

("No" in step A-8d), then control passes to step A-12", and then eventually to step A-13",

which are performed in a similar manner as steps A12" and A13", respectively, of Fig. 8a

described above. If it is detemiined in step A-8d" that the instruction infoπnation is included

in the user UI order ("Yes" in step A-8d), then control passes to step A-8e" where the

predetermined routine rolls back any previously "hi 'existing orders (i.e., so that any existing

order which was previously "hit" in step A-9" is not fulfilled), and then control passes to step

A-12", where the method then continues in the manner described above. In this manner, the

user UI order including the instruction information is not fulfilled at all, since it was determined in step A-8c" that the compatible, existing orders in the "Order Book" table 500

could not completely fulfill that order.

It should be noted that while the foregoing description describes an example of

the manner in which the automatic matching embodiment of this invention may be employed

to automatically process trade orders relating to an electrical power market, this embodiment

ofthe invention is not necessarily limited to being used only for trading the instmments of

that particular market. For example, the automatic matching embodiment of this invention

also may be employed for trading any other suitable type of instmments, goods, and/or

services, etc. One having skill in the art would readily appreciate, in view of this description,

how to create and/or modify the various programs described above to conform the present

embodiment for use in trading such other instmments, goods, and/or services. Also, the

relevant criteria used for determining whether or not orders are compatible with one another,

and the criteria used for determining the priority with which multiple pre-existing orders are

handled, may be defined in accordance with applicable criteria ofthe market paradigm of

interest, and are not necessarily limited to those described above. In other embodiments, no

priority criteria need be employed at all.

(O) AUTOMATIC CREDIT VERIFICATION SUB-EMBODIMENT

A further aspect of this invention will now be described. In accordance with

this aspect ofthe invention, a party Pl-Pn may specify conditions under which the party Pl-

Pn and/or its sub-parties will engage in a transaction with other parties and or sub-parties, and

those conditions are employed during the course of an electronic transaction to automatically

determine whether or not the transaction may be completed, as will be described in detail

below.

Before describing a method in accordance with this embodiment ofthe

invention, reference will first be made to Fig. 16, which depicts the "Order Book" table 500

and "Credit" table 910 stored in server memory 106a, and the "Order Book" folders SF5-a,

SF5-a', etc., and "Credit" folders SF5-b, SF5-b', etc., stored in the server memory 107a. As

was previously described, each ofthe "Order Book" folders SF5-a, SF5-a', etc., stores

information, such as, e.g., orders 920 that were "posted" by sub-parties in the "Order Book"

table 500 and subsequently copied to the folders SF5-a, SF5-a', etc., by the database

synchronization program (identified by reference numeral 911) in the above described

manner. That program 911 maintains the information included in the individual folders SF5-

a, SF5-a', etc., and SF5-b, SF5-b', etc., in synchronization with the information included in

the respective tables 500 and 910, respectively, in a similar manner as was described above.

In accordance with a prefened embodiment of this invention, the Credit"

folders SF5-b, SF5-b', etc., and "Credit" table 901 are employed for storing various user-

defined credit information specifying conditions under which a party Pl-Pn will engage in a transaction with another party Pl-Pn or sub-party. The "Credit" table 910 includes a plurality

of sub-tables ST-1 to ST-n, each of which conesponds to a respective one ofthe "Credit"

folders SF5-b, SF5-b', etc., and stores information that conesponds to infonnation stored in

the conesponding folder.

Preferably, only pre-authorized users, such as authorized credit administrators,

may have access to the infomiation included in the various folders SF5-b, SF5-b', etc., and

may enter, delete, modify, organize, or otherwise manipulate such information, using

functionalities provided by suitable information management software, preferably, Microsoft

Outlook 2000 (or later versions thereof) operating in conjunction with Microsoft Exchange

2000 (or later versions thereof). Non-authorized users, on the other hand, are preferably

prevented from viewing and accessing such information by a security service program

running in servers 106a and 107'. Any suitable, known type of security service program may

be employed for preventing non-authorized users from viewing and accessing such

information, and thus, the details of that security service program will not be described

herein.

An example ofthe manner in which credit infoπnation is provided in the

individual folders SF5-b, SF5-b', etc., and the "Credit" table 910 by an authorized user will

now be described, with reference to the flow diagram depicted in Fig. 9a. In step 901 of Fig.

9a, it is assumed that an authorized user, such as, e.g., user UI associated with party PI,

enters and/or modifies credit-related information in the "Credit" folder SF5-b(step 901).

Thereafter, the SES responds by invoking the event handler conesponding to that folder SF5-

b (step 903). The invoked event handler then copies the information contents from the folder SF5-b, and provides the copied contents to the SQL stored procedure in server 106', through

link Ll'(step 905). The SQL stored procedure then responds by storing the provided

information in the conesponding sub-table ST-1 within "Credit" table 910 of memory 106a

(step 907). In this manner, the information included in the sub-table ST-1 is updated in

accordance with the information included in the "Credit" folder SF5-b.

Reference is now made to Fig. 15, which shows an example of a displayed

window 900 that includes information representing various exemplary contents of one ofthe

"Credit" folders SF5-b, SF5-b', etc., associated with a particular one ofthe parties Pl-Pn,

respectively. For the puφoses of this description, it is assumed that those contents are from

"Credit" folder SF5-b associated with party PI . The contents of folder SF5-b may be

displayed on a display 2e of a user infomiation appliance 2 in response to, e.g., a user

opening the folder SF5-b in the above-described manner.

In accordance with an exemplary embodiment ofthe invention, included

within the window 900 are one or more user-selectable, primary information items, each of

which is denoted by reference numeral 902 and may coπespond to an electronic folder. In

the example depicted in Fig. 15, each primary information item 902 includes infoπnation

identifying a particular counter-party organization, such as, e.g., P2-Pn. One or more groups

904 of secondary (or sub-)information items are associated with each primary information

item 902, although for convenience, only one such group 904 is shown. Each ofthe groups

904 of secondary infomiation items may be displayed in the window 900 in response to a

user selecting a conesponding one ofthe primary infonnation items 902. A first one ofthe

secondary infonnation items in group 904 is further identified by reference numeral 904a, and includes information 904- la identifying the particular counter-party organization (e.g., party

P2), information 904-lb specifying a limit (e.g., a daily limit) on an amount of credit which

the party PI has authorized to extend to the counter-party organization, and information 904-

lc identifying the amount of available credit remaining for that counter-party organization

(e.g., on a particular day). The limits defined by the information 904-lb and 904-lc

collectively represent conditions under which the party PI will engage in a transaction with

the counter-party organization P2 identified by the information 904-1 a.

Each ofthe other information items ofthe group 904 is further identified by

reference 904b in Fig. 15, and includes a) information 904- Id identifying a respective counter

sub-party (such as a user UI', U2' or a counter sub-organization) that is associated with the

particular counter-party organization identified by information 904- la, b) infoπnation 904- le

identifying a location relating to that counter sub-party, c) information 904- If specifying a

limit (e.g., a daily limit) on an amount of credit which the party PI has authorized to extend

to the counter sub-party, and d) infonnation 904- lg specifying an amount of available credit

remaining for that counter sub-party. The limits defined by the infomiation 904- If and 904-

lg of each secondary infoπnation item 904b collectively represent conditions under which the

party Plwill engage in a transaction with the counter sub-party identified by the information

904- Id of that item.

It should be noted that the infomiation depicted in Fig.15 is merely intended to

be exemplary in nature, and not limiting to the scope of this invention. For example, other

types of conditions under which a transaction may be perfonned with a particular counter¬

party or counter sub-party also may be employed in lieu of, or in addition to, those described above, depending on the applicable market paradigm of interest. In other embodiments ofthe

invention, information specifying whether or not a transaction may be conducted with a

particular counter-party or counter sub-party ("yes" or "no") also may be employed in lieu of

the information 904-lb, 904- lc, 904- If, and 904- lg described above, or, in other

embodiments, other relevant types of conditions may be specified.

The manner in which the various credit-related information described above is

used in this invention will now be described, with reference to Figs. 9b-9d, which depict a

flow diagram of a method in accordance with a prefened embodiment of this invention.

Steps Al'" to A6'" of Fig. 9b are performed in a similar manner as the above-described steps

Al' to A6', respectively, of Fig. 7a, and thus will not be described herein in further detail.

After step A6'" is perfomied, control passes through connector (A'") to step A7'" of Fig. 9c,

where the SQL stored procedure detects the storage ofthe information in table 500 in

previous step A6'", and then responds by invoking the database synchronizer program, which,

in turn copies the information included in table 500, and provides a copy of that information

to a business object routine in the server 107'. The business object routine then responds to

receiving that infomiation by storing the information in each ofthe "Order Book" folders

SF5-a, SF5-a', etc., associated with respective parties Pl-Pn (step A7'"). As a result, the

infomiation defining the order originally proposed by the user UI in earlier step A3'" (and

any information defining any other orders 920 from the table 500) becomes "posted" (i.e., the

order is "posted") in each "Order Book" folder SF5-a, SF5-a', etc., for subsequent

consideration by users associated with the conesponding party Pl-Pn, upon opening the

respective folder. The order remains "posted" (i.e., stored) in the individual "Order Book"

ill folders SF5-a, SF5-a', etc., until the order is either canceled by the user UI or automatically

removed from the individual folders in the above-described manner.

After step A7'" is performed, steps A8'" and A9"are performed in a similar

manner as the above-described steps A8'and A9', respectively, of Figs. 7a and 7b, except that

in step A8'" the user UI' opens the "Order Book" folder SF5-a' (rather than folder 502)

associated with the party P2 to cause the contents of that folder to be displayed on the display

122b (step A8'"), and in step A9'"it is assumed that the user UI' selects a displayed

transaction information item relating to the order (from user UI) posted in folder SF5-a' in

previous step A7'". In response thereto, an electronic order book form 700 is retrieved in a

similar manner as was described above, information relating to the selected transaction

information item is copied from folder SF5-a' and inserted into conesponding fields ofthe

retrieved form 700, and then the fomi 700, including the inserted information, is displayed on

the display 122b (and conesponding infoπnation is stored in sub-memory 2c- 1 of worknode

122) in the above-described manner (step AlO'").

Assuming that the user UI' then selects the "done" item 70 ofthe displayed

form 700 (step All'"), then control passes to step Al l-a'", where a form script 40 associated

with the order book form 700 responds by retrieving the information (representing the

displayed form 700) from the sub-memory 2c-l of worknode 122, and by then storing the

retrieved infomiation in the "Order Book" folder SF5-a' associated with party P2.

Thereafter, in step Al 1-b'" the SES responds to the infomiation being stored in the folder

SF5-a' in previous step Al 1-a'" by invoking the conesponding event handler routine, which,

in turn, copies the information from the folder SF5-a' and provides the copy ofthe information to a SQL stored procedure in server 106' (step Al 1-b'"). In accordance with an

aspect of this invention, the SQL stored procedure then responds to receiving the information

by conelating infoπnation (e.g., a TCID) identifying party P2, from a portion ofthe received

information defining the order originally proposed by user UI in earlier step A3'", to

information 904-1 a identifying the party P2, included in the sub-table ST-1 conesponding to

party PI (i.e., to the information 904- la originally entered in the "Credit" folder SF5-b by the

credit administrator of party PI in step 901 of Fig. 9a). The SQL stored procedure then

conelates that infonnation 904-la in the sub-table ST-1 to conesponding infoπnation 904-lc

specifying the amount of available credit remaining for the party P2 (step Al 1-c'"). It also

conelates the infonnation representing remaining credit for party PI in sub-table ST-2.

Thereafter, in step Al I'd"' the SQL stored procedure compares that information 904-lc to a

portion ofthe infoπnation received in earlier step Al l-b'"specifying the "bid" price value

(originally included in field 303' of form 700), to determine whether or not the specified

"bid" price value exceeds the amount of available credit specified by the information 904-lc

(step Al 1-d'"). If the perfomiance of step Al 1-d'" results in a determination of "Yes"

("Yes" in step Al 1-d"), then at least one party is considered to have an insufficient amount of

credit available for completing the transaction, and control then passes to step Al 1-e'" where

a further step is performed in a manner as will be described below.

In accordance with a prefened embodiment of this invention, in steps All-c'"

and Al 1-d'", the SQL stored procedure also performs similar procedures as described above

to determine whether or not the party PI (with which the user UI who originally posted the

transaction in earlier step A3'" is associated) has a sufficient amount of credit available for

being able to fulfill the transaction with user UI' associated with party P2. For example, in this embodiment, in step All-c'"the SQL stored procedure also conelates identifier

information (e.g., a TCID) identifying party PI, included in the order information received in

step Al 1-b'", to information 904-la identifying that party PI from the sub-table ST-2

conesponding to party P2 (i.e., to information 904-la originally specified by a credit

administrator of party P2), and then conelates that infonnation 904-la to conesponding

infonnation 904-lc in sub-table ST-2, specifying the amount of available credit remaining for

the party PI (step Al 1-c'"). Thereafter, in step Al 1-d'" the SQL stored procedure compares

the conelated infoπnation 904-lc to a portion ofthe received information specifying the

"ask" price value (originally included in field 304' of form 700), to determine whether or not

the specified "ask" price value exceeds the amount of available credit specified by the

conelated information 904-lc (step Al 1-d'"). If it is determined that the specified price

value exceeds the amount of available credit remaining for party PI ("Yes" in step Al 1-d"),

then the party PI is considered to have an insufficient amount of credit available for

perfonning the transaction with sub-party UI' associated with party P2.

A case in which the performance of step Al 1-d'" results in a deteπnination

that at least one ofthe parties PI and P2 has an insufficient amount of available credit for

performing the transaction ("Y" in step Al 1-d'") will now be described. If "Yes" in step

Al 1-d'", then control passes to step Al 1-e'" where the SQL stored procedure returns a failure

code to the calling event service. The SES, in turn, invokes the messaging service employed

in the server 107 to cause that service to generate and send an electronic message to one or

more predetennined folders/mailboxes associated with respective ones ofthe users UI and

UI' (based on user identifiers included in the order infonnation in folders SF5-a, SF5-a'), for

notifying those users UI and UI' that the transaction cannot be completed (step Al 1-r'"). The messages may also indicate which party/sub-party was denied credit, and/or may specify,

e.g.,"We Deny You Credit" or "Credit Denied To Counter-Party", depending on whether or

not the stored information indicates which party/sub-party was denied credit.

A case in which the performance of step Al 1-d'" results in a determination

that both ofthe parties PI and P2 have a sufficient amount of credit available for performing

the transaction will now be described ("No" in step Al 1-d"). If "No" in step Al 1-d'", then

control passes to step Al 1-f ", where the SQL stored procedure conelates infoπnation

identifying user UI' (from the order information received in earlier step Al 1-b'") to

conesponding infonnation 904b' identifying that user UI' in sub-table ST-1, and then

conelates that infonnation 904b' to associated infonnation 904- lg in that sub-table ST-1

specifying the amount of available credit remaining for that user (sub-party) UI' (i.e., to the

information 904- lg originally entered into the "Credit" folder SF5-b by the credit

administrator of party PI in step 901 of Fig. 9a) (step Al 1-dl'").

Thereafter, in step Al 1-f '", the SQL stored procedure compares the portion of

the received order information specifying the "bid" price value to the conelated infoπnation

904- lg to detennine whether or not the specified "buy" price value exceeds the amount of

available credit specified by that infoπnation 904-lg. If "Yes" in step Al 1-f", then control

passes to step Al l-e'"where the method continues in the above-described manner. If "No"

instep Al l-f", then control passes tlirough connector (B'") to step Al l-g'" of Fig. 9d, where

a further step is perfonned in a manner as will be described below. In accordance with a prefened embodiment of this invention, in steps Al 1-

dl'" and Al 1-f", the SQL stored procedure also performs similar procedures as described

above to determine whether or not the user UI who originally proposed the transaction (in

earlier step A3'") has a sufficient amount of credit available for performing the transaction

with the user UI' from party P2. For example, in this embodiment, in step Al l-dl'"the SQL

stored procedure also conelates infoπnation identifying user UI, included in the received

order information (i.e., the information received in step Al 1-b'"), to information 904-ld

identifying that user UI from the sub-table ST-2 (i.e., to the information 904-ld originally

entered into the "Credit" folder SF5-b' by a credit administrator of party P2), and also

conelates that infoimation 904-ld to conesponding information 904- lg in the sub-table ST-

2, specifying the amount of available credit remaining for the user UI (step Al 1-dl'").

Thereafter, in step Al 1-f " the SQL stored procedure compares the conelated infonnation

904- lg to a portion of the received information specifying the "ask" price value (originally

included in field 304' of fomi 700), to determine whether or not the specified "ask" price

value exceeds the amount of available credit specified by the information 904- lg (step Al 1-

f "). If it is detemiined that the specified price value exceeds the amount of available credit

remaining for sub-party UI ("Yes" in step Al 1-f), then the sub-party UI is considered to

have an insufficient amount of credit available for performing the transaction, and control

then passes to step Al 1-e'", where the method continues in the above-described manner.

A case in which the performance of step Al 1-f" results in a determination

that each ofthe sub-parties UI and UI' has a sufficient amount of credit available for

perforating the transaction will now be described. If each sub-party UI and UI' is determined

to have a sufficient amount of available credit in step All-f" ("N" in step All-f"), then control passes through connector (B'") to step Al 1-g'" of Fig. 9d, where the SQL stored

procedure removes or modifies the information defining the original order stored earlier in

step A6'" from the "Order Book" table 500, and then stores that information and the

information received from the event handler routine in previous step Al 1-b'", in the "Deals

Done" table 504 within memory 106a (step Al 1-g'"). In this manner, two new entries are

made in the table 504, one of which represents the original transaction proposal posted by

user UI in earlier step A3'", and the other of which represents the transaction accepted by

user UI' in earlier step Al l'". In step Al 1-h'", the SQL stored procedure also performs a

calculation employing the price values (i.e., the values originally included in fields 303' and

304' of form 700) included in the order information and the infonnation 904-lc and 904-lg

from each ofthe sub-tables ST-1 and ST-2, defining the amounts of available credit for the

parties PI, P2 and sub-parties UI, UI', to detennine the credit amount now remaining for

each of those parties PI, P2 and sub-parties UI, UI', now that the transaction has been

perfonned (step Al 1-h"). Thereafter, in step Al 1-i'", the SQL stored procedure updates

(modifies) the previously-conelated information 904-lc (in both ofthe sub-tables ST1 and

ST2) conesponding to respective ones ofthe parties PI, P2 accordingly, if needed, and also

updates (modifies) the previously-conelated infoπnation 904-lg (in both ofthe sub-tables

ST1 and ST2) conesponding to respective ones ofthe sub-parties UI, UI' accordingly, if

needed, so that the respective updated infoπnation indicates the conesponding remaining

values calculated in previous step Al l-h'"(step Al 1-i'").

In step Al 1-j'", the SQL stored procedure responds to the information being

updated in previous step Al 1-i'" by invoking the database synchronizer program (e.g., NT

service), which, in turn copies (i.e., reproduces) the infomiation from the sub-tables ST-1 to ST-n to respective ones ofthe "Credit" folders SF5-b, SF5-b', etc., associated with the

respective parties Pl-Pn, to thereby update and synchronize the information included in those

folders in accordance with that stored in the table 910 (step Al 1-k'"). As a result, the

information included in folders SF5-b and SF5-b' will now indicate the amounts of available

credit calculated in earlier step All-h'".

In step Al 1-1'", the SQL stored procedure responds to the information being

stored in the "Deals Done" table 504 in earlier step Al 1-g'" by invoking the database

synchronizer program (e.g., NT service), which, in turn, copies (i.e., reproduces) the

information from that table 504 to the "Deals Done" folder 506 within memory 107a, to

thereby update and synchronize the infonnation included in that folder 506 in accordance

with the information stored in the table 504. Also in step Al 1-1'", the SQL stored procedure

responds to the information defining the original order being removed from the "Order Book"

table 500 in earlier step Al 1-g'" by copying (i.e., reproducing) the information from the

"Order Book" table 500 within memory 106a to each ofthe "Order Book" folders SF5-a,

SF5-a', etc., within memory 107a, to thereby update and synchronize the information

included in those folders in accordance with the information stored in the table 500.

Thereafter, control passes to block All-m"', where the SES responds to the information

being stored in the folders SF5-a, SF5-a' in previous step Al 1-1'" by invoking conesponding

event handler routines, which, in turn, retrieve the infomiation defining the original and

accepted orders from folders SF5-a, SF5-a', and causes the retrieved information to be stored

by a business object routine in both ofthe "Log" folders USF2 and USF2' associated with the

respective users UI and UI'. In this manner, an historical record ofthe order originally

proposed in earlier step A3 '"and the accepted version of that order is provided in the "Log" folders USF2 and USF2', for subsequent viewing by the respective users UI and UI'. Control

then passes to block Al 1-n'", where further procedures are performed in a similar manner as

steps Al 1-f to Al 1-h' of Fig. 7c described above, and thus those steps not be described in

further detail.

It should be noted that the "Automatic Credit Verification Sub-Embodiment"

of this invention is not limited to being employed only in the particular embodiment (e.g., the

"Firm Matching Sub-Embodiment") described above, nor for use only in associated with

trades of electrical power-related market instmments. For example, the "Automatic Credit

Verification Sub-Embodiment" of this invention also may be employed in other

embodiments/sub-embodiments described throughout this detailed description, including,

e.g., the "Electronic Trading Negotiation Embodiments" and the "Automatic Matching Sub-

Embodiment" described above, and also may be used for automatically verifying party/sub-

party creditworthiness in association with trades of any other types of instmments, goods, or

services, etc. One skilled in the art would readily appreciate in view of this description how

to incoiporate the features ofthe "Automatic Credit Verification Sub-Embodiment" into

those other embodiments ofthe invention, and also would appreciate the manner in which the

above-described credit- verification procedures would be adapted for use in trades of other

types of instmments, goods, or services. For example, in the case ofthe "Automatic

Matching Sub-Embodiment", the folders and tables depicted in Fig. 16 would also be

employed for storing infomiation as described above, and credit-verification procedures are

perfonned in the following manner. If it is determined in steps A8" to AlO" of Fig. 8a that

the order originally proposed by user UI in earlier step A3" and one ofthe pre-existing orders

in the "Order Book" table 500 1) relate to the same "instrument" ("Y"in step A8"), 2) propose compatible transaction counter-types ("Y"in step A9"), and 3) and include either the same or

partially comparable counter-price values ("Y" in step AlO") ("Y" in step A13"), in the^'

manner described above, then the predetermined routine performs steps Al 1-d'" to Al 1-f"

(Fig. 9c) in a similar as was described above to detemiine, based on predetermined

information in the sub-tables ST1 to ST-n, whether or not the parties PI, P2 and the

associated users UI, UI' who originated the orders have sufficient amounts of credit available

for enabling the transaction to be fulfilled. If it is determined in those steps that those parties

PI, P2 and sub-parties UI, UI' do have sufficient amounts of available credit, then control

passes through connector (G') to step AlO-a" of Fig. 8b, where the method continues in the

above-described manner. Otherwise, if it is determined that at least one ofthe parties PI, P2

and/or sub-parties UI, UI' does not have a sufficient amount of available for being able to

fulfill the transaction, then control passes to step Al l" of Fig. 8a where the method continues

in the above-described manner, except that, in this case, messages are also sent to

predetermined folders associated with the sub-parties UI, UI' to notify those sub-parties that

the transaction cannot be completed, in the above-described manner.

(E AUTOMATIC CREDIT-BASED VIEW SCREENING SUB-EMBODIMENT

Another aspect of this invention will now be described. In accordance with

this aspect of the invention, orders 920 that are posted in the "Order Book" table 500 are

examined prior to being copied to the "Order Book" folders SF5-a, SF5-a', etc., and are then

filtered or otherwise visually distinguished from other orders, based on whether or not the

parties/sub-parties which proposed the orders are deemed to be worthy of credit by other

parties Pl-Pn. A method in accordance with this aspect ofthe invention will now be described, with reference again being made to Figs. 9b-9d. As was previously described, in

each ofthe steps A7'"(Fig. 9c) and Al l-l'"(Fig. 9d) described above, a SQL stored procedure

detects the storage ofthe information in the "Order Book" table 500, and responds thereto by

invoking the database synchronizer program to copy (i.e., reproduce) the information contents

of table 500 to the server 107', wherein a business object routine then stores that information

in each ofthe "Order Book" folders SF5-a, SF5-a', etc., associated with respective parties Pl-

Pn. In accordance with the present aspect of this invention, prior to copying the information

from the table 500 to the folders SF5-a, SF5-a', etc., in steps A7'" and All-1'", the database

synchronizer program performs a number of preliminary steps. Those steps are identified by

reference numerals A12'" to A18" in Fig. 9e, and represent in further detail each ofthe steps

A7'" and Al l-l'"refened to above.

In step A12", the data base synchronizer program performs an operation in a

similar manner as in step Al 1-c'", but for each order 920 included in the "Order Book" table

500, and for each sub-table ST-1 to ST-n within the "Credit" table 910. For example, in step

A12", the database synchronizer program conelates respective party identifier information

(e.g., a TCID of a party Pl-Pn with which a user who posted the order is associated) from

each individual order 920 stored in the "Order Book" table 500 to conesponding infonnation

904-la from each individual one ofthe infonnation sub-tables ST-1 to ST-n in "Credit" table

910, and further conelates that infonnation 904-la to conesponding infoπnation 904-lc in

those respective sub-tables ST-1 to ST-n. The SQL stored procedure then compares the

conelated information 904-lc from each sub-table ST-1 to ST-n to a portion of each order

920 specifying the "bid" price value credit specified by the information 904-lc from the

respective sub-tables ST-1 to ST-n (step A13'"). If it is determined that the specified price value of a respective order 920 exceeds the amount of available credit specified by the

information 904-lc from a particular sub-table ST-1 to ST-n ("Yes" in step A13'"), then the

party Pl-Pn associated with the user who originally posted the order 920 is considered to

have an insufficient amount of credit available for engaging in a transaction with the

individual party Pl-Pn conesponding to that sub-table ST-1 to ST-n. As a result, the

database synchronizer program then sets either a "We Denied Credit" flag, a "They Denied

Credit" flag, or both in the order 920 to indicate that fact (step A14'"), depending on the limit

or limits exceeded. Otherwise, if "No" in step A13'", then no such flag is set in the order 920

of interest.

Preferably, in steps A12'" and A13'", the database synchronizer program also

performs similar procedures as described above to determine whether or not the individual

parties Pl-Pn associated with respective folders SF5-a, SF-5a', etc., have sufficient amounts

of credit available for engaging in a transaction with the parties/sub-parties which posted the

respective orders 920 in the "Order Book" table 500. For example, in step A12'", for each

order 920 in the table 500, the database synchronizer program refers to a sub-table ST-1 to

ST-n conesponding to the party Pl-Pn from which the order 920 originated, and then also

refers to information 904-lc within that sub-table specifying the amounts of available credit

that may be remaining for other parties Pl-Pn (step A12'"). Thereafter, the database

synchronizer program compares the portion of each individual order 920 specifying the "ask"

price value (originally included in field 304' of form 700), to the conelated infoπnation 904-

lc to determine whether or not the specified "ask" price value ofthe respective order exceeds

the amounts of available credit specified by the respective infoπnation 904-lc (step A13'").

If it is detemiined that the specified price value of a particular order 920 does exceed the amount of available credit specified by the information 904-lc ("Yes" in step A13"), then the

party Pl-Pn identified by that information 904-lc is considered to have an insufficient

amount of credit available for engaging in a transaction with the party Pl-Pn that originated

the order 920. As a result, the database synchronizer program sets either a "We Denied

Credit" flag, a "They Denied Credit" flag, or both, depending on the limit or limits exceeded,

in the order 920 to indicate that fact (step A14'"). Otherwise, if "No" in step A13'", then no

such flag is set in the order 920 of interest.

In step A15", the database synchronizer program conelates respective sub-

party identifier (e.g., user UI) information from each individual order 920 stored in the

"Order Book" table 500 to conesponding infoπnation 904-ld from each individual one ofthe

sub-tables ST-1 to ST-n of "Credit" table 910, and further conelates the infoπnation 904-ld

to conesponding infoπnation 904-lg in those respective sub-tables ST-1 to ST-n. The SQL

stored procedure then compares the portion of each order 920 specifying the "bid" price value

to the conelated infoπnation 904-lg in each sub-table ST-1 to ST-n to determine whether or

not the specified "bid" price value ofthe order exceeds the amount of available credit

specified by the information 904-lg in the respective sub-tables ST-1 to ST-n (step A16'").

If it is determined that the specified price value of a particular order 920 exceeds the amount

of available credit specified by the information 904-lg in a particular sub-table ST-1 to ST-n

("Y" in step A16'"), then the sub-party who originally posted the order is considered to have

an insufficient amount of credit available for engaging in a transaction with the party Pl-Pn

conesponding to that sub-table. As a result, the database synchronizer program sets a "We

Denied Credit" flag, a "They Denied Credit" flag, or both, depending on the limit or limits exceeded, in the order 920 to indicate that fact (step A17'"). Otherwise, if "No" in step

A16'", then no such flag is set in the order 920 of interest.

In step A18'" the database synchronizer program copies (i.e., reproduces) the

information defining the orders 920 from the table 500 to the server 107', wherein a business

object routine then stores that information in each ofthe "Order Book" folders SF5-a, SF5-a',

etc., associated with respective parties Pl-Pn.

The orders in a party's "Order Book" folder SF5-a may be displayed in such a

manner to indicate the values ofthe two credit-denied flags. Preferably, this is accomplished

using Outlook 2000 (or later versions thereof) filtering and automatic formatting facilities.

For example, the order infoπnation (that includes a set "credit-denied" flag) may be visually

distinguished by presenting it in a predetermined, distinguishing color (e.g., red), or, in other

embodiments, that infomiation is not displayed at all, and is thereby filtered from the other

order information.

At some time after the performance of step A18'", it is assumed that a sub-

party, such as user UI', interacts with worknode 122 tlirough interface 122a to select the

"Order Book" folder SF5-a'(step A19'"); this step conesponds to step A8"'of Fig. 9c.

Thereafter, in step A20'"a fomi script 40 associated with the selected folder SF5-a' responds

by examining the orders 920 included in the folder SF5-a' to determine whether or not either

ofthe credit-denied flags are set. If so, and if the order selects an information item ofthe

displayed folder contents, the order's "Done" button is disabled when presented in an

electronic for, since the posted deal is not available to the party. The transmit button may be activated if the party enters a smaller quantity in field 302'. A negotiated soft match may

yield a price value within the party's credit limit. Control then passes to step A22'", where

further steps are then performed in the above-described manner, beginning from, e.g., step

A9'"of Fig. 9b (assuming that step A12'" was originally entered from step A6'"of Fig. 9b).

It should be noted that the "Automatic Credit-Based View Screening Sub-

Embodiment" of this invention is not limited to being employed only in the particular

embodiment described above, and also may be employed in other embodiments/sub-

embodiments described throughout this detailed description. For example, the above-

described screening/filtering techniques may be performed in other embodiments/sub-

embodiments ofthe invention, where information is copied from the "OrderBook" table 500

to the "Order Book" folders SF5-a, SF5-a', etc. Moreover, in other embodiments, only a

unilateral credit verification may be performed, base on information specifying the credit

worthiness of a particular party and/or associated sub-parties.

IV) REAL-TIME INFORMATION INTEGRATION EMBODIMENT

Still another aspect of this invention will now be described. In accordance

with this aspect ofthe mvention, users ofthe communication system 200' are able to view

dynamic data during the course of a trade negotiation. This aspect ofthe invention will be

described with reference to Fig. 10, which illustrates a teclmique 400 for delivering dynamic

data streams (i.e., more or less constantly changing/real-time information), such as news

and/or financial market trading information (e.g., Interest Rate Swap (IRS)) market

infoπnation, Foreign Exchange (FX) market infoπnation), etc. The technique for delivering dynamic data streams is also disclosed in co-

pending U.S. Patent Application No. 09/434,794, filed November 5, 1999, entitled "Method,

Apparatus And Program For Delivery And Display Of Information From Dynamic And

Static Data Sources, by Stephen J. Scimone et al., and to the Computer Program Appendix

incoφorated by reference therein, both of which are incoφorated by reference herein in their

entireties, as if fully set out herein.

In the prefened embodiment, data source 410 of Fig. 10 conesponds to

infonnation source 140 in Fig. lb. The data can be Reuter's Marketed price data (ASCII),

which has been converted from IDN's Market stream binary data via software consisting of,

in the prefened embodiment, Source Sink Library, resident at data source 410, and JOIST

and SFC software, resident on seiver 430. The Marketed data is then converted into an XML

data stream by a software module 420, shown in Fig. 10, also resident on server 430.

Data server 430, which preferably is a Windows 2000 service maintained by

the Provider of data source 410, is responsible for maintaining the connections to the user

information appliances, and for maintaining in a memory table a registry ofthe interests for

each user, so that the user receives only the data of interest to him. When an item from data

source 410 matches an item in the memory table, data server 430 transmits the new item to

the user. Data server 430 can be remote from the network that includes user information

appliance 600, or can be part of that network. For example, the server 430 may be coupled to

interface 190 in Fig. lb, or may be hosted with other services provided in either server 106' or

107' of Fig. lb. In the prefened embodiment, there is a TCP/IP remote connection between the

data server 430 and the interface 440 at user information appliance 600. Interface 440

functions to ensure that the client's registered information is obtained from server 430. The

received XML data is segmented by a standard Microsoft IE XML parser 450, and the root of

the parsed tree is passed to a Microsoft OLE^'DB (database) Simple Provider interface 470.

Both parser 450 and interface 470 are resident in the user information appliance 600.

A user may invoke the display of dynamic data by selecting a predetermined

item displayed on his display 601 (step 4005, Fig. 12). As but one example, to invoke the

display of information relating to the Interest Rate Swap (IRS) market, a user may select item

624' of a displayed window 623 (Fig. 1 lb). As another example, to invoke the display of

information relating to the Foreign Exchange (FX) market, a user may select item 625' ofthe

window 623 (Fig. 11a). In response to the perfoπnance of step 4005, a form script 624

responds by communicating with the OLE DB Simple Provider Interface 470 to request the

latest data for a type of infoπnation relating to the selected item (step 4010). The request is

propagated by OLE DB Simple Provider Interface 470 tlirough the interface 440 to the data

server 430, which then passes the request to the data source 410. When the data is provided

back to the form script 624, the routine 624 causes that information to be displayed on the

display 601 ofthe user infomiation appliance 600 (step 4020). An example of displayed

information relating to the FX market is identified by reference numeral 626' in Fig. 11a, and

an example of displayed infonnation relating to the IRS market is identified by reference

numeral 627' in Fig. 1 lb, although, as can be appreciated, information relating to other types

of markets may also be displayed, depending on which predetermined item is selected by the

user in step 4005. In accordance with a prefened embodiment of this invention, and as was

previously described, dynamic information also may be retrieved and inserted into

conesponding, predetermined fields of an electronic form. As an example, in step A9 of Fig.

4b, in response to user UI' selecting the information 47 (Fig. 3d) presented on display 122b,

the form script 40 communicates with the OLE DB Simple Provider Interface 470 in the

above-described manner to obtain latest cunency data, in addition to retrieving the

information 36 and 38 from the "Incoming Calls" folder SF4'. Also in that step, the form

script 40 inserts the obtained data into one or more ofthe conesponding fields 62 and 64 of

the deal form, depending on whether the "buy" field 18, "sell" field 20, or "2-way"

transaction field 22 ofthe call form 10 was previously selected by the user UI who originated

the transaction. The fonn 50, including the inserted data and inserted portions ofthe

information 36 and 38, is then displayed on the display 122b in the above-described manner.

V) ELECTRONIC SPREADSHEET INTEGRATION EMBODIMENTS

In one embodiment of this invention, the information is displayed in step 4020

within predetermined fields of an electronic spreadsheet. For example, in addition to

requesting the latest data from the interface 470 in step 4010, the form script 624 also

retrieves a predetennined electronic spreadsheet file 629 from memory 620 ofthe user

infoπnation appliance 600 (Fig. 10). Preferably, the electronic spreadsheet file 629 is a

spreadsheet (e.g., Microsoft Excel) component of Microsoft Office Web Components

(MOWC) 9.0.2710 (or later versions'thereof), although in other embodiments, other suitable

types of electronic spreadsheet programs may also be employed. Thereafter, in step 4020, in response to the user information appliance 600

receiving the data from the interface 470, the form script 624 inserts that data into

conesponding, predetermined information fields ofthe retrieved electronic spreadsheet 629,

and displays the spreadsheet, including the inserted data, on display 601 ofthe information

appliance 600.

In accordance with another embodiment ofthe invention, an electronic

spreadsheet also is employed in cases in which a user selects the multi-deal field 14 ofthe

electronic call form 10 (see, e.g., step A3 of Fig. 4a) during the course ofthe method

described above. This embodiment ofthe invention will now be described with reference to

the flow diagram shown in Fig. 13, which represents in further detail step A3 of Fig. 4a, as

perfonned in accordance with this embodiment ofthe invention.

In step A3 -a, it is assumed that, prior to entering information into the various

fields 12 and 24-28 ofthe electronic call form 10 in the above-described manner, the user UI

selects the multi-deal field 14 ofthe call fonn 10. The fonn script 40 associated with that

formlO then responds by retrieving the predetennined electronic spreadsheet file 629 from

the memory 2c ofthe worknode 120 (i.e., information appliance 600 in Fig. 10), and by then

causing the retrieved spreadsheet to be displayed on the display 120b (i.e., display 601 in Fig.

10), along with the call form 10 (or, in other embodiments, within a predetermined portion of

the call form 10), as shown in, for example, Fig. 14a (step A3-b), wherein reference numeral

624a represents the displayed spreadsheet. The spreadsheet 624a preferably includes a

plurality of rows 624b and columns 624c of infoπnation fields, wherein the fields of a first

one ofthe columns 24' are employed for including user-entered first cunency code rates, the fields of a second one ofthe columns 26' are employed for including user-entered second

cunency code rates, and the fields of a third one ofthe columns 28' are employed for

including user-entered information specifying a desired volume of a first cunency code

included in a conesponding one ofthe fields from column 24'. Additional columns also may

be employed in other embodiments.

Assuming that the user enters information into selected ones of those

infonnation fields, and thereafter selects the "transmit" item (A3-c), the control passes to step

A4 of Fig. 4a, where the method proceeds in the above-described manner. However, in this

embodiment, the information forwarded from the worknode 120 to the memory 107a in step

A4 also includes the electronic spreadsheet and the incoφorated transaction information

entered previously by the user UI, which are incoφorated in the form 10. Also, when the deal

form 50 is later displayed to user UI' during the performance ofthe method, the electronic

spreadsheet and the incoφorated transaction information are presented as part ofthe form. As

an example, Fig. 14b depicts a deal fonn 50' (which, in this example relates to an Interest

Rate Swap (IRS) market) that includes an electronic spreadsheet 629' having transaction

information included within fields ofthe spreadsheet 629'. The user UI ' may then select any

desired one of rows 629" ofthe spreadsheet 629', in which case the form script 40 associated

with that form 50' responds by retrieving the infoπnation (II) and (12) from that selected row

by depressing the Select button which invokes a form script that inserts the information into

conesponding fields FI and F2 ofthe fonn 51'. Thereafter, further procedures may be

perfonned in the manner described above for continuing the transaction negotiation. It should be noted that although the above-described embodiment ofthe

invention has been described in the context of being employed for use in performing a trade

of cunencies and electrical power-related instruments, the invention is not limited to being

employed only in such transactions. For example, it should also be readily apparent to one

skilled in the art how to adapt the prefened embodiments ofthe invention for use in

electronically trading any other types of property, goods, or services, including, but not

limited to, securities, commodities, works of art, etc.. Also, although the invention is

described above in the context of information defining finally confiπned transactions being

provided to a predetermined destination (e.g., a back office server) for ultimately causing the

transactions to be effected, the use of such a destination for ultimately effecting the

transactions is not considered to be gem ane to this invention. For example, in some

embodiments ofthe invention, such a destination need not be employed at all. Also, the

functionalities provided by this invention may be extended to provide back office functions.

While the present invention has been described in detail with reference to the

prefened embodiment thereof, many modifications and variations thereof will be readily

apparent to those skilled in the art. Accordingly, the scope ofthe invention is not to be

limited by the details ofthe prefened embodiment described above, but only by the terms of

the appended claims.

Claims

WHAT IS CLAIMED IS:

1. An electronic trading system, comprising:

a server computer including

first storage media for storing trading information and

first information management software, and

a first controller coupled to said first storage media, said first controller

operating under the control of said first infoπnation management software;

and

at least one infoπnation appliance including

second storage media storing second information

management software,

at least one user interface, and

a second controller bidirectionally coupled to said second storage media and

said at least one user interface, said second controller being in bidirectional

communication with said first controller of said server computer, said second

controller operating under the control of said second information management software for performing at least one of (a) interacting with said first controller

of said server computer to cause a first item of user-generated trading

information input through said at least one user interface to be communicated

to said first controller of said server computer and stored by said first

information management software in said first storage media of said server

computer, and (b) interacting with said first controller of said

seiver computer in response to receiving a user-generated instmction from said

at least one user interface to cause a second item of trading information to be

retrieved by said first information management software from said first storage

media of said server computer and communicated to a user through said at

least one user interface.

2. The electronic trading system as in claim 1, wherein the trading information in the

first storage media is organized in folders.

3. The electronic trading system as in claim 1, wherein said first information

management software is Microsoft Exchange.

4. The electronic trading system as in claim 3, wherein said second information

management software is Microsoft Outlook.

5. The electronic trading system as in claim 1, wherein the first storage media further

stores a first electronic form, and wherein said second infomiation management software is

adapted to request download of said first electronic form to said at least one infonnation

appliance to provide a form for input of said first item of user-generated trading information.

6. The electronic trading system as in claim 5, wherein the first storage media further

stores a second electronic form, and wherein said second information management software

is adapted to download said second electronic form to said at least one information appliance

to provide a form to communicate through said at least one user interface said second item of

trading information to a user.

7. The electronic trading system as in claim 5, wherein the first electronic form is a

customized Outlook contact fonn, and the second electronic form is a customized Outlook

contact fonn.

8. An electronic trading system, comprising

a server computer including

a first arithmetic and logic unit for executing program

instmctions; first storage media containing program instmctions comprising first

information management software for (a) receiving a first item of trading

information from a first information appliance, (b) sending a second item of

trading information relating to said first item of trading information to a

second information appliance, and (c) storing trading information associated

with said first and second information appliances;

a first information appliance in communication with

said server computer, said information appliance including

a second arithmetic and logic unit for executing program instmctions;

a user input interface for entering trading

information;

second storage media containing program instmctions

comprising second information management software for

transmitting said first item of trading infoπnation

to said server computer;

a second information appliance in communication with

said seiver computer, said infomiation appliance .

including a third arithmetic and logic unit for executing program

instmctions;

a user output interface for providing trading

information to a user;

third storage media containing program instmctions

comprising third information management software for

receiving said second item of trading information

from said server computer.

9. The electronic trading system as in claim 8, wherein the first storage media includes

folders for storing a plurality of items of trading information.

10. The electronic trading system as in claim 8, wherein the first infomiation management

software is Microsoft Exchange.

11. The electronic trading system as in claim 10, wherein the second information

management software is Microsoft Outlook, and the third infomiation management software is Microsoft Outlook.

12. The electronic trading system as in claim 8, wherein said second storage media and

said third storage media each contain chat program instmctions to permit communication

between a user at said first information appliance and a user at said second information

appliance.

13. The electronic trading system as in claim 12, wherein the chat program instractions

comprise a COM Add-In.

14. The electronic trading system as in claim 8, wherein said first storage media further

stores a plurality of electronic foπns, said second infonnation management software is

adapted to request download of a first of said electronic fonns to said first information

appliance to provide a fonn for input of said first item of trading infonnation, and said third

information management software is adapted to download a second of said electronic forms

to said second information appliance to provide a fomi to communicate tlirough said user

output interface said second item of trading infoimation.

15. An automated matching electronic trading system, comprising:

at least one server computer including

at least one arithmetic and logic unit for executing program instructions,

first storage media containing a folder and

program instmctions comprising (a) first information

management software for placing trading orders from

a plurality of information appliances in the folder

and (b) matching algorithm program instmctions for

comparing a trading order received from an information

appliance with trading orders previously placed in the folder;

a plurality of infonnation appliances for submitting

trading orders to the first storage media, each

information appliance including

a second arithmetic and logic unit for executing

program instmctions;

second storage media containing second information

management software for transmitting a trading

order to said server computer.

16. An automatic trading credit verification system, comprising: at least one server including

at least one arithmetic and logic unit for

executing program instractions,

first storage media including a plurality of folders,

each folder conesponding to one party of a plurality

of parties and containing credit information

specifying conditions under which the one party

will engage in a transaction with at least one

ofthe other ofthe plurality of parties,

said first storage media further including program

instmctions comprising (a) first information

management software for placing in each of

said plurality of folders credit infoπnation

received from the conesponding party and

(b) credit verification program instractions

for comparing a trading order received from

a trading party with credit infoπnation

received from another party and conesponding

to the trading party;

a plurality of information appliances for submitting trading orders and credit information to the first

storage media, each information appliance

conesponding to a party and including

a second arithmetic and logic unit for executing

program instractions;

second storage media containing second

information management software for transmitting

a trading order and an item of credit

information to said first storage media.

17. A method of conducting electronic trading, comprising using information

management software to (a) receive a first item of trading information from a first

infonnation appliance, (b) send a second item of trading information relating to said first item

of trading information to a second information appliance, and (c) store trading information

associated with said first information appliance and said second infonnation appliance in

storage media.

18. A computer-readable medium which stores computer-executable process steps for

execution on a computer, the process steps comprising matching algorithm program

instractions for comparing a trading order received from an information appliance with trading orders previously placed by information management software in a folder located on

storage media.

19. A method for communicating transaction-related information, comprising the steps of:

providing at least one storage item for use in conjunction with information

management software;

causing the information management software to store first infoπnation defining a

transaction proposal in the at least one storage item;

causing the information management software to retrieve the first information

defining the transaction proposal from the at least one storage item; and

causing the information management software to store second information defining a

further state ofthe transaction in the at least one storage item.

20. A method according to Claim 19, wherein the at least one storage item is at least one

electronic folder.

21. A method according to Claim 20 wherein the at least one electronic folder is provided

in a server memory of a communication network.

22. A method according to Claim 19, wherein at least one ofthe first and second

information includes an electronic form.

23. A method according to Claim 22, wherein the second information specifies that the

transaction proposal is accepted.

24. A method according to Claim 19, wherein prior to the step of causing the information

management software to store the first information, steps are performed of:

providing a user an electronic form having at least one editable infonnation field; and

entering the first infonnation into the at least one editable information field.