WO2000046717A9 - Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente - Google Patents

Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente

Info

Publication number
WO2000046717A9
WO2000046717A9 PCT/US2000/002776 US0002776W WO0046717A9 WO 2000046717 A9 WO2000046717 A9 WO 2000046717A9 US 0002776 W US0002776 W US 0002776W WO 0046717 A9 WO0046717 A9 WO 0046717A9
Authority
WO
WIPO (PCT)
Prior art keywords
financial
scenario
information
date
modeling
Prior art date
Application number
PCT/US2000/002776
Other languages
English (en)
Other versions
WO2000046717A8 (fr
WO2000046717A2 (fr
Inventor
Ladislav V Belcsak
Luke Lee
David J Collop
Mark R Bewsher
Thadeus H Niemira
Dennis D Moritz
Stephen G Cohn
Original Assignee
Babcock & Brown Inc
Ladislav V Belcsak
Luke Lee
David J Collop
Mark R Bewsher
Thadeus H Niemira
Dennis D Moritz
Stephen G Cohn
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Babcock & Brown Inc, Ladislav V Belcsak, Luke Lee, David J Collop, Mark R Bewsher, Thadeus H Niemira, Dennis D Moritz, Stephen G Cohn filed Critical Babcock & Brown Inc
Priority to EP00908458A priority Critical patent/EP1175654A2/fr
Priority to CA002361206A priority patent/CA2361206C/fr
Priority to US09/530,040 priority patent/US6957191B1/en
Priority to AU29795/00A priority patent/AU772639B2/en
Publication of WO2000046717A2 publication Critical patent/WO2000046717A2/fr
Publication of WO2000046717A9 publication Critical patent/WO2000046717A9/fr
Publication of WO2000046717A8 publication Critical patent/WO2000046717A8/fr
Priority to US11/102,638 priority patent/US20050182709A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION 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/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06Asset management; Financial planning or analysis

Definitions

  • the present invention relates to an automated tool for modeling the cash flows of financial scenarios, which typically involve use of at least one financial instrument, between various parties to a financial transaction by providing analysts with the ability to graphically represent the parties to the transaction, and their complex interrelationships in a manner that simplifies analysis of various options for completing the deal.
  • the instant invention is directed to a modeling tool that analyzes various aspects of a proposed financial arrangement between parties to the transaction on the basis of information provided through a high level graphical user interface, and prepares competitive financial proposals, structures the proposals in an optimal manner, and which may further be used to manage and administer the final transaction to ensure compliance and delivery of the financial benefits determined by the tool.
  • the computer has become a critical tool for financial analysts whose job it is to analyze extremely complex financial transactions such as leveraged leases.
  • the computer allows the numerous variables in such transactions to be manipulated and analyzed in a fraction of the time required for these calculations to be performed by hand.
  • software designed for the particular application is needed.
  • Such software is often referred to as a "tool.”
  • Certain software tools for financial analysis of complex transactions have been developed; however, they have inherent limitations and are very difficult to use for a number of reasons, including, for example, their inflexibility in altering existing models, their requirement of complex commands and codes for building and modifying a proposed model, and their inability to manipulate a financial structure at the higher level of an overview.
  • the invention described herein was designed to overcome the problems with these earlier tools and represents a major advance in the field of financial engineering and analysis.
  • the invention incorporates extremely sophisticated aspects of computer aided design (CAD) resulting in a graphical user interface unique to financial analysis.
  • CAD computer aided design
  • this novel approach gives the analyst the ability to see partial results when building a model, provides the financial analyst with dynamic overviews (pictures) of the financial structure that can be directly manipulated to alter the financial structure, and provides an object-oriented distinction between high level structure and financial details which allow the user to defer details until they become available or relevant.
  • an important part of the invention is a computer software engine which has been designed to automatically obtain and generate information relating to a particular financial transaction or scenario in response to inputs from the user.
  • the software engine and the CAD-like graphical user interface have been designed to work cooperatively together in order to create a graphical representation of the particular transaction or scenario on the screen of the analyst's computer.
  • the system is designed to allow the analyst to cause this graphical representation to be manipulated, modified or revised so that information useful to many different aspects of the transaction or scenario can be quickly and easily obtained.
  • the end result is a system that is easy to use, extremely flexible and far more efficient than prior financial analysis tools.
  • ABC has been used by analysts to generate various alternatives within the constraints of a particular financial instrument and optimize the results so that analysts can generate a deal that is acceptable to all parties to the transaction.
  • One such commonly used financial instrument is referred to as a multiparty leveraged lease.
  • multiparty leveraged lease There are various other proprietary systems that provide such automated financial analysis.
  • the present invention provides a much more user friendly, flexible tool incorporating easy to understand graphics and interfaces to enable more efficient and practical application of the tool.
  • the invention provides a financial modeling tool that addresses model complexity with a graphical CAD-like approach to financial and/or mathematical modeling, which facilitates, among other things: the ability to see partial results while building a model; a short learning curve; the ability to make changes when the user views the results of the analysis; flexible "point and click" interfacing; easy handling of indexed data; integrated and automatic handling of certain variables, e.g., taxes and accrual; menu of building blocks, e.g., loans, rents, fees, purchases, etc.; menu of built in reports; and an interactive and intelligent graphical representation of the model.
  • a software engine hereinafter referred to as "engine” is provided in the tool and is programmed to automatically obtain and generate information on a financial scenario in response to the user creating a graphical representation of the scenario with the CAD-like user interface.
  • the manipulation of the graphical user interface to generate a visual representation of the scenario automatically results in the generation of information, such as formulas, objects, templates, timelines, calculations, constraints, parameters, optimizable parameters, cash flows, reports, or any other suitable information that is helpful in modeling the scenario represented by the visual representation created by the user using the CAD-like interface.
  • the information generated preferably at least partially model at least a portion of the scenario.
  • the interface After drawing a scenario, such as a proposed financial deal, using the interface, the interface enables the user to enter data and formulas, edit the information automatically generated by the engine in response thereto, and to further define the scenario in a manner which enables the engine to fully model and analyze the scenario.
  • the tool gives the user the ability to instruct the engine to attempt to optimize the scenario, either directly or by creating formulations to be optimized and passing the formulations to a separate optimizing program.
  • the results can be viewed by the user using the interface.
  • the scenario can also be modified by the user and new results based on the modification can be viewed.
  • the engine automatically modifies the information previously generated in a manner which corresponds to the modification to the visual representation.
  • a financial transaction modeling and analysis tool which includes: a graphical user interface which enables a user of the tool to create a graphical model of a financial scenario, generally including at least one financial transaction, on a display screen; and an engine operable, in response to creation of the graphical model, to generate information which at least partially models at least a part of-the financial scenario using information collected by the engine during creation of the graphical model.
  • the graphical user interface preferably enables the user to create party graphics respectively representing parties to the financial scenario, and to generate financial instrument graphics representing financial instruments, wherein each financial instrument graphic connects two of the party graphics.
  • the party graphics and the financial instrument graphics define the graphical model of the financial scenario.
  • the financial instrument graphics indicate a direction of flow, relative to the financial instrument represented thereby, between the parties connected by the financial instrument graphic.
  • the engine generates, in response to the creation of a graphical model, an instrument information, such as an instrument object or template, for each of the instruments in the graphical model.
  • an instrument information such as an instrument object or template
  • the graphical user interface enables the user to interact with the instrument information, such as adding scenario specific instrument data to each of the instrument objects generated by the engine.
  • the instrument data entered in connection with the instrument object constitutes either a fixed part of the financial scenario or a variable part of the financial scenario.
  • the graphical user interface also enables the user to enter and define date information relating to the financial transaction for use by the engine.
  • the graphical user interface is operable to display the date information in graphical form on the display screen.
  • the tool preferably enables the date information to be entered using a natural date language, wherein the engine is operable to process the date information from the natural date language.
  • the graphical user interface enables the user to modify the graphical model of the financial scenario, and the engine is operable, in response to the modification of the graphical model, to modify the information previously generated in accordance with the modification of the graphical model.
  • the engine is operable, in response to the creation of the financial instrument graphic, to define roles for parties represented by the party graphics connected by the financial instrument graphic, wherein the roles are used by said engine to define the parties interaction with the financial instrument represented by the financial instrument graphic when modeling the financial scenario.
  • the engine is preferably operable to determine and display an optimal solution or result for the financial scenario relative to at least one of the parties thereto, and to calculate optimal values for each of the variables defined by the instrument data based on the optimal solution.
  • the financial transaction modeling and analysis tool of the instant invention preferably includes an extensible library of predefined financial instruments, and the graphical user interface enables the user to select and use one or more of the predefined instruments during creation of the graphical model of the financial scenario.
  • numerous common and canned financial instruments are provided to the user to facilitate easy modeling of common transactions that may be used in financial scenarios.
  • the engine is operable, in response to creation of each of the party graphics to generate a party-specific information on the party, and the graphical user interface enables the user to retrieve and modify the information in the party-specific information.
  • the graphical user interface includes a worksheet section, also referred to herein as "smart paper," which enables the user to input scenario information which is independent of or supplementary to the date and instrument information relating to the financial scenario, and the engine is operable to use the scenario information when modeling the financial scenario.
  • the instant tool includes a formula language for use in creating the scenario information, wherein the formula language includes a library of predefined functions and keywords which can be used by the user when creating the scenario information.
  • the worksheet section is preferably a non-cell based, outline based interface for inputting data and formulas in an outline format. More particularly, the worksheet, also called "smart paper" herein, is a non-cell based calculation interface wherein references are based on a hierarchical outline rather than a position reference. In a preferred embodiment of smart paper, the interface enables one formula per row to be defined in an outline-type format.
  • the engine is preferably operable upon entry of scenario information, such as deal formulas, in the worksheet section to establish links between related scenario information and between scenario information and date information, thereby establishing a dependence therebetween, and further wherein the engine is operable to use the links when modeling the financial scenario.
  • scenario information such as deal formulas
  • the tool includes a library of predefined worksheets for use in the worksheet section, and the graphical user interface enables the user to select predefined worksheets from the library for use in the worksheet section.
  • the instant tool also enables a plurality of possible outcomes to be modeled based on different information provided by the user.
  • the graphical user interface is presented on the display screen in a book-like configuration in which a plurality of different sections of the graphical user interface are represented by different chapters in the book-like configuration, each of the chapters having a tab graphic associated therewith, wherein upon selection of the tab graphic by the user, the user interface is operable to display the chapter associated therewith.
  • the tab graphics are located along a side of the display screen, and each chapter may include a plurality of pages, the pages having page tab graphics which are also displayed to the user when a chapter having the pages is selected by the user.
  • the graphical user interface enables the user to view two of the chapters simultaneously in a split-screen format on the display.
  • the engine is preferably operable to update information in each chapter in response to changes made by the user in a chapter.
  • the chapters include a diagram chapter for creating the graphical model, a parties chapter for providing data relating to the parties, a time chapter for viewing and editing dates associated with the financial deal, an instruments chapter for viewing and editing instrument data, a worksheet chapter for enabling the user to define scenario information or formulas relating to the financial scenario, an optimization chapter for use in optimizing the financial scenario, a payment chapter for viewing payment flows in the financial scenario, and a reports chapter for enabling reports to be generated relating to the financial scenario.
  • FIG. 1 is a block diagram showing the major components in the modeling and analysis tool of the instant invention
  • FIG. 2 is a flow chart showing the main functions and steps involved in using the modeling and analysis tool of the instant invention to model and analyze a financial scenario;
  • FIG. 3 is a flow chart showing the main steps used to create a graphical model of a financial scenario, in accordance with the instant invention
  • FIG. 4 is a flow chart showing the main steps used to create a worksheet, also referred to as "smart paper", for use in connection with modeling of the financial scenario, in accordance with the instant invention
  • FIGS. 5-12 show, in a split screen format, exemplary information that is automatically generated by the engine in various chapters of the instant tool in response to creation of the exemplary graphical representation of a financial scenario shown in the Payment Diagram chapter.
  • FIG. 13 shows a graphical diagram of an exemplary financial deal created in accordance with the instant invention.
  • FIG. 14 shows a party graphic being made in the parties chapter as a first step in modeling the deal of Fig. 13, in accordance with the instant invention
  • FIG. 15 shows a further step in creating a graphical modeling the deal of Fig. 13, wherein two parties and a financial instrument are shown, in accordance with the instant invention.
  • FIG. 16. shows date information related to the exemplary deal of Fig. 13 being displayed in the time organizer chapter of the graphical user interface of the instant invention.
  • FIG. 17 shows another view of the time organizer of Fig. 16, where an early buy-out option is displayed
  • FIG. 18 shows a view of the instruments chapter containing data relating to the exemplary deal of Fig. 13;
  • FIG. 19 shows an enlarged, partial view of the display screen of Fig. 18, wherein the interest rate is being modified
  • FIG. 20 shows a view of the smart paper chapter of the instant invention containing information from the exemplary deal of Fig. 13
  • FIG. 21. shows the constraints sub-chapter of the optimization chapter of the instant invention, containing information from the exemplary deal of Fig. 13;
  • FIG. 22 shows an exemplary report produced in the reports chapter of the instant invention based on the exemplary deal of Fig. 13;
  • FIG. 23 shows the payment organizer chapter of the instant invention containing information on the exemplary deal of Fig. 13.
  • FIGS. 24-29 show example uses of the smart paper feature of the instant invention.
  • Fig. 1 shows an overview of the main elements which comprise a preferred embodiment of the financial scenario modeling and analysis tool of the present invention. More particularly, as shown in Fig. 1 , the tool 10 includes a user interface 12 which preferably enables both builder users 16 and end users 18 to interact therewith, a software engine 14, an optimizer system 20, which is preferably a software package known as CPLEX Optimization (version 6.0) offered by CPLEX, ILOG CPLEX Division, but any other suitable optimization software may be used, file I/O and support functions 22, output device(s) 26 such as a printer, and a hard disk 24 or other storage device for use in storing information and data provided with the tool 10 and input by the users thereof.
  • CPLEX Optimization version 6.0
  • the engine 14 performs all calculations when modeling a deal using the tool, including parsing of the formula inputs.
  • the engine 14 also reduces the data representing the deal into an abstract form for submission to the optimizer 20 in order to perform optimization functions for the deal.
  • the user interface 12 and the engine 14 are the main elements of the present invention and will be described in greater detail below.
  • Smart Paper - is one of the chapters in the user interface of the tool. Smart Paper is a non-cell based calculation interface wherein references are based on a hierarchical outline as opposed to a positional reference. Smart Paper is also referred to herein as a "worksheet.”
  • Party - represents a potential (or actual) participant in a financial transaction or scenario, and as such its meaning is close to that of colloquial English. Parties connect to the roles of instruments to define the financial interactions among the parties.
  • Instrument - is a tool object that encapsulates an atomic financial transaction among a pair of parties, including the tax consequences and classification of the transaction (e.g. rental payments).
  • Role - is a party connection point of an instrument that defines how the party interacts with the instrument.
  • Key Date - is a globally available date defined by the user in the Time Organizer.
  • Date Stream - is a chronological pattern of dates that defines both discrete dates and their relationship to time periods.
  • Timeline - is a globally available Date Stream defined in the Time Organizer that can be used for synchronizing payments and data throughout a user's model. Decision - represents a "yes or no” option at some point in time that is available within the transaction being modeled with the tool, wherein the tool then tracks both the "yes” and "no" results.
  • Outcome - is the result of some specific set of assumptions regarding Decisions, i.e. a specific assumption as regards the "yes” or “no” of each Decision (see also ACOE below)
  • ACSOE Alternative Courses of events - is the full set of possible Outcomes in a model, all of which are active within the model.
  • a deal or scenario may include the leasing of an airplane over 20 years where the lessee has the option to buy the plane after 10 years.
  • One outcome of the case is the 20 year lease, the other would be the 10 year buy out option.
  • Decision Handler - is the mechanism within Instruments that defines the action for a "yes" Decision.
  • Parameter - is a piece of information within a case which has a name, a mathematical formula, and a value.
  • the value can be a number, date stream, formula or other item.
  • Case - A case is a single file created with the tool which has all the different elements of a single deal or scenario.
  • the tool 10 provides a graphical CAD-like interface which is used to model the flow of financial instruments and data between various parties to a financial scenario, including individual, corporations, institutions and/or the like.
  • the tool enables users to visually define the parties involved in the scenario and, for example, the flows of money and assets in the form of a graphical model of the scenario. Parties are preferably represented by boxes which display the name of the party. Arrows are preferably used to represent the flows of instruments.
  • the tool provides an interface which enables the user to create various reports relating to the model generated for the scenario. These reports include, for example, the flow of instruments and assets over various time periods.
  • the tool enables the scenario to be optimized. For example, the deal may require that a party obtain a return on investment of at least 5%. The party may desire an even greater return provided all other aspects of the model of the scenario are satisfied.
  • constraints of the model are known as constraints of the model.
  • the process of optimization involves creating the best model which satisfies all such constraints and determines the best possible model based on the requirements and goals of the parties.
  • the instant tool enables optimization against a number of constraints that may exist in the scenario.
  • the tool operates in two basic modes: build mode and end user mode.
  • build mode the user creates the definition of certain aspects of the tool, such as creating instruments which model real world financial instruments. These instruments are then stored in the tool for use by end users when modeling a scenario using the tool.
  • the builder user provides a library of "canned" instruments which can be used by the user to more easily and efficiently model the scenario with the tool.
  • the instruments involve a set of inputs and calculations based on those inputs.
  • the end user incorporates the built instruments into a model and supplies the real inputs corresponding to the actual deal that is being modeled.
  • the build user mode also enables the builder user to create calculation templates to be used by the end user in conjunction with various instruments. Fig.
  • the first step 30 is for the user to draw a graphical diagram of the scenario using the CAD- like user interface section of the tool. Once the diagram is drawn, the next step 32 is to define and modify dates relating to the scenario. Once the dates are defined, the next step 34 is for the user to modify data and numbers in a worksheet section, also referred to herein as "smart paper", in order to provide all of the information necessary to model the deal.
  • step 40 the user can generate reports (step 40) using a reports section or chapter of the tool, and then the scenario or deal can be presented (step 46) to the client or the person contemplating participating in the deal.
  • step 44 the user can review all of the input (step 44) and edits or modify the deal as needed to make the deal acceptable. If optimization is desired, the user can run the optimizer (step 42) and then review the optimized deal. If the optimized deal is then acceptable, the user can run reports and present the deal to the client (steps 40 & 46).
  • one step involved in modeling a deal using the tool of the instant invention involves creating a party diagram (step 30) or graphical model of the deal.
  • Fig. 3 shows flow chart of the steps involved in creating this graphical model.
  • Fig. 4 shows the preferred steps involved in creating smart paper or a worksheet in step 34 of Fig. 2. It is noted that the flow charts of Figs. 2 and 3 are self- explanatory. Thus, no further explanation of the particular steps in the flow charts of Figs. 3 and 4 are provided at this time. However, further details regarding model creation and smart paper use are provided below.
  • GUI graphical user interface
  • the GUI may be implemented using Windows 98, Windows NT, MAC, or it may be Web-based.
  • the instant system may be implemented on any suitable standalone, networked or web-based platform.
  • the tool can be implemented using the following hardware, however any suitable hardware may be used in accordance with the invention: - A Pentium compatible machine running Windows NT 4 with service pack 3
  • Actuate reporting modules including all DLL's and OCX's (Actuate is a commercially available reporting technology)
  • the instant invention preferably uses a book-like display as a viewing device. More particularly, the invention displays its data as pages in a familiar-looking tabbed notebook configuration on the display screen. Each tab of the notebook represents a "Chapter", corresponding to one part of system's functionality. Users can work with one copy of the book visible (see Figs. 14-18 and 20-23), or with two copies visible at once (see Figs. 5-12). Viewing two copies of the book lets the user see related "pages" in both chapters simultaneously. When two book copies are visible, the books can turn each other's pages, so the user can click on a model component in one book to see more detail about that component in the other book.
  • the user should never be more than a couple of clicks away from seeing any part of the model or system.
  • the GUI is designed so that the user never feels lost inside the program.
  • the first chapter in the GUI is the Payment Diagram (see Figs. 14 and 15), which provides a graphic boxes and arrows overview of the relationship among parties and instruments, as well as the payments the parties make to one another. This is valuable because ideas for financial structures are often presented as boxes and arrows drawn on paper.
  • the payment diagram provides an analogous representation. However, as explained herein the payment diagram represents much more than simply a graphic diagram. The user can control or create the program's model by modifying the picture or graphical representation of the deal shown in the payment diagram.
  • the GUI provides for instantiation and deletion of parties.
  • the user can drag-and-drop a box onto the diagram to create a new model participant, and can delete a box to remove a model participant.
  • the GUI provides for instantiation and deletion of arrows representing financial instruments which, in turn, represent payments made by one participant to another, and/or represent the tax effects of those payments.
  • the user can rearrange who pays what to whom by moving the instrument arrows from one box to another.
  • the GUI also enables selection of an overview by possible outcome. In other words, in transactions with several contingencies, it is often helpful to show only those payments contingent on a particular decision path.
  • the user can rearrange the participant boxes on the diagram using a drag-and-drop method.
  • the connected instrument arrows follow automatically in response to the drag-and-drop operation.
  • the GUI provides a list of pre-defined instrument types immediately upon creating the instrument. Double- clicking on an instrument and party tells the system to show detailed information about that instrument or party. Clicking the second mouse button offers a list of actions appropriate for the instrument or party clicked.
  • the GUI also provides navigation to the Payment Organizer (preset for specified party) via the second- mouse-button menu
  • the next chapter is the Parties chapter.
  • the program simulates "parties," which are entities that participate in a financial transaction. It provides automatic creation and deletion of party-specific information. This party-specific information includes items, such as tax rates, fiscal-year-ending months, or yield requirements.
  • the GUI provides support to the Payment Diagram for party detail information.
  • the GUI also provides the user with a standardized and extensible location for party data. Each party can have individual tax attributes, paying different kinds of taxes to different governments (U.S. states or foreign countries).
  • the next chapter is the Time and Decision Organizer, which is also called
  • the GUI provides users with control of globally available (case-wide) key dates, timelines and outcomes (from decisions). This is important because: (a) transactions often require numerous payments to be synchronized; (b) payments are often contingent; (c) contingencies can interact or cancel each other out; and (d) having all these in one place, and graphically editable, can make a transaction much easier to explain and understand.
  • the GUI provides the ability to create, delete, and edit Key dates, timelines and decisions.
  • the GUI also provides a graphic overview of key dates. Also provided is a graphic overview of instrument payment date streams, aggregated by timelines. This lets the user see quickly whether the model's payments are properly synchronized.
  • the system also provides graphic control of decision interaction to create and delete mutually exclusive outcomes. The user can thus see whether decisions occur in the proper order, and that they are also properly contingent on each other.
  • the GUI also provides the user with control over the global default for "Calendar” (conventions used for counting the number of days in an interval).
  • Instruments are the containers for the systems built-in financial expertise. They handle a lot of the routine bookkeeping that financial models demand, leaving the user free to concentrate on the nonroutine business aspects of the transaction.
  • the GUI of this chapter provides controls for creation and definition of payment streams between parties, and the tax effects of such payments on the paying or receiving party.
  • An expandable library of instruments keeps the system up-to-date.
  • Instruments have clearly separated and protected “input” and “output” sections, so all users can rely on their integrity.
  • the system connects parties (badges) to payment streams via role definitions and allows the user to switch parties. This is how the model knows which parties pay or receive the payments the instrument defines.
  • This chapter also connects payment streams to payment organizer classifications (cash and income badges) via role definitions and allows users to change the classification. This is how the model puts labels on each payment, so that it can show up in an informative place on summary reports.
  • the system allows paying and receiving parties to have distinct interpretations of the instrument payments, tax effects, and classification. This is an important feature, because tax law often makes these distinctions.
  • Instruments contain pre-built and pre-tested Smart Paper computation sections, making the system more reliable and freeing the user from having to do repetitive programming.
  • the system automatically activates and deactivates instrument Smart Paper computation sections according to the user's selection of role information for the parties. Thus, sections not in use remain visible and available and do not distract the user. Glyphs are used to highlight the relationship between role specifications and the calculations. Specific items representing payment or receipt of funds, or of taxable income or deductions, are identified with symbols that make those items easy to find.
  • the system also allows the user to change the name of the instance of the instrument.
  • model pieces can be named with the names that other transaction negotiators are using, making communication a lot easier.
  • the system also automatically generates the parallel payment streams for different outcomes using handlers for each possible decision. Each instrument can thus generate different specific payments depending on the state of various contingencies. This is important because exercise or non-exercise of certain options can mandate different behavior on the part of the same instrument.
  • the system allows the user to modify the handlers' termination behavior. Thus, special cases do not require modifications to the system.
  • the system uses Smart Paper "protection" modes to preclude user corruption of instrument functionality, but otherwise allows users the ability to modify instrument Smart Paper. Thus, users can be confident that canned (and therefore tested and reliable) model parts are being used, instead of model parts which may not be correct given an unforeseen peculiarity of a particular model.
  • the system also provides canned calculations for specific types of financial elements (e.g. rent, loans, etc.). These canned calculations cover a very large fraction of the payments users would run into when modeling a financial scenario. Thus, users will spend little time having to invent new payment mechanisms.
  • this set of canned calculations is contained in an expandable library, so as the industry changes, additions can be added to the library to keep it up to date.
  • the system provides the user the ability to customize the calculations, making use of the invention a lot easier. Pre-defined reports of the instrument results are also provided. As a result, explanations of what an instrument is doing are only a click away.
  • the system also allows the user to specify that an instrument only exists when a certain decision is assumed. Contingent instruments can be put into the model and will thus automatically be properly handled.
  • the system also supports automatic decision and outcome creation for termination values and other make-whole payments. These contingency dates are too numerous to include as separate instruments or outcomes, and so including them here provides a compact way of computing them as a class.
  • the system may also include instruments for advanced corporate finance operations, such as mergers, acquisitions and the like.
  • Smart Paper is a powerful non-cell based calculation interface wherein references are based on a hierarchical outline as opposed to a positional reference. Unlike spreadsheet programs, smart paper is non-cell based and does not rely on a positional reference for use in calculations. Smart paper is the bridge between the ease-of-use that spreadsheet users depend on, and the power of financial and optimization packages. It makes computations visible, understandable, and accessible. Users do not need to be computer programmers or learn to work as programmers in order use the system effectively and efficiently. The system has enhanced data capabilities, which automatically perform a lot of rote date-related manipulation that makes spreadsheets hard to create and even harder to modify.
  • the smart paper chapter is the component where the user specifies the computations he wants the system to perform. Users can define values directly, or they can provide a formula which will tell the system how to compute the desired values. Smart paper provides user control over outline-like (i.e. tree-like) format of parameters and several nested layers of headings. This makes Smart Paper work much more readable, and provides a mechanism for the system to resolve (or ask the user to resolve) formula ambiguities. Smart paper allows the user to create one or more sheets of smart paper. Related computations can be kept together, and unrelated ones can be segregated. Tabs are provided for moving among sheets of smart paper.
  • the GUI provides controls for viewing "formulas” versus “results” or both. Thus, users can get immediate feedback as to whether they have properly specified a formula.
  • the GUI provides editing capabilities for headings and parameter names, as well as provides access to the template library and instantiation of templates. Smart paper defines parameter name scope and parameter index scope automatically via outline format. This resolves many "name clashes," which would be otherwise inevitable in a model of any size. It also provides a view of dependency relationships among parameters. Users can thus identify information relationships among their parameters. Also provided is general support goal-directed "search" for setting parameter values.
  • the system automates some of the trial-and-error involved in changing parameters' values in order to produce the desired answer. It also allows the user to specify formulas that define (dynamically) activation/deactivation of subtrees. This gives models the ability to be "context-sensitive,” responding sensibly to particular values of input data. It also provides capability for import/export of data and formulas from/to Microsoft EXCEL or the like. Models can be created using the system and the system will automatically reconstruct the model in Microsoft EXCEL.
  • the GUI also provides a date stream bar that always displays the index of the uppermost indexed stream. The important pairing between dates and date-indexed data is therefore always visible on the screen.
  • the GUI supports multiple data-entry modes: simple-edit, full- edit and rapid-entry. These modes make constructing models easier and faster. Also, smart paper items (e.g. headings, templates, formulas, indexes) can be changed into each other. Tool bar and menus provide editing to morph, promote, demote, insert, and delete operations. This eliminates the need for learning a lot of jargon. Instead, all the alternatives are displayed, and the user can choose the most logical one. The system also provides graphic feedback as to the type of indexed data represented by parameters.
  • formulas for dates resemble "English-language" instruction.
  • Formulas can be printed, providing human-readable documentation for a model. This differs significantly from spreadsheets, wherein formulas consist largely of a list of data locations instead of identities, resulting in a nearly useless documentation tool for a human.
  • the system creates templates as white-box functions which allow the user internal access. Thus, there is no need to refer to external, written documentation to figure out what a template/function is doing, because all the code is right there, visible.
  • smart paper has an extremely powerful formula language (with input/edit wizards). This formula language automates many tasks which are routine in finance but which are now cumbersome for spreadsheet users.
  • the formula language which is described in greater detail below, has the following exemplary features:
  • StartDates Date streams that represent the start of time periods
  • EndDates Date streams that represent the end of time periods
  • ActsLike Ties one parameter's type to the type of another parameter. • Uses Prefixes attached to formulas to define goal-oriented setting of parameter values
  • Parameter labels define the parameter name for formula references. This is different from spreadsheets, in that, in spreadsheets, values are identified generally by where they are, not by their names (despite a cumbersome facility spreadsheets offer for naming cells). • Notes can be added to any heading or parameter, and the identify of the user making the note is recorded. This helps with auditing and documentation of models.
  • Assertions can be added to any parameter. Assertions let a "product manager" create models and guide future users in the model's use.
  • constraints can be "data-driven.” This lets model builders build models for less- sophisticated users, who can operate complicated models by providing values for variables.
  • An activation formula can be attached to a heading to make the sub-tree (for which it is a root) inactive when the formula evaluates false.
  • Glyphs reflect the existence of notes and assertions including the pass/fail state of assertions. Thus, the user doesn't need to open a parameter in order to tell whether a note or assertion is inside it.
  • the next chapter is the Optimization chapter (see Fig. 21 ).
  • the system is able to solve mathematical linear programs and other "search for best answer" problems. It also provides extensive tools for managing and seeing the effect of model constraints. This feature is very important as models get complex, and the number of constraints grows to, for example, several dozen.
  • a deterministic, formula based model can be used as the basis for an optimizable model: starting with a deterministic model, the user can simply identify the objective and add constraints.
  • the optimization chapter provides an overview of all optimization constraints and parameters in a case and defines the objective function for optimization.
  • the system analyzes the optimization instructions and data contained in a model. It provides diagnostic status indicators for :
  • the system gathers all model constraints for viewing on one page. This is important because constraints are often of definitive concern in tax-motivated transactions.
  • the system also sorts constraints by failing, binding, non-binding, and inactive. This helps negotiators identify the critical points in their deals, or helps a user figure out why his model might fail to provide an answer he would expect. It also provides detail results of the values, slack, shadow prices or failure margin of constraints. This information helps the user explain anomalous results, or suggest ways that financial objectives may be attained at less cost. Also provided is a simple algebraic list of all constraints, making it easier to make sure that no constraints have been mistakenly taken out or left in. This list can be printed, and becomes an important "output" for deal participants to examine and approve.
  • the system also gathers all optimizable parameters, search parameters, and non-linear parameters for display separately on their own pages, helping make sure that the linear program model has been set up properly. It also automatically determines whether there are any parameters causing non-linearity and thus precluding being solved by the built-in linear optimizer The user can then more easily decide how to change the model to be solvable by the available optimizer.
  • the system automatically traces the non-linear parameters to corresponding optimizable parameters and displays them with the nonlinear parameter. This helps modelers find linear models that are approximate solutions to otherwise unsolvable nonlinear problems.
  • the system also allows users to specify facets of optimization in a way that is intuitive and easy to understand. Constraints are expressed in terms of comparisons and not just formulas.
  • the GUI presents user with detailed progress screen and saves the results back to the user's file.
  • the system also re-evaluates constraints in the context of the user's model to provide more useful feedback from optimization. This is important because the specific analytical assignment is often to reverse-engineer the set of constraints that produced a particular answer.
  • the system also automatically invokes Successive Linear Programming (SLP) when needed to solve for a search parameter. This saves the user the labor of having to determine that the problem at hand is SLP and then perform the SLP by successively invoking the optimizer. It also automatically combines point-by-point searching and mathematical optimization, saving the user the labor of searching over various valid values of nonlinear data.
  • SLP Successive Linear Programming
  • the Payment Organizer shows all the payments a given party receives, or taxable income effects a party might recognize (contingent on the exercise or non-exercise of a particular set of decisions, if there are any). In short, this is the party-specific "bottom-line.” It also provides user top-level control over payment stream classifications and summary report of all payments. The system calculates and summarizes the cash flows and taxable income effects of all instruments automatically. It also provides ability to add, delete, rename and reorganize (tree-like) all payment stream classifications. The system also provides the capability to filter payment streams according to party, outcome, or cash versus taxable income.
  • the next chapter is Reports (see Fig. 22).
  • the Reports chapter provides the user with the ability to create, edit, view and print model data in reports that are useable as explanatory documents. Users do not have to load data into some other program for cosmetic improvements.
  • a report can consist of several sections (each of which could otherwise be a freestanding report of its own, all arranged on a single report's page.
  • the system provides the ability to create report "sections" (report parts), and provides the ability to drag and drop report sections on a layout editor to organize above/below and left/right arrangements of report sections. It also provides for push-button pivoting of individual sections of a report so that dates and/or labels can be shown vertically or horizontally.
  • the system automatically creates headings for data rows/columns based on parameter names. The user can change these names. It also supports user-driven and automatic creation of nested super-headings (i.e., headings running across several columns). This makes reports more readable because it groups data into fewer, more easily understandable chunks, and helps the report reader find a particular column of interest more quickly. It also provides titles, headings, footnotes and control over data format. Reports can thus be "customer- ready" without having to be imported for clean-up into commercial word-processing or spreadsheet software. The system also supports the creation of sets of many reports to be printed or viewed. This is important because the "story" of a financial product often requires several related reports.
  • Reports may optionally bind reports to user models (so that they are stored with the model), or to instrument definitions (so that they are stored with the instrument definition and thus available in every model in which such an instrument is used). Reports are language-independent: thus output can be in a language other than the system user's working language. The user does not have to speak the output language.
  • Template Builder is a white-box piece of pre- built and pre-tested Smart Paper.
  • a library of such templates provides a large part of the built-in financial knowledge that users can draw on. This makes it worthwhile for an organization to invest in well-constructed Smart Paper pieces that can be reliably shared.
  • the GUI provides the ability to create Template definitions to be used for instantiation. Generally, only specially trained "builder/users" would invoke the Template Builder. It provides user access to protection controls over read/write specifications of parameters. It also allows the builder of templates to work in the same manner as in regular Smart Paper. Thus, they are familiar in appearance and do not require users to learn how separate components look and work.
  • the system provides linkage to the currently active model so as to provide useful feedback to the builder. It also allows the builder to create, edit and delete template definitions, and to make these definitions available to the larger user community.
  • Instrument Builder This chapter provides a special "build" mode for instrument builders to create the definitions of instruments. Instruments can be designed to, for example, calculate tax effects for numerous governments (U.S. states, foreign countries) simultaneously. Tax instruments can be designed to, for example, handle complex multinational tax interactions (foreign tax credits and the implications of various international tax treaties).
  • Main Menu Items These items include an extensive, full-featured on-line "help" system which provides documentation for system features and behavior, and also provides financial examples which can serve as a tutorial; options for adjusting the program's appearance (horiz/vert tabs); and a program that follows the Windows NT "Control Panel” settings for cosmetics (dates, mouse clicks).
  • help system which provides documentation for system features and behavior, and also provides financial examples which can serve as a tutorial
  • options for adjusting the program's appearance horiz/vert tabs
  • print previews are provided for enabling the user see output before committing it to paper, thereby saving time, paper, and aggravation.
  • general cosmetic formatting capability is provided which is similar to that found in commercially available word processing or spreadsheet programs.
  • the GUI also provides tree, containment, or list views of the files. It also provides an overlapping grouping capability, so files can be treated as a group in addition to individually.
  • the system also provides a mechanism for extracting key results for several files and presenting them in a tabular report. It also provides file search capabilities based on the contents of the file in addition to the file's name, as well as filtering and sorting capability (e.g. show only my files). A "recent files " section and "all-files" section is provided.
  • the system intelligently identifies differences between two or more selected files, making it easier to explain their differences. It also provides capability to reorganize files (i.e. the tree), and the capability to read and add notes to files. Thus, a file's owner can protect the file from changes, while letting colleagues look at, and then attach notes to the file. In addition, the system provides detail records of file (e.g. ancestry). This is important because the great majority of files will probably not be created anew, but rather will be modified versions of existing files. The ability to track the changes that produced a file is a very advantageous and time-saving feature.
  • Payment Diagram chapter 50 having a graphical representation 52 of a simple financial scenario involving a two parties (54 and 56) and a "loan" instrument arrow 58 connected therebetween.
  • the two book view is used in order to more clearly explain the functionality of the invention. It is noted that, in Figs. 5-12, the Payment Diagram chapter 50 has a reduced size so that greater information can be seen in the other chapters on the right side of the display.
  • the Engine is operable, in response to creating of a graphical model, to automatically create useful information in certain of the other chapters. More particularly, in response to drawing an instrument in the Payment Diagram chapter, such as "loan" as shown in Fig. 5, the engine automatically generates time lines 62 in the Time Organizer chapter 60. This functionality is illustrated in the split screen view of Fig. 5, wherein the Payment Diagram 50 is shown on the left side of the display, while the Time Organizer 60 is shown on the right side of the display.
  • the badged parameter in the instrument marks the most important cash flow which is displayed graphically in the Time Organizer. It is noted that the engine uses default data for generating the time lines of Fig.
  • Fig. 6 shows an instrument calculation that is automatically generated in the instruments chapter 68 in response to drawing of the "Loan" instrument 58 in the Payment Diagram chapter 50 . Default settings are also used for this canned loan instrument, but after it has been created, the user can modify the data in the instrument chapter as required to correspond with the particular scenario being modeled. Thus, by adding an instrument in the payment diagram 50 the engine automatically generates the instrument definition including related calculation in the instrument chapter 68.
  • Fig. 7 shows the badged parameters in the instrument of Fig. 6. The box to arrow graphic on the left side of the instruments chapter, as shown in Fig.
  • Fig. 7 indicates the important cash stream which shows up in the cash link in the payment organizer and in the time organizer link.
  • the triangles and squares combined with the plus and minus signs show the tax effect which shows up as the income in the payment organizer.
  • Fig. 8 shows the information automatically created in the constraints page of the optimization chapter 70 in response to drawing of the instrument shown in the instrument chapter 50.
  • Fig. 9 shows another page, i.e. the optimizable parameter page 70a, of the optimization chapter 70 and the related information automatically generated by the engine in response to drawing of the "Loan" instrument.
  • Fig. 10 shows the information (cash) that is automatically generated by the engine in the payment organizer chapter 72 in response to drawing of the "loan” instrument in the payment organizer chapter 50.
  • Fig. 11 shows the (Income
  • Fig. 12 shows the information that is automatically generated in the
  • This exemplary case is called a QTE or Qualified Telecommunications Equipment case.
  • a graphical representation of this exemplary financial scenario is shown in Fig. 13.
  • the party LessorNameHere is the client or main focus of the deal and is called the lessor.
  • the lessor wants the tax effects associated with owning QTE equipment.
  • the party LesseeNameHere, called the lessee currently owns the equipment and thus has the tax effects.
  • the lessor proposes a deal to buy the asset and lease it back to the lessee thus acquiring the tax effects.
  • the lessee still gets to use the equipment.
  • To get the lessee to agree to the deal a portion of the money used to buy the asset goes to the lessee as well.
  • the tool is used, in this example, to model the deal from the perspective of the lessor.
  • FIG. 7 provides a graphic representation of this exemplary financial scenario or deal. The diagram was created in using the tool of the present invention.
  • Step 1- Draw the diagram as shown in Fig. 13 in the Payment Diagram chapter.
  • the first step in creating a case involves drawing the diagram shown in Fig. 13 using the Payment Diagram chapter 50 of the user interface.
  • the basic steps for this involve adding the various parties to the diagram, as represented by boxes, and drawing financial instruments, as represented by directional arrows connecting the boxes.
  • Fig. 14 shows the Payment Diagram interface used to create the diagram, and also shows the result of the first step executed in this example, wherein a first party 78 named "LenderNameHere" has been drawn in the Payment Diagram chapter 50
  • the white area of Fig. 14 is the drawing area where the diagram of the deal is created.
  • the tools above the drawing area are used to create and view the diagram. For example, the magnifying glasses allow the user to zoom in and out.
  • This image also shows the general interface for the product. It is noted that not all figures herein show the full interface of the full chapter. In other words, some of the figures only show an enlarged partial view of the interface or chapter.
  • the tabs 76 on the left side of the screen are used to navigate around the program to the different interfaces or "chapters" of the user interface.
  • Each major step in creating a deal is represented by a chapter.
  • the icons under the menu bar are general purpose tools used , for example, to save a case to a hard disk or load a new case.
  • the user clicks the party tool the round box with a plus sign
  • the engine adds a new section to the Parties chapter with two parameters which the user can then edit and augment.
  • the two parameters represent, for example, the first month of that party's fiscal year, and the name of his tax counsel. This data is reflected in engine parameters to provide persistence to the data, and to make the data available to instruments which will be connected to this party.
  • FIG. 15 shows this next step with two parties and a single loan instrument.
  • the loan is a misnomer because payments or money flows in two directions.
  • the borrower receives the loan and then makes payments back.
  • the convention used by this embodiment of the program is to show only the direction in which the loan is paid back.
  • the application creates a representative object in the engine to calculate and generate the calculations and cash flows for that instrument. More specifically, the client application tells the engine General Registry to create a new instrument object, which initially is an empty shell. The client application reads in rom a data file the representation of the instrument that has been saved by the instrument designer, and splits this up into graphic and engine data and passes the engine part to the new Instrument object. The engine then reconstructs the instrument from this data; this includes a hierarchy of parameters and parameter lists, a couple of instrument party objects, and a default instrument handler. Each instrument party contains the role information needed to create the cash and tax implications for the party at one end of the instrument arrow.
  • the default instrument handler contains the information needed on whether and how to truncate the flows in non-base outcomes.
  • Each parameter's formula is parsed into its expression objects, and named references are registered with the general registry's name reference manager, which, if possible, resolves them, so that the parameter's values can be calculated when needed. As these references are resolved, links are made between the parameters' dependency managers so that changes are correctly propagated through the entire system.
  • the engine creates an instrument handler containing the information on whether and how to truncate the flows for outcomes containing that decision.
  • Each handler starts as a simple copy of the default handler, but can be changed by the user.
  • the client tells the engine instrument object the names of the parties at each end of the arrow.
  • the engine looks in the parties data to find a section of data for that party, which it then uses to complete the instrument party role information (e.g. date of fiscal year end).
  • the engine instrument synchronizer object then springs into action, generating the actual flow parameters for each party and outcome.
  • the instrument party information is used to determine which parameters contain the cash and tax flows for that party.
  • the synchronizer searches for the first decision that terminates the flow, according to the instrument handlers. It then generates a truncating parameter (if necessary), and a final parameter which it identifies to the internal database by attaching badges indicating the party, cash or income classification, outcome, instrument name, other party and tax authority (for income flows).
  • the engine internal database recognizes these new badged parameters and changes any collected data in (for example) yield calculation templates to update their values. This process also enables the payment organizer to update its display to show the new instrument. The user continues to add parties and instruments until the deal is modeled fully as shown in Fig. 13.
  • Step 2 - Define the dates
  • Dates and timelines are defined in the Time Organizer as depicted in Fig. 16.
  • the user defines single case dates known as Key Dates.
  • the dates are stored in the engine and can be referenced by other parts of the case.
  • the other tools next to the add date tool are used to modify the dates including changing or deleting a date.
  • the user defines the overall deal dates called the Eventuates. This sets the basic start and end of a deal and also the periodicity (annual, quarterly). The user changes the Eventuates by right clicking on the line and selecting "Edit timeline" from the menu. The other lines are for visual purposes only. All key dates defined in the deal are shown.
  • Each primary cash flow for an instrument is represented by a line in the time organizer. Badging information stored within the engine for each instrument defines which is the primary cash flow for that instrument.
  • the EBO date is turned into a "decision" by the engine, which means the deal splits in to two possible courses or “outcomes".
  • the normal case, or BaseOutcome means the deal comes to term and the assets are just sold to the market place.
  • the EBO outcome occurs when the lessee purchases the assets prior to the end of the deal.
  • the outcome tool the triangle with a plus sign (currently disabled in Fig. 16), is used to define an outcome.
  • the engine When the user adds an outcome to the time organizer chapter, the engine performs numerous functions. More particularly, the engine creates a new outcome object to house data specific to this outcome, with links to the decision objects which comprise the outcome. For each tax-like instrument (for which the instrument designer has specified a "fresh copy for each outcome"), a complete copy of its parameter, party and classification data is generated. For each instrument, the instrument synchronizer generates new terminating parameters as necessary. These parameters terminate the flows generated by this instrument at the first decision contained in the new outcome that has been designated by the user as a terminating decision in the instrument's decision handlers. For each instrument, the instrument synchronizer generates new badged parameters to identify the flows to the internal database.
  • These parameters take their value from the terminating parameters defined in the previous section (or the original parameters if not terminated), with possibly a sign change. They are given badges based on the data in the party and classification sections of the instrument; the categories are Party, Outcome, Cash or Income Classification, Other Party, Instrument Name and (for income classifications) Tax Authority.
  • the internal database receives the information about the new badged parameters, it signals all effected collector parameters that a change has occurred. These are parameters which have been designated as extraction parameters, or as formula parameters using one of the special "collect" functions. The next time that their values are requested, they will re-establish all links with badged parameters so that the new ones are included.
  • the collector parameters signal a value change via their dependency managers to tell all other parameters whose value depends on theirs that a change has occurred. In this way the flows generated by the new outcome spread their effect throughout the model.
  • Fig. 17 graphically shows the decisions and outcomes which result from the early buy-out (EBO) option in this example.
  • Step 3 Entering instrument data
  • Instrument data is entered in the Instruments chapter as seen in Fig. 18.
  • Fig. 18 shows the Calculations section of an instrument where data, such as the rate of a loan or cost of an asset, and calculations, such as the amortization of a loan or depreciation of an asset, are entered.
  • the first two tabs near the top of the figure and next to the "Calculations" tab are used to enter role information for each party associated with an instrument (as defined by the payment diagram explained earlier).
  • the Borrower tab can be seen where information about the party borrowing the money for the loan is modified such as how the loan interest is deducted. Lender information is modified by selecting the next tab.
  • the Event handlers tab contains the settings for how the instrument is processed if a different outcome is used. For example, loans are generally paid off if a deal ends early.
  • the Reports tab lists the reports specific to the instrument, such as the loan payments.
  • the loan rate is the only item which needs to change.
  • the other default or initial values for the instrument are sufficient for how the loan should be setup in this deal.
  • Money is borrowed at a fixed rate of 5.0625%.
  • the steps are as follows: 1 ) Double click on the current value for the loan rate (this is the Rate parameter in the Calculations section of the Loan instrument); and 2) Change the value from the default value to 5.0625%. (See Fig. 19). It is noted that the formula includes additional syntax that indicates how the Rate parameter is to be used throughout the model.
  • Instrument data generally falls into two categories. It is either a fixed part of a deal such as the cost of an asset or the interest rate of a loan. Or it is an optimized value that gets calculated when the optimal solution is found.
  • the instruments in this case are set up in the following way: Fixed data:
  • Residual - For this example, the residual is actually fixed at 20% of the cost of the assets.
  • loan -The loan payments or debt service are optimized to satisfy the deal (see the optimization step).
  • Rents - The rent payments are likewise optimized to satisfy the deal.
  • Smart Paper is a calculation based feature very similar to a enhanced spreadsheet (more details on Smart Paper are provided below) .
  • a spreadsheet is based on individual cells linked together strictly by formulas
  • Smart Paper formulas know about each other and about links to dates. More particularly, as explained above, Smart Paper is a non-cell based calculation interface where references are based on a hierarchical outline as opposed to a positional reference.
  • the linking information is stored in the engine. For example, one formula may contain a set of values linked to the first date of every year for 20 years. A second formula may only need the value from a specific date, such as the fifth date, within the first formula. The second formula need only specify the specific date and the engine will search out the most appropriate value.
  • the Smart Paper in this deal is built up in two ways. First, the user has a variety of templates he can add that perform pre-defined calculations. Second, the user can create custom calculations or enter custom data into Smart Paper.
  • Figure 20 shows the interface for creating Smart Paper. The main screen with all the data and calculations is where the user creates his outline of data and calculations. The tools along the top are used to change the view of Smart Paper and to operate on specific entries in the outline.
  • Each tab is a different sheet of Smart Paper where the user can create his outline and enter his data and calculations.
  • the engine creates a worksheet in the General Registry.
  • the engine creates mirroring Parameter Lists and Parameters.
  • the engine registers it with the name reference manager. This will attempt to resolve any outstanding references to this name by formulas in other parameters. It will also see if references to other parameters of the same name need to be more fully qualified to prevent ambiguities.
  • the referencing parameter sets up a link between its dependency manager and that of the new parameters, so that any changes in value of this parameter will be signaled to the referencing parameter.
  • the engine parses it into its basic expression nodes. Any references to other parameters are registered with the name reference manager which will attempt to resolve it immediately. If it cannot be resolved immediately, then the name reference manager keeps the request as pending, in case it can be later resolved. Any resolved reference causes links to be set up between the dependency managers as described above.
  • optimization is the process of imposing constraints or requirements on a case and the varying values and other parts of the case until the best result is found.
  • a constraint it is meant, for example, that some cases fall under certain restrictions from, for example, tax laws relating to leasing and rents which must be satisfied if the case involves a lease or rents.
  • the elements of a case that can be varied are called optimizable parameters. In this deal, we are maximizing the present value benefit to the lessee. The following constraints exist on this deal and must be satisfied when optimizing to the best result:
  • the loan amount must be less than or equal to 80% of the asset cost - Standard constraints on the calculation of a MISF yield for both the BaseOutcome and the EBO outcome
  • the optimization screen is divided into several pages by the tab across the top of the screen, as shown in Fig. 21.
  • the "Constraints" tab which is selected and shown in Fig. 21 shows those aspects of the deal which can't change or must be satisfied. These constraints are added to parameters spread throughout the instruments and sheets of Smart Paper.
  • the engine collects these and displays them in a precise form for the user to view and evaluate.
  • the Optimizable Parameters tab lists those items which can change.
  • the other tabs provide other relevant information to help the user evaluate his model.
  • the Objective Function shows what is being optimized and whether a maximum or minimum value is sought. The user simply clicks the Optimize button near the top of the screen to start an optimization.
  • the engine analyzes all the parameter definitions and constraints that the user has entered, and tries to set up a linear (or mixed integer) programming representation of these suitable to be sent to the CPLEX linear optimizer. Assuming that this can be done, it sends the model to CPLEX, gets the results back and puts the resulting values for optimizable parameters back into their formulas.
  • Step 6 Viewing output
  • the final step is viewing the data either in the reports chapter or in the payment organizer.
  • a report from the reports chapter is displayed in Fig. 22.
  • the tools are provided to allow the user to view different aspects of the report including zooming in and out or printing the report.
  • the data for a report is collected directly from Smart Paper and instruments.
  • the only function the reports chapter performs is formatting the data for professional output.
  • the Payment Organizer chapter allows the user to view the data and cash flows according to a specific party, outcome and time frame within the deal.
  • Fig. 23 shows the annual cash flows for the lessor party from the base outcome of the deal. The user changes the view by manipulating the various controls provided at the top of the screen.
  • Smart Paper is a non-cell based calculation interface where references are based on a hierarchical outline as opposed to a positional reference.
  • Figs. 24 and 25 show a simple, example piece of Smart Paper created in accordance with the instant invention, and demonstrates some of the benefits of the non-cell based formulas used therein.
  • Figs. 24 and 25 show a portfolio of airplane rents. Under the heading Aircraft, we see rents for Planel and Plane2. The rents for each aircraft are paid on different dates and for different amounts.
  • the Totals section sums all the dates that the rents are paid on and shows the rents paid on each date. In a sense, this acts as a summary table.
  • the AnnualTotals section refers directly to the Totals section but uses an annual date stream as opposed to the dates each rent is paid. This effectively shows the viewer how much rent is paid each year regardless of the specific day that rent is paid.
  • Fig. 24 shows the values or results of the formulas created in Smart Paper
  • Fig. 25 shows the corresponding (or hidden) formulas used to obtain the values in Fig. 24. It is noted that the actual rents are just dummy values used for illustration purposes.
  • the two functions used in this example are Subtotal and Union (see description of Formula Language below). Union collects a bunch of date streams and combines them into one. Subtotal searches all the parameters underneath a heading and collects values from all the parameters with the same name as specified for the function.
  • This example also demonstrates the advantage of the dynamic non-cell based formulas used in Smart Paper.
  • the AnnualTotals collects all the rents paid for each year.
  • the user would have to examine each rent stream and individually select which rent payments fall in each year. If the Annual table then needed to be changed to quarterly, the user would have to go back and redo the entire process from scratch.
  • formulas know how to link values to dates so that the final formula can interpret the input values based on the actual date rather than the position the date falls in a spreadsheet, which relies on positional references rather than the hierarchical references of the instant invention.
  • the TotalDates parameter benefits from non-cell based references if a new date is entered for any rent stream. The TotalDates will always collect all rent dates regardless of how many or few there are.
  • FIG. 26 shows the actual values in this smart paper example
  • Fig. 27 shows the underlying formulas used to calculate the values. The following table explains the particular headings, parameters and formulas used in the example of Figs. 26 and 27.
  • FIG. 28 shows the actual daily present value (PV) and investor rate of return (IRR) for all pre-tax and after-tax cash flows with respect to an investment.
  • Fig. 28 shows the actual values
  • Fig. 29 shows the underlying formulas used to calculate the values.
  • the following table explains the particular headings, parameters and formulas used in the example of Figs. 28 and 29.
  • the Smart Paper feature of the instant invention provides a very useful calculation interface and tool. It is noted that the Smart Paper tool can, in accordance with the instant invention, be used independently from the modeling and analysis tool of the instant invention as an improvement to spreadsheet applications.
  • the graphical user interface and the engine provide an intelligent interface which enables data to be generated which models the deal in response to graphical modeling of the deal by the user.
  • the graphical model not only provides a visual representation of the deal, but it also causes the engine to generate useful information which at least partially modeMhe deal based on the information the engine is able to obtain from actions performed by the user during creation of the graphical model of the deal.
  • the engine operates in accordance with the description below. More particularly, the engine is a computational server designed to support client applications wanting spreadsheet-like formula evaluation, manipulation of indexed streams of quantities and linear and mixed integer programming optimization.
  • the engine has the following main features:
  • the engine is designed as a COM server which can be initiated either in- process or out-of-process. In the latter case, it can be either local or remote, and can handle multiple clients.
  • the engine has a hierarchical organization of data; at the topmost level the predefined general registry can contain multiple worksheets and instruments; these can contain an arbitrarily deeply nested hierarchy of parameter lists, each containing parameters and other parameter lists.
  • the engine has interfaces which stream in or out all of the data that has been specified by the client in the form of an indexed bit stream. This enables the client to save and restore cases in files.
  • the index can be used by the client to view the structure of the data and compare files; it is used by the engine to recover as best it can from a corrupted bit stream. Copies of each index entry are included in the bit stream so that a client may attempt to recover from a corrupted index.
  • Parameter lists may be independently streamed in and out. This enables the client to maintain a library of templates, which are sets of parameters which can be instantiated into any case. Instruments may also be independently streamed in and out. This enables the client to maintain a library of instruments which can be instantiated into any case.
  • Each parameter is a fundamental calculation unit. It has a name by which it can be referred to by other parameters, a value, and possibly a means of calculating that value.
  • the tool uses categories like "cash classification", "party” and “outcome” to model the flows of a financial model.
  • Parameters can be designated as defining results. Each result is attached to a specific name, party and outcome.
  • the result parameters can then be collated by the client into capsule summary reports, for example.
  • the values manipulated by the parameters can have many types.
  • a plain array is a set of values indexed by the natural numbers (1 , 2, 3, ). Normally there is only a finite number of elements in the array, but limited support is provided for infinite arrays which are regular beyond a certain point.
  • a sorted array is always in ascending order of its elements, with no duplicates; it is used for streams of dates representing events in a financial model.
  • An indexed array, or stream is an array which is attached to a sorted array for indexing purposes. This is used to represent streams of cash flows in a financial deal, where each flow is attached to a date.
  • the elements of arrays can be other arrays, thus providing support for multidimensional arrays.
  • a keyed parameter is a parameter that has been connected to another parameter for the purposes of providing a key (or index) for its array value.
  • the key parameter has a date stream (i.e. a sorted array of dates) as its value, and these represent the dates of the flows defined in the keyed parameter.
  • a keyed parameter refers to another parameter in a formula, it triggers special calculations to convert the keys. This is normally an "accumulate to date" algorithm, but can be changed to effect accrual, table lookup, interpolation and extrapolation by using formula prefixes.
  • a date and a time interval can be added to produce another date.
  • a scalar can be added to an array (it is added to each element of the array).
  • Two arrays can be added by adding corresponding elements. If these are indexed arrays, then the corresponding elements are found by matching the indexes (i.e. two streams of payments are added by adding the payments on the same dates).
  • Parameter values can be specified in several ways.
  • the client could simply specify a value, or it could specify a way of calculating the value.
  • a formula parameter has a formula specified, which is an algebraic combination of constants, references to other parameters, and functions.
  • a copied parameter simply duplicates the value of another parameter.
  • the formula language includes an extensive set of functions to provide spreadsheet capabilities for manipulating data. Also included are functions for manipulating dates and arrays.
  • the formula language also includes a set of prefixes specified at the beginning of the formula. These prefixes affect the way that the parameter is handled in references by other parameters, and can trigger automatic accrual, table lookup, interpolation and extrapolation. The prefixes are also used to specify variability during optimization and to trigger search and repetitive calculations.
  • the client can define custom functions.
  • the engine duplicates the expression tree for each element in the array (normally for each date), so that the expression nodes can be evaluated without encountering circular reasoning. More generally, a set of parameters can form a self-referential group, triggering duplication for each parameter in the group.
  • Each expression node keeps its calculated value until it is invalidated by a client change. This "intelligent recalculation" minimizes unnecessary repetition of calculations.
  • a formula refers to another parameter, it does so by specifying the other parameter's name, possible qualified by the names of its worksheet or instrument and levels of the parameter list hierarchy.
  • Qualifiers are other names preceding the parameter name, separated by periods. Many levels of qualification are possible, e.g. "Loanl .Calculations.Amortization. Interest”.
  • the general registry has a name reference manager which maintains all these references. As parameters or parameter lists are created, destroyed and renamed by the client, the references get automatically updated. Unnecessary qualifiers are removed. Qualifiers are added if the original reference becomes ambiguous, thus maintaining the intended parameter linkages.
  • Each parameter has a dependency manager which handles the invalidation of expression nodes when the client changes a parameter.
  • the target parameter sets up a link between the source's and target's dependency managers. If the source value changes, an event is triggered in its dependency manager which is transmitted via the link to the target; in turn this is passed on to the target's dependents.
  • the dependency managers can also provide the client with lists of dependents and precedents for any parameter.
  • Dependency managers are also created for parameter lists, worksheets, instruments, and indeed the general registry. Changes are propagated up the parent chain so that each level knows when there has been some change inside them. This information can be tapped by clients to provide an intelligent refreshing mechanism; i.e. don't bother to redraw interfaces for objects which have not changed.
  • the client requests a modification server for any level from parameter up to general registry. This modification server can be polled to determine whether there has been any change since the last poll.
  • Search parameters are formula parameters with a search prefix. There are three kinds: the optimization search, the targeting search and the maximization search.
  • the optimization search only uses the first three arguments (low, high and accuracy) to the search prefix; it has no effect on calculations outside of the optimizer.
  • the other types of search specify a target formula as the fourth argument.
  • the targeting search specifies a value to target in the fifth argument, while the maximization search uses one of the keywords "maximum” or "minimum” as the fifth argument. Whenever a non-optimizing search parameter's value is requested, iterates guesses for its value until the target formula is equal to the target value, or maximized, or minimized, depending on the fifth argument. Its value is saved until the dependency managers invalidate it, to avoid pointless recalculation.
  • the targeting search preferably uses third-party software which is designed to find the zeroes of functions. This software does a good job if the function is monotonic. However, it can get confused by non-monotonic functions which may have several solutions.
  • the maximization search uses a custom algorithm which uses quadratic interpolation to refine the guesses. It depends on the function being fairly well-behaved as well. However, any suitable application can be used to perform this function.
  • the engine has a facility for collating multiple parameters into a single date- indexed table. It is called a parameter date table, and there is one in every worksheet (more are available on request).
  • the client specifies which parameters it wants in the table, and the engine collates their dates and outputs a combined list of dates and a matrix of values. If the client wants to collate the data in regular intervals (e.g. annually), it can specify any number of date buckets; these override the table's normal "daily" rule.
  • the engine maintains a set of client-specified numeric formatting rules. These can be specified at any level of the data tree, from parameter up to general registry.
  • the client can then request the effective formatting for any parameter, and use it to format numeric values using special engine calls.
  • the facilities include comma insertion, fixed number of decimal places, prefixes and suffixes, percentages and scaling.
  • the internal database uses a bill-of-materials structure to enable parameters to collate data which has been identified via badges on parameters.
  • each category there are members which can be connected in a directed a cyclic graph structure, with numeric coefficients applied to each link.
  • a category representing the parties in a deal can establish ownership links between the parties, e.g. A owns 50% of B.
  • the links are also used to establish rules on the cash classifications, like "after-tax cash” equals "pre-tax cash” plus “taxes”.
  • the categories and members are completely arbitrary, and maintained by the client. An interface is provided to stream the entire table in or out, so that the client can save a default table in a file.
  • Parameters can extract data from the internal database either by designating them as extraction parameters, or by designating them as formula parameters and using one of the "collect" functions. Either way, the parameter specifies a list of category-member pairs and receives back from the database a list of parameters matching those specifications, with corresponding coefficients, and it then combines their values to get a value.
  • Parameter lists can be given an activation formula by the client. This is a formula that should evaluate to true or false. When the formula evaluates to false, the parameter list and all of its contents are labeled as inactive. Inactive parameters do not have values. If an active parameter tries to reference an inactive one, it will get an error value. Clients can use this facility to de-emphasize blocks of the model that are not currently being used, and prevent useless calculations from slowing down the program. There are several restrictions on the formula that can be used - for example, it must not refer to a parameter inside its own parameter list. Invalid formulas will always make the parameter list inactive. The engine can supply the reason why a parameter list is inactive.
  • the general registry contains a predefined worksheet called the timeline. This is designed to hold basic date and date stream definitions for the rest of the model, and has special interfaces to enable the client to manage them.
  • the timeline acts as a preferred source of parameters to the name reference manager. If a reference cannot be resolved within the parameter's own worksheet or instrument, then the timeline is searched before going to any other worksheet or instrument. This gives a "global" nature to the timeline parameters.
  • the engine maintains lists of decisions and outcomes. Decisions are named objects attached to date-valued parameters. They are designed to represent points in a financial model from which the deal could proceed in different directions; e.g. depending on whether an option is exercised. Outcomes are named objects that are the result of saying whether each decision has been taken or not.
  • Other outcomes can be created by the client by adding a decision to an already existing outcome. For example, if the client has created three decisions, then there are seven possible outcomes in addition to the base outcome obtained from the seven different ways of saying which combination of the three decisions has been exercised. These extra outcomes are not created automatically because the decisions may not correspond to independent decisions in real life - only certain combinations of decisions may be realistic.
  • Instruments are objects created by the client in the general registry. They are like worksheets in that they have an arbitrarily complex parameter list, but they also have data geared toward modeling financial instruments like loans, rent agreements, etc. They simplify designing badges for parameters.
  • Each instrument can have one or more parties specified. (The tool always uses precisely two parties for each instrument, corresponding to the two ends of the arrows in the party diagram.)
  • the client can specify a role for each party. For example in an instrument modeling a loan, the two parties could be designated “lender” and "borrower".
  • the client may refer to the roles in formulas; they are automatically defined to take the value of the name of the party filling that role. For example, if there is a party called "MyBank" with a role of "lender”, then a formula may use the identifier "lender” with the same effect as specifying the character string "MyBank". This allows instrument builders to write parameters which automatically follow party substitutions.
  • the general registry has a special worksheet called the parties worksheet. It corresponds with the parties chapter in the tool. It is completely maintained by the client. However, if an instrument party finds a section in the parties worksheet that has the same name as itself, then it generates role parameters echoing the data inside that section. For example, if the parties worksheet has a section called "MyBank” with a parameter called "FirstFiscalMonth", then an instrument parameter could refer to its value as "Lender. FirstFiscalMonth". (Assuming that the instrument contains a party with name "MyBank” and role "Lender”.)
  • Each instrument party can have one or more cash classifications, and each cash classification can have one or more income classifications.
  • Each cash classification generates cash flows for that party by specifying the name of a parameter defined in the instrument, the section of the topmost parameter list in which to find the parameter, whether there is a sign change (for paying parties), and the name of the category member to be used to generate badges.
  • Each income classification functions similarly with the extra information of which tax authority to badge it for.
  • Each instrument has a default decision handler which specifies how the flow- generating parameters are treated in outcomes involving a decision.
  • the client can override this behavior for any actual decision that has been created. There are only two possibilities: either the decision is ignored, i.e. has no effect on cash flows, or the flows are truncated at the decision date. If they are truncated, the client can specify a formula for an extra amount to be assessed on the decision date. To generate the flows for a particular outcome, the earliest truncating decision is found which is in that outcome, and that controls the flow for that outcome. If there is no truncating decision for that parameter in that outcome, the flows are the same as the base outcome flows.
  • the client may specify for each instrument that it only generates flows for outcomes containing a certain required decision. This is designed to model purchase options which are only present if the corresponding decision is taken.
  • the client may instruct an instrument to generate its own decision and outcome for the purposes of calculating parameters and generating flows. This is designed to model termination values where a set of cash values needs to be calculated to terminate the deal at any of a fixed set of dates.
  • the instrument contains a date- valued parameter which becomes the decision date; the client can vary this date to get a table of termination values, or have the engine vary it automatically by specifying formula parameters with the TerminateByDate prefix.
  • the object responsible for generating flows from instruments is the instrument synchronizer.
  • the synchronizer regenerates (as necessary) parameters defining the flows and identifies them to the internal database with badges.
  • the synchronizer identifies the instrument parameter representing that flow according to the client inputs. For each outcome, it generates an auxiliary parameter which may change the sign of the flow and/or truncate it at the appropriate decision date. It badges the auxiliary parameters using the categories "party", “other party”, “cash or income classification”, “outcome”, "instrument name” and “tax authority” for income classifications.
  • the client may designate that certain instruments are to be cloned for each outcome. This is designed to model tax payment instruments where the basic parameters have to take different values for each outcome.
  • the instrument synchronizer clones the parameter lists and party sections for each non- base outcome before generating the auxiliary parameters. It sets up default collection parameters for each clone to ensure that parameters extracting data from the internal database pick the right outcome in each clone.
  • the general registry may also contain specialists. These are named objects designed to act like building blocks. Each specialist contains its own version of the general registry which can have worksheets and instruments and other specialists. Since they are in their own registry, there is no contact between them and the world outside; no danger of references being erroneously resolved. They are safer versions of the "template” concept. Special parameters are designated as inputs to and outputs from the specialist, and they do have interactions with the world outside the specialist.
  • An action is a named object representing a calculation that is too complicated for simple formulas to accomplish.
  • the client can create new actions inside worksheets to do things like targeting and repetitive (sensitivity) calculations.
  • the client can create action sequences, which are sequential series of actions, to create a primitive macro language.
  • Actions can be executed synchronously or asynchronously. In the latter case, the client starts off the action, and sits in a loop requesting action progress, until the progress report indicates that the action is complete. This enables the client to provide visual feedback to the user during actions which could take some time. For example, the client could display messages sent back from Cplex during optimization.
  • actions are executed in a sub-thread to free the main thread to respond to progress requests.
  • the engine preferably has an interface with the Cplex optimizer.
  • This is a solver, provided by a third-party, of linear (LP) and mixed integer (MIP) programming problems. It is encapsulated as an out-of-process COM server which can be run locally or remotely, with multiple users.
  • the server can be started by the client or by the engine with the client specifying on which machine to initiate it.
  • the set of instructions for the Cplex optimizer is generated by an optimizer model. This is a named object containing the data needed for the optimization. There can be more than one optimizer model in each case, if desired.
  • An optimizer needs three kinds of information to operate. It must know which parameters the optimizer can vary, what constraints have to be satisfied, and what the objective function is. For each parameter with some information pertinent to an optimization model, there is a model parameter which houses this information.
  • the client can request a model parameter from an optimization model for any given parameter in the system.
  • a parameter is variable in a given optimizer model, it is made an input parameter and the corresponding model parameter is given certain properties defining the variability, count (for array parameters), continuity (continuous, binary, integer), and any special ordering instructions for arrays (increasing, decreasing, SOS1 , SOS2).
  • the parameter can be made a formula parameter and the formula given an "optimize" prefix; this only works for the main optimizer model.
  • Constraints are parameters with some extra properties.
  • the value of a constraint parameter represents the right-hand-side of a constraint, and could be a formula involving variable parameters.
  • the left-hand-side of the constraint is the owning parameter, and the relation is specified by the client: greater-than, equals or less-than.
  • the client can specify that adjacent constraints be combined in an OR- relation rather than the default AND-relation.
  • Constraints have their own activation formulas; this enables the client to activate and de-activate constraints automatically. Constraints can be turned into assertions by setting their test-only switch. Assertions do not affect the optimization, but they can be queried by the client as to passing or failing just like constraints.
  • the client requests a model parameter for each component of the objective function and sets its "objective function coefficient" property to the appropriate number; a positive number implies maximization, negative minimization. If there is more than one parameter with a coefficient, the optimizer will optimize the sum of the values multiplied by their respective coefficients.
  • the solving of an optimization model is done in phases.
  • the formulas involved in constraints (and the objective function) are visited to determine the set of parameters that contribute (directly or indirectly) to constraints or the objective function.
  • the definitions of all these parameters are visited to determine which are variable.
  • the next few optimization phases are designed to determine array sizes and array element variabilities for those parameters with array values. This is done by generating an auxiliary set of parameters whose formulas are cloned from the original.
  • the auxiliary parameters corresponding to parameters that the client has specified as variable are given special place-holder values which have a trivial pass-through arithmetic.
  • the result is normally a place-holder value, or an array of such. Wherever a place-holder value is encountered, that represents a variable (column) to be created in the optimization model.
  • objects representing the basic variables (columns) of the model are created, and the coefficients, or rows, of the matrix are generated.
  • Some rows correspond to the definitions of parameters, others to the constraints as supplied by the client.
  • a special type of value is used which is basically a linear combination of variables. Once an arithmetic of these values has been programmed, then they can be passed through the normal expression evaluator, and the rows created from the results. A second set of auxiliary parameters with cloned formulas is used to do this. Only client constraints that cannot be interpreted as bounds on the variables generate rows.
  • the arrays that Cplex expects as inputs are created and the model transmitted to the Cplex server.
  • the engine waits until that server has completed, forwarding any progress messages back to the client.
  • the results are obtained from the Cplex server, and put back into the file wherever the client has specified that parameters are variable. Binding information and shadow prices are obtained from Cplex and stored in the corresponding constraints. To assist users in tracking down infeasibilities, only the values that the user has specified as optimizable are put back into the model; any dependent parameters and constraints are then recalculated from their formulas, and lists of failing constraints are available the client (user) to display.
  • optimization search parameters are formula parameters with a search prefix in which only the first three arguments have been specified (low, high, accuracy). This kind of search prefix has no effect outside of optimization. It is used by the client to solve for variable parameters which cannot be specified as variable to the optimization model without sending the model non-linear.
  • the algorithm for choosing the guesses is a custom quadratic-fit algorithm for finding the maximum of a function. For the purposes of generating the optimization model, any non-optimization search parameters are frozen at their current values. If one of these has a new value as a result of the optimization in such a way as to invalidate the optimization, then a message about this is generated and sent to the client, and a special status condition set. There are two optimization actions provided for the client to execute. The
  • the “optimize” action will perform all of the above steps.
  • the "build model” action performs only the first few steps, enough to get the client data on linearity, constraints, etc. This last action is performed by the Advantage optimization chapter to provide visual feedback while the data to display the chapter is being prepared.
  • the engine can export its model to Microsoft's EXCEL software, creating as far as possible a working spreadsheet model of all the parameter formulas.
  • the exported model is limited in that it cannot handle date changes or changes in frequency or term that require re-dimensioning of arrays. It does a good job of formatting the resulting sheets to reflect the data hierarchy of the model.
  • the client has control over the sheets and what is included in them.
  • a marksman is a targeting action which works similarly to the search prefix. Being an action, however, it can be executed asynchronously with the client displaying progress. Each time round the loop, the variable parameter is guessed, and a specified list of actions performed, which could include optimization and other marksmen. This is repeated until a target variable reaches a specified value, or is maximized or minimized.
  • a matrix is a repetitive action designed to vary a parameter over a range of values, perform a list of actions which could include optimization and marksmen at each iteration, and store a set of results. These results are collated into a two-dimensional matrix of values assigned to a result parameter.
  • An action sequence is a set of actions which is executed serially; this could be used to implement a primitive macro language.
  • the engine preferably has a background thread which steals idle cycles to perform tasks in advance of the client requesting them. For example, evaluation of parameters, including searches, and generation of the optimization model. This can markedly improve interaction speed as the client may well find that whatever it needs to create a display has already been prepared by the engine. For example, the engine may submit background optimizations to Cplex so that should the user decide to press the optimize button, he would get an instantaneous result.
  • the instant invention includes a powerful formula language which can be used in the worksheet, as well as in other chapters of the invention, to provide scenario information.
  • This formula language includes a library of predefined functions and keywords which can be used by the user when using the tool.
  • An exemplary set of these functions and keywords which comprise the formula language, together with an associated syntax, is provided below.
  • Number is any numeric value or expression that is a real number.
  • Source values come from one or more previously defined numbers streams.
  • This function differs from its cousin Periodlnterval in that it takes into account the Advance or Arrears nature of the payment stream in which it occurs. It combines this information with the StartDates or EndDates prefix of the payment stream date index to determine which interval is relevant to the current payment.
  • Offset is an integer that defines the periods in which to accrue values.
  • Offset 0 (or blank) accrues to each interval containing a value.
  • Offset +1 accrues to the interval of the next period of value, offset +2 includes the next two periods of value, and so on.
  • Offset -1 accrues to the interval of the previous period of value
  • offset -2 includes the previous two intervals, and so on.
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on.
  • AccumulateByPeriod (Stream, Period) Accumulates values from an indexed array into the overlapping periods under a different index.
  • Period is the name of the date index of periods to serve as points of accumulation.
  • Actual_365 divides the actual number of days in a given month into a year of 365 days.
  • AddYears returns a date based on the calculated interval between a given date and given number of years, using the day-counting metrics of the current calendar.
  • the interval is the sum of a whole number of years and a fractional part. Only the fractional part is affected by the calendar argument.
  • Years is a whole or decimal number to express the number of years.
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on.
  • Advance values Defines a payment stream in which each payment applies to the period following the date on which the payment occurs.
  • Alignment keywords anchor the anniversaries in continuing dates to a month/day or the same day each month at a given frequency. There are two ways to express alignment:
  • An anchor date is the point of departure in the calculation of an anniversary or other fixed date.
  • the anchor date is expressed as a relative date modified by the keyword expressions Align frequency or Align Monthly On.
  • Conditionl condition2 and so on are the conditions you want to test for being true or false.
  • An anniversary is a date that occurs on the basis of a given anchor date and frequency. • If the anchor date is March 1 and the frequency is Monthly, the first anniversary of the anchor date is April 1 , the second anniversary is May 1 , and so on. There is also an Anniversary function that lets you calculate the occurrence of an anniversary based on a set of arguments.
  • AnchorDate is the date from which the anniversary countdown begins.
  • Date is any date expression for the cutoff date.
  • Frequency is Monthly, Quarterly, Semiannual, or Annual.
  • Annual is a frequency keyword used to define the interval between continuing dates in a date stream.
  • Array is the name of the indexed array that contains the value to be returned.
  • Index is an integer (or array of integers) that refers to the key location of an index array value against its index. The reference for the value in the first position is 1 , the second position is 2, and so on.
  • An array is a type of parameter that contains a series of one or more values. The values are arranged according to a formula. There are three types of arrays:
  • Sorted array Stream of values in ascending order, with no duplicates.
  • a typical sorted array is an index parameter, as seen in the underlined set of dates used to coordinate a set of cash flows.
  • index parameter may be a key to a value in another array
  • index is also referred to as a key parameter.
  • Indexed array Stream of values in the scope of an index (sorted array).
  • a typical indexed array is a set of cash flows in a deal, where each flow is keyed (attached) to a position on a date index.
  • ArraySum returns the total of all the values in an array.
  • the Arrears prefix means that each payment applies to the period that precedes the date on which the payment is incurred.
  • the category “Instrument” includes the list members “Rent”, “Asset”, “Loan”, and so on.
  • a bookend date is a date index element that does not represent the beginning or end of a period.
  • the period prefix used in the date index determines the bookend date.
  • the tool relies on a user-specified calendar method to evaluate intervals between dates for the purposes of calculations such as:
  • the active calendar method in a calculation affects payment values because there are more or fewer days in a given interval based on the calendar.
  • Cash is the default prefix for a payment stream when neither the Advance prefix nor the Arrears prefix is given. Use the Cash prefix (or omit a prefix) to specify that each payment applies to the date on which it is incurred.
  • a badge is an internal ID that that comprises a category and one of the list members within that category. Certain functions use the list member portion of a badge as an argument to collect or extract data.
  • Code is a number between 1 and 255 that specifies a character on your computer.
  • Index specifies which value(s) to select from the list of arguments.
  • Index can be any scalar or array value, including numbers or parameter references. For example, if the value of Index is 2, the application returns the second argument. If Index has a fractional value, the application truncates the fraction and uses the resulting integer to select an argument.
  • Valuel , Value2 and so on are the list of arguments from which the application selects based on the value of Index.
  • the arguments can be any number or expression, including scalar or arrays.
  • Classifications (definition) A classification is a financial label. It tells the application how to retrieve values given a context such as instrument, outcome, party/role, and so on.
  • the application recognizes SourcesOfFunds and Sourcesoffunds, but not SourceOfFunds or SourcesOfFunding.
  • String is a series of text characters or a reference to a parameter that contains text characters.
  • CategoryMemberList is an expression of one or more badges, with one set of quote marks to encase the entire string. See Categories and List Member Reference.
  • Each argument position represents a category and takes a user-specified list member name. • See Category and List Member Reference for help on names for parties, classifications, and so on.
  • Party identifies the entity whose income flows you want to collect. You can use either a party name or a role name for the argument.
  • Classification is the Income classification name (in quote marks) for the flows to be collected.
  • Outcome is the name of the outcome (encased in quote marks) under which income is to be collected. The function assumes "BaseOutcome” if no outcome is specified.
  • Instrument is the name of the instrument (in quote marks) for which income is to be collected. The function considers all instruments if no instrument is specified.
  • Tax Authority identifies the tax collector for the income to be collected.
  • Each argument represents a category and takes a user-specified list member name. • See Category and List Member Reference for help on names for parties, classifications, and so on.
  • Party identifies the entity whose payments you want to collect. You can use either a party name or a role name for the argument.
  • Classification is the Payment classification name (in quote marks) for the flows to be collected.
  • Outcome is the name of the outcome (encased in quote marks) under which payments are to be collected. The function assumes "BaseOutcome" if no outcome is specified.
  • Instrument is the name of the instrument (in quote marks) for which payments are to be collected. The function considers all instruments if no instrument is specified.
  • a constraint/assertion is a formula you can add to a parameter along with the formula that generates the parameter values.
  • the constraint /assertion formula defines the degree to which values can be recalculated during optimization.
  • the constraint /assertion can be binding or non-binding.
  • Array is a series of values separated by semicolons, or the name of any array parameter such as a numbers stream or date index.
  • Array is the name of an array parameter, or it can be a series of values defined by numbers stream keywords.
  • Difference returns difference between each successive element in an array or series of values.
  • SumToDate returns a single number for the sum value of an array or series of values as of a given date.
  • Daily_Present_Value (Flows, PVRate, PVDate, Calendar) Returns the daily present value of a set of cash flows.
  • PVRate is a percentage for the nominal monthly discount rate.
  • PVDate is any single date expression to which the cash flows are discounted or accreted.
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on.
  • Month is a number that represents the month of Year.
  • Day is a number that represents day of Month.
  • Date can include a day number between 1 and 31 irrespective of the month.
  • a date expression is a date included in a formula.
  • the date can be given in any of the following formats (refer to example):
  • Date location by keyword reference as in First datestream or Last datestream.
  • Elapsed time before or after a date as in date +3y.
  • a date index is an array parameter that contains an ascending series of dates. The dates are used to coordinate series of values according to when they occur over time.
  • Each element on the index is a key (a point of coordination for sorting values). • Parameters below the index are indexed arrays of values that are keyed to the index positions.
  • First (and so on) is the parameter name of a payment or income stream, or a table of values.
  • Date is any name reference or text string that represents a date.
  • Date is any name reference or text string that represents a date.
  • Starting Date and Ending Date are the two date values you want to calculate the number of days between. If Ending Date occurs before Starting Date, a negative number is returned.
  • StartDate is the first date to include in the count.
  • EndDate is a bookend date that is not included in the count of days.
  • the End Date is Feb 1.
  • Period is two dates from a date index expressed mm/dd/yy to mm/dd/yy (or using other valid date syntax; see example).
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on. • If Calendar is omitted, the application uses the decision tree for multiple calendars to choose a method.
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on.
  • Calendar is omitted, the application uses the decision tree for multiple calendars to choose a method.
  • a destination parameter is one in which the formula refers to another parameter in order to use the referenced parameter as a source of data.
  • Array is the name of an array parameter or a series of values defined by numbers stream keywords.
  • the first date in the index is a bookend. It does not represent the end of a period.
  • EndDatesOf (First, Second, 7) Returns the combined dates used to organize a set of number streams, first converting them to end dates if necessary.
  • Derives period start dates from one or more numbers streams and/or date indexes then creates a date index of dates that reflect the end dates of the underlying periods. Also incorporates dates or date streams given as arguments.
  • StartDates is the default if no prefix is present.
  • the interval of 1 st to 31 st is 29 days.
  • WithinText is the text string that contains FindText.
  • StartNum is the character position where you want the application to start the search. For example, to start with the third character in WithinText, use a
  • StartNum is zero or less, or if StartNum is greater than the length of WithinText, the application returns an error.
  • Context can be any of the following:
  • Parameter is the name of the parameter that contains the value you want to find.
  • InactiveNull lets you specify a value to return in lieu of the error InactiveParameter if the context/parameter specification points to an inactive parameter.
  • Array can be a numbers stream or date stream.
  • For n ends the stream after n periods at the given frequency unless the For stream is further defined following a separator keyword such as ; (semicolon) or
  • GetResult Locates a SetResult parameter flagged with a matching set of arguments and returns the parameter value. Or, if optional arguments are included, the function can return a subsidiary parameter value.
  • Context is the name of a parameter that uses the Context function to pinpoint its location.
  • SubsidiaryParameter (which can only be argued in conjunction with Context) is the name of any parameter located under the same subheading as the given Context parameter .
  • LogicalTest is any expression that the application can evaluate to be true or false.
  • ValuelfTrue is any value or expression you want the application to return if LogicalTest is true. If you omit ValuelfTrue and the LogicalTest evaluates to
  • the application can return text if it is encased in quote marks.
  • An index is a type of parameter used to coordinate values.
  • each value is keyed to an element on the index.
  • Array is the name of any array or date index parameter.
  • Firstlndex (and so on) is a whole number representing the index key position for the value you seek.
  • the application uses the two Interpolate dates that are closest to the destination date to figure the stepped value.
  • An interval is the length of a date index period calculated as a portion of a year.
  • the first interval on a StartDates index is .5 if the index is semiannual, .25 if the index is quarterly, and so on.
  • the first interval begins on the first date and ends on the day before the next index date.
  • the last date on the index is a zero-length interval (starts and ends on same date).
  • the first date on the index is a zero-length interval (starts and ends on same date).
  • the second interval begins the day after the first date and extends through the next date on the index.
  • Datel and Date2 are any two single date expressions.
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on.
  • Calendar is omitted, the application uses the decision tree for multiple calendars to choose a method.
  • a key is a point of coordination on an index that is used to sort values.
  • Keys can be defined as dates, integers, or alphanumeric strings encased in quote marks.
  • Stream is the parameter name of a payment or income stream.
  • String is a series of text characters or a reference to a parameter that contains text characters.
  • NumChars is the number of characters you want returned starting with the first character. NumChars must be greater than or equal to zero.
  • Base is the base of the logarithm. If you omit Base, the application assumes it is
  • OutputList is a parameter that contains the values to return where there is a match between InputList and LookupValue.
  • OutputList is assumed to be the natural numbers (1 ;2;3.).
  • InputList is a parameter that contains or organizes the LookupValue.
  • InputList is omitted and OutputList is an indexed array, then InputList is assumed to be the index of OutputList. Otherwise, it is assumed to be the natural numbers (1 ;2;3.).
  • InputList is an unsorted array, then only exact value matches are possible (Action must be 0).
  • LookupValue is a parameter that contains the values the function should search for within the InputList.
  • Action specifies a code number for the type of result to return when an exact match is not found.
  • NotFoundValue specifies the result to be returned if LookupValue is not found in InputList according to the preceding arguments.
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on. • If Calendar is omitted, the application applies its own calendar selection method.
  • String is a series of text characters or a reference to a parameter that contains text characters. Enclose the text string in quote marks.
  • MaxOfAII (argumentl , argument2,9) Returns the single maximum value found in a set of arguments.
  • String is a series of text characters or a reference to a parameter that contains text characters. String contains the characters you want to extract.
  • Divisor is any numeric value by which you want to divide the number. If the divisor is zero, the application returns an error.
  • Month(Date) Returns an integer between 1 and 12 that represents the month in a date value.
  • Date is any single date expression.
  • This function is typically used to produce a date stream consisting of the last days of months, the equivalent of writing the date constant 31 MON YEAR.
  • Date is any single date expression.
  • Monthly is a frequency keyword used to define the interval between continuing dates in a date stream.
  • This function uses a built-in search (invisible to you) to determine the rate of return to apply to a set of cash flows in order to end up with a net investment balance of 0 on the last yield date. • Use this function in place of the MISFYieldByMonth template when you do not need to assert or constrain the result.
  • Flows is the parameter name for a set of cash flows keyed to a monthly date index.
  • SinkingFundRate is a percentage. The default is 0%.
  • each value refers to the next sequential value in a source array.
  • Array is the name of the current parameter or the name of a source array from which you want to retrieve the next values.
  • LastValue is a value used to calculate the final value of the array.
  • Condition is an expression that the application can evaluate to be true or false. If Condition is true, the application returns False. Otherwise, the application returns True.
  • Number is the numeric value you want to round up. If Number is an odd integer, the application does not round it up.
  • An example of an Objective Function is the total cash of a transaction.
  • the application calculates an optimized value that meets the requirements defined by the constraint.
  • Count/Date is the number of, or last date of, the elements in the parameter to be set. If you omit a value for this argument, the application returns a value for each position in the parameter index.
  • Conditionl condition2 and so on are the conditions you want to test for being true or false.
  • a parameter is data that represents a calculation and can be used in other calculations.
  • the components of a parameter include its name, its formula, and the value(s) computed as a result of the formula.
  • PeriodEdge (Date, Periods, First/Last, Containing/Following)
  • Periods is the parameter name of the date index that contains the period of interest.
  • Periodlntersection PeriodStreaml , PeriodStream2
  • PeriodStreaml is the parameter name of a date stream.
  • PeriodStream2 is the parameter name of a date stream.
  • Periodlnterval Maps a numbers stream into a set of user-defined intervals.
  • Offset is an integer that defines the periods in which to return interval values.
  • a blank or 0 offset assumes an interval of each period containing a value.
  • Calendar is a calendar method such as Actual_360, European_30_360, and so on.
  • PeriodLength PeriodLength (Period, Calendar)
  • Period is a pair of dates expressed as mm/dd/yy Xo mm/dd/yy (do not use a parameter reference).
  • Calendar is a calendar method such as Actua l_360, European_30_360, and so on.
  • Periods Returns a stream of periods to which values in the given numbers stream are keyed.
  • IncomeStream is the parameter name of a payment or income stream.
  • StartDate is the first date of the first period in the stream to be created.
  • DateStream is the parameter name of the date stream that contains the periods to be used in the period stream following the given StartDate.
  • EndDate is the end date of the last period in the period stream to be created.
  • a prefix is a keyword you use at the beginning of a formula.
  • the prefix applies to all the values in the formula and determines how the values apply to time periods.
  • each value refers to the preceding value in a source array.
  • Array is the name of the current parameter or the name of a source array from which you want to retrieve the previous values.
  • FirstValue defines a value to assume for the first position in the resulting array.
  • Quarterly is a frequency keyword to define the interval between continuing dates in a date stream.
  • RegularAscendingArray Creates an ascending array of in which each value increases by a specified increment.
  • Step is the amount you want to add to the starting value and each resulting value to create the next value in the array.
  • Number is an optional number of values you want in the resulting array.
  • StartDate is the first date in the stream.
  • Frequency is Monthly, Quarterly, Annual or Semiannual.
  • SecondDate is the second date in the stream.
  • LastDate is the last date in the stream. Omit LastDate to create an unterminated stream.
  • Term is the elapsed time between StartDate and LastDate. It can be given as an elapsed time expression or in the form of the ElapsedTime function.
  • OldString is the text string you want to replace. It can be given as a series of text characters or as a reference to a parameter that contains text characters.
  • StartNum is the position of the first character in OldString that you want to replace.
  • NewString is the string you want to insert as a replacement for OldString.
  • String is a series of text characters or a reference to a parameter that contains text characters. String is the text string you want to repeat.
  • NumberTimes is the number of times you want to repeat String. If NumberTimes is zero, the application returns an empty text string. RIGHT function
  • NumChars is the number of characters you want to extract starting with the last character. NumChars must be greater than or equal to zero.
  • a role is the name for the set of properties that defines Party interaction with an Instrument.
  • ROUND(number,num_digits) Returns a number rounded to the number of digits you specify.
  • ROUNDUP(number,nur ⁇ _digits) Returns a number rounded up (away from zero) to the number of digits you specify.

Abstract

La présente invention concerne un outil de modélisation et d'analyse de scénarii financiers, comportant une interface d'utilisateur graphique qui permet à l'utilisateur de créer un modèle graphique de scénario financier, contenant généralement au moins une transaction financière, sur un écran d'affichage, et un moteur opérable, en réponse à la création du modèle graphique, de manière à produire automatiquement des informations, comme par exemple des informations financières ou mathématiques, qui modélisent au moins partiellement une partie du scénario financier à l'aide d'informations collectées par le moteur lors de la création du modèle graphique. L'interface d'utilisateur graphique permet à l'utilisateur de créer des graphiques partiels représentant chacun des parties de l'opération financière, et de produire des graphiques d'instruments financiers représentant des instruments financiers, chaque graphique d'instrument financier reliant deux parties des graphiques partiels. Le moteur produit, en réponse à la création d'un modèle graphique, une information d'instrument, telle qu'un objet ou un gabarit, pour chacun des instruments du modèle graphique. L'instrument comprend un langage de dates naturel et un langage de formules utilisés pour modéliser un scénario. En outre, cet outil permet d'optimiser des paramètres optimisables définis dans le scénario, et comprend une interface d'utilisateur conviviale de type livre et de type CAD.
PCT/US2000/002776 1999-02-05 2000-02-03 Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente WO2000046717A2 (fr)

Priority Applications (5)

Application Number Priority Date Filing Date Title
EP00908458A EP1175654A2 (fr) 1999-02-05 2000-02-03 Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente
CA002361206A CA2361206C (fr) 1999-02-05 2000-02-03 Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente
US09/530,040 US6957191B1 (en) 1999-02-05 2000-02-03 Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
AU29795/00A AU772639B2 (en) 1999-02-05 2000-02-03 Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
US11/102,638 US20050182709A1 (en) 1999-02-05 2005-04-11 Automated financial scenario modeling and analysis tool having an intelligent graphical user interface

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11874399P 1999-02-05 1999-02-05
US60/118,743 1999-02-05

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US09/530,040 Continuation US6957191B1 (en) 1999-02-05 2000-02-03 Automated financial scenario modeling and analysis tool having an intelligent graphical user interface

Publications (3)

Publication Number Publication Date
WO2000046717A2 WO2000046717A2 (fr) 2000-08-10
WO2000046717A9 true WO2000046717A9 (fr) 2001-09-07
WO2000046717A8 WO2000046717A8 (fr) 2001-11-22

Family

ID=22380472

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/002776 WO2000046717A2 (fr) 1999-02-05 2000-02-03 Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente

Country Status (5)

Country Link
EP (1) EP1175654A2 (fr)
AU (1) AU772639B2 (fr)
CA (1) CA2361206C (fr)
WO (1) WO2000046717A2 (fr)
ZA (1) ZA200106401B (fr)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2002029724A1 (fr) * 2000-10-05 2002-04-11 Kloss Ronald J Systeme de publication d"echelles de temps
WO2002103490A2 (fr) 2001-06-19 2002-12-27 Deepak Gulati Procede de gestion d'instruments financiers, de derives de baux de materiel et d'autres instruments collateraux, architecture de donnees, programme d'application et de traitement
US11138621B2 (en) 2019-05-23 2021-10-05 Capital One Services, Llc Normalization grid
CN113111630B (zh) * 2021-04-21 2023-05-23 江西财经职业学院 一种会计系统

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5383113A (en) * 1991-07-25 1995-01-17 Checkfree Corporation System and method for electronically providing customer services including payment of bills, financial analysis and loans
US6430542B1 (en) * 1998-08-26 2002-08-06 American Express Financial Corporation Computer-implemented program for financial planning and advice system
US6233566B1 (en) * 1998-12-31 2001-05-15 Ultraprise Corporation System, method and computer program product for online financial products trading

Also Published As

Publication number Publication date
AU2979500A (en) 2000-08-25
CA2361206A1 (fr) 2000-08-10
WO2000046717A8 (fr) 2001-11-22
ZA200106401B (en) 2002-06-21
EP1175654A2 (fr) 2002-01-30
WO2000046717A2 (fr) 2000-08-10
AU772639B2 (en) 2004-05-06
CA2361206C (fr) 2007-06-19

Similar Documents

Publication Publication Date Title
US6957191B1 (en) Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
US20090138307A1 (en) Automated financial scenario modeling and analysis tool having an intelligent graphical user interface
US5220500A (en) Financial management system
US5414838A (en) System for extracting historical market information with condition and attributed windows
US7320122B2 (en) Specification to ABAP code converter
CN101084494B (zh) 用于管理计算机环境中的工作流的方法和设备
US8577704B2 (en) Automatically generating formulas based on parameters of a model
US5742836A (en) Graphical programming system and methods with user interface
US8341089B2 (en) Real estate management system and method
US20050055289A1 (en) Multi-dimensional business information accounting software engine
US20120253997A1 (en) Method for multi-dimensional accounting of business transactions and system therefor
Alexander et al. Access 2013 Bible
Westland Audit analytics: data science for the accounting profession
US20040111344A1 (en) Financial data reporting system
EP0765503A1 (fr) Systeme oriente objets servant a creer, a structurer, a manipuler et a evaluer un instrument financier
CA2361206C (fr) Outil de modelisation et d'analyse de scenario financier automatique a interface graphique d'utilisateur intelligente
EP1826719A1 (fr) Modélisation de scénario financier automatisée et outil d'analyse possédant une interface utilisateur graphique intelligente
CN114222971A (zh) 从自然语言自动生成功能架构文档和软件设计与分析规范文档的过程和系统
Zapawa Excel Advanced Report Development
Kusleika Data Visualization with Excel Dashboards and Reports
Garita Applied Quantitative Finance
Milne et al. The prospects for common financial language in wholesale financial services
McBride et al. A knowledge-based system for cash management with management science expertise
WO2002001393A2 (fr) Plan comptable dynamique pour la planification des ressources d'une entreprise et modalites de mise en oeuvre correspondantes
Inman Enterprise modeling advantages of San Francisco for general ledger systems

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
WWE Wipo information: entry into national phase

Ref document number: 09530040

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 29795/00

Country of ref document: AU

ENP Entry into the national phase in:

Ref country code: CA

Ref document number: 2361206

Kind code of ref document: A

Format of ref document f/p: F

Ref document number: 2361206

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 200106401

Country of ref document: ZA

Ref document number: 2001/06401

Country of ref document: ZA

WWE Wipo information: entry into national phase

Ref document number: 2000908458

Country of ref document: EP

AK Designated states

Kind code of ref document: C2

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C2

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

COP Corrected version of pamphlet

Free format text: PAGES 1/29-29/29, DRAWINGS, REPLACED BY NEW PAGES 1/22-22/22; DUE TO LATE TRANSMITTAL BY THE RECEIVING OFFICE

AK Designated states

Kind code of ref document: C1

Designated state(s): AE AL AM AT AU AZ BA BB BG BR BY CA CH CN CR CU CZ DE DK DM EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: C1

Designated state(s): GH GM KE LS MW SD SL SZ TZ UG ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA GN GW ML MR NE SN TD TG

D17 Declaration under article 17(2)a
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWP Wipo information: published in national office

Ref document number: 2000908458

Country of ref document: EP

WWG Wipo information: grant in national office

Ref document number: 29795/00

Country of ref document: AU

WWR Wipo information: refused in national office

Ref document number: 2000908458

Country of ref document: EP

WWW Wipo information: withdrawn in national office

Ref document number: 2000908458

Country of ref document: EP