• Home |
• Summary |
• Examples |
• Archive |
• About |
• Blog |
• Links

Examples

Here is our more detailed description of Smart-Accounts.

We organized this description as a series of examples, set in the near future. We will explain the Smart-Accounts system as necessary, in order to present the examples. Start with our one-page Introduction and Purpose for an overview; you may also want to see our more general Summary.

Example I. Band Selling a Song

We often work in coffeehouses in University City/West Philadelphia, and some of them have CDs from local independents bands on the counter for about $10. They must sell some since the CDs have been there for well over a year; but in hundreds of hours in coffeehouses we have never seen a sale. This is not a way to make a living. Today there are better options online, such as Magnatune, at www.magnatune.com.

Here we describe a new option, which we call Smart-Accounts.

Consider an imaginary band, Zero-Earth, that sings about a coming apocalypse. Assume this band has just finished a new song or album, "WOOPS!" -- about a political, industrial, or military mistake that causes an environmental catastrophe. The band has supporters and the song has potential appeal to a larger public, but what's the next step?

Here we assume that a Smart-Accounts system is running on a website, say www.automatic-accounts.com. In fact we reserved this domain name for just that purpose, once the software is ready. Incidentally, we almost chose "Automatic-Accounts" as our name for this system, but chose Smart-Accounts instead, mainly because it is shorter. In practice we expect that there will be many different systems of reproducing financial accounts that will be commercially available; it turns out that they can be made compatible even if they look very different from each other ("compatible" meaning that parties with accounts on the different systems can use them to do business with each other), provided that the organizations offering the accounts can trust each other

But for this example of selling music, it turns out that compatibility is unnecessary; if there are multiple systems of reproducing accounts, the musicians can take their pick, depending on who offers the best services for what they are doing, at the best price; their customers will not need to have any Smart-Accounts at all. It makes little difference to the public which reproducing-accounts system the musicians choose, as long as the software works properly.

Assume the band chooses www.automatic-accounts.com. The first step is that someone will visit the site for the band and sets up an ordinary website account (not a Smart-Account), getting a user name and password as usual. This communication will use SSL (the same securit used for credit-card transactions, which shows as a padlock image on the browser), to protect this login information. We expect that setting up this account will be free, as the business model that seems to make the most sense is to charge a small percentage of sales as they occur (maybe around 1% or 2%) to support the Smart-Accounts service. There might also be minimum charges for unusually heavy use of system resources, in case no sales are intended, or few sales occur.

The "Smart URL" and "Public Accounts"

We noted in the Introduction and Purpose that Smart-Accounts (or other reproducing accounts) will be able to circulate publicly or semi-publicly as Web addresses (URLs) -- accessible with just a click, by anyone who has the URL. What does it mean for an account to circulate as a URL?

The defining feature of Smart-Accounts is that they can reproduce; and the central benefit of reproduction is that these accounts can have as much "smarts" (automatic actions, settings, etc.) as anyone wants to put into them. (This is not very feasible with ordinary, non-reproducing accounts, due to the unlimited amount of setup that could be required for each new account; reproduction can handle almost all of this setup automatically.) So in addition to all sorts of other features, these accounts can provide a form of limited public access -- a public face -- in addition to private access by the owner.

For security advantages we have only developed a limited form of this public access so far: the "public account." Public accounts are born with an irrevocable restriction, enforced by the server: they can take money in, but they can never give any money out. Instead, these accounts are created by reproduction (like other Smart-Accounts); and any money put into them automatically shows up in the parent account. The account owner can keep the parent account's access information in an office safe or whatever, while the public account can circulates and do business around the world. There is NO non-public access to the public account, except through its parent. So there is no owner's password to lose, misplace, or steal. Of course the owner can take the money out of the parent, and also can use the parent to manage the public account; but no information about the parent account needs to circulate.

Note that the public account (which can never give money out) is only one of many kinds of possible restrictions on an account. To take other examples, the account might only have $5 in it, not much to lose or steal -- or it might be able to pay only certain accounts on a secret list, which may include creditors or other business partners of the account owner, meaning that the owner can use the account, but even someone who steals the complete owner's access to the account probably cannot profit. And of course, all transactions can be recorded and traced forever by the owner (or not recorded, if the owner chooses).

To get back to the smart URL, this URL will almost always represent a public account (since there are more secure ways for owners to access non-public accounts). The whole point of the public account is to share music, other content, or other services easily, through social networks. But how does a URL represent an account? How does a URL hang onto money and do all sorts of other tricks?

You can picture an example of a smart URL as follows. Start with our server, www.automatic-accounts.com, then add one or more names that together serve as a pointer to a database record for that single account. For example: www.smart-accounts.com/band/song/ where "band" is the name of the band, or other name the band made up to represent itself publicly in this way, and "song" is another name made up by the band to represent a particular composition, album, etc. In our example above, the smart URL for the song WOOPS! might be as follows: www.smart-accounts.com/zero-earth/WOOPS/ The smart URL must always be a proper URL; and in Smart-Accounts at least the server will ignore upper vs. lower case, so that people will not need to remember which is which. Therefore the same smart URL could also be written: www.smart-accounts.com/zero-earth/woops/ whichever way someone prefers.

How is this an account? Well, while the actual software will be more complicated, you can picture it in principle like this. Assume that all the numbers and letters after the domain name are strung together, with names separated by dashes, to get an account name -- zeroearth-woops in this case. There can be only one account named zeroearth-woops on www.automatic-accounts.com, since the band will reserve the name zeroearth, and then create different accounts that it owns, for whatever music it chooses to market in this way.

Now look at the database of accounts on the server -- which perhaps manages thousands of accounts that customers have opened. Each account may contain dozens (or even hundreds) of separate fields. For example, for an account used to sell bulk sponsorships to a song, which end users can then download free, one field will contain a pointer to the MP3 or whatever file is to be downloaded for that song; another field will contain the number of prepaid downloads remaining. Each download will decrement that number, until it reaches zero -- at which time anyone who clicks the URL will get a message that all prepaid copies are currently exhausted, and at least one must be purchased in order to get the requested download. Most likely the downloads will sell for much less in quantity, encouraging potential sponsors to buy dozens, hundreds, or even thousands of copies with one purchase. Another field in each account record will hold the sponsor's personal message to each downloader, if any. Since these accounts will allow many different people to each purchase their own sponsorship, and have them all in effect simultaneously, other fields will be devoted to this.

Of course most people won't want to pay anything. That's fine -- it's what this system is designed for. Say 98% of end users will pay nothing. That works if the other 2% are willing to sponsor an AVERAGE of 50 prepaid copies (and send their personal message out to 50 people in social networks interested in the particular music, artists, or a cause). Note that if one person has the money and sponsors 5,000 copies, that makes up for the next 4,999 end users who pay nothing at all to download the song. Also, if the prepaid copies still run out, then anyone can sponsor more and play the hero, earning gratitude associated publicly with their personal message, by instantly releasing more free downloads through all copies of that smart URL throughout the world.

Also note that if the sponsorships vs. free users still remain out of balance, the artists can move the balance one way or the other as needed, by lowing or raising their prices. If there is far too little sponsorship, for example, the artists might cut their per-download price by 75%, to make the existing sponsorships go four times as far (as well as motivating sponsors to spend more, since they get a relative bargain with the low price). And of course the person who sponsors 5,000 copies does not need to know 5,000 people to give them to, thanks to social-network distribution -- which also encourages sharing of music one likes, instead of criminalizing it.

In fact a non-empty smart URL is a gift with economic value, so it may tend to travel better than the average link, which has no similar money value. And as it travels, the smart URL not only supports the artists through new sponsorships, but also promotes the artist to new audiences, who get the smart URL from their friends. In effect, the smart URL can discover new constituent groups for the music it carries -- groups that may be completely unexpected by the artists and others involved, and reachable in no other way.

Also, the smart URL can do business in many languages, even without machine translation, just like many software packages can do; the Macintosh operating system, for example, can be installed and work in dozens of languages. With Smart-Accounts anyone who has the URL can change its language (perhaps by clicking a picture of flag, or the name of that language written in that language. That URL (and all copies of it that the person who changed the language may send to their friends) stays in the new language until someone changes it again. So now we have different swarms of the same URL, circulating in different languages in social networks throughout the world -- all supporting the same artist, art school, cause, etc. through their travel. Sponsors who wish to can provide the same or different personal messages in as languages as they wish, and mark each version of their message so that it will only be delivered when the URL is set to that language. The languages of the URLs different copies can change many times during their travels, and the sponsor's message will wait until it has an appropriate opportunity to come forth.

As they are passed from friend to friend, easily crossing international borders, these smart URLs will effectively hunt out new constituencies, which can be anywhere in the world. A local band in the U.S. might develop a cult following in China, or vice versa -- even if none of the people involved speak the other language.

Also note that the smart URL need never expire; it can keep going indefinitely as long as there is public interest in the work it carries, and/or the causes it may support. It can run out of prepaid downloads; but anyone who can pay money online can add more downloads by purchasing a new sponsorship (whether or not the existing prepaid downloads have already run out). Sponsors could be primarily in rich countries, end users could be anywhere, and the artists supported by this system could also be anywhere in the world.

Technical Note

The software to do all this will run on the server (www.automatic-accounts.com in our example). Each Smart-Account will have its own record in the database (in a large table within the database, often holding thousand of records, one for each account currently open, and probably one for accounts that have been closed as well, in order to maintain records for accounting purposes, or for many other kinds of reports such as sales projections or other business analysis, which the account owner can simply ask for at any time). The fields in each account's record will control the software for that account -- keeping track of multiple sponsorships, keeping track of which music or other content file that account can offer, etc.

Of course one field of the account record will be for the account name; but for security, it will exist only in a one-way hashed form, as is done with credit cards. The server will never store the real name of the account. The advantage of doing it this way is that even the theft of the entire account database will not allow anyone to use it to impersonate an account owner in the live system, which of course is where the money is controlled.

You could visualize the accounts database on the server as a huge spreadsheet. Each line is a different account; usually there will be room for thousands of these. And every column is a separate field. For simplicity, we assume here that every account in the database has the same fields (although many will be unused for any typical account). In fact, this rule could be relaxed, to allow different kinds of accounts on the same server, in order to use the disk or other random-access memory more efficiently.

Example II: Flexible Spam Control, by Email Users Charging to Receive Messages from Strangers

[to be continued]