This work is licensed under a Creative Commons License.
Summary: A good way to pay small amounts of money online would help writers, musicians, and other artists make a living from their work and reach new audiences as well. For example, a blog or other Web site could charge as little as five or ten cents for a song, a story, an essay, an answer to a question, or a joke of the week; then someone who liked it could buy a link that includes a code good for, say, 50 uses, email the link to their friends, and automatically be refunded any unused value remaining (after 30 days or whatever other expiration they chose). Such easily shared paid access, requiring no signup or registration at all, would create a new kind of easy, low-cost gift that supports the artists, opening new possibilities for grassroots business.
I learned how to do this while exploring ways to sell a newsletter online. But the system could have wider uses:
The key innovation is to use short, prepaid, secret codes that can pay for goods or services online -- but also can reach a Web control center that allows each code to create any number of new, customized codes with different values, either for personal use or for sale or distribution to others. These fully powered descendent codes can also reproduce, through any number of generations. An eight-character length allows a million million (1,000,000,000,000) different codes -- allowing a million to be issued through a given Web site and be active at one time, with the odds against guessing any correct code being less than a million to one. The code itself is both "user name" and "password" combined.
For a full description, see http://www.MicropaymentSmartCodes.com
John S. James, jjamesXXX@MicropaymentSmartCodes.com, October 7, 2004
People: remove the XXX from the email address. (Spam robots: leave it in.)
----------------------------------------
A prepaid secret code, used mainly for online payment, could also provide a control center, allowing its owner to create any number of customized new codes -- descendents that can also reproduce, through any number of generations, creating both secret and public codes with many uses. This simple idea leads to astonishing consequences.
----------------------------------------
Here's a way for writers or artists to charge five cents, 50 cents, 5 dollars, or whatever for an article, song, or image online. It also supports digital tickets, so that people attending shows can telephone admission to their friends immediately, even when they cannot get paper tickets to them. In fundraising, it can authenticate a contribution -- so that a donor can make a large gift up front, then re-"sell" portions of it to his or her friends, who can re-sell portions to their friends in turn. Micropayment smart codes may even allow donations to historically important causes to develop investment value as collectables, independent of their nominal amounts -- opening a new avenue of fundraising appeal.
The idea is to sell prepaid, secret codes (like digital gift certificates), for any amount the customer chooses to spend. What's new is that these micropayment smart codes ("smart codes" for short) also let owners use a control center, on the Web site of the issuing organization, to create any number of new, additional smart codes of any value (up to the total available in the original "parent" code) -- either for personal uses, or to give or sell to others. Each of these descendent codes has its own control center and can create descendents of its own, for any number of generations. Each new code can be customized or restricted if desired. Think of a smart code as a cross between a digital gift certificate, and a rabbit.
"Smart" means that each code has its own control center on the Web. Most importantly, this control center allows a code owner to immediately issue new, fully powered codes. Most customers will use their code only to pay for goods or services, not to create new codes. But they can still benefit from the flexibility of such a payment system.
For example, a specialty music site could publish and sell low-price downloads of works by artists not otherwise available -- perhaps advertising their work by creating new compositions from free samples offered by the artists. A nonprofit or small-business site could become a leading source for cutting-edge work within its specialty, as much of that music could not be purchased elsewhere. The artists could have an income and reach new audiences as well. With smart codes the prices could be low (such as 5 or 10 cents to hear a song, most or all of it going to the artist), and fans could easily share paid access with their friends.
Also, a merchant could use a secret smart code to create any number of custom public codes -- smart codes that can be published or otherwise distributed because they have no monetary value to others, but are used to place orders and make payment to the secret code that generated them. Basically this means that whoever has a smart code for any purpose can immediately start receiving payments online. (Credibility could be acknowledged through listings on Web sites of rating agencies or other trusted organizations.)
The fact that anyone could immediately receive payment online could be problematic. For example, even a child might start a business, club, or church in half an hour, and ask people around the world to send money. Such activity could be franchised, with one party providing technical, legal, and marketing support, and the other providing the constituency and/or story. There could be important benefits (in rapid, credible fundraising for disaster relief, for example), as well as possible abuses. What's new is easy payment online, as anyone can already receive payment in cash.
I developed the smart-code idea accidentally while working on another project. I have no proprietary interest in it, and offer it for public discussion and use. Micropayment smart codes could help people make a living doing work they love, outside "the system" -- something much needed today.
New uses and implications keep turning up. It is amazing that so simple an idea may have such far-reaching consequences.
Smart codes are usually short (4-8 alphanumeric character), truly random sequences, generated by a Web server that keeps a database of all codes it ever creates. (Users can optionally have the server replace the random sequence with any name they choose, of any length, as long as that name is not already in use in the database.) These codes serve as user name and password combined, allowing their owner to make payments that decrement the value of the code. The owner may also log on to the server and use some or all of the code's value to create any number of new smart codes.
In the simplest case, smart codes could be provided by a single organization that has a digital product to sell online (such as writing, music, images, or database access). Customers could buy these prepaid codes for any amount and use them to make purchases -- even for amounts too small to pay conveniently online by other means. The user can type in the code and have the browser or Web site remember it. Or the user could set up "zero-click" purchasing limits and rules that would pay some small charges automatically, requiring attention and confirmation only for charges outside those rules.
As with a digital gift certificate, when the code is used to pay for goods or services, the payment amount will be decremented from the code's value. Or if not enough value remains for the purchase, the payment will be rejected.
But the smart-code buyer could also use the same code to log in at a Web site of the organization that issued the code, and reach a control center for that particular code. The control center will show the remaining value, and provides various options inherited through the code's ancestors. These options can include the power to create any number of additional smart codes (secret or public); these are remembered by the server as descendents of the original. And these new codes can create descendents of their own.
The key innovation of smart codes is that each one can easily produce any number of new, fully powered, customized smart codes -- for all sorts of purposes, some of which are outlined below -- without the trouble of setting up new accounts. Friends and associates can share these codes with others, who can start using them immediately.
This system could spread easily, because new users will be introduced by receiving a code that they can use immediately. They don't need to register, set up an account, or remember a separate password. The code itself is the whole account.
Both merchants and customers can receive value into their codes from anyone, through public codes that they create and distribute, using their secret code's control center.
Every smart code (by definition) offers some form of access to a control center -- although probably most customers will only buy goods or services with their code, and never even see its control center. This paper deals with the codes themselves, their use to make payment and for other purposes, and their ability to reproduce and create new codes. It mentions various services in describing potential uses of the codes, but does not go into detail.
The servers that provide the control centers will also need to control these services -- such as delivery of songs, articles, or other content, processing orders for merchandise that needs to be shipped, regenerating digital art with the new owner's photos or other input if the artist provided for that, creating digital movie tickets, validating donations and allowing them to be subdivided, etc. The code servers could either provide such content directly, or just authenticate the smart codes and send authorization to servers elsewhere. Each organization that offers smart codes will have a menu of options that they may contain.
The services chosen for any code will usually be available also to its descendents, if the person creating the descendents wants them included. Services not included in a code will usually be unavailable to all of its descendents. The goal is not to put every service into every code, but to design the codes for particular uses, giving them the services that are necessary.
Smart codes can and should be as short as possible -- so that they can easily be given to friends or associates, in a telephone call for example. The length required depends on the maximum number of codes that may need to be issued, and the amount of security required. (Most commercial codes in use today are much too long, apparently because organizations go overboard on security; for example, the Starbucks card has a 16-digit code, enough to give 10 cards to every man, woman, and child on Earth, with odds against a guess hitting any valid code being less than one in 100,000.)
For smart codes, eight alphanumeric characters allows more than a million million (1,000,000,000,000) codes -- so a million random ones could be issued and used, and still the odds against a guess reaching any correct code would be less than a million to one (for calculations see the paragraph at the end of this section). For most purposes this should be enough. While code-breaking computers can easily test millions of passwords, that would not work in this case, because the only way to test a truly random code is to submit it to the server that issued it, which would recognize an attack long before a million guesses had been tried.
Or for a different example, a code to admit up to 1,000 people to a particular movie, lecture, game, or other event -- with less than one in a thousand chance of a random guess being correct -- would need only four characters. The thousand-to-one chance against guessing is enough in this case, as nobody could show up at a theater and try hundreds of guesses to get in.
Code designers should not make users distinguish between upper and lower case letters, because that's a hassle for people, especially when giving codes to each other by telephone.
Calculations: For a quick, conservative estimate of how many different smart codes are possible for any given length, note that there are 36 alphanumeric characters (26 letters and 10 digits); therefore two alphanumeric characters gives over 1000 different combinations. So four characters gives over a million codes, and eight gives over a million million. We think that eight characters will generally be used -- allowing a million codes to be given out with the odds against a guess being more than a million to one (or ten million to be given out with the odds against a guess more than 100,000 to one). And a very lucky guess would only allow the theft of money (if any) in that one particular code, and not compromise the rest of system.
Smart codes can have monetary value, and anyone who has the code can use it, so codes will have to be kept secret. This is analogous to credit-card information, and the technology for secure transmission could be used for the codes as well. In most cases it may not be necessary, however, as smart codes will usually have a small value, being intended for micropayment online. And they will generally be difficult to convert to cash, and will keep records of all transactions. Fraudulent use of small-value codes may not be profitable enough to become widespread.
The rare codes created with a large value could have a confirmation mechanism -- such as sending a random sequence to the owner's email address, which would have to be returned for transactions to go through (in case of a large transactions, or many significant small ones, or an attempt to use the control center to change the name or other properties of the code). Or the server could request a PIN. The owner could use these more secure codes to create more convenient, smaller ones for everyday use.
For more on security, see two sections below:
"Reassurance: You Can't Lose More Than the Value of the Code"
and
"Fraud Protection: Who Is Responsible for Theft?"
The codes discussed above need to be kept secret, because anyone who has one can spend the money it holds. But this micropayment system can be greatly extended by "public" codes. These can be given to anybody, because they allow the user to make payments into an account but not take money out. Note: we will use the term "secret code" to refer to a smart code that is not public. Incidentally, this system does not involve public-key cryptography.
As explained above, a smart code can generate any number of descendent smart codes. A public code is just one of those descendents, but one that has been marked to contain no cash value. Instead it receives value for its parent -- and it can take orders, and perform other services. One smart code can generate any number of these public codes (as well as any number of secret codes), so that its owner (usually a merchant or fundraiser) can see which marketing efforts are producing results.
Like any smart codes, public codes give access to a control center, which takes orders, receives contributions, etc. A default control center would exist automatically. Of course the organization creating a public code could place their own material or Web links at the control center reached by that code, so that they can include product advertisements or fundraising appeals. The secret code that created the public code allows the owner to add or change this material. Usually changes would be to the default -- so that new public codes would be created ready to go, without needing to be modified individually.
A secret code can create any number of public codes, even millions -- each with its own control center of course. There is no practical limit.
Some uses of public codes:
Someone could buy a micropayment smart code for a fairly large value (say $100 -- either for convenience or to get discounts), and use it to create a smaller code (say $10) to carry with them, leaving the original (parent) code safely at home. If the code is stolen, only $10 is at risk. And if the code is lost (and not actually used fraudulently), then nothing at all is at risk (since any remaining value can be cancelled and retrieved by the parent code, as explained below).
Buyers could give a small code to merchants they do not know, limiting their exposure to the purchase price, or other amount they control. They could create a new code only for that transaction, for the exact amount required -- or for convenience, use a code they happened to have with them that did not have much extra value. The merchant will only see whether or not the code works, and will not know that the buyer took this precaution.
At any time a code owner could cancel all remaining value of any code he or she created, by logging in to the Web control center of the code's parent and canceling the unwanted code, adding the value to the parent.
Also, a customer who has given their code to a merchant he or she does not fully trust can go to the control center for that code, after the merchant has been paid, and ask for a replacement. All remaining value is transferred to a new code that the merchant, and others who may have received or seen the original secret code, do not have.
The practical result is that owners can use these codes without fear, even on untrusted Web sites where they would not want to give a credit card. Services like Paypal also provide such protection. But a smart code is easier to use, because it does not require a new user to set up an account, nor enter any information except the code itself and the amount to be charged. And the code can come from anyone, not just one company.
Suppose at the last minute you want to invite friends to a show, but there's no way to meet to give them tickets in advance, and no will-call window. If you have a smart code that the theater accepts, you can phone it to your friends, who can use it for admission instead of a paper ticket. If the show might sell out, you or they can call the theater in advance and charge the code immediately, reserving a seat.
Note that one code can admit any designated number of people -- whether they arrive in a single party, in multiple parties, or individually, and whether they have already charged the code and reserved their seats, or only have the code but have not charged it yet, and will do so if space is available.
As noted above, a code for movie admission might be only four alphanumeric characters, since that would allow a thousand codes to be issued with a chance of a successful guess less than 1 in a thousand.
While no paper ticket need be created (a receipt for re-entry to the theater would be enough), it might be operationally easier to go through the existing ticket system. Customers could purchase tickets at the box office either with cash or with a code that would be charged through the theater's computer for the number of tickets requested. Since the valid codes would apply only to that particular show, there would be a limited number of them, so a paper backup could be held in reserve in case of computer failure.
A big problem in public and university libraries today is that each library buys a negotiated package of access to certain publications and other databases. Big organizations, especially the largest universities, can give their users most of the journals, etc. they need. Small organizations usually have much less.
It was always true that big universities subscribed to more journals than small ones. The key difference today is that the scarcity is entirely artificial. It would probably cost less to provide newspaper or journal access to everyone than to restrict it to certain schools or libraries.
Smart codes cannot fix this problem but might help us live with it. Libraries could use these codes to buy bulk access to publications and databases that they would otherwise not have, and give limited access to clients who had particular needs that could not be met by the databases purchased for unlimited use. (Librarians may have such access today, but they would have to use their own account, which they could not give to clients.)
The library could buy a high-value code and generate many small-value codes for clients. It's much easier for a library just give a reader a code for limited access, than to set up a new account with a user name and password.
If the reader loses the code, no problem. It could be set to expire automatically after a certain time (such as 30 days). At that time any unused value would revert to the parent code -- the one the library used to generate codes for its clients.
So the library can replace a lost smart code simply by giving the reader a new one. No action by anyone is required to retrieve the value remaining in the code that was lost. The code has no cash value, since it will only work at that library system. And the library does not need to set up a system to help readers with lost passwords, nor spend the time to do so.
As noted above, a secret smart code can create any number of public smart codes, each of which can receive payment into the secret code.
As a precaution, the organization providing the secret codes may require a contract with any merchant that wants to receive payment through the codes and get cash back. This control -- the fact that smart-code value could not be exchanged for cash except by special arrangement -- could help prevent the codes from having street value, reducing potential for theft or abuse.
But a very small business that did not want any cash back, and would only use profits to make other purchases with its secret code, would not need any agreement or permission. The founder would only need to buy a smart code (for a cost as low as one cent, or even zero), create a public code, and start receiving payments. This ease of getting started would encourage people to check out business ideas, see which ones worked, and do the formalities only for those that have already shown promise. Anyone could start a new business or organization immediately and receive payments or donations online, as long as they could get others to send them money.
Here is how a merchant transaction would work in practice. Somebody who had a secret micropayment smart code and wanted to make a purchase from a merchant, or wanted to make a donation to a cause or charity, would get the merchant's or organization's public code from a source they trusted (such as the entity they wanted to pay, or a trusted Web site, or a friend). They would use that code to log in to its control center, which would always have at least a form for entering the amount of payment and the smart code they wanted to charge. They would enter the information and save the receipt returned, including a new secret code that gave proof of the purchase or donation. The money would be subtracted from the buyer's smart code, and added to merchant's smart code (the parent of the merchant's public code).
When smart codes are used to make purchases, the value available must be checked (and decremented) in the database that originally issued the code. Many competing smart-code systems may be set up -- in fact, we probably don't want a monopoly, one company that provides the only smart codes in general use. But if there are many competing code system, your code might not work for the seller or other payee you wanted to deal with, who used a code from another company. How could this problem be handled?
The public codes suggested above help, because they make it easy for many new merchants to sign up to receive payment through a particular code-issuing system.
But the key advance would be to make the control center for a public code able to deal with other code servers. When someone wanted to use that public code to pay the merchant or organization with their own smart code, but their code was issued by a different organization (a different code server and database), they would put in not only their secret code and the amount to charge against it, but also the name of their code server. All smart-code servers that chose to do so would recognize a standard set of names.
Similarly, different code-issuing organizations do not need to agree on a single communication protocol in order to work together. More than one protocol could be in use, as long as the organizations could agree on a common set of names for them. Probably the code server serving the buyer would specify which protocol the other server would have to use to do business with it. The merchant and customer would not see any difference.
Then when a buyer makes a purchase (probably by logging on to the seller's server, using the seller's public code), the seller's server would receive the buyer's secret code, and submit it with the purchase amount to the buyer's server. The code's value would be decremented, and an approval returned to the seller. Each server would generate a transaction code, which could be used to prove the transaction occurred if necessary.
The different code-issuing organizations would periodically need to settle accounts with each other, especially if some dealt mostly with sellers and others mostly with buyers. This would be handled by contracts between them, with the software keeping track of the amounts due.
Both code-issuing organizations will have incentive to make the system work, since each has a client involved.
Note: different code databases or domains do not interfere with each other. If two different organizations each issue codes that are eight alphanumeric characters, entering a valid code into the wrong server would be just like entering a random guess into it. Smart codes are already designed to protect against that, usually with more than a million to one odds against a guess. The fact that the code is valid on some other server makes no difference.
Smart codes could work as gift certificates. There would be no card or certificate to transfer, so the gift itself could be given in a personal conversation or by phone -- great for last-minute shoppers. On the other hand, a good-looking gift card or certificates could be produced, online or not, optionally customized with the buyer's photographs or other art (which could be integrated into the design in many ways, not just inserted into it).
Unlike conventional gift certificates, smart codes need not be restricted to one merchant.
The traditional physical gift has the greatest restriction of all -- it is a single item with no choice by the recipient. Unless, of course, the gift is cash, in which case it has the least restriction and offers the greatest choice, namely anything that amount of money can buy. Smart-code gifts could occupy many places in between. For example, a code could have a fixed value that could be spent on any one or more of several recommended gifts.
Celebrities, organizations, or just anybody could publish recommended lists of gifts for certain kinds of people -- preferably in a standard format on a Web page. Then somebody who wanted to give a choice of recommended gifts could go to his or her own code's control center, create a new smart code as the gift, choose a dollar value, and enter one or more Web sites where standard-format gift lists reside. The new code would be generated with a combined list of all the recommended gifts that could be purchased for the value provided by the giver. The gift code (like any smart code) would have its own control center, and the recipient could log in to see or search the list of choices -- or receive a printed list from the giver -- or make a phone call and enter a number provided to hear the list and make a selection. After the first selection, the gifts that could still be purchased with the remaining value could be presented again. The gifts chosen could be drop-shipped, picked up at stores with the secret code, or otherwise delivered to the recipient.
A buyer with a prepaid secret code can use its control center to set percentage donations to one or more charities or other beneficiaries; these payment will be made as the money in the code is spent. The code owner can change this setup at any time.
Similarly a merchant can use its secret code to set donation percentages for associated public codes -- an easy way to have a certain percentage of sales contributed to a designated charity, instantly as the sales are made.
Suppose a trusted work team wants to spend money on a project they are doing together. One way would be to give each person a separate smart code. But if it's not known in advance how much of the total expenditure each person will need to make, some team members may run out unexpectedly and have to refill their codes (which could be done through the parent code, by anyone who knew that code).
Another approach is to let everyone use the same code, which has all the money budgeted for the expenses the group needs to use smart codes for. But then the code makes no record of who spent what.
Collective codes -- an option that could be provided in the control center, for use when new codes are made -- allows a team of smart codes to each have access to the full value of the parent code. Each member of the work group gets one of these team codes -- and can spend as needed, up to the full budgeted amount (or what remains of it). But the expenditure of each group member is recorded.
Every smart code will be born either revocable or irrevocable. Revocable means that the creator can cancel it and take the value back. Most codes would be revocable so that if lost, the value could be retrieved -- as in the library example above. Revocable status would probably be binding on all future generations; otherwise, for example, library clients could shield value in their codes from being refunded to the library if not used by the expiration date.
Codes created for resale would be irrevocable. As soon as they were sold the value would be immediately transferred in the server, so that even if the code seller went bankrupt, the buyer would not be affected. (Bankruptcy of code-issuing organizations would be more serious, so they might be expected to carry insurance against losing the value of the prepaid codes they sold.)
Smart codes could be created with other restrictions, such as parental controls, and these would be binding on all later generations (otherwise it would be easy to overcome them). For example, parents could restrict codes to certain movies or other entertainment for their children. The children could use the code to create new codes for their friends, but these would be limited to purchasing the same movies, etc. as the original. Organizations could publish lists of movies or other gifts that they recommend for children, and the code-issuer could provide these lists as a courtesy to its customers. Parents could then check off the organization(s) they trusted when creating a code for their children, and the code would be enabled to make any purchase recommended. This could be handled much like the gift codes above.
There could be other restrictions in addition, such as a maximum amount that could be spent per week, like an allowance.
These restrictions could not be changed through the code's control center, to which the children would have access. But the parent could change the restrictions, through the control center of the "parent" code -- the direct ancestor code that created the restricted code.
When a new code is created from a parent code, it will be given a random name by the server, typically four to eight alphanumeric characters. However, the person creating the code can override that name with a custom name or phrase of any length. The only restriction is that the name cannot already be in use by another smart code in the database.
The most obvious use for a custom name would be to make codes easier to remember, and easier to give to friends. Of course the owner would be responsible for not making the name too easy to guess. (Some code names could be created for the purpose of being guessed, however -- in a contest, for example.)
Smart codes with customized names could be used for promotions or contests. For example, the first ten people to find the answer to a radio contest could use that answer (a smart code) to reach a special Web page, where they could enter their name and address and have a $100 check sent. Of course they could call their friends and tell them, and this would be part of the drama. Or if that wasn't what the sponsor wanted, there could be ten different answers, each good for one check.
The code names could be anything -- even whole creeds or other documents that could be cut and pasted verbatim into Web forms. Or a name could be short -- even a single number or letter.
Zero-click purchasing lets users set rules for automatic purchases under certain conditions. For example, someone who likes to browse among proprietary newspaper archives might set 10 cents as the most they would pay automatically to read an article they selected. They could buy this way from sites they had never visited before and had no relationship with. They might not even know they had been charged (unless they wanted to be informed) -- only that any charges were according to the rules they set up, and that in no case could they lose more than the code's value. If the price were more than 10 cents, for example (or if there were more than, say, three charges in ten minutes), they would be asked to accept or reject the charge. Publishers will have an incentive to keep their prices low, in order to meet the zero-click limits of more of their customers and get these automatic sales.
Users could also set the maximum number of purchases allowed automatically at any visit. They would use their code's control center to turn on zero click, and set the maximum price, maximum number of charges per minute, and perhaps other options as well.
We think that people will be reassured by the fact that they can lose no more than the total value of their code -- enough to try the risk of making purchases with no human intervention, in return for the convenience of not having to repeatedly approve very small purchases.
One of the problems of browsing or reading from newspaper sites especially is that most now insist on "one-time" registration. If you visit dozens of different newspapers, that's not one but dozens of registrations. And a new computer requires having each user name and password, or starting the process over.
If you are giving a smart code to the site anyway (for making purchases), the code might help by remembering your information (name, junk-mail address, etc.) and providing it automatically if the site was set up to receive it. The code could remember a standard user name and password as well. Of course you could falsify the information, but no more than if you had to type it in manually for each site. And the sites may not care much if the personal data is false; they may be more interested in correctly combining their many Web sessions into separate users, or in demographics like age and ZIP.
These codes could also be used on a public terminal as well, giving automatic access to all your low-value accounts.
A dishonest merchant could remember a customer's code and charge it again without authorization. But any transaction benefiting the merchant's account would be recorded permanently in the database of the organization providing the codes (as would any other transaction).
What if a buyer used a stolen code, and the legitimate owner could prove ownership and said the transaction was not authorized? With credit cards, the card issuer usually pays, after a small amount; if the cardholder were stuck for the complete cost of the fraudulent use, people would be afraid to use credit cards.
But smart codes give the buyer great control over their exposure to loss. They cannot lose more than the value of a code -- and they can create new codes at any time for value they want. They can leave larger codes safe at home (or well encrypted in a portable computer). They can cancel a code at any time and get back all remaining value -- or conveniently replace the code, so that the previous code becomes worthless. If they lose a code that they created, they can go to the parent code that created it and take back the full value.
Smart-code users who wanted more security might be able to go the control center and create an optional PIN of any length, including any word or phrase, that would have to be used to charge the code; if they forget the PIN, the parent code can still take the value back. And an additional protection is provided by the fact that a code does a thief no good, without the knowledge of which organization's server recognizes it. Many of these protections are not available to credit or debit card users.
In addition, smart codes are prepaid and designed for convenience in micropayment. They are not intended or needed for transferring large amounts of money.
For these reasons I think it makes sense to leave the owner of smart codes responsible for loss due to fraud or theft. This could greatly reduce the cost of issuing codes, by largely avoiding the need for insurance and adjudication. Hopefully smart codes will be free for customers, and be provided by merchants to increase sales.
Of course the code owners would not be responsible if someone obtained their codes by breaking into the database of the organization that issued them.
Certainly the Web sites that issued codes would have to be trusted to not steal from their clients or others who did business with them. As always, people would deal with organizations they trust, and rating agencies could list those that met their standards. In case of doubt, a buyer could create a code for the exact amount required, avoiding any loss greater than the purchase price.
A smart-code database necessarily makes a record of every transaction, showing the flow of money from the time it enters the system when a prepaid code is purchased, as it moves from code to code, until it leaves in payment to a merchant or other payee. There are business reasons to save these records, in case a dispute should arise in the future. The transaction codes generated allow the buyer and seller to reprint the receipt and other information in case of need (without requiring staff time from the code-issuing organization). But this transaction code is meaningful only as long as the transaction record is preserved in the database on the server.
In addition, the use of smart codes for authentication (see below) would require that they be preserved indefinitely.
For these reasons it may become standard practice that all records are kept. The only way to make anonymous payments would be to pay cash for a code. And even in that case the online transactions could probably be traced.
But while this system does support truly anonymous payment, confidentiality is a different issue. For example, if someone wanted to make an "anonymous" contribution through a public code of the recipient, they should be able to do so. The information would still exist in the server, and law enforcement could subpoena these records. But ordinarily nobody would know who made the donation.
Will a smart-code owner who creates descendent codes be able to see how they are used? If the code is sold commercially, the answer should be no. But what if parents create codes for their children? One possibility would be that they could choose whether to monitor their children's use of the codes or not -- but if they did, there would be some indication or way for the children to know that this was happening. That puts the monitoring above board, out of the spying realm.
Many such confidentiality and privacy issues will likely need to be discussed and negotiated -- especially involving the flow of information and control up and down the chain of ancestors and descendents. Code-issuing organizations will make these decisions, and build their reputations accordingly.
A micropayment smart code can authenticate a particular donation to a charitable or cause organization as follows. The organization (or its server) gives the donor a secret smart code showing the value of the donation. But this code is marked as a donation acknowledgement, meaning that its value cannot be spent for goods or services.
At any time the donor could use this smart code to create a public code to prove that the donation occurred. But that may not be necessary.
Instead, the donor could use the secret code to create one or more new secret smart codes, each assigned part of the value of the original donation. These new codes would automatically be marked as donation acknowledgements. The donor could "sell" these new codes to friends and associates who wanted to help support the organization. The buyer could always check the control center of their secret code and confirm that the stated donation had indeed been made to the organization.
And the buyer of that part of the donation could in turn sell off portions of it to other, perhaps with additional matching. This process could repeat through any number of generations.
In this way donors could make larger contributions than otherwise, because they have a convenient way of sharing their donations with friends or associates. Today, organizations often use fundraising event tickets for such sharing; a board member or other major donor might buy 50 tickets, sell some to friends or other donors, and cover the rest personally.
Smart codes have the advantage over event tickets that they never expire (so long as the code database remains available on a Web server). The donor could sell off parts of the contribution even years later, if circumstances change and he or she needed the money. Perhaps an aftermarket could develop, a gift economy in which donations would be permanently in circulation, being carried by those supporters who could afford to do so at the time.
For historically important causes, such authenticated donations could become investments -- potentially developing value as collectables much greater than their original or nominal value. Collection value could be enhanced for donations made or re-sold by celebrities. The fact that a donation could also become an investment will help raise funds for some of the most important causes.
These donation codes could be used to print certificates suitable for hanging or framing, showing the history of that particular donation, and how it fit into the development of the cause. But the value would be in the code -- not in the certificate, which could always be reprinted by whoever has the code.
The permanence and therefore investment value of the donation smart code depends on the permanent maintenance of the database that gives access to the code's control center, which shows that the code is authentic, along with showing the original amount donated, and other history information. But eventually the issuing organization will be gone (even if its historic importance and interest remain). How can the smart codes be made permanent?
It could be done through a contract with a backup and archiving organization. For a fee, this organization would periodically receive an encrypted copy of the database, with complete information about all smart codes that organization had issued. If the information became inaccessible through its sponsoring organization for more than an agreed period of time, the archiving organization would decrypt the backup and make it publicly available through its own Web site, possibly on a read-only basis. Providing such access would cost little; therefore a modest endowment could finance it in perpetuity.
The archiving organization would also provide emergency backup, in case of destruction of other copies of the data.
Authenticating digital art is more complex than authenticating a charitable donation. Basically the art will live on the server as a series of files or database entries (probably encrypted). The smart code provides access to allow new (and possibly modified) image or music files to be made.
The rules governing these copies are set by the artist, as part of the work. For example, the artist might sell 50 numbered codes allowing numbered copies to be made. The server enforces this restriction, so there is no need to copy-protect any data.
The artist could also design the work so that it could optionally be recomposed, integrating digital photographs, sounds, or other digital content provided by the owner (see "Designing for Digital Customization," below). Only someone who possessed the code could recompose the work with his or her own material integrated.
Therefore exclusive ownership of the code would constitute ownership of the original (or of an authorized numbered copy). Public codes could give limited access online, allowing an artist to carry or publish a portfolio as an eight-character code.
Digital art could be designed to be customizable -- allowing the smart-code holder to insert his or her own photographs or other elements into the art when it is regenerated in physical form. For example, the buyer of a digital painting could have family photos replace certain pictures that the artist had designated for this option -- or have a photograph or drawing of his or her favorite place provide a new background for a photograph.
The integration of new material from the owner could be simple -- for example, inserting a new image into a digital composition. It could also be abstract or complex -- such as picking up a color scheme or other element from one or more photographs the owner uploaded, and using it to modify the art in some way. Music could be customized by including specific sounds provided by the owner, or by extracting rhythm or other elements from a music file the owner wants to use.
Physical copies of the work could not be changed in this way. That's because the new elements provided would often not just replace something in the artists work, but would be used to create an entirely new version of the work, through arbitrarily complex rules designed by the artist.
Since the code defines the original, the artist could allow unlimited physical copies to be generated. Only the possessor of the code could produce custom versions embodying his or her own material.
Smart codes are not required for such customizable art (powerful computers are required, so such an art medium could not have developed until recently). Smart codes do provide an additional motive for customizable art, because they give a tangible benefit to possession of a code, creating a very practical distinction between an original and a copy. Smart codes allow artists to produce numbered originals (or just one original) that can be displayed or sold anywhere, with almost no transportation or storage cost.
Micropayment smart codes could start with a single merchant who wants to sell online -- especially one who offers digital goods. I publish a newsletter, and developed this idea while exploring ways to sell it online. Subscribers could buy a smart code for any amount, and use to pay for subscriptions, for access to individual articles or archives, or for permission to distribute bulk copies, either internally or to their clients. (One advantage of payment codes is that organizations often have a certain amount of money to spend now, which may not match the cost of an annual subscription or other available price. With smart codes, they can put an invoice dated now into their hands immediately for whatever amount they want to pay, while keeping an electron trail of their expenditures -- a receipt smart code that can generate a full invoice whenever needed.)
Once one merchant is using smart codes, other merchants will be able to add themselves, simply by buying a smart code and using it to issue public codes, through which they can receive payment from their customers, as explained above.
Later, other organizations may set up their own code systems. Even if these use a different code length, the servers can still talk to each other and allow transactions to go through, even when the seller is on one server and the buyer is on another.
Many of the features described in this article will require special coding on the servers that manage the code database. Every smart code ever created will allow at least some access to a control center (that's what "smart" means), though many owners will never use this access. Each control center will offer a menu of options -- many of which pertain to the creation of new smart codes, either secret or public. The owner of a smart code will be able to use this menu to change the look, feel, actions, and powers of the control centers of its descendent smart codes -- usually by setting up defaults that apply to all new descendent smart codes created. Different servers, of course, will offer different options to start with -- and many codes will also be limited by restrictions imposed by their parents, or other ancestors. The goal is not to provide unlimited choice in every code, but focused choices that serve the purposes for which that particular code was created. If other powers are needed, the owner can buy another smart code that has them.
The whole smart-code system can start with one merchant or organization and grow from there. No central control is needed -- not even agreement on basic technical standards like length of the codes. Some protocols for communication among different smart-code servers will have to be worked out, in order to allow buyers and sellers to transact business when they are using different code systems. But this is unlikely to be a problem, since even redundant, competing, or changing standards would impose little cost; merchants and their customers would not see the difference, and would not need to change their procedures even if these communication standards changed. And code servers could cheaply support multiple standards if necessary.
Smart codes are like digital gift cards that can reproduce (through multiple generations if desired), by using a control center on the server of the code-issuing organization. This simple structure allows hassle-free online payments of arbitrarily small amounts, individual and group movie tickets distributed by phone, last-moment gifts, limited access by library patrons to expensive databases, donations that can be re-"sold" in whole or in part to other donors, fully digital collectible art (which can also be customizable), and donations that can develop investment value as collectables.
Clearly, many more uses have not yet been imagined.
This system could spread easily. Most people will be introduced by being given a code or buying one, and using it to make purchases, especially when other means of payment won't work. And if they wish, they can use their code's value to make new codes to give to others. All the complexity is optional.
Self-reproducing payment codes could have many consequences, mostly good. They could greatly reduce certain transaction costs, making new business models possible.
----------------------------------------
This work is licensed under a Creative Commons License.