WO2000028487A2 - Distributed, high performance architecture for online investment services - Google Patents

Abstract

A distributed, high-powered computer architecture is provided for conducting global, online financial and informational transactions. The computer architecture includes four independent layers for ensuring a scalable, flexible system for processing customer transactions. A gateways services layer (14) is configured to provide secure communications with a plurality of customers using a plurality of different access devices. An application services layer (16) is connected to the gateways services layer and is configured to accept customer transaction requests and to present a formatted response to the customer via the gateways services layer. A business transactions layer (18) is connected to the application services layer and is configured to receive customer transaction requests, execute the requests according to predetermined business logic rules, and return results of the transaction to the application services layer for presentation to the customer. A resource layer (20) is connected to the business transactions layer and is configured to supply customer information and securities market access to the business transactions layer.

Description

DISTRIBUTED, HIGH PERFORMANCE ARCHITECTURE

FOR ONLINE INVESTMENT SERVICES

The present invention relates to a computer systems architecture for

implementing online investment services. More particularly, the invention concerns a

computer architecture employing independent layers of functionality to provide a high

performance investment transaction processor that is flexible to support new products and

services and scalable to support a rapidly increasing customer base.

Background

With the advent of electronic transaction technologies such as automatic

teller machines, point-of-sale services, and Internet shopping, consumers have begun to

demand mat more of the transactions which they previously conducted in person or by

mail, now be conducted electronically. For example, many people now manage their

financial investments through online investing services. For investors who are both

computer-literate and market-savy, online investing offers the ultimate in personal

investing because it allows the investor to be his or her own financial advisor and

securities broker. Furthermore, such investors expect their online investing service to be

implemented in state-of-the-art technologies.

For a leading-edge online investing service, the underlying computing

architecture is pivotal to its success. The computing architecture should be a solid

foundation for current business operations as well support the aggressive growth

anticipated in both the variety of services provided and the number of customers served.

The number of Internet users is rapidly expanding and customers' expectations for what online businesses will offer are constantly shifting. For example, personalized Internet

content, once considered highly innovative, is becoming an entry-level criteria for web

service/content providers.

While other organizations can mask a weak internal architecture to the

outside world, deficiencies in the technical infrastructure of an online investing service

are likely to be highly visible and quickly experienced by customers across the globe.

Moreover, die very nature of the business, online investing services, precludes tolerance

for poor execution or inaccurate information. Meeting the challenges of competing in the

online market demands a robust, flexible architecture and meeting the expectations of

customers exploring and consummating financial decisions with an online investing

system requires near flawless execution.

In spite of these factors, many online investing services are supported by

outdated technology. Given the quick pace of change in online markets, technical

approaches that once seemed the best ways or even the only ways to meet requirements

have become obstacles that limit business growth and impede customer service. Thus,

alternative technologies are needed to replace the antiquated systems and to set the stage

for future business initiatives.

Any alternative technology capable of meeting the requirements of a

leading-edge, online investing service must meet many criteria which can be classified

broadly as: scalability, reliability, flexibility, manageability, performance, acceptable cost

of operation, and long-term viability. Using conventional architecture, some of these

criteria can be difficult to achieve simultaneously. To be scalable, the system must be able to be expanded or reduced in size

to meet business requirements. Bottlenecks should be resolvable by adding more

hardware, memory or processing power; constraints should not be imposed by the

software. Specifically, one can gauge scalability by considering the ability to easily

adjust for the number of concurrent users, data storage requirements, network capacity,

and so forth.

A system is reliable if it performs consistently in both normal and adverse

conditions within the accepted operational cycle — 24 hours per day, 7 days per week. In

the event of hazards, peak traffic loads, or attacks, the system should appear to operate

smoothly to customers while allowing for intuitive, effective management and recovery

by the system operator. The system architecture should eliminate single points of failure.

To achieve flexibility, the system must include the capability to expediently

add new products and services in response to business needs. Designing computer code

as discrete, re-useable modules in addition to selecting products that support well-known

standards is essential to providing flexibility. Avoiding product customization when

integrating the components to the architecture also aids flexibility.

Leading-edge performance means that the system must execute customer

transactions expeditiously. The interval from the time the user enters a request to the

time a response is returned to the customer should be minimized. Overall, if customers

perceive slowness it should result from their connection speed and quality rather than any

inherent limitations of the online system architecture. Performance factors include the ability to quickly route HTTP traffic, handle SSL sessions, complete a transaction, and

return a third-party service.

A system is considered manageable if all non-trivial components contain

the instrumentation to be proactively managed by a common administration tool.

Additionally, responses to messages from nodes (e.g. SNMP traps) should be automated

and sophisticated. Finally, management traffic must not create a burden on the system

resources.

Considering alternative approaches and comparable systems, the total cost

of ownership of the selected technology should be profitable. The architecture should

allow the system operator to receive a favorable return on investment in the short term (2-

3 years). Furthermore, the cost per transaction should be competitive with other

organizations offering similar services.

Finally, the design of the system should be based on leading-edge yet

proven concepts and the system should be implemented with best of breed products. The

selected product vendors should have a strong commitment to continuing to evolve the

system's core components and should be financially stable. To ensure long-term

viability, the system operator should be able to add new products and remove old products with minimal effort in order to enhance the system.

While articulating the criteria of a leading-edge, online investing system is

straight-forward, developing such a system that is capable of linking a wide range of

access methods (e.g., computers, personal digital assistants, voice recognition, etc.) to a

diverse array of products or transactions can be difficult even for a small number of customers. When the system must also be capable of supporting hundreds or thousands

of customers simultaneously and without significant delays, the complexity of

conventional, monolithic systems becomes impractical if not unmanageable. Finally, if

the system must be implemented in the context of dynamic, global financial markets, and

capable of adapting to sudden business paradigm shifts, it becomes clear mat a novel

architecture is required.

Therefore, it is desirable to have a new computer architecture for online

investment services which meets or exceeds the criteria of scalability, reliability,

flexibility, manageability, performance, acceptable cost of operation, and long-term

viability.

Summary of the Invention

The present invention can be summarized as a high-powered, stateless

system for conducting online financial and informational transactions. The system

includes four independent layers to provide a scalable and flexible architecture. First, a

gateways services layer is configured to provide secure communications with a plurality

of customers using a plurality of different access devices. Second, an application

services layer is connected to the gateways services layer and is configured to accept

customer transaction requests and to present a formatted response to the customer via the

gateways services layer. Third, a business transactions layer is connected to the

application services layer and is configured to receive customer transaction requests,

execute the requests according to predetermined business logic rules, and return results of

the transaction to the application services layer for presentation to the customer. Fourth, a resource layer is connected to the business transactions layer and is configured to

supply customer information and securities market access to the business transactions

layer.

Brief Description of the Drawings

Fig. 1 is a schematic view of a distributed, high performance architecture

for online investment systems according to the present invention.

Fig. 2 is a schematic view of an alternative embodiment of the distributed,

high performance architecture in which two instances of the architecture are linked to

ensure transparent fail over.

Detailed Description

A high-powered, stateless system for conducting online financial and

informational transactions is shown generally at 10 in Fig. 1. The system is configured to

provide personal, online transactional services to a large number of subscribers or

customers accessing the system through any of a wide variety of access terminals 12.

System 10 includes a multi-tiered applications framework that employs technology layers

to support a wide variety of features and functions as well as to provide a high degree of

fault tolerance and fail-over. Although well suited for a wide range of transactional

services, the system is particularly effective in providing online securities trading. In

addition, the system's flexibility and adaptability allows a system operator to respond

quickly to business paradigm shifts.

The system includes a first layer 14, also referred to herein as a Gateways

Services layer, configured to support multiple interfaces and protocols as required by the various access terminals. The Gateways Services layer is connected to communicate

with a second layer 16, also referred to herein as an Application Services layer, and acts

as an interface between the access terminals and the Application Services layer. The

Application Services layer supports the customer's online trading session by accepting

transaction requests, communicating the requests to a third, or Business Transactions

layer 18 for execution, and relaying the results of the requests back to the customer via

the Gateways Services layer.

Business Transactions layer 18 accepts transaction requests from the

Application Services layer and executes the requests in accordance with predetermined

business logic rules. The Business Transactions layer is connected to access a fourth

layer 20, also referred to herein as a Resource layer. The Resource layer includes a

variety of databases, external data feeds, and electronic trading interfaces which are

accessed by the Business Transactions layer to execute and manage a customer's

transactions with product markets such as NYSE, NASDAQ, etc.

The multi-tiered architecture of the present invention results in a reliable,

scalable, flexible and manageable system for providing online trading services. The

relative independence of the various layers allows changes and enhancements to be made

in one layer without affecting or requiring changes to the remaining layers. Additionally,

the system is portable such that it can be implemented using a variety of standard

networking components as will be described in more detail herein below. The system's

portability ensures that it is independent of the availability of specific hardware and allows a system manager to take advantage of new hardware components developed after

the system is implemented.

Focusing more particularly on the access terminals, the system provides

customers with a diverse array of trading methods. One common type of access terminal

is the hypertext transfer protocol (HTTP) client, most commonly known as a web

browser. When a customer accesses the system via a web browser, the system is

configured to provide transaction information and menus in the form of dynamically

generated hypertext markup language (HTML) pages. The HTML pages provide a

graphical user interface (GUI) by which the customer can access market information,

access his or her accounts and place financial and/or informational transaction requests.

Other possible access terminals include but are not limited to the Interactive

Voice Recognition (TVR) system, Personal Digital Assistants (PDA's), WebTV clients,

and die Open Financial Exchange (OFX). The system is adaptable to changes in

technology and customer preferences because transactions are independent of the method

of access.

Depending on the type of access terminal being used, the customer can

access the system using a variety of communications channels. Web browsers, PDA's,

OFX and WebTV clients typically use modems connected to plain old telephone (POTS)

or ISDN lines to access the system directly or via the Internet and the World Wide Web

(WWW). The IVR system uses voice recognition or touch tone inputs to access the

system. Regardless of the type of access terminal employed, customers access the

system by initiating a communications link to the Gateways Services layer via the

selected access terminal. The Gateways Services layer includes the hardware and

software components necessary for communicating with the various access terminals.

Further, the Gateways Services layer should be capable of supporting secure

communications protocols such as Secure Sockets Layer (SSL).

In one preferred embodiment in which the customer accesses the system

using a web browser, the Gateways Services layer includes a computer network firewall

22, a resonate local dispatcher 24, and one or more web servers 26. Firewall 22

comprises a combination of hardware and software configured to protect the system from

hostile electronic infiltration. The firewall is a standard component of network systems

and is well known in the art. Resonate local dispatcher 24 is also a standard network

systems component configured to route network traffic among the available web servers.

Web server 26 is preferably configured to manage high-volume,

commercial-grade web sites. The web server is capable of handling HTTP requests from

the access terminal as well as negotiating SSL sessions to protect information transferred

between the access terminal and the system over potentially hostile public networks.

The web server is selected to provide reliable and predictable performance

as well as a high degree of scalability to enable the system to grow with an expanding

customer base. One suitable web server is the Netscape Enterprise Server (NES),

manufactured by Netscape Communications Corp., of Mountain View, California. In

addition to providing HTTP and SSL capability, NES also supports simple network management protocol (SNMP) and provides both GUI and text-based management

options. Additionally, NES utilizes well-known application program interfaces (API) and

supports multiple software development approaches, providing the flexibility and ease of

use required to create new services and modify existing applications.

While the Gateways Services layer has been described as including an NES

web server, it will be appreciated by those skilled in the art that there are many other

suitable web servers and that the system is not dependent on the continued availability or

suitability of any particular product. Furthermore, as new types of access terminals are

developed and adopted by customers, the system is easily adaptable to support these new

devices by simply adding the appropriate components in the Gateways Services layer to

interface between the access terminals and the Application Services layer. In any event,

the Gateways Services layer functions to reliably and transparently link the customer with

d e Application Services layer, regardless of die type of access terminal the customer is

using, by translating communications from the access terminal into a format recognizable

by the Application Services layer, and vice versa.

As described in more detail below, the Application Services layer provides

the customer services including session management, state management, interface

functions such as personalized web pages, transaction management, and other customer

functions. The Application Services layer includes one or more application servers 28.

Application logic programmed into the application servers provides the system's

communication and transaction capabilities. The application logic maintains the customer

session and transaction state, performs all customer queries and responses, takes orders and ultimately delivers confirmations. Application logic also maintains order data

integrity by ensuring the underlying Business Transactions layer captures and receives all

required information.

For a customer using a web browser, the application servers dynamically

generate HTML pages by receiving data from the Business Transactions layer and

placing it into pre-defined HTML templates mat are stored and maintained by the

application servers. The template then becomes a complete web page that is delivered to

the user via the web server in the Gateways Services layer.

The HTML templates stored on the application servers provide the

framework and delivery for dynamic web content by allowing the system operator to

create pre-defined pages with areas where customer data will complete the content The

application servers offer the runtime template engines and communication services that

take the user data, match it to the proper areas of the HTML template, and then send the

resulting web page to the web server for delivery. Preferably, the application servers are

also configured to provide customized web pages as requested by individual customers.

Thus, customers are, in many respects, able to define how the system presents

information to them.

Additionally, it will be appreciated by those skilled in the art that since the

Application Services layer abstracts the state and session information from the Business

Transactions layer, the application logic is responsible for collecting and sending all

information required to perform a business transaction to the business services. The

Application Services layer also provides system customers with session management for maintaining state (i.e. a persistent login) throughout a transaction session by monitoring

all transactions during a session and updating a database of customer-specific session

information. Reading the information in the session database, the system is able to

monitor die progression, or state, of the customer's session.

In one preferred embodiment, two application servers support each web

server. One of the application servers functions as a primary server 28a while the other

functions as a secondary server 28b. The primary server maintains the user session

information, performs load balancing across the two servers and handles user requests.

The secondary server keeps a continuously updated copy, or 'hot replica,' of the user

session information and serves user requests as directed by the primary server. Once a

customer completes a successful login, session information is immediately backed-up at

the secondary server. If the primary server goes down, the secondary server becomes the

primary server and keeps the user sessions alive without disruption. Thus, the system

ensures fail-over by simultaneously running a secondary server configured to assume the

function of the primary server in the event d e primary server fails.

In a configuration using multiple application servers, the first server that

comes online is designated the primary server. The next one is designated the secondary

server. All secondary application servers periodically broadcast load information to the

primary server in order to balance the customer requests across the Application Services

layer.

The Application Services layer accepts information and transactional

requests from the customer and passes those requests on to the Business Transactions layer. Additionally, the Application Services layer receives information returned by the

Business Transactions layer in response to the requests. Preferably, the Apphcation

Services layer has no connection to the resources necessary to execute the request.

Rather, d e Apphcation Services layer includes a menu of information and transactional

requests executable by the Business Transactions layer. The Application Services layer

offers the menu to the customer and forwards the customer's requests to the Business

Transactions layer. Additionally, the Application Services layer receives responses from

the Business Transactions layer and presents those responses to the customer in a format

compatible with the access terminal.

As indicated by the discussion above, the Application Services layer is

independent of the types of information and/or transactions supported by the Business

Transactions layer. Thus, while the system has been described in the context of an online

securities trading service, the system could easily be adapted to provide other

transactions. Thus, for example, if the Business Transactions layer is configured to

execute airline reservations, the only change needed to the Apphcation Services layer is

the menu of allowable transactions and possibly the HTML templates.

Furthermore, the Apphcation Services layer is independent of the resources

accessed by the Business Transactions layer to execute customer requests. Thus, for

example, if the system operator elects to replace the vendor providing real-time stock

quotes, only the Business Transactions layer needs to be modified since the Apphcation

Services layer is abstracted from the mechanism by which stock quotes are generated. It will be appreciated by those of skill in the art that the independent

configuration of the Application Services layer provides maximum scalability and

flexibility for the system as a whole. The system is made scalable because new

application servers can be added to meet increasing customer loads. The system is

flexible because the menu of available information and transactions can be modified to

meet customer demand without redesigning all aspects of the system.

The Application Services layer may be implemented on any application

server configured to: a) guide the creation of and manage HTML templates; b) generate

data-driven, dynamic web content from the pre-defined HTML templates; c) manage user

sessions and maintain session state; and d) provide basic load-balancing and fail-over

capabilities. One such apphcation server is the Netscape Apphcation Server (NAS)

manufactured by Netscape Communications Corp., of Mountain View, California.

Preferably, die application servers also include interface software for integrating NAS

with the Business Transactions layer and an "Apphcation Builder" graphical interactive

development environment (IDE) for rapid apphcation development.

While the Application Services layer has been described herein as

implemented on Netscape Apphcation Servers, there are several other standard

apphcation servers well known in the art which are also suitable. In any event, the

Application Services layer functions to simultaneously manage a large number of

customer sessions and to translate customer informational and/or transactional requests to

a standard format recognized by the Business Transactions layer and to present responses from the Business Transactions layer to the customer in a dynamic and customizable

fashion.

The Application Services layer and the Business Transactions layer are

operatively connected in a client/server relationship. The Application Services layer,

acting as a client, makes informational or transactional requests to the Business

Transactions layer. The Business Transactions layer, acting as a server, executes those

requests and responds with the results of die request. Thus, the Business Transactions

layer defines the system's core functionality.

The Business Transactions layer implements the system's allowable

transactions on one or more transaction servers 30 running business logic routines

developed by the system operator. Unlike the Application Services layer, the Business

Transactions layer preferably is uninvolved in die duties of maintaining the transaction

state. The apphcation logic of the Apphcation Services layer abstracts the transaction

concept by translating all user requests into "atomic" service calls. With atomic service

calls, either all operations required to execute the request are completed, or none are.

Thus, the Business Transactions layer is "stateless."

Because the Business Transactions layer is stateless it does not know if a

user has logged in, what web page the user currently is accessing or what transaction a

user is trying to perform. The Business Transactions layer simply provides high-

performance, basic transactions based on requests and responses from the Application

Services layer. The Application Services layer, on the other hand, typically has no

knowledge of how a transaction is performed or how the data is managed. This architecture encapsulates the business logic from the application logic,

making the overall architecture highly flexible. If the rapidly changing market forces a

change in how business services are created or new services need to be added, the

Apphcation Services layer is not impacted. The existing transactions can be completely

redesigned at the Business Transactions layer as long as they conform to the existing

interface between the Apphcation Services layer and the Business Transactions layer.

The new transactions only need to inform the Apphcation Services layer of the required

protocol for accessing the new transactions.

The business logic also includes the system operator's business rales for

allowable transactions. For example, if a particular customer places an order to buy

stock, the business logic rules determine whether the customer is authorized to place such

an order and whether the customer has sufficient account funds or credit to cover he

purchase. Similarly, if a particular customer places an order to sell stock, die business

logic rules determine whether the customer owns the stock before allowing the

transaction to proceed.

In one preferred embodiment, the Business Transactions layer is

implemented on the TUXEDO transactional server system, manufactured by BEA

Systems, Inc. of San Jose, California. The TUXEDO server executes the core set of

business logic routines that define the system's basic transactions, or services, such as

making a trade or requesting a quote.

Once defined, the business logic routines make up the allowable set of

services offered to the Application Services client for the purpose of processing the data and returning desired information products back to requesting customer applications.

Preferably, the Business Transactions layer also includes BEA System's Java interface

("JOLT") which allows access to TUXEDO servers via standard Java calls originating from the Apphcation Services layer.

TUXEDO service chents (i.e., apphcation servers 28) connect directly to a

bulletin board (not shown) rather than to the TUXEDO servers, thereby improving

system performance. The service chents do not need to know server specifics and leave

the server load and availability management to the bulletin board. The bulletin board

contains a directory of transactions available that maps transaction names to servers

allowing chents to be unaware of server identity. This provides a transparent and flexible

system that masks TUXEDO chents from changes in server configurations. Additionally,

there may be a plurality of bulletin boards, each serving one or more transaction server.

The application servers translate customer requests into business logic

service calls. The service calls are placed on the bulletin board which conveys the

service call to a transaction server. In a multi-bulletin board system, a Distinguished

Bulletin Board Liaison (DBBL) (not shown) receives service calls from the apphcation

servers and forwards the service calls to one of the bulletin boards. The DBBL is an

administrative server that runs on a single host computer and manages the distribution of

the bulletin boards as well as updates to the bulletin boards. In any event, the primary

transaction server connected to the recipient bulletin board will remove the requests and

send them to the least busy transaction servers. A TUXEDO transaction server is configured to execute a configurable set

of transactions. Transactions and servers can be replicated easily and dynamically by

adding instances to support a high transaction load. If a server goes down, other

TUXEDO servers initiate additional services to handle the additional volume while

masking these load management activities from the customer. The result is a scalable

system having an underlying complexity that is completely transparent to the user.

Both TUXEDO and JOLT provide SNMP support in addition to a GUI

administrative interface. Development of TUXEDO services, and consequendy the

system's business logic, is done in the C programming language. Given C's widespread

acceptance and standardization, the code is portable to another operating system should

the need arise.

The Business Services layer has been described herein as implemented on a

TUXEDO transactional server system which is well known in the art as an established

product used in many high volume, high reliability applications. ^' Nevertheless, the

system is not dependent on a particular transaction server and can be implemented on

several competing products well known in the art.

In any event, the transaction servers use embedded Structured Query

Language (SQL) to interact with the Resource layer. Further, TUXEDO can perform

near simultaneous updates to different databases distributed across the Resource layer.

TUXEDO's Distributed Transaction Processing (DTP) capability allows for atomic

transactions by supervising a two-phase commit protocol to ensure that transaction

commits and rollbacks are properly handled. Thus, TUXEDO checks to make sure all operations of a transaction will be successful before committing to the transaction and

writing changes to the databases. If one or more operations will fail, TUXEDO rolls

back the transaction so that none of the operations are performed.

The Resource layer includes one or more database systems 32 which

incorporate dedicated database servers and database tables (not shown). Preferably,

access to a particular database system is restricted to the servers that exist within that

particular database. Thus, servers from one database system are not allowed access to

other database systems. However, a server on one database can request information from

a server on another database by initiating a database call via TUXEDO. Each server

accesses a separate set of tables within the database system where it exists and does not

access die tables accessed by other servers. Database joins (one of the most expensive

database operations) are only performed by servers on tables that the individual servers

can access. Joins across servers and database systems are preferably not required or

allowed.

Preferably, the databases consist of small databases, equivalent to basic

business objects, such as account, portfolio and user. This approach ensures a scalable

and highly available system since large databases take significantly longer to recover and

by sheer size have reduced scalability. By removing the business logic from the

databases to the Business Transactions layer, the maintainability of the resulting

databases and the business logic is increased. Thus, if modifications need to be made to

the business logic, they would be made exclusively at the Business Transactions layer

without changing the design or configuration of the Resource layer. In any event, the databases store the information used by the Business

Transactions layer to execute customer requests. Thus, for example, databases may

contain information regarding a customer's name, password, address, portfolio, account

balance, transaction history, etc. The Business Transactions layer requests information

from the appropriate database as needed to execute a particular request. The Business

Transactions layer also sends new data to the appropriate databases for storage.

The databases of the Resource layer are standard systems well known in die

art. Suitable products include those manufactured by Sybase, Inc. of Emeryville,

California, and Oracle Corp. of Redwood Shores, California. However, the system is not

dependent on a particular database system and can be implemented on a variety of

products well known in the art.

In one preferred embodiment, the Resource layer also includes external data

sources (not shown) such as news feeds and quote services, as well as transactional

interfaces, or access links, to product markets such as NYSE, NASDAQ, etc. The

Business Transactions layer executes requests by accessing the appropriate Resource

layer component, submitting the request and returning the results to the Apphcation

Services layer for presentation to the customer. Thus, the system can provide dynamic

informational and transactional services to a large number of dispersed users.

Referring now to Fig. 2, an alternative embodiment of the system is shown

which offers increased redundancy and fail-over. As shown in Fig. 2, a plurahty of

instances of the system can be linked over remote data centers. This alternative

embodiment of the system includes a Resonate Global Dispatcher 34 to intercept all customer access requests and route them to one of two local dispatchers 36 based on the

proximity of the incoming request. Each data center has a Resonate Local Dispatcher 36

that performs load balancing (round robin) in directing customer sessions to one of die

web servers. The databases include a replication server 38 that supports complete

asynchronous, bi-directional replication between two data centers.

The remainder of the architecture in this alternative embodiment is similar

to that described above. The web servers provide basic communications services and are

used to serve dynamically generated HTML pages from the Apphcation Services layer.

All customer actions and requests trigger processes at the apphcation servers and result in

dynamically created web content based on information received from the Business

Transactions layer. In the event that either instance of the system fails, the other instance

assumes all sessions, thus providing fail-over which is invisible to the customers.

The various embodiments of the invention as described above disclose a

distributed, high performance computer architecture for an online investment service.

The clean partitioning of operations and services into distinct layers within the high

performance architecture allows the system operator to isolate and manage changes

introduced to the environment with minimum effort and disruption. For example,

comprehensive changes can be made to the presentation of web content in the

Apphcation Services layer without having to modify the Business Transactions layer or

the Resource layer. Furthermore, with programming discipline, the strict separation of

services can result in an environment that facilitates the production of focused, reusable

computer code at each layer. In addition, identifying standard protocols and adopting common interface definitions between layers assists the efforts to build an environment

that is easily maintained. By adopting the distributed computing approach with control

over service partitioning, code design, and service interfaces, the high performance

architecture enables a leading-edge, online investment service to achieve its goals of

scalabiUty, rehabihty, flexibihty, manageability, performance, acceptable cost of

operation, and long-term viability.

While the invention has been disclosed in its preferred form, the specific

embodiments thereof as disclosed and illustrated herein are not to be considered in a

limiting sense as numerous variations are possible. Applicant regards the subject matter

of his invention to include all novel and non-obvious combinations and subcombinations

of the various elements, features, functions and/or properties disclosed herein. No single

feature, function, element or property of the disclosed embodiments is essential. The

following claims define certain combinations and subcombinations which are regarded as

novel and non-obvious. Other combinations and subcombinations of features, functions,

elements and/or properties may be claimed through amendment of the present claims or

presentation of new claims in this or a related application. Such claims, whether they are

broader, narrower or equal in scope to the original claims, are also regarded as included

within the subject matter of applicant's invention.

Claims

CLAIMS:

1. A distributed, high-powered, computer architecture for conducting

global, online financial and informational transactions, the computer architecture

comprising:

a flexible gateways services layer configured to provide secure

communications with a plurahty of customers, where the customers simultaneously

access the architecture using access devices, at least some of the access devices being

Internet browsers;

a scalable apphcation services layer connected to the gateways services

layer, and configured to accept customer transaction requests from the gateways services

layer and, when the transactions have been executed, to present a formatted response to

the customer via the gateways services layer, where one of the response formats is a

personalized web page;

a stateless business transactions layer connected to the application services

layer, and configured to receive customer transaction requests and to execute the requests

according to predetermined business logic rules and to return results of the transaction to

the apphcation services layer for presentation to the customer; and

a secure resource layer connected to the business transactions layer, and

including a database for storing customer information and an electronic interface to a

national securities market, where the resource layer is configured to supply customer

information and market access to the business transactions layer.

2. A system for executing online securities transactions, the system

comprising:

a first layer configured to communicate with a plurality of Internet

browsers accessing the system during a session, the first layer including

a computer network firewall configured to protect the system from

electronic infiltration,

a router configured to route communications between the first layer

and the Internet browsers, and

a web server configured to serve HTML pages;

a second layer configured to receive transaction requests from the Internet

browsers via the first layer and to generate responses in the form of pre-defined HTML

pages, the second layer including at least one apphcation server connected to the web

server;

a third layer configured to execute transaction requests independent of

session state, the third layer including

an electronic bulletin board connected to the apphcation server,

where the application server is configured to place transaction requests on

the bulletin board and to retrieve transaction results from the bulletin board,

and

a transaction server connected to the bulletin board and configured

to retrieve transaction requests from the bulletin board and to execute the transaction requests and to place results of the transaction request on the

bulletin board for retrieval by the apphcation server; and

a fourth layer connected to the third layer and configured to provide

information and market access to the third layer, the fourth layer including

a database of customer information configured to provide stored

customer information to the transaction server and to store customer

information received from the transaction server, and

an electronic interface to a securities market, where the transaction

server is configured to access the interface and submit the transaction

request to the securities market for execution.