Systems and methods for secure transaction management and electronic rights protection

Description of equivalent WO 9627155 A2

0001SYSTEMS AND METHODS FOR SECURE TRANSACTION MANAGEMENT AND ELECTRONIC RIGHTS PROTECTION

0002Fiβldfe) of the Inventi-mfe)

0003This invention generally relates to computer and/or electronic security.

0004More particularly, this invention relates to systems and techniques for secure transaction management. This invention also relates to computer-based and other electronic appliance- based technologies that help to ensure that information is accessed and/or otherwise used only in authorized ways, and maintains the integrity, availability, and/or confidentiality of such information and processes related to such use.

0005The invention also relates to systems and methods for protecting rights of various participants in electronic commerce and other electronic or electronically-facilitated transactions.

0006The invention also relates to secure chains of handling and control for both information content and information employed to regulate the use of such content and consequences of such use. It also relates to systems and techniques that manage, including meter and/or limit and/or otherwise monitor use of electronically stored and/or disseminated information. The invention particularly relates to transactions, conduct and arrangements that make use of, including consequences of use of, such systems and/or techniques.

0007The invention also relates to distributed and other operating systems, environments and architectures. It also generally relates to secure architectures, including, for example, tamper-resistant hardware-based processors, that can be used to establish security at each node of a distributed system.

0008Background and Summary of the Invention(β)

0009Telecommunications, financial transactions, government processes, business operations, entertainment, and personal business productivity all now depend on electronic appliances. Millions of these electronic appliances have been electronically connected together. These interconnected electronic appliances comprise what is increasingly called the "information highway." Many businesses, academicians, and government leaders are concerned about how to protect the rights of citizens and organizations who use this information (also "electronic" or

0010"digital") highway.

0011Electronic Content

0012Today, virtually anything that can be represented by words, numbers, graphics, or system of commands and instructions can be formatted into electronic digital information. Television, cable, satellite transmissions, and on-line services transmitted over telephone lines, compete to distribute digital information and entertainment to homes and businesses. The owners and marketers of this content include software developers, motion picture and recording companies, publishers of books, magazines, and newspapers, and information database providers. The popularization of on-line services has also enabled the individual personal computer user to participate as a content provider. It is estimated that the worldwide market for electronic information in 1992 was approximately $40 biUion and is expected to grow to $200 biUion by 1997, according to Microsoft Corporation. The present invention can materially enhance the revenue of content providers, lower the distribution costs and the costs for content, better support advertising and usage information gathering, and better satisfy the needs of electronic information users. These improvements can lead to a significant increase in the amount and variety of electronic information and the methods by which such information is distributed.

0013The inability of conventional products to be shaped to the needs of electronic information providers and users is sharply in contrast to the present invention. Despite the attention devoted by a cross-section of America's largest telecommunications, computer, entertainment and information provider companies to some of the problems addressed by the present invention, only the present invention provides commercially secure, effective solutions for configurable, general purpose electronic commerce transaction/distribution control systems.

0014Controlling Electronic Content The present invention provides a new kind of "virtual distribution environment" (called "VDE" in this document) that secures, administers, and audits electronic information use. VDE also features fundamentally important capabilities for managing content that travels "across" the "information highway." These capabilities comprise a rights protection solution that serves all electronic community members. These members include content creators and distributors, financial service providers, end-users, and others. VDE is the first general purpose, configurable, transaction control/rights protection solution for users of computers, other electronic appliances, networks, and the information highway.

0015A fundamental problem for electronic content providers is extending their ability to control the use of proprietary information. Content providers often need to limit use to authorized activities and amounts. Participants in a business model involving, for example, provision of movies and advertising on optical discs may include actors, directors, script and other writers, musicians, studios, publishers, distributors, retailers, advertisers, credit card services, and content end-users. These participants need the ability to embody their range of agreements and requirements, including use limitations, into an "extended" agreement comprising an overall electronic business model. This extended agreement is represented by electronic content control information that can automatically enforce agreed upon rights and obligations. Under VDE, such an extended agreement may comprise an electronic contract involving all business model participants. Such an agreement may alternatively, or in addition, be made up of electronic agreements between subsets of the business model participants. Through the use of VDE, electronic commerce can function in the same way as traditional commerce — that is commercial relationships regarding products and services can be shaped through the negotiation of one or more agreements between a variety of parties.

0016Commercial content providers are concerned with ensuring proper compensation for the use of their electronic information. Electronic digital information, for example a CD recording, can today be copied relatively easily and inexpensively. Similarly, unauthorized copying and use of software programs deprives rightful owners of billions of dollars in annual revenue according to the International Intellectual Property Alliance. Content providers and distributors have devised a number of limited function rights protection mechanisms to protect their rights. Authorization passwords and protocols, license servers, "lock/unlock" distribution methods, and non-electronic contractual limitations imposed on users of shrink-wrapped software are a few of the more prevalent content protection schemes. In a commercial context, these efforts are inefficient and limited solutions.

0017Providers of "electronic currency" have also created protections for their type of content. These systems are not sufficiently adaptable, efficient, nor flexible enough to support the generalized use of electronic currency. Furthermore, they do not provide sophisticated auditing and control configuration capabilities. This means that current electronic currency tools lack the sophistication needed for many real- world financial business models. VDE provides means for anonymous currency and for "conditionally" anonymous currency, wherein currency related activities remain anonymous except under special circumstances.

0018VDE Control Capabilities

0019VDE allows the owners and distributors of electronic digital information to rehably bill for, and securely control, audit, and budget the use of, electronic information. It can rehably detect and monitor the use of commercial information products. VDE uses a wide variety of different electronic information dehvery means: including, for example, digital networks, digital broadcast, and physical storage media such as optical and magnetic disks. VDE can be used by major network providers, hardware manufacturers, owners of electronic information, providers of such information, and clearinghouses that gather usage information regarding, and bill for the use of, electronic information.

0020VDE provides comprehensive and configurable transaction management, metering and monitoring technology. It can change how electronic information products are protected, marketed, packaged, and distributed. When used, VDE should result in higher revenues for information providers and greater user satisfaction and value. Use of VDE will normally result in lower usage costs, decreased transaction costs, more efficient access to electronic information, re-usability of rights protection and other transaction management implementations, greatly improved flexibility in the use of secured information, and greater standardization of tools and processes for electronic transaction management. VDE can be used to create an adaptable environment that fulfills the needs of electronic information owners, distributors, and users; financial clearinghouses; and usage information analyzers and resellers. ights and Control Information

0021In general, the present invention can be used to protect the rights of parties who have:

0022(a) proprietary or confidentiality interests in electronic information. It can, for example, help ensure that information is used only in authorized ways;

0023(b) financial interests resulting from the use of electronically distributed information. It can help ensure that content providers will be paid for use of distributed information; and

0024(c) interests in electronic credit and electronic currency storage, communication, and or use including electronic cash, banking, and purchasing.

0025Protecting the rights of electronic community members involves a broad range of technologies. VDE combines these technologies in a way that creates a "distributed" electronic rights protection "environment." This environment secures and protects transactions and other processes important for rights protection. VDE, for example, provides the abihty to prevent, or impede, interference with and/or observation of, important rights related transactions and processes. VDE, in its preferred embodiment, uses special purpose tamper resistant Secure Processing Units (SPUs) to help provide a high level of security for VDE processes and information storage and communication.

0026The rights protection problems solved by the present invention are electronic versions of basic societal issues. These issues include protecting property rights, protecting privacy rights, properly compensating people and organizations for their work and risk, protecting money and credit, and generally protecting the security of information. VDE employs a system that uses a common set of processes to manage rights issues in an efficient, trusted, and cost-effective way.

0027VDE can be used to protect the rights of parties who create electronic content such as, for example: records, games, movies, newspapers, electronic books and reference materials, personal electronic mail, and confidential records and communications. The invention can also be used to protect the rights of parties who provide electronic products, such as publishers and distributors; the rights of parties who provide electronic credit and currency to pay for use of products, for example, credit clearinghouses and banks; the rights to privacy of parties who use electronic content (such as consumers, business people, governments); and the privacy rights of parties described by electronic information, such as privacy rights related to information contained in a medical record, tax record, or personnel record.

0028In general, the present invention can protect the rights of parties who have:

0029(a) commercial interests in electronically distributed information - the present invention can help ensure, for example, that parties, will be paid for use of distributed information in a manner consistent with their agreement;

0030(b) proprietary and/or confidentiality interests in electronic information ~ the present invention can, for example, help ensure that data is used only in authorized ways;

0031(c) interests in electronic credit and electronic currency storage, communication, and/or use - this can include electronic cash, banking, and purchasing; and

0032(d) interests in electronic information derived, at least in part, from use of other electronic information.

0033VDE Functional Properties VDE is a cost-effective and efficient rights protection solution that provides a unified, consistent system for securing and managing transaction processing. VDE can:

0034(a) audit and analyze the use of content,

0035(b) ensure that content is used only in authorized ways, and

0036(c) allow information regarding content usage to be used only in ways approved by content users.

0037In addition, VDE:

0038(a) is very configurable, modifiable, and re-usable;

0039(b) supports a wide range of useful capabihties that may be combined in different ways to accommodate most potential applications;

0040(c) operates on a wide variety of electronic appliances ranging from hand-held inexpensive devices to large mainframe computers; (d) is able to ensure the various rights of a number of different parties, and a number of different rights protection schemes, simultaneously;

0041(e) is able to preserve the rights of parties through a series of transactions that may occur at different times and different locations;

0042(f) is able to flexibly accommodate different ways of securely delivering information and reporting usage; and

0043(g) provides for electronic analogues to "real" money and credit, including anonymous electronic cash, to pay for products and services and to support personal

0044(including home) banking and other financial activities.

0045VDE economically and efficiently fulfills the rights protection needs of electronic community members. Users of

0046VDE will not require additional rights protection systems for different information highway products and rights problems — nor will they be required to install and learn a new system for each new information highway application. VDE provides a unified solution that allows all content creators, providers, and users to employ the same electronic rights protection solution. Under authorized circumstances, the participants can freely exchange content and associated content control sets. This means that a user of VDE may, if allowed, use the same electronic system to work with different kinds of content having different sets of content control information. The content and control information supplied by one group can be used by people who normally use content and control information supplied by a different group. VDE can allow content to be exchanged "universally" and users of an implementation of the present invention can interact electronically without fear of incompatibilities in content control, violation of rights, or the need to get, install, or learn a new content control system.

0047The VDE securely administers transactions that specify protection of rights. It can protect electronic rights including, for example:

0048(a) the property rights of authors of electronic content,

0049(b) the commercial rights of distributors of content,

0050(c) the rights of any parties who facilitated the distribution of content, (d) the privacy rights of users of content,

0051(e) the privacy rights of parties portrayed by stored and/or distributed content, and

0052(f) any other rights regarding enforcement of electronic agreements.

0053VDE can enable a very broad variety of electronically enforced commercial and societal agreements. These agreements can include electronically implemented contracts, licenses, laws, regulations, and tax collection.

0054Contrast With Traditional Solutions Traditional content control mechanisms often require users to purchase more electronic information than the user needs or desires. For example, infrequent users of shrink-wrapped software are required to purchase a program at the same price as frequent users, even though they may receive much less value from their less frequent use. Traditional systems do not scale cost according to the extent or character of usage and traditional systems can not attract potential customers who find that a fixed price is too high. Systems using traditional mechanisms are also not normally particularly secure. For example, shrink-wrapping does not prevent the constant illegal pirating of software once removed from either its physical or electronic package.

0055Traditional electronic information rights protection systems are often inflexible and inefficient and may cause a content provider to choose costly distribution channels that increase a product's price. In general these mechanisms restrict product pricing, configuration, and marketing flexibility. These compromises are the result of techniques for controlling information which cannot accommodate both different content models and content models which reflect the many, varied requirements, such as content dehvery strategies, of the model participants. This can limit a provider's abihty to deliver sufficient overall value to justify a given product's cost in the eyes of many potential users. VDE allows content providers and distributors to create apphcations and distribution networks that reflect content providers' and users' preferred business models. It offers users a uniquely cost effective and feature rich system that supports the ways providers want to distribute information and the ways users want to use such information. VDE supports content control models that ensure rights and allow content dehvery strategies to be shaped for maximum commercial results. Chain of Handling and Control

0056VDE can protect a collection of rights belonging to various parties having in rights in, or to, electronic information. This information may be at one location or dispersed across (and/or moving between) multiple locations. The information may pass through a "chain" of distributors and a "chain" of users. Usage information may also be reported through one or more "chains" of parties. In general, VDE enables parties that (a) have rights in electronic information, and/or (b) act as direct or indirect agents for parties who have rights in electronic information, to ensure that the moving, accessing, modifying, or otherwise using of information can be securely controlled by rules regarding how, when, where, and by whom such activities can be performed.

0057VDE Applications and Software

0058VDE is a secure system for regulating electronic conduct and commerce. Regulation is ensured by control information put in place by one or more parties. These parties may include content providers, electronic hardware manufacturers, financial service providers, or electronic "infrastructure" companies such as cable or telecommunications companies. The control information implements "Rights Apphcations." Rights apphcations "run on" the "base software" of the preferred embodiment. This base software serves as a secure, flexible, general purpose foundation that can accommodate many different rights apphcations, that is, many different business models and their respective participant recruirements.

0059A rights application under VDE is made up of special purpose pieces, each of which can correspond to one or more basic electronic processes needed for a rights protection environment. These processes can be combined together like building blocks to create electronic agreements that can protect the rights, and may enforce fulfillment of the obligations, of electronic information users and providers. One or more providers of electronic information can easily combine selected building blocks to create a rights application that is unique to a specific content distribution model. A group of these pieces can represent the capabihties needed to fulfill the agreement(s) between users and providers. These pieces accommodate many requirements of electronic commerce including:

0060I the distribution of permissions to use electronic information;

0061I the persistence of the control information and sets of control information managing these permissions;

0062! configurable control set information that can be selected by users for use with such information; I data security and usage auditing of electronic information; and

0063I a secure system for currency, compensation and debit management.

0064For electronic commerce, a rights application, under the preferred embodiment of the present invention, can provide electronic enforcement of the business agreements between all participants. Since different groups of components can be put together for different apphcations, the present invention can provide electronic control information for a wide variety of different products and markets. This means the present invention can provide a "unified," efficient, secure, and cost-effective system for electromc commerce and data security.

0065This allows VDE to serve as a single standard for electronic rights protection, data security, and electronic currency and banking.

0066In a VDE, the separation between a rights application and its foundation permits the efficient selection of sets of control information that are appropriate for each of many different types of apphcations and uses. These control sets can reflect both rights of electronic community members, as well as obligations (such as providing a history of one's use of a product or paying taxes on one's electronic purchases). VDE flexibility allows its users to electronically implement and enforce common social and commercial ethics and practices. By providing a unified control system, the present invention supports a vast range of possible transaction related interests and concerns of individuals, communities, businesses, and governments. Due to its open design, VDE allows (normally under securely controlled circumstances) apphcations using technology independently created by users to be "added" to the system and used in conjunction with the foundation of the invention. In sum, VDE provides a system that can fairly reflect and enforce agreements among parties. It is a broad ranging and systematic solution that answers the pressing need for a secure, cost-effective, and fair electronic environment.

0067VDE Implementation

0068The preferred embodiment of the present invention includes various tools that enable system designers to directly insert VDE capabihties into their products. These tools include an Application Programmer's Interface ("API") and a Rights

0069Permissioning and Management Language ("RPML"). The RPML provides comprehensive and detailed control over the use of the invention's features. VDE also includes certain user interface subsystems for satisfying the needs of content providers, distributors, and users. Information distributed using VDE may take many forms. It may, for example, be "distributed" for use on an individual's own computer, that is the present invention can be used to provide security for locally stored data. Alternatively, VDE may be used with information that is dispersed by authors and/or publishers to one or more recipients. This information may take many forms including: movies, audio recordings, games, electronic catalog shopping, multimedia, training materials, E-mail and personal documents, object oriented libraries, software programming resources, and reference/record keeping information resources (such as business, medical, legal, scientific, governmental, and consumer databases).

0070Electromc rights protection provided by the present invention will also provide an important foundation for trusted and efficient home and commercial banking, electronic credit processes, electronic purchasing, true or conditionally anonymous electronic cash, and EDI (Electronic Data Interchange). VDE provides important enhancements for improving data security in organizations by providing "smart" transaction management features that can be far more effective than key and password based "go/no go" technology.

0071VDE normally employs an integration of cryptographic and other security technologies (e.g. encryption, digital signatures, etc.), with other technologies including: component, distributed, and event driven operating system technology, and related communications, object container, database, smart agent, smart card, and semiconductor design technologies.

0072I. Overview

0073A. VDE Solves Important Problems and Fills Critical Needs

0074The world is moving towards an integration of electronic information appliances. This interconnection of appliances provides a foundation for much greater electronic interaction and the evolution of electronic commerce. A variety of capabilities are required to implement an electronic commerce environment.

0075VDE is the first system that provides many of these capabihties and therefore solves fundamental problems related to electronic dissemination of information.

0076Electronic Content

0077VDE allows electromc arrangements to be created involving two or more parties. These agreements can themselves comprise a collection of agreements between participants in a commercial value chain and/or a data security chain model for handling, auditing, reporting, and payment. It can provide efficient, reusable, modifiable, and consistent means for secure electronic content: distribution, usage control, usage payment, usage auditing, and usage reporting. Content may, for example, include:

0078I financial information such as electronic currency and credit;

0079f commercially distributed electronic information such as reference databases, movies, games, and advertising; and

0080I electronic properties produced by persons and organizations, such as documents, e-mail, and proprietary database information.

0081VDE enables an electronic commerce marketplace that supports differing, competitive business partnerships, agreements, and evolving overall business models.

0082The features of VDE allow it to function as the first trusted electronic information control environment that can conform to, and support, the bulk of conventional electronic commerce and data security requirements. In particular, VDE enables the participants in a business value chain model to create an electronic version of traditional business agreement terms and conditions and further enables these participants to shape and evolve their electronic commerce models as they believe appropriate to their business requirements.

0083VDE offers an architecture that avoids reflecting specific distribution biases, administrative and control perspectives, and content types. Instead, VDE provides a broad-spectrum, fundamentally configurable and portable, electronic transaction control, distributing, usage, auditing, reporting, and payment operating environment. VDE is not limited to being an apphcation or apphcation specific toolset that covers only a limited subset of electronic interaction activities and participants. Rather, VDE supports systems by which such apphcations can be created, modified, and/or reused. As a result, the present invention answers pressing, unsolved needs by offering a system that supports a standardized control environment which facilitates interoperability of electronic appliances, interoperability of content containers, and efficient creation of electronic commerce apphcations and models through the use of a programmable, secure electronic transactions management foundation and reusable and extensible executable components.

0084VDE can support a single electronic "world" within which most forms of electronic transaction activities can be managed.

0085To answer the developing needs of rights owners and content providers and to provide a system that can accommodate the requirements and agreements of all parties that may be involved in electronic business models (creators, distributors, administrators, users, credit providers, etc.), VDE supplies an efficient, largely transparent, low cost and sufficiently secure system (supporting both hardware software and software only models). VDE provides the widely varying secure control and administration capabi ties required for:

0086Different types of electronic content,

0087Differing electronic content dehvery schemes,

00883. Differing electronic content usage schemes,

00894. Different content usage platforms, and

00905. Differing content marketing and model strategies.

0091VDE may be combined with, or integrated into, many separate computers and or other electronic apphances. These apphances typically include a secure subsystem that can enable control of content use such as displaying, encrypting, decrypting, printing, copying, saving, extracting, embedding, distributing, auditing usage, etc. The secure subsystem in the preferred embodiment comprises one or more "protected processing environments", one or more secure databases, and secure "component assemblies" and other items and processes that need to be kept secured. VDE can, for example, securely control electronic currency, payments, and/or credit management (including electronic credit and/or currency receipt, disbursement, encumbering, and/or allocation) using such a "secure subsystem."

0092VDE provides a secure, distributed electronic transaction management system for controlling the distribution and or other usage of electronically provided and/or stored information. VDE controls auditing and reporting of electronic content and/or apphance usage. Users of VDE may include content creators who apply content usage, usage reporting, and/or usage payment related control information to electronic content and/or apphances for users such as end-user organizations, individuals, and content and/or apphance distributors. VDE also securely supports the payment of money owed (including money owed for content and/or apphance usage) by one or more parties to one or more other parties, in the form of electronic credit and/or currency.

0093Electronic apphances under control of VDE represent VDE 'nodes' that securely process and control; distributed electronic information and/or apphance usage, control information formulation, and related transactions. VDE can securely manage the integration of control information provided by two or more parties. As a result, VDE can construct an electronic agreement between VDE participants that represent a "negotiation" between, the control requirements of, two or more parties and enacts terms and conditions of a resulting agreement. VDE ensures the rights of each party to an electronic agreement regarding a wide range of electronic activities related to electronic information and/or apphance usage.

0094Through use of VDE's control system, traditional content providers and users can create electronic relationships that reflect traditional, non-electronic relationships. They can shape and modify commercial relationships to accommodate the evolving needs of, and agreements among, themselves. VDE does not require electronic content providers and users to modify their business practices and personal preferences to conform to a metering and control apphcation program that supports limited, largely fixed functionality. Furthermore, VDE permits participants to develop business models not feasible with non¬ electronic commerce, for example, involving detailed reporting of content usage information, large numbers of distinct transactions at hitherto infeasibly low price points, "pass-along" control information that is enforced without involvement or advance knowledge of the participants, etc. The present invention allows content providers and users ulate their transaction environment to accommodate:

0095(1) desired content models, content control models, and content usage information pathways,

0096(2) a complete range of electronic media and distribution means,

0097(3) a broad range of pricing, payment, and auditing strategies,

0098(4) very flexible privacy and/or reporting models,

0099(5) practical and effective security architectures, and

0100(6) other administrative procedures that together with steps (1) through (5) can enable most "real world" electronic commerce and data security models, including models unique to the electronic world.

0101VDE's transaction management capabilities can enforce: (1) privacy rights of users related to information regarding their usage of electronic information and/or apphances,

0102(2) societal policy such as laws that protect rights of content users or require the collection of taxes derived from electronic transaction revenue, and

0103(3) the proprietary and/or other rights of parties related to ownership of, distribution of, and/or other commercial rights related to, electronic information.

0104VDE can support "real" commerce in an electronic form, that is the progressive creation of commercial relationships that form, over time, a network of interrelated agreements representing a value chain business model. This is achieved in part by enabling content control information to develop through the interaction of (negotiation between) securely created and independently submitted sets of content and or apphance control information. Different sets of content and/or apphance control information can be submitted by different parties in an electronic business value chain enabled by the present invention. These parties create control information sets through the use of their • respective VDE installations. Independently, securely dehverable. component based control information allows efficient interaction among control information sets supplied by different parties.

0105VDE permits multiple, separate electronic arrangements to be formed between subsets of parties in a VDE supported electronic value chain model. These multiple agreements together comprise a VDE value chain "extended" agreement. VDE allows such constituent electronic agreements, and therefore overall VDE extended agreements, to evolve and reshape over time as additional VDE participants become involved in VDE content and/or apphance control information handling. VDE electronic agreements may also be extended as new control information is submitted by existing participants. With VDE, electronic commerce participants are free to structure and restructure their electronic commerce business activities and relationships. As a result, the present invention allows a competitive electronic commerce marketplace to develop since the use of VDE enables different, widely varying business models using the same or shared content.

0106A significant facet of the present invention's abihty to broadly support electronic commerce is its abihty to securely manage independently delivered VDE component objects containing control information (normally in the form of VDE objects containing one or more methods, data, or load module VDE components). This independently delivered control information can be integrated with senior and other pre-existing content control information to securely form derived control information using the negotiation mechanisms of the present invention. All requirements specified by this derived control information must be satisfied before VDE controlled content can be accessed or otherwise used. This means that, for example, all load modules and any mediating data which are listed by the derived control information as required must be available and securely perform their required function. In combination with other aspects of the present invention, securely, independently dehvered control components allow electronic commerce participants to freely stipulate their business requirements and trade offs. As a result, much as with traditional, non-electronic commerce, the present invention allows electronic commerce

0107(through a progressive stipulation of various control requirements by VDE participants) to evolve into forms of business that are the most efficient, competitive and useful.

0108VDE provides capabihties that rationalize the support of electronic commerce and electronic transaction management. This rationalization stems from the reusability of control structures and user interfaces for a wide variety of transaction management related activities. As a result, content usage control, data security, information auditing, and electronic financial activities, can be supported with tools that are reusable, convenient, consistent, and familiar. In addition, a rational approach — a transaction distribution control standard — allows all participants in VDE the same foundation set of hardware control and security, authoring, administration, and management tools to support widely varying types of information, business market model, and/or personal objectives.

0109Employing VDE as a general purpose electronic transaction/distribution control system allows users to maintain a single transaction management control arrangement on each of their computers, networks, communication nodes, and/or other electronic apphances. Such a general purpose system can serve the needs of many electronic transaction management apphcations without requiring distinct, different installations for different purposes. As a result, users of VDE can avoid the confusion and expense and other inefficiencies of different, limited purpose transaction control apphcations for each different content and/or business model. For example, VDE allows content creators to use the same VDE foundation control arrangement for both content authoring and for licensing content from other content creators for inclusion into their products or for other use. Clearinghouses, distributors, content creators, and other VDE users can all interact, both with the apphcations running on their VDE installations, and with each other, in an entirely consistent ττ.^pτ.τ.^pr, using and reusing (largely transparently) the same distributed tools, mechanisms, and consistent user interfaces, regardless of the type of VDE activity.

0110VDE prevents many forms of unauthorized use of electronic information, by controlling and auditing (and other administration of use) electronically stored and/or disseminated information. This includes, for example, commercially distributed content, electronic currency, electronic credit, business transactions (such as EDI), confidential communications, and the like. VDE can further be used to enable commercially provided electronic content to be made available to users in user defined portions, rather than constraining the user to use portions of content that were "predeteπnined" by a content creator and/or other provider for billing purposes.

0111VDE, for example, can employ:

0112( 1 ) Secure metering means for budgeting and/or auditing electronic content and/or apphance usage;

0113(2) Secure flexible means for enabling compensation and/or billing rates for content and/or apphance usage, including electronic credit and/or currency mechanisms for payment means; (3) Secure distributed database means for storing control and usage related information (and employing validated compartmentalization and tagging schemes);

0114(4) Secure electronic apphance control means;

0115(5) A distributed, secure, "virtual black box" comprised of nodes located at every user (including VDE content container creators, other content providers, chent users, and recipients of secure VDE content usage information) site. The nodes of said virtual black box normally include a secure subsystem having at least one secure hardware element (a semiconductor element or other hardware module for securely executing VDE control processes), said secure subsystems being distributed at nodes along a pathway of information storage, distribution, payment, usage, and/or auditing. In some embodiments, the functions of said hardware element, for certain or all nodes, may be performed by software, for example, in host processing environments of electronic apphances;

0116(6) Encryption and decryption means; (7) Secure communications means employing authentication, digital signaturing, and encrypted transmissions. The secure subsystems at said user nodes utilize a protocol that establishes and authenticates each node's and/or participant's identity, and establishes one or more secure host-to-host encryption keys for communications between the secure subsystems; and

0117(8) Secure control means that can allow each VDE installation to perform VDE content authoring (placing content into VDE containers with associated control information), content distribution, and content usage; as well as clearinghouse and other administrative and analysis activities employing content usage information.

0118VDE may be used to migrate most non-electronic, traditional information dehvery models (including entertainment, reference materials, catalog shopping, etc.) into an adequately secure digital distribution and usage management and payment context. The distribution and financial pathways managed by a VDE arrangement may include:

0119! content creators), distributors), redistributor(s), chent aclministrator(s), chent user(s), financial and or other clearinghouse(s), and/or government agencies.

0120These distribution and financial pathways may also include:

0121advertisers, market survey organizations, and/or other parties interested in the user usage of information securely delivered and/or stored using

0122VDE.

0123Normally, participants in a VDE arrangement will employ the same secure VDE foundation. Alternate embodiments support VDE arrangements employing differing VDE foundations. Such alternate embodiments may employ procedures to ensure certain interoperability requirements are met.

0124Secure VDE hardware (also known as SPUs for Secure Processing Units), or VDE installations that use software to substitute for, or complement, said hardware (provided by Host Processing Environments (HPEs)), operate in conjunction with secure communications, systems integration software, and distributed software control information and support structures, to achieve the electronic contract rights protection environment of the present invention. Together, these VDE components comprise a secure, virtual, distributed content and/or apphance control, auditing (and other administration), reporting, and payment environment. In some embodiments and where commercially acceptable, certain VDE participants, such as clearinghouses that normally maintain sufficiently physically secure non- VDE processing environments, may be allowed to employ HPEs rather VDE hardware elements and interoperate, for example, with VDE end-users and content providers. VDE components together comprise a configurable, consistent, secure and "trusted" architecture for distributed, asynchronous control of electromc content and or apphance usage. VDE supports a

0125"universe wide" environment for electronic content dehvery, broad dissemination, usage reporting, and usage related payment activities.

0126VDE provides generalized configurability. This results, in part, from decomposition of generalized requirements for supporting electronic commerce and data security into a broad range of constituent "atomic" and higher level components (such as load modules, data elements, and methods) that may. be variously aggregated together to form control methods for electronic commerce apphcations, commercial electronic agreements, and data security arrangements. VDE provides a secure operating environment employing VDE foundation elements along with secure independently dehverable VDE components that enable electronic commerce models and relationships to develop. VDE specifically supports the unfolding of distribution models in which content providers, over time, can expressly agree to, or allow, subsequent content providers and/or users to participate in shaping the control information for, and consequences of, use of electronic content and/or apphances. A very broad range of the functional attributes important for supporting simple to very complex electronic commerce and data security activities are supported by capabihties of the present invention. As a result, VDE supports most types of electronic information and/or apphance: usage control (including distribution), security, usage auditing, reporting, other administration, and payment arrangements.

0127VDE, in its preferred embodiment, employs object software technology and uses object technology to form "containers" for dehvery of information that is (at least in part) encrypted or otherwise secured. These containers may contain electronic content products or other electronic information and some or all of their associated permissions (control) information. These container objects may be distributed along pathways involving content providers and or content users. They may be securely moved among nodes of a Virtual Distribution Environment (VDE) arrangement, which nodes operate VDE foundation software and execute control methods to enact electronic information usage control and/or administration models. The containers dehvered through use of the preferred embodiment of the present invention may be employed both for distributing VDE control instructions (information) and or to encapsulate and electronically distribute content that has been at least partially secured.

0128Content providers who employ the present invention may include, for example, software apphcation and game publishers, database publishers, cable, television, and radio broadcasters, electronic shopping vendors, and distributors of information in electronic document, book, periodical, e-mail and or other forms. Corporations, government agencies, and/or individual "end-users" who act as storers of, and/or distributors of, electronic information, may also be VDE content providers (in a restricted model, a user provides content only to himself and employs VDE to secure his own confidential information against unauthorized use by other parties). Electronic information may include proprietary and/or confidential information for personal or internal organization use, as well as information, such as software apphcations, documents, entertainment materials, and/or reference information, which may be provided to other parties. Distribution may be by, for example, physical media dehvery, broadcast and/or telecommunication means, and in the form of "static" files and/or streams of data. VDE may also be used, for example, for multi-site "real-time" interaction such as teleconferencing, interactive games, or on-line bulletin boards, where restrictions on, and/or auditing of, the use of all or portions of communicated information is enforced.

0129VDE provides important mechanisms for both enforcing commercial agreements and enabling the protection of privacy rights. VDE can securely dehver information from one party to another concerning the use of commercially distributed electronic content. Even if parties are separated by several "steps" in a chain (pathway) of handling for such content usage information, such information is protected by VDE through encryption and/or other secure processing. Because of that protection, the accuracy of such information is guaranteed by VDE, and the information can be trusted by all parties to whom it is dehvered. Furthermore, VDE guarantees that all parties can trust that such information cannot be received by anyone other than the intended, authorized, party(ies) because it is encrypted such that only an authorized party, or her agents, can decrypt it. Such information may also be derived through a secure VDE process at a previous pathway-of-handling location to produce secure VDE reporting information that is then communicated securely to its intended recipient's VDE secure subsystem. Because VDE can dehver such information securely, parties to an electronic agreement need not trust the accuracy of commercial usage and or other information dehvered through means other than those under control of VDE.

0130VDE participants in a commercial value chain can be "commercially" confident (that is, sufficiently confident for commercial purposes) that the direct (constituent) and/or

0131"extended" electronic agreements they entered into through the use of VDE can be enforced rehably. These agreements may have both "dynamic" transaction management related aspects, such as content usage control information enforced through budgeting, metering, and/or reporting of electronic information and/or apphance use, and or they may include "static" electronic assertions, such as an end-user using the system to assert his or her agreement to pay for services, not to pass to unauthorized parties electronic information derived from usage of content or systems, and/or agreeing to observe copyright laws. Not only can electronically reported transaction related information be trusted under the present invention, but payment may be automated by the passing of payment tokens through a pathway of payment (which may or may not be the same as a pathway for reporting). Such payment can be contained within a VDE container created automatically by a VDE installation in response to control information (located, in the preferred embodiment, in one or more permissions records) stipulating the "withdrawal" of credit or electronic currency (such as tokens) from an electronic account (for example, an account securely maintained by a user's VDE installation secure subsystem) based upon usage of VDE controlled electronic content and/or apphances (such as governments, financial credit providers, and users).

0132VDE allows the needs of electronic commerce participants to be served and it can bind such participants together in a universe wide, trusted commercial network that can be secure enough to support very large amounts of commerce. VDE's security and metering secure subsystem core will be present at all physical locations where VDE related content is (a) assigned usage related control information (rules and mediating data), and/or (b) used. This core can perform security and auditing functions (including metering) that operate within a "virtual black box," a collection of distributed, very secure VDE related hardware instances that are interconnected by secured information exchange (for example, telecommunication) processes and distributed database means. VDE further includes highly configurable transaction operating system technology, one or more associated libraries of load modules along with affiliated data, VDE related administration, data preparation, and analysis apphcations, as well as system software designed to enable VDE integration into host environments and apphcations. VDE's usage control information, for example, provide for property content and or apphance related: usage authorization, usage auditing (which may include audit reduction), usage billing, usage payment, privacy filtering, reporting, and security related communication and encryption techniques.

0133VDE extensively employs methods in the form of software objects to augment configurabihty, portabihty, and security of the

0134VDE environment. It also employs a software object architecture for VDE content containers that carries protected content and may also carry both freely available information (e.g, summary, table of contents) and secured content control information which ensures the performance of control information. Content control information governs content usage according to criteria set by holders of rights to an object's contents and/or according to parties who otherwise have rights associated with distributing such content (such as governments, financial credit providers, and users).

0135In part, security is enhanced by object methods employed by the present invention because the encryption schemes used to protect an object can efficiently be further used to protect the associated content control information (software control information and relevant data) from modification. Said object techniques also enhance portabihty between various computer and or other apphance environments because electronic information in the form of content can be inserted along with (for example, in the same object container as) content control information (for said content) to produce a "published" object. As a result, various portions of said control information may be specifically adapted for different environments, such as for diverse computer platforms and operating systems, and said various portions may all be carried by a VDE container.

0136An objective of VDE is supporting a transaction/distribution control standard. Development of such a standard has many obstacles, given the security requirements and related hardware and communications issues, widely differing environments, information types, types of information usage, business and/or data security goals, varieties of participants, and properties of dehvered information. A significant feature of VDE accommodates the many, varying distribution and other transaction variables by, in part, decomposing electronic commerce and data security functions into generalized capability modules executable within a secure hardware SPU and/or corresponding software subsystem and further allowing extensive flexibility in assembling, modifying, and/or replacing, such modules (e.g. load modules and/or methods) in apphcations run on a VDE installation foundation. This configurabihty and reconfigurabihty allows electronic commerce and data security participants to reflect their priorities and requirements through a process of iteratively shaping an evolving extended electronic agreement (electronic control model). This shaping can occur as content control information passes from one VDE participant to another and to the extent allowed by "in place" content control information. This process allows users of VDE to recast existing control information and/or add new control information as necessary (including the elimination of no longer required elements).

0137VDE supports trusted (sufficiently secure) electronic information distribution and usage control models for both commercial electronic content distribution and data security apphcations. It can be configured to meet the diverse requirements of a network of interrelated participants that may include content creators, content distributors, chent administrators, end users, and/or clearinghouses and/or other content usage information users. These parties may constitute a network of participants involved in simple to complex electronic content dissemination, usage control, usage reporting, and/or usage payment. Disseminated content may include both originally provided and VDE generated information (such as content usage information) and content control information may persist through both chains (one or more pathways) of content and content control information handling, as well as the direct usage of content. The configurability provided by the present invention is particularly critical for supporting electronic commerce, that is enabling businesses to create relationships and evolve strategies that offer competitive value. Electronic commerce tools that are not inherently configurable and interoperable will ultimately fail to produce products (and services) that meet both basic requirements and evolving needs ol^* most commerce apphcations.

0138VDE's fundamental configurabihty will allow a broad range of competitive electronic commerce business models to flourish. It allows business models to be shaped to maximize revenues sources, end-user product value, and operating efficiencies. VDE can be employed to support multiple, differing models, take advantage of new revenue opportunities, and dehver product configurations most desired by users. Electronic commerce technologies that do not, as the present invention does: ! support a broad range of possible, complementary revenue activities, ! offer a flexible array of content usage features most desired by customers, and ! exploit opportunities for operating efficiencies, will result in products that are often intrinsically more costly and less appealing and therefore less competitive in the marketplace.

0139Some of the key factors contributing to the configurabihty intrinsic to the present invention include:

0140(a) integration into the fundamental control environment of a broad range of electronic apphances through portable API and programming language tools that efficiently support merging of control and auditing capabihties in nearly any electronic apphance environment while maintaining overall system security;

0141(b) modular data structures;

0142(c) generic content model;

0143(d) general modularity and independence of foundation architectural components;

0144(e) modular security structures;

0145(f) variable length and multiple branching chains of control; and (g) independent, modular control structures in the form of executable load modules that can be maintained in one or more libraries, and assembled into control methods and models, and where such model control schemes can "evolve" as control information passes through the VDE installations of participants of a pathway of VDE content control information handling.

0146Because of the breadth of issues resolved by the present invention, it can provide the emerging "electronic highway" with a single transaction/distribution control system that can, for a very broad range of commercial and data security models, ensure against unauthorized use of confidential and/or proprietary information and commercial electronic transactions. VDE's electronic transaction management mechanisms can enforce the electronic rights and agreements of all parties participating in widely varying business and data security models, and this can be efficiently achieved through a single VDE implementation within each VDE participant's electronic apphance. VDE supports widely varying business and/or data security models that can involve a broad range of participants at various "levels" of VDE content and/or content control information pathways of handling. Different content control and/or auditing models and agreements may be available on the same VDE installation. These models and agreements may control content in relationship to, for example, VDE installations and/or users in general; certain specific users, installations, classes and/or other groupings of installations and/or users; as well as to electronic content generally on a given installation, to specific properties, property portions, classes and/or other groupings of content.

0147Distribution using VDE may package both the electronic content and control information into the same VDE container, and/or may involve the dehvery to an end-user site of different pieces of the same VDE managed property from plural separate remote locations and/or in plural separate VDE content containers and/or employing plural different dehvery means. Content control information may be partially or fully dehvered separately from its associated content to a user VDE installation in one or more VDE administrative objects. Portions of said control information may be dehvered from one or more sources. Control information may also be available for use by access from a user's VDE installation secure sub-system to one or more remote VDE secure sub-systems and or VDE compatible, certified secure remote locations. VDE control processes such as metering, budgeting, decrypting and/or fingerprinting, may as relates to a certain user content usage activity, be performed in a user's local VDE installation secure subsystem, or said processes may be divided amongst plural secure subsystems which may be located in the same user VDE installations and/or in a network server and in the user installation. For example, a local VDE installation may perform decryption and save any, or all of, usage metering information related to content and/or electronic apphance usage at such user installation could be performed at the server employing secure (e.g., encrypted) communications between said secure subsystems. Said server location may also be used for near real time, frequent, or more periodic secure receipt of content usage information from said user installation, with, for example, metered information being maintained only temporarily at a local user installation.

0148Dehvery means for VDE managed content may include electronic data storage means such as optical disks for dehvering one portion of said information and broadcasting and/or telecommunicating means for other portions of said information. Electronic data storage means may include magnetic media, optical media, combined magneto-optical systems, flash RAM memory, bubble memory, and/or other memory storage means such as huge capacity optical storage systems employing holographic, frequency, and/or polarity data storage techniques. Data storage means may also employ layered disc techniques, such as the use of generally transparent and/or translucent materials that pass light through layers of data carrying discs which themselves are physically packaged together as one thicker disc. Data carrying locations on such discs may be, at least in part, opaque.

0149VDE supports a general purpose foundation for secure transaction management, including usage control, auditing, reporting, and/or payment. This general purpose foundation is called "VDE Functions" ("VDEFs"). VDE also supports a collection of "atomic" apphcation elements (e.g., load modules) that can be selectively aggregated together to form various VDEF capabihties called control methods and which serve as VDEF apphcations and operating system functions. When a host operating environment of an electronic apphance includes VDEF capabihties, it is called a "Rights Operating System" (ROS). VDEF load modules, associated data, and methods form a body of information that for the purposes of the present invention are called "control information." VDEF control information may be specifically associated with one or more pieces of electronic content and/or it may be employed as a general component of the operating system capabilities of a VDE installation.

0150VDEF transaction control elements reflect and enact content specific and/or more generalized administrative (for example, general operating system) control information. VDEF capabihties which can generally take the form of apphcations (apphcation models) that have more or less configurabihty which can be shaped by VDE participants, through the use, for example, of VDE templates, to employ specific capabihties, along, for example, with capability parameter data to reflect the elements of one or more express electronic agreements between VDE participants in regards to the use of electronic content such as commercially distributed products. These control capabihties manage the use of, and/or auditing of use of, electronic content, as well as reporting information based upon content use, and any payment for said use. VDEF capabihties may "evolve" to reflect the requirements of one or more successive parties who receive or otherwise contribute to a given set of control information. Frequently, for a VDE apphcation for a given content model (such as distribution of entertainment on CD-ROM, content dehvery from an Internet repository, or electronic catalog shopping and advertising, or some combination of the above) participants would be able to securely select from amongst available, alternative control methods and apply related parameter data, wherein such selection of control method and/or submission of data would constitute their "contribution" of control information. Alternatively, or in addition, certain control methods that have been expressly certified as securely interoperable and compatible with said apphcation may be independently submitted by a participant as part of such a contribution. In the most general •example, a generally certified load module (certified for a given VDE arrangement and/or content class) may be used with many or any VDE apphcation that operates in nodes of said arrangement. These parties, to the extent they are allowed, can independently and securely add, delete, and/or otherwise modify the specification of load modules and methods, as well as add, delete or otherwise modify related information.

0151Normally the party who creates a VDE content container defines the general nature of the VDEF capabihties that will and or may apply to certain electronic information. A VDE content container is an object that contains both content ( for example, commercially distributed electronic information products such as computer software programs, movies, electronic publications or reference materials, etc.) and certain control information related to the use of the object's content. A creating party may make a VDE container available to other parties.

0152Control information dehvered by, and or otherwise available for use with, VDE content containers comprise (for commercial content distribution purposes) VDEF control capabihties (and any associated parameter data) for electronic content. These capabihties may constitute one or more "proposed" electronic agreements (and/or agreement functions available for selection and/or use with parameter data) that manage the use and/or the consequences of use of such content and which can enact the terms and conditions of agreements involving multiple parties and their various rights and obligations. A VDE electronic agreement may be explicit, through a user interface acceptance by one or more parties, for example by a "junior'' party who has received control information from a "senior" party, or it may be a process amongst equal parties who individually assert their agreement. Agreement may also result from an automated electronic process during which terms and conditions are "evaluated" by certain VDE participant control information that assesses whether certain other electronic terms and conditions attached to content and or submitted by another party are acceptable (do not violate acceptable control information criteria). Such an evaluation process may be quite simple, for example a comparison to ensure compatibility between a portion of, or all senior, control terms and conditions in a table of terms and conditions and the submitted control information of a subsequent participant in a pathway of content control information handling, or it may be a more elaborate process that evaluates the potential outcome of, and/or implements a negotiation process between, two or more sets of control information submitted by two or more parties. VDE also accommodates a semi- automated process during which one or more VDE participants directly, through user interface means, resolve "disagreements" between control information sets by accepting and/or proposing certain control information that may be acceptable to control information representing one or more other parties interests and/or responds to certain user interface queries for selection of certain alternative choices and or for certain parameter information, the responses being adopted if acceptable to applicable senior control information.

0153When another party (other than the first appher of rules), perhaps through a negotiation process, accepts, and/or adds to and or otherwise modifies, "in place" content control information, a VDE agreement between two or more parties related to the use of such electronic content may be created (so long as any modifications are consistent with senior control information).

0154Acceptance of terms and conditions related to certain electronic content may be direct and express, or it may be implicit as a result of use of content (depending, for example, on legal requirements, previous exposure to such terms and conditions, and requirements of in place control information).

0155VDEF capabihties may be employed, and a VDE agreement may be entered into, by a plurahty of parties without the VDEF capabihties being directly associated with the controlling of certain, specific electronic information. For example, certain one or more VDEF capabihties may be present at a VDE installation, and certain VDE agreements may have been entered into during the registration process for a content distribution apphcation, to be used by such installation for securely controlling VDE content usage, auditing, reporting and/or payment. Similarly, a specific VDE participant may enter into a VDE user agreement with a VDE content or electronic apphance provider when the user and/or her apphance register with such provider as a VDE installation and/or user. In such events, VDEF in place control information available to the user VDE installation may require that certain VDEF methods are employed, for example in a certain sequence, in order to be able to use all and/or certain classes, of electronic content and/or VDE apphcations.

0156VDE ensures that certain prerequisites necessary for a given transaction to occur are met. This includes the secure execution of any required load modules and the availability of any required, associated data. For example, required load modules and data (e.g. in the form of a method) might specify that sufficient credit from an authorized source must be confirmed as available. It might further require certain one or more load modules execute as processes at an appropriate time to ensure that such credit will be used in order to pay for user use of the content. A certain content provider might, for example, require metering the number of copies made for distribution to employees of a given software program (a portion of the program might be maintained in encrypted form and require the presence of a VDE installation to run). This would require the execution of a metering method for copying of the property each time a copy was made for another employee. This same provider might also charge fees based on the total number of different properties licensed from them by the user and a metering history of their licensing of properties might be required to maintain this information.

0157VDE provides organization, community, and/or universe wide secure environments whose integrity is assured by processes securely controlled in VDE participant user installations (nodes). VDE installations, in the preferred embodiment, may include both software and tamper resistant hardware semiconductor elements. Such a semiconductor arrangement comprises, at least in part, special purpose circuitry that has been designed to protect against tampering with, or unauthorized observation of, the information and functions used in performing the VDE's control functions. The special purpose secure circuitry provided by the present invention includes at least one of: a dedicated semiconductor arrangement known as a Secure Processing Unit (SPU) and/or a standard microprocessor, microcontroller, and/or other processing logic that accommodates the requirements of the present invention and functions as an SPU. VDE's secure hardware may be found incorporated into, for example, a fax/modem chip or chip pack, I/O controller, video .display controller, and/or other available digital processing arrangements. It is anticipated that portions of the present invention's VDE secure hardware capabihties may ultimately be standard design elements of central processing units (CPUs) for computers and various other electronic devices.

0158Designing VDE capabihties into one or more standard microprocessor, microcontroller and/or other digital processing components may materially reduce VDE related hardware costs by employing the same hardware resources for both the transaction management uses contemplated by the present invention and for other, host electronic apphance functions. This means that a VDE SPU can employ (share) circuitry elements of a "standard" CPU. For example, if a "standard" processor can operate in protected mode and can execute VDE related instructions as a protected activity, then such an embodiment may provide sufficient hardware security for a variety of apphcations and the expense of a special purpose processor might be avoided. Under one preferred embodiment of the present invention, certain memory (e.g., RAM, ROM, NVRAM) is maintained during VDE related instruction processing in a protected mode (for example, as supported by protected mode microprocessors). This memory is located in the same package as the processing logic (e.g. processor). Desirably, the packaging and memory of such a processor would be designed using security techniques that enhance its resistance to tampering. The degree of overall security of the VDE system is primarily dependent on the degree of tamper resistance and concealment of VDE control process execution and related data storage activities. Employing special purpose semiconductor packaging techniques can significantly contribute to the degree of security. Concealment and tamper-resistance in semiconductor memory (e.g., RAM, ROM, NVRAM) can be achieved, in part, by employing such memory within an SPU package, by encrypting data before it is sent to external memory (such as an external RAM package) and decrypting encrypted data within the

0159CPU/RAM package before it is executed. This process is used for important VDE related data when such data is stored on unprotected media, for example, standard host storage, such as random access memory, mass storage, etc. In that event, a VDE SPU would encrypt data that results from a secure VDE execution before such data was stored in external memory.

0160Summary of Some Important Features Provided by VDE in Accordance With the Present Invention VDE employs a variety of capabihties that serve as a foundation for a general purpose, sufficiently secure distributed electronic commerce solution. VDE enables an electronic commerce marketplace that supports divergent, competitive business partnerships, agreements, and evolving overall business models. For example, VDE includes features that: "sufficiently" impede unauthorized and/or uncompensated use of electronic information and/or apphances through the use of secure communication, storage, and transaction management technologies. 5 VDE supports a model wide, distributed security implementation which creates a single secure "virtual" transaction processing and information storage environment. VDE enables distributed VDE installations to securely store and communicate 10 information and remotely control the execution processes and the character of use of electronic information at other VDE installations and in a wide variety of ways;

016115 ! support low-cost, efficient, and effective security architectures for transaction control, auditing, reporting, and related communications and information storage. VDE may employ tagging related security techniques, the time-ageing of

016220 encryption keys, the compartmentalization of both stored control information (including differentially tagging such stored information to ensure against substitution and tampering) and distributed content (to, for many content apphcations, employ one or

016325 more content encryption keys that are unique to the specific VDE installation and/or user), private key techniques such as triple DES to encrypt content, pubhc key techniques such as RSA to protect communications and to provide the benefits of digital signature and authentication to securely bind together the nodes of a VDE arrangement, secure processing of important transaction management executable code, and a combining of a small amount of highly secure, hardware protected storage space with a much larger "exposed" mass media storage space storing secured (normally encrypted and tagged) control and audit information. VDE employs special purpose hardware distributed throughout some or all locations of a VDE implementation: a) said hardware controlling important elements of: content preparation (such as causing such content to be placed in a VDE content container and associating content control information with said content), content and/or electronic apphance usage auditing, content usage analysis, as well as content usage control; and b) said hardware having been designed to securely handle processing load module control activities, wherein said control processing activities may involve a sequence of required control factors; support dynamic user selection of information subsets of a VDE electronic information product (VDE controlled content). This contrasts with the constraints of having to use a few high level individual, pre-defined content provider information increments such as being required to select a whole information product or product section in order to acquire or otherwise use a portion of such product or section. VDE supports metering and usage control over a variety of increments (including "atomic" increments, and combinations of different increment types) that are selected ad hoc by a user and represent a collection of pre-identified one or more increments (such as one or more blocks of a preidentified nature, e.g., bytes, images, logically related blocks) that form a generally arbitrary, but logical to a user, content "dehverable." VDE control information (including budgeting, pricing and metering) can be configured so that it can specifically apply_? as appropriate, to ad hoc selection of different, unanticipated variable user selected aggregations of information increments and pricing levels can be, at least in part, based on quantities and/or nature of mixed increment selections (for example, a certain quantity of certain text could mean associated images might be discounted by 15%; a greater quantity of text in the "mixed" increment selection might mean the images are discounted 20%). Such user selected aggregated information increments can 5 reflect the actual requirements of a user for information and is more flexible than being limited to a single, or a few, high level, (e.g. product, document, database record) predetermined increments. Such high level increments may include

016410 quantities of information not desired by the user and as a result be more costly than the subset of information needed by the user if such a subset was available. In sum, the present invention allows information contained in electronic information

016515 products to be supplied according to user specification. Tailoring to user specification allows the present invention to provide the greatest value to users, which in turn will generate the greatest amount of electronic commerce activity. The user,

016620 for example, would be able to define an aggregation of content derived from various portions of an available content product, but which, as a dehverable for use by the user, is an entirely unique aggregated increment. The user may, for example,

016725 select certain numbers of bytes of information from various portions of an information product, such as a reference work, and copy them to disc in unencrypted form and be billed based on total number of bytes plus a surcharge on the number of 5 "articles" that provided the bytes. A content provider might reasonably charge less for such a user defined information increment since the user does not require all of the content from all of the articles that contained desired information. This

016810 process of defining a user desired information increment may involve artificial intelligence database search tools that contribute to the location of the most relevant portions of information from an information product and cause the automatic display

016915 to the user of information describing search criteria hits for user selection or the automatic extraction and dehvery of such portions to the user. VDE further supports a wide variety of predefined increment types including:

017020 ! bytes,

0171! images,

0172! content over time for audio or video, or any other increment that can be identified by content provider data mapping efforts, such as:

017325 ! sentences, paragraphs, articles, database records, and byte offsets representing increments of logically related information.

0174VDE supports as many simultaneous predefined increment types as may be practical for a given type of content and business model.

0175! securely store at a user's site potentially highly detailed infoπnation reflective of a user's usage of a variety of different content segment types and employing both inexpensive "exposed" host mass storage for maintaining detailed information in the form of encrypted data and maintaining summary information for security testing in highly secure special purpose VDE installation nonvolatile memory (if available).

0176! support trusted chain of handling capabihties for pathways of distributed electronic information and/or for content usage related information. Such chains may extend, for example, from a content creator, to a distributor, a redistributor, a chent user, and then may provide a pathway for securely reporting the same and or differing usage information to one or more auditors, such as to one or more independent clearinghouses and then back to the content providers, including content creators. The same and/or different pathways employed for certain content handling, and related content control information and reporting information handling, may also be employed as one or more pathways for electronic payment handling (payment is characterized in the present invention as administrative content) for electronic content and/or apphance usage. These pathways are used for conveyance of all or portions of content, and/or content related control information. Content creators and other providers can specify the pathways that, partially or fully, must be used to disseminate commercially distributed property content, content control information, payment administrative content, and/or associated usage reporting information. Control information specified by content providers may also specify which specific parties must or may (including, for example, a group of eligible parties from which a selection may be made) handle conveyed information. It may also specify what transmission means (for example telecommunication carriers or media types) and transmission hubs must or may be used.

0177! support flexible auditing mechanisms, such as

01785 employing "bitmap meters," that achieve a high degree of efficiency of operation and throughput and allow, in a practical manner, the retention and ready recall of infoπnation related to previous usage activities and related patterns. This flexibility is 10 adaptable to a wide variety of billing and security control strategies such as: P upgrade pricing (e.g. suite purchases), P pricing discounts (including quantity discounts), 15 P billing related time duration variables such as discounting new purchases based on the timing of past purchases, and P security budgets based on quantity of different, logically related units of electronic 20 information used over an interval of time.

0179Use of bitmap meters (including "regular" and "wide" bitmap meters) to record usage and/or purchase of information, in conjunction with other elements of 25 the preferred embodiment of the present invention, uniquely supports efficient maintenance of usage history for: (a) rental, (b) flat fee licensing or purchase, (c) licensing or purchase discounts based upon historical usage variables, and (d) reporting to 5 users in a manner enabling users to determine whether a certain item was acquired, or acquired within a certain time period (without requiring the use of conventional database mechanisms, which are highly inefficient for these apphcations). Bitmap

018010 meter methods record activities associated with electronic apphances, properties, objects, or portions thereof, and or administrative activities that are independent of specific properties, objects, etc., performed by a user and or electronic apphance such

018115 that a content and/or apphance provider and/or controller of an administrative activity can determine whether a certain activity has occurred at some point, or during a certain period, in the past (for example, certain use of a commercial electronic

018220 content product and/or apphance). Such determinations can then be used as part of pricing and or control strategies of a content and/or apphance provider, and/or controller of an administrative activity. For example, the content

018325 provider may choose to charge only once for access to a portion of a property, regardless of the number of times that portion of the property is accessed by a user.

01845 ! support "launchable" content, that is content that can be provided by a content provider to an end-user, who can then copy or pass along the content to other end-user parties without requiring the direct participation of a content provider to register and/or

018510 otherwise initialize the content for use. This content goes "out of (the traditional distribution) channel" in the form of a "traveling object." Traveling objects are containers that securely carry at least some permissions information and/or methods that are

018615 required for their use (such methods need not be carried by traveling objects if the required methods will be available at, or directly available to, a destination VDE installation). Certain travelling objects may be used at some or all VDE installations

018720 of a given VDE arrangement since they can make available the content control information necessary for content use without requiring the involvement of a commercial VDE value chain participant or data security administrator (e.g. a control officer or

018825 network administrator). As long as traveling object control information requirements are available at the user VDE installation secure subsystem (such as the presence of a sufficient quantity of financial credit from an authorized credit provider), at least some travelling object content may be used by a receiving party without the need to establish a connection with a remote VDE authority (until, for example, budgets are exhausted or a time content usage reporting interval has occurred). Traveling objects can travel "out-of-channel," allowing, for example, a user to give a copy of a traveling object whose content is a software program, a movie or a game, to a neighbor, the neighbor being able to use the traveling object if appropriate credit (e.g. an electronic clearinghouse account from a clearinghouse such as VISA or AT&T) is available. Similarly, electronic information that is generally available on an Internet, or a similar network, repository might be provided in the form of a traveling object that can be downloaded and subsequently copied by the initial downloader and then passed along to other parties who may pass the object on to additional parties. ! provide very flexible and extensible user identification according to individuals, installations, by groups such as classes, and by function and hierarchical identification employing a hierarchy of levels of chent identification (for example, chent organization ID, chent department ID, chent network ID, chent project ID, and chent employee ID, or any appropriate subset of the above).

0189! provide a general purpose, secure, component based content control and distribution system that functions as a foundation transaction operating system environment that employs executable code pieces crafted for transaction control and auditing. These code pieces can be reused to optimize efficiency in creation and operation of trusted, distributed transaction management arrangements. VDE supports providing such executable code in the form of "atomic" load modules and associated data. Many such load modules are inherently configurable, aggregatable, portable, and extensible and singularly, or in combination (along with associated data), run as control methods under the VDE transaction operating environment. VDE can satisfy the requirements of widely differing electronic commerce and data security apphcations by, in part, employing this general purpose transaction management foundation to securely process VDE transaction related control methods. Control methods are created primarily through the use of one or more of said executable, reusable load module code pieces (normally in the form of executable object components) and associated data. The component nature of control methods allows the present invention to efficiently operate as a highly configurable content control system. Under the present invention, content control models can be iteratively and asynchronously shaped, and otherwise updated to accommodate the needs of VDE participants to the extent that such shaping and otherwise updating conforms to constraints apphed by a VDE apphcation, if any (e.g., whether new component assembhes are accepted and, if so, what certification requirements exist for such component assembhes or whether any or certain participants may shape any or certain control information by selection amongst optional control information (permissions record) control methods. This iterative (or concurrent) multiple participant process occurs as a result of the submission and use of secure, control information components (executable code such as load modules and or methods, and/or associated data). These components may be contributed independently by secure communication 5 between each control information influencing VDE participant's VDE installation and may require certification for use with a given apphcation, where such certification was provided by a certification service manager for the VDE arrangement who

019010 ensures secure interoperability and/or reliability

0191(e.g., bug control resulting from interaction) between apphances and submitted control methods. The transaction management control functions of a VDE electronic apphance transaction operating

019215 environment interact with non-secure transaction management operating system functions to properly direct transaction processes and data related to electronic information security, usage control, auditing, and usage reporting. VDE provides the

019320 capability to manages resources related to secure

0194VDE content and/or apphance control information execution and data storage.

0195! facilitate creation of apphcation and/or system

019625 functionahty under VDE and to facilitate integration into electronic apphance environments of load modules and methods created under the present invention. To achieve this, VDE employs an Apphcation Programmer's Interface (API) and/or a transaction operating system (such as a ROS) rog amming language with incorporated functions, both of which support the use of capabihties and can be used to efficiently and tightly integrate VDE functionahty into commercial and user apphcations.

019710

0198! support user interaction through: (a) "Pop-Up" apphcations which, for example, provide messages to users and enable users to take specific actions such

019915 as approving a transaction, (b) stand-alone VDE apphcations that provide administrative environments for user activities such as: end-user preference specifications for limiting the price per transaction, unit of time, and/or session, for

020020 accessing history information concerning previous transactions, for reviewing financial information such as budgets, expenditures (e.g. detailed and/or summary) and usage analysis information, and (c) VDE aware apphcations which, as a result of the use

020125 of a VDE API and or a transaction management (for example, ROS based) programming language embeds VDE "awareness" into commercial or internal software (apphcation programs, games, etc.) so that VDE user control information and services 5 are seamlessly integrated into such software and can be directly accessed by a user since the underlying functionahty has been integrated into the commercial software's native design. For example, in a VDE aware word processor apphcation, a user

020210 may be able to "print" a document into a VDE content container object, applying specific control information by selecting from amongst a series of different menu templates for different purposes (for example, a confidential memo template for internal

020315 organization purposes may restrict the abihty to

0204"keep," that is to make an electronic copy of the memo).

0205! employ "templates" to ease the process of configuring

020620 capabihties of the present invention as they relate to specific industries or businesses. Templates are apphcations or apphcation add-ons under the present invention. Templates support the efficient specification and/or manipulation of criteria related 25 to specific content types, distribution approaches, pricing mechanisms, user interactions with content and/or administrative activities, and/or the like. Given the very large range of capabihties and configurations supported by the present invention, reducing the range of configuration opportunities to a manageable subset particularly appropriate for a given business model allows the full configurable power of the present invention to be easily employed by "typical" users who would be otherwise burdened with complex programming and/or configuration design responsibihties template apphcations can also help ensure that VDE related processes are secure and optimally bug free by reducing the risks associated with the contribution of independently developed load modules, including unpredictable aspects of code interaction between independent modules and apphcations, as well as security risks associated with possible presence of viruses in such modules. VDE, through the use of templates, reduces typical user configuration responsibihties to an appropriately focused set of activities including selection of method types (e.g. functionahty) through menu choices such as multiple choice, icon selection, and/or prompting for method parameter data (such as identification information, prices, budget limits, dates, periods of time, access rights to specific content, etc.) that supply appropriate and or necessary data for control information purposes. By limiting the typical (non-programming) user to a 5 limited subset of configuration activities whose general configuration environment (template) has been preset to reflect general requirements corresponding to that user, or a content or other business model can very substantially limit

020710 difficulties associated with content containerization

0208(including placing initial control information on content), distribution, chent acministration, electronic agreement implementation, end-user interaction, and clearinghouse activities, including

020915 associated interoperability problems (such as conflicts resulting from security, operating system, and or certification incompatibilities). Use of appropriate VDE templates can assure users that their activities related to content VDE

021020 containerization, contribution of other control information, communications, encryption techniques and/or keys, etc. will be in compliance with specifications for their distributed VDE arrangement. VDE templates constitute preset

021125 configurations that can normally be reconfigurable to allow for new and or modified templates that reflect adaptation into new industries as they evolve or to reflect the evolution or other change of an existing industry. For example, the template concept may be used to provide individual, overall frameworks for organizations and individuals that create, modify, market, distribute, consume, and/or otherwise use movies, audio recordings and hve performances, magazines, telephony based retail sales, catalogs, computer software, inforrnation data bases, multimedia, commercial communications, advertisements, market surveys, infomercials, games, CAD/CAM services for numerically controlled machines, and the like. As the context surrounding these templates changes or evolves, template apphcations provided under the present invention may be modified to meet these changes for broad use, or for more focused activities. A given VDE participant may have a plurahty of templates available for different tasks. A party that places content in its initial VDE container may have a variety of different, configurable templates depending on the type of content and/or business model related to the content. An end-user may have different configurable templates that can be apphed to different document types (e-mail, secure internal documents, database records, etc.) and/or subsets of users (applying differing general sets of control information to different bodies of users, for example, selecting a list of users who may, under certain preset criteria, use a certain document). Of course, templates may, under certain circumstances have fixed control information and not provide for user selections or parameter data entry.

021210 t support plural, different control models regulating the use and/or auditing of either the same specific copy of electronic information content and/or differently regulating different copies (occurrences)

021315 of the same electronic information content. Differing models for billing, auditing, and security can be apphed to the same piece of electronic information content and such differing sets of control information may employ, for control purposes, the same, or

021420 differing, granularities of electronic information control increments. This includes supporting variable control information for budgeting and auditing usage as apphed to a variety of predefined increments of electromc information, including

021525 employing a variety of different budgets and/or metering increments for a given electronic information dehverable for: billing units of measure, credit limit, security budget limit and security content metering increments, and/or market surveying and customer profiling content metering increments. For example, a CD-ROM disk with a database of scientific articles might be in part billed according to a formula based on the number of bytes decrypted, number of articles containing said bytes decrypted, while a security budget might limit the use of said database to no more than 5% of the database per month for users on the wide area network it is installed on.

0216provide mechanisms to persistently maintain trusted content usage and reporting control information through both a sufficiently secure chain of handling of content and content control information and through various forms of usage of such content wherein said persistence of control may survive such use. Persistence of control includes the abihty to extract information from a VDE container object by creating a new container whose contents are at least in part secured and that contains both the extracted content and at least a portion of the control information which control information of the original container and/or are at least in part produced by control information of the original container for this purpose and or VDE installation control information 5 stipulates should persist and/or control usage of content in the newly formed container. Such control information can continue to manage usage of container content if the container is "embedded" into another VDE managed object, such as an object 10 which contains plural embedded VDE containers, each of which contains content derived (extracted) from a different source.

0217! enables users, other value chain participants (such

021815 as clearinghouses and government agencies), and/or user organizations, to specify preferences or requirements related to their use of electronic content and/or apphances. Content users, such as end-user customers using commercially distributed 20 content (games, information resources, software programs, etc.), can define, if allowed by senior control information, budgets, and/or other control information, to manage their own internal use of content. Uses include, for example, a user setting a 25 limit on the price for electronic documents that the user is willing to pay without prior express user authorization, and the user establishing the character of metering information he or she is willing to allow to be collected (privacy protection). This includes providing the means for content users to protect the privacy of information derived from their use of a VDE installation and content and or apphance usage auditing. In particular, VDE can prevent information related to a participant's usage of electronic content from being provided to other parties without the participant's tacit or exphcit agreement.

0219provide mechanisms that allow control information to "evolve" and be modified according, at least in part, to independently, securely dehvered further control information. Said control information may include executable code (e.g., load modules) that has been certified as acceptable (e.g., rehable and trusted) for use with a specific VDE apphcation, class of apphcations, and or a VDE distributed arrangement. This modification (evolution) of control information can occur upon content control information (load modules and any associated data) circulating to one or more VDE participants in a pathway of handling of control information, or it may occur upon control information being received from a VDE participant. Handlers in a pathway of handling of content control information, to the extent 5 each is authorized, can establish, modify, and/or contribute to, permission, auditing, payment, and reporting control information related to controlling, analyzing, paying for, and/or reporting usage of, electronic content and/or apphances (for example, as

022010 related to usage of VDE controlled property content).

0221Independently dehvered (from an independent source which is independent except in regards to certification), at least in part secure, control information can be employed to securely modify

022215 content control information when content control information has flowed from one party to another party in a sequence of VDE content control information handling. This modification employs, for example, one or more VDE component assembhes

022320 being securely processed in a VDE secure subsystem.

0224In an alternate embodiment, control information may be modified by a senior party through use of their VDE installation secure sub-system after receiving submitted, at least in part secured, control

022525 information from a "junior" party, normally in the form of a VDE administrative object. Control information passing along VDE pathways can represent a mixed control set, in that it may include: control information that persisted through a sequence of control information handlers, other control information that was allowed to be modified, and further control information representing new control information and/or mediating data. Such a control set represents an evolution of control information for disseminated content. In this example the overall content control set for a VDE content container is "evolving" as it securely (e.g. communicated in encrypted form and using authentication and digital signaturing techniques) passes, at least in part, to a new participant's VDE installation where the proposed control information is securely received and handled. The received control information may be integrated (through use of the receiving parties' VDE installation secure sub-system) with in-place control information through a negotiation process involving both control information sets. For example, the modification, within the secure sub-system of a content provider's VDE installation, of content control information for a certain VDE content container may have occurred as a result of the incorporation of required control information provided by a financial credit provider. Said credit provider may have employed their VDE installation to prepare and securely communicate 5 (directly or indirectly) said required control infoπnation to said content provider. Incorporating said required control information enables a content provider to allow the credit provider's credit to be employed by a content end-user to compensate for

022610 the end-user's use of VDE controlled content and/or apphances, so long as said end-user has a credit account with said financial credit provider and said credit account has sufficient credit available. Similarly, control information requiring the payment

022715 of taxes and/or the provision of revenue information resulting from electronic commerce activities may be securely received by a content provider. This control information may be received, for example, from a government agency. Content providers might be

022820 required by law to incorporate such control information into the control information for commercially distributed content and/or services related to apphance usage. Proposed control information is used to an extent allowed by senior

022925 control information and as determined by any _* negotiation trade-offs that satisfy priorities stipulated by each set (the received set and the proposed set). VDE also accommodates different control schemes specifically applying to different participants (e.g., individual participants and/or participant classes (types)) in a network of VDE content handling participants.

0230support multiple simultaneous control models for the same content property and/or property portion.

0231This allows, for example, for concurrent business activities which are dependent on electronic commercial product content distribution, such as acquiring detailed market survey information and/or supporting advertising, both of which can increase revenue and result in lower content costs to users and greater value to content providers. Such control information and/or overall control models may be apphed, as determined or allowed by control information, in differing manners to different participants in a pathway of content, reporting, payment, and/or related control information handling. VDE supports applying different content control information to the same and/or different content and/or apphance usage related activities, and/or to different parties in a content and/or apphance usage model, such that different parties (or classes of VDE users, for example) are subject to differing control information managing their use of 5 electronic information content. For example, differing control models based on the category of a user as a distributor of a VDE controlled content object or an end-user of such content may result in different budgets being apphed. Alternatively, for

023210 example, a one distributor may have the right to distribute a different array of properties than another distributor (from a common content collection provided, for example, on optical disc). An individual, and/or a class or other grouping of

023315 end-users, may have different costs (for example, a student, senior citizen, and/or poor citizen user of content who may be provided with the same or differing discounts) than a "typical" content user.

023420 ! support provider revenue information resulting from customer use of content and/or apphances, and/or provider and/or end-user payment of taxes, through the transfer of credit and/or electronic currency from said end-user and/or provider to a government

023525 agency, might occur "automatically" as a result of such received control information causing the generation of a VDE content container whose content includes customer content usage information reflecting secure, trusted revenue summary information and or detailed user transaction listings

0236(level of detail might depend, for example on type or size of transaction — information regarding a bank interest payment to a customer or a transfer of a large (e.g. over $10,000) might be, by law, automatically reported to the government). Such summary and or detailed information related to taxable events and/or currency, and/or creditor currency transfer, may be passed along a pathway of reporting and/or payment to the government in a VDE container. Such a container may also be used for other VDE related content usage reporting information.

0237support the flowing of content control information through different "branches" of content control information handling so as to accommodate, under the present invention's preferred embodiment, diverse controlled distributions of VDE controlled content. This allows different parties to employ the same initial electronic content with differing (perhaps competitive) control strategies. In this instance, a party who first placed control information on content can make certain control assumptions and these assumptions would evolve into more 5 specific and/or extensive control assumptions. These control assumptions can evolve during the branching sequence upon content model participants submitting control information changes, for example, for use in "negotiating" with "in place" content

023810 control information. This can result in new or modified content control information and or it might involve the selection of certain one or more already "in-place" content usage control methods over in-place alternative methods, as well as the

023915 submission of relevant control information parameter data. This form of evolution of different control information sets apphed to different copies of the same electronic property content and/or apphance results from VDE control information

024020 flowing "down" through different branches in an overall pathway of handling and control and being modified differently as it diverges down these different pathway branches. This abihty of the present invention to support multiple pathway

024125 branches for the flow of both VDE content control information and VDE managed content enables an electronic commerce marketplace which supports diverging, competitive business partnerships, agreements, and evolving overall business models 5 which can employ the same content properties combined, for example, in differing collections of content representing differing at least in part competitive products.

024210 ! enable a user to securely extract, through the use of the secure subsystem at the user's VDE installation, at least a portion of the content included within a VDE content container to produce a new, secure object (content container), such that the extracted

024315 information is maintained in a continually secure manner through the extraction process. Formation of the new VDE container containing such extracted content shall result in control information consistent with, or specified by, the source VDE content

024420 container, and/or local VDE installation secure subsystem as appropriate, content control information. Relevant control information, such as security and administrative information, derived, at least in part, from the parent (source) object's control

024525 information, will normally be automatically inserted into a new VDE content container object containing extracted VDE content. This process typically occurs under the control framework of a parent object and/or VDE installation control information 5 executing at the user's VDE installation secure subsystem (with, for example, at least a portion of this inserted control information being stored securely in encrypted form in one or more permissions records). In an alternative embodiment,

024610 the derived content control information apphed to extracted content may be in part or whole derived from, or employ, content control information stored remotely from the VDE installation that performed the secure extraction such as at a remote server

024715 location. As with the content control information for most VDE managed content, features of the present invention allows the content's control information to:

0248(a) "evolve," for example, the extractor of content 20 may add new control methods and/or modify control parameter data, such as VDE apphcation compliant methods, to the extent allowed by the content's in-place control information. Such new control information 25 might specify, for example, who may use at least a portion of the new object, and/or how said at least a portion of said extracted content may be used (e.g. when at least a portion may be used, or what portion or quantity of portions may be used);

0249(b) allow a user to combine additional content with at least a portion of said extracted content, such as material authored by the extractor and/or content (for example, images, video, audio, and or text) extracted from one or more other VDE container objects for placement directly into the new container;

0250(c) allow a user to securely edit at least a portion of said content while maintaining said content in a secure form within said VDE content container;

0251(d) append extracted content to a pre-existing

0252VDE content container object and attach associated control information - in these cases, user added information may be secured, e.g., encrypted, in part or as a whole, and may be subject to usage and/or auditing control information that differs from the those apphed to previously in place object content;

0253(e) preserve VDE control over one or more portions of extracted content after various forms of usage of said portions, for example, maintain content in securely stored form while allowing "temporary" on screen display of content or allowing a software program to be maintained in secure form but transiently decrypt any encrypted executing portion of said program (all, or only a portion, of said program may be encrypted to secure the program).

0254Generally, the extraction features of the present invention allow users to aggregate and/or disseminate and/or otherwise use protected electronic content information extracted from content container sources while maintaining secure

0255VDE capabihties thus preserving the rights of providers in said content information after various content usage processes. ! support the aggregation of portions of VDE controlled content, such portions being subject to differing VDE content container control information, wherein various of said portions may have been 5 provided by independent, different content providers from one or more different locations remote to the user performing the aggregation. Such aggregation, in the prefeπed embodiment of the present invention, may involve preserving at least a portion

025610 of the control information (e.g., executable code such as load modules) for each of various of said portions by, for example, embedding some or all of such portions individually as VDE content container objects within an overall VDE content container

025715 and or embedding some or all of such portions directly into a VDE content container. In the latter case, content control information of said content container may apply differing control information sets to various of such portions based upon said

025820 portions original control information requirements before aggregation. Each of such embedded VDE content containers may have its own control information in the form of one or more permissions records. Alternatively, a negotiation between control

025925 information associated with various aggregated portions of electronic content, may produce a control information set that would govern some or all of the aggregated content portions. The VDE content control information produced by the negotiation may 5 be uniform (such as having the same load modules and/or component assembhes, and/or it may apply differing such content control information to two or more portions that constitute an aggregation of VDE controlled content such as differing metering,

026010 budgeting, billing and/or payment models. For example, content usage payment may be automatically made, either through a clearinghouse, or directly, to different content providers for different potions.

026115

0262! enable flexible metering of, or other collection of information related to, use of electronic content and/or electronic apphances. A feature of the present invention enables such flexibility of metering

026320 control mechanisms to accommodate a simultaneous, broad array of: (a) different parameters related to electronic information content use; (b) different increment units (bytes, documents, properties, paragraphs, images, etc.) and/or other organizations

026425 of such electronic content; and or (c) different categories of user and or VDE installation types, such as chent organizations, departments, projects, networks, and/or individual users, etc. This feature of the present invention can be employed for content security, usage analysis (for example, market surveying), and/or compensation based upon the use and/or exposure to VDE managed content. Such metering is a flexible basis for ensuring payment for content royalties, licensing, purchasing, and or advertising. A feature of the present invention provides for payment means supporting flexible electronic currency and credit mechanisms, including the abihty to securely maintain audit trails reflecting information related to use of such currency or credit. VDE supports multiple differing hierarchies of chent organization control information wherein an organization chent administrator distributes control information specifying the usage rights of departments, users, and/or projects. Likewise, a department (division) network manager can function as a distributor (budgets, access rights, etc.) for department networks, projects, and/or users, etc. ! provide scalable, integratable, standardized control means for use on electronic apphances ranging from inexpensive consumer (for example, television set-top apphances) and professional devices (and 5 hand-held PDAs) to servers, mainframes, communication switches, etc. The scalable transaction management auditing technology of the present invention will result in more efficient and rehable interoperabihty amongst devices functioning

026510 in electronic commerce and/or data security environments. As standardized physical containers have become essential to the shipping of physical goods around the world, allowing these physical containers to universally "fit" unloading equipment,

026615 efficiently use truck and train space, and accommodate known arrays of objects (for example, boxes) in an efficient manner, so VDE electronic content containers may, as provided by the present invention, be able to efficiently move electronic

026720 information content (such as commercially published properties, electronic currency and credit, and content audit information), and associated content control information, around the world. Interoperabihty is fundamental to efficient electronic

026825 commerce. The design of the VDE foundation, VDE load modules, and VDE containers, are important features that enable the VDE node operating environment to be compatible with a very broad range of electronic apphances. The abihty, for example, for control methods based on load modules to execute in very "small" and inexpensive secure sub-system environments, such as environments with very little read write memory, while also being able to execute in large memory sub-systems that may be used in more expensive electronic apphances, supports consistency across many machines. This consistent VDE operating environment, including its control structures and container architecture, enables the use of standardized VDE content containers across a broad range of device types and host operating environments. Since VDE capabihties can be seamlessly integrated as extensions, additions, and/or modifications to fundamental capabihties of electronic apphances and host operating systems, VDE containers, content control information, and the VDE foundation will be able to work with many device types and these device types will be able to consistently and efficiently interpret and enforce VDE control information. Through this integration users can also benefit from a transparent interaction with many of the capabihties of VDE. VDE integration with software operating on a host electronic apphance supports a variety of capabilities that would be unavailable or less secure without such integration.

0269Through integration with one or more device apphcations and/or device operating environments, many capabilities of the present invention can be presented as inherent capabihties of a given electronic apphance, operating system, or apphance apphcation. For example, features of the present invention include: (a) VDE system software to in part extend and/or modify host operating systems such that they possesses VDE capabihties, such as enabling secure transaction processing and electronic information storage; (b) one or more apphcation programs that in part represent tools associated with VDE operation; and/or (c) code to be integrated into apphcation programs, wherein such code incorporates references into VDE system software to integrate VDE capabihties and makes such apphcations VDE aware (for example, word processors, database retrieval apphcations, spreadsheets, multimedia presentation authoring tools, film editing software, music editing software such as MIDI apphcations and the like, robotics control systems such as those associated with CAD/CAM environments and NCM software and the like, electronic mail systems, teleconferencing 5 software, and other data authoring, creating, handling, and/or usage apphcations including combinations of the above). These one or more features (which may also be implemented in firmware or hardware) may be employed in 10 conjunction with a VDE node secure hardware processing capability, such as a microcontroller(s), microprocessors), other CPU(s) or other digital processing logic.

027015 ! employ audit reconciliation and usage pattern evaluation processes that assess, through certain, normally network based, transaction processing reconciliation and threshold checking activities, whether certain violations of security of a VDE

027120 arrangement have occuπed. These processes are performed remote to VDE controlled content end-user VDE locations by assessing, for example, purchases, and or requests, for electronic properties by a given VDE installation. Apphcations for such

027225 reconciliation activities include assessing whether the quantity of remotely dehvered VDE controlled content corresponds to the amount of financial credit and/or electronic currency employed for the use of such content. A trusted organization can acquire information from content providers concerning the cost for content provided to a given VDE installation and or user and compare this cost for content with the credit and/or electronic currency disbursements for that installation and/or user. Inconsistencies in the amount of content dehvered versus the amount of disbursement can prove, and/or indicate, depending on the circumstances, whether the local VDE installation has been, at least to some degree, compromised (for example, certain important system security functions, such as breaking encryption for at least some portion of the secure subsystem and or VDE controlled content by uncovering one or more keys). Determining whether irregular patterns (e.g. unusually high demand) of content usage, or requests for dehvery of certain kinds of VDE controlled information during a certain time period by one or more VDE installations and/or users (including, for example, groups of related users whose aggregate pattern of usage is suspicious) may also be useful in determining whether security at such one or more installations, and/or by such one or more users, has been compromised, particularly when used in combination with an assessment of electronic credit and/or currency provided to one or more VDE users and/or installations, by some or all of their credit and or currency suppliers, compared with the disbursements made by such users and or installations.

0273! support security techniques that materially increase the time required to "break" a system's integrity. This includes using a collection of techniques that minimizes the damage resulting from comprising some aspect of the security features of the present inventions.

0274! provide a family of authoring, administrative, reporting, payment, and billing tool user apphcations that comprise components of the present invention's trusted secure, universe wide, distributed transaction control and administration system. These components support VDE related: object creation (including placing control information on content), secure object distribution and management (including distribution control information, financial related, and other usage analysis), chent internal VDE activities administration and control, security management, user interfaces, payment disbursement, and clearinghouse related functions. These components are designed to support highly secure, uniform, consistent, and standardized: electronic commerce and/or data security pathway(s) of handling, reporting, and/or payment; content control and administration; and human factors (e.g. user interfaces ) .

0275support the operation of a plurahty of clearinghouses, including, for example, both financial and user clearinghouse activities, such as those performed by a chent administrator in a large organization to assist in the organization's use of a VDE arrangement, including usage information analysis, and control of VDE activities by individuals and groups of employees such as specifying budgets and the character of usage rights available under

0276VDE for certain groups of and or individual, chent personnel, subject to control information series to control information submitted by the chent administrator. At a clearinghouse, one or more VDE installations may operate together with a trusted distributed database environment (which may include concurrent database processing means). A financial clearinghouse normally receives at its location securely dehvered content usage information, and user requests (such as requests for further credit, electronic currency, and/or higher credit limit). Reporting of usage information and user requests can be used for supporting electronic currency, hilling, payment and credit related activities, and or for user profile analysis and/or broader market survey analysis and marketing (consolidated) list generation or other information derived, at least in part, from said usage information, this information can be provided to content providers or other parties, through secure, authenticated encrypted communication to the VDE installation secure subsystems. Clearinghouse processing means would normally be connected to specialized I/O means, which may include high speed telecommunication switching means that may be used for secure communications between a clearinghouse and other VDE pathway participants.

0277securely support electronic currency and credit usage control, storage, and communication at, and between, VDE installations. VDE further supports automated passing of electronic currency and/or credit information, including payment tokens (such as in the form of electronic currency or credit) or 5 other payment information, through a pathway of payment, which said pathway may or may not be the same as a pathway for content usage information reporting. Such payment may be placed into a VDE container created automatically by a VDE

027810 installation in response to control information stipulating the "withdrawal" of credit or electronic currency from an electronic credit or currency account based upon an amount owed resulting from usage of VDE controlled electronic content and/or

027915 apphances. Payment credit or currency may then be automatically communicated in protected (at least in part encrypted) form through telecommunication of a VDE container to an appropriate party such as a clearinghouse, provider of original property content

028020 or apphance, or an agent for such provider (other than a clearinghouse). Payment information may be packaged in said VDE content container with, or without, related content usage information, such as metering information. An aspect of the present

028125 invention further enables certain information regarding currency use to be specified as unavailable to certain, some, or all VDE parties ("conditionally" to fully anonymous currency) and/or further can regulate certain content information, such as currency and/or credit use related information

0282(and/or other electronic information usage data) to be available only under certain strict circumstances, such as a court order (which may itself require authorization through the use of a court controlled VDE installation that may be required to securely access "conditionally" anonymous information). Currency and credit information, under the preferred embodiment of the present invention, is treated as administrative content;

0283support fingerprinting (also known as watermarking) for embedding in content such that when content protected under the present invention is released in clear form from a VDE object (displayed, printed, communicated, extracted, and/or saved), information representing the identification of the user and/or VDE installation responsible for tr-msfoπning the content into clear form is embedded into the released content. Fingerprinting is useful in providing an abihty to identify who extracted information in clear form a VDE container, or who made a copy of a VDE object or a portion of its contents. Since the identity of the user and/or other identifying information may be embedded in an obscure or generally concealed manner, in VDE container content and/or control information, potential copyright violators may be deterred from unauthorized extraction or copying. Fingerprinting normally is embedded into unencrypted electronic content or control information, though it can be embedded into encrypted content and later placed in unencrypted content in a secure VDE installation sub-system as the encrypted content carrying the fingerprinting information is decrypted. Electronic information, such as the content of a VDE container, may be fingerprinted as it leaves a network (such as Internet) location bound for a receiving party. Such repository information may be maintained in unencrypted form prior to communication and be encrypted as it leaves the repository. Fingerprinting would preferably take place as the content leaves the repository, but before the encryption step. Encrypted repository content can be decrypted, for example in a secure VDE sub-system, fingerprint information can be inserted, and then the content can be re-encrypted for transmission. Embedding identification information of the intended recipient user and/or VDE installation into content as it leaves, for example, an Internet repository, would provide important information that would identify or assist in identifying any party that managed to compromise the security of a VDE installation or the dehvered content. If a party produces an authorized clear form copy of VDE controlled content, including making unauthorized copies of an authorized clear form copy, fingerprint information would point back to that individual and/or his or her VDE installation. Such hidden information will act as a strong disincentive that should dissuade a substantial portion of potential content "pirates" from stealing other parties electronic information. Fingerprint information identifying a receiving party and or VDE installation can be embedded into a VDE object before, or during, decryption, rephcation, or communication of VDE content objects to receivers.

0284Fingerprinting electronic content before it is encrypted for transfer to a customer or other user provides information that can be very useful for identifying who received certain content which may have then been distributed or made available in unencrypted form. This information would be useful in tracking who may have "broken" the security of a VDE installation and was illegally making certain electronic content available to others. 5 Fingerprinting may provide additional, available information such as time and/or date of the release (for example extraction) of said content information. Locations for inserting fingerprints may be specified by VDE installation and or content container control

028510 information. This information may specify that certain areas and/or precise locations within properties should be used for fingerprinting, such as one or more certain fields of information or information types. Fingerprinting information may

028615 be incorporated into a property by modifying in a normally undetectable way color frequency and/or the brightness of certain image pixels, by shghtly modifying certain audio signals as to frequency, by modifying font character formation, etc. Fingerprint

028720 information, itself, should be encrypted so as to make it particularly difficult for tampered fingerprints to be interpreted as valid. Variations in fingerprint locations for different copies of the same property; "false" fingerprint information; and

028825 multiple copies of fingerprint information within a specific property or other content which copies employ different fingerprinting techniques such as information distribution patterns, frequency and or brightness manipulation, and encryption related techniques, are features of the present invention for increasing the difficulty of an unauthorized individual identifying fingerprint locations and erasing and/or modifying fingerprint information.

0289provide smart object agents that can carry requests, data, and/or methods, including budgets, authorizations, credit or currency, and content. For example, smart objects may travel to and/or from remote information resource locations and fulfill requests for electronic information content. Smart objects can, for example, be transmitted to a remote location to perform a specified database search on behalf of a user or otherwise "intelligently" search remote one or more repositories of information for user desired information. After identifying desired information at one or more remote locations, by for example, performing one or more database searches, a smart object may return via communication to the user in the form of a secure "return object" containing retrieved information. A user may be charged for the remote retrieving of information, the returning of information to the user's VDE installation, and/or the use of such information. In the latter case, a user may be charged only for the information in the return object that the user actually uses. Smart objects may have the means to request use of one or more services and/or resources. Services include locating other services and/or resources such as information resources, language or format translation, processing, credit (or additional credit) authorization, etc. Resources include reference databases, networks, high powered or specialized computing resources (the smart object may carry information to another computer to be efficiently processed and then return the information to the sending VDE installation), remote object repositories, etc. Smart objects can make efficient use of remote resources (e.g. centralized databases, super computers, etc.) while providing a secure means for charging users based on information and/or resources actually used.

0290support both "translations" of VDE electronic agreements elements into modern language printed agreement elements (such as English language agreements) and translations of electronic rights protection transaction management modern language agreement elements to electronic VDE agreement elements. This feature requires m-ύntaining a library of textual language that coπesponds to VDE load modules and/or methods and/or component assembhes. As VDE methods are proposed and/or employed for VDE agreements, a listing of textual terms and conditions can be produced by a VDE user apphcation which, in a prefened embodiment, provides phrases, sentences and/or paragraphs that have been stored and correspond to said methods and/or assembhes. This feature preferably employs artificial intelligence capabihties to analyze and automatically determine, and/or assist one or more users to determine, the proper order and relationship between the library elements corresponding to the chosen methods and/or assembhes so as to compose some or all portions of a legal or descriptive document. One or more users, and/or preferably an attorney (if the document a legal, binding agreement), would review the generated document material upon completion and employ such additional textual information and or editing as necessary to describe non electronic transaction elements of the agreement and make any other improvements that may be necessary. These features further support employing modern language tools that allow one or more users to make 5 selections from choices and provide answers to questions and to produce a VDE electronic agreement from such a process. This process can be interactive and the VDE agreement formulation process may employ artificial intelligence expert

029110 system technology that learns from responses and, where appropriate and based at least in part on said responses, provides further choices and/or questions which "evolves" the desired VDE electronic agreement.

029215

0293! support the use of multiple VDE secure subsystems in a single VDE installation. Various security and/or performance advantages may be realized by employing a distributed VDE design within a single

029420 VDE installation. For example, designing a hardware based VDE secure subsystem into an electronic apphance VDE display device, and designing said subsystem's integration with said display device so that it is as close as possible to the

029525 point of display, will increase the security for video materials by making it materially more difficult to "steal" decrypted video information as it moves from outside to inside the video system. Ideally, for example, a VDE secure hardware module would be 5 in the same physical package as the actual display monitor, such as within the packaging of a video monitor or other display device, and such device would be designed, to the extent commercially practical, to be as tamper resistant as reasonable.

029610 As another example, embedding a VDE hardware module into an I/O peripheral may have certain advantages from the standpoint of overall system throughput. If multiple VDE instances are employed within the same VDE installation, these instances

029715 will ideally share resources to the extent practical, such as VDE instances storing certain control information and content and/or apphance usage information on the same mass storage device and in the same VDE management database.

029820

0299! requiring reporting and payment compliance by employing exhaustion of budgets and time ageing of keys. For example, a VDE commercial arrangement and associated content control information may

030025 involve a content provider's content and the use of clearinghouse credit for payment for end-user usage of said content. Control information regarding said arrangement may be dehvered to a user's (of said content) VDE installation and/or said financial clearinghouse's VDE installation. Said control information might require said clearinghouse to prepare and telecommunicate to said content provider both content usage based information in a certain form, and content usage payment in the form of electronic credit ( such credit might be "owned" by the provider after receipt and used in heu of the availability or adequacy of electronic currency) and/or electronic currency. This dehvery of information and payment may employ trusted VDE installation secure subsystems to securely, and in some embodiments, automatically, provide in the manner specified by said control information, said usage information and payment content. Features of the present invention help ensure that a requirement that a clearinghouse report such usage information and payment content will be observed. For example, if one participant to a VDE electronic agreement fails to observe such information reporting and/or paying obligation, another participant can stop the delinquent party from successfully participating in VDE activities related to such agreement. For example, if required usage information and payment was not reported as specified by content control information, the 5 "injured" party can fail to provide, through failing to securely communicate from his VDE installation secure subsystem, one or more pieces of secure information necessary for the continuance of one or more critical processes. For example, failure to

030110 report information and/or payment from a clearinghouse to a content provider (as well as any security failures or other disturbing irregularities) can result in the content provider not providing key and/or budget refresh information to the

030215 clearinghouse, which information can be necessary to authorize use of the clearinghouse's credit for usage of the provider's content and which the clearinghouse would communicate to end-user's during a content usage reporting communication

030320 between the clearinghouse and end-user. As another example, a distributor that failed to make payments and/or report usage information to a content provider might find that their budget for creating permissions records to distribute the content

030425 provider's content to users, and/or a security budget limiting one or more other aspect of their use of the provider's content, are not being refreshed by the content provider, once exhausted or timed-out (for example, at a predetermined date). In these and other cases, the offended party might decide not to refresh time ageing keys that had "aged out." Such a use of time aged keys has a similar impact as failing to refresh budgets or time-aged authorizations.

0305support smart card implementations of the present invention in the form of portable electronic apphances, including cards that can be employed as secure credit, hanking, and/or money cards. A feature of the present invention is the use of portable VDEs as transaction cards at retail and other establishments, wherein such cards can "dock" with an establishment terminal that has a VDE secure sub-system and/or an online connection to a VDE secure and/or otherwise secure and compatible subsystem, such as a "trusted" financial clearinghouse (e.g., VISA, Mastercard). The VDE card and the terminal (and/or online connection) can securely exchange information related to a transaction, with credit and/or electronic currency being transferred to a merchant and or clearinghouse and transaction information flowing back to the card. Such a card can be used for transaction activities of all sorts. A docking station, such as a PCMCIA connector on an electronic apphance, such as a personal computer, can receive a consumer's VDE card at home. Such a station/card combination can be used for on-line transactions in the same manner as a VDE installation that is permanently installed in such an electronic apphance. The card can be used as an "electronic wallet" and contain electronic currency as well as credit provided by a clearinghouse. The card can act as a convergence point for financial activities of a consumer regarding many, if not all, merchant, banking, and on-line financial transactions, including supporting home banking activities. A consumer can receive his paycheck and/or investment earnings and/or "authentic" VDE content container secured detailed information on such receipts, through on-line connections. A user can send digital currency to another party with a VDE arrangement, including giving away such currency. A VDE card can retain details of transactions in a highly secure and database organized fashion so that financially related information is both consolidated and very easily retrieved and/or analyzed. Because of the VDE security, including use of effective encryption, authentication, digital signaturing, and secure database structures, the records contained 5 within a VDE card arrangement may be accepted as valid transaction records for government and/or corporate recordkeeping requirements. In some embodiments of the present invention a VDE card may employ docking station and/or electronic

030610 apphance storage means and or share other VDE arrangement means local to said apphance and or available across a network, to augment the information storage capacity of the VDE card, by for example, storing dated, and/or archived, backup

030715 information. Taxes relating to some or ah of an individual's financial activities may be automatic ally computed based on "authentic" information securely stored and available to said VDE card. Said information may be stored in said card, in said

030820 docking station, in an associated electronic apphance, and/or other device operatively attached thereto, and/or remotely, such as at a remote server site. A card's data, e.g. transaction history, can be backed up to an individual's personal computer or

030925 other electronic apphance and such an apphance may have an integrated VDE installation of its own. A current transaction, recent transactions (for redundancy), or all or other selected card data may be backed up to a remote backup repository, such a 5 VDE compatible repository at a financial clearinghouse, during each or periodic docking for a financial transaction and/or information communication such as a user/merchant transaction. Backing up at least the current transaction during a

031010 connection with another party's VDE installation

0311(for example a VDE installation that is also on a financial or general purpose electronic network), by posting transaction information to a remote clearinghouse and/or bank, can ensure that

031215 sufficient backup is conducted to enable complete reconstruction of VDE card internal information in the event of a card failure or loss.

0313! support certification processes that ensure

031420 authorized interoperabihty between various VDE instaUations so as to prevent VDE arrangements and or installations that unacceptably deviate in specification protocols from other VDE arrangements and/or instaUations from interoperating in a manner 25 that may introduce security (integrity and/or confidentiahty of VDE secured information), process control, and/or software compatibility problems. Certification validates the identity of VDE instaUations and/or their components, as weU as VDE users. Certification data can also serve as information that contributes to determining the decommissioning or other change related to VDE sites.

0315support the separation of fundamental transaction control processes through the use of event (triggered) based method control mechanisms. These event methods trigger one or more other VDE methods (which are available to a secure VDE sub-system) and are used to carry out VDE managed transaction related processing. These triggered methods include independently (separably) and securely processable component hilling management methods, budgeting management methods, metering management methods, and related auditing management processes. As a result of this feature of the present invention, independent triggering of metering, auditing, billing, and budgeting methods, the present invention is able to efficiently, concurrently support multiple financial currencies (e.g. doUars, marks, yen) and content related budgets, and/or hilling increments as weU as very flexible content distribution models.

0316support, complete, modular separation of the control structures related to (1) content event triggering, (2) auditing, (3) budgeting (including specifying no right of use or unlimited right of use), (4) billing, and (5) user identity (VDE instaUation, chent name, department, network, and/or user, etc.). The independence of these VDE control structures provides a flexible system which aUows plural relationships between two or more of these structures, for example, the abihty to associate a financial budget with different event trigger structures (that are put in place to enable controlling content based on its logical portions). Without such separation between these basic VDE capabihties, it would be more difficult to efficiently maintain separate metering, budgeting, identification, and/or billing activities which involve the same, differing (including overlapping), or entirely different, portions of content for metering, billing, budgeting, and user identification, for example, paying fees associated with usage of content, performing home banking, managing advertising services, etc. VDE modular separation of these basic capabihties supports the programming of plural, "arbitrary" relationships between one or differing content 5 portions (and/or portion units) and budgeting, auditing, and/or billing control information. For example, under VDE, a budget limit of $200 doUars or 300 German Marks a month may be enforced for decryption of a certain database and 2 U.S. DoUars

031710 or 3 German Marks may be charged for each record of said database decrypted (depending on user selected currency). Such usage can be metered while an additional audit for user profile purposes can be prepared recording the identity of each filed

031815 displayed. AdditionaUy, further metering can be conducted regarding the number of said database bytes that have been decrypted, and a related security budget may prevent the decrypting of more than 5% of the total bytes of said database per year.

031920 The user may also, under VDE (if aUowed by senior control information;, coUect audit information reflecting usage of database fields by different individuals and chent organization departments and ensure that differing rights of access and differing

032025 budgets limiting database usage can be apphed to these chent individuals and groups. Enabling content providers and users to practicaUy employ such diverse sets of user identification, metering, budgeting, and billing control information results, in part, from the use of such independent control capabihties. As a result, VDE can support great configurabihty in creation of plural control models apphed to the same electronic property and the same and/or plural control models apphed to differing or entirely different content models (for example, home banking versus electronic shopping).

0321Methods, Other Control Information, and VDE Objects

0322VDE control information (e.g., methods) that coUectively control use of VDE managed properties (database, document, individual commercial product), are either shipped with the content itself (for example, in a content container) and or one or more portions of such control information is shipped to distributors and or other users in separably dehverable "administrative objects." A subset of the methods for a property may in part be dehvered with each property while one or more other subsets of methods can be dehvered separately to a user or otherwise made available for use (such as being avaUable remotely by telecommunication means). Required methods (methods listed as required for property and/or apphance use) must be avaUable as specified if VDE controUed content (such as inteUectual property distributed within a VDE content container) is to be used. Methods that control content may apply to a plurahty of VDE container objects, such as a class or other grouping of such objects. Methods may also be required by certain users or classes of users and/or VDE instaUations and/or classes of instaUations for such parties to use one or more specific, or classes of, objects.

0323A feature of VDE provided by the present invention is that certain one or more methods can be specified as required in order for a VDE instaUation and/or user to be able to use certain and/or aU content. For example, a distributor of a certain type of content might be aUowed by "senior" participants (by content creators, for example) to require a method which prohibits end-users from electronicaUy saving decrypted content, a provider of credit for VDE transactions might require an audit method that records the time of an electronic purchase, and/or a user might require a method that summarizes usage information for reporting to a clearinghouse (e.g. billing information) in a way that does not convey confidential, personal information regarding detahed usage behavior.

0324A further feature of VDE provided by the present invention is that creators, distributors, and users of content can select from among a set of predefined methods (if available) to control container content usage and distribution functions and/or they may have the right to provide new customized methods to control at least certain usage functions (such "new" methods may be required to be certified for trustedness and interoperabihty to the

0325VDE instaUation and/or for of a group of VDE apphcations). As a result, VDE provides a very high degree of configurabihty with respect to how the distribution and other usage of each property or object (or one or more portions of objects or properties as desired and or apphcable) will be controUed. Each VDE participant in a VDE pathway of content control information may set methods for some or aU of the content in a VDE container, so long as such control information does not conflict with senior control information already in place with respect to:

0326( 1 ) certain or aU VDE managed content,

0327(2) certain one or more VDE users and/or groupings of users,

0328(3) certain one or more VDE nodes and/or groupings of nodes, and/or

0329(4) certain one or more VDE apphcations and/or arrangements. For example, a content creator's VDE control information for certain content can take precedence over other submitted VDE participant control information and, for example, if aUowed by senior control information, a content distributor's control information may itself take precedence over a chent administrator's control information, which may take precedence over an end-user's control information. A path of distribution participant's abihty to set such electronic content control information can be limited to certain control information (for example, method mediating data such as pricing and/or sales dates) or it may be limited only to the extent that one or more of the participant's proposed control information conflicts with control information set by senior control information submitted previously by participants in a chain of handling of the property, or managed in said participant's VDE secure subsystem.

0330VDE control information may, in part or in fuU, (a) represent control information directly put in place by VDE content control information pathway participants, and or (b) comprise control information put in place by such a participant on behalf of a party who does not directly handle electronic content (or electronic apphance) permissions records information (for example control information inserted by a participant on behalf of a financial clearinghouse or government agency). Such control information methods ( and/or load modules and/or mediating data and/or component assembhes) may also be put in place by either an electronic automated, or a semi-automated and human assisted, control information (control set) negotiating process that assesses whether the use of one or more pieces of submitted control information will be integrated into and/or replace existing control information (and or chooses between alternative control information based upon interaction with in-place control information) and how such control information may be used.

0331Control information may be provided by a party who does not directly participate in the handling of electronic content (and/or apphance) and/or control information for such content (and/or apphance). Such control information may be provided in secure form using VDE instaUation secure sub-system managed communications (including, for example, authenticating the dehverer of at least in part encrypted control information) between such not directly participating one or more parties' VDE instaUation secure subsystems, and a pathway of VDE content control information participant's VDE instaUation secure subsystem. This control information may relate to, for example, the right to access credit supplied by a financial services provider, the enforcement of regulations or laws enacted by a government agency, or the requirements of a customer of VDE managed content usage information (reflecting usage of content by one or more parties other than such customer) relating to the creation, handling and/or manner of reporting of usage information received by such customer. Such control information may, for example, enforce societal requirements such as laws related to electronic commerce.

0332VDE content control information may apply differently to different pathway of content and/or control information handling participants. Furthermore, permissions records rights may be added, altered, and or removed by a VDE participant if they are aUowed to take such action. Rights of VDE participants may be defined in relation to specific parties and/or categories of parties and/or other groups of parties in a chain of handling of content and/or content control information (e.g., permissions records). Modifications to control information that may be made by a given, eligible party or parties, may be limited in the number of modifications, and or degree of modification, they may make.

0333At least one secure subsystem in electronic apphances of creators, distributors, auditors, clearinghouses, chent administrators, and end-users (understanding that two or more of the above classifications may describe a single user) provides a "sufficiently" secure (for the intended apphcations ) environment for: 1. Decrypting properties and control information;

03342. Storing control and metering related information; Ϊ 3. Managing communications;

03354. Processing core control programs, along with associated data, that constitute control information for electronic content and/or apphance rights protection, including the enforcing of preferences and requirements of VDE participants.

0336NormaUy, most usage, audit, reporting, payment, and distribution control methods are themselves at least in part encrypted and are executed by the secure subsystem of a VDE instaUation. Thus, for example, billing and metering records can be securely generated and updated, and encryption and decryption keys are securely utilized, within a secure subsystem. Since VDE also employs secure (e.g. encrypted and authenticated) communications when passing information between the participant location (nodes) secure subsystems of a VDE arrangement, important components of a VDE electronic agreement can be rehably enforced with sufficient security ( sufficiently trusted) for the intended commercial purposes. A VDE electronic agreement for a value chain can be composed, at least in part, of one or more subagreements between one or more subsets of the value chain participants. These subagreements are comprised of one or more electronic contract "compliance" elements (methods including associated parameter data) that ensure the protection of the rights of VDE participants.

0337The degree of trustedness of a VDE arrangement wiU be primarily based on whether hardware SPUs are employed at participant location secure subsystems and the effectiveness of the SPU hardware security architecture, software security techniques when an SPU is emulated in software, and the encryption algorithm(s and keys that are employed for securing content, control information, communications, and access to VDE node (VDE instaUation) secure subsystems. Physical facihty and user identity authentication security procedures may be used instead of hardware SPUs at certain nodes, such as at an established financial clearinghouse, where such procedures may provide sufficient security for trusted interoperabihty with a VDE arrangement employing hardware SPUs at user nodes.

0338The updating of property management files at each location of a VDE arrangement, to accommodate new or modified control information, is performed in the VDE secure subsystem and under the control of secure management file updating programs executed by the protected subsystem. Since aU secure communications are at least in part encrypted and the processing inside the secure subsystem is concealed from outside observation and interference, the present invention ensures that content control information can be enforced. As a result, the creator and/or distributor and/or chent administrator and/or other contributor of secure control information for each property (for example, an end-user restricting the kind of audit information he or she will aUow to be reported and/or a financial clearinghouse establishing certain criteria for use of its credit for payment for use of distributed content) can be confident that their contributed and accepted control information will be enforced (within the security limitations of a given VDE security implementation design). This control information can determine, for example:

0339( 1 ) How and/or to whom electronic content can be provided, for example, how an electronic property can be distributed;

0340(2) How one or more objects and/or properties, or portions of an object or property, can be directly used, such as decrypted, displayed, printed, etc;

0341(3 ) How payment for usage of such content and/or content portions may or must be handled; and (4) How audit information about usage information related to at least a portion of a property should be coUected, reported, and/or used.

0342Seniority of contributed control information, including resolution of confhcts between content control information submitted by multiple parties, is normaUy established by:

0343( 1 ) the sequence in which control information is put in place by various parties (in place control information normaUy takes precedence over subsequently submitted control information),

0344(2) the specifics of VDE content and/or apphance control information. For example, in-place control information can stipulate which subsequent one or more piece of control from one or more parties or class of parties will take precedence over control information submitted by one or more yet different parties and or classes of parties, and/or

0345(3 negotiation between control information sets from plural parties, which negotiation establishes what control information shaU constitute the resulting control information set for a given piece of VDE managed content and/or VDE instaUation.

0346Electronic Agreements and Rights Protection

0347An important feature of VDE is that it can be used to assure the administration of, and adequacy of security and rights protection for, electronic agreements implemented through the use of the present invention. Such agreements may involve one or more of:

0348(1) creators, publishers, and other distributors, of electronic information,

0349(2) financial service (e.g. credit) providers,

0350(3) users of (other than financial service providers) information arising from content usage such as content specific demographic information and user specific descriptive information. Such users may include market analysts, marketing list compilers for direct and directed marketing, and government agencies,

0351(4) end users of content, (5) infrastructure service and device providers such as telecommunication companies and hardware manufacturers (semiconductor and electronic apphance and/or other computer system manufacturers) who receive compensation based upon the use of their services and/or devices, and

0352(6) certain parties described by electronic information.

0353VDE supports commerciaUy secure "extended" value chain electronic agreements. VDE can be configured to support the various underlying agreements between parties that comprise this extended agreement. These agreements can define important electronic commerce considerations including:

0354(1) security,

0355(2) content use control, including electronic distribution,

0356(3) privacy (regarding, for example, information concerning parties described by medical, credit, tax. personal, and/or of other forms of confidential information),

0357(4) management of financial processes, and (5) pathways of handling for electronic content, content and/or apphance control information, electronic content and/or apphance usage information and payment and/or credit.

0358VDE agreements may define the electronic commerce relationship of two or more parties of a value chain, but such agreements may, at times, not directly obhgate or otherwise directly involve other VDE value chain participants. For example, an electronic agreement between a content creator and a distributor may establish both the price to the distributor for a creator's content (such as for a property distributed in a VDE container object) and the number of copies of this object that this distributor may distribute to end-users over a given period of time. In a second agreement, a value chain end-user may be involved in a three party agreement in which the end-user agrees to certain requirements for using the distributed product such as accepting distributor charges for content use and agreeing to observe the copyright rights of the creator. A third agreement might exist between the distributor and a financial clearinghouse that aUows the distributor to employ the clearinghouse's credit for payment for the product if the end-user has a separate (fourth) agreement directly with the clearinghouse extending credit to the end-user. A fifth, evolving agreement may develop between all value chain participants as content control information passes along its chain of handling. This evolving agreement can establish the rights of all parties to content usage information, including, for example, the nature of information to be received by each party and the pathway of handling of content usage information and related procedures. A sixth agreement in this example, may involve aU parties to the agreement and establishes certain general assumptions, such as security techniques and degree of trustedness (for example, commercial integrity of the system may require each VDE instaUation secure subsystem to electronicaUy warrant that their VDE node meets certain interoperabihty requirements). In the above example, these six agreements could comprise agreements of an extended agreement for this commercial value chain instance.

0359VDE agreements support evolving ("living") electronic agreement arrangements that can be modified by current and/or new participants through very simple to sophisticated "negotiations" between newly proposed content control information interacting with control information already in place and/or by negotiation between concurrently proposed content control information submitted by a plurahty of parties. A given model may be asynchronously and progressively modified over time in accordance with existing senior rules and such modification may be apphed to aU, to classes of, and/or to specific content, and/or to classes and/or specific users and/or user nodes. A given piece of content may be subject to different control information at different times or places of handling, depending on the evolution of its content control information (and/or on differing, applicable VDE installation content control information). The evolution of control information can occur during the passing along of one or more VDE control information containing objects, that is control information may be modified at one or more points along a chain of control information handling, so long as such modification is aUowed. As a result, VDE managed content may have different control information apphed at both different "locations" in a chain of content handling and at similar locations in differing chains of the handling of such content. Such different apphcation of control information may also result from content control information specifying that a certain party or group of parties shall be subject to content control information that differs from another party or group of parties. For example, content control information for a given piece of content may be stipulated as senior information and therefore not changeable, might be put in place by a content creator and might stipulate that national distributors of a given piece of their content may be permitted to make 100,000 copies per calendar quarter, so long as such copies are provided to boni fide end-users, but may pass only a single copy of such content to a local retailers and the control information limits such a retailer to making no more than 1,000 copies per month for retaU sales to end-users. In addition, for example, an end-user of such content might be limited by the same content control information to making three copies of such content, one for each of three different computers he or she uses (one desktop computer at work, one for a desktop computer at home, and one for a portable computer).

0360Electronic agreements supported by the prefeπed embodiment of the present invention can vary from very simple to very elaborate. They can support widely diverse information management models that provide for electronic information security, usage administration, and communication and may support:

0361(a) secure electronic distribution of information, for example commercial literary properties,

0362(b) secure electronic information usage monitoring and reporting,

0363(c) secure financial transaction capabihties related to both electronic information and/or apphance usage and other electronic credit and/or currency usage and administration capabihties, (d) privacy protection for usage information a user does not wish to release, and

0364(e) "hving" electronic information content dissemination models that flexibly accommodate:

0365( 1 ) a breadth of participants,

0366(2) one or more pathways (chains) for: the handling of content, content and/or apphance control information, reporting of content and/or apphance usage related information, and/or payment,

0367(3) supporting an evolution of terms and conditions incorporated into content control information, including use of electronic negotiation capabihties,

0368(4) support the combination of multiple pieces of content to form new content aggregations, and

0369(5) multiple concurrent models. Secure Processing Units

0370An important part of VDE provided by the present invention is the core secure transaction control arrangement, herein called an SPU (or SPUs), that typicaUy must be present in each user's computer, other electronic apphance, or network.

0371SPUs provide a trusted environment for generating decryption keys, encrypting and decrypting information, managing the secure communication of keys and other information between electronic apphances (i.e. between VDE instaUations and/or between plural VDE instances within a single VDE installation), securely accumulating and managing audit trail, reporting, and budget information in secure and/or non-secure non-volatile memory, maintaining a secure database of control information management instructions, and providing a secure environment for performing certain other control and administrative functions.

0372A hardware SPU (rather than a software emulation) within a VDE node is necessary if a highly trusted environment for performing certain VDE activities is required. Such a trusted environment may be created through the use of certain control software, one or more tamper resistant hardware modules such as a semiconductor or semiconductor chipset (including, for example, a tamper resistant hardware electronic apphance peripheral device), for use within, and/or operatively connected to, an electronic apphance. With the present invention, the trustedness of a hardware SPU can be enhanced by enclosing some or all of its hardware elements within tamper resistant packaging and/or by employing other tamper resisting techniques (e.g. microfusing and/or thin wire detection techniques). A trusted environment of the present invention implemented, in part, through the use of tamper resistant semiconductor design, contains control logic, such as a microprocessor, that securely executes VDE processes.

0373A VDE node's hardware SPU is a core component of a VDE secure subsystem and may employ some or all of an electronic apphance' s primary control logic, such as a microcontroUer, microcomputer or other CPU aπangement. This primary control logic may be otherwise employed for non VDE purposes such as the control of some or aU of an electronic appliance's non- VDE functions. When operating in a hardware SPU mode, said primary control logic must be sufficiently secure so as to protect and conceal important VDE processes. For example, a hardware SPU may employ a host electronic apphance microcomputer operating in protected mode while performing VDE related activities, thus allowing portions of VDE processes to execute with a certain degree of security. This alternate embodiment is in contrast to the preferred embodiment wherein a trusted environment is created using a combination of one or more tamper resistant semiconductors that are not part of said primary control logic. In either embodiment, certain control information (software and parameter data) must be securely maintained within the SPU, and further control information can be stored externaUy and securely (e.g. in encrypted and tagged form) and loaded into said hardware SPU when needed. In many cases, and in particular with microcomputers, the prefeπed embodiment approach of employing special purpose secure hardware for executing said VDE processes, rather than using said primary control logic, may be more secure and efficient. The level of security and tamper resistance required for trusted SPU hardware processes depends on the commercial requirements of particular markets or market niches, and may vary widely.

0374>TION OF THE DRAWINGS

0375These and other features and advantages provided by the present invention(s) may be better and more completely understood by referring to the foUowing detailed description of presently prefeπed example embodiments in connection with the drawings, of which:

0376FIGURE 1 illustrates an example of a "Virtual Distribution Environment" provided in accordance with a preferred example/embodiment of this invention;

0377FIGURE IA is a more detaUed illustration of an example of the "Information Utility" shown in FIGURE 1;

0378FIGURE 2 iUustrates an example of a chain of handling and control;

0379FIGURE 2 A iUustrates one example of how rules and control information may persist from one participant to another in the Figure 2 chain of handling and control; FIGURE 3 shows one example of different control information that may be provided;

0380FIGURE 4 iUustrates examples of some different types of rules and/or control information;

0381FIGURES 5A and 5B show an example of an "object";

0382FIGURE 6 shows an example of a Secure Processing Unit ("SPIT);

0383FIGURE 7 shows an example of an electronic apphance;

0384FIGURE 8 is a more detailed block diagram of an example of the electronic apphance shown in FIGURE 7;

0385FIGURE 9 is a detailed view of an example of the Secure Processing Unit (SPU) shown in FIGURES 6 and 8;

0386FIGURE 10 shows an example of a "Rights Operating

0387System" ("ROS") architecture provided by the Virtual Distribution Environment; FIGURES 11A-11C show examples of functional relationship(s) between apphcations and the Rights Operating System;

0388FIGURES 11D-11J show examples of "components" and "component assembhes";

0389FIGURE 12 is a more detailed diagram of an example of the Rights Operating System shown in FIGURE 10;

0390FIGURE 12A shows an example of how "objects" can be created;

0391FIGURE 13 is a detailed block diagram of an example the software architecture for a "protected processing environment" shown in FIGURE 12;

0392FIGURES 14A-14C are examples of SPU memory maps provided by the protected processing environment shown in FIGURE 13; FIGURE 15 iUustrates an example of how the channel services manager and load module execution manager of FIGURE 13 can support a channel;

0393FIGURE 15A is an example of a channel header and channel detail records shown in FIGURE 15;

0394FIGURE 15B is a flowchart of an example of program control steps that may be performed by the FIGURE 13 protected processing environment to create a channel;

0395FIGURE 16 is a block diagram of an example of a secure data base structure;

0396FIGURE 17 is an iUustration of an example of a logical object structure;

0397FIGURE 18 shows an example of a stationary object structure;

0398FIGURE 19 shows an example of a traveling object structure; FIGURE 20 shows an example of a content object

0399structure;

0400FIGURE 21 shows an example of an administrative object structure;

0401FIGURE 22 shows an example of a method core structure;

0402FIGURE 23 shows an example of a load module structure;

0403FIGURE 24 shows an example of a User Data Element (UDE) and/or Method Data Element (MDE) structure;

0404FIGURES 25A-25C show examples of "map meters";

0405FIGURE 26 shows an example of a permissions record (PERC) structure;

0406FIGURES 26A and 26B together show a more detailed example of a permissions record structure; FIGURE 27 shows an example of a shipping table structure;

0407FIGURE 28 shows an example of a receiving table structure;

0408FIGURE 29 shows an example of an administrative event log structure;

0409FIGURE 30 shows an example inter-relationship between and use of the object registration table, subject table and user rights table shown in the FIGURE 16 secure database;

0410FIGURE 31 is a more detailed example of an object registration table shown in FIGURE 16;

0411FIGURE 32 is a more detailed example of subject table shown in FIGURE 16;

0412FIGURE 33 is a more detailed example of a user rights table shown in FIGURE 16; FIGURE 34 shows a specific example of how a site record table and group record table may track portions of the secure database shown in FIGURE 16;

0413FIGURE 34A is an example of a FIGURE 34 site record table structure;

0414FIGURE 34B is an example of a FIGURE 34 group record table structure;

0415FIGURE 35 shows an example of a process for updating the secure database;

0416FIGURE 36 shows an example of how new elements may be inserted into the FIGURE 16 secure data base;

0417FIGURE 37 shows an example of how an element of the secure database may be accessed;

0418FIGURE 38 is a flowchart example of how to protect a secure database element; FIGURE 39 is a flowchart example of how to back up a secure database;

0419FIGURE 40 is a flowchart example of how to recover a secure database from a backup;

0420FIGURES 41A-41D are a set of examples showing how a "chain of handling and control" may be enabled using "reciprocal methods";

0421FIGURES 42A-42D show an example of a "reciprocal" BUDGET method;

0422FIGURES 43A-43D show an example of a "reciprocal" REGISTER method;

0423FIGURES 44A-44C show an example of a "reciprocal" AUDIT method;

0424FIGURES 45-48 show examples of several methods being used together to control release of content or other information; FIGURES 49, 49A-49F show an example OPEN method;

0425FIGURES 50, 50A-50F show an example of a READ method;

0426FIGURES 51, 51A-51F show an example of a WRITE method;

0427FIGURE 52 shows an example of a CLOSE method;

0428FIGURES 53A-53B show an example of an EVENT method;

0429FIGURE 53C shows an example of a BILLING method;

0430FIGURE 54 shows an example of an ACCESS method;

0431FIGURES 55A-55B show examples of DECRYPT and ENCRYPT methods;

0432FIGURE 56 shows an example of a CONTENT method; FIGURES 57A and 57B show examples of EXTRACT and EMBED methods;

0433FIGURE 58A shows an example of an OBSCURE method;

0434FIGURES 58B, 58C show examples of a FINGERPRINT method;

0435FIGURE 59 shows an example of a DESTROY method;

0436FIGURE 60 shows an example of a PANIC method;

0437FIGURE 61 shows an example of a METER method;

0438FIGURE 62 shows an example of a key "convolution" process;

0439FIGURE 63 shows an example of how different keys may be generated using a key convolution process to determine a "true" key; FIGURES 64 and 65 show an example of how protected processing environment keys may be initialized;

0440FIGURES 66 and 67 show example processes for decrypting information contained within stationary and traveling objects, respectively;

0441FIGURE 68 shows an example of how a protected processing environment may be initialized;

0442FIGURE 69 shows an example of how firmware may be downloaded into a protected processing environment;

0443FIGURE 70 shows an example of multiple VDE electronic apphances connected together with a network or other communications means;

0444FIGURE 71 shows an example of a portable VDE electronic apphance; FIGURES 72A-72D show examples of "pop-up" displays that may be generated by the user notification and exception interface;

0445FIGURE 73 shows an example of a "smart object";

0446FIGURE 74 shows an example of a process using "smart objects";

0447FIGURES 75A-75D show examples of data structures used for electronic negotiation;

0448FIGURES 75E-75F show example structures relating to an electronic agreement;

0449FIGURES 76A-76B show examples of electronic negotiation processes;

0450FIGURE 77 shows a further example of a chain of handling and control;

0451FIGURE 78 shows an example of a VDE "repository"; FIGURES 79-83 show an example illustrating a chain of handhng and control to evolve and transform VDE managed content and control information;

0452FIGURE 84 shows a further example of a chain of handhng and control involving several categories of VDE participants;

0453FIGURE 85 shows a further example of a chain of distribution and handling within an organization;

0454Figures 86 and 86A show a further example of a chain of

0455handhng and control; and

0456Figure 87 shows an example of a virtual silicon container

0457model.

MORE DETAILED DESCRIPTION

0459Figures 1-7 and the discussion below provides an overview of some aspects of features provided by this invention. FoUowing this overview is a more technical "detail description" of example embodiments in accordance with the invention.

0460Overview

0461Figure 1 shows a "Virtual Distribution Environment"

0462("VDE") 100 that may be provided in accordance with this invention. In Figure 1, an information utility 200 connects to communications means 202 such as telephone or cable TV lines for example. Telephone or cable TV lines 202 may be part of an "electronic highway" that carries electronic information from place to place. Lines 202 connect information utility 200 to other people

0463such as for example a consumer 208, an office 210, a video production studio 204, and a publishing house 214. Each of the people connected to information utihty 200 may be caUed a "VDE participant" because they can participate in transactions occurring within the virtual distribution environment 100.

0464Almost any sort of transaction you can think of can be supported by virtual distribution environment 100. A few of many examples of transactions that can be supported by virtual distribution environment 100 include:

0465C home ba-uking and electronic payments;

0466C electronic legal contracts;

0467C distribution of "content" such as electronic printed matter, video, audio, images and computer programs; and C secure communication of private information such as medical records and financial information.

0468Virtual distribution environment 100 is "virtual" because it does not require many of the physical "things" that used to be necessary to protect rights, ensure rehable and predictable distribution, and ensure proper compensation to content creators and distributors. For example, in the past, information was distributed on records or disks that were difficult to copy. In the past, private or secret content was distributed in sealed envelopes or locked briefcases dehvered by courier. To ensure appropriate compensation, consumers received goods and services only after they handed cash over to a seUer. Although information utihty 200 may dehver information by transferring physical "things" such as electronic storage media, the virtual distribution environment 100 facilitates a completely electronic "chain of handling and control."

0469VDE Flexibility Supports Transactions

0470Information utihty 200 flexibly supports many different kinds of information transactions. Different VDE participants may define and/or participate in different parts of a transaction. Information utihty 200 may assist with dehvering information about a transaction, or it may be one of the transaction participants.

0471For example, the video production studio 204 in the upper right-hand corner of Figure 1 may create video/television programs. Video production studio 204 may send these programs over lines 202, or may use other paths such as satellite li k 205 and CD ROM dehvery service 216. Video production studio 204 can send the programs directly to consumers 206, 208, 210, or it can send the programs to information utihty 200 which may store and later send them to the consumers, for example. Consumers 206, 208, 210 are each capable of receiving and using the programs created by video production studio 204 — assuming, that is, that the video production studio or information utihty 200 has arranged for these consumers to have appropriate "rules and controls" (control information) that give the consumers rights to use the programs.

0472Even if a consumer has a copy of a video program, she cannot watch or copy the program unless she has "rules and controls" that authorize use of the program. She can use the program only as permitted by the "rules and controls."

0473For example, video production studio 204 might release a half-hour exercise video in the hope that as many viewers as possible will view it. The video production studio 204 wishes to receive $2.00 per viewing. Video production studio 204 may, through information utihty 200, make the exercise video available in "protected" form to ah consumers 206, 208, 210. Video production studio 204 may also provide "rules and controls" for the video. These "rules and controls" may specify for example:

0474(1) any consumer who has good credit of at least $2.00 based on a credit account with independent financial provider 212 (such as Mastercard or VISA⁾ may watch the

0475video,

0476₍2₎ virtual distribution environment 100 wiU "meter" each time a consumer watches the video, and report usage to video production studio 204 from time to time, and

0477₍3) financial provider 212 may electronicaUy coUect payment ($2.00) from the credit account of each consumer who watches the video, and transfer these payments to the

0478video production studio 204.

0479Information utihty 200 aUows even a small video production studio to market videos to consumers and receive compensation for its efforts. Moreover, the videos can, with appropriate payment to the video production studio, be made available to other video publishers who may add value and/or act as repackagers or redistributors.

0480Figure 1 also shows a publishing house 214. Pubhshing house 214 may act as a distributor for an author 206. The publishing house 214 may distrihut^p rights to use "content" (such as computer software, electronic newspapers, the video produced by publishing house 214, audio, or any other data) to consumers such as office 210. The use rights may be defined by "rules and controls" distributed by pubhshing house 216. Pubhshing house

0481216 may distribute these "rules and controls" with the content, but this is not necessary. Because the content can be used only by consumers that have the appropriate "rules and controls," content emd its associated "rules and controls" may be distributed at different times, in different ways, by different VDE participants. The abihty of VDE to securely distribute and enforce "rules and controls" separately from the content they apply to provides great advantages.

0482Use rights distributed by publishing house 214 may, for example, permit office 210 to make and distribute copies of the content to its employees. Office 210 may act as a redistributor by extending a "chain of handhng and control" to its employees. The office 210 may add or modify "rules and controls" (consistent with the "rules and controls" it receives from publishing house 214) to provide office-internal control information and mechanisms. For example, office 210 may set a maximum usage budget for each individual user and/or group within the office, or it may permit only specified employees and/or groups to access certain information.

0483Figure 1 also shows an information dehvery service 216 dehvering electronic storage media such as "CD ROM" disks to consumers 206. Even though the electronic storage media themselves are not dehvered electronicaUy by information utihty 200 over lines 202, they are stiU part of the virtual distribution environment 100. The electronic storage media may be used to distribute content, "rules and controls," or other information.

0484Example of What's Inside Information Utility 200

0485"Information utihty" 200 in Figure 1 can be a coUection of participants that may act as distributors, financial clearinghouses, and administrators Figure IA shows an example of what may be inside one example of information utihty 200. Information utihty participants 200a-200g could each be an independent organization business. There can be any number of each of participants 200a-200g. In this example, electronic "switch" 200a connects internal parts of infoπnation utihty 200 to each other and to outside participants, and may also connect outside participants to one another.

0486Information utihty 200 may include a "transaction processor" 200b that processes transactions (to transfer electronic funds, for example) based on requests from participants and/or report receiver 200e. It may also include a "usage analyst" 200c that analyzes reported usage information. A "report creator" 200d may create reports based on usage for example, and may provide these reports to outside participants and/or to participants within information utihty 200. A "report receiver" 200e may receive reports such as usage reports from content users. A "permissioning agent" 200f may distribute "rules and controls" granting usage or distribution permissions based on a profile of a consumer's credit worthiness, for example. An administrator 200h may provide information that keeps the virtual distribution environment 100 operating properly. A content and message storage 200g may store information for use by participants within or outside of information utihty 200.

0487Example of Distributing Content" Using A Chain of Handling and Control"

0488As explained above, virtual distribution environment 100 can be used to manage almost any sort of transaction. One type of important transaction that virtual distribution environment 100 may be used to manage is the distribution or communication of "content" or other important information. Figure 2 more abstractly shows a "model" of how the Figure 1 virtual distribution environment 100 may be used to provide a "chain of handling and control" for distributing content. Each of the blocks in Figure 2 may correspond to one or more of the VDE participants shown in Figure 1.

0489In the Figure 2 example, a VDE content creator 102 creates "content." The content creator 102 may also specify "rules and controls" for distributing the content. These distribution-related "rules and controls" can specify who has permission to distribute the rights to use content, and how many users are aUowed to use the content. Arrow 104 shows the content creator 102 sending the "rules and controls" associated with the content to a VDE rights distributor 106 ("distributor) over an electronic highway 108 (or by some other path such as an optical disk sent by a dehvery service such as U. S. mail). The content can be distributed over the same or different path used to send the "rules and controls." The distributor 106 generates her own "rules and controls" that relate to usage of the content. The usage-related "rules and controls" may, for example, specify what a user can and can't do with the content and how much it costs to use the content. These usage-related "rules and controls" must be consistent with the "rules and controls" specified by content creator 102.

0490Arrow 110 shows the distributor 106 distributing rights to use the content by sending the content's "rules and controls" to a content user 112 such as a consumer. The content user 112 uses the content in accordance with the usage-related "rules and controls."

0491In this Figure 2 example, information relating to content use is, as shown by arrow 114, reported to a financial clearinghouse 116. Based on this "reporting," the financial clearinghouse 116 may generate a hill and send it to the content user 112 over a "reports and payments" network 118. Arrow 120 shows the content user 112 providing pa^yments for content usage to the financial clearinghouse 116. Based on the reports and payments it receives, the financial clearinghouse 116 may provide reports and/or payments to the distributor 106. The distributor 106 may, as shown by arrow 122, provide reports and/or payments to the content creator 102. The clearinghouse 116 may provide reports and payments directly to the creator 102. Reporting and/or payments may be done differently. For example, clearinghouse 116 may directly or through an agent, provide reports and or payments to each of VDE content creators 102, and rights distributor 106, as weU as reports to content user 112.

0492The distributor 106 and the content creator 102 may be the same person, or they may be different people. For example, a musical performing group may act as both content creator 102 and distributor 106 by creating and distributing its own musical recordings. As another example, a pubhshing house may act as a distributor 106 to distribute rights to use works created by an author content creator 102. Content creators 102 may use a distributor 106 to efficiently manage the financial end of content distribution.

0493The "financial clearinghouse" 116 shown in Figure 2 may also be a " F. A m n stra or " Financial clearinghouse 116 in its

0494VDE administrator role sends "adninistratiye" information to the VDE participants. This administrative information helps to keep the virtual distribution environment 100 operating properly. The "VDE administrator" and financial clearinghouse roles may be performed by different people or companies, and there can be more than one of each.

0495More abont Rules and Controls"

0496The virtual distribution environment 100 prevents use of protected information except as permitted by the "rules and controls" (control information). For example, the "rules and controls" shown in Figure 2 may grant specific individuals or classes of content users 112 "permission" to use certain content. They may specify what kinds of content usage are permitted, and what kinds are not. They may specify how content usage is to be paid for and how much it costs. As another example, "rules and controls" may require content usage information to be reported back to the distributor 106 and/or content creator 102.

0497Every VDE participant in "chain of handling and control" is normaUy subject to "rules and controls." "Rules and controls" define the respective rights and obligations of each of the various VDE participants. "Rules and controls" provide information and mechanisms that may establish interdependences and relationships between the participants. "Rules and controls" are flexible, and permit "virtual distribution environment" 100 to support most "traditional" business transactions. For example: C "Rules and controls" may specify which financial clearinghouse(s) 116 may process payments, C "Rules and controls" may specify which participant(s) receive what kind of usage report, and

0498C "Rules and controls" may specify that certain information is revealed to certain participants, and that other information is kept secret from them.

0499"Rules and controls" may self limit if and how they may be changed. Often, "rules and controls" specified by one VDE participant cannot be changed by another VDE participant. For example, a content user 112 generally can't change "rules and controls" specified by a distributor 106 that require the user to pay for content usage at a certain rate. "Rules and controls" may "persist" as they pass through a "chain of handling and control," and may be "inherited" as they are passed down from one VDE participant to the next.

0500Depending upon their needs, VDE participants can specify that their "rules and controls" can be changed under conditions specified by the same or other "rules and controls." For example,

0501"rules and controls" specified by the content creator 102 may permit the distributor 106 to "mark up" the usage price just as retail stores "mark up" the wholesale price of goods. Figure 2A shows an example in which certain "rules and controls" persist unchanged from content creator 102 to content user 112; other

0502"rules and controls" are modified or deleted by distributor 106; and stiU other "rules and controls" are added by the distributor.

0503"Rules and controls" can be used to protect the content user's privacy by limiting the information that is reported to other VDE participants. As one example, "rules and controls" can cause content usage information to be reported anonymously without revealing content user identity, or it can reveal only certain information to certain participants (for example, information derived from usage) with appropriate permission, if required. This abihty to securely control what information is revealed and what VDE participant(s) it is revealed to aUows the privacy rights of all VDE participants to be protected.

0504Rules and Contents" Can Be Separately Delivered

0505As mentioned above, virtual distribution environment 100 "associates" content with corresponding "rules and controls," and prevents the content from being used or accessed unless a set of corresponding "rules and controls" is available. The distributor 106 doesn't need to dehver content to control the content's distribution. The preferred embodiment can securely protect content by protecting corresponding, usage enabling "rules and controls" against unauthorized distribution and use.

0506In some examples, "rules and controls" may travel with the content they apply to. Virtual distribution environment 100 also allows "rules and controls" to be dehvered separately from content. Since no one can use or access protected content without "permission" from corresponding "rules and controls," the distributor 106 can control use of content that has already been (or wiU in the future be) dehvered. "Rules and controls" may be dehvered over a path different from the one used for content dehvery. "Rules and controls" may also be dehvered at some other time. The content creator 102 might dehver content to content user 112 over the electronic highway 108, or could make the content available to anyone on the highway. Content may be used at the time it is dehvered, or it may be stored for later use or reuse.

0507The virtual distribution environment 100 also aUows payment and reporting means to be dehvered separately. For example, the content user 112 may have a virtual "credit card" that extends credit (up to a certain limit) to pay for usage of any content. A "credit transaction" can take place at the user's site without requiring any "online" connection or further authorization. This invention can be used to help securely protect the virtual "credit card" against unauthorized use.

0508Rules and Contents" Define Processes

0509Figure 3 shows an example of an overaU process based on "rules and controls." It includes an "events" process 402, a meter process 404, a billing process 406, and a budget process 408. Not aU of the processes shown in Figure 3 will be used for every set of "rules and controls."

0510The "events process" 402 detects things that happen

0511("events") and determines which of those "events" need action by the other "processes." The "events" may include, for example, a request to use content or generate a usage permission. Some events may need additional processing, and others may not. Whether an "event" needs more processing depends on the "rules and controls" corresponding to the content. For example, a user who lacks permission wiU not have her request satisfied ("No Go"). As another example, each user request to turn to a new page of an electronic book may be satisfied ("Go"), but it may not be necessary to meter, bill or budget those requests. A user who has purchased a copy of a novel may be permitted to open and read the novel as many times as she wants to without any further metering, billing or budgeting. In this simple example, the "event process" 402 may request metering, billing and/or budgeting processes the first time the user asks to open the protected novel (so the purchase price can be charged to the user), and treat aU later requests to open the same novel as "insignificant events." Other content (for example, searching an electronic telephone directory) may require the user to pay a fee for each access.

0512"Meter" process 404 keeps track of events, and may report usage to distributor 106 and/or other appropriate VDE participant(s). Figure 4 shows that process 404 can be based on a number of different factors such as: (a) type of usage to charge for, (b) what kind of unit to base charges on,

0513(c) how much to charge per unit,

0514(d) when to report, and

0515(e) how to pay.

0516These factors may be specified by the "rules and controls" that control the meter process.

0517Billing process 406 determines how much to charge for events. It records and reports payment information.

0518Budget process 408 limits how much content usage is permitted. For example, budget process 408 may limit the number of times content may be accessed or copied, or it may limit the number of pages or other amount of content that can be used based on, for example, the number of doUars available in a credit account. Budget process 408 records and reports financial and other transaction information associated with such limits.

0519Content may be supphed to the user once these processes have been successfuUy performed.

0520Containers and Objects" Figure 5A shows how the virtual distribution environment

0521100, in a prefeπed embodiment, may package information elements (content) into a "container" 302 so the infoπnation can't be accessed except as provided by its "rules and controls." Normally, the container 302 is electronic rather than physical. Electronic container 302 in one example comprises "digital" information having a weU defined structure. Container 302 and its contents can be caUed an "object 300."

0522The Figure 5A example shows items "within" and enclosed by container 302. However, container 302 may "contain" items without those items actuaUy being stored within the container. For example, the container 302 may reference items that are available elsewhere such as in other containers at remote sites. Container 302 may reference items available at different times or only during limited times. Some items may be too large to store wit-άin container 302. Items may, for example, be dehvered to the user in the form of a "live feed" of video at a certain time. Even then, the container 302 "contains" the hve feed (by reference) in this example.

0523Container 302 may contain information content 304 in electronic (such as "digital") form. Information content 304 could be the text of a novel, a picture, sound such as a musical performance or a reading, a movie or other video, computer software, or just about any other kind of electronic information you can think of. Other types of "objects" 300 (such as "administrative objects") may contain "administrative" or other information instead of or in addition to information content 304.

0524In the Figure 5A example, container 302 may also contain "rules and controls" in the form of: (a) a "permissions record" 808:

0525(b) "budgets" 308; and

0526(c) "other methods" 1000. Figure 5B gives some additional detail about permissions record 808, budgets 308 and other methods 1000. The "permissions record" 808 specifies the rights associated with the object 300 such as, for example, who can open the container 302, who can use the object's contents, who can distribute the object, and what other control mechanisms must be active. For example, permissions record 808 may specify a user's rights to use, distribute and/or administer the container 302 and its content. Permissions record 808 may also specify requirements to be apphed by the budgets 308 and "other methods" 1000.

0527Permissions record 808 may also contain security related infoπnation such as scrambling and descrambling "keys."

0528"Budgets" 308 shown in Figure 5B are a special type of "method" 1000 that may specify, among other things, limitations on usage of information content 304, and how usage will be paid for. Budgets 308 can specify, for example, how much of the total information content 304 can be used and/or copied. The methods 310 may prevent use of more than the amount specified by a specific budget. "Other methods" 1000 define basic operations used by "rules and controls." Such "methods" 1000 may include, for example, how usage is to be "metered," if and how content 304 and other information is to be scrambled and descrambled, and other processes associated with handling and controlling information content 304. For example, methods 1000 may record the identity of anyone who opens the electronic container 302, and can also control how information content is to be charged based on "metering." Methods 1000 may apply to one or several different information contents 304 and associated containers 302, as weU as to all or specific portions of information content 304.

0529Secure Processing Unit (SPU)

0530The "VDE participants" may each have an "electronic appliance " The apphance may be or contain a computer. The apphances may communicate over the electronic highway 108.

0531Figure 6 shows a secure processing unit ("SPU") 500 portion of the "electronic apphance" used in this example by each VDE participant. SPU 500 processes information in a secure processing environment 503, and stores important information securely. SPU 500 may be emulated by software operating in a host electronic apphance. SPU 500 is enclosed within and protected by a "tamper resistant, security barrier" 502. Security barrier 502 separates the secure environment 503 from the rest of the world. It prevents information and processes within the secure environment 503 from being observed, interfered with and leaving except under appropriate secure conditions. Barrier 502 also controls external access to secure resources, processes and information within SPU 500. In one example, tamper resistant security barrier 502 is formed by security features such as "encryption," and hardware that detects tampering and or destroys sensitive information within secure environment 503 when tampering is detected.

0532SPU 500 in this example is an integrated circuit ("IC") "chip" 504 including "hardware" 506 and "firmware" 508. SPU

0533500 connects to the rest of the electronic apphance through an "applianre link" 510. SPU "firmware" 508 in this example is "software" such as a "computer program(s)" "embedded" within chip 504. Firmware 508 makes the hardware 506 work. Hardware 506 preferably contains a processor to perform instructions specified by firmware 508. "Hardware" 506 also contains long-term and short-term memories to store information securely so it can't be tampered with. SPU 500 may also have a protected clock/calendar used for timing events. The SPU hardware 506 in this example may include special purpose electronic circuits that are speciaUy designed to perform certain processes (such as "encryption" and "decryption") rapidly and efficiently.

0534The particular context in which SPU 500 is being used will determine how much processing capabihties SPU 500 should have. SPU hardware 506, in this example, provides at least enough processing capabihties to support the secure parts of processes shown in Figure 3. In some contexts, the functions of SPU 500 may be increased so the SPU can perform aU the electronic apphance processing, and can be incorporated into a general purpose processor. In other contexts, SPU 500 may work alongside a general purpose processor, and therefore only needs to have enough processing capabihties to handle secure processes. VDE Electronic Appliance and Rights Operating System"

0535Figure 7 shows an example of an electronic apphance 600 including SPU 500. Electronic apphance 600 may be practicaUy any kind of electrical or electronic device, such as:

0536C a computer C a T.V. "set top" control box C a pager C a telephone C a sound system

0537C a video reproduction system C a video game player C a "smart" credit card

0538Electronic apphance 600 in this example may include a keyboard or keypad 612, a voice recognizer 613, and a display 614. A human user can input commands through keyboard 612 and/or voice recognizer 613, and may view information on display 614. Apphance 600 may communicate with the outside world through any of the connections/devices normaUy used within an electronic apphance. The connections/devices shown along the bottom of the drawing are examples: a "modem" 618 or other telecommunications link; a CD ROM disk 620 or other storage medium or device; a printer 622; broadcast reception 624; a document scanner 626; and a "cable" 628 connecting the apphance with a "network."

0539Virtual distribution environment 100 provides a "rights operating system" 602 that manages apphance 600 and SPU 500 by controlling their hardware resources. The operating system

0540602 may also support at least one "apphcation" 608. GeneraUy, "apphcation" 608 is hardware and/or software specific to the context of apphance 600. For example, if apphance 600 is a personal computer, then "apphcation" 608 could be a program loaded by the user, for instance, a word processor, a communications system or a sound recorder. If apphance 600 is a television controUer box, then apphcation 608 might be hardware or software that aUows a user to order videos on demand and perform other functions such as fast forward and rewind. In this example, operating system 602 provides a standardized, weU defined, generalized "interface" that could support and work with many different "apphcations" 608. Operating system 602 in this example provides "rights and auditing operating system functions" 604 and "other operating FYff ftm functions" 606. The "rights and auditing operating system functions" 604 securely handle tasks that relate to virtual distribution environment 100. SPU 500 provides or supports many of the security functions of the "rights and auditing operating system functions" 402. The "other operating system functions" 606 handle general apphance functions. OveraU operating system 602 may be designed from the beginning to include the "rights and auditing operating system functions" 604 plus the "other operating system functions" 606, or the "rights and auditing operating system functions" may be an add-on to a preexisting operating system providing the "other operating system functions."

0541"Rights operating system" 602 in this example can work with many different types of apphances 600. For example, it can work with large mainframe computers, "minicomputers" and "microcomputers" such as personal computers and portable computing devices. It can also work in control boxes on the top of television sets, smaU portable "pagers," desktop radios, stereo sound systems, telephones, telephone switches, or any other electronic apphance. This abihty to work on big apphances as weU as little apphances is celled "scalable." A "scalable" operating system 602 means that there can be a standardized interface across many different apphances performing a wide variety of tasks.

0542The "rights operating system functions" 604 are "services- based" in this example. For example, "rights operating system functions" 604 handle summary requests from apphcation 608 rather than requiring the apphcation to always make more detailed "subrequests" or otherwise get involved with the underlying complexities involved in satisfying a summary request. For example, apphcation 608 may simply ask to read specified information; "rights operating system functions" 604 can then decide whether the desired information is VDE- protected content and, if it is, perform processes needed to make the information avaUable. This feature is caUed "transparency." "Transparency" makes tasks easy for the apphcation 608. "Rights operating system functions" 604 can support apphcations 608 that "know" nothing about virtual distribution environment

0543100. Apphcations 608 that are "aware" of virtual distribution environment 100 may be able to make more detailed use of virtual distribution environment 100.

0544In this example, "rights operating system functions" 604 are "event driven". Rather than repeatedly examining the state of electronic apphance 600 to determine whether a condition has arisen, the "rights operating system functions" 604 may respond directly to "events" or "happenings" within apphance 600.

0545In this example, some of the services performed by "rights operating system functions" 604 may be extended based on additional "components" dehvered to operating system 602. "Rights operating system functions" 604 can coUect together and use "components" sent by different participants at different times. The "components" help to make the operating system 602

0546"scalable." Some components can change how services work on little apphances versus how they work on big apphances (e.g., multi-user). Other components are designed to work with specific apphcations or classes of apphcations (e.g., some types of meters and some types of budgets).

0547Electronic Apphance 600 An electronic apphance 600 provided by the preferred embodiment may, for example, be any electronic apparatus that contains one or more microprocessors and/or microcontroUers and or other devices which perform logical and/or mathematical calculations. This may include computers; computer terminals; device controUers for use with computers; peripheral devices for use with computers; digital display devices; televisions; video and audio/video projection systems; channel selectors and/or decoders for use with broadcast and/or cable transmissions; remote control devices; video and/or audio recorders; media players including compact disc players, videodisc players and tape players; audio and/or video amplifiers; virtual reality machines; electronic game players; multimedia players; radios; telephones; videophones; facsiπ-ile machines; robots; numericaUy controUed machines including machine tools and the like; and other devices containing one or more microcomputers and or microcontroUers and/or other CPUs, including those not yet in existence.

0548Figure 8 shows an example of an electronic apphance 600. This example of electronic apphance 600 includes a system bus

0549653. In this example, one or more conventional general purpose central processing units ("CPUs") 654 are connected to bus 653. Bus 653 connects CPU(s) 654 to RAM 656, ROM 658, and I/O controUer 660. One or more SPUs 500 may also be connected to system bus 653. System bus 653 may permit SPU(s) 500 to communicate with CPU(s) 654, and also may aUow both the CPU(s) and the SPU(s) to communicate (e.g., over shared address and data lines) with RAM 656, ROM 658 and I/O controUer 660. A power supply 659 may provide power to SPU 500, CPU 654 and the other system components shown.

0550In the example shown, I/O controUer 660 is connected to secondary storage device 652, a keyboard/display 612,614, a communications controUer 666, and a backup storage device 668. Backup storage device 668 may, for example, store information on mass media such as a tape 670, a floppy disk, a removable memory card, etc. Communications controUer 666 may aUow electronic apphance 600 to communicate with other electronic apphances via network 672 or other telecommunications links. Different electronic apphances 600 may interoperate even if they use different CPUs and different instances of ROS 602, so long as they typicaUy use compatible communication protocols and/or security methods. In this example, I/O controUer 660 permits CPU 654 and SPU 500 to read from and write to secondary storage 662, keyboard/display 612, 614, communications controUer 666, and backup storage device 668.

0551Secondary storage 662 may comprise the same one or more non-secure secondary storage devices (such as a magnetic disk and a CD-ROM drive as one example) that electronic apphance 600 uses for general secondary storage functions. In some implementations, part or aU of secondary storage 652 may comprise a secondary storage device(s) that is physicaUy enclosed within a secure enclosure. However, since it may not be practical or cost-effective to physically secure secondary storage 652 in many implementations, secondary storage 652 may be used to store information in a secure manner by encrypting information before storing it in secondary storage 652. If information is encrypted before it is stored, physical access to secondary storage

0552652 or its contents does not readily reveal or compromise the information.

0553Secondary storage 652 in this example stores code and data used by CPU 654 and/or SPU 500 to control the overall operation of electronic apphance 600. For example, Figure 8 shows that "Rights Operating System" ("ROS") 602 (including a portion 604 of ROS that provides VDE functions and a portion 606 that provides other OS functions) shown in Figure 7 may be stored on secondary storage 652. Secondary storage 652 may also store one or more VDE objects 300. Figure 8 also shows that the secure files 610 shown in Figure 7 may be stored on secondary storage 652 in the form of a "secure database" or management file system 610. This secure database 610 may store and organize information used by ROS 602 to perform VDE functions 604. Thus, the code that is executed to perform VDE and other OS functions 604, 606, and secure files 610 (as weU as

0554VDE objects 300) associated with those functions may be stored in secondary storage 652. Secondary storage 652 may also store "other information" 673 such as, for example, information used by other operating system functions 606 for task management, non- VDE files, etc. Portions of the elements indicated in secondary storage 652 may also be stored in ROM 658, so long as those elements do not require changes (except when ROM 658 is replaced). Portions of ROS 602 in particular may desirably be included in ROM 658 (e.g., "bootstrap" routines, POST routines, etc. for use in establishing an operating environment for electronic apphance 600 when power is apphed). Figure 8 shows that secondary storage 652 may also be used to store code ("apphcation programs") providing user apphcation(s) 608 shown in Figure 7. Figure 8 shows that there may be two general types of apphcation programs 608: "VDE aware" apphcations 608a, and Non-VDE aware apphcations

0555608b. VDE aware apphcations 608a may have been at least in part designed specifically with VDE 100 in mind to access and take detailed advantage of VDE functions 604. Because of the "transparency" features of ROS 602, non-VDE aware apphcations 608b (e.g., apphcations not specificaUy designed for VDE 100) can also access and take advantage of VDE functions 604.

SECURE PROCESSING UNIT 500

0557Each VDE node or other electronic apphance 600 in the preferred embodiment may include one or more SPUs 500. SPUs

0558500 may be used to perform aU secure processing for VDE 100. For example, SPU 500 is used for decrypting (or otherwise unsecuring) VDE protected objects 300. It is also used for managing encrypted and/or otherwise secured communication (such as by employing authentication and/or error-correction validation of information). SPU 500 may also perform secure data management processes including governing usage of, auditing of, and where appropriate, payment for VDE objects 300 (through the use of prepayments, credits, real-time electronic debits from bank accounts and or VDE node currency token deposit accounts). SPU 500 may perform other transactions related to such VDE objects 300.

0559SPU Physical Packaging and Security Barrier 502

0560As shown Figure 6, in the preferred embodiment, an SPU 500 may be implemented as a single integrated circuit "chip" 505 to provide a secure processing environment in which confidential and or commerciaUy valuable information can be safely processed, encrypted and/or decrypted. IC chip 505 may, for example, comprise a smaU semiconductor "die" about the size of a thumbnail. This semiconductor die may include semiconductor and metal conductive pathways. These pathways define the circuitry, and thus the functionahty, of SPU 500. Some of these pathways are electricaUy connected to the external "pins" 504 of the chip 505.

0561As shown in Figures 6 and 9, SPU 500 may be surrounded by a tamper-resistant hardware security barrier 502. Part of this security barrier 502 is formed by a plastic or other package in which an SPU "die" is encased. Because the processing occurring within, and information stored by, SPU 500 are not easily accessible to the outside world, they are relatively secure from unauthorized access and tampering. AU signals cross barrier 502 through a secure, controUed path provided by BIU 530 that restricts the outside world's access to the internal components within SPU 500. This secure, controUed path resists attempts from the outside world to access secret information and resources within SPU 500.

0562It is possible to remove the plastic package of an IC chip and gain access to the "die." It is also possible to analyze and "reverse engineer" the "die" itself (e.g., using various types of logic analyzers and microprobes to coUect and analyze signals on the die while the circuitry is operating, using acid etching or other techniques to remove semiconductor layers to expose other layers, viewing and photographing the die using an electron microscope, etc.) Although no system or circuit is absolutely impervious to such attacks, SPU barrier 502 may include additional hardware protections that make successful attacks exceedingly costly and time consuming. For example, ion implantation and/or other fabrication techniques may be used to make it very difficult to visuaUy discern SPU die conductive pathways, and SPU internal circuitry may be fabricated in such a way that it "self-destructs" when exposed to air and/or hght. SPU 500 may store secret information in internal memory that loses its contents when power is lost. Circuitry may be incorporated within SPU 500 that detects microprobing or other tampering, and self-destructs (or destroys other parts of the SPU) when tampering is detected. These and other hardware-based physical security techniques contribute to tamper-resistant hardware security barrier 502.

0563To increase the security of security barrier 502 even further, it is possible to encase or include SPU 500 in one or more further physical enclosures such as, for example: epoxy or other "potting compound"; further module enclosures including additional self-destruct, self-disabling or other features activated when tampering is detected; further modules providing additional security protections such as requiring password or other authentication to operate; and the like. In addition, further layers of metal may be added to the die to comphcate acid etching, micro probing, and the like; circuitry designed to "zeroize" memory may be included as an aspect of self-destruct processes; the plastic package itself may be designed to resist chemical as weU as physical "attacks"; and memories internal to SPU 500 may have specialized addressing and refresh circuitry that "shuffles" the location of bits to comphcate efforts to electricaUy determine the value of memory locations. These and other techniques may contribute to the security of barrier 502.

0564In some electronic apphances 600, SPU 500 may be integrated together with the device microcontroUer or equivalent or with a device I/O or communications microcontroUer into a common chip (or chip set) 505. For example, in one preferred embodiment, SPU 500 may be integrated together with one or more other CPU(s) (e.g., a CPU 654 of an electronic apphance) in a single component or package. The other CPU(s) 654 may be any centraUy controlling logic arrangement, such as for example, a microprocessor, other microcontroUer, and or array or other paraUel processor. This integrated configuration may result in lower overaU cost, smaller overaU size, and potentiaUy faster interaction between an SPU 500 and a CPU 654. Integration may also provide wider distribution if an integrated SPU/CPU component is a standard feature of a widely distributed microprocessor line. Merging an SPU 500 into a main CPU 654 of an electronic apphance 600 (or into another apphance or apphance peripheral microcomputer or other microcontroUer) may substantiaUy reduce the overhead cost of implementing VDE 100. Integration considerations may include cost of implementation, cost of manufacture, desired degree of security, and value of compactness.

0565SPU 500 may also be integrated with devices other than CPUs. For example, for video and multimedia apphcations, some performance and/or security advantages (depending on overaU design) could result from integrating an SPU 500 into a video controUer chip or chipset. SPU 500 can also be integrated directly into a network communications chip or chipset or the like. Certain performance advantages in high speed communications apphcations may also result from integrating an

0566SPU 500 with a modem chip or chipset. This may facilitate incorporation of an SPU 500 into communication apphances such as stand-alone fax machines. SPU 500 may also be integrated into other peripheral devices, such as CD-ROM devices, set-top cable devices, game devices, and a wide variety of other electronic apphances that use, aUow access to, perform transactions related to, or consume, distributed information. SPU 500 Internal Architecture

0567Figure 9 is a detailed diagram of the internal structure within an example of SPU 500. SPU 500 in this example includes a single microprocessor 520 and a limited amount of memory configured as ROM 532 and RAM 534. In more detail, this example of SPU 500 includes microprocessor 520, an encrypt/decrypt engine 522, a DMA controUer 526, a real-time clock 528, a bus interface unit ("BIU") 530, a read only memory (ROM) 532, a random access memory (RAM) 534, and a memory management unit ("MMU") 540. DMA controUer 526 and MMU

0568540 are optional, but the performance of SPU 500 may suffer if they are not present. SPU 500 may also include an optional pattern matching engine 524, an optional random number generator 542, an optional arithmetic accelerator circuit 544, and optional compression/decompression circuit 546. A shared address/data bus arrangement 536 may transfer information between these various components under control of microprocessor 520 and or DMA controUer 526. Additional or alternate dedicated paths 538 may connect microprocessor 520 to the other components (e.g., encrypt/decrypt engine 522 via line

0569538a, real-time clock 528 via line 538b, bus interface unit 530 via line 538c, DMA controUer via line 538d, and memory management unit (MMU) 540 via line 538e).

0570The foUowing section discusses each of these SPU components in more detail.

0571Microprocessor 520

0572Microprocessor 520 is the "brain" of SPU 500. In this example, it executes a sequence of steps specified by code stored (at least temporarily) within ROM 532 and/or RAM 534.

0573Microprocessor 520 in the preferred embodiment comprises a dedicated central processing arrangement (e.g., a RISC and/or CISC processor unit, a microcontroUer, and/or other central processing means or, less desirably in most apphcations, process specific dedicated control logic) for executing instructions stored in the ROM 532 and or other memory. Microprocessor 520 may be separate elements of a circuitry layout, or may be separate packages within a secure SPU 500.

0574In the preferred embodiment, microprocessor 520 normaUy handles the most security sensitive aspects of the operation of electronic apphance 600. For example, microprocessor 520 may manage VDE decrypting, encrypting, certain content and/or apphance usage control information, keeping track of usage of VDE secured content, and other VDE usage control related functions.

0575Stored in each SPU 500 and or electronic apphance secondary memory 652 may be, for example, an instance of ROS 602 software, apphcation programs 608, objects 300 containing VDE controUed property content and related information, and management database 610 that stores both information associated with objects and VDE control information. ROS 602 includes software intended for execution by SPU microprocessor 520 for, in part, controlling usage of VDE related objects 300 by electronic apphance 600. As wiU be explained, these SPU programs include "load modules" for performing basic control functions. These various programs and associated data are executed and manipulated primarily by microprocessor 520.

0576Real Time Clock (RTC) 528 In the prefeπed embodiment, SPU 500 includes a real time clock circuit ("RTC") 528 that serves as a rehable, tamper resistant time base for the SPU. RTC 528 keeps track of time of day and date (e.g., month, day and year) in the preferred embodiment, and thus may comprise a combination calendar and clock. A rehable time base is important for implementing time based usage metering methods, "time aged decryption keys," and other time based SPU functions.

0577The RTC 528 must receive power in order to operate. OptimaUy, the RTC 528 power source could comprise a small battery located within SPU 500 or other secure enclosure. However, the RTC 528 may employ a power source such as an externaUy located battery that is external to the SPU 500. Such an externaUy located battery may provide relatively uninterrupted power to RTC 528, and may also maintain as non- volatile at least a portion of the otherwise volatile RAM 534 within SPU 500.

0578In one implementation, electronic apphance power supply 659 is also used to power SPU 500. Using any external power supply as the only power source for RTC 528 may significantly reduce the usefulness of time based security techniques unless, at minimum, SPU 500 recognizes any interruption (or any material interruption) of the supply of external power, records such interruption, and responds as may be appropriate such as disabling the abihty of the SPU 500 to perform certain or aU VDE processes. Recognizing a power interruption may, for example, be accomplished by employing a circuit which is activated by power faUure. The power failure sensing circuit may power another circuit that includes associated logic for recording one or more power fail events. Capacitor discharge circuitry may provide the necessary temporary power to operate this logic. In addition or alternatively, SPU 500 may from time to time compare an output of RTC 528 to a clock output of a host electronic apphance 600, if available. In the event a discrepancy is detected, SPU 500 may respond as appropriate, including recording the discrepancy and or disabling at least some portion of processes performed by SPU 500 under at least some circumstances.

0579If a power faUure and/or RTC 528 discrepancy and/or other event indicates the possibility of tampering, SPU 500 may automaticaUy destroy, or render inaccessible without privUeged intervention, one or more portions of sensitive information it stores, such as execution related information and/or encryption key related information. To provide further SPU operation, such destroyed information would have to be replaced by a VDE clearinghouse, administrator and/or distributor, as may be appropriate. This may be achieved by remotely downloading update and or replacement data and/or code. In the event of a disabling and/or destruction of processes and/or information as described above, the electronic apphance 600 may require a secure VDE communication with an administrator, clearinghouse, and/or distributor as appropriate in order to reinitialize the RTC 528. Some or aU secure SPU 500 processes may not operate until then.

0580It may be desirable to provide a mechanism for setting and/or synchronizing RTC 528. In the preferred embodiment, when communication occurs between VDE electronic apphance 600 and another VDE apphance, an output of RTC 528 may be compared to a controUed RTC 528 output time under control of the party authorized to be "senior" and controlling. In the event of a discrepancy, appropriate action may be taken, including resetting the RTC 528 of the "junior" controUed participant in the communication.

0581SPU Encrypt/Decrypt Engine 522 In the preferred embodiment, SPU encrypt/decrypt engine 522 provides special purpose hardware (e.g., a hardware state machine) for rapidly and efficiently encrypting and or decrypting data. In some implementations, the encrypt/decrypt functions may be performed instead by microprocessor 520 under software control, but providing special purpose encrypt decrypt hardware engine 522 will, in general, provide increased performance. Microprocessor 520 may, if desired, comprise a combination of processor circuitry and dedicated encryption/decryption logic that may be integrated together in the same circuitry layout so as to, for example, optimaUy share one or more circuit elements.

0582GeneraUy, it is preferable that a computationaUy efficient but highly secure "bulk" encryption/decryption technique should be used to protect most of the data and objects handled by SPU

0583500. It is preferable that an extremely secure encryption/decryption technique be used as an aspect of authenticating the identity of electronic apphances 600 that are establishing a communication channel and securing any transferred permission, method, and administrative information.

0584In the preferred embodiment, the encrypt/decrypt engine 522 includes both a symmetric key encryption decryption circuit (e.g. DES, Skipjack/Clipper, IDEA, RC-2, RC-4, etc.) and an antisymmetric (asymmetric) or Pubhc Key ("PK") encryption decryption circuit. The public/private key encryption/decryption circuit is used principaUy as an aspect of secure communications between an SPU 500 and VDE administrators, or other electronic apphances 600, that is between VDE secure subsystems. A symmetric encryption decryption circuit may be used for "bulk" encrypting and decrypting most data stored in secondary storage 662 of electronic apphance 600 in which SPU 500 resides. The symmetric key encryption decryption circuit may also be used for encrypting and decrypting content stored within VDE objects 300.

0585DES or public/private key methods may be used for aU encryption functions. In alternate embodiments, encryption and decryption methods other than the DES and public/private key methods could be used for the various encryption related functions. For instance, other types of symmetric encryption decryption techniques in which the same key is used for encryption and decryption could be used in place of DES encryption and decryption. The preferred embodiment can support a plurahty of deciyption encryption techniques using multiple dedicated circuits within encrypt/decrypt engine 522 and/or the processing arrangement within SPU 500.

0586Pattern Matching Engine 524

0587Optional pattern matching engine 524 may provide special purpose hardware for performing pattern matching functions. One of the functions SPU 500 may perform is to validate/authenticate VDE objects 300 and other items. Vahdation authentication often involves comparing long data strings to determine whether they compare in a predetermined way. In addition, certain forms of usage (such as logical and/or physical (contiguous) relatedness of accessed elements) may require searching potentiaUy long strings of data for certain bit patterns or other significant pattern related metrics. Although pattern matching can be performed by SPU microprocessor 520 under software control, providing special purpose hardware pattern matching engine 524 may speed up the pattern matching process.

0588Compression/Decompression Engine 546 An optional compression/decompression engine 546 may be provided within an SPU 500 to, for example, compress and or decompress content stored in, or released from, VDE objects 300. Compression/decompression engine 546 may implement one or more compression algorithms using hardware circuitry to improve the performance of compression/decompression operations that would otherwise be performed by software operating on microprocessor 520, or outside SPU 500. Decompression is important in the release of data such as video and audio that is usually compressed before distribution and whose decompression speed is important. In some cases, information that is useful for usage monitoring purposes (such as record separators or other delimiters) is "hidden" under a compression layer that must be removed before this information can be detected and used inside SPU 500.

0589Random Number Generator 542

0590Optional random number generator 542 may provide specialized hardware circuitry for generating random values (e.g., from inherently unpredictable physical processes such as quantum noise). Such random values are particularly useful for constructing encryption keys or unique identifiers, and for initializing the generation of pseudo-random sequences. Random number generator 542 may produce values of any convenient length, including as smaU as a single bit per use. A random number of arbitrary size may be constructed by concatenating values produced by random number generator 542. A cryptographicaUy strong pseudo-random sequence may be generated from a random key and seed generated with random number generator 542 and repeated encryption either with the encrypt decrypt engine 522 or cryptographic algorithms in SPU 500. Such sequences may be used, for example, in private headers to frustrate efforts to determine an encryption key through cryptoanalysis.

0591Arithmetic Accelerator 544 An optional arithmetic accelerator 544 may be provided within an SPU 500 in the form of hardware circuitry that can rapidly perform mathematical calculations such as multiphcation and exponentiation involving large numbers. These calculations can, for example, be requested by microprocessor 520 or encrypt/decrypt engine 522, to assist in the computations required for certain asymmetric encryption/decryption operations. Such arithmetic accelerators are weU-known to those skiUed in the art. In some implementations, a separate arithmetic accelerator 544 may be omitted and any necessary calculations may be performed by microprocessor 520 under software control.

0592DMA Controller 526

0593DMA controUer 526 controls information transfers over address/data bus 536 without requiring microprocessor 520 to process each individual data transfer. TypicaUy, microprocessor 520 may write to DMA controUer 526 target and destination addresses and the number of bytes to transfer, and DMA controUer 526 may then automatically transfer a block of data between components of SPU 500 (e.g., from ROM 532 to RAM 534, between encrypt/decrypt engine 522 and RAM 534, between bus interface unit 530 and RAM 534, etc.). DMA controUer 526 may have multiple channels to handle multiple transfers simultaneously. In some implementations, a separate DMA controUer 526 may be omitted, and any necessary data movements may be performed by microprocessor 520 under software control.

0594Bus Interface Unit (BIU) 530 Bus interface unit (BIU) 530 communicates infoπnation between SPU 500 and the outside world across the security barrier 502. BIU 530 shown in Figure 9 plus appropriate driver software may comprise the "apphance link" 510 shown in Figure 6. Bus interface unit 530 may be modeUed after a USART or PCI bus interface in the preferred embodiment. In this example, BIU 530 connects SPU 500 to electronic apphance system bus 653 shown in Figure 8. BIU 530 is designed to prevent unauthorized access to internal components within SPU 500 and their contents. It does this by only aUowing signals associated with an

0595SPU 500 to be processed by control programs running on microprocessor 520 and not supporting direct access to the internal elements of an SPU 500.

0596Memory Management Unit 540

0597Memory Management Unit (MMU) 540, if present, provides hardware support for memory management and virtual memory management functions. It may also provide heightened security by enforcing hardware compartmentalization of the secure execution space (e.g., to prevent a less trusted task from modifying a more trusted task). More details are provided below in connection with a discussion of the architecture of a Secure Processing Environment ("SPE") 503 supported by SPU 500.

0598MMU 540 may also provide hardware-level support functions related to memory management such as, for example, address mapping.

0599SPU Memory Architecture

0600In the preferred embodiment, SPU 500 uses three general kinds of memory:

0601(1) internal ROM 532;

0602(2) internal RAM 534; and

0603(3) external memory (typicaUy RAM and/or disk supphed by a host electronic apphance).

0604The internal ROM 532 and RAM 534 within SPU 500 provide a secure operating environment and execution space. Because of cost limitations, chip fabrication size, complexity and other limitations, it may not be possible to provide sufficient memory Vvithin SPU 500 to store all information that an SPU needs to process in a secure manner. Due to the practical limits on the amount of ROM 532 and RAM 534 that may be mcluded within SPU 500, SPU 500 may store infoπnation in memory external to it, and move this information into and out of its secure internal memory space on an as needed basis. In these cases, secure processing steps performed by an SPU typicaUy must be segmented into smaU, securely packaged elements that may be "paged in" and "paged out" of the limited available internal memory space. Memory external to an SPU 500 may not be secure. Since the external memory may not be secure, SPU 500 may encrypt and cryptographicaUy seal code and other information before storing it in external memory. Similarly, SPU

0605500 must typicaUy decrypt code and other information obtained from external memory in encrypted form before processing (e.g., executing) based on it. In the preferred embodiment, there are two general approaches used to address potential memory limitations in a SPU 500. In the first case, the small, securely packaged elements represent information contained in secure database 610. In the second case, such elements may represent protected (e.g., encrypted) virtual memory pages. Although virtual memory pages may correspond to information elements stored in secure database 610, this is not required in this example of a SPU memory architecture. The foUowing is a more detailed discussion of each of these three SPU memory resources.

0606SPU Internal ROM SPU 500 read only memory (ROM) 532 or comparable purpose device provides secure internal non-volatile storage for certain programs and other information. For example, ROM 532 may store "kernel" programs such as SPU control firmware 508 and, if desired, encryption key information and certain fundamental "load modules." The "kernel" programs, load module information, and encryption key information enable the control of certain basic functions of the SPU 500. Those components that are at least in part dependent on device configuration (e.g., POST, memory aUocation, and a dispatcher) may be loaded in ROM 532 along with additional load modules that have been determined to be required for specific installations or apphcations.

0607In the preferred embodiment, ROM 532 may comprise a combination of a masked ROM 532a and an EEPROM and/or equivalent "flash" memory 532b. EEPROM or flash memory 532b is used to store items that need to be updated and/or initialized, such as for example, certain encryption keys. An additional benefit of providing EEPROM and/or flash memory 532b is the abihty to optimize any load modules and library functions persistently stored within SPU 500 based on typical usage at a specific site. Although these items could also be stored in NVRAM 534b, EEPROM and/or flash memory 532b may be more cost effective.

0608Masked ROM 532a may cost less than flash and/or EEPROM 532b, and can be used to store permanent portions of

0609SPU software firmware. Such permanent portions may include, for example, code that interfaces to hardware elements such as the RTC 528, encryption/decryption engine 522, interrupt handlers, key generators, etc. Some of the operating system, library calls, libraries, and many of the core services provided by

0610SPU 500 may also be in masked ROM 532a. In addition, some of the more commonly used executables are also good candidates for inclusion in masked ROM 532a. Items that need to be updated or that need to disappear when power is removed from SPU 500 should not be stored in masked ROM 532a. Under some rircumstances, RAM 534a and/or NVRAM 534b (NVRAM 534b may, for example, be constantly powered conventional RAM) may perform at least part of the role of ROM 532.

0611SPU Internal RAM

0612SPU 500 general purpose RAM 534 provides, among other things, secure execution space for secure processes. In the preferred embodiment, RAM 534 is comprised of different types of RAM such as a combination of high-speed RAM 534a and an

0613NVRAM ("non-volatile RAM") 534b. RAM 534a may be volatile, while NVRAM 534b is preferably battery backed or otherwise arranged so as to be non-volatile (i.e., it does not lose its contents when power is turned off).

0614High-speed RAM 534a stores active code to be executed and associated data structures.

0615NVRAM 534b preferably contains certain keys and summary values that are preloaded as part of an initialization process in which SPU 500 communicates with a VDE administrator, and may also store changeable or changing information associated with the operation of SPU 500. For security reasons, certain highly sensitive information (e.g., certain load modules and certain encryption key related information such as internaUy generated private keys) needs to be loaded into or generated internaUy by SPU 500 from time to time but, once loaded or generated internaUy, should never leave the SPU. In this preferred embodiment, the SPU 500 non-volatile random access memory (NVRAM) 534b may be used for securely storing such highly sensitive information. NVRAM 534b is also used by SPU 500 to store data that may change frequently but which preferably should not be lost in a power down or power faU mode.

0616NVRAM 534b is preferably a flash memory array, but may in addition or alternatively be electricaUy erasable programmable read only memory (EEPROM), static RAM (SRAM), bubble memory, three dimensional holographic or other electro-optical memory, or the like, or any other writable (e.g., randomly accessible) non-volatile memory of sufficient speed and cost-effectiveness.

0617SPU External Memory The SPU 500 can store certain information on memory devices external to the SPU. If avaUable, electronic apphance 600 memory can also be used to support any device external portions of SPU 500 software. Certain advantages may be gained by aUowing the SPU 500 to use external memory. As one example, memory internal to SPU 500 may be reduced in size by using non-volatile read/write memory in the host electronic apphance 600 such as a non-volatile portion of RAM 656 and/or ROM 658.

0618Such external memory may be used to store SPU programs, data and or other information. For example, a VDE control program may be, at least in part, loaded into the memory and communicated to and decrypted within SPU 500 prior to execution. Such control programs may be re-encrypted and communicated back to external memory where they may be stored for later execution by SPU 500. "Kernel" programs and/or some or aU of the non-kernel "load modules" may be stored by SPU 500 in memory external to it. Since a secure database 610 may be relatively large, SPU 500 can store some or all of secure database 610 in external memory and caU portions into the SPU

0619500 as needed. As mentioned above, memory external to SPU 500 may not be secure. Therefore, when security is required, SPU 500 must encrypt secure information before writing it to external memory, and decrypt secure information read from external memory before using it. Inasmuch as the encryption layer rehes on secure processes and information (e.g., encryption algorithms and keys) present within SPU 500, the encryption layer effectively "extends" the SPU security barrier 502 to protect information the SPU 500 stores in memory external to it.

0620SPU 500 can use a wide variety of different types of external memory. For example, external memory may comprise electronic apphance secondary storage 652 such as a disk; external EEPROM or flash memory 658; and/or external RAM 656. External RAM 656 may comprise an external nonvolatile

0621(e.g. constantly powered) RAM and/or cache RAM.

0622Using external RAM local to SPU 500 can significantly improve access times to infoπnation stored externaUy to an SPU. For example, external RAM may be used:

0623C to buffer memory image pages and data structures prior to their storage in flash memory or on an external hard disk (assuming transfer to flash or hard disk can occur in significant power or system failure cases); C provide encryption and decryption buffers for data being released from VDE objects 300. C to cache "swap blocks" and VDE data structures currently in use as an aspect of providing a secure virtual memory environment for SPU 500. C to cache other information in order to, for example, reduce frequency of access by an SPU to secondary storage 652 and/or for other reasons.

0624Dual ported external RAM can be particularly effective in improving SPU 500 performance, since it can decrease the data movement overhead of the SPU bus interface unit 530 and SPU microprocessor 520.

0625Using external flash memory local to SPU 500 can be used to significantly improve access times to virtuaUy aU data structures. Since most avaUable flash storage devices have limited write lifetimes, flash storage needs to take into account the number of writes that will occur during the lifetime of the flash memory. Hence, flash storage of frequently written temporary items is not recommended. If external RAM is non- volatile, then transfer to flash (or hard disk) may not be necessary.

0626External memory used by SPU 500 may include two categories:

0627C external memory dedicated to SPU 500, and C memory shared with electronic apphance 600.

0628For some VDE implementations, sharing memory (e.g., electronic apphance RAM 656, ROM 658 and/or secondary storage 652) with CPU 654 or other elements of an electronic apphance 600 may be the most cost effective way to store VDE secure database management files 610 and information that needs to be stored external to SPU 500. A host system hard disk secondary memory 652 used for general purpose file storage can, for example, also be used to store VDE management files 610. SPU 500 may be given exclusive access to the external memory (e.g., over a local bus high speed connection provided by BIU 530). Both dedicated and shared external memory may be provided. The hardware configuration of an example of electronic apphance 600 has been described above. The foUowing section describes an example of the software architecture of electronic apphance 600 provided by the preferred embodiment, including the structure and operation of preferred embodiment "Rights

0629Operating System" ("ROS") 602.

0630Rights Operating System 602

0631Rights Operating System ("ROS") 602 in the preferred embodiment is a compact, secure, event-driven, services-based,

0632"component" oriented, distributed multiprocessing operating system environment that integrates VDE information security control information, components and protocols with traditional operating system concepts. Like traditional operating systems, ROS 602 provided by the preferred embodiment is a piece of software that manages hardware resources of a computer system and extends management functions to input and/or output devices, including communications devices. Also like traditional operating systems, preferred embodiment ROS 602 provides a coherent set of basic functions and abstraction layers for hiding the differences between, and many of the detaUed complexities of, particular hardware implementations. In addition to these characteristics found in many or most operating systems, ROS 602 provides secure VDE transaction management and other advantageous features not found in other operating systems. The foUowing is a non-exhaustive list of some of the advantageous features provided by ROS 602 in the preferred embodiment:

0633Standardized interface provides coherent set of basic functions

0634C simplifies programming

0635C the same apphcation can run on many different platforms Event driven

0636C eases functional decomposition

0637C extendible

0638C accommodates state transition and/or process oriented events C simplifies task management

0639C simplifies inter-process communications

0640Services based

0641C allows simplified and transparent scalability

0642C simplifies multiprocessor support C hides machine dependencies

0643C eases network management and support

0644Component Based Architecture C processing based on independently dehverable secure components C component model of processing control aUows different sequential steps that are reconfigurable based on requirements

0645C components can be added, deleted or modified (subject to permissioning) C full control information over pre-defined and user-defined apphcation events C events can be individuaUy controUed with independent executables

0646Secure

0647C secure communications

0648C secure control functions C secure virtual memory management

0649C information control structures protected from exposure

0650C data elements are validated, correlated and access controUed

0651C components are encrypted and validated independently C components are tightly correlated to prevent unauthorized use of elements C control structures and secured executables are validated prior to use to protect against tampering

0652C integrates security considerations at the I/O level

0653C provides on-the-fly decryption of information at release time

0654C enables a secure commercial transaction network

0655C flexible key management features

0656Scalaeble

0657C highly scalaeble across many different platforms C supports concurrent processing in a multiprocessor environment C supports multiple cooperating processors C any number of host or security processors can be supported C control structures and kernel are easUy portable to various host platforms and to different processors within a target platform without recompUation C supports remote processing C Remote Procedure Calls may be used for internal OS communications Highly Tntegratable

0658C can be highly integrated with host platforms as an additional operating system layer C permits non-secure storage of secured components and information using an OS layer "on top of traditional OS platforms C can be seamlessly integrated with a host operating system to provide a common usage paradigm for transaction management and content access C integration may take many forms: operating system layers for desktops (e.g., DOS, Windows, Macintosh); device drivers and operating system interfaces for network services (e.g, Unix and Netware); and dedicated component drivers for "low end" set tops are a few of many examples C can be integrated in traditional and real time operating systems Distributed, C provides distribution of control information and reciprocal control information and mechanisms C supports conditional execution of controUed processes within any VDE node in a distributed, asynchronous arrangement C controUed delegation of rights in a distributed environment

0659C supports chains of handhng and control C management environment for distributed, occasionally connected but otherwise asynchronous networked database C real time and time independent data management C supports "agent" processes

0660Trfln^gpqπT*

0661C can be seamlessly integrated into existing operating systems C can support apphcations not specificaUy written to use it Network friendly C internal OS structures may use RPCs to distribute processing C subnets may seamlessly operate as a single node or independently

0662General Background Regarding Operating Systems

0663An "operating system" provides a control mechanism for organizing computer system resources that aUows programmers to create apphcations for computer systems more easUy. An operating system does this by providing commonly used functions, and by helping to ensure compatibility between different computer hardware and architectures (which may, for example, be manufactured by different vendors). Operating systems also enable computer "peripheral device" manufacturers to far more easUy supply compatible equipment to computer manufacturers and users.

0664Computer systems are usuaUy made up of several different hardware components. These hardware components include, for example: a central processing unit (CPU) for executing instructions;

0665an array of main memory cells (e.g., "RAM" or "ROM") for storing instructions for execution and data acted upon or parameterizing those instructions; and

0666one or more secondary storage devices (e.g., hard disk drive, floppy disk drive, CD-ROM drive, tape reader, card reader, or "flash" memory) organized to reflect named elements (a "file system") for storing images of main memory cells. Most computer systems also include input/output devices such as keyboards, mice, video systems, printers, scanners and communications devices. To organize the CPU's execution capabihties with available RAM, ROM and secondary storage devices, and to provide commonly used functions for use by programmers, a piece of software called an "operating system" is usually included with the other components. TypicaUy, this piece of software is designed to begin executing after power is apphed to the computer system and hardware diagnostics are completed. Thereafter, aU use of the CPU, main memory and secondary memory devices is normaUy managed by this "operating system" software. Most computer operating systems also typicaUy include a mechanism for extending their management functions to I/O and other peripheral devices, including commonly used functions associated with these devices.

0667By managing the CPU, memory and peripheral devices through the operating system, a coherent set of basic functions and abstraction layers for hiding hardware details aUows programmers to more easUy create sophisticated apphcations. In addition, managing the computer's hardware resources with an operating system allows many differences in design and equipment requirements between different manufacturers to be hidden. Furthermore, apphcations can be more easUy shared with other computer users who have the same operating system, with significantly less work to support different manufacturers' base hardware and peripheral devices.

0668ROS 602 is an Operating System Providing Significant

0669Advantages

0670ROS 602 is an "operating system." It manages the resources of electronic apphance 600, and provides a commonly used set of functions for programmers writing apphcations 608 for the electronic apphance. ROS 602 in the preferred embodiment manages the hardware (e.g., CPU(s), memory(ies), secure RTC(s), and encrypt decrypt engines) within SPU 500. ROS may also manage the hardware (e.g., CPU(s) and memory(ies)) within one or more general purpose processors within electronic apphance 600. ROS 602 also manages other electronic apphance hardware resources, such as peripheral devices attached to an electronic apphance. For example, referring to Figure 7, ROS 602 may manage keyboard 612, display 614, modem 618, disk drive 620, printer 622, scanner 624. ROS 602 may also manage secure database 610 and a storage device (e.g., "secondary storage" 652) used to store secure database 610. ROS 602 supports multiple processors. ROS 602 in the preferred embodiment supports any number of local and/or remote processors. Supported processors may include at least two types: one or more electronic apphance processors 654, and/or one or more SPUs 500. A host processor CPU 654 may provide storage, database, and communications services. SPU 500 may provide cryptographic and secured process execution services. Diverse control and execution structures supported by ROS 602 may require that processing of control information occur within a controUable execution space - this controUable execution space may be provided by SPU 500. Additional host and/or SPU processors may increase efficiencies and/or capabihties. ROS 602 may access, coordinate and/or manage further processors remote to an electronic apphance 600 (e.g., via network or other communications link) to provide additional processor resources and or capabilities.

0671ROS 602 is services based. The ROS services provided using a host processor 654 and/or a secure processor (SPU 500) are linked in the prefeπed embodiment using a "Remote

0672Procedure CaU" ("RPC") internal processing request structure. Cooperating processors may request interprocess services using a RPC mechanism, which is minimally time dependent and can be distributed over cooperating processors on a network of hosts. The multi-processor architecture provided by ROS 602 is easUy extensible to support any number of host or security processors. This extensibility supports high levels of scalability. Services also aUow functions to be implemented differently on different equipment. For example, a small apphance that typicaUy has low levels of usage by one user may implement a database service using very different techniques than a very large apphance with high levels of usage by many users. This is another aspect of scalability.

0673ROS 602 provides a distributed processing environment For example, it permits information and control structures to automaticaUy, securely pass between sites as required to fulfiU a user's requests. Communications between VDE nodes under the distributed processing features of ROS 602 may include interprocess service requests as discussed above. ROS 602 supports conditional and/or state dependent execution of controUed processors within any VDE node. The location that the process executes and the control structures used may be locaUy resident, remotely accessible, or carried along by the process to support execution on a remote system.

0674ROS 602 provides distribution of control information, including for example the distribution of control structures required to permit "agents" to operate in remote environments. Thus, ROS 602 provides facilities for passing execution and or information control as part of emerging requirements for "agent" processes.

0675If desired, ROS 602 may independently distribute control information over very low bandwidth connections that may or may not be "real time" connections. ROS 602 provided by the preferred embodiment is "network friendly," and can be implemented with any level of networking protocol. Some examples include e-mail and direct connection at approximately "Layer 5" of the ISO model.

0676The ROS 602 distribution process (and the associated auditing of distributed information) is a controUed event that itself uses such control structures. This "reflective" distributed processing mechanism permits ROS 602 to securely distribute rights and permissions in a controUed manner, and effectively restrict the characteristics of use of information content. The controUed delegation of rights in a distributed environment and the secure processing techniques used by ROS 602 to support this approach provide significant advantages.

0677Certain control mechanisms within ROS 602 are "reciprocal." Reciprocal control mechanisms place one or more control components at one or more locations that interact with one or more components at the same or other locations in a controUed way. For example, a usage control associated with object content at a user's location may have a reciprocal control at a distributor's location that governs distribution of the usage control, auditing of the usage control, and logic to process user requests associated with the usage control. A usage control at a user's location (in addition to controlling one or more aspects of usage) may prepare audits for a distributor and format requests associated with the usage control for processing by a distributor. Processes at either end of a reciprocal control may be further controUed by other processes (e.g., a distributor may be limited by a budget for the number of usage control mechanisms they may produce). Reciprocal control mechanisms may extend over many sites and many levels (e.g., a creator to a distributor to a user) and may take any relationship into account (e.g., creator/distributor, distributor user, user/user, user/creator, user/creator/distributor, etc.) Reciprocal control mechanisms have many uses in VDE 100 in representing relationships and agreements in a distributed environment.

0678ROS 602 is scalable. Many portions of ROS 602 control structures and kernel(s) are easUy portable to various host platforms without recompUation. Any control structure may be distributed (or redistributed) if a granting authority permits this type of activity. The executable references within ROS 602 are portable within a target platform. Different instances of ROS 602 may execute the references using different resources. For example, one instance of ROS 602 may perform a task using an

0679SPU 500, while another instance of ROS 602 might perform the same task using a host processing environment running in protected memory that is emulating an SPU in software. ROS 602 control informationis similarly portable; in many cases the event processing structures may be passed between machines and host platforms as easUy as between cooperative processors in a single computer. Apphances with different levels of usage and/or resources avaUable for ROS 602 functions may implement those functions in very different ways. Some services may be omitted entirely if insufficient resources exist. As described elsewhere, ROS 602 "knows" what services are avaUable, and how to proceed based on any given event. Not aU events may be processable if resources are missing or inadequate.

0680ROS 602 is component based. Much of the functionahty provided by ROS 602 in the preferred embodiment may be based on "components" that can be securely, independently dehverable, replaceable and capable of being modified (e.g., under appropriately secure conditions and authorizations). Moreover, the "components" may themselves be made of independently dehverable elements. ROS 602 may assemble these elements together (using a construct provided by the preferred embodiment caUed a "channel") at execution time. For example, a "load module" for execution by SPU 500 may reference one or more "method cores," method parameters and other associated data structures that ROS 602 may coUect and assemble together to perform a task such as billing or metering. Different users may have different combinations of elements, and some of the elements may be customizable by users with appropriate authorization. This increases flexibility, aUows elements to be reused, and has other advantages.

0681ROS 602 is highly secure. ROS 602 provides mechanisms to protect information control structures from exposure by end users and conduit hosts. ROS 602 can protect information, VDE control structures and control executables using strong encryption and validation mechanisms. These encryption and validation mechanisms are designed to make them highly resistant to undetected tampering. ROS 602 encrypts information stored on secondary storage device(s) 652 to inhibit tampering. ROS 602 also separately encrypts and validates its various components. ROS 602 correlates control and data structure components to prevent unauthorized use of elements. These features permit ROS 602 to independently distribute elements, and also allows integration of VDE functions 604 with non-secure "other" OS functions 606.

0682ROS 602 provided by the preferred embodiment extends conventional capabilities such as, for example, Access Control

0683List (ACL) structures, to user and process defined events, including state transitions. ROS 602 may provide fuU control information over pre-defined and user-defined apphcation events. These control mechanisms include "go/no-go" permissions, and also include optional event-specific executables that permit complete flexibility in the processing and/or controlling of events. This structure permits events to be individuaUy controUed so that, for example, metering and budgeting may be provided using independent executables. For example, ROS 602 extends ACL structures to control arbitrary granularity of information. Traditional operating systems provide static "go-no go" control mechanisms at a file or resource level; ROS 602 extends the control concept in a general way from the largest to the smallest sub-element using a flexible control structure. ROS 602 can, for example, control the printing of a single paragraph out of a document file.

0684ROS 602 provided by the preferred embodiment permits secure modification and update of control information governing each component. The control information may be provided in a template format such as method options to an end-user. An end-user may then customize the actual control information used within guidelines provided by a distributor or content creator. Modification and update of existing control structures is preferably also a controUable event subject to auditing and control information.

0685ROS 602 provided by the preferred embodiment validates control structures and secured executables prior to use. This validation provides assurance that control structures and executables have not been tampered with by end-users. The validation also permits ROS 602 to securely implement components that include fragments of files and other operating system structures. ROS 602 provided by the prefeπed embodiment integrates security considerations at the operating system I/O level (which is below the access level), and provides "on-the-fly" decryption of information at release time. These features permit non-secure storage of ROS 602 secured components and information using an OS layer "on top of traditional operating system platforms.

0686ROS 602 is highly integratable with host platforms as an additional operating system layer. Thus, ROS 602 may be created by "adding on" to existing operating systems. This involves hooking VDE "add ons" to the host operating system at the device driver and network interface levels. Alternatively, ROS 602 may comprise a whoUy new operating system that integrates both VDE functions and other operating system functions.

0687Indeed, there are at least three general approaches to integrating VDE functions into a new operating system, potentiaUy based on an existing operating system, to create a Rights Operating System 602 including:

0688(1) Redesign the operating system based on VDE transaction management requirements;

0689(2) CompUe VDE API functions into an existing operating systems; and

0690(3) Integrate a VDE Interpreter into an existing operating system.

0691The first approach could be most effectively apphed when a new operating system is being designed, or if a significant upgrade to an existing operating system is planned. The transaction management and security requirements provided by the VDE functions could be added to the design requirements list for the design of a new operating system that provides, in an optimaUy efficient manner, an integration of "traditional" operating system capabihties and VDE capabihties. For example, the engineers responsible for the design of the new version or instance of an operating system would include the requirements of VDE metering/transaction management in addition to other requirements (if any) that they use to form their design approach, specifications, and actual implementations. This approach could lead to a "seamless" integration of VDE functions and capabihties by threading metering/transaction management functionahty throughout the system design and implementation.

0692The second approach would involve taking an existing set of API (Apphcation Programmer Interface) functions, and incorporating references in the operating system code to VDE function calls. This is similar to the way that the current Windows operating system is integrated with DOS, wherein DOS serves as both the launch point and as a significant portion of the kernel underpinning of the Windows operating system. This approach would be also provide a high degree of "seamless" integration (although not quite as "seamless" as the first approach). The benefits of this approach include the possibility that the incorporation of metering/transaction management functionahty into the new version or instance of an operating system may be accomplished with lower cost (by making use of the existing code embodied in an API, and also using the design implications of the API functional approach to influence the design of the elements into which the metering/transaction management functionahty is incorporated).

0693The third approach is distinct from the first two in that it does not incorporate VDE functionahty associated with metering/transaction management and data security directly into the operating system code, but instead adds a new generalized capability to the operating system for executing metering/transaction management functionahty. In this case, an interpreter including metering transaction management functions would be integrated with other operating system code in a "stand alone" mode. This interpreter might take scripts or other inputs to determine what metering/transaction management functions should be performed, and in what order and under which circumstances or conditions they should be performed.

0694Instead of (or in addition to) integrating VDE functions into/with an electronic apphance operating system, it would be possible to provide certain VDE functionahty avaUable as an apphcation running on a conventional operating system.

0695ROS Software Architecture Figure 10 is a block diagram of one example of a software structure/architecture for Rights Operating System ("ROS") 602 provided by the preferred embodiment. In this example, ROS 602 includes an operating system ("OS") "core" 679, a user Apphcation Program Interface ("API") 682, a "redirector" 684, an "intercept" 692, a User Notification/Exception Interface 686, and a file system 687. ROS 602 in this example also includes one or more Host Event Processing Environments ("HPEs") 655 and/or one or more Secure Event Processing Environments ("SPEs") 503 (these environments may be genericaUy referred to as "Protected Processing Environments" 650).

0696HPE(s) 655 and SPE(s) 503 are self-contained computing and processing environments that may include their own operating system kernel 688 including code and data processing resources. A given electronic apphance 600 may include any number of SPE(s) 503 and/or any number of HPE(s) 655. HPE(s) 655 and SPE(s) 503 may process information in a secure way, and provide secure processing support for ROS 602. For example, they may each perform secure processing based on one or more VDE component assembhes 690, and they may each offer secure processing services to OS kernel 680.

0697In the preferred embodiment, SPE 503 is a secure processing environment provided at least in part by an SPU 500. Thus, SPU 500 provides the hardware tamper-resistant barrier 503 surrounding SPE 503. SPE 503 provided by the preferred embodiment is preferably:

0698C smaU and compact

0699C loadable into resource constrained environments such as for example minimally configured SPUs 500 C dynamicaUy updatable

0700C extensible by authorized users C integratable into object or procedural environments secure.

0701In the preferred embodiment, HPE 655 is a secure processing environment supported by a processor other than an SPU, such as for example an electronic apphance CPU 654 general-purpose microprocessor or other processing system or device. In the preferred embodiment, HPE 655 may be considered to "emulate" an SPU 500 in the sense that it may use software to provide some or all of the processing resources provided in hardware and/or firmware by an SPU. HPE 655 in one preferred embodiment of the present invention is fuU- featured and fuUy compatible with SPE 503— that is, HPE 655 can handle each and every service call SPE 503 can handle such that the SPE and the HPE are "plug compatible" from an outside interface standpoint (with the exception that the HPE may not provide as much security as the SPE).

0702HPEs 655 may be provided in two types: secure and not secure. For example, it may be desirable to provide non-secure versions of HPE 655 to aUow electronic apphance 600 to efficiently run non-sensitive VDE tasks using the fuU resources of a fast general purpose processor or computer. Such non-secure versions of HPE 655 may run under supervision of an instance of ROS 602 that also includes an SPE 503. In this way, ROS 602 may run aU secure processes within SPE 503, and only use HPE 655 for processes that do not require security but that may require (or run more efficiently) under potentiaUy greater resources provided by a general purpose computer or processor supporting HPE 655. Non-secure and secure HPE 655 may operate together with a secure SPE 503.

0703HPEs 655 may (as shown in Figure 10) be provided with a software-based tamper resistant barrier 674 that makes them more secure. Such a software-based tamper resistant barrier 674 may be created by software executing on general-purpose CPU 654. Such a "secure" HPE 655 can be used by ROS 602 to execute processes that, whUe stiU needing security, may not require the degree of security provided by SPU 500. This can be especially beneficial in architectures providing both an SPE 503 and an HPE 655. The SPU 502 may be used to perform aU truly secure processing, whereas one or more HPEs 655 may be used to provide additional secure (albeit possibly less secure than the SPE) processing using host processor or other general purpose resources that may be avaUable within an electronic apphance 600. Any service may be provided by such a secure HPE 655. In the preferred embodiment, certain aspects of "channel processing" appears to be a candidate that could be readUy exported from SPE 503 to HPE 655. The software-based tamper resistant barrier 674 provided by HPE 655 may be provided, for example, by: introducing time checks and/or code modifications to comphcate the process of stepping through code comprising a portion of kernel 688a and/or a portion of component assembhes 690 using a debugger; using a map of defects on a storage device (e.g., a hard disk, memory card, etc.) to form internal test values to impede moving and or copying HPE 655 to other electronic apphances 600; using kernel code that contains false branches and other complications in flow of control to disguise internal processes to some degree from disassembly or other efforts to discover details of processes; using "self-generating" code (based on the output of a co-sine transform, for example) such that detaUed and/or complete instruction sequences are not stored exphcitly on storage devices and/or in active memory but rather are generated as needed; using code that "shuffles" memory locations used for data values based on operational parameters to comphcate efforts to manipulate such values; using any software and/or hardware memory management resources of electronic apphance 600 to "protect" the operation of HPE 655 from other processes, functions, etc.

0704Although such a software-based tamper resistant barrier 674 may provide a fair degree of security, it typicaUy will not be as secure as the hardware-based tamper resistant barrier 502 provided (at least in part) by SPU 500. Because security may be better/more effectively enforced with the assistance of hardware security features such as those provided by SPU 500 (and because of other factors such as increased performance provided by special purpose circuitry within SPU 500), at least one SPE 503 is prefeπed for many or most higher security apphcations. However, in apphcations where lesser security can be tolerated and or the cost of an SPU 500 cannot be tolerated, the SPE 503 may be omitted and aU secure processing may instead be performed by one or more secure HPEs 655 executing on general-purpose CPUs 654. Some VDE processes may not be aUowed to proceed on reduced-security electronic apphances of this type if insufficient security is provided for the particular process involved.

0705Only those processes that execute completely within SPEs 503 (and in some cases, HPEs 655) may be considered to be truly secure. Memory and other resources external to SPE 503 and HPEs 655 used to store and/or process code and/or data to be used in secure processes should only receive and handle that information in encrypted form unless SPE 503/HPE 655 can protect secure process code and/or data from non-secure processes.

0706OS "core" 679 in the preferred embodiment includes a kernel 680, an RPC manager 732, and an "object switch" 734. API 682, HPE 655 and SPE 503 may communicate "event" messages with one another via OS "core" 679. They may also communicate messages directly with one another without messages going through OS "core" 679.

0707Kernel 680 may manage the hardware of an electronic apphance 600. For example, it may provide appropriate drivers and hardware managers for interacting with input/output and/or peripheral devices such as keyboard 612, display 614, other devices such as a "mouse" pointing device and speech recognizer

0708613, modem 618, printer 622, and an adapter for network 672. Kernel 680 may also be responsible for initiaUy loading the remainder of ROS 602, and may manage the various ROS tasks (and associated underlying hardware resources) during execution. OS kernel 680 may also manage and access secure database 610 and file system 687. OS kernel 680 also provides execution services for apphcations 608a(l), 608a(2), etc. and other apphcations.

0709RPC manager 732 performs messaging routing and resource management/integration for ROS 680. It receives and routes "calls" from to API 682, HPE 655 and SPE 503, for example.

0710Object switch 734 may manage construction, deconstruction and other manipulation of VDE objects 300.

0711User Notification/Exception Interface 686 in the preferred embodiment (which may be considered part of API 682 or another apphcation coupled to the API) provides "pop up" windows/displays on display 614. This aUows ROS 602 to communicate directly with a user without having to pass information to be communicated through apphcations 608. For apphcations that are not "VDE aware," user notification/exception interface 686 may provide communications between ROS 602 and the user. API 682 in the preferred embodiment provides a standardized, documented software interface to apphcations 608. In part, API 682 may translate operating system "calls" generated by apphcations 608 into Remote Procedure Calls ("RPCs") specifying "events." RPC manager 732 may route these

0712RPCs to kernel 680 or elsewhere (e.g., to HPE(s) 655 and/or SPE(s) 503, or to remote electronic apphances 600, processors, or VDE participants) for processing. The API 682 may also service RPC requests by passing them to apphcations 608 that register to receive and process specific requests.

0713API 682 provides an "Apphcations Programming Interface" that is preferably standardized and documented. It provides a concise set of function calls an apphcation program can use to access services provided by ROS 602. In at least one preferred example, API 682 will include two parts: an apphcation program interface to VDE functions 604; and an apphcation program interface to other OS functions 606. These parts may be interwoven into the same software, or they may be provided as two or more discrete pieces of software (for example). Some apphcations, such as apphcation 608a(l) shown in Figure 11, may be "VDE aware" and may therefore directly access both of these parts of API 682. Figure 11A shows an example of this. A "VDE aware" apphcation may, for example, include exphcit calls to ROS 602 requesting the creation of new

0714VDE objects 300, metering usage of VDE objects, storing information in VDE-protected form, etc. Thus, a "VDE aware" apphcation can initiate (and, in some examples, enhance and/or extend) VDE functionahty provided by ROS 602. In addition, "VDE aware" apphcations may provide a more direct interface between a user and ROS 602 (e.g., by suppressing or otherwise dispensing with "pop up" displays otherwise provided by user notification/exception interface 686 and instead providing a more "seamless" interface that integrates apphcation and ROS messages).

0715Other apphcations, such as apphcation 608b shown in Figure 11B, may not be "VDE Aware" and therefore may not "know" how to directly access an interface to VDE functions 604 provided by API 682. To provide for this, ROS 602 may include a

0716"redirector" 684 that aUows such "non-VDE aware" apphcations 608(b) to access VDE objects 300 and functions 604. Redirector 684, in the preferred embodiment, translates OS calls directed to the "other OS functions" 606 into calls to the "VDE functions" 604. As one simple example, redirector 684 may intercept a "file open" caU from apphcation 608(b), determine whether the file to be opened is contained within a VDE container 300, and if it is, generate appropriate VDE function caU(s) to file system 687 to open the VDE container (and potentiaUy generate events to HPE 655 and/or SPE 503 to determine the name(s) of file(s) that may be stored in a VDE object 300, establish a control structure associated with a VDE object 300, perform a registration for a

0717VDE object 300, etc.). Without redirector 684 in this example, a non-VDE aware apphcation such as 608b could access only the part of API 682 that provides an interface to other OS functions 606, and therefore could not access any VDE functions.

0718This "translation" feature of redirector 684 provides "transparency." It aUows VDE functions to be provided to the apphcation 608(b) in a "transparent" way without requiring the apphcation to become involved in the complexity and details associated with generating the one or more calls to VDE functions 604. This aspect of the "transparency" features of ROS 602 has at least two important advantages: (a) it allows apphcations not written specificaUy for VDE functions 604 ("non-VDE aware apphcations") to nevertheless access critical VDE functions; and

0719(b) it reduces the complexity of the interface between an apphcation and ROS 602.

0720Since the second advantage (reducing complexity) makes it easier for an apphcation creator to produce apphcations, even "VDE aware" apphcations 608a(2) may be designed so that some calls invoking VDE functions 604 are requested at the level of an "other OS functions" call and then "translated" by redirector 684 into a VDE function caU (in this sense, redirector 684 may be considered a part of API 682). Figure 11C shows an example of this. Other calls invoking VDE functions 604 may be passed directly without translation by redirector 684.

0721Referring again to Figure 10, ROS 620 may also include an "interceptor" 692 that transmits and/or receives one or more real time data feeds 694 (this may be provided over cable(s) 628 for example), and routes one or more such data feeds appropriately whUe providing "translation" functions for real time data sent and/or received by electronic apphance 600 to aUow "transparency" for this type of information analogous to the transparency provided by redirector 684 (and/or it may generate one or more real time data feeds).

0722Secure ROS Components and Component Assemblies As discussed above, ROS 602 in the preferred embodiment is a component-based architecture. ROS VDE functions 604 may be based on segmented, independently loadable executable "component assembhes" 690. These component assembhes 690 are independently securely dehverable. The component assembhes 690 provided by the preferred embodiment comprise code and data elements that are themselves independently dehverable. Thus, each component assembly 690 provided by the preferred embodiment is comprised of independently securely dehverable elements which may be communicated using VDE secure communication techniques, between VDE secure subsystems.

0723These component assembhes 690 are the basic functional unit provided by ROS 602. The component assembhes 690 are executed to perform operating system or apphcation tasks. Thus, some component assembhes 690 may be considered to be part of the ROS operating system 602, whUe other component assembhes may be considered to be "apphcations" that run under the support of the operating system. As with any system incorporating "apphcations" and "operating systems," the boundary between these aspects of an overaU system can be ambiguous. For example, commonly used "apphcation" functions

0724(such as determining the structure and/or other attributes of a content container) may be incorporated into an operating system. Furthermore, "operating system" functions (such as task management, or memory aUocation) may be modified and/or replaced by an apphcation. A common thread in the preferred embodiment's ROS 602 is that component assembhes 690 provide functions needed for a user to fulfiU her intended activities, some of which may be "application-like" and some of which may be "operating system-like."

0725Components 690 are preferably designed to be easUy separable and individuaUy loadable. ROS 602 assembles these elements together into an executable component assembly 690 prior to loading and executing the component assembly (e.g., in a secure operating environment such as SPE 503 and/or HPE 655).

0726ROS 602 provides an element identification and referencing mechanism that includes information necessary to automaticaUy assemble elements into a component assembly 690 in a secure manner prior to, and/or during, execution.

0727ROS 602 apphcation structures and control parameters used to form component assembhes 690 can be provided by different parties. Because the components forming component assembhes 690 are independently securely dehverable, they may be dehvered at different times and/or by different parties ("dehvery" may take place within a local VDE secure subsystem, that is submission through the use of such a secure subsystem of control information by a chain of content control information handling participant for the preparation of a modified control information set constitutes independent, secure dehvery). For example, a content creator can produce a ROS 602 apphcation that defines the circumstances required for licensing content contained within a VDE object 300. This apphcation may reference structures provided by other parties. Such references might, for example, take the form of a control path that uses content creator structures to meter user activities; and structures created/owned by a financial provider to handle financial parts of a content distribution transaction (e.g., defining a credit budget that must be present in a control structure to establish creditworthiness, audit processes which must be performed by the licensee, etc.). As another example, a distributor may give one user more favorable pricing than another user by dehvering different data elements defining pricing to different users. This attribute of supporting multiple party securely, independently dehverable control infoπnation is fundamental to enabling electronic commerce, that is, defining of a content and/or apphance control information set that represents the requirements of a coUection of independent parties such as content creators, other content providers, financial service providers, and/or users.

0728In the preferred embodiment, ROS 602 assembles securely independently dehverable elements into a component assembly 690 based in part on context parameters (e.g., object, user).

0729Thus, for example, ROS 602 may securely assemble different elements together to form different component assembhes 690 for different users performing the same task on the same VDE object 300. Similarly, ROS 602 may assemble differing element sets which may include, that is reuse, one or more of the same components to form different component assembhes 690 for the same user performing the same task on different VDE objects

0730300.

0731The component assembly organization provided by ROS 602 is "recursive" in that a component assembly 690 may comprise one or more component "subassembhes" that are themselves independently loadable and executable component assembhes 690. These component "subassembhes" may, in turn, be made of one or more component "sub-sub-assemblies." In the general case, a component assembly 690 may include N levels of component subassembhes.

0732Thus, for example, a component assembly 690(k) that may includes a component subassembly 690(k + 1). Component subassembly 690(k + 1), in turn, may include a component sub- sub-assembly 690(3), ... and so on to N-level subassembly 690(k + N). The abihty of ROS 602 to buUd component assembhes 690 out of other component assembhes provides great advantages in terms of, for example, code/data reusability, and the ability to aUow different parties to manage different parts of an overaU component. Each component assembly 690 in the preferred embodiment is made of distinct components. Figures 11D-11H are abstract depictions of various distinct components that may be assembled to form a component assembly 690(k) showing Figure 111. These same components can be combined in different ways (e.g., with more or less components) to form different component assembhes 690 providing completely different functional behavior. Figure 11J is an abstract depiction of the same components being put together in a different way (e.g., with additional components) to form a different component assembly

0733690(j). The component assembhes 690(k) and 690(j) each include a common feature 691 that interlocks with a "channel" 594 defined by ROS 602. This "channel" 594 assembles component assembhes 690 and interfaces them with the (rest of) ROS 602.

0734ROS 602 generates component assembhes 690 in a secure manner. As shown graphicaUy in Figures 111 and IU, the different elements comprising a component assembly 690 may be "interlocking" in the sense that they can only go together in ways that are intended by the VDE participants who created the elements and/or specified the component assembhes. ROS 602 includes security protections that can prevent an unauthorized person from modifying elements, and also prevent an unauthorized person from substituting elements. One can picture an unauthorized person making a new element having the same "shape" as the one of the elements shown in Figures 11D-11H, and then attempting to substitute the new element in place of the original element. Suppose one of the elements shown in Figure 11H establishes the price for using content within a VDE object 300. If an unauthorized person could substitute her own "price" element for the price element intended by the VDE content distributor, then the person could establish a price of zero instead of the price the content distributor intended to charge. Similarly, if the element establishes an electronic credit card, then an ability to substitute a different element could have disastrous consequences in terms of aUowing a person to charge her usage to someone else's (or a non-existent) credit card. These are merely a few simple examples demonstrating the importance of ROS 602 ensuring that certain component assembhes 690 are formed in a secure manner. ROS 602 provides a wide range of protections against a wide range of "threats" to the secure handling and execution of component assembhes 690. In the preferred embodiment, ROS 602 assembles component assembhes 690 based on the foUowing types of elements:

0735Permissions Records ("PERC"s) 808;

0736Method "Cores" 1000;

0737Load Modules 1100;

0738Data Elements (e.g., User Data Elements ("UDEs") 1200 and Method Data Elements ("MDEs") 1202); and

0739Other component assembhes 690.

0740Briefly, a PERC 808 provided by the preferred embodiment is a record corresponding to a VDE object 300 that identifies to ROS 602, among other things, the elements ROS is to assemble together to form a component assembly 690. Thus PERC 808 in effect contains a "list of assembly instructions" or a "plan" specifying what elements ROS 602 is to assemble together into a component assembly and how the elements are to be connected together. PERC 808 may itself contain data or other elements that are to become part of the component assembly 690. The PERC 808 may reference one or more method "cores" 1000N. A method core 1000N may define a basic "method" 1000 (e.g., "control," "billing," "metering," etc.)

0741In the preferred embodiment, a "method" 1000 is a coUection of basic instructions, and information related to basic instructions, that provides context, data, requirements, and/or relationships for use in performing, and/or preparing to perform, basic instructions in relation to the operation of one or more electronic apphances 600. Basic instructions may be comprised of, for example:

0742C machine code of the type commonly used in the programming of computers; pseudo-code for use by an interpreter or other instruction processing program operating on a computer; C a sequence of electronicaUy represented logical operations for use with an electronic apphance 600; C or other electronic representations of instructions, source code, object code, and/or pseudo code as those terms are commonly understood in the arts. Information relating to said basic instructions may comprise, for example, data associated intrinsicaUy with basic instructions such as for example, an identifier for the combined basic instructions and intrinsic data, addresses, constants, and/or the like. The information may also, for example, include one or more of the foUowing:

0743C information that identifies associated basic instructions and said intrinsic data for access, correlation and/or validation purposes;

0744C required and/or optional parameters for use with basic instructions and said intrinsic data; C information defining relationships to other methods; C data elements that may comprise data values, fields of information, and/or the like;

0745C information specifying and/or defining relationships among data elements, basic instructions and/or intrinsic data; C information specifying relationships to external data elements; information specifying relationships between and among internal and external data elements, methods, and/or the hke, if any exist; and

0746additional information required in the operation of basic instructions and intrinsic data to complete, or attempt to complete, a purpose intended by a user of a method, where required, including additional instructions and/or intrinsic data.

0747Such information associated with a method may be stored, in part or whole, separately from basic instructions and intrinsic data. When these components are stored separately, a method may nevertheless include and encompass the other information and one or more sets of basic instructions and intrinsic data (the latter being included because of said other information's reference to one or more sets of basic instructions and intrinsic data), whether or not said one or more sets of basic instructions and intrinsic data are accessible at any given point in time.

0748Method core 1000' may be parameterized by an "event code" to permit it to respond to different events in different ways. For example, a METER method may respond to a "use" event by storing usage information in a meter data structure. The same METER method may respond to an "administrative" event by reporting the meter data structure to a VDE clearinghouse or other VDE participant.

0749In the preferred embodiment, method core 1000' may "contain," either exphcitly or by reference, one or more "load modules" 1100 and one or more data elements (UDEs 1200, MDEs 1202). In the prefeπed embodiment, a "load module" 1100 is a portion of a method that reflects basic instructions and intrinsic data. Load modules 1100 in the preferred embodiment contain executable code, and may also contain data elements ("DTDs" 1108) associated with the executable code. In the prefeπed embodiment, load modules 1100 supply the program instructions that are actuaUy "executed" by hardware to perform the process defined by the method. Load modules 1100 may contain or reference other load modules.

0750Load modules 1100 in the prefeπed embodiment are modular and "code pure" so that individual load modules may be reenterable and reusable. In order for components 690 to be dynamicaUy updatable, they may be individuaUy addressable within a global pubhc name space. In view of these design goals, load modules 1100 are preferably smaU, code (and code-like) pure modules that are individuaUy named and addressable. A single method may provide different load modules 1100 that perform the same or similar functions on different platforms, thereby making the method scalable and/or portable across a wide range of different electronic apphances.

0751UDEs 1200 and MDEs 1202 may store data for input to or output from executable component assembly 690 (or data describing such inputs and or outputs). In the preferred embodiment, UDEs 1200 may be user dependent, whereas MDEs 1202 may be user independent.

0752The component assembly example 690(k) shown in Figure HE comprises a method core 1000', UDEs 1200a & 1200b, an MDE 1202, load modules HOOa-llOOd, and a further component assembly 690(k+l). As mentioned above, a PERC 808(k) defines, among other things, the "assembly instructions" for component assembly 690(k), and may contain or reference parts of some or aU of the components that are to be assembled to create a component assembly.

0753One of the load modules 1100b shown in this example is itself comprised of plural load modules 1100c, HOOd. Some of the load modules (e.g., 1100a, HOOd) in this example include one or more "DTD" data elements 1108 (e.g., 1108a, 1108b). "DTD" data elements 1108 may be used, for example, to inform load module 1100a of the data elements included in MDE 1202 and/or UDEs 1200a, 1200b. Furthermore, DTDs 1108 may be used as an aspect of forming a portion of an apphcation used to inform a user as to the information required and/or manipulated by one or more load modules 1100, or other component elements. Such an apphcation program may also include functions for creating and or manipulating UDE(s) 1200, MDE(s) 1202, or other component elements, subassembhes, etc.

0754Components within component assembhes 690 may be "reused" to form different component assembhes. As mentioned above, figure 1 IF is an abstract depiction of one example of the same components used for assembling component assembly 690(k) to be reused (e.g., with some additional components specified by a different set of "assembly instructions" provided in a different PERC 808(1)) to form a different component assembly 690(1). Even though component assembly 690(1) is formed from some of the same components used to form component assembly 690(k), these two component assembhes may perform completely different processes in complete different ways.

0755As mentioned above, ROS 602 provides several layers of security to ensure the security of component assembhes 690. One important security layer involves ensuring that certain component assembhes 690 are formed, loaded and executed only in secure execution space such as provided within an SPU 500. Components 690 and/or elements comprising them may be stored on external media encrypted using local SPU 500 generated and/or distributor provided keys.

0756ROS 602 also provides a tagging and sequencing scheme that may be used within the loadable component assembhes 690 to detect tampering by substitution. Each element comprising a component assembly 690 may be loaded into an SPU 500, decrypted using encrypt decrypt engine 522, and then tested/compared to ensure that the proper element has been loaded. Several independent comparisons may be used to ensure there has been no unauthorized substitution. For example, the pubhc and private copies of the element ID may be compared to ensure that they are the same, thereby preventing gross substitution of elements. In addition, a validation/correlation tag stored under the encrypted layer of the loadable element may be compared to make sure it matches one or more tags provided by a requesting process. This prevents unauthorized use of information. As a third protection, a device assigned tag (e.g., a sequence number) stored under an encryption layer of a loadable element may be checked to make sure it matches a corresponding tag value expected by SPU 500. This prevents substitution of older elements. Validation/correlation tags are typicaUy passed only in secure wrappers to prevent plaintext exposure of this information outside of SPU 500.

0757The secure component based architecture of ROS 602 has important advantages. For example, it accommodates limited resource execution environments such as provided by a lower cost SPU 500. It also provides an extremely high level of configurabihty. In fact, ROS 602 will accommodate an almost unlimited diversity of content types, content provider objectives, transaction types and chent requirements. In addition, the abihty to dynamicaUy assemble independently dehverable components at execution time based on particular objects and users provides a high degree of flexibility, and facilitates or enables a distributed database, processing, and execution environment.

0758One aspect of an advantage of the component-based architecture provided by ROS 602 relates to the abihty to "stage" functionahty and capabihties over time. As designed, implementation of ROS 602 is a finite task. Aspects of its wealth of functionahty can remain unexploited until market realities dictate the implementation of corresponding VDE apphcation functionahty. As a result, initial product implementation investment and complexity may be limited. The process of "surfacing" the fuU range of capabilities provided by ROS 602 in terms of authoring, administrative, and artificial intelligence apphcations may take place over time. Moreover, already- designed functionahty of ROS 602 may be changed or enhanced at any time to adapt to changing needs or requirements. More Detailed Discussion of Rights Operating System 602 Architecture

0759Figure 12 shows an example of a detaUed architecture of ROS 602 shown in Figure 10. ROS 602 may include a file system 687 that includes a commercial database manager 730 and external object repositories 728. Commercial database manager 730 may maintain secure database 610. Object repository 728 may store, provide access to, and/or maintain VDE objects 300.

0760Figure 12 also shows that ROS 602 may provide one or more SPEs 503 and/or one or more HPEs 655. As discussed above, HPE 655 may "emulate" an SPU 500 device, and such HPEs 655 may be integrated in heu of (or in addition to) physical SPUs 500 for systems that need higher throughput. Some security may be lost since HPEs 655 are typicaUy protected by operating system security and may not provide truly secure processing. Thus, in the preferred embodiment, for high security apphcations at least, aU secure processing should take place within an SPE 503 having an execution space within a physical

0761SPU 500 rather than a HPE 655 using software operating elsewhere in electronic apphance 600. As mentioned above, three basic components of ROS 602 are a kernel 680, a Remote Procedure CaU (RPC) manager 732 and an object switch 734. These components, and the way they interact with other portions of ROS 602, wiU be discussed below.

0762Kernel 680

0763Kernel 680 manages the basic hardware resources of electronic apphance 600, and controls the basic tasking provided by ROS 602. Kernel 680 in the preferred embodiment may include a memory manager 680a, a task manager 680b, and an

0764I/O manager 680c. Task manager 680b may initiate and or manage initiation of executable tasks and schedule them to be executed by a processor on which ROS 602 runs (e.g., CPU 654 shown in Figure 8). For example, Task manager 680b may include or be associated with a "bootstrap loader" that loads other parts of ROS 602. Task manager 680b may manage aU tasking related to ROS 602, including tasks associated with apphcation program(s) 608. Memory manager 680a may manage aUocation, deaUocation, sharing and/or use of memory (e.g., RAM 656 shown in Figure 8) of electronic apphance 600, and may for example provide virtual memory capabilities as required by an electronic apphance and/or associated application(s). I/O manager 680c may manage aU input to and output from ROS 602, and may interact with drivers and other hardware managers that provide communications and interactivity with physical devices.

0765RPC Manager 732

0766ROS 602 in a prefeπed embodiment is designed around a "services based" Remote Procedure CaU architecture/interface. AU functions performed by ROS 602 may use this common interface to request services and share information. For example, SPE(s) 503 provide processing for one or more RPC based services. In addition to supporting SPUs 500, the RPC interface permits the dynamic integration of external services and provides an array of configuration options using existing operating system components. ROS 602 also communicates with external services through the RPC interface to seamlessly provide distributed and or remote processing. In smaUer scale instances of ROS 602, a simpler message passing IPC protocol may be used to conserve resources. This may limit the configurabihty of ROS 602 services, but this possible limitation may be acceptable in some electronic apphances. The RPC structure aUows services to be caUed/requested without the calling process having to know or specify where the service is physically provided, what system or device wiU service the request, or how the service request wiU be fulfiUed. This feature supports families of services that may be scaled and/or customized for specific apphcations. Service requests can be forwarded and serviced by different processors and/or different sites as easUy as they can be forwarded and serviced by a local service system. Since the same RPC interface is used by ROS 602 in the prefeπed embodiment to request services within and outside of the operating system, a request for distributed and/or remote processing incurs substantiaUy no additional operating system overhead. Remote processing is easUy and simply integrated as part of the same service calls used by ROS 602 for requesting local-based services. In addition, the use of a standard RPC interface ("RSI") allows ROS 602 to be modularized, with the different modules presenting a standardized interface to the remainder of the operating system. Such modularization and standardized interfacing permits different vendors/operating system programmers to create different portions of the operating system independently, and also allows the functionahty of ROS 602 to be flexibly updated and/or changed based on different requirements and/or platforms.

0767RPC manager 732 manages the RPC interface. It receives service requests in the form of one or more "Remote Procedure

0768Calls" (RPCs) from a service requestor, and routes the service requests to a service providers) that can service the request. For example, when rights operating system 602 receives a request from a user apphcation via user API 682, RPC manager 732 may route the service request to an appropriate service through the

0769"RPC service interface" ("RSI"). The RSI is an interface between RPC manager 732, service requestors, and a resource that wiU accept and service requests.

0770The RPC interface (RSI) is used for several major ROS 602 subsystems in the preferred embodiment.

0771RPC services provided by ROS 602 in the preferred embodiment are divided into subservices, i.e., individual instances of a specific service each of which may be tracked individuaUy by the RPC manager 732. This mechanism permits multiple instances of a specific service on higher throughput systems whUe maintaining a common interface across a spectrum of implementations. The subservice concept extends to supporting multiple processors, multiple SPEs 503, multiple HPEs 655, and multiple communications services.

0772The preferred embodiment ROS 602 provides the foUowing RPC based service providers/requestors (each of which have an RPC interface or "RSI" that communicates with RPC manager 732): SPE device driver 736 (this SPE device driver is connected to an SPE 503 in the prefeπed embodiment); HPE Device Driver 738 (this HPE device driver is connected to an HPE 738 in the preferred embodiment); Notification Service 740 (this notification service is connected to user notification interface 686 in the preferred embodiment); API Service 742 (this API service is connected to user API 682 in the preferred embodiment; Redirector 684;

0773Secure Database (FUe) Manager 744 (this secure database or file manager 744 may connect to and interact with commercial database manager 730 and secure files 610 through a cache manager 746, a database interface 748, and a database driver 750);

0774Name Services Manager 752; Outgoing Administrative Objects Manager 754;

0775Incoming Adm-inistrative Objects Manager 756; a Gateway 734 to object switch 734 (this is a path used to allow direct communication between RPC manager 732 and Object Switch 734); and Communications Manager 776.

0776The types of services provided by HPE 655, SPE 503, User Notification 686, API 742 and Redirector 684 have already been described above. Here is a brief description of the type(s) of services provided by OS resources 744, 752, 754, 756 and 776:

0777Secure Database Manager 744 services requests for access to secure database 610; Name Servjc^es Manager 752 services requests relating to user, host, or service identification; Outgoing Administrative Objects M^a*ιager 754 services requests relating to outgoing administrative objects; Tnroming Administrative Objects Manager 756 services requests relating to incoming administrative objects; and πnmmnnirations Manager 776 services requests relating to communications between electronic apphance 600 and the outside world.

0778Object Switch 734

0779Object switch 734 handles, controls and communicates (both locaUy and remotely) VDE objects 300. In the preferred embodiment, the object switch may include the foUowing elements: a stream router 758; a real time stream interface(s) 760 (which may be connected to real time data feed(s) 694); a time dependent stream interface(s) 762; a intercept 692; a container manager 764; one or more routing tables 766; and buffering/storage 768.

0780Stream router 758 routes to from "real time" and "time independent" data streams handled respectively by real time stream interface(s) 760 and time dependent stream interface(s) 762. Intercept 692 intercepts I/O requests that involve real-time information streams such as, for example, real time feed 694. The routing performed by stream router 758 may be determined by routing tables 766. Buffering/storage 768 provides temporary store-and-forward, buffering and related services. Container manager 764 may (typicaUy in conjunction with SPE 503) perform processes on VDE objects 300 such as constructing, deconstructing, and locating portions of objects.

0781Object switch 734 communicates through an Object Switch Interface ("OSI") with other parts of ROS 602. The Object Switch Interface may resemble, for example, the interface for a Unix socket in the preferred embodiment. Each of the "OSI" interfaces shown in Figure 12 have the abihty to communicate with object switch 734.

0782ROS 602 includes the foUowing object switch service providers/resources (each of which can communicate with the object switch 734 through an "OSI"):

0783Outgoing Administrative Objects Manager 754; Incoming Administrative Objects Manager 756; Gateway 734 (which may translate RPC calls into object switch calls and vice versa so RPC manager 732 may communicate with object switch 734 or any other element having an OSI to, for example, provide and or request services);

0784External Services Manager 772;

0785Object Submittal Manager 774; and

0786Communications Manager 776.

0787Briefly,

0788Object Repository Manager 770 provides services relating to access to object repository 728; External Services Manager 772 provides services relating to requesting and receiving services externaUy, such as from a network resource or another site;

0789Object Submittal Manager 774 provides services relating to how a user apphcation may interact with object switch 734 (since the object submittal manager provides an interface to an apphcation program 608, it could be considered part of user API 682); and

0790Communications Manager 776 provides services relating to communicating with the outside world. , In the preferred embodiment, communications manager 776 may include a network manager 780 and a maU gateway (manager) 782. MaU gateway 782 may include one or more maU filters 784 to, for example, automaticaUy route VDE related electronic maU between object switch 734 and the outside world electronic mail services. External Services Manager 772 may interface to communications manager 776 through a Service Transport Layer 786. Service Transport Layer 786a may enable External Services Manager 772 to communicate with external computers and systems using various protocols managed using the service transport layer 786.

0791The characteristics of and interfaces to the various subsystems of ROS 680 shown in Figure 12 are described in more detaU below.

0792RPC Manager 732 and Its RPC Services Interface

0793As discussed above, the basic system services provided by ROS 602 are invoked by using an RPC service interface (RSI). This RPC service interface provides a generic, standardized interface for different services systems and subsystems provided by ROS 602. RPC Manager 732 routes RPCs requesting services to an appropriate RPC service interface. In the preferred embodiment, upon receiving an RPC caU, RPC manager 732 determines one or more service managers that are to service the request. RPC manager 732 then routes a service request to the appropriate service(s) (via a RSI associated with a service) for action by the appropriate service managers).

0794For example, if a SPE 503 is to service a request, the RPC Manager 732 routes the request to RSI 736a, which passes the request on to SPE device driver 736 for forwarding to the SPE. Similarly, if HPE 655 is to service the request, RPC Manager 732 routes the request to RSI 738a for forwarding to a HPE. In one preferred embodiment, SPE 503 and HPE 655 may perform essentiaUy the same services so that RSIs 736a, 738a are different instances of the same RSI. Once a service request has been received by SPE 503 (or HPE 655), the SPE (or HPE) typicaUy dispatches the request internaUy using its own internal RPC manager (as will be discussed shortly). Processes within SPEs 503 and HPEs 655 can also generate RPC requests. These requests may be processed internaUy by a SPE/HPE, or if not internaUy serviceable, passed out of the SPE/HPE for dispatch by RPC Manager 732.

0795Remote (and local) procedure calls may be dispatched by a RPC Manager 732 using an "RPC Services Table." An RPC

0796Services Table describes where requests for specific services are to be routed for processing. Each row of an RPC Services Table in the prefeπed embodiment contains a services ID, the location of the service, and an address to which control will be passed to service a request. An RPC Services Table may also include control information that indicates which instance of the RPC dispatcher controls the service. Both RPC Manager 732 and any attached SPEs 503 and HPEs 655 may have symmetric copies of the RPC Services Table. If an RPC service is not found in the RPC services tables, it is either rejected or passed to external services manager 772 for remote servicing.

0797Assuming RPC manager 732 finds a row coπesponding to the request in an RPC Services Table, it may dispatch the request to an appropriate RSI. The receiving RSI accepts a request from the RPC manager 732 (which may have looked up the request in an RPC service table), and processes that request in accordance with internal priorities associated with the specific service.

0798In the preferred embodiment, RPC Service Interface(s) supported by RPC Manager 732 may be standardized and published to support add-on service modules developed by third party vendors, and to facilitate scalability by making it easier to program ROS 602. The prefeπed embodiment RSI closely foUows the DOS and Unix device driver models for block devices so that common code may be developed for many platforms with minimum effort. An example of one possible set of common entry points are listed below in the table.

0799Interface call Description

0800SVC LOAD Load a service manager and return its status.

0801SVC UNLOAD Unload a service manager.

0802SVC_MOUNT Mount (load) a dynamicaUy loaded subservice and return its status.

0803SVC UNMOUNT Unmount (unload) a dynamicaUy loaded subservice.

0804SVC OPEN Open a mounted subservice.

0805SVC CLOSE Close a mounted subservice.

0806SVC READ Read a block from an opened subservice. SVC WRITE Write a block to an opened subservice.

0807SVC IOCTL Control a subservice or a service manager

0808Load

0809In the preferred embodiment, services (and the associated RSIs they present to RPC manager 732) may be activated during boot by an installation boot process that issues an RPC LOAD. This process reads an RPC Services Table from a configuration file, loads the service module if it is run time loadable (as opposed to being a kernel linked device driver), and then calls the LOAD entry point for the service. A successful return from the LOAD entry point will indicate that the service has properly loaded and is ready to accept requests.

0810RPC LOAD CaU Example: SVC_LOAD (long service_id)

0811This LOAD interface caU is caUed by the RPC manager 732 during rights operating system 602 initialization. It permits a service manager to load any dynamicaUy loadable components and to initialize any device and memory required by the service. The service number that the service is loaded as is passed in as service_id parameter. In the prefeπed embodiment, the service returns 0 is the initialization process was completed successfully or an error number if some error occurred.

0812Mount Once a service has been loaded, it may not be fuUy functional for aU subservices. Some subservices (e.g., communications based services) may require the establishment of additional connections, or they may require additional modules to be loaded. If the service is defined as "mountable," a RPC manager 732 will caU the MOUNT subservice entry point with the requested subservice ID prior to opening an instance of a subservice.

0813RPC MOUNT CaU Example: SVC_MOUNT (long serv e_id, long subservice.id, BYTE

0814*buffer)

0815This MOUNT interface caU instructs a service to make a specific subservice ready. This may include services related to networking, communications, other system services, or external resources. The service_id and subservice_id parameters may be specific to the specific service being requested. The buffer parameter is a memory address that references a control structure appropriate to a specific service.

0816Open Once a service is loaded and "mounted," specific instances of a service may be "opened" for use. "Opening" an instance of a service may aUocate memory to store control and status infoπnation. For example, in a BSD socket based network connection, a LOAD caU will initialize the software and protocol control tables, a MOUNT caU wiU specify networks and hardware resources, and an OPEN wiU actuaUy open a socket to a remote instaUation.

0817Some services, such as commercial database manager 730 that underhes the secure database service, may not be

0818"mountable." In this case, a LOAD caU wiU make a connection to a database manager 730 and ensure that records are readable. An OPEN call may create instances of internal cache manager 746 for various classes of records.

0819RPC OPEN CaU Example:

0820SVC_OPEN (long service_id, long subservice_id, BYTE *buffer, int (*receive) (long request_id)) This OPEN interface caU instructs a service to open a specific subservice. The service_id and subservice_id parameters are specific to the specific service being requested, and the buffer parameter is a memory address that references a control structure appropriate to a specific service.

0821The optional receive parameter is the address of a notification caUback function that is called by a service whenever a message is ready for the service to retrieve it. One caU to this address is made for each incoming message received. If the caUer passes a NULL to the interface, the software will not generate a caUback for each message.

0822Close, Unmount and Unload

0823The converse of the OPEN, MOUNT, and LOAD caUs are CLOSE, UNMOUNT, and UNLOAD. These interface caUs release any aUocated resources back to ROS 602 (e.g., memory manager 680a). RPC CLOSE Call Example: SVC_CLOSE (long svc_handle)

0824This LOAD interface caU closes an open service "handle." A service "handle" describes a service and subservice that a user wants to close. The caU returns 0 if the CLOSE request succeeds (and the handle is no longer valid) or an error number.

0825RPC UNLOAD CaU Example: SVCJ NLOAD (void)

0826This UNLOAD interface caU is caUed by a RPC manager 732 during shutdown or resource reaUocation of rights operating system 602. It permits a service to close any open connections, flush buffers, and to release any operating system resources that it may have aUocated. The service returns 0.

0827RPC UNMOUNT CaU Example: SVCJJNMOUNT (long service_id, long subservice_id)

0828This UNMOUNT interface caU instructs a service to deactivate a specific subservice. The service_id and subservice_id parameters are specific to the specific service being requested, and must have been previously mounted using the SVC_MOUNT() request. The caU releases aU system resources associated with the subservice before it returns. Read and Write

0829The READ and WRITE calls provide a basic mechanism for sending information to and receiving responses from a mounted and opened service. For example, a service has requests written to it in the form of an RPC request, and makes its response avaUable to be read by RPC Manager 732 as they become avaUable.

0830RPC READ Call Example: SVC_READ (long svc iandle, long requested, BYTE

0831*buffer, long size)

0832This READ caU reads a message response from a service.

0833The svc_handle and requested parameters uniquely identify a request. The results of a request wiU be stored in the user specified buffer up to size bytes. If the buffer is too smaU, the first size bytes of the message w l be stored in the buffer and an error will be returned.

0834If a message response was returned to the caUer's buffer coπectly, the function will return 0. Otherwise, an error message will be returned. RPC WRITE CaU Example:

0835SVC_write (long service.id, long subservice_id, BYTE *buffer, long size, int (*receive) (long request_id)

0836This WRITE caU writes a message to a service and subservice specified by the service_id/subservice_id parameter pair. The message is stored in buffer (and usuaUy conforms to the VDE RPC message format) and is size bytes long. The function returns the request id for the message (if it was accepted for sending) or an error number. If a user specifies the receive caUback functions, aU messages regarding a request wiU be sent to the request specific caUback routine instead of the generalized message caUback.

0837Input/Output Control The IOCTL ("Input/Output ConTroL") caU provides a mechanism for querying the status of and controlling a loaded service. Each service type will respond to specific general IOCTL requests, aU required class IOCTL requests, and service specific IOCTL requests. RPC IOCTL CaU Example: ROI_SVC_IOCTL (long service_id, long subservice_id, int command, BYTE "buffer)

0838This IOCTL function provides a generalized control interface for a RSI. A user specifies the service_id parameter and an optional subservice_id parameter that they wish to control. They specify the control command parameter(s), and a buffer into/from which the command parameters may be written/read. An example of a list of commands and the appropriate buffer structures are given below.

0839Command Structure Description

0840GET_INFO SVC NFO Returns information about a service/subservice .

0841GET_STATS SVC_.STATS Returns current statistics about a service/subservice.

0842CLR_STATS None Clears the statistics about a service/subservice.

0843Now that a generic RPC Service Interface provided by the prefeπed embodiment has been described, the foUowing description relates to particular examples of services provided by ROS 602.

0844SPE Device Driver 736 SPE device driver 736 provides an interface between ROS

0845602 and SPE 503. Since SPE 503 in the preferred embodiment runs within the confines of an SPU 500, one aspect of this device driver 736 is to provide low level communications services with the SPU 500 hardware. Another aspect of SPE device driver 736 is to provide an RPC service interface (RSI) 736a particular to

0846SPE 503 (this same RSI may be used to communicate with HPE 655 through HPE device driver 738).

0847SPE RSI 736a and driver 736 isolates calling processes vvάthin ROS 602 (or external to the ROS) from the detaUed service provided by the SPE 503 by providing a set of basic interface points providing a concise function set. This has several advantages. For example, it permits a fuU line of scaled SPUs 500 that aU provide common functionahty to the outside world but which may differ in detailed internal structure and architecture. SPU 500 characteristics such as the amount of memory resident in the device, processor speed, and the number of services supported within SPU 500 may be the decision of the specific SPU manufacturer, and in any event may differ from one SPU configuration to another. To maintain compatibility, SPE device driver 736 and the RSI 736a it provides conform to a basic common RPC interface standard that "hides" differences between detaUed configurations of SPUs 500 and/or the SPEs 503 they may support.

0848To provide for such compatibility, SPE RSI 736a in the preferred embodiment foUows a simple block based standard. In the prefeπed embodiment, an SPE RSI 736a may be modeled after the packet interfaces for network Ethernet cards. This standard closely models the block mode interface characteristics of SPUs 500 in the prefeπed embodiment.

0849An SPE RSI 736a aUows RPC calls from RPC manager 732 to access specific services provided by an SPE 736. To do this, SPE RSI 736a provides a set of "service notification address interfaces." These provide interfaces to individual services provided by SPE 503 to the outside world. Any calling process within ROS 602 may access these SPE-provided services by directing an RPC call to SPE RSI 736a and specifying a coπesponding "service notification address" in an RPC caU. The specified "service notification address" causes SPE 503 to internaUy route an RPC caU to a particular service within an SPE. The foUowing is a listing of one example of a SPE service breakdown for which individual service notification addresses may be provided:

0850Channel Services Manager

0851Authentication Manager/Secure Communications Manager

0852Secure Database Manager

0853The Channel Services Manager is the principal service provider and access point to SPE 503 for the rest of ROS 602. Event processing, as wiU be discussed later, is primarily managed (from the point of view of processes outside SPE 503) by this service. The Authentication Manager/Secure

0854Communications Manager may provide login logout services for users of ROS 602, and provide a direct service for managing communications (typicaUy encrypted or otherwise protected) related to component assembhes 690, VDE objects 300, etc. Requests for display of information (e.g., value remaining in a financial budget) may be provided by a direct service request to a Secure Database Manager inside SPE 503. The instances of Authentication Manager/Secure Communications Manager and Secure Database Manager, if avaUable at aU, may provide only a subset of the information and or capabilities avaUable to processes operating inside SPE 503. As stated above, most (potentiaUy aU) service requests entering SPE are routed to a Channel Services Manager for processing. As will be discussed in more detaU later on, most control structures and event processing logic is associated with component assembhes 690 under the management of a Channel Services Manager.

0855The SPE 503 must be accessed through its associated SPE driver 736 in this example. GeneraUy, calls to SPE driver 736 are made in response to RPC calls. In this example, SPE driver RSI 736a may translate RPC calls directed to control or ascertain information about SPE driver 736 into driver caUs. SPE driver

0856RSI 736a in conjunction with driver 736 may pass RPC calls directed to SPE 503 through to the SPE.

0857The foUowing table shows one example of SPE device driver 736 caUs: Entry Point Description

0858SPE_info() Returns summary information about t SPE driver 736 (and SPE 503)

0859SPE_initialize_interface( ) Initializes SPE driver 736, and sets th default notification address for receive packets.

0860SPE_terminate_interface( ) Terminates SPE driver 736 and resets SPU 500 and the driver 736.

0861SPE_reset_interf ace( ) Resets driver 736 without resetting SP 500.

0862SPE_get_stats() Return statistics for notification addresses and/or an entire driver 736.

0863SPE_clear_stats() Clears statistics for a specific notification address and/or an entire driver 736.

0864SPE_set_notify() Sets a notification address for a specifi service ID.

0865SPE_get_notify() Returns a notification address for a specific service ID.

0866SPE_tx_pkt() Sends a packet (e.g., containing an RP caU) to SPE 503 for processing.

0867The foUowing are more detaUed examples of each of the SPE driver calls set forth in the table above. Example of an "SPE Infoπnation"Driver Call: SPE_info (void)

0868This function returns a pointer to an SPEJNFO data structure that defines the SPE device driver 736a. This data structure may provide certain information about SPE device driver 736, RSI 736a and or SPU 500. An example of a SPE INFO structure is described below:

0869Version Number/ID for SPE Device Driver 736

0870Version Number/ID for SPE Device Driver RSI 736

0871Pointer to name of SPE Device Driver 736

0872Pointer to ID name of SPU 500

0873Functionahty Code Describing SPE Capabilities/functionality

0874Example of an SPE "Initialize InterfaceTDriver CaU:

0875SPE_initiahze_interface (int (fen *receiver)(void))

0876A receiver function passed in by way of a parameter will be caUed for aU packets received from SPE 503 unless their destination service is over-ridden using the set_notify() caU. A receiver function allows ROS 602 to specify a format for packet communication between RPC manager 732 and SPE 503.

0877This function returns "0" in the preferred embodiment if the initiahzation of the interface succeeds and non-zero if it fails If the function fails, it will return a code that describes the reason for the faUure as the value of the function.

0878Example of an SPE "Terminate InterfaceDriver CaU:

0879SPE_terminate_interface (void)

0880In the prefeπed embodiment, this function shuts down SPE Driver 736, clears aU notification addresses, and terminates aU outstanding requests between an SPE and an ROS RPC manager 732. It also resets an SPE 503 (e.g., by a warm reboot of SPU 500) after aU requests are resolved.

0881Termination of driver 736 should be performed by ROS 602 when the operating system is starting to shut down. It may also be necessary to issue this caU if an SPE 503 and ROS 602 get so far out of synchronization that aU processing in an SPE must be reset to a known state. Example of an SPE "Reset Interface'Driver Call:

0882SPE_reset_interface (void)

0883This function resets driver 736, terminates aU outstanding requests between SPE 503 and an ROS RPC manager 732, and clears aU statistics counts. It does not reset the SPU 500, but simply restores driver 736 to a known stable state.

0884Example of an SPE "Get Statistics'Driver CaU: SPE_get_stats (long service_id)

0885This function returns statistics for a specific service notification interface or for the SPE driver 736 in general. It returns a pointer to a static buffer that contains these statistics or NULL if statistics are unavaUable (either because an interface is not initiahzed or because a receiver address was not specified). An example of the SPE_STATS structure may have the foUowing definition:

0886<img file="WO9627155A2_D0001.tif" /><img file="WO9627155A2_D0002.tif" />

0887If a user specifies a service ID, statistics associated with packets sent by that service are returned. If a user specified 0 as the parameter, the total packet statistics for the interface are returned.

0888Example of an SPE "Clear Statistics'Driver CaU:

0889SPE_clear_stats (long service_id)

0890This function clears statistics associated with the SPE service_id specified. If no service_id is specified (i.e., the caUer passes in 0), global statistics will be cleared. The function returns 0 if statistics are successfuUy cleared or an eπor number if an eπor occurs. Example of an SPE "Set Notification AddreβsTDriver Call:

0891SPE_set_notify (long service_id, int (fcn*receiver) (void))

0892This function sets a notification address (receiver) for a specified service. If the notification address is set to NULL, SPE device driver 736 wiU send notifications for packets to the specified service to the default notification address.

0893Example of a SPE "Get Notification Address'Driver CaU:

0894SPE_get_notify (long service_id) This function returns a notification address associated with the named service or NULL if no specific notification address has been specified.

0895Example of an SPE "Send PackefDriver CaU: send_pkt (BYTE *buffer, long size, int (far *receive) (void))

0896This function sends a packet stored in buffer of "length" size. It returns 0 if the packet is sent successfuUy, or returns an error code associated with the faUure.

0897Redirector Service Manager 684

0898The redirector 684 is a piece of systems integration software used principaUy when ROS 602 is provided by "adding on" to a pre-existing operating system or when "transparent" operation is desired for some VDE functions, as described earlier. In one embodiment the kernel 680, part of communications manager 776, file system 687, and part of API service 742 may be part of a pre-existing operating system such as DOS, Windows,

0899UNIX, Macintosh System, OS9, PSOS, OS/2, or other operating system platform. The remainder of ROS 602 subsystems shown in Figure 12 may be provided as an "add on" to a preexisting operating system. Once these ROS subsystems have been supphed and "added on," the integrated whole comprises the ROS

0900602 shown in Figure 12.

0901In a scenario of this type of integration, ROS 602 will continue to be supported by a preexisting OS kernel 680, but may supplement (or even substitute) many of its functions by providing additional add-on pieces such as, for example, a virtual memory manager.

0902Also in this integration scenario, an add-on portion of API service 742 that integrates readUy with a preexisting API service is provided to support VDE function calls. A pre-existing API service integrated with an add-on portion supports an enhanced set of operating system cells including both calls to VDE functions 604 and calls to functions 606 other than VDE functions (see Figure 11A). The add-on portion of API service 742 may translate VDE function calls into RPC calls for routing by RPC manager 732.

0903ROS 602 may use a standard communications manager 776 provided by the preexisting operating system, or it may provide "add ons" and/or substitutions to it that may be readUy integrated into it. Redirector 684 may provide this integration function.

0904This leaves a requirement for ROS 602 to integrate with a preexisting file system 687. Redirector 684 provides this integration function.

0905In this integration scenario, file system 687 of the preexisting operating system is used for aU accesses to secondary storage. However, VDE objects 300 may be stored on secondary storage in the form of external object repository 728, file system

0906687, or remotely accessible through communications manager 776. When object switch 734 wants to access external object repository 728, it makes a request to the object repository manager 770 that then routes the request to object repository 728 or to redirector 692 (which in turn accesses the object in file system 687).

0907GeneraUy, redirector 684 maps VDE object repository 728 content into preexisting calls to file system 687. The redirector 684 provides preexisting OS level information about a VDE object 300, including mapping the object into a preexisting OS's name space. This permits seamless access to VDE protected content using "normal" file system 687 access techniques provided by a preexisting operating system.

0908In the integration scenarios discussed above, each preexisting target OS file system 687 has different interface requirements by which the redirector mechanism 684 may be "hooked." In general, since aU commerciaUy viable operating systems today provide support for network based volumes, file systems, and other devices (e.g., printers, modems, etc.), the redirector 684 may use low level network and file access "hooks" to integrate with a preexisting operating system. "Add-ons" for supporting VDE functions 602 may use these existing hooks to integrate with a preexisting operating system.

0909User Notification Service Manager 740 User Notification Service Manager 740 and associated user notification exception interface ("pop up") 686 provides ROS 602 with an enhanced ability to communicate with a user of electronic apphance 600. Not aU apphcations 608 may be designed to respond to messaging from ROS 602 passed through API 682, and it may in any event be important or desirable to give ROS

0910602 the abihty to communicate with a user no matter what state an apphcation is in. User notification services manager 740 and interface 686 provides ROS 602 with a mechanism to communicate directly with a user, instead of or in addition to passing a return caU through API 682 and an apphcation 608.

0911This is similar, for example, to the abihty of the Windows operating system to display a user message in a "dialog box" that displays "on top of a running apphcation irrespective of the state of the apphcation.

0912The User Notification 686 block in the prefeπed embodiment may be implemented as apphcation code. The implementation of interface 740a is preferably buUt over notification service manager 740, which may be implemented as part of API service manager 742. Notification services manager 740 in the preferred embodiment provides notification support to dispatch specific notifications to an appropriate user process via the appropriate API return, or by another path. This mechanism permits notifications to be routed to any authorized process — not just back to a process that specified a notification mechanism.

0913API Service Manager 742

0914The preferred embodiment API Service Manager 742 is implemented as a service interface to the RPC service manager 732. AU user API requests are buUt on top of this basic interface. The API Service Manager 742 preferably provides a service instance for each running user apphcation 608.

0915Most RPC calls to ROS functions supported by API Service Manager 742 in the preferred embodiment may map directly to service calls with some additional parameter checking. This mechanism permits developers to create their own extended API libraries with additional or changed functionahty. In the scenario discussed above in which ROS 602 is formed by integrating "add ons" with a preexisting operating system, the API service 742 code may be shared (e.g., resident in a host environment hke a Windows DLL), or it may be directly linked with an apphcations's code — depending on an apphcation programmer's implementation decision, and/or the type of electronic apphance 600. The Notification Service Manager 740 may be implemented within API 682. These components interface with Notification Service component 686 to provide a transition between system and user space.

0916Secure Database Service Manager ("SDSM7 744

0917There are at least two ways that may be used for managing secure database 600: C a commercial database approach, and

0918C a site record number approach.

0919Which way is chosen may be based on the number of records that a VDE site stores in the secure database 610.

0920The commercial database approach uses a commercial database to store securely wrappered records in a commercial database. This way may be preferred when there are a large number of records that are stored in the secure database 610. This way provides high speed access, efficient updates, and easy integration to host systems at the cost of resource usage (most commercial database managers use many system resources).

0921The site record number approach uses a "site record number" ("SRN") to locate records in the system. This scheme is prefeπed when the number of records stored in the secure database 610 is smaU and is not expected to change extensively over time. This way provides efficient resources use with limited update capabihties. SRNs permit further grouping of similar data records to speed access and increase performance.

0922Since VDE 100 is highly scalable, different electronic apphances 600 may suggest one way more than the other. For example, in limited environments like a set top, PDA, or other low end electronic apphance, the SRN scheme may be prefeπed because it limits the amount of resources (memory and processor) required. When VDE is deployed on more capable electronic apphances 600 such as desktop computers, servers and at clearinghouses, the commercial database scheme may be more desirable because it provides high performance in environments where resources are not limited.

0923One difference between the database records in the two approaches is whether the records are specified using a fuU VDE

0924ID or SRN. To translate between the two schemes, a SRN reference may be replaced with a VDE ID database reference wherever it occurs. Similarly, VDE IDs that are used as indices or references to other items may be replaced by the appropriate SRN value.

0925In the prefeπed embodiment, a commerciaUy avaUable database manager 730 is used to maintain secure database 610. ROS 602 interacts with commercial database manager 730 through a database driver 750 and a database interface 748. The database interface 748 between ROS 602 and external, third party database vendors' commercial database manager 730 may be an open standard to permit any database vendor to implement a VDE compliant database driver 750 for their products.

0926ROS 602 may encrypt each secure database 610 record so that a VDE-provided security layer is "on top of the commercial database structure. In other words, SPE 736 may write secure records in sizes and formats that may be stored within a database record structure supported by commercial database manager 730. Commercial database manager 730 may then be used to organize, store, and retrieve the records. In some embodiments, it may be desirable to use a proprietary and or newly created database manager in place of commercial database manager 730. However, the use of commercial database manager 730 may provide certain advantages such as, for example, an ability to use already existing database management product(s).

0927The Secure Database Services Manager ("SDSM") 744 makes calls to an underlying commercial database manager 730 to obtain, modify, and store records in secure database 610. In the prefeπed embodiment, "SDSM" 744 provides a layer "on top of the structure of commercial database manager 730. For example, aU VDE-secure information is sent to commercial database manager 730 in encrypted form. SDSM 744 in conjunction with cache manager 746 and database interface 748 may provide record management, caching (using cache manager

0928746), and related services (on top of) commercial database systems 730 and or record managers. Database Interface 748 and cache manager 746 in the preferred embodiment do not present their own RSI, but rather the RPC Manager 732 communicates to them through the Secure Database Manager RSI 744a.

0929Name Services Manager 752

0930The Name Services Manager 752 supports three subservices: user name services, host name services, and services name services. User name services provides mapping and lookup between user name and user ED numbers, and may also support other aspects of user-based resource and information security. Host name services provides mapping and lookup between the names (and other information, such as for example address, communications connection routing information, etc.) of other processing resources (e.g., other host electronic apphances) and VDE node IDs. Services name service provides a mapping and lookup between services names and other pertinent information such as connection information (e.g., remotely avaUable service routing and contact information) and service IDs. Name Services Manager 752 in the preferred embodiment is connected to External Services Manager 772 so that it may provide external service routing information directly to the external services manager. Name services manager 752 is also connected to secure database manager 744 to permit the name services manager 752 to access name services records stored within secure database 610.

0931External Services Manager 772 &amp; Services Transport Layer 786 The External Services Manager 772 provides protocol support capabihties to interface to external service providers. External services manager 772 may, for example, obtain external service routing infoπnation from name services manager 752, and then initiate contact to a particular external service (e.g., another VDE electronic apphance 600, a financial clearinghouse, etc.) through communications manager 776. External services manager 772 uses a service transport layer 786 to supply communications protocols and other information necessary to provide communications.

0932There are several important examples of the use of External Services Manager 772. Some VDE objects may have some or aU of their content stored at an Object Repository 728 on an electronic apphance 600 other than the one operated by a user who has, or wishes to obtain, some usage rights to such VDE objects. In this case, External Services Manager 772 may manage a connection to the electronic apphance 600 where the VDE objects desired (or their content) is stored. In addition, file system 687 may be a network file system (e.g., Netware, LANtastic, NFS, etc.) that aUows access to VDE objects using redirecter 684. Object switch 734 also supports this capability.

0933If External Services Manager 772 is used to access VDE objects, many different techniques are possible. For example, the VDE objects may be formatted for use with the World Wide Web protocols (HTML, HTTP, and URL) by including relevant headers, content tags, host ID to URL conversion (e.g., using

0934Name Services Manager 752) and an HTTP-aware instance of Services Transport Layer 786.

0935In other examples, External Services Manager 772 may be used to locate, connect to, and utilize remote event processing services; smart agent execution services (both to provide these services and locate them); certification services for Public Keys; remote Name Services; and other remote functions either supported by ROS 602 RPCs (e.g., have RSIs), or using protocols supported by Services Transport Layer 786.

0936Outgoing Administrative Object Manager 754

0937Outgoing adn-inistrative object manager 754 receives administrative objects from object switch 734, object repository manager 770 or other source for transmission to another VDE electronic apphance. Outgoing administrative object manager 754 takes care of sending the outgoing object to its proper destination. Outgoing adniinistrative object manager 754 may obtain routing information from name services manager 752, and may use communications service 776 to send the object. Outgoing administrative object manager 754 typicaUy maintains records (in concert with SPE 503) in secure database 610 (e.g., shipping table 444) that reflect when objects have been successfuUy transmitted, when an object should be transmitted, and other information related to transmission of objects.

0938Incoming Administrative Object Manager 756

0939Incoming administrative object manager 756 receives admiiiistrative objects from other VDE electronic apphances 600 via communications manager 776. It may route the object to object repository manager 770, object switch 734 or other destination. Incoming administrative object manager 756 typicaUy maintains records (in concert with SPE 503) in secure database 610 (e.g., receiving table 446) that record which objects have been received, objects expected for receipt, and other information related to received and or expected objects.

0940Object Repository Manager 770 Object repository manager 770 is a form of database or file manager. It manages the storage of VDE objects 300 in object repository 728, in a database, or in the file system 687. Object repository manager 770 may also provide the ability to browse and/or search information related to objects (such as summaries of content, abstracts, reviewers' commentary, schedules, promotional materials, etc.), for example, by using INFORMATION methods associated with VDE objects 300.

0941Object Submittal Manager 774 Object submittal manager 774 in the prefeπed embodiment provides an interface between an apphcation 608 and object switch 734, and thus may be considered in some respects part of API 682. For example, it may aUow a user apphcation to create new VDE objects 300. It may also allow incoming/outgoing administrative object managers 756, 754 to create VDE objects 300 (administrative objects).

0942Figure 12A shows how object submittal manager 774 may be used to communicate with a user of electronic apphance 600 to help to create a new VDE object 300. Figure 12A shows that object creation may occur in two stages in the preferred embodiment: an object definition stage 1220, and an object creation stage 1230. The role of object submittal manager 774 is indicated by the two different "user input" depictions (774(1), 774(2)) shown in Figure 12A.

0943In one of its roles or instances, object submittal manager

0944774 provides a user interface 774a that aUows the user to create an object configuration file 1240 specifying certain characteristics of a VDE object 300 to be created. This user interface 774a may, for example, allow the user to specify that she wants to create an object, aUow the user to designate the content the object wiU contain, and aUow the user to specify certain other aspects of the information to be contained within the object (e.g., rules and control information, identi-fying information, etc.).

0945Part of the object definition task 1220 in the preferred embodiment may be to analyze the content or other information to be placed within an object. Object definition user interface 774a may issue calls to object switch 734 to analyze "content" or other information that is to be included within the object to be created in order to define or organize the content into "atomic elements" specified by the user. As explained elsewhere herein, such "atomic element" organizations might, for example, break up the content into paragraphs, pages or other subdivisions specified by the user, and might be explicit (e.g., inserting a control character between each "atomic element") or implicit. Object switch 734 may receive static and dynamic content (e.g., by way of time independent stream interface 762 and real time stream interface 760), and is capable of accessing and retrieving stored content or other information stored within file system 687.

0946The result of object definition 1240 may be an object configuration file 1240 specifying certain parameters relating to the object to be created. Such parameters may include, for example, map tables, key management specifications, and event method parameters. The object construction stage 1230 may take the object configuration file 1240 and the information or content to be included within the new object as input, construct an object based on these inputs, and store the object within object repository 728.

0947Object construction stage 1230 may use information in object configuration file 1240 to assemble or modify a container. This process typicaUy involves communicating a series of events to SPE 503 to create one or more PERCs 808, pubhc headers, private headers, and to encrypt content, aU for storage in the new object 300 (or within secure database 610 within records associated with the new object).

0948The object configuration file 1240 may be passed to container manager 764 within object switch 734. Container manager 734 is responsible for constructing an object 300 based on the object configuration file 1240 and further user input. The user may interact with the object construction 1230 through another instance 774(2) of object submittal manager 774. In this further user interaction provided by object submittal manager 774, the user may specify peπnissions, rules and/or control information to be apphed to or associated with the new object 300. To specify permissions, rules and control information, object submittal manager 774 and/or container manager 764 within object switch 734 generaUy wiU, as mentioned above, need to issue caUs to SPE 503 (e.g., through gateway 734) to cause the SPE to obtain appropriate information from secure database 610, generate appropriate database items, and store the database items into the secure database 610 and or provide them in encrypted, protected form to the object switch for incorporation into the object. Such information provided by SPE 503 may include, in addition to encrypted content or other information, one or more PERCs 808, one or more method cores 1000', one or more load modules 1100, one or more data structures such as UDEs 1200 and or MDEs 1202, along with various key blocks, tags, pubhc and private headers, and error correction information.

0949The container manager 764 may, in cooperation with SPE 503, construct an object container 302 based at least in part on parameters about new object content or other information as specified by object configuration file 1240. Container manager 764 may then insert into the container 302 the content or other information (as encrypted by SPE 503) to be included in the new object. Container manager 764 may also insert appropriate permissions, rules and/or control information into the container 302 (this permissions, rules and/or control information may be defined at least in part by user interaction through object submittal manager 774, and may be processed at least in part by SPE 503 to create secure data control structures). Container manager 764 may then write the new object to object repository 687, and the user or the electronic apphance may "register" the new object by including appropriate information within secure database 610.

0950Communications Subsystem 776 Communications subsystem 776, as discussed above, may be a conventional communications service that provides a network manager 780 and a maU gateway manager 782. MaU filters 784 may be provided to automaticaUy route objects 300 and other VDE information to/from the outside world. Communications subsystem 776 may support a real time content feed 684 from a cable, satellite or other telecommunications link. Secure Processing Environment 503

0951As discussed above in connection with Figure 12, each electronic apphance 600 in the preferred embodiment includes one or more SPEs 503 and/or one or more HPEs 655. These secure processing environments each provide a protected execution space for performing tasks in a secure manner They may fulfiU service requests passed to them by ROS 602, and they may themselves generate service requests to be satisfied by other services within ROS 602 or by services provided by another VDE electronic apphance 600 or computer.

0952In the prefeπed embodiment, an SPE 503 is supported by the hardware resources of an SPU 500. An HPE 655 may be supported by general purpose processor resources and rely on software techniques for security/protection. HPE 655 thus gives

0953ROS 602 the capability of assembling and executing certain component assembhes 690 on a general purpose CPU such as a microcomputer, minicomputer, mainframe computer or supercomputer processor. In the prefeπed embodiment, the overaU software architecture of an SPE 503 may be the same as the software architecture of an HPE 655. An HPE 655 can "emulate" SPE 503 and associated SPU 500, i.e., each may include services and resources needed to support an identical set of service requests from ROS 602 (although ROS 602 may be restricted from sending to an HPE certain highly secure tasks to be executed only within an SPU 500).

0954Some electronic apphance 600 configurations might include both an SPE 503 and an HPE 655. For example, the HPE 655 could perform tasks that need lesser (or no) security protections, and the SPE 503 could perform aU tasks that require a high degree of security. This abihty to provide serial or concurrent processing using multiple SPE and or HPE arrangements provides additional flexibility, and may overcome limitations imposed by limited resources that can practicaUy or cost- effectively be provided within an SPU 500. The cooperation of an SPE 503 and an HPE 655 may, in a particular apphcation, lead to a more efficient and cost effective but nevertheless secure overaU processing environment for supporting and providing the secure processing required by VDE 100. As one example, an HPE 655 could provide overaU processing for aUowing a user to manipulate released object 300 'contents,' but use SPE 503 to access the secure object and release the information from the object. Figure 13 shows the software architecture of the preferred embodiment Secure Processing Environment (SPE) 503. This architecture may also apply to the preferred embodiment Host Processing Environment (HPE) 655. "Protected Processing Environment" ("PPE") 650 may refer generaUy to SPE 503 and/or

0955HPE 655. Hereinafter, unless context indicates otherwise, references to any of "PPE 650," "HPE 655" and "SPE 503" may refer to each of them.

0956As shown in Figure 13, SPE 503 (PPE 650) includes the foUowing service managers/major functional blocks in the preferred embodiment:

0957Kernel/Dispatcher 552

0958C Channel Services Manager 562 C SPE RPC Manager 550

0959C Time Base Manager 554

0960C Encryption Decryption Manager 556

0961C Key and Tag Manager 558

0962C Summary Services Manager 560 C Authentication Manager/Service Communications

0963Manager 564 C Random Value Generator 565 C Secure Database Manager 566 C Other Services 592.

0964Each of the major functional blocks of PPE 650 is discussed in detaU below.

0965I. SPE Kernel/Dispatcher 552

0966The Kernel/Dispatcher 552 provides an operating system "kernel" that runs on and manages the hardware resources of SPU 500. This operating system "kernel" 552 provides a self- contained operating system for SPU 500; it is also a part of overaU ROS 602 (which may include multiple OS kernels, including one for each SPE and HPE ROS is controlhng/managing). Kernel/dispatcher 552 provides SPU task and memory management, supports internal SPU hardware interrupts, provides certain "low level services," manages "DTD" data structures, and manages the SPU bus interface unit 530. Kernel/dispatcher 552 also includes a load module execution manager 568 that can load programs into secure execution space for execution by SPU 500. In the preferred embodiment, kernel/dispatcher 552 may include the foUowing software/functional components: load module execution manager 568 task manager 576 memory manager 578 virtual memory manager 580 "low level" services manager 582 internal interrupt handlers 584 BIU handler 586 (may not be present in HPE 655) Service interrupt queues 588

0967DTD Interpreter 590.

0968At least parts of the kernel/dispatcher 552 are preferably stored in SPU firmware loaded into SPU ROM 532. An example of a memory map of SPU ROM 532 is shown in Figure 14 A. This memory map shows the various components of kernel/dispatcher 552 (as weU as the other SPE services shown in Figure 13) residing in SPU ROM 532a and/or EEPROM 532b. The Figure 14B example of an NVRAM 534b memory map shows the task manager 576 and other information loaded into NVRAM. One of the functions performed by kernel/dispatcher 552 is to receive RPC calls from ROS RPC manager 732. As explained above, the ROS Kernel RPC manager 732 can route RPC calls to the SPE 503 &lt;via SPE Device Driver 736 and its associated RSI 736a) for action by the SPE . The SPE kernel dispatcher 552 receives these calls and either handles them or passes them on to SPE RPC manager 550 for routing internaUy to SPE 503. SPE 503 based processes can also generate RPC requests. Some of these requests can be processed internaUy by the SPE 503. If they are not internaUy serviceable, they may be passed out of the

0969SPE 503 through SPE kernel/dispatcher 552 to ROS RPC manager 732 for routing to services external to SPE 503.

0970A. Kernel/Dispatcher Task Management Kernel/dispatcher task manager 576 schedules and oversees tasks executing within SPE 503 (PPE 650). SPE 503 supports many types of tasks. A "channel" (a special type of task that controls execution of component assembhes 690 in the prefeπed embodiment) is treated by task manager 576 as one type of task. Tasks are submitted to the task manager 576 for execution. Task manager 576 in turn ensures that the SPE 503/SPU 500 resources necessary to execute the tasks are made avaUable, and then arranges for the SPU microprocessor 520 to execute the task.

0971Any caU to kernel/dispatcher 552 gives the kernel an opportunity to take control of SPE 503 and to change the task or tasks that are currently executing. Thus, in the preferred embodiment kernel/dispatcher task manager 576 may (in conjunction with virtual memory manager 580 and/or memory manager 578) "swap out" of the execution space any or aU of the tasks that are currently active, and "swap in" additional or different tasks.

0972SPE tasking managed by task manager 576 may be either "single tasking" (meaning that only one task may be active at a time) or "multi-tasking" (meaning that multiple tasks may be active at once). SPE 503 may support single tasking or multi¬ tasking in the prefeπed embodiment. For example, "high end" implementations of SPE 503 (e.g., in server devices) should preferably include multi-tasking with "preemptive scheduling." Desktop apphcations may be able to use a simpler SPE 503, although they may still require concurrent execution of several tasks. Set top apphcations may be able to use a relatively simple implementation of SPE 503, supporting execution of only one task at a time. For example, a typical set top implementation of SPU 500 may perform simple metering, budgeting and billing using subsets of VDE methods combined into single "aggregate" load modules to permit the various methods to execute in a single tasking environment. However, an execution environment that supports only single tasking may limit use with more complex control structures. Such single tasking versions of SPE 503 trade flexibility in the number and types of metering and budgeting operations for smaUer run time RAM size requirements. Such implementations of SPE 503 may (depending upon memory limitations) also be limited to metering a single object 300 at a time. Of course, variations or combinations are possible to increase capabihties beyond a simple single tasking environment without incurring the additional cost required to support "fuU multitasking."

0973In the prefeπed embodiment, each task in SPE 503 is represented by a "swap block," which may be considered a "task" in a traditional multitasking architecture. A "swap block" in the preferred embodiment is a bookkeeping mechanism used by task manager 576 to keep track of tasks and subtasks. It corresponds to a chunk of code and associated references that "fits" within the secure execution environment provided by SPU 500. In the preferred embodiment, it contains a list of references to shared data elements (e.g., load modules 1100 and UDEs 1200), private data elements (e.g., method data and local stack), and swapped process "context" information (e.g., the register set for the process when it is not processing). Figure 14C shows an example of a snapshot of SPU RAM 532 storing several examples of "swap blocks" for a number of different tasks/methods such as a "channel" task, a "control" task, an "event" task, a "meter" task, a

0974"budget" task, and a "hilling" task. Depending on the size of SPU RAM 532, "swap blocks" may be swapped out of RAM and stored temporarily on secondary storage 652 until their execution can be continued. Thus, SPE 503 operating in a multi-tasking mode may have one or more tasks "sleeping." In the simplest form, this involves an active task that is currently processing, and another task (e.g., a control task under which the active task may be running) that is "sleeping" and is "swapped out" of active execution space. Kernel dispatcher 522 may swap out tasks at any time. Task manager 576 may use Memory Manager 578 to help it perform this swapping operation. Tasks may be swapped out of the secure execution space by reading appropriate information from RAM and other storage internal to SPU 500, for example, and writing a "swap block" to secondary storage 652. Kernel 552 may swap a task back into the secure execution space by reading the swap block from secondary storage 652 and writing the appropriate information back into SPU RAM 532. Because secondary storage 652 is not secure, SPE 503 must encrypt and cryptographicaUy seal (e.g., using a one-way hash function initiahzed with a secret value known only inside the SPU 500) each swap block before it writes it to secondary storage. The SPE 503 must decrypt and verify the cryptographic seal for each swap block read from secondary storage 652 before the swap block can be returned to the secure execution space for further execution.

0975Loading a "swap block" into SPU memory may require one or more "paging operations" to possibly first save, and then flush, any "dirty pages" (i.e., pages changed by SPE 503) associated with the previously loaded swap blocks, and to load aU required pages for the new swap block context. Kernel/dispatcher 522 preferably manages the "swap blocks" using service interrupt queues 588. These service interrupt queues 588 aUow kernel/dispatcher 552 to track tasks (swap blocks) and their status (running, "swapped out," or "asleep"). The kernel/dispatcher 552 in the preferred embodiment may maintain the foUowing service interrupt queues 588 to help it manage the "swap blocks": RUN queue SWAP queue SLEEP queue.

0976Those tasks that are completely loaded in the execution space and are waiting for and/or using execution cycles from microprocessor 502 are in the RUN queue. Those tasks that are "swapped" out (e.g., because they are waiting for other swappable components to be loaded) are referenced in the SWAP queue.

0977Those tasks that are "asleep" (e.g., because they are "blocked" on some resource other than processor cycles or are not needed at the moment) are referenced in the SLEEP queue. Kernel dispatcher task manager 576 may, for example, transition tasks between the RUN and SWAP queues based upon a "round- robin" scheduling algorithm that selects the next task waiting for service, swaps in any pieces that need to be paged in, and executes the task. Kernel/dispatcher 552 task manager 576 may transition tasks between the SLEEP queue and the "awake" (i.e., RUN or SWAP) queues as needed.

0978When two or more tasks try to write to the same data structure in a multi-tasking environment, a situation exists that may result in "deadly embrace" or "task starvation." A "multi¬ threaded" tasking arrangement may be used to prevent "deadly embrace" or "task starvation" from happening. The prefeπed embodiment kernel dispatcher 552 may support "single threaded" or "multi-threaded" tasking.

0979In single threaded apphcations, the kernel/dispatcher 552 "locks" individual data structures as they are loaded. Once locked, no other SPE 503 task may load them and will "block" waiting for the data structure to become avaUable. Using a single threaded SPE 503 may, as a practical matter, limit the ability of outside vendors to create load modules 1100 since there can be no assurance that they will not cause a "deadly embrace" with other VDE processes about which outside vendors may know little or nothing. Moreover, the context swapping of a partiaUy updated record might destroy the integrity of the system, permit unmetered use, and/or lead to deadlock. In addition, such "locking" imposes a potentiaUy indeterminate delay into a typicaUy time critical process, may limit SPE 503 throughput, and may increase overhead.

0980This issue notwithstanding, there are other significant processing issues related to building single-threaded versions of SPE 503 that may limit its usefulness or capabihties under some circumstances. For example, multiple concurrently executing tasks may not be able to process using the same often-needed data structure in a single-threaded SPE 503. This may effectively limit the number of concurrent tasks to one. Additionally, single-threadedness may eliminate the capabihty of producing accurate summary budgets based on a number of concurrent tasks since multiple concurrent tasks may not be able to effectively share the same summary budget data structure. Single-threadedness may also eliminate the capabihty to support audit processing concurrently with other processing. For example, real-time feed processing might have to be shut down in order to audit budgets and meters associated with the monitoring process. One way to provide a more workable "single-threaded" capability is for kernel/dispatcher 552 to use virtual page handling algorithms to track "dirty pages" as data areas are written to. The "dirty pages" can be swapped in and out with the task swap block as part of local data associated with the swap block. When a task exits, the "dirty pages" can be merged with the current data structure (possibly updated by another task for SPU 500) using a three-way merge algorithm (i.e., merging the original data structure, the current data structure, and the "dirty pages" to form a new current data structure). During the update process, the data structure can be locked as the pages are compared and swapped. Even though this virtual paging solution might be workable for aUowing single threading in some apphcations, the vendor limitations mentioned above may limit the use of such single threaded implementations in some cases to dedicated hardware. Any implementation that supports multiple users (e.g., "smart home" set tops, many desk tops and certain PDA apphcations, etc.) may hit limitations of a single threaded device in certain circumstances.

0981It is preferable when these limitations are unacceptable to use a fuU "multi-threaded" data structure write capabilities. For example, a type of "two-phase commit" processing of the type used by database vendors may be used to aUow data structure sharing between processes. To implement this "two-phase commit" process, each swap block may contain page addresses for additional memory blocks that wiU be used to store changed information. A change page is a local copy of a piece of a data element that has been written by an SPE process. The changed page(s) references associated with a specific data structure are stored locaUy to the swap block in the preferred embodiment.

0982For example, SPE 503 may support two (change pages) per data structure. This limit is easUy alterable by changing the size of the swap block structure and aUowing the update algorithm to process aU of the changed pages. The "commit" process can be invoked when a swap block that references changed pages is about to be discarded. The commit process takes the original data element that was originaUy loaded (e.g., UDEQ), the cuπent data element (e.g., UDE_n) and the changed pages, and merges them to create a new copy of the data element (e.g., UDE -^). Differences can be resolved by the DTD interpreter 590 using a

0983DTD for the data element. The original data element is discarded (e.g., as determined by its DTD use count) if no other swap block references it.

0984B. Kernel Dispatcher Memory Management Memory manager 578 and virtual memory manager 580 in the preferred embodiment manage ROM 532 and RAM 534 memory within SPU 500 in the preferred embodiment. Virtual memory manager 580 provides a fuUy "virtual" memory system to increase the amount of "virtual" RAM avaUable in the SPE secure execution space beyond the amount of physical RAM 534a provided by SPU 500. Memory manager 578 manages the memory in the secure execution space, controlling how it is accessed, aUocated and deaUocated. SPU MMU 540, if present, supports virtual memory manager 580 and memory manager 578 in the prefeπed embodiment. In some "minimal" configurations of SPU 500 there may be no virtual memory capability and aU memory management functions wiU be handled by memory manager 578. Memory management can also be used to help enforce the security provided by SPE 503. In some classes of SPUs 500, for example, the kernel memory manager 578 may use hardware memory management unit (MMU) 540 to provide page level protection within the SPU 500. Such a hardware-based memory management system provides an effective mechanism for protecting VDE component assembhes 690 from compromise by "rogue" load modules.

0985In addition, memory management provided by memory manager 578 operating at least in part based on hardware-based MMU 540 may securely implement and enforce a memory architecture providing multiple protection domains. In such an architecture, memory is divided into a plurahty of domains that are largely isolated from each other and share only specific memory areas under the control of the memory manager 578. An executing process cannot access memory outside its domain and can only communicate with other processes through services provided by and mediated by privUeged kernel dispatcher software 552 within the SPU 500. Such an architecture is more secure if it is enforced at least in part by hardware within MMU 540 that cannot be modified by any software-based process executing within SPU 500.

0986In the prefeπed embodiment, access to services implemented in the ROM 532 and to physical resources such as NVRAM 534b and RTC 528 are mediated by the combination of privUeged kernel/dispatcher software 552 and hardware within MMU 540. ROM 532 and RTC 528 requests are privUeged in order to protect access to critical system component routines (e.g., RTC 528).

0987Memory manager 578 is responsible for aUocating and deaUocating memory; supervising sharing of memory resources between processes; and enforcing memory access/use restriction. The SPE kernel/dispatcher memory manager 578 typicaUy initiaUy aUocates aU memory to kernel 552, and may be configured to permit only process-level access to pages as they are loaded by a specific process. In one example SPE operating system configuration, memory manager 578 aUocates memory using a simplified aUocation mechanism. A list of each memory page accessible in SPE 503 may be represented using a bit map aUocation vector, for example. In a memory block, a group of contiguous memory pages may start at a specific page number. The size of the block is measured by the number of memory pages it spans. Memory aUocation may be recorded by setting/clearing the appropriate bits in the aUocation vector. To assist in memory management functions, a "dope vector" may be prepended to a memory block. The "dope vector" may contain information aUowing memory manager 578 to manage that memory block. In its simplest form, a memory block may be structured as a "dope vector" foUowed by the actual memory area of the block. This "dope vector" may include the block number, support for dynamic paging of data elements, and a marker to detect memory overwrites. Memory manager 578 may track memory blocks by their block number and convert the block number to an address before use. AU accesses to the memory area can be automaticaUy offset by the size of the "dope vector" during conversion from a block memory to a physical address. "Dope vectors" can also be used by virtual memory manager 580 to help manage virtual memory.

0988The ROM 532 memory management task performed by memory manager 578 is relatively simple in the preferred embodiment. AU ROM 532 pages may be flagged as "read only" and as "non-pagable." EEPROM 532B memory management may be slightly more complex since the "burn count" for each

0989EEPROM page may need to be retained. SPU EEPROM 532B may need to be protected from aU uncontroUed writes to conserve the limited writable lifetime of certain types of this memory. Furthermore, EEPROM pages may in some cases not be the same size as memory management address pages.

0990SPU NVRAM 534b is preferably battery backed RAM that has a few access restrictions. Memory manager 578 can ensure control structures that must be located in NVRAM 534b are not relocated during "garbage coUection" processes. As discussed above, memory manager 578 (and MMU 540 if present) may protect NVRAM 534b and RAM 534a at a page level to prevent tampering by other processes.

0991Virtual memory manager 580 provides paging for programs and data between SPU external memory and SPU internal RAM 534a. It is likely that data structures and executable processes will exceed the limits of any SPU 500 internal memory. For example, PERCs 808 and other fundamental control structures may be fairly large, and "bit map meters" may be, or become, very large. This eventuahty may be addressed in two ways:

0992(1) subdividing load modules 1100; and

0993(2) supporting virtual paging. Load modules 1100 can be "subdivided" in that in many instances they can be broken up into separate components only a subset of which must be loaded for execution. Load modules 1100 are the smallest pagable executable element in this example. Such load modules 1100 can be broken up into separate components (e.g., executable code and plural data description blocks), only one of which must be loaded for simple load modules to execute. This structure permits a load module 1100 to initiaUy load only the executable code and to load the data description blocks into the other system pages on a demand basis. Many load modules 1100 that have executable sections that are too large to fit into SPU 500 can be restructured into two or more smaUer independent load modules. Large load modules may be manuaUy "split" into multiple load modules that are "chained" together using explicit load module references.

0994Although "demand paging" can be used to relax some of these restrictions, the preferred embodiment uses virtual paging to manage large data structures and executables. Virtual Memory Manager 580 "swaps" information (e.g., executable code and or data structures) into and out of SPU RAM 534a, and provides other related virtual memory management services to aUow a fuU virtual memory management capabihty. Virtual memory management may be important to aUow limited resource SPU 500 configurations to execute large and or multiple tasks.

0995C. SPE Load Module Execution Manager 568

0996The SPE (HPE) load module execution manager ("LMEM") 568 loads executables into the memory managed by memory manager 578 and executes them. LMEM 568 provides mechanisms for tracking load modules that are currently loaded inside the protected execution environment. LMEM 568 also provides access to basic load modules and code fragments stored within, and thus always avaUable to, SPE 503. LMEM 568 may be caUed, for example, by load modules 1100 that want to execute other load modules.

0997In the prefeπed embodiment, the load module execution manager 568 includes a load module executor ("program loader") 570, one or more internal load modules 572, and hbrary routines 574. Load module executor 570 loads executables into memory (e.g., after receiving a memory aUocation from memory manager

0998578) for execution. Internal load module hbrary 572 may provide a set of commonly used basic load modules 1100 (stored in ROM 532 or NVRAM 534b, for example). Library routines 574 may provide a set of commonly used code fragments/routines (e.g., bootstrap routines) for execution by SPE 503.

0999Library routines 574 may provide a standard set of hbrary functions in ROM 532. A standard list of such hbrary functions along with their entry points and parameters may be used. Load modules 1100 may caU these routines (e.g., using an interrupt reserved for this purpose). Library calls may reduce the size of load modules by moving commonly used code into a central location and permitting a higher degree of code reuse. AU load modules 1100 for use by SPE 503 are preferably referenced by a load module execution manager 568 that maintains and scans a list of avaUable load modules and selects the appropriate load module for execution. If the load module is not present within

1000SPE 503, the task is "slept" and LMEM 568 may request that the load module 1100 be loaded from secondary storage 562. This request may be in the form of an RPC caU to secure database manager 566 to retrieve the load module and associated data structures, and a caU to encrypt/decrypt manager 556 to decrypt the load module before storing it in memory aUocated by memory manager 578. In somewhat more detaU, the preferred embodiment executes a load module 1100 by passing the load module execution manager 568 the name (e.g., VDE ID) of the desired load module 1100. LMEM 568 first searches the list of "in memory" and "built-in" load modules 572. If it cannot find the desired load module 1100 in the list, it requests a copy from the secure database 610 by issuing an RPC request that may be handled by ROS secure database manager 744 shown in Figure 12. Load module execution manager 568 may then request memory manager 578 to allocate a memory page to store the load module 1100. The load module execution manager 568 may copy the load module into that memory page, and queue the page for decryption and security checks by encrypt/decrypt manager 556 and key and tag manager 558. Once the page is decrypted and checked, the load module execution manager 568 checks the validation tag and inserts the load module into the list of paged in modules and returns the page address to the caUer. The caUer may then caU the load module 1100 directly or aUow the load module execution module 570 to make the caU for it.

1001Figure 15a shows a detaUed example of a possible format for a channel header 596 and a channel 594 containing channel detaU records 594(1), 594(2), . . . 594(N). Channel header 596 may include a channel ID field 597(1), a user ID field 597(2), an object ID field 597(3), a field containing a reference or other identification to a "right" (i.e., a coUection of events supported by methods referenced in a PERC 808 and/or "user rights table" 464)

1002597(4), an event queue 597(5), and one or more fields 598 that cross-reference particular event codes with channel detail records ("CDRs"). Channel header 596 may also include a "jump" or reference table 599 that permits addressing of elements within an associated component assembly or assembhes 690. Each CDR

1003594(1), . . . 594(N) coπesponds to a specific event (event code) to which channel 594 may respond. In the preferred embodiment, these CDRs may include exphcitly and/or by reference each method core 1000N (or fragment thereof), load module 1100 and data structure(s), (e.g., URT, UDE 1200 and or MDE 1202) needed to process the corresponding event. In the preferred embodiment, one or more of the CDRs (e.g., 594(1)) may reference a control method and a URT 464 as a data structure.

1004Figure 15b shows an example of program control steps performed by SPE 503 to "open" a channel 594 in the prefeπed embodiment. In the prefeπed embodiment, a channel 594 provides event processing for a particular VDE object 300, a particular authorized user, and a particular "right" (i.e., type of event). These three parameters may be passed to SPE 503. Part of SPE kernel/dispatcher 552 executing within a "channel 0" constructed by low level services 582 during a "bootstrap" routine may respond initiaUy to this "open channel" event by aUocating an avaUable channel supported by the processing resources of SPE 503 (block 1125). This "channel 0" "open channel" task may then issue a series of requests to secure database manager 566 to obtain the "blueprint" for constructing one or more component assembhes 690 to be associated with channel 594 (block 1127). In the prefeπed embodiment, this "blueprint" may comprise a PERC 808 and/or URT 464. In may be obtained by using the "Object, User, Right" parameters passed to the "open channel" routine to "chain" together object registration table 460 records, user/object table 462 records, URT 464 records, and PERC 808 records. This "open channel" task may preferably place calls to key and tag manager 558 to validate and coπelate the tags associated with these various records to ensure that they are authentic and match. The preferred embodiment process then may write appropriate information to channel header 596 (block 1129). Such information may include, for example, User ID, Object ID, and a reference to the "right" that the channel will process. The preferred embodiment process may next use the "blueprint" to access (e.g, the secure database manager 566 and/or from load module execution manager library(ies) 568) the appropriate "control method" that may be used to, in effect, supervise execution of all of the other methods 1000 within the channel 594 (block 1131). The process may next "bind" this control method to the channel (block 1133), which step may include binding information from a URT 464 into the channel as a data structure for the control method. The process may then pass an "initiahzation" event into channel 594 (block 1135). This "initiahzation" event may be created by the channel services manager 562, the process that issued the original caU requesting a service being fulfiUed by the channel being buUt, or the control method just bound to the channel could itself possibly generate an initiahzation event which it would in effect pass to itself.

1005In response to this "initiahzation" event, the control method may construct the channel detaU records 594(1), . . . 594(N) used to handle further events other than the

1006"initiahzation" event. The control method executing "within" the channel may access the various components it needs to construct associated component assembhes 690 based on the "blueprint" accessed at step 1127 (block 1137). Each of these components is bound to the channel 594 (block 1139) by constructing an associated channel detaU record specifying the method core(s) 1000N, load module(s) 1100, and associated data structure(s) (e.g.,

1007UDE(s) 1200 and/or MDE(s) 1202) needed to respond to the event. The number of channel detail records will depend on the number of events that can be serviced by the "right," as specified by the "blueprint" (i.e., URT 464). During this process, the control method will construct "swap blocks" to, in effect, set up aU required tasks and obtain necessary memory allocations from kernel 562. The control method will, as necessary, issue calls to secure database manager 566 to retrieve necessary components from secure database 610, issue calls to encrypt/decrypt manager 556 to decrypt retrieved encrypted information, and issue caUs to key and tag manager 558 to ensure that aU retrieved components are validated. Each of the various component assembhes 690 so constructed are "bound" to the channel through the channel header event code/pointer records 598 and by constructing appropriate swap blocks referenced by channel detaU records

1008594(1), . . . 594(N). When this process is complete, the channel 594 has been completely constructed and is ready to respond to further events. As a last step, the Figure 15b process may, if desired, deaUocate the "initiahzation" event task in order to free up resources.

1009Once a channel 594 has been constructed in this fashion, it will respond to events as they arrive. Channel services manager 562 is responsible for dispatching events to channel 594. Each time a new event arrives (e.g., via an RPC caU), channel services manager 562 examines the event to determine whether a channel already exists that is capable of processing it. If a channel does exist, then the channel services manager 562 passes the event to that channel. To process the event, it may be necessary for task manager 576 to "swap in" certain "swappable blocks" defined by the channel detaU records as active tasks. In this way, executable component assembhes 690 formed during the channel open process shown in Figure 15b are placed into active secure execution space, the particular component assembly that is activated being selected in response to the received event code. The activated task will then perform its desired function in response to the event. To destroy a channel, the various swap blocks defined by the channel detaU records are destroyed, the identification information in the channel header 596 is wiped clean, and the channel is made avaUable for re-aUocation by the "channel 0" "open channel" task.

1010D. SPE Interrupt Handlers 584

1011As shown in Figure 13, kernel dispatcher 552 also provides internal interrupt handlers) 584. These help to manage the resources of SPU 500. SPU 500 preferably executes in either

1012"interrupt" or "polling" mode for aU significant components. In polling mode, kernel/dispatcher 552 may poU each of the sections/circuits within SPU 500 and emulate an interrupt for them. The foUowing interrupts are preferably supported by SPU 500 in the prefeπed embodiment:

1013C "tick" of RTC 528 C interrupt from bus interface 530 C power faU interrupt C watchdog timer interrupt C interrupt from encrypt/decrypt engine 522

1014C memory interrupt (e.g., from MMU 540). When an interrupt occurs, an interrupt controUer within microprocessor 520 may cause the microprocessor to begin executing an appropriate interrupt handler. An interrupt handler is a piece of software/firmware provided by kernel/dispatcher 552 that aUows microprocessor 520 to perform particular functions upon the occurrence of an interrupt. The interrupts may be "vectored" so that different interrupt sources may effectively cause different interrupt handlers to be executed.

1015A "timer tick" interrupt is generated when the real-time

1016RTC 528 "pulses." The timer tick interrupt is processed by a timer tick interrupt handler to calculate internal device date/time and to generate timer events for channel processing.

1017The bus interface unit 530 may generate a series of interrupts. In the prefeπed embodiment, bus interface 530, modeled after a USART, generates interrupts for various conditions (e.g., "receive buffer fuU," "transmitter buffer empty," and "status word change"). Kernel/dispatcher 552 services the transmitter buffer empty interrupt by sending the next character from the transmit queue to the bus interface 530. Kernel/dispatcher interrupt handler 584 may service the received buffer fuU interrupt by reading a character, appending it to the cuπent buffer, and processing the buffer based on the state of the service engine for the bus interface 530. Kernel/dispatcher 552 preferably processes a status word change interrupt and addresses the appropriate send/receive buffers accordingly.

1018SPU 500 generates a power faU interrupt when it detects an imminen power faU condition. This may require immediate action to prevent loss of information. For example, in the preferred embodiment, a power faU interrupt moves aU recently written information (i.e., "dirty pages") into non-volatUe NVRAM 534b, marks aU swap blocks as "swapped out," and sets the appropriate power faU flag to facilitate recovery processing. Kernel dispatcher 552 may then periodicaUy poU the "power faU bit" in a status word untU the data is cleared or the power is removed completely.

1019SPU 500 in the example includes a conventional watchdog timer that generates watchdog timer interrupts on a regular basis. A watchdog timer interrupt handler performs internal device checks to ensure that tampering is not occurring. The internal clocks of the watchdog timer and RTC 528 are compared to ensure SPU 500 is not being paused or probed, and other internal checks on the operation of SPU 500 are made to detect tampering.

1020The encryption/decryption engine 522 generates an interrupt when a block of data has been processed. The kernel interrupt handler 584 adjusts the processing status of the block being encrypted or decrypted, and passes the block to the next stage of processing. The next block scheduled for the encryption service then has its key moved into the encrypt/decrypt engine

1021522, and the next cryptographic process started.

1022A memory management unit 540 interrupt is generated when a task attempts to access memory outside the areas assigned to it. A memory management interrupt handler traps the request, and takes the necessary action (e.g., by initiating a control transfer to memory manager 578 and or virtual memory manager 580). GeneraUy, the task wiU be faUed, a page fault exception will be generated, or appropriate virtual memory page(s) will be paged in. E. Kernel/Dispatcher Low Level Services 582

1023Low level services 582 in the preferred embodiment provide "low level" functions. These functions in the preferred embodiment may include, for example, power-on initialization, device POST, and faUure recovery routines. Low level services

1024582 may also in the preferred embodiment provide (either by themselves or in combination with authentication manager/service communications manager 564) download response-challenge and authentication communication protocols, and may provide for certain low level management of SPU 500 memory devices such as EEPROM and FLASH memory (either alone or in combination with memory manager 578 and/or virtual memory manager 580).

1025F. Kernel/Dispatcher BIU handler 586

1026BIU handler 586 in the preferred embodiment manages the bus interface unit 530 (if present). It may, for example, maintain read and write buffers for the BIU 530, provide BIU startup initiahzation, etc. G. Kernel/Dispatcher DTD Interpreter 590

1027DTD interpreter 590 in the preferred embodiment handles data formatting issues. For example, the DTD interpreter 590 may automaticaUy open data structures such as UDEs 1200 based on formatting instructions contained within DTDs.

1028The SPE kernel/dispatcher 552 discussed above supports aU of the other services provided by SPE 503. Those other services are discussed below.

1029II. SPU Channel Services Manager 562

1030"Channels" are the basic task processing mechanism of SPE 503 (HPE 655) in the preferred embodiment. ROS 602 provides an event-driven interface for "methods." A "channel" aUows component assembhes 690 to service events. A "channel" is a conduit for passing "events" from services supported by SPE 503 (HPE 655) to the various methods and load modules that have been specified to process these events, and also supports the assembly of component assembhes 690 and interaction between component assembhes. In more detaU, "channel" 594 is a data structure maintained by channel manager 593 that "binds" together one or more load modules 1100 and data structures (e.g., UDEs 1200 and/or MDEs 1202) into a component assembly 690. Channel services manager 562 causes load module execution manager 569 to load the component assembly 690 for execution, and may also be responsible for passing events into the channel 594 for response by a component assembly 690. In the preferred embodiment, event processing is handled as a message to the channel service manager 562.

1031Figure 15 is a diagram showing how the prefeπed embodiment channel services manager 562 constructs a

1032"channel" 594, and also shows the relationship between the channel and component assembhes 690. Briefly, the SPE channel manager 562 establishes a "channel" 594 and an associated "channel header" 596. The channel 594 and its header 596 comprise a data structure that "binds" or references elements of one or more component assembhes 690. Thus, the channel 594 is the mechanism in the preferred embodiment that coUects together or assembles the elements shown in Figure HE into a component assembly 690 that may be used for event processing.

1033The channel 594 is set up by the channel services manager 562 in response to the occurrence of an event. Once the channel is created, the channel services manager 562 may issue function calls to load module execution manager 568 based on the channel 594. The load module execution manager 568 loads the load modules 1100 referenced by a channel 594, and requests execution services by the kernel/dispatcher task manager 576.

1034The kernel/dispatcher 552 treats the event processing request as a task, and executes it by executing the code within the load modules 1100 referenced by the channel.

1035The channel services manager 562 may be passed an identification of the event (e.g., the "event code"). The channel services manager 562 parses one or more method cores 1000' that are part of the component assembly(ies) 690 the channel services manager is to assemble. It performs this parsing to determine which method(s) and data structure(s) are invoked by the type of event. Channel manager 562 then issues calls (e.g., to secure database manager 566) to obtain the methods and data structure(s) needed to buUd the component assembly 690. These caUed-for method(s) and data structure(s) (e.g., load modules 1100, UDEs 1200 and/or MDEs 1202) are each decrypted using encrypt/decrypt manager 556 (if necessary), and are then each vahdated using key and tag manager 558. Channel manager 562 constructs any necessary "jump table" references to, in effect, "link" or "bind" the elements into a single cohesive executable so the load module(s) can reference data structures and any other load module(s) in the component assembly. Channel manager 562 may then issue calls to LMEM 568 to load the executable as an active task.

1036Figure 15 shows that a channel 594 may reference another channel. An arbitrary number of channels 594 may be created by channel manager 594 to interact with one another.

1037"Channel header" 596 in the preferred embodiment is (or references) the data structure(s) and associated control program(s) that queues events from channel event sources, processes these events, and releases the appropriate tasks specified in the "channel detaU record" for processing. A "channel detaU record" in the preferred embodiment links an event to a "swap block" (i.e., task) associated with that event. The "swap block" may reference one or more load modules 1100, UDEs 1200 and private data areas required to properly process the event.

1038One swap block and a coπesponding channel detaU item is created for each different event the channel can respond to. In the prefeπed embodiment, Channel Services Manager 562 may support the foUowing (internal) calls to support the creation and maintenance of channels 562:

1039Call Name Source Description

1040"Write Write Writes an event to the channel for response by Event" the channel. The Write Event call thus permit the caUer to insert an event into the event queue associated with the channel. The event will be processed in turn by the channel 594.

1041"Bind Ioctl Binds an item to a channel with the Item" appropriate processing algorithm. The Bind Item caU permits the caUer to bind a VDE item ID to a channel (e.g., to create one or more swap blocks associated with a channel). This call may manipulate the contents of individual swap blocks.

1042"Unbind Ioctl Unbinds an item from a channel with the Item" appropriate processing algorithm. The Unbind Item caU permits the caUer to break the binding of an item to a swap block. This caU may manipulate the contents of individual swap blocks. SPE RPC Manager 550

1043As described in connection with Figure 12, the architecture of ROS 602 is based on remote procedure calls in the preferred embodiment. ROS 602 includes an RPC Manager 732 that passes RPC calls between services each of which present an RPC service interface ("RSI") to the RPC manager. In the prefeπed embodiment, SPE 503 (HPE 655) is also buUt around the same RPC concept. The SPE 503 (HPE 655) may include a number of internal modular service providers each presenting an RSI to an RPC manager 550 internal to the SPE (HPE). These internal service providers may communicate with each other and/or with ROS RPC manager 732 (and thus, with any other service provided by ROS 602 and with external services), using RPC service requests.

1044RPC manager 550 within SPE 503 (HPE 655) is not the same as RPC manager 732 shown in Figure 12, but it performs a similar function within the SPE (HPE): it receives RPC requests and passes them to the RSI presented by the service that is to fulfiU the request. In the prefeπed embodiment, requests are passed between ROS RPC manager 732 and the outside world (i.e., SPE device driver 736) via the SPE (HPE) Kernel/Dispatcher 552. Kernel Dispatcher 552 may be able to service certain RPC requests itself, but in general it passes received requests to RPC manager 550 for routing to the appropriate service internal to the SPE (HPE). In an alternate embodiment, requests may be passed directly between the HPE,

1045SPE, API, Notification interface, and other external services instead of routing them through the ROS RPC manager 732. The decision on which embodiment to use is part of the scalability of the system; some embodiments are more efficient than others under various traffic loads and system configurations. Responses by the services (and additional service requests they may themselves generate) are provided to RPC Manager 550 for routing to other service(s) internal or external to SPE 503 (HPE 655).

1046SPE RPC Manager 550 and its integrated service manager uses two tables to dispatch remote procedure calls: an RPC services table, and an optional RPC dispatch table. The RPC services table describes where requests for specific services are to be routed for processing. In the preferred embodiment, this table is constructed in SPU RAM 534a or NVRAM 534b, and hsts each RPC service "registered" within SPU 500. Each row of the RPC services table contains a service ID, its location and address, and a control byte. In simple implementations, the control byte indicates only that the service is provided internaUy or externaUy. In more complex implementations, the control byte can indicate an instance of the service (e.g., each service may have multiple "instances" in a multi-tasking environment). ROS RPC manager 732 and SPE 503 may have symmetric copies of the RPC services table in the preferred embodiment. If an RPC service is not found in the RPC services table, SPE 503 may either reject it or pass it to ROS RPC manager 732 for service.

1047The SPE RPC manager 550 accepts the request from the RPC service table and processes that request in accordance with the internal priorities associated with the specific service. In SPE 503, the RPC service table is extended by an RPC dispatch table. The prefeπed embodiment RPC dispatch table is organized as a list of Load Module references for each RPC service supported internaUy by SPE 503. Each row in the table contains a load module ID that services the caU, a control byte that indicates whether the caU can be made from an external caUer, and whether the load module needed to service the caU is permanently resident in SPU 500. The RPC dispatch table may be constructed in SPU ROM 532 (or EEPROM) when SPU firmware 508 is loaded into the SPU 500. If the RPC dispatch table is in EEPROM, it flexibly allows for updates to the services without load module location and version control issues.

1048In the prefeπed embodiment, SPE RPC manager 550 first references a service request against the RPC service table to determine the location of the service manager that may service the request. The RPC manager 550 then routes the service request to the appropriate service manager for action. Service requests are handled by the service manager within the SPE 503 using the RPC dispatch table to dispatch the request. Once the RPC manager 550 locates the service reference in the RPC dispatch table, the load module that services the request is caUed and loaded using the load module execution manager 568. The load module execution manager 568 passes control to the requested load module after performing aU required context configuration, or if necessary may first issue a request to load it from the external management files 610. SPU Time Base Manager 554

1049The time base manager 554 supports calls that relate to the real time clock ("RTC") 528. In the preferred embodiment, the time base manager 554 is always loaded and ready to respond to time based requests.

1050The table below lists examples of basic calls that may be supported by the time base manager 554:

1051Call Name Description

1052Independent requests

1053Get Time Returns the time (local, GMT, or ticks).

1054Set time Sets the time in the RTC 528. Access to this command may be restricted to a VDE adrninistrator.

1055Adjust time Changes the time in the RTC 528. Access to this command may be restricted to a VDE administrator.

1056Set Time Set GMT / local time conversion and the Parameter current and aUowable magnitude of user adjustments to RTC 528 time.

1057Channel Services Manager Requests

1058Bind Time Bind timer services to a channel as an event source.

1059Unbind Unbind timer services from a channel as an Time event source. CaU Name Description

1060Set Alarm Sets an alarm notification for a specific time. The user wUl be notified by an alarm event at the time of the alarm. Parameters to this request determine the event, frequency, and requested processing for the alarm.

1061Clear Alarm Cancels a requested alarm notification.

1062SPU Encryption/Decryption Manager 556

1063The Encryption/Decryption Manager 556 supports calls to the various encryption decryption techniques supported by SPE 503/HPE 655. It may be supported by a hardware-based encryption/decryption engine 522 within SPU 500. Those encryption/decryption technologies not supported by SPU encrypt/decrypt engine 522 may be provided by encrypt decrypt manager 556 in software. The primary bulk encryption decryption load modules preferably are loaded at aU times, and the load modules necessary for other algorithms are preferably paged in as needed. Thus, if the primary bulk encryption decryption algorithm is DES, only the DES load modules need be permanently resident in the RAM 534a of SPE 503/HPE 655. The foUowing are examples of RPC calls supported by Encrypt/Decrypt Manager 556 in the preferred embodiment:

1064CaU Name Description

1065PK Encrypt Encrypt a block using a PK (pubhc key) algorithm.

1066PK Decrypt Decrypt a block using a PK algorithm.

1067DES Encrypt a block using DES. Encrypt

1068DES Decrypt a block using DES. Decrypt

1069RC-4 Encrypt a block using the RC-4 (or other bulk Encrypt encryption) algorithm.

1070RC-4 Decrypt a block using the RC-4 (or other bulk Decrypt encryption) algorithm.

1071Initialize Initialize DES instance to be used.

DES

1073Instance

1074Initialize Initialize RC-4 instance to be used.

RC-4

1076Instance

1077Initialize Initialize MD5 instance to be used.

MD5

1079Instance

1080Process MD5 Process MD5 block. Block The caU parameters passed may include the key to be used; mode (encryption or decryption); any needed Initialization Vectors; the desired cryptographic operating (e.g., type of feedback); the identification of the cryptographic instance to be used; and the start address, destination address, and length of the block to be encrypted or decrypted.

1081SPU Key and Tag Manager 558

1082The SPU Key and Tag Manager 558 supports calls for key storage, key and management file tag look up, key convolution, and the generation of random keys, tags, and transaction numbers.

1083The foUowing table shows an example of a list of SPE/HPE key and tag manager service 558 caUs:

1084CaU Name Description

1085Kev Requests

1086Get Kev Retrieve the requested key.

1087Set Kev Set (store) the specified key.

1088Generate Key Generate a key (pair) for a specified algorithm

1089Generate Convoluted Generate a key using a specified convolution a . gori Kev and algorithm parameter block.

1090Get Convolution Return the currently set (default) convolution Algorithm parameters for a specific convolution alεrorithi L

1091<img file="WO9627155A2_D0003.tif" />

1092Keys and tags may be securely generated within SPE 503 (HPE 655) in the prefeπed embodiment. The key generation algorithm is typicaUy specific to each type of encryption supported. The generated keys may be checked for cryptographic weakness before they are used. A request for Key and Tag Manager 558 to generate a key, tag and/or transaction number preferably takes a length as its input parameter. It generates a random number (or other appropriate key value) of the requested length as its output.

1093The key and tag manager 558 may support caUs to retrieve specific keys from the key storage areas in SPU 500 and any keys stored external to the SPU. The basic format of the calls is to request keys by key type and key number. Many of the keys are periodicaUy updated through contact with the VDE administrator, and are kept within SPU 500 in NVRAM 534b or EEPROM because these memories are secure, updatable and non-volatUe.

1094SPE 503/HPE 655 may support both Pubhc Key type keys and Bulk Encryption type keys. The pubhc key (PK) encryption type keys stored by SPU 500 and managed by key and tag manager 558 may include, for example, a device pubhc key, a device private key, a PK certificate, and a pubhc key for the certificate. GeneraUy, pubhc keys and certificates can be stored externaUy in non-secured memory if desired, but the device private key and the pubhc key for the certificate should only be stored internaUy in an SPU 500 EEPROM or NVRAM 534b. Some of the types of bulk encryption keys used by the SPU 500 may include, for example, general-purpose bulk encryption keys, administrative object private header keys, stationary object private header keys, traveling object private header keys, download/initiahzation keys, backup keys, traU keys, and management file keys. As discussed above, preferred embodiment Key and Tag Manager 558 supports requests to adjust or convolute keys to make new keys that are produced in a deterministic way dependent on site and or time, for example. Key convolution is an -Ugorithmic process that acts on a key and some set of input parameter(s) to yield a new key. It can be used, for example, to increase the number of keys avaUable for use without incurring additional key storage space. It may also be used, for example, as a process to "age" keys by incorporating the value of real-time RTC 528 as parameters. It can be used to make keys site specific by incorporating aspects of the site ID as parameters.

1095Key and Tag Manager 558 also provides services relating to tag generation and management. In the prefeπed embodiment, transaction and access tags are preferably stored by

1096SPE 503 (HPE 655) in protected memory (e.g., within the NVRAM 534b of SPU 500). These tags may be generated by key and tag manager 558. They are used to, for example, check access rights to, validate and correlate data elements. For example, they may be used to ensure components of the secured data structures are not tampered with outside of the SPU 500. Key and tag manager 558 may also support a traU transaction tag and a communications transaction tag.

1097SPU Summary Services Manager 560

1098SPE 503 maintains an audit traU in reprogrammable non¬ volatile memory within the SPU 500 and/or in secure database 610. This audit traU may consist of an audit summary of budget activity for financial purposes, and a security summary of SPU use. When a request is made to the SPU, it logs the request as having occuπed and then notes whether the request succeeded or faUed. AU successful requests may be summed and stored by type in the SPU 500. FaUure information, including the elements listed below, may be saved along with details of the faUure:

1099Control Infoπnation Retained in an SPE on Access Failures

1100Object ID

1101User ID

1102Type of faUure

1103Time of faUure

1104This infoπnation may be analyzed to detect cracking attempts or to determine patterns of usage outside expected (and budgeted) norms. The audit traU histories in the SPU 500 may be retained until the audit is reported to the appropriate parties. This wiU aUow both legitimate faUure analysis and attempts to cryptoanalyze the SPU to be noted.

1105Summary services manager 560 may store and maintain this internal summary audit information. This audit information can be used to check for security breaches or other aspects of the operation of SPE 503. The event summaries may be maintained, analyzed and used by SPE 503 (HPE 655) or a VDE administrator to determine and potentiaUy limit abuse of electronic apphance 600. In the preferred embodiment, such parameters may be stored in secure memory (e.g., within the NVRAM 534b of SPU 500).

1106There are two basic structures for which summary services are used in the prefeπed embodiment. One (the "event summary data structure") is VDE administrator specific and keeps track of events. The event summary structure may be maintained and audited during periodic contact with VDE administrators. The other is used by VDE administrators and/or distributors for overaU budget. A VDE administrator may register for event summaries and an overall budget summary at the time an electronic apphance 600 is initialized. The overaU budget summary may be reported to and used by a VDE administrator in determining distribution of consumed budget (for example) in the case of corruption of secure management files 610. Participants that receive appropriate permissions can register their processes (e.g., specific budgets) with summary services manager 560, which may then reserve protected memory space (e.g., vvithin NVRAM 534b) and keep desired use and/or access parameters. Access to and modification of each summary can be controUed by its own access tag.

1107The foUowing table shows an example of a list of PPE summary service manager 560 service calls:

1108CaU Name Description

1109Create summary Create a summary service if the user info has a "ticket" that permits her to request this service.

1110Get value Return the current value of the summary service. The caller must present an appropriate tag (and/or "ticket") to use this request.

1111Set value Set the value of a summary service. Increment Increment the specified summary service(e.g., a scalar meter summary data area). The caller must present an appropriate tag (and/or "ticket") to use this request.

1112Destroy Destroy the specified summary service if the user has a tag and/or "ticket" that permits them to request this service.

1113In the preferred embodiment, the event summary data structure uses a fixed event number to index into a look up table. The look up table contains a value that can be configured as a counter or a counter plus limit. Counter mode may be used by VDE administrators to deteπnine device usage. The limit mode may be used to limit tampering and attempts to misuse the electronic apphance 600. Exceeding a limit will result in SPE 503 (HPE 655) refusing to service user requests until it is reset by a VDE a-hninistrator. Calls to the system wide event summary process may preferably be buUt into aU load modules that process the events that are of interest.

1114The foUowing table shows examples of events that may be separately metered by the prefeπed embodiment event summary data structure: Event Type

1115Successful Initialization completed successfuUy. Events User authentication accepted.

1116Communications established.

1117Channel loads set for specified values.

1118Decryption completed.

1119Key information updated.

1120New budget created or existing budget updated.

1121New billing information generated or existing billing updated.

1122New meter set up or existing meter updated.

1123New PERC created or existing PERC updated.

1124New objects registered.

1125Administrative objects successfully processed.

1126Audit processed successfuUy.

1127AU other events.

1128FaUed Events Initiahzation faUed.

1129Authentication faUed.

1130Communication attempt faUed.

1131Request to load a channel faUed.

1132Validation attempt unsuccessful.

1133Link to subsidiary item faUed coπelation tag match. Authorization attempt faUed.

1134Decryption attempt faUed.

1135AvaUable budget insufficient to complete requested procedure.

1136Audit did not occur.

1137Adr----Lnistrative object did not process coπectly.

1138Other faUed events.

1139Another, "overaU cuπency budget" summary data structure maintained by the preferred embodiment summary services manager 560 aUows registration of VDE electronic apphance 600. The first entry is used for an overaU currency budget consumed value, and is registered by the VDE administrator that first initializes SPE 503 (HPE 655). Certain currency consuming load modules and audit load modules that complete the auditing process for consumed cuπency budget may caU the summary services manager 560 to update the currency consumed value. Special authorized load modules may have access to the overaU cuπency summary, whUe additional summaries can be registered for by individual providers. SPE Authentication Manager/Service Communications Manager 564

1140The Authentication Manager/Service Communications Manager 564 supports calls for user password vahdation and "ticket" generation and vahdation. It may also support secure communications between SPE 503 and an external node or device (e.g., a VDE administrator or distributor). It may support the foUowing examples of authentication-related service requests in the prefeπed embodiment:

1141Call Name Description

1142User Services

1143Create User Creates a new user and stores Name Services Records (NSRs) for use by the Name Services Manager 752.

1144Authenticate Authenticates a user for use of the system. This User request lets the caUer authenticate as a specific user ID. Group membership is also authenticated by this request. The authentication returns a "ticket" for the user.

1145Delete User Deletes a user's NSR and related records.

1146Ticket Services

1147Generate Ticket Generates a "ticket" for use of one or more services.

1148Authenticate Authenticates a "ticket." Ticket Not included in the table above are calls to the secure communications service. The secure communications service provided by manager 564 may provide (e.g., in conjunction with low-level services manager 582 if desired) secure communications based on a pubhc key (or others) chaUenge-response protocol. This protocol is discussed in further detail elsewhere in this document. Tickets identify users with respect to the electronic apphance 600 in the case where the apphance may be used by multiple users. Tickets may be requested by and returned to VDE software apphcations through a ticket-granting protocol (e.g., Kerberos). VDE components may require tickets to be presented in order to authorize particular services.

1149SPE Secure Database Manager 566

1150Secure database manager 566 retrieves, maintains and stores secure database records within secure database 610 on memory external to SPE 503. Many of these secure database files 610 are in encrypted foπn. AU secure information retrieved by secure database manager 566 therefore must be decrypted by encrypt/decrypt manager 556 before use. Secure information (e.g., records of use) produced by SPE 503 (HPE 655) which must be stored external to the secure execution environment are also encrypted by encrypt/decrypt manager 556 before they are stored via secure database manager 566 in a secure database file 610.

1151For each VDE item loaded into SPE 503, Secure Database manager 566 in the preferred embodiment may search a master list for the VDE item ID, and then check the corresponding transaction tag against the one in the item to ensure that the item provided is the current item. Secure Database Manager 566 may maintain list of VDE item ID and transaction tags in a "hash structure" that can be paged into SPE 503 to quickly locate the appropriate VDE item ID. In smaUer systems, a look up table approach may be used. In either case, the list should be structured as a pagable structure that aUows VDE item ID to be located quickly.

1152The "hash based" approach may be used to sort the list into "hash buckets" that may then be accessed to provide more rapid and efficient location of items in the list. In the "hash based" approach, the VDE item IDs are "hashed" through a subset of the full item ID and organized as pages of the "hashed" table. Each "hashed" page may contain the rest of the VDE item ID and current transaction tag for each item associated with that page. The "hash" table page number may be derived from the components of the VDE item ID, such as distribution ID, item ID, site ID, user ID, transaction tag, creator ID, type and/or version. The hashing algorithm (both the algorithm itself and the parameters to be hashed) may be configurable by a VDE administrator on a site by site basis to provide optimum hash page use. An example of a hash page structure appears below:

1153<img file="WO9627155A2_D0004.tif" /> In this example, each hash page may contain all of the VDE item IDs and transaction tags for items that have identical distributor ID, item ID, and user ID fields (site ID will be fixed for a given electronic apphance 600). These four pieces of information may thus be used as hash algorithm parameters.

1154The "hash" pages may themselves be frequently updated, and should carry transaction tags that are checked each time a "hash" page is loaded. The transaction tag may also be updated each time a "hash" page is written out.

1155As an alternative to the hash-based approach, if the number of updatable items is kept small (such as in a dedicated consumer electronic apphance 600), then assigning each updatable item a unique sequential site record number as part of its VDE item ID may aUow a look up table approach to be used. Only a smaU number of bytes of transaction tag are needed per item, and a table transaction tag for aU frequently updatable items can be kept in protected memory such as SPU NVRAM 534b. Random Value Generator Manager 565

1156Random Value Generator Manager 565 may generate random values. If a hardware-based SPU random value generator 542 is present, the Random Value Generator Manager 565 may use it to assist in generating random values.

1157Other SPE RPC Services 592

1158Other authorized RPC services may be included in SPU 500 by having them "register" themselves in the RPC Services Table and adding their entries to the RPC Dispatch Table. For example, one or more component assembhes 690 may be used to provide additional services as an integral part of SPE 503 and its associated operating system. Requests to services not registered in these tables will be passed out of SPE 503 (HPE 655) for external servicing.

1159SPE 503 Performance Considerations

1160Performance of SPE 503 (HPE 655) is a function of: C complexity of the component assembhes used C number of simultaneous component assembly operations

1161C amount of internal SPU memory available C speed of algorithm for block encryption/decryption The complexity of component assembly processes along with the number of simultaneous component assembly processes is perhaps the primary factor in determining performance. These factors combine to determine the amount of code and data and must be resident in SPU 500 at any one time (the minimum device size) and thus the number of device size "chunks" the processes must be broken down into. Segmentation inherently increases run time size over simpler models. Of course, feature limited versions of SPU 500 may be implemented using significantly smaller amounts of RAM 534. "Aggregate" load modules as described above may remove flexibihty in configuring VDE structures and also further limit the abihty of participants to individuaUy update otherwise separated elements, but may result in a smaUer minimum device size. A very simple metering version of SPU 500 can be constructed to operate with minimal device resources.

1162The amount of RAM 534 internal to SPU 500 has more impact on the performance of the SPE 503 than perhaps any other aspect of the SPU. The flexible nature of VDE processes aUows use of a large number of load modules, methods and user data elements. It is impractical to store more than a smaU number of these items in ROM 532 within SPU 500. Most of the code and data structures needed to support a specific VDE process wiU need to be dynamicaUy loaded into the SPU 500 for the specific VDE process when the process is invoked. The operating system within SPU 500 then may page in the necessary VDE items to perform the process. The amount of RAM 534 within SPU 500 wiU directly determine how large any single VDE load module plus its required data can be, as weU as the number of page swaps that will be necessary to run a VDE process. The SPU I/O speed, encryption/decryption speed, and the amount of internal memory 532, 534 will directly affect the number of page swaps required in the device. Insecure external memory may reduce the wait time for swapped pages to be loaded into SPU 500, but will stUl incur substantial encryption/decryption penalty for each page.

1163In order to maintain security, SPE 503 must encrypt and cryptographicaUy seal each block being swapped out to a storage device external to a supporting SPU 500, and must similarly decrypt, verify the cryptographic seal for, and vahdate each block as it is swapped into SPU 500. Thus, the data movement and encryption/decryption overhead for each swap block has a very large impact on SPE performance.

1164The performance of an SPU microprocessor 520 may not significantly impact the performance of the SPE 503 it supports if the processor is not responsible for moving data through the encrypt/decrypt engine 522.

1165VDE Secure Database 610 VDE 100 stores separately dehverable VDE elements in a secure (e.g., encrypted) database 610 distributed to each VDE electronic apphance 610. The database 610 in the prefeπed embodiment may store and/or manage three basic classes of VDE items: VDE objects,

1166VDE process elements, and VDE data structures.

1167The foUowing table lists examples of some of the VDE items stored in or managed by information stored in secure database 610: Class Brief Description

1168Objects Content Objects Provide a container for content.

1169Administrative Provide a container for information Objects used to keep VDE 100 operating.

1170Traveling Objects Provide a container for content and control infoπnation.

1171Smart Objects Provide a container for (user- specified) processes and data.

1172Process Method Cores Provide a mechanism to relate event Elements to control mechanisms and permissions.

1173Load Modules Secure (tamper-resistant) executable

1174("LMs") code.

1175Method Data Independently dehverable data

1176Elements structures used to control/customize

1177("MDEs") methods.

1178Data Permissions Permissions to use objects; Structures Records ("PERCs") "blueprints" to buUd component assembhes.

1179User Data Basic data structure for storing Elements ("UDEs") information used in conjunction with load modules.

1180Administrative Used by VDE node to maintain Data Structures administrative information Each electronic apphance 600 may have an instance of a secure database 610 that securely maintains the VDE items. Figure 16 shows one example of a secure database 610. The secure database 610 shown in this example includes the foUowing VDE-protected items:

1181C one or more PERCs 808;

1182C methods 1000 (including static and dynamic method

1183"cores" 1000, and MDEs 1202); C Static UDEs 1200a and Dynamic UDEs 1200b; and C load modules 1100.

1184Secure database 610 may also include the foUowing additional data structures used and maintained for administrative purposes: C an "object registry" 450 that references an object storage 728 containing one or more VDE objects; C name service records 452; and C configuration records 454 (including site configuration records 456 and user configuration records 458). Secure database 610 in the preferred embodiment does not include VDE objects 300, but rather references VDE objects stored, for example, on file system 687 and/or in a separate object repository 728. Nevertheless, an appropriate "starting point" for understanding VDE-protected information may be a discussion of

1185VDE objects 300.

1186VDE Objects 300

1187VDE 100 provides a media independent container model for encapsulating content. Figure 17 shows an example of a

1188"logical" structure or format 800 for an object 300 provided by the preferred embodiment.

1189The generalized "logical object" structure 800 shown in Figure 17 used by the prefeπed embodiment supports digital content dehvery over any cuπently used media. "Logical object" in the prefeπed embodiment may refer coUectively to: content; computer software and or methods used to manipulate, record, and/or otherwise control use of said content; and permissions, limitations, administrative control information and/or requirements apphcable to said content, and/or said computer software and/or methods. Logical objects may or may not be stored, and may or may not be present in, or accessible to, any given electronic apphance 600. The content portion of a logical object may be organized as information contained in, not contained in, or partiaUy contained in one or more objects.

1190Briefly, the Figure 17 "logical object" structure 800 in the prefeπed embodiment includes a pubhc header 802, private header 804, a "private body" 806 containing one or more methods 1000, permissions record(s) (PERC) 808 (which may include one or more key blocks 810), and one or more data blocks or areas

1191812. These elements may be "packaged" within a "container" 302. This generalized, logical object structure 800 is used in the preferred embodiment for different types of VDE objects 300 categorized by the type and location of their content.

1192The "container" concept is a convenient metaphor used to give a name to the coUection of elements required to make use of content or to perform an administrative-type activity. Container 302 typicaUy includes identifying information, control structures and content (e.g., a property or administrative data). The term

1193"container" is often (e.g., Bento/OpenDoc and OLE) used to describe a coUection of information stored on a computer system's secondary storage system(s) or accessible to a computer system over a communications network on a "server's" secondary storage system. The "container" 302 provided by the preferred embodiment is not so limited or restricted. In VDE 100, there is no requirement that this information is stored together, received at the same time, updated at the same time, used for only a single object, or be owned by the same entity. Rather, in VDE 100 the container concept is extended and generalized to include real-time content and/or online interactive content passed to an electronic apphance over a cable, by broadcast, or communicated by other electronic communication means.

1194Thus, the "complete" VDE container 302 or logical object structure 800 may not exist at the user's location (or any other location, for that matter) at any one time. The "logical object" may exist over a particular period of time (or periods of time), rather than aU at once. This concept includes the notion of a "virtual container" where important container elements may exist either as a plurahty of locations and/or over a sequence of time periods (which may or may not overlap). Of course, VDE

1195100 containers can also be stored with aU required control structures and content together. This represents a continuum: from aU content and control structures present in a single container, to no locaUy accessible content or container specific control structures.

1196Although at least some of the data representing the object is typicaUy encrypted and thus its structure is not discernible, within a PPE 650 the object may be viewed logicaUy as a "container" 302 because its structure and components are automaticaUy and transparently decrypted.

1197A container model merges weU with the event-driven processes and ROS 602 provided by the preferred embodiment. Under this model, content is easUy subdivided into small, easUy manageable pieces, but is stored so that it maintains the structural richness inherent in unencrypted content. An object oriented container model (such as Bento/OpenDoc or OLE) also provides many of the necessary "hooks" for inserting the necessary operating system integration components, and for defining the various content specific methods.

1198In more detaU, the logical object structure 800 provided by the prefeπed embodiment includes a pubhc (or unencrypted) header 802 that identifies the object and may also identify one or more owners of rights in the object and/or one or more distributors of the object. Private (or encrypted) header 804 may include a part or aU of the information in the pubhc header and further, in the prefeπed embodiment, will include additional data for validating and identifying the object 300 when a user attempts to register as a user of the object with a service clearinghouse, VDE administrator, or an SPU 500. Alternatively, information identifying one or more rights owners and/or distributors of the object may be located in encrypted form within encrypted header 804, along with any of said additional validating and identifying data.

1199Each logical object structure 800 may also include a "private body" 806 containing or referencing a set of methods

12001000 (i.e., programs or procedures) that control use and distribution of the object 300. The abihty to optionaUy incorporate different methods 1000 with each object is important to making VDE 100 highly configurable. Methods 1000 perform the basic function of defining what users (including, where appropriate, distributors, chent administrators, etc.), can and cannot do with an object 300. Thus, one object 300 may come with relatively simple methods, such as allowing unlimited viewing within a fixed period of time for a fixed fee (such as the newsstand price of a newspaper for viewing the newspaper for a period of one week after the paper's pubhcation), while other objects may be controUed by much more complicated (e.g., billing and usage limitation) methods.

1201Logical object structure 800 shown in Figure 17 may also include one or more PERCs 808. PERCs 808 govern the use of an object 300, specifying methods or combinations of methods that must be used to access or otherwise use the object or its contents. The permission records 808 for an object may include key block(s) 810, which may store decryption keys for accessing the content of the encrypted content stored within the object 300.

1202The content portion of the object is typicaUy divided into portions caUed data blocks 812. Data blocks 812 may contain any sort of electronic information, such as, "content," including computer programs, images, sound, VDE administrative

1203information, etc. The size and number of data blocks 812 may be selected by the creator of the property. Data blocks 812 need not aU be the same size (size may be influenced by content usage, database format, operating system, security and/or other considerations). Security wUl be enhanced by using at least one key block 810 for each data block 812 in the object, although this is not required. Key blocks 810 may also span portions of a plurahty of data blocks 812 in a consistent or pseudo-random manner. The spanning may provide additional security by applying one or more keys to fragmented or seemingly random pieces of content contained in an object 300, database, or other information entity.

1204Many objects 300 that are distributed by physical media and or by "out of channel" means (e.g., redistributed after receipt by a customer to another customer) might not include key blocks 810 in the same object 300 that is used to transport the content protected by the key blocks. This is because VDE objects may contain data that can be electronicaUy copied outside the confines of a VDE node. If the content is encrypted, the copies wiU also be encrypted and the copier cannot gain access to the content unless she has the appropriate decryption key(s). For objects in which maintaining security is particularly important, the permission records 808 and key blocks 810 will frequently be distributed electronicaUy, using secure communications techniques (discussed below) that are controUed by the VDE nodes of the sender and receiver. As a result, permission records 808 and key blocks 810 wUl frequently, in the preferred embodiment, be stored only on electronic apphances 600 of registered users (and may themselves be dehvered to the user as part of a registration/initialization process). In this instance, permission records 808 and key blocks 810 for each property can be encrypted with a private DES key that is stored only in the secure memory of an SPU 500, making the key blocks unusable on any other user's VDE node. Alternately, the key blocks 810 can be encrypted with the end user's pubhc key, making those key blocks usable only to the SPU 500 that stores the corresponding private key (or other, acceptably secure, encryption security techniques can be employed).

1205In the prefeπed embodiment, the one or more keys used to encrypt each permission record 808 or other management information record wUl be changed every time the record is updated (or after a certain one or more events). In this event, the updated record is re-encrypted with new one or more keys.

1206Alternately, one or more of the keys used to encrypt and decrypt management information may be "time aged" keys that automaticaUy become invalid after a period of time. Combinations of time aged and other event triggered keys may also be desirable; for example keys may change after a certain number of accesses, and/or after a certain duration of time or absolute point in time. The techniques may also be used together for any given key or combination of keys. The preferred embodiment procedure for constructing time aged keys is a one-way convolution algorithm with input parameters including user and site information as weU as a specified portion of the real time value provided by the SPU RTC 528. Other techniques for time aging may also be used, including for example techniques that use only user or site information, absolute points in time, and/or duration of time related to a subset of activities related to using or decrypting VDE secured content or the use of the VDE system.

1207VDE 100 supports many different types of "objects" 300 having the logical object structure 800 shown in Figure 17. Objects may be classified in one sense based on whether the protection information is bound together with the protected information. For example, a container that is bound by its control(s) to a specific VDE node is caUed a "stationary object" (see Figure 18). A container that is not bound by its control information to a specific VDE node but rather carries sufficient control and permissions to permit its use, in whole or in part, at any of several sites is caUed a "Traveling Object" (see Figure 19).

1208Objects may be classified in another sense based on the nature of the information they contain. A container with information content is celled a "Content Object" (see Figure 20). A container that contains transaction information, audit trails, VDE structures, and or other VDE controVadministrative information is called an "Administrative Object" (see Figure 21). Some containers that contain executable code operating under VDE control (as opposed to being VDE control information) are caUed "Smart Objects." Smart Objects support user agents and provide control for their execution at remote sites. There are other categories of objects based upon the location, type and access mechanism associated with their content, that can include combinations of the types mentioned above. Some of these objects supported by VDE 100 are described below. Some or aU of the data blocks 812 shown in Figure 17 may include "embedded" content, administrative, stationary, traveling and/or other objects. 1. Stationary Objects

1209Figure 18 shows an example of a "Stationary Object" structure 850 provided by the preferred embodiment. "Stationary Object" structure 850 is intended to be used only at specific VDE electronic apphance/instaUations that have received exphcit permissions to use one or more portions of the stationary object. Therefore, stationary object structure 850 does not contain a permissions record (PERC) 808; rather, this permissions record is supphed and/or dehvered separately (e.g., at a different time, over a different path, and/or by a different party) to the apphance/instaUation 600. A common PERC 808 may be used with many different stationary objects.

1210As shown in Figure 18, pubhc header 802 is preferably "plaintext" (i.e., unencrypted). Private header 804 is preferably encrypted using at least one of many "private header keys." Private header 804 preferably also includes a copy of identification elements from pubhc header 802, so that if the identification information in the plaintext pubhc header is tampered with, the system can determine precisely what the tamperer attempted to alter. Methods 1000 may be contained in a section caUed the "private body" 806 in the form of object local methods, load modules, and or user data elements. This private body (method) section 806 is preferably encrypted using one or more private body keys contained in the separate permissions record 808. The data blocks 812 contain content (information or administrative) that may be encrypted using one or more content keys also provided in permissions record 808.

12112. Traveling Objects

1212Figure 19 shows an example of a "traveling object" structure 860 provided by the preferred embodiment. Traveling objects are objects that carry with them sufficient information to enable at least some use of at least a portion of their content when they arrive at a VDE node.

1213Traveling object structure 860 may be the same as stationary object structure 850 shown in Figure 18 except that the traveling object structure includes a permissions record (PERC) 808 within private header 804. The inclusion of PERC 808 within traveling object structure 860 permits the traveling object to be used at any VDE electronic apphance/participant 600

1214(in accordance with the methods 1000 and the contained PERC 808). "Traveling" objects are a class of VDE objects 300 that can specificaUy support "out of channel" distribution. Therefore, they include key block(s) 810 and are transportable from one electronic apphance 600 to another. Traveling objects may come with a quite hmited usage related budget so that a user may use, in whole or part, content (such as a computer program, game, or database) and evaluate whether to acquire a hcense or further hcense or purchase object content. Alternatively, traveling object PERCs 808 may contain or reference budget records with, for example:

1215(a) budget(s) reflecting previously purchased rights or credit for future licensing or purchasing and enabling at least one or more types of object content usage, and/or

1216(b) budget(s) that employ (and may debit) avaUable credit(s) stored on and managed by the local VDE node in order to enable object content use, and/or

1217(c) budget(s) reflecting one or more maximum usage criteria before a report to a local VDE node (and, optionaUy, also a report to a clearinghouse) is required and which may be foUowed by a reset allowing further usage, and/or modification of one or more of the original one or more budget(s).

1218As with standard VDE objects 300, a user may be required to contact a clearinghouse service to acquire additional budgets if the user wishes to continue to use the traveling object after the exhaustion of an avaUable budget(s) or if the traveling object (or a copy thereof) is moved to a different electronic apphance and the new apphance does not have a avaUable credit budget(s) that corresponds to the requirements stipulated by permissions record 808.

1219For example, a traveling object PERC 808 may include a reference to a required budget VDE 1200 or budget options that may be found and or are expected to be avaUable. For example, the budget VDE may reference a consumer's VISA, MC, AMEX, or other "generic" budget that may be object independent and may be apphed towards the use of a certain or classes of traveling object content (for example any movie object from a class of traveling objects that might be Blockbuster Video rentals). The budget VDE itself may stipulate one or more classes of objects it may be used with, while an object may specificaUy reference a certain one or more generic budgets. Under such circumstances, VDE providers wiU typicaUy make information avaUable in such a manner as to aUow correct referencing and to enable billing handling and resulting payments.

1220Traveling objects can be used at a receiving VDE node electronic apphance 600 so long as either the apphance carries the coπect budget or budget type (e.g. sufficient credit avaUable from a clearinghouse such as a VISA budget) either in general or for specific one or more users or user classes, or so long as the traveling object itself carries with it sufficient budget aUowance or an appropriate authorization (e.g., a stipulation that the traveling object may be used on certain one or more installations or instaUation classes or users or user classes where classes coπespond to a specific subset of instaUations or users who are represented by a predefined class identifiers stored in a secure database 610). After receiving a traveling object, if the user (and/or instaUation) doesn't have the appropriate budget(s) and/or authorizations, then the user could be informed by the electronic apphance 600 (using infoπnation stored in the traveling object) as to which one or more parties the user could contact. The party or parties might constitute a list of alternative clearinghouse providers for the traveling object from which the user selects his desired contact).

1221As mentioned above, traveling objects enable objects 300 to be distributed "Out-Of-Channel;" that is, the object may be distributed by an unauthorized or not explicitly authorized individual to another individual. "Out of channel" includes paths of distribution that aUow, for example, a user to directly redistribute an object to another individual. For example, an object provider might aUow users to redistribute copies of an object to their friends and associates (for example by physical dehvery of storage media or by dehvery over a computer network) such that if a friend or associate satisfies any certain criteria required for use of said object, he may do so.

1222For example, if a software program was distributed as a traveling object, a user of the program who wished to supply it or a usable copy of it to a friend would normaUy be free to do so. Traveling Objects have great potential commercial significance, since useful content could be primarily distributed by users and through buUetin boards, which would require little or no distribution overhead apart from registration with the "original" content provider and or clearinghouse.

1223The "out of channel" distribution may also aUow the provider to receive payment for usage and or elsewise maintain at least a degree of control over the redistributed object. Such certain criteria might involve, for example, the registered presence at a user's VDE node of an authorized third party financial relationship, such as a credit card, along with sufficient avaUable credit for said usage.

1224Thus, if the user had a VDE node, the user might be able to use the traveling object if he had an appropriate, avaUable budget avaUable on bis VDE node (and if necessary, aUocated to him), and or if he or his VDE node belonged to a speciaUy authorized group of users or instaUations and or if the traveling object carried its own budget(s).

1225Since the content of the traveling object is encrypted, it can be used only under authorized circumstances unless the traveling object private header key used with the object is broken — a potentiaUy easier task with a traveling object as compared to, for example, permissions and/or budget information since many objects may share the same key, giving a cryptoanalyst both more information in cyphertext to analyze and a greater incentive to perform cryptoanalysis.

1226In the case of a "traveling object," content owners may distribute information with some or all of the key blocks 810 included in the object 300 in which the content is encapsulated. Putting keys in distributed objects 300 increases the exposure to attempts to defeat security mechanisms by breaking or cryptoanalyzing the encryption algorithm with which the private header is protected (e.g., by determining the key for the header's encryption). This breaking of security would normaUy require considerable skiU and time, but if broken, the algorithm and key could be published so as to aUow large numbers of individuals who possess objects that are protected with the same key(s) and algorithm(s) to illegally use protected information. As a result, placing keys in distributed objects 300 may be limited to content that is either "time sensitive" (has reduced value after the passage of a certain period of time), or which is somewhat limited in value, or where the commercial value of placing keys in objects (for example convenience to end-users, lower cost of eliminating the telecommunication or other means for dehvering keys and/or permissions information and/or the abihty to supporting objects going "out-of-channel") exceeds the cost of vulnerability to sophisticated hackers. As mentioned elsewhere, the security of keys may be improved by employing convolution techniques to avoid storing "true" keys in ή traveling object, although in most cases using a shared secret provided to most or aU VDE nodes by a VDE administrator as an input rather than site ID and/or time in order to aUow objects to remain independent of these values.

1227As shown in Figure 19 and discussed above, a traveling object contains a permissions record 808 that preferably provides at least some budget (one, the other, or both, in a general case). Permission records 808 can, as discussed above, contain a key block(s) 810 storing important key information. PERC 808 may also contain or refer to budgets containing potentiaUy valuable quantities/values. Such budgets may be stored within a traveling object itself, or they may be dehvered separately and protected by highly secure communications keys and administrative object keys and management database techniques. The methods 1000 contained by a traveling object wiU typicaUy include an instaUation procedure for "self registering" the object using the permission records 808 in the object (e.g., a REGISTER method). This may be especiaUy useful for objects that have time limited value, objects (or properties) for which the end user is either not charged or is charged only a nominal fee (e.g., objects for which advertisers and/or information publishers are charged based on the number of end users who actuaUy access published information), and objects that require widely avaUable budgets and may particularly benefit from out-of-channel distribution (e.g., credit card derived budgets for objects containing properties such as movies, software programs, games, etc.). Such traveling objects may be supphed with or without contained budget UDEs.

1228One use of traveling objects is the publishing of software, where the contained permission record(s) may aUow potential customers to use the software in a demonstration mode, and possibly to use the fuU program features for a hmited time before having to pay a hcense fee, or before having to pay more than an initial trial fee. For example, using a time based billing method and budget records with a smaU pre-instaUed time budget to aUow fuU use of the program for a short period of time. Various control methods may be used to avoid misuse of object contents. For example, by setting the minimum registration interval for the traveling object to an appropriately large period of time (e.g., a month, or six months or a year), users are prevented from re-using the budget records in the same traveling object.

1229Another method for controlling the use of traveling objects is to include time-aged keys in the permission records that are incorporated in the traveling object. This is useful generaUy for traveling objects to ensure that they wiU not be used beyond a certain date without re-registration, and is particularly useful for traveling objects that are electronicaUy distributed by broadcast, network, or telecommunications (including both one and two way cable), since the date and time of dehvery of such traveling objects aging keys can be set to accurately correspond to the time the user came into possession of the object.

1230Traveling objects can also be used to facilitate "moving" an object from one electronic apphance 600 to another. A user could move a traveling object, with its incorporated one or more permission records 808 from a desktop computer, for example, to his notebook computer. A travehng object might register its user within itself and thereafter only be useable by that one user. A traveling object might maintain separate budget information, one for the basic distribution budget record, and another for the "active" distribution budget record of the registered user. In this way, the object could be copied and passed to another potential user, and then could be a portable object for that user.

1231Travehng objects can come in a container which contains other objects. For example, a travehng object container can include one or more content objects and one or more administrative objects for registering the content object(s) in an end user's object registry and/or for providing mechanisms for enforcing permissions and or other security functions. Contained administrative object(s) may be used to instaU necessary permission records and/or budget information in the end user's electronic apphance.

1232Content Objects Figure 20 shows an example of a VDE content object structure 880. GeneraUy, content objects 880 include or provide information content. This "content" may be any sort of electronic information. For example, content may include: computer software, movies, books, music, information databases, multimedia information, virtual reality information, machine instructions, computer data files, communications messages and/or signals, and other information, at least a portion of which is used and/or manipulated by one or more electronic apphances. VDE 100 can also be configured for authenticating, controlling, and/or auditing electronic commercial transactions and communications such as inter-bank transactions, electronic purchasing communications, and the transmission of, auditing of, and secure commercial archiving of, electronicaUy signed contracts and other legal documents; the information used for these transactions may also be termed "content." As mentioned above, the content need not be physicaUy stored within the object container but may instead be provided separately at a different time (e.g., a real time feed over a cable).

1233Content object structure 880 in the particular example shown in Figure 20 is a type of stationary object because it does not include a PERC 808. In this example, content object structure 880 includes, as at least part of its content 812, at least one embedded content object 882 as shown in Figure 5A. Content object structure 880 may also include an administrative object 870. Thus, objects provided by the preferred embodiment may include one or more "embedded" objects.

1234Administrative Objects

1235Figure 21 shows an example of an administrative object structure 870 provided by the prefeπed embodiment. An "administrative object" generaUy contains permissions, administrative control information, computer software and/or methods associated with the operation of VDE 100.

1236Administrative objects may also or alternatively contain records of use, and/or other information used in, or related to, the operation of VDE 100. An adniinistrative object may be distinguished from a content object by the absence of VDE protected "content" for release to an end user for example. Since objects may contain other objects, it is possible for a single object to contain one or more content containing objects and one or more administrative objects. Administrative objects may be used to transmit information between electronic apphances for update, usage reporting, billing and/or control purposes. They contain information that helps to administer VDE 100 and keep it operating properly. Administrative objects generaUy are sent between two VDE nodes, for example, a VDE clearinghouse service, distributor, or chent administrator and an end user's electronic apphance 600.

1237Administrative object structure 870 in this example includes a pubhc header 802, private header 804 (including a "PERC" 808) and a "private body" 806 containing methods 1000. Administrative object structure 870 in this particular example shown in Figure 20 is a type of travehng object because it contains a PERC 808, but the administrative object could exclude the PERC 808 and be a stationary object. Rather than storing information content, administrative object structure 870 stores ^* "administrative information content" 872. Administrative information content 872 may, for example, comprise a number of records 872a, 872b, . . . 872n each coπesponding to a different

1238"event." Each record 872a, 872b, . . . 872n may include an "event" field 874, and may optionaUy include a parameter field 876 and or a data field 878. These administrative content records 872 may be used by VDE 100 to define events that may be processed during the course of transactions, e.g., an event designed to add a record to a secure database might include parameters 896 indicating how and where the record should be stored and data field 878 containing the record to be added. In another example, a coUection of events may describe a financial transaction between the creator(s) of an administrative object and the recipient(s), such as a purchase, a purchase order, or an invoice. Each event record 872 may be a set of instructions to be executed by the end user's electronic apphance 600 to make an addition or modification to the end user's secure database 610, for example. Events can perform many basic management functions, for example: add an object to the object registry, including providing the associated user/group record(s), rights records, permission record and/or method records; delete audit records (by "rolling up" the audit traU information into, for example, a more condensed, e.g. summary form, or by actual deletion); add or update permissions records 808 for previously registered objects; add or update budget records; add or update user rights records; and add or update load modules.

1239In the prefeπed embodiment, an administrative object may be sent, for example, by a distributor, chent administrator, or, perhaps, a clearinghouse or other financial service provider, to an end user, or, alternatively, for example, by an object creator to a distributor or service clearinghouse. Administrative objects, for example, may increase or otherwise adjust budgets and/or permissions of the receiving VDE node to which the administrative object is being sent. Similarly, administrative objects containing audit information in the data area 878 of an event record 872 can be sent from end users to distributors, and/or clearinghouses and/or chent administrators, who might themselves further transmit to object creators or to other participants in the object's chain of handhng.

1240Methods

1241Methods 1000 in the preferred embodiment support many of the operations that a user encounters in using objects and communicating with a distributor. They may also specify what method fields are displayable to a user (e.g., use events, user request events, user response events, and user display events).

1242AdditionaUy, if distribution capabihties are supported in the method, then the method may support distribution activities, distributor communications with a user about a method, method modification, what method fields are displayable to a distributor, and any distribution database checks and record keeping (e.g., distribution events, distributor request events, and distributor response events). Given the generality of the existing method structure, and the diverse array of possibilities for assembling methods, a generalized structure may be used for establishing relationships between methods. Since methods 1000 may be independent of an object that requires them during any given session, it is not possible to define the relationships within the methods themselves. "Control methods" are used in the preferred embodiment to define relationships between methods. Control methods may be object specific, and may accommodate an individual object's requirements during each session.

1243A control method of an object establishes relationships between other methods. These relationships are parameterized with exphcit method identifiers when a record set reflecting desired method options for each required method is constructed during a registration process.

1244An "aggregate method" in the preferred embodiment represents a coUection of methods that may be treated as a single unit. A coUection of methods that are related to a specific property, for example, may be stored in an aggregate method. This type of aggregation is useful from an implementation point of view because it may reduce bookkeeping overhead and may improve overaU database efficiency. In other cases, methods may be aggregated because they are logicaUy coupled. For example, two budgets may be linked together because one of the budgets represents an overaU limitation, and a second budget represents the current limitation avaUable for use. This would arise if, for example, a large budget is released in smaU amounts over time.

1245For example, an aggregate method that includes meter, hilling and budget processes can be used instead of three separate methods. Such an aggregate method may reference a single "load module" 1100 that performs aU of the functions of the three separate load modules and use only one user data element that contains meter, billing and budget data. Using an aggregate method instead of three separate methods may minimize overaU memory requirements, database searches, decryptions, and the number of user data element writes back to a secure database 610. The disadvantage of using an aggregate method instead of three separate methods can be a loss of some flexibihty on the part of a provider and user in that various functions may no longer be independently replaceable. Figure 16 shows methods 1000 as being part of secure database 610.

1246A "method" 1000 provided by the preferred embodiment is a coUection of basic instructions and information related to the basic instructions, that provides context, data, requirements and or relationships for use in performing, and/or preparing to perform, the basic instructions in relation to the operation of one or more electronic apphances 600. As shown in Figure 16, methods 1000 in the preferred embodiment are represented in secure database 610 by:

1247C method "cores" 1000N; C Method Data Elements (MDEs) 1202; C User Data Elements (UDEs) 1200; and C Data Description Elements (DTDs).

1248Method "core" 1000N in the prefeπed embodiment may contain or reference one or more data elements such as MDEs 1202 and UDEs 1200. In the prefeπed embodiment, MDEs 1202 and UDEs 1200 may have the same general characteristics, the main difference between these two types of data elements being that a UDE is preferably tied to a particular method as weU as a particular user or group of users, whereas an MDE may be tied to a particular method but may be user independent. These MDE and UDE data structures 1200, 1202 are used in the preferred embodiment to provide input data to methods 1000, to receive data outputted by methods, or both. MDEs 1202 and UDEs 1200 may be dehvered independently of method cores 1000N that reference them, or the data structures may be dehvered as part of the method cores. For example, the method core 1000N in the preferred embodiment may contain one or more MDEs 1202 and/or UDEs 1200 (or portions thereof). Method core 1000N may, alternately or in addition, reference one or more MDE and/or UDE data structures that are dehvered independently of method core(s) that reference them.

1249Method cores 1000N in the prefeπed embodiment also reference one or more "load modules" 1100. Load modules 1100 in the prefeπed embodiment comprise executable code, and may also include or reference one or more data structures called "data descriptor" ("DTD") information. This "data descriptor" information may, for example, provide data input information to the DTD interpreter 590. DTDs may enable load modules 1100 to access (e.g., read from and/or write to) the MDE and/or UDE data elements 1202, 1200.

1250Method cores 1000' may also reference one or more DTD and/or MDE data structures that contain a textual description of their operations suitable for inclusion as part of an electronic contract. The references to the DTD and MDE data structures may occur in the private header of the method core 1000', or may be specified as part of the event table described below.

1251Figure 22 shows an example of a format for a method core 1000N provided by the prefeπed embodiment. A method core 1000N in the preferred embodiment contains a method event table 1006 and a method local data area 1008. Method event table 1006 lists "events." These "events" each reference "load modules"

12521100 and/or PERCs 808 that control processing of an event. Associated with each event in the list is any static data necessary to parameterize the load module 1000 or permissions record 808, and reference(s) into method user data area 1008 that are needed to support that event. The data that parameterizes the load module 1100 can be thought of, in part, as a specific function caU to the load module, and the data elements coπesponding to it may be thought of as the input and/or output data for that specific function caU.

1253Method cores 1000N can be specific to a single user, or they may be shared across a number of users (e.g., depending upon the uniqueness of the method core and or the specific user data element). SpecificaUy, each user/group may have its own UDE 1200 and use a shared method core 1000N. This structure aUows for lower database overhead than when associating an entire method core 1000N with a user/group. To enable a user to use a method, the user may be sent a method core 1000N specifying a UDE 1200. If that method core 1000N already exists in the site's secure database 610, only the UDE 1200 may need to be added. Alternately, the method may create any required UDE 1200 at registration time.

1254The Figure 22 example of a format for a method core 1000N provided by the prefeπed embodiment includes a pubhc (unencrypted) header 802, a private (encrypted) header 804, method event table 1006, and a method local data area 1008. <img file="WO9627155A2_D0005.tif" />

1255An example of a possible field layout for method core 1000N pubhc header 802 is shown in the foUowing table:

1256Field Type Description

1257Method ID Creator ID Site ID of creator of this method.

1258Distributor ID Distributor of this method (e.g., last change).

1259Type ID Constant, indicates method "tvpe."

1260Method ID Unique sequence number for this method.

1261Version ID Version number of this method.

1262Other Class ID ED to support different method classification "classes." information

1263Type ID ID to support method type compatible searching.

1264Descriptive Description(s) Textual description* s ) of the Information method.

1265Event Summary Summary of event classes (e.g., USE) that this method supports.

1266An example of a possible field layout for private header 804 is shown below: W l / »» %0 g \ mm XJ

1267Field Type Description

1268Copy of Pubhc Header 802 Method ID Method ID from Pubhc Header and "Other Classification Information"

1269Descriptive # of Events # of events supported in this Information method.

1270Access and Access tag Tags used to determine if this Reference Tags method is the correct method

1271Vahdation tag under management by the SPU; ensure that the method core 1000

1272Coπelation tag is used only under appropriate circumstances.

1273Data Structure Reference Optional Reference to DTD(s) and/or MDE(s)

1274Check Value Check value for Private Header and method event table.

1275Check Value for Pubhc Header Check Value for Pubhc Header

1276Referring once again to Figure 22, method event table 1006 may in the prefeπed embodiment include from 1 to N method event records 1012. Each of these method event records 1012 coπesponds to a different event the method 1000 represented by method core 1000N may respond to. Methods 1000 in the prefeπed embodiment may have completely different behavior depending upon the event they respond to. For example, an AUDIT method may store information in an audit traU UDE 1200 in response to an event corresponding to a user's use of an object or other resource. This same AUDIT method may report the stored audit traU to a VDE administrator or other participant in response to an administrative event such as, for example, a timer expiring within a VDE node or a request from another VDE participant to report the audit traU. In the preferred embodiment, each of these different events may be represented by an "event code." This "event code" may be passed as a parameter to a method when the method is called, and used to

1277"look up" the appropriate method event record 1012 within method event table 1006. The selected method event record 1012, in turn, specifies the appropriate information (e.g., load module(s) 1100, data element UDE(s) and MDE(s) 1200, 1202, and/or PERC(s) 808) used to construct a component assembly 690 for execution in response to the event that has occurred.

1278Thus, in the prefeπed embodiment, each method event record 1012 may include an event field 1014, a LM/PERC reference field 1016, and any number of data reference fields

12791018. Event fields 1014 in the prefeπed embodiment may contain a "event code" or other information identifying the corresponding event. The LM/PERC reference field 1016 may provide a reference into the secure database 610 (or other "pointer" information) identifying a load module 1100 and/or a PERC 808 providing (or referencing) executable code to be loaded and executed to perform the method in response to the event. Data reference fields 1018 may include information referencing a UDE 1200 or a MDE 1202. These data structures may be contained in the method local data area 1008 of the method core 1000N, or they may be stored within the secure database 610 as independent dehverables.

1280The foUowing table is an example of a possible more detaUed field layout for a method event record 1012:

1281Field Type Description

1282Event Field 1014 Identifies corresponding event.

1283Access tag Secret tag to grant access to this row of the method event record.

1284LM/PERC DB ID or offset/size Database reference (or local pointer). Reference Field 1016 Coπelation tag Coπelation tag to assert when referencing this element. Field Type Description

1285# of Data Element Reference Fields Count of data reference fields in the method event record.

1286Data UDE ID or Database 610 reference (or local Reference offset/size pointer). Field 1

1287Coπelation tag Coπelation tag to assert when referencing this element.

1288!

1289Data UDE ID or Database 610 reference (or local Reference offset/size pointer). Field n

1290Coπelation tag Coπelation tag to assert when referencing this element.

1291Load Modules

1292Figure 23 is an example of a load module 1100 provided by the prefeπed embodiment. In general, load modules 1100 represent a coUection of basic functions that are used for control operations.

1293Load module 1100 contains code and static data (that is functionaUy the equivalent of code), and is used to perform the basic operations of VDE 100. Load modules 1100 wiU generaUy be shared by aU the control structures for aU objects in the system, though proprietary load modules are also permitted. Load modules 1100 may be passed between VDE participants in administrative object structures 870, and are usuaUy stored in secure database 610. They are always encrypted and authenticated in both of these cases. When a method core 1000N references a load module 1100, a load module is loaded into the SPE 503, decrypted, and then either passed to the electronic apphance microprocessor for executing in an HPE 655 (if that is where it executes), or kept in the SPE (if that is where it executes). If no SPE 503 is present, the load module may be decrypted by the HPE 655 prior to its execution.

1294Load module creation by parties is preferably controUed by a certification process or a ring based SPU architecture. Thus, the process of creating new load modules 1100 is itself a controUed process, as is the process of replacing, updating or deleting load modules already stored in a secured database 610.

1295A load module 1100 is able to perform its function only when executed in the protected environment of an SPE 503 or an

1296HPE 655 because only then can it gain access to the protected elements (e.g., UDEs 1200, other load modules 1100) on which it operates. Initiation of load module execution in this environment is strictly controUed by a combination of access tags, vahdation tags, encryption keys, digital signatures and/or correlation tags. Thus, a load module 1100 may only be referenced if the caUer knows its ID and asserts the shared secret correlation tag specific to that load module. The decrypting SPU may match the identification token and local access tag of a load module after decryption. These techniques make the physical replacement of any load module 1100 detectable at the next physical access of the load module. Furthermore, load modules 1100 may be made

1297"read only" in the prefeπed embodiment. The read-only nature of load modules 1100 prevents the write-back of load modules that have been tampered with in non-secure space.

1298Load modules are not necessarily directly governed by

1299PERCs 808 that control them, nor must they contain any time/date information or expiration dates. The only control consideration in the prefeπed embodiment is that one or more methods 1000 reference them using a coπelation tag (the value of a protected object created by the load module's owner, distributed to authorized parties for inclusion in their methods, and to which access and use is controUed by one or more PERCs 808). If a method core 1000N references a load module 1100 and asserts the proper coπelation tag (and the load module satisfies the internal tamper checks for the SPE 503), then that load module can be loaded and executed, or it can be acquired from, shipped to, updated, or deleted by, other systems.

1300As shown in Figure 23, load modules 1100 in the preferred embodiment may be constructed of a pubhc (unencrypted) header 802, a private (encrypted) header 804, a private body 1106 containing the encrypted executable code, and one or more data description elements ("DTDs") 1108. The DTDs 1108 may be stored within a load module 1100, or they may be references to static data elements stored in secure database 610.

1301The foUowing is an example of a possible field layout for load module pubhc header 802:

1302Field Type Description

1303LM ID VDE ID of Load Module.

1304Creator ID Site ID of creator of this load module.

1305Type ID Constant indicates load module type. Field Type Description

1306LM ID Unique sequence number for this load module, which uniquely identifies the load module in a sequence of load modules created by an authorized VDE participant.

1307Version ID Version number of this load module.

1308Other Class ID ID to support different load module classification classes. information

1309Type ID ID to support method type compatible searching.

1310Descriptive Description Textual description of the load module. Information

1311Execution space Value that describes what execution code space (e.g., SPE or HPE) this load module.

1312Many load modules 1100 contain code that executes in an SPE 503. Some load modules 1100 contain code that executes in an HPE 655. This aUows methods 1000 to execute in whichever environment is appropriate. For example, an INFORMATION method 1000 can be buUt to execute only in SPE 503 secure space for government classes of security, or in an HPE 655 for commercial apphcations. As described above, the load module pubhc header 802 may contain an "execution space code" field that indicates where the load module 1100 needs to execute. This functionahty also allows for different SPE instruction sets as weU as different user platforms, and aUows methods to be constructed without dependencies on the underlying load module instruction set.

1313Load modules 1100 operate on three major data areas: the stack, load module parameters, and data structures. The stack and execution memory size required to execute the load module 1100 are preferably described in private header 804, as are the data descriptions from the stack image on load module caU, return, and any return data areas. The stack and dynamic areas are described using the same DTD mechanism. The foUowing is an example of a possible layout for a load module private header 1104:

1314Field Type Description

1315Copy of some or all of information f-cjox-Object ID from Pubhc Header. pubhc header 802

1316Other Check Value Check Value for Pubhc Header. classification information

1317Descriptive LM Size Size of executable code block. Information

1318LM Exec Size Executable code size for the load modul

1319LM Exec Stack Stack size required for the load module

1320Execution space c d-Code that describes the execution spac load module.

1321Access and Acceβe tag Tags used to determine if the load mod reference tags correct LM requested by the SPE.

1322Vahdation tag

1323Correlation tag Tag used to determine if the caUer of th the right to execute this LM.

1324Digital Signature Used to determine if the LM executable is intact and was created by a trusted s with a correct certificate for creating L

1325Data record DTD count Number of DTDs that foUow the code bl descriptor information DTD 1 reference If locaUy defined, the physical size and bytes of the first DTD defined for this L

1326If publicly referenced DTD, this is the and the correlation tag to permit acceββ record. DTD N reference If locaUy defined, the physical size and bytes of the Nth DTD defined for this L

1327If pubhcly referenced DTD, this is the and the coπelation tag to permit access record.

1328Check Value Check Value for entire LM.

1329Each load module 1100 also may use DTD 1108 information to provide the information necessary to support buUding methods from a load module. This DTD information contains the definition expressed in a language such as SGML for the names and data types of aU of the method data fields that the load module supports, and the acceptable ranges of values that can be placed in the fields. Other DTDs may describe the function of the load module 1100 in English for inclusion in an electronic contract, for example.

1330The next section of load module 1100 is an encrypted executable body 1106 that contains one or more blocks of encrypted code. Load modules 1100 are preferably coded in the "native" instruction set of their execution environment for efficiency and compactness. SPU 500 and platform providers may provide versions of the standard load modules 1100 in order to make their products cooperate with the content in distribution mechanisms contemplated by VDE 100. The preferred embodiment creates and uses native mode load modules 1100 in heu of an interpreted or "p-code" solution to optimize the performance of a hmited resource SPU. However, when sufficient SPE (or HPE) resources exist and/or platforms have sufficient resources, these other implementation approaches may improve the cross platform utihty of load module code.

1331The foUowing is an example of a field layout for a load module DTD 1108:

1332Field Type Description

1333DTD ID Uses Object ID from Private Header.

1334Creator ID Site ID of creator of this DTD.

1335Type ID Constant.

1336DTD ID Unique sequence number for this DTD.

1337Version ID Version number of this DTD.

1338Descriptive DTD Size Size of DTD block. Information

1339Access and Access tag Tags used to determine if the DTD is the reference tags DTD requested by the SPE.

1340Vahdation tag

1341Correlation tag Tag used to determine if the caller of this the right to use the DTD.

1342DTD Body DTD Data Defix lition 1

1343DTD Data Defix iition 2

13441

1345DTD Data Defix lition N

1346Check Value Check Value for entire DTD record.

1347Some examples of how load modules 1100 may use DTDs 1108 include: C Increment data element (defined by name in DTD3) value in data area DTD4 by value in DTD1

1348C Set data element (defined by name in DTD3) value in data area DTD4 to value in DTD3

1349C Compute atomic element from event in DTD1 from table in DTD3 and return in DTD2

1350C Compute atomic element from event in DTD1 from equation in DTD3 and return in DTD2

1351C Create load module from load module creation template referenced in DTD3

1352C Modify load module in DTD3 using content in DTD4

1353C Destroy load module named in DTD3

1354Commonly used load modules 1100 may be buUt into a

1355SPU 500 as space permits. VDE processes that use buUt-in load modules 1100 will have significantly better performance than processes that have to find, load and decrypt external load modules. The most useful load modules 1100 to buUd into a SPU might include sealer meters, fixed price billing, budgets and load modules for aggregate methods that perform these three processes. User Data Elements (UDEs) 1200 and Method Data Elements (MDEs) 1202

1356User Data Elements (UDEs) 1200 and Method Data Elements (MDEs) 1202 in the preferred embodiment store data.

1357There are many types of UDEs 1200 and MDEs 1202 provided by the prefeπed embodiment. In the preferred embodiment, each of these different types of data structures shares a common overaU format including a common header definition and naming scheme. Other UDEs 1200 that share this common structure include "local name services records" (to be explained shortly) and account information for connecting to other VDE participants. These elements are not necessarily associated with an individual user, and may therefore be considered MDEs 1202. AU UDEs 1200 and aU MDEs 1202 provided by the preferred embodiment may, if desired, (as shown in Figure 16) be stored in a common physical table within secure database 610, and database access processes may commonly be used to access aU of these different types of data structures.

1358In the prefeπed embodiment, PERCs 808 and user rights table records are types of UDE 1200. There are many other types of UDEs 1200/MDEs 1202, including for example, meters, meter trails, budgets, budget trails, and audit trails. Different formats for these different types of UDEs/MDEs are defined, as described above, by SGML definitions contained within DTDs 1108. Methods 1000 use these DTDs to appropriately access UDEs/MDEs 1200, 1202.

1359Secure database 610 stores two types of items: static and dynamic. Static data structures and other items are used for information that is essentially static information. This includes load modules 1100, PERCs 808, and many components of methods. These items are not updated frequently and contain expiration dates that can be used to prevent "old" copies of the information from being substituted for newly received items. These items may be encrypted with a site specific secure database file key when they are stored in the secure database

1360610, and then decrypted using that key when they are loaded into the SPE.

1361Dynamic items are used to support secure items that must be updated frequently. The UDEs 1200 of many methods must be updated and written out of the SPE 503 after each use. Meters and budgets are common examples of this. Expiration dates cannot be used effectively to prevent substitution of the previous copy of a budget UDE 1200. To secure these frequently updated items, a transaction tag is generated and included in the encrypted item each time that item is updated. A list of aU VDE item IDs and the cuπent transaction tag for each item is maintained as part of the secure database 610.

1362Figure 24 shows an example of a user data element ("UDE") 1200 provided by the preferred embodiment. As shown in Figure 24, UDE 1200 in the preferred embodiment includes a pubhc header 802, a private header 804, and a data area 1206. The layout for each of these user data elements 1200 is generaUy defined by an SGML data definition contained within a DTD 1108 associated with one or more load modules 1100 that operate on the UDE 1200.

1363UDEs 1200 are preferably encrypted using a site specific key once they are loaded into a site. This site-specific key masks a vahdation tag that may be derived from a cryptographicaUy strong pseudo-random sequence by the SPE 503 and updated each time the record is written back to the secure database 610. This technique provides reasonable assurance that the UDE 1200 has not been tampered with nor substituted when it is requested by the system for the next use.

1364Meters and budgets are perhaps among the most common data structures in VDE 100. They are used to count and record events, and also to limit events. The data structures for each meter and budget are determined by the content provider or a distributor/redistributor authorized to change the information. Meters and budgets, however, generaUy have common information stored in a common header format (e.g., user ED, site

1365ID and related identification information).

1366The content provider or distributor/redistributor may specify data structures for each meter and budget UDE. Although these data structures vary depending upon the particular apphcation, some are more common than others. The foUowing table lists some of the more commonly occurring data structures for METER and BUDGET methods: Field type Format Typical Use Description or Use

1367Ascending Use byte, short, lon{ , Meter/Budget Ascending count of use Counter or unsigned versions of the same widths

1368Descending Use byte, short, long , Budget Descending count of Counter or unsigned permitted use; eg., versions of the remaining budget. same widths

1369Counter/Limit 2, 4 or 8 byte Meter/Budget usage limits since a sp integer spht int ) time; generaUy used in two related byt&lt; β compound meter data or words structures.

1370Bitmap Array bytes Meter/Budget Bit indicator of use or ownership.

1371Wide bitmap Array of bytes Meter/Budget Indicator of use or ownership that may ag with time.

1372Last Use Date time t Meter/Budget Date of last use.

1373Start Date time t Budget Date of first allowable

1374Expiration Date time t Meter/Budget Expiration Date.

1375Last Audit Date time t Meter Budget Date of last audit.

1376Next Audit Date time t Meter/Budget Date of next required a

1377Auditor VDE ID Meter/Budget VDE ID of authorized auditor.

1378The information in the table above is not complete or comprehensive, but rather is intended to show some examples of types of information that may be stored in meter and budget related data structures. The actual structure of particular meters and budgets is deteπnined by one or more DTDs 1108 associated with the load modules 1100 that create and manipulate the data structure. A list of data types permitted by the DTD interpreter 590 in VDE 100 is extensible by properly authorized parties.

1379Figure 25 shows an example of one particularly advantageous kind of UDE 1200 data area 1206. This data area 1206 defines a "map" that may be used to record usage information. For example, a meter method 1000 may maintain one or more "usage map" data areas 1206. The usage map may be a "usage bit map" in the sense that it stores one or more bits of infoπnation (i.e., a single or multi-dimensional bit image) coπesponding to each of several types or categories of usage. Usage maps are an efficient means for referencing prior usage. For example, a usage map data area may be used by a meter method 1000 to record aU apphcable portions of information content that the user has paid to use, thus supporting a very efficient and flexible means for aUowing subsequent user usage of the same portions of the information content. This may enable certain VDE related security functions such as "contiguousness," "logical relatedness," randomization of usage, and other usage types. Usage maps may be analyzed for other usage patterns (e.g., quantity discounting, or for enabling a user to reaccess information content for which the user previously paid for unlimited usage).

1380The "usage map" concept provided by the prefeπed embodiment may be tied to the concept of "atomic elements." In the prefeπed embodiment, usage of an object 300 may be metered in terms of "atomic elements." In the prefeπed embodiment, an "atomic element" in the metering context defines a unit of usage that is "sufficiently significant" to be recorded in a meter. The definition of what constitutes an "atomic element" is determined by the creator of an object 300. For instance, a "byte" of information content contained in an object 300 could be defined as an "atomic element," or a record of a database could be defined as an "atomic element," or each chapter of an electronicaUy pubhshed book could be defined as an "atomic element."

1381An object 300 can have multiple sets of overlapping atomic elements. For example, an access to any database in a plurahty of databases may be defined as an "atomic element." Simultaneously, an access to any record, field of records, sectors of informations, and/or bytes contained in any of the plurahty of databases might also be defined as an "atomic element." In an electronicaUy pubhshed newspaper, each hundred words of an article could be defined as an "atomic element," whUe articles of more than a certain length could be defined as another set of "atomic elements." Some portions of a newspaper (e.g., advertisements, the classified section, etc. ) might not be mapped into an atomic element.

1382The prefeπed embodiment provides an essentiaUy unbounded ability for the object creator to define atomic element types. Such atomic element definitions may be very flexible to accommodate a wide variety of different content usage. Some examples of atomic element types supported by the prefeπed embodiment include bytes, records, files, sectors, objects, a quantity of bytes, contiguous or relatively contiguous bytes (or other predefined unit types), logicaUy related bytes containing content that has some logical relationship by topic, location or other user specifiable logic of relationship, etc. Content creators preferably may flexibly define other types of atomic elements.

1383The prefeπed embodiment of the present invention provides EVENT methods to provide a mapping between usage events and atomic elements. GeneraUy, there may be an EVENT method for each different set of atomic elements defined for an object 300. In many cases, an object 300 will have at least one type of atomic element for metering relating to hilling, and at least one other atomic element type for non-hilling related metering (e.g., used to. for example, detect fraud, bill advertisers, and/or coUect data on end user usage activities).

1384In the prefeπed embodiment, each EVENT method in a usage related context performs two functions: (1) it maps an accessed event into a set of zero or more atomic elements, and (2) it provides information to one or more METER methods for metering object usage. The definition used to define this mapping between access events and atomic elements may be in the form of a mathematical definition, a table, a load module, etc. When an EVENT method maps an access request into "zero" atomic elements, a user accessed event is not mapped into any atomic element based on the particular atomic element definition that apphes. This can be, for example, the object owner is not interested in metering usage based on such accesses (e.g., because the object owner deems such accesses to be insignificant from a metering standpoint).

1385A 'usage map" may employ a "bit map image" for storage of usage history information in a highly efficient manner. Individual storage elements in a usage map may coπespond to atomic elements. Different elements within a usage map may coπespond to different atomic elements (e.g., one map element may coπespond to number of bytes read, another map element may coπespond to whether or not a particular chapter was opened, and yet another map element may coπespond to some other usage event).

1386One of the characteristics of a usage map provided by the prefeπed embodiment of the present invention is that the significance of a map element is specified, at least in part, by the position of the element within the usage map. Thus, in a usage map provided by the prefeπed embodiment, the information indicated or encoded by a map element is a function of its position (either physicaUy or logicaUy) within the map structure. As one simple example, a usage map for a twelve-chapter novel could consist of twelve elements, one for each chapter of the novel. When the user opens the first chapter, one or more bits within the element coπesponding to the first chapter could be changed in value (e.g., set to "one"). In this simple example where the owner of the content object contai-ning the novel was interested only in metering which chapters had been opened by the user, the usage map element coπesponding to a chapter could be set to "one" the first time the user opened that coπesponding chapter, and could remain "one" no matter how many additional times the user opened the chapter. The object owner or other interested VDE participant would be able to rapidly and efficiently teU which chapters) had been opened by the user simply by examining the compact usage map to determine which elements were set to ' one.''

1387Suppose that the content object owner wanted to know how many times the user had opened each chapter of the novel. In this case, the usage map might comprise, for a twelve-chapter novel, twelve elements each of which has a one-to-one coπespondence with a different one of the twelve chapters of the novel. Each time a user opens a particular chapter, the coπesponding METER method might increment the value contained in the coπesponding usage map element. In this way. an account could be readily maintained for each of the chapters of the novel.

1388The position of elements within a usage map may encode a multi-variable function. For example, the elements within a usage map may be arranged in a two-dimensional array as shown in Figure 25B. Different array coordinates could coπespond to independent variables such as, for example, atomic elements and time. Suppose, as an example, that a content object owner distributes an object containing a coUection of audio recordings. Assume further that the content object owner wants to track the number of times the user listens to each recording within the coUection, and also wants to track usage based on month of the year. Thus, assume that the content object owner wishes to know how many times the user during the month of January listened to each of the recordings on a recording-by-recording basis, simUarly wants to know this same information for the month of February, March, etc. In this case, the usage map (see Figure 25B) might be defined as a two-dimensional array of elements. One dimension of the array might encode audio recording number. The other dimension of the array might encode month of the year. During the month of January, the coπesponding METER method would increment elements in the array in the "January" column of the array, selecting which element to increment as a function of recording number. When January comes to an end, the METER method might cease writing into the array elements in the January column, and instead write values into a further set of February array elements — once again selecting the particular array element in this column as a function of recording number. This concept may be extended to N dimensions encoding N different variables.

1389Usage map meters are thus an efficient means for referencing prior usage. They may be used to enable certain VDE related security functions such as testing for contiguousness (including relative contiguousness), logical relatedness (including relative logical relatedness), usage randomization, and other usage patterns. For example, the degree or character of the "randomness" of content usage by a user might serve as a potential indicator of attempts to circumvent VDE content budget limitations. A user or groups of users might employ multiple sessions to extract content in a manner which does not violate contiguousness, logical relatedness or quantity limitations, but which nevertheless enables reconstruction of a material portion or aU of a given, valuable unit of content. Usage maps can be analyzed to determine other patterns of usage for pricing such as, for example, quantity discounting after usage of a certain quantity of any or certain atomic units, or for enabling a user to reaccess an object for which the user previously paid for unlimited accesses (or unlimited accesses over a certain time duration). Other useful analyses might include discounting for a given atomic unit for a plurahty of uses.

1390A further example of a map meter includes storing a record of aU apphcable atomic elements that the user has paid to use (or alternatively, has been metered as having used, though payment may not yet have been required or made). Such a usage map would support a very efficient and flexible way to aUow subsequent user usage of the same atomic elements.

1391A further usage map could be maintained to detect fraudulent usage of the same object. For example, the object might be stored in such a way that sequential access of long blocks should never occur. A METER method could then record aU apphcable atomic elements accesses during, for example, any specified increment of time, such as ten minutes, an hour, a day, a month, a year, or other time duration). The usage map could be analyzed at the end of the specified time increment to check for an excessively long contiguous set of accessed blocks, and/or could be analyzed at the initiation of each access to apphcable atomic elements. After each time duration based analysis, if no fraudulent use is detected, the usage map could be cleared (or partiaUy cleared) and the mapping process could begin in whole or in part anew. If a fraudulent use pattern is suspected or detected, that information might be recorded and the use of the object could be halted. For example, the user might be required to contact a content provider who might then further analyze the usage infoπnation to determine whether or not further access should be permitted.

1392Figure 25c shows a particular type of "wide bit map" usage record 1206 wherein each entry in the usage record coπesponds to usage during a particular time period (e.g., cuπent month usage, last month's usage, usage in the month before last, etc.). The usage record shown thus comprises an array of "flags" or fields 1206, each element in the array being used to indicate usage in a different time period in this particular example. When a time period ends, aU elements 1206 in the array may be shifted one position, and thus usage information (or the purchase of user access rights) over a series of time periods can be reflected by a series of successive array elements. In the specific example shown in Figure 25c, the entire wide array 1206 is shifted by one array position each month, with the oldest aπay element being deleted and the new array element being "turned" in a new array map coπesponding to the cuπent time period. In this example, record 1302 tracks usage access rights and/or other usage related activities during the present calendar month as weU for the five immediately prior calendar months. Coπesponding billing and or billing method 406 may inspect the map, determine usage as related to hilling and/or security monitoring for cuπent usage based on a formula that employs the usage data stored in the record, and updates the wide record to indicate the apphcable array elements for which usage occuπed or the like. A wide bit map may also be used for many other purposes such as maintaining an element by element count of usage, or the contiguousness. relatedness. etc. function described above, or some combination of functionahty.

1393Audit traU maps may be generated at any frequency determined by control, meter, budget and billing methods and load modules associated with those methods. Audit trails have a similar structure to meters and budgets and they may contain user specific information in addition to information about the usage event that caused them to be created. Like meters and budgets, audit trails have a dynamic format that is defined by the content provider or their authorized designee. and share the basic element types for meters and budgets shown in the table above. In addition to these types, the foUowing table lists some examples of other significant data fields that may be found in audit trails:

1394Field type Format Typical Use Description of Use

1395Use Event ID unsigned long Meter/Budget/ Event ID that started a processing Billing sequence.

1396Internal unsigned long Meter/Budgetv Transaction number to help detect

1397Sequence Billing audits that have been tampered

1398Number with Field type Format Typical Use Description of Use

1399Atomic Unsigned Meter/Billing Atomic element! si and ID of object Element! s) integer, s) of that was used. &amp; Object ID appropriate width

1400Personal User Character or Budget/Billing Personal information about user. Information other information

1401Use Date/Time time_t Meter/Budget/ Date/time of use. Billing

1402Site ID/User VDE ID Meter/Budget/ VDE ID of user. ID Hilling

1403Audit trail records may be automaticaUy combined into single records to conserve header space. The combination process may, for example, occur under control of a load module that creates individual audit traU records.

1404Permissions Record Overview

1405Figure 16 also shows that PERCs 808 may be stored as part of secure database 610. Permissions records ("PERCs") 808 are at the highest level of the data driven control hierarchy provided by the prefeπed embodiment of VDE 100. BasicaUy, there is at least one PERC 808 that coπesponds to each information and/or transactional content distributed by VDE 100. Thus, at least one PERC 808 exists for each VDE object 300 in the prefeπed embodiment. Some objects may have multiple coπesponding PERCs 808. PERC 808 controls how access and/or manipulation permissions are distributed and/or how content and/or other information may otherwise be used. PERC 808 also specifies the "rights" of each VDE participant in and to the content and/or other information.

1406In the prefeπed embodiment, no end user may use or access a VDE object unless a permissions record 808 has been dehvered to the end user. As discussed above, a PERC 808 may be dehvered as part of a traveling object 860 or it may be dehvered separately (for example, within an administrative object). An electronic apphance 600 may not access an object unless a coπesponding PERC 808 is present, and may only use the object and related information as permitted by the control structures contained within the PERC.

1407Briefly, the PERC 808 stores infoπnation concerning the methods, method options, decryption keys and rights with respect to a coπesponding VDE object 300.

1408PERC 808 includes control structures that define high level categories or classifications of operations. These high level categories are referred to as "rights." The ^"right" control structures, in turn, provide internal control structures that reference "methods" 1000. The internal structure of prefeπed embodiment PERC 808 organizes the "methods" that are required to perform each aUowable operation on an object or associated control structure (including operations performed on the PERC itself). For example, PERC 808 contains decryption keys for the object, and usage of the keys is controUed by the methods that are required by the PERC for performing operations associated with the exercise of a "right."

1409PERC 808 for an object is typicaUy created when the object is created, and future substantive modifications of a PERC, if aUowed, are controUed by methods associated with operations using the distribution right(s) defined by the same (or different) PERC.

1410Figure 22 shows the internal structures present in an example of a PERC 808 provided by the prefeπed embodiment. AU of the structures shown represent (or reference ) coUections of methods required to process a coπesponding object in some specific way. PERCs 808 are organized as a hierarchical structure, and the basic elements of the hierarchy are as foUows: "rights" records 906

1411"control sets" 914

1412"required method" records 920 and "required method options" 924. There are other elements that may be included in a PERC 808 hierarchy that describe rules and the rule options to support the negotiation of rule sets and control information for smart objects and for the protection of a user's personal infoπnation by a privacy filter. These alternate elements may include: optional rights records optional control sets optional method records permitted rights records permitted rights control sets permitted method records required DTD descriptions optional DTD descriptions permitted DTD descriptions These alternate fields can control other processes that may, in part, base negotiations or decisions regarding their operation on the contents of these fields. Rights negotiation, smart object control infoπnation, and related processes can use these fields for more precise control of their operation.

1413The PERC 808 shown in Figure 26 includes a PERC header 900, a CSO ("control set 0") 902, private body keys 904, and one or more rights sub-records 906. Control set 0 902 in the prefeπed embodiment contains information that is common to one or more "rights" associated with an object 300. For example, a particular "event" method or methods might be the same for usage rights, extraction rights and/or other rights. In that case, "control set 0" 902 may reference this event that is common across multiple "rights." The provision of "control set 0" 902 is actuaUy an optimization, since it would be possible to store different instances of a commonly-used event within each of plural "rights" records 906 of a PERC 808.

1414Each rights record 906 defines a different "right" coπesponding to an object. A "right" record 906 is the highest level of organization present in PERC 808. There can be several different rights in a PERC 808. A "right" represents a major functional partitioning desired by a participant of the basic architecture of VDE 100. For example, the right to use an object and the right to distribute rights to use an object are major functionεd groupings within VDE 100. Some examples of possible rights include access to content, permission to distribute rights to access content, the abihty to read and process audit trails related to content and/or control structures, the right to perform transactions that may or may not be related to content and/or related control structures (such as banking transactions, catalog purchases, the coUection of taxes, EDI transactions, and such), and the abihty to change some or aU of the internal structure of PERCs created for distribution to other users. PERC 808 contains a rights record 906 for each type of right to object access/use the PERC grants.

1415NormaUy, for VDE end users, the most frequently granted right is a usage right. Other types of rights include the "extraction right," the "audit right" for accessing audit traU information of end users, and a "distribution right" to distribute an object. Each of these different types of rights may be embodied in a different rights record 906 (or alternatively, different PERCs 808 coπesponding to an object may be used to grant different rights).

1416Each rights record 906 includes a rights record header 908, a CSR ("control set for right") 910, one or more "right keys" 912, and one or more "control sets" 914. Each "rights" record 906 contains one or more control sets 914 that are either required or selectable options to control an object in the exercise of that "right." Thus, at the next level, inside of a "right" 906, are control sets 914. Control sets 914, in turn, each includes a control set header 916, a control method 918, and one or more required methods records 920. Required methods records 920, in turn, each includes a required method header 922 and one or more required method options 924. Control sets 914 exist in two types in VDE 100: common required control sets which are given designations "control set 0" or "control set for right," and a set of control set options. "Control set 0" 902 contains a list of required methods that are common to aU control set options, so that the common required methods do not have to be duplicated in each control set option. A "control set for right" ("CSR") 910 contains a similar hst for control sets within a given right. "Control set 0" and any "control sets for rights" are thus, as mentioned above, optimizations; the same functionahty for the control sets can be accomplished by listing aU the common required methods in each control set option and omitting "control set 0" and any "control sets for rights."

1417One of the control set options, "control set 0" and the appropriate "control set for right" together form a complete control set necessary to exercise a right.

1418Each control set option contains a list of required methods 1000 and represents a different way the right may be exercised. Only one of the possible complete control sets 914 is used at any one time to exercise a right in the prefeπed embodiment.

1419Each control set 914 contains as many required methods records 920 as necessary to satisfy aU of the requirements of the creators and/or distributors for the exercise of a right. Multiple ways a right may be exercised, or multiple control sets that govern how a given right is exercised, are both supported. As an example, a single control set 914 might require multiple meter and budget methods for reading the object's content, and also require different meter and budget methods for printing an object's content. Both reading and printing an object's content can be controUed in a single control set 914.

1420Alternatively, two different control set options could support reading an object's content by using one control set option to support metering and budgeting the number of bytes read, and the other control set option to support metering and budgeting the number of paragraphs read. One or the other of these options would be active at a time.

1421TypicaUy, each control set 914 wUl reference a set of related methods, and thus different control sets can offer a different set of method options. For example, one control set 914 may represent one distinct kind of metering methodology, and another control set may represent another, entirely different distinct metering methodology.

1422At the next level inside a control set 914 are the required methods records 920. Methods records 920 contain or reference methods 1000 in the prefeπed embodiment. Methods 1000 are a coUection of "events," references to load modules associated with these events, static data, and references to a secure database 610 for automatic retrieval of any other separately dehverable data elements that may be required for processing events (e.g., UDEs). A control set 914 contains a list of required methods that must be used to exercise a specific right (i.e., process events associated with a right). A required method record 920 listed in a control set 914 indicates that a method must exist to exercise the right that the control set supports. The required methods may reference "load modules" 1100 to be discussed below. Briefly, load modules 1100 are pieces of executable code that may be used to carry out required methods.

1423Each control set 914 may have a control method record 918 as one of its required methods. The referenced control method may define the relationships between some or aU of the various methods 1000 defined by a control set 906. For example, a control method may indicate which required methods are functionaUy grouped together to process particular events, and the order for processing the required methods. Thus, a control method may specify that required method referenced by record 920(a)( l)(i) is the first to be caUed and then its output is to go to required method referenced by record 920(a)(1)(h) and so on. In this way, a meter method may be tied to one or more hilling methods and then the billing methods may be individuaUy tied to different budget methods, etc.

1424Required method records 920 specify one or more required method options 924. Required method options are the lowest level of control structure in a prefeπed embodiment PERC 808. By parameterizing the required methods and specifying the required method options 924 independently of the required methods, it becomes possible to reuse required methods in many different circumstances.

1425For example, a required method record 920 may indicate that an actual budget method ID must be chosen from the list of budget method IDs in the required method option hst for that required method. Required method record 920 in this case does not contain any method IDs for information about the type of method required, it only indicates that a method is required. Required method option 924 contains the method ID of the method to be used if this required method option is selected. As a further optimization, an actual method ID may be stored if only one option exists for a specific required method. This aUows the size of this data structure to be decreased.

1426PERC 808 also contains the fundamental decryption keys for an object 300, and any other keys used with "rights" (for encoding and/or decoding audit trails, for example). It may contain the keys for the object content or keys to decrypt portions of the object that contain other keys that then can be used to decrypt the content of the object. Usage of the keys is controUed by the control sets 914 in the same "right" 906 within PERC 808.

1427In more detaU, Figure 26 shows PERC 808 as including private body keys 904, and right keys 912. Private body keys 904 are used to decrypt information contained within a private body 806 of a coπesponding VDE object 300. Such information may include, for example, methods 1000, load modules 1100 and/or UDEs 1200, for example. Right keys 912 are keys used to exercise a right in the prefeπed embodiment. Such right keys 912 may include, for example, decryption keys that enable a method specified by PERC 808 to decrypt content for release by a VDE node to an end user. These right keys 912 are, in the prefeπed embodiment, unique to an object 300. Their usage is preferably controUed by budgets in the prefeπed embodiment.

1428DetaUed Example of a PERC 808

1429Figures 26A and 26B show one example of a prefeπed embodiment PERC 808. In this example. PERC header 900 includes: a site record number 926, a field 928 specifying the length of the private body key block, a field 930 specifying the length of the PERC, an expiration date time field 932 specifying the expiration date and/or time for the PERC, a last modification date/time field 934 specifying the last date and/or time the PERC 808 was modified, the original distributor ID field 936 that specifies who originaUy distributed the PERC and/or coπesponding object, a last distributor field 938 that specifies who was the last distributor of the PERC and/or the object, an object ID field 940 identifying the coπesponding VDE object 300, a field 942 that specifies the class and/or type of PERC and/or the instance ID for the record class to differentiate the PERCs of the same type that may differ in their particulars, a field 944 specifying the number of "rights" sub- records 906 within the PERC, and a vahdation tag 948. The PERC 808 shown in Figures 26a, 26b also has private body keys stored in a private body key block 950. This PERC 808 includes a control set 0 sub-record 914 (0) that may be used commonly by aU of rights 906 within the PERC. This control set 0 record 914(0) may include the foUowing fields: a length field 952 specifying the length of the control set 0 record a field 954 specifying the number of required method records 920 within the control set an access tag field 956 specifying an access tag to control modification of the record and one or more required method records 920. Each required method record 920, in turn may include: a length field 958 specifying the length of the required method record a field 960 specifying the number of method option records within the required method record 920 an access tag field 962 specifying an access tag to control modification of the record and one or more method option records 924. Each method option sub-record 924 may include: a length field 964 specifying the length of the method option record a length field 966 specifying the length of the data area (if any; coπesponding to the method option record a method ID field 968 specifying a method ID (e.g., type/owner/class/instance) a coπelation tag field 970 specifying a coπelation tag for correlating with the method specified in field 968 an access tag field 972 specifying an access tag to control modification of this record a method-specific attributes field 974 a data area 976 and a check value field 978 for vahdation purposes

1430In this example of PERC 808 also includes one or more rights records 906, and an overaU check value field 980. Figure 23b is an example of one of right records 906 shown in Figure 16a. In this particular example, rights record 906a includes a rights record header 908 comprising: a length field 982 specifying the length of the rights key block 912 a length field 984 specifying the length of the rights record 908 an expiration date/time field 986 specifying the expiration date and/or time for the rights record a right ID field 988 identifying a right a number field 990 specifying the number of control sets 914 within the rights record 906, and an access tag field 992 specifying an access tag to control modification of the right record.

1431This example of rights record 906 includes: a control set for this right (CSR) 910 a rights key block 912 one or more control sets 914, and a check value field 994.

1432Object Registry

1433Referring once again to Figure 16, secure database 610 provides data structures that support a "lookup" mechanism for "registered" objects. This "lookup" mechanism permits electronic apphance 600 to associate, in a secure way, VDE objects 300 with PERCs 808. methods 1000 and load modules 1100. In the prefeπed embodiment, this lookup mechanism is based in part on data structures contained within object registry 450.

1434In one embodiment, object registry 450 includes the foUowing tables:

1435• an object registration table 460;

1436• a subject table 462; a User Rights Table ("URT") 464; • an Administrative Event Log 442;

1437• a shipping table 444; and

1438• a receiving table 446.

1439Object registry 460 in the example embodiment is a database of information concerning registered VDE objects 300 and the rights of users and user groups with regard to those objects. When electronic apphance 600 receives an object 300 containing a new budget or load module 1100, the electronic apphance usuaUy needs to add the information contained by the object to secure database 610. Moreover, when any new VDE object 300 arrives at an electronic apphance 600, the electronic apphance must "register" the object within object registry 450 so that it can be accessed. The hsts and records for a new object 300 are buUt in the prefeπed embodiment when the object is "registered" by the electronic apphance 600. The information for the object may be obtained from the object's encrypted private header, object body, and encrypted name services record. This information may be extracted or derived from the object 300 by SPE 503, and then stored within secure database 610 as encrypted records.

1440In one embodiment, object registration table 460 includes information identifying objects within object storage &lt; repository) 728. These VDE objects 300 stored within object storage 728 are not, in the example embodiment, necessarily part of secure database 610 since the objects typicaUy incorporate their own security (as necessary and required) and are maintained using different mechanisms than the ones used to maintain the secure database. Even though VDE objects 300 may not strictly be part of secure database 610, object registry 450 (and in particular, object registration table 460) refers to the objects and thus "incorporates them by reference" into the secure database. In the prefeπed embodiment, an electronic apphance 600 may be disabled from using any VDE object 300 that has not been appropriately registered with a coπesponding registration record stored within object registration table 460.

1441Subject table 462 in the example embodiment estabhshes coπespondence between objects refeπed to by object registration table 460 and users (or groups of users) of electronic apphance 600. Subject table 462 provides many of the attributes of an access control list ("ACL"), as will be explained below.

1442User rights table 464 in the example embodiment provides permissioning and other information specific to particular users or groups of users and object combinations set forth in subject table 462. In the example embodiment, permissions records 808 ( also shown in Figure 16 and being stored within secure database 610) may provide a universe of permissioning for a particular object-user combination. Records within user rights table 464 may specify a sub-set of this permissioning universe based on, for example, choices made by users during interaction at time of object registration.

1443Administrative event log 442, shipping table 444, and receiving table 446 provide information about receipts and deliveries of VDE objects 300. These data structures keep track of administrative objects sent or received by electronic apphance 600 including, for example, the purpose and actions of the administrative objects in summary and detaUed form. Briefly, shipping table 444 incudes a shipping record for each administrative object sent (or scheduled to be sent) by electronic apphance 600 to another VDE participant. Receiving table 446 in the prefeπed embodiment includes a receiving record for each adrninistrative object received (or scheduled to be received) by electronic apphance 600. Administrative event log 442 includes an event log record for each shipped and each received administrative object, and may include detaUs concerning each distinct event specified by received administrative objects.

1444Ad-cαiiustrative Object Shipping and Receiving

1445Figure 27 is an example of a detaUed format for a shipping table 444. In the prefeπed embodiment, shipping table 444 includes a header 444A and any number of shipping records 445. Header 444 A includes information used to maintain shipping table 444. Each shipping record 445 within shipping table 444 provides detaUs concerning a shipping event (i.e., either a completed shipment of an administrative object to another VDE participant, or a scheduled shipment of an administrative object).

1446In the example embodiment of the secure database 610, shipping table header 444 A may include a site record number 444A(1), a user (or group) ID 444A(2), a series of reference fields 444A(3)-444A(6), vahdation tags 444A(7)-444A(8), and a check value field 444A(9). The fields 444A(3)-444A(6) reference certain recent IDs that designate lists of shipping records 445 within shipping table 444. For example, field 444A(3) may reference to a "first" shipping record representing a completed outgoing shipment of an administrative object, and field 444A(4) may reference to a "last" shipping record representing a completed outgoing shipment of an administrative object. In this example, "first" and "last" may, if desired, refer to time or order of shipment as one example. Similarly, fields 444A(5) and 444A(6) may reference to "first" and "last" shipping records for scheduled outgoing shipments. Vahdation tag 444 A( 7) may provide vahdation from a name services record within name services record table 452 associated with the user (group) ID in the header. This permits access from the shipping record back to the name services record that describes the sender of the object described by the shipping records. Vahdation tag 444A(8) provides vahdation for a "first" outgoing shipping record referenced by one or more of pointers 444A(3)-444A(6). Other vahdation tags may be provided for vahdation of scheduled shipping record(s).

1447Shipping record 444(1) shown includes a site record number 445(1)(A). It also includes first and last scheduled shipment date/times 445(1)(B), 445(1 )(C) providing a window of time used for scheduling administrative object shipments. Field 445(1 )(D) may specify an actual date/time of a completed shipment of an administrative object. Field 445(1 )(E) provides an ID of an administrative object shipped or to be shipped, and thus identifies which administrative object within object storage 728 pertains to this particular shipping record. A reference field 445(1 )(G) references a name services record within name services record table 452 specifying the actual or intended recipient of the administrative object shipped or to be shipped. This information within name services record table 452 may, for example, provide routing information sufficient to permit outgoing administrative objects manager 754 shown in Figure 12 to inform object switch 734 to ship the administrative object to the intended recipient. A field 445(1)(H) may specify (e.g., using a series of bit flags ) the purpose of the administrative object shipment, and a field 445(1 )(I) may specify the status of the shipment. Reference fields 445(1)(J), 445(1)(K) may reference "previous" and "next" shipping records 445 in a linked list (in the preferred embodiment, there may be two linked lists, one for completed shipping records and the other for scheduled shipping records). Fields 445(1)(L) - 445(1)(P) may provide vahdation tags respectively from header 444A, to a record within administrative event log 442 pointed to by pointer 445(1)(F); to the name services record referenced by field 445(1 KG); from the previous record referenced by 445(1 )(J); and to the next record referenced by field 445(1 )(K). A check value field 445(1 )(Q) may be used for validating shipping record 445.

1448Figure 28 shows an example of one possible detaUed format for a receiving table 446. In one embodiment, receiving table 446 has a structure that is similar to the structure of the shipping table 444 shown in Figure 27. Thus, for example, receiving table 446 may include a header 446a and a plurahty of receiving records 447, each receiving record including detaUs about a particular reception or scheduled reception of an administrative object. Receiving table 446 may include two linked hsts, one for completed receptions and another for schedule receptions. Receiving table records 447 may each reference an entry within name services record table 452 specifying an administrative object sender, and may each point to an entry within administrative event log 442. Receiving records 447 may also include additional details about scheduled and/or completed reception (e.g., scheduled or actual date/time of reception, purpose of reception and status of reception), and they may each include vahdation tags for validating references to other secure database records.

1449Figure 29 shows an example of a detaUed format for an administrative event log 442. In the prefeπed embodiment, administrative event log 442 includes an event log record 442(1 ) . . . 442(N) for each shipped administrative object and for each received administrative object. Each administrative event log record may include a header 443a and from 1 to N sub-records 442(J)(1) . . . 442(J)(N). In the prefeπed embodiment, header 443a may include a site record number field 443A(1), a record length field 443A(2), an administrative object ID field 443A(3 ), a field 443A(4 ) specifying a number of events, a vahdation tag 443 A( 5) from shipping table 444 or receiving table 446, and a check sum field 443A(6). The number of events specified in field 443A(4) coπesponds to the number of sub-records 442(J)(1) . . . 442(J)(N ) within the administrative event log record 442(J). Each of these sub-records specifies information about a particular "event" affected or coπesponding to the administrative object specified vrithin field 443(A)(3 ). Administrative events are retained in the administrative event log 442 to permit the reconstruction (and preparation for construction or processing) of the administrative objects that have been sent from or received by the system. This permits lost administrative objects to be reconstructed at a later time.

1450Each sub-record may include a sub-record length field 442(J)(l)(a), a data area length field 442(J)(l)(b), an event ID field 442(J)(l)(c), a record type field 442(J)(l)(d), a record ID field 442(J)(l)(e), a data area field 442(J)(l)(f), and a check value field 442(J)(l)(g). The data area 442(J)(l)(f) may be used to indicate which information within secure database 610 is affected by the event specified in the event ID field 442(J)(l)(c), or what new secure database item(s) were added, and may also specify the outcome of the event.

1451The object registration table 460 in the prefeπed embodiment includes a record coπesponding to each VDE object 300 within object storage (repository) 728. When a new object arrives or is detected (e.g., by redirector 684), a prefeπed embodiment electronic apphance 600 "registers" the object by creating an appropriate object registration record and storing it in the object registration table 460. In the prefeπed embodiment, the object registration table stores information that is user- independent, and depends only on the objects that are registered at a given VDE electronic apphance 600. Registration activities are typicaUy managed by a REGISTER method associated with an object.

1452In the example, subject table 462 associates users (or groups of users) with registered objects. The example subject table 462 performs the function of an access control list by specifying which users are authorized to access which registered VDE objects 300.

1453As described above, secure database 610 stores at least one PERC 808 coπesponding to each registered VDE object 300. PERCS 808 specify a set of rights that may be exercised to use or access the coπesponding VDE object 300. The prefeπed embodiment aUows user to "customize" their access rights by selecting a subset of rights authorized by a coπesponding PERC 808 and/or by specifying parameters or choices that coπespond to some or aU of the rights granted by PERC 808. These user choices are set forth in a user rights table 464 in the prefeπed embodiment. User rights table (URT) 464 includes URT records, each of which coπesponds to a user (or group of users). Each of these URT records specifies user choices for a coπesponding VDE object 300. These user choices may, either independently or in combination with a PERC 808, reference one or more methods 1000 for exercising the rights granted to the user by the PERC 808 in a way specified by the choices contained within the URT record.

1454Figure 30 shows an example of how these various tables may interact with one another to provide a secure database lookup mechanism. Figure 30 shows object registration table 460 as having a plurahty of object registration records 460(1), 460(2), . . .. These records correspond to VDE objects 300(1), 300(2), . . . stored within object repository 728. Figure 31 shows an example format for an object registration record 460 provided by the prefeπed embodiment. Object registration record 460(N) may include the foUowing fields: site record number field 466(1) object type field 466(2) creator ID field 466(3) object ID field 466(4) a reference field 466(5) that references subject table 462 an attribute field 466(6) a minimum registration interval field 466(7) a tag 466(8) to a subject table record, and a check value field 466(9).

1455The site record number field 466(1) specifies the site record number for this object registration record 460(N). In one embodiment of secure database 610. each record stored within the secure database is identified by a site record number. This site record number may be used as part of a database lookup process in order to keep track of aU of the records within the secure database 610.

1456Object type field 466(2) may specify the type of registered VDE object 300 (e.g., a content object, an administrative object, etc.).

1457Creator ID field 466(3) in the example may identify the creator of the coπesponding VDE object 300.

1458Object ID field 466(4) in the example uniquely identifies the registered VDE object 300.

1459Reference field 466(5) in the prefeπed embodiment identifies a record within the subject table 462. Through use of this reference, electronic apphance 600 may determine aU users ( or user groups) listed in subject table 462 authorized to access the coπespondmg VDE object 300. Tag 466(8) is used to vahdate that the subject table records accessed using field 466(5) is the proper record to be used with the object registration record 460(N). Attribute field 466(6) may store one or more attributes or attribute flags coπesponding to VDE object 300.

1460Minimum registration interval field 466(7) may specify how often the end user may re-register as a user of the VDE object 300 with a clearinghouse service, VDE administrator, or VDE provider. One reason to prevent frequent re-registration is to foreclose users from reusing budget quantities in traveling objects until a specified amount of time has elapsed. The minimum registration interval field 466(7 ) may be left unused when the object owner does not wish to restrict re-registration.

1461Check value field 466(9) contains vahdation information used for detecting corruption or modification of record 460(N) to ensure security and integrity of the record. In the preferred embodiment, many or aU of the fields within record 460(N) (as with other records within the secure database 610) may be fuUy or partiaUy encrypted and/or contain fields that are stored redundantly in each record (once in unencrypted form and once in encrypted form). Encrypted and unencrypted versions of the same fields may be cross checked at various times to detect corruption or modification of the records.

1462As mentioned above, reference field 466(5) references subject table 462. and in particular, references one or more user/object records 460(M) within the subject table. Figure 32 shows an example of a format for a user/object record 462(M) provided by the example. Record 462(M) may include a header 468 and a subject record portion 470. Header 468 may include a field 468(6) referencing a "first" subject record 470 contained within the subject registration table 462. This "first" subject record.470(1) may, in turn, include a reference field 470(5) that references a "next" subject record 470(2) within the subject registration table 462, and so on. This "linked list" structure permits a single object registration record 460(N) to reference to from one to N subject records 470.

1463Subject registration table header 468 in the example includes a site record number field 468(1) that may uniquely identify the header as a record within secure database 610. Header 468 may also include a creator ID field 468(2) that may be a copy of the content of the object registration table creator ID field 466(3). Similarly, subject registration table header 468 may include an object ID field 468(5) that may be a copy of object ED field 466(4 ) within object registration table 460. These fields 468(2), 468(5) make user/object registration records exphcitly coπespond to particular VDE objects 300.

1464Header 468 may also include a tag 468(7) that permits vahdation. In one example arrangement, the tag 468(7 ) within the user/object registration header 468 may be the same as the tag 466(8) within the object registration record 460(N) that points to the user/object registration header. Correspondence between these tags 468(7) and 466(8) permits vahdation that the object registration record and user/object registration header match up.

1465User/object header 468 also includes an original distributor ID field 468(3) indicating the original distributor of the coπesponding VDE object 300, and the last distributor ID field 468(4) that indicates the last distributor within the chain of handhng of the object prior to its receipt by electronic apphance 600.

1466Header 468 also includes a tag 468(8) aUowing vahdation between the header and the "first" subject record 470(1) which field 468(6) references

1467Subject record 470(1) includes a site record number 472(1 ), a user (or user group) ID field 472(2), a user (or user group) attributes field 472(3), a field 472(4) referencing user rights table 464, a field 472(5) that references to the '^"next" subject record 470(2) (if there is one), a tag 472(6) used to vahdate with the header tag 468(8), a tag 472(7) used to vahdate with a coπesponding tag in the user rights table record referenced by field 472(4), a tag 472(9) used to vahdate with a tag in the "next" subject record referenced to by field 472(5) and a check value field

1468472(9).

1469User or user group ID 472(2) identifies a user or a user group authorized to use the object identified in field 468(5). Thus, the fields 468(5) and 472(2) together form the heart of the access control list provided by subject table 462. User attributes field 472(3) may specify attributes pertaining to use/access to object 300 by the user or user group specified in fields 472(2). Any number of different users or user groups may be added to the access control list (each with a different set of attributes 472(3)) by providing additional subject records 470 in the "linked list" structure.

1470Subject record reference field 472(4) references one or more records within user rights table 464. Figure 33 shows an example of a prefeπed format for a user rights table record 464(k). User rights record 464(k) may include a URT header 474, a record rights header 476, and a set of user choice records 478. URT header 474 may include a site record number field, a field 474(2) specifying the number of rights records within the URT record 464(k), a field 474(3) referencing a "first" rights record (i.e., to rights record header 476), a tag 474(4) used to vahdate the lookup from the subject table 462, a tag 474(5) used to vahdate the lookup to the rights record header 476, and a check value field 474(6).

1471Rights record header 476 in the prefeπed embodiment may include site record number field 476(1), a right ID field 476(2), a field 476(3) referencing the "next" rights record 476(2), a field 476(4) referencing a first set of user choice records 478(1), a tag 476(5) to aUow vahdation with URT header tag 474(5), a tag 476(6) to aUow vahdation with a user choice record tag 478(6), and a check value field 476(7). Right ID field 476(2) may, for example, specify the type of right conveyed by the rights record 476(e.g., right to use, right to distribute, right to read, right to audit, etc.).

1472The one or more user choice records 478 referenced by rights record header 476 sets forth the user choices coπesponding to access and/or use of the coπesponding VDE object 300. There will typicaUy be a rights record 476 for each right authorized to the coπesponding user or user group. These rights govern use of the VDE object 300 by that user or user group. For instance, the user may have an "access" right, and an "extraction" right, but not a "copy" right. Other rights controUed by rights record 476 (which is derived from PERC 808 using a REGISTER method in the prefeπed embodiment) include distribution rights, audit rights, and pricing rights. When an object 300 is registered with the electronic apphance 600 and is registered with a particular user or user group, the user may be permitted to select among various usage methods set forth in PERC 808. For instance, a VDE object 300 might have two required meter methodologies: one for billing purposes, and one for accumulating data concerning the promotional materials used by the user. The user might be given the choice of a variety of meter/billing methods, such as: payment by VISA or MasterCard; choosing between billing based upon the quantity of material retrieved from an information database, based on the time of use, and/or both. The user might be offered a discount on time and/or quantity billing if he is willing to aUow certain details concerning his retrieval of content to be provided to third parties (e.g., for demographic purposes). At the time of registration of an object and/or user for the object, the user would be asked to select a particular meter methodology as the "active metering method" for the first acquired meter. A VDE distributor might narrow the universe of avaUable choices for the user to a subset of the original selection array stipulated by PERC 808. These user selection and configuration settings are stored within user choice records 480(1), 480(2), 480(N). The user choice records need not be explicitly set forth within user rights table 464; instead, it is possible for user choice records 480 to refer (e.g., by site reference number) to particular VDE methods and/or information parameterizing those methods. Such reference by user choice records 480 to method 1000 should be validated by vahdation tags contained within the user choice records. Thus, user choice records 480 in the prefeπed embodiment may select one or more methods 1000 for use with the coπesponding VDE object 300 (as is shown in Figure 27). These user choice records 480 may themselves fuUy define the methods 1000 and other information used to buUd appropriate components assembhes 690 for implementing the methods. Alternatively, the user/object record 462 used to reference the user rights record 464 may also reference the PERC 808 corresponding to VDE object 300 to provide additional information needed to buUd the component assembly 690 and/or otherwise access the VDE object 300. For example, PERC 808 may be accessed to obtain MDEs 1202 pert----ning to the selected methods, private body and/or rights keys for decrypting and/or encrypting object contents, and may also be used to provide a checking capabihty ensuring that the user rights record conveys only those rights authorized by a cuπent authorization embodied vrithin a PERC.

1473In one embodiment provided by the present invention, a conventional database engine may be used to store and organize secure database 610, and the encryption layers discussed above may be "on top of^* the conventional database structure. However, if such a conventional database engine is unable to organize the records in secure database 610 and support the security considerations outlined above, then electronic apphance 600 may maintain separate indexing structures in encrypted form. These separate indexing structures can be maintained by SPE 503. This embodiment would require SPE 503 to decrypt the index and search decrypted index blocks to find appropriate "site record IDs" or other pointers. SPE 503 might then request the indicated record from the conventional database engine. If the record ID cannot be checked against a record list, SPE 503 might be required to ask for the data file itself so it can retrieve the desired record. SPE 503 would then perform appropriate authentication to ensure that the file has not been tampered with and that the proper block is returned. SPE 503 should not simply pass the index to the conventional database engine (unless the database engine is itself secure) since this would aUow an incorrect record to be swapped for the requested one.

1474Figure 34 is an example of how the site record numbers described above may be used to access the various data structures within secure database 610. In this example, secure database 610 further includes a site record table 482 that stores a plurahty of site record numbers. Site record table 482 may store what is in effect a "master list" of aU records within secure database 610. These site record numbers stored by site record table 482 permit any record within secure database 610 to be accessed. Thus, some of the site records within site record table 482 may index records with an object registration table 460, other site record numbers within the site record table may index records within the user/object table 462, still other site record numbers within the site record table may access records within URT 464, and still other site record numbers within the site record table may access PERCs 808. In addition, each of method cores 1000' may also include a site record number so they may be accessed by site record table 482.

1475Figure 34A shows an example of a site record 482(j) within site record table 482. Site record 482(j) may include a field 484(1) indicating the type of record, a field 484(2) indicating the owner or creator of the record, a "class " field 484(3) and an "instance" field 484(4) providing additional information about the record to which the site record 482(j) points; a specific descriptor field 484(5) indicating some specific descriptor (e.g., object ED) associated with the record; an identification 484(6) of the table or other data structure which the site record references; a reference and/or offset within that data structure indicating where the record begins; a vahdation tag 484(8) for validating the record being looked up, and a check value field 484(9). Fields 484(6) and 484(7) together may provide the mechanism by which the record referenced to by the site record 484(j) is actuaUy physicaUy located within the secure database 610. Updating Secure Database 610

1476Figure 35 show an example of a process 1150 which can be used by a clearinghouse, VDE administrator or other VDE participant to update the secure database 610 maintained by an end user's electronic apphance 600. For example, the process 1500 shown in Figure 35 might be used to coUect "audit traU" records within secure database 610 and/or provide new budgets and permissions (e.g., PERCs 808) in response to an end user's request.

1477Typically, the end user's electronic apphance 600 may initiate communications with a clearinghouse (Block 1152). This contact may, for example, be established automaticaUy or in response to a user command. It may be initiated across the electronic highway 108, or across other communications networks such as a LAN, WAN, two-way cable or using portable media exchange between electronic apphances. The process of exchanging administrative information need not occur in a single "on line" session, but could instead occur over time based on a number of different one-way and/or two-way communications over the same or different communications means. However, the process 1150 shown in Figure 35 is a specific example where the end user's electronic apphance 600 and the other VDE participant (e.g., a clearinghouse) establish a two-way real-time interactive communications exchange across a telephone line, network, electronic highway 108, etc.

1478The end user's electronic apphance 600 generaUy contacts a particular VDE administrator or clearinghouse. The identity of the particular clearinghouse is based on the VDE object 300 the user wishes to access or has already accessed. For example, suppose the user has already accessed a particular VDE object 300 and has run out of budget for further access. The user could issue a request which will cause her electronic apphance 600 to automaticaUy contact the VDE administrator, distributor and/or financial clearinghouse that has responsibihty for that particular object. The identity of the appropriate VDE participants to contact is provided in the example by information within UDEs 1200, MDEs 1202, the Object Registration Table 460 and/or Subject Table 462, for example. Electronic apphance 600 may have to contact multiple VDE participants (e.g., to distribute audit records to one participant, obtain additional budgets or other permissions from another participant, etc.). The contact 1152 may in one example be scheduled in accordance with the Figure 27 Shipping Table 444 and the Figure 29 Administrative Event Log 442.

1479Once contact is established, the end user's electronic apphance and the clearinghouse typicaUy authenticate one another and agree on a session key to use for the real-time information exchange (Block 1154). Once a secure connection is established, the end user's electronic apphance may determine (e.g., based on Shipping Table 444) whether it has any administrative object(s) containing audit information that it is supposed to send to the clearinghouse (decision Block 1156). Audit information pertaining to several VDE objects 300 may be placed within the same administrative object for transmission, or different administrative objects may contain audit information about different objects. Assuming the end user's electronic apphance has at least one such administrative object to send to this particular clearinghouse ("yes" exit to decision Block 1156), the electronic apphance sends that administrative object to the clearinghouse via the now-established secure real-time communications (Block 1158). In one specific example, a single administrative object may be sent an administrative object containing audit information pertaining to multiple VDE objects, with the audit information for each different object compromising a separate "event" within the administrative object.

1480The clearinghouse may receive the administrative object and process its contents to determine whether the contents are "valid" and "legitimate." For example, the clearinghouse may analyze the contained audit information to deteπnine whether it indicates misuse of the apphcable VDE object 300. The clearinghouse may, as a result of this analysis, may generate one or more responsive administrative objects that it then sends to the end user's electronic apphance 600 (Block 1160). The end user's electronic apphance 600 may process events that update its secure database 610 and/or SPU 500 contents based on the administrative object received (Block 1162). For example, if the audit information received by the clearinghouse is legitimate, then the clearinghouse may send an administrative object to the end user's electronic apphance 600 requesting the electronic apphance to delete and/or compress the audit information that has been transfeπed. Alternatively or in addition, the clearinghouse may request additional infoπnation from the end- user electronic apphance 600 at this stage (e.g., retransmission of certain information that was corrupted during the initial transmission, transmission of additional information not earlier transmitted, etc.). If the clearinghouse detects misuse based on the received audit information, it may transmit an administrative object that revokes or otherwise modifies the end user's right to further access the associated VDE objects 300.

1481The clearinghouse may, in addition or alternatively, send an administrative object to the end user's electronic apphance 600 that instructs the electronic apphance to display one or more messages to the user. These messages may inform the user about certain conditions and/or they may request additional information from the user. For example, the message may instruct the end user to contact the clearinghouse directly by telephone or otherwise to resolve an indicated problem, enter a PIN, or it may instruct the user to contact a new service company to re-register the associated VDE object. Alternatively, the message may teU the end user that she needs to acquire new usage permissions for the object, and may inform the user of cost, status and other associated information.

1482During the same or different communications exchange, the same or different clearinghouse may handle the end user's request for additional budget and/or permission pertaining to VDE object 300. For example, the end user's electronic apphance 600 may (e.g., in response to a user input request to access a particular VDE object 300) send an administrative object to the clearinghouse requesting budgets and/or other permissions aUowing access (Block 1164). As mentioned above, such requests may be transmitted in the form of one or more administrative objects, such as, for example, a single administrative object having multiple "events" associated with multiple requested budgets and/or other permissions for the same or different VDE objects 300. The clearinghouse may upon receipt of such a request, check the end user's credit, financial records, business agreements and/or audit histories to determine whether the requested budgets and/or permissions should be given. The clearinghouse may, based on this analysis, send one or more responsive administrativ objects which cause the end user's electronic apphance 600 to update its secure database in response (Block 1166, 1168). This updating might, for example, comprise replacing an expired PERC 808 with a fresh one, modifying a PERC to provide additional (or lesser) rights, etc. Steps 1164-1168 may be repeated multiple times in the same or different communications session to provide further updates to the end user's secure database 610.

1483Figure 36 shows an example of how a new record or element may be inserted into secure database 610. The load process 1070 shown in Figure 35 checks each data element or item as it is loaded to ensure that it has not been tampered with, replaced or substituted. In the process 1070 shown in Figure 35, the first step that is performed is to check to see if the cuπent user of electronic apphance 600 is authorized to insert the item into secure database 610 (block 1072). This test may involve, in the prefeπed embodiment, loading (or using already loaded) appropriate methods 1000 and other data structures such as UDEs 1200 into an SPE 503, which then authenticates user authorization to make the change to secure database 610 (block 1074). If the user is approved as being authorized to make the change to secure database 610. then SPE 503 may check the integrity of the element to be added to the secure database by decrypting it (block 1076) and determining whether it has become damaged or corrupted (block 1078). The element is checked to ensure that it decrypts properly using a predetermined management file key, and the check value may be vahdated. In addition, the pubhc and private header ID tags (if present) may be compared to ensure that the proper element has been provided and had not been substituted, and the unique element tag ID compared against the predetermined element tag. If any of these tests faU, the element may be automaticaUy rejected, eπor coπected, etc. Assuming the element is found to have integrity, SPE 503 may re-encrypt the information (block 1080) using a new key for example (see Figure 37 discussion below). In the same process step an appropriate tag is preferably provided so that the information becomes encrypted within a security wrapper having appropriate tags contained therein (block 1082). SPE 503 may retain appropriate tag information so that it can later vahdate or otherwise authenticate the item when it is again read from secure database 610 (block 1084). The now-secure element within its security wrapper may then be stored within secure database 610.

1484Figure 37 shows an example of a process 1050 used in the prefeπed embodiment database to securely access an item stored in secure database 610. In the prefeπed embodiment, SPE 503 first accesses and reads in the item from secure database 610 records. SPE 503 reads this information from secure database 610 in encrypted foπn, and may "unwrap" it (block 1052) by decrypting it (block 1053) based on access keys internaUy stored within the protected memory of an SPU 500. In the preferred embodiment, this "unwrap" process 1052 involves sending blocks of information to encrypt decrypt engine 522 along with a management file key and other necessary information needed to decrypt. Decrypt engine 522 may return "plaintext" information that SPE 503 then checks to ensure that the security of the object has not been breached and that the object is the proper object to be used (block 1054). SPE 503 may then check aU coπelation and access tags to ensure that the read-in element has not been substituted and to guard against other security threats (block 1054). Part of this "checking" process involves checking the tags obtained from the secure database 610 with tags contained within the secure memory or an SPU 500 (block 1056). These tags stored within SPU 500 may be accessed from SPU protected memory (block 1056) and used to check further the now- unwrapped object. Assuming this "checking" process 1054 does not reveal any improprieties (and block 1052 also indicates that the object has not become corrupted or otherwise damaged), SPE 503 may then access or otherwise use the item (block 1058). Once use of the item is completed, SPE 503 may need to store the item back into secure database 610 if it has changed. If the item has changed. SPE 503 will send the item in its changed form to encrypt decrypt engine 522 for encryption (block 1060), providing the appropriate necessary information to the encrypt decrypt engine (e.g., the appropriate same or different management file key and data) so that the object is appropriately encrypted. A unique, new tag and/or encryption key may be used at this stage to uniquely tag and/or encrypt the item security wrapper (block 1062; see also detailed Figure 37 discussion below). SPE 503 may retain a copy of the key and/or tag within a protected memory of SPU 500 (block 1064) so that the SPE can decrypt and vahdate the object when it is again read from secure database 610.

1485The keys to decrypt secure database 610 records are, in the prefeπed embodiment, maintained solely within the protected memory of an SPU 500. Each index or record update that leaves the SPU 500 may be time stamped, and then encrypted with a unique key that is determined by the SPE 503. For example, a key identification number may be placed "in plain view" at the front of the records of secure database 610 so the SPE 503 can determine which key to use the next time the record is retrieved. SPE 503 can maintain the site ED of the record or index, the key identification number associated with it, and the actual keys in the list internal to the SPE. At some point, this internal hst may fill up. At this point, SPE 503 may caU a maintenance routine that re-encrypts items within secure database 610 containing changed information. Some or aU of the items within the data structure containing changed information may be read in, decrypted, and then re-encrypted with the same key. These items may then be issued the same key identification number. The items may then be written out of SPE 503 back into secure database 610. SPE 503 may then clear the internal list of item IDs and coπesponding key identification numbers. It may then begin again the process of assigning a different key and a new key identification number to each new or changed item. By using this process, SPE 503 can protect the data structures (including the indexes) of secure database 610 against substitution of old items and against substitution of indexes for cuπent items. This process also aUows SPE 503 to vahdate retrieved item IDs against the encrypted list of expected IDs.

1486Figure 38 is a flowchart showing this process in more detaU. Whenever a secure database 610 item is updated or modified, a new encryption key can be generated for the updated item. Encryption using a new key is performed to add security and to prevent misuse of backup copies of secure database 610 records. The new encryption key for each updated secure database 610 record may be stored in SPU 500 secure memory with an indication of the secure database record or record(s) to which it apphes. SPE 503 may generate a new encryption/decryption key for each new item it is going to store within secure database 610 (block 1086). SPE 503 may use this new key to encrypt the record prior to storing it in the secure database (block 1088). SPE 503 make sure that it retains the key so that it can later read and decrypt the record. Such decryption keys are, in the prefeπed embodiment, maintained within protected non-volatile memory (e.g., NVRAM 534b) within SPU 500. Since this protected memory has a hmited size, there may not be enough room within the protected memory to store a new key. This condition is tested for by decision block 1090 in the prefeπed embodiment. If there is not enough room in memory for the new key (or some other event such as the number of keys stored in the memory exceeding a predetermined number, a timer has expired, etc.), then the prefeπed embodiment handles the situation by re- encrypting other records with secure database 610 with the same new key in order to reduce the number of (or change) encryption/decryption keys in use. Thus, one or more secure database 610 items may be read from the secure database (block 1092), and decrypted using the old key(s) used to encrypt them the last time they were stored. In the prefeπed embodiment, one or more "old keys" are selected, and aU secure database items encrypted using the old key(s) are read and decrypted. These records may now be re-encrypted using the new key that was generated at block 1086 for the new record (block 1094). The old key(s) used to decrypt the other record(s) may now be removed from the SPU protected memory (block 1096), and the new key stored in its place (block 1097). The old key(s) cannot be removed from secure memory by block 1096 unless SPE 503 is assured that aU records within the secure database 610 that were encrypted using the old key(s) have been read by block 1092 and re-encrypted by block 1904 using the new key. AU records encrypted (or re-encrypted) using the new key may now be stored in secure database 610 (block 1098). If decision block 1090 determines there is room within the SPU 500 protected memory to store the new key, then the operations of blocks 1092, 1094, 1096 are not needed and SPE 503 may instead simply store the new key within the protected memory (block 1097) and store the new encrypted records into secure database 610 (block 1098).

1487The security of secure database 610 files may be further improved by segmenting the records into "compartments." Different encryption/decryption keys may be used to protect different "compartments." This strategy can be used to limit the amount of information within secure database 610 that is encrypted with a single key. Another technique for increasing security of secure database 610 may be to encrypt different portions of the same records with different keys so that more than one key may be needed to decrypt those records. Backup of Secure Database 610

1488Secure database 610 in the preferred embodiment is backed up at periodic or other time intervals to protect the information the secure database contains. This secure database information may be of substantial value to many VDE participants. Back ups of secure database 610 should occur without significant inconvenience to the user, and should not breach any security.

1489The need to back up secure database 610 may be checked at power on of electronic apphance 600, when SPE 503 is initiaUy invoked, at periodic time intervals, and if "audit roU up" value or other summary services information maintained by SPE 503 exceeds a user set or other threshold, or triggered by criteria established by one or more content publishers and/or distributors and/or clearinghouse service providers and/or users. The user may be prompted to backup if she has faUed to do so by or at some certain point in time or after a certain duration of time or quantity of usage, or the backup may proceed automaticaUy without user intervention.

1490Referring to Figure 8, backup storage 668 and storage media 670 (e.g., magnetic tape) may be used to store backed up information. Of course, any non-volatile media (e.g., one or more floppy diskettes, a writable optical diskette, a hard drive, or the like) may be used for backup storage 668.

1491There are at least two scenarios to backing up secure database 610. The first scenario is "site specific," and uses the security of SPU 500 to support restoration of the backed up information. This first method is used in case of damage to secure database 610 due for example to faUure of secondary storage device 652, inadvertent user damage to the files, or other occurrences that may damage or corrupt some or aU of secure database 610. This first, site specific scenario of back up assumes that an SPU 500 stiU functions properly and is avaUable to restore backed up information.

1492The second back up scenario assumes that the user's SPU 500 is no longer operational and needs to be, or has been, replaced. This second approach permits an authorized VDE administrator or other authorized VDE participant to access the stored back up information in order to prevent loss of critical data and/or assist the user in recovering from the error.

1493Both of these scenarios are provided by the example of program control steps performed by ROS 602 shown in Figure 39. Figure 39 shows an example back up routine 1250 performed by an electronic apphance 600 to back up secure database 610 (and other infoπnation) onto back up storage 668. Once a back up has been initiated, as discussed above, back up routine 1250 generates one or more back up keys (block 1252). Back up routine 1250 then reads aU secure database items, decrypts each item using the original key used to encrypt them before they were stored in secure database 610 (block 1254). Since SPU 500 is typicaUy the only place where the keys for decrypting this information within an instance of secure database 610 are stored, and since one of the scenarios provided by back up routine 1250 is that SPU 500 completely faUed or is destroyed, back up routine 1250 performs this reading and decrypting step 1254 so that recovery from a backup is not dependent on knowledge of these keys within the SPU. Instead, back up routine 1250 encrypts each secure database 610 item with a newly generated back up key(s) (block 1256) and writes the encrypted item to back up store 668 (block 1258). This process continues until aU items within secure database 610 have been read, decrypted, encrypted with a newly generated back up key(s), and written to the back up store (as tested for by decision block 1260).

1494The prefeπed embodiment also reads the summary services audit information stored within the protected memory of SPU 500 by SPE summary services manager 560, encrypts this information with the newly generated back up key(s), and writes this summary services information to back up store 668 (block 1262).

1495FinaUy, back up routine 1250 saves the back up key(s) generated by block 1252 and used to encrypt in blocks 1256, 1262 onto back up store 668. It does this in two secure ways in order to cover both of the restoration scenarios discussed above. Back up routine 1250 may encrypt the back up key(s) (along with other information such as the time of back up and other appropriate information to identify the back up) with a further key or keys such that only SPU 500 can decrypt (block 1264). This encrypted information is then written to back up store 668 (block 1264). For example, this step may include multiple encryptions using one or more pubhc keys with coπesponding private keys known only to SPU 500. Alternatively, a second back up key generated by the SPU 500 and kept only in the SPU may be used for the final encryption in place of a pubhc key. Block 1264 preferably includes multiple encryption in order to make it more difficult to attack the security of the back up by "cracking" the encryption used to protect the back up keys. Although block 1262 includes encrypted summary services information on the back up, it preferably does not include SPU device private keys, shared keys, SPU code and other internal security information to prevent this information from ever becoming avaUable to users even in encrypted form. The information stored by block 1264 is sufficient to aUow the same SPU 500 that performed (or at least in part performed) back up routine 1250 to recover the backed up information. However, this information is useless to any device other than that same SPU because only that SPU knows the particular keys used to protect the back up keys. To cover the other possible scenario wherein the SPU 500 fails in a non-recoverable way, back up routine 1250 provides an additional step (block 1266) of saving the back up key(s) under protection of one or more further set of keys that may be read by an authorized VDE administrator. For example, block 1266 may encrypt the back up keys with an "download authorization key" received during initiahzation of SPU 500 from a VDE administrator. This encrypted version of back up keys is also written to back up store 668 (block 1266). It can be used to support restoration of the back up files in the event of an SPU 500 faUure. More specificaUy, a VDE administrator that knows the download authorization (or other) keys(s) used by block 1266 may be able to recover the back up key(s) in the back up store 668 and proceed to restore the backed up secure database 610 to the same or different electronic apphance 600.

1496In the prefeπed embodiment, the information saved by • routine 1250 in back up files can be restored only after receiving a back up authorization from an authorized VDE administrator. In most cases, the restoration process wUl simply be a restoration of secure database 610 with some adjustments to account for any usage since the back up occurred. This may require the user to contact additional providers to transmit audit and hilling data and receive new budgets to reflect activity since the last back up. Current summary services information maintained within SPU 500 may be compared to the summary services information stored on the back up to determine or estimate most recent usage activity.

1497In case of an SPU 500 faUure, an authorized VDE administrator must be contacted to both initialize the replacement SPU 500 and to decrypt the back up files. These processes aUow for both SPU faUures and upgrades to new SPUs. In the case of restoration, the back up files are used to restore the necessary information to the user's system. In the case of upgrades, the back up files may be used to vahdate the upgrade process.

1498The back up files may in some instances be used to transfer management information between electronic apphances 600. However, the prefeπed embodiment may restrict some or all information from being transportable between electronic .apphances with appropriate authorizations. Some or all of the back up files may be packaged within an administrative object and transmitted for analysis, transportation, or other uses.

1499As a more detaUed example of a need for restoration from back up files, suppose an electronic apphance 600 suffers a hard disk failure or other accident that wipes out or corrupts part or all of the secure database 610, but assume that the SPU 500 is still functional. SPU 500 may include aU of the information (e.g., secret keys and the hke) it needs to restore the secure database 610. However, ROS 602 may prevent secure database restoration until a restoration authorization is received from a VDE administrator. A restoration authorization may comprise, for example, a "secret value" that must match a value expected by SPE 503. A VDE administrator may, if desired, only provide this restoration authorization after, for example, summary services information stored within SPU 500 is transmitted to the administrator in an administrative object for analysis. In some circumstances, a VDE administrator may require that a copy (partial or complete) of the back up files be transmitted to it within an administrative object to check for indications of fraudulent activities by the user. The restoration process, once authorized, may require adjustment of restored budget records and the like to reflect activity since the last back up, as mentioned above. Figure 40 is an example of program controUed "restore" routine 1268 performed by electronic apphance 600 to restore secure database 610 based on the back up provided by the routine shown in Figure 38. This restore may be used, for example, in the event that an electronic apphance 600 has failed but can be recovered or "reinitialized" through contact with a VDE administrator for example. Since the preferred embodiment does not permit an SPU 500 to restore from backup unless and until authorized by a VDE administrator, restore routine 1268 begins by establishing a secure communication with a VDE administrator that can authorize the restore to occur (block 1270). Once SPU 500 and the VDE administrator authenticate one another (part of block 1270), the VDE administrator may extract "work in progress" and summary values from the SPU 500's internal non-volatUe memory (block 1272). The VDE administrator may use this extracted information to help determine, for example, whether there has been a security violation, and also permits a faUed SPU 500 to effectively "dump" its contents to the VDE administrator to permit the VDE administrator to handle the contents. The SPU 500 may encrypt this information and provide it to the VDE administrator packaged in one or more administrative objects. The VDE administrator may then request a copy of some or aU of the cuπent backup of secure database 610 from the SPU 500 (block 1274). This information may be packaged by SPU 500 into one or more administrative objects, for example, and sent to the VDE administrator. Upon receiving the information, the VDE administrator may read the summary services audit information from the backup volume (i.e., information stored by Figure 38 block 1262) to determine the summary values and other information stored at time of backup. The VDE administrator may also determine the time and date the backup was made by reading the information stored by Figure 38 block 1264.

1500The VDE administrator may at this point restore the summary values and other information within SPU 500 based on the information obtained by block 1272 and from the backup (block 1276). For example, the VDE administrator may reset SPU internal summary values and counters so that they are consistent with the last backup. These values may be adjusted by the VDE administrator based on the "work in progress" recovered by block 1272, the amount of time that has passed since the backup, etc. The goal may typicaUy be to attempt to provide internal SPU values that are equal to what they would have been had the faUure not occurred.

1501The VDE administrator may then authorize SPU 500 to recover its secure database 610 from the backup files (block 1278). This restoration process replaces aU secure database 610 records with the records from the backup. The VDE administrator may adjust these records as needed by passing commands to SPU 500 during or after the restoration process.

1502The VDE administrator may then compute bills based on the recovered values (block 1280), and perform other actions to recover from SPU downtime (block 1282). TypicaUy, the goal is to bill the user and adjust other VDE 100 values pertaining to the failed electronic apphance 600 for usage that occurred subsequent to the last backup but prior to the faUure. This process may involve the VDE administrator obtaining, from other VDE participants, reports and other information pertaining to usage by the electronic apphance prior to its faUure and comparing it to the secure database backup to determine which usage and other events are not yet accounted for.

1503In one alternate embodiment, SPU 500 may have sufficient internal, non-volatile memory to aUow it to store some or aU of secure database 610. In this embodiment, the additional memory may be provided by additional one or more integrated circuits that can be contained vrithin a secure enclosure, such as a tamper resistant metal container or some form of a chip pack containing multiple integrated circuit components, and which impedes and/or evidences tampering attempts, and/or disables a portion or aU of SPU 500 or associated critical key and/or other control information in the event of tampering. The same back up routine 1250 shown in Figure 38 may be used to back up this type of information, the only difference being that block 1254 may read the secure database item from the SPU internal memory and may not need to decrypt it before encrypting it with the back up key(s).

1504Event-Driven VDE Processes

1505As discussed above, processes provided by/under the prefeπed embodiment rights operating system (ROS) 602 may be "event driven." This "event driven" capabihty facilitates integration and extendibility.

1506An "event" is a happening at a point in time. Some examples of "events" are a user striking a key of a keyboard, arrival of a message or an object 300, expiration of a timer, or a request from another process.

1507In the preferred embodiment, ROS 602 responds to an "event" by performing a process in response to the event. ROS 602 dynamicaUy creates active processes and tasks in response to the occuπence of an event. For example, ROS 602 may create and begin executing one or more component assembhes 690 for performing a process or processes in response to occuπence of an •event. The active processes and tasks may terminate once ROS 602 has responded to the event. This abihty to dynamicaUy create (and end) tasks in response to events provides great flexibihty, and also permits limited execution resources such as those provided by an SPU 500 to perform a virtuaUy unlimited variety of different processes in different contexts.

1508Since an "event" may be any type of happening, there are an unlimited number of different events. Thus, any attempt to categorize events into different types will necessarily be a generalization. Keeping this in mind, it is possible to categorize events provided/supported by the preferred embodiment into two broad categories:

1509• user-initiated events; and

1510• system-initiated events.

1511GeneraUy, "user-initiated" events are happenings attributable to a user (or a user apphcation). A common "user- initiated" event is a user's request (e.g., by pushing a keyboard button, or transparently using redirector 684) to access an object 300 or other VDE-protected information.

1512"System-initiated" events are generaUy happenings not attributable to a user. Examples of system initiated events include the expiration of a timer indicating that information should be backed to non-volatile memory, receipt of a message from another electronic apphance 600, and a service caU generated by another process (which may have been started to respond to a system-initiated event and/or a user-initiated event).

1513ROS 602 provided by the preferred embodiment responds to an event by specifying and beginning processes to process the event. These processes are, in the preferred embodiment, based on methods 1000. Since there are an unlimited number of different types of events, the preferred embodiment supports an unlimited number of different processes to process events. This flexibihty is supported by the dynamic creation of component assembhes 690 from independently dehverable modules such as method cores 1000', load modules 1100, and data structures such as UDEs 1200. Even though any categorization of the unlimited potential types of processes supported/provided by the prefeπed embodiment will be a generalization, it is possible to generaUy classify processes as falling within two categories:

1514• processes relating to use of VDE protected infoπnation; and

1515• processes relating to VDE administration.

1516"Use'and "Adjnijiistrative "Processes

1517"Use" processes relate in some way to use of VDE-protected information. Methods 1000 provided by the preferred embodiment may provide processes for creating and maintaining a chain of control for use of VDE-protected information. One specific example of a "use" type process is processing to permit a user to open a VDE object 300 and access its contents. A method 1000 may provide detaUed use-related processes such as, for example, releasing content to the user as requested (if permitted), and updating meters, budgets, audit traUs, etc. Use- related processes are often user-initiated, but some use processes may be system-initiated. Events that trigger a VDE use-related process may be caUed "use events."

1518An "administrative" process helps to keep VDE 100 working. It provides processing that helps support the transaction management "infrastructure" that keeps VDE 100 running securely and efficiently. Administrative processes may, for example, provide processing relating to some aspect of creating, modifying and/or destroying VDE-protected data structures that establish and maintain VDE's chain of handhng and control. For example, "administrative" processes may store, update, modify or destroy information contained within a VDE electronic apphance 600 secure database 610. Administrative processes also may provide communications services that establish, maintain and support secure communications between different VDE electronic apphances 600. Events that trigger administrative processes may be caUed "administrative events." Reciprocal Methods

1519Some VDE processes are paired based on the way they interact together. One VDE process may "request" processing services from another VDE process. The process that requests processing services may be caUed a "request process." The "request" constitutes an "event" because it triggers processing by the other VDE process in the pair. The VDE process that responds to the "request event" may be called a "response process." The "request process" and "response process" may be caUed "reciprocal processes."

1520The "request event" may comprise, for example, a message issued by one VDE node electronic apphance 600 or process for certain information. A coπesponding "response process" may respond to the "request event" by, for example, sending the information requested in the message. This response may itself constitute a "request event" if it triggers a further VDE "response process." For example, receipt of a message in response to an earlier-generated request may trigger a "reply process." This "reply process" is a special type of "response process" that is triggered in response to a "reply" from another "response process." There may be any number of "request" and "response" process pairs within a given VDE transaction. A "request process" and its paired "response process" may be performed on the same VDE electronic apphance 600, or the two processes may be performed on different VDE electronic apphances. Communication between the two processes in the pair may be by way of a secure (VDE-protected) communication, an "out of channel" communication, or a combination of the two.

1521Figures 41a-41d are a set of examples that show how the chain of handhng and control is enabled using "reciprocal methods." A chain of handling and control is constructed, in part, using one or more pairs of "reciprocal events" that cooperate in request-response manner. Pairs of reciprocal events may be managed in the preferred embodiment in one or more "reciprocal methods." As mentioned above, a "reciprocal method" is a method 1000 that can respond to one or more "reciprocal events." Reciprocal methods contain the two halves of a cooperative process that may be securely executed at physicaUy and/or temporaUy distant VDE nodes. The reciprocal processes may have a flexibly defined information passing protocols and information content structure. The reciprocal methods may, in fact, be based on the same or different method core 1000' operating in the same or different VDE nodes 600. VDE nodes 600 A and 600B shown in Figure 41a may be the same physical • electronic apphance 600 or may be separate electronic apphances. Figure 41a is an example of the operation of a single pair of reciprocal events. In VDE node 600A, method 1000a is processing an event that has a request that needs to be processed at VDE node 600B. The method 1000a (e.g., based on a component assembly 690 including its associated load modules 1100 and data) that responds to this "request" event is shown in Figure 41a as 1450. The process 1450 creates a request (1452) and, optionaUy, some information or data that will be sent to the other VDE node 1000b for processing by a process associated with the reciprocal event. The request and other information may be transmitted by any of the transport mechanisms described elsewhere in this disclosure.

1522Receipt of the request by VDE node 600b comprises a response event at that node. Upon receipt of the request, the VDE node 600b may perform a "reciprocal" process 1454 defined by the same or different method 1000b to respond to the response event. The reciprocal process 1454 may be based on a component assembly 690 (e.g., one or more load modules 1100, data, and optionaUy other methods present in the VDE node 600B).

1523Figure 41b extends the concepts presented in Figure 41a to include a response from VDE node 600B back to VDE node 600A. The process starts as described for Figure 41a through the receipt and processing of the request event and information 1452 by the response process 1454 in VDE node 600B. The response process 1454 may, as part of its processing, cooperate with another request process (1468) to send a response 1469 back to the initiating VDE node 600A. A corresponding reciprocal process 1470 provided by method 1000A may respond to and process this request event 1469. In this manner, two or more VDE nodes 600A, 600B may cooperate and pass configurable information and requests between methods 1000A, 1000B executing in the nodes. The first and second request-response sequences [(1450, 1452, 1454) and (1468, 1469, 1470)] may be separated by temporal and spatial distances. For efficiency, the request (1468) and response (1454) processes may be based on the same method 1000 or they may be implemented as two methods in the same or different method core 1000 ' . A method 1000 may be parameterized by an "event code" so it may provide different behaviors/results for different events, or different methods may be provided for different events.

1524Figure 41c shows the extension the control mechanism described in Figures 41a-41b to three nodes (600A, 600B, 600C). Each request -response pair operates in the manner as described for Figure 41b, with several pairs linked together to form a chain of control and handhng between several VDE nodes 600 A, 600B, 600C. This mechanism may be used to extend the chain of handling and control to an arbitrary number of VDE nodes using any configuration of nodes. For example, VDE node 600C might communicate directly to VDE node 600A and communicate directly to VDE 600B, which in turn communicates with VDE node 600A. Alternately, VDE node 600C might communicate directly with VDE node 600A, VDE node 600A may communicate with VDE node 600B, and VDE node 600B may communicate with VDE node 600C.

1525A method 1000 may be parameterized with sets of events that specify related or cooperative functions. Events may be logicaUy grouped by function (e.g., use, distribute), or a set of reciprocal events that specify processes that may operate in conjunction with each other. Figure 4 Id iUustrates a set of "reciprocal events" that support cooperative processing between several VDE nodes 102, 106, 112 in a content distribution model to support the distribution of budget. The chain of handhng and control, in this example, is enabled by using a set of "reciprocal events" specified within a BUDGET method. Figure 4 Id is an example of how the reciprocal event behavior within an example BUDGET method (1510) work in cooperation to estabhsh a chain of handling and control between several VDE nodes. The example BUDGET method 1510 responds to a "use" event 1478 by performing a "use" process 1476 that defines the mechanism by which processes are budgeted. The BUDGET method 1510 might, for example, specify a use process 1476 that compares a meter count to a budget value and fail the operation if the meter count exceeds the budget value. It might also write an audit traU that describes the results of said BUDGET decisions. Budget method 1510 may respond to a "distribute" event by performing a distribute process 1472 that defines the process and/or control information for further distribution of the budget. It may respond to a "request" event 1480 by performing a request process 1480 that specifies how the user might request use and/or distribution rights from a distributor. It may respond to a "response" event 1482 by performing a response process 1484 that specifies the manner in which a distributor would respond to requests from other users to whom they have distributed some (or all) of their budget to. It may respond to a "reply" event 1474 by performing a reply process 1475 that might specify how the user should respond to message regranting or denying (more) budget.

1526Control of event processing, reciprocal events, and their associated methods and method components is provided by PERCs 808 in the prefeπed embodiment. These PERCs (808) might reference administrative methods that govern the creation, modification, and distribution of the data structures and administrative methods that permit access, modification, and further distribution of these items. In this way, each link in the chain of handhng and control might, for example, be able to customize audit information, alter the budget requirements for using the content, and/or control further distribution of these rights in a manner specified by prior members along the distribution chain.

1527In the example shown in Figure 4 Id, a distributor at a VDE distributor node (106) might request budget from a content creator at another node (102). This request may be made in the context of a secure VDE communication or it may be passed in an "out-of-channel" communication (e.g. a telephone caU or letter). The creator 102 may decide to grant budget to the distributor 106 and processes a distribute event (1452 in BUDGET method 1510 at VDE node 102). A result of processing the distribute event within the BUDGET method might be a secure communication (1454) between VDE nodes 102 and 106 by which a budget granting use and redistribute rights to the distributor 106 may be transfeπed from the creator 102 to the distributor. The distributor's VDE node 106 may respond to the receipt of the budget information by processing the communication using the reply process 1475B of the BUDGET method 1510. The reply event processing 1475B might, for example, instaU a budget and PERC 808 within the distributor's VDE 106 node to permit the distributor to access content or processes for which access is control at least in part by the budget and/or PERC. At some point, the distributor 106 may also desire to use the content to which she has been granted rights to access.

1528After registering to use the content object, the user 112 would be required to utilize an array of "use" processes 1476C to, for example, open, read, write, and/or close the content object as part of the use process.

1529Once the distributor 106 has used some or aU of her budget, she may desire to obtain additional budget. The distributor 106 might then initiate a process using the BUDGET method request process (1480B). Request process 1480B might initiate a communication (1482AB) with the content creator VDE node 102 requesting more budget and perhaps providing details of the use activity to date (e.g., audit trails). The content creator 102 processes the 'get more budget' request event 1482AB using the response process (1484A) within the creator's BUDGET method 1510A. Response process 1484A might, for example, make a determination if the use information indicates proper use of the content, and/or if the distributor is credit worthy for more budget. The BUDGET method response process 1484A might also initiate a financial transaction to transfer funds from the distributor to pay for said use, or use the distribute process 1472A to distribute budget to the distributor 106. A response to the distributor 106 granting more budget (or denying more budget) might be sent immediately as a response to the request communication 1482AB, or it might be sent at a later time as part of a separate communication. The response communication, upon being received at the distributor's VDE node 106, might be processed using the reply process 1475B within the distributor's copy of the BUDGET method 1510B. The reply process 1475B might then process the additional budget in the same manner as described above.

1530The chain of handling and control may, in addition to posting budget information, also pass control information that governs the manner in which said budget may be utilized. For example, the control information specified in the above example may also contain control information describing the process and limits that apply to the distributor's redistribution of the right to use the creator's content object. Thus, when the distributor responds to a budget request from a user (a communication between a user at VDE node 112 to the distributor at VDE node 106 simUar in nature to the one described above between VDE nodes 106 and 102) using the distribute process 1472B within the distributor's copy of the BUDGET method 1510B, a distribution and request/response/reply process simUar to the one described above might be initiated. Thus, in this example a single method can provide multiple dynamic behaviors based on different "triggering" events. For example, single BUDGET method 1510 might support any or aU of the events listed below:

1531Eτ«nt Type Eτ«nt Proc-tia Description

1532"Use" Events use budget Use budget.

1533Request Events request more budget Request more monev for budget. Processed by User request audit by auditor #1 Request that auditor #1 audit the Node Request Process budget use. 1480c request budget deletion Request that budget be deleted from system. request method updated Update method used for auditing. request to change auditors Change from auditor 1 to auditor 2, or vice versa. request different audit Change time interval between audits. interval request ability to provide Request ability to provide copies of a budget copies budget. request ability to Request ability to distribute a budget distribute budget to other users. request account status Request information on current status of an account.

1534Request New Method Request new method.

1535Request Method Update Request update of method

1536Request Method Deletion Request deletion of method.

1537Response Events receive more budget Allocate more monev to budget. Processed by User receive method update Update method. Node Request Process 1480C receive auditor change Change from one auditor to another receive change to audit Change interval between audits. interval Efβnt Type Eτ*nt Process Description receive budget deletion Delete budget. provide audit to auditor #1 Forward audit information to auditor #1. provide audit to auditor #2 Forward audit information to auditor #2. receive account status Provide account status.

1538Receive New Receive new budget.

1539Receive Method Update Receive updated information.

1540Receive More Receive more for budget.

1541Sent Audit Send audit information.

1542Perform Deletion Delete information.

1543"Distribute" Events Create New Create new budget.

1544Provide More Provide more for budget.

1545Audit Perform audit.

1546Delete Delete information.

1547Reconcile Reconcile budget and auditing.

1548Copy Copy budget.

1549Distribute Distribute budget.

1550Method Modification Modifv method.

1551Display Method Displav requested method.

1552"Request" Events Delete Delete information. Processed by Distributor Node Get New Get new budget. Request Process Get More Get more for budget. 1484B

1553Get Updated Get updated information.

1554Get Audited Get audit information.

1555"Response Events'" Provide New to user Provide new budget to user Processed by Distributor Node Provide More to user Provide more budget to user Request Process Provide Update to user Provided updated budget to user

15561484B Event Type Event Pro eaa Deacxiption

1557Audit user Audit a specified user.

1558Delete user's method Delete method belonging to user.

1559Examples of Reciprocal Method Processes

A. BUDGET

1561Figures 42a, 42b, 42c and 42d, respectively, are flowcharts of example process control steps performed by a representative example of BUDGET method 2250 provided by the prefeπed embodiment. In the prefeπed embodiment, BUDGET method 2250 may operate in any of four different modes:

1562• use (see Figure 42a)

1563• administrative request (see Figure 42b)

1564• administrative response (see Figure 42c)

1565• administrative reply (see Figure 42d).

1566In general, the "use" mode of BUDGET method 2250 is invoked in response to an event relating to the use of an object or its content. The "administrative request" mode of BUDGET method 2250 is invoked by or on behalf of the user in response to some user action that requires contact with a VDE financial provider, and basicaUy its task is to send an administrative request to the VDE financial provider. The "adπ-inistrative response" mode of BUDGET method 2250 is performed at the VDE financial provider in response to receipt of an administrative request sent from a VDE node to the VDE financial provider by the ''administrative request" invocation of BUDGET method 2250 shown in Figure 42b. The "administrative response" invocation of BUDGET method 2250 results in the transmission of an administrative object from VDE financial provider to the VDE user node. FinaUy, the "administrative reply" invocation of BUDGET method 2250 shown in Figure 42d is performed at the user VDE node upon receipt of the administrative object sent by the "administrative response" invocation of the method shown in Figure 42c.

1567In the prefeπed embodiment, the same BUDGET method 2250 performs each of the four different step sequences shown in Figures 42a-42d. In the preferred embodiment, different event codes may be passed to the BUDGET method 2250 to invoke these various different modes. Of course, it would be possible to use four separate BUDGET methods instead of a single BUDGET method with four different "dynamic personalities," but the prefeπed embodiment obtains certain advantages by using the same BUDGET method for each of these four types of invocations.

1568Looking at Figure 42a, the "use" invocation of BUDGET method 2250 first primes the Budget Audit TraU (blocks 2252, 2254). It then obtains the DTD for the Budget UDE, which it uses to obtain and read the Budget UDE blocks 2256-2262). BUDGET method 2250 in this "use" invocation may then determine whether a Budget Audit date has expired, and terminate if it has ("yes" exit to decision block 2264; blocks 2266, 2268). So long as the Budget Audit date has not expired, the method may then update the Budget using the atomic element and event counts (and possibly other information) (blocks 2270, 2272), and may then save a Budget User Audit record in a Budget Audit TraU UDE (blocks 2274, 2276) before terminating (at terrninate point 2278).

1569Looking at Figure 42b, the first six steps (blocks 2280- 2290) may be performed by the user VDE node in response to some user action (e.g., request to access new information, request for a new budget, etc.). This "administrative request" invocation of BUDGET method 2250 may prime an audit traU (blocks 2280, 2282). The method may then place a request for administrative processing of an appropriate Budget onto a request queue (blocks 2284, 2286). FinaUy, the method may save appropriate audit trail information (blocks 2288, 2290). Sometime later, the user VDE node may prime a communications audit traU (blocks 2292, 2294), and may then write a Budget Administrative Request into an administrative object (block 2296). This step may obtain information from the secure database as needed from such sources such as, for example, Budget UDE; Budget Audit TraU UDE(s); and Budget Administrative Request Record(s) (block 2298).

1570Block 2296 may then communicate the administrative object to a VDE financial provider, or alternatively, block 2296 may pass administrative object to a separate communications process or method that arranges for such communications to occur. If desired, method 2250 may then save a communications audit traU (blocks 2300, 2302) before terminating (at termination point 2304)

1571Figure 42c is a flowchart of an example of process control steps performed by the example of BUDGET method 2250 provided by the prefeπed embodiment operating in an "administrative response" mode. Steps shown in Figure 42c would, for example, be performed by a VDE financial provider who has received an administrative object containing a Budget administrative request as created (and communicated to a VDE administrator for example) by Figure 42b (block 2296).

1572Upon receiving the administrative object, BUDGET method 2250 at the VDE financial provider site may prime a budget communications and response audit traU (blocks 2306, ^• 2308), and may then unpack the administrative object and retrieve the budget request(s), audit traU(s and record(s) it contains (block 2310). This information retrieved from the adrninistrative object may be written by the VDE financial provider into its secure database (block 2312). The VDE financial provider may then retrieve the budget request(s) and determine the response method it needs to execute to process the request (blocks 2314, 2316). BUDGET method 2250 may send the event(s) contained in the request record(s) to the appropriate response method and may generate response records and response requests based on the RESPONSE method (block 2318). The process performed by block 2318 may satisfy the budget request by writing appropriate new response records into the VDE financial provider's secure database (block 2320). BUDGET method 2250 may then write these Budget administrative response records into an administrative object (blocks 2322, 2324), which it may then communicate back to the user node that initiated the budget request. BUDGET method 2250 may then save communications and response processing audit traU information into appropriate audit traU UDE(s) (blocks 2326, 2328) before terminating (at termination point 2330).

1573Figure 42d is a flowchart of an example of program control steps performed by a representative example of BUDGET method 2250 operating in an "administrative reply" mode. Steps shown in Figure 42d might be performed, for example, by a VDE user node upon receipt of an adrninistrative object containing budget- related information. BUDGET method 2250 may first prime a Budget administrative and communications audit traU (blocks 2332, 2334). BUDGET method 2250 may then extract records and requests from a received administrative object and write the reply record to the VDE secure database (blocks 2336, 2338). The VDE user node may then save budget administrative and communications audit traU information in an appropriate audit traU UDE(s) (blocks 2340, 2341).

1574Sometime later, the VDE user node may retrieve the reply record from the secure database and determine what method is required to process it (blocks 2344, 2346). The VDE user node may, optionaUy, prime an audit traU (blocks 2342, 2343) to record the results of the processing of the reply event. The BUDGET method 2250 may then send event(s) contained in the reply record(s) to the REPLY method, and may generate/update the secure database records as necessary to, for example, insert new budget records, delete old budget records and/or apply changes to budget records (blocks 2348, 2350). BUDGET method 2250 may then delete the reply record from the secure data base (blocks 2352, 2353) before writing the audit trail (if required) (blocks 2354m 2355) terminating (at terminate point 2356). B. REGISTER

1575Figures 43a-43d are flowcharts of an example of program control steps performed by a representative example of a REGISTER method 2400 provided by the preferred embodiment. In this example, the REGISTER method 2400 performs the example steps shown in Figure 43a when operating in a "use" mode, performs the example steps shown in Figure 43b when operating in an "administrative request" mode, performs the steps shown in Figure 43c when operating in an "administrative response" mode, and performs the steps shown in Figure 43d when operating in an "administrative reply" mode.

1576The steps shown in Figure 43a may be, for example, performed at a user VDE node in response to some action by or on behalf of the user. For example the user may ask to access an object that has not yet been (or is not now) properly registered to her. In response to such a user request, the REGISTER method 2400 may prime a Register Audit TraU UDE (blocks 2402, 2404) before determining whether the object being requested has already been registered (decision block 2406). If the object has already been registered ("yes" exit to decision block 2406), the REGISTER method may terminate (at termination point 2408). If the object is not already registered ("no" exit to decision block 2406), then REGISTER method 2400 may access the VDE node secure database PERC 808 and/or Register MDE (block 2410). REGISTER method 2400 may extract an appropriate Register Record Set from this PERC 808 and/or Register MDE (block 2412), and determine whether aU of the required elements are present that are needed to register the object (decision block 2414). If some piece(s) is missing ("no" exit to decision block 2414), REGISTER method 2400 may queue a Register request record to a communication manager and then suspend the REGISTER method until the queued request is satisfied (blocks 2416, 2418). Block 2416 may have the effect of communicating a register request to a VDE distributor, for example. When the request is satisfied and the register request record has been received (block 2420), then the test of decision block 2414 is satisfied ("yes" exit to decision block 2414), and REGISTER method 2400 may proceed. At this stage, the REGISTER method 2400 may aUow the user to select Register options from the set of method options aUowed by PERC 808 accessed at block 2410 (block 2422). As one simple example, the PERC 808 may permit the user to pay by VISA or MasterCard but not by American Express; block 2422 may display a prompt asking the user to select between paying using her VISA card and paying using her MasterCard (block 2424). The REGISTER method 2400 preferably validates the user selected registration options and requires the user to select different options if the initial user options were invalid (block 2426, "no" exit to decision block 2428). Once the user has made aU required registration option selections and those selections have been vahdated ("yes" exit to decision block 2428), the REGISTER method 2400 may write an User Registration Table (URT) corresponding to this object and this user which embodies the user registration selections made by the user along with other registration information required by PERC 808 and/or the Register MDE (blocks 2430, 2432). REGISTER method 2400 may then write a Register audit record into the secure database (blocks 2432, 2434) before terminating (at terminate point 2436).

1577Figure 43b shows an example of an "administrative request" mode of REGISTER method 2400. This Admi-oistrative Request Mode may occur on a VDE user system to generate an appropriate administrative object for communication to a VDE distributor or other appropriate VDE participant requesting registration information. Thus, for example, the steps shown in Figure 43b may be performed as part of the "queue register request record" block 2416 shown in Figure 43a. To make a Register admi-oistrative request, REGISTER method 2400 may first prime a communications audit traU (blocks 2440, 2442), and then access the secure database to obtain data about registration (block 2444). This secure database access may, for example, • aUow the owner and/or publisher of the object being registered to find out demographic, user or other information about the user. As a specific example, suppose that the object being registered is a spreadsheet software program. The distributor of the object may want to know what other software the user has registered. For example, the distributor may be willing to give preferential pricing if the user registers a "suite" of multiple software products distributed by the same distributor. Thus, the sort of information sohcited by a "user registration" card enclosed with most standard software packages may be sohcited and automaticaUy obtained by the prefeπed embodiment at registration time. In order to protect the privacy rights of the user, REGISTER method 2400 may pass such user-specific data through a privacy filter that may be at least in part customized by the user so the user can prevent certain information from being revealed to the outside world (block 2446). The REGISTER method 2400 may write the resulting information along with appropriate Register Request information identifying the object and other appropriate parameters into an administrative object (blocks 2448, 2450). REGISTER method 2400 may then pass this administrative object to a communications handler. REGISTER method 2400 may then save a communications audit traU (blocks 2452, 2454) before terminating (at terminate point 2456).

1578Figure 43c includes REGISTER method 2400 steps that may be performed by a VDE distributor node upon receipt of Register Administrative object sent by block 2448, Figure 43b. REGISTER method 2400 in this "administrative response" mode may prime appropriate audit trails (blocks 2460, 2462), and then may unpack the received adrninistrative object and write the associated register request(s) configuration information into the secure database (blocks 2464, 2466). REGISTER method 2400 may then retrieve the administrative request from the secure database and determine which response method to run to process the request (blocks 2468, 2470). If the user fails to provide sufficient information to register the object, REGISTER method 2400 may faU (blocks 2472, 2474). Otherwise, REGISTER method 2400 may send event(s) contained in the appropriate request record(s) to the appropriate response method, and generate and write response records and response requests (e.g., PERC(s) and/or UDEs) to the secure database (blocks 2476, 2478). REGISTER method 2400 may then write the appropriate Register administrative response record into an administrative object (blocks 2480, 2482). Such information may include, for example, one or more replacement PERC(s) 808, methods, UDE(s), etc. (block 2482). This enables, for example, a distributor to distribute limited right permissions giving users only enough information to register an object, and then later, upon registration, replacing the limited right permissions with wider permissioning scope granting the user more complete access to the objects. REGISTER method 2400 may then save the communications and response processing audit traU (blocks 2484, 2486), before terminating (at terminate point 2488).

1579Figure 43d shows steps that may be performed by the VDE user node upon receipt of the administrative object generated transmitted by Figure 43c block 2480. The steps shown in Figure 43d are very similar to those shown in Figure 42d for the BUDGET method administrative reply process.

C. AUDIT

1581Figures 44a-44c are flowcharts of examples of program control steps performed by a representative example of an AUDIT method 2520 provided by the preferred embodiment. As in the examples above, the AUDIT method 2520 provides three different operational modes in this prefeπed embodiment example: Figure 44a shows the steps performed by the AUDIT method in an "administrative request" mode; Figure 44b shows steps performed by the method in the "administrative response" mode; and Figure 44c shows the steps performed by the method in an "administrative reply" mode.

1582The AUDIT method 2520 operating in the "administrative request" mode as shown in Figure 44a is typicaUy performed, for example, at a VDE user node based upon some request by or on behalf of the user. For example, the user may have requested an audit, or a timer may have expired that initiates communication of audit information to a VDE content provider or other VDE participant. In the preferred embodiment, different audits of the same overaU process may be performed by different VDE participants. A particular "audit" method 2520 invocation may be initiated for any one (or aU) of the involved VDE participants. Upon invocation of AUDIT method 2520, the method may prime an audit administrative audit traU (thus, in the preferred embodiment, the audit processing may itself be audited) (blocks 2522, 2524). The AUDIT method 2520 may then queue a request for administrative processing (blocks 2526, 2528), and then may save the audit administrative audit traU in the secure database (blocks 2530, 2532). Sometime later, AUDIT method 2520 may prime a communications audit traU (blocks 2534, 2536), and may then write Audit Adrninistrative Request(s) into one or more administrative object(s) based on specific UDE, audit traU UDE(s), and/or administrative record(s) stored in the secure database (blocks 2538, 2540). The AUDIT method 2520 may then save appropriate information into the communications audit traU (blocks 2542, 2544) before terminating (at terminate point 2546).

1583Figure 44b shows example steps performed by a VDE content provider, financial provider or other auditing VDE node upon receipt of the administrative object generated and communicated by Figure 44a block 2538. The AUDIT method 2520 in this "administrative response" mode may first prime an Audit communications and response audit traU (blocks 2550, 2552), and may then unpack the received administrative object and retrieve its contained Audit request(s) audit traU(s) and audit record(s) for storage into the secured database (blocks 2554, 2556). AUDIT method 2520 may then retrieve the audit request(s) from the secure database and determine the response method to run to process the request (blocks 2558, 2560). AUDIT method 2520 may at this stage send event(s) contained in the request record(s) to the appropriate response method, and generate response record(s) and requests based on this method (blocks 2562, 2564), The processing block 2562 may involve a communication to the outside world.

1584For example, AUDIT method 2520 at this point could caU an external process to perform, for example, an electronic funds transfer against the user's bank account or some other bank account. The AUDIT administrative response can, if desired, caU an external process that interfaces VDE to one or more existing computer systems. The external process could be passed the user's account number, PIN, doUar amount, or any other information configured in, or associated with, the VDE audit traU • being processed. The external process can communicate with non-VDE hosts and use the information passed to it as part of these communications. For example, the external process could generate automated clearinghouse (ACH) records in a file for submittal to a bank. This mechanism would provide the abihty to automaticaUy credit or debit a bank account in any financial institution. The same mechanism could be used to communicate with the existing credit card (e.g. VISA) network by submitting VDE based charges against the charge account.

1585Once the appropriate Audit response record(s) have been generated, AUDIT method 2520 may write an Audit adrninistrative record(s) into an administrative object for communication back to the VDE user node that generated the Audit request (blocks 2566, 2568). The AUDIT method 2520 may then save communications and response processing audit information in appropriate audit traU(s) (blocks 2570, 2572) before terminating (at terminate point 2574).

1586Figure 44c shows an example of steps that may be performed by the AUDIT method 2520 back at the VDE user node upon receipt of the administrative object generated and sent by Figure 44b, block 2566. The steps 2580-2599 shown in Figure 44c are similar to the steps shown in Figure 43d for the REGISTER method 2400 in the "administrative reply" mode. Briefly, these steps involve receiving and extracting appropriate response records from the administrative object (block 2584 j, and then processing the received information appropriately to update secure database records and perform any other necessary actions (blocks 2595, 2596).

1587Examples of Event-Driven Content-Based Methods

1588VDE methods 1000 are designed to provide a very flexible and highly modular approach to secure processing. A complete VDE process to service a "use event" may typicaUy be constructed as a combination of methods 1000. As one example, the typical process for reading content or other information from an object 300 may involve the foUowing methods:

1589• an EVENT method a METER method

1590• a BILLING method a BUDGET method.

1591Figure 45 is an example of a sequential series of methods performed by VDE 100 in response to an event. In this example, when an event occurs, an EVENT method 402 may "qualify" the event to determine whether it is significant or not. Not aU events are significant. For example, if the EVENT method 1000 in a control process dictates that usage is to be metered based upon number of pages read, then user request "events" for reading less than a page of information may be ignored. In another example, if a system event represents a request to read a certain number of bytes, and the EVENT method 1000 is part of a control process designed to meter paragraphs, then the EVENT method may evaluate the read request to determine how many paragraphs are represented in the bytes requested. This process may involve mapping to "atomic elements" to be discussed in more detail below.

1592EVENT method 402 filters out events that are not significant with regard to the specific control method involved. EVENT method 402 may pass on qualified events to a METER process 1404, which meters or discards the event based on its own particular criteria.

1593In addition, the preferred embodiment provides an optimization called "precheck." EVENT method process 402 may perform this "precheck" based on metering, billing and budget information to determine whether processing based on an event will be aUowed. Suppose, for example, that the user has already exceeded her budget with respect to accessing certain information content so that no further access is permitted. Although BUDGET method 408 could make this deteπnination, records and processes performed by BUDGET method 404 and/or BILLING method 406 might have to be "undone" to, for example, prevent the user from being charged for an access that was actuaUy denied. It may be more efficient to perform a "precheck" within EVENT method 402 so that fewer transactions have to be "undone."

1594METER method 404 may store an audit record in a meter "traU" UDE 1200, for example, and may also record information related to the event in a meter UDE 1200. For example, METER method 404 may increment or decrement a "meter" value vάthin a meter UDE 1200 each time content is accessed. The two different data structures (meter UDE and meter traU UDE) may be maintained to permit record keeping for reporting purposes to be maintained separately from record keeping for internal operation purposes, for example.

1595Once the event is metered by METER method 404, the metered event may be processed by a BILLING method 406. BILLING method 406 determines how much budget is consumed by the event, and keeps records that are useful for reconciliation of meters and budgets. Thus, for example, BILLING method 406 may read budget information from a budget UDE, record billing information in a billing UDE, and write one or more audit records in a billing traU UDE. WhUe some billing traU information may duphcate meter and/or budget trail information, the hilling traU information is useful, for example, to aUow a content creator 102 to expect a payment of a certain size, and serve as a reconciliation check to reconcUe meter traU information sent to creator 102 with budget traU information sent to, for example, an independent budget provider.

1596BILLING method 406 may then pass the event on to a BUDGET method 408. BUDGET method 408 sets limits and records transactional information associated with those limits For example, BUDGET method 408 may store budget information in a budget UDE, and may store an audit record in a budget traU UDE. BUDGET method 408 may result in a "budget remaining" field in a budget UDE being decremented by an amount specified by BILLING method 406.

1597The information content may be released, or other action taken, once the various methods 402, 404, 406, 408 have processed the event.

1598As mentioned above, PERCs 808 in the prefeπed embodiment may be provided with "control methods" that in effect "oversee" performance of the other required methods in a control process. Figure 46 shows how the required methods/processes 402, 404, 406, and 408 of Figure 45 can be organized and controUed by a control method 410. Control method 410 may caU, dispatch events, or otherwise invoke the •other methods 402, 404, 406, 408 and otherwise supervise the processing performed in response to an "event." Control methods operate at the level of control sets 906 within PERCs 808. They provide structure, logic, and flow of control between disparate acquired methods 1000. This mechanism permits the content provider to create any desired chain of processing, and also allows the specific chain of processing to be modified (within permitted limits) by downstream redistributors. This control structure concept provides great flexibihty.

1599Figure 47 shows an example of an "aggregate" method 412 which coUects METER method 404, BUDGET method 406 and BILLING method 408 into an "aggregate" processing flow. Aggregate method 412 may, for example, combine various elements of metering, budgeting and billing into a single method 1000. Aggregate method 412 may provide increased efficiency as a result of processing METER method 404, BUDGET method 406 and BILLING method 408 aggregately, but may decrease flexibihty because of decreased modularity.

1600Many different methods can be in effect simultaneously. Figure 48 shows an example of prefeπed embodiment event processing using multiple METER methods 404 and multiple BUDGET methods 1408. Some events may be subject to many different required methods operating independently or cumulatively. For example, in the example shown in Figure 48, meter method 404a may maintain meter traU and meter information records that are independent from the meter traU and meter information records maintained by METER method 404b. Similarly, BUDGET method 408a may maintain records independently of those records maintained by BUDGET method 408b. Some events may bypass BILLING method 408 whUe nevertheless being processed by meter method 404a and BUDGET method 408a. A variety of different variations are possible.

REPRESENTATIVE EXAMPLES OF VDE METHODS

1602Although methods 1000 can have virtuaUy unlimited variety and some may even be user-defined, certain basic "use" type methods are preferably used in the prefeπed embodiment to control most of the more fundamental object manipulation and other functions provided by VDE 100. For example, the foUowing high level methods would typicaUy be provided for object manipulation:

1603OPEN method

1604READ method

1605WRITE method

1606CLOSE method.

1607An OPEN method is used to control opening a container so its contents mav be accessed. A READ method is used to control the access to contents in a container. A WRITE method is used to control the insertion of contents into a container. A CLOSE method is used to close a container that has been opened.

1608Subsidiary methods are provided to perform some of the steps required by the OPEN, READ, WRITE and/or CLOSE methods. Such subsidiary methods may include the foUowing:

1609ACCESS method

1610PANIC method

1611ERROR method

1612DECRYPT method

1613ENCRYPT method

1614DESTROY content method

1615INFORMATION method

1616OBSCURE method

1617FINGERPRINT method

1618EVENT method.

1619CONTENT method

1620EXTRACT method

1621EMBED method

1622METER method

1623BUDGET method

1624REGISTER method

1625BILLING method

1626AUDIT method An ACCESS method may be used to physicaUy access content associated with an opened container (the content can be anywhere). A PANIC method may be used to disable at least a portion of the VDE node if a security violation is detected. An ERROR method may be used to handle eπor conditions. A DECRYPT method is used to decrypt encrypted information. An ENCRYPT method is used to encrypt information. A DESTROY content method is used to destroy the abihty to access specific content within a container. An INFORMATION method is used to provide pubhc information about the contents of a container. An OBSCURE method is used to devalue content read from an opened container (e.g., to write the word "SAMPLE" over a displayed image). A FINGERPRINT method is used to mark content to show who has released it from the secure container. An event method is used to convert events into different events for response by other methods.

1627Open

1628Figure 49 is a flowchart of an example of prefeπed embodiment process control steps for an example of an OPEN method 1500. Different OPEN methods provide different detaUed steps. However, the OPEN method shown in Figure 49 is a representative example of a relatively fuU-featured "open" method provided by the prefeπed embodiment. Figure 49 shows a macroscopic view of the OPEN method. Figures 49a-49f are together an example of detaUed program controUed steps performed to implement the method shown in Figure 49.

1629The OPEN method process starts with an "open event." This open event may be generated by a user apphcation, an operating system intercept or various other mechanisms for capturing or intercepting control. For example, a user apphcation may issue a request for access to a particular content stored within the VDE container. As another example, another method may issue a command.

1630In the example shown, the open event is processed by a control method 1502. Control method 1502 may caU other methods to process the event. For example, control method 1502 may caU an EVENT method 1504, a METER method 1506, a BILLING method 1508, and a BUDGET method 1510. Not aU OPEN control methods necessarily caU of these additional methods, but the OPEN method 1500 shown in Figure 49 is a representative example.

1631Control method 1502 passes a description of the open event to EVENT method 1504. EVENT method 1504 may determine, for example, whether the open event is permitted and whether the open event is significant in the sense that it needs to be processed by METER method 1506, BILLING method 1508, and/or BUDGET method 1510. EVENT method 1504 may maintain audit traU information within an audit traU UDE, and may determine permissions and significance of the event by using an Event Method Data Element (MDE). EVENT method 1504 may also map the open event into an "atomic element" and count that may be processed by METER method 1506, BILLING method 1508, and/or BUDGET method 1510.

1632In OPEN method 1500, once EVENT method 1504 has been called and returns successfuUy, control method 1502 then may caU METER method 1506 and pass the METER method, the atomic element and count returned by EVENT method 1504. METER method 1506 may maintain audit traU information in a METER method Audit Trail UDE, and may also maintain meter information in a METER method UDE. In the prefeπed embodiment, METER method 1506 returns a meter value to control method 1502 assuming successful completion.

1633In the prefeπed embodiment, control method 1502 upon receiving an indication that METER method 1506 has completed successfuUy, then calls BILLING method 1508. Control method 1502 may pass to BILLING method 1508 the meter value provided by METER method 1506. BILLING method 1508 may read and update billing information maintained in a BILLING method map MDE, and may also maintain and update audit traU in a BILLING method Audit TraU UDE. BILLING method 1508 may return a billing amount and a completion code to control method 1502.

1634Assumin BILLING method 1508 completes successfuUy, control method 1502 may pass the billing value provided by BILLING method 1508 to BUDGET method 1510. BUDGET method 1510 may read and update budget information within a BUDGET method UDE, and may also maintain audit traU information in a BUDGET method Audit TraU UDE. BUDGET method 1510 may return a budget value to control method 1502, and may also return a completion code indicating whether the open event exceeds the user's budget (for this type of event).

1635Upon completion of BUDGET method 1510, control method 1502 may create a channel and estabhsh read/use control information in preparation for subsequent calls to the READ method.

1636Figures 49a-49f are a more detaUed description of the OPEN method 1500 example shown in Figure 49. Referring to Figure 49a, in response to an open event, control method 1502 first may determine the identification of the object to be opened and the identification of the user that has requested the object to be opened (block 1520). Control method 1502 then determines whether the object to be opened is registered for this user (decision block 1522). It makes this determination at least in part in the prefeπed embodiment by reading the PERC 808 and the User Rights Table (URT) element associated with the particular object and particular user determined by block 1520 (block 1524). If the user is not registered for this particular object ("no" exit to decision block 1522), then control method 1502 may caU the REGISTER method for the object and restart the OPEN method 1500 once registration is complete (block 1526). The REGISTER method block 1526 may be an independent process and may be time independent. It may, for example, take a relatively long time to complete the REGISTER method (say if the VDE distributor or other participant responsible for providing registration wants to perform a credit check on the user before registering the user for this particular object).

1637Assuming the proper URT for this user and object is present such that the object is registered for this user ("yes" exit to decision block 1522), control method 1502 may determine whether the object is already open for this user (decision block 1528). This test may avoid creating a redundant channel for opening an object that is already open. Assuming the object is not already open ("no" exit to decision block 1528), control method 1502 creates a channel and binds appropriate open control elements to it (block 1530). It reads the appropriate open control elements from the secure database (or the container, such as, for example, in the case of a travelling object), and "binds" or "links" these particular appropriate control elements together in order to control opening of the object for this user. Thus, block 1530 associates an event with one or more appropriate method core(s), appropriate load modules, appropriate User Data Elements, and appropriate Method Data Elements read from the secure database (or the container) (block 1532). At this point, control method 1502 specifies the open event (which started the OPEN method to begin with), the object ID and user ID (determined by block 1520), and the channel ID of the channel created by block 1530 to subsequent EVENT method 1504, METER method 1506, BILLING method 1508 and BUDGET method 1510 to provide a secure database "transaction" (block 1536). Before doing so, control method 1502 may prime an audit process (block 1533) and write audit information into an audit UDE (block 1534) so a record of the transaction exists even if the transaction fails or is interfered with.

1638The detaU steps performed by EVENT method 1504 are set forth on Figure 49b. EVENT method 1504 may first prime an event audit traU if required (block 1538) which may write to an EVENT Method Audit TraU UDE (block 1540). EVENT method 1504 may then perform the step of mapping the open event to an atomic element number and event count using a map MDE (block 1542). The EVENT method map MDE may be read from the secure database (block 1544). This mapping process performed by block 1542 may, for example, determine whether or not the open event is meterable, b lable, or budgetable, and may transform the open event into some discrete atomic element for metering, billing and/or budgeting. As one example, block 1542 might perform a one-to-one mapping between open events and "open" atomic elements, or it may only provide an open atomic element for every fifth time that the object is opened. The map block 1542 preferably returns the open event, the event count, the atomic element number, the object ED, and the user ID. This information may be written to the EVENT method Audit TraU UDE (block 1546, 1548). In the preferred embodiment, a test (decision block 1550) is then performed to determine whether the EVENT method faUed. SpecificaUy, decision block 1550 may determine whether an atomic element number was generated. If no atomic element number was generated (e.g., meaning that the open event is not significant for processing by METER method 1506, BILLING method 1508 and/or BUDGET method 1510), then EVENT method 1504 may return a "faU" completion code to control method 1502 ("no" exit to decision block 1550).

1639Control method 1502 tests the completion code returned by EVENT method 1504 to determine whether it faUed or was successful (decision block 1552). If the EVENT method faUed ("no" exit to decision block 1552), control method 1502 may "roU back* the secure database transaction (block 1554) and return itself with an indication that the OPEN method faUed (block 1556). In this context, "rolling back" the secure database transaction means, for example, "undoing" the changes made to audit traU UDE by blocks 1540, 1548. However, this "roU back" performed by block 1554 in the prefeπed embodiment does not "undo" the changes made to the control method audit UDE by blocks 1532, 1534.

1640Assuming the EVENT method 1504 completed successfuUy, control method 1502 then calls the METER method 1506 shown on Figure 49c. In the prefeπed embodiment, METER method 1506 primes the meter audit traU if required (block 1558), which typicaUy involves writing to a METER method audit traU UDE (block 1560). METER method 1506 may then read a METER method UDE from the secure database (block 1562), modify the meter UDE by adding an appropriate event count to the meter value contained in the meter UDE (block 1564), and then writing the modified meter UDE back to the secure database (block 1562). In other words, block 1564 may read the meter UDE, increment the meter count it contains, and write the changed meter UDE back to the secure database. In the prefeπed embodiment, METER method 1506 may then write meter audit traU information to the METER method audit traU UDE if required (blocks 1566, 1568). METER method 1506 preferably next performs a test to determine whether the meter increment succeeded (decision block 1570). METER method 1506 returns to control method 1502 with a completion code (e.g., succeed or faU) and a meter value determined by block 1564.

1641Control method 1502 tests whether the METER method succeeded by examining the completion code, for example (decision block 1572). If the METER method faUed ("no" exit to decision block 1572), then control method 1502 "rolls back" a secure database transaction (block 1574), and returns with an indication that the OPEN method faUed (block 1576). Assuming the METER method succeeded ("yes" exit to decision block 1572), control method 1502 calls the BILLING method 1508 and passes it the meter value provided by METER method 1506.

1642An example of steps performed by BILLING method 1508 is set forth in Figure 49d. BILLING method 1508 may prime a billing audit traU if required (block 1578) by writing to a BILLING method Audit TraU UDE within the secure database (block 1580). BILLING method 1508 may then map the atomic element number, count and meter value to a billing amount using a BILLING method map MDE read from the secure database (blocks 1582, 1584). Providing an independent BILLING method map MDE containing, for example, price list information, aUows separately dehverable pricing for the billing process. The resulting billing amount generated by block 1582 may be written to the BILLING method Audit TraU UDE (blocks 1586, 1588), and may also be returned to control method 1502. In addition, BILLING method 1508 may determine whether a billing amount was properly selected by block 1582 (decision block 1590). In this example, the test performed by block 1590 generaUy requires more than mere examination of the returned billing amount, since the billing amount may be changed in unpredictable ways as specified by BILLING method map MDE. Control then returns to control method 1502, which tests the completion code provided by BILLING method 1508 to determine whether the BILLING method succeeded or faUed (block 1592). If the BILLING method faUed ("no" exit to decision block 1592), control method 1502 may "roU back" the secure database transaction (block 1594), and return an indication that the OPEN method faUed (block 1596). Assuming the test performed by decision block 1592 indicates that the BILLING method succeeded ("yes" exit to decision block 1592), then control method 1502 may caU BUDGET method 1510.

1643Other BILLING methods may use site, user and/or usage information to estabhsh, for example, pricing information. For example, information concerning the presence or absence of an object may be used in estabhsbing "suite" purchases, competitive discounts, etc. Usage levels may be factored into a BILLING method to estabhsh price breaks for different levels of usage. A currency translation feature of a BILLING method may aUow purchases and/or pricing in many different currencies. Many other possibilities exist for determining an amount of budget consumed by an event that may be incorporated into BILLING methods.

1644An example of detaUed control steps performed by BUDGET method 1510 is set forth in Figure 49e. BUDGET method 1510 may prime a budget audit traU if required by writing to a budget traU UDE (blocks 1598, 1600). BUDGET method 1510 may next perform a billing operation by adding a billing amount to a budget value (block 1602). This operation may be performed, for example, by reading a BUDGET method UDE from the secure database, modifying it, and writing it back to the secure database (block 1604). BUDGET method 1510 may then write the budget audit traU information to the BUDGET method Audit TraU UDE (blocks 1606, 1608). BUDGET method 1510 may finaUy, in this example, determine whether the user has run out of budget by determining whether the budget value calculated by block 1602 is out of range (decision block 1610). If the user has run out of budget ("yes" exit to decision block 1610), the BUDGET method 1510 may return a "faU completion" code to control method 1502. BUDGET method 1510 then returns to control method 1502, which tests whether the BUDGET method completion code was successful (decision block 1612). If the BUDGET method faUed ("no" exit to decision block 1612), control method 1502 may "roU back" the secure database transaction and itself return with an indication that the OPEN method faUed (blocks 1614, 1616). Assuming control method 1502 determines that the BUDGET method was successful, the control method may perform the additional steps shown on Figure 49f. For example, control method 1502 may write an open audit traU if required by writing audit information to the audit UDE that was primed at block 1532 (blocks 1618, 1620). Control method 1502 may then estabhsh a read event processing (block 1622), using the User Right Table and the PERC associated with the object and user to estabhsh the channel (block 1624). This channel may optionaUy be shared between users of the VDE node 600, or may be used only by a specified user.

1645Control method 1502 then, in the prefeπed embodiment, tests whether the read channel was established successfuUy (decision block 1626). If the read channel was not successfuUy established ("no" exit to decision block 1626), control method 1502 "roUs back" the secured database transaction and provides an indication that the OPEN method faUed (blocks 1628, 1630). Assuming the read channel was successfuUy estabhshed ("yes" exit to decision block 1626), control method 1502 may "commit" the secure database transaction (block 1632). This step of "committing" the secure database transaction in the preferred embodiment involves, for example, deleting intermediate values associated with the secure transaction that has just been performed and, in one example, writing changed UDEs and MDEs to the secure database. It is generaUy not possible to "roU back" a secure transaction once it has been committed by block 1632. Then, control method 1502 may "tear down" the channel for open processing (block 1634) before terminating (block 1636). In some arrangements, such as multi-tasking VDE node environments, the open channel may be constantly maintained and avaUable for use by any OPEN method that starts. In other implementations, the channel for open processing may be rebuUt and restarted each time an OPEN method starts.

1646Read

1647Figure 50, 50a-50f show examples of process control steps for performing a representative example of a READ method 1650. Comparing Figure 50 with Figure 49 reveals that the same overaU high level processing may typicaUy be performed for READ method 1650 as was described in connection with OPEN method 1500. Thus, READ method 1650 may caU a control method 1652 in response to a read event, the control method in turn invoking an EVENT method 1654, a METER method 1656, a BILLING method 1658 and a BUDGET method 1660. In the prefeπed embodiment, READ control method 1652 may request methods to fingerprint and/or obscure content before releasing the decrypted content.

1648Figures 50a-50e are similar to Figures 49a-49e. Of course, even though the same user data elements may be used for both the OPEN method 1500 and the READ method 1650, the method data elements for the READ method may be completely different, and in addition, the user data elements may provide different auditing, metering, billing and/or budgeting criteria for read as opposed to open processing.

1649Referring to Figure 50f, the READ control method 1652 must determine which key to use to decrypt content if it is going to release decrypted content to the user (block 1758). READ control method 1652 may make this key determination based, in part, upon the PERC 808 for the object (block 1760). READ control method 1652 may then caU an ACCESS method to actuaUy obtain the encrypted content to be decrypted (block 1762). The content is then decrypted using the key determined by block 1758 (block 1764). READ control method 1652 may then determine whether a "fingerprint" is desired (decision block 1766). If fingerprinting of the content is desired ("yes" exit of decision block 1766), READ control method 1652 may caU the FINGERPRINT method (block 1768). Otherwise, READ control method 1652 may determine whether it is desired to obscure the decrypted content (decision block 1770). If so, READ control method 1652 may caU an OBSCURE method to perform this function (block 1772). FinaUy, READ control method 1652 may commit the secure database transaction (block 1774), optionaUy tear down the read channel (not shown), and terminate (block 1776).

1650Write

1651Figures 51, 51a-51f are flowcharts of examples of process control steps used to perform a representative example of a WRITE method 1780 in the prefeπed embodiment. WRITE method 1780 uses a control method 1782 to caU an EVENT method 1784, METER method 1786, BILLING method 1788, and BUDGET method 1790 in this example. Thus, writing information into a container (either by overwriting information already stored in the container or adding new infoπnation to the container) in the prefeπed embodiment may be metered, billed and/or budgeted in a manner similar to the way opening a container and reading from a container can be metered, billed and budgeted. As shown in Figure 51, the end result of WRITE method 1780 is typicaUy to encrypt content, update the container table of contents and related information to reflect the new content, and write the content to the object. Figure 51a for the WRITE control method 1782 is similar to Figure 49a and Figure 50a for the OPEN control method and the READ control method, respectively. However, Figure 51b is slightly different from its open and read counterparts. In particular, block 1820 is performed if the WRITE EVENT method 1784 fails. This block 1820 updates the EVENT method map MDE to reflect new data. This is necessary to aUow information written by block 1810 to be read by Figure 51b READ method block 1678 based on the same (but now updated) EVENT method map MDE.

1652Looking at Figure 51f, once the EVENT, METER, BILLING and BUDGET methods have returned successfuUy to WRITE control method 1782, the WRITE control method writes audit information to Audit UDE (blocks 1890, 1892), and then determines (based on the PERC for the object and user and an optional algorithm) which key should be used to encrypt the content before it is written to the container (blocks 1894, 1896). CONTROL method 1782 then encrypts the content (block 1898) possibly by calling an ENCRYPT method, and writes the encrypted content to the object (block 1900). CONTROL method 1782 may then update the table of contents (and related information) for the container to reflect the newly written information (block 1902), commit the secure database transaction (block 1904), and return (block 1906). Close

1653Figure 52 is a flowchart of an example of process control steps to perform a representative example of a CLOSE method 1920 in the prefeπed embodiment. CLOSE method 1920 is used to close an open object. In the preferred embodiment, CLOSE method 1920 primes an audit trail and writes audit information to an Audit UDE (blocks 1922, 1924). CLOSE method 1920 then may destroy the current channel(s) being used to support and/or process one or more open objects (block 1926). As discussed above, in some (e.g., multi-user or multi-tasking) instaUations, the step of destroying a channel is not needed because the channel may be left operating for processing additional objects for the same or different users. CLOSE method 1920 also releases appropriate records and resources associated with the object at this time (block 1926). The CLOSE method 1920 may then write an audit traU (if required) into an Audit UDE (blocks 1928, 1930) before completing.

1654Event

1655Figure 53a is a flowchart of example process control steps provided by a more general example of an EVENT method 1940 provided by the prefeπed embodiment. Examples of EVENT methods are set forth in Figures 49b, 50b and 51b and are described above. EVENT method 1940 shown in Figure 53a is somewhat more generalized than the examples above. Like the EVENT method examples above, EVENT method 1940 receives an identification of the event along with an event count and event parameters. EVENT method 1940 may first prime an EVENT audit traU (if required) by writing appropriate information to an EVENT method Audit TraU UDE (blocks 1942, 1944). EVENT method 1940 may then obtain and load an EVENT method map DTD from the secure database (blocks 1946, 1948). This EVENT method map DTD describes, in this example, the format of the EVENT method map MDE to be read and accessed immediately subsequently (by blocks 1950, 1952). In the prefeπed embodiment, MDEs and UDEs may have any of various different formats, and their formats may be flexibly specified or changed dynamicaUy depending upon the instaUation, user, etc. The DTD, in effect, describes to the EVENT method 1940 how to read from the EVENT method map MDE. DTDs are also used to specify how methods should write to MDEs and UDEs, and thus may be used to implement privacy filters by, for example, preventing certain confidential user information from being written to data structures that wUl be reported to third parties.

1656Block 1950 ("map event to atomic element # and event count using a Map MDE") is in some sense the "heart" of EVENT method 1940. This step "maps" the event into an "atomic element number" to be responded to by subsequently caUed methods. An example of process control steps performed by a somewhat representative example of this "mapping" step 1950 is shown in Figure 53b.

1657The Figure 53b example shows the process of converting a READ event that is associated with requesting byte range 1001- 1500 from a specific piece of content into an appropriate atomic element. The example EVENT method mapping process (block 1950 in Figure 53a) can be detaUed as the representative process shown in Figure 53b.

1658EVENT method mapping process 1950 may first look up the event code (READ) in the EVENT method MDE (1952) using the EVENT method map DTD (1948) to determine the structure and contents of the MDE. A test might then be performed to determine if the event code was found in the MDE (1956), and if not ("No" branch), the EVENT method mapping process may the terminate (1958) without mapping the event to an atomic element number and count. If the event was found in the MDE ("Yes" branch), the EVENT method mapping process may then compare the event range (e.g., bytes 1001-1500) against the atomic element to event range mapping table stored in the MDE (block 1960). The comparison might yield one or more atomic element numbers or the event range might not be found in the .mapping table. The result of the comparison might then be tested (block 1962) to determine if any atomic element numbers were found in the table. If not ("No" branch), the EVENT method mapping process may terminate without selecting any atomic element numbers or counts (1964). If the atomic element numbers were found, the process might then calculate the atomic element count from the event range (1966). In this example, the process might calculate the number of bytes requested by subtracting the upper byte range from the lower byte range (e.g., 1500 - 1001 + 1 = 500). The example EVENT method mapping process might then terminate (block 1968) and return the atomic element number(s) and counts.

1659EVENT method 1940 may then write an EVENT audit traU if required to an EVENT method Audit TraU UDE (block 1970, 1972). EVENT method 1940 may then prepare to pass the atomic element number and event count to the calling CONTROL method (or other control process) (at exit point 1978). Before that, however, EVENT method 1940 may test whether an atomic element was selected (decision block 1974). If no atomic element was selected, then the EVENT method may be faUed (block 1974). This may occur for a number of reasons. For example, the EVENT method may faU to map an event into an atomic element if the user is not authorized to access the specific areas of content that the EVENT method MDE does not describe. This mechanism could be used, for example, to distribute customized versions of a piece of content and control access to the various versions in the content object by altering the EVENT method MDE dehvered to the user. A specific use of this technology might be to control the distribution of different language (e.g., English, French, Spanish) versions of a piece of content.

1660Billing

1661Figure 53c is a flowchart of an example of process control steps performed by a BILLING method 1980. Examples of BILLING methods are set forth in Figures 49d, 50d, and 51d and are described above. BILLING method 1980 shown in Figure 53c is somewhat more generalized than the examples above. Like the BILLING method examples above, BILLING method 1980 receives a meter value to determine the amount to bUl. BILLING method 1980 may first prime a BILLING audit traU (if required) by writing appropriate information to the BILLING method Audit TraU UDE (blocks 1982, 1984). BILLING method 1980 may then obtain and load a BILLING method map DTD from the secure database (blocks 1985, 1986), which describes the BILLING method map MDE (e.g., a price list, table, or parameters to the billing amount calculation algorithm) that should be used by this BILLING method. The BILLING method map MDE may be dehvered either as part of the content object or as a separately dehverable component that is combined with the • control information at registration. The BILLING method map MDE in this example may describe the pricing algorithm that should be used in this BILLING method (e.g., bUl $0,001 per byte of content released). Block 1988 ("Map meter value to billing amount") functions in the same manner as block 1950 of the EVENT method; it maps the meter value to a billing value. Process step 1988 may also inteπogate the secure database (as limited by the privacy filter) to deteπnine if other objects or information (e.g., user information) are present as part of the BILLING method algorithm.

1662BILLING method 1980 may then write a BILLING audit traU if required to a BILLING method Audit TraU UDE (block 1990, 1992), and may prepare to return the billing amount to the palling CONTROL method (or other control process). Before that, however, BILLING method 1980 may test whether a billing amount was determined (decision block 1994). If no billing amount was determined, then the BILLING method may be faUed (block 1996). This may occur if the user is not authorized to access the specific areas of the pricing table that the BILLING method MDE describes (e.g., you may purchase not more than $100.00 of information from this content object). Access

1663Figure 54 is a flowchart of an example of program control steps performed by an ACCESS method 2000. As described above, an ACCESS method may be used to access content embedded in an object 300 so it can be written to, read from, or otherwise manipulated or processed. In many cases, the ACCESS method may be relatively trivial since the object may, for example, be stored in a local storage that is easUy accessible. However, in the general case, an ACCESS method 2000 must go through a more complicated procedure in order to obtain the object. For example, some objects (or parts of objects) may only be avaUable at remote sites or may be provided in the form of a real-time download or feed (e.g., in the case of broadcast transmissions). Even if the object is stored locaUy to the VDE node, it may be stored as a secure or protected object so that it is not directly accessible to a calling process. ACCESS method 2000 establishes the connections, routings, and security requisites needed to access the object. These steps may be performed transparently to the calling process so that the calling process only needs to issue an access request and the particular ACCESS method coπesponding to the object or class of objects handles aU of the detaUs and logistics involved in actuaUy accessing the object. ACCESS method 2000 may first prime an ACCESS audit traU (if required) by writing to an ACCESS Audit TraU UDE (blocks 2002, 2004). ACCESS method 2000 may then read and load an ACCESS method DTD in order to determine the format of an ACCESS MDE (blocks 2006, 2008). The ACCESS method MDE specifies the source and routing information for the particular object to be accessed in the prefeπed embodiment. Using the ACCESS method DTD, ACCESS method 2000 may load the coπection parameters (e.g., by telephone number, account ID, password and/or a request script in the remote resource dependent language).

1664ACCESS method 2000 reads the ACCESS method MDE from the secure database, reads it in accordance with the ACCESS method DTD, and loads encrypted content source and routing information based on the MDE (blocks 2010, 2012). This source and routing information specifies the location of the encrypted content. ACCESS method 2000 then determines whether a connection to the content is avaUable (decision block 2014). This "connection" could be, for example, an on-line connection to a remote site, a real-time information feed, or a path to a secure/protected resource, for example. If the connection to the content is not currently avaUable ("No" exit of decision block 2014), then ACCESS method 2000 takes steps to open the connection (block 2016). If the connection fails (e.g., because the user is not authorized to access a protected secure resource), then the ACCESS method 2000 returns with a faUure indication (termination point 2018). If the open connection succeeds, on the other hand, then ACCESS method 2000 obtains the encrypted content (block 2020). ACCESS method 2000 then writes an ACCESS audit traU if required to the secure database ACCESS method Audit TraU UDE (blocks 2022, 2024), and then terminates (terminate point 2026).

1665Decrypt and Encrypt

1666Figure 55a is a flowchart of an example of process control steps performed by a representative example of a DECRYPT method 2030 provided by the prefeπed embodiment. DECRYPT method 2030 in the prefeπed embodiment obtains or derives a decryption key from an appropriate PERC 808, and uses it to decrypt a block of encrypted content. DECRYPT method 2030 is passed a block of encrypted content or a pointer to where the encrypted block is stored. DECRYPT 2030 selects a key number from a key block (block 2032). For security purposes, a content object may be encrypted with more than one key. For example, a movie may have the first 10 minutes encrypted using a first key, the second 10 minutes encrypted with a second key, and so on. These keys are stored in a PERC 808 in a structure caUed a "key block." The selection process involves determining the coπect key to use from the key block in order to decrypt the content. The process for this selection is simUar to the process used by EVENT methods to map events into atomic element numbers. DECRYPT method 2030 may then access an appropriate PERC 808 from the secure database 610 and loads a key (or "seed") from a PERC (blocks 2034, 2036). This key information may be the actual decryption key to be used to decrypt the content, or it may be information from which the decryption key may be at least in part derived or calculated. If necessary, DECRYPT method 2030 computes the decryption key based on the information read from PERC 808 at block 2034 (block 2038). DECRYPT method 2030 then uses the obtained and/or calculated decryption key to actuaUy decrypt the block of encrypted information (block 2040). DECRYPT method 2030 outputs the decrypted block (or the pointer indicating where it may be found), and terminates (termination point 2042).

1667Figure 55b is a flowchart of an example of process control steps performed by a representative example of an ENCRYPT method 2050. ENCRYPT method 2050 is passed as an input, a block of information to encrypt (or a pointer indicating where it may be found). ENCRYPT method 2050 then may determine an encryption key to use from a key block (block 2052). The encryption key selection makes a determination if a key for a specific block of content to be written already exists in a key block stored in PERC 808. If the key already exists in the key block, then the appropriate key number is selected. If no such key exists in the key block, a new key is calculated using an algorithm appropriate to the encryption algorithm. This key is then stored in the key block of PERC 808 so that DECRYPT method 2030 may access the key in order to decrypt the content stored in the content object. ENCRYPT method 2050 then accesses the appropriate PERC to obtain, derive and/or compute an encryption key to be used to encrypt the information block (blocks 2054, 2056, 2058, which are similar to Figure 55a blocks 2034, 2036, 2038). ENCRYPT method 2050 then actuaUy encrypts the information block using the obtained and/or derived encryption key (block 2060) and outputs the encrypted information block or a pointer where it can be found before terminating (termination point 2062). Content

1668Figure 56 is a flowchart of an example of process control steps performed by a representative of a CONTENT method 2070 provided by the prefeπed embodiment. CONTENT method 2070 in the prefeπed embodiment buUds a "synopsis" of protected content using a secure process. For example, CONTENT method 2070 may be used to derive unsecure ("pubhc"; infoπnation from secure content. Such derived pubhc information might include, for example, an abstract, an index, a table of contents, a directory of files, a schedule when content may be avaUable, or excerpts such as for example, a movie "tra er." CONTENT method 2070 begins by determining whether the derived content to be provided must be derived from secure contents, or whether it is already avaUable in the object in the form of static values (decision block 2070). Some objects may, for example, contain prestored abstracts, indexes, tables of contents, etc., provided expressly for the purpose of being extracted by the CONTENT method 2070. If the object contains such static values ("static" exit to decision block 2072), then CONTENT method 2070 may simply read this static value content information from the object (block 2074), optionaUy decrypt, and release this content description (block 2076). If, on the other hand, CONTENT method 2070 must derive the synopsis/content description from the secure object ("derived" exit to decision block 2072), then the CONTENT method may then securely read information from the container according to a synopsis algorithm to produce the synopsis (block 2078).

1669Extract and Embed

1670Figure 57a is a flowchart of an example of process control steps performed by a representative example of an EXTRACT method 2080 provided by the prefeπed embodiment. EXTRACT method 2080 is used to copy or remove content from an object and place it into a new object. In the prefeπed embodiment, the EXTRACT method 2080 does not involve any release of content, but rather simply takes content from one container and places it into another container, both of which may be secure. Extraction of content differs from release in that the content is never exposed outside a secure container. Extraction and Embedding are complementary functions; extract takes content from a container and creates a new container containing the extracted content and any specified control information associated with that content. Embedding takes content that is already in a container and stores it (or the complete object) in another container directly and/or by reference, integrating the control information associated with existing content with those of the new content.

1671EXTRACT method 2080 begins by priming an Audit UDE (blocks 2082, 2084). EXTRACT method then calls a BUDGET method to make sure that the user has enough budget for (and is authorized to) extract content from the original object (block 2086). If the user's budget does not permit the extraction ("no" exit to decision block 2088), then EXTRACT method 2080 may write a faUure audit record (block 2090), and terminate (termination point 2092). If the user's budget permits the extraction ("yes" exit to decision block 2088), then the EXTRACT method 2080 creates a copy of the extracted object with specified rules and control information (block 2094). In the prefeπed embodiment, this step involves calling a method that actuaUy controls the copy. This step may or may not involve decryption and encryption, depending on the particular the PERC 808 associated with the original object, for example. EXTRACT method 2080 then checks whether any control changes are permitted by the rights authorizing the extract to begin with (decision block 2096). In some cases, the extract rights require an exact copy of the PERC 808 associated with the original object (or a PERC included for this purpose) to be placed in the new (destination) container ("no" exit to decision block 2096). If no control changes are permitted, then extract method 2080 may simply write audit information to the Audit UDE (blocks 2098, 2100) before terminating (terminate point 2102). If, on the other hand, the extract rights permit the user to make control changes ("yes" to decision block 2096), then EXTRACT method 2080 may caU a method or load module that sohcits new or changed control information (e.g., from the user, the distributor who created/granted extract rights, or from some other source) from the user (blocks 2104, 2106). EXTRACT method 2080 may then caU a method or load module to create a new PERC that reflects these user-specified control information (block 2104). This new PERC is then placed in the new (destination) object, the auditing steps are performed, and the process terminates.

1672Figure 57b is an example of process control steps performed by a representative example of an EMBED method 2110 provided by the prefeπed embodiment. EMBED method 2110 is similar to EXTRACT method 2080 shown in Figure 57a. However, the EMBED method 2110 performs a shghtly different function — it writes an object (or reference) into a destination container. Blocks 2112-2122 shown in Figure 57b are similar to blocks 2082-2092 shown in Figure 57a. At block 2124, EMBED method 2110 writes the source object into the destination container, and may at the same time extract or change the control information of the destination container. One alternative is to simply leave the control information of the destination container alone, and include the full set of control information associated with the object being embedded in addition to the original container control information. As an optimization, however, the prefeπed embodiment provides a technique whereby the control information associated with the object being embedded are "abstracted" and incorporated into the control information of the destination container. Block 2124 may caU a method to abstract or change this control information. EMBED method 2110 then performs steps 2126-2130 which are simUar to steps 2096, 2104, 2106 shown in Figure 57a to aUow the user, if authorized, to change and/or specify control information associated with the embedded object and/or destination container. EMBED method 2110 then writes audit information into an Audit UDE (blocks 2132, 2134), before terminating (at termination point 2136). Obscure

1673Figure 58a is a flowchart of an example of process control steps performed by a representative example of an OBSCURE method 2140 provided by the prefeπed embodiment. OBSCURE method 2140 is typicaUy used to release secure content in devalued form. For example, OBSCURE method 2140 may release a high resolution image in a lower resolution so that a viewer can appreciate the image but not enjoy its fuU value. As another example, the OBSCURE method 2140 may place an obscuring legend (e.g., "COPY," "PROOF," etc.) across an image to devalue it. OBSCURE method 2140 may "obscure" text, images, audio information, or any other type of content.

1674OBSCURE method 2140 first calls an EVENT method to determine if the content is appropriate and in the range to be obscured (block 2142). If the content is not appropriate for obscuring, the OBSCURE method terminates (decision block 2144 "no" exit, terminate point 2146). Assuming that the content is to be obscured ("yes" exit to decision block 2144), then OBSCURE method 2140 determines whether it has previously been caUed to obscure this content (decision block 2148). Assuming the OBSCURE 2140 has not previously caUed for this object/content ("yes" exit to decision block 2148), the OBSCURE method 2140 reads an appropriate OBSCURE method MDE from the secure database and loads an obscure formula and/or pattern from the MDE (blocks 2150, 2152). The OBSCURE method 2140 may then apply the appropriate obscure transform based on the patters and/or formulas loaded by block 2150 Oolock 2154). The OBSCURE method then may terminate ⁽terminate block 2156).

1675Fingerprint

1676Figure 58b is a flowchart of an example of process control steps performed by a representative example of a FINGERPRINT method 2160 provided by the prefeπed embodiment. FINGERPRINT method 2160 in the prefeπed embodiment operates to "mark" released content with a "fingerprint" identification of who released the content and/or check for such marks. This aUows one to later determine who released unsecured content by examining the content. FINGERPRINT method 2160 may, for example, insert a user ID within a datastream representing audio, video, or binary format information. FINGERPRINT method 2160 is quite similar to OBSCURE method 2140 shown in Figure 58a except that the transform apphed by FINGERPRINT method block 2174 "fingerprints" the released content rather than obscuring it.

1677Figure 58c shows an example of a "fingerprinting" procedure 2160 that inserts into released content "fingerprints" .2161 that identify the object and/or property and/or the user that requested the released content and/or the date and time of the release and/or other identification criteria of the released content.

1678Such fingerprints 2161 can be "buried" ~ that is inserted in a manner that hides the fingerprints from typical users, sophisticated "hackers," and or from aU users, depending on the file format, the sophistication and/or variety of the insertion algorithms, and on the avaUabUity of original, non-fingerprinted content (for comparison for reverse engineering of algorithm(s)). Inserted or embedded fingerprints 2161, in a preferred embodiment, may be at least in part encrypted to make them more secure. Such encrypted fingerprints 2161 may be embedded within released content provided in "clear" (plaintext) form.

1679Fingerprints 2161 can be used for a variety of purposes including, for example, the often related purposes of proving misuse of released materials and proving the source of released content. Software piracy is a particularly good example where fingerprinting can be very useful. Fingerprinting can also help to enforce content providers' rights for most types of electronicaUy dehvered information including movies, audio recordings, multimedia, information databases, and traditional "literary" materials. Fingerprinting is a desirable alternative or addition to copy protection. Most piracy of software apphcations, for example, occurs not with the making of an illicit copy by an individual for use on another of the individual's own computers, but rather in giving a copy to another party. This often starts a chain (or more accurately a pyramid) of illegal copies, as copies are handed from individual to individual. The fear of identification resulting from the embedding of a fingerprint 2161 will likely dissuade most individuals from participating, as many currently do, in widespread, "casual" piracy. In some cases, content may be checked for the presence of a fingerprint by a fingerprint method to help enforce content providers' rights.

1680Different fingerprints 2161 can have different levels of security (e.g., one fingerprint 2161(1) could be readable/identifiable by commercial concerns, whUe another fingerprint 2161(2) could be readable only by a more trusted agency. The methods for generating the more secure fingerprint 2161 might employ more complex encryption techniques (e.g., digital signatures) and/or obscuring of location methodologies. Two or more fingerprints 2161 can be embedded in different locations and/or using different techniques to help protect fingerprinted information against hackers. The more secure fingerprints might only be employed periodicaUy rather than each time content release occurs, if the technique used to provide a more secure fingerprint involves an undesired amount of additional overhead. This may nevertheless be effective since a principal objective of fingerprinting is deterrence — hat is the fear on the part of the creator of an illicit copy that the copying wiU be found out.

1681For example, one might embed a copy of a fingerprint 2161 which might be readily identified by an authorized party— for example a distributor, service personal, chent administrator, or clearinghouse using a VDE electronic apphance 600. One might embed one or more additional copies or variants of a fingerprint 2161 (e.g., fingerprints carrying information describing some or aU relevant identifying -----formation) and this additional one or more fingerprints 2161 might be maintained in a more secure manner.

1682Fingerprinting can also protect privacy concerns. For example, the algorithm and/or mechanisms needed to identify the fingerprint 2161 might be avaUable only through a particularly trusted agent.

1683Fingerprinting 2161 can take many forms. For example, in an image, the color of every N pixels (spread across an image, or spread across a subset of the image; might be subtly shifted in a visuaUy unnoticeable manner (at least according to the normal, unaided observer). These shifts could be interpreted by analysis of the image (with or without access to the original image), with each occurrence or lack of occurrence of a shift in color (or greyscale) being one or more binary "on or off" bits for digital information storage. The N pixels might be either consistent, or alternatively, pseudo-random in order (but interpretable, at least in part, by a object creator, object provider, chent administrator, and/or VDE administrator).

1684Other modifications of an image (or moving image, audio, etc.) which provide a similar benefit (that is, storing information in a form that is not normaUy noticeable as a result of a certain modification of the source infoπnation) may be appropriate, depending on the apphcation. For example, certain subtle modifications in the frequency of stored audio information can be modified so as to be normaUy unnoticeable to the listener whUe stUl being readable with the proper tools. Certain properties of the storage of information might be modified to provide such shght but interpretable variations in polarity of certain information which is opticaUy stored to achieve similar results. Other variations employing other electromc, magnetic, and/or optical characteristic may be employed.

1685Content stored in files that employ graphical formats, such as Microsoft Windows word processing files, provide significant opportunities for "burying" a fingerprint 2161. Content that includes images and/or audio provides the opportunity to embed fingerprints 2161 that may be difficult for unauthorized individuals to identify since, in the absence of an "unfingerprinted" original for purposes of comparison, minor subtle variations at one or more time instances in audio frequencies, or in one or more video images, or the like, wUl be in themselves undiscernible given the normaUy unknown nature of the original and the large amounts of data employed in both image and sound data (and which is not particularly sensitive to minor variations). With formatted text documents, particularly those created with graphical word processors (such as Microsoft Windows or Apple Macintosh word processors and their DOS and Unix equivalents), fingerprints 2161 can normaUy be inserted unobtrusively into portions of the document data representation that are not normaUy visible to the end user (such as in a header or other non-displayed data field).

1686Yet another form of fingerprinting, which may be particularly suitable for certain textual documents, would employ and control the formation of characters for a given font. Individual characters may have a shghtly different visual formation which connotes certain "fingerprint" information. This alteration of a given character's form would be generaUy undiscernible, in part because so many shght variations exist in versions of the same font avaUable from different suppliers, and in part because of the smaUness of the variation. For example, in a prefeπed embodiment, a program such as Adobe Type Align could be used which, in its off-the-shelf versions, supports the abihty of a user to modify font characters in a variety of ways. The mathematical definition of the font character is modified according to the user's instructions to produce a specific set of modifications to be apphed to a character or font. Information content could be used in an analogous manner (as an alternative to user selections) to modify certain or aU characters too subtly for user recognition under normal circumstances but which nevertheless provide appropriate encoding for the fingerprint 2161. Various subtly different versions of a given character might be used within a single document so as to increase the abihty to carry transaction related font fingerprinted information.

1687Some other examples of apphcations for fingerprinting might include:

16881. In software programs, selecting certain interchangeable code fragments in such a way as to produce more or less identical operation, but on analysis, differences that detaU fingerprint information.

16892. With databases, selecting to format certain fields, such as dates, to appear in different ways. 3. In games, adjusting backgrounds, or changing order of certain events, including noticeable or very subtle changes in timing and or ordering of appearance of game elements, or shght changes in the look of elements of the game.

1690Fingerprinting method 2160 is typicaUy performed (if at aU) at the point at which content is released from a content object 300. However, it could also be performed upon distribution of an object to "mark" the content whUe still in encrypted form. For example, a network-based object repository could embed fingerprints 2161 into the content of an object before transmitting the object to the requester, the fingerprint information could identify a content requester/end user. This could help detect "spoof electronic apphances 600 used to release content without authorization.

1691Destroy

1692Figure 59 is a flowchart of an example of process control steps performed by a representative performed by a DESTROY method 2180 provided by the prefeπed embodiment. DESTROY method 2180 removes the abihty of a user to use an object by destroying the URT the user requires to access the object. In the prefeπed embodiment, a DESTROY method 2180 may first write audit information to an Audit UDE (blocks 2182, 2184). DESTROY method 2180 may than caU a WRITE and/or ACCESS method to write information which will corrupt (and thus destroy) the header and/or other important parts of the object (block 2186). DESTROY method 2180 may then mark one or more of the control structures (e.g., the URT) as damaged by writing appropriate information to the control structure (blocks 2188, 2190). DESTROY method 2180, finaUy, may write additional audit information to Audit UDE (blocks 2192, 2194) before terminating (terminate point 2196).

1693Panic

1694Figure 60 is a flowchart of an example of process control steps performed by a representative example of a PANIC method 2200 provided by the prefeπed embodiment. PANIC method 2200 may be caUed when a security violation is detected. PANIC method 2200 may prevent the user from further accessing the object currently being accessed by, for example, destroying the channel being used to access the object and marking one or more of the control structures (e.g., the URT) associated with the user and object as damaged (blocks 2206, and 2208-2210, respectively). Because the control structure is damaged, the VDE node wiU need to contact an administrator to obtain a valid control structure(s) before the user may access the same object again When the VDE node contacts the administrator, the administrator may request information sufficient to satisfy itself that no security violation occurred, or if a security violation did occur, take appropriate steps to ensure that the security violation is not repeated.

1695Meter

1696Figure 61 is a flowchart of an example of process control steps performed by a representative example of a METER method provided by the prefeπed embodiment. Although METER methods were described above in connection with Figures 49, 50 and 51, the METER method 2220 shown in Figure 61 is possibly a somewhat more representative example. In the prefeπed embodiment, METER method 2220 first primes an Audit TraU by accessmg a METER Audit TraU UDE (blocks 2222, 2224). METER method 2220 may then read the DTD for the Meter UDE from the secure database (blocks 2226, 2228). METER method 2220 may then read the Meter UDE from the secure database (blocks 2230, 2232). METER method 2220 next may test the obtained Meter UDE to determine whether it has expired (decision block 2234). In the prefeπed embodiment, each Meter UDE may be marked with an expiration date. If the cuπent date/time is later than the expiration date of the Meter UDE ("yes" exit to decision block 2234), then the METER method 2220 may record a faUure in the Audit Record and terminate with a faUure condition (block 2236, 2238). Assuming the Meter UDE is not yet expired, the meter method 2220 may update it using the atomic element and event count passed to the METER method from, for example, an EVENT method (blocks 2239, 2240). The METER method 2220 may then save the Meter Use Audit Record in the Meter Audit TraU UDE (blocks 2242, 2244), before terminating (at terminate point 2246).

1697Additional Security Features Provided by the Preferred Embodiment

1698VDE 100 provided by the preferred embodiment has sufficient security to help ensure that it cannot be compromised short of a successful "brute force attack," and so that the time and cost to succeed in such a "brute force attack" substantiaUy exceeds any value to be derived. In addition, the security provided by VDE 100 compartmentalizes the internal workings of VDE so that a successful "brute force attack" would compromise only a strictly bounded subset of protected information, not the entire system.

1699The foUowing are among security aspects and features provided by the prefeπed embodiment:

1700• security of PPE 650 and the processes it performs