Financial portfolio management system and method

A financial portfolio management system operable in a network environment can be configured to gather financial information from a plurality of sources over an electronic network and intelligently aggregate the information into a financial portfolio viewable by a client. The client can determine which accounts should be included in the portfolio. The system uses web crawling, parsing, or spidering technology to update the portfolio information. The system provides one platform that conveys financial information from a variety of accounts held at several different financial institutions.

FIELD OF THE INVENTION

The present invention relates generally to data gathering and management using communication networks, such as, the Internet. More particularly, an exemplary embodiment of the present invention relates to a system for and method of managing financial portfolios over a communication network.

BACKGROUND OF THE INVENTION

The tremendous growth of technology has positively affected the growth of financial markets. For example, technologies, such as, communication systems and networks have enabled investors to access a veritable plethora of information and carry out a variety of transactions involving financial markets. Such financial information can be gathered, distributed, and acted upon much faster and more efficiently than ever before. Prior to communication systems and networks, such as, the Internet, mechanisms for gathering and consolidating information from financial institutions were slow and inefficient.

Even today, financial institutions do not use a single standard interface, data format, or communication protocol to provide and exchange financial data on-line. Investors who want a single source of portfolio information have to move all of their assets to a single large investment industry vendor. However, such large vendors may not necessarily offer simple, easy access and a single source for financial information. Furthermore, despite the availability of “one-shop” institutions, many investors do not want to use a single institution because diversification across many institutions allows investors to get the “best” offerings from a variety of vendors.

Thus, as the marketplace shifts toward greater control by the self-directed investor, there is a need to provide financial vendors with tools and services that attract and retain investors. Further, there is a need for vendors to provide investors with the ability to automatically gather financial information from any number of financial institutions. Even further, there is a need for investor-oriented portfolio data consolidation.

Heretofore, conventional computer applications have been commercially available which provide what can be called either desktop financial packages or financial statement consolidators. For example, desktop financial packages, such as, QUICKEN sold by Intuit, Inc. of Mountain View, Calif., and MONEY or MSN INVESTOR, both sold by Microsoft Corporation of Redmond, Wash., allow users to perform calculations on financial information and present the financial information and any calculation results. However, conventional desktop financial packages are limited to only downloading information from direct data connections with individual remote locations, such as, an individual financial institution. Further, such desktop financial packages only handle specific data formats and do little, if anything, to relate downloaded financial information.

As another example, financial statement consolidators, such as Yodlee, Inc. of Redwood City, Calif., and GreenTrack Investments of New Rochelle, N.Y., gather information about accounts and re-present that information as if the financial institutions had issued a common statement. However, such consolidators do not manipulate the information because it all has a common format before it is gathered. The financial information is only represented.

Thus, there is a need for a financial portfolio management system which provides access to financial information from a variety of unrelated financial sources. Further, there is a need to normalize and integrate financial information from various financial sources as to provide meaningful and accurate information. Even further, there is a need to aggregate financial information in a way that provides relationships among the financial information.

SUMMARY OF THE INVENTION

An exemplary embodiment is related to a financial portfolio management computer-implemented method for providing access to financial information of customers of financial institutions. The financial information can originate from financial sources including a number of financial institutions. This method can include the steps of gathering financial information associated with a client from the financial sources, normalizing the financial information from the financial sources into a single normalized data format, aggregating the financial information into a financial portfolio, and conveying information associated with the financial portfolio to the client. The financial sources can include at least one financial institution and the financial information is stored in at least one data format.

Another exemplary embodiment is related to a financial portfolio management system operable in a network environment. This system can include means for gathering client-specific electronic financial information from sources over an electronic network, means for normalizing the client-specific financial information into a single normalized data format, means for intelligently aggregating the client-specific financial information into a financial portfolio, and means for conveying information associated with the financial portfolio to the client. The financial information is stored in at least one of a plurality of data formats, and the financial information is associated with a client.

Another exemplary embodiment is related to a user interface configured to allow a client to view and modify financial portfolio information gathered from a plurality of financial sources. The plurality of financial sources can include a number of unrelated financial institutions. The user interface can include means for presenting financial account information of a client where the financial account information is associated with at least one of a plurality of financial institutions, means for presenting information for at least one of a plurality of financial securities, and means for presenting a value from the financial account information with at least one of a plurality of financial institutions.

Another exemplary embodiment is related to a method of enabling access to financial information over a network. This method can include using a first processing system to maintain a financial information processing unit, receiving a signal for invoking the financial information processing unit from a remote processing system via a network, and using the first processing system to operate the financial information processing unit in response to the signal. The financial information processing unit receives and processes requests for financial information associated with a number of unrelated financial institutions. The signal for invoking the financial information processing unit is transmitted from the remote processing system in response to a selection of a hypermedia link.

Another exemplary embodiment relates to a method of enabling access to financial information over a network in a local processing system. The method includes the steps of receiving a request from a first remote processing system via a network and, in response to receiving the request, transmitting to the first remote processing system over the network information for enabling the first remote processing system to output a financial information interface to a user. The financial information interface includes financial information for a number of financial institutions and is configured to enable the user to request specific financial information for a financial institution. The request is generated by the first remote processing system according to a hypermedia link provided to the first remote processing system from a separate processing system on the network.

Another exemplary embodiment relates to a processing system including a central processing unit (CPU) and a storage device coupled to a processor and having stored there information for configuring the CPU. The CPU can be configured to maintain a financial information processing unit corresponding to a single client and financial institutions maintaining accounts for the client. This financial information processing unit is configured to provide a user interface for enabling the client to submit requests for information on financial information of the financial institutions and configured to receive and process the requests. The CPU can also be configured to receive a request for invoking the financial information processing unit from a remote processing system via a network. This request is transmitted from the remote processing system in response to a selection of a hypertext link by the user. The CPU can further be configured to operate the financial information processing unit in response to the request.

Another exemplary embodiment relates to an apparatus for enabling access to financial information from a plurality of unrelated financial institutions over a network. This apparatus can include means for receiving a signal from a remote processing system via the network. This signal is transmitted from the remote processing system in response to a selection of a hypermedia link by a client. The hypermedia link can be provided by a web site of a financial institution and can specify a financial information aggregator. The apparatus can also include means for invoking a financial information processing unit in a local processing system in response to the signal. The means for invoking can include providing information for generating a user interface for access to financial information from the financial information aggregator. The financial information processing unit is configured to receive and process requests for financial information.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

A system for and method of managing financial portfolio information over a communication network are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be evident, however, to one skilled in the art that the exemplary embodiments may be practiced without these specific details. In other instances, structures and devices are shown in block diagram form in order to facilitate description of the exemplary embodiments.

In one embodiment, a computer system is used which has a central processing unit (CPU) that executes sequences of instructions contained in a memory. More specifically, execution of the sequences of instructions causes the CPU to perform steps, which are described below. The instructions may be loaded into a random access memory (RAM) for execution by the CPU from a read-only memory (ROM), a mass storage device, or some other persistent storage. In other embodiments, hardwired circuitry may be used in place of, or in combination with, software instructions to implement the functions described. Thus, the embodiments described herein are not limited to any specific combination of hardware circuitry and software, nor to any particular source for the instructions executed by the computer system.

FIG. 1illustrates a connection between a portfolio manager10and a network20. Portfolio manager10provides access to financial information available via network20. In an exemplary embodiment, network20is the Internet, a worldwide network of computer networks that use various protocols to facilitate data transmission and exchange. Network20can use a protocol, such as, the TCP/IP network protocol or the DECnet, X.25, and UDP protocols. In alternative embodiments, network20is any type of network, such as, a virtual private network (VPN), an Ethernet, or a Netware network. Further, network20can include a configuration, such as, a wide area network (WAN) or a local area network (LAN). Network20preferably provides communication with Hypertext Markup Language (HTML) Web pages30and40. Web pages30and40include a variety of data on a variety of Web servers. Network20also provides communication with a communication network portal50which couples computers52and54and a service56including a database58to network20. Service56is any type of company, content or service provider with a connection to network20. Database58is a storage medium for data and may be an optical, magnetic, or any other suitable storage medium.

Generally, portfolio manager10can be implemented using a computer server configured by software. Preferably, the server includes read/write memory, such as, disc drives and other storage. A customer or client can access portfolio manager10via a web page30or40which is conveyed to the client at computer52or54. Computers52or54can be any type of computing device, including work stations, laptops, notebooks, personal digital assistants (PDAs), cell phones, beepers, or other equipment capable of communication with network20. In another embodiment, portfolio manager10can be accessed via telephones, such as, a cell phone12or a standard telephone14. Other user interface platforms may also be provided for using portfolio manager10. Such user interface platforms include, for example, WAP (wireless application protocol) and web interfaces.

Advantageously, portfolio manager10provides a portfolio management service that draws investors or their representatives to web sites of financial service vendors, such as, asset managers, brokerage firms, information portals, and research firms. Portfolio manager10enables investors or their representatives to work with data from all on-line accounts within a single managed software application. Further, portfolio manager10benefits financial service vendors by providing needed comprehensive financial planning and analysis tools to web sites of financial service vendors. These added tools result in greater attraction and retention of investors and provides a basis for which investors will frequent the web site of a vendor.

In an exemplary embodiment, portfolio manager10is embedded in the web site of a financial vendor. As such, portfolio manager10can help attract and retain investors to the web site of the financial vendor, significantly increasing the frequency, duration, and quality of visits by the investor to the web site.

In an exemplary embodiment, portfolio manager10employs web crawling and parsing technology to obtain data from other web sites and automatically updates portfolios on a daily or more frequent basis. Portfolio manager10gathers information from a variety of institutions, whether or not those institutions support a standard data format. Such information is encrypted and securely stored at a hosting facility of portfolio manager10. Advantageously, the parsing technology permits portfolio manager10to support a variety of aggregation needs without special arrangements or prior approval from financial vendors.

In an exemplary embodiment, portfolio manager10includes an interface implemented as a JAVA applet. The applet provides quick delivery of information to the client and no loss of context when switching between data views. The applet is also designed to accommodate vendor web site color schemes and branding. The applet can also be configured with hypertext links to vendor tools/web sites and can also be configured to pass security, position, account, and portfolio information to the application or page at the other end of the hypertext link, integrating the applications and allowing them to cooperate.

Portfolio manager10can include a sophisticated web crawler that gathers account data from financial institutions by parsing data from financial institutions, including data in formats, such as, Hypertext Markup Language (HTML), Open Financial Exchange (OFX), Quicken Interchanged Format (QIF), and ASCII files having tab- or comma-delimited values (e.g., a format suitable for importing into spreadsheet applications). Portfolio manager10can also directly connect to data servers, such as OFX servers and back-office accounting systems, without relying on web crawling or similar techniques.

FIG. 2illustrates a general functional block diagram200of portfolio manager10(described with reference toFIG. 1), in accordance with another exemplary embodiment. As shown in diagram200, data network210is communicatively connected to a financial information gatherer220. Financial information gatherer220can be a computer program configured to automatically retrieve financial information over network20. Alternatively, financial information gatherer220can be a person who receives paper statements or views a web site and transcribes the data.

Financial information gatherer220receives financial information from any of a variety of financial institutions. For example, financial institutions can include credit unions, banking institutions, stock exchanges, portfolio managing companies, or any of a variety of other institutions which may provide a source for financial information. In an exemplary embodiment, financial information from different financial institutions can be available in different data formats. Different data formats means that financial information may be stored in HTML, QIF, or other data structure formats.

Financial information gatherer220can obtain a variety of different data or information from different account types and in a variety of different file transfer formats. Table 1 below provides example financial sources and corresponding example account types, data, and file transfer formats.

Financial information gatherer220communicates financial information to a financial information normalizer230. Financial information normalizer230receives raw financial information in a variety of different formats and converts the raw financial information into a normalized format. A normalized format is one which financial information from different sources is nevertheless consistent.

By way of example, as an exchange standard, the OFX data format defines how the “total” for a buy or sell transaction is identified, but it imposes no limits on the amount itself (e.g., is that total positive or negative). Similar situations exist with balances and with transaction identification. For instance, OFX defines a means to report balances, but does not require that the actual cash in an account be identified or reported in any specific way. Further, OFX defines a way for transactions to be given unique identifiers, but does not require that the financial institution use the same identifier for the transaction each time the transaction is retrieved. The OFX scope is also limited to the retail banking and retail asset management arenas. OFX makes no provision for more sophisticated financial issues, such as, position cost basis, tax lot identification, or the division between principal and income portions of a trust. Furthermore, even where OFX is well-defined, actual usage may deviate from OFX guidelines. Advantageously, portfolio manager10can work with such deviations to normalize and integrate all available financial data.

Normalization by financial information normalizer230takes elements of the raw data and assigns them to appropriate places or “positions” in a data model. This normalization process largely “standardizes” the non-standard formats, while also addresses some of the issues inherent in the standard formats.

Financial information normalizer230communicates the normalized financial information to a financial portfolio integrator240. Financial portfolio integrator240collects financial information associated with a client into a portfolio. A plurality of financial portfolios can be provided. Such portfolios can include security holdings, savings and checking information, mutual funds, and other financial data. Financial portfolio integrator240can communicate a portfolio to a financial portfolio presenter250for conveyance to the client. For example, the portfolio can be conveyed to the client via displays, such as, the displays described with reference toFIGS. 6-15.

In an exemplary embodiment, financial portfolio integrator240uses a series of heuristics and algorithms to evaluate the financial data, respond to inconsistencies and gaps, and combine that data with other sources of information (e.g., third-party data sources, previously retrieved information, and user-supplied/manual input) to produce a complete data picture. Preferably, the integration process learns over time, and is adapted to the idiosyncrasies of new financial institution data sources as they are brought on board.

Advantageously, financial portfolio integrator240processes data into richer, more consistent formats. Such integration can involve interpretation of free-form data to answer questions, such as, to what instrument does the data refer; what kind of activity does it represent; and what are the relevant values? Integration can also involve reconciliation, answering questions, such as, is this “real” account information or an error; has this information been seen before; and how does this relate to everything else? Integration can involve adjustments, answering questions, such as, what are the implications for other positions; and what are the implications for cash flows?

Financial portfolio integrator240decides how normalized data fits into the data model of portfolio manager10. For example, over18terms are used to indicate a “buy” transaction. These can include “automatic investment”, “automatic purchase”, “BOT”, “bought”, “buy”, “contribution”, “direct investment”, “direct purchase”, “EECON”, “invested”, “investment”, “money fund sweep”, and other terms. Financial portfolio integrator240identifies differences in semantics to avoid loss of critical information and is instrumented to detect and report situations where decisions cannot be made or where those decisions appear to be incorrect based on other data available from other sources.

Financial portfolio integrator240applies business logic, interpreting and categorizing financial information, enabling portfolio manager10to provide value-added portfolio management tools. Examples of business logic can include asset class categorization, sub-asset class categorization, comparison of actual to target allocation, computation of allocation adjustment, personal return calculations, net worth history, e-mail alerts (e.g., daily security activity, holding “issues”), and portfolio metrics (e.g., portfolio level return; portfolio risk/volatility).

Advantageously, the process described with reference toFIG. 2automatically brings together the financial information data of one client from any of a multitude of financial institutions, regardless of the data formats used by the financial institutions and regardless of the relationships between financial institutions.

FIG. 3illustrates a flow diagram300of exemplary steps in a financial portfolio integration process. Flow diagram300depicts one process by which financial portfolio integrator240described with reference toFIG. 2operates. In an exemplary embodiment, a step310is performed in which raw or parsed financial data313is examined to determine whether there are missing pieces of data. If there are missing pieces of data, a context-free description interpreter315is engaged.

Context-free description interpreter315applies various language-processing techniques, such as, recognition of numbers and symbols with special meaning, to extract missing information from the description. As an example, some financial institutions provide an “incomplete” set of data elements and pack the remaining information into a description. The institution might report something like:

Trade date:Jan. 03, 2001Settle date:Jan. 06, 2001Ticker:QCOMDescription:Buy 100 shares @ $65/shareTotal:$6,500
In this example, transaction type, units/quantity and unit price are not provided as separate data elements, but are desired by a data model used by portfolio manager10. The above description is broken into tokens “BUY”, “100 SHARES”, and “@ $65/SHARE”. A dictionary can be used to identify “BUY” as an activity type, pattern matching and a dictionary can be used to identify “100 SHARES” as a quantity of 100, and more pattern matching can be used to identify “@ $65/SHARE” as a unit price of $65.

Free-text descriptions in context-free description interpreter315can be unlimited by nature, and a term may have several possible meanings, depending on context (e.g., the word “INCOME” may indicate an activity type, as in “INCOME RECEIVED”, or may be part of a name, as in “GROWTH AND INCOME FUND”). A context-sensitive description interpreter (described below) can handle descriptions not handled by context-free description interpreter315.

If data is not missing in step310or after context-free description interpreter315is engaged, a step320can be performed in which a determination is made as to whether there are multi-part values in the financial data. If multi-part values are present, a value combiner325is engaged. Value combiner325can handle the situation where a financial information source (e.g., a web site) divides totals into income and principal portions. These portions need to be combined to produce a total. Value combiner325can also handle the situations where a financial information source provides multiple activity descriptions. For example, a financial institution can present the transaction information provided in Table 2 below.

Value combiner325can use a rule-based mechanism to take the “transaction type” information and the “activity type” information and produce a single type for each of the three transactions (e.g., Income, Buy, and Deposit, respectively). Value combiner325can also handle the situations, such as, a balance conflict by adding the OFX-specified elements of AVAILCASH and MARGINBALANCE together, watching for specific free-form balance entries and using these to adjust that result further (e.g., “MARGIN ACCOUNT EQUITY” is subtracted, adjusting for the use of MARGINBALANCE to report the total value of a margin account).

If there are not multi-part values in step320or after value combiner325is engaged, a data record filter335can be engaged. Records downloaded from financial institutions may hold transactions, but they also may hold summary information (e.g., subtotal/total rows, such as one might have in a spreadsheet) or status information (e.g., the only record in a table may be “system not available”). Data record filter335can use rules with a combination of statistics (e.g., does a record contain the elements “expected” based both on other records/column headers seen and on data model requirements) and a dictionary (e.g., does the record look like it refers to a known-to-be-uninteresting type of data) to eliminate records deemed to be of no value. At the same time, data record filter335can preserve status information, marking it as a “status” transaction (as opposed to balance, holding, or activity) so later processing can mark the account appropriately. Data record filter335results in filtered data337.

Filtered data337and name/quote data343are provided to an equity identifier345. Financial institutions identify instruments by Ticker, CUSIP (identification number selected by the Committee on Uniform Securities Identification Procedures), or name (which may be abbreviated) identifiers. The identification may be free-standing, or may be embedded in a free-text description. Equity identifier345is responsible for identifying the equity associated with a transaction. A CUSIP can look like quantities and other numerical values. It is used in the absence of a ticker and only if the CUSIP is clearly identified by the financial institution (via a label of some sort). Where a CUSIP is used, equity identifier345looks the CUSIP up in a database of equities and uses the resulting Ticker.

Equity identifier345can use a variety of techniques to identify an equity. For example, equity identifier345can check to determine whether the name is a ticker name or a name-in-database as well as checking the description contains a ticker or name-in-database. If an equity is not identified, equity identifier345can incorporate the institution's name (because mutual fund companies often do not include their name with the fund name, while the rest of the world does). For example, the SCUDDER Internet web site might list “Global Fund”, while all non-SCUDDER sources call it “Scudder Global Fund”.

Equity identifier345can use smart handling to identify situations where common names are used to identify instruments that do not correspond to what other sources would expect. For example, an insurance company may name a variable annuity after a mutual fund on which the annuity is based. A successful identification requires that the instrument's NAV (net asset value) correspond to the price reported by the financial institution (within tolerances) for a successful match. This identification technique can be expanded beyond mutual funds to any name to avoid potential incorrect identification from free-form names.

After equity identifier345is engaged, previous position data353and data from equity identifier345can be provided to a position identifier355. Position identifier355can determine to which existing position in the data model of portfolio manager10a transaction corresponds. To do so, position identifier355can rely on equity-based and name-based matching.

After position identifier355is engaged, a context-sensitive description interpreter365can be engaged. Transactions with missing information and free-text descriptions can be interpreted again in light of the account's known positions. Context sensitive description interpreter365can compare the descriptions to the names of the account's positions (or the names/tickers of the associated equities) and attempt to find a point at which to break the description into components, much as numbers and special symbols were used in context-free description interpreter315, described above. If the description can be broken down, similar techniques to those described earlier can be used to extract data values. Success may cause position identifier355to be re-engaged.

After context sensitive description interpreter365is engaged, a value adjuster375can be engaged. Value adjuster375can correct values (e.g., adjusting signage to conform to the data model) and supply missing values based on information in the transaction and knowledge of the equity. For example, given any two of unit price, quantity, and total, the missing element can be calculated. If unit price is missing but the equity is known, the unit price can be supplied.

After value adjuster375is engaged, a step380can be performed in which a decision is made whether a transaction identifier (ID) is missing. If the transaction ID is missing, a transaction ID generator382can be engaged. Transaction ID generator382generates a unique ID for the transaction by combining a representation of all of its data elements (e.g., date, amount, account, equity, etc.).

If the transaction ID is not missing or after the transaction ID generator382is engaged, a duplicate eliminator385can be engaged. Duplicate eliminator385can manage multiple copies of the same information. In the case of holding and balance information, duplicate eliminator385deletes any older information from the same day (holding information is not “final” until the close of the business day, so later information is better). In the case of activity information, duplicate eliminator385deletes the new copy, as the older copies will have been processed already, and the information about a transaction never changes (any changes are posted via “corrections”, which are new transactions).

After duplicate eliminator385is engaged, a position adjuster387can be engaged. Position adjuster387can create, update, and/or delete positions based on the new transactions. Position adjuster387may also combine multi-part holdings into a single entity. Examples can include combining a trust's holding of a single equity reported as separate “principal” and “income” holdings into a single position, combining multiple pieces of an overall cash balance into a single balance representing all of the cash in the account, and combining holdings of a single equity bought using different techniques (e.g., bought using cash vs. bought on margin) into a single position.

After position adjuster387is engaged, a step390can be performed in which a determination is made as to whether a position in the data model of portfolio manager10is missing or, in other words, the position with which a transaction being processed is associated has not been identified. If a position is missing, an orphan handler392is engaged. It is possible that some transactions remain without having an identified position. Orphan handler392provides an attempt to assign these transactions to a position. In an exemplary embodiment, orphan handler392identifies transactions that do not carry equity information with them, checking their type for applicability to a cash transaction, and associating those transactions with the account's cash balance.

After orphan handler392is engaged, a step393can be performed in which a determination is made as to whether a position is discovered. If a position is discovered, context-sensitive description interpreter365is engaged. If a position is not discovered or if a position is not determined to be missing in step390, a cash flow adjuster395can be engaged. The arrival of new transaction information may have implications on cash flows for various historical periods. Cash flow adjuster395can map newly processed transactions with non-neutral cash flow implications to the periods covering each transaction's date and recalculates the flow for that period. The result of cash flow adjuster395is personalized data397. Personalized data397is used in the formation or updating of a financial portfolio file.

Advantageously, the financial portfolio integration process described with reference toFIG. 3intelligently aggregates financial information into a financial portfolio. Such integration allows for inter-relationships among financial information to be established. Further, the integration provides an automated processing of financial information such that calculations, projections, and other operations can be performed on the data included in the information.

FIG. 4illustrates a general functional block diagram400of exemplary operational components of portfolio manager10described with reference toFIG. 1, in accordance with yet another exemplary embodiment. As shown in diagram400, a web browser410can include an applet application412. Applet application412is configured to communicate with a web server420. In an exemplary embodiment, applet application412provides data presentation and user interaction and is written in the JAVA programming language.

Web server420can include a servlet application422. Servlet application422is configured to communicate with an application service component430. Servlet application422provides data access and request processing/dispatching by interacting with the client-side applet412, and can be written in the JAVA programming language. Servlet application422can be accessed via a secure (HTTPS) uniform resource locator (URL), using Secure Sockets Layer (SSL) support of web server420.

Application service component430can include an equity update agent432, business logic434, and a spider agent436. Application service component430provides security and account data acquisition and interpretation. Equity update agent432can communicate with a quote server440and an equity information database450. Equity update agent432is a module responsible for interacting with third party quote service to obtain security information. Quote server440is a server computer which is configured to provide equity pricing information (e.g., information obtained from financial exchanges and other third party data providers). Equity information database450is a database that contains information on equity (e.g., stock, bond, mutual funds) obtained from third party quote services.

Business logic434can communicate with equity information database450, a login information database460, and a portfolio information database470. Business logic434is a module responsible for performing transaction interpretation, rate of return calculations, and any other data processing required by portfolio manager10. Login information database460is a database which contains login identifications and passwords/PINs, obtained from users, for each on-line account, if the user opts to allow portfolio manager10to gather and update account information automatically. Portfolio information database470is a database which contains user and portfolio information, populated with a combination of user-supplied information, data obtained from financial institutions, and results of calculations made by business logic434. Spider agent436can communicate with portfolio information database470and financial institutions480,482, and484. In an exemplary embodiment, spider agent436is a module responsible for crawling financial institution sites for account data.

In an exemplary embodiment, the following scenarios are illustrative of the interaction of components of portfolio manager10during operation. Servlet application422can receive a user registration request either from applet application412or from a separate vendor web page. Servlet application422connects to the login information database460to create an account for the client. If this request does not come directly from the client, the password is pre-expired. The client can request creation of a portfolio, or registration of an account, while running applet application412. Applet application412collects all required information and sends the information along with a “stored new data” request to servlet application422. Servlet application422receives the request and its information and hands the package off to a new thread. This thread stores the information in the login information database460and portfolio information database470.

In an exemplary embodiment, if the user is registering an account and opts not to have a personal identification number (PIN) information stored by server420, the login information is not transmitted to server420, but rather is stored locally by applet application412.

In an exemplary embodiment, nightly spidering takes place on behalf of all clients, without a specific client request to drive it. Application service component430maintains a spidering schedule. When the time arrives for nightly spidering, spider agent436of application service component430, first, finds the accounts it is to handle; second, consults login information database460and makes a list of those accounts for which it also has login information; and third, distributes this list among a set of spidering threads.

Each spidering thread connects to the appropriate financial institution, performs a log-in procedure using the login information supplied to it, and then downloads the information for the specified account. The results are handed off to a data parser that interprets the downloaded data and writes transaction and holding information to portfolio information database470. Once information from an account has been updated, spider agent436notifies business logic434, which looks up the account (from portfolio information database470), processes any newly downloaded transactions, and writes the results of its calculations back to portfolio information database470. Business logic434also evaluates any alerts associated with the portfolio of the account and generates and delivers any required electronic mail by contacting a SMTP server to do so.

In an exemplary embodiment where spidering is initiated upon a request by the client and PIN information is located on the server, the following may be performed. Where the client is working in applet application412and requests and an account update, applet application412checks the PIN storage policy of the client, sees that PINs are stored on the server, and sends an “on-demand spidering” request to servlet application422, identifying the client who's accounts are to be spidered. Servlet application422hands this package to a new thread, which simply passes the request and its parameters through to application service component430. The thread of servlet application422sends an acknowledgement back to applet application412and issues a periodic series of “progress” responses based on information it gets periodically from application service component430. Spider agent436identifies that the request contains no account or login information and looks up the information from login information database460and portfolio information database470. Processing then proceeds as it does during nightly spidering.

In an exemplary embodiment where the client requests spidering and PINs are located on the client, applet application412checks a list of client account information, looks up login and PIN information from a local database or memory device. Applet application412then sends this full list and an “on-demand spidering” request to servlet application422. Servlet application422handles this request the same way it handles other on-demand spider requests.

FIG. 5illustrates a general functional block diagram500of an exemplary embodiment of application service component430described with reference toFIG. 4. Application service component430includes a main server, spider agent, equity update agent, and business logic. The main server can include a controller512and an error logger514. Spider agent can include a dispatcher522, financial institution (FI) data collectors524, a data buffer queue526, and a data parser528. The equity update agent can include a quote collector532and a news collector534. The business logic can include a transaction interpreter542, a return calculator544, and an alert generator546.

Controller512handles update scheduling and on-demand processing requests, passing them along to the appropriate component to which the requests correspond. Error logger514generates an error notification, which is a service available to all components of application service component430. Dispatcher522accepts spidering requests from controller512. Dispatcher522starts and monitors FI data collector524for each financial institution and/or account involved, eliminating the number of concurrent threads based on server parameters. Dispatcher522reads information from a login information database and passes this information to FI collectors524. Dispatcher522also accepts log-in information passed from an applet application using a local PIN database through the servlet application to application service component430.

FI data collectors524are responsible for contacting a financial institution and downloading account data as requested by dispatcher522. FI data collectors524build a buffer of raw data and place it on data buffer queue526. Several FI data collectors524may be active at the same time. Data buffer queue526serves as a coordination point between FI data collectors524which fill queue526and data parser528, which empties queue526. In an exemplary embodiment, data buffer queue526is an in-memory, thread-safe repository of data buffers. Data parser528is responsible for translating raw financial institution data and turning it into data objects and records with a common format and storing the results in a database.

Quote collector532is responsible for interacting with a third party quote service, such as, North American Quotations of London, Ontario, Canada, to gather security information and update records in the equity information database450. News collector534is responsible for interacting with a third party news service, such as Reuters, gathering articles and news releases and updating records in equity information database450.

Transaction interpreter542is responsible for reading unprocessed transactions from portfolio information database470and using this information to adjust holding information, such as cost basis, and numbers of shares, and writing any results back to portfolio information database470. Transaction interpreter542may consult the security information database for information about securities referred to by the transactions. To avoid the performance hit of polling for unprocessed transactions, the database access responsible for creating an unprocessed transaction “pings” or sends a communication to the transaction interpreter542to let it know there are transactions to be processed. Return calculator544is responsible for calculating internal rates of return for holdings and portfolios. Return calculator544reads information from both portfolio information database470and equity information database450and updates portfolio information database470. Information from databases450,460and470can be accessed through a database access537. Alert generator546is responsible for evaluating portfolio and holding changes and generating alerts. Alerts can be stored in portfolio information database470and are also sent to an SMTP mail server for delivery as e-mail messages.

FIG. 6illustrates an exemplary user interface display600conveying information from portfolio manager10(FIG. 1). Display600includes information associated with financial markets, such as, the Dow Jones Industrial Average market index. Display600also includes information regarding specific stocks held by the client or being watched by the client. Further, display600includes information regarding fundamentals and alerts specific to a selected stock.

In an exemplary embodiment, display600includes a section610depicting a graphical representation of financial market information. A section620can include a list of security holdings arranged by ticker symbol, including the security price daily change, and volume of transactions in the financial market. A section630in display600shows additional information about a particular security selected in section620.

FIG. 7illustrates an exemplary user interface display700conveying information from portfolio manager10(FIG. 1). Display700provides information regarding total net worth of the client. Total net worth can include information regarding the total value of each portfolio and account, the value of any other assets the client may hold, and the amount of any liabilities owed by the client. Further, display700can include a graph of the client's net worth as it changes over time, as well as detailed information regarding values of specific holdings, values of asset classes of holdings, and values of asset subclasses of holdings within accounts and portfolios.

FIG. 8illustrates an exemplary user interface display800conveying information from portfolio manager10(FIG. 1). Display800displays information regarding the risk and return for selected holdings in the portfolio of the client. Risk and return can be shown in display800graphically as well as textually.

FIG. 9illustrates an exemplary user interface display900conveying information from portfolio manager10(FIG. 1). Display900includes information on a financial portfolio. Display900also includes a graphical display of actual value and target value for the portfolio.

FIG. 10illustrates an exemplary user interface display1000conveying information from portfolio manager10(FIG. 1). Display1000includes information on transactions for a financial portfolio. Display900also includes transaction details for a selected transaction.

FIG. 11illustrates an exemplary user interface display1100conveying information from portfolio manager10(FIG. 1). Display1100includes set up information for a financial portfolio. Display1100also provides for the input of personal information from the user of portfolio manager10.

FIG. 12illustrates an exemplary user interface display1200conveying information from portfolio manager10(FIG. 1). Display1200includes set up information for a financial portfolio. Display1100also provides for the selection, creation, and comparison of portfolios from the user of portfolio manager10.

FIG. 13illustrates an exemplary user interface display1300conveying information from portfolio manager10(FIG. 1). Display1300includes set up information for a financial portfolio. Display1300provides for the input of assets and liabilities in a portfolio from the user of portfolio manager10.

FIG. 14illustrates an exemplary user interface display1400conveying information from portfolio manager10(FIG. 1). Display1400includes set up information for a financial portfolio. Display1400provides for the input of ticker names to watch from the user of portfolio manager10.

FIG. 15illustrates an exemplary user interface display1500conveying information from portfolio manager10(FIG. 1). Display1500includes set up information for a financial portfolio. Display1500provides for the input of financial alerts from the user of portfolio manager10.

FIG. 16illustrates an exemplary user interface display1600conveying information from portfolio manager10(FIG. 1). Display1600includes basic holding information for a financial portfolio. Display1600provides a graphical and numerical representation of holdings allocations in the financial portfolio.

FIG. 17illustrates an exemplary user interface display1700conveying information from portfolio manager10(FIG. 1). Display1700includes more detailed holding information for a financial portfolio than display1600described with reference toFIG. 16. Display1700provides a graphical and numerical representation of holdings allocations as well as target allocations for a financial portfolio.

Advantageously, portfolio manager10provides total information access, bringing all customer financial data from any bank, brokerage, or other institution in one place. Further, portfolio manager10makes it easy for customers to see their portfolio performance at any time with automatic updates. Portfolio manager10allows customers to customize and organize portfolios and help understand risk and return with advanced analysis tools. Further, portfolio manager10helps attract and retain key customers with the added value of portfolio manager10. Portfolio manager10allows customers co-branding and custom links to products and services available from specific financial institutions.

Portfolio manager10can include the ability to share data at two levels, such as, at a client level and at a financial intermediary level. At a client level, portfolio manager10provides individuals with financial information that may be from multiple financial sources. At an intermediary level, such as brokers, financial advisors, and accountants, portfolio manager10provides financial services intermediaries with a tool for assisting customers in the management of their financial portfolio.

Advantageously, customers can track all of their assets and liabilities and monitor their net worth in one place. Portfolio manager10helps customers to set and monitor personal investment goals. Portfolio manager10assists in evaluating return relative to risk information, allowing customers to make smarter decisions on investments.

While the exemplary embodiments illustrated in the figures and described above are presently preferred, it should be understood that these embodiments are offered by way of example only. Other embodiments may include, for example, a wide variety of ways to convey financial portfolio information, such as, wireless application protocol (WAP), personal digital assistant (PDA) protocols, and other presentation means. Further, while exemplary embodiments describe the invention in the context of financial assets, the invention may extend to other assets or other items which can be organized into a portfolio. The invention is not limited to a particular embodiment, but extends to various modifications, combinations, and permutations that nevertheless fall within the scope and spirit of the appended claims.