US20060036530A1 - Method and apparatus for facilitating micro energy derivatives transactions on a network system - Google Patents

Method and apparatus for facilitating micro energy derivatives transactions on a network system Download PDF

Info

Publication number
US20060036530A1
US20060036530A1 US10/915,048 US91504804A US2006036530A1 US 20060036530 A1 US20060036530 A1 US 20060036530A1 US 91504804 A US91504804 A US 91504804A US 2006036530 A1 US2006036530 A1 US 2006036530A1
Authority
US
United States
Prior art keywords
buyer
seller
redemption
contract
order
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.)
Abandoned
Application number
US10/915,048
Inventor
Gary Shkedy
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.)
Individual
Original Assignee
Individual
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 Individual filed Critical Individual
Priority to US10/915,048 priority Critical patent/US20060036530A1/en
Publication of US20060036530A1 publication Critical patent/US20060036530A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00Commerce
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/38Payment protocols; Details thereof
    • G06Q20/382Payment protocols; Details thereof insuring higher security of transaction
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/04Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange

Definitions

  • the present invention relates to a method and an apparatus for facilitating transactions on an electronic commercial network system and specifically to a method and system for facilitating the issuance and redemption of micro energy derivative contracts.
  • Energy derivative contracts e.g., options, futures contracts, Asian options, lookback options to name a few—hereafter generally referred to as “derivatives”
  • derivatives are normally traded on the financial exchanges or over the counter by major brokerage firms and are useful for managing the risks associated with the buying and selling of energy products.
  • derivatives are available for all the major energy products, and specifically for: light sweet crude, natural gas, heating oil, unleaded gasoline, propane and electricity.
  • the typical contract sizes for energy derivative contracts are very large, for example, 42,000 gallons of unleaded gasoline, 1000 US barrels of light sweet crude oil or 4000 million BTU for the “mini” natural gas contract.
  • the target markets for these products are the corporation in the energy business such as refineries, oil producers, institutional or professional energy consumers.
  • the major airlines frequently make use of derivatives to manage the cost of aviation fuels.
  • the owner of a small taxi fleet is unable to lock in the price of his gasoline, and so his profits become very volatile as the price of gasoline fluctuates.
  • micro derivative contracts on energy products would be of enormous value to these consumers, but they do not exist in the current marketplaces.
  • a micro derivative contract can be an unleaded gasoline contract for about 50 to 100 gallons, which is the typical monthly gasoline usage of a typical individual consumer.
  • One of the major obstacles to micro derivative contracts is the trading costs associated with the buying and selling of derivative contracts. For example, at current prices, it costs about $12 to trade a single option contract with the cheapest broker in the USA. Other brokers charge as much as $50 to trade a single contract. Assuming that a three-month micro option on gasoline could cost $2 in premium and a one-month micro option contract may cost $0.50, even the cheapest $12 transaction cost would stifle any attempt to trade micro derivatives.
  • Another major barrier for development of derivative fuel contracts in the present marketplace is that the contracts on the major exchanges are for delivery of the energy product at a specific location, e.g., the unleaded gasoline contract is for delivery in the New York harbor. This makes it useless for a consumer in the Californian market who only uses 50 gallons a month on an average.
  • Micro derivative contracts could be structured so that the delivery of the underlying energy commodity could be in any specific geographic location, such as within any given zip code or at any particular gas station desired by the consumer. Hence, there is a need for such delivery point independent micro derivative contract and a trading system for such contracts.
  • micro-derivative contracts can be used as a loyalty reward for consumers of a particular brand of energy.
  • a retail gasoline company could offer the contracts to its customers provided that they redeem the contract at a participating gas station affiliated with that particular retail gasoline company. This would help ensure customer loyalty and could be constructed in such a way that the seller pays the premium. Therefore, there is a need for a micro derivative contract system that can be readily utilized as a loyalty reward system or be linked to an existing reward system.
  • a system and method for using a POS device and a computer to facilitate a transaction between a buyer and a seller includes a customer submitting an order to the central controller.
  • the central controller authorizes the contract that is issued to the buyer. If the buyer is redeeming the contract then the customer submits the details of the contract to the central controller; the central controller authenticates the contract; and the central controller issues authorization for sale of the energy commodity at the contract price.
  • a system and method provides individuals with the ability to buy and redeem micro derivative contracts on energy products, thereby effectively locking in the prevailing market price by buying price protection insurance.
  • the individual energy consumers are forced to bear market risk and pay higher prices when these products are in short supply. Therefore, it is one aspect of the present invention to provide a method and a system for facilitating the issuance and redemption of micro energy derivative contracts.
  • An aspect of the present invention is to allow the buyer to pay for the contract using cash. Another aspect of the present invention is to allow the buyer to pay for the contract using a credit card. An aspect of the present invention for the buyer is to buy the contract on credit and have the system communicate with the seller's accounting system. Another aspect of the present invention is to allow the buyer to pay a premium for his current usage of energy, where that premium is then used to automatically purchase a derivative contract. It is yet another aspect of the present invention to allow buyers to redeem the contracts for cash.
  • the buyer can redeem a previously purchased micro derivative contract by receiving the energy product at a future date. Alternately, the buyer can assign the contract to another buyer or any other third party. Further, the buyer can redeem the micro derivative energy contract for cash.
  • the buyer redeems the contract by purchasing the underlying physical energy product for the price agreed in the contract.
  • Another aspect of the invention allows the buyer to prepay for the underlying physical energy product that the buyer will later collect as part of the redemption process.
  • FIG. 1 illustrates a block diagram of an embodiment of the present invention
  • FIG. 2 is a block diagram showing an exemplary central controller in an embodiment of the present invention
  • FIG. 3 illustrates an exemplary flow of an issue transaction
  • FIG. 4A is a block diagram showing an embodiment of the buyer interface
  • FIG. 5 illustrates an embodiment showing how a buyer order is generated
  • FIG. 6 illustrates an embodiment showing the acceptance of a buyer order and credit card payment by the central controller
  • FIG. 7 illustrates an embodiment showing how a buyer redemption order is generated
  • FIG. 8 illustrates an embodiment showing the acceptance of a buyer redemption order and payment authorization by the central controller
  • FIG. 9 illustrates an embodiment showing the use of a certificate authority and a settlement server.
  • micro derivative contract as used here in context of energy and fuel related contracts indicates that the contract are of a type suitable to either individual or a small number of consumers. For example, one feature of such contract can be that it deals with an energy purchase of a relatively smaller value. Another could be a small amount of quantity of the fuel to be purchased under the contract. Another feature could be that the fuel would be available at the buyers location under the contract. Those skilled in the art will appreciate that many more such features can be used to define such micro contracts and the above listed examples are only given for illustration.
  • micro derivative contracts that are typically large quantity, high value and destination specific.
  • Such micro derivative contracts would typically be bought by relatively small consumers.
  • such small consumers can be individual consumers, groups of such consumers, non-profit entities and relatively small and medium size commercial organizations.
  • At least one aspect of the present invention provides a trading system for buyers wishing to buy contracts and redeem their contracts.
  • the illustrative method and system according to the present invention provides the seller with a system for managing the issuance and redemption of derivative contracts that achieves a cost saving for both buyers and issuers.
  • At least one aspect of the illustrative method and system the present invention effectuates performance of resulting orders and redemptions, and authentication.
  • One aspect of the present invention is a viable facility for transacting micro derivative contracts and the ability to issue and redeem derivative contracts at a Point Of Service (POS) device. This is achieved by using the same magnetic cards that are used, for example, as department store gift cards or POS authorized prepaid phone cards.
  • POS Point Of Service
  • a POS system for gasoline stations is described in U.S. Pat. No. 4,395,626. The POS system could either be used by the buyer themselves or by a sales agent assisting the buyer.
  • a system that can also utilize physical tokens that interact with POS device as a method of authenticating the buyer will be more likely to attract the attention of potential buyers, because they offer an ease of use normally associated with credit accounts.
  • These tokens could be smart cards or a transponder similar to the smartcards that need only to be waived before a terminal to complete payment for a transaction.
  • An example of a transponder payment system is disclosed in U.S. Pat. No. 6,073,840.
  • FIG. 1 in a preferred embodiment, an electronic network including a central controller 200 is shown.
  • the network facilitates communications between a plurality of buyers using a plurality of POS devices and a seller (i.e., central controller 200 ).
  • FIG. 1 illustrates a plurality of POS devices coupled to one central controller 200 in a variety of manners.
  • POS devices 400 are electronically connected to the central controller via Ethernet connections.
  • Wireless POS devices 401 connect to the central controller via a wireless router that is electronically linked to central controller 200 .
  • POS device 402 connects to central controller with POS modems 408 .
  • Each of the plurality of buyers who wish to make purchases independently accesses the central controller 200 to create purchase orders using any of the POS devices.
  • POS system examples include the “G-SITE” system from Gilbarco Inc. which is a retail POS for the gasoline industry.
  • RELPOS 80 Another POS system is the “REALPOS 80” from National Cash Register.
  • An example of a wireless POS could be a HP IPAQ 555, which is a Bluetooth enabled PDA (Personal Digital Assistant).
  • the wireless router can be a Linksys BEFW11S4 or any other wireless router.
  • the central controller 200 is preferably located at a remote server.
  • FIG. 3 illustrates the steps associated with the creation and inclusion of an order 100 into the order database 270 .
  • a buyer 16 selects the particular contract he wishes to purchase. This most probably will be a buyer selecting a magnetic card from a display stand.
  • the buyer swipes the magnetic card through the card reader at the POS system. Again it may be a sales clerk that does the actual swiping of the card.
  • the buyer submits the contract to the central controller 200 for issuance.
  • a typical buyer created order, order 100 could, for example, specify that the buyer wishes to purchase a Mar. 31, 2005 option to buy unleaded gasoline at $1.95. This would be equivalent to purchasing an insurance policy that guaranteed the buyer could purchase 20 gallons on unleaded gasoline for $1.95 at any time up to Mar. 31, 2005 irrespective of what the prevailing market price happened to be.
  • the central controller 200 assigns a unique tracking number to the order 100 , timestamps it and adds it to the order database.
  • the central controller 200 may require that the buyer 16 has sufficient credit in his account to cover the purchase price of the specified product.
  • the central controller 200 transmits an acknowledgement to the buyer. Instead of an acknowledgement code, the central controller could send an authorization code to the POS to authorize the order 100 . Once s a buyer is authenticated and found to be credit worthy, the central controller would complete step 38 .
  • the central controller 200 determines if it is a valid contract. If it is not, then at step 45 , the central controller 200 notifies the buyer that the contract is invalid and the process terminates. If it is a valid contract, then at step 46 the central controller 200 assigns a unique tracking number to the redemption order 160 and stores it in the redemption database 280 .
  • the central controller 200 calculates the redemption value of the contract and at step 48 the central controller 200 authorizes sale of the underlying commodity to the buyer at the contract price.
  • communications between the various parties may be transmitted via numerous means including a worldwide-web interface, personal digital assistant (PDA), web enabled cellular phones, POS systems, electronic mail, voice mail, facsimile, or postal mail.
  • PDA personal digital assistant
  • POS systems electronic mail
  • voice mail facsimile
  • postal mail postal mail
  • At least one embodiment of the present invention can also be practiced in an off-line environment.
  • buyer 16 s may communicate with the central controller 200 via telephone, facsimile, postal mail, or another off-line communication tool.
  • buyers may use telephones to create the orders 100 (with or without the assistance of live agents) as well as create redemptions 150 with the use of telephones.
  • FIG. 1 may use cryptographic protocols to authenticate the identity of buyer 16 s and verify the integrity of buyer 16 's communications with the central controller 200 . This would be useful in embodiments where the purchase of derivative contracts is made against the credit account of a buyer.
  • the use of cryptography, smart cards and biometrics can make it significantly more difficult for unauthorized persons to tamper with the system by passing themselves off as legitimate buyer 16 s or eavesdropping on system communications.
  • the buyer 16 could receive their selected contract in the form of a physical token 19 .
  • a token could be a plastic card with a magnetic strip (similar to a credit card), a smart card with an embedded chip, or a transponder similar to a SPEEDPASS from Mobil.
  • Other tokens not explicitly enumerated herein are also within the scope of the invention.
  • buyer 16 could present the physical token 19 to a POS system to redeem their contract. The final payment the buyer would then make at the POS would depend on the redemption value of the contract.
  • Other embodiments may have the seller make use of selling agents who authorize and authenticate contracts through the use of seller interface 300 .
  • such an interface could be a credit card terminal that would authorize energy cards and then validate them at the time of redemption.
  • One embodiment of the present invention divides the functionality of the central controller 200 into three components and embodies them in three separate servers: an operations server, a certificate authority, and a settlement server.
  • the certificate authority authenticates the identity of buyer 16 s while the settlement server verifies their ability to pay or deliver contracts.
  • the operations server posts orders 100 relying upon messages from the other two servers for validation. This configuration allows for greater specialization of the servers.
  • the present invention provides a method and apparatus to issue and redeem micro derivative contracts in energy products.
  • central controller 200 includes central processor (CPU) 205 , cryptographic processor 210 , RAM 215 , ROM 220 , payment processor 230 , clock 235 , operating system 240 , network interface 245 , and data storage device 250 .
  • a conventional personal computer or computer workstation with sufficient memory and processing capability may be used as central controller 200 .
  • Central controller 200 operates as a web server, both receiving orders 100 and processing redemption orders 120 ,
  • Central controller 200 must be capable of high volume transaction processing, performing a significant number of mathematical calculations in processing communications and database searches.
  • a microprocessor for example, an ITANIUM 2.1 GHz, commonly manufactured by Intel Inc., may he used for CPU 205 .
  • This processor employs a 128-bit architecture.
  • Equivalent processors include the IBM's POWERPC 970 64 bit processor or Sun Microsystem's ULTRASPARC-III CU.
  • An MPC180 security processor commonly manufactured by Motorola Inc. may be used for cryptographic processor 210 . Suitable equivalent processors may also be used without limiting the invention in any manner.
  • This 66 MHz micro-controller has a RSA signature time of 32 ms supporting 10 IKE handshakes per second.
  • Cryptographic processor 210 supports the authentication of communications from buyers and sellers, as well as allowing for anonymous transactions. Ideally, cryptographic processor 210 may also be configured as part of CPU 205 .
  • Other commercially available specialized cryptographic processors include Phillip's 40 MHz VMS113.
  • Customer database 255 maintains data on customers with fields such as account type, name, address, telephone number, ID number, electronic mail address, smart card ID, public/private key information, etc. This information is obtained when the customer first registers with the system, or immediately prior to posting his first order 100 . Different information may be required for different account types e.g. individual accounts would require credit card information, etc.
  • Product database 260 maintains data on all the underlying energy products with fields such as product ID, product description, product availability, product provider, and where applicable a geographic area where the product is available. This database is a catalog of all the underlying products on which the derivative contracts are written.
  • Security master database 265 maintains data on all the specific derivative contracts that can be purchased. It has fields such as security ID, contract type, expiration, strike if applicable, product ID, etc.
  • the security master database 265 is the catalog of derivative contracts that can be traded.
  • Order database 270 tracks all the order 100 s with fields such as status, tracking number, date, time, security ID, customer ID and quantity.
  • Transaction database 275 tracks the payment information regarding the order. Fields include customer name, customer ID number, order tracking number, type of payment, amount and associated credit card authorization number.
  • Redemption database 280 tracks all payments made to the buyers and contract details with fields such as customer ID number, amount of payment, and associated order tracking number.
  • Cryptographic key database 285 facilitates cryptographic functions, storing both symmetric and asymmetric keys. These keys are used by cryptographic processor 210 for encrypting and decrypting orders 100 .
  • Audit database 290 stores transactional information relating to the purchase of orders 100 and the redemption of redemption orders 160 .
  • Seller Account Database 295 tracks all payments made to and by the seller. This account may be a pointer to account data stored at the seller's bank.
  • Buyer account 296 tracks all information pertaining to the customer's account with fields such as customer ID, bank account numbers, and debit or credit transactions. This account may be a pointer to account data stored at the customer's bank.
  • Microsoft's EXCHANGE SERVER 5.5 is a secure server-based electronic mail software package designed to link people and information over enterprise networks and the Internet.
  • the product utilizes open standards based on Internet protocols. Users can exchange messages with enclosures such as files, graphics, video and audio.
  • network interface 245 may be configured as a voice mail interface, web site, BBS, or electronic mail address, etc.
  • central controller 200 is configured in a distributed architecture, wherein the databases and processors are housed in separate units or locations. Some controllers perform the primary processing functions and contain at a minimum RAM, ROM, and a general processor. Each of these controllers is attached to a Wide Area Network (WAN) hub, which serves as the primary communication link with the other controllers and interface devices.
  • WAN Wide Area Network
  • the WAN hub may have minimal processing capability itself, serving primarily as a communications router.
  • the certificate authority embodiment provides more details of such a distributed environment describing operations server 164 , certificate authority 165 , and settlement server 170 .
  • the hardware of these servers would be configured similarly to that described for central controller 200 .
  • communications between buyers and the seller take place via electronic or wireless networks, with central controller 200 acting as a web-server.
  • the buyer logs on to central controller 200 , selects the energy product he or she is interested in, selects the derivative contract he or she wishes to purchase, examines the current market prices given by central controller 200 , adds a quantity specifier and thereby creates order 100 , and then disconnects from the network.
  • the buyer logs onto central controller 200 and submits a redemption request by supplying the details of the purchased contract.
  • the central controller 200 authenticates the contract and then if it is valid calculates the redemption value of the contract.
  • Central controller 200 then authorizes payment to the buyer.
  • Modem 450 may not require high-speed data transfer if most buyer orders 100 produced are text-based and not too long. If a cryptographic processor is required, the MPC180 micro-controller described above is used. The structure of biometric device 455 and smart card reader 465 will be described below in conjunction with the cryptographic authentication embodiment.
  • Data storage device 460 is a conventional magnetic-based hard disk storage unit such as those manufactured by Conner Peripherals or Maxtor.
  • Message database 470 may be used for archiving buyer orders 100
  • audit database 480 may be used for recording payment records and communications with the central controller 200 .
  • EUDORA PRO manufactured by Qualcomm, Incorporated, for example, provides editing tools for the creation of messages as well as the communications tools to route the message to the appropriate electronic address.
  • EUDORA PRO manufactured by Qualcomm, Incorporated, for example, provides editing tools for the creation of messages as well as the communications tools to route the message to the appropriate electronic address.
  • the central controller 200 is configured as a web-server, conventional communications software such as a web browser may also be used. The buyer may use these browsers to transmit order 100 . No proprietary software is required.
  • step 500 the buyer logs on to central controller 200 using buyer modem 450 of buyer interface 300 , establishing a communication link.
  • buyer modem 450 of buyer interface 300 establishing a communication link.
  • central controller 200 has a page or website on the World Wide Web, allowing the buyer to provide information through the interface of a conventional web browser software.
  • the buyer selects the energy product he wants to purchase by selecting from a list of possible energy products.
  • products might include electricity or unleaded gasoline, etc.
  • the buyer selects a derivative contract on the product. As shown in box 512 , this might be a Dec. 31 2004 option to buy unleaded gasoline at $1.95 a gallon, etc.
  • a form is displayed on video monitor 430 of buyer interface 300 (Note steps 505 and 510 could also be accomplished in the same way). This form is an electronic contract with a table of the current market price for the specific contract and selection fields and/or a number of blanks to be filled out by the buyer. Note that steps 505 and 510 could also be accomplished by using a selection box.
  • the buyer adds the quantity he requires.
  • the buyer attaches his name and credit card information or a unique user ID number to order 100 .
  • This ID number is received from central controller 200 when the customer registers for the service, or is chosen by the customer and then registered with central controller 200 by phone.
  • Central controller 200 maintains a database of customer ID numbers in customer database 255 , and issues (or allows) only unique numbers. If less security is required, the user's telephone number or social security number could serve as the ID number since it has the advantages of being both unique and easily remembered. However, since credit card information is being stored, customers may be more comfortable with a more secure version. If additional security is required, those procedures described in the cryptographic embodiment may be implemented.
  • the buyer transmits them to central controller 200 at step 560 .
  • the buyer does this by clicking on a “send” button located on the screen in which he entered the terms of order 100 .
  • the buyer has placed an order for a derivative contract and proceeds to the payment method as described in FIG. 6 .
  • buyers may also transmit order 100 data via other means including electronic mail, PDAs, Electronic Data Interchange (EDI), voice mail, facsimile, or postal mail transmissions.
  • voice mail the buyer calls central controller 200 and leaves order 100 in audio form.
  • These orders 100 may be transcribed into digital text at central controller 200 , or maintained in multiple formats.
  • Central controller 200 supports a plurality of transmission methods, allowing for a wide variety of formats of order 100 s.
  • Orders transmitted by mail in paper form may be scanned-in and digitized, using optical character recognition software to create digital text and then used to create orders 100 . These embodiments are more fully described in the off-line embodiment described later.
  • central controller 200 Once central controller 200 has received the authorization it accepts the buyer order at step 630 .
  • a unique tacking number is added to the order 100 .
  • the central controller 200 timestamps order 100 at step 650 and stores order 100 in the order database 270 at step 660 .
  • Order database 270 contains a record for the order 100 .
  • the record contains fields such as status, tracking number, timestamp, security ID, quantity and customer ID.
  • the status field has values of “pending,” “complete,” “redeemed” and “cancelled.”
  • a status of “pending”, means that the order cannot currently be transacted. Either, central controller 100 is still processing it, or the buyer has temporarily suspended it.
  • a “complete” order 100 is one that has been sold.
  • a “redeemed” order is one that has been redeemed by the customer or has expired worthless.
  • An “cancelled” order 100 can no longer be used.
  • a process by which a buyer creates a redemption order is described.
  • the buyer logs on to central controller 200 using buyer modem 450 of buyer interface 300 , establishing a communication link.
  • This process is a mirror image of the process described above in the buyer selection process of FIG. 5 .
  • the buyer provides his or her unique ID as described in FIG. 5 .
  • the buyer is provided with a web page of their un-expired available contracts. At this point the buyer would select the contract he or she wanted to redeem.
  • the buyer creates the redemption order 160 This could be accomplished by pushing the send button on the given web page.
  • central controller accepts the redemption order.
  • central controller 200 extracts the contract information from redemption order 160 .
  • central controller 200 checks to see if the contract is a valid contract by checking order database 270 .
  • the central controller examines the buyer's account to see if the buyer has a valid contracts. If the contract is not a valid contract the buyer is requested to submit a valid contract at step 810 .
  • the redemption order is accepted at step 830 .
  • a unique tracking number is added to the redemption order 160 .
  • the central controller 200 timestamps redemption order 160 at step 850 .
  • the central controller 200 calculates the redemption value of the contract.
  • the central controller 200 sets the status of the redemption order 160 to “redeemed” and stores it in the redemption database 280 .
  • central controller authorizes payment of the redemption value to the buyer. This could be accomplished by either crediting the customer's account or by crediting their credit card account.
  • a buyer may use a telephone, for example, to generate order 100 .
  • the buyer calls central controller 200 and is connected with an agent.
  • the buyer provides the terms of order 100 such as product ID, contract type, expiration, quantity, price, etc.
  • the buyer also provides his customer ID, password, or private key so that central controller 200 can authenticate his identity.
  • the agent puts this data into digital form by typing it into a terminal.
  • Order 100 is then transmitted to central controller 200 where it is added to order database 267 as described in the on-line embodiment.
  • the agent then provides the buyer with the authorization code for their contract.
  • a similar process would also allow the buyer to redeem their contracts via telephone, for example.
  • the buyer/seller calls central controller 200 and is connected with a conventional Interactive Voice Response Unit (IVRU) which allows the buyer to enter some or all of the terms of order 100 without the assistance of a live agent.
  • IVRU Interactive Voice Response Unit
  • the buyer initially selects from a menu of products with the touch-tone keys of his phone. The specific contract type and expiration can also be selected in the same manner.
  • the central controller 200 can then announce the schedule of market prices for each contract and the buyer can then use his touch-tone keys to select the quantity and price required. This information can then be used to generate order 100 .
  • central controller 200 is separated into three distinct elements: operations server 164 , certificate authority 165 , and redemption server 170 .
  • Each server performs a distinct task in the process of managing order 100 and redemption orders 160 . This separation makes it more difficult for attackers to compromise the system, as they must defeat the security of three separate systems, instead of one.
  • these servers work in conjunction with POS 400 and wireless POS 401 and POS 402 .
  • Operations server 164 has the task of posting orders 100 and accepts all transactions previously authenticated by a certificate authority 165 .
  • the certificate authority 165 authenticates the identity of buyers while redemption server 170 processes all redemption orders 160 and the payments related to them.
  • each server type may be distributed over a number of servers.

Abstract

A system and method and device for using a computer to facilitate the issuance and redemption of energy related micro derivative contracts between a buyer and an seller, including a customer determining the derivative contract to be purchased and swiping the card through the card reader. The customer then submits the order to the central controller. At that point, the central controller will store the order in the database. The buyer then submits the contract to the central controller to request to redeem the contract. The central controller then validates the contract and if it is valid authorizes the delivery of the energy product to the customer.

Description

    TECHNICAL FIELD
  • The present invention relates to a method and an apparatus for facilitating transactions on an electronic commercial network system and specifically to a method and system for facilitating the issuance and redemption of micro energy derivative contracts.
  • DISCUSSION OF RELATED ART
  • Historically, there have been numerous events such as wars, sudden deregulation, riots, stoppages, natural disasters, supply crises, labor unrests, etc., that have caused spikes in the prices of energy sources like gasoline, electricity or natural gas. Unlike other commodity consumers, energy consumers are unable to buy “insurance” or derivative contracts that would protect them from the volatility in the energy market caused by such shocks to the energy supply. If the consumers facing such unpredictable energy crises could purchase derivative contracts they could either lock in the current price or buy insurance to protect them against huge price swings.
  • Energy derivative contracts (e.g., options, futures contracts, Asian options, lookback options to name a few—hereafter generally referred to as “derivatives”) are normally traded on the financial exchanges or over the counter by major brokerage firms and are useful for managing the risks associated with the buying and selling of energy products. Currently, derivatives are available for all the major energy products, and specifically for: light sweet crude, natural gas, heating oil, unleaded gasoline, propane and electricity.
  • The typical contract sizes for energy derivative contracts are very large, for example, 42,000 gallons of unleaded gasoline, 1000 US barrels of light sweet crude oil or 4000 million BTU for the “mini” natural gas contract. The target markets for these products are the corporation in the energy business such as refineries, oil producers, institutional or professional energy consumers. For example, the major airlines frequently make use of derivatives to manage the cost of aviation fuels. On the other hand, the owner of a small taxi fleet is unable to lock in the price of his gasoline, and so his profits become very volatile as the price of gasoline fluctuates.
  • The practice of using derivatives to manage risk in energy products is well known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to John C. Hull, Options, Futures and Other Derivatives (5th Ed, Prentice Hall, 2002) or Energy Risk Management by Peter Fusaro (McGraw Hill, 1998).
  • The advent of prepaid telephone cards has educated consumers in the use of “forward contracts” in the sense that the consumer has contracted to purchase a given amount of minutes from a designated carrier at some point in the future. Additionally most prepaid cards also have an expiration date beyond which, the contract will expire to be worthless. However, the price of a telephone call is not as volatile as the price of, say, gasoline and thus a prepaid gasoline card would require much more sophisticated planning and hedging on the part of the seller. Also the price of energy varies from state to state and so either the pricing of the prepaid card or the delivery of the underlying product becomes more complicated. Hence, there is a need for micro derivative contracts that would allow smaller consumers to hedge the risks of inflationary fuel prices.
  • However, micro derivative contracts on energy products would be of enormous value to these consumers, but they do not exist in the current marketplaces. For example a micro derivative contract can be an unleaded gasoline contract for about 50 to 100 gallons, which is the typical monthly gasoline usage of a typical individual consumer. One of the major obstacles to micro derivative contracts is the trading costs associated with the buying and selling of derivative contracts. For example, at current prices, it costs about $12 to trade a single option contract with the cheapest broker in the USA. Other brokers charge as much as $50 to trade a single contract. Assuming that a three-month micro option on gasoline could cost $2 in premium and a one-month micro option contract may cost $0.50, even the cheapest $12 transaction cost would stifle any attempt to trade micro derivatives.
  • Another major barrier for development of derivative fuel contracts in the present marketplace is that the contracts on the major exchanges are for delivery of the energy product at a specific location, e.g., the unleaded gasoline contract is for delivery in the New York harbor. This makes it useless for a consumer in the Californian market who only uses 50 gallons a month on an average. Micro derivative contracts could be structured so that the delivery of the underlying energy commodity could be in any specific geographic location, such as within any given zip code or at any particular gas station desired by the consumer. Hence, there is a need for such delivery point independent micro derivative contract and a trading system for such contracts.
  • Another important aspect of the micro-derivative contracts is that they can be used as a loyalty reward for consumers of a particular brand of energy. For example, a retail gasoline company could offer the contracts to its customers provided that they redeem the contract at a participating gas station affiliated with that particular retail gasoline company. This would help ensure customer loyalty and could be constructed in such a way that the seller pays the premium. Therefore, there is a need for a micro derivative contract system that can be readily utilized as a loyalty reward system or be linked to an existing reward system.
  • Despite recent advances in computers, electronic network technology and wireless technology and the explosive growth in electronic commerce (e-commerce), applicant is not aware of a commercially viable market in micro derivative contracts on energy products, wherein consumers can buy and redeem micro derivative contracts for their energy consumption.
  • SUMMARY OF THE INVENTION
  • In one aspect of the invention, a system and method for using a POS device and a computer to facilitate a transaction between a buyer and a seller includes a customer submitting an order to the central controller. The central controller authorizes the contract that is issued to the buyer. If the buyer is redeeming the contract then the customer submits the details of the contract to the central controller; the central controller authenticates the contract; and the central controller issues authorization for sale of the energy commodity at the contract price.
  • A system and method provides individuals with the ability to buy and redeem micro derivative contracts on energy products, thereby effectively locking in the prevailing market price by buying price protection insurance. At present, the individual energy consumers are forced to bear market risk and pay higher prices when these products are in short supply. Therefore, it is one aspect of the present invention to provide a method and a system for facilitating the issuance and redemption of micro energy derivative contracts.
  • An aspect of the present invention is to allow the buyer to pay for the contract using cash. Another aspect of the present invention is to allow the buyer to pay for the contract using a credit card. An aspect of the present invention for the buyer is to buy the contract on credit and have the system communicate with the seller's accounting system. Another aspect of the present invention is to allow the buyer to pay a premium for his current usage of energy, where that premium is then used to automatically purchase a derivative contract. It is yet another aspect of the present invention to allow buyers to redeem the contracts for cash.
  • The buyer can redeem a previously purchased micro derivative contract by receiving the energy product at a future date. Alternately, the buyer can assign the contract to another buyer or any other third party. Further, the buyer can redeem the micro derivative energy contract for cash.
  • In another aspect of the invention the buyer redeems the contract by purchasing the underlying physical energy product for the price agreed in the contract. Another aspect of the invention allows the buyer to prepay for the underlying physical energy product that the buyer will later collect as part of the redemption process.
  • These and other aspects, features and advantages of the present invention will become apparent from the following detailed description of illustrative embodiments thereof, which is to be read in connection with the accompanying drawings in which the same reference numerals are used throughout the various figures to designate same or similar components.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • FIG. 1 illustrates a block diagram of an embodiment of the present invention;
  • FIG. 2 is a block diagram showing an exemplary central controller in an embodiment of the present invention;
  • FIG. 3 illustrates an exemplary flow of an issue transaction;
  • FIG. 4 illustrates an exemplary flow of a redemption transaction;
  • FIG. 4A is a block diagram showing an embodiment of the buyer interface;
  • FIG. 5 illustrates an embodiment showing how a buyer order is generated;
  • FIG. 6 illustrates an embodiment showing the acceptance of a buyer order and credit card payment by the central controller;
  • FIG. 7 illustrates an embodiment showing how a buyer redemption order is generated;
  • FIG. 8 illustrates an embodiment showing the acceptance of a buyer redemption order and payment authorization by the central controller; and
  • FIG. 9 illustrates an embodiment showing the use of a certificate authority and a settlement server.
  • DETAILED DESCRIPION OF PREFERRED EMBODIMENTS
  • A system and method according to the present invention is provided for facilitating the issue and redemption of micro derivatives on energy products. The term “micro derivative” contract as used here in context of energy and fuel related contracts indicates that the contract are of a type suitable to either individual or a small number of consumers. For example, one feature of such contract can be that it deals with an energy purchase of a relatively smaller value. Another could be a small amount of quantity of the fuel to be purchased under the contract. Another feature could be that the fuel would be available at the buyers location under the contract. Those skilled in the art will appreciate that many more such features can be used to define such micro contracts and the above listed examples are only given for illustration.
  • This is in contrast with conventional energy related derivative contracts that are typically large quantity, high value and destination specific. Such micro derivative contracts would typically be bought by relatively small consumers. For example, such small consumers can be individual consumers, groups of such consumers, non-profit entities and relatively small and medium size commercial organizations.
  • At least one aspect of the present invention provides a trading system for buyers wishing to buy contracts and redeem their contracts. The illustrative method and system according to the present invention provides the seller with a system for managing the issuance and redemption of derivative contracts that achieves a cost saving for both buyers and issuers. At least one aspect of the illustrative method and system, the present invention effectuates performance of resulting orders and redemptions, and authentication.
  • One aspect of the present invention is a viable facility for transacting micro derivative contracts and the ability to issue and redeem derivative contracts at a Point Of Service (POS) device. This is achieved by using the same magnetic cards that are used, for example, as department store gift cards or POS authorized prepaid phone cards. A POS system for gasoline stations is described in U.S. Pat. No. 4,395,626. The POS system could either be used by the buyer themselves or by a sales agent assisting the buyer.
  • Moreover, a system that can also utilize physical tokens that interact with POS device as a method of authenticating the buyer will be more likely to attract the attention of potential buyers, because they offer an ease of use normally associated with credit accounts. These tokens could be smart cards or a transponder similar to the smartcards that need only to be waived before a terminal to complete payment for a transaction. An example of a transponder payment system is disclosed in U.S. Pat. No. 6,073,840.
  • Referring now to FIG. 1, in a preferred embodiment, an electronic network including a central controller 200 is shown. The network facilitates communications between a plurality of buyers using a plurality of POS devices and a seller (i.e., central controller 200). FIG. 1 illustrates a plurality of POS devices coupled to one central controller 200 in a variety of manners. POS devices 400 are electronically connected to the central controller via Ethernet connections. Wireless POS devices 401 connect to the central controller via a wireless router that is electronically linked to central controller 200. POS device 402 connects to central controller with POS modems 408.
  • Each of the plurality of buyers who wish to make purchases, independently accesses the central controller 200 to create purchase orders using any of the POS devices. Examples of a POS system are the “G-SITE” system from Gilbarco Inc. which is a retail POS for the gasoline industry. Another POS system is the “REALPOS 80” from National Cash Register. An example of a wireless POS could be a HP IPAQ 555, which is a Bluetooth enabled PDA (Personal Digital Assistant). The wireless router can be a Linksys BEFW11S4 or any other wireless router. The central controller 200 is preferably located at a remote server.
  • FIG. 3 illustrates the steps associated with the creation and inclusion of an order 100 into the order database 270. At step 30, a buyer 16 selects the particular contract he wishes to purchase. This most probably will be a buyer selecting a magnetic card from a display stand. At step 32, the buyer swipes the magnetic card through the card reader at the POS system. Again it may be a sales clerk that does the actual swiping of the card. At step 34 the buyer submits the contract to the central controller 200 for issuance.
  • A typical buyer created order, order 100, could, for example, specify that the buyer wishes to purchase a Mar. 31, 2005 option to buy unleaded gasoline at $1.95. This would be equivalent to purchasing an insurance policy that guaranteed the buyer could purchase 20 gallons on unleaded gasoline for $1.95 at any time up to Mar. 31, 2005 irrespective of what the prevailing market price happened to be.
  • At step 36, the central controller 200 assigns a unique tracking number to the order 100, timestamps it and adds it to the order database. The central controller 200 may require that the buyer 16 has sufficient credit in his account to cover the purchase price of the specified product. At step 38, the central controller 200 transmits an acknowledgement to the buyer. Instead of an acknowledgement code, the central controller could send an authorization code to the POS to authorize the order 100. Once s a buyer is authenticated and found to be credit worthy, the central controller would complete step 38.
  • FIG. 4 illustrates the steps associated with the redemption of a micro contract 150. At step 40 the buyer submits his redemption request by transmitting it to the central controller 200. At step 42 the central controller 200 receives the request 155 and extracts the contract 150 from the request 155.
  • At step 44, the central controller 200 determines if it is a valid contract. If it is not, then at step 45, the central controller 200 notifies the buyer that the contract is invalid and the process terminates. If it is a valid contract, then at step 46 the central controller 200 assigns a unique tracking number to the redemption order 160 and stores it in the redemption database 280.
  • At step 47 the central controller 200 calculates the redemption value of the contract and at step 48 the central controller 200 authorizes sale of the underlying commodity to the buyer at the contract price.
  • In at least one embodiment of the present invention, communications between the various parties may be transmitted via numerous means including a worldwide-web interface, personal digital assistant (PDA), web enabled cellular phones, POS systems, electronic mail, voice mail, facsimile, or postal mail. Those skilled in the art would appreciate that the above mentioned transmission methods and devices are illustrative and the same does not limit the invention in any manner. Hence, any other suitable transmission methods or devices can be used.
  • At least one embodiment of the present invention can also be practiced in an off-line environment. Instead of using electronic mail or web-based servers, buyer 16 s may communicate with the central controller 200 via telephone, facsimile, postal mail, or another off-line communication tool. For example, buyers may use telephones to create the orders 100 (with or without the assistance of live agents) as well as create redemptions 150 with the use of telephones.
  • Other embodiments may use cryptographic protocols to authenticate the identity of buyer 16 s and verify the integrity of buyer 16's communications with the central controller 200. This would be useful in embodiments where the purchase of derivative contracts is made against the credit account of a buyer. The use of cryptography, smart cards and biometrics can make it significantly more difficult for unauthorized persons to tamper with the system by passing themselves off as legitimate buyer 16 s or eavesdropping on system communications.
  • In another embodiment, buyer 16 could purchase a prepaid energy card that could then be authorized by the central controller 200. This is the equivalent of a prepaid forward contract that allows the buyer to take delivery of the specified amount of energy product at any point up to the expiration of the contract. In general, the buyer and seller of a micro derivative contract may specify any contractual term for supply of energy resources. For example, the buyer and seller can agree on a specific termination date of a given micro derivative contract.
  • In another embodiment, the buyer 16 could receive their selected contract in the form of a physical token 19. Such a token could be a plastic card with a magnetic strip (similar to a credit card), a smart card with an embedded chip, or a transponder similar to a SPEEDPASS from Mobil. Other tokens not explicitly enumerated herein are also within the scope of the invention.
  • In the same embodiment, buyer 16 could present the physical token 19 to a POS system to redeem their contract. The final payment the buyer would then make at the POS would depend on the redemption value of the contract.
  • Other embodiments may have the seller make use of selling agents who authorize and authenticate contracts through the use of seller interface 300. For example, such an interface could be a credit card terminal that would authorize energy cards and then validate them at the time of redemption.
  • One embodiment of the present invention divides the functionality of the central controller 200 into three components and embodies them in three separate servers: an operations server, a certificate authority, and a settlement server. The certificate authority authenticates the identity of buyer 16 s while the settlement server verifies their ability to pay or deliver contracts. The operations server posts orders 100 relying upon messages from the other two servers for validation. This configuration allows for greater specialization of the servers.
  • Another embodiment of the present invention does not require a transfer of funds from seller 20 to buyer 16. Instead, the system may be used to consummate a contract involving an exchange of loyalty rewards, e.g., loyalty points, that can then be exchanged for other products and services. Similarly, the same loyalty points can be used by buyer 16 to purchase further contract(s) from seller 20 without the use of money.
  • In at least one embodiment of the present invention is a highly effective system for the issue and redemption of micro derivative contracts on energy products. The present invention provides numerous unique advantages including ease of purchase, delivery, reduced fees and portability.
  • The present invention will now be discussed with reference to FIGS. 1 and 2. At least one embodiment of the present invention includes central controller 200 and POS 400, and associated databases. The present invention receives orders from buyers and then authorizes the contract. A buyer is able to redeem his contracts through the system.
  • A system architecture of at least one embodiment of the present invention is explained with reference to FIGS. 1 and 2. As shown In FIG. 1, an apparatus of the present invention comprises central controller 200, and POS 400 (collectively the “nodes”). Each node is connected via an Internet connection using a public switched phone network, such as those provided by a local or regional telephone operating company. Connection may also be provided by dedicated data lines, cellular, Personal Communication Systems (“PCS”), microwave, or satellite networks. Other embodiments may use other means of communication not enumerated herein. POS systems 400, 401 and 402 are the input and output gateways for communications with central controller 200.
  • Using the above components, the present invention provides a method and apparatus to issue and redeem micro derivative contracts in energy products.
  • As shown in FIG. 2, central controller 200 includes central processor (CPU) 205, cryptographic processor 210, RAM 215, ROM 220, payment processor 230, clock 235, operating system 240, network interface 245, and data storage device 250.
  • A conventional personal computer or computer workstation with sufficient memory and processing capability may be used as central controller 200. In one embodiment it operates as a web server, both receiving orders 100 and processing redemption orders 120, Central controller 200 must be capable of high volume transaction processing, performing a significant number of mathematical calculations in processing communications and database searches. A microprocessor, for example, an ITANIUM 2.1 GHz, commonly manufactured by Intel Inc., may he used for CPU 205. This processor employs a 128-bit architecture. Equivalent processors include the IBM's POWERPC 970 64 bit processor or Sun Microsystem's ULTRASPARC-III CU.
  • An MPC180 security processor, commonly manufactured by Motorola Inc. may be used for cryptographic processor 210. Suitable equivalent processors may also be used without limiting the invention in any manner. This 66 MHz micro-controller has a RSA signature time of 32 ms supporting 10 IKE handshakes per second. Cryptographic processor 210 supports the authentication of communications from buyers and sellers, as well as allowing for anonymous transactions. Ideally, cryptographic processor 210 may also be configured as part of CPU 205. Other commercially available specialized cryptographic processors include Phillip's 40 MHz VMS113.
  • Data storage device 250 may include hard disk magnetic or optical storage units, as well as CD-ROM drives or flash memory. Data storage device 250 contains databases used in the processing of transactions in the present invention. These include customer database 255, product database 260, security master database 265, order database 270, transaction confirmation database 275, redemption database 280, cryptographic key database 285, and audit database 295. In an embodiment database software such as ORACLE9i, manufactured by Oracle Corporation, is used to create and manage these databases. Data storage device 250 also stores information pertaining to seller account 295 and buyer account 296.
  • Customer database 255 maintains data on customers with fields such as account type, name, address, telephone number, ID number, electronic mail address, smart card ID, public/private key information, etc. This information is obtained when the customer first registers with the system, or immediately prior to posting his first order 100. Different information may be required for different account types e.g. individual accounts would require credit card information, etc.
  • Product database 260 maintains data on all the underlying energy products with fields such as product ID, product description, product availability, product provider, and where applicable a geographic area where the product is available. This database is a catalog of all the underlying products on which the derivative contracts are written.
  • Security master database 265 maintains data on all the specific derivative contracts that can be purchased. It has fields such as security ID, contract type, expiration, strike if applicable, product ID, etc. The security master database 265 is the catalog of derivative contracts that can be traded.
  • Order database 270 tracks all the order 100 s with fields such as status, tracking number, date, time, security ID, customer ID and quantity. Transaction database 275 tracks the payment information regarding the order. Fields include customer name, customer ID number, order tracking number, type of payment, amount and associated credit card authorization number. Redemption database 280 tracks all payments made to the buyers and contract details with fields such as customer ID number, amount of payment, and associated order tracking number.
  • Cryptographic key database 285 facilitates cryptographic functions, storing both symmetric and asymmetric keys. These keys are used by cryptographic processor 210 for encrypting and decrypting orders 100.
  • Audit database 290 stores transactional information relating to the purchase of orders 100 and the redemption of redemption orders 160. Seller Account Database 295 tracks all payments made to and by the seller. This account may be a pointer to account data stored at the seller's bank.
  • Buyer account 296 tracks all information pertaining to the customer's account with fields such as customer ID, bank account numbers, and debit or credit transactions. This account may be a pointer to account data stored at the customer's bank.
  • Network interface 245 is the gateway to communicate with buyers through POS 400. Conventional internal or external modems may serve as network interface 245. Network interface 245 supports modems at a range of baud rates from 1200 upward, but may combine such inputs into a T1 or T3 line if more bandwidth is required. In a preferred embodiment, network interface 245 is connected with the Internet and/or any of the commercial on-line services such as America Online, Road Runner or Verizon Online. Network interface could also be a DSL modem or a cable modem. These services are also commercially available from Internet Service Provider (ISP) companies. This allows buyers to choose access service(s) from a wide range of on-line connections. Several commercial electronic mail servers include the above functionality. Microsoft's EXCHANGE SERVER 5.5 is a secure server-based electronic mail software package designed to link people and information over enterprise networks and the Internet. The product utilizes open standards based on Internet protocols. Users can exchange messages with enclosures such as files, graphics, video and audio. Alternatively, network interface 245 may be configured as a voice mail interface, web site, BBS, or electronic mail address, etc.
  • While the above embodiment describes a single computer acting, as central controller 200, those skilled in the art will realize that the functionality can be distributed over a plurality of computers. In one embodiment, central controller 200 is configured in a distributed architecture, wherein the databases and processors are housed in separate units or locations. Some controllers perform the primary processing functions and contain at a minimum RAM, ROM, and a general processor. Each of these controllers is attached to a Wide Area Network (WAN) hub, which serves as the primary communication link with the other controllers and interface devices. The WAN hub may have minimal processing capability itself, serving primarily as a communications router. Those skilled in the art will appreciate that an almost unlimited number of controllers may be supported. This arrangement yields a more dynamic and flexible system, less prone to catastrophic hardware failures affecting the entire system. The certificate authority embodiment provides more details of such a distributed environment describing operations server 164, certificate authority 165, and settlement server 170. The hardware of these servers would be configured similarly to that described for central controller 200.
  • In one embodiment of the present invention, communications between buyers and the seller take place via electronic or wireless networks, with central controller 200 acting as a web-server. The buyer logs on to central controller 200, selects the energy product he or she is interested in, selects the derivative contract he or she wishes to purchase, examines the current market prices given by central controller 200, adds a quantity specifier and thereby creates order 100, and then disconnects from the network. Similarly, for redemptions, the buyer logs onto central controller 200 and submits a redemption request by supplying the details of the purchased contract. The central controller 200 authenticates the contract and then if it is valid calculates the redemption value of the contract. Central controller 200 then authorizes payment to the buyer.
  • Referring now to FIG. 4A, there is described buyer interface 300, which includes central processor (CPU) 405, RAM 415, ROM 420, clock 435, video driver 425, video monitor 430, communication port 440, input device 445, modem 450, and data storage device 460. Cryptographic processor 410, smart card reader 465 and biometric device 455 may be added for stronger authentication as described later. A microprocessor such as the 3 GHz Pentium 4 Processor made by Intel Corporation may be used for a CPU 305. Clock 435 is a standard real-time chip-based clock, which can serve to timestamp buyer order 100 produced with buyer interface 300.
  • Modem 450 may not require high-speed data transfer if most buyer orders 100 produced are text-based and not too long. If a cryptographic processor is required, the MPC180 micro-controller described above is used. The structure of biometric device 455 and smart card reader 465 will be described below in conjunction with the cryptographic authentication embodiment.
  • Data storage device 460 is a conventional magnetic-based hard disk storage unit such as those manufactured by Conner Peripherals or Maxtor. Message database 470 may be used for archiving buyer orders 100, while audit database 480 may be used for recording payment records and communications with the central controller 200.
  • There are many commercial software applications that can enable the communications required by buyer Interface 300, the primary functionality being message creation and transmission. EUDORA PRO manufactured by Qualcomm, Incorporated, for example, provides editing tools for the creation of messages as well as the communications tools to route the message to the appropriate electronic address. When the central controller 200 is configured as a web-server, conventional communications software such as a web browser may also be used. The buyer may use these browsers to transmit order 100. No proprietary software is required.
  • With reference to FIG. 5, a process is described by which the buyer formulates order 100. At step 500, the buyer logs on to central controller 200 using buyer modem 450 of buyer interface 300, establishing a communication link. It should be noted that the buyer might be an individual, a corporation, a partnership, government or any other entity. In one embodiment, central controller 200 has a page or website on the World Wide Web, allowing the buyer to provide information through the interface of a conventional web browser software.
  • At step 505, the buyer selects the energy product he wants to purchase by selecting from a list of possible energy products. As shown in box 507 products might include electricity or unleaded gasoline, etc. After the product is selected, in step 510 the buyer than selects a derivative contract on the product. As shown in box 512, this might be a Dec. 31 2004 option to buy unleaded gasoline at $1.95 a gallon, etc. At step 520 a form is displayed on video monitor 430 of buyer interface 300 (Note steps 505 and 510 could also be accomplished in the same way). This form is an electronic contract with a table of the current market price for the specific contract and selection fields and/or a number of blanks to be filled out by the buyer. Note that steps 505 and 510 could also be accomplished by using a selection box.
  • At step 530, the buyer adds the quantity he requires. At step 570 the buyer attaches his name and credit card information or a unique user ID number to order 100. This ID number is received from central controller 200 when the customer registers for the service, or is chosen by the customer and then registered with central controller 200 by phone. Central controller 200 maintains a database of customer ID numbers in customer database 255, and issues (or allows) only unique numbers. If less security is required, the user's telephone number or social security number could serve as the ID number since it has the advantages of being both unique and easily remembered. However, since credit card information is being stored, customers may be more comfortable with a more secure version. If additional security is required, those procedures described in the cryptographic embodiment may be implemented.
  • Once the above elements have been developed, the buyer transmits them to central controller 200 at step 560. The buyer does this by clicking on a “send” button located on the screen in which he entered the terms of order 100. At this step the buyer has placed an order for a derivative contract and proceeds to the payment method as described in FIG. 6.
  • Instead of a World Wide Web based interface, buyers may also transmit order 100 data via other means including electronic mail, PDAs, Electronic Data Interchange (EDI), voice mail, facsimile, or postal mail transmissions. With voice mail, the buyer calls central controller 200 and leaves order 100 in audio form. These orders 100 may be transcribed into digital text at central controller 200, or maintained in multiple formats. Central controller 200 supports a plurality of transmission methods, allowing for a wide variety of formats of order 100 s.
  • Some formats may be changed, however, before further processing by central controller 200. Orders transmitted by mail in paper form, for example, may be scanned-in and digitized, using optical character recognition software to create digital text and then used to create orders 100. These embodiments are more fully described in the off-line embodiment described later.
  • Referring now to FIG. 6, order 100 is received and the credit card info is extracted either from the order or from the customer database if the customer only provided his unique identifier (ID). At step 605, central controller 200 requests a merchant approval code for the purchase price of the contract. The interface to the credit card processing centers is well known in the art and is standard for e-commerce on the Internet. One such interface is provided by Linkpoint International. Steps 607 and 620 are implemented as part of the merchant approval process as once the central controller 200 receives an authorization number it is then able to complete the transaction. If any part of the authorization fails, then at step 610, central controller 200 requests a new credit card from the buyer.
  • Once central controller 200 has received the authorization it accepts the buyer order at step 630. At step 640 a unique tacking number is added to the order 100. The central controller 200 timestamps order 100 at step 650 and stores order 100 in the order database 270 at step 660. Order database 270 contains a record for the order 100. The record contains fields such as status, tracking number, timestamp, security ID, quantity and customer ID. The status field has values of “pending,” “complete,” “redeemed” and “cancelled.” A status of “pending”, means that the order cannot currently be transacted. Either, central controller 100 is still processing it, or the buyer has temporarily suspended it. A “complete” order 100 is one that has been sold. A “redeemed” order is one that has been redeemed by the customer or has expired worthless. An “cancelled” order 100 can no longer be used.
  • Referring again to FIG. 7, a process by which a buyer creates a redemption order is described. At step 700, the buyer logs on to central controller 200 using buyer modem 450 of buyer interface 300, establishing a communication link. This process is a mirror image of the process described above in the buyer selection process of FIG. 5. At step 710, the buyer provides his or her unique ID as described in FIG. 5. At step 720, the buyer is provided with a web page of their un-expired available contracts. At this point the buyer would select the contract he or she wanted to redeem. At step 730, the buyer creates the redemption order 160. This could be accomplished by pushing the send button on the given web page. At step 740, central controller accepts the redemption order.
  • Again, once the process is completed the seller has entered into a binding contract with the intermediary.
  • Referring now to FIG. 8, redemption order 160 is received and checked. At step 800, central controller 200 extracts the contract information from redemption order 160. At step 805, central controller 200 checks to see if the contract is a valid contract by checking order database 270. At step 807, the central controller examines the buyer's account to see if the buyer has a valid contracts. If the contract is not a valid contract the buyer is requested to submit a valid contract at step 810.
  • If all is well, the redemption order is accepted at step 830. At step 840, a unique tracking number is added to the redemption order 160. The central controller 200 timestamps redemption order 160 at step 850. At step 860, the central controller 200 calculates the redemption value of the contract. At step 870, the central controller 200 sets the status of the redemption order 160 to “redeemed” and stores it in the redemption database 280. At step 880 central controller authorizes payment of the redemption value to the buyer. This could be accomplished by either crediting the customer's account or by crediting their credit card account.
  • In an embodiment of the present invention, buyers and the seller communicate in an off-line manner with central controller 200. Rather than sending electronic mail or using web-based servers, the seller and buyers use a telephone, fax machine, postal mail, or other off-line communication tools.
  • A buyer may use a telephone, for example, to generate order 100. The buyer calls central controller 200 and is connected with an agent. The buyer provides the terms of order 100 such as product ID, contract type, expiration, quantity, price, etc. The buyer also provides his customer ID, password, or private key so that central controller 200 can authenticate his identity. The agent puts this data into digital form by typing it into a terminal. Order 100 is then transmitted to central controller 200 where it is added to order database 267 as described in the on-line embodiment. The agent then provides the buyer with the authorization code for their contract. A similar process would also allow the buyer to redeem their contracts via telephone, for example.
  • In another embodiment, the buyer/seller calls central controller 200 and is connected with a conventional Interactive Voice Response Unit (IVRU) which allows the buyer to enter some or all of the terms of order 100 without the assistance of a live agent. The buyer initially selects from a menu of products with the touch-tone keys of his phone. The specific contract type and expiration can also be selected in the same manner. The central controller 200 can then announce the schedule of market prices for each contract and the buyer can then use his touch-tone keys to select the quantity and price required. This information can then be used to generate order 100.
  • Buyers may also communicate with an agent at central controller 200 through faxes or postal mail. The agent receives the message and proceeds to digitize it and form order 100 as described above.
  • In at least one embodiment of the present invention, central controller 200 is separated into three distinct elements: operations server 164, certificate authority 165, and redemption server 170. Each server performs a distinct task in the process of managing order 100 and redemption orders 160. This separation makes it more difficult for attackers to compromise the system, as they must defeat the security of three separate systems, instead of one. As indicated in FIG. 9, these servers work in conjunction with POS 400 and wireless POS 401 and POS 402. Operations server 164 has the task of posting orders 100 and accepts all transactions previously authenticated by a certificate authority 165. The certificate authority 165 authenticates the identity of buyers while redemption server 170 processes all redemption orders 160 and the payments related to them. In this embodiment, each server type may be distributed over a number of servers.
  • There are two types of certificate authorities. The first is an internal server and the second is a trusted third party. This third party could also be the settlement server as well. For example, banks, insurance companies and other financial institutions could issue digital certificates establishing the identity of an individual and convey other pertinent information such as the individual's authority to represent an organization and his spending limit. Similarly, they could also certify the individual's ability to pay or deliver goods much as they do now when they issue letters of credit. These third parties have the financial capability to back up their certifications and thus can insure both buyers and sellers against fraud.
  • An example of such a system is the CERTAUTHORITY Solution manufactured by CertCo LLC. This system also comes with an optional tamper proof hardware based private key that is easy to transport and store securely.
  • The practice of using certificate authorities and settlement servers is well known in the art and need not be described here in detail. For reference, one of ordinary skill in the art may refer to Winfield Treese and Lawrence Stewart, Designing Systems for Internet Commerce, Addison Wesley, 1998.
  • This set of protocols describes one possible implementation of an infrastructure to support order 100. It is important to note that operations server 164, certificate authority and redemption server 170 can conceivably be the same entity. In this case the protocols are somewhat simplified but can still be achieved using the same software mentioned above.
  • According to another aspect of the invention, the buyer can interact with the POS using a physical token. The physical token could be a transponder similar to the Mobil SPEEDPASS made by Gilbarco. In this embodiment, the buyer could use the online embodiment to purchase the contract and then use the transponder for the redemption of the contract. Similarly, the buyer could purchase the contract at the POS system and instead of issuing the buyer a card, the seller could issue the buyer a transponder. This would simplify the redemption process for the buyer, who could just use the transponder to redeem the contract. The process is the same as the one outlined in FIGS. 3 and 4.
  • In an embodiment, the seller could bypass the steps for issuance by creating a loyalty card that would be issued free of charge to buyers. This would create an incentive for the buyer to return to the issuing provider in order to redeem the contract. In this embodiment the buyer would redeem the contract using the same process outlined in FIG. 4.
  • In one embodiment the derivative contract could be on a “basket”, i.e., a pool or collection of deliverable energy products. This contract could come in any of a variety of combinations. On form is where the whole basket is deliverable under the contract, e.g., an option to buy gasoline and electricity from potentially two different suppliers. The second version is where the seller has the option of choosing which member of the basket to deliver at expiration. An example would be an option contract to buy a gasoline from two different suppliers such as Shell and Chevron. At expiration the seller could select which gasoline to deliver. The third version is where the buyer has the option to select which member of the basket they desire to transfer or assign their energy contract(s).
  • There is also a need for the seller to administer the issuance and redemption of these micro derivative contracts. In monitoring the issuance and redemption of these contracts, the seller can hedge their exposure to fluctuations in the price of the underlying energy commodity thereby avoiding huge potential losses in the underwriting of these “insurance” policies. This could be achieved by trading the major contracts on the financial exchanges or by buying and selling the underlying commodity. In addition to hedging the exposure, the seller would also have to ensure the validity of the contract being presented.
  • In the financial field, practitioners have developed a myriad of exotic options that could be applicable to the non-commodity product world. These include contracts that have multiple underlying options or even other contracts as underlying options. Illustrative examples of these contracts include:
      • 1) Future options—This is an option to buy a future contract. An example of such future option would be an option to buy a future contract on a tank full of gasoline.
      • 2) Compound option—This is an option on an option, for example, a call option on an option to buy a 1 Kilowatt of electricity.
      • 3) Asian options—The buyer pays the average price of the underlying option during the life of the option. The averaging could be defined over any periodicity, e.g., the daily average price or the weekly average price of gasoline.
      • 4) Lookback options—Here the buyer pays the maximum or minimum price experienced over the life of the option. An example would be an option to buy a gasoline at the cheapest price the gas station sold gasoline over the life of the option.
      • 5) Special options—Here the buyer would receive a discount on the price of the energy product at delivery. This would eliminate the need to develop location-based contracts. For example, the buyer could buy a contract to buy gasoline for 10 cents below the market price on the day of redemption.
  • Although the above list is only illustrative and not exhaustive, anyone skilled in the art will realize that any of the financial derivative structures are equally applicable to the energy products world.
  • Not all transactions require the transfer of the energy product from seller to the buyer on the expiration of the derivative contract. Just as in the financial markets, the derivative contracts could be settled for cash. And hence eliminate the added cost of shipping and handling the underlying product. This system also allows individuals from any state to participate in the market without worrying about the location of the redemption.
  • Further applications of the present invention are described below:
      • 1) A customer buying a Dec. 6, 2004 forward contract for 30 gallons of unleaded 87 octane branded gasoline at $1.48 a gallon.
      • 2) A customer buying a Dec. 6, 2004 option contract to buy 30 gallons of premium unleaded braded gasoline at $1.45 and paying $1.05 in option premium.
      • 3) An individual buying a Aug. 15, 2004 forward contract on 100 Kilowatt-hours of SDGE electricity for delivery in California at $0.0723 per kWh.
      • 4) A company buying a 1-year option to buy 50 kWh of peak demand electricity from an energy supplier utility at $0.0925 per kWh and paying $5.25 in option premium.
      • 5) A customer buying a Jun. 30, 2005 forward contract to buy 150 gallons of diesel at $1.35 in Austin Texas.
      • 6) A company buying a Nov. 15, 2004 option to buy 50 Therms of natural gas for $1.02 per Therm and paying $2.75 for the contract
      • 7) An ambulance service buying a Jan. 10, 2005 option to buy unleaded gasoline at the average daily price paid in New York City during the month of December 2004.
      • 8) A customer buying an option that provided his consumption of energy utilities is below or equal to its historical value, the most he will pay for his utility bill will be $150.00 for the month
  • The above listed examples are merely exemplary and those skilled in the art will agree that many different applications are possible within the scope of the invention.
  • Having described preferred embodiments of the present invention, it is noted that modifications and variations can be made by persons skilled in the art in light of the above teachings. It is therefore to be understood that changes may be made in the particular embodiments of the invention disclosed which are within the scope and spirit of the invention as outlined by the appended claims.

Claims (32)

1. An electronic system for facilitating trading of derivative contracts, comprising:
a transmitter for transmitting an order for a micro derivative contract from a buyer to a seller; and
a controller associated with the seller for receiving the order transmitted from the transmitter over the electronic system, the controller assigning an authorization identifier corresponding to the micro derivative contract, the controller storing the authorization identifier in a database and transmitting an acknowledgement to the buyer.
2. The system of claim 1, wherein the micro derivative contract has a predetermined expiration condition.
3. The system of claim 1 wherein the central controller authenticates the identity of the buyer by checking an electronic smart card submitted by the buyer with an issuer of the electronic smart card.
4. The system of claim 3 wherein the authentication is carried out using cryptographic means.
5. The system of claim 1 wherein the transmitter is a point of sale terminal.
6. The system of claim 5 wherein the point of sale terminal is wirelessly connected to the controller for transmitting and receiving data.
7. The system of claim 1 wherein the electronic system is at least one of the Internet, an intranet, a local area network and a wide area network.
8. The system of claim 1 wherein the controller is a computer system.
9. A computer based method for facilitating contractual transactions using an electronic system between a buyer and a seller, the method comprising:
receiving at the seller an order to buy a micro derivative contract for at least one energy product from the buyer, the order being transmitted from a transmitter, said seller having a controller including a database stored in a storage;
assigning an authorization identifier corresponding to said micro derivative contract;
storing said authorization identifier in the database; and transmitting acknowledgement to the buyer.
10. The method of claim 9, wherein at least one of the buyer and the seller stipulates a price for the micro derivative contract they will trade.
11. The method of claim 10, wherein at least one of the buyer and the seller stipulates the expiration of the micro derivative contracts that they will trade.
12. The method of claim 11, wherein the buyer purchases the energy product at a predetermined contract price.
13. The method of claim 9, wherein the buyer's order further comprises:
a quantity specifier.
14. The method of claim 13, further comprising the step of:
authenticating by the controller the identification and authority of the buyer.
15. The method of claim 14, wherein the step of authenticating is performed by comparing the buyer's identification, with a buyer identification previously stored in the central controller database.
16. The method of claim 14, wherein the step of authenticating comprises: authenticating the an electronic smart card submitted by the buyer with an issuer of the electronic smart card.
17. The method of claim 14, wherein the step of authenticating is performed using cryptographic means.
18. The method of claim 9, further comprising the step of:
providing a payment to the seller.
19. The method of claim 18, wherein the step of providing payment to the seller is performed using an automatic payment management system.
20. The method of claim 18, wherein the payment is in form of a currency.
21. The method of claim 9, further comprising:
transferring said contract to the buyer.
22. The system of claim 9 wherein the electronic system is at least one of the Internet, an intranet, a local area network and a wide area network.
23. The system of claim 9 wherein the controller is a computer system.
24. A computer based method for facilitating the redemption of micro derivatives contracts on energy products in transacting contracts between a buyer and a seller, the method comprising:
receiving at the seller a redemption order for a micro derivative contract from the buyer, the redemption order being transmitted from a transmitter, said seller having a controller including database storage;
authenticating the validity of the redemption order;
assigning a redemption identifier corresponding to said redemption order;
storing said redemption identifier in the database; and authorizing delivery of energy product to buyer.
25. The method of claim 9, wherein at least one communication between the buyer and the seller is conducted over an electronic network.
26. The method of claim 24, wherein at least one communication of the buyer with the central controller is achieved using at least one software agent.
27. The method of claim 24, wherein at least one communication between the buyer and the seller is conducted over a telecommunications network.
28. The method of claim 24, wherein the micro derivative contract is a forward contract.
29. The method of claim 24, wherein the micro derivative contract is an option contract.
30. A computer based method for facilitating the redemption of micro derivatives contracts on energy products in transacting contracts between a buyer and a seller, the method comprising:
receiving at the seller a redemption order for a micro derivative contract from the buyer, the redemption order being transmitted from a transmitter, said seller having a controller including database storage;
authenticating the validity of the redemption order;
assigning a redemption identifier corresponding to said redemption order;
storing said redemption identifier in the database; and
settling a redemption value of the redemption order in cash.
31. A device having stored programs executable by a computer to perform method steps for facilitating the issuance of micro derivatives contracts on energy products in transmitting contracts between a buyer and an seller, comprising:
receiving at the seller an order to buy a micro derivative contract from the buyer, the order being transmitted from a transmitter, said seller having a controller including a database storage;
assigning an authorization identifier corresponding to said contract;
storing said authorization identifier to said database; and
transmitting acknowledgement to the buyer.
32. A device having stored programs executable by a computer to perform method steps for facilitating the redemption of micro derivatives contracts on energy products in transmitting contracts between a buyer and an seller, comprising:
receiving at the seller a redemption order for a specific derivative contract from the buyer, the redemption order being transmitted from a transmitter, said seller having a central controller including database storage;
authenticating the validity of said redemption order;
assigning a redemption identifier corresponding to said redemption order;
storing said redemption identifier to said database; and
authorizing delivery of the energy product to buyer.
US10/915,048 2004-08-10 2004-08-10 Method and apparatus for facilitating micro energy derivatives transactions on a network system Abandoned US20060036530A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US10/915,048 US20060036530A1 (en) 2004-08-10 2004-08-10 Method and apparatus for facilitating micro energy derivatives transactions on a network system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US10/915,048 US20060036530A1 (en) 2004-08-10 2004-08-10 Method and apparatus for facilitating micro energy derivatives transactions on a network system

Publications (1)

Publication Number Publication Date
US20060036530A1 true US20060036530A1 (en) 2006-02-16

Family

ID=35801152

Family Applications (1)

Application Number Title Priority Date Filing Date
US10/915,048 Abandoned US20060036530A1 (en) 2004-08-10 2004-08-10 Method and apparatus for facilitating micro energy derivatives transactions on a network system

Country Status (1)

Country Link
US (1) US20060036530A1 (en)

Cited By (25)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060161488A1 (en) * 2005-01-14 2006-07-20 Oki Electric Industry Co., Ltd. Data confirming system and data confirming method
US20080010147A1 (en) * 2006-07-10 2008-01-10 Ward/Kraft System and method for calculating employee recognition benefits in the form of fuel credits
US20080015964A1 (en) * 2005-10-25 2008-01-17 Shuster Gary S Retail Price Hedging
US20080015981A1 (en) * 2006-07-11 2008-01-17 Andre Danesh Process for supplying fuel
US20080195432A1 (en) * 2007-02-12 2008-08-14 Fell Robert M Method and system for providing price protection for commodity purchasing through price protection contracts
WO2008124714A2 (en) * 2007-04-09 2008-10-16 Pricelock, Inc. System and method for index based settlement under price protection contracts
US20080262892A1 (en) * 2007-04-23 2008-10-23 Bank Of America Corporation Method of Hedging Retail Transactions for Fuel
US20080257957A1 (en) * 2007-04-17 2008-10-23 Steinecker Jeffrey T System and method for personalized e-commerce and information communications
US20080306777A1 (en) * 2007-04-09 2008-12-11 Pricelock, Inc. System and method for providing an insurance premium for price protection
US20080306789A1 (en) * 2007-02-12 2008-12-11 Pricelock, Inc. System and Method for Generating Revenues in a Retail Commodity Network
US20080306858A1 (en) * 2007-02-12 2008-12-11 Pricelock, Inc. System and method for enabling hedging customers to lock forward positions with customer-friendly payment options
US20080306833A1 (en) * 2007-04-09 2008-12-11 Pricelock, Inc. System and method for constraining depletion amount in a defined time frame
US20080306821A1 (en) * 2007-02-12 2008-12-11 Pricelock, Inc. System and Method of Driving Commodity Consumers to Selective Retail Locations
US20080306776A1 (en) * 2007-04-09 2008-12-11 Pricelock, Inc. System and method for risk acceptance in the provisioning of price protection products
US20080313067A1 (en) * 2007-02-12 2008-12-18 Pricelock, Inc. Management and decision making tool for commodity purchases with hedging scenarios
US20080313014A1 (en) * 2007-02-12 2008-12-18 Pricelock, Inc. System and method of determining a retail commodity price within a geographic boundary
US8160952B1 (en) * 2008-02-12 2012-04-17 Pricelock, Inc. Method and system for providing price protection related to the purchase of a commodity
US8500550B2 (en) 2008-04-24 2013-08-06 Aristocrat Technologies Australia Pty Limited Player tracking method and a player tracking system
US9547870B1 (en) * 2007-11-02 2017-01-17 Fair Isaac Corporation System and methods for selective advertising
US20180308183A1 (en) * 2017-04-20 2018-10-25 International Business Machines Corporation Facilitating power transactions
US20200098063A1 (en) * 2018-05-06 2020-03-26 Strong Force TX Portfolio 2018, LLC Systems and methods for fleet forward energy and energy credits purchase
US10803451B2 (en) 2016-04-29 2020-10-13 Digital Asset Holdings, LLC Digital asset modeling
US11494836B2 (en) 2018-05-06 2022-11-08 Strong Force TX Portfolio 2018, LLC System and method that varies the terms and conditions of a subsidized loan
US11544782B2 (en) 2018-05-06 2023-01-03 Strong Force TX Portfolio 2018, LLC System and method of a smart contract and distributed ledger platform with blockchain custody service
US11550299B2 (en) 2020-02-03 2023-01-10 Strong Force TX Portfolio 2018, LLC Automated robotic process selection and configuration

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020026403A1 (en) * 2000-04-10 2002-02-28 Roger Tambay Systems and methods for facilitating transactions in a commodity marketplace
US6950806B2 (en) * 2000-11-02 2005-09-27 Cargill, Inc. Sales transactions for transfer of commodities

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020026403A1 (en) * 2000-04-10 2002-02-28 Roger Tambay Systems and methods for facilitating transactions in a commodity marketplace
US6950806B2 (en) * 2000-11-02 2005-09-27 Cargill, Inc. Sales transactions for transfer of commodities

Cited By (103)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060161488A1 (en) * 2005-01-14 2006-07-20 Oki Electric Industry Co., Ltd. Data confirming system and data confirming method
US20080015964A1 (en) * 2005-10-25 2008-01-17 Shuster Gary S Retail Price Hedging
US8577698B2 (en) * 2005-10-25 2013-11-05 Intellectual Ventures I Llc Retail price hedging
US20080010147A1 (en) * 2006-07-10 2008-01-10 Ward/Kraft System and method for calculating employee recognition benefits in the form of fuel credits
US20080015981A1 (en) * 2006-07-11 2008-01-17 Andre Danesh Process for supplying fuel
US8156022B2 (en) * 2007-02-12 2012-04-10 Pricelock, Inc. Method and system for providing price protection for commodity purchasing through price protection contracts
US20080313067A1 (en) * 2007-02-12 2008-12-18 Pricelock, Inc. Management and decision making tool for commodity purchases with hedging scenarios
WO2008100897A1 (en) * 2007-02-12 2008-08-21 Pricelock, Inc. Method and system for providing price protection for commodity purchasing through price protection contracts
US20080195432A1 (en) * 2007-02-12 2008-08-14 Fell Robert M Method and system for providing price protection for commodity purchasing through price protection contracts
US8019694B2 (en) 2007-02-12 2011-09-13 Pricelock, Inc. System and method for estimating forward retail commodity price within a geographic boundary
US20080306789A1 (en) * 2007-02-12 2008-12-11 Pricelock, Inc. System and Method for Generating Revenues in a Retail Commodity Network
US20080306858A1 (en) * 2007-02-12 2008-12-11 Pricelock, Inc. System and method for enabling hedging customers to lock forward positions with customer-friendly payment options
US8538795B2 (en) 2007-02-12 2013-09-17 Pricelock, Inc. System and method of determining a retail commodity price within a geographic boundary
US20080306821A1 (en) * 2007-02-12 2008-12-11 Pricelock, Inc. System and Method of Driving Commodity Consumers to Selective Retail Locations
US20080313014A1 (en) * 2007-02-12 2008-12-18 Pricelock, Inc. System and method of determining a retail commodity price within a geographic boundary
WO2008124714A2 (en) * 2007-04-09 2008-10-16 Pricelock, Inc. System and method for index based settlement under price protection contracts
US20080306776A1 (en) * 2007-04-09 2008-12-11 Pricelock, Inc. System and method for risk acceptance in the provisioning of price protection products
WO2008124714A3 (en) * 2007-04-09 2009-12-30 Pricelock, Inc. System and method for index based settlement under price protection contracts
US20080306833A1 (en) * 2007-04-09 2008-12-11 Pricelock, Inc. System and method for constraining depletion amount in a defined time frame
US7945501B2 (en) 2007-04-09 2011-05-17 Pricelock, Inc. System and method for constraining depletion amount in a defined time frame
US7945500B2 (en) 2007-04-09 2011-05-17 Pricelock, Inc. System and method for providing an insurance premium for price protection
US20110178916A1 (en) * 2007-04-09 2011-07-21 Pricelock, Inc. System and method for constraining depletion amount in a defined time frame
US20080306777A1 (en) * 2007-04-09 2008-12-11 Pricelock, Inc. System and method for providing an insurance premium for price protection
US8065218B2 (en) 2007-04-09 2011-11-22 Pricelock, Inc. System and method for providing an insurance premium for price protection
US8086517B2 (en) 2007-04-09 2011-12-27 Pricelock, Inc. System and method for constraining depletion amount in a defined time frame
US7886964B2 (en) * 2007-04-17 2011-02-15 Steinecker Jeffrey T System and method for personalized e-commerce
US20080257957A1 (en) * 2007-04-17 2008-10-23 Steinecker Jeffrey T System and method for personalized e-commerce and information communications
US8412613B2 (en) 2007-04-23 2013-04-02 Bank Of America Corporation Method of hedging retail transactions for fuel
US20080262892A1 (en) * 2007-04-23 2008-10-23 Bank Of America Corporation Method of Hedging Retail Transactions for Fuel
US9547870B1 (en) * 2007-11-02 2017-01-17 Fair Isaac Corporation System and methods for selective advertising
US8160952B1 (en) * 2008-02-12 2012-04-17 Pricelock, Inc. Method and system for providing price protection related to the purchase of a commodity
US8500550B2 (en) 2008-04-24 2013-08-06 Aristocrat Technologies Australia Pty Limited Player tracking method and a player tracking system
US8979640B2 (en) 2008-04-24 2015-03-17 Aristocrat Technologies Australia Pty Limited Player tracking method and a player tracking system
US11531983B2 (en) 2016-04-29 2022-12-20 Digital Asset (Switzerland) GmbH Digital asset modeling
US10803451B2 (en) 2016-04-29 2020-10-13 Digital Asset Holdings, LLC Digital asset modeling
US10810583B2 (en) * 2016-04-29 2020-10-20 Digital Asset Holdings Digital asset modeling
US20180308183A1 (en) * 2017-04-20 2018-10-25 International Business Machines Corporation Facilitating power transactions
US10803535B2 (en) * 2017-04-20 2020-10-13 International Business Machines Corporation Facilitating power transactions
US11720978B2 (en) 2018-05-06 2023-08-08 Strong Force TX Portfolio 2018, LLC Systems and methods for crowdsourcing a condition of collateral
US11688023B2 (en) 2018-05-06 2023-06-27 Strong Force TX Portfolio 2018, LLC System and method of event processing with machine learning
US11494836B2 (en) 2018-05-06 2022-11-08 Strong Force TX Portfolio 2018, LLC System and method that varies the terms and conditions of a subsidized loan
US11501367B2 (en) 2018-05-06 2022-11-15 Strong Force TX Portfolio 2018, LLC System and method of an automated agent to automatically implement loan activities based on loan status
US11514518B2 (en) 2018-05-06 2022-11-29 Strong Force TX Portfolio 2018, LLC System and method of an automated agent to automatically implement loan activities
US11488059B2 (en) 2018-05-06 2022-11-01 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems for providing provable access to a distributed ledger with a tokenized instruction set
US11544782B2 (en) 2018-05-06 2023-01-03 Strong Force TX Portfolio 2018, LLC System and method of a smart contract and distributed ledger platform with blockchain custody service
US11544622B2 (en) 2018-05-06 2023-01-03 Strong Force TX Portfolio 2018, LLC Transaction-enabling systems and methods for customer notification regarding facility provisioning and allocation of resources
US11928747B2 (en) 2018-05-06 2024-03-12 Strong Force TX Portfolio 2018, LLC System and method of an automated agent to automatically implement loan activities based on loan status
US11829907B2 (en) 2018-05-06 2023-11-28 Strong Force TX Portfolio 2018, LLC Systems and methods for aggregating transactions and optimization data related to energy and energy credits
US11580448B2 (en) 2018-05-06 2023-02-14 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems and methods for royalty apportionment and stacking
US11829906B2 (en) 2018-05-06 2023-11-28 Strong Force TX Portfolio 2018, LLC System and method for adjusting a facility configuration based on detected conditions
US11586994B2 (en) 2018-05-06 2023-02-21 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems and methods for providing provable access to a distributed ledger with serverless code logic
US11823098B2 (en) 2018-05-06 2023-11-21 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems and methods to utilize a transaction location in implementing a transaction request
US11599941B2 (en) 2018-05-06 2023-03-07 Strong Force TX Portfolio 2018, LLC System and method of a smart contract that automatically restructures debt loan
US11599940B2 (en) 2018-05-06 2023-03-07 Strong Force TX Portfolio 2018, LLC System and method of automated debt management with machine learning
US11605127B2 (en) 2018-05-06 2023-03-14 Strong Force TX Portfolio 2018, LLC Systems and methods for automatic consideration of jurisdiction in loan related actions
US11605125B2 (en) 2018-05-06 2023-03-14 Strong Force TX Portfolio 2018, LLC System and method of varied terms and conditions of a subsidized loan
US11605124B2 (en) 2018-05-06 2023-03-14 Strong Force TX Portfolio 2018, LLC Systems and methods of smart contract and distributed ledger platform with blockchain authenticity verification
US11609788B2 (en) 2018-05-06 2023-03-21 Strong Force TX Portfolio 2018, LLC Systems and methods related to resource distribution for a fleet of machines
US11610261B2 (en) 2018-05-06 2023-03-21 Strong Force TX Portfolio 2018, LLC System that varies the terms and conditions of a subsidized loan
US11620702B2 (en) 2018-05-06 2023-04-04 Strong Force TX Portfolio 2018, LLC Systems and methods for crowdsourcing information on a guarantor for a loan
US11625792B2 (en) 2018-05-06 2023-04-11 Strong Force TX Portfolio 2018, LLC System and method for automated blockchain custody service for managing a set of custodial assets
US11631145B2 (en) 2018-05-06 2023-04-18 Strong Force TX Portfolio 2018, LLC Systems and methods for automatic loan classification
US11636555B2 (en) 2018-05-06 2023-04-25 Strong Force TX Portfolio 2018, LLC Systems and methods for crowdsourcing condition of guarantor
US11645724B2 (en) 2018-05-06 2023-05-09 Strong Force TX Portfolio 2018, LLC Systems and methods for crowdsourcing information on loan collateral
US11657339B2 (en) 2018-05-06 2023-05-23 Strong Force TX Portfolio 2018, LLC Transaction-enabled methods for providing provable access to a distributed ledger with a tokenized instruction set for a semiconductor fabrication process
US11657340B2 (en) 2018-05-06 2023-05-23 Strong Force TX Portfolio 2018, LLC Transaction-enabled methods for providing provable access to a distributed ledger with a tokenized instruction set for a biological production process
US11657461B2 (en) 2018-05-06 2023-05-23 Strong Force TX Portfolio 2018, LLC System and method of initiating a collateral action based on a smart lending contract
US11669914B2 (en) 2018-05-06 2023-06-06 Strong Force TX Portfolio 2018, LLC Adaptive intelligence and shared infrastructure lending transaction enablement platform responsive to crowd sourced information
US11676219B2 (en) 2018-05-06 2023-06-13 Strong Force TX Portfolio 2018, LLC Systems and methods for leveraging internet of things data to validate an entity
US11681958B2 (en) 2018-05-06 2023-06-20 Strong Force TX Portfolio 2018, LLC Forward market renewable energy credit prediction from human behavioral data
US11687846B2 (en) 2018-05-06 2023-06-27 Strong Force TX Portfolio 2018, LLC Forward market renewable energy credit prediction from automated agent behavioral data
US11494694B2 (en) 2018-05-06 2022-11-08 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems and methods for creating an aggregate stack of intellectual property
US11710084B2 (en) 2018-05-06 2023-07-25 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems and methods for resource acquisition for a fleet of machines
US11715163B2 (en) 2018-05-06 2023-08-01 Strong Force TX Portfolio 2018, LLC Systems and methods for using social network data to validate a loan guarantee
US11715164B2 (en) 2018-05-06 2023-08-01 Strong Force TX Portfolio 2018, LLC Robotic process automation system for negotiation
US20200098063A1 (en) * 2018-05-06 2020-03-26 Strong Force TX Portfolio 2018, LLC Systems and methods for fleet forward energy and energy credits purchase
US11727319B2 (en) 2018-05-06 2023-08-15 Strong Force TX Portfolio 2018, LLC Systems and methods for improving resource utilization for a fleet of machines
US11727505B2 (en) 2018-05-06 2023-08-15 Strong Force TX Portfolio 2018, LLC Systems, methods, and apparatus for consolidating a set of loans
US11727506B2 (en) 2018-05-06 2023-08-15 Strong Force TX Portfolio 2018, LLC Systems and methods for automated loan management based on crowdsourced entity information
US11727504B2 (en) 2018-05-06 2023-08-15 Strong Force TX Portfolio 2018, LLC System and method for automated blockchain custody service for managing a set of custodial assets with block chain authenticity verification
US11727320B2 (en) 2018-05-06 2023-08-15 Strong Force TX Portfolio 2018, LLC Transaction-enabled methods for providing provable access to a distributed ledger with a tokenized instruction set
US11734620B2 (en) 2018-05-06 2023-08-22 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems and methods for identifying and acquiring machine resources on a forward resource market
US11734619B2 (en) 2018-05-06 2023-08-22 Strong Force TX Portfolio 2018, LLC Transaction-enabled systems and methods for predicting a forward market price utilizing external data sources and resource utilization requirements
US11734774B2 (en) 2018-05-06 2023-08-22 Strong Force TX Portfolio 2018, LLC Systems and methods for crowdsourcing data collection for condition classification of bond entities
US11741553B2 (en) 2018-05-06 2023-08-29 Strong Force TX Portfolio 2018, LLC Systems and methods for automatic classification of loan refinancing interactions and outcomes
US11741401B2 (en) 2018-05-06 2023-08-29 Strong Force TX Portfolio 2018, LLC Systems and methods for enabling machine resource transactions for a fleet of machines
US11741402B2 (en) 2018-05-06 2023-08-29 Strong Force TX Portfolio 2018, LLC Systems and methods for forward market purchase of machine resources
US11741552B2 (en) 2018-05-06 2023-08-29 Strong Force TX Portfolio 2018, LLC Systems and methods for automatic classification of loan collection actions
US11748673B2 (en) 2018-05-06 2023-09-05 Strong Force TX Portfolio 2018, LLC Facility level transaction-enabling systems and methods for provisioning and resource allocation
US11748822B2 (en) 2018-05-06 2023-09-05 Strong Force TX Portfolio 2018, LLC Systems and methods for automatically restructuring debt
US11763214B2 (en) 2018-05-06 2023-09-19 Strong Force TX Portfolio 2018, LLC Systems and methods for machine forward energy and energy credit purchase
US11763213B2 (en) 2018-05-06 2023-09-19 Strong Force TX Portfolio 2018, LLC Systems and methods for forward market price prediction and sale of energy credits
US11769217B2 (en) 2018-05-06 2023-09-26 Strong Force TX Portfolio 2018, LLC Systems, methods and apparatus for automatic entity classification based on social media data
US11776069B2 (en) 2018-05-06 2023-10-03 Strong Force TX Portfolio 2018, LLC Systems and methods using IoT input to validate a loan guarantee
US11790287B2 (en) 2018-05-06 2023-10-17 Strong Force TX Portfolio 2018, LLC Systems and methods for machine forward energy and energy storage transactions
US11790286B2 (en) * 2018-05-06 2023-10-17 Strong Force TX Portfolio 2018, LLC Systems and methods for fleet forward energy and energy credits purchase
US11790288B2 (en) 2018-05-06 2023-10-17 Strong Force TX Portfolio 2018, LLC Systems and methods for machine forward energy transactions optimization
US11810027B2 (en) 2018-05-06 2023-11-07 Strong Force TX Portfolio 2018, LLC Systems and methods for enabling machine resource transactions
US11816604B2 (en) 2018-05-06 2023-11-14 Strong Force TX Portfolio 2018, LLC Systems and methods for forward market price prediction and sale of energy storage capacity
US11586177B2 (en) 2020-02-03 2023-02-21 Strong Force TX Portfolio 2018, LLC Robotic process selection and configuration
US11586178B2 (en) 2020-02-03 2023-02-21 Strong Force TX Portfolio 2018, LLC AI solution selection for an automated robotic process
US11567478B2 (en) 2020-02-03 2023-01-31 Strong Force TX Portfolio 2018, LLC Selection and configuration of an automated robotic process
US11550299B2 (en) 2020-02-03 2023-01-10 Strong Force TX Portfolio 2018, LLC Automated robotic process selection and configuration

Similar Documents

Publication Publication Date Title
US20060036530A1 (en) Method and apparatus for facilitating micro energy derivatives transactions on a network system
US6805289B2 (en) Prepaid card payment system and method for electronic commerce
US6260024B1 (en) Method and apparatus for facilitating buyer-driven purchase orders on a commercial network system
US7734527B2 (en) Method and apparatus for making secure electronic payments
AU2005201681B2 (en) Method and apparatus for conducting commerce between individuals
US9129464B2 (en) Staged transactions systems and methods
EP0917119A2 (en) Distributed network based electronic wallet
US20110231283A1 (en) Online Processing for Offshore Business Transactions
US20080114684A1 (en) Termination of transactions
US20180205474A1 (en) Digital Content Downloading System and Method
WO2002046880A2 (en) System and method for push-model fund transfers
WO2002071299A1 (en) Web based system and method for managing business to business online transactions
WO2001035570A1 (en) Payment method and system for online commerce
KR20000037129A (en) Electronic commerce security system and method thereof on internet
WO2014072846A1 (en) Electronic intermediary for secured escrow service. the trustedpayer system
KR20000030790A (en) Electronic Commerce Method & System with Reliability and Protection of Individual Information between Two Parties
KR20010070545A (en) Intermediate transaction method using payment guarantee check issued as collateral for deposit amount of buyer's real name verified financial account in e-commerce and reality
JP2002222380A (en) Shopping settlement surrogate method
KR20050075051A (en) A method and system for dealing a foreign currency
KR20020007440A (en) Method of dual electronic payment service in electronic payment
KR20080072106A (en) Intermediary type b2b electronic trade system and operating method thereof
CA2289395A1 (en) Procurement and settlement system and method
Byron et al. Online Monetary
KR20020008698A (en) Method and system for credit purchasing of electronic commerce on the internet
WO2000067170A1 (en) Payment by card at electronic shopping

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION