Addendum 2004-11-14 to "Micropayment with Smart Codes That Can Reproduce"

By John S. James

Here are some additions and clarification to the October 28, 2004 article

• Payments to public codes: Anyone can make a payment to someone else's public smart code through a credit card, Paypal, or other conventional means, even if they never get a smart code of their own. This is possible because the public code gives access to its control center on the Web, which can provide instructions and/or forms for any means of payment that the merchant accepts and the server supports. Therefore a merchant who simply buys a smart code, which can cost little or nothing, already has the machinery in place to receive payments from anybody through one or more public codes, if the code provider gives that merchant permission to do so.
• Fundraising: I outlined some exotic and apparently new uses for smart codes in fundraising, but should have also noted the obvious: the hierarchical public codes provide an easy way to keep track of the results of different volunteers, teams, appeals, and campaigns. Programs like the AIDS walk and breast-cancer run work on the principle that people are asked by their friends, and can support their friends socially while giving to the cause financially at the same time. Smart codes do the same, but offer additional options. Anyone can take a public code given to them by their friend (or published widely by someone in the news), make a donation to it online (either by credit card, etc. or by their own smart code), and leave a note online with the donation if they wish. Or if they had a smart code, they could create a new secret smart code for the exact amount of the donation, perhaps give it a memorable name, and phone it to their friend or write it out on a piece of paper. Their friend could enter the code without even remembering the amount donated (if the giver asked for a code that, once submitted to the server of the public coded, would transfer its full value). Such codes would probably be made irrevocable for 30 days or so, and if not used by then would automatically cancel, returning their full value to the donor (through the parent code that the donor used to create the donation). This way the donor could not possibly overdraw the account and cause the gift code to be rejected, or otherwise cancel the gift, and yet if the code were lost, all of the money in it would be returned.
• Flexible code formats: Codes can be any length, or can be all numeric, or can be words or phrases, at any time. The defaults we suggested (8 random alphanumeric characters not case sensitive, or 12 random numeric digits) provide at least enough security for most uses, but users may change this (at their own risk), sacrificing security for convenience, especially for low-value codes where there is little to lose in case of fraud. Users may also create longer codes for increased security. Some servers may decide to accept only numeric codes for better international compatibility (as well as for ease of use with cell phones); in that case owners of alphanumeric codes could use them to generate numeric codes when necessary. And public codes have no security needs, so merchants could choose easy words that people could use to make payments to them; of course they could not do so if someone else had already chosen that word on that server. Code providers might charge for certain custom public codes, in order to help control squatting. In any case, a standard format for payment through public codes might be one word that identifies the server, followed by the code itself (which could be either a random sequence, or a meaningful word or phrase chosen by the merchant).
• Code server compatibility without agreement on technical standards: No agreement on code or internal data formats, etc. is needed, because only the server that issued a code can process charges against it. Therefore, when a buyer on one code server pays a seller on a different server (by using a secret code of the buyer and a public code of the seller), the only role of the seller's server in accomplishing the transaction is to securely deliver the buyer's code and the amount of the sale to the buyer's server, and to receive a secure message that the code has been charged (or rejected). If the buyer's server uses a different code alphabet (for example, Chinese characters), there may be a problem delivering the code through computer equipment not set up to handle it. Only for this reason do we suggest that all code servers should be able to produce numeric-only codes if asked. Of course a communication protocol must be agreed among the servers, but this can be added on later -- meaning that different code servers can go into business now and not worry about compatibility, since the only compatibility required will be in software created or purchased later. And even if companies refuse to agree and there are competing communication protocols in use, transactions will still work as long as the buyer's and seller's servers support at least one communication protocol in common. All this provides an easy uptake path, since any organization with digital content to sell (or even certain other goods or services, such as tickets to events) could start selling smart codes on its own, and know that its codes will almost automatically be compatible with whatever smart-code systems other organizations may develop in the future. And needless to say, smart-code software could be sold or leased to financial organizations, so that the companies that develop the software, the companies or individuals that sell the codes, and the companies that handle the money, could all be different.
• Disputes about payments: In case of a dispute about charges, the control center for a secret code can show a history of all transactions with that code. Alternatively, a parent or other ancestor code could provide that information (unless deliberately blocked) in a report including all descendent codes. If someone pays using a public code, whatever he or she used to make payment with (a secret smart code, a credit card, etc.) will have a record showing that payment. Because the smart-code system gives users a complete accounting of all money into and out of their codes, and also gives them the means to limit their risk when dealing with an unknown merchant, standard agreements could state that the code owner would assume small risks, and the smart-code provider would not be expected to spend human time investigating disputes less than some agreed amount.
• Codes restricted to certain uses -- how they work: Restricted codes can be used for parental controls, or to pay for particular gifts in preference to giving money by leaving the code unrestricted. (I believe they could also be used in spam control, to allow email users to charge a fee for receipt of mail from strangers, with an easy start-up path because it could work even if implemented by a single ISP or even a single email user, without waiting for general agreements; however the details of doing this are not yet fully worked out.) The restrictions are enforced by creating a private gift smart code that will only pay certain public codes and not any others; if any other public code is submitted in a payment request, it will be rejected. With gifts, for example, merchants could cooperate by creating a separate public code for each popular gift item; this would take a little work but would make sales easier. The sequence is that the giver would use his or her private smart code to reach its control center, and ask it to create a new private smart code that could only be used to pay one or more specified public codes; optionally a gift certificate could be printed so that the recipient could order by telephone without going online. Then the recipient (either online, through an automated phone system, or by calling a person to place the order) would reach the control center of the gift code and choose one of the gifts available, which would bring him or her to the control center for that public code, which is customized by the seller; options like color and size of the gift, or method of delivery, could be entered at this time through a form or buttons, or that process could be automated through an optional smart-code profile entered by the gift recipient. When the buyer (the recipient) confirms that the order is correct, the seller's server will charge the buyer's gift code, transferring the money into the (seller's) private code that created the public code for the merchandise item. If the buyer and seller are using different code servers, then the organizations that run them will accumulate debts to each other; these will be reconciled periodically.
• Flexible security through family trees of codes: A business or other organization can simply buy a code from anyone, and use it to create public codes that others can use to make payments to it (with smart codes, credit or debit cards, or other means) -- but is subject to rules imposed by all ancestor codes, up to the code server itself (or more likely, a broker used by the code server as an intermediary), which maintains the merchant accounts with the various credit-card and other financial companies. Therefore a serious business would probably want to deal directly with the broker, in order to have only one party to negotiate with. Note that the merchant never sees the credit-card numbers used to make payments to it, because these go to the broker (or code server), which charges the credit cards and applies the payment to the secret smart code of the payee. This greatly reduces the possibility of theft or other abuse of the credit-card information. However, the broker is still ultimately responsible if a payer demands a refund -- so the more the broker can trust the payee, the better rates and terms it can give. For very small businesses run by unknowns, such as a new artist who wants to use micropayment to test the market for his or her work, payments could be limited to small amounts, perhaps $5 per payee and $50 total per day, allowing easy trial arrangements under terms that could be liberalized as the parties come to know and trust each other. A big advantage of this system is that the broker could set up merchant accounts only once, with many different credit and debit cards and other means of payment, including of course any smart codes that could be charged successfully -- and all the overhead work of setting up these accounts would immediately be available to each new payee to use this system, under whatever rules and limitations the broker felt necessary to protect itself from misuse. (Note that when a payment cannot be received because a limit has been reached, the smart-code's control center need not say so, but can simply provide a message from the payee asking the payer to send a check, or use other payment means that do not go through the broker.) The long-term advantage of this system in the great flexibility, in which the broker could offer many different payment options to anyone from day one, with a whole range of different payment limits or other restrictions as necessary.
• One-time permission codes [internal use, not seen by end user]: When a customer buys a download of a song, article, photograph, or other content, a different server may be used to provide the download (not the server that manages the smart codes). In this case the code server needs to send an authorization to the computer that does the download, in a way that cannot be forged with fake authorization messages. Since micropayment systems are intended to allow sales at very low prices, the cost of maintaining secure connections at all times among the servers could become problematic. A less expensive way would be for the code server to initially send the downloading server a list of say, 1000 nine-digit random numbers to be used to authenticate permissions; this file would be encrypted or otherwise securely transmitted. Later, when a download was purchased, the code server would send the instructions for downloading with the next random code in sequence -- with no encryption or secure transmission required; the downloading server would compare this code with the next one in the sequence of 1000 (or request a new sequence if needed). These codes could not be fraudulently harvested in transit for later use, because as soon as they were received they would be used to give the authorization, and then would become worthless, since they could never be used again. In theory a criminal could intercept the transmissiion and use the code to gain one fraudulent download. But since all they could get by doing so would be a song or other artwork (usually of little monetary value, in a micropayment system) they would find that this crime does not pay. And the chance against guessing a nine-digit code is a billion (1,000,000,000) to one.
• Archiving codes in perpetuity: I proposed certain uses of smart codes that would require them to be kept in service indefinitely, allowing anyone to reach an active control center for that code -- for example, to authenticate donations to historically important causes, enabling them to develop value as collectables. The infrastructure do to so -- corporate organization, finance, contracts, insurance, mirrored servers, encryption, security, etc. -- will have other uses as well, reducing the effective cost of permanently archiving smart codes. A recent New York Times article, "Even Digital Memories Can Fade" by Kathie Hafner, 2004-11-10, shows how serious the archiving problem is; it notes that the Web may be the best way to preserve much of the information -- except for the risk that the companies now archiving it may not be around in the future. This article became the most-emailed one on its day of publication -- supporting my hunch that millions of people will pay for reasonable assurance that their stories, writings, voice, art, photos and voices of friends, art they own, Web sites, etc., would be preserved and remain available to anyone for centuries. (Of course code owners could change their minds, and use their codes to edit or delete their material.) Smart codes could piggyback cheaply on this archiving activity -- especially since the storage, computation and bandwidth requirements are very small, and especially small for archival use. And beyond piggybacking, smart codes provide an excellent system to control access to this material, since the code owner has full access, and can give limited and highly customized access to others through children codes. For example, ten friends could have conditional edit permission, such that any of them could make changes conditionally, and a specified large majority could approve those changes without the approval of the owner -- allowing removal of embarrassing material in case the owner dies unexpectedly and his or her code is lost, while allowing a living owner to cancel any changes and revoke any permission(s) he or she has given to others. And of course the owner would not have to give any edit permission to anyone
• Big picture -- computer cash allows new era in money: Digital cash should not be seen as only an easier way to pay online. Instead, computerized money can do all sorts of things that money could not easily do before: reproduce generations of customized payment instruments through control centers; flexibly limit potential losses; automatically identify users or not identify them; negotiate with sellers' robots on their owner's behalf; compute multiple license fees, commissions, or increased royalties to artists, and automatically make these payments immediately; keep all accounting records of payments into or out of each code for as long as desired; do currency exchange automatically when needed, asking the buyer's approval or not, as instructed by the buyer (or only asking if the cost of the exchange seems excessive in view of current rates); allow charitable or "cause" donations to be re-"sold" to other donors, and to develop value as collectables; and so on, all for a guesstimated cost of about a tenth of a cent for each money transfer. All sorts of experiments will become possible. The limiting factor today seems to be the cumbersomeness of setting up digital-money accounts (requiring end users to enter personal information, remember various user names and passwords, and log in repeatedly), and some barriers to adding new merchants. Our "smart code" proposal seems to eliminate these problems, since users never need to register or log in, and new merchants can add themselves simply by obtaining a code. Anyone can be given a smart code and start using it immediately to make purchases or donations; and anyone can make payments to merchants or others through public smart codes (even buyers who have never had a smart code of their own). Different code servers can be developed independently, with different technical standards, and yet still work together seamlessly for merchants and customers alike -- facilitating rapid, widespread, non-monopoly adoption of this kind of digital-money system.
• Notes on ease of startup:
  • Anyone can purchase or be given a smart code and use it immediately to pay for purchases or to create new smart codes, without even having to open an account. In fact, there are no user names or passwords in this system, no registration or logging in, as there is such thing as accounts (except for the codes themselves) -- pretty much eliminating start-up hassle for new users. The codes, through their control centers, can provide access to any service offered by the broker who runs the code server.
  • Anyone can make payments to a public code with a credit card, Paypal, or other conventional means if the server has a merchant account, even if they have never had a smart code (or they can pay with a smart code if they do have one) -- encouraging merchants to use this system since they can use it to do business with anyone, not only those already involved. And the public codes can be mnemonic or promotional, since they do not need to be hard to guess.
  • Anyone with a smart code can immediately make a new smart code for any lesser value they choose, limiting risk of loss if they pay an untrusted merchant.
  • New merchants can join this system simply by buying a smart code, and using it to create public codes through which their customers can pay them. In practice they would need permission, but that is not required by the smart-code technology.
  • Smart codes only make payments to other smart codes -- or to the owner who is withdrawing money from a code. But companies that bill their customers, like other merchants, can buy one or more smart codes and use them to create public codes through which bills can be paid by smart code, online or by phone.
  • The buyer and seller can be on different code servers, which can manage the transaction seamlessly even if they were programmed by different teams using no common technical standards at all -- meaning that there is no natural monopoly in providing these payment codes, since there is no significant cost of having competing providers. Only the communication protocol on top of the servers needs to be standard, and there can be multiple communication standards in use, as long as the servers processing codes for the buyer and seller can find one in common.
• Legality and permission: This site looks at what is technically possible -- not what is or should be allowed, as that is a different decision. Technically, for example, the "smart code" system described here would enable even a child to buy a code from a classmate for a penny, and within a few minutes create and distribute public codes that can receive payments online from around the world (through other smart codes, or credit cards if the code provider that runs the server has a merchant account, or other means provided by the server). Obviously there will have to be controls, and what they might be is beyond the scope of this description. But the flexibility of computerized payment will highlight the need to design money that works for people -- and highlight the fact that modern poverty is primarily an institutional choice, not personal flaws, an accident, or a fact of nature.

John S. James, 2004-11-12
jjamesXXX@MicropaymentSmartCodes.com [see note below]
People: remove the XXX from the email address. (Spam robots: leave it in.)

----------------------------------------

This work is licensed under a Creative Commons License.