Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
  • G06Q40/06—Asset management; Financial planning or analysis

Definitions

• the present invention relates to a system and method for providing convenient and remote access to investment product information, such as summary information and various related program and transactional documents pertaining to past and present investment products offered to investors.
• investment product information such as summary information and various related program and transactional documents pertaining to past and present investment products offered to investors.
• the Internet has sparked tremendous growth in the amount of information available at people's fingertips. As is well-known, such information includes online access to individuals' brokerage accounts for purposes of trading and obtaining information about their investments. Substantial efficiencies can be gained by disseminating investment information electronically via the Internet as opposed to traditional means of paper document delivery.
• Institutional Investors have not benefited as much as retail investors from the growth of the Internet and its information distribution and access capabilities. There are several possible reasons for this. First, the nature and extent of information and documentation on financial products desired by Institutional Investors is far more complicated and sophisticated than consumer financial products, particularly given that the dollar value of a typical transaction is millions of dollars or greater. Second, the distribution channels for such products have been and continue to be distinct from those for consumer financial products.
• the syndicated loan market evolved in the 1970s when large loan facilities were jointly originated and underwritten by a club of agent lenders (i.e., a "lending syndicate"). Although loan terms and structures were negotiable with the lending syndicate, club loans were expensive to borrowers and only marginally profitable to the lenders. With the development of the corporate bond market in the 1980s, corporate borrowers were able to access the capital markets directly. However, these debt facilities were typically not underwritten and terms and structures were invariably less flexible. Disruption of the corporate bond market in the late 1980s and early 1990s led corporate borrowers to seek a more stable and flexible source of debt financing in the form of the syndicated loan.
• the loan In a syndicated loan transaction, the loan is typically negotiated with and underwritten by one or several lenders with full closing and/or commitment fees, and syndicated to many lenders with partial fees, thereby allowing underwriting lenders to generate a fee income and to shed some of their underwriting risk.
• the domestic corporate loan and debt markets includes a number of participants performing various functions including marketing and origination, arranging and underwriting, ongoing loan administration and monitoring, loan syndication and/or debt placements, investment analysis, portfolio management and trading. Information needs within each of these functions center around quantitative and qualitative credit information, historical, interim and projected financial information, loan terms and conditions, and pricing information. Prior to the closing of a syndicated loan facility and/or private placement debt facility, such information and related documents are "living" in that they are not final and subject to several revisions. Some information may also be confidential (e.g., with respect to private companies), or material and non-public (e.g., in the case of public companies), and thus require secure accessibility.
• Agent lenders are required to use manual methods or separate unintegrated systems for information management. As a result, such information often requires double entry, is only partially captured and/or is incompatible between systems.
• agent lenders use contact management systems (such as Microsoft Outlook® and Symantec's ACT) which capture contact details, but do not capture investment appetite.
• Specialized software applications such as Syntrack and LoanRunner®) capture contact detail, investment appetite and syndication status, but do not provide secure and selective access to information or information archives.
• Internet-based application service providers (such as Intralinks®) provide secure and selective access to information, but, among other things, do not provide information archiving or investor appetite functionality.
• Such a system and method preferably should also allow the agent lenders to target their solicitations to a limited number of QIBs, ideally those with an appetite for the type of investment to be considered, and to provide such investors with historical information relating to closed and declined deals so as to enable them to more intelligently make decisions concerning currently offered deals.
• QIBs should be provided with an efficient tool for screening opportunities, managing internal distribution of information on investments under review and archiving information on investments made (and not made) for portfolio management and comparative analysis.
• the present invention overcomes the inadequacies of the prior art and meets the needs of the Institutional Investor community.
• a method of providing investors with remote access via an information portal to relevant financial and other information relating to financial products or deals presently or previously offered to qualified investors is disclosed.
• the method comprises the steps of receiving and storing investor profile information, storing deal information including deal summary information and at least one deal document for each financial product, receiving a user status classification and a document user group classification and/or individual document access classification for each investor invited to participate with respect to each financial product, and providing the investors remote access to the deal summary information based on their individual user status classifications and the deal document(s) based on their document user group classifications and/or individual document access classification.
• deal summary information and deal documents pertaining to past deals are archived and maintained accessible to investors even after the financial product is no longer available for investment.
• investors may optionally choose to be notified by e-mail when new documents relating to a syndication deal are posted to a deal page and such investors can view such new documents automatically by clicking on a link to such deal page.
• an investor's access to new deal information is restricted once such investor has declined to participate in a deal, while such investor's access to previously accessible deal documents is still permitted, i.e., before the investor declined.
• monthly conduit investor reports for ABCP conduits are, if the investor so chooses, automatically disseminated to such investor, e.g., by electronic mail.
• Figure 1 is a block diagram of a system in accordance with one embodiment of the present invention.
• Figure 2 is a block diagram of the server of Figure 1.
• Figure 3A-3I is a chart of tables stored in the database of the server of
• Figure 4A illustrates an exemplary embodiment of a Registration Form for a user to provide profile and other registration information.
• Figure 4B illustrates an exemplary embodiment of an Edit Profile Form for a user to revise profile and other registration information.
• Figure 5 illustrates an exemplary embodiment of a Syndication Deals List Form for providing information to the user regarding syndication deals that the user has been invited for review.
• Figure 6A-6B illustrates an exemplary embodiment of a Deal Summary Form for providing specific information about a particular syndicated deal.
• Figure 7 illustrates an exemplary embodiment of a User Classification Form for an administrator to assign a user a status and/or to a user group.
• Figure 8 illustrates an exemplary embodiment of an ABCP Conduit List Form for providing information to the user regarding ABCP conduits that the user may access.
• Figure 9A-9B illustrates an exemplary embodiment of an ABCP Summary Form for providing specific information to the user about a particular ABCP.
• the present invention is implemented as an information portal accessed through a site on the world wide web, e.g., at http://www.gecapitalmarkets.com.
• Figure 1 shows an embodiment of a system in accordance with the present invention, where a plurality of institutional investors 110 exchange information over the Internet 120 with a server 200 that generally retrieves information relating to presently or previously offered financial products or deals from a database (not shown) and selectively provides such information to the investors 110 based on a number of predetermined criteria.
• the information provided to the investors 110 and the predetermined criteria associated therewith is input over the Internet 120 to the server 200 by a plurality of administrators 130 at content entry desktop stations.
• Each investor 110 and each administrator 130 asynchronously communicates with the server 200 by accessing the htt ://www. gecapitalmarkets . com
• Web site over the Internet 120 using a web-browser (e.g., Netscape® or Internet
• ISP Internet Service Provider
• PDA personal digital assistant
• FIG. 2 is a block diagram showing the architecture of a preferred embodiment of the server 200.
• the server 200 is in actuality a combination of three servers: a web server 210; an application server 220; and a database server 230.
• the server 200 may actually include multiple web servers 210 and application servers 220 clustered together in a unit.
• Servers 210, 220 and 230 each include certain standard hardware components, such as a central processing unit (“CPU") that is linked to both a random access memory (“RAM”) and a read only memory (“ROM”) by means of a shared data bus or by dedicated connections.
• CPU central processing unit
• RAM random access memory
• ROM read only memory
• the CPU performs all of the processing functions of the servers 210, 220 and 230 in accordance with an operating system ("OS"; not shown) that is stored in the ROM and which has multi-tasking capabilities. Because the system is intended for a large number of investors 110 and administrators 130, the RAM is preferably of sufficient size to prevent problems such as slow loading and system failure due to too many connections being attempted to be established at the same time.
• OS operating system
• the web server 210 comprises a cluster of two Sun Ultra 2 servers, each including 1 GB RAM, two 300 MHz CPUs and 9 GB disk space, wherein the requests from the investors 110 and administrators 130 are distributed between the servers by a CISCO LocalDirector 430 load balancer;
• the application server 220 comprises two Sun E450 servers, each including 4 GB RAM, two 400 MHz CPUs and 16 GB disk space, clustered in a load- balancing mode;
• the database server 230 comprises a Sun E450 having 2 CPUs, 2 GB RAM and 9GB disk space and in communication with a database 260, which is stored in both the database server 230 and a fully-mirrored 1000 Redundant Array of Independent Disks ("RAID") having 36.4 GB prior to mirroring.
• RAID Redundant Array of Independent Disks
• the web server 210 indirectly communicates with the investors 110 (or administrators 130) on hypertext transfer protocol ("HTTP") that is secured using a standard secure protocol (e.g., secure socket layer (“SSL”) encryption software) through an input/output communications port.
• HTTP hypertext transfer protocol
• SSL secure socket layer
• an investor 110 gains access to the Internet 120 by means of his ISP.
• the investor 110 requests access to the Web site by transmitting the domain name
• the investor's request is routed through his ISP to a hosting ISP (not shown) associated with the web server 210.
• the hosting ISP in turn routes the investor's request to the web server's communications port via a communication line (e.g., a TI or T3 line). This type of line provides a high speed data connection between the hosting ISP and the web server 210.
• a communication line e.g., a TI or T3 line
• the web server 210 communicates directly with the application server 220 over an internal communications line to an input/output communications port of the application server 220.
• the application server 220 is also connected via an internal communications line with the database server 230.
• the input/output communications ports for the web and application servers 210 and 220 are Cisco 2924 XL switches with redundancy.
• Servers 210, 220 and 230 all include certain software components, such as software servers and software databases, to store information and perform the plurality of requests and transactions.
• the implementation of software servers to execute Internet-directed software in conjunction with a central server is well-known in the art, and the servers' configurations are accordingly not described in detail herein.
• the web server 210 includes a software component that performs the function of acting as a liaison between the investors 110 and the application server 220.
• the web server 210 stores and serves static content to the investors and requests information from the investors 110 as directed by the application server 220.
• the application server 220 includes two distinct software components: the first component 240 is referred to as “Future Tense Java Applogics,” and basically controls the dynamic content logic of the server 200, i.e., updating the database 260, caching HTML and database result sets, and processing searches and content entry; the second component 250 is referred to as “Other Java Classes,” and includes authentication, logging, authorization and other business logic. As shown in Figure 2, the Future Tense Java Applogics 240 component runs on a Future Tense 280 application, and the Other Java Classes 250 component runs on a Netscape Application Server 270 application.
• Figures 3A-3I comprises a chart listing records of tables/variables stored in the database 260 in the preferred embodiment of the invention.
• field 310 of the chart an identifier of the table stored in the database 260 is provided.
• the different variables for which corresponding information is stored are listed in the same record in field 320. All information entered by the investors 110 and administrators 130 during operation of the system is stored in the appropriate table(s)/variable(s) of Figures 3A-3I. n.
• table TCMS_CONTACT (field 330) stores securitization program contacts; table TCMS_CONTACT_TYP (field 332) stores information relating to types of contacts (e.g., dealer, rating, agency, etc.); table TCMS_COUNTRY (field 334) stores country names and codes; table TCMS_CURRENCY (field 336) stores information relating to the currencies of various countries; table TCMS_DEAL (field 338) stores information relating to syndication deals; table TCMS_DEAL_CATEGORY (field 340) stores information relating to syndication deal categories; table TCMS_DEAL_CATEGORY_REF (field 342) stores referencing information relating to the syndication deals; table TCMS_DEAL_SUB_CAT (field 344) stores information relating to syndication deal sub-categories; table TCMS_DEAL_TO_USGRP (field 346) stores relationships between deals
• TCMS_USER_DOC_EMAIL_STATUS (field 385) stores information relating to syndication documents received by investors; table
• TCMS_USER_EMAIL_PREFS_PROGRAM (field 386) stores information relating to e-mails about securitization programs that an investor wishes to receive; table TCMS_USER_GROUP (field 387) stores information relating to user groups; table TCMS_USER_STATUS (field 388) stores the different statuses that can be assigned to investors (e.g., active, disabled, etc.); table TCMS_USER_TO_PROG_ROLE (field 389) stores information relating to the securitization program roles granted to administrators; table TCMS_USR_DEAL_DET (field 390) stores information mapping investors to various syndication deals; table
• TCMS_USR_EMAIL_PREFSJDEAL (field 392) stores information relating to e- ails about syndication deals that an investor wishes to receive; table TCMS_USER_TO_USRGRP (field 394) stores information mapping users to user groups; and table TCMS_USER (field 396) stores information relating to application users (i.e., not database users).
• a user To begin the registration process, a user must first access the Web site home page from which the information is made available (here, http://www.gecapitalmarkets.com). Due to the fact that the investment products described on the Web site involves the offer and/or sale of securities and the parties to the transactions are furnishing confidential information, password protection is used to limit access to certain information to registered users. However, prior to receiving a password, the user must first provide his profile and other registration information.
• FIG. 4A An exemplary embodiment of a form for the user to provide such information (i.e., a "Registration Form") is illustrated in Figure 4A.
• Section 410 contains securities law information and a QIB certification from the investor.
• Section 420 includes fields for the user to provide contact information, such as his name, e-mail address, company name and mailing address.
• Section 430 permits the user to elect to be notified of new or modified documents pertaining to syndication deals.
• the Edit Profile Form generally comprises three sections. Section 460 includes fields for the user to change his contact information, such as his name, address, e-mail address, etc. Section 465 includes buttons for the user to "x" if he would like to be notified via e- mail regarding various investor reports related to corresponding ABCP conduits. Finally, section 470 permits the user to elect to be notified of new or modified documents pertaining to syndication deals.
• the registration process (illustrated in Figure 4A) also requires the user to indicate in a QIB certificate that he meets the requirements of a QIB under SEC regulations.
• an administrator sets the user status as "active" and a password is generated for the user and e-mailed to the user's provided e-mail address.
• the first time the investor logs onto the Web site with his new password he will be required to agree to the specified terms and conditions for access to information. Acceptance of the terms and conditions to the Web site must be made by the user before he will be given access to secured portions of the Web site.
• an authentication page is transmitted to the user the first time the user requests access to a password-protected page on the site. The user must then enter his user name and provided password on the authentication page, which is verified by the system before access is granted to the requested page.
• a user may be temporarily designated inactive if, for example, he leaves his current employer, although he may thereafter be re-activated through his new employer.
• the system also maintains a list of previously rejected users to prevent future access to the site by those users.
• administrators 130 can then invite the user to review certain deal information, such as deal summary information and deal documents.
• deal information such as deal summary information and deal documents.
• the process by which administrators 130 determine which deals and which documents relating to those deals will be made available to the user will be discussed in detail below with respect to Figure 7.
• private debt placements or private equity placements are treated in the same manner as loan syndications.
• the principles and methods set forth herein apply equally to private debt placements, private equity placements and other financial products.
• the Syndication Deals List Form generally comprises three sections. Section 510 includes a drop down menu from which several categories of syndication deals may be selected for display, i.e., "Active deals", “Closed deals”, “Declined deals” and "All deals”. "Active deals” are deals for which the relevant syndication closing date has not passed and which has not previously been declined by the investor. "Closed deals” are deals for which the relevant syndication closing date has passed, but the investor has not previously declined. Such deals may still be available for investment in the secondary or closed primary syndication phase. "Declined deals” are those deals that were made available to the user but were previously declined by the user, regardless of whether the syndication closing date has passed. "All deals” include “Active deals”, “Closed deals” and "Declined deals”.
• the administrator 130 associated with the deal maintains in the database an identification of deal(s) declined by the user and dates on which the deals were declined.
• the user is provided with access to only those deal documents and revisions thereof that existed at the time a specific deal was declined.
• a user who has declined to participate in a given deal is not provided access to revisions made or new documents added to the deal after he has declined.
• the declined user is permitted continued access to those documents that were accessible prior to declining.
• Archived access to declined deal documents is particularly helpful to permit the user to compare information on previously declined deals with those currently offered and available. This feature aids in the user's decision-making process for "Active deals" in which primary syndication is still open.
• the user's selection of deal type in the pull-down menu of section 510 displays deals in that category in section 520, which includes columns to show the next milestone, name, deal size, deal purpose and general industry of each of the deals.
• Each of the deal names are hyper-linked to a Deal Summary Form corresponding to the deal, which will be discussed in more detail below with respect to Figure 6A-6B.
• Section 530 comprises hyper-links to forms for editing the user's profile, changing his password and logging out. Also included is an expandable list of deals in their respective categories which provides an alternate form of navigation to the Deal Summary Forms. However, prior to the user's first time viewing any of the specific information for a deal, the user is presented with a confidentiality agreement specific to the deal, which is an addendum to the master confidentiality agreement previously discussed. Once the user has indicated acceptance of the agreement, the user may proceed directly to the deal information upon subsequent sessions.
• An exemplary embodiment of a Deal Summary Form is illustrated in Figures 6A-6B.
• Sections of this form provides the important details of a specific deal, including: the deal name in section 610; a summary of the deal, including a description of the industry, company, market position and/or financing purpose in section 620; total facility amount and relevant launch/meeting/commitment/closing dates in section 630; basic financial information for the company seeking the financing, such as summary credit statistics, in section 640; the tranches included in the deal as well as an indication of their types, terms, and a brief description of each, in section 650; a listing of documents relevant to the offer that are available for download, such as an information memorandum and a financial projections model, in section 660; a listing of analytical tools that are available for download, such as a sample cash flow model, in section 670; a listing of legal documents that are available for download, such as a draft credit agreement and exhibits and final execution documents, in section 680; and other information available for download, such as an allocation memo and a hyperlink to the company's Web site, in section 690.
• a particularly useful aspect of the Deal Summary Form is an option presented to the user to receive e-mail notification of changes to the deal documents (not shown). Due to the fact that it is not uncommon for deal documents to be revised several times before a deal is closed, or for additional deal documents to be made available, providing the user with convenient access and notification of document revisions and additions is particularly advantageous. Thus, a link is provided to permit users to edit their user profile either to activate or deactivate e-mail notification of document revisions.
• An additional feature of the deal detail screen is the ability to permit the user to send an e-mail to the designated deal contact for the specific deal (also not shown).
• An administrator 130 responsible for a specific deal determines which users will be invited to participate in the deal. In one embodiment, this may be done simply by contacting users by telephone to determine if they have an interest in a specific deal. In alternate embodiments, users may provide specific information in a profile concerning the types of deals they are interested in, which profile information can then be matched to specific deals so as to automatically invite certain users to specific deals. Similarly, information on the specific deals users previously invested in may be used to match them to new deals. In other words, the system may be configured to "learn" a user's preferences based on past experience and use this learned data to determine which new deals to invite the investor to participate in.
• Figure 7 illustrates an exemplary embodiment of a form used by an administrator 130 to add the user to a specific deal (i.e., a "User Classification Form").
• This form appears to the administrator 130 after the user has been chosen to be added to a specific deal.
• Section 710 of this form includes a "Status" portion for the administrator 130 to classify the status of the user for the deal.
• the status categories include: "Active,” “Committed,” and "Declined.”
• the user status for a particular deal dictates the category of the deal for purposes of his Syndicated Deals List Form of Figure 5.
• “Active” status means that the deal will be identified as an “Active deal” before the syndication closing date and a “Closed deal” after the syndication closing date, provided the user has not declined the deal.
• “Committed” status means that that the user has agreed to participate in the deal and the deal will also be identified as an “Active deal” before the syndication closing date and a “Closed deal” after the syndication closing date.
• “Declined” status means that user has rejected the deal, and the deal is identified as a "Declined deal” both before and after the syndication closing date.
• Adding a user to a deal only provides the user with access to the deal summary information, but not any of the deal documents described above in connection with Figures 6A-6B.
• the user must be separately authorized access to deal documents by the administrator 130. This provides an advantage, because it permits the administrator 130 to first determine if there is any serious interest by a specific investor before providing access to confidential and potentially sensitive deal documents. Furthermore, it provides substantial flexibility to the administrator 130 with regard to controlling access to the various documents associated with a syndication deal.
• section 720 of the User Classification Form allows the administrator 130 to permit access to deal documents on a user group basis.
• Each user group may be allowed access to different sets of deal documents as determined by the administrator 130, and all assigned members of the user group automatically receive viewing permission or access to the deal documents associated with that group.
• Non-investors e.g., administrators
• Users may also be granted access to documents on an individual document basis.
• the administrator 130 may make documents available to users by designating them as available to one or more groups and/or one or more investors. Providing access on a document-by-document basis allows for significant flexibility in distribution of deal documents. However, once a user's status becomes "Declined,” he is not permitted access to any new documents pertaining to the deal, but is permitted continued access to those documents for which permission was previously granted prior to declining.
• the investor classification and document permission aspects of the present invention personalize each investor's display of syndicated deal information. Each user can be permitted access to a different set of deals, and to different sets of documents for the deals. In this manner, the invention provides substantial flexibility to administrators 130 in disseminating and controlling access to deal information by allowing them to readily keep track of the specific documents made available to each
• the user If the user has elected to be notified by e-mail about new or modified syndicated deal documents, he will receive an e-mail in the event that he is granted individual permission to view a document, he is added as a member of a document user group that contains documents or a new document has been added to a document user group of which he is a member.
• the e-mail will notify the user that a document has been made available for review by the user and will further contain a link to the Web site home page (http://www.gecapitalmarkets.comJ.
• Administrator Classification Administrators 130 are also classified into groups that control the permissions they receive to perform certain activities. For example, a “super user” has full permission to add/delete users and add or change the documents for any deal. A “deal owner” can perform these same functions but only for the specific deal(s) he owns. A “sales desk” administrator can add or delete investors from a deal and change their status and user group memberships. A “syndication super viewer” has the ability to view all of the deal summary information and documents that are available to investor-users.
• a benefit of this classification system is that it permits a centralized building of knowledge with regard to all deals.
• the system and method of the present invention also provides for archiving of deal documents and summary information.
• An active user maintains access to all the information and documents that were previously made available to him.
• ABCP Asset-Backed Commercial Paper
• FIG. 8 An exemplary embodiment of a form for providing a listing of asset- backed commercial paper conduits (i.e., "ABCP Conduit List Form") is illustrated in Figure 8.
• Password protection is also implemented to access this page as well as linked information providing more detail concerning each conduit.
• a user has logged on to the general Web site by inputting his user name and password, it is not necessary to re-enter this information when navigating between ABCP screens and syndication deals.
• Section 810 of the ABCP Conduit List Form includes general information regarding asset-backed commercial paper and summary information concerning the specific programs or conduits available. Summary information for the various conduits available includes: the name of the conduits; the dates the conduits were established; the ratings assigned to the conduits by ratings agencies (e.g., Standard & Poors and Moody's); the asset types that secure the financing for the conduit; the date as of which the information is current; and the outstanding commitments and commercial paper, both in dollars. Also included are hyper-links to the ABCP Summary Forms where each of the conduits is described in detail (discussed below with respect to Figure 9A-9B). Section 820 provides the user with edit profile, change password and log-out options as discussed above. Hyper-links are also provided to the ABCP Summary Forms for each of the specific conduits.
• FIG. 9A-9B An "ABCP Summary Form" for a representative conduit (i.e., ABCP #1) is illustrated in Figure 9A-9B.
• This form generally includes: the name of the conduit in section 910; general program information regarding the conduit, including a brief description, in section 920; edit profile, change password, log-out, e-mail notification options and hyper-links to the ABCP Summary Forms for each of the specific conduits in section 930; the date as of which the information is current, the program limit, outstanding commercial paper, and outstanding commitments in section 940; monthly report information available for download in section 950; and miscellaneous information available for download, such as a program overview, a private placement memorandum and a credit and investment policy, in section 960.
• the monthly reports provide summary program information, including updated data regarding the total number of sellers/borrowers, total fundings outstanding, total commercial paper outstanding and total program letter of credit.
• the conduits are divided into pools of sellers/borrowers, and the reports further include information concerning the various sellers/borrowers, including industry, S&P and Moody's ratings, maximum facility limit, fundings outstanding, asset type and payment terms, and other information.
• Centralized access to archived monthly reports permits investors to readily track the performance of the conduit.
• Hyper-links to the ratings agencies' Web sites may also be provided on the ABCP Summary Form (not shown).
• a hyper-link to provide the user with access to broker/dealer information so that users can initiate transactions may also be provided (not shown).
• Additional buttons can be included to provide the user with access to contact information at the rating agencies and broker/dealers and answers to frequently asked questions (FAQ).
• the monthly conduit investor reports and other documents relating to the ABCP conduits may be made available for download in different formats, such as pdf format or a word processing format (e.g., Microsoft Word) Additional aspects that may optionally be included in systems and methods of the present invention are discussed below.
• the system and method of the present invention may further include the capability to keep track of the total book for all of its deals (known as "book- building").
• This book-building function includes an accounting of how much money has already been committed for each deal and by whom, and the amount of additional commitments required before the deal can be closed.
• This information is generated into a report, which shows the status of sales efforts on a deal-by-deal basis.
• reports may be generated on an investor-by-investor basis to review the history of an investor's past investments.
• the system and method of the present invention may further include the capability to receive and process feedback and market soundings regarding transactions over the Internet 120 from users 110. This eliminates the need for administrators 130 to have to make numerous phone calls to gather data on the likely performance of a transaction in the market. It will also preferably provide users 110 with an opportunity to suggest changes to the transaction structure that they believe will make the deal more marketable. From a business standpoint, the functionality provides a significant competitive advantage through greater data accuracy and speed in generating market intelligence. On-line Commitments & Auctions
• the system and method of the present invention may further include the capability to receive on-line bids from users 1 10 for transactions. Such bids can be submitted without any changes to the term sheet, or can be submitted dependant upon acceptance by administrators 130 of user-added conditions.
• This bidding system provides a significant competitive advantage through increased speed in execution of transactions.
• This functionality also preferably allows the system to hold auctions where multiple users 110 can bid on transactions. The users 110 can be advised in real-time of the best current bids on the deal, thereby allowing them to increase their bids. Report Generation
• the system and method of the present invention may further include the capability for administrators 130 to generate different types of reports relating to investor activity.
• Reports may be generated in any number of ways using the database of current and archived deal information. Reports may be generated on an individual deal basis, an individual investor basis, or a QIB basis, i.e., using the affiliation of individual investor users.
• One example is a report that permits an administrator 130 to select a particular deal document or group of deal documents relating to a financial product and receive a report of all of the investors who have accessed the document(s) within a specified time period. This capability provides one means for the administrator 130 to monitor investor interest in the financial product.
• Another type of report is an investor status report, which allows an administrator 130 to select an investor and receive a report indicating the investor's status (i.e., active, committed or declined) for each deal in which the investor has been invited to participate.
• the administrator 130 can utilize this information for marketing purposes, e.g., to direct his efforts towards investors having a history of participating in deals offered to them. Reports based on QIBs or individual investor affiliation are useful to track the success of sales efforts.

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Finance (AREA)
• Accounting & Taxation (AREA)
• Development Economics (AREA)
• Operations Research (AREA)
• Game Theory and Decision Science (AREA)
• Human Resources & Organizations (AREA)
• Entrepreneurship & Innovation (AREA)
• Economics (AREA)
• Marketing (AREA)
• Strategic Management (AREA)
• Technology Law (AREA)
• Physics & Mathematics (AREA)
• General Business, Economics & Management (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Priority Applications (3)

Applications Claiming Priority (2)

Publications (1)

Family

ID=24638913

Family Applications (1)

Country Status (4)

Cited By (1)

• 2001
  • 2001-08-28 JP JP2002524855A patent/JP2004528612A/ja active Pending
  • 2001-08-28 WO PCT/US2001/026956 patent/WO2002021311A2/fr active Application Filing
  • 2001-08-28 AU AU2001286906A patent/AU2001286906A1/en not_active Abandoned
  • 2001-08-28 EP EP01966386A patent/EP1317717A1/fr not_active Withdrawn

Also Published As

Similar Documents

Legal Events