JP4138852B2 - How to exchange debt electronically - Google Patents

Description

  The present invention relates to a method applied to finance and crisis management, and an apparatus including an electronic computer and a data processing device. In particular, the present invention relates to crisis management for a specified, unknown future situation (event).

  Individuals and companies are always in crisis because of future situations beyond their control. The consequences of such future events can have a positive or negative impact on the well-being of individuals and companies. Individuals and businesses generally do not like to be aware of the potential for bad outcomes regardless of the perception of the likelihood (probability) of such a situation. Individuals and businesses are interested in considering that if the potential for bad outcomes is discovered, the “assets” they currently own are less likely to be significantly affected by future outcomes.

  Crisis can take many forms in terms of the wide range and types of future events that can have bad consequences. Crisis can be classified as “economic” as an example. The phenomena that make up the economic crisis include prices, currency exchange rates, interest rates, property values, stock prices, inflation rates, corporate performance, and market event-based indexes.

  Another crisis is related to the “technical” phenomenon. Technological phenomena include such things as power plant failures, aircraft engine accidents, and orbital damage or failure of telecommunications satellites. The result of each of the above phenomena adversely affects the user and / or the supplier.

  Other forms of crisis such as weather-based (i.e., rain or sunshine) or other natural phenomena (i.e., earthquakes or collisions between icebergs and navigating ships) cannot be easily represented.

  For example, there is a less obvious crisis in the sense that future results are unknown in connection with the release of air pollutants and the disposal of toxic waste that cannot be processed. However, there is advice that future results may be inconvenient based on current information.

  Today, crisis management capabilities are becoming more important than ever and are likely to become even more important in the future, as they are increasingly faced with a wide range of future phenomena beyond the control of individuals or companies. is there. Furthermore, with respect to a certain future phenomenon, the feasible range of events that can occur in the future is expanded, and the uncertainty regarding the probability of occurrence increases, that is, the instability increases.

  In addition, an individual may want to avoid the crisis even more in the event of a recession if there are significantly fewer disposable assets available to trade to protect themselves from adverse future events.

  In the prior art, individuals and companies faced with “technological” crises have adopted quality assurance services, collateral, increased research and development activities (related intellectual property rights such as patents, utility models and registered designs), modernization Measures for future outcomes through mechanisms such as automated plant and equipment acquisitions, improved inventory, occupational health and safety and employer / employee litigation.

  For example, consider an integrated circuit manufacturer who has a large number of customers who wish to purchase the integrated circuit to be manufactured. With a large number of purchase requirements, there is a delay in shipments due to limited manufacturing capacity, so it is necessary to facilitate production planning for orders already received. Manufacturers typically provide buyers with guarantees regarding measurable integrated circuit performance criteria. If the batch does not meet the specified criteria, the manufacturer is required to exchange the batch by contract. That is, buyers are not interested in obtaining financial compensation for poor quality integrated circuits because they need parts for their products. In the above example, the “consideration” given by the warranty is a preferential production plan for alternative batches of poor quality integrated circuits, replacement of other planned production processes if possible, or to other buyers. Means postponement of shipment.

  The above contractual arrangements are inherently individual and are concluded only between the manufacturer and the individual purchaser. Furthermore, such an arrangement exposes the manufacturer to complaints from other customers whose orders have been delayed due to replanning. Manufacturers do not have a convenient mechanism available to take action against such complaints, and perhaps have a manufacturing right with other manufacturers as an alternative to the unavailability of their own manufacturing facilities. I will prepare it.

  When faced with such “economic” crises, individuals and businesses can have negative consequences directly by indirect means such as self-insurance and by means such as futures contracts, forward contracts and swaps. Take measures.

  The above available economic crisis management mechanisms have drawbacks or limitations. In particular, the mechanism at best provides an indirect method for handling crisis management requests. The available mechanisms are quite expensive and the phenomena handled are limited and do not meet the demands of entities seeking to take measures against the widespread future crisis. The infrastructure and payment costs associated with switching between commodity and stock markets are often very high for entities, regardless of size. For this reason, it turns out that the entity has an unavoidable responsibility that is hardly under control.

  With regard to “uncertain” forms of crisis, for example, an example of such a form of crisis management in the prior art is for the atmospheric release of sulfur dioxide sold by the US Environmental Protection Agency (EPA) in March 1993. “Pollution rights”. According to this example, a “permission” allowing release into the atmosphere was sold by auction. As of 1995, any company or organization that releases sulfur dioxide in the United States would be accused without obtaining sufficient permission to cover the total emissions. That is, the contaminated person must either purchase a permit or modify or replace the plant and equipment to reduce emissions. The EPA adjusts the total amount of permissions that can be obtained. Already issued permits are valuable “tradeable” property among sulfur dioxide emitters, that is, already valuable transactions even before the time when no further permits can be sought. It is a possible “property”.

  Management techniques for uncertain and uncertain forms of crisis are in the early stages. Existing formats induce a need for devices and methods that can achieve efficient management.

Specific examples of patents relating to methods and devices for handling various forms of conventional crisis management include the `` Automatic Safety Transaction Device (Merrill Lynch Pierce Fenner and Smith Incorporated), whose applicant is Merrill Lynch Pierce Fenner and Smith Incorporated. Patent Document 1 relating to “Automated Securities Trading Apparatus” ”(corresponding to Patent Document 2 and further related to Patent Document 3 and Patent Document 4). Other examples include U.S. Pat. No. 6,057,049, entitled “Methods and Apparatus for Restructuring Debt Obligations,” assigned to Lazard Freres and Co. A. Patent Document 6 related to “An Automated Investment System” assigned to the company, and “Methods and Apparatus for Accumulating Uncertain Costs of Future Debt” assigned to the Collageage Savings Bank Patent Literature 7, Patent Literature 8, and Patent Literature 9 relating to “For Funding Future Liability of Uncertain Cost” are included.
British Patent No. 2180380 US Pat. No. 4,674,004 U.S. Pat. No. 4,346,442 U.S. Pat. No. 4,376,978 U.S. Pat. No. 4,739,478 US Pat. No. 4,751,640 U.S. Pat. No. 4,752,877 US Pat. No. 4,722,055 US Pat. No. 4,839,804

  The present invention is directed to overcoming the shortcomings of conventional crisis management mechanisms in light of the increasing importance of crisis management for certain unforeseen future situations.

  In this sense, the present invention deals with matters having economic value as individuals, companies and society as a whole. Methods and apparatus for providing crisis management, for example, minimize the consequences of bad futures, forms of compensation when bad future consequences occur, and risk management that was not supported and available in the prior art. It offers both forms and is valuable in the field of economic activity.

  The present invention places a party (participant) at a particular risk by placing an order for a compensation claim contract with a counter party (partner party) that has not yet been identified subject to the occurrence of a specific future situation. By eliminating this, a method and apparatus is provided that enables crisis management related to certain unforeseen future events. The party applies the order to the “device” in order to evaluate and compete with the most appropriate opponents, so that the established contract is properly processed by the maturity date.

  Thus, according to the present invention, a person concerned can manage a crisis that is anticipated with respect to a situation that may occur in a known but unforeseen future. Such future events may relate to measurable phenomena that can verify the results and are not significantly affected by other parties interested in the results.

  The ability to price and compete for a crisis avoidance contract arises essentially due to the nature of the crisis itself. There are many people who each have different views on the certainty (probability, likelihood) of the outcome of a future situation. That is, when each person is required to individually assess the range of results for a specified future day, there is almost always variation in the assessment. Therefore, it is possible to compete for these expectations among the parties involved in order to conclude a contract. Potential opponents for the contract you have signed up (candidates for opponents) can use future results from various perspectives to benefit their own interests, for gain, or form of crisis management There is a motivation to take up opportunities.

  It is important that the assessment of the future consequences of the situation be done separately from other parties that may be the opponents of the contract. Therefore, the nature of pricing and competition (match) is quite different from conventional negotiations or bidding as between related parties.

  According to the present invention, the parties can better manage the crisis because they can be more explicit about the uncontrollable, future events that have been found to be bad for them. become. Participants have the ability to use existing assets to lessen face certain crises and have access to widely available mechanisms that can explicitly trade existing assets to increase certainty about the future. I will. Further, the parties have the discretion to determine the extent to which the transaction is to be performed, actually perform such transaction and manage this transaction in a simple and low cost manner.

  Furthermore, the present invention provides an automated infrastructure that allows parties to access without restrictions regarding nationality or residence status. This will allow interested parties to participate directly without the need for an intermediary.

Thus, according to one aspect of the present invention, a data processing apparatus is disclosed that allows multiple parties to conclude a crisis management contract. This device
Contract data that identifies future maturity dates, rights due to maturity over the scope of the results, and consideration for the stakeholder in the relationship, where the stakeholder placing the order has at least one predetermined At least one stakeholder input means capable of entering contract data representing at least one applied contract of phenomenon;
At least one opposing stakeholder input means by which at least one opposing stakeholder may enter registration data for each aspect of the results within the predetermined range of results for the at least one predetermined phenomenon; ,
Data storage means connected to the stakeholder input means, connected to the opposing stakeholder input means, and storing the contract data and the registration data;
Data processing means connected to the data storage means for evaluating and competing contracts from the contract data and the registration data;
including. In the data processing means, the evaluation selects registration data corresponding to the maturity date for each predetermined phenomenon, calculates a counter value obtained from the right, and the competition determines the counter value and the counter value. Compare and establish the applied contract with at least one opposing stakeholder.

According to a second aspect of the present invention, a method is disclosed that allows a multi-stakeholder to conclude a crisis management contract, the method comprising:
(A) Identify future maturity dates, rights due to maturity for the range of results, and consideration for opposing stakeholders via means of input for at least one stakeholder Entering into the data processor contract data representing at least one subscribed contract in at least one predetermined phenomenon having a range of future outcomes;
(B) via the at least one counter-related stakeholder input means the data processing of the counter-stakeholder registration data for each aspect of each result within a predetermined range of future results of the at least one predetermined phenomenon; Input to the device;
(C) storing the contract data and the registration data in data storage means of the data processing device connected to the respective stakeholder means and connected to the opposing stakeholder input means;
(D) evaluating and competing for at least one of the applied contracts by the data processing means of the data processing device connected to the data storage means;
Have
The stage of evaluating and competing above is as follows:
(I) selecting registration data corresponding to the maturity date of the predetermined phenomenon;
(Ii) calculating the counter-value received from the rights;
(Iii) comparing the consideration to the counter-consideration;
(Iv) establishing a contract based on the above comparison;
including.

  In the preferred embodiment, the ordering stakeholder and the opposing stakeholder may be considered the buyer of the contract and the seller of the contract, respectively. The rights of each outcome may be in the form of “money” payments (both positive and negative) on the maturity of the contract that has been established, or in some cases in the form of goods, services, promises, credits or guarantees. Another form of compensation may be used. Consideration specified by the buyer or calculated by the seller may be essentially a reward or payment, or may be transferred to other “non-monetary” property or debt, typically when the contract is finalized. In some cases, it may be in a form that can be postponed until the expiration date or beyond the expiration date.

  During the period between contract formation and maturity, various buyers, sellers, and other contractual stakeholders may review any contracts with which they are involved, through evaluation and competition procedures, or It is possible to require the contract to be traded with other parties by changing the evaluation and competition procedures. These actors are responsible for the loss expected when their view of the future outcome of the phenomenon that is the purpose of the contract has changed significantly, or when an unforeseen bad trend has occurred in the real-day outcome of the phenomenon. There is a tendency to try to deal with other parties as described above as means for minimizing the risk. In addition to trading existing contracts, additional contracts may be applied to “quiesce” or avoid the crisis. Stakeholders create portfolios of incumbent and application contracts that are constantly traded to gain a good position, as long as they can always be reviewed in time.

  In addition, application contracts can be based on differences between phenomena and can manage perceived crises between phenomena. Thus, the basic contract phenomenon can be created to meet the most specific requirements of buyers and sellers, thus providing significant flexibility.

  In most cases, the maturity date is predetermined by the “product sponsor” who is the stakeholder, otherwise the stakeholder cannot be the buyer or seller of the contract he is sponsoring. Even so, it is assumed that the maturity date is bound to a specific time from when the contract is established. Such a constraint is appropriate when a maturity date is due in the near future. In this case, otherwise, the application contract will remain unsettled after the initial application until the maturity date arrives.

  Other stakeholders have administrative roles such as management, assuring the ability of buyers and sellers, enforcement, and supervision. In this way, the number and type of buyers and sellers that can be considered when evaluating and competing for an application contract can be controlled.

  Furthermore, the present invention provides an apparatus and method for handling contracts at maturity, and in particular handling rights transfer.

Thus, according to a further aspect of the present invention, a method is disclosed for exchanging debt between parties holding a credit record and a debit record for exchanging a given debt with an exchange, the method comprising:
(A) creating a temporary credit record and a temporary debit record for each party to be retained by the data processing device supervisory body separately from the exchange in the data recording device;
Obtaining a debit account at the beginning of the day for a temporary credit record and a temporary debit record from each exchange and storing in a data storage device (b);
For each transaction that generates an exchange obligation, liquidate the temporary credit record or temporary debit record in chronological order, and only allow transactions where the value of the temporary credit record does not become smaller than the value of the temporary debit record at any time Performing step (c);
At the end of the day, depending on the liquidation of the authorized transaction, the post-transaction credit or debit account, which is an irrevocable, time-invariable obligation imposed on the exchange, will be transferred to the respective parties. Instructing one of the exchanges to move to the credit and debit records of (d),
Have

Hereinafter, a number of embodiments of the present invention will be described with reference to the accompanying drawings. There are a number of “annexes” that aid in the described embodiment. These annexes are part of the detailed description of the invention herein. The attached table is as follows.
Appendix A shows the meaning of terms that are not customary.
Appendix B is a detailed description of the contract device and its stakeholders.
Appendix C is a detailed description of each of the nine processors of the contract device.
Appendix D is a detailed description of the nature of the crisis management contract.
Appendix E is a table and graph relating to Example I. Charts E2 to E9 correspond to Tables 1 to 8 in order.
Appendix F is a table and graph relating to Example II. Charts F2 to F10 correspond to Tables 9 to 17 in order.
Annex G is a table and graph relating to Example III. Charts G2 to G14 correspond to Tables 18 to 30 in order.
Annex H is a list of main variables and data files used in process 2 of the contract device.

Detailed Description of the Best Mode for Carrying Out the Invention
1. In the following, the relationship between various users (stakeholders) of “device (or system)” will be described first, and then the hardware data processing platform and the stakeholders will interact with each other and with each other. A peripheral input / output device used for this will be described. Next, the range of “applications” that a device can provide in relation to various stakeholders and the interrelationships of device components will be described. In addition, details regarding software methodology for implementing the application provided by the device are described, along with numerous examples of crisis management contract execution and trading. In the detailed description, a number of unusual expressions and terms are used. For convenience, explanations of the above terms are listed in Appendix A.

2. System Configuration FIG. 1 shows a block diagram of a general-purpose “device (or system)” for implementing the present invention. Each of the various stakeholders or parties in the system 10 has access to the centralized processing unit 20. The processing unit 20 can be composed of at least one data processing device, and all the data processing devices are interconnected. Provide access to the application software provided. Access to the at least one data processing device is controlled by a general form of communication coordination and safety processing unit 25.

  In addition, FIG. 1 shows a number of stakeholder types, where each stakeholder type includes a number of individual stakeholders. The basic types of interested parties are as follows: applicant 11, product sponsor 12, product ordering party (buyer) 13, and potential product opponent (seller) ) 14, guarantor 15 of the opposing party, regulator 16, price / rights transfer (“settlement”) party 17, and various parties 18. The detailed functions of each of the above stakeholders will be described in detail later. The number of stakeholder types represented in FIG. 1 is a typical maximum number provided by the system 10.

  One embodiment of a computer device of system 10 is shown in FIG. The heart of the device hardware is a collection of data processing units. In the above embodiment, the processing unit 20 comprises three interconnected data processors 93, 97, 104, such as Sun 670 MP manufactured by Sun Microsystems, Inc. Each processing unit 93, 97, 104 executes operating system software such as Sun Microsystems OS 4.1.2 and application software. The application software creates a data file that is described in part in the form of flowcharts sequentially described in FIGS. 8 to 16 and FIGS. 18 to 40 or summarized in Appendix H. The processor configuration shown in FIG. 1 handles thousands of interested party transactions, input and output data generated by the interested parties, risk management contract evaluation, establishment, and subsequent processing functions. Therefore, it represents a large device designed.

  Each processing unit 93, 97, 104 has at least a mass storage device to store all data received from interested parties and other data related to all other software operations that create or extract stored information 95, 100, 110 are operatively connected. Suitable mass storage devices include, for example, mass storage devices that are commercially available from Sun Microsystems.

  A number of communication controllers 80, 84, 87 constituting the communication coordination and safety processing unit 25 are coupled to the processing unit 20. The controller affects communication between the processing units 93, 97, 104 and a number of external hardware devices used by interested parties that communicate data or instructions between the processing units. Communication controllers include controllers such as Encore ANNEX II, IBM AS / 400 server, or CISCO Systems AGS +.

  A wide range of communication hardware products are supported, and these communication hardware devices are collectively referred to as stakeholder input / output devices 70. One of the many communication devices 70 is a personal computer 51 and an attached printer 52, and these are in communication connection with the communication controller 80 via the modem 50. Further, there is an external host device 53 such as a mini or mainframe computer, and is connected to the communication controller 80 via a modem 54. Alternatively, communication may be set up using a tone dial telephone 56 that provides input of instructions or data using the tone dial function itself. Alternatively, voice connection via the operator 75 may be realized by a conventional telephone 58. Both of the illustrated external devices are connected to the communication controller 84. Further, it is possible to transfer data using the facsimile machine 65, and this example is shown connected to the communication controller 87.

  In all cases, the user of the input device may have access to a device such as, for example, a Racal RG 500 watchword generator 66, 67, 68, 69 (personal) and a Racal RG 1000 model built into the mainframe computer 53. It is required to create a password and use an encryption device. A corresponding decoding device for this device is incorporated in the communication controller 80, 84, 87.

  In addition, the general purpose processing unit 20 includes a number of “portable” information recording devices such as printers, disk drive devices, etc., so that various types of information can be written to a printable or movable storage medium. Become. This manifests a confirmation document of the established crisis contract, especially for storage as a hard copy record or for sending to at least one interested party to each individual established contract. Appropriate when necessary.

  The general-purpose system 10 shown in FIG. 1 provides a number of modified configurations for the “architecture” that can be realized not only by the number and type of stakeholders, but also by a combination of device hardware and software. In that sense, the configuration shown in FIG. 2 should only be considered as a broad representation of one form of hardware configuration required to implement the present invention.

  The “substantial” level of the system 10 is called INVENTCO. INVENTCO is a set of one or more devices that are potentially interrelated as shown in FIG. Each INVENTCO device (INVENTCO device # 1... INVENTCO device #N) allows for a wide range of contractual commitments and transactions, including crisis management contracts. The hardware configuration shown in FIG. 2 needs to be understood as an embodiment of a single INVENTCO device and represents a number of INVENTCO devices as well, with the processing unit 20 being common throughout and not shown. Along with the associated external communication device 70, only one supports the numerous communication coordination and safety devices 25 shown.

  INVENTCO allows crisis management contracts to be signed and traded, but is responsible for processing the contracts until maturity, and possibly even after maturity.

  There are many INVENTCO devices, but these devices are essentially interdependent or free-standing. In the case of interdependence, INVENTCO (10) serves as a transaction between the devices.

  INVENTCO and all its components may have addresses in legally or geographically distinct countries or states. INVENTCO's supranational nature allows stakeholders to manage risk regardless of their legal location or other similar conditions that are often characteristic of traditional risk management mechanisms and meet certain criteria such as creditworthiness. The mechanism can be used. In practice, the legal whereabouts, location, ownership, and interest participation stakeholders of INVENTCO or any subsystem are constantly changing.

  Further, each INVENTCO apparatus shown in FIG. 3 includes an infrastructure component called I-INVENTCO and a market repository component M-INVENTCO. I-INVNETCO has a relationship with communication called AXCO and other safety considerations, and a network called VIRPRO and a general-purpose management device are provided. M-INVENTCO is a repository for product market (application) software that is within INVENTCO authorized under VIRPRO's consent and distributed using I-INVENTCO.

  At least one local or wide area telecommunications network connects VIRPRO and M-INVENTCO to AXSCO and to each other. Thus, both VIRPRO and M-INVENTCO are efficiently placed around AXSCO.

  Thus, AXSCO consists of a number of uniquely addressed communication controllers connected to each other in a number of possible ways. In one embodiment, the AXCO is represented by a communication coordination and safety processing device 25 as shown in FIG. Component hardware, such as the three controllers 80, 84, 87 shown in FIG. 2, typically plays the role of three types of operational applications. The first application relates to the time stamps of data received from other parts of INVENTCO and data sent in the same way to those outside INVENTCO. The second application relates to protecting one's identity and / or location within INVENTCO from others. The third application is responsible for the overall management of the received data and the path order of the data to be sent to those within INVENTCO and outside of INVENTCO.

  Referring to FIG. 4, within M-INVENTCO, there are various sets of device sponsorship phenomena or “markets”, one set of which is called a contract application program (CONTRACT application program). Each contract application program within the “market” set of contract application programs is inherently related to a particular form of crisis management phenomenon. The purpose of each contract application program is double. The first purpose is the relationship related to the product ordering parties participating in profits, as well as other parties in INVENTCO registered as having legitimate interests in the nature, size and composition of the above trading / exchange / transfer. It is to buy / sell / exchange / transfer crisis management contracts (and derivatives of transactions) with opposing parties (partner parties) who are in a relationship that can be permitted by a person. The second objective is to consistently and properly manage all established / confirmed contracts until the maturity date.

  Each contract application program is responsible for performing the above tasks in accordance with the specific rules embodied by that contract as defined by the interested parties that may apply.

Noting that in most cases, not all possible types of stakeholders are included, the role played by a number of stakeholders for a contract application program is briefly described as follows: .
(A) The applicant himself / herself is responsible for all functions of the contract application program, and the responsibility is recognized by VIRPRO.
(B) A product sponsor is a person who encourages and manages the rules of trading and the management of the next limited “product” selected for inclusion in the contract application program by the applicant.
(C) An ordering party (buyer) is a person who seeks to obtain a contract application program product from a potential opponent (seller).
(D) Opponents or counterparties (sellers) are those who are potentially preparing to satisfy the demand for products in the contract application program of the ordering party (buyer).
(E) The guarantor is a person who guarantees the seller's ability to settle and pay the debt as a result of the establishment of the contract application program.
(F) The regulator is the person who oversees all other stakeholders involved in the contract application program, in particular the guarantor's runtime capabilities.
(G) The operator / entity of the consideration / rights transfer (“settlement”) maintains an “account” to transfer the consideration / rights required by all other contract application program stakeholders. It is a related person.
(H) Other various parties are those who have other clear interests in the function of the contract application program.

  In every device embodiment, each type of stakeholder includes a large number. A detailed discussion of the nature of the contract application program and the types of stakeholders for the contract application program is provided in Appendix B.

As shown in FIG. 5, one contract application program consists of a cluster of 9 (sometimes more or less) specific processes. In the cluster,
(A) Process that handles file management and updates tasks that support all other processes (called process 1)
(B) Process for accepting and processing “primary” crisis avoidance contract transactions (referred to as process 2)
(C) Process for accepting and processing “secondary” crisis avoidance contract transactions (referred to as process 3)
(D) The process of accepting and processing “derivative primary” crisis avoidance contract transactions (referred to as process 4).
(E) The process of accepting and processing “derivative secondary” crisis avoidance contract transactions (referred to as process 5).
(F) Process for handling “office work” management of all four types of crisis avoidance contract transactions and transactions handled by processors 7 to 9 (referred to as process 6)
(G) The process of dealing with contract application programs not related to the transfer of interest, rights and other “payment” obligations (referred to as Process 7).
(H) the stakeholder of the contract application program (and other authorized INVENTCOs) to the expert system to assist interested parties to determine the best connection method to the specified components of INVENTCO. Process that handles access (called process 8)
(I) A process (referred to as Process 9) that handles stakeholder access to the contract application program (and other authorized INVENTCOs) within the scope of “value added services” using INVENTCO.
Is included. A detailed description of these nine contract application program processes is provided in Appendix C.

  The process as a whole accesses a large number of data files and a large number of records in the file in an integrated manner. The variable and data files used in the processor 2 and the key components of the contract application program are described in Appendix H.

  The following description reveals the essential interaction between the hardware platform and the application computer software running on it.

  A first example of the life cycle of the crisis management contract will be described below. A more detailed explanation of the nature of the crisis management contract is given in Appendix D.

3. Life cycle of a crisis management contract: Example I
The first example of a crisis management contract represents a contract for managing a crisis related to a microprocessor failure. Briefly, the above example shows that the system of the present invention seeks to avoid the bad consequences of a faulty microprocessor (specifically a 64-bit microprocessor) used in military standard equipment. One party, such as a supplier of equipment, such as the above microprocessor manufacturer, who wants to take advantage of the opportunity based on the likelihood (predictment) of future failures of the microprocessor he produced. It has been shown that it will be possible to sign a contract with another party.

  A specific application is an application that grants a specific incidental (or contingent) right to an “exclusive product warranty (XPW)” to the parties who order the contract. In other words, the above guarantee is given priority to a specific amount of alternatives and additional microprocessors that are immediately available from a production line that is guaranteed another high quality that is available to suppliers considering the payment of monetary obligations. Give the owner the right to access. XPW's rights are a percentage index of the proportion of 64-bit microprocessors shipped by the manufacturer in a specific prior period that were determined to be faulty for a certain degree of commitment on the contract expiration date. It is incidental to the value. In this example, the determined degree is a microprocessor that does not have a failure as determined by the normal end of the self-test.

  In the above example, the key stakeholder concerned is: the applicant himself (Demdata Inc), a number of product sponsors (eg, parties such as Demdata itself), and a number of primary products. The ordering party (for example, the party like Denisons), the only potential opponent (Demdata), and the application regulator (Ministry of Defense).

  A timeline showing the stages of the contract from the first stage application identification to the final stage contract settlement is shown in FIG. Appendix E contains eight detailed tables (Tables 1 to 8) that help FIG. This appendix should be read with the following explanation. Charts E2 to E9 correspond to Tables 1 to 8.

  Looking at the first stage of the timeline (application specific) in conjunction with Chart E2, Demdata is at 92.02.10.17.00.00 (ie, 5pm on February 10, 1992) to handle the liability management. It can be seen that the contract application program (application identification number (ID) 100) has been set. Application identification number 100 supports a range of products (applicable product identification numbers are 1200-1250).

  Looking at the second stage of the temporal procedure (product identification) in conjunction with chart E3, it can be seen that the dem data was the product sponsor of product 1210 at the same time (92.02.10.17.00.00). This product relates to a market termed the factory quality index and a secondary market termed the 64-bit microprocessor fault tolerance index. The maturity date of product 1210 is 95.02.10.17.00.00.00. Consideration for a specific contract involving product 1210 is in the form of money (commercial bank deposits denominated in Australian dollars). Rights are in the form of exclusive product warranty (XPW). The exclusive product warranty gives the contracting party the right to preferentially access the previous production capacity of the production line of a 64-bit microprocessor with a guaranteed high quality. Product 1210 specifies a range of 0% to 100% in 2% increments for secondary market results.

  Looking at the third stage of the time sequence (Potential Opponent Product Price Identification), it can be seen that the dem data serves as the only potential counterparty for the upcoming primary product order dealing with product 1210. At the time of the temporal procedure (93.07.01.14.00.00.00), ie after a specific 17 months of product 1210, the dem data identified parameters that evaluated the order of the potential next product.

  Looking at the fourth stage of the time sequence (primary order identification) in conjunction with chart E4, the ordering party Denisons is the product 1210 at the time (93.07.01.14.25.30.00) (from dem data of the providing party). Ask for a contract. Chart E4 shows the specific “payment” parameters established by Denisons for the contracts we are seeking at this time, with the highest acceptable contract consideration (a premium) amount of 32,000 (commercial bank in Australian dollars). )It is included.

  Looking at the fifth stage of the temporal procedure (order specific evaluation) in conjunction with chart E5, the dem data shows that Denison's order is 93.07.01.14 (using the set of evaluation parameters specified in 93.07.01.14.00.00.00). It can be seen that the rating was .26.40.00. The dem data evaluation parameter indicates that Denison's appropriate limited environmental identification number is 14. As shown, this identification number was assessed over a fee range of 1.10%, a discount rate of 9.90%, a specific set of component product prices, and a range of specific feasible values. A set of occurrence probabilities (results) is shown.

  The contract bid price is automatically calculated using application software as follows. The amount of the desired desired contingent right of the party to order, ie “registered data” (covering the range of product determinable values that can be implemented) is the product price of the identified component of the potential opponent (This value is rarely 1 because each opponent is trying to “compete” potential ordering parties in a different way) and the corresponding number of implied contingent rights Forehead is obtained. When these numbers are added together, (34.110) is reached, where the parenthesis means a negative value. This figure represents the expected payment for future opponents' rights (specified maturity dates such as 95.02.10.17.00.00). The value for this day of this number, calculated using the specified discount rate of 9.90% per year, reaches 29,220. To this amount, 1.10% of the potential opponent's desired leveling fee is added, resulting in a contract bid price of 29,540 (in units of consideration / rights for products of commercial banks denominated in Australian dollars). It is done. In this example, the exchange rate does not apply because Ordering Party Denisons does not seek to treat consideration or rights in a unit different from the formally specified unit of the product. Depending on the parameters of the dem data, it is calculated that the consideration bid price of 29,540 (in units of commercial banks denominated in Australian dollars) will give rise to a base margin on 3,180 contracts.

  The above margin amount is calculated by the following method. The amount of the desired contingent rights identified by the ordering party (including the range of product determinable values that can be implemented) is identified and assessed by the potential opponents to obtain a corresponding number of net contingent valuations. Multiplied by the generated probability of occurrence. When added all at once, it reaches (30.770). This amount represents the contractual expected loss of the rights of future opponents (at a specified maturity date such as 95.02.10.17.00.00). The value for this day of this number, calculated using the specified discount rate of 9.90% per year, reaches 26,360. Thus, for example (ignoring the amount of consideration for 29,540 until the contract expires in some way with dem data and the margins that would benefit from the use of various transaction fees) The margin that can be expected by entering is less than the indiscriminate price 29,540 of its calculated current value by a contractual expected loss 26,360 of its calculated current value (or 3 , 180).

  The last two columns of the chart in Chart E5 are used to check that this contract does not violate the portfolio valuation or repayment limits that it imposes if demdata joins. This concept is explained in detail in Example III.

  Looking at the 6th stage of the time sequence (confirmation of the order), the contract bid price 29,540 of Demdata is less than Dennisson's specified maximum value of 32,000, so the order price of 93.07.01.14.29.10.00 It will be established.

  The seventh stage of the temporal procedure (order / contract confirmation) is 12 minutes when it is determined by the device that Denisons can immediately pay (and therefore pay) the amount of consideration funds 29,540 required by Denisons. It can be seen that it will be done at 93.07.01.14.38.50.00 later.

  Looking at the eighth stage of the timeline (contract evaluation) in conjunction with Chart E6, the contract evaluation report to Denisons was issued within one hour after contract confirmation, ie 93.07.01.16.00.00.00 I understand. The market value of the future product value of the 64BMFT index at this point is found to be 38 (standard deviation is 4), which means that the contract has a future expected value of 29,330 XPW (standard deviation is 6,213) Means that.

  Chart E7 shows that the equivalent report of DemData's future expected rights payments to Dem Data is the same as Denisons' future expected rights receipt (net profit vs. payment / receipt above). Ignoring future commission payments that come as a). The market evaluation of the future product value is a defined synthesis of the probability of the device being assessed by the contracting party and the numbers obtained from the set of all similar contracts recently established / confirmed by the device. Determined by applying numbers.

The ninth stage of the temporal procedure (contract evaluation) relates to the contract evaluation report issued for Denisons after 6 months, ie 94.11.15.10.00.00.00 (see Chart E8). As can be seen from the chart, the market estimate of the future product value of the index of 64BMFT at this point was found to be 5 to 8 (with a standard deviation of 5), which is the expected value 42,160XPW of this contract the future ( Standard deviation means to have 6,209). Accordingly, Denisons' future expected value has increased by 12,830 XPW since the date / time of the previous assessment.

  The tenth stage of the temporal procedure, contract maturity, relates to the practical determination of product value at 95.02.10.17.00.00.00 at contract maturity. As can be seen from Chart E9, the product value of such a 64 MBFT index is specified by the dem data (as a product sponsor) to be 74, which is the contract value on the Denisons side and the corresponding debt on the dem data side is 100,660 XPW. Means that. The quantity of 74 is substantially out of order (preferably by the Department of Defense, the application regulator) in the 64-bit microprocessor shipped by demdata for a specified period of time before the specified contract expiration date. Represents the percentage determined to be.

  The eleventh stage of the temporal procedure involves the formal transfer of 100,660 XPW to Denisons via demdata (if ignoring potential fee payments by one or both parties).

4). Life cycle of a crisis management contract: example II
The second example represents a crisis management contract related to the use of telecommunications business capabilities. In summary, this example shows one party (telecommunications) trying to avoid the bad consequences of under- and over-giving its calling capacity between specified points (eg, New York and Boston). Allowing the operator to sign a contract with another party (eg, another telecommunications carrier with call service capabilities between the same two cities) that is also ready to take action on the outcome of its appearance. Shows how to become.

  The specific application is a contingent right (indeterminate) for a transmission time unit (referred to as the primary TTU) in the time zone of 1200-1800 daily on the New York-Boston line within a fixed future period. Rights, conditional rights) to the contract order party and the calculated price of the main TTU on the New York-Boston line of the order party itself within another defined future period It is based on an assignment by an ordering party to a counter party (the determined TTU may not be interchangeable with a TTU on a line in another city). The TTU's right is a record of the difference between the use of the counterparty's network by the ordering party and the use of the ordering party's network by the counterparty during the specified prior period ending on the contract expiration date. It is incidental to the value at the contract maturity date.

  In the case of the above example, the key stakeholder concerned is the applicant himself (Newcom Inc) and a number of product sponsors (eg one of the parties involved is Newcom itself). And a number of primary product ordering parties (one of which is Bastel Co.) and two potential opponents (Tasnet and Aarcom) , The application regulator (ITT).

  FIG. 7 shows a time procedure showing the steps in the contract from the first stage of application identification to the final stage of contract settlement. Annex F includes nine detailed explanatory charts F2 to F10 that assist FIG. Charts F2 to F10 correspond to Tables 9 to 17. This appendix should be read with the following explanation.

  Looking at the first stage of the temporal procedure (application specific) in conjunction with Chart F2, Newcom is 93.11.01.17.00.00 to handle hardware performance management (ie 5:00 pm on November 1, 1993) It can be seen that the contract application program (application identification number 001) is set in Application identification number 001 supports a range of products (applicable product identification numbers 2001-2020).

  Looking at the second stage of the time sequence (product identification) in conjunction with Chart F3, it can be seen that Newcom is also the product sponsor of product 2001 at the same time (93.11.01.17.00.00). This product relates to a market called telecommunications business capability and a secondary market called primary TTU. The consideration for a particular contract that includes product 2001 is in the form of an “order party TTU”. The rights are in the form of "Counter Parties TTU", and the Contract Order Participants are entitled "Transmission Time Units of 1200-1800 hours per day on the New York-Boston Line (within a fixed future period)" Is granted. The realizable value of the main TTU is normalized in the range of -1.0 and +1.0, which indicates the ratio of using each network among the parties involved in the contract.

  Looking at the third stage of the time sequence (identifying the product price of potential opponents), two other vendors TASNET that serve as potential opponents for the upcoming primary product order dealing with product 2001 and You can find Arcom. At this point in the timeline (94.06.01.14.00.00.00) seven months after identification of product 2001, both Tasnet and Arcom will now identify the parameters that will evaluate the order of the potential next product. To do.

  Looking at the fourth stage of the time sequence (identifying the primary order) together with Chart F4, the ordering party Bastel asked for a contract for the product 2001 from the applicant at the time (94.06.01.14.25.30.00). I understand that Chart F4 shows the specific parameters (rights) defined for the contract that Bastel is seeking at this time, including the maximum allowable contract value of 58,000 (in its own TTU unit).

  Looking at the fifth stage of the temporal procedure (order specific evaluation) in conjunction with Chart F5, the TASNET (using the set of evaluation parameters specified in 94.06.01.14.00.00.00) is 94.06.01.14.26.40. It can be seen that 00 evaluates the order of Bastel. The evaluation parameter of TASNET shows that the suitably limited environment identification number of BASTEL is 8. As shown in the chart, this identification number means a fee rate of 1.00%, a discount rate of 9.90% per year, a specific set of component product prices, and a specific set of estimated probability of occurrence. . A similar process as described in Example I yields a contract bid price of 55,180 (in Bastel TTU units), and the calculation of this Tasnet parameter is on the contract (in Bastel TTU units) 10, Creates a base profit margin of 760.

  By looking at the fifth stage of the temporal procedure in conjunction with Chart F6, Arcom can further evaluate Bastel orders (using the set of evaluation parameters specified in 94.06.01.14.00.00.00). I understand. Arcom's evaluation parameter means that the appropriate limited environmental identification number for Bastel is 9. As can be seen from the chart, this identification number is then followed by a commission rate of 0.90%, a discount rate of 8.50% per year, a set of prices for a specific component product, and a specific assessed probability of occurrence. Means a set of. This yields a contract bid price of 55,390 (in Bastel TTU units) and a base margin of 9,430 in Arcom parameters (in Bastel TTU units).

  By looking at the 6th stage of the time sequence (ordering), Tasnet's pricing price 55,180 is lower than Arcom's pricing price 55,390, and the amount 55,180 is Bastel's specified maximum consideration price. Less than 58,000. This results in the formal establishment of the order for Bastel by Tasnet at 94.06.01.14.29.10.00.

  The seventh stage of the temporal procedure (order / contract confirmation) is about 10 seconds after the device determines that Bastel can (and will) immediately allocate the required consideration amount of 55,180 TTUs to Tasnet. It can be seen that it will be done later at 94.06.01.14.38.50.00.

  By looking at the 8th stage (contract evaluation) of the time procedure in conjunction with Chart F7, know the contract evaluation report of Bastel issued about 2 hours after contract confirmation, that is, 94.06.01.16.00.00.00 be able to. As shown in the chart, the logarithm of the difference between the utilization of the Bastel tasnet network (during the specified previous period ending on the contract expiration date) and the utilization of the tasnet bastel network, as shown in the chart The market value of this value is (0.150) (standard deviation is 0.023) at this point in time, and this evaluation is based on the expected future value of 54,236 Tasnet TTU (standard deviation is 9,207). It means having. Chart F8 shows Tasnet's equivalent (when ignoring future fee payments, which are purely profitable for the above payment / receipt), that the expected future consideration payment is the same as Bastel's future expected receipt. A report is shown.

  The ninth stage of the temporal procedure (contract evaluation) relates to the contract evaluation report issued for Bastel after 5 months, ie 94.11.22.10.00.00.00 (see Figure F9). As can be seen from the chart, the logarithmic value of the difference between the use of the Bastel tasnet network (during the specified previous period ending on the contract expiry date) and the use of the tasnet bastel network The market evaluation is (0.400) (standard deviation is 0.010) at this point, and this evaluation indicates that the contract has a future expected value of 350,181 Tasnet TTU (standard deviation is 74,200) Means. Thus, the future expected value of Bastel has increased by 295,945 TTU since the date / time of the previous evaluation.

  The tenth stage of the temporal procedure (contract maturity) relates to the practical determination of product value at 96.11.01.17.00.00.00 at contract maturity. As can be seen from Chart F10, the product value of this TTU has been identified by Newcom (as a product sponsor) to remain unchanged (0.400) from the date / time of the previous evaluation, This means that the TASNET side debt corresponding to the contract value on the side is 368,340 TASNET TTU. This amount is greater than the previous assessment figure because the actual decision figure is essentially free of standard deviation elements.

  The eleventh stage of the temporal procedure involves the formal transfer of 368,340 TTUs to Bastel by Tasnet (if ignoring possible fee payments by one or both parties).

5. Primary Product Order Processing Before describing the third most detailed example, consider the “core” product (brokerage) ordering, evaluation and completion processing. Note that expressions such as (PORD NEW) represent file names.

  The flow charts of FIGS. 8 to 16 show processing flowcharts of the primary product order establishment device presented to the contract application program by the order related stakeholders, and the application program (the amount of consideration paid is independent). EV-CE counter-related pricing method, continuous order formation processing, and the price / right value date immediately after the date / time specified by the product sponsor. Based on the establishment rules that do the following three things. The above three matters are, firstly, for each ordering party's order, provided that the ordering party is below the highest price specified by indicating that the ordering party is ready to make payments. Authorize opponents to offer pricing bids. Second, the expected loss constraint of the portfolio is established based on “product with equal maturity date”, “product with same maturity date”, and “all products”. Thirdly, the partial establishment of the product order is applied to the above establishment rule based on the pre-tax, and the conditional order establishment rule is not applied.

  Referring to FIG. 8, the device begins at block 610 and proceeds to block 625 to determine which set of orders should be processed, authorize the order, and counter the order if possible. Establish with related parties and confirm the order. As described in blocks 1010 to 1070 of FIG. 9, the device will process a newly submitted order (PORD NEW) and all previously submitted orders that were previously defined as pending orders (PORD QUEUE). ). Parameters and algorithms are provided to give the device the ability to determine when new or pending orders should be processed. For example, the simplest algorithm is to alternate one order at the same time between primary order new (PORD NEW) and primary order queue (PORD QUEUE). In another example, a pending order is loaded only when there is a change in the opponent's parameters. Test 1020 checks the decision made at block 1010.

  For a new order, the device proceeds to block 1030. The next recorded new order details are loaded from the primary order new master file (block 1040). The order data field includes an order party identification name (BID), an order party's own introduction (BREF), a product identification name (PID) specified by the order party, and a right payment function type ( PAYFUNC), "payment" function parameters for rights (PAYPARAM), "transaction type" identifier (DTID), anonymous and manual transaction identifiers (OAON and OMANUAL), order hold time limit (RET LIM), order It includes the maximum consideration (MAX CONSID) that the party is ready to pay, the number of accounts to “pay” the consideration (ACC CONSID), and the number of accounts to which the “payment” amount of the right is to be paid (ACC ENTTL). This set of information is used to authorize an order at the next stage of the device. This is done at block 1050.

Order Authorization Block 1050 is expanded from blocks 1100 to 1162 in FIG. Beginning at block 1100, the order is assigned a unique identifier, which is set in the order data field OID. Prior to matching other orders, additional information is requested by the device. At block 1110, product details (order data field PID) are loaded from the master file primary order product PPRODUCT (block 1120). The above information includes product maturity date (PMAT), product consideration / rights unit (PC / ED), product currency unit (PCUR), domestic currency unit (PNCUR), product limits and parameters (PMIN, PMAX and PSTEP) ) Is included. Test 1130 checks whether the order parameters are consistent with the master file parameters indicated by the confirmed product identifier (PID). Orders that do not pass this test are rejected at block 1140 and the details of the order are stored in the master file primary order reject PORD REJ (block 1150). The ordering party is then notified of this situation (block 1160). Processing returns to the beginning of the flowchart (block 1010) to prepare for loading the next order. When the order is approved, processing continues at block 640.

  If a pending order has been loaded (block 1060), the order field is set using the details stored in the pending file primary order queue (block 1070). This data is a combination of the new order data (as described in block 1030) and the data loaded or set when the order was first matched (block 1110). The authorized order processing continues with the order confirmation process at block 640.

Order Completion Blocks 640 are described by blocks 1200 to 1616 of FIGS. The order has a due date stored in the order variable RET LIM. Test 1200 checks whether the order hold deadline has expired. If the deadline has expired, the order is rejected at block 1210 and the order details are copied to the primary order rejection file (PORD REJ). The ordering party is then notified of the rejection at block 1230 and processing returns to the main loop via connection “A”. If the order is still valid, the order creation process proceeds. The purpose here is to find an appropriate opponent (or multiple opponents) that “evaluates” the “right function” of the ordering party within the limits set by the ordering party. The described formation process begins at block 1240 and, for each ordering party's order, the order's minimum " It is a process that tries to identify the opponents who present the “price price”.

  Blocks 1300 through 1370 in FIG. 12 provide an explanation of block 1240. The first step is to limit at least the group of opponents that are ready to trade with the ordering party. This is described as obtaining a short list of available opponents. Initially, a short list of opponents is cleared (block 1300). The order data fields BID (Order Participant Identification Name) and PID (Product Identification Name) then list all opposing parties ready to consider transactions with the ordering party for the identified product. Used to look up from (PDEAL LIST) master file (block 1320). In addition, all interested parties who have set the MANUAL (manual) or ANON (anonymous) flag are loaded. For each selected opponent, the SID is set to the corresponding identification name. Test 1330 initiates a loop that allows all available opponents to be handled next. For all currently selected opponents (identifier set in SID), data flow proceeds to test 1365. If the order data field OAON is set by an order party and one stakeholder requires manual confirmation (MANUAL (SID)), the current potential stakeholder is not added to the short list. The same is true if the ordering party sets OMANUAL and some other interested party needs anonymity (ANON (SID)). In either case, the data flow returns to test 1330. Otherwise, flow continues at block 1335. At this time, the device defines a “limited environment” applicable to the order. To determine this, the currently loaded order data field and the parameters set in the primary selection limited environment (PSEL DC) master file (block 1336) are used. At block 1340, evaluation parameters are selected from the PSEL PRICE master file (block 1350), including consideration / right exchange rate (if applicable), fee rate, and discount rate. Since a “limited environment” identifier (set to DCID) is used, all potential opponents identified based on any of the order data fields for each order have a separate set of evaluation parameters. You may have. Test 1360 checks whether all necessary parameters are known. A counter party does not have a complete set of evaluation parameters for the current order specification, even if it is ready to trade with the order party. Such opponents are not included in the short list of opponents and processing returns to test 1330. At block 1370, the opponents are variable in the price details: PRICEFUNC (SID), CR (SID), DR (SID), C-C / EDXCHANGE (SID), C-CXCHANGE (SID), C-NCXCHANGE (SID) , E-C / EDEXCHANGE (SID), E-CXCHANGE (SID), E-NCXCHANGE (SID), MANUAL (SID), and ANON (SID) are added to the short list of opponents. The process then returns to test 1330 where the next selected potential opponent is handled. If all selected potential opponents have been processed, program flow returns to block 1250. This gives a short list of potential opponents.

Blocks 1400-1500 of FIGS. 13 and 14 show block 1250 in more detail, with each potential counterparty having an offer price calculated based on individual valuation parameters for the currently loaded order. At block 1400, a loop is initiated that allows each potential opponent in the short list of potential opponents to be traded next. The SID is set to the identification name of the currently selected opponent. Test 1410 checks whether there are opponents left for processing. At block 1420, potential opponent pricing is calculated. Blocks 1490-1550 describe this calculation in more detail. At block 1490, the variable INDEX is assigned an initial value (PMIN) of the product value range. In addition, “price” is initialized to zero. Test 1500 begins a loop and all index points in the product range are moved. Block 1520 calculates an evaluation value returned by the potential opponent evaluation function PRIICEFUNC as stored in (PRICEFUNC (SID)) at the current index point and stores the value in P1. Block 1530 determines the payment amount requested by the ordering party at the current index point and stores this value in P2. At block 1540, the total price of the current index point is calculated by multiplying P1 by P2. This value is added to the running total stored in PRICE (SID). At block 1550, the index counter (INDEX) is incremented by the product step size (PSTEP) and the flow returns to test 1500. When the end of the product range (PMAX) is reached, the flow proceeds to block 1510 and the calculated pricing value is:
PRICE (SID) = PRICE (SID) * EC / EDXCHANG (SID) * E-CXCHANG (SID) * E-NCXCHANG (SID)
Will be changed.

Returning to block 1430, the pricing values stored in the PRICE (SID) are in applicable product consideration / rights units, currency units, and local currency units. The following steps (blocks 1430-1470) determine and apply a discount rate applicable to the calculated pricing price (currently a future value condition), thereby providing a pricing price at the current value condition. Get. This is done as follows. That is, at block 1430, the number of product maturity days is determined. Block 1440 initializes the loop counter and discount rate divisor. For each day (or appropriate part of it) between the current date / time and the product expiration date / time, the divisor is the formula:
DIV = DIV * (1 + ((DR (SID) / 100) / 365))
Will be changed according to.

At block 1470, the pricing price is the formula:
PRICE (SID) = PRICE (SID) / DIV
Adjusted according to.
After the pricing price is known at the current value condition, a limited fee for potential opponents is added to the price (block 1480). If CR (SID) represents the percent commission rate, the formula:
PEICE (SID) = PRICE (SID) + ((CR (SID) / 100) * PRICE (SID))
It is.

  When test 1410 has evaluated all potential opponents, program flow continues at block 1255.

  The test at block 1255 checks whether the order is a “quote only” order. If it is a quote order, the flow continues to block 1256 and at least one opponent bid price is selected. At block 1230, the ordering party is notified of the collected evaluation information. If the order is not a quote order (i.e., a real product order), an attempt is made to identify the current order request and the opposing party from a short list of potential opposing parties. This is done at block 1260. This process is described in detail in blocks 1560 to 1616 of FIG.

A check is made from test 1560 to see if the short list of potential opponents is not empty. If the short list is empty, no establishment is possible and the flow continues to block 1612. At this time, before proceeding to block 1614 where the entire order (because there is no portion established), the SID is used to indicate that there are no opponents selected from a short list of potential opponents. Is assigned "0". If the list is not empty, program flow proceeds to block 1570 where the lowest priced opponent is selected from the short list of opponents. This determination is based on the bid price (PRICE (SID)) of each potential counterparty converted to the consideration / rights type, currency, and local currency “payment” units required by the ordering party. (Ie, PRICE (SID) = PRICE (SID) * CC / EDXCHANG (SID) * C-CXCHANG (SID) * C-NCXCHANG (SID)). The identification name of the opponent is stored in the SID, and the price presentation is stored in the BPRICE. At block 1580, the following formula:
BPRICE> MAXCONSID
Is checked.

  If the selected price is higher than the order party's specified maximum consideration payment (MAXCONSID) limit, it is not considered possible to establish with the current potential counterparty. This is true for any opponents remaining in the short list of opponents. The portion of the establishment process returns without a potential opponent being selected for establishment in the short list (block 1612). Otherwise, the current price is allowed and the process proceeds to establish with the currently selected opponent.

  The next stage (block 1590) is read from the primary selection limit (PSEL LIMIT) master file (block 1600), ALL1 (SID), ALL2 (SID), ELL1 (SID), and ELL2 (SID). ELL3 (SID), ELL4 (SID), ELL5 (SID), EVL1 (SID), MC (SID), and applicable contracts, products and portfolios to be stored in MCC (SID) All absolute losses, expected losses, expected value limits, and maximum repayment limits are required. Further, the current accumulated absolute and expected losses are read and stored in CAL2 (SID), CEL2 (SID), CEL3 (SID), CEL4 (SID), and CEL5 (SID). The ELFUNC (SID) and EVFUNC (SID) values are also set for use when calculating the expected loss and expected value of the current order. Block 1602 calculates the price of the order's rights function using the expected loss of the counterparty product and the expected value parameters ELFUNC (SID) and EVFUNC (SID). The expected loss of the order is stored in EL (SID), and the expected value of the order is stored in EV (SID). The absolute loss function is determined at block 1602 and stored in AL (SID). Proceeding to block 1604, a portion of the order is calculated that does not violate the opponent's restrictions. This check is performed at test 1606. If no portion of the order is finalized, process flow proceeds to block 1608. Potential opponents are excluded from the short list of opponents.

  If a portion of the order is established with the current opponent, processing proceeds to block 1610. Here, the SID is set to the identification name of the established opponent. The unsuccessful portion (if any) is stored as a new order in the primary order waiting master file (block 1616). Flow returns to test 1261 in FIG. When established, program flow returns to block 650. The established order is confirmed by performing a number of additional steps, as shown in blocks 1620 through 1641 of FIG. If not, the current order process proceeds and returns to the top via connection point “A”. The device is ready to load the next available order.

Confirmation of fulfilled orders A number of additional actions are required to make a successful order into a contract. Initially, a manual authorization check is performed at test 1620. If manual authorization is required, program flow proceeds to block 1621 where the authorization request is sent to the associated third party. Block 1623 then tests for a rejection response. If at least one rejection is received, program flow proceeds to block 1627 where the order is rejected. If there is no rejection, flow proceeds to block 1624. Block 1624 performs the payment of the consideration by creating a transaction in a shadow payment account (PAYACC SHADOW) file (block 1625). However, if the specified account does not exist, or at least indicates that the required consideration is not available, the consideration cannot be paid. Test 1626 checks whether the “payment” is successful. If the “payment” could not be made, the established order is rejected (block 1627), and the details are stored in the rejected order master file primary order rejection (block 1628). The ordering party is notified of the situation at block 1640.

  If the payment is successful, the program flow proceeds to block 1630 where the current accumulated absolute and expected loss figures of the opponent are updated (master file primary selection limit—block 1631). At block 1632, the order data field OPRICE is set to the price PRICE (SID) provided by the opponent and SPRICE is set to the opponent's identifier SID. At block 1634, the fulfilled order is confirmed and guaranteed with all details recorded in the master file primary order confirmation (PORD CONF) (block 1636). The next step, block 1638, reports the details of the newly created contingent contract to all interested parties. The program flow then returns to the beginning via connection point “A”. The device is ready to begin processing the next order presented by the identified order party.

6). Life cycle of a crisis management contract: example III
A third example of a crisis management contract represents a contract that manages a crisis related to the potential future movement of the value of the identified index of the stock price (referred to as the PTSE 75 index). In summary, the above example attempts to avoid the bad consequences of the device having a significant drop in the future value of the PTSE 75 index (especially the drop in June 1994 relative to the provisional (January 1993) value of the index) ( So that one party (such as an institutional fund manager) can be contracted with another party that is not yet known, such as another fund manager, who is trying to avoid the negative consequences of a significant corresponding increase in the value of the PTSE 75 index. Shows how to do.

  Certain applications are contracted with contingent rights identified for future payouts of compensatory Australian dollars, based on payments to the opponents who still do not know the amount of the prepaid consideration calculated by the ordering party. Give to the ordering officials. Future monetary rights are incidental to the value of the individually defined PTSE 75 index at the contract maturity date.

  In the above example, the relevant key stakeholders are: the applicant himself (BLC), a number of product sponsors (eg, related parties such as BLC itself), and a number of product orders. With stakeholders (eg, Abbotts & Taylor, Shearer & Associates) and a number of potential opponents (eg, Abrahamsons and Carpenters Inc.) The guarantor (CNZ Bank) and the application regulator (Pacific Central Bank).

  FIG. 17 shows a time sequence representing contract-type stages from the first stage (application identification) to the final stage (contract settlement). The separate table G includes thirteen detailed explanatory charts G2 to G14 that assist FIG. Charts G2-G14 correspond to Tables 18-30. This annex must be read with the following explanation.

  Looking at the first stage of the timeline (application specific) in conjunction with Chart G2, BLC signed a contract with 91.06.03.17.00.00 (ie, 5:00 pm on June 3, 1991) to deal with economic crisis management It can be seen that the application program (application identification number 001) has been set. Application identification number 001 supports a range of products (applicable product identification numbers 10020-11400).

  Looking at the second stage of the temporal procedure (product identification) in conjunction with chart G3, it can be seen that BLC is also the product sponsor of product 10061 at the same time (91.06.03.17.00.00). This product relates to a market called the stock price index and a secondary market called PTSE 75. The expiry date of product 10061 is 94.06.03.17.00.00. The consideration for a particular contract associated with product 10061 is in the form of money (commercial bank deposits denominated in Australian dollars). In addition, the rights are in the form of commercial bank deposits denominated in Australian dollars and can be paid immediately (if necessary) immediately after the specified maturity date / time of the product.

  Looking at the third stage of the timeline (specific identification of potential counterproduct evaluation), two entities acting as potential opponents for the next primary product order to trade product 10061, Abrahamsons and You can find Carpenters. At this point in the timeline (93.01.01.17.00.00.00) after a specific 19 months of product 10061, both Abraham Sands and Carpenters have parameters that evaluate the potential next product order. Specify at this time.

  Looking at the fourth stage of the time sequence (primary order identification) in conjunction with chart G4, the ordering party Abbotts and Taylor, from that time (93.01.01.17.37.06.00) Seeking a contract. Chart G4 shows the specific parameters (rights) that Abbotts and Taylor have set for the contract being explored at this time, which includes a maximum allowed contract of 54,000 (commercial bank units denominated in Australian dollars). The consideration is included.

  In order to explain in more detail the fifth to seventh stages of the following temporal procedure, the block numbers selected from FIGS. 8 to 16 are referred to as “[]” as follows:

  Looking at the fifth stage of the time sequence (order specific evaluation) in conjunction with Chart G5, the evaluation parameters identified by Abrahamsons set to 93.01.01.17.37.06.00 are 93.01.01.17.38.02.00. It can be seen that it is used to evaluate Andy Taylor's orders. The Abrahamsons evaluation parameter indicates that Abbots and Taylor's appropriate limited environment identification number is 26 [1240]. As can be seen from the chart, this identification number is then followed by a fee rate of 1.25%, a discount rate of 10.00% per year, a specific set of component product prices, and a specific assessed probability of occurrence. Means a pair. In a process similar to that shown in Example, a contract bid price of 51,920 (AUD-based commercial bank units) is obtained, and Abrahamsons' parameter calculation is 4,580 (AUD-based commercial bank). A basic margin on contract (1250).

  Looking again at the fifth stage of the timeline in conjunction with Chart G6, the evaluation parameters set by 93.01.01.17.37.06.00 and specified by Carpenters are Abbotts and Taylor orders at 93.01.01.17.38.02.00. It can be seen that it was further used for evaluation. Carpenters' evaluation parameters indicate that Abbots and Taylor's appropriate limited environment identification number is 17 [1240]. As can be seen from the chart, this identification number is then followed by a commission rate of 1.30%, a discount rate of 9.80% per year, a specific set of component product prices, and a specific assessed probability of occurrence. Means a pair. This yields a contract bid price of 53,050 (commercial bank denominated in Australian dollars) and a contractual basis margin of 5,610 (commercial bank denominated in Australian dollars) is calculated by calculating the Carpenters parameter [ 1250].

  Looking further at the fifth stage of the temporal procedure in conjunction with Chart G7, it is used to determine the acceptability of an ordered contract based on the composite attributes of absolute loss, expected loss, expected value, and highest portfolio (93.01. It can be seen that the Abrahamsons evaluation-related parameters (set to 01.17.37.06.00) are met by Abbots and Taylor's orders [1604]. According to the Abrahamsons view, the price price of Abrahamsons is lower than the price price of Carpenters, and the price is specified by Abbots & Taylor as specified in the order specification (Chart G4) Abbots & Taylor orders are eligible to be included in Abrahamson's product / contract portfolio only if they are below the maximum consideration available.

  Finally, looking at the fifth phase of the temporal procedure, now in conjunction with Chart G8, determines the acceptance of the ordered contract based on absolute loss, expected loss, expected value, and highest portfolio composite attribute It can be seen that the parameters related to Carpenters's assessment (set at 93.01.01.17.37.06.00) for the Abbott and Taylor orders are further met. Second, Carpenters' view is that Carpenters' price considerations are lower than Abrahamsons' price pricing, which Abbotts and Taylor specifies and pays for order identification (Chart G4) Abbots and Taylor orders are eligible to be included in the Carpenters product / contract portfolio only if they are below the maximum consideration available.

  Looking at the 6th stage of the time sequence (confirmation of the order), Abrahamsons 51,920 is priced lower than Carpenters 53,050, and the amount 51,920 is specified by Abbotts and Taylor. Lower than the highest consideration price of 54,000. Therefore, the Abbots and Taylor order is officially finalized by Abrahamsons at 93.01.01.17.38.07.00.

  The seventh stage of the timeline (order / contract confirmation) allows the Abbott and Taylor to pay the Abrahamsons for the amount of 51,920 consideration required by the equipment (and actually pay). After the determination, it is performed at 93.01.01.17.38.11.00 after 5 seconds [650].

  Referring to Stage 8 of the timeline (Contract Evaluation) in conjunction with Chart G9, see the contract evaluation report for Abbots and Taylor published approximately 6 hours after the contract, ie 93.01.01.23.00.00.00 be able to. The market value of the future product value of the PTSE 75 index at this point is found to be 1970 (standard deviation is 333), which means that the contract is 53,000 (standard deviation) per commercial bank denominated in Australian dollars. It can be seen that it has a future expected value of 21,160). From Chart G10 we can see a similar report for Abrahamsons where the expected payment of the required future rights is in line with the expected receipt of Abbott and Taylor's future rights (the future of which is the net profit on the payment / receipt above) Fee payments were ignored).

  The ninth stage of the temporal procedure detailed in Figure 11 (secondary order identification) takes place approximately 6 months after the contract evaluation event, ie 93.06.06.08.00.00.00. At this time, Abbotts and Taylor will sell the contract status established / confirmed at 93.01.01. · 17.38.11.00 (when the device is assigned order identification number 915651800) at a price better than 57,000. Seeking. Shearer and Associates is ready to pay 60,000 (in Australian bank denominated commercial bank deposits) for that position. In all other respects, the contract attributes remain unchanged. According to Chart G12, in the tenth stage of the timeline, the contract is for sale at a price of 58,300, which is slightly lower than the above-mentioned maximum purchase price amount of 60,000 specified by Shearer and Associates. I understand. This amount is currently the best estimate of the future expected value of the contract, and the standard deviation of the expected value in the future calculated by the device using other recent transaction data is 10,610. Shearer & Associates has officially taken over Abbott & Taylor's status as a stakeholder in the contract.

  The eleventh stage of the timeline (contract evaluation) relates to a contract evaluation report issued to Shearer & Associates at 94.01.01.17.00.00.00 after 7 hours (see Chart G13). The market value of the future product value of the PTSE 75 index at this point is found to be 1800 (standard deviation is 283), which means that the above contract is 162,360 (standard deviation) per commercial bank denominated in Australian dollars. Can be seen to have a future expected value of 35,160). This represents an increase of 104,060 in future expectations for Shearer and Associates since the date / time of the previous evaluation. The above market valuation of future product value is determined by a device that applies a defined composition of figures of probability of occurrence of contracted parties extracted from a set of all contracts recently established / confirmed by the device. Determined.

  The twelfth stage of the temporal procedure (contract maturity) concerns the actual determination of the product value at maturity of 94.06.03.17.00.00.00. As can be seen from Chart G14, the product value of the PTSE index was specified by BLC (as a product sponsor) to 1820 and the contract value of 187,200 (in terms of commercial bank deposits denominated in Australian dollars) with Sharer and Associates And the corresponding debt against Abrahamsons. The number 1820 represents the actual value of the PTSE stock index at 94.06.03.17.00.00.00, which was obtained from an information source that BLC could independently collate. It was disclosed when the sponsorship rights were first announced.

  The fifteenth stage of the timeline involves the formal payment of 187,200 (in one Australian dollar denominated commercial bank savings unit) to Abrahamsons to Sharer and Associates (possibly by one or both parties) I ignored the payment.

7). Consideration of the consideration / rights payment process The purpose of the contract application program consideration / rights (and related transactions) payment / receipt process is specifically for participating consideration / rights transfer (or exchange) parties 17 at the expiration of the contract. Lending to an INVENTCO stakeholder's account, reflecting the payment / receipt rights and obligations that occur within INVENTCO. In the above process, payment / receipt is performed in two stages. First, based on the actual time, the stakeholder's (data file) applicable with the consideration / rights transfer party 17 (C / E party or C / E transferor) 17 outside INVENTCO and participating in profit Borrow / loan to the associated shadow record (first account) in the shadow payment account (PAYACC SHADOW). The applicable stakeholder maintains an account (second account) at the consideration / rights transfer party 17. Then, using the existing potential payment mechanism, a corresponding payment instruction is periodically executed for the payer. Details of the mechanism will be described below.

  All INVENTCO stakeholders maintain (at least) two dedicated (net credit deduction accounts) accounts with (at least) one selected VIRPRO certified C / E transferor. The purpose of a dedicated account is to ensure that only INVENTCO initiated borrowing and lending is made to that account. Thus, the account balance deductions in each shadow payment account file must always match the true temporal deduction accounts of the actual account maintained by the C / E transferor. .

  The purpose of providing two accounts is to ensure that only lending is done through one account and only borrowing is done through the other account. The purpose of the “net credit deduction account only” account is to ensure that borrowing on a borrowing-only account never exceeds the loan accumulated in the account contribution balance plus the loan-dedicated account.

  C / E transferors typically (but need not) have 6 types: public / private records-registries, credit card companies (typically retail) Transaction only), commercial banks, central banks, tax authorities, and any / all of the six types of non-bank bill exchange and depository.

  The assets transferred by the above persons may be in any form. However, in the most typical case, the deposit is appropriate for the entity. Public / private record-in the case of a registry office, a deposit of rights (including stocks of financial or physical assets, interest in participating in gambling, etc.). In the case of a credit / debit card company, it is a regular card company deposit (in local currency or substitute currency (eg, SDR) units). In the case of a commercial bank, it is a normal bank deposit (in local currency or substitute currency (eg SDR) units). In the case of a central bank, it is a foreign exchange settlement account (or equivalent) deposit. In the case of a taxing authority, it is a taxable account deposit. In the case of non-bank bill exchange and depository, it is a deposit of property tools, precious metals, etc. Potential opponents of the contract application program may in fact be C / E transferors, as well as order party guarantors (outside INCENTCO) that provide loans to product order parties. In addition, some of the accounts include potential opponents (and product ordering parties) for applications that require periodic payments of collateral to independent stakeholders to function as additional safety devices. A trust account maintained for

  Each C / E transferor is applicable in the “donated balance” of the INVENTCO account for all debits and credits he / she maintains, either daily or immediately after more frequent transaction processing and related settlement functions. The contract application program is notified electronically (at this stage the debit account balance must be zero and the credit account balance must be greater than or equal to zero). If an INVENTCO stakeholder has an overdraft or loan with the C / E transferor, the value of the loan is reflected in the non-zero balance of the credit account at this time.

  Upon receipt of the notification, the applicable contract application program updates / confirms the stakeholder's implicit deduction account. Thus, in this respect, all credit and debit shadow account balances need to be identical to the actual debit and credit account balances.

  INVENTCO's stakeholder's authorized (permitted) borrowing and lending to the INVENTCO's stakeholder's shadow account is based on real time, borrowing and debiting accounts, and lending sequentially throughout the day (Where “day” may be different for each C / E transferor due to a combination of payer's time-location differences with respect to applicable contract application programs, The payer's account processing cycle may be different). At any point in time, the Contract Application Program confirms that the cumulative debit balance of each stakeholder's debit account does not exceed the “loan balance” (starting balance) plus the cumulative loan balance of the stakeholder's credit account. Guarantee. Thus, for each INVENTCO stakeholder, the combination of each stakeholder's debit and credit account is always two real, “true”, pure, stakeholder maintained outside INVENTCO. Represents the occasional value of a dedicated account.

  Borrowings and loans to INVENTCO's stakeholder accounts are made according to strict rules and conditions, and differ between loans and borrowings. All INVENTCO stakeholder credit accounts can be credited with C / E transferors nominated by other INVENTCO stakeholders for any reason. Of course, because INVENTCO stakeholders are not aware of the account details of other interested parties, the loan will be made automatically according to the information and rules known to the applicable contract application program or necessary. This is done semi-automatically by an INVENTCO stakeholder who requests from VIRPRO the credit account number of the stakeholder to whom the asset is to be transferred. This account number is valid for the nominated period and is typically not the actual account number of the particular stakeholder with the nominated consideration / transferr, but to the INVENTCO file containing this number It's just a reference mark.

  On the other hand, the borrowing is the debit account of INVENTCO's stakeholders with C / E transferors nominated by the stakeholders themselves and other interested parties whose rights have been explicitly guaranteed by each interested party. The stakeholder needs the other stakeholders to enforce the rights according to the rules and conditions specified for him.

  If an INVENTCO stakeholder seeks to initiate / authenticate for a nominated account, this is specified by the consideration / rights transferor (reflected in the VIRPRO specific INVENTCO communication process) Performed only by interested parties who perform the verification and safety process satisfactorily. The types of processing specified by all profit participating C / E relocators include (at least) the following types: First, a secret file of the PIN number of the account corresponding to each INVENTCO stakeholder and a request-response process for a number of possible owner passwords associated with one of the customers handling the appropriate device. The consideration / rights transferor who provides VIRPRO with a similar secret “black box” to initiate confirms that the remote message received from the customer and processed by the “black box” is authentic. Secondly, the consideration / rights transferor provides the INVENTCO customers with a programmable smart card (or equivalent device), and with each customer's account maintained at INVENTCO remotely via telephone or direct computer line. Can be clearly convinced of the identity of the account, thereby borrowing for that account within certain parameters related to factors such as maximum transaction value, possible transaction types, account usage patterns, etc. Gain the ability to authenticate. Thirdly, INVENTCO may use a non-real-time process to grant a stakeholder the right to access the account record, or using a unique time-stamped reference number generated accordingly. , Provide a mechanism for direct stakeholder communication with the C / E transferor's shadow debit account and a formal update of the account.

  When an INVENTCO stakeholder allows an INVENTCO stakeholder to begin borrowing for a nominated account (any of) in accordance with some form of continuing authority, Only by the stakeholder himself / herself, who has been fully certified and certified by the C / E transferee nominated by the guaranteed stakeholder (and reflected in the INVENTCO communication process identified by VIRPRO) It is possible to do. In addition, the types of processing specified by all profit participating C / E relocators in the above respect include (at least) the following types: First, the C / E relocator is an INVENTCO The PIN number of the account corresponding to each of the stakeholder debit accounts and each of the other INVENTCO stakeholder certified to borrow (within defined parameters) Supply the secret file to VIRPRO. Second, C / E providing VIRPRO with a secret “black box” that initiates a request-response process for a number of potential owners associated with one of the customers handling the appropriate device. The transferor confirms that the remote message received from the authenticated person and processed by the “black box” is authentic. Third, the C / E transferor provides the INVENTCO customer with a programmable smart card (or equivalent device) for distribution to the authorized person, and remotely via telephone or direct computer line. Make sure the identity of the customer's shadow payment account with the account is clear, so that certain parameters related to factors (such as maximum transaction amount, possible transaction types, account usage patterns, etc.) Ability to authenticate borrowing for that account (within scope). Fourth, INVENTCO provides a mechanism for communicating with the secret debit account of a direct secret authenticated stakeholder C / E transferor.

  At the end of the date (or part of a day) designated by each C / E transferor, the applicable contract application program transfers (at least) two of the following to the transferor: First, if the request is If applicable, the contract application program has or communicates with the appropriate clearing authority of the C / E transferor (for each of the applicable consideration / rights units, associated payment / receipt currency and local currency types) A series of numbers representing an entry in a bill settlement (or equivalent) account. The above figures represent balanced net borrowing or lending figures corresponding to the sum of all of the INVENTCO customer's transaction entities up to that date. Second, a detailed file of all customer transactions made on that day (corresponding to the net number if requested). Upon receipt of the above transaction and aggregation figures, the C / E transferor will be able to borrow / lend each transaction to the appropriate actual customer account and calculate a new “sink” account balance. (The above “shink” balance must exactly match the end-of-day balance communicated with the customer transaction file by the applicable contract application program) ((d) At the end of the day, depending on the settlement of the permitted transactions, the respective transferee / rights transfer party will lend and / or borrow to each party's second account held by the transferee / right transfer party. Corresponding to the ordering stage, which is an irrevocable and time-invariant obligation imposed on the party transferring the price / right. To do). Next, the above-mentioned “sink balance” becomes the “donated balance” of the account of the C / E transferer on the next day. The notification process of the contract application program is repeated.

  At the end of each day of the “Bill Exchange” (eg National Central Bank) of a cluster of C / E transferers, etc., where applicable, the contract application program will reconcile the net bill settlement settlement entity. Move to a new location. The entity functions to balance the entries of individual customer accounts that have been individually transferred to each relevant C / E transferor.

8). Industrial Applicability The present invention has industrial applicability in the use of electronic computers and data communications. The above apparatus and method make it possible to implement crisis management in a manner automated by computer programming. The form of events related to crisis management devices and methodologies is valuable in the area of economic activity because it involves physical and technical phenomena.

9. Various aspects of the present invention The following aspects are further conceivable regarding the above description.

(Claim 1) A data processing apparatus including a computer that concludes a crisis management contract that expires on a future date among a number of parties,
A data storage means is provided for holding contract data entered on the ordering party side and registration data entered on the other party side,
Data linked to the data storage means and representing at least one application contract related to at least one predetermined phenomenon on the ordering party side, and ordered at maturity for a range of possible outcomes associated with the phenomenon in the future At least one ordering party input means for entering contract data, which is data specifying the rights given to the parties and the consideration given to the parties
Linked to the data storage means, and at least one partner party, regardless of the order party entering the contract data, the future outcomes for one or more of the predetermined phenomena At least one partner input means for entering registration data for the probability of each result within the range;
Linked to data storage means, based on the contract data and the registration data, pricing the contract by calculating the other party reward from the probability and the right, and comparing the consideration with the other party reward Data processing means is provided for competing contracts and establishing an application contract with at least one of the parties concerned.
Data processing device.

    (Claim 2) Connected to the data storage means, the phenomenon and the range of the result related to this phenomenon are inputted, this phenomenon is regarded as one of the predetermined phenomena, and the range of the result related to this phenomenon is Item 2. The data processing device according to item 1, further comprising at least one other order-related person input unit that is stored in the data storage unit as a range of results that can occur in the future with respect to this phenomenon.

(Claim 3) Another order party input means is configured such that a predetermined maturity is associated with the predetermined phenomenon and a range of possible outcomes in the future,
The contract data and the registration data are contract data and registration data for the predetermined maturity.
Item 3. A data processing apparatus according to Item 2.

(Section 4) The registration data for each result represents the probability that the result will occur at maturity,
The opponent's reward is calculated by multiplying the probability associated with the right, adding over the entire range of results and adjusting to obtain the value for the day,
Item 4. A data processing device according to item 2 or 3.

    (Claim 5) The data processing according to item 4, wherein the other order-related person input means is configured to receive update data relating to the result of the day of each phenomenon and send the update data to the data storage means for recording. apparatus.

(Item 6) An output means is further provided,
At the expiration of the contract, the data processing means
Obtain updated results for each phenomenon from the data storage means,
Determine the rights granted to the result,
Send this right to the output means to exchange the rights between the competing order parties,
Item 6. The data processing device according to Item 5.

(Claim 7) The output means is linked to a remote place where the account of the ordering party is located using data communication means,
The data processing means generates a right transaction with each order party account.
Item 7. The data processing device according to item 6.

(Claim 8) The other ordering party input means sets the qualification data for qualifying the registration data that can be used to price the application contract and register the application contract in the registration data of the other party side. received,
The qualification data is held in a data storage means;
Item 5. A data processing apparatus according to item 4.

    (Item 9) Item 8 wherein the qualification data is input to the other order-related party input means on the guarantor side on the order-related party side and the related party side including the financial or organizational regulator side. Data processing equipment.

    (Claim 10) The data processing device according to Item 4, wherein the data processing means is configured to compete for an application contract based only on a partner reward that is equal to or less than the consideration.

    (Item 11) The data processing device according to Item 10, wherein the data processing means is configured to establish an application contract with one partner reward selected from the partner rewards that are equal to or less than the consideration.

(Clause 12) Credit and debit records for the exchange of rights for each party are maintained by the exchange,
The data storage means holds a temporary credit record and a temporary debit record for each party concerned,
The above data processing means obtains a deduction account at the beginning of the day for temporary credit records and temporary debit records, and generates a corresponding temporary credit record or temporary debit record for each transaction that generates an exchange liability. It is configured to liquidate in sequence and only allow transactions where the value of the provisional credit record is no less than the value of the provisional debit record,
The data processing means further provides a post-transaction credit or debit, which is an irrevocable, time-invariant obligation imposed on the exchange at the end of the day, depending on the liquidation of the authorized transaction. Configured to instruct the exchange to move to the debit and credit records of each party.
Item 5. A data processing apparatus according to item 4.

    (Item 13) The data processing device according to Item 1, wherein when the application contract is established, the data processing means sends the established agreement to the data storage means and records it.

    (Item 14) The data processing device according to item 13, further comprising output means for generating a confirmation document for each related party for the established contract.

    (Item 15) The data processing device according to Item 1, further comprising second partner input means for inputting registration data on the second partner side.

(Section 16) A plurality of main data processing devices that are interconnected by at least one data communication link and that execute an operating system and application software;
At least one data storage device accessed by each main data processing device;
A plurality of data input / output channels for connection to a plurality of parties with data processing means;
Have
The data input / output channel coordinates the input of data specifying the crisis, the range of possible outcomes for the phenomenon, and the maturity,
The data processing means provided on the ordering party side specifies the rights granted at the expiration of each result within the range of possible outcomes for one of the prescribed phenomena and the amount payable to the seller Supply the contract data entered on the ordering party side to the data storage device,
The data processing means provided on the partner side is independent of the contract data entered on the order party side with respect to the probability of each result within the range of possible results for at least one predetermined phenomenon. , Supplying the registration data input on the partner side to the data storage device,
The main data processing device selects registration data for each phenomenon from the registered data of the seller for at least one application contract for each application contract, and designates each result within the range of possible results for the phenomenon By calculating the other party's reward according to the rights granted and comparing the calculated other party's reward with the consideration, the contract is priced, the contract is competed, and the application contract is established with at least one partner party Let
A system to conclude crisis management contracts among many parties.

(Section 17) An output means for the data processing means on the related party side is provided,
When the contract is established, a confirmation certificate is output in the form of data or document to the respective output means for the parties with whom the contract has been established.
Item 17. The system according to Item 16.

(Claim 18) A method for concluding a crisis management contract that expires on a future date among a large number of parties by a data processing device,
Contract data representing at least one application contract related to at least one predetermined phenomenon, which is input using at least one order party input means on the order party side, and is associated with a range of possible outcomes in the future. Supplying to the processing apparatus (a);
Regardless of the right given to the ordering party at maturity for the range of possible outcomes in the future and the contract data on the ordering party side that specifies the consideration given to the counterparty party, Data processing is performed on the registered data on the counterparty side inputted using at least one counterparty input means on the counterparty side regarding the probability of each result within the range of results that can occur in the future for one or more Supplying to the apparatus (b);
(C) holding the contract data and the registration data by data storage means of a data processing device connected to the order related party input means and the counterpart related party input means;
A step (d) in which the data processing means of the data processing device assigns a price to at least one application contract based on the contract data and the registration data held in the data storage means;
Have
In step (d), the application contract is priced and established.
Calculating the other party reward obtained from the probability and the right (I);
Comparing the consideration with the opponent reward (II);
(III) establishing a contract based on a result of comparing the consideration and the opponent's reward;
Having
Method.

(Section 19) Before supplying the contract data to the data processing apparatus (a),
19. The method according to claim 18, further comprising the step (aa) of supplying data of a predetermined phenomenon and associated result range from at least one other order party input means to the data processing device.

    (20) The method according to (19), wherein the step (aa) of supplying data of a predetermined phenomenon and related result range supplies data including a predetermined maturity for each predetermined phenomenon and related result range. .

(Claim 21) The registration data for each result represents the probability of the result occurring at maturity,
The stage (I) of calculating the opponent's reward is
Calculate the product of the elemental rights of each result and the corresponding probability,
Calculate the sum of the products over the range of results,
To get the other party's reward, adjust the total above to calculate at least the value of the day,
Item 21. The method according to Item 20, wherein the other party's reward is calculated.

(Section 22) After the stage (d) in which the application contract is priced and established,
Item 22. The method according to Item 21, further comprising the step (h) of inputting the qualification data given to the registration data on the partner party side that can be used to price the application contract by the separate order party input means. .

    (Item 23) The method according to item 21, wherein the step (III) of establishing the contract is executed in consideration of only the other party's reward less than the consideration.

    (Item 24) The method according to Item 23, wherein the step (III) of establishing the contract establishes a contract with one opponent reward selected from the opponent rewards equal to or less than the consideration.

(Claim 25) After the stage (d) in which the application contract is priced and established,
Item 19. The method according to Item 18, further comprising the step (e) of supplying data representing the result of the day of each phenomenon to the data processing device by the other order party input means.

(Item 26) After the step (e) of supplying data representing the result of the day of each phenomenon to the data processing device,
Calculating the right to the updated current day result (f);
A stage (g) of exchanging the rights between the parties involved in the competition;
Item 26. The method according to Item 25, further comprising:

(Claim 27) After the stage (d) of establishing and pricing the application contract, before the maturity,
An application for underwriting of a debt is made from one party of the established contract to another party in exchange for the consideration, and the debt is accepted from the other party of the finalized contract. Item 18 or 19 further comprising the step (m) in which the other party side becomes the party side related to the established contract in place of the one party side when receiving the approval of the exchange. The method described.

(Section 28) Credit and debit records for the exchange of rights for each party are maintained by the exchange,
After step (d) of establishing a price for the application contract,
A step (i) in which the data processing device creates a temporary credit record and a temporary debit record for each party to be held by the data processing device separately from the exchange;
(J) the data processing device obtaining a deduction account at the beginning of the day for a temporary credit record and a temporary debit record from the exchange;
The data processing device clears a temporary credit record or a temporary debit record for each transaction that results in an exchange liability, and the value of the temporary credit record is greater than the value of the temporary debit record at any time. Allowing only non-small transactions (k);
At the end of the day, the data processing device provides a post-transaction credit or debit account, which is an irrevocable, time-invariant debt incurred by the exchange in response to the settlement of the authorized transaction. (1) instructing one of the exchanges to move to the credit and debit records of the respective parties;
The method of claim 18, comprising:

    29. The method of paragraph 28, wherein the instructions given at the end of the day represent the net credit and debit accounts throughout the day for each party for all transactions of the day.

(Claim 30) After the stage (d) in which the application contract is priced and established,
Item 19. The method according to Item 18, further comprising the step (n) of supplying and storing the contract for which the data processing apparatus is established to the data storage means.

(Item 31) After the step (n) of supplying and storing the established contract to the data storage means,
Item 31. The method according to Item 30, further comprising the step (o) of creating a confirmation document for each related party for each established contract.

(Claim 32) A method for constructing a computer system for concluding a crisis management contract that expires on a future date among a large number of parties,
Interconnecting at least one order party data input means and at least one counterparty data input means to the data storage means;
Interconnecting the data storage means with the data processing means;
Interconnecting the data processing means with output means;
Have
In the data processing means,
Each phenomenon includes a range of future possible outcomes, and contract data includes future maturities, rights granted for each outcome within the range of possible outcomes, and consideration payable to the other party. , And accepting input data on the ordering party side, which is contract data representing at least one application contract specifying a predetermined phenomenon,
Regardless of the received order party input data, the registration data on the other party side is accepted with respect to the probability of each result within the range of future possible results for one or more of each phenomenon,
Select registration data corresponding to maturity for each predetermined phenomenon, price the contract by calculating the partner's reward from the rights and probabilities included in the registration data, and compete the application contract with at least one other party To complete the contract by comparing the consideration and the other party's reward,
Output confirmation data or documents for each established contract,
Further comprising executing a program for
Method.

(Claim 33) In a data processing apparatus, a method for exchanging debts between parties concerned who has a credit record and a debit record for exchanging a predetermined debt held by an exchange,
(A) creating a temporary credit record and a temporary debit record for each party to be retained by the data processing device supervisory body separately from the exchange in the data recording device;
Obtaining a debit account at the beginning of the day for a temporary credit record and a temporary debit record from each exchange and storing in a data storage device (b);
For each transaction that generates an exchange obligation, liquidate the temporary credit record or temporary debit record in chronological order, and only allow transactions where the value of the temporary credit record does not become smaller than the value of the temporary debit record at any time Performing step (c);
At the end of the day, depending on the liquidation of the authorized transaction, the post-transaction credit or debit account, which is an irrevocable, time-invariable obligation imposed on the exchange, will be transferred to the respective parties. Instructing one of the exchanges to move to the credit and debit records of (d),
Having a method.

    34. The method of paragraph 33, wherein the instructions given at the end of the day represent the net credit and debit accounts throughout the day for each participant for all transactions for the day.

(Claim 35) A data processing system for concluding a crisis management contract among a large number of parties,
Data representing at least one application contract related to at least one predetermined phenomenon on the ordering party side, which is given to the ordering party side at the maturity with respect to a range of possible outcomes associated with the phenomenon. At least one ordering party input means for entering contract data, which is data specifying the right to be
At least one counterparty for whom registration data is input for one or more of the predetermined phenomena, regardless of the ordering party for which the contract data is input, on at least one counterparty side Input means;
A data storage means linked to the order party input means and the counterpart party input means and holding the contract data and the registration data;
Linking with the data storage means, based on the contract data and the registration data, pricing the contract by calculating a counter-compensation obtained from the registration data related to the phenomenon of contract data; Data processing means for establishing an application contract with at least one partner party among the partner parties by comparing
A data processing system.

(Claim 36) A data processing system that concludes a crisis management contract among potential multiple parties,
Data representing at least one application contract related to at least one predetermined phenomenon on the side of the ordering party and given to the ordering party at maturity for a range of possible outcomes associated with the phenomenon At least one ordering party input means for entering contract data,
At least one partner input for which registration data is input for one or more of the predetermined phenomena regardless of the ordering party that inputs the contract data on at least one partner side Means,
A data storage means linked to the order party input means and the counterpart party input means and holding the contract data and the registration data;
Data processing means linked to the data storage means and for pricing the contract by calculating a counterparty reward obtained from the registration data related to the phenomenon of contract data based on the contract data and the registration data;
A data processing system.

(Claim 37) A data processing system for concluding a crisis management contract among a large number of parties,
Data representing at least one application contract related to at least one predetermined phenomenon on the ordering party side, and is given to the ordering party side at the time of maturity with respect to a range of possible outcomes associated with the phenomenon At least one ordering party input means for entering contract data, which is data for specifying rights;
At least one partner input for which registration data is input for one or more of the predetermined phenomena regardless of the ordering party that inputs the contract data on at least one partner side Means,
A data storage means linked to the order party input means and the counterpart party input means and holding the contract data and the registration data;
Linked to a data storage means, and based on the contract data and the registration data, the partner reward obtained from the registration data related to the phenomenon of the contract data is calculated for each range of the result, and the price for the contract is calculated. Data for establishing an application contract with at least one partner party among the partner parties by comparing the partner reward for each result within the range over the entire range. Processing means;
A data processing system.

(Claim 38) A data processing system for concluding a crisis management contract among a large number of parties,
Data representing at least one application contract related to at least one predetermined phenomenon on the side of the ordering party and given to the ordering party at maturity for a range of possible outcomes associated with the phenomenon At least one ordering party input means for entering contract data,
At least one partner input for which registration data is input for one or more of the predetermined phenomena regardless of the ordering party that inputs the contract data on at least one partner side Means,
A data storage means linked to the order party input means and the counterpart party input means and holding the contract data and the registration data;
Linked to the data storage means, based on the contract data and the registration data, the right is divided into an integer number of components, and for each component, the other party reward obtained from the registration data related to the contract data phenomenon is calculated. A data processing means for establishing a contract with at least one partner party among the partner parties by pricing the contract by comparing the partner reward for each component;
A data processing system.

(Claim 39) A data processing system for concluding a crisis management contract among a large number of parties,
Data that represents at least one application contract related to at least one predetermined phenomenon on the ordering party side, and is given to the ordering party side at maturity for the range of possible outcomes associated with the phenomenon in the future At least one ordering party input means for entering contract data,
At least one partner input for which registration data is input for one or more of the predetermined phenomena regardless of the ordering party that inputs the contract data on at least one partner side Means,
A data storage means linked to the order party input means and the counterpart party input means and holding the contract data and the registration data;
Linked to data storage means, and based on the contract data and the registration data, evaluates the contract by calculating a counter-side reward obtained from the registration data related to the phenomenon of contract data, and compares the counter-part reward By establishing an application contract with at least one partner party among the partner parties, and calculating a partner reward obtained from at least a part of the registration data related to the phenomenon of the contract A data processing means for periodically re-evaluating the order data of the established contract,
A data processing system.

(Claim 40) The data processing means (20), the data storage means (95, 100; 110), the data input means (51) and the data output means (51, 52) are provided, and a number of possible quantifications can be made by the parties concerned. A computer device capable of participating in contracts for future events including possible outcomes,
The data storage means allows the user to enter into the storage means event data defining future events having a large number of possible quantifiable results using the data input means (51). Means for defining the definition interfaces (E2, E3; F2; F3; G2, G3);
The future event can be determined by the user, thereby enabling the user to set the computing device to a state that processes data related to the user's selected future event,
The data storage means defines a plurality of possible quantified results of an event defined by the event data by a first party to a potential contract using the data input means (51). A first user input interface that allows selection of first data and first input data that includes a plurality of first quantities associated with each quantified result defined by the first data (E4; F4; G4) are stored,
The data storage means allows a second party to a potential contract to use the data input means (51) to define a plurality of possible quantified results defined by the event data. And a second user input that allows selection of second input data that includes a plurality of second quantities associated with each possible quantified result defined by the second data Store the interface (E5; F5; G5)
An evaluation amount of the possibility of the result corresponding to each second quantity can be determined by the second party, and the evaluation amount is related to each second quantity,
The data storage means stores means (93; 97; 104) for processing the first quantity and the second quantity to generate output data relating to the potential contract.
Computer device.

41. A communication device that allows a first party and a second party to participate in a contract related to a number of possible quantifiable future events,
A first terminal (51) including a data processing means (20), a data storage means (95; 100; 110), a data input means (51) and a data output means (51, 52) is provided.
The data storage means includes first data for a first party to a potential contract to define a plurality of possible quantified outcomes of an event using the data input means (51); and A first user input interface (E4; F4; G4) that allows selection of first input data including a plurality of first quantities associated with each quantified result defined by the first data Store
A second terminal (51) including a data processing means (20), a data storage means (95; 100; 110), a data input means (51) and a data output means (51, 52) is provided.
The data storage means includes a second party to a potential contract that uses the data input means to define a plurality of possible quantified results of events to which the first input data relates. A second input data comprising a second data and a plurality of second quantities associated with each of the possible quantified results defined by the second data; Store user input interface (E5; F5; G5),
An evaluation amount of the possibility of the result corresponding to each second quantity can be determined by the second party, and the evaluation amount is related to each second quantity,
Processing the first quantity and the second quantity to obtain a numerical value from the first quantity and the second quantity, and depending on the obtained numerical value, output data relating to a potential contract; Means (20) for generating a command for generating
Communication device.

(Item 42) The data storage means allows a user to input data defining future events having a large number of possible quantifiable results to the storage means using the data input means. Storing means for defining event definition interfaces (E2, E3; F2; F3; G2, G3);
The first user input interface defines the first data defining a plurality of possible outcomes from data defining a future event having a number of possible quantifiable outcomes stored in the data storage means. The second user input interface is adapted to select a plurality of possible results from data defining future events having a large number of possible quantifiable results stored in the data storage means. Adapted to select the second data to be defined;
Item 42. The communication device according to Item 41.

(Section 43) The second user input interface operates such that a plurality of second input data can be selected.
The means (20) for processing the first quantity and the second quantity processes a second quantity of the plurality of selected second input data using the first quantity, Adapted to derive a numerical value from the plurality of selected second input data and generate output data in response to the derived numerical value;
Item 43. The computer device according to Item 40 or the communication device according to Item 41 or 42.

    (Item 44) The means for processing the first quantity and the second quantity may be configured to determine the second selected input data based on the comparison of the numerical values derived from the second input data. Item 44. The computer device or communication device according to Item 43, wherein the computer device or the communication device is adapted for selecting one second input data from the second input data.

    (Item 45) The computer device or the communication device according to Item 44, wherein the second user input interface further includes identification information generation means for generating identification data for identifying a party who has selected the second input data.

    (Claim 46) The means for processing the first quantity and the second quantity includes a numerical value derived by the means for processing and identification data for identifying a party who has selected the second input data. Item 46. The computer device or communication device according to Item 45, which operates to generate output data on the basis thereof.

(Section 47) The first user input interface is adapted to allow entry of participant constraint data;
The means (20) for processing the first quantity and the second quantity compares the participant constraint data with the identification data, and based on a result of the comparison, the second quantity associated with the identification data. Adapted to determine whether to process a plurality of second quantities of input data;
Item 47. The computer apparatus or communication apparatus according to Item 45 or 46.

    48. The means (20) for processing the first quantity and the second quantity may include the second quantity to a first quantity associated with a quantified result that may occur with the first data. Multiply the second quantity associated with the same possible quantified result by the data of and the product sum obtained by multiplication for each possible quantified result defined by the first data 48. A computer device or communication device according to any one of clauses 40 to 47, adapted to derive a numerical value by obtaining.

(Item 49) The first user input interface further includes means for inputting party identification data related to the first party,
The second user input interface further comprises means for inputting a discount rate and a fee rate;
The means (20) for processing the first quantity and the second quantity includes the first quantity according to the discount rate and the commission rate associated with the party identification data related to the first input data. And adapted to derive the numerical value from the second quantity,
Item 49. The computer device or communication device according to any one of Items 40 to 48.

(Section 50) The first user input interface operates to input numerical constraint data;
Means for processing the first quantity and the second quantity (209 is a result of comparing the numerical constraint data with the numerical value derived by processing the first quantity and the second quantity; Adapted to generate output data based on
50. The computer device or communication device according to any one of Items 40 to 49.

    (Claim 51) The means (20) for processing the first quantity and the second quantity includes the numerical value processed according to the discount rate and the fee rate as price information related to the potential contract. Item 52. The computer device or communication device according to Item 49, adapted to control the data output means (51, 52) for display as.

(Section 52) The first user input interface operates to input numerical constraint data;
The means (20) for processing the first quantity and the second quantity compared the numerical constraint data with the numerical values derived by processing the first quantity and the second quantity. Based on the result, adapted to generate output data,
The means (20) for processing the first quantity and the second quantity includes the processed first quantity and the discount rate depending on a relative value of the second quantity and the numerical constraint data. And adapted to control the data output means (51) to output the numerical value processed by the fee rate;
Item 49. The computer device or communication device according to Item 49 (Item 50 depending on Item 49).

53. The data storage means (95, 100, 110) are adapted to hold account data relating to each party,
The means (20) for processing the first quantity and the second quantity is adapted to update the account data in accordance with the numerical values derived from the first data and the second data. ,
Item 53. The computer device or communication device according to any one of Items 40 to 52.

(Item 54) The first user input interface and the second user input interface each include a confirmation unit.
The means (20) for processing the first quantity and the second quantity is adapted to update the account data in accordance with the derived numerical value only when a confirmation input from the confirmation means is received. is doing,
Item 54. The computer device or communication device according to Item 53.

(Claim 55) The method further comprises means for inputting the result of an event that may produce a large number of quantifiable results,
Clause 53 or 54, wherein the means (20) for processing the first quantity and the second quantity is adapted to update the bill data in response to the first quantity associated with the result. Computer device or communication device.

[Appendix A]
Glossary of key terms
Alpha (X)
The value of the situation specified by the ordering party is the inflection point of contract right payment (profit) of the Xth future product situation value

Application Promoter
Under a defined contract application program that includes: the specific product that was applied for the transaction; the stakeholder category and stakeholder terms; and the stakeholder continuity and stakeholder dispute resolution nature. Authorized by VIRPRO to identify and manage defined rules and regulations in

Automatic / manual deal and no deal flags
Indicator that specifies how each stakeholder is notified to the contract application program and how the stakeholder wants to do business with another stakeholder

AXSCO
Communication coordination and safety devices linked to all stakeholders and component applications

B.
Base pricing probabilities
The price set by the seller for the unit right payment of the contract at each future index value that may be expressed in consideration / right, currency, and local currency units formally specified in the contract

Beta (X)
Desired right of interest of the ordering party expressed in the desired currency unit of the contract right profit (payment), the local currency unit of the contract right profit (payment) corresponding to the inflection point of the Xth event value ( Payment)

Bilateral Payments Netting indicator
An indicator that provides the net "individual" variable "current" value of payment / reception fees between all participating stakeholder pairs

Bilateral Payments Netting indicator
Indicator that gives the net payment of total payment / receipt at the end of each individual day between a pair of participating INVENTCO stakeholders

C.
Commission rate
The minimum required percent profit difference required by potential opponents that exceeds the “lossless” bid price of the order requested by the parties.

Consideration / Entitlement Transfer Entity
VIRPRO and the applicant are allowed to meet the limited minimum level of financial strength, lending qualifications and integrity, maintain the consideration / rights account for interested parties and transfer the above assets according to instructions. Person

CONTRACT APP stakeholder types
Expected stakeholder types include applicants, product sponsors, product ordering parties, opponents, opponent guarantors, regulators, consideration / rights transferers, various others The person concerned.

Contract and Product “absolute loss” limit
Limits on the value of the maximum absolute loss specified by potential opponents prepared to maintain the contract / product independent of the assessment of the likelihood of a particular level that could be lost

Contract and Product “expected loss” limit
Limits on the value of the maximum expected loss specified by potential opponents prepared to maintain a contract / product based on an assessment of the likelihood of all levels of potential loss of opponents

Contract authorization
The process of verifying whether an ordering party's product purchase order contains appropriate data for the requested product and whether the ordering party has been confirmed and certified correctly

Contract Collateralisation indicator
Is the asset / money (collateral) required to be transferred to an independent trust fund on a regular basis to ensure that the counterparty can liquidate the obligation to pay potential rights on the maturity of the contract? Descriptor set by the applicant himself that specifies what and what is the basis if required

Contract confirmation
All affected by the purchase orderer, including approving the required product consideration and fees of the related party by the relevant consideration / rights transferor by either automatic or manual authorization Process to ensure stakeholder positive agreement

Contract Matching
Refer to the processing of the establishment of the ordering party / potential opponent.

Contractual Obligation
a. A binding responsibility in which one person (or group) must give the product, service or information to another person (or group) in exchange for the agreed amount of product, service or information; b. In order to allow the restriction of activities imposed by those who have been given other authority based on an agreed relationship as a condition that everyone participates in at least one component device. VIRPRO and binding responsibilities for each other

Contract portfolio Netting
Term used to describe the process of "offset" or "get as net profit" for future payment rights and obligations between ordering parties and opposing parties in a bilateral or multilateral manner

Currency and National Currency exchange rates
Rate used to convert contract consideration / rights currency and local currency requirements into product consideration / rights currency and local currency units

D.
Deal flag
An indicator or “flag” to be notified to the contract application program indicating that it is a stakeholder who is satisfied to unconditionally agree with the other party with the flag set

Defined Circumstances
Possible combinations of product-order information categories provided by ordering parties

Defined Probability Distributions
A set of evaluation probability parameters including at least a probability distribution type indicator, the expected value of the distribution, the standard deviation of the distribution, and the probability distribution adjustment value or function specified by the ordering party.

Desired Currency Denomination of Contract Entitlement
A term that describes the potential payment currency that the ordering party wants to receive from the requested contract

Desired Currency Denomination of Consideration Payment
A term that describes the currency of the consideration that the ordering party wishes to pay as the required consideration for the contract sought.

Desired National currency Denomination of Contract Entitlement
Term indicating the local currency of potential rights payments that the ordering party wishes to receive from the requested contract

Desired National currency Denomination of Consideration Payment
A term that describes the local currency of the consideration that the ordering party wishes to pay as the required consideration for the contract sought.

Discount rate
The rate used to determine the current value of the expected future rights of potential opponents

E.
Entitlememt (right)
The payment expected by the parties presented at maturity as specified for each outcome within the scope of the outcome. Payments can be both positive and negative values over the range of results and can be either money or non-monetary goods, services, promises, credits or guarantees.

EV-CE evaluation (EV-CE evaluation)
A primary contract price detection mechanism that means "the certainty of the expected value equivalent to the valuation" is obtained by calculating the current expected value or the value of the future contract.

Expected Value
EV- which means the sum of the product of all possible contract rights profits / payments and the assessment of the order party / counter party's assessment of the probability of the future occurrence of the rights contractually occurring CE evaluation function

Expected value limits on a Counterparty's aggregate product portfolio
“Equivalent maturity date”; the limit of the value of the option specified by the potential opponent at any time specified for “maturity date of the same month” and “all possible maturity dates”, and the product expectation Includes the maximum (and possibly minimum) ratio of the total expected loss of the opposing product's total product portfolio that can be accounted for by the loss limit and individual contract / product expected loss.

G.
Gamma (X)
The ordering party identifies between alpha (1), beta (1) and alpha (2), beta (2), etc., to which the gamma represents all possible shapes that can be mathematically defined The desired function shape

I.
I-INVENTCO
INVENTCO basic structural components

INVENTCO
A collection of at least one (potentially related) device that is a combination of telecommunications, computing and other forms of infrastructure and a number of markets and support services arranged by the infrastructure

M.M.
M-INVENTCO
Virpro certified “market” application software repository

Manual deal flag
An indicator or “flag” that is communicated to the contract application program by an interested party, indicating that the interested party wishes to manually certify the related agreement with another interested party of the flagged party

Multilateral Payments Netting indicator
Net profit from total payment / receipt at the end of each individual day between participating stakeholder and identified third party trustee / liquidator
Multilateral Obligations Netting indicator
Net income derived from the individual “fluctuating” net present value of future payments / receipts between the participating stakeholder and the identified third party trustee / liquidator

N.
Negative Contract Payoffs
Contract type where the contract order party has the contingent interest of the potential counterparty of the contract (ie, the reverse of a normal contract)

No Deal flag
An indicator or “flag” that is communicated to the contract application program by the interested party, indicating that the interested party is not willing to agree at all with the other interested party of the flag

O.
Ordering party Contingent Claims Function
Identification of product payments or mathematical functions to calculate product payment requirements for order parties

P.
Portfolio Product “expected loss” limit
Specified by a potential opponent of maximum expected loss prepared by the potential opponent to maintain the product portfolio based on an assessment of the likelihood of all levels of potential loss of the opponent Value limit

Product Ordering Party
Those who are interested in contract application program products and are able to obtain contract application program products

Product Establishment date / time
Date / time when applicant first provides limited product for trading

Product future event value “density” indicator (product future event value “density” indicator)
Indicator that identifies the number of midpoints between the lowest and highest future product definition values specified for the product by the applicant / product sponsor

Product event value “width” indicator (product event value “width” indicator)
An indicator that identifies the range of values (minimum-maximum) of future events offered by the product as set by the applicant / product sponsor

Product future event value
Term used to indicate the actual value of a limited product at maturity date / time

Product Maturity date / time
The date and time when the applicant is required to determine the actual value in order to make payments related to the contracted contractual rights

Product Price Quote requests
A type of product purchase order in which the closing process is stopped and the result is communicated to the ordering party when the desired price pricing or price pricing range is achieved

Product Purchase Orders
A specific product purchase order consisting of three types: automatic order, manual order and “hidden” order, where the ordering party seeks to establish potential opponents

Product Purchase Order withdrawals
A request issued by an ordering party to stop processing a purchase order that has been presented in advance but has not yet been confirmed.

Product potential Counterparty
Those who have been approved by VIRPRO and the applicant, apply for a contract application program that exceeds the limited minimum level of financial strength, loan qualification and integrity, and is limited to interested parties of product orders

Product Sponsor
A person who is authorized by VIRPRO and the applicant, and who is responsible for defining product parameters in detail, including timely determination of product value

R.
Regulator
A person who is authorized by VIRPRO and has local, state, national or international jurisdiction over at least one contract application program

S.
Set of Pricing Probabilities
Identified by the value of the “limited environment” and applied to all possible future product situations defined for the product by the applicant himself, Probability range to apply to the class

Stakeholder
Participants registered in the component part of at least one INVENTCO

V.
Value Dates
Each date / time when the contracted consideration and rights established are agreed to be contracted by the relevant ordering party / counterparties

VIRPRO
INVENTCO network and general management component

X.
“X”
Term used to indicate the number of contract payment (profit) inflection points (including extreme points) that the ordering party seeks within the tolerance of the value of future product situations

[Appendix B]
CONTRACT APPS (contract application program)
Overview A contract application program is a term that refers to some form of application software that may (but need not) exist within the "market" software repository of the INVENTCO device (M-INVENTCO). . The purpose of each contract application program is dual. First, INVENTCO has a legitimate interest in the profit participation ordering party and the related parties and the nature, size and composition of the above trading / exchange / transfer. The sale / exchange / transfer of crisis avoidance contracts (and derivatives of those contracts) between opposing parties authorized by others registered within. Second, properly manage all established / confirmed contracts until the maturity date including final settlement.

  Each contract application program performs the above tasks according to specific rules that are defined and embodied by stakeholders in the contract application program. The contract application program exists efficiently on AXSCO and in M-INVENTCO.

Stakeholder Type The contract application program is a general type of “unique” (as distinguished from other INVENTCO stakeholders) in the following eight (and possibly less): Contain the person. The above eight types include the applicant himself, the product sponsor, the product ordering party, the potential product counter-participant, the counter-participant guarantor, the regulator, the consideration / right transferor, and others. Of various parties.

  The above stakeholders are described in some detail below, and the applicant himself is the person responsible for the overall function of the contract application program (the responsibility is guaranteed by VIRPRO). The product sponsor is the person who promotes and supervises the rules of buying and selling, and then manages limited contingent claims that contract the products selected for inclusion in the contract application program by the applicant. A product ordering party is a person who tries to obtain a product of the contract application program from a potential product opponent (the product ordering party may be a product competition party). A potential product party is a person who potentially prepares the product needs of the product order party's contract application program (potential product relationship opponents may be product order parties). The Opponent Guarantor is the person who guarantees the ability of the Product Opponent to settle any / all of the potential contract transfer obligations to the Product Order Participant. As a result, it becomes an opponent related to the product order related person. The regulator oversees the ongoing actions of all other interested parties involved in the contract application program, in particular the guarantor of the opponent. A consideration / right transferor is a person who maintains an “account” in order to transfer the consideration / rights required by all other contract application program stakeholders to all others. The various parties are all others who have a stake limited to the functionality of the contract application program.

  Various parties include independent persons contracted by the applicant or product sponsor to formally determine the “value” of the product on the maturity date, as well as trustees / liquidation that earns the net benefits of multilateral debt and payments. Human organization, independent (non-regulatory) tax and other administrative authorities, electronic “gateway” providers (outside INVENTCO), and host device organization (in an INVENTCO device linked to a common host device) Contract application program). There is no limit to the number of unique stakeholders that a contract application program will accommodate in each of the above general types.

The product type contract application program gives any combination of the values of a number of attributes to the “product type” of the crisis avoidance contract. Among the many attributes listed above are the basic nature / purpose of the product, the date of establishment / maturity of the product, the consideration / right unit type, currency (if applicable) and local currency (if applicable). It includes a consideration / right identifier associated with the product, a “width” and “density” identifier of the possible future value of the product, and various other product descriptors.

  The “Basic Property / Purpose of Product” attribute may incorporate an identifier including a temporary rights payment size identifier, a market identifier, a secondary market identifier, and a market type identifier. The “temporary right payment scale identifier” specifies a numerical value of the scale for the temporary right payment required by the ordering party. The market identifier is whether the product is related to “actual” or “prospect” phenomena, the number of such phenomena (if applicable), and the category of applicable phenomena (eg industrial, scientific) And financial market connection). The secondary market identifier gives a more specific descriptor for the product. The market type identifier is the day of the applicable future period (eg, not limited as long as such as “predetermined contract expiry date / hour”, “at a specific time before contract expiry date / hour”, etc.) / Time and the related future (for example, not limited as long as it is an indicator of some relevant value of the phenomenon (spot value, average value, etc.) or an indicator of the “rate of change” of some value of the phenomenon) Identify the type of situation.

  The “product establishment / maturity date / time” attribute indicates the date / time when the applicant first applied for the sale of the product and the date / time when the given product expires (ie, contract transfer can be performed). Specify the date / time when the product sponsor is required to determine the value of the actual situation.

  The Consideration / Right Identifier Related to Product in Consideration / Right Unit Type, Currency (if Applicable), and Local Currency (if Applicable) Attributes have the following types: (Rights and Rights, Physical Assets) , And all possible types of “monetary”, and associated consideration / right types, and in the case of a “monetary” consideration / right type, the currency of the consideration / right (this currency type is public / private (Including deposits from record depository deposits, deposits from commercial credit card companies, deposits from commercial banks, central bank deposits, deposits from tax authorities, deposits from non-bank bill exchanges and depositories), and "money" In the case of a target consideration / right type, a consideration / right domestic currency identifier (this national currency type may be in the form of any national currency or a synthetic currency) is specified.

  The “Width” and “Density” identifiers of the possible future value of the product attribute, respectively, provide the minimum and maximum allowable range of future value provided by the product and the product. Determine the number of intermediate points between the predetermined minimum and maximum values of the future events that have been made.

  The “Descriptors for various other products” attribute identifies the product for which the stakeholder's access has been granted by the applicant in question and the form of the trading service by the applicant in question. (This product attribute is related to such things as contract portfolio net profit, contract collateral, consideration loan amount, possibility of specifying negative contract rights of ordering parties, and effectiveness of secondary / derivative market product trading. It is like a product that specifies the degree of “transparency” in buying, selling and clearing and settlement by the applicant in question (which identifies the accessibility of the product to the scope of feasible “stakeholder services”) .

[Transaction type]
The scope of primary, secondary, derivative primary and derivative secondary crisis avoidance contract transactions is accommodated by the contract application program.

  Within the scope of “primary” (and derivative primary (eg, optional)) crisis avoidance contract transaction types (mainly handled by processes 2 and 4 described in Appendix C) Order related party order (and optional order) seeking the “successful” of the contractor, request price estimate (and optional price estimate) request of the order related party, and cancellation of the existing product order of the order related party (and product order) (Cancellation of the above options). An automatic order is an order that is ready to be automatically established (even if the stakeholders of other contract application programs have specified the conditions of “successful” in advance) The ordering party will be automati- cally when there is no stakeholder in the normal automatic order (which is only subject to the restrictions set by the party's order) and the contract application program (which requires manual authorization of the transaction). Orders that are ready to be automatically established, even if the stakeholders of other contract application programs have specified the conditions for “satisfied” in advance, only the restrictions set for the order of the related parties By doing so, it can potentially identify ordering parties) and anonymous automated orders. Manual ordering (the ordering party requires manual approval before the order is finally approved, ie the contract is “confirmed” after the opposing party “successful” is implemented. Normal manual ordering (subject to only the constraints set for the ordering party's orders), even if other contract application program stakeholders have previously identified the conditions for "successful" If there is no stakeholder in the contract application program that specifically requires the transaction to be authorized, the ordering party will require manual authorization before the order is finally approved, ie the opposing party After the “successful” is executed, before the contract is “confirmed”, even if interested parties of other contract application programs have specified the “satisfied” conditions in advance, Only under certain restrictions and by doing so, It is possible to certify to the ordering party) consisting of a manual order of anonymity.

  The scope of “secondary” (and derivative secondary (eg, optional)) crisis avoidance contract transaction types (mainly handled by Processes 3 and 5 described in Appendix B) are identified within existing contracts. The product order (and optional order) of the acquiring party who intends to “acquire” the status of the stakeholder in the “crisis countering relationship” is composed of an automatic order and a manual order.

  An automatic order is an order that the acquisition party is ready to be automatically completed (even if the stakeholders of other contract application programs have specified the conditions of “satisfaction” in advance. The acquisition party is automatic if there is no stakeholder in the normal automatic order (which is only subject to the restrictions set by the party's order) and the contract application program (which requires manual authorization of the transaction) Orders that are ready to be automatically established, in addition to all the “satisfied” conditions specified in advance by stakeholders in other contract application programs, as well as the restrictions set for the order of the acquiring parties By doing so, it consists of anonymous automatic orders (which can potentially certify acquisition parties).

  Manual orders (acquisition officials require manual approval before the order is finally approved, i.e. after the "successful" is implemented, the contract "sell" is "confirmed" Before (manual manual orders), subject only to the constraints set for the order of the acquisition party, even if other contract application program stakeholders have previously identified the conditions of “successful” If there is no stakeholder in the contract application program seeking to authorize the transaction, the obtaining party will require manual authorization before the order is finally approved, i.e. After being implemented, before the contract “sell” is “confirmed”, even if interested parties of other contract application programs have specified the conditions of “successful” in advance, they are determined in the order of the acquiring party. By taking the constraints only and doing so, It is possible to certify the parties) consisting of a manual order of anonymity.

Primary product evaluation process type The contract application program allows all potential opponents to follow all expectations according to the “Expected Value / Usage Equivalence (EV / U-CE)” evaluation method or other mathematically definable evaluation method. Allows limited (primary and derivative primary) product orders to be “bidding” automatically.

  In the case of the “Expectation-Establishment Equivalence (EV-CE)” evaluation scheme, each potential opponent is limited to an indicator of limited attributes with product orders that are not yet known, and basic Fee rate, base discount rate, base consideration / right unit, currency and local currency conversion rate pair (if applicable), base unit product price, and (provided by the specified order party) Specify the desired adjustment to the determinants of the preceding base bid price that depends on the particular order.

  The above-mentioned limited attribute indicators for product orders that are not yet known (referred to as a limited environment) are the many attributes of the contingent charges that are sought, and the ordering party accepts it by the opposing party Whether the ordering party is interested in participating in the potential net gains and collateral of the application program, whether the ordering party is interested in participating in the application program. Reflects a combination of multiple features of an order (independent of the ordering party) including the maximum (and possibly minimum) consideration that is ready. The basic fee rate specifies the margin of the minimum percentage profit required by the opposing party beyond the zero bid profit bid price of the product order.

  The above basic discount rate determines the current value of the expected future situation of the counterparty involved in the contract (the net gain of the consideration of the ordering party and is expected to occur for the future revenue stream. ) If applicable, the above basic consideration / right unit, currency and local currency conversion rate pairs are converted into the basic consideration / right unit, currency and local currency of the ordering party, and the contract formation process is the product. It will be possible to compare the price of opponents against orders.

  The product price of the base unit is the price set by the potential opponent for payment of the unit right of the contract at each possible future value, and is the officially specified price / right of the contract. Type and, where applicable, expressed in units of currency type and local currency type (the unit price is a number entered directly for each possible future product situation (the sum of the numbers is 1) Or may be specified as a parameter of a defined mathematical function). The desired adjustments to the preceding basic bid price determinants that depend on the specific ordering party presenting a specific order include fee rate adjustment, discount rate adjustment, currency exchange rate adjustment, and domestic Includes currency exchange rate adjustments.

  For the “Expected Availability Certainty Equivalence (EU-CE)” evaluation method, each potential counterparty will be responsible for all consideration and rights “payments” that may be assumed to be related to the product / contract. All of the above parameters applied to the EV-CE evaluation method are specified in addition to the “usability benchmark” numbers.

Primary Product Formation Process Type Contract application programs can provide any of a number of possible (primary and derivative primary) order formation processes as well, where the process is sequential Multiple processes including processing and parallel processing may be used.

  The sequential order creation process is characterized by the “sequential decision” and “settlement” rules that it implements, which include “Last In First Out (LIFO)”, “First In First Out (FIFO)”. There are many types, such as priced priorities. The closing rule may be any of a number of types, for example, a specific closing process may be for each product ordering party to present a product price below the highest price that the ordering party is willing to pay ( Alternatively, the contract price determined is the lowest price presented by the potential opponent or the “highest price” specified by the order party and the potential opponent. Either the midpoint between the lowest prices presented by the parties), or for each potential product opponent, the highest price above the price at which the opponent is ready to trade. Find the order party ready to pay (where the determined contract value is the order party's “highest price” price, or the lowest price the order party is ready to receive and the order relation Value of the “maximum value” It is any one of the midpoint or the like between the).

  Parallel order establishment processing is a process for obtaining an optimal solution of a certain type according to a predetermined purpose. The purpose is, for example, “order relation-maximizing the number of established opponents” or “between the values of the actual and desired order participants and the established attributes of the opponents (according to the prospective importance). Minimize the value of the function that identifies the sum of the differences (which may be weighted).

  Furthermore, both the sequential and parallel establishment processes can provide provisional contract establishment rules; and a pre-tax and post-tax optimization mechanism.

Application types Contract application programs include “intra-organization” application programs or “public” application programs, “single potential opponents” application programs or “multiple potential opponents” application programs, “regulators”, etc. Application programs that differ in the degree and form of monitoring of interested parties of the application, and application programs that differ in the degree and form of monitoring of potential product related parties by the “partner guarantor”.

  The contract application program is postponed to an “immediate” date (which means exactly the time at which the contract was confirmed) or to a predetermined time in the future expressed in seconds, minutes, hours or days. Support the value of “payment”. Similarly, a contract application program has an “immediate” date (which means exactly when the applicable applicant has formally notified the other contract application program stakeholders of the outcome of the contract that expires), Alternatively, it supports the value of the right “payment” deferred until a predetermined time after the “result” of the contract to maturity is known.

  According to the contract application program, contracts are allowed to be modified and settled after creation. Contracts: modified through direct negotiations on specific contracts by the relevant “crisis counter parties” or acquisition / sale of “derivative” secondary crisis avoidance contract transactions (see Appendix C, Process 5) Is possible. Similarly, a contract can be settled after creation by negotiating a contract (internal or external to INVENTCO) and the contract between the initial ordering party and the opposing party. In addition, contracts can be efficiently settled by interested order parties / counterparties by obtaining a mirror image of the contract (inside or outside of INVENTCO).

Post-order process types The contract application program is responsible for various general types of "post-order process" management functions for the above general types of "transactions", including all contract applications. The ability to maintain a formal registration of contractual responsibilities with the parties authorized by VIRPRO who are outside of either the applicable contract application program or the entire INVENTCO; Independent evaluation of consideration and rights and obligations between application program stakeholders and between contract application program stakeholders and those authorized by VIRPRO outside each applicable contract application program Based on the functions and considerations of rights and obligations related to contract application program transactions, the contract application program The ability to determine and implement transfer of “collateral” consideration / rights between program stakeholders and those authorized by VIRPRO outside each applicable contract application program, and the interests of the contract application program Necessary net interest-bearing “consideration / rights debt” between parties involved and between the parties in the contract application program and those authorized by VIRPRO outside each applicable contract application program Functions determined and acquired in accordance with the contract application program stakeholders, and parties authorized by VIRPRO outside the contract application program and applicable contract application program stakeholders (nominated interests) And the function of determining and acquiring the multilateral net income of the accumulated “consideration / rights of debt” as necessary, and the maturity. The ability to manage contract-related processing, accounting, reporting and rights “payment” tasks, all contract application application (and other INVENTCO) stakeholders, and VIRPRO outside INVENTCO permitted The function to determine the device usage and access fee paid between the contractors, and the VIPRO who is outside each contract application program applicable between the contract application program stakeholders and the contract application program stakeholders Functions to determine and implement the transfer of consideration / rights “obtained as bilateral net income” as necessary, between interested parties in the contract application program, and between interested parties in the contract application program A person authorized by VIRPRO outside each applicable contract application program (the “Bill Exchange” of the nominated stakeholder) Ability to determine and implement transfer of consideration / rights “obtained as multilateral net income” as needed, and customization of stakeholders in contract application applications (and other INVENTCO) A function to create and distribute the generated information is included.

Complementary process types Contract application programs are responsible for many other types of support processes, which include consideration, rights, and other `` stakeholders '' independent of the transfer initiated by the contract application program transaction. Allow payments' obligations to be transferred between each other (see the description of Process C in Appendix C), and contract application program (and other INVENTCO) stakeholders Provide shared access to specific devices to contract application program (and other INVENTCO) stakeholders to help determine the best interface method (see Appendix C, description of process 8); And make it easier for stakeholders in the contract application program (and other INVENTCOs) Providing access to a range of selected “value added services” (see the description of Process 9 in Appendix C).

Order Placement Constraint Type During trading, the Contract Application Program allows all interested parties for a particular Contract Application Program, in particular, any other stakeholder that they want to trade or do not want to trade, and Identifies conditions under which you want to manually allow certain aspects of a transaction involving stakeholders in any other contract application program that controls some form of authority.

  When specifying other stakeholders that you want to trade or do not want to trade, the stakeholders in the contract application program have a variety of choices. The applicant himself / herself specifies acceptable product sponsors, products, ordering parties, and potential opponents by type individually within the scope of the application. Similarly, product sponsors specify acceptable applicant principals, products, ordering parties, potential opponents, and opponent guarantors individually by type within the scope of the application.

  Product Opponents and Order Participants (collective) specify the order / potential counterparts that they want or do not want to trade individually by type, and the extent and application of preparation to be included in the contract net income Specify the collateral arrangement provided by the principal, specify the applicant himself, the product sponsor, the product, and the consideration / transferee individually by type, who want or do not want to trade, and conduct the transaction Specify the ordering party / potential opponent who wants to trade exclusively and specify the degree of transparency of the transaction that they need and confirm the order before confirming Specify whether you want to allow manually.

  Potential opponents are either order participants who are ready to apply for a loan, or the class of order participants (and what are the conditions), and the “order related guarantor” is ready to apply for a loan. A person and their loan terms can be specified. Similarly, a product order party (only) designates a guarantor guarantor (individually by type) that he or she does not want or want to trade, and he / she can implement a specific form of counterparty-loan. You can specify the opponents you want to trade exclusively or preferentially, and you can designate potential “order relationship guarantors” that you want or do not want to trade (outside INVENTCO).

  The opponent guarantor can designate potential opponents authorized to buy and sell, the applicant himself / herself who is prepared to indirectly establish a relationship, the product sponsor, and other ordering parties. Similarly, a regulator can designate a counter party guarantor authorized to buy and sell, an order party, an applicant himself, a product sponsor, and a product. Finally, the consideration / rights transferor will have the latest rules regarding the ordering party who is or is not willing to trade, the opposing party, the applicant himself, the product sponsor, and the opposing party guarantor. Can be monitored and maintained.

Order Participant Requirements During trading, the Contract Application Program will provide information on the above “Product Type” and “Interactions with Other Stakeholders”, a number of attributes of the specific order you are seeking, and the contract price. Is the credit approved by the other party, or is interested in using the potential net gains and collateral of the application program, and the highest is ready to pay for the specified product (And in some cases the minimum) of the primary product ordering party for the contract application program when registering an order for the product of their choice to specify the price "price" and the size of various other needs Requires interested parties. Here, the various other needs described above include the name / title that the other contract application program interested party wants to be identified, the time that the order is desired to be presented, the order The time interval that the order needs to be maintained before it is automatically canceled, whether it is ready to accept part of the order, and the market transparency you want to be exposed to The degree of gender, whether you want to have the option to trade the established contract on the authorized INVENTCO secondary market (see the explanation for Process 5 in Appendix C), and potential opponents of the order If it is desired to manually consider / authorize the estimate of the potential opponent and if the estimate of the potential opponent needs to be considered / authorized manually, Seki After given to the person, the ordering party is the largest of the time and you want to consideration of the estimates, include the consideration / entitlement transfer entity of the relevant account you want to make / receive a "payment".

  The multiple attributes of the particular primary order that the ordering party is seeking may or may not want to directly enter the “adjustment” of the desired contingent billing order right, whether one-dimensional or multi-dimensional. Whether it wants to mathematically specify a function of the right to reflect the desired product order (indicates the contingent contract right conditioned on at least two phenomena) Includes “consideration / right unit”, “currency” (if applicable), and “domestic currency” (if applicable) that you wish to “pay” / “receive” the rights. If the ordering party wants to mathematically specify the desired primary product order as a one-dimensional rights function, the entered condition “X” is searched by the ordering party within the acceptable range of future product events. Indicates the number of “inflection points” (including extreme points in the range of values) of the contract right being entered, and the entered condition “alpha (X)” is the contract for the value of the Xth future product situation Indicates the value of the situation identified by the ordering party corresponding to the inflection point of the right, and the inputted condition “beta (X)” identifies the ordering party corresponding to the inflection point of the value of the Xth situation The desired amount of rights (desired “consideration / right form”, “currency” and “local currency” rights units); the input condition “gamma (X−1)” is [alpha (1), Beta (1)] and [Alpha (2), Beta (2)], [Alpha (2), Beta (2)] and Alpha (3), Beta (3)], etc. (if applicable) represent the ordering party's specified desired function shape between each, where gamma is defined mathematically Represents all possible forms that can be done.

Potential Counterparty Requirements During trading, the Contract Application Program further defines the various parameters that serve as the basis for automatically evaluating orders, so that the primary product “Potential Counter Relationship” to the Contract Application Program. You need a stakeholder. The above parameters include a parameter for which a stakeholder of the primary product “Potential Counter Relationship” wants to establish a “bidding for consideration” based on a product order established, and the primary product “Potential Counter Relationship”. The stakeholder of “ Included are possible expected product portfolio constraints that need to be met if a stakeholder “stakeholder” stakeholder becomes a stakeholder for a defined product order party order.

  In defining the parameters that one would like to establish a “Bid for Consideration” for a product order defined under the “EV-CE” valuation scheme above, each potential counterparty should, in particular, identify all possible product orders. Appropriate “limited environment” indicators, basic “fee rate”, basic “discount rate”, basic “consideration / right unit”, “currency” and “domestic currency” (if applicable) A basic "unit product price", a basic commission rate, a discount rate, and an exchange rate on a specific product order according to a set of exchange rates and a predetermined value of a "limited" indicator (based on a specific product order) And the desired adjustment to the unit product price is required.

  Individual contract and product constraints that may be required to be met if a potential opponent is to become a counterpart to a given product order party are absolute loss limit constraints (this constraint is a single Specific constraints and / or function constraints), and an expected loss limit constraint (this constraint takes into account the likelihood that potential opponents will produce any feasible future product value) , Define the maximum “expected” total loss you are willing to incur in the contract / product) and the overall expectation of the potential opponent's contract / product that can be explained by the defined individual contract / product expected loss Includes constraints on maximum percentage of total loss. Similarly, expected product portfolio constraints that may be required to be met when a potential counterparty becomes a counterparty against a defined product order party is due to the expected loss of individual contracts / products. Includes the maximum (and possibly minimum) percentage of the total expected total loss of the potential opponent product portfolio that can be accounted for.

Communication Interested parties in the contract application program communicate with the applicable contract application program via AXSCO. Individual “stakeholder-AXSCO” communication can be done in the following ways: voice communication with AXSCO-coupled “live operator” or “record communication” device, direct AXSCO touch phone (touch-teleophone) communication, or any / all methods of computer-to-computer communication with AXSCO (dedicated or via a dial-up line). In any of the above three communication formats, the stakeholder of the contract application program must use the computer hardware and / or software mechanism specified during communication with AXSCO (quoted in Appendix H). (Including "payment" permission "black box" device).

Component processes When appearing as telecommunications / computer software on telecommunications / computer hardware, each contract application program uses multiple data files and consists of clusters of processes in at least one processing unit (details It is described in Appendix C). The data files associated with nine (and more or fewer) specific processes are in the contract application program, and nine processes manage and update the files that support all other processes. A process that handles tasks (called process 1), a process that handles the receipt and processing of “primary” crisis management contract transactions (called process 2), and the receipt and processing of “secondary” crisis management contract transactions Process (referred to as Process 3), process handling receipt and processing of “Derivative-Primary” Crisis Management Contract Transactions (referred to as Process 4), and receipt and processing of “Derivative-Secondary” Crisis Management Contract Transactions Process (called process 5), process to handle “office work” management of all four types of crisis management contract transactions (called process 6), and stakeholders Processes other than transactions related to consideration, rights, and other “payment” debt transfers (referred to as Process 7), and contract application program (and other INVENTCO) interested parties A process (referred to as Process 8) that handles access to the expert system that helps the above stakeholders to determine the best way to interface with the contract application program for the scope of “value added services” facilitated by INVENTCO (and It consists of a process (referred to as process 9) that handles the access of other INVENTCO stakeholders. The above processes may function in parallel.

[Appendix C]
Contract application program process description Process 1
Process 1 handles file management and update tasks that support all other processes (FIG. 18). Product (PRODUCT), Product Transaction (PRODUCT TRANS S), Agreement List (DEAL LIST) and Agreement List Transaction (DEAL LIST TRANS) files shown in FIG. 18 are primary, secondary, derivative primary, and derivative. Applied individually or collectively to secondary contract orders. The Sell Price (SEL PRICE), Sell Price Transaction (SEL PRICE TRANS), Sell Limit (SEL LIMIT) and Sell Limit Transaction (SEL LIMIT TRANS) files apply only to primary and derivative primary contract orders. The TRADE PRICE, TRADE PRICE TRANS, TRADE LIMIT, and TRADE LIMIT TRANS files only apply to secondary and derivative secondary contract orders.

  The file management and update tasks handled by Process 1 process generic data file information received from stakeholders in the contract application program and are received from other related INVENTCO stakeholders, in particular VIRPRO and AXSCO. Process general data files and other order processing information, process trading support information received directly from contract application program stakeholders, and order primary and derivative primary products for potential opponents It processes the “competitive bid” parameter and order establishment constraints, processes the secondary and derivative secondary order establishment constraints of the current contract presenter, and processes various information from those outside of INVENTCO.

  Current and future stakeholders are required to provide the identifiers and other information specified in their applicable contract application programs and maintain the integrity of this information continuously. Each stakeholder's information includes applicable name, address, contract number and inquiry, desired device access medium, consideration / transferr's account details, and, if applicable, another INVENTCO interest. Includes the required schedule of fees and charges that may be paid by the parties involved. This information is held in the management file (ADMIN) of the data file, and the updated information is received by the management transaction file (ADMIN TRANS).

  VIRPRO provides various types of general-purpose data file information to applicable contract application programs, including (each) identification data relating to the applicant of the contract application program and permitted device access media. Types of details and consideration / rights units available for each application. Further, this information is held in a management data file, and updated information is received via the management transaction file.

  VIRPRO also provides various types of general-purpose data file information to applicable contract application programs, including those that are between the various parts of INVENTCO and outside the various parts of INVENTCO and INVENTCO. And various types of statistical information, including information on all data transmitted to and received from and data traffic volume, data file storage location information, and the like. This information is continuously collected by AXSCO and held in a history data file.

  Trading support information received directly from stakeholders in the contract application program consists of stakeholder information of general nature and specific information from individual stakeholders (detailed in Appendix B). )

  Stakeholder relationship information of a general nature is composed of “transaction communication parameters” and “auto / manual agreement and no agreement flag”. Transaction communication parameters are parameters set by all (registered) contract application program stakeholders that define the boundaries where all of their communications within INVENTCO want to be within its scope for safety. . The automatic / manual agreement and no agreement flags are set by all (registered) stakeholder interests as required, and their requirements regarding relationships with other stakeholder interests. Is a “flag”. This information is held in the agreement list data file, and the updated information is received by the agreement list transaction file.

  Specific information from individual stakeholders varies according to the relevant stakeholder category.

  The applicant himself provides, among other things, information in the product data file (updated transactions can be received from the product transaction file) and future information in the management data file (updated transactions can be received from the management transaction file). . The information in the product data file includes details of the specific product applicant's offer for sale / exchange / transfer. The information in the management data file includes the price evaluation and formation process that underlies the application, the “value date” of the consideration / rights that underlie the application, and the categories of other interested parties that are allowed to participate in the application. , Restrictions on the participation of other interested parties; specific rules for the promise of opposing guarantors by potential opposing parties, contract application program interested parties applying for “lending”, “collateral” and “net profit” "Effectiveness to use the characteristics, in other words, conditions and constraints (implemented in various post-order management rules), as well as details of the consideration / rights transferor for the application and account balance And related safety information.

  Product sponsors provide complete details of the products they offer, and product orderers and potential opponents want to do business with each other (in bulk) or want to have exclusive relationships Indicates a person. Potential opponents provide (exclusively) a lot of specific information, including details of the rules of the applicant himself, the product sponsor, and the opponent guarantor selected to function, Data that records the limits of any loans applied to the ordering party, and the general and above-mentioned loan limits (applicable to individual ordering parties and / or a limited class of ordering parties) and Specific conditions and constraints, and parameters used by potential opponents when they want to determine the “pricing” of the consideration for an order. The opponent guarantor provides details of any potential opponents who have agreed to the guarantee and the nature of the guarantee. Enforcers are interested in the application and are related to each other (for example, which opponent guarantor is responsible for which opponent, which potential opponents provide which products Etc.), details of the specific regulations identified for the scheme, and parameters that define the taxation of transactions associated with all types of orders. The consideration / rights transferer provides services for the renewal of account balances and renewal of account balances that have been “opened”. All of the above information is held in a management data file, and updated information is received using a management transaction file.

  Potential Opponent Participant Primary Product Order “Compensation Bid” When dealing with parameters and order formation constraints, potential Product Order Opponents are used especially when they want to establish “Competitive Bid” on limited product orders. Define various parameters and define parameters to be used when potential opponents want to determine adjustments to the “basic price” pricing of product orders by the particular ordering parties involved (this information is the selling price) The information kept and updated in the data file will be received by the sale price transaction file), to the potential parties to the individual contracts and the orders of the product order parties determined by the potential opponents If so, define the product constraints that need to be met, and be satisfied if the potential counterparty becomes the counterparty to the order of the determined product orderer Define the product portfolio constraints that may be required (the last two categories of information above are retained in the sale limit and acquisition limit data files, and updated information is received using the sale limit transaction file. (See Appendix B for more details).

  When dealing with the restrictions on the establishment of secondary orders of current contract application parties, the application parties must include, in particular, the order identification number of the contract that the related party wants to sell as a stakeholder of the contract, and each contract. On the other hand, it is required to identify price valuations and other parameters that need to be met before a contractual status "sale" is implemented. This information is held in the selling price data file, and the updated information is received using the selling price transaction file.

  When dealing with the “competitive bid” parameter of a derivative primary order of a potential opponent and the order fulfillment constraint, the potential product order opponent provides essentially the same information as above for the primary product order. It is necessary to. However, further information is needed that is directly applicable to the relevant type of derivative primary transaction (eg, the option to establish a primary product order at a later date).

  When dealing with the constraints on the establishment of derivative secondary orders of current contract application parties, it is necessary for the application parties to provide essentially the same information as described above for secondary product orders. However, further information is needed that is directly applicable to the relevant type of derivative secondary transaction (e.g., the option to sell the status of the primary product order at a later date).

  When dealing with various information from someone outside of INVENTCO, this information can be any type of information and could potentially be used by any part of INVENTCO. This information is held in the management data file along with the updated information received via the management transaction file.

Process 2
Process 2 handles the receipt and processing of multiple types of “primary” crisis management contract transactions (this term is defined in Appendix D) (described in detail in Appendix B). The various sub-processes of Process 2 handle the receipt and processing of all possible forms of transactions, including product order processing, price quote requests, and cancellation of current product orders.

  The primary “product order” consists of a central “primary” crisis management contract transaction type (FIG. 19 is a schematic flowchart, and the description includes a flowchart and detailed description of the transaction type processing). Are listed).

  The primary product order consists of key items of the following information: order related party identification information, contract application program application and product identification information, “other stakeholder continuity” information, (directly as a rights relationship or mathematical function) Incorporate the parameters of the above-mentioned function when the one-dimensional mathematical function is used for order specification (the input of the desired product specific format of the order party) (the parameters of the function are the condition “X” and the condition “alpha ( X) "and conditions" Beta (X) "and conditions" Gamma (X) ", contract face value and rights" face value type "," currency (if applicable) "and" local currency (if applicable) " ”Whether the ordering party is interested in lending against undetermined contractual value guaranteed by a potential counterparty, and whether the ordering party uses the potential net income and debt of the application program. Whether the ordering party is willing to pay for a given product, the price range of the price, the magnitude of the needs of various other ordering parties, and the associated “payment” May include the consideration / rights transferor account you receive). Upon receipt, all of the above information is written to a primary order new (PORD NEW) file and then processed from there.

  Processing of the primary product order includes sub-process-order authorization, order establishment, and confirmation of the established order. For the most typical type of order, referred to as a “normal automatic” primary product order, the sub-process works as follows.

  The primary product order authorization sub-process verifies that all orders contain data appropriate for the product for which each order is sought, and that each ordering party has been correctly identified and qualified (this sub-process Mainly uses primary product (PPRODUCT) data files).

  The primary product order establishment sub-process arranges counter parties who may be best suited to transactions of the order parties in accordance with the “settlement rules” embodied in the application program identified by the applicant. The sub-process performs such placement using three component sub-processes: a short list of potential opponents, an “evaluation” calculation of each potential opponent, and opponent selection.

  The “Short List of Potential Opponents” sub-process component intends to provide the product requested by the Order Participant when it receives the consideration it considers appropriate from the Order Participant. Establish a list of potential opponents (if this is present) (this sub-process is primarily based on the PDEAL LIST data file).

  The individual potential opponent valuation calculation sub-process component calculates a “bid” that each is ready to execute on a product order for a product order participant (or a portion thereof) and identifies the potential opponent To add to the short list of potential opponents, the above valuation parameters previously identified by each listed in the short list of potential opponents are used (this sub-process is primarily the primary sale price (PSEL)). PRICE) based on data files).

  The “Selection Participant Selection” sub-process component takes into account all the establishment constraints specified in advance by the stakeholders of all applicable application programs, and the “Establishment Rules” specified by the applicant himself / herself embodied in the application program. In accordance with the above, from the above “short list of potential opponents”, the opponents who are likely to be best in the transaction of the ordering parties are extracted. If the above selection is made and the price pricing is within the tolerance limits specified by the ordering party, and there is no request for manual authorization intervention by the relevant interested parties, then it is assumed that a successful order exists ( This sub-process is primarily based on the PSEL LIMIT file).

  The Confirm Confirmation sub-process automatically and practically guarantees the positive arrangements of all affected stakeholders for the contract, which includes the contract consideration (and if Confirmation of the ability to pay instantly (or some other applicable fee is guaranteed) (or guaranteed by the counterparty or the guarantor of the ordering party). The automatic authorization of the contract is made by electronically transferring the assets recorded in the order party's applicable consideration / rights transferor's account to the applicable counterparty (consideration / right “payment” process). See Appendix H for an explanation of. Next, the establishment restriction of the opponents held in the primary sale limit file is automatically updated.

  At the end of the processing stage, unsuccessful order transactions are written to the PORDER QUEUE file for the next establishment attempt, and the established and confirmed order transactions have an interest in the contract application program. (This process is mainly based on the management data file) and is written to the primary order confirmation (PORD CONF) file for the next “office work” process and the interested parties in the contract application program are rejected. The order is notified (this process is mainly based on the administrative data file) and the record is written to the primary order rejection (PORD REJ) file for the next “office work” process. A copy of all processing output is written to the history file.

Process 3
Process 3 deals with the receipt and processing of “secondary” crisis management contract transactions (this term is defined in Appendix D). Like the “primary” crisis management contract, the “secondary” crisis management contract is of multiple types (described in detail in Appendix B), and the various sub-processes of process 3 include product order processing and product Handles the receipt and processing of all possible types of such transactions, including price markings and cancellation of current product orders.

  The “secondary product order” consists of a central “secondary” crisis management contract transaction type (FIG. 20 is a schematic flowchart of processing of this transaction type).

  The key items of information included in the “secondary” product order are potential acquisition party identification information, a preset order identification number required for the primary contract, and the potential acquisition party is the application party. Whether the acquisition party is interested in using the guaranteed net profit and debt of the application program, The scope of the acquisition “price” you are willing to pay for the identified contract, the magnitude of the needs of other potential acquisition parties, and the account of the consideration / transferr who wants to spend / receive the payment. May be included. The information is written to a secondary order new (SORD NEW) file upon receipt and then processed from there.

  Three sub-processes—order authorization, order confirmation, and confirmation of the established order are included in the processing of the secondary product order. For the most typical type of order, referred to as a “normal automatic” secondary product order, the sub-process works as follows.

  The secondary product order authorization sub-process verifies that all orders contain data appropriate for the product for which each order is sought, and that each potential acquisition party has been correctly identified and qualified (this sub The process mainly uses secondary product (SPRODUCT) data files).

  The secondary product order confirmation sub-process places a record of the required contract and, based on the contents of the record, “sells” to potential acquisition parties of the specified stakeholder status in the contract. The acquisition “price” range that is ready to “pay” for the current stakeholder status designated by the potential acquisition stakeholder is specified in advance by the applicable contract stakeholder. It is determined whether the value is equal to or greater than the “allowable sale price”. If it turns out that a contract “sale” is feasible and none of the interested parties require intervention by manual authorization, it is considered that “successful” has been obtained.

  The secondary product confirmation order sub-process automatically and practically guarantees the positive arrangements of all interested parties affected by the contractual status “sale”, which includes contract acquisition parties The ability to immediately pay the required “sale price” consideration (and possibly other applicable fees) (or guarantee the loan of the current stakeholder or the guarantor of the acquirer) Confirmation is included. The automatic sale of the “sale” is made by electronically transferring the assets recorded in the applicable consideration / transfer rights account of the acquiring party to the current contracting party.

  At the end of the processing phase, the unsuccessful order transaction is written to the secondary order wait (SORDER QUEUE) file for the next establishment trial, and the established and confirmed order transaction is the interest of the contract application program. (This process is mainly based on the management data file), and the required records are written to the secondary order confirmation (SORD CONF) file as needed for subsequent “office work” processing and rejected. The order transaction is notified to interested parties in the contract application program (this process is mainly based on the management data file), and the required records are secondary order rejection (SORD REJ) for further “office work” processing. Written to a file. A copy of all processing output is written to the history file.

Process 4
Process 4 handles the receipt and processing of “derivative primary” crisis management contract transactions (this term is defined in Schedule D). Like the “primary” crisis management contract, the “derivative primary” crisis management contract is of multiple types (described in detail in Appendix B). It handles the various sub-processes of process 4, product order processing, product price indication, and receipt and processing of all possible forms of transactions including cancellation of current product orders.

  “Product option order” is an example of a “derivative primary” crisis management contract transaction type (FIG. 21 is a schematic flowchart of the processing of this transaction type).

  “Derivative Primary” product option orders are key items of the following information (details are shown in Appendix B): Order Participant Identification Information, Contract Application Program Application and Product Identification Information, “Other “Stakeholder continuity” information, the desired product specific form of the order party (directly entered as a rights relationship or mathematical function), and the parameters of the above function when a one-dimensional mathematical function is used to specify the order. Incorporate (the parameters of the above function are condition "X", condition "alpha (X)", condition "beta (X)" and condition "gamma (X-1)", contract consideration and rights "face value type", " "Currency (if applicable)" and "Local currency (if applicable)", whether the ordering party is interested in lending against undetermined contract option value guaranteed by a potential counterparty, order relations Person Whether you are interested in taking advantage of the potential net gains and debts of the application program, the range of consideration "price" your ordering party is willing to pay for the product options you have defined, and various other May include the magnitude of the needs of the ordering party and the consideration / rights transferor account to spend / receive the associated “payment”). Upon receipt, all of the above information is written to a derivative primary order new (DPORD NEW) file and then processed from there.

  Processing of the derivative primary product order includes sub-process—order authorization, order confirmation, and confirmation of the completed order. In the case of an order of the most typical type, referred to as a “normal automatic” derivative primary product option order (see Appendix 5 for details), the sub-process functions as follows.

  The primary product option order approval sub-process verifies that all orders contain the appropriate data for the product option for which each order is sought, and that each ordering party has been correctly identified and qualified (this The sub-process mainly uses a derivative primary product (DPPRODUCT) data file).

  The primary product option order creation sub-process arranges counter parties who may be best suited to the transactions of the order parties according to the “settlement rules” embodied in the application program identified by the applicant. The above sub-processes make such an arrangement using three component sub-processes: a short list of potential option opponents, an “evaluation” calculation of each potential option opponent, and option opponent selection. Execute.

  The “Short List of Potential Option Opponents” sub-process component intends to provide the product requested by the Order Participant when receiving option consideration from the Order Participant that it considers appropriate (Potential Options Establish a list of potential option opponents (if there are opponents) (this sub-process is primarily based on the Derived Primary Agreement List (DPDEAL LIST) data file).

  The “Evaluation Calculation for Individual Potential Option Participants” sub-process component calculates a “bid” that each is ready to execute on a product option order for a product option order party (or part thereof) To add a potential option counterparty to the short list file of potential option counterparties, use the evaluation parameters previously identified by each listed in the short list of potential option counterparties (this sub-process Are based primarily on derivative primary sale price (DPSEL PRICE) data files).

  The “Select Option Counterparties” sub-process component takes into account all the establishment constraints specified in advance by the stakeholders of all applicable application programs, and the “Establishment Rules” specified by the applicant himself / herself embodied in the application program. ”Is extracted from the above“ short list of potential option counterparties ”which may be best for the order party's transaction. If the above selection is made and the price pricing is within the tolerance limits specified by the ordering party, and there is no request for manual authorization intervention by the relevant interested parties, then it is assumed that a successful order exists ( This sub-process is mainly based on a derivative primary sale limit (DPSEL LIMIT) file).

  The confirmation of fulfillment sub-process automatically and practically guarantees the positive arrangements of all affected stakeholders for the option contract, which includes the option product consideration requested by the product option order party. Includes confirmation of the ability to pay immediately (and possibly other applicable fees) (or guarantee of a counterparty loan or an order party guarantor loan). The automatic authorization of the contract is made by electronically transferring the assets recorded in the account / appropriate transferee's account of the ordering party to the applicable counterparty (this process is described in Appendix H). checking). Next, an automatic update of the establishment constraints of the option opponents held in the derivative primary sale limit file is performed.

  At the end of the processing stage, the unsuccessful order transaction is written to a derivative primary order waiting (DPORD QUEUE) file for the next establishment trial, and the confirmed and confirmed option order transaction is stored in the contract application program. Stakeholder (this process is primarily based on administrative data files), a derivative primary master criteria file, and a derivative primary order confirmation (DPORD CONF) file for the next "office work" process And the stakeholder of the contract application program is notified of the rejected order (this process is mainly based on the administrative data file) and the record is a derivative primary order for the next “office work” processing. Written to a rejection (DPORD REJ) file. A copy of all processing output is written to the history file.

  If / when the option holder wants to implement the option on a pre-established contract, the option holder retrieves the record of the contract from the derivative primary master, performs the necessary additional consideration payment, and The option is implemented by notifying the contract application program that writes a new record to the primary order confirmation file for reasons. As described above, the appropriate history and other files are updated during this process.

Process 5
Process 5 deals with the receipt and processing of “derivative secondary” crisis management contract transactions (this term is defined in Appendix D). Like the “secondary” crisis management contract, the “derivative secondary” crisis management contract is of multiple types (described in detail in Appendix B), and the various sub-processes of process 5 are product order processing and Handles the receipt and processing of all possible types of the above transactions, including product price indications and cancellation of current product orders.

  “Product option order” is an example of a “derivative secondary” crisis management contract transaction type (FIG. 22 is a schematic flowchart of processing for this transaction type).

  The key elements of the information incorporated in the “derivative secondary” product option order are the potential acquisition party identification information, the preset order identification number required for the primary contract (the option is this order identification number) Whether the potential acquirer is interested in the loan guaranteed by the application party for the pending contract acquisition, whether the acquirer is likely to have a net profit of the application program. Whether you are interested in using other features, the range of acquisition “price” you are willing to pay for the contract options that the acquisition party has identified, the magnitude of the needs of other potential acquisition parties, and May include the account of the consideration / rights transferor who wishes to spend / receive the “payment”. The information is written to a derivative secondary order new (DSORD NEW) file upon receipt and then processed from there.

  The sub-processes involved in processing a derivative secondary product option order are essentially a combination of the above processes described in Secondary Product Order (Process 3) and Derivative Primary Product Option Order (Process 4). At the end of the closing process, the completed orders are written to the derivative secondary master reference file and the derivative secondary order confirmation file for the next paperwork.

  If / when the option holder wants to implement the option on a pre-established contract, the option holder retrieves the record of the contract from the derivative secondary master file, performs any additional consideration payments required, and The option is implemented by notifying the contract application program that writes a new record in the secondary order confirmation file for business reasons. As described above, the appropriate history and other files are updated during this process.

Process 6
Process 6 deals with “confirmed / confirmed” primary, secondary, derivative primary and derivative secondary crisis management contract transactions and the “office” management of the transactions handled by process 7-9. This process consists of a number of sub-processes that collectively access a number of data files: a primary crisis management contract paperwork, a secondary crisis management contract paperwork, a derivative primary crisis management contract paperwork, The business process of the derivative secondary crisis management contract, the transaction process of “Process 7”, the transaction process of “Process 8”, and the transaction process of “Process 9” are incorporated (FIG. 23).

  Numerous subprocesses for confirmation / fulfilled primary crisis management contracts, receiving subprocess of “actual product value of contract expired” on previous operation date, “daily donation payment account (PAYACC) management” Subprocess, Contract expiration management subprocess, Confirmed contract processing subprocess, Information creation and distribution subprocess, Information extraction subprocess from primary order, Contract evaluation subprocess, Contract collateral payment subprocess, Equipment access and usage fee A number of sub-processes including decision and payment sub-process, bilateral net profit sub-process, diversified debt net profit sub-process, bi-directional net profit sub-process, multi-purpose net profit sub-process, and "one-day payment account management" sub-process Involved.

  The detailed reception of “actual product situation value of contract expired” on the previous operation date (the previous operation date) will be described. This sub-process is shown in a flow chart in FIG. 24 and relates to an applicable contract application program that receives the details of the “actual product value of a contract that has expired” from a product sponsor outside the associated INVENTCO. The maturity product value file in the main data file is updated with this information. The management, history, and information files that are auxiliary data files are similarly updated with applicable information.

  Next, the payment account management of “daily sink” will be described. This sub-process is shown in the flow chart of FIG. 25 and receives the “actual account” contribution balance of the consideration / right from the participating consideration / rights transferer (outside of INVENTCO) (see process 7 for details) ) The negative payment account (PAYACC SHADOW) and final payment account (PAYACC FINAL) data files are updated with the above information. The management, history and information auxiliary data files are similarly updated with applicable information.

  Explain contract maturity management. This sub-process is shown in the flowchart of FIG. 26 and is applicable to determine and perform primary and related rights transfers between applicable contract application program stakeholders and other applicable INVENTCO stakeholders. Here, the transfer is mainly reflected in the entry in the shadow payment account data file. The contract application program includes data files for INTREG, product value at maturity (MAT PROD VALUES), collateral (COLLAT), loan management (CREDIT MGMT), bilateral net income (BILAT OBLIG NET), and multilateral debt net income (MULTILAT OBLIG NET). The transfer is judged and executed by using the product / contract information held in the above. The data files are updated appropriately in the process as well as the auxiliary data files management, history, tax / deduction (TAX / SUB), shadow payment accounts and information files.

  The confirmed contract processing will be described. This sub-process is shown in a flowchart in FIG. 27 and operates continuously during each operation day. Details of the new established / confirmed contract are read from the primary order confirmation file and time stamped, one record related to the contract order party and the other record related to the contract counter party Are written in the INTREG file as two records. Information, management and history auxiliary data files are updated appropriately during this process.

  Information creation and distribution will be described. This sub-process is shown in a flowchart in FIG. 28 and operates continuously based on the information data file (after the defined operation date). As described above, the information file is continuously updated as contract application programs and other INVENTCO events occur, including the associated AXSCO message information originally written to the history file. All relevant INVENTCO stakeholders have access to a pre-authorized part of the information.

  Information extraction from the primary order will be described. This sub-process is shown in a flowchart in FIG. 29 and is executed after the end of the defined operation date. In essence, the sub-process includes a single task that processes the historical data file to obtain information related to the information data file. One of the most important items that can be obtained from the history file is secret information about all of the potential bidder's consideration bid parameters of the previous day, in particular a data item called “assessed occurrence probability”. This information provides “market” information for the next contract evaluation sub-process.

  Describe contract evaluation. This sub-process, flowcharted in FIG. 30, is based primarily on the “market” information previously written to the information file. Relevant information from this file is “applied” to all outstanding contracts held in the INTREG file, thereby updating the updated “future product value (FPV)” and “expectation” of all contracts. Information on "value" and "sales" value, and also a re-evaluation of "expected value" and "sales" value of all future rights. The reevaluation number is held in the INTREG file along with applicable information that is also written to the information file and history file.

  Explain contract collateral payment. This sub-process, flowcharted in FIG. 31, is mainly based on the data file INTREG. Following the contract evaluation process, this collateral process reads the associated file INTREG and the calculated portion of the present value of expected future consideration is (among other things) the expected future value associated with each of the contracts. Depending on the pre-calculated “current value” of the rights, debited or credited to the applicable collateral trustees and also to the payment account files behind the applicable product ordering parties and / or opponents is there.

  In general, when the “current value” calculated immediately before the expected future right associated with each of the contracts indicates a negative contract value, and this negative value exceeds the previous contract evaluation number If applicable, the trust account of the applicable person is credited with the difference in funds, and the account of the person's own consideration / transferr is credited correspondingly. If the above negative value does not exceed the previous contract valuation number, the trust account of the applicable person will be debited with the difference in funds, and the account of the person's own consideration / transferr will be credited accordingly. Filled in. On the other hand, if the “current value” calculated immediately before the expected future right associated with each of the contracts indicates a positive contract value, the required collateral payment adjustment is in the trust account of the applicable person. The only adjustment is that all funds (if any) are transferred to their own consideration / transfer rights account. In any of the above cases, all affected records are written to the collateral data file and some of this information is written to the history data file and the information data file.

  Unit access and usage fee units and payment will be described. This sub-process, flowcharted in FIG. 32, deals with device access and usage fee determination and payment (as distinct from contract maturity fee payments). This function is mainly based on data file management and history. Fee payment parameters are maintained in the data file management. The above parameters apply to new records of the day that have already been written to the history file. The charge debits and credits thus determined are written to the implicit payment account file along with the summary information written to the information and history file.

  Explain the bilateral net income. This process, flow charted in FIG. 33, is continuously adjusted based on the current considerations, rights and other payments / receipts required (the interests of other participating contract application programs and INVENTCO Effectively maintains an up-to-date matrix of the present value of expected future rights (and other) debt between participating order parties and opponents. If necessary, the function updates the matrix in two steps. First, it is updated using the latest contract reevaluation number stored in the INTREG file. Second, it is updated with the daily payment / receipt amount stored in the shadow payment account file. Transfer between the consideration / rights transferor and the applicable person is permitted by any / all of the two-way current value adjusted (according to the parameters specified by the applicant himself to do so) Determined based on whether the limit is exceeded. The above is written to the shadow payment account file, and the data files BILAT OBLIG NET, INTREG, history, and information are subsequently updated.

  Explain diversified net debt. This process, which is flow charted in FIG. 34, shows that a specific “clearing / management” person is effectively intervened among all two-way opponents, so that the net gained debt is a specific “ It is essentially the same as the two-way net profit function, except that it is only between the “Bill Exchange / Trustee” person and each participant.

  Explain the two-way net income. This process, shown in FIG. 34, is separate from the bi-directional and multilateral debt net profit sub-process. The two-way payment net profit sub-process works by creating a payment / receipt matrix with two-way net profit based on the records stored in the implicit payment account data file. Only one number of payments / receipts with net gains is written back to the shadow payment account file, and the data file BILAT PYMTS NET, management, history, and information are then updated.

  Explain diversified net income. Similar to the dual business net profit, this sub-process, which is flowcharted in FIG. 36, is separate from the dual business and multilateral net profit sub-process. This diversified net payments subprocess is based on records stored in the implicit payments account data file for payments / receipts that have been bilaterally netted with an applicable “Bill Exchange / Trustee”. It works by creating a matrix. Only one number of payments / receipts with net gains (with the “Bill Exchange / Trustee” person) is again written to the shadow payments account file, and the data file MULTILAT PYMTS NET Management, history, and information are then updated.

  The “One-day sink” payment account (PAYACC) management will be described. This sub-process, flowcharted in FIG. 37, includes a three stage process. The first process is the preparation of a transferor “balance account” transaction between consideration / rights. The second process transfers the final contents of the shadow payment account data file to the PAYACC FINAL data file. The third process is electronic transmission of the contents of the final payment account file to the applicable consideration / rights transferor (outside of INVENTCO). The management, history and information auxiliary data files are then updated.

Process 7
Process 7 is a debt transfer that is independent of the contract application program between applicable INVENTCO stakeholders, ie, “assets” registered by INVENTCO, typically (recorded as an INTREG record in the contract application program Handles the contracts established / confirmed and the transfer of ownership of the consideration / rights transferor's assets (recorded as payment account records). Both of the above items are valuable to their owners. This process allows the owner of the item to transfer or lend some of its possession to others at his / her own will by initiating an appropriate transaction, such as an NCAROT transaction. This process accesses only a relatively small number of data files (see FIG. 38). When an NCAROT transaction is received, the main data file, the shadow payment account file and the INTREG file, are updated appropriately. Next, the history file, management file, and information file, which are auxiliary data files, are updated.

Process 8
Process 8 (shown in the flowchart in FIG. 39) is a contract application program (and other INVENTCO) stakeholder specific device to help determine the best way to interface with at least one aspect of INVENTCO. Handle shared access to. For those interested in contract application programs that are most likely to make use of this process, a group of such expert devices is referred to as a “decision support device”. The purpose of the device is to guide the user's stakeholders on how to react / respond to a continuously changing environment within the contract application program they handle. Different clusters of devices are applied to stakeholders in different contract application programs. The apparatus includes a hierarchical structure of potentially any number of value added components.

  An example of such a device that is useful to primary product ordering parties is an order that has been previously identified by the ordering party, but has not yet been fulfilled, and is a potential new product order. It is a device that helps you decide the order to be presented. This device is based on two things: “utility optimization” which certifies the best configuration of pending orders (and therefore the current open order to be canceled and the new order to be submitted). optimization) "mechanism. First, this device (collectively referred to as the “buyer's target portfolio”) “real business exposure” for each product of the ordering party, and the portfolio of contracts of the “settled” but unconfirmed ordering party. Between the actual and desired value weighted sum of a set of attributes associated with a single or multiple product across a presented but unfulfilled order and a potential unsubmitted order There is an objective function that tries to minimize the difference among the above attributes, in particular the “expected value” of the target portfolio, the “standard deviation” of the target portfolio, the “increased cash flow” attribute of the target portfolio, and the target portfolio The “maximum absolute loss” attribute of the target portfolio; the “expected loss” attribute of the target portfolio; the “implicit minimum profit on investment” of the target portfolio; In particular, there is a set of constraints that specify the required "minimum value" of each objective function attribute and the required minimum product share of the ordering party's entire product portfolio. The mathematical form of “optimization” can be any of a number of other forms.

  An optimization mechanism similar to the optimization mechanism described above can help potential opponents in defining evaluation parameters to apply to product orders that they come from.

  Efficiently, a device of the above type is rented by a VIRPRO authorized party independent of INVENTCO and / or obtained by a VIRPRO authorized party whether or not it is an INVENTOC stakeholder. In the applicable contract application program as a software “library”. Requests from interested parties in the contract application program (and other INVENTCO) to use the software in the library are received via a record of the SSA transaction file. The above request results in the appropriate record in the file SSA being accessed and used for use via an electronic link to AXSCO and the INVENTCO authorized by the applicable person. Appropriate records of the use of SSA file records are written to the history data file, management data file, and information data file.

Process 9
Process 9 (flow charted in FIG. 40) deals with shared access to a range of value-added services provided by the contract application program (and other INVENTCO) stakeholders, INVENTCO. Such services include accounting, reconciliation and information services, many types of financial services, and data processing and telecommunications services. Efficiently, the software related to the above services may be lent out by a VIRPRO authorized party unrelated to INVENTCO and / or by an authorized party of VIRPRO whether or not it is an INVENTCO interested party. It is kept as a software “library” within the applicable contract application (even if acquired). Requests from interested parties in the contract application program (and other INVENTCO) to use the software in the library are received via a record of the VAS transaction file. The above request provides an appropriate record in the VAS transaction file that is accessed and used for use via an electronic link between AXSCO and the INVENTCO authorized by the applicable person. Appropriate records of VAS file record usage are written to the history data file, management data file, and information data file.

[Appendix D]
Crisis Management Contracts Crisis management contracts are not necessarily required, but can be traded / exchanged / transferred using INVENTCO equipment, and then one of the contractual obligations to be processed and settled. A term used to refer to a type. The crisis management contract includes a “primary” crisis management contract, a “secondary” crisis management contract, a “derivative primary” crisis management contract, and a “derivative secondary” crisis management contract.

  A “primary” crisis management contract is essentially “simple” and may be “composite” (a “simple” contract is a derivative of a “composite” contract).

  A “simple” primary crisis management contract is a tradeable or non-tradable contract that transfers a debt to a certain person, depending on the value of a given phenomenon, to determine the right to others at a given time in the future, The person is warranted by the other (or accepts a promise that is warranted by the other).

  A “composite” primary crisis management contract is available for sale or transfer of debt to one or both of the two parties, depending on the value of a given phenomenon, to establish a right to pay / receive each other at a given time in the future A non-tradable contract, where one party is (usually) guaranteed by the other party (or accepts a promise guaranteed by the other party). “Composite” contracts may be either “basic” or “advanced” in nature, and “composite basic” contracts are the third trustees of the ordering party and / or the order-counting party established during the contract period. Or a contract that does not include “collateral payment” to the liquidator, and the “multi-level” contract is a “collateral” to the third trustee or liquidator of the ordering party and / or the ordering party established during the contract period. The contract includes “payment”.

  A “secondary” crisis management contract is a “primary” crisis management contract that exists for which a “crisis counter relationship” stakeholder for an existing contract has been applied (individually or as a portfolio).

  “Derivative primary” risk management contracts are option contracts, futures contracts, futures contracts, futures contracts, swaps, or similar financial instruments based on primary risk management contracts that have not yet been established. is there.

  “Derivative secondary” crisis management contracts are option contracts, futures contracts, futures contracts, futures contracts, swaps, or similar financial instruments based on pre-existing primary risk management contracts. This “derivative secondary” crisis management contract (which may have been traded since it was first set up) is identified as a secondary crisis management contract that has not yet been established, and a 2 Includes means based on deliberate third sale / exchange / transfer of next crisis management contract.

[Appendix E]
Sample “temporal procedure” for ordering / contracting products Example I: For a microprocessor

[Appendix F]
Sample “temporal procedure” for ordering / contracting products Example II: Remote communication capability

[Appendix G]
Sample “Time Procedure” for Product Order / Contract Example III: Stock Index

[Appendix H]
Process 2 variables and data files This appendix lists the file names and descriptions of the files.

Order data field
OID: Unique identifier assigned by the contract application program to all new orders submitted
BID: Ordering party identifier
BREF: Ordering party's self-reference for orders
PID: Order field that specifies the requested product
PMAT ・ ・ ・ Product expiration date
PC / ED: Product consideration / right unit
PCUR ・ ・ ・ Currency unit of product
PNCUR: Domestic currency unit of the product
PPARAM ・ ・ ・ Product specific parameters (Example: Minimum value (PMIN), Maximum value (PMAX), Step size (PSTEP))
MAXCONSID: Maximum consideration paid by the ordering party for the contract
PAYFUNC ... Payment function type associated with at least one index variable
PAYPARAM ・ ・ ・ Parameters related to PAYFUNC
ACC CONSID ・ ・ ・ Account of the ordering party for which consideration is paid. The implicit account is rights / consideration, currency, and local currency.
ACC ENTITL ・ ・ ・ Account of the ordering party to whom the contract right is paid. The implicit account is rights / consideration, currency, and local currency.
RET LIM: Order hold period limit that sets the expiration date for orders that have not been fulfilled
OPRICE ... Price calculated and selected for the order (this value is the final price)
SPRICE ・ ・ ・ Identifiers of the parties involved with the order
PAY TRAN: Payment transaction number
DCID: Limited environment identifier
OANON ・ ・ ・ Anonymous flag set by the ordering party when you want to avoid manual authorization requests from other interested parties
OMANUAL: Manual authorization request flag. If set, the ordering party will request manual authorization before the completed order is fully confirmed.
DTID ... Agreement type identifier that encodes various flag combinations such as collateral, bilateral and multilateral net income requirements

An array of short lists of opponents
PRICEFUNC (SID) ・ ・ ・ Evaluation function: Function type and related parameters
ELFUNC (SID) ・ ・ ・ Expected loss determination function: Function type and related parameters
EVFUNC (SID) ・ ・ ・ Expected value determination function: Function type and related parameters
CR (SID): Fee rate used for the current limited environment
DR (SID) ・ ・ ・ Discount rate used in the current limited environment
PRICE (SID) ・ ・ ・ Price calculated by each opponent
EL (SID): Calculated expected loss of the current order by each opponent
AL (SID): Calculated absolute loss of the current order by each opponent
EV (SID): Expected expected value of current order by each opponent
MCC (SID): highest composition in the total portfolio that any contract can have (as expected loss)
MC (SID): highest composition in the total portfolio that the product can have (as expected loss)
ELL1 (SID) ・ ・ ・ Expected order loss limit
ELL2 (SID) ・ ・ ・ Expected loss limit of the product set by the opponent
ELL3 (SID): Expected loss limit for products with equivalent maturity dates set by the opponent
ELL4 (SID) ・ ・ ・ Expected loss limit for products due in the same month set by opponents
ELL5 (SID) ・ ・ ・ Expected loss limit for orders of all products set by opponents
CEL2 (SID) ・ ・ ・ Current cumulative expected loss of products
CEL3 (SID) ・ ・ ・ Current cumulative expected loss of products with equivalent maturity dates
CEL4 (SID) ・ ・ ・ Current cumulative expected loss of products due in the same month
CEL5 (SID) ・ ・ ・ Current cumulative expected loss of orders for all products
ALL1 (SID): Absolute loss limit function for each contract
ALL2 (SID) ・ ・ ・ Product absolute loss limit function set
CAL2 (SID): Accumulated current absolute limit function of the product
EVL1 (SID) ・ ・ ・ Expected limit on each order
CC / EDXCHANG (SID): Counter party price / right unit exchange rate for converting the ACC CONSID (and MAXCONSID) unit of consideration of the order party to the product price unit
C-CXCHANG (SID)-Counter party currency exchange rate that converts the currency of the ACC CONSID (and MAXCONSID) of the party involved to the currency that is the unit of the product
C-NCXCHANG (SID)-Counter party currency exchange rate that converts the local currency of the ACC CONSID (and MAXCONSID) of the ordering party into the local currency in the unit of the product
EC / EDXCHANG (SID): Counter party price / right unit exchange rate that converts the ACC ENTITL unit of consideration of the ordering party into the unit of consideration of the product
E-CXCHANG (SID)-Counter party currency exchange rate for converting the ACC ENTITL currency of the ordering party to the currency in the unit of the product
E-NCXCHANG (SID)-Counter party currency exchange rate that converts the local currency of the ACC ENTITL of the ordering party into the local currency in the unit of the product

Various variables
BPRICE: Best price selected from the PRICE (SID) sequence
SID: Opponent identifier currently selected or considered
INDEX: Index counter required for order price calculation
P1 ・ ・ ・ Value calculated by the evaluation function at the index point
P2: Value calculated by the payment function at the index point

Master file file ... Description / Contents
PORD NEW ・ ・ ・ Details of all new orders submitted by ordering parties (new primary orders)
BID: Ordering party identifier
BREF: Ordering party's self-reference for orders
PID: Order field that specifies the requested product
MAXCONSID: Maximum consideration paid by the ordering party for the contract
PAYFUNC ... Payment function type associated with at least one index variable
PAYPARAM ・ ・ ・ Parameters related to PAYFUNC
ACC CONSID ・ ・ ・ Account of the ordering party for whom the consideration is paid
ACC C / ED: Consideration / rights account
ACC CUR ・ ・ ・ Currency account of ordering party
ACC NCUR ・ ・ ・ Local currency account of the ordering party
ACC ENTITL ・ ・ ・ Account of the ordering party to whom the contract right is paid.
RET LIM: Order hold period limit that sets the expiration date for orders that have not been fulfilled
OANON ・ ・ ・ Anonymous flag set by the ordering party when you want to avoid manual authorization requests from other interested parties
OMANUAL: Manual authorization request flag. If set, the ordering party will request manual authorization before the completed order is fully confirmed.
DTID ... Agreement type identifier that encodes various flag combinations such as collateral, bilateral and multilateral net income requirements
PORD QUEUE ... A master file that holds the details of an order that has already been approved and previously attempted to close. Several fields are added to ORD NEW (order new) (waiting for the first order).
OID: Unique identifier assigned by P-CONTRACT to all new orders submitted
PMAT ・ ・ ・ Product expiration date
C / ED: Product consideration / right unit
PCUR ・ ・ ・ Currency unit of product
PNCUR: Domestic currency unit of the product
PPARAM ・ ・ ・ Product specific parameters (Example: Minimum value (PMIN), Maximum value (PMAX), Step size (PSTEP))
DCID: Limited environment identifier
PORD REJ: All rejected orders remaining in the file. As for the field, another field is added to ORD QUEUE (waiting for order).
ERRCODE: Error code indicating the reason why the order was rejected
OPRICE ... Price calculated and selected for the order. This value is the final price.
SPRICE ・ ・ ・ Identifiers of the parties involved with the order
PAY TRAN: Payment transaction number
PPRODUCT ... This master file holds information (details of definition) about each product known to the device. (Primary product)
PID: Product identifier
PMAT ・ ・ ・ Product expiration date
PC / ED: Product consideration / right unit
PCUR ・ ・ ・ Currency unit of product
PNCUR: Domestic currency unit of the product
PPARAM ・ ・ ・ Product specific parameters (Example: Minimum value (PMIN), Maximum value (PMAX), Step size (PSTEP))
PDEAL LIST-This file holds a list of tutors of the ordering party / product / countering party of the agreements allowed to be generated. Thus, specifying an order party (BID) and a product (PID) provides a list of opponents that are ready to enter into an order party / product combination and agreement.
BID: Ordering party identifier
PID: Product identifier
SID: Counter party identifier
ANON: Identifier for all interested parties requesting anonymous confirmation
MANUAL ・ ・ ・ Identifier of all interested parties requesting manual authorization
PSEL DC ... This file allows the opponent to define a set of potential order parameter sets. (Environment limited to primary sale)
DCID: Limited environment identifier
BID: Ordering party identifier
PAYFUNC ... Payment function type associated with at least one index variable
PAYPARAM ・ ・ ・ Parameters related to PAYFUNC
ACC CONSID ・ ・ ・ Account of the ordering party for whom the consideration is paid
ACC ENTITL ・ ・ ・ Account of the ordering party to whom the contract right is paid
DTID ... Agreement type identifier
PC / ED: Product consideration / right unit
PCUR ・ ・ ・ Currency unit of product
PNCUR: Domestic currency unit of the product
PSEL PRICE: A file containing the evaluation parameters of all opponents, including commission rate, discount rate and exchange rate. (Primary sale price)
SID: Counter party identifier
PID: Product identifier
DCID: Limited environment identifier
PRICEFUNC ・ ・ ・ Evaluation function: Function type and related parameters
CR: Fee rate used for the current ordering party of the current product
DR: Discount rate used for the current ordering party of the current product
CC / EDXCHANG: Counter party price / right unit exchange rate for converting the ACC CONSID (and MAXCONSID) consideration unit of the order party into the product unit
C-CXCHANG: Counter party currency exchange rate that converts the currency of the ACC CONSID (and MAXCONSID) of the party concerned to the currency in the unit of the product
C-NCXCHANG: Counter party currency exchange rate for converting the local currency of the ACC CONSID (and MAXCONSID) of the party concerned to the local currency in the unit of the product
EC / EDXCHANG: Counter party price / right unit exchange rate for converting the ACC ENTITL unit of order related party into the product price unit
E-CXCHANG: Counter party currency exchange rate for converting the ACC ENTITL currency of the ordering party to the unit currency of the product
E-NCXCHANG: Counter party currency exchange rate for converting the ACC ENTITL local currency of the ordering party to the local currency in the unit of the product
PSEL LIMIT-retains the portfolio limits of all opponents and the current accumulated exposure in various mathematical formats allowed by the device. (First sale limit)
SID: Counter party identifier
PID: Product identifier
DATE ・ ・ ・ Maturity date
MCC-the highest composition in the total portfolio that any contract can have (as expected loss)
MC: The highest component of the total portfolio that the product can have (as expected loss)
ELL1 ・ ・ ・ Expected order loss limit
ELL2 ・ ・ ・ Expected loss limit of the product set by the opponent
ELL3 ・ ・ ・ Expected loss limit of the product with equivalent maturity date set by the opponent
ELL4 ・ ・ ・ Expected loss limit for products with maturity set by the opponent
ELL5 ・ ・ ・ Expected loss limit for all product orders set by the opponent
CEL2 ・ ・ ・ Current cumulative expected loss of products
CEL3 ・ ・ ・ Current cumulative expected loss of products with equivalent maturity dates
CEL4 ・ ・ ・ Current cumulative expected loss of products due in the same month
CEL5 ・ ・ ・ Current cumulative expected loss of orders for all products
ALL1 ... Absolute loss limit function for each contract
ALL2 ... Absolute loss limit function set of products
CAL2 ... Accumulated current absolute limit function of the product
EVL1 ・ ・ ・ Expected value limit for each order
PAYACC ... All registered stakeholder payment accounts (including deduction accounts and previous shadow transactions) are stored in this master file. (Payment account)
ID: Stakeholder identifier
NO ... Account (account) number
ACC C / ED: Consideration / rights account
ACC CUR ・ ・ ・ Currency account of ordering party
ACC NCUR ・ ・ ・ Local currency account of the ordering party
BALANCE ・ ・ ・ Funds available
GID: Stakeholder identifier that guarantees the account

1 is a block diagram of a general-purpose “device” that implements the present invention. It is a block diagram showing the hardware platform which supports the apparatus of FIG. It is a figure showing INVENTCO and its main components. FIG. 2 is a block diagram of a subset of parts of an INVENTCO equipment market repository (M-INVENTCO). FIG. 4 is a block diagram of the components of the processing of a “market” shaped subset (called a contract device) that may belong to M-INVENTCO. Timeline that applies to Example I. Timeline that applies to Example II. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. It is a flowchart of contract evaluation and establishment processing. Timeline that applies to Example III. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus. It is a flowchart of the component of a process of a contract apparatus.

Explanation of symbols

10 System 11 Applicant 12 Product sponsor 13 Product ordering party (buyer)
14 Opponents of potential products (sellers)
15 Guarantor of the party concerned 16 Enforcer 17 Price / right transfer party 18 Various parties

Claims (1)

In a computer system (10), a method for electronically exchanging debt between parties:
(a) a data storage means connection stage for connecting data storage means (95, 100, 110) to the data processing unit (93, 97, 104), wherein the data storage means comprises:
i) The first of each party registered in the computer system separately from the second account held in the price / rights transfer party (17) for each party (13, 14, 15, 18) Remember account,
ii) store potential authorized transactions involving at least two parties registered with the computer system;
Where data storage means connection stage;
(b) connecting the data processing unit for processing and exchanging debt between the parties to the communication means (25);
(c) causing the data processing unit to perform the following steps:
i) the process of selecting potential allowed transactions;
ii) the process of selecting the first account of the parties involved in the selected transaction;
iii) obtaining a starting balance, a loan balance and a borrowed balance from the first account stored in the data storage means, and storing the starting balance, the cumulative loan balance and the cumulative borrowed balance of the first account of the party in the memory The process of
iv) the process of ensuring that the cumulative borrowed balance of the party in memory does not exceed the starting balance in the memory plus the cumulative loan balance in the memory;
v) said iv) the process allowing the selected transaction when the process is guaranteed, and
vi) the process of reimbursing the first account of the party for the permitted transaction by lending / borrowing each cumulative balance of the first account of the party stored in the data storage means;
(d) at the end of a predetermined time interval , lending and / or borrowing to each party's second account held by the party transferring the price / right in accordance with the settlement of a plurality of such permitted transactions To the transfer party of each price / right through the communication means (25), and the loan and / or borrowing corresponds to the sum of all transactions of each party over the predetermined time interval. An order stage , which represents a net loan and / or loan amount to be balanced, the order being an irrevocable and time-invariant debt imposed on the transferee of the price / right; and
(e) outputting confirmation data or written documents for the permitted transactions via the communication means (25);
A method consisting of:

Images