Fixed income securities ratings visualization

[0001] The financial investment industry has been transformed by developments of communication and computer technologies. Low cost personal computers and the Internet have allowed individual investors to gain access to financial information as well as trading and investment technology. The advent of self-directed retirement savings accounts has increased the need for market data and for tools to aid investors in their decision-making. In the equity and mutual fund markets, various platforms and tools sets have been developed and made easily available to individual investors via computer systems and the Internet.

[0002] The fixed income market has traditionally been an institutional market that serves, for example, pension funds, insurance companies and banks. The fixed income market lacks price transparency and liquidity. Trades executed in the fixed income market are often done in very large quantities. There are very few ways for individual investors to gain access to bonds offered for sale and practically no tools available to evaluate the offerings beyond rudimentary yield calculators. In addition, market information is fragmentary and often unavailable to retail investors.

[0003] The fixed income market is generally segmented into the Treasury, corporate bond, municipal bond, mortgage-backed security, federal agency and asset backed securities. The Treasury market, which comprises the debt of the United States government, has historically provided the most actively traded and widely owned fixed income securities. It is widely believed that this debt will never default and is considered the gold standard for safety. Therefore, the risk of owning other types of debt is usually measured against the safety of owning Treasury debt.

[0004] Almost all fixed income securities, other than Treasury debt, are rated by rating agencies that are quasi-regulatory groups that evaluate the creditworthiness of firms that issue debt securities. The rating agencies are designated Nationally Recognized Statistical Rating Agencies by the United States Securities and Exchange Commission and play an important role in the financial markets.

[0005] A retail investor seeking to evaluate fixed income securities offered for sale, is typically presented with tables of symbolic or alphanumeric rating data. Each of such symbolic ratings may correspond to an evaluation of a security from a particular rating agency and may have well defined semantic meanings in terms of the creditworthiness of the security. In addition, since there may be more than one such rating agency, each of such rating agencies may have its own rating scheme with a different symbolic rating scale. When a retail investor receives such rating information, it is very difficult to review the offerings and understand the relative risk of one security versus another. The difficulty is related to both the fact that each fixed income security may be associated with various credit ratings issued by different rating agencies and the retail investor's ability to weigh the risk and return based on such information. It becomes even more difficult when a retail investor attempts to evaluate the risk and return of a portfolio of rated debt. In the current market, there are no available systems or tools that facilitate retail investors in examining market information and in making fixed income market investment decisions. This shopping difficulty prevents many retail investors from participating in the fixed income market.

[0006] The inventions claimed and/or described herein are further described in terms of exemplary embodiments. These exemplary embodiments are described in detail with reference to the drawings. These embodiments are non-limiting exemplary embodiments, in which like reference numerals represent similar parts throughout the several views of the drawings, and wherein:

[0007] FIG. 1 depicts the overall architecture for a fixed income online retail enabling mechanism, according to the embodiments of the present invention;

[0008] FIG. 2 depicts an exemplary internal high level functional block diagram of a fixed income online retail enabling mechanism;

[0009] FIG. 3 depicts an exemplary internal high level functional block diagram of a front-end engine that facilitates visual interactions between an online fixed income user and a fixed income online retail enabling mechanism;

[0010] FIGS. 4(a)-(b) illustrate exemplary constructs of different conversion tables used in converting a symbolic rating to different representations;

[0011] FIG. 4(c) illustrates exemplary relationships between different symbolic ratings and converted ratings;

[0012] FIG. 5(a) depicts an exemplary internal structure of a visualization mechanism that is capable of generating various visual presentations for information related to fixed income market data;

[0013] FIGS. 5(b)-(n) illustrate exemplary visualizations of information related to fixed income securities;

[0014] FIG. 6 depicts an exemplary internal structure of a process interface mechanism that activates different mechanism based on user's instructions;

[0015] FIG. 7 describes an exemplary internal structure of an offering management mechanism;

[0016] FIG. 8 describes an exemplary internal structure of a rating management mechanism;

[0017] FIG. 9 describes an exemplary internal structure of an account management mechanism;

[0018] FIG. 10 describes an exemplary internal structure of a transaction processing mechanism for online trading of fixed income securities;

[0019] FIG. 11 is a flowchart of an exemplary process, in which a user performs operations related to online trading of fixed income securities via a fixed income online retail enabling mechanism;

[0020] FIG. 12 is a flowchart of an exemplary process, in which a fixed income online retail enabling mechanism visually presents information related to fixed income capital markets to a user;

[0021] FIG. 13 is a flowchart of an exemplary process, in which a symbolic rating obtained from a rating institution is converted into a color code;

[0022] FIG. 14 is a flowchart of an exemplary process, in which a symbolic rating obtained from a rating institution is converted into a real value;

[0023] FIG. 15 is a flowchart of an exemplary process, in which a visualization mechanism constructs different visualizations based on information related to different aspects of fixed income securities and converted ratings according to user's choice;

[0024] FIG. 16 is a flowchart of an exemplary process, in which an account management mechanism performs different account management operations; and

[0025] FIG. 17 is a flowchart of an exemplary process, in which a transaction processing mechanism performs operations to facilitate online trading of fixed income securities.

[0026] The processing described below may be performed by a properly programmed general-purpose computer alone or in connection with a special purpose computer. Such processing may be performed by a single platform or by a distributed processing platform. In addition, such processing and functionality can be implemented in the form of special purpose hardware or in the form of software or firmware being run by a general-purpose or network processor. Data handled in such processing or created as a result of such processing can be stored in any memory as is conventional in the art. By way of example, such data may be stored in a temporary memory, such as in the RAM of a given computer system or subsystem. In addition, or in the alternative, such data may be stored in longer-term storage devices, for example, magnetic disks, rewritable optical disks, and so on. For purposes of the disclosure herein, a computer-readable media may comprise any form of data storage mechanism, including such existing memory technologies as well as hardware or circuit representations of such structures and of such data.

[0027] FIG. 1 depicts the overall architecture 100 for online retail of fixed income securities, according to embodiments of the present invention. The architecture 100 includes a user terminal 110, a graphical user interface 120, and a fixed income online retail enabling mechanism 130. The user terminal 110 may be operated by an individual retail investor or an investor representative acting on behalf of an individual customer investor. The user, via terminal 110, trades, via the fixed income online retail enabling mechanism 130, securities in one or more fixed income capital markets 150 based on information related to such securities such as offering information 170, the ratings 180 with respect to the securities in the fixed income capital markets 150 obtained from rating institutions 140, as well as other market data 190 from other sources of market data 160.

[0028] The fixed income online retail enabling mechanism 130 provides the means to facilitate online trading of securities in fixed income markets. This may include, but is not limited to, means to visualize information from different sources so that a user can effectively evaluate a specific security or conditions within the market against their portfolios from a multiple perspectives. To do so, the fixed income online retail enabling mechanism 130 may also facilitate different peripheral functionalities to enable various business processes related to online fixed income bond trading. For instance, the fixed income online retail enabling mechanism 130 may offer the means to manage portfolios associated with different accounts, including dynamic update of a portfolio whenever a corresponding user trades fixed income securities or the rating on a specific fixed income security is changed.

[0029] FIG. 2 depicts an exemplary internal high-level functional block diagram of the fixed income online retail enabling mechanism 130. The fixed income online retail enabling mechanism 130 may comprise a front-end engine 205, a data collection and management mechanism 225, an account management mechanism 265, and a transaction processing mechanism 270. The front-end engine 205 interfaces with the graphical user interface 120 to facilitate the interaction between the user operating through the user terminal 110 and the fixed income online retail enabling mechanism 130.

[0030] The data collection and management mechanism 225 is responsible for collecting relevant data from different sources and such information is used for visualizing different aspects of the market and for helping a user to evaluate the fixed income capital markets. The types of information to be collected for such purposes may include, but not limited to, offering information describing daily offerings of different securities in the fixed income markets, ratings of such offerings issued by one or more authorized rating institutions (140), and other market data related to the securities such as pricing, news, or commentaries related to different securities in the fixed income markets.

[0031] To make information from different sources readily available for use in enabling online trading of fixed income securities, the data collection and management mechanism may comprise an offering management mechanism 230, a rating management mechanism 240, and a market data management mechanism 250. Each may have an associated database deployed to organize the collected data. For instance, the offering management mechanism 230 may be associated with an offering database 235 used for storage, organization, and retrieval of information related to the bond inventory. The rating management mechanism 240 may be associated with a rating database 245 that is used for the storage and retrieval of rating information. Similarly, the market data management mechanism 250 may be associated with a market data database where different types of market data are stored, organized, and accessed when needed.

[0032] Each of the management mechanisms (the offering mechanism 230, the rating management mechanism 240, and the market data management mechanism 250) may be capable of performing a plurality of functionalities related to managing the corresponding types of information. That is, each may have its own data collection capabilities (i.e., communicate with outside servers to request relevant information), data organizational capabilities (e.g., sorting data according to some specified criteria), data indexing capabilities (e.g., to build efficient indexing scheme), and data retrieval capabilities (e.g., efficiently retrieve requested data based on pre-established indexing system). For example, these management mechanisms may be capable of contacting relevant agencies to request information. The offering management mechanism 230 is capable of contacting authorized institutions to gather offering information. The rating management mechanism 240 is capable of connecting to the rating institutions to gather official rating information about different securities. Similarly, the market data management mechanism 250 may connect to a set of different sources to gather commentaries and pricing about certain securities. Details related to the offering mechanism 230 and the rating management mechanism 240 are discussed with reference to FIG. 7 and FIG. 8.

[0033] The ratings collected from the rating institutions 140 may be in some standard symbolic representations. Each rating may be given with respect to a particular bond identifiable using some identification scheme. For instance, each of the securities can be identified according to a unique identification such as the Uniform Security Identification Procedures (CUSIP) adopted by The American Bankers Association's Committee. There may be different sources of ratings with respect to a single bond such as Moodys' rating, Standard and Poors (S&P)'s rating, and Fitch's rating. Different rating institutions may adopt different symbolic rating schemes. For instance, rating AA from S&P may correspond to rating Aa1 (a different rating symbol) from Moodys. In addition, ratings issued from different rating institutions with respect to a single bond may differ. For instance, for bond X, Moodys may have a rating of Aaa (corresponding to rating AAA of S&P's) but S&P may give a different rating AA (corresponding to rating Aa1 of Moodys which is a lower rating than Aaa) with regard to the credit quality of the same bond.

[0034] Each of the rating scales adopted may be associated with a particular semantic meaning. Semantic interpretations associated with different ratings may be pre-determined. For example, rating Aaa may mean Best quality and rating Aa2 may mean High quality.

[0035] The ratings obtained from rating institutions are used to help a user to evaluate the securities in the fixed income markets. To make the evaluation more effective and efficient, the front-end engine 205 provides a rating conversion mechanism 210 to convert the symbolic ratings from the rating institutions 140 into easier to understand and visually appealing representations. Such representations may include, but are not limited to, color representation or numerical representation. The rating conversion mechanism 210 takes a symbolic rating (such as AAA) as input and generates either a color code (such as green) or a real value (such as 9.5) to describe the meaning of the symbolic rating. Details of the rating conversion mechanism 210 are discussed with reference to FIG. 3.

[0036] In converting a symbolic rating into a color code or a real value, the rating conversion mechanism 210 may employ different schemes to complete the conversion. For example, a scheme of table look up may be adopted. In this case, one or more conversion tables 215 are pre-constructed that allows conversion to be achieved via a simple online look-up operation. Exemplary constructs of conversion tables are described with reference to FIGS. 4(a) and 4(b). There may be other alternative conversion schemes such as automatic conversion via a pre-defined formula (not shown in FIG. 2). For instance, a formula may be defined as a mapping from a symbolic rating to a color code. That is, a symbolic rating may be taken as a parameter of the formula.

[0037] To achieve conversion using a pre-defined formula, a symbolic rating may be first transformed into a numeric value. The numeric value may then be plugged in the pre-defined formula to produce one or more output values corresponding to a color code. For example, if (R,G,B) scheme is adopted to represent color, the resulting values from the pre-defined formula corresponding to the value of R (red), G (green), and B (blue). On the other hand, a different color representation may be adopted such as (G, Y, R) (corresponding to green, yellow, and red).

[0038] A symbolic rating may also be converted into a real value defined in a pre-specified range. For example, a converted rating may correspond to a real value within the range of 0, 10, where a converted real value of 10 may be specified as a perfect rating (highest possible) and a converted real value of 7.5 may correspond to a rating that is of a less than perfect quality.

[0039] The rating conversion mechanism 210 takes a symbolic rating (collected by, for example, the rating management mechanism 240) from a particular rating institution (e.g., S&P) and produces one or more rating representations (e.g., color code or a real value). Such converted rating representations are then used by a user interaction control mechanism 220 to generate various visual presentations of the information related to securities in the fixed income capital markets 150 to assist a user to evaluate the securities. Details of the user interaction mechanism 220 are presented with reference to FIGS. 3, 5, 6, 12, 13, 14, and 15.

[0040] In addition to facilitate a user in analyzing information related to securities through data collection, management, conversion, and visualization, the fixed income online retail enabling mechanism 130 may also assist the user in managing corresponding account information or performing bond transactions. The account management mechanism 265 may provide various means for the user to query, add, delete, and update account information in the portfolio of each account. Details about the account management mechanism 265 are discussed with reference to FIGS. 9 and 16. Account information associated with users of the fixed income online retail enabling mechanism 130 may be stored in an account information storage 260 which may organize information related to both account (260a) as well as portfolio information (260b) associated with individual accounts in a coherent manner.

[0041] Although account and portfolio information are shown as separate entities in FIG. 2, they may be managed as coupled information. The account information storage 260 may be realized in many different arrangements. One arrangement may integrate portfolio information with each account and manage the portfolio information as part of the account information. In an alternative arrangement, portfolio information may be managed as a separate data set with indices established using account information. In this arrangement, each database (e.g., the account database 260a or the portfolio database 260b) may be managed in a manner that is most suitable considering the nature of the data. Yet, the relationships between different databases can be effectively established based on indices. Specific arrangements for different deployments may be determined according to application needs.

[0042] The storage 260 may provide not only physical storage management capabilities but also indexing and efficient retrieving capabilities. Off-the-shelf database products such as dBase III or Oracle may be used to implement the account information storage. In this case, the account information storage 260 may interface with other mechanisms (such as the account management mechanism 265 and the transaction processing mechanism 270) via standard database protocols such as standard query language (SQL). Through such a standard interface, an outside mechanism such as the account management mechanism 265 may perform various database operations. For example, using SQL, the account management mechanism 265 may retrieve information about an account, add an account, delete an account, or update information associated with an account (e.g., updating a portfolio after a transaction).

[0043] The transaction processing mechanism 270 facilitates a user in trading fixed income securities. When receiving an order (e.g., to buy or to sell securities) issued by the user from the user terminal 110 via the user interaction control mechanism 220, the transaction processing mechanism 270 carries out the requested transaction according to what is specified in the received order. To do so, it may, for example, conduct further processing such as checking the credit available in the account against the value of the trade and updating a corresponding portfolio when the transaction is completed. The transaction processing mechanism 270 may also interact with the account information storage 260a to, for example, retrieve cash balance information stored in an account and update the portfolio of the account. Details related to the transaction processing mechanism 270 are described with reference to FIGS. 10 and 17.

[0044] FIG. 3 depicts an exemplary internal high level functional block diagram of the user interaction control mechanism 220 of the front-end engine 205 (in relation to the rating conversion mechanism 210) that facilitates visual interactions between an online fixed income bond trading user and the fixed income online retail enabling mechanism 130. The user interaction control mechanism 220 directs the fixed income online retail enabling mechanism 130 to perform appropriate acts according to the requests of the user specified via the graphical user interface 120. The user interaction control mechanism 220 comprises an interactive interface driver 360, a process interface mechanism 370, a data aggregation mechanism 330, a data analysis mechanism 340, and a visualization mechanism 350.

[0045] The interactive interface driver 360 forwards requests from a user issued through the user terminal 110 first to the process interface mechanism 370 so that the process interface mechanism 370 can activate appropriate parts of the fixed income online retail enabling mechanism 130 to react to the user's requests. Details of the internal structure of the process interface mechanism 370 to achieve described function are described with reference to FIG. 6. The interactive interface driver 360 may also forward user request related information to the data aggregation mechanism 330, the data analysis mechanism 340, and the visualization mechanism 350. For instance, the user may specify what kind of information (e.g., ratings) is desired with respect to certain securities. In this case, the interactive interface driver 360 may first send the relevant data to the process interface mechanism 370 so that it can direct appropriate mechanisms to collect desired information. The interactive interface driver 360 may also inform the data aggregation mechanism 330 in terms of what types of data to be aggregated. In addition, it may inform the data analysis mechanism 340 to sort the data according to the alphabetic order of the issuing corporations with original ratings displayed in an order of, for instance, Moodys, S&P, and Fitch.

[0046] The data aggregation mechanism 330 takes different data inputs and aggregates data to generate consolidated data. For example, it may take daily offering data from the offering management mechanism 230, market data from the market data management mechanism 250, and the symbolic ratings corresponding to the daily offerings as well as their converted ratings (e.g., in color codes and in real values) as input and generate a table of data in which each row corresponds to one offering and each column corresponds, for instance, either a converted rating or market data. In addition, the data aggregation mechanism 330 may also take some proprietary data as input and use it together with the information from other sources. For instance, such proprietary data may be generated internally by other parts of the fixed income online retail enabling mechanism 130 or may be information from other business partners.

[0047] Such proprietary data may be generated based on information originally offered as public data yet analyzed using some proprietary methodologies or algorithms. Business partnerships or licenses may also allow one party to provide such proprietary data to other parties so that the business partners may share information. For instance, a market data firm may form a business partnership that allows them to share data, which relates to historical pricing for fixed income securities. Under this partnership, the data with regard to a particular security is analyzed and processed using in-house developed models to analyze such gathered data and generate a prediction of the performance of a security. This prediction could be derived from the historical return on fixed income securities that have, for example, credit quality of 7.5 and are securities from issuing corporations in the telecommunications sector.

[0048] The data aggregation mechanism 330 may also perform aggregation based on instructions received from the interactive interface driver 360 that may generate such instructions based on the input from the user received via the graphical user interface 120. For example, if the user indicates, via the graphical user interface 120, that only ratings are to be reviewed (without other market data), the interactive interface driver 360 then instructs the process interface mechanism 370 to activate accordingly appropriate data collection mechanisms (discussed with reference to FIG. 6) to gather desired information. The desired information is then, after being collected, sent to the data aggregation mechanism 330 to prepare for visual presentation.

[0049] The aggregated data generated by the data aggregation mechanism 330 may be fed to the data analysis mechanism 340 where data may be further processed for visual presentation purposes. For example, when a list of daily offerings are gathered with converted ratings, the offerings may be sorted, in an alphabetic order, according to the names of the issuing corporations. The processed data is then sent to the visualization mechanism 350 so that a visual presentation of the processed aggregated data can be constructed. The form of the visual presentation to be generated may be determined according to what the user desires. The visualization mechanism 350 generates appropriate visual presentations on the graphical user interface according to what the user desires (informed via the interactive interface driver 360).

[0050] As described earlier, the converted ratings can be color code or real values. In FIG. 3, the rating conversion mechanism 210 includes, but is not limited to, a color code conversion mechanism 310 and a numeric code conversion mechanism 320. The former converts a symbolic rating to a color code and the latter converts a symbolic rating to a real value with a pre-specified range. The rating conversion mechanism 210 may perform the conversion based on one or more conversion tables that may be pre-constructed to facilitate real-time table look-up operations in converting a rating.

[0051] FIGS. 4(a)-(b) illustrate exemplary constructs of different conversion tables used in converting a symbolic rating to different representations. FIG. 4(a) shows an exemplary construct of a table 400 used in converting a symbolic rating to a color code. The table 400 may have a plurality of rows, corresponding to different symbolic ratings 410, and a plurality of columns, corresponding to different rating institutions 420. For instance, the symbolic ratings may include labels such as AAA or A2. Each of the columns represents a single rating institution.

[0052] Each of the element in table 400 stored a color code represented using a particular color scheme. For instance, a color code may be represented as a tuple of (green, yellow, red) or (G, Y, R) or as a tuple of (red, green, blue) or (R, G, B). Each of the values in such a three-value tuple represents the proportion along each underlying color spectrum and blending the three portions yields a color represented by the tuple.

[0053] To perform rating conversion to a color code, a real-time table look up operation may be performed based on the table 400. For example, if a rating from Moodys is A2, the table look up operation identifies the column corresponding to the Moodys (e.g., first column in FIG. 4(a)) and the row corresponding to the symbolic rating A2. This gives rise to an entry in the table 400 where a particular color code can be retrieved as the converted color code.

[0054] The color codes stored in the table 400 may be pre-determined according to intended visual effects of the corresponding symbolic ratings. For example, a symbolic rating D (stands for default) may be assigned a color of bright red intended to have an alarming visual effect. On the other hand, a symbolic rating of AAA may be assigned a color of dark green indicating that the credit quality of the corresponding bond is excellent. Between these two extremes, different symbolic ratings may be assigned colors from the medium green to yellow and all the way to bright red, indicating gradual drop of credit quality of the underlying securities. Along the vertical direction of the table 400 from top to the bottom, the symbolic ratings are arranged from the best to the worst so that the arrangement yields gradual varying color zones. For example, the color codes assigned to the top row(s) may correspond to dark green and the color codes assigned to the bottom row(s) may correspond to bright red. Ratings in between the top and the bottom in top down direction may correspond to one or more rows of green (e.g., varying degree of green) to one or more rows of yellow (e.g., varying degrees of yellow), to one or more rows of red. This is illustrated in FIG. 4(a).

[0055] When there is a need to convert a combination of more than one symbolic rating into a single color code (e.g., visualizing the overall credit quality of a bond rated by a plurality of rating institutions), different alternatives may be employed to achieve the task. For example, if a bond is rated by Moodys, S&P, as well as Fitch and the corresponding ratings are X, Y, and Z. To generate a single color code based on ratings X, Y, and Z, the relationships among the symbolic ratings may be analyzed. If all the symbolic ratings are from the same credit quality category (e.g., all correspond to green color), a particular shade of green may be selected to represent the overall rating. The selection may be based on the principle of worst or best or average. The lightest color (the worst) among all may be selected to conservatively visualize the overall credit quality. The darkest color (the best) among all may be selected to optimistically visualize the overall credit quality of the bond. The middle color may also be selected to represent a medium overall quality. Yet another alternative is to average the three color codes to yield an averaged credit quality visualization.

[0056] FIG. 4(b) describes an exemplary conversion table 450 used in converting a symbolic rating to a real value. The table 450 may be structured in a similar way as the table 400. The difference between the table 400 and the table 450 is the values stored in each element of the table. In general, the values stored in a table correspond to the converted ratings. For example, since the table 400 is used to convert to color codes, the values stored in individual elements of the table 400 correspond to color codes. The table 450 is constructed to assist the conversion from a symbolic rating to a real value, the values stored in individual elements of the table 450 correspond to real values.

[0057] A real value converted based on a symbolic rating may fall within a fixed range. For example, such a range can be between 0 and 10 (as shown in FIG. 4(b)). Such a range may be intended to provide the user a sense of the credit quality of a bond that is rated. One end of the range may correspond to a best quality rating and the other end of the range represents the opposite. Given a range of 0, 10, real value 10 may correspond to a best quality and 0 may correspond to a worst quality. Conversion from a symbolic rating to a real value is therefore a mapping from a range of symbols (e.g., AAA, A2, . . . , D) to a range of real values (e.g., 10, 9.5, . . . , 0.0). The table 450 is designed to facilitate the conversion.

[0058] Similar to converting a plurality of symbolic ratings to a single color code representing a visualization of the overall credit quality based on different ratings, different strategies may be applied in converting a plurality of symbolic ratings of a single bond to a single real value representing an assessment of the overall credit quality of the bond based on ratings from multiple sources. Given multiple symbolic ratings, a plurality of real values may be identified from the table 450. One strategy is to use the minimum real value among such derived plurality of real values as a conservative overall assessment of the credit quality of the bond. Alternatively, the maximum real values may be used to optimistically evaluate the overall credit quality of the bond. Similarly to color conversion, an average of the individually converted real values may be computed to provide an averaged assessment of the overall quality of the bond.

[0059] FIG. 4(c) illustrates correspondence among color codes, real values, symbolic ratings from different sources, as well as the semantic interpretation of different ratings. Each row corresponds to a distinct converted rating equivalent to some symbolic rating (or symbolic ratings from different sources). The left column displays a color code converted from some symbolic rating(s). The color code is displayed as a block of color visualized according to the color represented by the converted color code. Due to the requirement for non-color figures in a patent application, to indicate what color each color block is, the color of the block is indicated using an abbreviation of the color. For instance, abbreviation DG indicates dark green, MDG for medium dark green, MLG for medium light green, LG for light green, LY for light yellow, DY for dark yellow, LO for light orange, LO for light orange, R for red, and DR for dark red. This abbreviation system is merely for clarification purposes and may not be used in implementation of the present invention. Any implementation of the present invention may adopt only color to effectuate the visual effect of the converted color code.

[0060] The second column displays the real value converted from the same symbolic rating(s). The third column displays the semantic meaning of the corresponding symbolic rating(s). The last three columns give the equivalent symbolic ratings from different sources. For example, an Aaa rating from Moodys corresponds to an AAA rating from both S&P and Fitch and they all have a semantic interpretation of prime, maximum safety. In addition, an Aa1 rating from Moodys corresponds to an AA rating from the other two, Aa2 to AA, and Aa3 to AA, all interpreted as having quality of very high grade and quality. From top down, the quality degrades gradually and so are the color codes (from dark green to lighter and lighter green to yellow to bright red) and the real values (from value 10.0 to value 0.0).

[0061] Based on processed aggregated data (aggregated data is generated by the data aggregation mechanism 330 and may then further processed by the data analysis mechanism 340), the visualization mechanism 350 creates appropriate visual presentations on the graphical user interface 120. FIG. 5(a) depicts an exemplary internal structure of the visualization mechanism 350 that is capable of generating various visual presentations for information related to the specific characteristics of fixed income securities (ie coupon rate, credit rating). To support effective visualization of different aspects of information related to fixed income securities, the visualization mechanism 350 comprises a bond offering visualization mechanism 510, a life cycle visualization mechanism 520, a portfolio holdings visualization mechanism 530, an interest projection visualization mechanism 540, an income/principal projection visualization mechanism 550, and a default rate visualization constructor 560.

[0062] The visualization mechanism 350 is driven by the user's visualization choices. That is, according to the user's visualization choice, different parts of the visualization mechanism 350 may be activated to construct a selected visual presentation. Such visualization choice may be related to the operations performed by the user. For example, if the user is examining offering related information, the visualization choice may be related to visualizing the bond offerings. Similarly, if the user is performing portfolio management activities (e.g., checking the income of a corresponding portfolio), the visualization choice may be related to visualizing the income/principal projections.

[0063] The bond offering visualization mechanism 510 visualizes the bond offerings based on aggregated data. One exemplary visualization of fixed income securities is shown in FIG. 5(b) where each row corresponds to one offering. In each row, the left-most column gives the name of the corporation that issues the bond and the year that security matures, the second column provides the symbolic ratings of the bond from different sources, and the third column provides a combined assessment of the overall credit quality of the offering visualized based on a color and a real value converted from the symbolic ratings. For example, the bond in the first row (corresponding to bond issued by Xerox which matures in year 2011) has a symbolic rating of Ba1/BBB and has a real value of 4.75 displayed on a color of light yellow (the color light yellow is indicated as LY). The fourth column provides information related to current yield (CY %) associated with the bond in the same row.

[0064] Different information may be incorporated in visualizing offerings. For example, FIGS. 5(c), 5(d), and 5(e) illustrate different visual presentations of fixed income bond offerings. Although symbolic ratings in these visualizations are not shown, they may also be incorporated into the visualizations. In these visualizations, different information such as yield to maturity (YTM %) measured in percentage and current yield (CY %) measured in percentage may be shown together with the converted ratings. The converted ratings of the securities are visualized in a similar fashion in FIG. 5(c) (third column) as in FIG. 5(b) where the higher the real value ratings are, the darker the background colors are (the colors of the visualized color blocks using converted color code are indicated using the abbreviation described above).

[0065] In FIGS. 5(d) and 5(e), a numeric conversion for the symbolic rating associated with each security is utilized with the YTM %. In FIG. 5(d), both the YTM % and the credit quality are visualized as horizontal bars with lengths of the bars reflecting the quantity associated with the YTM % and the numeric rating value converted from the symbolic rating of the corresponding security. The values of the YTM % and the converted ratings are simultaneously plotted on top of the bars. Although the (color) shades of the credit quality bars in the visualizations in FIG. 5(d) and 5(e) do not change with the converted rating, it is understood by a person in the art that the color code discussed with reference to FIG. 4(a) may be applied to visualize the bars for credit qualities.

[0066] The visualization schemes illustrated in FIGS. 5(d) and 5(e), although characterizing the same features of different offerings, the visual configurations of the horizontal bars corresponding to the YTM % and the credit quality are different. For example, the YTM % bar and the credit quality bar in FIG. 5(d) are adjacent to each other in the direction of left to right; while a credit quality bar in FIG. 5(e) is on top of a corresponding YTM % bar. Each visual configuration may provide its own appeal to a user. For example, since all the credit quality bars (of different securities) in FIG. 5(e) are plotted starting from the same point (right to the name of the security), relative credit qualities of different securities may be quickly evaluated by comparing the length of the bars.

[0067] The user may also instruct the fixed income online retail enabling mechanism 130 to visualize information related to individual fixed income securities. The life cycle visualization constructor 520 may be designed to produce life cycle related visualizations based on characteristics of individual securities such as the length of years to maturity and the coupon rate. For example, FIG. 5(f) illustrates the visualization of the life cycle of a fixed income security. The X-axis represents time (measured in years) starting from the year of the purchase to the year of maturity. The Y-axis represents the amount of either principal or interest received over the period from the purchase date to the maturity date (life cycle of the bond). The plot shown in FIG. 5(f) corresponds to a distribution of investment and return. This provides the user a visualization of his/her return during the life cycle of the bond.

[0068] The portfolio holdings visualization constructor 530 is responsible for generating visualizations related to portfolio holdings using converted color codes and numeric values. Portfolio holdings may be visualized in different ways. FIG. 5(g) illustrates a visualization of the holdings within the portfolio of the user. The table shown in FIG. 5(g) displays a list of holdings in the portfolios wherein each row provides information related to one particular holding. For example, the first column lists the name and maturity of the holding, the second column shows the coupon rate of the security, the third column visualizes the combined converted ratings for the security, and the fourth column indicates the number of this particular bond the user currently has (holds) in his/her portfolio.

[0069] Using converted ratings (either the color codes or the numeric values) for securities in a particular portfolio may also be used to visualize the overall rating of the portfolio and optionally such visualization of the overall credit quality of the portfolio may be visualized in comparison with standard ratings such as the US Treasuries. FIG. 5(h) illustrates such an example, in which the overall credit quality and yield profile of a portfolio is visualized against the overall credit quality and yield profile of both the US Treasuries and the Dow Jones 20 Bonds Index. In FIG. 5(h), each of the three dimensional bar has two sections, one corresponding to the overall credit quality (the lower section of each bar) and the other corresponding to the current yield (the upper section). Each of the overall credit qualities (three) is characterized by both the height of the section and a converted numeric value. The height of the bar is proportional to the value of the converted numeric value. The color of the credit quality bar may also be visualized using the converted color code (not shown in FIG. 5(h)). The overall rating of the portfolio may be computed as, for example, an average across all the converted numeric values of the securities within the portfolio.

[0070] Some of the information visualized in FIGS. 5(g) and FIG. 5(h) may be created based on data dynamically acquired when the user requested the information. For example, the ratings (displayed in a combined fashion with both color code and real values) may be converted based on the symbolic ratings from different sources published (or issued) most recently. Similarly, the current yield for US Treasuries in FIG. 5(h) may also correspond to the most recent applicable rate.

[0071] The interest projection visualization constructor 540 is responsible for generating various visualizations associated with interest information using converted color codes and numeric values of the corresponding symbolic ratings. FIG. 5(i) illustrates a visualization of interest projections related to bonds of different credit qualities within a portfolio. In FIG. 5(i), the first column lists consecutive years (e.g., from year 2002 to year 2023). The next three columns detail the coupon payments for three categories of bonds. One corresponds to a converted rating of 4.5 (the real value corresponding to a color code is displayed on a color block visualized using the color code and the exact color of the color block is indicated using the abbreviation scheme described earlier), one corresponds to a converted rating of 6.0, and the other corresponds to a converted real value rating of 7.5. Each category of bonds yields different interest amounts and is computed by summing the interest payments on the bonds within that credit quality category for that year. The interest received in the different quality categories is then summed to yield the total annual interest in the last column. The last row provides the summed interest over time in the individual credit qualities The last element in the last row sums all the coupon payments for the various credit qualities and years. This number represents the total annual interest (coupon payments) for the investor's portfolio.

[0072] The income/principal projection visualization constructor 550 is responsible for generting visualizations related to income/principal projection information based on color codes or numeric values converted from corresponding symbolic ratings. FIG. 5(j) illustrates a visualization of income/principal projection related to bonds of different ratings within a portfolio. In FIG. 5(j), bonds of three categories of converted ratings are illustrated. The X-axis represents year and the Y-axis represents dollar amount. Different colors represent the payment of income and principal for bonds of different ratings. For each year the different color portion in each bar corresponds to a different rating and the size (height) of that color portion corresponds to the amount of income/principal. For example, in the year 2014 the user receives approximately $320 dollars from interest on securities rated 4.5, approximately $3,780 from interest and principal repayment on securities rated 6.0, and approximately $7,730 from interest and principal repayments on securities rated 7.5.

[0073] Income/principal projection related to bonds of different ratings within a portfolio may also be visualized in a three dimensional representation, as shown in FIG. 5(k). In this exemplary representation, the X-axis (horizontal) represents the year of maturity, the Y-axis (goes into the paper) represents credit quality (expressed in terms of converted numeric values), and the Z-axis (vertical) represents the dollar amount of the coupon and the principal payment. For example, in year 2006, the bonds having rating around 7.0 within the illustrated portfolio will provide income/principal, according to projection, of around $20,000. In FIG. 5(k), the last row along the Y-axis corresponds to the annual total of the coupon and principal payment. The annual total of a particular year may be computed as the total coupon and principal payments for all the bonds of all the ratings.

[0074] The default rate visualization constructor 560 is responsible for generating visualizations related to default rates. FIGS. 5(l) and 5(m) show how numeric rating values, converted based on symbolic ratings from different rating agencies, may be used to visualize the correlation between historical default rates and the ratings from different rating agencies. In FIG. 5(l), the X-axis represents the converted numeric values and the Y-axis represents the percentage of default. The two plots are shown, one representing the relationship between numeric ratings converted based on Moody's symbolic ratings and the other representing the relationship between numeric ratings converted based on S&P's symbolic ratings. The higher the ratings are, the lower the default rates are. For instance, from FIG. 5(l), one can see that, historically, securities rated around 5.5 (converted from both Moody's and S&P) had default rate of approximately 4%. FIG. 5(m) visualizes the same relationships except the visualization is different.

[0075] Numeric rating values may also be used as a criterion in determining the visualization content. This may be particularly useful when different rating agencies provide symbolic ratings that are difficult to harmonize. With a coherent converted rating expressed in a numeric fashion, the scale is well defined. In FIG. 5(n), the behavior of default rates of bonds having a particular rating with respect to the number of years of holding the bonds is visualized. The plot in FIG. 5(n) corresponds to securities that have S&P rating of A which corresponding to a converted numeric rating of 7.0.

[0076] Converted ratings, in the forms of both color code 430 and numerical values 460, may be used in any fashion desired. The illustrated embodiments of various visualizations are described as way of examples instead of limitations. The visualization mechanism 350 may be implemented to generate various visualizations based on a request from the user. According to application needs, the visualization mechanism 350 may be customized to realize different required visualization schemes. The visualization mechanism 350 may be implemented as an application deployed on a device that is capable of supporting computation required for visualization. Such a device includes a general purpose computer, a special purpose computer, a personal computer, a laptop, a personal data assistance (PDA), a cellular phone, or a wristwatch.

[0077] As described, the visualization mechanism 350 may correspond to a collection of visualization tools, each of which may be designed to realize one or more visualization schemes. Different visualization tools may be distributed on more than one device across a network. Such a network represents a generic network which may correspond to a local area network (LAN), a wide area network (WAN), the Internet, a wireless network, or a proprietary network.

[0078] FIG. 6 depicts an exemplary internal structure of the process interface mechanism 370 that activates different mechanisms located outside of the front-end engine 205 based on user's input. The process interface mechanism 370 comprises an input analysis mechanism 610 and a plurality of activation mechanisms including an offering information request activation mechanism 620, a rating information request activation mechanism 630, a market data request activation mechanism 640, an account management activation mechanism 650, and a transaction processing activation mechanism 660.

[0079] Based on user's input, the input analysis mechanism 610 determines which mechanism(s) to be activated and then invokes appropriate activation mechanism(s) accordingly. Each of the activation mechanisms activates one or more mechanisms outside of the front-end engine. During activation, appropriate data necessary for the activation may be gathered, organized, and forwarded to the mechanism to be activated. For instance, to activate account management mechanism (to perform some account management functions), the account management activation mechanism 650 may identify the account number from the user's input and then pass such information to the account management mechanism 265. Similarly, to activate the transaction processing mechanism 270, the transaction processing activation mechanism 660 may extract order related information from the user's input and forward such information to the transaction processing mechanism 270 in order to enable the transaction processing mechanism 270 to proceed with the transaction processing.

[0080] The offering information request activation mechanism 620 may be invoked when the user requests to check information related to certain fixed income securities. For example, the user may specify to examine information related to a particular set of securities identified according to some criteria (e.g., bonds offered that mature in the year 2011). To activate the offering management mechanism 230 to identify requested information, the offering information request activation mechanism 620 may extract necessary data (e.g., the criteria specifying maturity in 2011) to be used in locating the information from the users input and then send such data with the activation signal to the offering management mechanism 230.

[0081] The rating information request activation mechanism 630 and the market data request activation mechanism 640 may forward the identification of relevant securities (e.g., the CUSIPs of the bonds) to the corresponding rating management mechanism 240 and the market data management mechanism 250 when activating such mechanisms.

[0082] FIGS. 7 and 8 describe exemplary internal structures of the offering management mechanism 230 and the rating management mechanism 240. As discussed earlier, the mechanisms within the data collection and management mechanism 225 are capable of collecting data from different sources, analyzing such collected data, and storing and managing the collected data.

[0083] The offering management mechanism 230 depicted in FIG. 7 comprises a communication mechanism 710, a daily offering requesting mechanism 720, a historical data) requesting mechanism 730, an inventory data analysis mechanism 740, and an inventory database management mechanism 750. The communication mechanism 710 facilitates the need of the offering management mechanism 230 to communicate with, for example, the fixed income capital markets, to gather desired information (e.g., offering information).

[0084] The daily offering requesting mechanism 720 is capable of collecting offering data via the communication mechanism 710. The historical data requesting mechanism 730 is responsible for collecting historical data related to certain bonds, via the communication mechanism 710, from various sources. It is possible that both the daily offering requesting mechanism 720 and the historical data requesting mechanism 730 gather data from the same sources. In this case, the two may be implemented as an integrated entity (not shown in FIG. 7).

[0085] The collected data (offerings or historical data) may be stored or forwarded to other mechanisms for presentation purposes. Prior to such uses, the inventory data analysis mechanism 740 may also analyze the collected data to either generate new data or merely organizing the data. For example, useful statistics, such as the average yield by credit rating and maturity, may be computed based on the collected data and such newly generated information may also be stored and used. The inventory database management mechanism 750 is responsible for organizing, indexing, storing inventory related data in the inventory database 235.

[0086] FIG. 8 describes an exemplary internal structure of the rating management mechanism 240, according to embodiments of the present invention. The rating management mechanism 230 comprises a communication mechanism 810, a plurality of rating collecting agents 820 (agent 1 820a, agent 2, 820b, . . . , agent n 820c) that gather symbolic ratings from different sources, a rating data analysis mechanism 830, and a rating database management mechanism 840. The communication mechanism 810 facilitates the need of the rating collection agents 820 to communicate with, for example, various rating institutions 140, to gather desired rating information.

[0087] The rating collection agents 820 are capable of collecting rating related data via the communication mechanism 810. Each of the rating collection agents may be responsible for collecting rating information from a single source (e.g., agent 1 820a is responsible for collecting rating information from Moodys and agent 2 820b may be responsible for collecting rating data from Fitch). Each may be designed differently to interface with different rating institutions. It is also possible to implement a single agent responsible for collecting rating information from all possible sources (not shown in FIG. 8).

[0088] The collected rating information (offerings or historical data) may be stored or forwarded to other mechanisms for presentation purposes. Prior to such uses, the rating data analysis mechanism 830 may analyze the rating information to categorize the gathered information. For example, collected rating data may include both the symbolic ratings as well as their semantic interpretations. Symbolic ratings may be separated from their semantic interpretations (different categories of information) so that ratings and semantic interpretations may be managed more efficiently. Yet, the correspondence between the two may be retained using, for example, appropriate indices.

[0089] FIG. 9 describes an exemplary internal structure of the account management mechanism 265. The account management mechanism 265 may include, but are not limited to, an account registration mechanism 910, a portfolio management mechanism 920, and an account update mechanism 930. The account registration mechanism 910 is responsible for registering new users. This may include creating a new account using information from a new user and initializing the content of the new account such as the portfolio of the new user. The portfolio management mechanism 920 is responsible for managing portfolios corresponding to existing users. The portfolio management mechanism 920 may adaptively update portfolio information according to, for example, credit rating upgrades and downgrades.

[0090] The account update mechanism 930 is responsible for any changes to be made to existing accounts, including deleting an existing account or updating the account information such as address changes. The account registration mechanism 910 may interact with the portfolio management mechanism 920. For instance, when a new account is created, a portfolio may be initially set up through the portfolio management mechanism 920 to allow for the transfer of securities from an account at another brokerage firm. In addition, the account update mechanism 930 may also interact with the portfolio mechanism 920. For example, when an existing account is deleted (closed), the assets in the corresponding portfolio may be transferred so that the portfolio is updated to reflect that.

[0091] All the mechanisms within the account management mechanism 265 interact with the account information storage 260. The account database 260a and the portfolio database 260b may be managed as separate (yet linked) entities or as an integrated entity. The implementation decision maybe made according to application needs or practicality.

[0092] FIG. 10 describes an exemplary internal structure of the transaction processing mechanism 270 for trading fixed income securities. The transaction processing mechanism 270 may include an order processing mechanism 1010, a transaction engine 1020, a portfolio update mechanism 1030, and a transaction reporting mechanism 1040. The order processing mechanism 1010 may receive an order from the user (e.g., forwarded from transaction processing activation mechanism 660 in the process interface mechanism 370, see FIG. 6) for trading certain fixed income securities. The received order is processed to prepare for the transaction. For example, the identification of the bonds to be traded may be extracted from the order.

[0093] The transaction engine 1020 is then activated to carry out the transaction. This may include informing the counterparty of the specifics of the order and the creation of an internal identification number for the order so auditing trails can be established. When the transaction is completed, the transaction engine 1020 may invoke the portfolio update mechanism 1030 to update the portfolio to reflect the changes in the account holdings. The transaction is then reported to an authorized site (e.g., NASDAQ's Transaction Reporting And Compliance Engine or TRACE) through the transaction reporting mechanism 1040.

[0094] FIG. 11 is a flowchart of an exemplary process, in which the user performs operations related to online trading of fixed income securities via the fixed income online retail enabling mechanism 130. The fixed income online retail enabling mechanism 130 first receives, at act 1110, a request from the user. The request is analyzed at act 1120. Based on the type of the request, determined at act 1130, different parts of the fixed income online retail mechanism 130 is activated to facilitate the needs of the user.

[0095] If the request relates to information inquiry (e.g., information related to offerings), the fixed income online retail enabling mechanism 130 presents, at act 1140, requested information in a visual form with converted ratings. More details about the acts performed to present requested information are described with reference to FIGS. 12-15. If the request relates to managing account information, the fixed income online retail enabling mechanism 130 interacts with the user to facilitate the need in managing the account information at act 1150. Details related to specific acts performed to facilitate the management of account information are described with reference to FIG. 16. If the request involves a bond trade transaction, the fixed income online retail enabling mechanism 130 interacts with the user to conduct, at act 1160, a transaction. Details related to how to complete a transaction are discussed with reference to FIG. 17.

[0096] FIG. 12 is a flowchart of an exemplary process, in which the fixed income online retail enabling mechanism 130 visually presents information related to fixed income capital markets to the user. Inquired information related to fixed income capital markets is first collected at act 1210. Data collected may be public information or proprietary information. For example, if the user asks to see information related to current offerings (public information) of fixed income securities, such offering information may be collected. As another example, market data such as commentary information related to certain securities may be collected from different sources. Such market data includes news items, equity prices and press releases relating to a firm whose fixed income security is offered for sale. Such collected public data may also be used to generate proprietary information. For instance, the difference in price between a US Treasury bond (10.0) maturing in 2011 and a 9.5 (AAA/Aaa) bond maturing in 2011 can be collected and proprietary data generated that will help inform an investor when one of these securities is inexpensive relative to the other on an historical basis. Such prediction may be generated within the fixed income online retail enabling mechanism 130 or may be generated by some business partners. Such proprietary prediction information may also be collected at act 1210 as part of relevant data.

[0097] Symbolic ratings associated with the inquired bonds are then obtained, at act 1220, from different sources. To generate effective visual presentation of the inquired information, the symbolic ratings are converted into color codes, at act 1230, and real values, at act 1240. Details related to the conversions are discussed with reference to FIGS. 13 and 14. Other types of information may also be gathered for presentation purposes.

[0098] Based on information gathered so far, such information is aggregated, at act 1250, to satisfy different presentation needs. For example, some presentations may require the display of the original symbolic ratings but some may not. The aggregated data may be further organized, at act 1260, in a certain fashion for display. For instance, a list of offerings may be organized in a sequence arranged according to the descending order of the converted ratings in real value. The same list of offerings may also be organized in a sequence arranged in terms of the alphabetic order of the names of the offering corporations or in descending order of yield to maturity or current yield.

[0099] As alternatives, the information may also be organized in different manners according to the information associated with each offering. For instance, each of the offerings may be associated with a series of information such as symbolic ratings from different sources, converted color code and real value, YTM (yield to maturity), CY (current yield). Different presentations may be constructed by including different types of information. The information is organized according to either the user's preference or some predetermined format. Such organized data is then used for visualizing, at act 1270, the inquired information. Specifics related to visualizing the inquired information are described with reference to FIG. 15.

[0100] FIG. 13 is a flowchart of an exemplary process, in which a symbolic rating obtained from a rating institution is converted into a color code. As discussed earlier, different embodiments of converting a symbolic rating to a color code may be employed. In FIG. 13, the conversion procedure of using a pre-constructed table to achieve the symbolic rating to color code conversion is described. To convert a given symbolic rating into a color code, a conversion table constructed for such purposes is first accessed at act 1310. The conversion table provides specific conversions from symbolic ratings from different rating institutions to color codes.

[0101] To determine a specific conversion, the source of the given symbolic rating is identified at act 1320. Such identified source of the rating and the symbolic rating itself can be used to determine, at act 1330, an entry to the conversion table. For example, given a symbolic rating AAA and the corresponding rating institution S&P, an entry in the conversion table can be uniquely located. The color code stored in such determined entry can then be retrieved, at act 1340, to accomplish the conversion.

[0102] FIG. 14 is a flowchart of an exemplary process, in which a symbolic rating obtained from a rating institution is converted into a real value. As discussed earlier, different embodiments of converting a symbolic rating to a real value may be employed. In FIG. 14, the conversion procedure of using a pre-constructed table is described. To convert a given symbolic rating to a real value, a conversion table constructed for such purposes is first accessed at act 1410. The conversion table provides specific conversions from symbolic ratings from different rating institutions to real values within a pre-determined range.

[0103] To determine a specific conversion, the source of the given symbolic rating is identified at act 1420. Such identified source of the rating and the symbolic rating itself can be used to determine, at act 1430, an entry to the conversion table. For example, given a symbolic rating AAA and the corresponding rating institution S&P, an entry in the conversion table can be uniquely located. The real value stored in such determined entry can then be retrieved, at act 1440, to accomplish the conversion.

[0104] FIG. 15 is a flowchart of an exemplary process, in which the visualization mechanism 350 constructs different visualizations based on information related to different aspects of fixed income securities and converted ratings according to user's choice. The specified choice of presentation from the user is first received at act 1510. For instance, the user may specify to review information related to bond offerings. The visualization mechanism 350 then receives, at act 1515, the inquired information that has been appropriately aggregated and organized (by the data aggregation mechanism 330 and the data analysis mechanism 340).

[0105] Depending on the types of presentation requested (by the user), determined at act 1520, the visualization mechanism 350 performs different visualization operations. There may be different exemplary categories of presentations. One may correspond to visual presentation of information related to a list of bonds. The other may correspond to visual presentation of different properties related to a particular bond. At act 1520, the visualization mechanism 350 may distinguish visualization operations related to visualizing information related to a plurality of bonds from visualization operations related to a particular bond.

[0106] If the user requests to visualize information related to a plurality of bonds, the visualization mechanism 350 may further distinguish whether the requested information is associated with a particular portfolio (e.g., holdings of the user) or corresponds to general bond offerings (e.g., daily bond offerings). Such distinction may be necessary due to the fact that different scenarios may require different presentations. If the requested presentation is based on the holdings of a particular portfolio, determined at act 1525, the visualization mechanism 350 presents visualization, at act 1530, of the holdings to the user. If general offering information is to be visualized, the visualization mechanism 350 visualizes, at act 1535, the offerings with converted rating information to the user.

[0107] Information related to an individual bond may be visualized in different ways, depending on which particular feature of the bond is requested. To request to visualize different aspects of a particular bond, the user who requests the information may or may not hold that bond. That is, the bond whose information is requested may or may not be a holding of the user who requests the information. For example, the user may request to review the life cycle of a particular bond, determined at act 1540. The bond whose life cycle is being visualized may be a holding of the user. The bond may also be simply a current offering (i.e., the user does not have that holding yet). The user may also request to visualize the interest projection of a particular bond, determined at act 1550. Furthermore, the user may like to see the income/principal projection of a specific fixed income bond or the default rates of different bonds according to historical data, determined at act 1560. Information related to other properties associated with a fixed income security may also be gathered and visualized (not shown in FIG. 15). Depending on the specific types of information requested, the visualization mechanism 350 accordingly performs appropriate visualization operations at acts 1545 (visualize life style), 1555 (visualize interest projection), 1565 (visualize default rates), and 1570 (visualize income/principal projection).

[0108] FIG. 16 is a flowchart of an exemplary process, in which the account management mechanism 265 performs different account management operations. According to user's specification, the type of requested account management operation is first determined at act 1605. Three exemplary types of account management operations are described in FIG. 16. If a requested account management operation relates to adding a new account, information about the new account (which may be associated with a new user) is received at act 1610. A new account is then created, at act 1612, for the new user. Information about the new user is used to fill in, at act 1614, the details (e.g., address, social security number, etc.) before the new account is set up, at act 1616, in the account database.

[0109] If a portfolio associated with the account is to be set up, determined at act 1618, a corresponding portfolio is created, at act 1620, for the new account. At the initial stage of creating a new account, the portfolio may still be empty. In this case, a default empty portfolio may be used which may be later updated when trading activities occur. The operation of creating a new account may then be optionally logged at act 1622.

[0110] If the requested account management operation is to delete an existing account, the account to be deleted is accessed at act 1630. The account to be deleted may then be marked, at act 1632, as deleted or inactive. Alternatively, instead of marking the account as deleted, the account may also be physically deleted. The choice of means to delete an account may be determined according to the application requirement.

[0111] There may be additional operations associated with the deletion of an account. For example, if the holdings in the associated portfolio of the deleted account are not empty, the holdings (corresponding to assets) may need to be transferred. Furthermore, other operations that ensure the integrity of the account information may also be performed. For example, if the deleted account is associated with another existing account, such association may have to be removed once the deletion is effective.

[0112] If assets associated with the deleted account are to be transferred, determined at act 1634, the account management mechanism 265 transfers the assets at act 1636. Such transfer makes the portfolio of the deleted account empty. To make the account coherent, the account management mechanism 265 may also perform, at act 1638, other operations such as clearing the portfolio of the account to ensure that the deleted account has coherent information. The account management mechanism 265 further ensures, at act 1640, the integrity of the data in the account database. For example, any association of the deleted account with other accounts may be removed.

[0113] If the requested account management operation is an update operation, the update may be performed to either the information related to the underlying user or the portfolio of the account. The former may occur when, for example, the address of the user changed. The latter situation may occur when, for example, the portfolio of the user needs to be updated due to, for instance, trading activities. The information used to update the account is first received at act 1650. The account to be updated is then accessed at act 1652. Relevant information to be updated (e.g., address of the user) is identified at act 1654 and then updated at act 1656. Whether the portfolio associated with the account is to be updated is determined at act 1658. If changes to the portfolio are required, the portfolio is updated at act 1660. Then, the update operation performed is logged at act 1662.

[0114] FIG. 17 is a flowchart of an exemplary process, in which the transaction processing mechanism 270 performs operations to facilitate online trading of fixed income securities. A trading order is first received at act 1710. The user may issue the trading order, which may include information such as what bond(s) to trade, the counterparty with whom the trade is to take place, the price at which the trade is conducted, and the quantity of the trade.

[0115] To move forward with the transaction, the transaction processing mechanism 270 may perform credit check at act 1715. If the credit check is not satisfactory, determined at act 1720, the transaction processing mechanism 270 may abort the transaction at act 1760. If the credit check is satisfactory, the transaction processing mechanism 270 proceeds with the transaction.

[0116] To complete the transaction, the transaction processing mechanism 270 informs, at act 1725, the specified counterparty of the trade. The trading order is then executed at act 1730. After the execution, the order is confirmed at act 1735. Before completing the transaction at act 1745, the order is cleared at act 1740. As part of the post processing associated with the transaction, the portfolio of the corresponding account is updated at act 1750. To do so, the portfolio update mechanism in the transaction processing mechanism 270 may be invoked to perform the update. Finally, the transaction reporting mechanism 1040 in the transaction processing mechanism 270 reports the transaction at act 1755. The reporting may include both reporting the status of the transaction (e.g., completed or aborted) to the user and reporting the details of the transaction (e.g., what bonds are traded at what price) to some designated authority (e.g., NASDAQ's TRACE).

[0117] While the inventions have been described with reference to the certain illustrated embodiments, the words that have been used herein are words of description, rather than words of limitation. Changes may be made, within the purview of the appended claims, without departing from the scope and spirit of the invention in its aspects. Although the invention has been described herein with reference to particular structures, acts, and materials, the invention is not to be limited to the particulars disclosed, but rather can be embodied in a wide variety of forms, some of which may be quite different from those of the disclosed embodiments, and extends to all equivalent structures, acts, and, materials, such as are within the scope of the appended claims.