[go: up one dir, main page]

WO2000028452A1 - Architecture securisee permettant l'execution d'echanges de contrats a signature numerique - Google Patents

Architecture securisee permettant l'execution d'echanges de contrats a signature numerique Download PDF

Info

Publication number
WO2000028452A1
WO2000028452A1 PCT/US1999/025853 US9925853W WO0028452A1 WO 2000028452 A1 WO2000028452 A1 WO 2000028452A1 US 9925853 W US9925853 W US 9925853W WO 0028452 A1 WO0028452 A1 WO 0028452A1
Authority
WO
WIPO (PCT)
Prior art keywords
party
contract
holder
parties
backer
Prior art date
Legal status (The legal status 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 status listed.)
Ceased
Application number
PCT/US1999/025853
Other languages
English (en)
Inventor
Robert Green
Jeremy Stammers
Vincent Cate
Sean Hastings
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SECURE ACCOUNTS Ltd
Original Assignee
SECURE ACCOUNTS Ltd
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 SECURE ACCOUNTS Ltd filed Critical SECURE ACCOUNTS Ltd
Priority to AU19079/00A priority Critical patent/AU1907900A/en
Publication of WO2000028452A1 publication Critical patent/WO2000028452A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/3825—Use of electronic signatures

Definitions

  • This invention relates to the use of computers, networks, and encryption algorithms to manage and secure exchanges of value, and more particularly to a computer architecture and system for performing and managing value exchanges that operate on a wide range of inexpensive computer systems.
  • Value exchanges in the abstract sense are a part of payments, invoicing, bartering, market making, wire transfers, stock trades, issuance and clearing of checks, and currency conversions.
  • the existing prior art performs some, but not all of these value exchanges, or only performs the communication needed prior to the exchange and not the exchange itself.
  • Open Trading Protocol is a method of making incompatible payment systems interoperable. It sits on top of other payment systems such as Mondex and is supported by a consortium of payment vendors .
  • Open Financial Exchange is a standard for formatting requests and responses in a markup language, but does not specify how the requests are processed; security via SSL is optional;
  • JEPI - Joint Electronic Payment Initiative from CommerceNet and W3C the World Wide Web Consortium
  • Mondex Electronic Cash extends the ATM model by making smart cards where the money and the secret that protects it are embedded in a special card.
  • the security of the money is dependent upon special hardware that is difficult to break into. To spend the money, you must insert the card into an ATM or special reader. If you cannot read the internals of the card, you cannot duplicate it. If you could duplicate the card, you could steal the "money” .
  • the money belongs to the physical card; if you lose the card, you lose the money. If someone steals the card, they may not be able to spend the money, if the card has a PIN, but you have still lost it. There is no output from the card except to a card reader such as the ATM. If a phony ATM on the street was taking all your electronic money, but telling you it was not, you would have no way of knowing until you tried to use the card again later at a real ATM. Mondex will probably be used mainly for small amounts, with no accounting record.
  • This model of electronic money is patterned after real physical money. The value is recorded in a unique physical configuration that is difficult to counterfeit and can be used anonymously.
  • CyberCash puts a public key around an existing credit card number in order to allow merchants to do real-time credit card authorizations.
  • CyberCash is converting its system to use SET, which is a version of this approach created by the credit card organizations themselves .
  • the present invention can easily emulate the wrapping of a credit card in a public key: in the agreement field of a SAXAS contract, you authorize another party to charge your credit card, and then you digitally sign the contract. But SAXAS can do much more: handle multiple accounting units, match up complementary conversion orders, and transfer values without a credit card being involved.
  • eCashTM a product of Digicash
  • eCashTM offers software-based electronic coins that can be spent at eCash merchants and verified at a central point or bank. Since eCash "coins" can be digitally duplicated, the first person to the bank gets the money. They can only be used once and each has a unique serial number. There is no special hardware required, since each coin is just a string of bits that equals the right to a specific amount of money.
  • eCash assumes a central issuing authority, modeled after existing currency issued by governments and deposited at banks. When you transfer eCash to another party, the bank must play a part. That is because eCash coins can be duplicated and can only be spent once. Therefore, eCash must have a central database that lists all the serial numbers of coins issued and which have been spent so far. SAXAS allows accounting unit balances to move from party to party without the issuing bank being aware of the transfer. ECash uses a
  • the SAXAS system can emulate the eCash capability by creating a one-time identity for a SAXAS contract, then including the private key as well as the public key within the contract.
  • Teen receiving the contract could sign it, execute it, then do an Owner change to move the amount from the one-time account to his or her own account.
  • First Virtual is an Internet payment system that allows you to circumvent sending your credit card over the Internet. You set up an account with them, register your credit card over the phone, and type in your password when prompted at sites charging using this system. You have to wait 60 days for your money, and it is one of the most barrier free methods of receiving payment over the Internet, you do not even need a merchant credit card account to accept credit cards. You do need to set up some scripts on a working First Virtual server.
  • Open Trading Protocol is a consortium that is attempting to create "an open and interoperable standard for purchasing goods and services on the Internet.”
  • the model behind OTP is the existing business of purchasing goods and services.
  • Existing types of participants in this model are explicitly identified in the model (i.e., merchant, consumer, deliverer, customer care agent, bank) .
  • Open Financial Exchange is a markup language for creating requests and formatting responses. It specifically tags for USA-based financial attributes such as 401K Plans, etc. Security via SSL is optional. OFX does not specify how exchanges are processed or does it perform exchanges itself. OFX looks like an extended version of HTML (HyperText Markup Language) with tags for specific financial structures. It imposes a structure on the messages that is mapped on the specific types of financial institutions that are the intended audience of the protocol. That is, it is not a generalized method for doing any value exchange.
  • HTML HyperText Markup Language
  • OFX the servers are identified by X.509 certificates. If the client and server do not share a common Certificate Authority (CA) , the client cannot validate the server's certificate. Therefore, OFX specifies which CAs are to be trusted by OFX clients.
  • CA Certificate Authority
  • Verisign and Thawte There are currently two main Certificate authorities that have achieved market acceptance: Verisign and Thawte. They perform due diligence on a person of firm or web page or email address, then "certify" that the public key actually came from the entity in question, and generates an X509 certificate that a party can supply to strangers to vouch for them.
  • SAXAS allows all parties to identify themselves with X.509 certificates, but such certificates are optional in SAXAS and it is up to a particular SAXAS server to decide which certificates it will require.
  • X509 certificates are not essential to performance of the invention set forth in this application.
  • the parties to a contract may require a particular type of certificate from the parties, or they might not, depending on the situation.
  • a network-based sales system includes at least one buyer computer for operation by a user desiring to buy a product, at least one merchant computer, and at least one payment computer.
  • the buyer computer, the merchant computer, and the payment computer are interconnected by a computer network.
  • the buyer computer is programmed to receive a user request for purchasing a product, and to cause a payment message to be sent to the payment computer that comprises a product identifier identifying the product.
  • the payment computer is programmed to receive the payment message, to cause an access message to be created that comprises the product identifier and an access message authenticator based on a cryptographic key, and to cause the access message to be sent to the merchant computer.
  • the merchant computer is programmed to receive the access message, to verify the access message authenticator to ensure that the access message authenticator was created using the cryptographic key, and to cause the product to be sent to the user desiring to buy the product.
  • the method for transferring funds from a payer to a payee comprises the steps of preparing a payment form including information- for identifying an amount to be transferred, a bank of the payee and an account number of the payee, receiving and verifying a security code at an encryption unit to authorize a transmission including an encryption, preparing a facsimile transmission device to send an image of the payment form, connecting the facsimile device through the encryption unit over a communication line to a payment service provider, receiving at the payment service provider the transmission including an encryption, and sending a confirmation message to the facsimile device that the transmission has been correctly received, decrypting the encryption at the payment service provider, determining whether the encryption was authentically generated by the payer, extracting the identifying information from the facsimile transmission, and generating an electronic funds transfer request based on the identifying information provided that the encryption is determined to be authentic .
  • a system for electronic commercial payment having a customer trusted agent associated with a first money module, a merchant trusted agent that establishes a first cryptographically secure session with the customer trusted agent and associated with a second money module. Where the money modules establish a second cryptographically secure session.
  • the customer trusted agent provides remittance advice information to the merchant trusted agent, and the merchant trusted agent provides a commercial payment ticket to the customer trusted agent. Upon receiving said commercial payment ticket, the customer trusted agent initiates a transfer of electronic money from the first money module to the second money module.
  • This invention describes a combination of methods and apparatus that creates electronic money for personal transactions which integrates the functions of cash, checks and credit cards with constant surveilance against fraud.
  • This money can also serve as an international medium-of-exchange, and support automated sales tax collections and payment.
  • This money's support system is comprised of personal terminals, vendor terminals, an electronic banking sub-system, and homebase terminals. Such a system, if widely used, would increase commercial and personal productivity, provide better security against fraud and counterfeiting, facilitate the automation of operations that involve currency, and sharply diminish the flood of paper that threatens to inundate the present system.
  • a number of electronic communications methods are described involving a first and second party (i.e., sender and recipient) , with assistance from at least a trusted party, enabling electronic transactions in which the first party has a message for the second party.
  • the first party, the second party and the trusted party undertake an exchange of transmissions, such that if all transmissions reach their destinations the second party only receives the message if the first party receives at least one receipt.
  • the identity of the first party is temporarily withheld from the second party during the transaction.
  • At least one receipt received to the first party enables the first party to prove the content of the message received by the second party.
  • a courier electronic payment system provides customers, merchants, and banks with a secure mechanism for using a public network as a platform for credit card payment services.
  • the system governs the relationship between a Customer, Merchant, and Acquirer Gateway to perform credit card purchases over such networks as the Internet.
  • the system uses a secure connection to simplify the problem of Internet-based financial transactions in accordance with an electronic payment protocol that secures credit card payments and certifies infrastructure that is required to enable all of the parties to participate in the electronic commerce, as well as to provide the necessary formats and interfaces between the different modules and systems.
  • a network payment system performs payment order authorization in a network with untrusted switching, transmission, and host components. Payment orders are backed by accounts in an external financial system network, and the payment system obtains account authorizations from this external network in real-time. Payment orders are signed with authenticators that can be based on any combination of a secret function of the payment order parameters, a single-use transaction identifier, or a specified network address.
  • Accounting Units to facilitate general or limited value exchanges; examples include, but are not limited to, banks that require a way to manage customer balances, Frequent Flyer Miles for airlines, gambling tokens for casinos, cooperative marketing "coupons" that allow a customer to purchase related products from other vendors, etc.
  • Fig. 1 shows the relationship of the parties and resources used in a value exchange
  • Fig. 2 shows a public key that can define and identify a party and digital signature which can verify that a party agrees to the contract;
  • Fig. 3 shows an X.509 certificate that is an alternate way to define and identify a party
  • Fig. 4 shows an account defined by a unique triplet of Holder, Owner and Backer, plus a balance
  • Fig. 5 shows several different types of accounts
  • Fig. 6 shows the accounts created for one backer, two holders and three owners ,-
  • Fig. 7 shows the accounts created when a holder is also an owner of units
  • Fig. 8 shows the structure of a value exchange contract
  • Fig. 9 shows the three types of contracts
  • Fig. 10 shows a Single-Party Owner Change Contract with an agreement
  • Fig. 11 shows the structure of a multi-party Owner Change contract
  • Fig. 12 shows Holder Change Contract, from Original Holder to Backer
  • Fig. 13 shows Holder Change Contract, from Backer to new Holder
  • Fig. 14 shows the structure of a Backer Change contract
  • Fig. 15 the same accounts in Fig. 6, but with Friendly Names instead of element numbers;
  • Fig. 16 shows the execution logic for an Owner Change contract;
  • Fig. 17 shows the execution logic for a Holder Change contract;
  • Fig. 18 shows the execution logic for a new Backer Change clause
  • Fig. 19a and 19b show examples of matching Backer change clauses
  • Fig. 20 shows a queue of waiting Backer change clauses matched to a new backer change clause
  • Fig. 21 shows the queue of Backer change clauses after matching a new clause.
  • This invention involves a secure architecture for value exchanges among parties, such that the parties can be widely distributed geographically and can employ a wide range of Accounting Units. It comprises a formalized legal contract in a special format, a public key that identifies each party, a computer for each party, a software program for each party that can create, validate, sign, store, encrypt, transmit, and execute contracts, a communication method between the computers, and a database for each party to hold the contracts and Identity information for each party.
  • Fig. 1 shows the main components of the SAXAS architecture of value exchange.
  • An actor in an exchange is called a Party 50.
  • a party may play more than one role in a given exchange and a party's role may change for each exchange.
  • the architecture allows any party to be a Backer, a Holder or an Owner, or all three.
  • the Identity 98 of a party consists of a unique Public Key 68, Fig. 2, plus any information that the party wishes to make public.
  • the Identity is signed by the party. This digital signature ensures that the identity information does go with the public key.
  • the public key is also used to encrypt communications with the party, ensuring that only the intended party can read the message.
  • the information in the Identity includes a Notify Method which specifies how the SAXAS software can communicate with the party. This field will contain a URL (Universal Resource Locator) , which can specify a Internet address or an email address.
  • URL Universal Resource Locator
  • the identify information may also include a preferred friendly name, telephone number, web page address, and details on any SAXAS services that the party offers .
  • the Identity may also include a list of attached documents, including, but not limited to, X.509 certificates and graphic logo images.
  • the computer 54 could comprise a personal computer (PC) running Windows® 95 or Windows® 98 with a minimum of 32MB of memory and at least 5MB of free disk space to manage the database, code and installation requirements.
  • PC personal computer
  • the computer 54 is a personal computer (PC) running Windows NT Workstation or Server software, then it requires a minimum of 64MB of memory and 5MB of free hard disk space.
  • the database 52 components could include a database engine compatible with JDBC, such as SQL Anywhere 5.0 from Sybase or Access from Microsoft. Also required is a JDBC driver and an ODBC drive for this database.
  • the SAXAS software required would include an Installshield or self-extracting zip file containing the SAXAS software, JRE 1.2, JDK 1.1.6, JIT 1.1.7.
  • the communications requirement includes a TCP/IP connection to other SAXAS sites, such as provided by an Internet Service Provider through a modem, or indirectly through a LAN using Network Interface Cards and then through an Internet Connection.
  • the combination of resources belonging to a party creates a Server 96 for the Party, which is capable of managing recording the exchanges undertaken by the Party. It is possible for a single physical server to act as the logical server for a number of parties; the only requirement is that these parties share the same Transport public key for decoding incoming contracts. The function and use of these resources is explained further in the drawings and description that follow.
  • the Backer 62 is the party that issues or "backs" an Accounting Unit, which can also be considered as an electronic currency or virtual currency.
  • the backer guarantees the accounting unit value by providing exchange to a specified Real World value.
  • the backer must also act as holder and support a market for the accounting unit, matching buy and sell orders.
  • the backer may also act as holder for other accounting units and provide exchanges to and from them to his accounting unit.
  • the backer may also act as the owner of accounts with other holders .
  • the Backer can be a government that backs legal tender, a bank that backs receipts for legal tender or for shares in a Money Market Mutual fund, a.
  • the architecture does not ensure in any way that the backers are reliable or can be trusted to keep their promises. What the architecture does do is create an open market in their accounting units such that the exchange value of the accounting units can be marked down if the backer is unreliable. Therefore, what is backing an accounting unit is actually the reputation of the backer.
  • An Accounting Unit is equivalent to the public key that identifies the backer 62.
  • a specific person or organization could of course have several public keys and act as backer for several Accounting Units .
  • the Holder 58 is typically a bank, escrow agent or broker.
  • the Holder keeps amounts for other Owners in the Accounting Units of one or more Backers.
  • the holder may provide various exchange services that are publicly defined in the architecture and available for computerized execution.
  • the holder must be the Owner of an account with each Backer whose Accounting Unit it holds.
  • the holder may also be an Owner of accounts with other holders and may also be the backer of an accounting unit.
  • the holder may provide whatever degree of anonymity or lack thereof that he decides is appropriate to his business.
  • the Holder enforces knowledge of parties by requiring specific types of Certificates 74 in a party's Identity 98.
  • the Owner 60 is the signatory for one or more accounting unit balances at one or more holders.
  • the owner must sign for any transfers from those balances.
  • the owner may also be a holder or a backer.
  • the owner identity may be a temporary identity that is used only one-time.
  • the degree of anonymity allowed to an owner is determined
  • Fig. 2 shows the format of a public key 68 and a digital signature 114.
  • a public key is a sequence of unforgeable characters that can uniquely and securely identify the party who holds the corresponding private key (see U.S. Patent No. 4,200,770, for the Diffie-Hellman public key cryptosystem and U.S. Patent No. 4,405,829 for RSA public key cryptosystem) .
  • each party is uniquely defined by a public key.
  • the private key is used to sign SAXAS contracts and changes to contracts that are specific to the signing party.
  • the result is a digital signature 114, like the one shown in Fig. 2.
  • the public key is used to verify authorizations by the party, ensuring that only the true party can authorize withdrawals of value from that account or exchanges to other Accounting Units. So, the official name and identity of a Party, whether acting as Holder, Owner or Backer, is the public key.
  • Fig. 3 shows another form of party identity: the X.509 digital certificate.
  • This is a public key plus information about the real world identity of the party, all signed and verified by a certifying authority.
  • a party who acts as a holder can require that the parties it opens accounts for have valid certificates from specified authorities. In this way the holder can enforce the degree of anonymity it wishes to offer on accounts.
  • Fig. 4 shows the structure of an account 92 in the SAXAS architecture.
  • An account is uniquely defined by the public key identities of a Holder 58, Owner 60, and Backer 62, and also contains an account balance 94 in the Backer's accounting unit. The same party can appear as one, two or three of the Holder, Owner or Backer parties. Balances can be negative as in double-entry bookkeeping systems.
  • the specific account diagrammed in Fig. 4 is interpreted as "Holder 50a owes Owner 50b the sum of 100 units of Backer 50c accounting units". Transferring a balance to a nonexistent account automatically creates a new account for the Owner, unless this feature is turned off by the Holder.
  • the architecture makes it easy for the Holder to charge a fee for maintaining account records and the Holder should charge enough to keep account records indefinitely.
  • Fig. 5 introduces the different types of accounts that can exist in the SAXAS architecture.
  • a positive balance indicates that the Holder owes the Owner the balance amount
  • a negative balance indicates that the Owner owes the Holder the absolute value of the balance.
  • the account balance indicates the total units owned by the Holder on his own behalf (this amount is zero or positive) .
  • account 92a has a positive balance and means that Holder 50a owes 100 units of 50c to owner 50b.
  • • account 92b has a negative balance and means that party 50b is owed 100 units of 50c by party 50a. When account 92a exists for party 50a, then account 92b always exists for party 50b. Account 92b is held by party 50b as a claim against party 50a. Notice that the same party can be both holder and owner in different accounts . • account 92c records the total units issued to holder 50a by backer 50c. Since the balance is negative, the holder has a claim against the owner, who is also the backer .
  • account 92d has the Holder and the Owner the same party and a positive balance; this means that party 50b has a total of 100 units of 50c that are held for it by one or more holders. Account 92b shows that the 100 units are actually held by party 50a.
  • An account resides on the server 96, Fig. 1, belonging to the party 50 who is the Holder specified in the account triplet. Therefore, in Fig. 5, accounts 92a and 92c reside on the server of party 50a, while accounts 92b and 92d reside on the server of party 50b.
  • Fig. 5 also shows how accounts can be balanced against each other, both on the same server and on different servers .
  • Account 92c balances against 92a i.e., the total 50c units issued to 50a is the sum of the units held for owners such as 50b) .
  • Fig. 6 shows the accounts that would be created to handle one backer, two holders, and three owners:
  • Accounts 92k-92m reside on the 50c server and record units backed by this party. Notice that accounts 921-
  • Accounts 92n-92p reside on the server of holder 50a and balance to zero.
  • Account 92n is the complement of account 921 on the backer server and records the 20 units received by this holder.
  • Accounts 92o-92p record what happened to those 20 units: 5 units are held for owner 50d and 15 units for 50e.
  • Accounts 92q-92s reside on the server of the second holder 50b and balance to zero.
  • Account 92q is the complement of account 92m on the backer server and records the 30 units received by this holder.
  • Account 92r-92s record what happened to those 30 units: 20 are held for owner 50d and 10 are held for owner 5Of . Notice that party 50d has units held by both holders.
  • Accounts 92t-92v reside on the server of owner 50d and balance to zero.
  • Account 92t records the 25 units total backed by 50c that belong to this owner.
  • Account 92u records that five of the units are held by holder 50a, and account 92v records that the other 20 are held by holder 50b. Notice that account 92v is the complement of 92r and balances it. And account 92u is the complement of 92o and balances it.
  • Accounts 92w-92x reside on the server of owner 50e and balance to zero.
  • Account 92w records the total units of 50c received by this owner and account 92x balances to account 92p on the holder server.
  • Accounts 92y-92z reside on the server of owner 50f and balance to zero. Account 92y records the total units of 50c received by this owner and account 92z shows that the units are held by holder 50b (see account 92s) .
  • Fig. 7 shows how accounts are balanced when a Holder 58 is also the Owner 60 of some accounting units.
  • backer 50c has issued 50 units to Holder 50a, of which 50a holds 10 for his own account and 40 for Owner 50b. This is represented by the following accounts:
  • Accounts 92a-92b reside on the server of backer 50c and balance to zero.
  • Account 92a records the total units that backer 50c has issued to all parties and account 92b records the units issued to Holder 50a. In this case they are the same, because only one holder is assumed. Otherwise, account 92a would balance to the sum total of the accounts recording units issued to any holder .
  • Accounts 92c-92e reside on the server of Holder 50a and balance to zero.
  • Account 92c records the total units that backer 50c has issued to the holder 50a, including both those held for owner 50b and those owned by the holder himself.
  • Account 92d records the units actually owned by the Holder 50a himself (the Holder party equals the Owner party) .
  • Account 92e records the units held on behalf of Owner 50b.
  • Accounts 92f-92g reside on the server of owner 50b and balance to zero. Account 92f records the total units backed by 50c that the owner 50b has at all holders (only one in this case) and account 92g records the units held for 50b at holder 92a.
  • Fig. 8 shows the structure of a value exchange contract 66.
  • all exchanges of value are enacted in response to signed contracts.
  • Each of the parties who appears as a source in the Clause section 82 must sign the top four sections (76, which comprises Header 78, Parties 80, Clauses 82, Agreement 84) of the contract in the fifth section (Signatures 86) .
  • the contracts are signed by the parties using their Identity (98, either public key 68 or digital certificate 74), Fig. 1, thus ensuring that everyone agrees to the same contract, then executed by the server.
  • Signatures do not oversign each other; parties sign only the signable portion of the contract 76 and the Memo, Sig-Time and Status specific to that party in the Signatures section. Only a party listed in the party section 80 of the contract is allowed to sign in the Signatures section 86, thus allowing verification of the signature using the public key.
  • the contract resides in the data storage of the SAXAS server, but can be generated in various formats for external use: display (HTML-format document (HyperText Markup
  • the format that is signed is a text version of the contract (not the HTML ) , which the software can display for user inspection and print for submission to a legal authority or arbitrator.
  • the Agreement 84 is empty except in an owner change contract (see Fig. 9b) .
  • the "When Contract Becomes Valid" field of the Header 78 is only relevant to backer change contracts (see Fig. 9c); other contracts are valid as soon as they are signed by all parties.
  • the "When Contract Expires" field is not relevant for holder change changes (see Fig. 9a) since they are complete as soon as execution starts.
  • Fig. 9 shows the three most common types of contracts in the architecture. There are different types of contracts with different restrictions on them in order to ensure that no account balances are ever lost or in an ambiguous state. Since an Account 92, Fig. 4, is defined by a triplet of Holder 58, Owner 60 and Backer 62, moving an amount from one account balance to another can be looked at as changing the associated Holder, Owner and/or Backer value.
  • Each contract specifies an Executor 64 in the Header section 78, Fig. 8. This party will also act as the Holder party 58 in all clauses except the destination account of Holder clauses 106.
  • Each contract regardless of type, may have an optional Fee Clause 90 that is the first clause in the Clause section 82.
  • the fee clause 64 extracts a fee for executing the contract. If it exists, it does an Owner Change on some amount of some accounting unit from that of the party paying the fee to that of the Executor.
  • the accounting unit of the Fee Clause need not be the same as the accounting unit used in the other clauses. Therefore, there can always be one extra Backer party to the contract if the Fee clause Backer differs from the others.
  • a contract will only modify one of the values on an account: Holder, Owner or Backer. It is theoretically possible to change more than one attribute of an account in a single contract (such as moving an amount to a new owner and changing the accounting unit at the same time) , but in such cases it is more difficult to ensure that the contract executes completely or is not executed at all (i.e., that no amounts are left in limbo). Therefore, the first embodiment of SAXAS does not support that feature, in order to ensure reliability and easy auditing of the system, although other embodiments may allow this (see Alternate Embodiments) .
  • Holder change contract 98 is like a wire transfer; it moves a balance from one Holder to another, perhaps to then take advantage of a conversion service offered by that Holder, but it does not change the Owner or the Backer (accounting unit) .
  • Either the source or destination Holder must be the Backer, so it takes two contracts to move from one non-Backer Holder to another non-Backer Holder.
  • the parties to the contract will be one Owner 60, the Backer 62 and one Party who is the source or destination Holder 58.
  • the executor 64 will be the party originally holding the amount, not the destination party.
  • the Agreement section 84 is empty.
  • the Signatures section 86 contains only the signature of the Owner, the Holder and the Backer.
  • Fig. 9b Owner change contract 100 is like a check or an invoice, depending upon the author. When an invoice is signed, it becomes a check. The amount stays on the same Holder's server and in the same accounting unit, but has a new owner. Parties to the contract include at most one Holder 58 and at least one Backer 62 and at least two Owners 60, but it is permissible to include unlimited owners and backers for unlimited owner clauses 108. Either all the clauses are executed or none.
  • the Agreement section 84 may contain one or more real world agreements that becomes part of the contract. The Agreement is open-ended and can contain multiple agreements and objects.
  • Any digital object can be included in the Agreement by converting it into ASCII-armored format using Radix 64 (expanding groups of 3 binary 8-bit bytes into 4 printable ASCII characters).
  • the Signature section 86 must contain the signatures of all owners who appear in a source account of any clause.
  • Backer change contract 102 is like a real world currency exchange .
  • the server matches up the request to change Backer with other contracts which go the opposite way and that have compatible prices .
  • the parties to the contract include exactly one holder 58, exactly two backers 62 and exactly one owner 60, although it is possible that a single party could play multiple roles in the contract.
  • the Agreement section 84 is empty.
  • the Signatures section 86 must contain the signature of the owner 60.
  • Fig. 10 shows a simple Owner Change Contract 100 in more detail.
  • the Owner change is the simplest and most common type of contract.
  • the Holder remains the same as does the Backer (i.e., the Accounting Unit).
  • the Backer i.e., the Accounting Unit.
  • the only clauses allowed in the Clause section are the Fee Clause 90 and the Owner Clauses 108.
  • the Fee Clause transfers 0.50 units of Backer 62 to the executor 58 in return for attempting to execute the signed contract.
  • the first owner clause transfers 20.00 units of unit 62 to owner 60b; the MinRate of 1.00 means that the entire amount must be transferred and none can be taken by the executor as a fee (for this contract, the fee is corrected by the 2.00 units in the Fee clause) .
  • the second owner clause is a zero-value clause, included so that the second owner 60b will appear as a debited account and will need to sign the contract before it is valid.
  • the second signature ensures that 60b agrees with the Agreement section that follows.
  • the Agreement section spells out what Owner 60b agrees to do for 60a in return for the 20 units of 62.
  • the Signature section must include signatures by 60a and 60b, since both appear as owners in the source portion of clauses .
  • Fig. 11 shows a more complex multi-party Owner change contract 100. Although there can only be one Holder/Executor in an Owner Change contract, the number of owners, backers and Owner clauses is unlimited. This makes it possible to create multi-party swaps. None of the owner clauses will be executed unless all of them are executed, i.e., if one party does not have enough units to complete their part in the exchange, none of the exchanges occur.
  • the three accounting units are called by the common names Lumberbucks, SoftFrancs and JackpotChips and the three owners are called Bill, Sam and June.
  • the contract says that Bill gives Sam 200 Lumberbucks, Sam gives June 500
  • the executor/holder 58 takes 2% of each transfer as a fee for holding the balances and executing the trade. All amounts must be moved to the Executor's server before the trade is initiated. And all three owners must sign the contract before it is executable.
  • Backer change 102 The differences are that in an explicit Backer change the Owner does not know who provides the other accounting units and may specify a limit price as opposed to a fixed price. So a two-party Owner change contract is like an off-market, non-anonymous block trade and the Backer change contract is like an automatic buy or sell order with a range of amounts and prices that are possible to complete the order .
  • Identity information about all the parties to the contract to all other parties to the contract could obtain the Identity information from web pages, email messages, floppy disks, or any other medium.
  • the method by which a party passes on Identity information to other parties is known as the SAXAS Name Service.
  • the SAXAS Name Service is implemented as Owner Change Contracts. Any party can and will act as a SAXAS Name Service at various times. The party needing the Identity information authors a contract requesting Name Service on a specific Public Key; these details are stored in the agreement section of the contract. The contract is sent to the Name Service party for execution. The Name Service inserts the desired Identity into the memo field and signs it. Any party can also pass their own Identity on to other parties by including it in their memo section of any contract and signing it.
  • Fig. 12 shows a Holder Change Contract 98 in more detail.
  • a fee clause is used to collect 1.15 units of 62 for performing the transfer.
  • the Backer is always the Executor of holder change contracts and always receives the fee, if any.
  • the Agreement section is empty.
  • the Signature section requires the signature of the Holder 58, Owner 60 and Backer 62.
  • Fig 13 shows a Holder change contract 98 that goes from the backer to a holder.
  • the Backer 62 is acting as the original Holder as well.
  • the amount is moved to the party 58 as the new Holder.
  • the Fee clause allows the executor, who is the backer in this case, to take up to 0.75 units and move it to the account described as 62-62-62 in HOB format (this is account 92k on Fig. 6, the same account that usually has a negative total for all the units issued by this backer. So in effect the backer is withdrawing some units from circulation by collecting this fee.
  • the holder clause transfers 400 units from the backer's server 62 to the server of party 58, making 58 the new holder.
  • This clause also allows the executor to take up to 0.2% of the amount as a fee.
  • a Holder to Holder change is executed as two contracts and uses the Backer as an intermediary, there is no information left on the original Holder as to the final destination of the amount. Only the Owner and the Backer know that the funds moved from Holder A to Holder B.
  • Fig. 14 shows the Backer Change Contract 102 in more detail.
  • the Fee clause is in a different accounting unit from either of the units involved in the Backer Clause itself. This is permissible under the SAXAS architecture.
  • the Backer clause 110 offers to give up 400 units backed by 60b in return for some units backed by 60c as long as the conversion MinRate is 0.552 or better.
  • the owner 60 will not be aware of who traded him the units .
  • the executor matches up this contract with complementary contracts that offer to go the other way and also match in price. The actual conversion rate will be based on the offers available and a fee charged by the executor for this clause.
  • SAXAS allows for a single conversion clause to remain open and be matched up with multiple complimentary conversion clauses created by other owners.
  • the clause will remain active and available for matching until the full amount offered for conversion has been converted, or the owner is found to have insufficient funds in his account, or the expiration date occurs.
  • the details of each partial conversion are stored in the executor's memo field of the contract, and re-signed by the executed after each partial conversion. See Fig. 18-21 for operational details .
  • Each SAXAS account is uniquely defined by an identity triplet: Holder, Owner and Backer. It is possible for each component of the triplet to be a different party, the same party, or a mixture of parties.
  • the Holder is the party where the account resides .
  • the Owner is the party who signs for the units and controls the account.
  • the Backer is the party who defines the accounting unit for the account and "backs it". Every party in the system has a SAXAS account server and thus has accounts where it is the "holder” , although these may exist only to balance with accounts that the party has with other parties .
  • Contracts all have an "Executor” that signs that a contract has been executed so that other parties to the contract know to update their books on notification.
  • the executor is the final authority, or "commit coordinator” .
  • owner change or backer change contracts it is the holder of the account.
  • holder change contracts it is the backer of the currency, or central bank for that currency.
  • the executor does not execute a contract unless all owners of accounts giving up something (and an owner change can have more than one) have signed. Also, in a holder change the holders have to sign. The holder where the units are going to has to agree to hold the units. The holder where the units are coming from has to agree that the owner really had that much.
  • Fig. 15 shows the same sample set of accounts as in Fig. 6, but in this case the element numbers have been replaced with friendly names to make the logic easier to follow.
  • the friendly name of the party backing the accounting unit is $-Backer
  • the names of the parties acting as holders are H- Bank and Union Bank
  • the names of the parties acting as Owners are Bob, Alice and Ted.
  • Each Party has some Accounts on their server and some accounts on other servers, as shown in Fig. 6. It is noted that any accounts residing on a party's server will have that party as the "Holder" of the account, even though that party is acting as an Owner in the overall SAXAS scheme.
  • Fig. 16 shows the execution of an owner change contract. See Fig. 10-11 for the structure of an owner change.
  • Processing is simplified because the owners must move all amounts to be swapped onto the Executor's server. No other servers are communicated with in the execution of a contract, although the server does send a notification copy of the completed contract to each party so that they can update their book keeping.
  • the optional fee clause is handled separately from the other owner change clauses. It is executed as soon as the executor receives a copy that is signed by the author and the fee payor, regardless of whether all the clauses of the contract turn out to be executable or not.
  • the executor verifies that any parties appearing as
  • This execution model means that you can exchange something in an Owner change that you do not own at the start of the execution, but acquire during execution of the clauses.
  • the Executor computes any percentage fees to be charged on each clause, but does not actually credit them until the end. Otherwise the Executor would have to lock the Executor's account for the entire execution time of the contract and this would make the process inherently single threaded, since the Executor is involved in every contract on the server.
  • the Executor attempts to send a notification copy of the contract as executed to each party. This may involve use of the SAXAS Name Information Service to discover where the parties are currently to be notified. Notification can be via email if a party is not currently online, or notification may be optional.
  • Fig. 17 shows execution of a Holder Change Contract See also Fig. 12-13 for the structure of Holder Changes.
  • a Holder Change Contract is like a wire transfer in the traditional world of financial transactions - an amount is moved from one Holder to another, but retains the same Owner and Accounting Unit (i.e. Backer) .
  • the receiving holder has to agree (sign) to hold the units before the contract is executed. This allows a holder control over whom it holds units for by automatically verifying that the party's Identity contains certain
  • a backer is like a central bank for clearing inter-holder transfers in his currency. And acting as the central bank for his currency, the backer is the executor for all holder changes in his currency.
  • the Holder Change contract allows the Owner to move value amounts from one Holder to another, but without changing the Accounting Unit (Backer) .
  • the contract is signed by the Owner, the Holder and the Backer, to ensure that the amount will not be rejected when it arrives at its destination.
  • the author will create two contracts, one to move the amount from the current holder to the backer and the second to move it on to the new holder. The reason for this is that it makes each contract atomic and unambiguous.
  • the owner can always verify where the funds are - they are never in limbo. If the funds get to the backer, but cannot be transferred to the new holder, they are still in the name of the owner on the backer's server and the owner can verify their status .
  • Contract 1 (Union, Bob, $) $5 -> ($,Bob,$)
  • Contract 2 ($,Bob,$) $5 -> (H-Bank, Bob, $ )
  • the executor also sends a notification copy to Union, the original holder. However, since it has already does the transfers in anticipation of this notification, it merely marks the contract as complete.
  • $-Backer sends notification copies of the signed contract to H-Bank and to the Owner Bob, so that there book entries can be updated as well.
  • transfers on each server are the transfers on each server:
  • the Backer Change Contract is a conversion of accounting units. The Owner and the Holder remain the same.
  • Fig. 18 shows execution of a Backer Change clause in a Backer Change Contract (see Fig. 14 for the structure) .
  • the fee clause is executed at once when the contract is recorded by the Executor. There may also be percentage fees extracted from each conversion.
  • the Executor can be any holder that makes a market. The conversion fees charged by that Executor are described in their identity record.
  • Each backer change clause of the contract is executed independently.
  • the Backer change contract as described statically in Fig. 15 appears to involve only the Holder and the Owner. In fact the Holder matches the contract with one or more reciprocal contracts by other Owners, contracts which offer the reverse conversion at a MinRate which allows matching of the contracts .
  • MinRate value is the minimum rate at which the conversion can occur.
  • MinRate the minimum rate at which the conversion can occur.
  • the actual rate at which it occurs is higher than MinRate, if the Executor can find a matching contract going the other way that allows for the Executor's fee. Partial conversion is supported, as well as conversions by matching multiple reciprocal contracts.
  • the contract After the initial execution, if there is any amount left to be converted, the contract goes into the outstanding offers list. If the contract is matched with a new incoming contract before it expires, it receives exactly the MinRate.
  • the Backer Change Contract cannot be shown using Fig. 15, since Fig. 15 only shows one Backer for all amounts. Therefore, go back to the initial state of Fig. 15 and assume a new party Y acting as Backer for a new accounting unit, CyberYen.
  • Y authorizes Union Bank to hold accounts backed by Y and Union Bank offers a service converting Y units into $ units and vice versa, all performed by the SAXAS server. If Owner Ted wants to convert $5 from his Union Bank account into Y at a minimum rate of 100Y per $, this can be notated as a Backer Change Offer in SAXAS:
  • Fig. 19a shows an example of two reciprocal backer change clauses that will be matched and executed. Below are two contracts that can be matched up and executed, if the fee is zero. Assume Holder A, Owners B and C, Backers D and E:
  • Fig. 19b shows a different situation where there is a spread between the bid and offer.
  • Fig. 19b example is the same as Fig. 19a, except that owner B has lowered his price. He will part with 100 D units for 48 E units instead of 50 E. Since owner C will give up 50 E units for 100 D, there are 2.0 units of E left over, from which the executor can extract his fee.
  • Fig. 20-21 shows waiting bids and offers and how they are matched with a new, incoming contract. Note that none of the existing Backer change clauses can be matched because the sellers are asking more than the buyers are willing to pay. So the clauses wait on the Holder's server for a new Backer change clause to appear.
  • the new offer to sell 60 units of D at a MinRate of 4.25 E per D can be matched with the two best offers to sell D for E.
  • the best waiting offer is to sell 50E at 4.40 E per D, which equals 11.37D, plus a 1% commission of 0.1137D, gives a price of 11.4837D.
  • the second best waiting offer is to sell 137E at 4.30 E per D, which matches the amount remaining on the new contract. Therefore this order is matched as well, generating a price of 31.86D plus a 1% commission of 0.3186D, which equals 32.1786D.
  • the outstanding balance goes into the list of buy and sell orders as the best unmatched sell offer. It will be matched with the first new contract that comes in and offers 4.25. The new contract gets the benefit of the best price. The old contracts that are waiting on the server for further matches will always get their MinRate and no better, but they don't have to pay any fees. The new contract effectively pays the Executor's fee if there is one.
  • Fig. 21 shows the resulting buy and sell orders after the new contract is processed. Notice the two offers to sell E for D are gone and new offer to sell D for E has been added.
  • a clause in a SAXAS contract changes only one element of the Identity triplet defining an account: either the holder, the owner, or the backer. This simplifies the design and the implementation and makes it less likely that any units will ever be lost. It is also desirable to change two of the elements in a single clause.
  • SAXAS user interface can allow an owner to transfer an amount from any currency, any place, to any other owner in any other currency at any other place, using the contracts in the preferred embodiment.
  • the holder change can be performed in a single contract instead of two contracts (holder to backer and backer to holder) .
  • the logic is similar to the two contract method, but occurs as a single logical step:
  • the Backer is the executor of Holder Change contracts, because the Backer is the only one who can give any assurance that the holder still has the amount that is being transferred. Actually, the Backer can only verify that the holder has at least the amount in the contract in total funds; the Backer cannot verify that the holder has not done something amiss with other amounts .
  • JDBC Java Database Connectivity
  • Alternate Packaging The preferred embodiment of this invention is a standalone program that performs its own communication and display, but it could also be embodied as a browser plug in. Alternate Computing Devices
  • the preferred embodiment of this invention is an Intel- Microsoft personal computer, but the invention can be easily implemented on a wide range of computing platforms, including but not limited to UNIX, IBM AS/400, Hewlett- Packard MPE/iX, DEC VAX, and IBM mainframe.
  • a database is not needed; only a way to store and recall contracts.
  • a network connection is not needed, only a way to send a contract from one party to another. The contract could even be printed, mailed, scanned, converted back to characters by optical character recognition, and it would still be valid.
  • a computer is not strictly needed, only an algorithmic device that can parse the contract, compute the mathematical signatures, and send the contract on in some fashion. Given advances in various technologies, this could be a specialized piece of hardware or a genetically engineered biological entity.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Finance (AREA)
  • Data Mining & Analysis (AREA)
  • Computer Security & Cryptography (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

Architecture sécurisée permettant d'échanger des valeurs entre parties (58, 60, 62), de façon que lesdites parties puissent être très éloignées géographiquement et utiliser une grande diversité d'unités de compte. L'architecture comprend un contrat formalisé conformément à la loi, présenté sous un format spécial; une clé publique identifiant chaque partie; un ordinateur pour chaque partie (54); un programme (56) logiciel pour chaque partie, capable de créer, valider, signer, stocker, coder, transmettre et exécuter des contrats; une technique permettant aux ordinateurs de communiquer; et une base de données (52) pour chaque partie, destinée à conserver les contrats et les informations (98) d'identité de chaque partie.
PCT/US1999/025853 1998-11-05 1999-11-03 Architecture securisee permettant l'execution d'echanges de contrats a signature numerique Ceased WO2000028452A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU19079/00A AU1907900A (en) 1998-11-05 1999-11-03 Secure architecture for exchange executes digitally signed contracts

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US10726198P 1998-11-05 1998-11-05
US60/107,261 1998-11-05
US29229199A 1999-04-15 1999-04-15
US09/292,291 1999-04-15

Publications (1)

Publication Number Publication Date
WO2000028452A1 true WO2000028452A1 (fr) 2000-05-18

Family

ID=26804587

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US1999/025853 Ceased WO2000028452A1 (fr) 1998-11-05 1999-11-03 Architecture securisee permettant l'execution d'echanges de contrats a signature numerique

Country Status (2)

Country Link
AU (1) AU1907900A (fr)
WO (1) WO2000028452A1 (fr)

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001091025A1 (fr) * 2000-05-25 2001-11-29 Thirdphase Limited Procede et systeme de collecte et de verification de donnees issues de plusieurs sites
EP1209579A1 (fr) * 2000-11-21 2002-05-29 DR. Riccardo Genghini Studio Notarile Genghini Système pour le déroulement automatique de transactions par gestion active d'identité
WO2002052832A3 (fr) * 2000-12-22 2002-11-14 Siemens Ag Procede pour la facturation souple de services et de ressources dans des reseaux
WO2002039401A3 (fr) * 2000-11-13 2004-02-26 Currenex Inc Utilisation de signatures numeriques pour valider la negociation et le reglement accelere de flux de transactions financieres
JPWO2002044966A1 (ja) * 2000-11-30 2004-04-02 株式会社東芝 ポイントを用いた取引方法及び取引装置
US6970836B1 (en) * 1998-04-14 2005-11-29 Citicorp Development Center, Inc. System and method for securely storing electronic data
EP1316168A4 (fr) * 2000-08-04 2006-05-10 First Data Corp Procede et systeme d'utilisation de communications electroniques pour un contrat electronique
US7065509B2 (en) 2003-05-09 2006-06-20 International Business Machines Corporation Method, system and computer program product for protection of identity information in electronic transactions using attribute certificates
US7206758B2 (en) 2003-11-12 2007-04-17 International Business Machines Corporation Method, system and computer program product for identifying and implementing collected privacy policies as aggregate privacy policies in electronic transactions
US7272572B1 (en) * 2000-03-20 2007-09-18 Innovaport Llc Method and system for facilitating the transfer of intellectual property
US8260673B2 (en) 2003-05-09 2012-09-04 International Business Machines Corporation Method, system and computer program product for selective data disclosure and contract negotiation in an E-marketplace based on predetermined preferences
CN113177395A (zh) * 2021-04-23 2021-07-27 深圳市乘法信息技术有限公司 电子合同平台在线签章方法、系统及电子设备

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5870473A (en) * 1995-12-14 1999-02-09 Cybercash, Inc. Electronic transfer system and method

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5826241A (en) * 1994-09-16 1998-10-20 First Virtual Holdings Incorporated Computerized system for making payments and authenticating transactions over the internet
US5757917A (en) * 1995-11-01 1998-05-26 First Virtual Holdings Incorporated Computerized payment system for purchasing goods and services on the internet
US5870473A (en) * 1995-12-14 1999-02-09 Cybercash, Inc. Electronic transfer system and method

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6970836B1 (en) * 1998-04-14 2005-11-29 Citicorp Development Center, Inc. System and method for securely storing electronic data
US7272572B1 (en) * 2000-03-20 2007-09-18 Innovaport Llc Method and system for facilitating the transfer of intellectual property
US8554636B1 (en) 2000-03-20 2013-10-08 Patent Cloud Llc Method and system for facilitating the transfer of intellectual property
US8700476B1 (en) 2000-03-20 2014-04-15 Patent Cloud Llc Method and system for facilitating the transfer of intellectual property
GB2378369A (en) * 2000-05-25 2003-02-05 Thirdphase Ltd Method and system for collection and verification of data from plural sites
GB2378369B (en) * 2000-05-25 2004-03-10 Thirdphase Ltd Method and system for collection and verification of data from plural sites
WO2001091025A1 (fr) * 2000-05-25 2001-11-29 Thirdphase Limited Procede et systeme de collecte et de verification de donnees issues de plusieurs sites
EP1316168A4 (fr) * 2000-08-04 2006-05-10 First Data Corp Procede et systeme d'utilisation de communications electroniques pour un contrat electronique
WO2002039401A3 (fr) * 2000-11-13 2004-02-26 Currenex Inc Utilisation de signatures numeriques pour valider la negociation et le reglement accelere de flux de transactions financieres
US6807635B1 (en) 2000-11-13 2004-10-19 Currenex, Inc. Using digital signatures to validate trading and streamline settlement of financial transaction workflow
EP1209579A1 (fr) * 2000-11-21 2002-05-29 DR. Riccardo Genghini Studio Notarile Genghini Système pour le déroulement automatique de transactions par gestion active d'identité
JPWO2002044966A1 (ja) * 2000-11-30 2004-04-02 株式会社東芝 ポイントを用いた取引方法及び取引装置
WO2002052832A3 (fr) * 2000-12-22 2002-11-14 Siemens Ag Procede pour la facturation souple de services et de ressources dans des reseaux
US7065509B2 (en) 2003-05-09 2006-06-20 International Business Machines Corporation Method, system and computer program product for protection of identity information in electronic transactions using attribute certificates
US8260673B2 (en) 2003-05-09 2012-09-04 International Business Machines Corporation Method, system and computer program product for selective data disclosure and contract negotiation in an E-marketplace based on predetermined preferences
US7206758B2 (en) 2003-11-12 2007-04-17 International Business Machines Corporation Method, system and computer program product for identifying and implementing collected privacy policies as aggregate privacy policies in electronic transactions
CN113177395A (zh) * 2021-04-23 2021-07-27 深圳市乘法信息技术有限公司 电子合同平台在线签章方法、系统及电子设备

Also Published As

Publication number Publication date
AU1907900A (en) 2000-05-29

Similar Documents

Publication Publication Date Title
US6609200B2 (en) Method and system for processing electronic documents
US6236972B1 (en) Method and apparatus for facilitating transactions on a commercial network system
US7734527B2 (en) Method and apparatus for making secure electronic payments
US7177830B2 (en) On-line payment system
US5677955A (en) Electronic funds transfer instruments
US5884288A (en) Method and system for electronic bill payment
US8645266B2 (en) Universal merchant platform for payment authentication
US20030208406A1 (en) Method and apparatus for processing one or more value bearing instruments
WO1996031965A9 (fr) Instruments electroniques de transfert de fonds
WO1998026364A9 (fr) Procede et systeme de paiement electronique de factures
WO2006023599A2 (fr) Procede destine a fournir de l'argent liquide et un equivalent d'argent liquide pour des transactions electroniques
CN112767185B (zh) 一种基于区块链的反向保理融资方法、设备及存储介质
CN1425164A (zh) 多对多的对应:用于替代银行间转帐的方法和系统
WO2001080100A1 (fr) Systeme de paiement pour commerce electronique
WO2000028452A1 (fr) Architecture securisee permettant l'execution d'echanges de contrats a signature numerique
US8249921B2 (en) Method for facilitating a transaction between buyers and sellers
WO2002015088A1 (fr) Systeme et procede de compensation repartie de paiements electroniques
AU4060502A (en) Method and system for processing electronic documents
JP2003256651A (ja) 申請データの認証サービス方法
KR102817815B1 (ko) 블록체인 기반으로 발행된 결제 매개 수단을 이용한 결제 방법
CA2380479A1 (fr) Systeme et dispositif pour coordonner et faciliter des transactions commerciales
CA2328807C (fr) Methode et systeme de transmission de donnees protegees
Sivaradje et al. The Characteristics of Electronic Payment Schemes—Prospects for the Future
AU3819202A (en) Method and system for processing electronic documents
Sharma An evaluation of e-payment systems and their application in mobile commerce.

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

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

AL Designated countries for regional patents

Kind code of ref document: A1

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

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)
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase