This work is licensed under a Creative Commons License.
I designed a new way of making small payments online, with advantages over current systems such as credit cards or PayPal. It uses secret, computer-controlled ("smart") payment codes that can reproduce any number of "children" codes, through any number of generations, creating family trees that inherit options, properties, and services. Anyone with a smart code can pay anyone else who has one. And anybody who buys or is given a smart code can use it immediately, like a universal gift card that can receive money also -- without ever registering, logging in, giving personal information, or having a user name or password.
This payment system could help artists sell downloads of their work at low prices through social networks worldwide, with little or no startup expense or hassle. It could help solve the download-copy problem by allowing supporters of the artist or the art to buy download permissions in bulk and give them away to selected communities, which could pass them on -- so that most downloads could be free while the artist still gets paid for every one. Also, smart codes will help organizations raise money -- especially for causes likely to be recognized as historically important (for reasons explained below).
The estimated processing cost per financial transaction with smart codes is about a tenth of a cent.
This invention happened accidentally. I publish a newsletter, and explored better ways to sell subscriptions online in an increasingly unequal world, when some organizations can best pay for subscriptions on a windfall basis at irregular times. The first step in the design was to abandon the annual or other fixed term, in favor of subscriptions with progressively increasing bulk discounts for any number of issues (downloads) the buyer desires. These future issues could then be subdivided and given or sold in bulk to others who could re-divide them in turn, without the publisher's involvement (requiring the use of computer-controlled, reproducing codes). The next step was to realize that the codes could be denominated in money, instead of issues of a particular publication -- and that reproducing codes can generate "public codes" that receive payment only, allowing any secret code to pay any other while both remain secret. Also, public codes can receive payment by credit card, etc.
I have no proprietary claim to this smart-code design, and am starting a discussion toward open-source development and use.
Anyone who buys or is given a smart code will be able to use it immediately to make purchases online. The new smart-code owner will never need to register, log in, or remember a user name or password, because the code itself is the whole access to the account -- greatly improving ease of startup and use over traditional micropayment systems. This immediate ease of use is critical, explaining why "micropayment" has usually failed, while "gift cards" have recently become a major success.
This system uses "smart" (computer controlled) secret payment codes that can be customized if desired. Each code holds whatever financial value has been put into it, like a gift card (which is often really a code). But each smart code can pay any other smart code, not just a single merchant. And it can have many options and features set or changed by its owner, through a Web control center.
Most importantly, each smart code can reproduce (also through the control center), creating any number of children codes that have part of the financial value of the parent. These children are fully powered smart codes that can also reproduce, and inherit characteristics automatically through any number of generations -- building family trees of payment codes with related but varying features. Setting up or changing features is strictly optional, through the Web control center that every smart code automatically has (but may never use).
Technically, each smart code is a record in a database running on a server. Its control center is one or more Web pages that do not normally exist, but are generated on the fly when needed. The code itself could be part of the URL, or it could be transmitted separately for better security. Options (features, services, etc.) are set or modified by the code's owner (meaning anyone who has the secret code), who has access to the control center, which changes the values of fields in the record in ways provided by the server.
Codes reproduce by creating a new record for each child -- which usually inherits options by simply copying most fields from its parent. Code owners can create hundreds of similar children with one command. Each can have some financial value, subtracted from the value of the parent code.
Anyone with a smart code can also RECEIVE money into it, by having that code reproduce one or more special "public codes" to accept online payments from other people, and transfer the money to its parent. These public smart codes have no financial value and can be published or given to anyone, while the parent code that receives the money remains secret. Each public code has its own Web control center (a Web site open to the public), which can accept payment not only from other smart codes, but also from credit or debit cards or other conventional payment means handled by the server -- easily integrating conventional payments into the smart-code system. The payee never sees the credit-card information, only the server does.
Most importantly, public codes allow any smart code to receive money from any other smart code while both remain secret -- or alternatively, to receive money from credit cards, etc. A standard smart-code transaction requires the secret code to be charged, the public code to be paid, and the transaction amount. Possession of the secret code authorizes that account to be charged. If the secret code is valid and has enough money in it, and is authorized to pay that public code, then the server decrements that account, and increments the account of the parent of the public code. The server knows who the parent is, but the public does not know that.
Each public code provides a separate income stream into the parent code, with its own accounting -- allowing the owner of any smart code to create any number of public codes to test different marketing or fundraising appeals, keep track of sales-team results, etc.
The control centers of public codes are instant Web sites that can provide marketing, fundraising, or other information to the public, whether or not that code accepts money. For example, a fundraising site could show current progress as a daily or weekly bar graph, accurate to the minute and second -- perhaps showing recent additions in a different color so that donors could see their own contribution show up. The control center of the secret parent code (which is not accessible to the public) is used to edit the Web site of any of its public-code children. These minimal sites could only show options provided by the server. But they could link to Web pages elsewhere.
Anyone with a smart code could receive money into it without ever going online. This is because the secret code could have one or more public codes created and delivered with it. In fact, probably all smart codes will have a public code created with them (except for codes deliberately set to be able to spend money only, not receive it). Then almost anybody who gets a smart code will automatically be set up with at least a limited merchant account as well, with no action at all required on their part. If they want additional services, like separate accounting for multiple income streams into their secret code, or public codes with names that they select, then they will need to go online to create the additional public codes.
But note that the smart-code system is designed for SPENDING money only while the buyer is online (or on the telephone, which effectively counts as online even if the buyer never uses a computer). Offline use, such as writing a code on a slip of paper and using it for a purchase, will require that both parties trust each other, and that the party receiving payment through a valuable code properly conceal it before use and destroy it afterwards. Other problems with offline use are that an error in giving the code would not be detected immediately -- and that if the secret code got out, there would be no way to determine who's mistake was responsible. However, with additional technology it would be possible to download cash (while online or by phone) from smart codes into smart cards, which could then make payments offline at a cash register.
Note: the organization running the server and providing the codes could be responsible for disputed credit-card charges, so it will need to have some control over the ability to accept credit or debit cards. The way to handle this technically is that when smart codes reproduce, the owner can set the children to be more restrictive on charge cards than the parent -- but not less restrictive. Permission to accept particular credit cards would then have to be allowed by the server and all ancestor codes. Debit cards are treated more like cash, so permission to accept them could be controlled in the same way, but might be more easily granted.
For most uses a 12-digit random code would be long enough. Twelve digits allows up to a million different secret codes to be issued, while the odds against a guess are at least a million to one. Trial and error would not work to find a valid code, because only the server can tell if a code is valid, and it would recognize an attack long before a million guesses had been tried.
Since public codes do not need to be kept secret, there is no practical limit to how many of them can be issued. With 12-digit codes, if a million secret codes are in use, up to 999,999,000,000 public codes are still available. Another way of looking at it is that if the server charged a penny apiece for them, it would cost almost $10 billion to buy them all.
For some special uses, such as digital admission to a particular event or performance, six random digits may be enough. That would allow up to a thousand paperless tickets to be sold, with the odds against a guess being less than a thousand to one. No one could show up at a theater and try hundreds of different guesses to get in. (Note that each digital ticket could admit not just one individual, but a group of any size, arriving either together or separately.) Six-digit tickets are convenient to transmit by phone, and people could buy them even from their seat in the theater to admit their friends outside.
All-numeric codes would be advantageous internationally, and for cell-phone entry. But in general, the format of smart codes could be entirely open. Owners who created children codes could ask for random numeric or alphanumeric sequences of any length they wanted. Or they could even ask for a particular code, perhaps selected to be easy for them to remember -- taking full responsibility if it is too easy to guess. A smart code could be a single character -- or tens of thousands of characters, such as an exact cut-and-paste of a particular chapter from a book -- or a sequence of Chinese characters (if the intended users could key them in). Some practical limits might be imposed for server efficiency.
Here are several ways that people will get smart codes ordinarily. Keep in mind that these codes are intended primarily for making small purchases online (or by telephone).
(1) Someone who wants a smart code could go to a Web site (or call a phone number) and buy one with a credit or debit card. The seller, who would take no risk since the code would not be given or made active until payment had been approved, would charge a small commission in addition to the credit or debit card fee. Also, additional value could be added to an existing code in this way.
(2) Smart codes could be purchased on cards at retail stores or elsewhere, like telephone cards. Telephone cards already have all-numeric codes that are entered manually by the user (in the U.S. and other countries where few phones can read a magnetic stripe on the card). The same card could work for both -- allowing its value to be spent either for phone calls, or at Web sites or other merchants set up to receive the codes by phone.
Smart codes given out by different organizations can be compatible, provided that the organizations can reach agreement and trust each other, as we have explained in elsewhere (see "For More Information -- Earlier Articles" below).
(3) Smart codes, perhaps printed on cards, could be given as gift cards. They would not need to be restricted to a single merchant, but could be restricted to one or a certain group of merchants if that is what the buyer wanted to do.
(4) Restricted smart codes could be given to patrons of a public library, students in a school, or clients or customers of a business or other organization, allowing limited free access to certain databases, art, or other online material that charged for public access. The library or other organization might pay a reduced, negotiated rate, or sometimes receive the access for free.
Security could be flexible, ranging from unbreakable encryption for protecting large amounts of money, to no security at all for small, restricted, amount-of-purchase payment codes that probably could not be ripped off even if stolen in transit.
The owner of a high-value code would need to have a secure connection with the server. Through that connection, the owner could produce and receive children codes with smaller values. These could be used to limit the total amount that could be lost in case of theft or fraud. Encryption may be necessary for only a minority of transactions.
Note that there is no risk of identity theft with smart codes, since they contain no personal information (except what the owner may choose to enter, such as a shipping address). If the code is stolen, the owner's maximum loss is the value it contains. But the owner could optionally enter a name, arbitrary number, or other safe identification into the code, so that accounting records would clearly show proof of payment by that owner. Or an automatically generated transaction number could show proof of payment.
A smart code given to the Web site automatically created by a public code will never be seen by the payee -- only by the server, which will transfer the money the buyer specifies to the payee. This is the better way to deal with unknown or untrusted payees. But a smart code given to a merchant's site will be accessible to the payee, and could be abused by a dishonest merchant.
A stolen smart code might be of little or no use -- if it is limited to paying for library materials such as scientific articles, for example, or if it is limited to some list of payees but offers no hint of who they are, or if it has a very low value (or no value at all, because it was created for the purchase price only, and already used all its value for that purchase).
Smart codes offer easy cancellation and replacement. If a code may have been compromised, the owner could telephone a special number at the server, type in the code, and that code is immediately gone -- its remaining value transferred to its parent, or to some other pre-set destination the thief would be unlikely to have. Then the owner can have the parent reproduce a new child to create a replacement code. Canceling and replacing a credit card, debit card, or PayPal account is more of a hassle.
The danger of attack on the server and theft of all the codes could largely be prevented by using a one-way hash function, a familiar technique in computer security. Only the owner and no one else in the world would have the original secret code; the server would not keep any copy, only the value it hashed into. When a code was submitted for payment (or submitted by the owner for maintenance), the server would hash the code and destroy the original, then use the hashed value to look up the appropriate record in the database (if any). Even if the entire code database including all the hashed codes were stolen, and the theft were unsuspected, the server could keep operating as before, authenticating valid codes as they came in and using them to authorize payment or maintenance. The thief could tell if a given code was valid or not, and know how much value it contained at the time of the theft, and which record was its parent, but would have to get the code first -- and would have no way of identifying any code owners, if they did not include personal information in the database. The thief could try billions of guesses quickly -- but the relatively few codes worth stealing could be protected by a code length great enough to stop a brute-force attack.
While good security looks possible, I see smart codes as primarily for micropayment, handling small amounts online. For example, Starbucks limits the value of its card to $500 -- making many kinds of attack not worth doing. Large amounts raise additional issues and require more expensive security.
We listed the following mainly to help clarify what the smart-code system is. For better lists of uses and advantages, see Smart Codes: Online Micropayment for Artists and Fundraisers, with Payment Codes That Reproduce, and other earlier articles.
LOW PROCESSING COST: In most cases the estimated processing cost per smart-code financial transaction will be about a tenth of a cent or less. This estimate is based on storage and bandwidth pricing for commercial Web hosting. The storage, bandwidth, and computation requirements of smart codes are all minimal. More expensive services such as downloaded or streaming video should be priced separately, not as part of the financial-transaction cost. Telephone support should seldom be necessary, but when it is, it could be priced separately as well.
PAYMENT RESTRICTIONS: Smart codes can be restricted to an approved list of payees -- either statically (a fixed list of public codes they can pay), or dynamically (a list of trusted Web sites that list acceptable public codes, changing as necessary to keep up with events). Uses can vary greatly, from parental controls, to gift recommendations, to donors who want to pay for access to particular artists or information.
CURRENCY EXCHANGE: Smart-code currency exchange between certain countries could be free in one direction, since opposite money flows between each pair of countries would tend to balance each other, and flows in the unpopular direction would actually reduce the cost to the server of buying currency commercially.
PayPal supports five currencies for its mass-payment system. A smart-code server might allow both buyers and sellers to work transparently in whichever of several currencies they desired, handling the exchange automatically. When necessary a clearly displayed currency-exchange fee would be added to the selling price.
ACCOUNTING: All transaction information will be maintained on the server, which can easily give code owners many choices of accounting reports -- either for particular codes, or for entire families of related codes.
Every transaction will have a unique, permanent transaction number in the system, which can be used to show proof of payment. It will be given to both parties, and also recorded for both parties automatically on the server, accessible forever through their secret codes.
Note that this transaction number is NOT a smart code, as it has no Web control center.
GETTING MONEY OUT OF A SMART CODE: This is not a problem. For example, a business could receive payment by smart code, deduct a service charge, and mail you a check. You could optionally have your smart code provide a mailing address along with the payment, and in that case you would not even need to have an account. Or banks and other financial institutions where you do have an account could transfer the money from your code directly into it.
ANOTHER WAY TO PAY: A small but real advantage of smart codes is that just having a different payment option will stimulate commerce, by offering greater convenience at times. Some transactions will happen that otherwise would not occur.
IDEAL FOR WI-FI PAYMENT, SENDING EMAIL: Probably most laptop Wi-Fi users avoid non-free services at coffeehouses even when money is no issue, because of the hassles of maintaining all the different accounts. Smart codes would let users pay for whatever time or bandwidth they wanted, and take care of all the accounting through options set using the control center. Hassle-free money would show up in the service provider's account, at rates higher than those paid by regular subscribers.
A problem with most free Wi-Fi is sending email from a laptop using one's regular POP accounts. Smart codes would allow coffeehouses, etc. to offer free Wi-Fi service as they do today, but charge a small amount for each email sent, and/or require a code sold to customers at the cash register, deterring spammers. Or customers could register their own codes with different coffeehouses, allowing them to use the same authentication code everywhere to send email, and to pay usage charges if any.
NON-PAYMENT USES: The same smart codes used for payments could have many non-financial uses as well. For example, they could provide access to restricted data online under any rules desired. Children codes that allowed only one access a day, that could not further reproduce, that documented every use, and that could be cancelled instantly by anyone who had them, would not get loose into widespread circulation. In this case the monetary value in the code might not be zero, but a small amount to pay the transaction fees for years to come; no billing would be necessary, as the server could take the money out of the code automatically, per agreement. Or to take another example, codes could be designed to be guessed, for contests that could be announced on the radio or online. The control center could tell the winner how to claim the money. Or the code itself could contain the prize money, which the winner would have to spend immediately to prevent another winner from doing so first.
This smart-code system largely eliminates the need to have a large base of users in order to be worth using -- commonly a big impediment to improvement of many technologies. One reason why is that no one ever needs to sign up for smart codes -- they can just buy or be given a smart code, and start buying from or selling to anyone else who has one. Merchants who offer smart-code payment can also receive credit-card payments into their codes, even from customers who have never heard of smart codes. And if a buyer needs to pay only a small amount such as 20 cents to download an article, he or she can pay more by credit card, and get a smart code in "change" to use later on the same Web site, or on many others. (This is a great way to introduce new people to the smart-code system, since most people are reluctant to walk away from financial value, and willing to learn something new to avoid doing so.)
Even a smart-code test set up by a small organization, if done well, could possibly spread on its own throughout the world. Its customers could pay and receive money from each other, attracting new merchants and customers, organizations and donors. Smart-code transactions use very little bandwidth, memory, or computation, and equipment could be upgraded as necessary.
And rival smart-code systems could be made compatible with each other even if they were not designed that way in advance, through an agreed communication protocol that could be added later -- meaning that anybody with a code on one system could pay or receive payment from anybody with a code on another. (Different smart-code servers can only be compatible if the organizations providing them can trust each other to operate honestly, and reimburse the occasional debts that arise due to more selling on one system and more buying on another.)
Smart codes could help artists reach their audiences directly, offering their work for sale throughout the world at zero set-up expense. The small cost of providing the codes could be paid in many ways, for example by a percentage of the sales -- meaning that the code provider benefits from the success of their clients, not from demanding prohibitive upfront costs or humiliating terms for the chance to reach an audience.
And smart codes will assist social-network marketing, by integrating payment from individual end users with payment from donors, friends, or supporters of the artist or the work, who can afford to buy bulk download permissions for emailing to their friends or associates as a contribution to them and to the artist. For example, a supporter of the artist might buy a Web link containing a smart code good for 100 downloads, and email it to any number of friends or list members, and/or perhaps donate it for public use on a specialized art or music site.
Then most or all of the resulting downloads could be free to the end user, while the artist still gets paid for every one. And whenever the downloads in a Web link are exhausted, those who click on the link will get a payment page allowing them to pay for their own copy, and/or buy a new link with multiple downloads for their friends, and/or buy as many downloads as they wish to instantly recharge all copies of the old link, wherever they are throughout the world. And these donors can set a deadline on their money, after which any unspent portion will automatically return to them -- so that they are paying only for work that people want.
[Technically this works because all the copies of the link use the same smart code on the server -- and that code's options are set so that its value is denominated in downloads rather than money, since downloads will often be sold for different amounts, due to quantity discounts, special offers, etc. To allow multiple donors to the same link to put different conditions on their donations, the server must allow multiple funds within the same smart code, so that each donor can have his or her own deadline, and his or her own return code for unspent money. Incidentally, the code's control center is not directly involved in keeping track of the number of downloads, since its only purpose is to interface with the human owner of the code. The control center does not even exist unless a person is using it at the time. It only sets options that later affect the processing transactions as they come in.]
Smart codes could help artists or musicians even in remote areas where there are no computers or modern communication. In this case, a trusted organization or individual would record or photograph the work and make it available for downloading throughout the world. Free samples could be provided (and might be designed to be used in visual or music collages by other artists), free codes good for 10 or 50 downloads might be given out as prizes for contests, and other simple promotions could help to spread the word, provided there really is a constituency for the work. Income from sales would accumulate in a smart code, from which it could be transferred to the artists in any feasible way.
This smart-code design does not do copy protection or other digital rights management (although that could be added). I think it will not be needed for the main intended use of this system, which is to allow artists to easily reach social-network markets, often with novel or experimental material -- not for reaching mass markets. An artist could charge a low price such as 20 cents to download a copy, and a friend or supporter of that artist could buy hundreds of downloads, repackage them if desired into multiple children codes embedded in Web links, and distribute the links they had paid for to people they knew -- who could redistribute grandchildren codes if they liked the art, or simply email the links. When any code runs out of downloads, anyone who tried to use it could recharge it -- as could anyone else who had the code, whether it was exhausted or not. Artists could aim for sustainability or takeoff within a narrow segment of potential fans worldwide -- meaning that enough people care so that each free download would on the average generate payment for at least one more, until the market segment became saturated and sustainability was lost.
Note that smart codes can easily receive payment in many languages (as well as in multiple currencies for those relatively rare occasions when payment is needed). A row of clickable flags in the control-center Web site could allow users to change both the language and the currency whenever necessary. The artist who started with a smart code that was to become the parent of all these codes could use its control center to simply mark a checkbox to obtain the row of flags for that code, providing all language and currency options handled by that server -- options then automatically inherited by all its children and descendents.
Also note that as the flow of downloads propagates out through social networks, it automatically seeks out the communities that do appreciate the art, as these are the ones where the bulk sales and free downloads will approach or reach sustainability. Neither the artist nor anyone else need know in advance where the work will go. Artists will be able to reach fans directly, without going through corporations that impose their own agendas. And this marketing runs on two legs (end users, and friends/supporters, two groups working together) while conventional marketing of music or other content is to end users alone.
Instead of blocking free copies in order to force fans to pay the artist, smart codes facilitate cooperative marketing so everyone gets what they want -- the casual fan or curious explorer who wants free downloads, the artist who needs to get paid, and the donor -- a friend or serious fan who can afford to give but wants a rational context for doing so, instead of dropping a check into the unknown.
Payment for scientific and medical journals is a serious problem today. Basically only big universities and corporations get good access. Small schools get spotty or poor access, and individuals get the worst of all. This is a particular issue in medicine, where information involves everybody's health, and the public has already paid for most medical research through taxes. Smart codes would not solve the problem, but would make it easier for journals to sell bulk access to agencies that would market to individuals, small schools, small businesses, and other occasional users who are largely excluded today.
Many popular newspapers and magazines have articles on their Web sites for subscribers only. This does not work even when money is not an issue, because many people need occasional articles from dozens or hundreds of newspapers or magazines, and do not want the hassle of managing hundreds of subscriptions, each with its junk mail, automatic renewal problems, etc. Today most potential readers do without the article, or use the public library, and the publisher gets nothing; probably most readers abandon even free articles that demand registration only. Everyone would be better off if the publisher could charge maybe 20 cents or a dollar for an article with no hassle for either party, and pay a few pennies or less for the transaction. Smart codes will make this possible.
Payment options for Web-based "content" today are a mess -- a big reason why selling content online is so difficult. Many people just leave premium sites because of the hassle, even if they have plenty of money and are willing to spend it. A radical simplification would benefit everybody.
Giving free or discounted access with smart codes is more complicated than it may seem. Just charging less for a multi-vendor smart code is not a good option, because smart codes are usually denominated in money, and it would be confusing to have both regular money and also funny money worth only 50% or 75% of its nominal value. Customers could alternatively be given discounts through special public codes, but then it would be hard to prevent these from getting out and being used by unauthorized parties.
The problem can be seen if a vendor of online content (art, databases, etc.) wants to give low-cost access to public libraries for their patrons, while charging full price for other customers. The vendor will sell the library a code that the library may use to make hundreds of children or other descendent codes, each limited to a fairly small value, to be given to patrons on request. When the patron submits this code to the vendor for payment, how will the vendor know it is from a library? The library could tell the vendor about all the codes it generates, but this would be a serious administrative burden. The vendor knows the parent code because the vendor sold it to the library, but the library cannot release that to patrons because it must be kept secret.
This problem could be solved by invisible discount codes. The vendor will give the library or libraries a special public code for their use, restricted to libraries only, and this public code will charge the agreed discounted amount. The way the public code will be restricted is that the vendor will have the server generate a discount code (a number long enough to prevent guessing, but not a smart code because it has no Web control center of its own), when creating the smart code that will be given to the library to use as the parent of all the codes for its patrons. This code will embedded invisibly both in the newly created parent code (in a Buyers Discount variable-length field, which is able to hold any number of discount codes), and also in vendor's public code that will be used by the libraries (in a Sellers Discount variable-length field).
When the parent code reproduces the children, grandchildren, etc. to be given to the library patrons, the discount code will be inherited by all the descendents. But the library will never see that code, which will only exist at the server. In fact, the vendor may never see the discount code either (although it would not hurt to allow the vendor to do so, if the need ever arises).
Now the patron will log into the Web site that is the control center of the public code (or alternatively will log into the vendor's site, and give the public code there, indicating the discount), and make any selections of what to download. The price charged to the library may or may not be shown, depending on what the library decides.
When the patron makes the purchase, the transaction goes to the code server. It sees in the vendor's record that the vendor requires a discount code to be present. So it checks to make sure that at least one code in the Buyers Discount field of the code used by the patron matches a code in the Sellers Discount field of the vendor. If there is no match, the transaction is rejected with a message saying that Web site is restricted to library patrons only. Otherwise the sale goes through as normal.
This system assumes that the library and the vendor are using the same code server. As we have explained elsewhere (not in this article), different code servers can be compatible if their operators agree, allowing buyers on one to purchase from sellers on the other. The above discount system will not work across servers, however, without a messy need to transmit confidential information between them, when the transaction has to be completed rapidly to avoid an annoying delay. I suspect the problem could be solved by allowing one server to virtually "borrow" a code on another, but have not yet worked this out.
Meanwhile it will not be a problem that libraries and their vendors will need to use the same code server, in order to do library discounts. The overhead of getting a new smart code is negligible, so institutions or even individuals will easily be able to use different codes for different purposes.
Two other important discount situations are easier to handle, because they are special cases. In both of them there is no problem with the buyer and seller having codes on different servers, because all that takes place is a standard purchase.
(1) Many companies give out discount codes in newspaper ads, etc. In this case only one vendor is involved -- and anyone who has the code is authorized to use it (but maybe only the first 500 customers or whatever). So the customer can just select the merchandise and enter the code on the Web site, and see if the deal is still available.
(2) The music downloads discussed above also involve a single vendor (a single musician, artist, or publisher, or a group of artists offering a common pool of works at the same price). In fact, often a particular smart-code Web link will be for a single song or other work (another song by the same or other artist will use a separate public code, so that listeners can choose to support whichever they like). In either case the server will need to allow an option for a smart code to be denominated in downloads instead of money. Its cash value will be zero, but a separate Downloads field will be available, and each time the work is downloaded, its value will decrease by one. If no downloads are left, a Web page will require payment in money (by smart code, credit or debit card, etc.), and offer increasing discounts for larger bulk purchases of downloads.
Sometimes free access would require no code at all. For example, a medical journal might decide to provide free online access to developing countries, where few could afford to pay. For the server to recognize which ISPs qualified could be complex, with options, negotiations and exceptions developing over time. But this would only have to be done once, and then any journal using that server could simply check a box at its Web control center to provide free access to all countries internationally listed as developing or least-developed. If ambiguities remain about whether a particular access qualifies as free or not, then each journal could choose among a number of different options that handle the ambiguities in different ways.
Another path to donating free access would be to use the discount codes described above, giving 100% discount at Web pages set up for that purpose. For convenience, different journals could agree to recognize the same codes, although this would not be necessary; customers are used to using a different site for each journal today. Smart codes with the discount code(s) secretly embedded could be used as parent codes by nonprofits or others organizations trusted by the server to use them properly; these organizations would then give descendents to those needing free access. Codes that got out and were sold or otherwise abused could be detected through usage patterns (which could be analyzed instantly), and cancelled with or without human intervention at whatever level of the hierarchy (family tree of smart codes) was required. New codes could be issued as necessary for legitimate users. Some ongoing abuse would be likely, but it would have to stay limited enough to be discrete, or the codes involved would go away.
Here is something so new and unprecedented that it may look bizarre -- but it seems to be workable. Smart codes could assist in fundraising for potentially historic organizations or causes, by giving financial or other contributions an entirely new kind of value as investments -- dated, authenticated artifacts that can be displayed to the public, traded among collectors, sold at auctions, etc. throughout the future. They could develop value as collectables far higher than the amount contributed. This creates an entirely new motive to donate, working in synergy with all existing motives to help important organizations raise money.
The idea requires the creation of an archival organization with computer backup and financial endowment, able to provide credible assurance that it can maintain an archival smart-code database for decades or centuries into the future (assuming that human life, and the Web or a successor, continue to exist in some form). The actual expense of maintaining the database would be minimal, because the usage of the archival smart codes would be very low, perhaps averaging around one access per year. Credible archiving will create the possibility that codes themselves can become digital collectable artifacts.
Note that each secret smart code can create any number of public codes that can be given out freely -- each one of which automatically has a public Web site, which can display a desired view of the contents of the secret code. So even though the archival code itself must be kept secret, it can still be put on public display. When the secret code is sold, the new owner can use the code to change it to a new code, assuring exclusive possession.
The startup path for using this system will be very easy, once credible archiving has been set up. An organization that is raising funds anyway could get a smart code, and place into it some of the history of what it is doing that year, perhaps with links to photos, videos, etc. Then it can produce any number of secret children codes, which automatically inherit this history, to give to donors. Each donor, along with the standard acknowledgement of the contribution, will also receive a sheet titled something like, "Save This Code (and Keep It Secret); It Could Be Valuable Some Day". The rest of the sheet would include the unique code (maybe a 16-digit number), explain what it was, and tell them how to use it to reach the control center and create public codes they could give to anyone. The code owner (the donor) could not change the history entered by the recipient organization (as that is preserved for future users), but could change or delete its display through the public codes. And of course the owner could destroy the code entirely.
The owner could also add his or her own account to the history (which that owner could change, but future owners could not -- once the name of the code has been changed by a new owner, all current history will be locked in). Codes owned by a series of leaders, celebrities, or other well-known figures could develop additional value for this reason. (Note that the value as a collectable is totally different from the cash value of the code, which will usually be zero.)
Codes will probably be traded (in part) by year. The fact that the code actually was issued in that year will be date stamped and locked in by the server. It is too late to get a 2004 donation code -- none exist, and none ever will. But maybe they will for 2005 or 2006.
Could a digital code develop value as a collectable artifact? It seems likely. Everyone is familiar with digital objects, and everyone knows that codes can have financial value. And these artifacts can easily be displayed around the world through the Web, with each display customized as desired. Obtaining, showing, discussing, and trading these history codes is a social process. They will tell what happened in participants' own words, and this record will grow over time as successive owners add additional history.
Supplies are limited because once a year is over, no more codes for that year can be issued. And sometimes the date that counts will not be a new calendar year, but a particular event. Donors should be alert to get their contributions in, before it is too late forever.
People ask what advantages smart codes have over PayPal. While PayPal is in many ways an excellent payment system, it is not as flexible or as easy for beginners as people assume. Here are some areas where I think the smart-code design will be superior:
(1) A public library could not open a PayPal account and use it to generate 500 new PayPal accounts to give its patrons limited, customized access to certain premium articles, art, or databases -- while automatically canceling any lost accounts and returning their value to the library, without any human attention at all. But the library could put money into a smart code, and use it to generate hundreds of smart codes holding a few dollars each, restricted to certain public codes of artists, publications or databases for which the library had decided to buy access. Payment would occur only when a patron requested specific material -- generating statistics that would help the library justify the funding. The codes could pay negotiated rates to each artist's or publisher's site. Each new code could be printed on a sheet of paper, with instructions listing sites that accepted that code, which the patron would type into a box on the Web site automatically generated by that public code (or other Web site the publisher set up). A lost code could simply be replaced, since it would automatically expire and return its value at a time the library had set. (This capability of buying customized access will expand the market for artists, by allowing libraries to easily pay small amounts for downloads from selected sites, when clients asked for them.)
(2) A PayPal account cannot instantly create any number of public Web sites, each with its own separate income stream and income accounting, and each able to accept payments by smart code, credit card, PayPal, or otherwise. A smart code can, since it can generate any number of public codes, each with its own Web site (smart-code control center, often used as a public Web site for public codes) and its own accounting.
(3) PayPal has automatic payment options, but apparently cannot instantly pay sales taxes, commissions, royalties, donations, or other payments you request, fully automatically whenever money comes in. Smart codes can, if the server provides options for setting up such automatic payments, which it certainly will.
(4) PayPal accounts probably cannot request payment only when a supply of prepaid music or other downloads is exhausted -- and then offer deals for extra payment to re-stock that supply for the customer's electronic community, for some other community, or for the general public.
(5) Your PayPal account cannot negotiate with publishers' sites on your behalf, kicking the purchasing decision upstairs to the human (you) only if the robots fail to reach agreement. (For more information, see discussion of robot negotiation in Smart Codes: Online Micropayment for Artists and Fundraisers, with Payment Codes That Reproduce.)
(6) The smart-code per-transaction cost is very low, a small fraction of the cost of PayPal -- which is more than 30 cents a transaction, ruling out low prices. (Credit cards are even worse.)
(7) Smart codes are easier than PayPal to start using, since anyone who receives a code can simply paste it into a single field in Web sites to make purchases, with no sign-up process required. Getting a new person signed up for PayPal is not as easy and trouble-free.
(8) Of course there is no PayPal equivalent to the potential use of smart codes to give donations additional investment value as digital collectables. And there are other unique uses of smart codes as well -- such as establishing the original of a digital work of art, by allowing it to be regenerated with the new owner's photos, writing, voice, favorite tunes, or other content included, under the control of the artist -- preserving the unique value of the original work, no matter how many copies of copies are made.
This introduction has only noted a few of the countless advantages of what could be called "smart money" (general-purpose computerized payment instruments that can offer any options and features their server is programmed to provide). This smart-code design, based on payment codes that can reproduce and inherit features, is only one way to do smart money. It has the advantage of exceptionally easy startup, low cost, and suitability for small-business and small-payment use -- exactly what many artists need to be able to sell their work throughout the world, from anywhere.
The writeups below are often not coordinated with each other, because they were "defensive publication" intended to prevent parts of this system from being patented and denied to public use. Later I may organize this information into a single paper that describes all the ideas.
See Smart Code Startup for suggestions on how artists, fundraisers, merchants, and others could feasibly introduce smart codes -- and for more details on how smart codes work. Or see Smart Codes: 12 Advantages Over Other Online Payment Systems.
For an earlier and longer description, see Smart Codes: Online Micropayment for Artists and Fundraisers, with Payment Codes That Reproduce, January 2005
For another description, see Micropayment with Smart Codes That Can Reproduce, October 28, 2004. Some clarifications and additions to this summary were added in an addendum, November 14, 2004.
For more details see a longer article, "Micropayment Smart Codes for Small Business, Arts, Fundraising: A Better Way to Pay Online," at http://www.communicationpractices.org/micropayment/draft2004-10-07.html.
If you think something stated here will not work, let me know and I will either explain it or fix it.
Watch for a blog to continue this discussion, at our home page, www.MicropaymentSmartCodes.com
Privacy statement: we won't send advertisements or give out your email to anyone, and you can get off our list at any time.
Micropayment for online purchasing was disappointing for years, but may be ready for a comeback. The next big commercial push may be in instant messaging (SMS, short message service), using one's phone to pay for music, tickets, games, etc. An advantage of smart codes here (in addition to all the other advantages) is that people will be able to pay for event tickets and other non-telephone items through their phone, without going through their phone company.
Here are some places to look for micropayment information:
One excellent short article, including interesting examples of some currently successful systems, is "Micropayment Systems: Giving Your Two Cents, Digitally," on Joe Kissell's Interesting Thing of the Day, at http://itotd.com/index.alt?ArticleID=376
Try a Google search on "micropayment 2005" or "micropayment 2004" (without the quotation marks), or just "micropayment". Look through the top 50 or so links.
BitPass -- www.bitpass.com -- sells content online, apparently successfully. Also see Palo Alto Weekly article, January 28, 2004.
AlloPass -- http://www.en.allopass.com/ -- lets you restrict part of your Web site; users call AlloPass to buy a code, charged to their phone bill or a credit card, to access the restricted documents. The Web-site operator gets about half the cost of the call or less, depending on the country the user is calling from, mainly due to phone-company charges. This European system is even more expensive for U.S. or Canadian callers.
Visit www.simpay.com for information on micropayment and SMS.
The Amazon Honor System is a voluntary micropayment service started in 2001 for supporting small Web sites (and one big one). It is expensive, but important for showing that there is a demand for an easy way for visitors to contribute to Web sites they like. (I don't like the name, however, as there is no dishonor in not making a voluntary contribution.) You really can give money with one click, if you have turned that option on at the Amazon site -- and you can revoke the gift as well. For information visit www.Amazon.com and click on "Honor System" (in the left-hand column toward the bottom of the page).
The U. S. Patent and Trademark Office has 57 patents that mention "micropayment" -- and over 111 published patent applications (as of January 27, 2005). Visit www.uspto.gov -- and under Patents (in the left-hand column) click Search. You can start with a Quick Search for "micropayment" -- both in Issued Patents, and also in Published Applications. If the title looks interesting, click on it and read the abstract or full text.
Watch this space for more links.
John S. James, Philadelphia
Contact john2james at gmail dot com
This work is licensed under a Creative Commons License.