Updated July 24, 1998

Digital Property

An Educom/IMS Working Paper
by Brad Cox, Ph.D.

This section adopts an informal and tutorial style to distinguish between unigranular and multigranular digital property and to show how an advanced economy in multigranular digital property could operate.The tutorial style isn't because the concepts are complicated, hard to understand or even unfamiliar, but because because they are so familiar that we tend to overlook them. For further information, see Superdistribution: Objects as Property on the Electronic Frontier (Addison Wesley 1996) and Object-oriented Programming; An Evolutionary Approach (Addison Wesley 1991) by Brad Cox.

Figure 1 shows a financial exchange transaction such as, for example, a real estate sale. Property made of atoms (timber, lumber, nails, homes, etc) flows in one direction while financial value (money) flows in the other.

Figure 1
Figure 1: In exchange transactions, money flows in one direction and goods flow in the other. Physical conservation laws, such as conservation of mass, bind disparate self-interested actors into a cooperative social system by ensuring that property rights understandings aren't violated. Notice that if tangible property (real estate) could be replicated as easily as a PC can replicate digital property, the construction industry would quickly collapse, reverting to the primitive state that the software "industry" is in today.

This proposal is concerned with exchange transactions in which goods are not made of the tangible atoms of the real estate example, but the intangible bits of the information age. Examples of goods made of bits, digital property, are:

Being made of bits and not atoms, digital property is immune to the physical conservation laws (conservation of mass, spin, energy, etc) that underpin exchange transactions in tangible goods. For if timber, lumber and homes could be replicated as easily any PC can replicate software, who would invest in making it since others could obtain the results of their labor for free.

Macroaccount and Microaccount Systems

In barter economies, natural laws such as conservation of mass enforced ownership for both legs of the transaction. But as barter gave way to cash, and cash to checking, credit cards and digicash, conservation of money relies less and less on natural laws and more on more on the laws, computer software and transaction journals of mankind. The money side of most modern transactions is handled digitally already. Since credit card transactions are not practical below the tens of dollars range, a micropayments system will be needed to consolidate small transactions (pennies or less) into macro transactions that existing financial solutions (credit or debit card systems) can process efficiently. Figure 3 shows such a system.

Figure [Micro] Figure 3: The micropayments system consolidates micro transactions until balances reach levels that macropayments systems can process efficiently.

Unigranular versus Multigranular Property

The real estate example spans two different cases; unigranular versus multigranular, which are synonyms for what we have in mind when we speak of primitive versus advanced economies.

Most people are so accustomed to the advanced model that it can be shocking to realize that it barely applies to what most of us think of as the most advanced of modern goods. With rare exceptions, companies don't build digital products such as computer software, digital books, and course ware by assembling them from subcomponents produced by other vendors. We don't because we don't know how to. Without the conservation of mass laws that tangible goods producers implictly count on to protect their revenue stream, each company bears the crushing complexity of building digital products from the ground up, unaided by the other companies that might support them. The multi-level hierarchies of producers and consumers does not exist today, and cannot begin to exist without an accepted and deployed solution to the problems of buying, selling and owning property made of bits.

Unigranular Property

This proposal does not address unigranular property; i.e. software that is entirely owned by a single individual or corporation.

This is not because we think unigranular property is unimportant; unigranular property is by far the most common kind of digital property today. This proposal does not address it because

Point #2 does not apply to unigranular property because single-owner software can easily be protected for sale under Point #1. It does apply to multi-owner property, such as a digital course owned by a university that uses a digital textbook owned by a publishing company, both of which might use smaller granularity reusable software components owned by yet other entrepreneurs.

Revenue collection for digital property owned by multiple owners, each expecting to get paid for each others' uses of digital property, is the problem to be addressed by this standard.

Multigranular Property

The solution to be presented in this document is based on the four-level techno-social architecture shown in figure 4.

Figure [Architecture].

Figure 4: The 4-level technosocial architecture proposed in this document.

The lowest level, Objects, is the basis for multigranular property. The higher levels work only for objects (hybrids of procedure and state), not for as is traditional, passive data and active procedures.

The second represents the metering infrastructure explained in this proposal.

The third represents superdistribution backoffice functions such as the Terms and Conditions Algorithms, which convert usage counts into financial amounts such as dollars.

The fourth level represents the rules of just conduct (e.g. laws) concerning just behaviors with respect to the proposed infrastructure and penalties for unjust (fraudulent) behavior

Everyone is accustomed to the choice between buying a car and using it for free or renting one and paying by the mile or the day. From the seller or renter's perspective, it is straightforward to do business either way because goods such as automobiles provide built-in metering infrastructures on which revenue collection can be based. For example the car's odometer is a metering infrastructure that supports revenue collection in proportion to use; i.e. by the mile. In the case of owning, the metering infrastructure is built in at a much deeper level. Cars, being made of atoms, abide by physical laws such as conservation of mass, which make it hard (impossible) for buyers to undercut revenue collection by replicating cars like computer software.

This proposal describes a metering infrastructure for computer software. It works the way the odometer in a rental car works, by recording when, how often, and by whom the software has been used. The proposal bases revenue collection on use (renting) instead of acquisition (owning) because of an obvious but rarely mentioned essential difference between bits and atoms. It is very hard (impossible) to develop software that counts how many times it has been copied but trivial to write software that counts how many times it has been invoked. The situation is the opposite for tangible goods made of atoms because physical laws (conservation of mass) make it very hard (impossible) to replicate physical goods as we replicate digital goods.

Objects as Multigranular Property

The foundation level of the architecture in Figure 1 are objects; hybrid entities that maintain their own state and exhibit their own behaviors. This is by contrast with the practice of maintaining state as passive entities (data, files, and records) and expressing behavior as active entities (programs, applications, and subroutines). Other popular features of object-oriented programming, such as classes and inheritance are not required or assumed by this proposal.

Markets in tangible goods work well because conservation of mass provides a robust basis for revenue collection. Conservation of mass is endogenous, an intrinsic part of the atoms from which tangible products are comprised, not exogenous , attached externally as plastic and cardboard is attached to software products in a store. Exogenous protection can be, and usually must be, stripped off and discarded when the product is put into use but endogenous protection is part of the product forever. For example, encryption is a common exogenous protection mechanism. The protection it provides must be removed before the encrypted software or data can be used.

There is no way to provide endogenous protection for bare data. Bare data is dumb, too dumb to protect itself from unauthorized use. But objects are smart. Each access from the outside is mediated by procedures that remain with the object forever. There were written by the object's owner to mediate access and block access by those who haven't paid the fees. The invocation metering infrastructure to be described here can be thought of as a standard way that object authors can call to determine those who've paid the specified fees.

Figure 5 shows property A invoking property B and C, which invokes D, E, F, and so on. By providing a metering infrastructure whereby invocation counts from each level are gathered and used to support the interests of each of the parties A, B, C and D, the economic preconditions for the emergence of an advanced (e.g. multilevel) market in digital property as envisioned in the requirements document could be met.

Figure [Hierarchy]

Figure 5 defines digital property names that will be used in the text. Property E is used as a subcomponent by properties B and C and any other properties that might invoke them in the future. It uses (invokes) subcomponents H and I and others not in this figure.

The text will make no distinction between a digital property and the legal entities (people or corporations) than own it because the accounting system maintains the correspondence between a property and its owner.

An important exception concerns the end-user at the top. This is the person who invoked the hierarchy and whose account will be debited for its use. The CID (Customer ID) of this account will be determined by a logon process, establishing that person's account as the entity to be charged for any software they invoke. How this debit will be credited to others is determined by the nesting relationship and will be described in more length in the text.

Figure 6 shows the key elements of the proposed solution. The left-most two boxes (green and yellow) are similar to any other micropayments systems such as Millicent. This proposal considers property protection for digital money as already solved in acceptable ways. It's focus is providing property protection for digital goods, the right-most part of this figure.

Figure 3
Click here for a larger view.

Figure 6: The proposed infrastructure for multigranular digital commerce. The meter records the consumer's invocations of digital property. Terms and Conditions Algorithms convert the usage counts to financial amounts. These micro payments are consolidated over time into macropayments large enough to be handled efficiently by existing financial institutions such as credit card companies and banks.

The graphic at the right represents an end-user, the consumer. The disk represents somebody digital property, the producer. It will be useful to think of this digital property as the robotic agent of the producer, its owner, lest the figure grow too complex. Our purpose here is to facilitate the emergence of an advanced, e.g. multi-level commercial economy exactly like those that operate for tangible goods. This figure focuses on a single producer-consumer transaction within what we hope will soon become an elaborate graph in time.

When digital property (at any hierarchical level of the invocation graph) is invoked, it uses the invocation meter to record

PID (Product ID)
The PID identifies which property is being used

CID (Customer ID)
The CID (customer ID) identifies which account will be debited for this use. This parameter is not explicitly passed to the meter. It is implicit in the nesting of query/commit calls.

Timestamp
An explicit timestamp might be useful for time sensitive billing. I'm undecided about whether this is essential and invite input from the coalition on this matter. Time sensitive billing such as January White Sales might be handled without this by simply releasing a new version of the product with a different PID and corresponding TACA.

These quantities are recorded in a tamper-resistant cache and periodically (say monthly) communicated to the superdistribution back office for billing. The CID needn't be explicitly recorded because the party to be billed for the use of a property at any level is implicit in the hierarchical nesting of query-commit calls. Figure 7 shows the query and commit functions

public boolean login(ID cid) { return this.Cache("Login", cid); }

public boolean logout(ID cid) { return this.Cache("Logout", cid); }

public boolean query(ID pid) { return this.Cache("Query", pid); }

public boolean commit(ID pid) { return this.Cache("Commit", pid); }

public boolean flush() { ... }
Figure 7: The Java implementation of the two usage metering functions, Meter.query and Commit, and the Login and Logout functions. The cid arguments identify customers and the pid arguments identify digital products.

The Rules of Just Conduct require that these functions shall be used as follows. Using them otherwise constitutes legally prosecutable fraud under the terms of the contract that was signed when acquiring a superdistribution account.

login and logout
These calls are issued by a global login/logout procedure. The cid argument indicates the customer ID whose account is to be debited by the top-level software they use. Notice that this only applies to top-level software... lower-level software debits the owner of the software that called them (as reflected in the query/commit nesting relationship). The Login/Logout calls are to "ground out" the implied recursion.

query and commit
These calls are coded into digital property by the property's developer to surround the value-bearing (chargeable) portions. In effect, they divide each property into (possibly multiple) "inner" and "outer" regions, analogous to the (free) outside and (chargeable) insides of a cereal box. Query returns a boolean indicating whether the transaction should be allowed. The commit call commits the transaction, indicating that the service was successfully delivered.

Flush
This function is normally called internally by the metering logic depending on parameterizable settings, typically when the cache fills or when a timing parameter (monthly?) expires. It may also be called externally by property that is so valuable that up to the second information about the customer's payment status is required.

If the modules in Figure 5 call each other without looping in a breadth-first sequence, the cache would contain the invocation records shown in Figure 8.

Login PersonID
-Query A
--Query B
---Query D
----Query G
----Commit G
----Query H
----Commit H
---Commit D
---Query E
----Query H
----Commit H
----Query I
----Commit I
---Commit E
--Commit B (continued)
 
--Query C
---Query E
----Query H
----Commit H
----Query I
----Commit I
---Commit E
---Query F
----Query I
----Commit I
----Query J
----Commit J
---Commit F
--Commit C
-Commit A
Logout PersonID
Figure 8: This shows how invocation records for the call graph in Figure5 would be stored assuming the modules call each other without loops in a breadth-first manner. Notice that information about who's to be charged for each invocation is not stored in each record but is implicit in the nesting relationship. The Login/Logout records at the beginning and end of this example indicate the account of the end-user who will be debited and credited to the owner of the top level component, A. A's owner will then be debited for A's use of subcomponents B and C and credited accordingly. B's owner's account will be debited for B's use of subcomponents D and E and credited accordingly. And so forth recursively at each level. The indentation is to aid readability and is only stored implicitly.

When the cache fills to a customizable threshold level, or when a customizable timeout period (say monthly) arrives, the meter establishes a connection (details to be described later) with the superdistribution back office and an information interchange ensues:

Terms And Conditions Algorithms (TACAs)

Notice that everything up to this point has been in terms of unitless numbers (invocation counts). The client side knows nothing about money. This is extremely important because issues involving money are complex. Since the client side focuses only on counting, it can be simple and fast, simple enough to be implemented in silicon. Ultimately they can be incorporated within next-generation CPU chips, thus achieving the level of tamper-resistance that will be needed to serve untrusted markets.

Until then, software implementations should be confined to trusted markets. Fortunately examples of these are common. For example, large companies and other institutions are trusted markets. They perceive the gains stealing software isn't worth the risk of the penalties in the rules of just conduct that they contractually agreed to when they acquired their meter and superdistribution account.

Terms and Conditions Algorithms (TACAs) are algorithms; functions that convert the information in a query/commit pair into a financial amount to be debited from the micro account that is passed to the TACA as an argument. TACAs are provided by each product's owner when during the product registration process and permanently stored by the superdistribution backoffice, indexed by PID (Product ID).

Each TACA is a function. Its argument is a persistent object derived by the calling infrastructure from the master account record of the party to be debited that the TACA. TACAs will typically refer to the contents of this object for information about the history of that account, update it as needed, and return the financial amount that the calling infrastructure will debit from the master account record. Notice that the TACA doesn't access or update the master account record directly. It accesses persistent storage that the calling infrastructure creates for its use and manages on its behalf.

Invocation Infrastructure

The TCP's are invoked by an invocation infrastructure. This is a subroutine that calls itself recursively to reconstruct the invocation hierarchy shown in Figure 8 as its own call stack. Each level of the recursion processes a single Query/Commit pair from the invocation history. As it traverses the graph it also determines the account to be debited and passes it as an argument to the next level of the recursion.

Thus each level of the recursion receives the account to be debited as an argument. It extracts the PID of the account to be credited from the recorded information, locates the TACA for that PID from the master account record, constructs a copy of the relevant information for use by the TACA, and invokes the TACA from the master account record. The TACA computes the amount to be credited for that invocation. The invocation infrastructure debits this amount from the master micro account of the CID that it received as an argument, credits it to the master micro account of the owner of the PID it is processing, and saves any changes that the TACA made to its persistent storage area. Figure 9 shows (raw, untested and no doubt incorrect) Perl code does this.

 sub ProcessRecord {
my ($CID, $CODE, $PID) = @_;
Assert($CODE eq 'Query'); #Always true if all is well with the data
my ($NextCODE, $NextPID) = $InvocationRecordFile->NextRecord;
my $DebitAccount = $AllAccounts->Lookup($CID);
if ($NextCODE eq 'Commit') {
my $CreditAccount = $AllAccounts->Lookup($NextPID);
my $PersistentStore = $CreditAccount->GetPersistentStore;
my $FinancialAmount = $CreditAccount->RunTACA($PersistentStore);
$CreditAccount->SavePersistentStore($PersistentStore);
$CreditAccount->Credit($Amount);
$DebitAccount->Debit($Amount);
} else {
ProcessRecord($DebitAccount, $NextCODE, $NextPID);
}

}

Figure 9 is a (untested and probably incorrect) recursive Perl subroutine for processing invocation records. The CID argument identifies the account to be debited. The CODE and PID arguments are the two fields from the current invocation record. The code references the external variables $InvocationRecordFile as the file of invocation records and $AllAccounts as the database of all micro accounts.

The effect of this loop is that an amount is debited from the account of the party using each subcomponent and credited to the account of its owner. The invocation record file is then deleted and/or archived (See rules of just conduct).

The account balance of the top-level user is then compared against tunable thresholds to determine whether that account is in good standing. This boolean is returned to the client computer and will be stored there and returned by all Query calls during the next billing cycle.

Periodically (typically monthly) the status of all micro accounts will be compared against tunable thresholds to reconcile them the external macro accounts that the owner specified when the accounts were established, using whatever electronic funds transfer mechanisms the macro account operators (banks, credit card companies, digicash) have available.

Rules of Just Conduct

This is a hastily edited collection of rules submitted by students in my Taming the Electronic Frontier course. A commercial enterprise would, of course, extend them substantially.

The proposed rules emphasize property-conscious morés insted of the communitarian, property-averse values that are widespread on the internet today. The reason for the pro-property bias is, as I explained in Superdistribution: Objects as Property on the Electronic Frontier, advanced property-conscious (European-style) economies tend to generate far greater social power than property-averse communitarian ones as evidenced by the domination of property-averse, tribal, communitarian cultures by property-conscious, capitalistic societies (American Indians, Australian Aborigines, South American Indians, African Tribes, Soviet Bloc, etc.)

Rules of just conduct cannot be dictated by any one person or group. Individual propose but markets dispose. The following are proposed rules, recommended but not dictated:
Truth in Charging
Terms, conditions and prices must be made known to the consumer before the price is actually charged. For example there must be a clear disclosure alongside the button that incurs the change.The price actually charged must be equal to (or less than) the price advertised above.

Contractually Binding
Acquisition of a superdistribution account establishes a contractual relationship that spells out legally binding rules of just conduct. Violation of the rules of just conduct is contractual, legally prosecutable, fraud.

Exclusively for billing
Nearest neighbor rule. The superdistribution backoffice will only supply information to each level in the tree about nearest neighbors. Information about the entire production or consumption chain is not available to anyone. I advise an extremely strong stand because invocation metering raises severe and legitimate privacy concerns that could be fatal to the whole approach. Precedents for stringent controls were established when librarians refused FBI access to book records during the McCarthy era. The librarians won this confrontation in the courts which culminated in the Librarian Bill of Rights, which establishes that library records are private information, immune even to legal supoenas. I advise an equally stringent approach.

Nonrepudiation
Producers are responsible for charges incurred by their property. Bugs are no excuse Consumers are responsible for charges incurred by using other people's property. Accidental clicks are no excuse.

Tampering and fraud will be prosecuted
During the initial stages of deployment the infrastructure is exclusively based on software and is by definition exposed to tampering or fraud. During later stages, increasingly sophisticated technical barriers become feasible, such as bundling the entire meter inside the CPU chip. However even then, the increasing difficulty of cracking the infrastructure may be offset by the increasing prospect of ill-gotten gains. Based on the observation that increasingly sophisticated technical barriers can be surmounted by increasingly sophisticated anti-barriers, we should not rely on technical barriers alone. Social sanctions must step in once technical sanctions fail, thus the repeated references to rules of just conduct throughout this proposal.

Meter Packaging Options

This table resulted from a meeting (2/12/98) with IMS to discuss packaging alternatives. This lists several options for packaging and deploying the metering functions and the underlying cache. The blue dots indicate tradeoffs in tamper-resistance, convenience of use, and convenience of deployment.

Meter Location

Tradeoffs

Tamper Resistance

Convenience to use

Convenience to build

Within the
CPU chip

The ideal for tamper-resistance and convenience of use. Convenience of deployment very low, but surmountable in the long run since chip manufacturers could then claim a cut of the revenue collected via their on-board meters.

Plugable Hardware (cards, dongles, etc)

An interim stage. Tamper-resistance is lowered since each plug creates an opportunity for attack. Cryptography could inhibit tampering at this interface at unknown cost in performance and complexity.

Inside the operating system

The meter functions and cache could be packaged with operating systems and enabled during the account-registration process. Software-based metering is by definition tamperable, which limits deployment to trusted markets. This excludes deployment to the internet at large but should not exclude deployment to trusted markets such as large companies and institutions.

Within
browsers or applet runners

Meters are installed in java environments (via agreement with vendors or via patch self-installer). Users must register to activate them and agree to rules of just conduct. Cache flush thread runs in parallel with the product code to continually flush the cache (for "connected" environments). The application's exit logic overloaded to flush cache before exiting. Tamper-resistance is low because the concluding flush could easily be circumvented but it's perhaps an acceptable place to begin.

Within
applications

Recommended for initial deployments. Commercial applications can bundle a copy of the meter/cache logic and operate as described above.

Server
based

Mentioned primarily because this came up in discussions at blackboard. I need to think further as to whether this is viable but I don't see a problem, other than performance and tamper-resistance, at this time. The meter functions would be hard-coded into applications, connect to a server-based cache on startup, and transmit their cache updates to the server "live".

© Copyright 1998 by Educom/IMS