WO2001011812A2 - Systemes repartis d'application de regles - Google Patents

Systemes repartis d'application de regles Download PDF

Info

Publication number
WO2001011812A2
WO2001011812A2 PCT/US2000/021586 US0021586W WO0111812A2 WO 2001011812 A2 WO2001011812 A2 WO 2001011812A2 US 0021586 W US0021586 W US 0021586W WO 0111812 A2 WO0111812 A2 WO 0111812A2
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
market
certificate
entity
subject
Prior art date
Application number
PCT/US2000/021586
Other languages
English (en)
Other versions
WO2001011812A3 (fr
Inventor
Frank W. Sudia
Original Assignee
Sudia Frank W
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sudia Frank W filed Critical Sudia Frank W
Priority to AU67609/00A priority Critical patent/AU6760900A/en
Publication of WO2001011812A2 publication Critical patent/WO2001011812A2/fr
Publication of WO2001011812A3 publication Critical patent/WO2001011812A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/047—Payment circuits using payment protocols involving electronic receipts
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/403—Solvency checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2211/00—Indexing scheme relating to details of data-processing equipment not covered by groups G06F3/00 - G06F13/00
    • G06F2211/007—Encryption, En-/decode, En-/decipher, En-/decypher, Scramble, (De-)compress
    • G06F2211/008—Public Key, Asymmetric Key, Asymmetric Encryption

Definitions

  • This invention pertains to secure and efficient systems for controlling access to data and network resources, and providing privacy and authentication of data, in electronic commerce on the Internet.
  • digital certificates can be used to declare and enforce use condition specifications, which can be checked by one or more entities in a multi-stage transaction matching, clearing, and settlement system.
  • the approval of a transaction can be made conditional on securing the consent of a "reference party," which maintains a synchronized parallel account database.
  • the present invention constitutes a system to efficiently create and enforce use conditions for electronic transactions, especially in a global financial market system.
  • FIG 1 shows a general overview of the certificates, participants, and process flow for distributed rule enforcement for an electronic exchange market.
  • the rules and use-conditions are shown being checked by the clearinghouse. However, since all the relevant certificates are generally available to all entities, it is possible to check these conditions at other stages in the process as well. Elements shown as dotted outlines represent additional parties commonly found in exchange trading systems, but which are not essential for understanding or implementing the system.
  • FIG 2 shows the general method of use (preferred embodiment) in which a user transaction (order) message is sent to an exchange and matched, whereupon the exchange creates and signs an execution report message, which is sent to the clearinghouse, usually along with copies of the underlying user transaction messages and user certificates. The clearinghouse then validates the parties and the transaction and sends trade confirmation messages back to the parties.
  • FIG 3 shows the transaction elements seen by the clearinghouse, and some tests that the clearinghouse can perform to enforce trading rules as contemplated by this invention. The specific tests are detailed in the accompanying text.
  • FIG 4 shows additional tests and processing performed by the electronic market server and/or the clearinghouse to (a) enforce any trading restrictions or limitations that may apply to the participant or products traded by the participant, and (b) transfer the product using a specified means, such as an electronic registry system (transfer agent or securities depository) or physical processing agent (fulfillment service).
  • a specified means such as an electronic registry system (transfer agent or securities depository) or physical processing agent (fulfillment service).
  • FIG 5 shows additional tests and processing performed by the electronic market server and/or the clearinghouse to enforce any restrictions relative to the source of funds used to settle the transaction.
  • This may include the requirement of a warranty as to the origin or destination of funds, to be made by a paying bank or institution, relative to funds being received from or paid to that bank or institution.
  • This method can be used with respect to the source and destination of securities, commodities, or other products being traded in an electronic market.
  • product-oriented restrictions would be applied within the messages sent to central depositories, transfer agents, fulfillment services, and the like.
  • FIG 6 is a schematic representation of a general framework for a distributed accounting system
  • FIG 7 is a schematic representation of a multi-signature transaction approval process (prior art);
  • FIG 8 is a schematic representation of a required co-signer transaction approval process (prior art);
  • FIG 9 is a schematic representation of a required confirmer transaction approval process (prior art);
  • FIG 10 is a schematic representation of an exemplary multi-entity oversight architecture (present invention).
  • Participants may utilize a trade matching system to efficiently create contracts that bind themselves and another party to perform some transaction, such as the purchase or sale of a product.
  • the perceived quality of service to the participant will depend in part on the rules and remedies that can be, and are in fact, enforced against counterparties in that system, in case any problems arise.
  • Product means goods, services, real estate, transportation, software, information, intellectual property rights, money, credit, foreign exchange, financial instruments, scrip, allocations or allotments, investment opportunities, admission to events, advice, barter, employment opportunities, charitable subscriptions or projects, computer time, communication network capacity; oil, natural gas, and electric power transmission facilities; any associated or bundled taxes, commissions, and fees; requests for quotations (RFQs) and requests for proposals (RFPs); plus all other things, rights, capabilities, liabilities, opportunities, privileges, etc., tangible or intangible, now or hereafter capable of being listed for trading on an electronic exchange trading system. 2.
  • Exchange means the system of computerized and/or human processes that lists products for sale, purchase, or barter in an auction market, publishes bid/ask prices, receives incoming orders to buy, sell, or exchange, matches those orders with each other to produce enforceable contracts, and reports the trade back to the participants, their brokers, and/or the entities appointed to clear and settle the transaction, and
  • Market system means the entire ensemble of entities, parties, rules, electronic systems, security procedures, and the like needed to accomplish the trading process in a secure and reliable manner, and to maintain and properly care for the assets before and after the trade.
  • Order means a binding offer to buy or sell a product.
  • Trade means a binding contract to buy or sell a product.
  • Trading system means any software, hardware, facilities or personnel relevant to any aspect of the trading process, including portfolio management, pricing analytics, trade entry, order routing and processing, data feeds, etc. that may be utilized by any party in the market system. In common usage his term may, but often does not, encompass the exchange matching system itself.
  • Clearinghouse means a processing service which receives execution reports from one or more exchange market systems, identifies and verifies the parties, records the trade, sends a trade confirmation to the parties or their brokers, and sends instructions to settlement and/or payment services designated by the parties or their brokers telling those services to complete the process of transferring the underlying product.
  • Settlement means delivering, exchanging, or making the appropriate book entries to memorialize the payment for, and transfer of, an underlying product. In the case of financial securities, settlement may involve instructions to the buyer's bank to make payment to the seller, and instructions to a corporate transfer agent, or to a securities depository, such as Depository Trust Company (DTC), to transfer ownership of a specified number of security units.
  • Participant means any individual or entity interacting with an electronic market system, including customers, brokers, market makers, dealers, specialists, banks, insurers, regulatory agencies and personnel, system operators and managers, etc. A participant typically has a primary identification certificate and optionally one or more authorization certificates that define his identity, attributes, and trading rights or administrative rights.
  • This distributed rule enforcement system is concerned with providing means for allowing appropriate trading rules to be enacted and enforced across most or all such systems in a global distributed environment.
  • the underlying economic and regulatory premise of this invention is that there will be many markets, but relatively few clearinghouses. Hence, if the regulators can acquire jurisdiction over the clearing process, then this system will be highly effective, while permitting broad proliferation (scaling) of the number and kinds of markets, without causing increased regulatory problems. Indeed, this system will probably simplify and enhance the regulation of existing exchange markets, thereby increasing the level of protection those markets can provide to investors and traders.
  • the rule enforcement and use condition checking steps proposed herein can be performed at any stage of the trading process, including y the participant prior to initiating an order, by a broker or other intermediary (if any), by a trade routing service, by the exchange market, by the clearinghouse, or by the settlement or depository entities. Such checking and rule enforcement is preferably performed by the clearinghouse, however, since that can provide centralized control over possible abuses by market operators, while allowing nearly unlimited proliferation of market servers, 3. Discussion of Prior Art on Certificates
  • certificate is an electronic message which makes an assertion about one or more useful facts, and has been signed by a trusted third party. 3.1. Types of Certificates
  • certificates of identity which bind the identity of a party with the public key attributed to that party, so the certificate and its public key can be used to authenticate messages electronically signed by that party
  • certificates of authority which are long-lived representations that a given party has been granted the authority or privilege to perform or access some function by a sponsor, which typically is an employer or commercial entity to whose rules the party has subscribed.
  • a party may have multiple authority certificates each granted by different sponsors, whereas it may prefer to have only one or a small number of identity certificates granted by a single certifying authority. It is relatively costly to perform the in-person identification needed to bind an individual to a public key, whereas once that has been done, the action of issuing the secondary authorization certificates can generally be accomplished on-line without personal presence, when other facts are in good order. Also once an individual has built up a collection of different authorities, it would be inconvenient if those all had to be contained in his identity certificate, because each time one permission needs to be revoked or modified, all other permissions would need to be reissued by the subject's other sponsors. Therefore, it is more convenient to "normalize" the permissions into a portfolio of separate authorization certificates each signed and issued by the relevant authorizing sponsor and linked to the identity certificate of the party.
  • identity specification the basic contents of an identity certificate.
  • data elements will typically include: certificate version number, issuer name, issuer serial number, issuer signature algorithm type, subject name, subject public key, validity period, policy reference, issuer digital signature.
  • the policy reference can be any text or object identifier describing or pointing to a policy or set of terms and conditions pertaining to the manner in which the certificate was issued and the responsibility or liability, if any, of the issuer and subject - all digitally signed by the issuer.
  • the issuing certifying authority will generally have a similar certificate from its parent CA, containing similar information and digitally signed by that parent CA.
  • the parent in turn may have another parent, or its certificate may have been issued by a Root CA, i.e., on that has no certificate, but which has made its public key widely available through physical delivery in an uncertified form.
  • the general framework for issuance of identity certificates by CAs is well defined in the prior art.
  • the set of attributes or extensions that state the authorizations and restrictions of a given party are referred to as an "authority specification.”
  • this authority specification may be included in the same certificate as the party's identity specification, but more commonly, for ease of issuance and revocation, it will be placed in a separate secondary authority certificate.
  • a secondary authorization certificate there is a need to refer to the primary identity certificate that the recipient must use to identify the party having the stated authority. Most commonly this is done by listing the issuer name and certificate number of the relevant identity certificate as a data field in the authority certificate. Or alternatively, it might be accomplished by directly reproducing all or part of the full identity specification from the base certificate. Whether the information is given in full, or by reference using a pointer (such as the issuer name and serial number), such identity information will in both cases be referred to as the "identity specification" of the authority certificate.
  • the distributed rule enforcement system defined herein continues this requirement, with the understanding that (unlike a pure contracting system, where the recipient may be anyone in the world) the most important recipients will be markets, clearinghouses, and payment processors, who are relatively few in number and comparatively easy to regulate and audit.
  • the initiating participant (sender) and any intermediary along the way can also check the validity of a transaction against the authorizations and restrictions specified in the relevant certificates.
  • the best point at which to perform effective checking is generally right before the final transfer or reliance takes place.
  • filters In the field of authorization certificates, the pertinent requirements may be defined as "filters" or composite statements containing logical operators, including AND, OR,
  • a short tag may declared and defined as standing for the given condition, requirement, variable or data value, which can then be used in the filter for economy of expression, being expanded in full prior to being interpreted and evaluated.
  • the ampersand '&' character may be used as a prefix to identify a text "macro" variable.
  • certificates are subject to revocation by their issuers at any time, based on receipt of information that makes the information represented in the certificate inaccurate or unreliable.
  • a certificate will be identified by its issuer name and certificate serial number. Issuers desiring to revoke certificates will publish the relevant serial numbers on a list, known as a certificate revocation list (CRL), containing the issuer's name and signed by the issuer.
  • CRLs are then made available to individuals, firms, and directory services, which in turn republish this information in broadly available form, such that anyone desiring to learn the status of a given certificate may do so by inquiring to the appropriate service.
  • This invention specifies (a) new certificate attributes suitable for assigning various types of trading rights and privileges to parties and entities in a global electronic market system; (b) new types of certificates to be attached to markets, products, and rules; and (c) new technical processes whereby these certificate attributes can be verified and compared by appropriate entities in the course of a transaction in an electronic market system to determine whether the rules have been followed and reject transactions that are not in accord with the rules.
  • Capabilities for performing real time checks of external limitation specs for specific product types in participant certificates.
  • Allowed market formats e.g., continuous double auction, dealer market, specialist market, one-price auction, Dutch auction, Vickrey [2nd price] auction, broker call auction, anonymous preference optimization, etc.
  • Allowed order matching rules e.g., traditional execution control rules such as stop, limit, AON, FOK, at the close, at the open, etc., as well as various novel methods of seeing a suitable match, including rules based on multi-factor nonlinear optimization, fuzzy logic, and the like). This will also include customer selectable instructions for splitting and grouping of an order, including partial order fills, allocation preferences, etc.
  • Allowed or preferred trade routing rules such as instructions to seek a match on a local order matching system for a certain period of time, and if unsuccessful, or if prices are moving in a certain direction, to reroute the order to another market and seek an execution there.
  • Intermarket trading groups in which the market participates. (Note: Each intermarket trading group will also have a certificate assigned to it, identifying its product groups and intermarket pricing rules. The market's certificate may refer to the intermarket trading group certificate.) 13. Source of funds rules, such as a restriction on the sources of funds that can be used to pay and settle transactions. 14. Information regarding who (which entities, e.g., market, clearinghouse, bank) will enforce market rules, whether any programmable trusted devices are used to enhance the reliability of the rule enforcement process, and if so who has administrative control of such devices.
  • Product Certificate issued by a regulator to define and enable a specific product, including its textual and data description (data format, rule set, terms and conditions, warranties, etc.), approved trading formats and rules (including acceptable matching rules, possible limits on bid/ask spreads, types of allowed participants, e.g., dealers or accredited investors only, etc.), how the ownership interest may be transferred (such as via instructions to a securities depository, transfer agent, or fulfillment service, etc.), restrictions on source/destination of funds/delivery including warranty requirements, external context restrictions, and who (if anyone) may modify the data description, etc.
  • textual and data description data format, rule set, terms and conditions, warranties, etc.
  • approved trading formats and rules including acceptable matching rules, possible limits on bid/ask spreads, types of allowed participants, e.g., dealers or accredited investors only, etc.
  • how the ownership interest may be transferred (such as via instructions to a securities depository, transfer agent, or fulfillment service, etc.)
  • restrictions on source/destination of funds/delivery including warranty requirements,
  • Rule Certificate issued by a regulator to a define and enable a specific matching rule or trade routing rule, including its textual and data description (pseudo-code, executable code, terms and conditions, etc.), market formats in which it may be used, approved methods of use, who may modify it, etc.
  • Participant Certificate issued by any reputable CA, such as a bank, preferably under authority and direction from a regulator or market, attesting to the identity, attributes, and qualifications of an individual user to participate in allowed trading markets, including allowed products and allowed trading and matching rules.
  • allowed markets, allowed products, trading rights, and trading/matching rules may be grouped in different ways.
  • the participant's certificate may contain an external limit specification, directing the market or clearing agent to verify that the participant has not exceed his trading limits (which may apply only to a small range of products). It may also contain a payment and settlement specification, identifying a bank account to be used as a source or destination of funds for purchases or sales, and a custody account (such as with a securities broker) to be used as the source or destination of the ownership interest in products traded.
  • a market index when being traded in an index futures market, can also be a product.
  • a market index certificate is primarily intended to provide an evidentiary definition of the index itself, for use in other calculations and processes. This will aid the proliferation of a wide variety of useful market indices in many areas other than financial securities.
  • Data Feed Source Certificate issued by a regulator to a source of current or historical price and transaction information. This certificate will define and register a source of price information, such as an active trading or dealer market, and may contain a public key which can be used to verify individual price feed messages (ticks) which have been timestamped and signed by the data source.
  • Quote Source Certificate issued by a regulator to a source of current price quotes, and may include a public key used to authenticate individual quote feed messages which have been timestamped and signed by the quote source. Since the entity certified is typically an active trading market, this is nearly the same as a market certificate. However, it may be preferable to limit use of the signature key of the market to signing completed transactions, while using a separate key for signing outgoing price quote messages. Data source and quote source certificates are useful to verify the source and timeliness of signed price report or quote status messages that may be required for enforcing "external context" restrictions.
  • the long form identity specification will be the basis for a primary identity certificate.
  • This certificate can, in theory, contain the additional specifications of authority, allowed markets, allowed products, trading rights, and product limitations. However, these items will typically be found in a secondary certificate that points to such a long form certificate using a short form identity specification (see next).
  • a short form identity specification will be used in a secondary certificate to provide a reference to the primary identity certificate.
  • the subject's name alone will generally be insufficient, since there may be multiple subjects with the same name, or it may be possible to procure a very low quality certificate that lists any subject name desired.
  • the issuer name and serial number are generally be required, to provide assurance to the sponsor granting the authority that the quality of the underlying identity certificate will not be less than anticipated.
  • identity_spec ⁇ issuer name (of base identity certificate) issuer serial number (of base identity certificate) hash of subject public key (optional) subject name ⁇
  • a party has a specified authority from another sponsor, such as a Series 7 broker license issued by the National Association of Securities Dealers (NASD)
  • a license would generally be represented by yet another secondary portfolio authorization certificate issued directly by or on behalf of the NASD.
  • the issuer of an authorization could be the NASD (or possibly Merrill Lynch) and the role or title could be "Series 7 qualified broker”.
  • product_spec ⁇ list or description of products ⁇
  • tradingjrights ⁇ trader, dealer, official, etc.
  • sponsoring broker * ⁇ one or more brokers ⁇ ⁇ purposes of this market specification:
  • product_desc ⁇ listed equity, listed equity options, OTC equity,
  • OTC equity options, commodity futures ⁇ • "trading rights" is a list of the privileges the subject has with respect to the product group in the specified market.
  • the rights to buy, sell, bid, ask, buy options, write options, view the pending order book, and others may be separately granted or denied with respect to a given product or class of products.
  • An official, whether of the exchange or from a regulatory body, may also have the right to view and participate in the market. They cannot buy or sell, but can view the order book approve or disapprove a given trade, and halt trading if necessary.
  • a participant may have a certificate that allows them (a) the right to trade (take market) in many products on many markets, subject to credit and broker sponsorship, but (b) only the right to "make market” in a relatively small number of products (i.e., post bid and ask prices and sizes, and view the book of pending orders, etc.).
  • these attributes will be grouped together to reflect these relative associations, as shown in the example below.
  • “sponsoring broker” is a list of one or more brokers that stands behind (makes itself legally liable for) the trades placed by the subject by: countersigning the subject's trades before they are placed confirming the subject's trades after they are placed
  • list_of_markets [1]
  • exchange type equity .AND.
  • the person holding the certificate possesses ordinary trading rights in any US equity market with an average daily volume greater than or equal to 1 million shares per day.
  • Products for which a participant has special trading rights could be identified in other ways, such as by some common property (e.g., stocks underwritten by a given dealer), or by the name of an access control (group) list (ACL) maintained within the exchange's computer system, etc.
  • groups access control
  • ACL access control list
  • These specifications apply mainly to market access and trading rights for purposes of placing and executing trades with unknown counterparties.
  • Trading rights could be subsumed under the prior art concept of allowed roles, but the currently existing roles of trader, dealer, specialist, etc. are not specific enough to directly imply the ability to post price quotes on specific stocks or view an order book in a market system.
  • the trading, market, product, routing, and other rules defined in this system can be enforced by any party having copies of the relevant certificates and the capacity to verify those certificates and compare them to the specifics of a given transaction.
  • participant By Participant.
  • the participant himself may retrieve all relevant certificates and make his own determination as to whether a given transaction will be allowed. He may often do so, to check the current validity of any given strategy he seeks to execute.
  • the participant cannot in general be trusted to enforce rules against himself, other than in an honor system.
  • Market Certificate A market certificate is issued by a regulator to an exchange market (dealer, order- driven, etc.) to identify the market, its sponsors and rules, and specify what classes of products it may trade.
  • a regulator may include (a) a government agency having jurisdiction over the products in question (e.g., US Securities and Exchange Commission, US Commodity Futures Trading Commission, US Federal Energy Regulatory Commission, US Environmental Protection Agency, etc.), or (b) an industry trade association which promulgates rules concerning trading activity and may provide a dispute resolution procedure (e.g., National Assn of Securities Dealers, National Futures Assn, National Grain and Feed Assn, Electric Power Research Institute, American Petroleum Institute, etc.)
  • a government agency having jurisdiction over the products in question e.g., US Securities and Exchange Commission, US Commodity Futures Trading Commission, US Federal Energy Regulatory Commission, US Environmental Protection Agency, etc.
  • an industry trade association which promulgates rules concerning trading activity and may provide a dispute resolution procedure (e.g., National Assn of Securities Dealers, National Futures Assn, National Grain and Feed Assn, Electric Power Research Institute, American Petroleum Institute, etc.)
  • the regulator may issue the certificate in its own name, or it may direct another to issue it on its behalf or under its authority.
  • network domain address of market mkt.nsepe.com
  • pointer to rule book http://www.nsepe.com/pub/rules.html
  • subject public key info Fle33S58hjRdFgSjfzFbhKEfd578, etc.
  • Such a certificate identifies the market, its sponsoring organization, the products it ed to trade, and the participants allowed to trade them, and certifies a public digital signature key, which it can use to authenticate itself. It might also specify the types of optimization and matching rules to be used, as will be described later.
  • this market certificate contains the notion of "use-conditions,” such as the qualifications required of participants, the products they can trade, settlement and payment terms, etc. This amounts to a joint statement by the market authorities and the issuing regulatory entity, specifying who may use the market and what rights they have.
  • a product certificate is issued by a regulator and applies to a specific product's textual and data description (data format, rule set, and terms & conditions) specifying how it may be traded in an approved manner, who may modify it, etc.
  • a rule certificate is a certificate issued by a regulator which applies to a specific trade matching rule, including its textual and data description (pseudo-code, executable code, and terms & conditions) specifying how it may be applied in an approved manner, who may modify it, etc.
  • a participant certificate may be issued by any reputable CA, such as a bank, under authority from a regulator or market, attesting to the identity and qualifications of an individual user to participate in allowed trading markets, handling allowed products, under allowed trading and matching rules. Allowed markets, products, rights, and trading/matching rules may be grouped in different ways, either by the use of parenthesis and macros within the same certificate, or more likely by the use of different participant certificates for each principal combination of rights. As shown in the drawings:
  • Participant Certificate ⁇ Ul Identity / Reliance U2 Authority Spec U3 Market Specs ⁇ U4 Allowed Products, U5 Allowed T/M Rules, U6 Trading Rights ⁇ Bank CA Signature ⁇
  • An index certificate is a certificate issued by a regulator or market which codifies and fixes the definition, formulas, and rules (terms and conditions) for a market index. As the index composition, formulas, and/or terms and conditions change over time, new certificates will be issued for each such version. Old versions may remain outstanding as they continue to certify the composition of the index for historical purposes, even after they have been superseded by a newer index definition. As shown in the drawings:
  • a nation's court system may refuse to provide legal remedies in accord with the rule of law, or may be incapable of enforcing its laws against bribery, corruption, organized crime, etc.
  • an effective transactional oversight capability hosted securely in a different country that does support the rule of law, can provide a framework for securely and properly administering an investment that may help minimize or avert losses to the outside investors.
  • the present invention provides a (a) general oversight framework by which the internal financial and accounting controls, as well as other rule-governed activities of a subject entity, can be greatly strengthened, and (b) elucidates a wide range of specific examples in which the oversight framework can be applied to produce useful results.
  • Several general methodologies are employed in this system: 1. Dual Control.
  • the public key digital signature of an entity or its officers can be based on a private key that is split into two or more fragments, with one held by the nominal signer (subject) entity and the other(s) held by a confirming (or oversight) entity.
  • the signer's digital public key certificate issued by a CA as described herein, may contain an indication that one or more oversight entities is involved, which can be either named or anonymous.
  • Co-Signatures Alternatively, the subject entity/signer's digital public key certificate can specify a required co-signer [as in Fischer] or state that there is a confirmation requirement [as in Sudia]. In this case the named required co-signer or confirmer can be the oversight entity. 3.
  • oversight entity would be a bank, CPA firm, or some other well recognized entity trusted to enforce the rules as described herein.
  • the oversight entity might be a government agency or administrative control board (e.g., a State Department of Finance), or it could be a parent corporation, major investor, superior government (e.g., cabinet) department, or another entity with "parental" responsibility toward the subj ect.
  • the overseeing party may maintain either (a) a complete (mirror) copy of the entire financial and administrative bookkeeping system of the subject entity, (b) a summary of information relevant to the overseer's decisions, (d) such information as is needed to operate the system of rules the overseer is required to enforce, or (d) possibly a complementary set of data (such as a partial ledger) that is related to but not identical to the ledger components maintained by the subject.
  • CA Certificates Under this system a CA issues a certificate that creates the oversight relationship. Typically, the CA is knowledgeable of this control system and is an active participant in helping to create and enforce the relationships defined herein. This certificate can be for a single public key that is partially held by the oversight entity, or for a key that is entirely held by the subject, but there is a stated co-signer or confirm-to requirement. When a recipient gets a signed document or transaction from the subject, they know in the first case the overseer must have contributed to the signature, or in the latter, the overseer's separate digital signature and associated public key certificate is also required to be present. 7. End-User Contracting.
  • a subject entity receives a public key certificate which contains the condition (either explicit or implicit) that its signature is not valid without the consent of an oversight entity.
  • the subject signs a business transaction in the ordinary course of business and sends it to a recipient, along with the subject's certificate, and the recipient validates the signature and the certificate, including verifying any conditions that may be stated in the certificate.
  • the transaction Prior to becoming valid, the transaction is first sent to the oversight entity, which may merely record it in a mirrored database for audit purposes, or it may check the transaction against some number of pre-determined rules to determine if it is valid according to those rules, confirming if it is okay, and declining to confirm and issuing an error message if it is not.
  • the oversight entity may merely record it in a mirrored database for audit purposes, or it may check the transaction against some number of pre-determined rules to determine if it is valid according to those rules, confirming if it is okay, and declining to confirm and issuing an error message if it is not.
  • a subject entity receives a digital public key certificate [1] from a CA, where the subject's signature is not complete or valid unless partially signed, co-signed, or confirmed by an oversight entity. Where relevant the overseer also receives a digital public key certificate [2].
  • the subject entity normally maintains a database or ledger detailing each business transaction as well as maintaining cumulative running totals for various important financial values and ratios, and checking the transaction against its internal business rules prior to issuing it.
  • the subject entity might not be trusted to make its decisions and keep its records in an entirely competent or honest manner.
  • the transaction is required to be sent to the oversight entity for partial signature, co-signature, or confirmation.
  • the oversight entity also maintains a database, which may be a full (mirrored) copy of the subject's database, or a subset or complement thereof, or may be a set of running totals with a series of rules to be applied in various cases.
  • a database which may be a full (mirrored) copy of the subject's database, or a subset or complement thereof, or may be a set of running totals with a series of rules to be applied in various cases.
  • the computer systems of both subject and overseer are programmed to process a set of pre-determined transactions. Also, there is a class of maintenance transactions that may be initiated by either party to create a new transaction type, decision rule or account type, modify an existing one, or delete an old one, typically taking effect only upon consent of the immediate overseer or some other overseer made responsible for approving such changes.
  • the subject entity forms and signs (or partially signs) a business transaction [3], updates its own database, and sends it to the overseer for partial signature, co-signature, or confirmation.
  • the overseer checks the transaction, updates its own database, approves the transaction by partially signing, co-signing, or confirming it, and then either (a) sends it back [4] to the subject which passes it on [5] to the intended recipient, or (b) sends it [6] to said recipient directly.
  • FIGS 7-9 show three prior art frameworks for multiple-signature approval. Any of the three can work equally well in the present invention, along with any others which may be discovered in the future that can perform a similar function of distributing an approval function among a plurality of entities. This material is being covered here in some detail to simplify the main discussion of oversight control mechanisms that follows.
  • a subject entity [1] prepares and partially signs a document or transaction using a partial private key [k ⁇ l] and transmits it [2] to the oversight entity [3] which (after performing the checks described in this invention) also partially signs it with its matched portion [k"2] of the private key [K], which is then forwarded to the final recipient.
  • the recipient receives or obtains a digital public key certificate [5] naming the Subject, and listing its public key K.
  • Recipient already possesses the public key [6] of the CA, which it received via a trusted delivery method.
  • the document to be signed would be routed via a Workflow Engine to both the Subject and the Overseer, and their partial signatures would each be computed separately, in parallel. Then the workflow engine would route the partially signed documents to a "Combiner" that combines the two (or more) partial signatures into one full signature, whereupon the Workflow Engine sends the fully signed document to its intended destinations, generally sending fully signed copies to all three parties. 8.2. Required Co-Signer
  • FIG 8 shows a simplified overview of a required co-signer scheme, in which a Subject Entity [1] prepares and fully signs a document or transaction [2], with the proviso that its CA certificate (or secondary authority certificate) [5] states that the Subject's signature is not valid without the co-signature of the Oversight Entity, or at least is not valid by itself for certain types of transactions, such as those with a stated value of over $10.
  • the transaction is sent to the Oversight Entity [3] for its review and approval, and after performing the checks and operations described in this invention, it will generally approve the transaction by co-signing it, and forwarding it to the Final Recipient [8].
  • the Recipient [8] has already received the public key [K + C ] 0 f the CA, which it received via a trusted delivery method. It obtains the certificates [5, 6] of the Subject and Oversight entities, either with the transaction or by retrieving them from a directory, verifies them using the CA public key, and in turn uses the respective public keys of the entities listed therein to verify [7] the Subject signature and Overseer co-signature, whereupon, if all signatures verify and all conditions are satisfied, it accepts [8] the transaction.
  • the document or transaction is formatted according to "PKCS #7: Cryptographic Message Syntax Standard” (or its successor, "S/MIME”) and each successive signature is attached using a series of PKCS #7 signature blocks, which blocks may if desired carry the signer's certificates as unauthenticated attributes. 8.3. Required Confirmer
  • FIG 9 shows a third framework for requiring the Oversight Entity's consent before the Final Recipient can be permitted to legally rely on the transaction.
  • the Subject Entity [1] prepares and sends a document or transaction [2] directly to the Final Recipient
  • the Recipient obtains the Subject's certificate [6], either with the transaction [2] or by retrieval from a directory, and notes that it contains an "Overseer Must Confirm" requirement and names a specific overseer (or a determinable class of overseers).
  • the recipient then sends at least part of the transaction to Oversight Entity [4], which after performing the checks and operations described in this invention, will generally approve the transaction by co-signing it, and return it to the Recipient [5].
  • the Recipient [3] obtains the certificates [6, 7] of the Subject and Oversight entities, verifies them using the CA public key, and uses the respective public keys of the entities listed therein to verify [8] the Subject signature and Overseer co-signature. If all signatures verify and all conditions are satisfied, it accepts the transaction.
  • the agent or counterparty may notice (from facts noted in the agent's or entity's certificate) that the agent did not possess valid authority or consent to make that contract (or authorize that instruction).
  • the counterparty relying upon the legal doctrines of apparent authority or implied authority, can claim that the principal (the subject entity) is legally bound by its agent's representations, especially if the counterparty changed position (e.g., shipped goods) in reliance upon the existence of a contract. This may be termed "leakage,” and it is a legal problem, whose solution lies outside the scope of the present invention.
  • Possible countermeasures include (a) counter claim for mistake of fact, (b) legislation, or (c) creation of a novel corporate charter for "subject entities," possibly attended with a new type of chartered entity designation (distinct from existing designations such as Corp, Inc, LLC, LTD, and so on), to place all potential counterparties on legally effective notice that "leakage" contracts will not be enforced.
  • the Oversight function can be divided among several distinct entities, under the control of different legal organizations, which may exist mainly as backups to each other for reliability purposes, or may substantively divide up roles and perform different parts of the approval process, each contributing to the resulting signature(s) and
  • the Subject entity may in fact consist of multiple entities, with varying relationships to each other, such as a corporation or government agency and its subdivisions.
  • the manner of computing or forming the signatures from each entity to effect complete approval can, in any given case, be based on all parties adhering to one of the three major multi-party approval frameworks given above, or as it will be obvious to one skilled in the art, the approval of any given participating entity can be obtained and verified using any of the above or similar methods, independently of the method used by any other participant, and furthermore, one entity's approval in a given case could be expressed using any of these or similar methods, without regard to how approval was expressed by that same entity in any prior approval.
  • FIG 10 shows a simple but desirable multi-entity configuration, in which there are still only two legally distinct entities, the Subject Entity and the Oversight Entity, but both of them are mirrored replica sites for reliability and disaster protection, thereby giving the effect of four separate entities (since it is undesirable to mirror a private key fragment).
  • the multi-signature group signs with a single key which here has been divided into four fragments [k ⁇ l ... k"4], of which any two are sufficient to form the valid signature of the Subject Entity (i.e., a "2-of-4" multi-signature scheme) as taught by and Brickell et al and references cited therein.
  • approval by the Oversight entity is conditional on its first performing a pre-determined set of checks and other operations, as further described below.
  • a Subject Entity forms a document or transaction, partially signs it with its private key fragment [k ⁇ l], and forwards [1] the partially signed transaction to a Combiner [4] (as further described in Brickell et al). At the same time, it forwards a copy [2] of that transaction to the Oversight Entity, which after performing predetermined checks and other operations, typically approves and partially signs its copy with its private key fragment [k ⁇ 3] and forwards [3] the second partially signed result to the Combiner [4].
  • the Oversight Entity which after performing predetermined checks and other operations, typically approves and partially signs its copy with its private key fragment [k ⁇ 3] and forwards [3] the second partially signed result to the Combiner [4].
  • Combiner [4] combines the two partial signatures to form one whole signature, which it then appends to the transaction, discards the partial signatures, and sends the result [5] to the Final Recipient.
  • the Oversight Entity In case the primary Oversight Entity site becomes unavailable, due to a system or network or other failure, the Oversight Entity "cuts over" to its mirror site, and in accord with well known principles of reliable computing system design and operation, it typically notifies the Subject Entity (which here is still operating normally) to send transactions [7] to its mirror site.
  • the Oversight Entity performs the same pre-determined checks and operations (or similar ones) prior to approval as it would have performed at its primary site, partially signs the transaction, and sends the result [8] to the Combiner [4], which combines the partially signed transactions into one fully signed one and forwards [5] that to the Final Recipient, which verifies the transaction using the Subject's digital public key certificate and the public key [K + C ] 0 f the CA, which it received via a trusted delivery method, and accepts or rejects the transaction [6] based on the outcome of said verification.
  • Oversight Entity does not solely approve or reject a transaction proposed by the Subject Entity, but itself is a substantive participant in determining the content of the transaction.
  • Such a configuration could exist where two or more Subject Entities were both involved in planning and executing the transaction, and at least one is serving as an Oversight Entity for the other.
  • the multi-signature method may become impractical, as the partial signature of the first entity becomes invalid if the second entity adds or changes the transaction data.
  • a process can be supported via the required co-signer or required confirmer frameworks. Under either of those frameworks, it would not be unusual for the Oversight Entity, in addition to approving the Subject Entity transaction, to furnish some additional data, such a transaction approval sequence number, or any other data that might be useful for the Final Recipient.
  • CD parental Cabinet Department
  • B specific Bureau
  • CD could confirm B's financial transactions, adding to them such useful information as the CD level account number from which the funds will be derived, and specifying in real time a bank account number from which the funds can be drawn.
  • a parent insurance company may exercise oversight authority over all transactions of a local insurance subsidiary, and in addition to approving each policy written or claim paid, the parent (in addition to administering a set of solvency and diversification rules, as further discussed below) can also furnish in real time a master binder number for a policy or a bank account number from which a payment is to be made.
  • an entity such as a certified digital signature capability and/or access to designated bank accounts or other digitally managed rights
  • this system can be used to implement a set of rule based controls around an accounting system, typically for the benefit of a lender or investor.
  • the objective would be to assure via the oversight entity that 2 general rules are followed: a.
  • the accounting system's "books" always remain in balance, and b. No payment orders are authorized against a given bank account unless sufficient funds are available in it. 10.2. Oversight Plan
  • the subject entity [company] and oversight entity possibly in cooperation with (a) the lender or investor [PAA: plan approving authority], and (b) the bank that holds the account [DTI: deposit and transfer institution], would develop and agree to an oversight plan, to be implemented and followed in all relevant transactions.
  • the oversight entity could be the PAA or DTI, or any other specialized entity holding itself out as a provider of secure distributed business oversight services.
  • plan would specify the precise mechanism of the control structure, and identify the certification authority that will issue a certificate for the subject's signature, conditional upon the oversight process. This certificate would be come active upon completion and verification of all processes needed to assure that the oversight model is implemented and is operating correctly. 10.3. Oversight Model and Initial Rules Under such an oversight model, the subject and oversight entities would agree upon an approved accounting method and chart of accounts, and a pre-determined set of transaction types and formats that could be initiated by the subject entity and forwarded to the oversight entity for approval.
  • the process can be further defined to include issuance of certificates, initial state data input and approval, change data (add, modify, delete), migration to new oversight model, and oversight termination and wrap-up.
  • the secure distributed accounting system can enforce a variety of rules or conditions: Simple mirrored database (keep a true copy), double entry with credit debit separation, bank risk capital rules, payment processor R > T constraint, insurance capital rules and monitoring.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Security & Cryptography (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne un procédé de communication d'informations authentifiées relatives à un certificat numérique à clé publique. Une structure de données en arbre de hachage est créée et contient une liste prédéterminée d'informations possibles, telles que des autorisations, des restrictions, des privilèges, ou des notifications de périodes de validité. Les articles de la liste peuvent comprendre du texte et des valeurs codées. Chaque entrée de la liste se voit préfixer une valeur de données aléatoires différente (bloqueur) stockée de manière sûre et impossible à deviner. Chaque article de la liste est haché de façon à produire un hachage de feuille. Les hachages de feuille sont combinés pour produire un arbre de hachage, et le noeud de racine dudit arbre est incorporé dans un certificat numérique ou un message signé au moyen d'une clé privée. En réponse à une demande d'informations authentifiées relatives à un certificat numérique à clé publique, l'authorité du certificat publie l'article pertinent de la liste, sa valeur de bloqueur, et d'autres valeurs de hachage suffisantes pour authentifier l'article de la liste au moyen du noeud de racine incorporé dans le certificat numérique.
PCT/US2000/021586 1999-08-09 2000-08-08 Systemes repartis d'application de regles WO2001011812A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU67609/00A AU6760900A (en) 1999-08-09 2000-08-08 Distributed rule enforcement systems

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US14786999P 1999-08-09 1999-08-09
US14795199P 1999-08-09 1999-08-09
US60/147,869 1999-08-09
US60/147,951 1999-08-09

Publications (2)

Publication Number Publication Date
WO2001011812A2 true WO2001011812A2 (fr) 2001-02-15
WO2001011812A3 WO2001011812A3 (fr) 2001-09-13

Family

ID=26845295

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/021586 WO2001011812A2 (fr) 1999-08-09 2000-08-08 Systemes repartis d'application de regles

Country Status (2)

Country Link
AU (1) AU6760900A (fr)
WO (1) WO2001011812A2 (fr)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2390446A (en) * 2002-07-02 2004-01-07 Hewlett Packard Co Apparatus for analysing electronic representations of business processes
US6766450B2 (en) 1995-10-24 2004-07-20 Corestreet, Ltd. Certificate revocation system
US7657751B2 (en) 2003-05-13 2010-02-02 Corestreet, Ltd. Efficient and secure data currentness systems
US7660994B2 (en) 1995-10-24 2010-02-09 Corestreet, Ltd. Access control
US7716486B2 (en) 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US7822989B2 (en) 1995-10-02 2010-10-26 Corestreet, Ltd. Controlling access to an area
US7966487B2 (en) 2004-01-09 2011-06-21 Corestreet, Ltd. Communication-efficient real time credentials for OCSP and distributed OCSP
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
US8707030B2 (en) 2003-11-19 2014-04-22 Corestreet, Ltd. Distributed delegated path discovery and validation
US8732457B2 (en) 1995-10-02 2014-05-20 Assa Abloy Ab Scalable certificate validation and simplified PKI management
CN109766375A (zh) * 2017-11-09 2019-05-17 布罗德里奇金融解决方案公司 用于加密保护的分布式数据管理的以数据库为中心的计算机网络系统和计算机实现的方法
CN110992045A (zh) * 2019-11-15 2020-04-10 安徽海汇金融投资集团有限公司 一种应收账款债权流转异常风险监控方法及系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5987440A (en) * 1996-07-22 1999-11-16 Cyva Research Corporation Personal information security and exchange tool

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5987440A (en) * 1996-07-22 1999-11-16 Cyva Research Corporation Personal information security and exchange tool
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
DAVID CHESS ET AL.: 'Itinerant agents for mobile computing' IEEE PERSONAL COMMUNICATIONS October 1995, pages 34 - 49, ISSN: 1070-9916 *

Cited By (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7716486B2 (en) 1995-10-02 2010-05-11 Corestreet, Ltd. Controlling group access to doors
US7822989B2 (en) 1995-10-02 2010-10-26 Corestreet, Ltd. Controlling access to an area
US8732457B2 (en) 1995-10-02 2014-05-20 Assa Abloy Ab Scalable certificate validation and simplified PKI management
US8015597B2 (en) 1995-10-02 2011-09-06 Corestreet, Ltd. Disseminating additional data used for controlling access
US6766450B2 (en) 1995-10-24 2004-07-20 Corestreet, Ltd. Certificate revocation system
US7660994B2 (en) 1995-10-24 2010-02-09 Corestreet, Ltd. Access control
US8261319B2 (en) 1995-10-24 2012-09-04 Corestreet, Ltd. Logging access attempts to an area
GB2390446A (en) * 2002-07-02 2004-01-07 Hewlett Packard Co Apparatus for analysing electronic representations of business processes
US7657751B2 (en) 2003-05-13 2010-02-02 Corestreet, Ltd. Efficient and secure data currentness systems
US8707030B2 (en) 2003-11-19 2014-04-22 Corestreet, Ltd. Distributed delegated path discovery and validation
US7966487B2 (en) 2004-01-09 2011-06-21 Corestreet, Ltd. Communication-efficient real time credentials for OCSP and distributed OCSP
CN109766375A (zh) * 2017-11-09 2019-05-17 布罗德里奇金融解决方案公司 用于加密保护的分布式数据管理的以数据库为中心的计算机网络系统和计算机实现的方法
CN109766375B (zh) * 2017-11-09 2024-05-28 布罗德里奇金融解决方案公司 用于加密保护的分布式数据管理的以数据库为中心的计算机网络系统和计算机实现的方法
CN110992045A (zh) * 2019-11-15 2020-04-10 安徽海汇金融投资集团有限公司 一种应收账款债权流转异常风险监控方法及系统
CN110992045B (zh) * 2019-11-15 2024-03-22 安徽海汇金融投资集团有限公司 一种应收账款债权流转异常风险监控方法及系统

Also Published As

Publication number Publication date
WO2001011812A3 (fr) 2001-09-13
AU6760900A (en) 2001-03-05

Similar Documents

Publication Publication Date Title
US11522700B1 (en) Systems, methods, and program products for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
US11139955B1 (en) Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
JP6704985B2 (ja) デジタル資産仲介電子決済プラットフォーム
US20190197622A1 (en) System and method of providing unique identifiers in security blockchain-based tokens
US6236972B1 (en) Method and apparatus for facilitating transactions on a commercial network system
US8055575B2 (en) Central counterparty for data management
US20180189887A1 (en) Cryptographic currency for financial data management, digital and digitalized cross-asset identification and unique digital asset identifier generation, asset valuation and financial risk management
US20190197620A1 (en) Financial settlement systems and methods
US20160335629A1 (en) Rights transfer and verification
US20020128958A1 (en) International trading of securities
US20120185373A1 (en) Registry of u3 identifiers
JP2002536706A (ja) 証明書関連その他のサービスを提供するシステム及び方法
US20120011044A1 (en) Method and system for issuing primary securities in a trading market
US20220277275A1 (en) Distributed cryptographic tokens with downstream administrative control
CA2416550A1 (fr) Systemes de gestion d'avoirs perfectionnes
US20190385172A1 (en) Trade finance management systems and methods
KR102303711B1 (ko) 유가증권의 공매도를 지원하는 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
WO2001011812A2 (fr) Systemes repartis d'application de regles
Adrian et al. A multi-currency exchange and contracting platform
Jain et al. A blockchain technology approach for the security and trust in trade finance
Welch Electronic banking and treasury security
US11909860B1 (en) Systems, methods, and program products for loaning digital assets and for depositing, holding and/or distributing collateral as a token in the form of digital assets on an underlying blockchain
KR20190051366A (ko) 분산원장을 이용하여 유가증권 공매도를 지원하는 방법, 시스템 및 비일시성의 컴퓨터 판독 가능 기록 매체
Ante Cryptocurrencies
Martino et al. Blockchain Technology: Key Features and Main Applications

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

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

AL Designated countries for regional patents

Kind code of ref document: A2

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
AK Designated states

Kind code of ref document: A3

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

AL Designated countries for regional patents

Kind code of ref document: A3

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

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase in:

Ref country code: JP