Systems and methods for secure transaction management and electronic rights protection

The present invention generally relates to computer and / or electronic security.

More specifically, the present invention relates to systems and techniques for secure transaction management. The present invention also relates to computer-based and other electronic device-based techniques that ensure that access to and / or use of information is performed only in approved manners, such use by the present invention. The integrity, availability, and / or confidentiality of such information and processes related to is maintained.

The present invention also relates to systems and methods for protecting the rights of various participants in electronic commerce and other electronic or electronically promoted transactions.

The present invention also relates to information content and a secure chain of handling and control for the information used to regulate the use of such content and its consequences. The present invention also relates to systems and techniques for measuring and / or limiting and / or monitoring the use of electronically stored and / or distributed information. The present invention relates, in particular, to transactions, operations and arrangements utilizing such systems and / or technologies, including the consequences of the use of such systems and / or technologies. The present invention also relates to distributed and other operating systems, environments and architectures. The invention also generally relates to a secure architecture, including, for example, a hardware-based processor that cannot be tampered with, which can be used, for example, to establish security at each node of a distributed system.

Background and gist of the invention Today, telecommunications, financial transactions, administrative procedures, business operations, entertainment, and personal business production all rely on electronics. These millions of electronic devices are electronically connected to each other. These interconnected electronic devices are equipped with what is increasingly referred to as the "information highway." Many businesses, scholars and political leaders are wondering how to protect the rights of citizens and organizations to use this information (electronic or digital) highway. Electronic content Today, virtually anything that can be represented by words, numbers, graphics, or commands and command schemes can be formatted into electronic digital information. Online services transmitted over television, cable, satellite transmission, and telephone lines are competing for the distribution of digital information and entertainment to homes and businesses. Owners and sellers of this content include software developers, video and record companies, book, magazine and newspaper publishers, and information database providers. The popularization of online services has also allowed individual personal computer users to participate as content providers. Microsoft According to the Corporation, the global market for electronic information in 1992 was about $ 40 billion and is estimated to grow to $ 200 billion by 1997. The present invention makes it possible to significantly increase the total revenue of content providers, significantly reduce distribution costs and content costs, better support advertising and usage information collection, and better meet the demands of electronic information users. To do. These improvements will significantly increase the amount and type of electronic information and the way such information is distributed.

<p> The inability of conventional products to meet the demands of electronic information providers and users makes a clear difference from the present invention. America's largest and most representative telecommunications, computer, entertainment and information provider companies have turned to some of the issues addressed by the present invention, but only the present invention is configurable general purpose e-commerce / distribution. It provides a commercially safe and effective solution for control systems.</p>

<p> Controlling electronic content The present invention provides a new kind of "virtual distribution environment" (referred to herein as "VDE") that secures, manages, and audits the use of electronic information. VDE also features a fundamentally important capability of managing content that "passes" through the "information highway." These capabilities include rights protection solutions that serve all electronic community members. These members include content creators and distributors, financial service providers, end users, and more. VDE is the first configurable general purpose transaction control / rights protection solution for users of computers, other electronics, networks and information highways.</p><p> The fundamental problem that electronic content providers have is to extend their ability to control the use of proprietary information. Content providers often need to limit their use to approved activities and quantities. For example, participants in the corporate model for film distribution and optical disc advertising include actors, directors, screenwriters and other writers, musicians, studios, publishers, distributors, retailers, advertisers, credit card services, etc. And content end users may be included. These participants will need the ability to embody the scope of contracts and requirements, including usage restrictions, into "extended" contracts that include the entire electronic enterprise model. This extended contract is represented by electronic content control information that can automatically enforce the contract by rights and obligations. Under VDE, such extended contracts may include electronic contracts that include all corporate model participants. Or, in addition, such contracts may consist of electronic contracts between a subset of corporate model participants. By using VDE, electronic commerce can function like traditional commerce. That is, commercial relationships regarding goods and services can be achieved by negotiating one or more contracts between various parties.</p><p> Commercial content providers are committed to ensuring proper compensation for their use of electronic information. For example, electronic digital information, which is a CD recording, can be copied relatively easily and inexpensively today. Similarly, rights holders suffer billions of dollars in revenue from unauthorized copying and use of software programs, according to the International Intellectual Property Alliance. Content providers and distributors have devised a number of restricted functional rights protection mechanisms to protect their own rights. Some of the more prevalent content protection schemes include authorization passwords and protocols, license servers, "lock / unlock" distribution methods, and non-electronic contracts imposed on users of shrink-wrapped software. There is a limit. In the commercial context, these efforts are ineffective and provide a limited solution.</p><p> "Electronic currency" providers have also created protection for this type of content. These systems are not sufficiently adaptable, efficient, or flexible enough to support the use of common electronic currencies. Moreover, these systems do not provide sophisticated audit and control configuration capabilities. This means that current electronic currency tools lack the sophistication required for many real-world financial enterprise models. VDE provides a means for anonymous currencies and currencies that are "conditional" anonymous, in which case currency-related activities remain anonymous except under special circumstances. VDE control capabilities VDE enables owners and distributors of electronic digital information to reliably charge for the use of electronic information, and to securely control, audit, and budget the use of electronic information. .. This allows the use of commercially available information products to be reliably detected and monitored. VDE uses a wide variety of different electronic information delivery means, including, for example, digital networks, digital broadcasts, and physical storage media such as optical disks and magnetic disks. VDE is a major network provider, hardware manufacturer, owner of electronic information, providers of such information, and information exchanges that collect usage information about electronic information and charge for the use of electronic information. Can be used by clearinghouse).</p><p> VDE provides comprehensive and configurable transaction management, weighing and monitoring technologies. VDEs can change the way electronic information products are protected, sold, packaged, and distributed. At the time of use, VDE should bring greater revenue to information providers and greater satisfaction and value to users. The use of VDEs typically lowers usage and transaction costs, makes access to electronic information more efficient, makes rights protection and other transaction management practices reusable, and uses secure information. Flexibility will be significantly improved and tools and processes for electronic transaction management will be more standardized. VDEs can be used to create a adaptable environment that meets the requirements of electronic information owners, distributors, and users; financial information exchanges; as well as usage information analysts and resellers. Rights and control information The present invention can generally be used to protect the rights of parties having: (a) Ownership or confidential interest in electronic information. This can ensure, for example, that the information is used only in approved ways; (b) Financial gains arising from the use of electronically distributed information. This may ensure that the content provider is paid for the use of the distributed information; (c) Benefits in use including electronic credit and electronic currency storage, communications, and / or electronic cash, banking and purchases.</p><p> A wide range of technologies are involved in protecting the rights of electronic community members. VDE combines these technologies to create a "distributed" electronic rights protection "environment". This environment secures and protects transactions and other processes that are critical to the protection of rights. For example, VDE provides prevention, or obstruction, interference and / or observation of transactions and processes related to material rights. In a preferred embodiment, the VDE uses a special purpose tamper-proof safety processing unit (SPU) to enable it to provide a high level of security for the VDE process as well as information storage and communication.</p><p> The rights protection problem solved by the present invention is an electronic consideration of a basic social problem. These issues include protection of property rights, protection of privacy rights, appropriate compensation for the work and risks of people and organizations, protection of money and credit, and comprehensive protection of information security. VDE uses a system that uses a common set of processes to manage rights issues in an efficient, credible and cost-effective manner.</p><p> VDEs can be used to protect the rights of parties to create electronic content such as records, games, movies, newspapers, ebooks and references, personal emails, and confidential records and communications. The invention also provides the rights of parties that supply electronic products such as publishers and distributors; for example, parties that supply electronic credits and currencies to make payments for the use of the products, such as credit exchanges and banks. Rights; The party's right to privacy of the party using the electronic content (consumers, businessmen, government, etc.) and the party's right to privacy regarding the information contained in medical, tax or personal records. Can be used to protect privacy rights.</p><p> The present invention may generally protect the rights of parties having: (a) The commercial benefit of electronically distributed information. The present invention may ensure that, for example, parties are paid for their use of the distributed information in a manner consistent with their contract; (b) Ownership and / or confidential interests in electronic information. The present invention may allow, for example, the data to be safely used only in approved ways; (c) Benefits in electronic credit and electronic currency storage, communications, and / or use. This may include electronic cash, banking and purchases; and (d) Benefits in electronic information, at least in part, obtained from the use of other electronic information. VDE functional characteristics VDE is a cost-effective and efficient protection solution that provides a unified and consistent system for securing and managing transaction processing. VDE can do the following:</p><p> (a) Audit and analyze content usage, (b) Ensure that the content is used only in approved ways, (c) make information about content use available only in a manner permitted by the content user.</p><p> In addition, VDE (a) Highly configurable, modifiable and reusable; (b) Support a wide range of useful capabilities that can be combined in various ways to provide most potential applications; (c) Operates on a wide range of electronics, from inexpensive handheld devices to large mainframe computers; (d) Different rights of many different parties and many different protection schemes can be guaranteed at the same time; (e) The rights of the party may be protected through a series of transactions that may occur at different times and at different locations; (f) Flexible acceptance of various methods of delivering information securely and reporting use; and (g) Electronic analogies of "real" money and credit, including anonymous electronic cash, to make payments for goods and services and to support personal (including home) banking and other financial activities. Provide things.</p><p> VDE economically and efficiently meets the rights protection requirements of electronic community members. VDE users do not need additional information superhighway products and additional rights protection systems for rights issues, nor do they need to install and learn new systems for new information superhighway applications.</p><p> VDE provides a unified solution that allows all content creators, providers and users to use the same electronic rights protection solution. Under approved circumstances, participants are free to exchange content and associated content control sets. This means that VDE users, if permitted, may use the same electronic system to work with different types of content that have different sets of content control information. The content and control information provided by one group may be used by people who normally use the content and control information provided by different groups. Content can be exchanged "universally" by VDE, requiring users implementing the invention to be concerned about incompatibilities in content control, infringement of rights, or to obtain, install or learn new content control systems. Can interact electronically without.</p><p> VDE securely manages transactions that specify the protection of rights. This may protect electronic rights, including, for example: (a) Ownership of the author of the electronic content, (b) Commercial rights of content distributors, (c) Any party's right to promote the distribution of content, (d) Content user privacy rights, (e) Party privacy rights represented by the stored and / or distributed content, (f) Any other right with respect to the enforcement of electronic contracts.</p><p> VDEs can enable a very wide range of electronically enforced commercial and social contracts. These contracts may include electronically enforced contracts, licenses, laws, rules and tax collection. Contrast with traditional solutions Traditional content control mechanisms often require users to purchase more electronic information than they need or desire. For example, users who use shrink-wrapped software infrequently need to purchase the program at the same price as frequently used users, even though they receive far less reward for using it infrequently. There is. Traditional systems do not determine the cost according to the degree of use or the nature of use, and consumers who may purchase feel that the fixed price is too high and cannot attract them. Also, systems that use conventional mechanisms are usually not particularly secure. For example, shrink packaging does not prevent constant software piracy, once removed from physical or electronic packaging.</p><p> Traditional electronic information rights protection systems are often inflexible and inefficient, which allows content providers to choose costly distribution channels and increase product prices. In general, these mechanisms limit the flexibility of commodity pricing, composition, and market buying and selling. These breaches result from the technology that controls information that cannot accept both different content models and content models that reflect the many different demands of model participants, such as content delivery strategies. This can limit the provider's ability to deliver sufficient overall value to justify the cost of a product given in the presence of many potential users. VDE enables content providers and distributors to create applications and distribution networks that reflect the preferred corporate model of content providers and users. This provides the user with a uniquely cost-effective and feature-rich system that supports the provider's desired information distribution method and the user's desired usage of such information. VDE supports a content control model that guarantees rights and can adapt content delivery strategies for maximum commercial outcomes. Handling and control chain VDEs may protect the collection of rights in or to various parties that have rights to electronic information. This information may be in one location or distributed across multiple locations (and / or moved between locations). Information can pass through a "chain" of distributors and a "chain" of users. Usage information can also be reported through one or more "chains" of parties. In general, by VDE, a party acting as a direct or indirect agent for a party that (a) has rights in electronic information and / or (b) has rights in electronic information is of information. It can be ensured that movement, access, modification or use can be safely controlled by rules regarding how, when, where and by whom such activities can be performed. VDE applications and software VDE is a secure system for regulating electronic processing and commerce. Regulation is guaranteed by control information 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 the "rights application". The rights application "runs" on the "basic software" of the preferred embodiment. This basic software acts as a secure and flexible foundation that can accept many different rights applications, namely different corporate models and their respective participant requirements.</p><p> Rights applications under VDE consist of parts with special purposes, each part of which may correspond to one or more basic electronic processes required for a rights protection environment. These processes can be combined like building blocks, thereby creating electronic contracts that can protect the rights of users and providers of electronic information and allow them to carry out their obligations. One or more providers of electronic information can easily combine selected building blocks, thereby creating rights applications specific to specialized content distribution models. A group of these parts may offer the capabilities needed to fulfill the contract between the user and the provider. These parts can accept many requirements for electronic contracts, including: ! Distribution of permissions to use electronic information; ! Persistence of control information and the set of control information that manages these permissions; ! Configurable control set information that can be selected by the user for use with such information; Data security and usage audit of electronic information; and A secure system for currency, compensation, and debit management.</p><p> For electronic commerce, in a preferred embodiment of the invention, the rights application may provide electronic enforcement of corporate contracts among all participants. Since different groups of components can be assembled for different applications, the present invention can provide electronic control information for a wide range of different products and markets. This means that the present invention may provide an "integrated" efficient, secure and cost-effective system for e-commerce and data security. This allows VDE to become the single standard for electronic rights protection, data security, and electronic currency and banking operations.</p><p> In VDE, the separation between rights applications and their foundations allows efficient selection of the appropriate set of control information for each of many different types of applications and uses. These control sets may reflect both the rights and obligations of members of the electronic community, such as providing a usage history of a person's products or paying taxes on an electronic purchase of a person. VDE flexibility allows VDE users to electronically implement and enforce common social and commercial ethics and practices. By providing a unified control system, the present invention supports a wide range of potential transaction-related interests and concerns of individuals, communities, businesses and governments. Due to its open design, VDE "adds" applications (usually under safe control) to the system using technology independently created by the user and is used with the basis of the present invention. Will be possible. In short, VDE provides a system that can highly reflect and enforce contracts between parties. This system is a wide range of systematic solutions that meet the urgent need for a safe, cost-effective and fair electronic environment.</p><p> VDE implementation Preferred embodiments of the present invention include various tools that allow system designers to directly insert VDE capabilities into their products. These tools include an application programmer's interface (API) and rights permissions and management language (RPML). RPML provides comprehensive and detailed control over the use of the features of the invention. VDE also includes certain user interface subsystems to meet the demands of content providers, distributors and users.</p><p> Information distributed using VDE can take many forms. For example, information can be "distributed" for use on an individual's own computer. That is, the present invention can be used to provide security to locally stored data. Alternatively, VDE may be used with information distributed by the author and / or publisher for one or more recipients. This information can take many forms, including: They include movies, audio recordings, games, electronic catalog shopping, multimedia, training materials, email, and personal documents, object-oriented libraries, software programming resources, and reference / record keeping information resources (corporate databases, medical databases, law). Databases, scientific databases, administrative databases, and consumer databases).</p><p> The electronic rights protections provided by the present invention are also credible and efficient home banking and commercial banking, electronic credit processes, electronic purchases, true or tentatively anonymous electronic cash, and EDI (electronic). It also provides an important basis for data interchange). VDE makes important enhancements to improve data security in organizations by providing "smart" transaction management features that can be far more effective than key and password-based "go / no go" technologies.</p><p> VDEs typically include cryptographic and other security technologies (eg, encryption, digital signatures, etc.) and component-based, distributed, and event-initiated operating system technologies, as well as related communications, object containers, databases, and smart agents. Uses integration with other technologies, including smart cards, and semiconductor design technologies. I. Overview A.VDE solves key issues and meets critical needs.</p><p> The world is moving towards the integration of electronic information devices. This interconnection of devices provides the basis for the development of even greater electronic interactions and electronic trading. Various capabilities are required to implement an e-commerce environment. VDE offers many of these capabilities and is therefore the first system to solve the basic problems associated with electronic distribution of information.</p><p> Electronic content VDE makes it possible to make electronic arrangements involving two or more parties. These contracts themselves may include the collection of contracts between participants in a commercial value chain and / or a data security chain model for handling, auditing, reporting and payment. This may provide a consistent, effective, reusable and modifiable means for secure electronic content such as distribution, usage control, usage payments, usage audits, and usage reporting. Content includes, for example:</p><p> ! Financial information such as electronic currencies and credits, ! Reference databases, commercially distributed electronic information such as movies, games and advertisements, and ! Electronic properties generated by individuals and organizations, such as documents, emails and ownership database information.</p><p> VDE enables an e-commerce market that supports alliances, contracts, and the entire evolving corporate model of different competing companies.</p><p> Due to the characteristics of VDE, VDE can serve as the first credible electronic information control environment that can meet and support a large number of traditional e-commerce and data security requirements. In particular, VDE creates an electronic version of traditional corporate contract agreements and terms for participants in the corporate value chain model, and further adapts the e-commerce model so that these participants consider it appropriate for their corporate requirements. It will be possible to develop and develop.</p><p> VDE provides an architecture that avoids reflecting specific distribution biases, management and control perspectives, and content types. Instead, VDE provides a broad spectrum, essentially configurable and portable e-commerce control, distribution, use, auditing, reporting and payment operating environment. VDEs are not limited to applications or application-specific toolsets that cover only electronic interaction activities and a limited subset of participants. Rather, VDE supports systems in which such applications can be created, modified and / reused. As a result, the present invention provides electronic device interoperability, content container interoperability, and e-commerce applications and the use of programmable and secure e-commerce management foundations and reusable and extensible executable components. It provides a system that supports a standardized control environment that facilitates the efficient creation of models, thereby meeting urgent and open demands. VDEs may support a single electronic "world" in which most forms of electronic trading activity can be managed.</p><p> To provide a system that meets the growing demands of rights owners and content providers and can accept the requirements and contracts of all parties (creators, distributors, administrators, users, credit providers, etc.) who may be involved in the electronic enterprise model. In addition, VDE provides efficient, largely transparent, low-cost and sufficiently secure systems (supporting both hardware / software models and software-only models). VDE provides a wide range of safety control and management capabilities required:</p><p> 1. Various types of electronic content, 2. Different electronic content delivery schemes, 3. Different electronic content usage schemes, 4. Various content use platforms, and 5. Different content market buying and selling and model strategies.</p><p> The VDE can be combined or integrated with many separate computers and / or other electronic devices. These devices typically provide a secure subsystem that can allow control of content usage for use such as display, encryption, decryption, printing, copying, storage, extraction, embedding, distribution, auditing, etc. Including. A secure subsystem in a preferred embodiment is one or more "protected processing environments", one or more secure databases, and a secure "component assembly" that needs to be maintained in a secure state. And other items and processes. For example, VDE uses such "secure subsystems" to include electronic currency, payments, and / or credit management (electronic credit and / or currency receipt, payment, imposition of debt, and / or allocation. ) Can be safely controlled.</p><p> VDE provides a secure decentralized electronic transaction management system for controlling the distribution and / or other use of electronically supplied and / or stored information. VDE controls the auditing and reporting of electronic content and / or equipment use. For VDE users, apply control information about content usage, usage reporting, and / or usage payments to electronic content and / or equipment for users such as end-user organizations, individuals, and content and / or device distributors. May include content creators. VDE also, in the form of electronic credit and / or currency, the money that one or more parties ow to one or more other parties, including the money paid for the use of content and / or equipment. Support payment.</p><p> Electronic devices under the control of VDE represent VDE "nodes" that securely process and control distributed electronic information and / or device 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, the VDE may constitute an electronic contract between VDE participants that represents a "negotiation" between the control requirements of two or more parties, and defines the contracts and terms of the resulting contract. VDE guarantees each party's rights to electronic contracts for a wide range of electronic activities related to electronic information and / or equipment use.</p><p> Through the use of VDE's control system, traditional content providers and users can establish electronic relationships that reflect traditional and non-electronic relationships. Content providers and users may adapt and modify commercial relationships to accommodate growing demands between providers and users and contracts between them. VDE does not require electronic content providers and users to change the corporate regulations and personal preferences of electronic content providers and users to accommodate weighing and control application programs that support limited and mostly fixed functionality. In addition, VDE requires, for example, detailed reporting of content usage information, many individual transactions at low prices that were previously infeasible, involvement of participants or prior knowledge of participants. Participants can develop an infeasible corporate model with non-electronic transactions, including pass-along controls that are implemented without.</p><p> The present invention allows content providers and users to formulate their trading environment to accommodate:</p><p> (1) Desired content model, content control model, and content usage information route, (2) All range of electronic media and distribution means, (3) Extensive pricing, payment and audit strategies, (4) Very flexible privacy and / or reporting model, (5) Practical and effective security architecture, and (6) Along with steps (1)-(5), other management procedures that may enable most "real-world" e-commerce and data security models, including models unique to the electronic world.</p><p> VDE's transaction management capabilities can enforce:</p><p> (1) Privacy rights related to electronic information and / or information about the use of the device, (2) Social policies such as laws that protect the rights of content users or require tax collection resulting from electronic transaction revenues, (3) Party ownership and / or other rights related to ownership, distribution and / or other commercial rights related to electronic information.</p><p> VDE can support "real" commerce in electronic form. It is a progressive world of commerce that over time forms a network of interrelated contracts that represent a value chain corporate model. This is achieved, in part, by allowing the content control information to evolve through the interaction (negotiation between them) of a set of content and / or device control information that is securely created and submitted independently. Will be done. Different sets of content and / or device control information may be submitted by different parties in the electronic enterprise value chain enabled by the present invention. These parties create a control information set by using their respective VDE installations (equipment). Independently and securely deliverable component-based control information enables effective interaction between control information sets supplied by different parties.</p><p> VDE allows for multiple separate electronic agreements between a subset of parties in a VDE-supported electronic value chain model. When these multiple contracts are combined, they include the VDE value chain "extended" contracts. As additional VDE participants become involved in the handling of VDE content and / or device control information, VDE may allow the electronic contracts that make up such configurations, and thus the entire VDE extension contract, to develop and reconform over time. .. The VDE electronic contract can be extended even if new control information is submitted by existing participants. With VDE, trading participants are free to configure and reconstruct their own e-commerce business activities and relationships. As a result, the present invention can develop competing e-commerce markets, as the use of VDE allows for a wide variety of different corporate models with the same or shared content.</p><p> An important aspect of the invention's ability to generally support e-commerce is delivered independently, including control information (usually in the form of a VDE object containing one or more methods, data, and load module VDE components). The ability to securely manage VDE component objects. This independently delivered control information can be integrated with other existing content control information superior (senior) to safely form the control information induced using the negotiation mechanism of the present invention. All requirements specified by this obtained control information must be met before VDE controlled content can be accessed or used. This means that, for example, all load modules listed by the required obtained control information and any intervening data must be available and perform their required functions safely. Means. Combined with another aspect of the invention, a safe, independently delivered control component allows e-commerce participants to freely define their own corporate requirements and trade-offs. As a result, as with traditional non-electronic commerce, the present invention can develop e-commerce (via the progressive provisions of various control requirements by VDE participants) into the most efficient and competitive form of enterprise. ..</p><p> VDE provides the capabilities to streamline support for e-commerce and e-commerce management. This rationalization arises from the reusability of control structures and user interfaces for a wide range of activities related to transaction management. As a result, content usage control, data security, information auditing and electronic financial activities can be supported with reusable, convenient, consistent and popular tools. In addition, a rational approach-trading / distribution control standards-to support a wide variety of types of information, corporate market models, and / or confidential purposes for all participants in VDE. Allows the same basic set of hardware control and security, authoring, management and management tools.</p><p> By using VDE as a general purpose electronic trading / distributed control system, users can maintain a single trading management control arrangement on each computer, network, communication node, and / or other electronic device. Such general purpose systems meet the needs of many e-commerce management applications without the need for different installations (equipment) for different purposes. As a result, VDE users can avoid the confusion, costs and other inconveniences of different restricted purpose transaction control applications for each different content and / or corporate model. For example, VDE allows content creators to use the same VDE basic control configuration for content authoring and for inclusion in products or for licensing content from other content creators for other uses. Information exchanges, distributors, content creators, and other VDE users all (generally transparently) utilize and reuse the same distribution tools, mechanisms, and consistent user interfaces, regardless of the type of VDE activity. Can interact with and interact with applications running on VDE installations in a completely consistent manner.</p><p> By controlling and auditing (and other controls of use) of electronically stored and / or distributed information, VDE prevents unauthorized use of electronic information in many forms. This includes, for example, commercial content, electronic currencies, electronic credits, corporate transactions (such as EDI), confidential communications and the like. VDEs are also commercially available in user-specified portions, rather than restricting users to use "predetermined" parts of content for billing by Content Creators and / or other providers. It can be used to make electronic content available to users.</p><p> VDE can use, for example: (1) Safe weighing instruments for budgeting and / or auditing electronic content and / or equipment use, (2) A secure and flexible means that enables compensation and / or billing rates for content and / or device use, including electronic credit and / or monetary mechanisms for payment instruments; (3) Securely distributed database means for storing information related to control and use (and using partitioning and tagging schemes found to be valid); (4) Safe electronic device control means; (5) A decentralized and secure "virtual black box" that includes nodes located at all user locations (including VDE Content Container Creators, other Content Providers, Client Users, and Recipients of Secure VDE Content Usage Information). ". The node of this virtual black box usually contains a secure subsystem having at least one secure hardware element (semiconductor element or other hardware module for safely executing a VDE control process). Secure subsystems are distributed across nodes along information storage, distribution, payment, use and / or audit pathways. In some embodiments, the functioning of the hardware element may be performed by software on some or all of the nodes, eg, in the host processing environment of an electronic device; (6) Encryption and decryption means; (7) A secure means of communication using authentication, digital signatures, and encrypted transmission. A secure subsystem at a user node establishes and authenticates the identity of each node and / or participant, and provides one or more secure host-host encryption keys for communication between secure subsystems. Use the protocol to establish; and (8) For each VDE installation, VDE content authoring (placement of content in VDE containers with associated control information), content distribution, and content use, as well as information exchanges and other information exchanges using content usage information. A secure control measure that can enable management and analysis activities to take place.</p><p> VDEs can be used to properly transition most non-electronic traditional information delivery models, including entertainment, reference materials, catalog shopping, etc., to secure digital distribution and usage management and payment contexts. Decentralized and financial channels managed by the VDE configuration include: ! Content Creator, Distributor, ! Redistributor, ! Client admin, ! Client user, ! Financial Information Exchange and / or Other Information Exchanges, ! And / or government agencies.</p><p> These distribution and financial channels can also include: ! Advertiser, ! Market research organization and / or ! Other parties interested in using the information securely delivered and / or stored using VDE.</p><p> Participants in a VDE configuration typically use the same secure VDE foundation. Another embodiment supports VDE configurations that use different VDE foundations. Such another embodiment may use procedures to ensure that certain interaction requirements are met.</p><p> VDE installations that replace or supplement secure VDE hardware (also known as SPUs representing safety processing units) or hardware (provided by the Host Processing Environment (HPE)) using software are the present invention. Works in collaboration with secure communications, system integration software, and distribution software control information and support structures to achieve an electronic contract / rights protection environment. Overall, these VDE components include secure, virtual, distributed content and / or device control, auditing (and other management), reporting and payment environments. In some commercially acceptable embodiments, certain VDE participants, such as information exchanges that typically maintain a sufficiently physically secure non-VDE processing environment, use HPE rather than VDE hardware elements. It can be used, for example, to interact with VDE end users and content providers. Overall, VDE components include a configurable, consistent, secure, and "trusted" architecture for distributed asynchronous control of electronic content and / or equipment use. VDE supports a "global" environment for electronic content delivery, widespread distribution, usage reporting and usage-related payment activities.</p><p> VDE provides generalized configurability. It is, in part, a wide range of generalized requirements to support e-commerce and data security that can be assembled to form control methods for e-commerce applications, commercial e-commerce and data security configurations. It is caused by decomposing into "atomic" level and higher level components (load modules, data elements, methods, etc.) that can be various components. VDE provides a secure operating environment using VDE foundation elements along with secure, independently deliverable VDE components that can develop e-commerce models and relationships. VDE expresses that content providers have agreed over time that subsequent content providers and / or users will participate in the adaptation of control information for and as a result of their use of electronic content and / or electronics. It specifically supports the opening of distribution models that may or may allow it. The very wide range of functional attributes that are important for supporting e-commerce and data security activities from simple to very complex are supported by the capabilities of the present invention. As a result, VDE supports most types of electronic information and / or equipment: usage control (including allocation), security, usage auditing, reporting, and other management and payment configurations.</p><p> In a preferred embodiment, VDE uses object software technology and uses object technology to form a "container" for the delivery of (at least in part) encrypted or secure information. These containers may contain some or all of the electronic content products or other electronic information and their associated permission (control) information. These container objects can be distributed along routes related to content providers and / or content users. They can safely move between nodes in a Virtual Distribution Environment (VDE) configuration. These nodes operate the VDE basic software and establish the electronic information usage control and / or management model by executing the control methods. A container delivered by using a preferred embodiment of the invention is for distributing VDE control instructions (information) and / or for encapsulating and electronically distributing at least partially secure content. Can be used for both.</p><p> Content providers using the present invention include, for example, software application and game publishers, database publishers, cable, television and radio broadcasters, electronic shopping sellers, and electronic documents, books, periodicals, emails and / or Includes distributors of information in other forms. The "end user" of corporations, government agencies and / or individuals who act as stores and / or distributors of electronic information may be VDE content providers (in a restricted model, users own the content themselves. Supply only to yourself and use VDE to protect your own confidential information from unauthorized use by another party). Electronic information may include proprietary and / or confidential information for personal or internal use, as well as software applications, documents, entertainment material, and / or reference information that may be supplied to other parties. Distribution can be by physical media delivery, broadcasting and / or telecommunications means, for example in the form of "static" files and / or data streams. VDE can also be used for multi-site "real-time" interactions such as electronic conferences, interactive games, or online bulletin boards where restrictions and / or audits are enforced on the use of some or all of the communicated information, for example. ..</p><p> VDE provides an important mechanism for implementing commercial contracts and enabling the protection of privacy rights. VDE may securely deliver information from one party to another regarding the use of electronic content sold. Even if the parties are separated by several "steps" in the chain of handling for such content usage information, such information is VDE via encryption and / or other secure processing. Protected by. Due to its protection, the accuracy of such information is guaranteed by VDE and the information can be trusted by all parties to which it is delivered. In addition, since such information is encrypted so that it can only be decrypted by the authorized party or its agents, all parties trust that this information can only be received by the intended and authorized party. It is guaranteed by VDE that it can be done. Such information is obtained via secure VDE processing at the previous handling route location, thereby generating secure VDE reporting information, which is then safely sent to the intended recipient's VDE safety subsystem. Can be communicated. VDE can securely deliver such information, so that the party making the electronic contract is accurate in commercial usage information and / or other information delivered through means other than those under VDE's control. You don't have to trust.</p><p> VDE participants in the commercial value chain "commercially" ensure that direct (constituent) and / or "extended" electronic contracts concluded by using VDE can be reliably enforced. Reliable (ie, sufficiently reliable for commercial purposes). These contracts may have aspects related to "dynamic" transaction management, such as content usage control information enforced by electronic and / or equipment usage budgeting, weighing and / or reporting, and / Alternatively, it may include "static" electronic claims, such as not passing electronic information obtained from payments for services, use of content or systems to unauthorized parties, and / or agreeing to protect copyright. Not only can information related to electronically reported transactions be trusted by the present invention, but payments are automated by passing payment tokens through a payment channel (which may or may not be the same as the channel for reporting). Can be done. Such payments are based on VDE-controlled electronic content and / or equipment (such as government agencies, financial credit providers, and users) and electronic accounts (eg, accounts secured by the user's VDE installation security subsystem). Automatically by VDE installation in response to control information (in the preferred embodiment, located within one or more permission records) that defines a "withdrawal" of credits or electronic currency (such as tokens) from Can be contained within the created VDE container.</p><p> VDE meets the demands of e-commerce participants and allows all such participants to be brought together in a globally trusted commercial network that can be secure enough to support very large commerce. The VDE Security and Metric Safety Subsystem Core (core) is where the VDE-related content is (a) control information (rules and arbitration data) related to the assigned use, and / or (b) used. , Exists in all physical positions. This core is a decentralized, highly secure VDE-related hardware interconnected by a secure information exchange (eg, telecommunications) process and distributed database means, referred to as a "virtual blackbox." Can perform security and auditing functions (including weighing) that operate within a collection of examples. VDE also provides highly configurable trading operating system technology, one or more related libraries of load modules with associated data, VDE-related management, data preparation and analysis applications, and VDE integration into host environments and applications. Includes system software designed to enable it. VDE usage control information includes, for example, use authorization, use audits (including audit discounts), use charges, use payments, privacy breaches, reporting and security related communications and related to property content and / or equipment. Provides encryption technology.</p><p> VDE makes extensive use of software object form methods to improve the configuration, portability, and security of the VDE environment. VDE also uses a software object architecture for VDE content containers that hold protected content. The VDE may also retain both freely available information (eg, content gist, table) and secure content control information that guarantees the performance of the control information. Content control information is content according to standards set by the holder of rights to the content of the object and / or according to the parties (governments, financial credit providers, and users) who have the rights associated with the distribution of such content. Decide to use.</p><p> In part, the cryptographic schemes used to protect objects can be further used efficiently to protect associated content control information (software control information and related data) from alterations, and thus the present invention. Increased security depending on the object method used by. Because electronic information in the form of content can be inserted with content control information (eg, as content information within the same object container), thereby creating a "published" object (for said content). This object technology increases portability between various computer and / or other device environments. As a result, different parts of control information can be specifically adapted to different environments such as different computer platforms and operating systems. All the various parts can be loaded in a VDE container.</p><p> The purpose of VDE is to support trading / distribution control standards. The evolution of such standards includes many obstacles, given security requirements and related hardware and communication issues, very different environments, information types, types of information use, corporate and / or data security purposes, and a variety of other things. You own the participants and the information delivered. An important feature of VDE is, in part, many different distributions and generalized capability modules that enable electronic commerce and data security functions within secure hardware SPUs and / or corresponding software subsystems. Allows great flexibility in decomposing other trading variables and even assembling, modifying and / or replacing such modules (eg load modules and / or methods) in applications running on the VDE installation basis. By including many different distribution and other trading variables. This constructivity and reconfigurability allows e-commerce and data security participants to reflect their priorities and requirements through the process of iteratively adapting evolving and extended electronic contracts (electronic control models). This adaptation can occur to the extent enabled by "in place" content control information as content control information is passed from one VDE participant to another. This process allows VDE users to recast existing control information and / or add new control information as needed (including removing elements that are no longer needed). Become.</p><p> VDE supports a credible (sufficiently secure) electronic information distribution and usage control model for commercial electronic content distribution and data security applications. VDE to meet various requirements of networks of interrelated participants, including content creators, content distributors, client administrators, end users and / or information exchanges and / or other content usage information users. Can be configured. These parties may constitute a network of participants involved in electronic content distribution, usage control, usage reporting and / or usage payments, from simple to complex. The distributed content can include both originally supplied information and VDE-generated information (such as content usage information), and the content control information is the content and the chain of content control information handling (one or more paths) and the content. Can be sustained through both direct use. The constructivity provided by the present invention is particularly important to support electronic commerce, which allows businesses to build relationships and develop strategies that provide competing value. Electronic trading tools that are neither configurable nor interactable in nature cannot ultimately produce products (and services) that meet both the basic requirements and the evolving requirements of most trading applications.</p><p> The basic structure of VDE allows a wide range of competing e-commerce enterprise models to succeed. This allows the enterprise model to be adapted to maximize revenue sources, end-user product value, and operational efficiency. VDEs can be used to support multiple different models, to take advantage of new revenue opportunities, and to deliver the product configurations most desired by users. The following things that the present invention does, that is, Support for a wide range of possible complementary revenue activities, Providing a flexible array of content usage features most desired by customers, and Use of opportunities to increase efficiency, Using e-commerce technology that does not do so often results in products that are inherently more costly, less attractive, and therefore less competitive in the market.</p><p> Key factors that contribute to the essential constructability of the present invention include:</p><p> (a) Extensive electronics foundations through portable APIs and programming language tools that efficiently support control and audit capability merging in almost any electronics environment while maintaining overall system security. Integration into a typical control environment; (b) Modular data structure; (c) Comprehensive content model; (d) General modularity and independence of underlying architecture components; (e) Modular security structure; (f) Multiple branch chains of variable length and control; and (g) An independent modular control structure in the form of an executable load module that can be maintained in one or more libraries and assembled into control methods and models, where the control information is the path of VDE content control information handling. After passing the participant's VDE installation, such a model control scheme can "evolve".</p><p> Due to the range of problems solved by the present invention, a single that can prevent unauthorized use of confidential and / or proprietary information and commercial electronic transactions for a very broad commercial and data security model. Trading / distribution control systems can be prepared for emerging "electronic highways". VDE's e-commerce management mechanism can enforce the electronic rights and contracts of all parties participating in a wide variety of enterprise and data security models, enabled by a single VDE installation within each VDE participant's electronics. Can be achieved. VDE supports a wide variety of enterprise and / or data security models that can involve a wide range of participants at various "levels" of content control information pathways for VDE content and / or handling. Different content controls and / or audit models and contracts can be available in the same VDE installation. These models and contracts are broadly given, for example, content related to general VDE installations and / or users, certain users, installations, classes and / or installations and / or other grouping of users. You can control content related to electronic content, specific characteristics, characteristic parts, classes and / or other grouping of content on your installation.</p><p> Distribution using VDE packages both electronic content and control information in the same VDE container and / or from multiple separate remote locations and / or in multiple separate VDE content containers and / or multiple different deliveries. It may involve delivery of different parts of the same VDE management characteristics to the end user site using the main end. Content control information can be delivered in part or in whole separately from the associated content to the user VDE installation in one or more VDE managed objects. The control information portion may be delivered from one or more sources. Control information may be made available for use by accessing one or more remote VDE safety subsystems and / or VDE-compatible certified safety remote locations from the user's VDE installation safety subsystem. VDE control processes such as weighing, budgeting, decryption and / fingerprinting are performed in the user's remote VDE installation safety subsystem as related to certain user content usage activities, but the same user VDE installation. And / or can be split into multiple secure subsystems that can be located within the network server and user installation. For example, a remote VDE installation may be capable of decrypting and storing any or all of the associated usage metering information, and / or electronic equipment use in such a user installation may be between the secure subsystems described above. It can be done on a server that uses secure (eg, encrypted) communication. The above server location can be used for near real-time, frequent or more regular secure receipt of content usage information from the above user installations, for example, weighed information can be used for remote user installations. Is maintained only temporarily.</p><p> Delivery means for VDE-managed content include electronic data storage means such as optical disk electronic data storage means for delivering and broadcasting some of the above information and / or telecommunications means for other parts of the above information. Can include. Electronic data storage means include magnetic media, optical media, combination of magneto-optical systems, flash RAM memory, bubble memory and / or holography, and other memory such as mass optical storage systems using frequency and / or polarity data storage technology. Includes storage means. Data storage means use generally transparent and / or translucent material multilayer disc technology that allows light to pass through layers of data retention discs that are physically packaged together as a single thick disc. May be good. The data holding location on such a disk can be at least partially opaque.</p><p> VDE supports a general-purpose basis for secure transaction management, including usage control, auditing, reporting and / or payments. This general purpose foundation is called the "VDE function" ("VDEF"). VDEs are also a collection of "atomic-sized" application elements (eg, load modules) that can be selectively collected to form various VDEF capabilities (called control methods) that act as VDEF applications and operating system functions. Also supports. When the host operating environment of an electronic device includes VDEF capabilities, it is referred to as the "rights operating system" (ROS). The VDEF load module, associated data and methods form a major part of the information referred to as "control information" for the purposes of the present invention. VDEF control information may be specifically associated with one or more parts of electronic content or used as a normal component of the operating system capabilities of a VDE installation.</p><p> VDEF transaction control elements reflect and specify specific and / or more generalized management (eg, general operating system) control information in the content. There is, for example, one VDEF capability that can generally take the form of an application (application model) with some configuration that can be adapted by VDE participants using, for example, a VDE template to use a particular capability. Represents an electronic contract between VDE participants regarding the use of electronic content such as commercially available products, along with capability parameter data to reflect the above elements. These control capabilities manage the use and / or audit of the use of electronic content, as well as reporting information based on the use of the content, and any payments for that use. VDEF capabilities can be "developed" to receive a given set of control information or to reflect the requirements of one or more consecutive parties that contribute to that set. Participants often use VDE applications for a given content model (such as entertainment distribution on a CD-ROM, internet container, or electronic catalog shopping and advertising, or some of the above combinations). Possible alternative control methods may be selected and relevant parameter data may be given. In this case, such control method selection and / or data submission constitutes a "contribution" of control information. Alternatively (or more), certain control methods that are clearly certified to be safely interoperable and compatible with the above applications may be submitted independently by participants as part of such contributions. .. In the most common example, a generally certified load module (certified for a given VDE configuration and / or content class) is used with many or any VDE application running on a node in that configuration. Can be To the extent permitted, these parties may independently and safely add, remove, and / or modify the specifications of load modules and methods, as well as add, remove, and modify relevant information.</p><p> Generally, the party that creates the VDE content container defines the general nature of VDEF capabilities that can be applied and / or applied to certain electronic information. A VDE content container is an object that contains both content (eg, commercially available electronic information such as computer software programs, movies, electronic publications, or references) and certain control information related to the use of the object's content. The making party may make the VDE container available to other parties. The control information delivered by the VDE content container and / or available for use with the VDE content container is the VDEF control capability for electronic content (for content marketing) (and any associated parameter data). including. These capabilities control the use and / or consequences of such content and may specify contracts and conditions associated with multiple parties and the various rights and obligations of those parties. Proposed "electronic contracts (and / or contract features available for selection and / or use of parameter data) may be configured.</p><p> The VDE electronic contract may be revealed by receiving a user interface by one or more parties-for example, the "lower" party receiving control information from the "upper" party-and also owning itself. It may be an equivalent inter-party process that claims the contract individually. The contract is a VDE that determines if another electronic contract and condition attached to the content and / or submitted by another party is acceptable (does not violate acceptable control information standards). Contracts and conditions are "evaluated" by participant control information, which may result from an automated electronic process. Such an evaluation process is a very simple process, eg, control contracts and conditions in a table of contracts and conditions, some or all of the higher control contracts and conditions, and the next participant in the content control information handling path. Potential consequences of the negotiation process between two or more sets of control information submitted by two or more parties, even for comparisons to ensure compatibility with the submitted control information. It may be a more complex process of performing the evaluation and / or negotiation process. VDE also has certain controls that may be acceptable for control information that represents the answer to a user interface query for the benefit of one or more other parties and / or the choice of another option and / or certain parameter information. Includes a semi-automated process in which one or more VDE participants determine a "mismatch" between control information sets by user interface means by allowing and / or proposing information. Here, the response is adapted where it is acceptable to the applicable higher level control information.</p><p> When another party (other than the first rule applicant) receives and / or adds and / or modifies "in-place" content control information, perhaps through a negotiation process, such electronic content. A VDE agreement between two or more parties related to the use of is possible (as long as any modification matches the superior control information). The acceptance of contracts and conditions related to certain electronic content is direct and clear (for example, depending on legal requirements, giving such contracts and conditions in advance, and the requirements of appropriate control information). It may be implicit as a result of the use of the content.</p><p> The VDEF capability may be used by multiple parties without directly associating the VDEF capability with the control of certain electronic information, or a VDE contract may be made. For example, there may be one or more VDEF capabilities in a VDE installation to be used by such installations for secure control, auditing, reporting and / or payment of VDE content usage. A VDE agreement may be made during the registration process for the content distribution application. Similarly, when a user and / or their device registers with such a provider as a VDE installation and / or user, a particular VDE participant may enter into a VDE user contract with the VDE Content or electronics provider. In such cases, the VDEF-appropriate control information available for the user VDE installation is, for example, to allow the use of all and / or some classes of electronic content and / or VDE applications. , It may be necessary for some VDEF methods to be used in a sequence.</p><p> VDE securely meets certain prerequisites required for a given transaction. This includes the secure execution of any required module and the availability of any required associated data. For example, the required load module and data (in the form of a method, etc.) may specify that sufficient credit from an authorized source must be confirmed to be available. This further requires running one or more load modules as a process at the right time so that such credits can be safely used to make payments for the user's use of the content. Can be. A content provider, for example, distributes a given software program to users (part of the program may be maintained in encrypted form and may require the presence of a VDE installation to run). It may be necessary to weigh the number of copies made for. This requires performing a measurement method for copying properties each time a copy is made for another user. This same provider may also charge based on the total number of different properties granted by the user from the property, and a property authorization weighing history may be required to maintain this information.</p><p> VDE provides a globally secure environment with integrity guaranteed by processes that are securely controlled in organizations, communities and / or VDE participant user installations (nodes). In a preferred embodiment, the VDE installation may include both software and hardware semiconductor devices that cannot be tampered with. Such semiconductor structures include, at least in part, special purpose circuits designed to prevent tampering with the information and functions used in performing VDE control functions or unauthorized observations thereof. A special purpose safety circuit according to the invention is a dedicated semiconductor configuration known as a safety processing unit (SPU) and / or a standard microprocessor, microcontroller, and / or another that meets the requirements of the present invention and acts as an SPU. Includes at least one of the processing logics. VDE safety hardware can be found, for example, to be incorporated into fax / modem chips or chip packs, I / O controllers, video display controllers, and / or other available digital processing configurations. It is expected that some of the VDE safety hardware capabilities of the present invention will ultimately be the standard design equipment for central processing units (CPUs) for computers and various other electronic processing units.</p><p> By designing VDE capabilities within one or more standard microprocessors, microcontrollers and / or other digital processing components, they are identical for both transaction management use and other host electronics features considered by the present invention. Hardware resources can be used, which can reduce VDE-related hardware costs in terms of materials. This is VDE SPU means that the circuit elements of a "standard" CPU can be used (shared). For example, if a "standard" processor operates in protected mode and can execute VDE-related instructions as a protected activity, such an embodiment provides sufficient hardware security for various applications and is a special purpose processor. Expenses can be reduced. In one preferred embodiment of the invention, a memory (eg, RAM, ROM, NVRAM) is maintained in protected mode (eg, as supported by a protected mode microprocessor) during VDE-related instruction processing. To. This memory is arranged in the same package as a processing logic (for example, a processor). Desirably, the packaging and memory of such processors are designed using security techniques that enhance tamper resistance.</p><p> The degree of security of the entire VDE system depends primarily on the degree of tamper resistance and the degree of concealment of VDE control process execution and related data storage activities. The use of special purpose semiconductor packaging technology can greatly contribute to the degree of security. Concealment and tamper resistance in semiconductor memory (eg RAM, ROM, NVRAM) uses such memory within the SPU package and allows the data to be sent to an external memory (such as an external RAM package). Part can be achieved by encrypting and decrypting the encrypted data in the CPU / RAM package before the encrypted data is executed. This process is used for important VDE-related data when such data is stored on unprotected media, such as standard host storage such as random access memory, mass storage. In such cases, the VDE SPU encrypts the data obtained from a secure VDE run before such data is stored in external memory. Summary of some important features provided by VDE according to the invention VDE uses various capabilities that underlie a general purpose, sufficiently secure, decentralized e-commerce solution. VDE enables an e-commerce market that supports scattered, competing partnerships, contracts and an evolving overall corporate model. For example, VDE has the following characteristics.</p><p> "Sufficient" prevention of unauthorized and / or uncompensated use of electronic information and / or equipment through secure communications, storage and transaction management technologies. VDE supports model wide decentralized security enforcement that forms a single secure "virtual" transaction processing and information storage environment. VDEs allow distributed VDE implementations to securely store and communicate information and to remotely control the implementation process and characteristics of the use of electronic information in a wide range of ways in other VDE implementations.</p><p> !! Supports a low-cost, efficient and effective security architecture for transaction control, auditing, reporting and related communications and information storage. VDE provides security techniques related to tagging, cryptographic key aging, stored control information, including differential tagging of such information for protection against replacement and tampering) and distribution. Separation of both the content (for many content applications, to use a particular VDE installation and / or one or more content encryption keys that are unique to the user), triple DES to encrypt the content, etc. Cryptographic key technology, public key technology such as RSA that protects communications and provides the benefits of digital signing and authentication, thereby securely coupling nodes in VDE configurations with each other, secure processing of critical transaction management executable code, And a small amount of very secure hardware-protected storage space and a larger "exposed" mass media storage space to store secure (usually encrypted and tagged) control and audit information. A combination with and can be used. VDE uses special purpose hardware that is distributed in some or all locations of the VDE implementation. a) The above hardware provides content preparation (such as placing such content within a VDE content container and associating content control information with that content), content and / or electronic device usage audits, content usage analysis, and content usage. It controls the key elements of control, b) the hardware is designed to handle processing load module control activities safely, and this control processing activities can involve a sequence of required control factors.</p><p> !! Supports dynamic user selection of information subsets of VDE electronic information products (VDE controlled content). This is some high level individual pre-specified content provider information such that it is necessary to select the entire product or product section to obtain or use part of such product or section. Contrast with the constraint that increments must be used. A VDE is chosen solely for that purpose by the forming user, and is generally optional, but one or more pre-identified increments (eg, bytes, images, logical associations) that make the logical content "deliverable" to the user. Weighing and use for various increments (including "atomic" increments, and combinations of different increment types) that represent a collection of blocks (such as one or more blocks with pre-identified properties) such as blocks that have been identified. Support control. VDE control information (including budgeting, pricing and weighing) can be specifically applied as appropriate and specifically to that particular selection of a collection of unexpected and variable user choices with different information increments. Pricing level means "mixed" increments, at least in part, meaning that the amount and / or nature of mixed increment selections (eg, an associated image of some amount of text can be discounted by 15%). A larger amount of text in the selection can be configured to get based on (meaning that the image can be discounted by 20%). Such user-selected aggregated information increments can reflect the user's actual requirements for information and are limited to a single or some high level (eg, product, document, database record) predetermined increment. It's more flexible than the one. Such a high level increment may contain an amount of information that is not desired by the user and, as a result, may be more costly than the subset of information required by the user if the subset is available. in short, The present invention makes it possible to supply information contained in an electronic information product according to user specifications. By conforming to the user specifications, the present invention can give the user maximum value, which results in the maximum amount of electronic trading activity. The user may specify, for example, the accumulation of content obtained from various parts of the available content product, but these parts are in a completely unique accumulation increment as deliverable for use by the user. is there. The user selects a certain number of bytes of information from various parts of the information product, such as reference material, copies those bytes to disk in unencrypted form, and adds that byte to the total number of bytes. You may be charged based on an additional charge for the number of "goods" you provide. Since the user does not need all the content from all the products containing the desired information, the content provider may be charged a reasonably lower amount for such user-specified information increments. This process of defining the information increments that the user desires contributes to the location of the most relevant parts of the information from the information product, for user selection or automatic extraction and delivery of such parts to the user. A search criterion may include an artificial intelligence database search tool that automatically displays information indicating hits to the user. VDE further supports a wide variety of pre-defined increment types, including: Bytes may be selected, copied to disk in unencrypted form, and charged based on the total number of bytes plus an additional charge for the number of "goods" that provided the bytes. Since the user does not need all the content from all the products containing the desired information, the content provider may be charged a reasonably lower amount for such user-specified information increments. This process of defining the information increments that the user desires contributes to the location of the most relevant parts of the information from the information product, for user selection or automatic extraction and delivery of such parts to the user. A search criterion may include an artificial intelligence database search tool that automatically displays information indicating hits to the user. VDE further supports a wide variety of pre-defined increment types, including: Bytes may be selected, copied to disk in unencrypted form, and charged based on the total number of bytes plus an additional charge for the number of "goods" that provided the bytes. Since the user does not need all the content from all the products containing the desired information, the content provider may be charged a reasonably lower amount for such user-specified information increments. This process of defining the information increments that the user desires contributes to the location of the most relevant parts of the information from the information product, for user selection or automatic extraction and delivery of such parts to the user. A search criterion may include an artificial intelligence database search tool that automatically displays information indicating hits to the user. VDE further supports a wide variety of pre-defined increment types, including:</p><p> !Part-Time Job, !image, ! Content over time for audio or video, or !Sentence, ! Paragraph, !chapter, ! Database records, and ! Byte offset representing the increment of logically associated information Content provider data mapping such as any other increment that can be identified by effort.</p><p> VDE supports a pre-specified number of simultaneous increment types, as many as can be practical for a given type of content and enterprise model. Inexpensive to maintain detailed information in encrypted data form and to maintain summary information for security testing in very secure special purpose VDE installation non-volatile memory (if available) "Exposure" Host Mass storage is used to securely store potentially very detailed information in the user's location that reflects the use of users of a variety of different content segment types. !! Support a trusted chain of handling capabilities for the channels of distributed electronic information and / or content usage related information. Such chains extend from content creators to distributors, redistributers, client users, for example, and then one or more of the same and / or different usage information, such as one or more independent information exchanges. Can safely report to an auditor and then provide a route back to the content provider, including the content creator. The same and / or different routes used for handling certain content, related control information and reporting information are electronic content and / or electronic payment processing for device specifications (payment is characterized as managed content in the present invention). ) Can also be used as one or more routes. These routes are used to carry whole and part of the content and / or content-related control information. Content creators and other providers have routes that must be used in part or in whole to deliver commercially distributed property content, content control information, payment management content, and / or related usage reporting information. Can be specified. The control information specified by the content provider may specify that a particular party must or can handle the information carried (eg, including a group of suitable parties from which selections can be made). It can also specify which transmission means (eg, telecommunications carrier or medium type) and transmission hub must or can be used. Flexible, such as using "bitmap weighing" that achieves highly efficient operation and throughput, and allows for practical retention of information and related patterns related to previous usage activities and feasible recalls. Supports various audit mechanisms. This flexibility is adaptable to a wide variety of billing and security control strategies:</p><p> P Upgrade pricing (eg renewal purchase), P Price discount (including volume discount), P Billing-related period variables such as discounts on new purchases based on the timing of past purchases, and P A security budget based on the amount of different, logic-related units of electronic information used over a time interval.</p><p> The use of bitmap metrics (including "regular" and "wide" bitmap metrics) to record the use and / of purchase of information along with other elements of the preferred embodiments of the invention is (a) rental, ( b) Flat-rate licenses or purchases, (c) Discounts on licenses or purchases based on historical usage variables, and (d) whether an item was acquired or acquired within a period of time (very much for these applications). Uniquely supports the efficient maintenance of usage history for reporting to users to allow them to make decisions (without requiring the use of traditional database mechanisms that are inefficient). .. Bitmap Measurement Act has caused activity in which the content and / or device provider and / or controller of management activity has been at some point in the past or for a period of time (eg, commercial electronic content products and / or device). Records activities related to electronic devices, characteristics, objects, or parts thereof, and / or management performed by users and / or electronic devices that are unrelated to specific characteristics, objects, etc. To do. Such decisions can then be used as part of content and / or equipment provider pricing and / or control strategies, and / or as controllers for management activities. For example, a content provider may choose to charge only once for access to a portion of a property, regardless of how many times the portion of the property is accessed by the user.</p><p> ! Supporting "launchable" content, which may be provided to the end user by the content provider, the end user then content to register and / or initialize the content for use. Content can be copied or passed to another end-user party without requiring the provider to participate directly. This content is "traveling object (traveling) Proceed "outside the (conventional distribution) channel" in the form of "object)". The move object is a method that is required for at least some permission information and / or use (such a method is available in the destination VDE installation, or the destination VDE instrument. A container that safely carries (does not have to be carried by moving objects) if it is available directly to the method. A moving object can be used in some or all of a given VDE configuration or all VDE installations. This is because the content control information required for content use can be made available without the involvement of a commercial VDE value chain participant or data security administrator (eg, controller or network administrator). At least some moving object content is remote, as long as the moving object's control information requirements are available in the user VDE installation safety subsystem (such as having a sufficient amount of financial credit from an approved credit provider). It can be used by the receiving party without the need to establish a relationship with VDE privileges (for example, until the budget is exhausted or there is a time content usage reporting interval). Moving objects move "out of the channel" and allow the user to give neighbors a copy of the moving object whose content is, for example, a software program, movie, or game. Neighbors have the appropriate credit (eg VISA or AT &amp; If an information exchange account from an information exchange such as T) is available, a moving object can be used. Similarly, electronic information commonly available in storage locations on the Internet (or similar networks) is downloaded and then copied by early downloaders to other parties who may pass the object to an additional party. It can be provided in the form of moving objects that can be passed.</p><p> ! Groups such as individuals, installations, classes, and features and client identifications (eg, client identification IDs, client department IDs, client network IDs, client project IDs, and client employer IDs, or any of the appropriate subsets above). Provides highly flexible and extensible user identification through hierarchical identification using the level hierarchy of.</p><p> !! It provides a general purpose secure component-based content control and distribution system that acts as a basic trading operating system environment with executable code pieces created for trade control and auditing. These code parts can be reused to optimize efficiency in the formation and operation of trusted decentralized transaction management configurations. VDE supports the provision of such executable code in the form of "atomic" load modules and associated data. Many such load modules are essentially configurable, aggregate, portable, extensible, single or combined (with associated data), as control methods under the VDE trading operating environment. Will be executed. VDE can meet the requirements of very different electronic trading and data security applications, in part by using this general purpose trading management foundation to securely handle VDE trading related control methods. Control methods are primarily formed by the use of one or more of the above executable reusable load module code parts (usually in the form of executable object components) and associated data. The component nature of control methods allows the invention to operate efficiently as a highly configurable content control system. In the present invention, the content control model, if done (new component assemblies are allowed, if allowed, certification requirements exist for such component assemblies, or either). Can participants adapt any or some control information by selection from selective control information (permission recording) control methods), to the extent that such adaptations and updates meet the constraints given by the VDE application. It can be iteratively and asynchronously adapted or updated to meet the requirements of the participants. This repetitive (or simultaneous) compound The number participant process results from the submission and use of secure control information components (load modules and / or methods, and / or executable code such as related data). These components may be given independently by secure communication between each control information affecting the VDE installation of a VDE participant and may require proof for use with a given application, in which case such. Proof is provided by the Proof Service Manager for VDE configuration to ensure secure interaction and / reliability (eg, bug control resulting from the interaction) between the device and the presented control methods. The transaction management control function of the VDE electronics trading operating environment interacts with the insecure transaction management operating system function, thereby appropriately guiding the data related to the transaction process and electronic information security, usage control, auditing and usage reporting. VDE provides the capabilities to manage secure VDE content and / or resources related to device control information execution and data storage. Properly guide the data related to the report. VDE provides the capabilities to manage secure VDE content and / or resources related to device control information execution and data storage. Properly guide the data related to the report. VDE provides the capabilities to manage secure VDE content and / or resources related to device control information execution and data storage.</p><p> ! Facilitates the formation of application and / or system functionality under VDE and facilitates the integration of load modules and methods formed by the present invention into the electronics environment. To achieve this, VDE uses a trading operating system (such as ROS) programming language with application programmer interfaces (APIs) and / or built-in functions. Both of these can be used to support the use of capabilities and to efficiently and tightly integrate VDE functionality into commercial and user applications.</p><p> ! (a) A "pop-up" application that allows the user to take certain actions, such as giving a message to the user and authorizing the transaction, (b) per transaction, per hour unit and / or per session. User activities such as end-user preference specifications to review budget, consumption (eg, detailed and / or rough) and usage analysis information, to limit the price of, to access historical information about previous transactions. A stand-alone VDE application that provides a management environment for, and (c) the underlying functionality is incorporated into the original design of the commercial software, so that VDE user control information and services are seamlessly incorporated into such software. VDE "recognition" of commercial or internal software (application programs, games, etc.), VDE so that it can be accessed directly by the user Supports user interaction through embedded VDE-aware applications as a result of using APIs and / or transaction management (eg, ROS-based) programming languages. For example, in a VDE-aware word processor application, by "printing" a document onto a VDE content container object and choosing from a set of different menu templates for different purposes (eg, a secure memo template for internal organization purposes). It may be possible to give specific control information (which can limit the ability to "hold", i.e. make electronic copies of notes).</p><p> !! When the process of configuration capabilities of the present invention is relevant to a particular industry or company, "templates" are used to facilitate those processes. Templates are applications or application add-ons according to the invention. Templates support operations on efficient specifications and / or criteria associated with a particular content type, distribution approaches, pricing mechanisms, user interactions with content and / or management activities, and more. Given the very wide range of capabilities and configurations supported by the present invention, complex programming and / or configurations by reducing the range of configuration opportunities for manageable subsets that are particularly suitable for a given corporate model. It makes it easier for "general" users who are burdened with design responsibility to use the full configurable capabilities of the invention, and template applications can predict code interactions between independent modules and applications. VDE-related processes are safe by reducing the risks associated with the contribution of independently developed load modules, including the impossible aspects and the security risks associated with the potential for virus presence in such modules. Optimal can be assured that it is bug-free. By using templates for control information purposes such as multiple choices, icon selections, and / or prompts for method parameter data (identification information, prices, budget limits, dates, time periods, access to specific content, etc.) VDE reduces general user configuration responsibility for properly squeezed sets of activities, including selection of method types (eg, functionality) by menu selection that provides the appropriate and / or required data for. General (non-programming) to a limited subset of configuration activities that have a general configuration environment (template) pre-configured to reflect general requirements for that user, content, or other corporate model. By restricting users Content containerization (including placing initial control information on content), distribution, client management, including related interoperability issues (such as inconsistencies resulting from security, operating system, and / or proof incompatibilities) , Electronic contract enforcement, end-user interaction and information exchange activities and related issues can be substantially restricted. By using the appropriate VDE template, user activity related to content VDE containerization, other control information contributions, communications, cryptography and / or keys, etc., meets specifications for distributed VDE configurations. Can be guaranteed to the user.</p><p> VDE templates evolve or allow new and / or modified templates to reflect adaptation to new enterprises as they evolve, or are usually re-developed to reflect other changes in the development of existing enterprises. Configure a pre-configured configuration that may be configurable. For example, the concept of templates is movies, audio recordings and live performances, magazines, phone-based retail, catalogs, computer software, information databases, multimedia, commercial communications, advertising, market observations, infomercial, games, numbers. CAD / CAM services for machines controlled by, etc. can be used to form, modify, market, sell, distribute, consume and / or provide an entire individual framework for organizations and individuals to use. As the context surrounding these templates changes or develops, the template application provided by the present invention can be modified to accommodate these changes for a wide range of specifications or for more squeezed activities. The party that places the content in the initial VDE container may have a variety of different configurable templates, depending on the type of content and / or the enterprise model associated with the content. End users give different document types (email, secure internal documents, database records, etc.) and / or (give different users different general sets of control information, for example, documents that are pre-set criteria. It may have different configurable templates that can be applied to a subset of users (select a list of available users). Under certain circumstances, it is clear that the template may have fixed control information and may not be given for user selection and parameter data input.</p><p> !! Multiple different controls that regulate the use and / or audit of the same particular copy of electronic information content and / or the use and / or audit of different regulated and different copies (occurrence) of multiple different control models of the same electronic information content. Support the model. Different models for billing, auditing and security can be applied to the same piece of electronic information content, and such different sets of control information can be the same or different subdivision of electronic information control increments for control. Gender can be used. This is a variety of different budgets and / or metric billing units, credit limits, security budget limits and security content metric increments, and / or given electronic information that can be delivered for market observation and customer profiling content metric increments. Includes supporting variable usage information for budgeting and auditing use, as applied to various pre-specified increments of electronic information, including using metric increments for. For example, a CD-ROM disc with a database of scientific articles may be partially charged according to a formula based on the number of bytes decrypted, the number of articles containing decrypted bytes, but the security budget is installed. You can limit the use of the database to 5% of the database each month for users on your wide area network.</p><p> Provides and controls a sufficiently secure chain of content and content control information handling and mechanisms for sustaining and maintaining trusted content use and reporting control information through various forms of such content use. Such use may continue due to the persistence of. Control persistence has at least partly secured content, controls the information in the original container, and / or is generated at least in part by the control information in the original container for this purpose. Includes the ability to extract information from VDE container objects by creating a new container that contains at least some of the extracted content and control information, and / or the VDE installation control information provision is newly formed. The use of content in the container should be sustained and / or controlled. Such control information is when the container is "embedded" in another VDE-managed object, such as an object containing multiple embedded VDE containers, each containing content derived (extracted) from a different source. , Can continue to manage the use of container content.</p><p> ! Allow users, other value chain participants (such as information exchanges and government agencies) and / or user organizations to identify preferences or requirements related to the use of electronic content and / or equipment. End users with off-the-shelf content (games, information resources, software programs, etc.) Content users, such as customer content users, are themselves content themselves, if permitted by superior control information, budget and / or other control information. Control of internal use can be specified. Use is, for example, a user who sets a limit on the price of an electronic document that the user wants to pay without priorly expressing user approval, and a user who establishes the characteristics of the weighing information that the user wants to allow to be collected ( Includes privacy protection). This includes providing a means for content users to protect the privacy of information and content and / or device use audits obtained from the use of VDE installations. In particular, VDE may prevent giving information related to a participant's use of electronic content to other parties without the participant's implicit or explicit contract.</p><p> !! To provide a mechanism that allows control information to be "developed" and modified according to additional control information that is delivered at least in part independently and securely. This control information is executable code certified as acceptable (eg, reliable and trusted) for use with a particular VDE application, application class, and / or VDE distribution configuration. May include. This modification (evolution) of control information can occur on content control information (load modules and any associated data) that circulates to one or more VDE participants in the control information handling path, or from VDE participants. It may occur on the received control information. The handling of content control information relates to control, analysis, payment and / or reporting use of electronic content and / or equipment (eg, as related to the use of VDE control characteristic content), to the extent approved by each. Establish, modify and / or contribute to permission, audit, payment and reporting control information. Control information delivered independently (from an independent source that is independent except with respect to certification), at least partially secure, is from one party whose content control information is in the sequence of VDE content control information handling. Can be used to securely modify content control information when flowing to a party.</p><p> This modification uses, for example, one or more VDE component assemblies that are safely processed within the VDE safety subsystem. In another embodiment, using the VDE installation safety subsystem after receiving at least some secure control information submitted by a "subordinate" party, which is usually in the form of a VDE managed object. , Control information can be modified by a higher party. The control information that passes along the VDE path contains sustained control information through a sequence of control information handlers, other control information that can be modified, and other control information that represents new control information and / or intervening data. In terms of possible inclusion, it can represent a mixed control set. Such a control set represents the evolution of control information about the delivered content. In this embodiment, the proposed control information is securely received and handled as at least part of the content control set is securely passed to the new participant's VDE installation (eg, communicated in encrypted form). , Using authentication and digital signature technology), The entire content control set for VDE content containers will "evolve". The received control information can be integrated (by using the receiving party's VDE installation safety subsystem) with the control information in place via a negotiation process involving both sets of control information. For example, modification of content control information for a VDE content container within a content provider's VDE installation can result from the incorporation of the required control information provided by the financial credit provider. The credit provider may use the VDE installation to prepare this required control information and communicate (directly or indirectly) with its content provider.</p><p> By incorporating this required control information, the end of VDE controlled content and / or equipment as long as the end user has a financial credit provider and a credit account and that credit account has sufficient available credit. Allows content end users to use credits from credit providers to guarantee their use. Similarly, control information and / or revenue information resulting from e-commerce activities that require payment of taxes may be securely received by the content provider. This control information can be received, for example, from an administrative agency. Content providers may be required by law to incorporate such control information into control information about commercial content and / or services related to device use. The proposed control information shall be determined by any negotiation trade-off that meets the priorities specified by each set (received set and proposed set) to the extent permitted by the higher control information. Used. VDE also considers different control schemes that are specifically adapted to different participants (eg, individual participants and / or participant classes (types)) within the network of VDE content handling participants.</p><p> !! Supports multiple simultaneous control models for the same content property and / or property part. This relies on e-commerce product content distribution, such as increasing revenue, thus lowering content costs to users, increasing value to content providers, obtaining detailed market observations and / or supporting advertising. Simultaneous corporate activities become possible. Such control information and / or the entire control model is given to different participants in different ways in the content, reporting, payment and / or related control information handling pathways, as determined or permitted by the control information. Can be. VDE is an activity related to the same and / or different content and / or device use, and / so that different parties (or, for example, a class of VDE users) receive different control information that governs the use of electronic information content. Or support the provision of different content control information to different parties in content and / or device usage models. For example, different control models may result in different budgeting applied as a result of different control models based on the category of distributors of VDE-controlled content objects or users of such content as end users. Alternatively, for example, one distributor may have the right to distribute an array of properties different from another (eg, from a common content collection provided on an optical disc). Classes or other groupings of individuals and / or end users can have different costs than "general" content users (eg, students, senior citizens, and / or low-income content users. , Can receive the same or different discounts).</p><p> ! Customer use of content and / or equipment and / or provider revenue information resulting from the transfer of credit and / or electronic currency from end-users and / or providers to government agencies from provider and / or end-user tax payments. Support provides secure trusted revenue summary information and / or a detailed user transaction list (the level of detail can depend, for example, on the type or size of the transaction, ie bank interest payments to customers or large sums of money ( For example, information regarding transfers (over $ 10,000) may be automatically reported to the governing body by law) in VDE Content Containers that contain content that reflects customer content usage information, such received control information. It can occur "automatically" as a result of it. Such summaries and / details related to taxable events and / or currencies and / or creditor currency transfers are passed along the reporting and / or payment channels to the governing body within the VDE container. obtain. Such containers may also be used for other VDE-related content usage reporting information.</p><p> !! According to a preferred embodiment of the present invention, the flow of content control information through different "branches" of content control information handling is supported so as to accept a controlled and diverse distribution of VDE-controlled content. This allows different parties to use the same initial electronic content with different (possibly competing) control strategies. In this example, the party that initially gave the control information for the content may make certain control assumptions, which evolve into more specific and / or broader control assumptions. These control assumptions can develop, for example, during the branching sequence when content model participants submit control information exchanges for use in "negotiation" with "appropriate" content control information. This can result in new or modified content control information, and / or selection of one or more already "appropriate" content usage control methods for another suitable method, as well as related control information parameter data. May include submissions. This evolution of the control information set, which applies to different copies of the same electronic property content / and equipment, flows "downward" through different branches throughout the handling and control path, separating these different path branches. It results from VDE control information that is sometimes modified differently. The ability of the present invention to support multiple route branches for both VDE content control information and VDE managed content flows represents different competing partnerships, contracts, and, for example, different at least some competing products. It enables an electronic commerce market that supports an entire evolving enterprise that can use the same content properties that are combined in different collections of content.</p><p> !! Users use a secure subsystem in their VDE installation to ensure that at least some of the content contained within the VDE content container is maintained by the user so that the extracted information is continuously secured throughout the extraction process. Create a new secure object (content container) by allowing it to be safely extracted. As a result of the formation of a new VDE container containing such extracted content, it matches or is specified by the source VDE content container and / or remote VDE installation safety subsystem content control information as appropriate. Control information is obtained. Relevant control information, such as security and management information, which at least partly derives from the control information of the parent object, is typically automatically inserted into a new VDE content container object that contains the extracted VDE content. To. Performed by this process in the user's VDE installation secure subsystem (eg, with at least some of this inserted control information that is securely stored in encrypted form during one or more permission recordings). Commonly occurs under the control framework and / or VDE installation control information of the parent object. In another embodiment, the induced content control information applied to the extracted content is part or all from the content control information stored remotely from the VDE installation that performs secure extraction such as remote server location. Can be obtained, or its content information can be used. Similar to the case where the content control information for most VDE-managed contents is used, the features of the present invention allow the content control information to:</p><p> (a) To "develop". For example, a content extractor may add new control information and / or modify control parameter data, such as how to follow a VDE application, to the extent enabled by the content's appropriate control information. Such new control information may be used, for example, by who can use at least a portion of the new object and / or how at least a portion of the extracted content can be used (eg, when at least a portion is used). It can be specified, or which part and which amount of a part can be used).</p><p> (b) Content extracted from one or more other VDE container objects for direct placement in the material and / or new container created by the extractor (eg, image, video, audio, and / or text). Allowing users to combine at least some of the extracted content, such as, with additional content.</p><p> (c) Allow the user to safely edit at least part of the content while keeping the content in a secure form within the VDE content container.</p><p> (d) Add the extracted content to an existing VDE content container object and attach the associated control information. In these cases, the information added by the user is secure, eg, partially or wholly encrypted, and gives the object content in place different usage / and / or audit control information than previously given. Can be done.</p><p> (e) Protect VDE control over one or more parts of the extracted content after use of various forms of that part. For example, while allowing content "temporarily" on a screen display, or allowing software to retain it in a secure form, it retains the content in a securely stored form, but the encryption of the program. Transiently decrypt any of the encrypted execution parts (all or part of the program can be encrypted to secure the program).</p><p> In general, the extraction features of the present invention provide protection extracted from content container sources while maintaining secure VDE capabilities and thus protecting the rights of providers in their content information after various content usage processes. The electronic content information below can be aggregated and / or distributed and / or used by the user.</p><p> !! Supports a collection of parts of content controlled by VDE. Such parts receive different VDE content container control information. Various parts of this may be provided by different content providers independent of one or more different locations remote from the gathering user. In a preferred embodiment of the invention, such a set may, for example, individually embed some or all of such parts as VDE content container objects within all VDE content containers and / or of such parts. By embedding some or all directly into the VDE content container, it may include protecting at least some of the control information (eg, executable code such as load modules) for each of its various parts. In the latter case, the content control information of this content container may give different control sets to various such parts based on the original control information requirements of this part before aggregation. Each such embedded VDE content container may have its own control information in the form of one or more permission records. Alternatively, negotiation between various aggregated parts of electronic content and associated control information may generate a control information set that manages some or all of the aggregated content parts. Even if the VDE content control information generated by the negotiation is uniform (such as having the same load module and / or component assembly), and / or a collection of VDE control content such as different weighing, budgeting, billing and / or payment models. Different such content control information may be given to two or more constituent parts. For example, content usage payments may be made to different content providers for different parts, either through an information exchange or directly.</p><p> !! Allows flexible weighing or other collection of information related to the use of electronic content and / or electronic devices. A feature of the present invention allows the metric control mechanism to include the following simultaneous wide arrays: (a) Different parameters related to the use of electronic content, (b) different increment units (bytes, documents, properties, paragraphs, images, etc.) and / or other organizations of such electronic content, and / or (c) Different categories and / or VDE installation types for users, such as client organizations, departments, projects, networks, and / or individual users. Features of the invention may be used for content security, usage analysis (eg, market observations), and / or use and / or exposure-based compensation for VDE-managed content. Such weighing is a flexible basis for guaranteeing content usage fees, licensing, purchases, and / or payments for advertising. A feature of the invention provides a payment instrument that supports flexible such currency and credit mechanisms, including the ability to secure audit tracking that reflects information related to the use of electronic currencies and credits. VDE supports multiple different hierarchies of cleanant organizational control information, where the organizational cleanant administrator distributes control information that specifies usage rights for departments, users, and / or projects. Similarly, a department network manager can act as a distributor (budgeting, access rights, etc.) for department networks, projects and / or users.</p><p> !! Scaleable and integrateable standardization for use on electronic devices ranging from inexpensive consumers (eg TV set-top devices) and specialized machines (and palm-sized PDAs) to servers, mainframes, communication switches, etc. Provide the controlled means. The variable scale transaction management / auditing techniques of the present invention provide more efficient and reliable interoperability between devices functioning in electronic commerce and / or data security environments. Standardized physical containers have become indispensable for shipping physical goods around the world, and these physical containers are universally "fit" for loading and unloading equipment, making effective use of truck and train space. When it becomes possible to efficiently contain a known array of objects (eg, a box), a VDE electronic content container, as provided by the present invention, is an electronic information content (commercially published property, electronic). Currency and credit and content audit information) and associated content control information can be efficiently moved around the world. Interoperability is the basis of efficient e-commerce. The design of the VDE foundation, VDE load module, and VDE container is an important feature that makes the VDE node operating environment compatible with a very wide range of electronics. Control methods based on load modules can be performed in very "small" and inexpensive secure subsystem environments, such as environments with very small read / write memory, and at the same time in more expensive electronics. Capability supports consistency across many machines. This consistent VDE operating environment, including its control structure and container architecture, enables the use of standardized VDE content containers across a wide range of device types and host operating environments.</p><p> VDE containers, content control information and VDE foundations work with many device types, as VDE capabilities can be seamlessly integrated as extensions, additions and / or modifications to the basic capabilities of electronics and host operating systems. These device types can translate and implement VDE control information consistently and efficiently. Through this integration, users can benefit from transparent interactions with the many capabilities of VDE. VDE integration with software running on host electronics supports a variety of capabilities that would otherwise be unavailable or insecure. Through integration with one or more device applications and / or device operating environments, the many capabilities of the present invention may be presented as the essential capabilities of an electronic device, operating system or device application.</p><p> For example, features of the present invention partially extend and / or modify the host operating system so that it possesses VDE capabilities such as (a) enabling secure transaction processing and electronic information storage. VDE system software for, (b) one or more application programs that represent some of the tools associated with VDE behavior, and / or (c) code embedded in an application program, such code being VDE capabilities. Incorporate references into VDE system software to integrate and make such applications VDE-aware (eg, music editing for word processors, database search applications, spreadsheets, multimedia presentation authoring tools, movie editing software, MIDI applications, etc. Robot control systems such as those associated with software, CAD / CAM environments and NCM software, e-mail systems, e-conference software, and other data authoring, generation, handling, and / or applications used including the above combinations. ). One or more of these features (which can also be implemented in firmware or hardware) can be used with VDE node-safe hardware processing capabilities such as microcontrollers, microprocessors, other CPUs or other digital processing logic. ..</p><p> !! An audit reconciliation and usage pattern evaluation process is used to assess whether a secure breach of the VDE configuration has occurred, typically through network-based transaction processing reconciliation and threshold checking activities. These processes are performed remotely, for example, to a VDE-controlled content end-user VDE location by, for example, evaluating purchases and / or requests for electronic properties with a given VDE installation. Applications for such mediation activities assess whether the amount of remotely delivered VDE-controlled content corresponds to the amount of financial credits and / or electronic currencies used for the use of such content. including. A trusted organization obtains information from the content provider regarding the cost of a given VDE installation and / or the content given to the user, and the cost of this content is charged to the installation and / or the user's credit and / or electronic currency. Compare with spending. Inconsistencies in the amount of content delivered relative to the amount of spending, depending on the situation, have the remote VDE installation been compromised at least to some extent (eg, a subsystem secure by exposing one or more keys and / or VDE. It can prove and / or show some important system security features, such as decrypting at least some of the controlled content. Irregular patterns of content usage (eg, very high demands), or one or more VDE installations and / or users (eg, including groups of related users with a set pattern of suspicious usage). Security in one or more installations such as and / or in combination with the electronic credit and / or currency judgment given to one or more VDE users and / or installations in particular. Such users and / or in when used</p><p> ! Support security technologies that materially increase the time required to "break" system integrity. This involves using a collection of techniques that minimizes the damage resulting from including some aspects of the security properties of the present invention.</p><p> ! To provide a collection of authoring, administrative, reporting, payment and billing tools user applications, including components of the reliable / secure, worldwide decentralized transaction control and management system of the present invention. These components are related to VDE, object generation (including placing control information on content), secure object distribution and management (including distribution control information, financial related and other usage analysis), and client internals. Supports VDE activity management and control, security management, user interfaces, payment spending, and information exchange related features. These components are highly secure, uniform, consistently standardized, processing, reporting and / or payment e-commerce and / or data security channels, content control and management, and human factors (eg, user interfaces). Is designed to support.</p><p> !! Financial and user information exchange activities, such as activities performed by client administrators in large organizations to assist in the use of organizations with VDE configurations, including usage information management, and information submitted by client administrators. VDE activities by an individual or group of employers, such as specifying the budget and entitlement characteristics available under VDE for a group and / or individual with client personnel that are provided with a set of control information for control. Supports the operation of multiple information exchanges, including control of. At an information exchange, one or more VDE installations can work with a reliable distributed database environment, which may include concurrent database processing means. Financial information exchanges typically receive content usage information and user requests that are securely delivered at that location, such as another credit, electronic currency and / or higher credit limits. Usage information and user request reporting are to support electronic currency, billing, payment and credit related activities, and / or user profile analysis and / or broader market observation analysis, and (integrated) list generation or at least. Some may be used for marketing other information obtained from the above usage information. This information may be given to the content provider or other party via an authenticated encrypted communication that is secure to the VDE installation secure subsystem. Information exchange processing means are typically specialized I / O means that may include high-speed remote communication switching means that can be used for secure communication between the information exchange means and other VDE route participants. Be connected.</p><p> !! Securely support communication in and between electronic currency and credit usage controls, storage and VDE installations. VDE also supports the automated passage of electronic currency and / or credit information, including payment tokens (such as in the form of electronic currency or credit) or other payment information through the payment channel. It may or may not be the same as the content usage information reporting route. Such payments are VDE-controlled electronic content and / or VDE instruments in response to control information defining a "withdrawal" of credit or electronic currency from an electronic credit or currency account based on the amount owned resulting from the use of the device. It can be placed in a VDE container that is automatically generated by the ration. The payment credit or currency is then appropriate, such as an information exchange, a provider for the original property content or equipment, or an agent for such a provider (other than the information exchange) via the VDE container's telecommunications. Can automatically communicate with other parties. Payment information may be packaged in the VDE content container described above with or without relevant content usage information such as weighing information. One aspect of the invention allows certain information about transit use to be designated as unavailable to some, some or all VDE parties ("conditionally" a completely anonymous currency). And / or some content information, such as currency and / or credit usage related information (and / or electronic information usage data), is required for secure access to court orders ("conditionally" anonymous information). It may be regulated to be available only under certain harsh conditions, such as (which may itself require approval through the use of VDE installations controlled by the court). Currency and credit information is treated as administrative content in a preferred embodiment of the invention.</p><p> !! Information and / or content that represents the user's identity when protected content is emitted in a clear form from a VDE object (displayed, printed, communicated, extracted, and / or stored) according to the present invention. Supports fingerprinting (also known as watermarking) for embedding in content so that the VDE installation, which is responsible for transforming it into a clear form, is embedded in the released content. Fingerprinting is useful in providing the ability to identify the person who extracted information in a clear form from a VDE container, or who created a copy of a VDE object or part of its content. Unauthorized extraction or copying by potential pirates as user identification and / or other identification information can be obscured or generally concealed and embedded in VDE container content and / or control information. Can be prevented. Fingerprints can be embedded in encrypted content and later placed in unencrypted content in a secure VDE installation subsystem when encrypted content with fingerprint information is decrypted, but fingerprints , Usually embedded in unencrypted electronic content or control information. Electronic information, such as the contents of a VDE container, can be fingerprinted as it leaves the network (such as the Internet) for the receiving party. Such storage location information is maintained in unencrypted form prior to communication and can be encrypted when leaving the storage location. Fingerprinting can preferably occur before the encryption step, preferably when the content leaves the storage location.</p><p> The encrypted storage content can be decrypted, for example, in a secure VDE subsystem, the fingerprint information inserted, and then the content can be re-encrypted for transmission. Managed a security breach of VDE installation or delivered content by embedding the intended recipient user's identity and / or VDE installation in the content, for example, when the content leaves the Internet storage location. Provide important information that identifies or assists in identifying any party. If the party makes an approved and explicit copy of the VDE Control Content, including making an unapproved copy of the approved and explicit copy, the fingerprint information is for the individual and / or that individual's VDE installation. Point again. Such hidden information acts as a powerful act of impeding action, which should prevent most of the potential content "infringement" from stealing other party's electronic information. Fingerprint information that recognizes the receiving party and / or the VDE installation may be embedded in the VDE object before or during decryption, duplication, or communication with the recipient of the VDE Content Object. Fingerprinting of electronic information before encrypting the electronic information for transfer to consumers or other users identifies the person who receives certain content that may be distributed or made available in unencrypted form. Provides information that can be very useful for. This information can "break" the security of the VDE installation and is useful for tracking people who have made some electronic information illegally available to others, by fingerprinting the release of the above content information (eg, for example). Extraction) May provide additional available information such as time and / or day. The location for inserting the fingerprint can be specified by the VDE installation and / or content container control information. This information can be found in an area within a property, such as one or more information fields or information types. And / or the exact location can specify that it should be used for fingerprinting. Fingerprint information is a property, such as by modifying the font character formation by slightly modifying an audio signal with respect to frequency by modifying the color frequency and / or the brightness of an image pixel to be normally undetectable. Can be incorporated. The fingerprint information itself should be encrypted so that it is particularly difficult to interpret the tampered fingerprint as valid. Multiple copies of fingerprint position changes, "fake" fingerprint information, and fingerprint information within a particular property or other content for different copies of the same property, information distribution pattern, frequency and / or brightness processing. And copying using different fingerprinting techniques, such as encryption-related techniques, is a feature of the invention to make it more difficult for unauthorized individuals to identify fingerprint locations and erase and / or modify fingerprint information. ..</p><p> !! Provides a smart object agent that can carry requests, data, and / or methods, including budgeting, approval, credit or currency, and content. For example, smart objects can move to and / or from remote information resource locations to meet demands for electronic information content. Smart objects are, for example, transmitted to remote locations, thereby performing a designated database search on behalf of the user, or "intelligently" remotely storing one or more stores of information about the information the user wants. Search for. For example, after identifying the desired information at one or more remote locations by performing one or more database searches, the smart object communicates in the form of a secure "return object" containing the retrieved information. You can return to the user through. You may be charged for remote retrieval of information, return of information to your VDE installation, and / or use of such information. In the latter case, the user may only be charged for the information in the return object that the user actually uses. A smart object may have a means of requesting the use of one or more services and / or resources. Services include placement of resources such as other services and / or information resources, language or format conversion, processing, credit (or additional credit) approval, and the like. Resources can be reference databases, networks, high power or specialized computing resources (smart objects can carry information to other computers, thereby processing information efficiently and then sending it back to the VDE installation). , Includes remote object storage location, etc. Smart objects can provide a secure means for billing users based on the information and / or resources actually used, while at the same time allowing remote resources (eg, centralized databases, supercomputers, etc.) to be used efficiently. ..</p><p> !! Supports both "translation" of VDE electronic contract elements into modern language printing contract elements (such as English contracts) and translation of electronic rights protection / transaction management modern language contract elements into electronic VDE contract elements. This feature requires maintenance of a text language library for VDE load modules and / or method and / or component assemblies. As VDE methods are proposed and / or used for VDE contracts, a list of textual terms and conditions is stored in preferred embodiments, with phrases, sentences, and / or paragraphs corresponding to the methods and / or assemblies described above. Can be generated by the provided VDE user application. This feature preferably analyzes and automatically analyzes the proper order and relationships between library elements corresponding to methods and / or assemblies selected to form part or all of a legal or descriptive document. Use artificial intelligence capabilities to make decisions and / or assist in the decisions of one or more users. One or more users and / or preferably a legal representative (if the document is a legally binding contract), review the documentary material created upon completion, such additional textual information and / Or describe the non-electronic trading element of the contract and use edits as necessary to make any other improvements that may be necessary. These features also support the use of modern language tools that allow one or more users to make choices, answer questions, and generate VDE electronic contracts from such a process. This process is interactive, and the VDE contract formulation process learns from the response and, if appropriate and at least in part based on that response, offers additional options and / or questions to "develop" the desired VDE electronic contract. The provided artificial intelligence expert system technology can be used.</p><p> !! Supports the use of multiple VDE safety subsystems in a single VDE installation. Various security and / or performance benefits can be realized by using a distributed VDE design within a single VDE installation. For example, by designing a hardware-based VDE safety subsystem inside an electronic VDE display device, and by designing the display device and subsystem integration as close to the display point as possible, from outside the video system to inside. It makes it more materially difficult to "steal" the decrypted video information as you move to, which increases the security of the video material. Ideally, for example, the VDE safety hardware module is in the same physical package as the actual display monitor, such as in the package of a video monitor or other display device, and such a device is commercially available. It is designed to be reasonably non-tamperable to the extent that it is practical. In another embodiment, embedding a VDE hardware module in an I / O peripheral may have some advantages in terms of overall system throughput. When multiple VDE examples are used in the same VDE installation, the VDE examples store control information and content and / or device usage information on the same mass storage and in the same VDE management database, etc. As such, these examples ideally share resources to a practical degree.</p><p> Budget depletion and key aging over time (time) Require reporting and payment compliance by using aging). For example, VDE commercial configuration and associated content control information may involve the use of information exchange credits for payment of content provider content and end-user use of that content. Control information about this configuration may be delivered to the user's VDE installation (of its content) and its financial information exchange VDE installation. This control information includes some form of Content Usage Base Information, and electronic credits (such credits may be "owned" by the Provider upon receipt and used in lieu of the availability and validity of the Electronic Currency) and / Or both of the content usage payments in the form of electronic currency need to be prepared by the above information exchange and remotely communicated to the content provider. This delivery of information and payments may use a reliable VDE installation safety subsystem to provide it securely, and in some embodiments automatically, in the manner specified by the control information above. .. The features of the present invention may guarantee the requirement that information exchange reports of such usage information and payment content be available.</p><p> For example, if one participant in a VDE electronic contract cannot see such information reporting and / or payment obligations, another participant may go to VDE activities related to such contract of a law-breaking party. Can stop participating. For example, if the requested usage and payments are not reported as specified by the content control information, the "injured" party will not be able to communicate securely from its VDE installation safety subsystem. It cannot provide one or more pieces of sensitive information needed for one or more critical processes. For example, if the information exchange fails to report information and / or payments to the content provider (and there is any security flaw or other sabotage), the content provider will send the key and / or budget refresh information to the information exchange. Cannot be given. This information may be required to approve the use of information exchange credits for the provider's use of content, which may be used during content usage reporting communications between the information exchange and end users. Communicate with the end user. As another example, a distributor who fails to pay and / or report usage information to a content provider may have a budget and / or provider's budget and / or provider to create a permission record to distribute the content provider's content to the user. Security budgets that limit one or more other aspects of a user's use of content may find that once exhausted or decommissioned (eg, on a given date), they are not refreshed by the content provider. In these and other cases, the offending party may decide not to refresh the "aged out" aging key over time. The use of such aging keys over time has similar implications as budgets and aging approvals over time cannot be refreshed.</p><p> !! Supports smart card implementation of the present invention in the form of portable electronic devices, including cards that can be used as secure credit, bank, and / or monetary cards. A feature of the present invention is the use of mobile VDEs as trading cards in retail and other schemes. Here, such cards are ordered with VDE secure subsystems and / or VDE secure and / or secure compatible subsystems such as "trusted" financial information exchanges (eg VISA, Mastercard). Can "dock" with the terminal. VDE cards and terminals (and / or online connections) securely exchange transaction-related information as credits and / or electronic currencies are transferred to merchants and / or information exchanges and transaction information flows back to the card. obtain. Such cards can be used for all types of trading activities. Docking stations such as PCMCIA connectors on electronic devices such as personal computers can receive consumer VDE cards at home. Such station / card combinations can be used for online transactions in the same way as VDE installations that are permanently installed on such electronics. The card is used as an "electronic wallet" and contains electronic currency and credits provided by information exchanges. Cards can serve as a convergence point for consumer financial activities in many, if not all, commercial, banking and online financial transactions, including home banking activities.</p><p> Consumers may receive payroll checks and / or investment revenues and / or secure details regarding such receipts in a "trustworthy" VDE content container via an online connection. Users may send digital currencies to other parties using VDE configurations, including giving such currencies. VDE cards can retain transaction details in a very secure and database-organized manner so that financially relevant information can be merged and searched and / or analyzed very easily. Due to VDE security including efficient encryption, authentication, digital signature, and secure database structure, the records contained within the VDE card structure are valid transaction records for management and / or integrated record protection. It can be accepted as a requirement. In some embodiments of the invention, the VDE card uses a docking station and / or electronic device storage means and / or other VDE configuration means available remotely and / or over a network to the above devices. Increase the information storage capacity of the VDE card by sharing, for example, storing dated and / or stored backup information. Taxes related to some or all of an individual's financial activities may be calculated automatically based on the "trustworthy" information that is securely stored and available on the VDE card above. The above information is from the above cards, the above docking stations, the above associated electronics, and / or other devices operably attached to them and / or remotely attached to remote server sites, etc. Can be stored in. Card data, such as transaction history, may be backed up to a personal computer or other electronic device, such device may have its own integrated VDE installation. Current transactions, recent transactions (due to redundancy), or all or other selected card data can be used for financial transactions such as user / merchant transactions and / Alternatively, it may be backed up to a remote backup storage location, such as a VDE compatible storage location at a financial information exchange, during each or periodic docking for telecommunications. Back up at least the current transaction while connecting to another party's VDE installation (eg, a VDE installation on a financial or general purpose electronic network) by transporting transaction information to a remote information exchange and / or bank. Doing so can ensure that sufficient backup is made to allow a complete reconstruction of the VDE card internal information in the event of a bad or lost card.</p><p> ! The specification protocol deviates unacceptably from other VDE configurations and / or installations VDE configurations and / or installations have security (integration and / or security of VDE security information), process control, And / or support a certification process that guarantees approved interoperability between various VDE installations to prevent them from interfering with each other to introduce software compatibility issues. The proof shows the identification of the VDE installation and / or its components, as well as the validity of the VDE user. Proof data can be information that contributes to the withdrawal or other change decisions related to the VDE site.</p><p> ! Supports the separation of basic transaction control processes by using event-based (event-triggered) method control mechanisms. These event methods are used to trigger one or more other VDE methods (which are valid for the secure VDE subsystem) and perform processing related to transactions managed by VDE. These triggered methods include component billing management methods, budgeting management methods, metrology management methods, and associated audit management processes that can be processed independently (separately) and securely. As a result of the present invention having this feature: independent triggers for weighing, auditing, billing and budgeting methods, the present invention presents budgets related to multiple financial currencies (eg, dollars, marks, yen) and content, and / Or can efficiently support billing increments as well as a highly flexible content distribution model in parallel.</p><p> ! (1) Content Event Triggers, (2) Audits, (3) Budgeting (including specifying that there are no usage rights or restrictions on usage rights), (4) Billing, and (5) User Identity ( Supports complete modular isolation of control structures related to VDE installations, client names, departments, networks, and / or users. The independence of these VDE control structures allows flexible systems that allow multiple relationships between two or more of these configurations, such as financial budgets based on different event-triggered structures (based on their logical part). Provides the ability to associate with) (placed in the right place to allow control of the content).</p><p> Without such separation between these basic VDE capabilities, separate weighing, billing, budgeting and identification, and / or, for example, paying associated with content use, home banking, advertising services, etc. It becomes more difficult to efficiently maintain billing activities involving the same, different (including superposition) or completely different parts for weighing, billing, budgeting and user identification, such as managing. VDE modular isolation of these basic cavities supports programming, budgeting, auditing and / or billing control information for multiple "arbitrary" relationships between one or different content parts (and / or subunits). .. For example, under VDE, it is applied for decrypting databases with a budget limit of $ 200 or 300 Deutschmarks per month, and each time the decrypted database is recorded (depending on the currency chosen by the user). 2 U.S. dollars or 3 Deutschmarks can be charged. Such use may be weighed, additional audits prepared for user profile purposes, and each filed and displayed identity recorded. In addition, further weighing can be done with respect to the number of decoded database bytes. Also, the associated security budget can prevent more than 5% of all bytes in the database from being decrypted each year. Users may also collect audit information under VDE (if permitted by superior control information) that reflects the use of database fields by different individuals and client organizational units. Users also ensure that different rights to access and different budgets limiting the database can be applied to these individual and group clients. The actual use of such different sets of user identification, weighing, budgeting, and billing control information by content providers and users is partly due to such independent control capabilities.It is done as a result of the use of abilities. As a result, VDE forms multiple control models that apply to the same electronic property, the same and / or multiple control models that apply to different or completely different content models (eg, electronic shopping for home banking). Can support high configuration.</p><p> Methods, other control information and VDE objects VDE control information (eg, methods) that collectively controls the use of VDE-managed properties (databases, documents, personal commercial products) is shipped with the content itself (eg, in a content container), and / Or one or more pieces of such control information are transported to the distributor and / or other users in "administrative objects" that can be delivered separately. A subset of the methods for a property is delivered in part with each property, and one or more other subsets of the methods are delivered separately to the user or made available for use (remote by telecommunications means). Can be made available to). The required methods (property and / or methods listed to be required for device use) are specified when VDE controlled content (such as intellectual properties distributed within the VDE content container) is used. Should be available. Methods that control content can apply to multiple VDE container objects, such as classes of objects or other groups. Also, some users or their classes and / or VDE installations and / or installation classes for such parties require that the method use one or more specific objects or classes of objects. Can be done.</p><p> The features of VDE provided by the present invention are such that one or more methods are required to enable a VDE installation and / or a user to use some and / or all of a content. It can be specified. For example, allowing "upper" participants (eg, content creators) to require a method that prohibits end users from electronically saving decrypted content for certain types of content distributors. Credit providers for VDE transactions require an audit method to record the time of electronic purchases, and / or users report to the Information Exchange not to carry confidential confidential information regarding the details of their use. You may need a method to summarize usage information (eg, billing information) to do so.</p><p> A further feature of the VDE provided by the present invention is that content creators, distributors and users choose from a set of predefined methods (if available) to control container content usage and distribution capabilities. Customized new methods that allow and / or content creators, distributors and users to control at least some usage features (such "new" methods are VDE installations and / or VDEs. It may have the right to provide (which may need to be proven for reliability and interoperability with a group of applications). As a result, VDE is concerned with how the distribution and other use of each property or object (or one or more parts of the object or property as desired and / or applicable) is controlled. It provides a very high degree of composition. Each VDE participant in the VDE path of content control information uses methods for some or all of the content in the VDE container, unless such control information conflicts with the superior control information already in place with respect to: Can be set.</p><p> (1) Part or all of VDE managed content, (2) One or more VDE users and / or groups of users, (3) One or more VDE nodes and / or groups of nodes, and / or (4) One or more VDE applications and / or configurations.</p><p> For example, the content creator's VDE control information for one content has an advantage over other submitted VDE participant control information. Further, for example, when higher-level control information permits, the control information of the content distributor itself can be superior to the control information of the client administrator, and can be superior to the control information of the end user. The path of the distribution participant's ability to set such electronic content control information is limited to certain control information (eg, data intervening methods such as pricing and / or sale date) or one. The above participant's proposed control information conflicts with the control information previously submitted by the participant in the property handling chain or set by the higher level control information managed in the participant's VDE safety subsystem above. It can be limited to the extent that it does.</p><p> VDE control information, in part or in whole, represents (a) control information placed directly in place by a VDE content control information path participant, and / or (b) electronic content (or electronic device) permission recording information. Includes control information put in place by such participants on behalf of a party that does not directly handle (eg, control information inserted by a participant representing a financial information exchange or government agency). Such control information methods (and / or load modules and / or intervening data and / or component assemblies) incorporate the use of one or more parts of the submitted control information into existing control information, and / Or replaces existing control information (and / or makes choices between other control information based on its interaction with in-place control information) and what control information is used and how It can be placed in-place by an electronically or semi-automated, human-assisted control information (control set) negotiation process to determine what to obtain.</p><p> Control information may be provided by parties that do not directly participate in the handling of electronic content (and / or equipment) and / or control information for such content (and / or equipment). Such control information is the VDE installation safety between the VDE installation safety subsystem of one or more parties that do not participate directly and the VDE installation safety subsystem path of the VDE content control information participant. It may be provided in a secure form using communications managed by the subsystem (eg, including authentication of the deliverer of control information that is at least partially encrypted). This control information is managed by VDE, for example, regarding access to credits provided by financial service providers, enforcement of regulations or laws enacted by government agencies, or how usage information received by customers is generated, handled and reported. Content usage information (reflecting content usage by one or more parties other than such customers) may be relevant to the customer's requirements. Such control information can impose social requirements, such as laws related to e-commerce.</p><p> VDE content control information can be given differently to different routes of content and control information handling participants. In addition, permission recording rights may be added, altered and / or removed by the VDE participant if the VDE participant is allowed to take such action. The rights of VDE participants may be defined in relation to specific parties and / or categories of parties and / or other groups of parties in the chain of handling content and / or content control information (eg, permission records). Modifications of control information that can be made by a given, qualified single or multiple parties can be limited by the number of modifications that those parties can make, and / or the extent of the modifications.</p><p> At least one safety in the electronic device of creators, distributors, auditors, information exchanges, clients, administrators and end users (understanding that two or more of the above categories can describe a single user). Subsystems provide a "sufficiently" secure environment (for intended applications) for:</p><p> 1. Decryption of property and control information, 2. Storage of information related to control and weighing, 3. Communication management, 4. Process the core control programs that make up the control information for electronic content and / or device rights protection, including the enforcement of VDE administrator preferences and requirements, along with the associated data.</p><p> Most use, audit, reporting, payment and distribution control methods themselves are typically performed by a secure subsystem of the VDE installation, which is at least partially encrypted. Thus, for example, billing and weighing records can be securely generated and updated within a secure subsystem, and encryption and decryption keys are securely utilized. VDE also uses secure (eg, encrypted and authenticated) communication when passing information between participant location (node) secure subsystems in a VDE configuration, so the important component of a VDE electronic contract is It can be enforced reliably (fully trusted) with sufficient security for the intended commercial purpose. A VDE electronic contract for a value chain can consist, at least in part, of one or more subcontracts between one or more subsets of value chain participants. These subcontracts consist of one or more electronic contract "compliance" elements (methods containing associated parameter data) that guarantee the protection of the rights of VDE participants.</p><p> The degree of reliability of the VDE configuration is whether the participant location safety subsystem uses the hardware SPU, the effectiveness of the SPU hardware security architecture, the software security technology when the SPU is emulated in the software, and the content. , Control information, communication and VDE node (VDE installation) Relies primarily on the encryption algorithm and keys used to secure access to the secure subsystem. Physical features and user identification authentication security procedures are established financial information exchanges where such security procedures can provide sufficient security for reliable interoperability with VDE configurations using hardware SPUs at user nodes. Can be used in place of a hardware SPU in certain nodes such as.</p><p> Updating the property management file at each location in the VDE configuration to contain new or modified control information is a secure management that updates the programs executed by the protected subsystem in the VDE secure subsystem. It is done under the control of the file. The present invention ensures that content control information can be enforced, as at least some of all secure communications are encrypted and processing within the secure subsystem is hidden from external observations and disturbances. As a result, creators and / or distributors and / or client administrators and / or other contributors of secure control information about each property (eg, end users who limit the types of audit information that can be reported, and / or Financial information exchanges that establish certain standards for the use of their credits for payment of the use of distributed content) have their contributed and permissible control information (security limits of the given VDE security implementation design). You can be confident that it will be enforced (within). This control information may determine, for example:</p><p> (1) How and / or to whom electronic content is provided, for example, how electronic properties can be distributed. (2) How one or more objects and / or properties, or parts of an object or property can be used directly, eg, decrypted, displayed, printed, etc. (3) How payments for such content and / use of parts of the Content may or must be handled, and (4) How audit information is collected, reported and / or used for usage information related to at least some of the properties.</p><p> The superiority of the contributed control information, including the resolution of conflicts between content control information submitted by multiple parties, is usually established by:</p><p> (1) Sequences in which control information is placed in-place by various parties (in-place control information is usually superior to the next submitted control information), (2) Specific details of VDE content and / or device control information. For example, in-place control information can be any of one or more of the following parts of control from one or more parties or classes of parties to control information submitted by one or more different parties and classes of parties: Can specify whether it will be superior to (3) Negotiation between control information sets from multiple parties to establish which control information constitutes the resulting control information set for a given portion of VDE-managed content and / or VDE installation. .. Electronic contracts and rights protection An important feature of VDE is that it is used to ensure the management and adequacy of security and rights protection for electronic contracts performed by the use of the present invention. Such a contract may involve one or more of the following:</p><p> (1) Electronic information creators, publishers, and other distributors, (2) Financial services (eg credit) providers, (3) A user (other than a service provider) of information resulting from the use of content, such as content-specified statistical information and user-specified descriptive information. Such users include market analysis, market list compilers for direct directed market buying and selling, and government agencies, (4) Content end user, (5) Substructure service and equipment providers, such as telecommunications carriers and hardware manufacturers (semiconductor and electronics and / or other computer system manufacturers), who receive compensation based on their use of services and / or equipment. and (6) A party described by electronic information, May include.</p><p> VDE supports commercially secure "extended" value chain electronic contracts. The VDE may be configured to support various underlying contracts between parties, including this extended contract. These contracts may specify what is considered for significant e-commerce, including:</p><p> (1) Security, (2) Content usage control, including electronic distribution, (3) Privacy (eg, regarding information about parties described by medical, credit, tax, personal and / or other forms of confidential information), (4) Management of financial processes, (5) Handling channels for electronic content, content and / or device control information, electronic content and / or device usage information and payments and / or credits.</p><p> VDE contracts may govern e-commerce relationships between two or more parties in a value chain, but such contracts sometimes cannot directly enforce or involve other VDE value chain participants. For example, an electronic contract between a content creator and a distributor is the price to the distributor for the creator's content (such as for properties distributed in a VDE container object), and for the period this distributor is given. Can specify both the number of copies of this object that can be distributed to end users. In the second agreement, the end user agrees to certain requirements for using the distributed goods, such as accepting the distributor's request for the use of the content and agreeing to retain the copyright of the creator. The value chain end user can be relevant. The third contract is for the distributor and the information exchange for payment of the product if the end user has a separate (fourth) contract directly with the information exchange that extends credit to the end user. It can exist with financial information exchanges that allow distributors to use credits. A fifth evolving contract can evolve among all value chain participants as content control information passes along that chain of handling. This evolving contract may establish all parties' rights to Content Usage Information, including, for example, the nature of the information received by each Party and the handling of Content Usage Information and related procedures. The sixth contract in this embodiment can involve all parties in the contract, such as the degree of security technology and reliability (eg, for commercial integration of systems, each VDE installation safety subsystem has theirs. Establishes some general assumptions (which require a VDE node to be electronically guaranteed to meet certain interaction requirements). In the above example, these six contracts include an extended contract contract for this commercial value chain example.</p><p> VDE contracts are made by current and / or new participants through very simple to elaborate "negotiations" between newly proposed content control information that interacts with control information that is already in place. , And / or support evolving (living) electronic contract configurations that can be modified by negotiations between simultaneously proposed content control information submitted by multiple parties. A given model can be progressively modified asynchronously over time according to existing superordinate rules. Such modifications may apply to all, specific content, and / or classes and / or specific users and / or user nodes, and / or to these classes. A given portion of content may be subject to different times or different treatments depending on the evolution of its content control information (and / or depending on different applicable VDE installation content control information). The evolution of control information can occur during passage along one or more control information, including objects. That is, the control information can be modified at one or more points along the chain of handling control information, as long as the modification is allowed. As a result, the content managed by VDE may have different control information given at both different "positions" in the chain of content handling and similar positions in different chains of handling such content. Also, such different applications of control information can be obtained from content control information that specifies that one party or group of parties is served different content than another party or group of parties. For example, content control information about a given part of content is defined as superior information and therefore immutable information, placed in-place by the content creator, and the domestic distributor of the given part of these content. Is a copy of boni fide As long as it is supplied to the end user, it may be allowed to make 100,000 copies every three months, but only a single copy of such content is passed to the remote retailer, and control information is such. It may be stipulated that retailers may be restricted from making no more than 1000 copies each month for retail to end users. In addition, the end user of such content is restricted to make three copies of such content with the same content control information, each of which is three different computers used by the end user. (One is a desktop computer at work, one is a desktop computer at home, and the other is a portable computer).</p><p> The electronic contracts supported by the preferred embodiments of the present invention can range from very simple to very sophisticated. These contracts may support a wide variety of information management models that provide electronic information security, usage management, and communications, and:</p><p> (a) Secure electronic distribution of information, eg, commercial literal properties, (b) Safe electronic information use monitoring and reporting, (c) Secure financial transaction capabilities related to both electronic information and / or device use and other electronic credit and / or currency use and management capabilities. (d) Privacy protection of usage information that the user does not want to release, and (e) An "active" electronic information content distribution model that flexibly accommodates: (1) Participants of a certain width, (2) One or more channels (chains) for handling content, reporting content and / or device control information, reporting content and / or device usage related information, and / or payment. (3) Support for the development of contracts and conditions incorporated into content control information, including the use of electronic negotiation capabilities. (4) Support for combining multiple parts of content to form a new content collection, and (5) Multiple parallel models. Safe processing unit An important part of the VDE provided by the present invention is the core secure transaction control configuration referred to herein as the SPU, which must be representative of each user's computer, other electronic equipment or network. .. The SPU generates decryption keys, encrypts and decrypts information, keys and other information for electronic devices (ie, between VDE installations and / or between multiple VDE instances within a single VDE installation). Secure communication management, audit tracking in secure and / insecure non-volatile memory, secure accumulation and management of reporting and budgeting information, maintaining a secure database of control information management instructions, and some others. Provide a reliable environment for providing a secure environment for performing control and management functions.</p><p> If a reliable environment is required to perform certain VDE activities, a hardware SPU (not software emulation) in the VDE node is required. Such a reliable environment is one or more non-tamperable, such as certain control software, semiconductors or semiconductor chipsets, for use within and / or operably connected to the electronics. It can be created by a hardware module (eg, a hardware electronics peripheral that cannot be tampered with). According to the present invention, the reliability of a hardware SPU can be determined by encapsulating some or all of its hardware elements in a non-tamperable packaging and / or other non-tamperable techniques (eg,). It can be enhanced by using microfusing and / or thin wiring detection techniques). The reliable environment of the present invention implemented, in part, includes control logic to safely execute VDE processes such as microprocessors by using tampered semiconductor designs.</p><p> The hardware SPU of a VDE node is a core component of the VDE safety subsystem and may use some or all of the key control logic of an electronic device such as a microcontroller, macro computer, or other CPU configuration. Alternatively, such controls may be used for non-VDE purposes, such as controlling some or all of the non-VDE functions of an electronic device. When operating in hardware SPU mode, the primary control logic must be secure enough to protect and conceal critical VDE processes. For example, a hardware SPU may use a host electronics microcomputer operating in protected mode while performing VDE-related activities and thus allowing some of the VDE processes to run with some degree of security. This other embodiment contrasts with the preferred embodiment in which a reliable environment is created using a combination of one or more non-tamperable semiconductors that are not part of the primary control logic. In either embodiment, certain control information (software and parameter data) must be kept securely within the SPU, and the control information is externally secure (eg, in encrypted and tagged form). ) Stored and loaded into the above hardware SPU when needed. In many cases, a preferred embodiment approach using special purpose safety hardware to perform the VDE process rather than using the primary control logic described above, especially when used with a microcomputer, is safer and more efficient. Can be a target. The level of security and tamper-proof required for a reliable SPU hardware process depends on the commercial requirements of a particular market or market niche and can vary widely.</p>

<figref num="1">It is a figure which shows an example of the "virtual distribution environment" provided according to the preferable Example / Embodiment of this invention.</figref><figref num="1A">It is a figure which shows an example of the "information utility" shown in FIG. 1 in more detail.</figref><figref num="2">It is a figure which shows an example of the chain of processing and control.</figref><figref num="2A">FIG. 2 illustrates an example of how rule and control information can be sustained from one participant to another in the processing and control chain of FIG.</figref><figref num="3">It is a figure which shows an example of the different control information which can be provided.</figref><figref num="4">FIG. 5 illustrates examples of several different types of rules and / or control information.</figref><figref num="5A">It is a figure which shows the example of "object".</figref><figref num="5B">It is a figure which shows the example of "object".</figref><figref num="6">It is a figure which shows an example of a safe processing unit (SPU).</figref><figref num="7">It is a figure which shows an example of an electronic device.</figref><figref num="8">It is a more detailed block diagram of an example of an electronic device shown in FIG.</figref><figref num="9">It is a detailed view of an example of a safe processing unit (SPU) shown in FIGS. 6 and 8.</figref><figref num="10">It is a figure which shows an example of the "rights operating system" ("ROS") architecture provided by a virtual distribution environment.</figref><figref num="11A">It is a figure which shows an example of the functional relationship between an application and a rights operating system.</figref><figref num="11B">It is a figure which shows an example of the functional relationship between an application and a rights operating system.</figref><figref num="11C">It is a figure which shows an example of the functional relationship between an application and a rights operating system.</figref><figref num="11D">It is a figure which shows the example of "component" and "component assembly".</figref><figref num="11E">It is a figure which shows the example of "component" and "component assembly".</figref><figref num="11F">It is a figure which shows the example of "component" and "component assembly".</figref><figref num="11G">It is a figure which shows the example of "component" and "component assembly".</figref><figref num="11H">It is a figure which shows the example of "component" and "component assembly".</figref><figref num="11I">It is a figure which shows the example of "component" and "component assembly".</figref><figref num="11J">It is a figure which shows the example of "component" and "component assembly".</figref><figref num="12">FIG. 10 is a more detailed view of an example of the rights operating system shown in FIG.</figref><figref num="12A">It is a figure which shows an example of how an "object" is created.</figref><figref num="13">It is a detailed block diagram of an example of the software architecture for the "protected processing environment" shown in FIG.</figref><figref num="14A">This is an example of an SPU memory map provided by the protected processing environment shown in FIG.</figref><figref num="14B">This is an example of an SPU memory map provided by the protected processing environment shown in FIG.</figref><figref num="14C">This is an example of an SPU memory map provided by the protected processing environment shown in FIG.</figref><figref num="15">It is a figure which shows an example of how the channel service manager and the load module execution manager of FIG. 13 can support a channel.</figref><figref num="15A">It is an example of the channel header and the channel detail record shown in FIG.</figref><figref num="15B">It is a flowchart of an example of a program control step which can be performed by the protected processing environment of FIG. 13 to form a channel.</figref><figref num="16">It is a block diagram of an example of a secure database structure.</figref><figref num="17">It is a figure of an example of a logical object structure.</figref><figref num="18">It is a figure which shows an example of a stationary object structure.</figref><figref num="19">It is a figure which shows an example of the moving object structure.</figref><figref num="20">It is a figure which shows an example of the content object structure.</figref><figref num="21">It is a figure which shows an example of a management object structure.</figref><figref num="22">It is a figure which shows an example of the method core structure.</figref><figref num="23">It is a figure which shows an example of the load module structure.</figref><figref num="24">It is a figure which shows an example of the user data element (UDE) and / or the method data element (MDE) structure.</figref><figref num="25A">It is a figure which shows the example of "map weighing".</figref><figref num="25B">It is a figure which shows the example of "map weighing".</figref><figref num="25C">It is a figure which shows the example of "map weighing".</figref><figref num="26">It is a figure which shows an example of the permission record (PERC) structure.</figref><figref num="26A">It is a figure which shows a more detailed example of a permission record structure.</figref><figref num="26B">It is a figure which shows a more detailed example of a permission record structure.</figref><figref num="27">It is a figure which shows an example of a shipping table structure.</figref><figref num="28">It is a figure which shows an example of the reception table structure.</figref><figref num="29">It is a figure which shows an example of the management event log structure.</figref><figref num="30">FIG. 5 illustrates an example of the interrelationships and uses between the object registration table, subject table, and user rights table shown in the secure database of FIG.</figref><figref num="31">This is a more detailed example of the object registration table shown in FIG.</figref><figref num="32">This is a more detailed example of the subject table shown in FIG.</figref><figref num="33">It is a more detailed example of the user rights table shown in FIG.</figref><figref num="34">It is a figure which shows the specification example of how a site record table and a group record table can track a part of a secure database shown in FIG.</figref><figref num="34A">This is an example of the site record table structure shown in FIG.</figref><figref num="34B">This is an example of the group record table structure shown in FIG. 34.</figref><figref num="35">It is a figure which shows an example of the process for updating a safety database.</figref><figref num="36">It is a diagram showing an example of how a new element can be inserted into the secure database of FIG.</figref><figref num="37">It is a figure which shows an example of how the element of a secure database can be accessed.</figref><figref num="38">This is an example of a flowchart of how to protect a secure database element.</figref><figref num="39">This is an example of a flowchart of how to back up a secure database.</figref><figref num="40">This is an example of a flowchart of how to recover a safe database from a backup.</figref><figref num="41a">A set of examples showing how a "processing and control chain" can be enabled using "mutual methods".</figref><figref num="41b">A set of examples showing how a "processing and control chain" can be enabled using "mutual methods".</figref><figref num="41c">A set of examples showing how a "processing and control chain" can be enabled using "mutual methods".</figref><figref num="41d">A set of examples showing how a "processing and control chain" can be enabled using "mutual methods".</figref><figref num="42a">It is a figure which shows an example of a "mutual" BUDGET method.</figref><figref num="42b">It is a figure which shows an example of a "mutual" BUDGET method.</figref><figref num="42c">It is a figure which shows an example of a "mutual" BUDGET method.</figref><figref num="42d">It is a figure which shows an example of a "mutual" BUDGET method.</figref><figref num="43a">It is a figure which shows an example of the "mutual" REGISTER method.</figref><figref num="43b">It is a figure which shows an example of the "mutual" REGISTER method.</figref><figref num="43c">It is a figure which shows an example of the "mutual" REGISTER method.</figref><figref num="43d">It is a figure which shows an example of the "mutual" REGISTER method.</figref><figref num="44a">It is a figure which shows an example of the "mutual" AUDIT method.</figref><figref num="44b">It is a figure which shows an example of the "mutual" AUDIT method.</figref><figref num="44c">It is a figure which shows an example of the "mutual" AUDIT method.</figref><figref num="45">FIG. 5 illustrates examples of several methods used together to control the release of content or other information.</figref><figref num="46">FIG. 5 illustrates examples of several methods used together to control the release of content or other information.</figref><figref num="47">FIG. 5 illustrates examples of several methods used together to control the release of content or other information.</figref><figref num="48">FIG. 5 illustrates examples of several methods used together to control the release of content or other information.</figref><figref num="49">It is a figure which shows an example of the OPEN method.</figref><figref num="49a">It is a figure which shows an example of the OPEN method.</figref><figref num="49b">It is a figure which shows an example of the OPEN method.</figref><figref num="49c">It is a figure which shows an example of the OPEN method.</figref><figref num="49d">It is a figure which shows an example of the OPEN method.</figref><figref num="49e">It is a figure which shows an example of the OPEN method.</figref><figref num="49f">It is a figure which shows an example of the OPEN method.</figref><figref num="50">It is a figure which shows an example of a READ method.</figref><figref num="50a">It is a figure which shows an example of a READ method.</figref><figref num="50b">It is a figure which shows an example of a READ method.</figref><figref num="50c">It is a figure which shows an example of a READ method.</figref><figref num="50d">It is a figure which shows an example of a READ method.</figref><figref num="50e">It is a figure which shows an example of a READ method.</figref><figref num="50f">It is a figure which shows an example of a READ method.</figref><figref num="51">It is a figure which shows an example of a WRITE method.</figref><figref num="51a">It is a figure which shows an example of a WRITE method.</figref><figref num="51b">It is a figure which shows an example of a WRITE method.</figref><figref num="51c">It is a figure which shows an example of a WRITE method.</figref><figref num="51d">It is a figure which shows an example of a WRITE method.</figref><figref num="51e">It is a figure which shows an example of a WRITE method.</figref><figref num="51f">It is a figure which shows an example of a WRITE method.</figref><figref num="52">It is a figure which shows an example of the CLOSE method.</figref><figref num="53a">It is a figure which shows an example of the EVENT method.</figref><figref num="53b">It is a figure which shows an example of the EVENT method.</figref><figref num="53c">It is a figure which shows an example of the BILLING method.</figref><figref num="54">It is a figure which shows an example of the ACCESS method.</figref><figref num="55a">It is a figure which shows the example of DECRYPT and ENCRYPT method.</figref><figref num="55b">It is a figure which shows the example of DECRYPT and ENCRYPT method.</figref><figref num="56">It is a figure which shows an example of a CONTENT method.</figref><figref num="57a">It is a figure which shows the example of EXTRACT and EMBED method.</figref><figref num="57b">It is a figure which shows the example of EXTRACT and EMBED method.</figref><figref num="58a">It is a figure which shows an example of the OBSCURE method.</figref><figref num="58b">It is a figure which shows the example of the FINGERPRINT method.</figref><figref num="58C">It is a figure which shows the example of the FINGERPRINT method.</figref><figref num="59">It is a figure which shows an example of the DESTROY method.</figref><figref num="60">It is a figure which shows an example of a PANIC method.</figref><figref num="61">It is a figure which shows an example of the METER method.</figref><figref num="62">It is a figure which shows an example of a key "convolution" process.</figref><figref num="63">It is an example of how different keys can be generated using a key swivel process for determining a "true" key.</figref><figref num="64">It is a figure which shows an example of how the processing environment key under protection is initialized.</figref><figref num="65">It is a figure which shows an example of how the processing environment key under protection is initialized.</figref><figref num="66">It is a figure which shows the example of the process for decoding the information contained in a stationary object and a moving object, respectively.</figref><figref num="67">It is a figure which shows the example of the process for decoding the information contained in a stationary object and a moving object, respectively.</figref><figref num="68">It is a figure which shows an example of how the processing environment under protection can be initialized.</figref><figref num="69">It is a figure which shows an example of how the firmware can be downloaded to a protected processing environment.</figref><figref num="70">It is a figure which shows the example of a plurality of VDE electronic devices connected with a network or other communication means.</figref><figref num="71">It is a figure which shows the example of the portable VDE electronic device.</figref><figref num="72A">FIG. 5 illustrates an example of a "pop-up" display that can be generated by a user notification and exception interface.</figref><figref num="72B">FIG. 5 illustrates an example of a "pop-up" display that can be generated by a user notification and exception interface.</figref><figref num="72C">FIG. 5 illustrates an example of a "pop-up" display that can be generated by a user notification and exception interface.</figref><figref num="72D">FIG. 5 illustrates an example of a "pop-up" display that can be generated by a user notification and exception interface.</figref><figref num="73">It is a figure which shows an example of "smart object".</figref><figref num="74">It is a figure which shows an example of the process which uses a "smart object".</figref><figref num="75A">It is a figure which shows the example of the data structure used for electronic negotiation.</figref><figref num="75B">It is a figure which shows the example of the data structure used for electronic negotiation.</figref><figref num="75C">It is a figure which shows the example of the data structure used for electronic negotiation.</figref><figref num="75D">It is a figure which shows the example of the data structure used for electronic negotiation.</figref><figref num="75E">It is a figure which shows the example of the structure related to an electronic contract.</figref><figref num="75F">It is a figure which shows the example of the structure related to an electronic contract.</figref><figref num="76A">It is a figure which shows the example of the electronic negotiation process.</figref><figref num="76B">It is a figure which shows the example of the electronic negotiation process.</figref><figref num="77">It is a figure which shows another example of the chain of handling and control.</figref><figref num="78">It is a figure which shows an example of VDE "repository".</figref><figref num="79">It is a figure which shows the example which illustrates the chain of the process and control for developing and transforming VDE management content and control information.</figref><figref num="80">It is a figure which shows the example which illustrates the chain of the process and control for developing and transforming VDE management content and control information.</figref><figref num="81">It is a figure which shows the example which illustrates the chain of the process and control for developing and transforming VDE management content and control information.</figref><figref num="82">It is a figure which shows the example which illustrates the chain of the process and control for developing and transforming VDE management content and control information.</figref><figref num="83">It is a figure which shows the example which illustrates the chain of the process and control for developing and transforming VDE management content and control information.</figref><figref num="84">FIG. 5 illustrates another example of a chain of processing and control for several categories of VDE participants.</figref><figref num="85">FIG. 5 shows another example of a distribution and processing chain within an organization.</figref><figref num="86">It is a figure which shows another example of the chain of processing and control.</figref><figref num="86A">It is a figure which shows another example of the chain of processing and control.</figref><figref num="87">It is a figure which shows the example of the virtual silicon container model.</figref>

These and other features and advantages provided by the present invention are better and more fully understood by reference to the following detailed description of embodiments preferred at this time in the context of the drawings. obtain.

More detailed explanation Figures 1-7 and the following discussion outline some aspects of the features provided by the present invention. A more technical "detailed description" of embodiments according to the invention is provided after this overview. Overview FIG. 1 shows a "virtual distribution environment" ("VDE") 100 that may be provided in accordance with the present invention. In FIG. 1, the information utility 200 connects to a communication means 202, such as a telephone or cable TV line. The telephone or cable TV line 202 can be part of an "electronic highway" that carries electronic information from place to place. Line 202 connects the information utility 200 to other people such as consumer 208, office 210, video production studio 204 and publisher 214. Since the people connected to the information utility 200 can participate in the transactions that occur within the virtual distribution environment 100, each can be referred to as a "VDE participant".

Almost all possible types of transactions can be supported by Virtual Distribution Environment 100. Some of the many examples of transactions that can be supported by Virtual Distribution Environment 100 include: C Home Banking and Electronic Payments; C Electronic legal contract; C Distribution of "content" such as electronic printed matter, video, audio, images and computer programs; and C Secure communication of confidential information such as medical records and financial information.

Virtual Distribution Environment 100 is used as necessary to protect rights, ensure reliable and predictable distribution, and ensure adequate compensation for content creators and distributors. It is "virtual" because it does not require "things". For example, in the past, information was distributed on records or disks that were difficult to copy. In the past, secrets or confidential content was distributed in sealed envelopes or locked briefcases delivered by envoys. To ensure proper compensation, consumers could only receive goods and services after giving cash to the seller. The information utility 200 can deliver information by moving physical "things" such as electronic recording media, while the virtual distribution environment 100 facilitates a completely electronic "chain of processing and control". VDE flexibility trading support Information Utility 200 flexibly supports many different types of information transactions. Different VDE participants may define and / or participate in different parts of the transaction. The information utility 200 may assist in the delivery of information about the transaction, or may be one of the transaction participants.

For example, the video production studio 204 in the upper right corner of FIG. 1 may produce a video / television program. Video production studio 204 may send these programs through line 202 or may use other routes such as satellite link 205 and CD ROM delivery service 216. Video production studio 204 may send the program directly to consumers 206, 208 and 210. Alternatively, the video production studio may, for example, send the program to the information utility 200, store the program there, and then send the program to the consumer. That is, assuming that the video production studio or information utility 200 arranges these consumers to have the appropriate "rules and controls" (control information) that give them the right to use the program, Consumer 206, Each of 208 and 210 can receive and use the program produced by the video production studio 204.

Even if the consumer has a copy of the video program, he or she may not view or copy the program unless the consumer has "rules and controls" that authorize the use of the program. Consumers can only use the program as permitted by "rules and controls".

For example, video production studio 204 may broadcast a 30-minute trial video in the hope that as many viewers as possible will see it. Video production studio 204 wants to receive $ 2.00 per broadcast. Video production studio 204 may make trial videos available in a "protected" form to all consumers 206, 208, 210 through information utilities. Video production studio 204 may also give the video "rules and controls". These "rules and controls" may specify, for example: (1) Any consumer with good credit of at least $ 2.00 based on the credit account of an independent financial provider 212 (such as Mastercard or VISA) may watch the video, (2) Virtual distribution environment 100 "weighs" each time a consumer watches a video, occasionally reports use to video production studio 204, and (3) The financial provider 212 may electronically collect payments ($ 2.00) from each consumer's credit account watching the video and transfer these payments to the video production studio 204.

The Information Utility 200 allows even small video production studios to sell video to consumers and receive compensation for their efforts. In addition, with proper payment to the video production studio, the video may be made available to other video production companies that add value and / or can be repackagers or redistributors.

Figure 1 also shows publisher 214. Publisher 214 can be a distributor for author 206. Publisher 214 may distribute the right to use "content" (computer software, electronic newspapers, video, audio or any other data produced by Publisher 214) to consumers such as Office 210. Use rights may be governed by "Rules and Controls" distributed by Publisher 216. Publisher 216 distributes these "rules and controls" with the content, but this is not necessary. Content and related "rules and controls" may be distributed by different VDE participants at different times and in different ways, as the content may only be used by consumers who have the appropriate "rules and controls". VDE's ability to securely distribute and enforce "rules and controls" apart from the content to which the rules and controls apply offers great benefits.

By using the rights distributed by publisher 214, office 210 can, for example, make a copy of the content and distribute it to employees. Office 210 can be a redistributor by extending the "chain of processing and control" to employees. Office 210 may add or modify "rules and controls" (corresponding to "rules and controls" received from publisher 214) to provide office internal control information and mechanisms. For example, office 210 may set a maximum budget for each individual user and / or group in the office, or may grant access to information in a designated employee and / or group. ..

FIG. 1 also shows an information delivery service 216 that delivers an electronic storage medium, such as a "CD ROM" disc, to consumer 206 to consumer 206. The electronic storage medium itself is not delivered electronically by the information utility 200 through line 202, but remains part of the virtual distribution environment 100. Electronic storage media can be used to distribute content, "rules and controls" or other information. Example of what is in Information Utility 200 The "information utility" 200 in FIG. 1 can be a collection of participants who can act as distributors, financial information exchanges, and administrators. FIG. 1A shows an example of what could be inside an example of the Information Utility 200. Information utility participants 200a-200g can each be an independent organization / company. There may be any number of 200a to 200g of each participant. In this embodiment, the electronic "switch" 200a connects the internal components of the information utility 200 with each other and with external participants. The electronic switches may also connect external participants to each other.

The information utility 200 may include a "transaction processor" 200b that processes transactions (eg, for the transfer of electronic funds) based on requests from participants and / or report recipients 200e. It may also include a "use analyst" 200c that analyzes the reported usage information. The Report Creator 200d may, for example, create reports based on usage and may provide these reports to external participants and / or participants within the Information Utility 200. The "report recipient" 200e may receive reports such as usage reports from content users. The "permission agent" 200f may distribute "rules and controls" that grant use or distribution permissions, for example, based on a consumer's credit value profile. The administrator 200h may provide information to maintain proper operation of the virtual distribution environment 100. The content and message storage device 200g may store information used by participants inside or outside the Information Utility 200. Example of distribution of "content" using "chain of processing and control" As described above, the virtual distribution environment 100 can be used to manage almost all types of transactions. One of the important types of transactions in which the virtual distribution environment 100 can be used for management is the distribution or communication of "content" or other important information. FIG. 2 shows a more abstract "model" of how the virtual distribution environment 100 of FIG. 1 can be used to provide a "chain of processing and control" for distributing content. Each block in Figure 2 may correspond to one or more VDE participants shown in Figure 1.

In the example of FIG. 2, VDE content creator 102 creates content. Content Creator 102 may also specify "rules and controls" for distributing content. The "rules and controls" associated with these distributions may specify who has permission to distribute the right to use the Content and who is authorized to use the Content.

Arrow 104 points to VDE Rights Distributor 106 (Distributor) through the electronic highway 108 (or by other routes such as optical discs sent by delivery services such as US mail) the rules and controls associated with the content. ) Indicates the content creator 102. Content may be distributed through the same or different routes as those used to send "rules and controls". Distributor 106 creates its own "rules and controls" related to the use of the content. Use-related "rules and controls" may specify, for example, what the user can and cannot do with the Content, and the cost of using the Content. The "rules and controls" associated with these uses must match the "rules and controls" specified by Content Creator 102.

Arrow 110 indicates a distributor 106 that distributes the right to use the content by sending "rules and controls" of the content to content users 112 such as consumers. Content User 112 uses content in accordance with the "rules and controls" associated with its use.

In this example of FIG. 2, information about content use is reported to the financial information exchange 116, as indicated by arrow 114. Based on this "report", the financial information exchange 116 may create an invoice and send the invoice to the content user 112 through the "report and payment" network 118. Arrow 120 indicates content user 112 who pays for content use to financial information exchange 116. Based on the reports and payments received, Financial Information Exchange 116 may give the distributor reports and / or payments. Distributor 106 may give a report and / or payment to Content Creator 102, as indicated by arrow 122. The financial information exchange 116 may give the creator 102 reports and payments directly. Reporting and / or payments can be made differently. For example, information exchange 116 may give reports and / or payments to each of VDE Content Creator 102 and Rights Distributor 106, and report to Content User 112, either directly or through an agent.

The distributor 106 and the content creator 102 may be the same person or different people. For example, a group engaged in musical activities can be both content creator 102 and distributor 106 by recording and distributing their own music. As another example, a publisher can be a distributor 106 that distributes the right to use the work created by the author, Content Creator 102. Content Creator 102 may use Distributor 106 to efficiently manage the financial objectives of content distribution.

The financial information exchange 116 shown in Figure 2 can also be a VDE administrator. The financial information exchange 116, which acts as the VDE administrator, sends "administrative" information to VDE participants. This administrative information can maintain the proper behavior of the virtual distribution environment 100. The roles of "VDE administrator" and financial information exchange can be performed by different persons or companies. Also, each of these can be more than one. Furthermore, about "rules and controls" Virtual distribution environment 100 prevents the use of protected information except as permitted by "rules and controls" (control information). For example, the "rules and controls" shown in FIG. 2 may give "permissions" to use certain content to a particular individual or class of content user 112. These rules and controls may specify what types of content are allowed and what are not. These rules and controls may specify the payment method for content use and the costs involved. As another example, "rules and controls" may need to report content usage information to Distributor 106 and / or Content Creator 102 again.

Each VDE participant in the "chain of processing and control" is usually subject to "rules and control". "Rules and Controls" define the rights and obligations of each of the various VDE participants. "Rules and Controls" provide information and mechanisms that can establish interdependencies and relationships between participants. "Rules and Controls" are flexible, allowing the "Virtual Distribution Environment" 100 to support most "traditional" business transactions. For example C Rules and Controls may specify which payments the Financial Information Exchange 116 may process. C "Rules and Controls" may specify what kind of usage information a participant receives. and C "Rules and Controls" may specify that some information is exposed to some participants and others are kept secret from those participants.

"Rules and controls" can self-limit whether they can be changed and how they can be changed. Often, the "rules and controls" specified by one VDE participant cannot be modified by another VDE participant. For example, content user 112 may not generally change the "rules and controls" specified by distributor 106 that requires the user to pay a fee for content use. "Rules and controls" can be "persistent" when passed through a "chain of processing and control" and "taken over" when passed from one VDE participant to the next.

Based on the request, VDE participants may specify that their "rules and controls" may be modified under the same or different conditions specified by the "rules and controls". For example, the "rules and controls" specified by Content Creator 102 may allow Distributor 106 to "add" to the usage price, just as retailers "add" to the wholesale price of goods. Figure 2A shows that one "rule and control" persists unchanged from content creator 102 to content user 112, another "rule and control" is modified or deleted by distributor 106, and yet another "rule and control". Is added by the distributor.

"Rules and Controls" can be used to protect the privacy of content users by limiting the information reported to other VDE participants. As an example, "rules and controls" may allow content usage information to be reported anonymously without revealing the identity of the content user. Alternatively, "rules and controls" may, if necessary, inform a participant of only certain information (eg, information obtained from use) with "appropriate permissions". This ability to securely control what information is communicated and to which VDE participants are informed enables the protection of the privacy rights of all VDE participants. "Rules and Content" that can be delivered separately As mentioned above, Virtual Distribution Environment 100 associates content with the corresponding "rules and controls" and prevents the content from being used or accessed unless a corresponding set of "rules and controls" is available. .. Distributor 106 does not need to deliver the content to control the distribution of the content. A preferred embodiment may secure the content by protecting the corresponding use which allows "permission and control" from unauthorized distribution and use.

In some examples, "rules and controls" may move with the content to which they apply. Virtual distribution environment 100 also allows "rules and controls" to be delivered separately from the content. The carrier 106 has already been delivered (or will be delivered in the future) because no one can use or access the protected content without the "permissions" from the corresponding "rules and controls". You can control the use of content. "Rules and controls" may be delivered via a different route than that used for content delivery. "Rules and controls" can also be delivered at different times. The content creator 102 may deliver the content to the content user 112 through the electronic highway 108. Alternatively, the content creator may make the content available to anyone on the highway. Content may be used during delivery or may be stored for later use or reuse.

Virtual distribution environment 100 also allows payment and reporting means to be delivered separately. For example, content user 112 may have a virtual "credit card" that extends credit (up to a limit) to pay for the use of any content. A "credit transaction" can occur on a user's site without the need for any "online" connection or further approval. The present invention may be used to assist in the secure protection of virtual "credit cards" from unauthorized use. "Rules and content" define the process Figure 3 shows an example of the entire process based on "rules and controls". This example includes an "event" process 402, a weighing process 404, a billing process 406, and a budgeting process 408. Not all processes shown in Figure 3 are used for each set of "rules and controls".

The "event process" 402 detects what has occurred ("event") and determines which of these "events" requires action by another "process". An "event" includes, for example, a request to use the content or issue permission to use it. Some events may require additional processing, while others may not. Whether an "event" requires further processing depends on the "rules and controls" that correspond to the content. For example, a user who lacks permissions does not satisfy his request ("No" Go "). As another example, each user request to open a new page in an ebook may be met (Go), but these requests may not be required for weighing, billing, or budgeting. A user who has purchased a portion of a novel may be allowed to open and read the novel as many times as the user desires, without further weighing, billing, or budgeting. In this simple example, the "event process" 402 weighs, charges, and / or budgets when the user first wants to open a protected novel (ie, when the purchase price can be charged to the user). Requests to request the creation process and later open all the same novels can be treated as "insignificant events". Other content (eg, searching the electronic phone book) may require the user to pay for each access.

The weighing process 404 may record the event and report its use to Distributor 106 and / or other appropriate VDE participants. Figure 4 shows that process 404 can be based on a number of different factors, including:

(a) Type of use billed (b) The type of unit on which the bill is based, (c) Billing charges per unit, (d) When to report, (e) Payment method. These elements may be specified by "rules and controls" that control the weighing process.

Billing process 406 determines the billing amount for the event. This process records and reports payment information.

Budgeting process 408 limits the amount of content used allowed. For example, budgeting process 408 may limit the number of times content can be accessed or copied, eg, limit the number of pages or other content that can be used based on the dollar amount available in a credit account. You may. Budgeting process 408 records and reports financial and other transaction information associated with such restrictions.

If the execution of these processes is successful, the content can be supplied to the user. Containers and "objects" FIG. 5A shows how the virtual distribution environment 100 transfers an information element (content) to a "container" 302 so that, in a preferred embodiment, the information can only be accessed when given by "rules and controls" of the information. Indicates whether it can be packaged in. Normally, the container 302 is electronic rather than physical. The electronic container 302 in one embodiment contains "digital" information having a well-defined structure. Container 302 and its contents may be referred to as "Object 300".

The example of FIG. 5A shows an item that can be placed "inside" container 302. However, container 302 may "contain" these items without actually storing them in the container. For example, container 302 may reference items available at other locations, such as in other containers on a remote site. Container 302 may reference items that are only available for different or limited times. Some items may be too large to be stored in container 302. The item may be delivered to the user, for example, in the form of a "live feed" of video at a given time. Even then, in this embodiment, container 302 "contains" live feed (by reference).

The container 302 may contain the information content 304 in electronic (such as "digital") form. Information content 304 can be novel text, photographs, audio such as music performances or readings, movies or other videos, computer software, or almost any other type of electronic information that can be considered. Other types of "objects" 300 ("managed objects") may include "administrative" or other information in lieu of or in addition to the information content 304.

In the example of FIG. 5A, container 302 may also include the following forms of "rules and controls":

(a) "Permission record" 808 (b) "Budget" 308, and (c) "Other methods" 1000.

Figure 5B shows some additional details regarding permission records 808, budget 308 and other methods 1000. The "permission record" 808 relates to the object 300, for example, who can open container 302, who can use the contents of the object, who can distribute the object, and other control mechanisms that must be active. Specify the right to do. For example, permission record 808 may specify the rights of users to use, distribute and / or manage container 302 and its contents. The permission record 808 may also specify the requirements applied by budget 308 and "other methods" 1000. The permission record 808 may also include security-related information such as scrambling and descrambled "keys".

The "budget" 308 shown in FIG. 5B is, among other things, a special type of "method" 1000 that can specify restrictions on the use of the information content 304 and how payments will be made for the use. Budget 308 may specify, for example, how much of the entire information content 304 can be used and / copied. Method 310 may prevent the use of an amount that exceeds the amount specified by a particular budget.

"Other Methods" 1000 defines the basic behavior used by "Rules and Controls". Such a "method" 1000 is, for example, how usage is "weighed", whether content 304 and other information is scrambled and descrambled, and how it is scrambled and descrambled. , And other processes related to the handling and control of information content 304. For example, method 1000 can record the identities of everyone who opens the electronic container 302 and control how the information content is billed based on "weighing". Method 1000 may apply to one or more different information contents 304 and related containers 302, as well as all or certain parts of the information content 304. Safe processing unit (SPU) Each "VDE participant" may have an "electronic device". The device may be a computer or may include a computer. The device may communicate through the electronic highway 108. FIG. 6 shows the portion of the electronic device secure processing unit (SPU) 500 used in this example by each VDE participant. The SPU500 processes information in a secure processing environment 503 and securely stores important information. The SPU can be emulated by software running on the host electronics.

The SPU500 is enclosed and protected in the "Unauthorized Security Barrier" 502. The security barrier 502 separates the secure environment 503 from other areas. This prevents information and processes in the safe environment 503 from being observed, interfered with and placed outside of appropriate safe conditions. Barrier 502 also controls external access to secure resources, processes and information within the SPU500. In one embodiment, the non-tamperable security barrier 502 detects "encryption" and / or tampering and / or is sensitive within a secure environment 503 when tampering is detected. ) Formed by security features such as hardware that destroys information.

The SPU500 in this embodiment is an integrated circuit (IC) chip 504 that includes hardware 506 and firmware 508. The SPU500 connects to the rest of the electronics via the "device link" 510. The SPU "firmware" 508 in this embodiment is "software" such as "embedded" in the chip 504 and "computer program". Firmware 508 runs hardware 506. Hardware 506 preferably includes a processor for performing the instructions specified by firmware 508. "Hardware" 506 also includes long-term and short-term memory for securely storing information so that it cannot be tampered with. The SPU500 may also have a protected clock / calendar used to time events. The SPU hardware 506 in this embodiment may include special purpose electronic circuits specially designed to perform certain processes (such as "encryption" and "decryption") quickly and efficiently.

The special context in which the SPU500 is used determines how much processing power the SPU500 should have. In this embodiment, the SPU hardware 506 provides at least sufficient processing power to support the safe part of the process shown in FIG. In some contexts, the functionality of the SPU500 can be improved so that the SPU can handle all electronics and be incorporated into general purpose processors. In another context, the SPU500 can work with general purpose processors, so it only needs enough processing power to handle safe processes. VDE Electronics and "Rights Operating System" FIG. 7 shows an example of an electronic device 600 including the SPU500. The electronic device 600 may be substantially any type of electrical device or electronic device such as: C computer C TV "Set Top" Control Box, C pager C phone C sound system C video playback system C video game player C "smart" credit card Is.

The electronic device 600 in this embodiment may include a keyboard or keypad 612, a voice recognizer 613, and a display 614. A human user can enter commands via keyboard 612 and / or voice recognizer 613 to see information on display 614. The device 600 may communicate with the outside world via any of the connections / devices commonly used within electronic devices. The connections / devices shown along the bottom of the figure are examples such as: "Modem" 618 or other telecommunications link; CD ROM disk 620, or other storage medium or device; Printer 622; Broadcast receiver 624; Document Scanner 626; and "Cable" 628 to connect devices to the "network".

Virtual distribution environment 100 provides a "rights operating system" 602 that manages equipment 600 and SPU 500 by controlling their hardware resources. Operating system 602 may also support at least one "device" 608. In general, "application" 608 is hardware and / or software specific to the context of the device 600. For example, if the device 600 is a personal computer, the "application" 608 can be a user-loaded program, such as a word processor, communication system or sound recorder. If the device 600 is a television controller box, application 608 can be hardware or software that allows the user to order the requested video and perform other functions such as fast forward and rewind. In this embodiment, the operating system 602 provides a standardized, well-defined and integrated "interface" that can be supported and operated with many different "applications" 608.

The operating system 602 in this embodiment provides "rights and audit operating system functions" 604 and "other operating system functions" 606. "Rights and Audit Operating System Features" 604 safely handles tasks related to Virtual Distribution Environment 100. The SPU500 provides or supports many of the security features of "Rights and Audit Operating System Features" 402. "Other Operating System Features" 606 deals with general device features. The entire operating system 602 was designed to include "Rights and Audit Operating System Features" 604 plus "Other Operating System Features" 606 from the beginning, but "Rights and Audit Operating System Features" is "Other Operating System Features". May be added to an existing operating system that provides.

The "rights operating system" 602 in this embodiment can work with many different types of equipment 600. For example, a rights operating system can work with large mainframe computers, "minicomputers", and "microcomputers" such as personal computers and portable computing devices. The rights operating system can also work in a control box at the top of a television set, a small portable "pager", a desktop radio, a stereo sound system, a telephone, a telephone switch, or any other electronic device. This ability to operate not only on small devices but also on large devices is called "scalable". The "scaleable" operating system 602 means that there can be a standardized interface through many different devices that perform a wide variety of tasks.

"Rights operating system function" 604 is "service-based" in this embodiment. For example, "Rights Operating System Function" 604 does not always make more detailed "sub-requests" or require the application to relate to the underlying complexity associated with satisfying summary requests. Handles summary requests from application 608. For example, application 608 may simply request that the specified information be read. The "rights operating system function" 604 may then determine whether the desired information is VDE protected content and, if so, perform the processes required to make the information available. This feature is referred to as "transparency". "Transparency" facilitates tasks for application 608. The "rights operating system feature" 604 may support application 608, which knows nothing about the virtual distribution environment 100. Application 608, which "knows" the virtual distribution environment 100, may make more detailed use of the virtual distribution environment 100.

In this embodiment, the "rights operating system function" 604 is "event driven". The "rights operating system function" 604 may respond directly to an "event" or "event" within the device 600, rather than repeatedly reviewing the state of the electronic device 600 to determine if a condition arises.

In this embodiment, some services provided by "rights operating system function" 604 may be extended based on additional "components" delivered to operating system 602. The "Rights Operating System Function" 604 can collect and use "components" sent by different participants at different times. The "component" assists in making the operating system 602 "scaleable". Some components can change how a service behaves on a small device as opposed to how it behaves on a large device (eg, multi-user). Other components are designed to work with a particular application or class of applications (eg, some types of weighing and some types of budgeting). Electronic equipment 600 The electronic device 600 provided by the preferred embodiment can be any electronic device, including, for example, one or more microprocessors and / or microcontrollers and / or other devices that perform logical and / or mathematical calculations. .. It is a computer, computer terminal, device controller for use with a computer, peripherals for use with a computer, digital display, television, video and audio / video projection system, channel selector for use with broadcast and / or cable transmission. Media players including and / or decoders, remote controllers, video and / or audio recorders, compact disc players, video disc players, and tape players, audio and / video amplifiers, virtual reality machines, electronic game players, multimedia players, Rated control machines including radios, telephones, video telephones, faxes, robots, machine tools, etc., and other devices including one or more microcomputers and / or microcontrollers and / or other CPUs that do not yet exist. Can be.

FIG. 8 shows an example of the electronic device 600. This example of electronics 600 includes a system bus 653. In this example, one or more conventional general purpose central processing units (CPU) 654 are connected to bus 653. Bus 653 connects CPU 654 to RAM 656, ROM 658 and I / O controller 660. One or more SPU500s can also be connected to system bus 653. System bus 653 allows the SPU500 to communicate with the CPU 654, and both the CPU and SPU communicate with the RAM 656, ROM 658 and I / O controller 660 (eg, through shared addresses and data lines). ) Can be made possible. Power 659 may power the SPU500, CPU654 and other system components shown.

In the illustrated example, the I / O controller 660 is connected to a second storage device 652, a keyboard / display 612, 614, a communication controller 666 and a backup storage device 668. The backup storage device 668 may store information on mass media such as tape 670, floppy disks, and removable memory cards. The communication controller 666 may allow an electronic device to communicate with another electronic device over a network 672 or other remote communication link. Different electronics 600 can interact with different CPUs and different examples of ROS 602, as long as they typically use compatible communication protocols and / or security methods. In this example, the I / O controller 660 allows the CPU 654 and SPU 500 to read and write from the second storage device 662, keyboard / display 612, 614, communication controller 666 and backup storage device 668.

The second storage device 662 is one or more identical non-secure second storage devices used by the electronic device 600 for general second storage device functions (eg, magnetic disks and magnetic disks). A CD-ROM drive) may be provided. In some embodiments, some or all of the second storage device 652 may include a second storage device that is physically enclosed in a secure enclosure. However, in many embodiments, physically securing the second storage device cannot be practical or cost effective, so that the second storage device 652 stores information in the second storage device 652. It can be used to securely store information by encrypting it before storing it in. If the information is encrypted before it is stored, physical access to the second storage device 652 or its contents will not easily expose or damage the information.

The second storage device in this example stores the code and data used by the CPU 654 and / or the SPU 500 to control the operation of the entire electronic device 600. For example, in Figure 8, the "rights operating system" ("ROS") 602 shown in Figure 7 (including part 604 of ROS that provides VDE functionality and portion 606 that provides other OS functionality) is second. Indicates that it can be stored on storage device 652. The second storage device 652 may also store one or more VDE objects 300. Also, FIG. 8 shows that the secure file 610 shown in FIG. 7 can be stored in a second storage device 652 in the form of a "safe database" or management file system 610. This secure database 610 may perform VDE function 604 by storing and organizing the information used by ROS602. Therefore, the code executed to perform VDE and other OS functions 604 and 606 and the secure file 610 associated with these functions (as well as the VDE object 300) can be stored in a second storage device 652. The second storage device 652 may also store "other information" 673, such as information used by other operating system functions 606 for task management, non-VDE files, and so on. The parts of the elements shown in the second storage 652 may be stored in ROM 658 (except when ROM 658 is replaced) unless these elements require modification. In particular, the ROS602 part is preferably included in the ROM 658 (eg, "bootstrap" routine, POST routine, etc. for use in establishing an operating environment for the electronics 600 when powered). It can be.

FIG. 8 shows that the second storage device 652 can also be used to store the code (application program) that provides the user application 608 shown in FIG. Figure 8 shows that there are two common types of application programs 608, namely the "VDE-aware" application 608a and the non-VDE-aware application 608b. The VDE recognition application 608a may be designed, at least in part, to access and take full advantage of the VDE function 604, especially with the VDE 100 in mind. Due to the "transparency" feature of ROS602, non-VDE-aware applications 608b (eg, applications not specifically designed for VDE100) can also take advantage of access and VDE function 604. Safe processing unit 500 Each VDE node or other electronic device 600 in a preferred embodiment may include one or more SPU500s. The SPU500 can be used to do all the secure processing for the VDE100. For example, the SPU500 is used to decrypt (or unsecure) the VDE protected object 300. The SPU500 can also be used to manage encrypted and / or secure communications (eg by using information authentication and / or error correction validity checking). The SPU500 also manages, audits, and, where appropriate, secure data management processes for VDE Object 300 (via prepayments, credits, and real-time electronic debits from bank accounts and / or VDE node token savings accounts). Can also be done. The SPU500 may also make other transactions related to such VDE object 300. SPU Physical Packaging and Security Barrier 502 As shown in FIG. 6, in a preferred embodiment, the SPU500 provides a secure processing environment in which sensitive and / or commercially valuable information can be securely processed, encrypted and / or decrypted. Can be implemented as a single integrated circuit "chip" 505. The IC chip 505 may include, for example, a small semiconductor "die" about the size of a thumb nail. The semiconductor die may include semiconductor and metal conductive paths. These paths define the functionality of the circuit and therefore the SPU500. Some of these paths are electrically connected to the outer "pin" 504 of the chip 505.

As shown in FIGS. 6 and 9, the SPU500 may be surrounded by a non-tamperable hardware security barrier 502. Part of this security barrier 502 is made of plastic or other packaging that contains the SPU "die". These are relatively safe from unauthorized access and tampering, as the processing that occurs within the SPU500 and the information stored by the SPU500 is not easily accessible to the outside world. All signals pass through the barrier 502 over a secure controlled path provided by BIU530 that limits outside access to internal components within the SPU500. This secure, controlled route attempts to thwart attempts from the outside world to access confidential information and resources within the SPU500.

It is possible to remove the plastic package of the IC chip and achieve access to the "die". Also (eg, using an electron microscope to observe and photograph the die, using other techniques such as operating the circuit and acid-etching or removing the semiconductor layer to expose the other layer, at the same time on the die. It is also possible to analyze and "reverse engineer" the "die" itself (using various types of logic analyzers and microscopes) to collect and analyze the signal. Although no system or circuit is completely immune to such attacks, the SPU Barrier 502 can also include additional hardware protection that is very costly and time consuming for a successful attack. For example, ion implantation and / or other control techniques make it very difficult to visually recognize the SPU die conductive path, so that the SPU internal circuit "self-significantly destroys" when exposed to air and / or light. Can be manufactured in. The SPU500 can store confidential information in internal memory that loses content when it loses power. The circuit can be incorporated into the SPU500, which detects microprobes or other tampering and self-significantly destroys (or destroys other parts of the SPU) when tampering is detected. These and other hardware-based physical security technologies contribute to a hardware security barrier 502 that cannot be tampered with.

To further increase the security of the security barrier 502, it is possible to put or include the SPU500 in one or more physical enclosures, for example: Epoxy or other "embedding resin", another module enclosure containing additional self-significant destruction, self-disabling or other features that are activated when tampering is detected, a password or Other modules that provide additional security protection, such as other authentication requirements for operation. In addition, the addition of another layer of metal to the die can complicate acid etching, microprobing, and the like. Circuits designed to "zero" memory can be included as a phase of self-significant destruction. The plastic package itself can be designed to resist chemical and physical "attacks". The memory inside the SPU500 may have a specialized addressing and refreshing circuit that "shuffles" the bit positions and thereby electrically determines the value of the memory position. These and other techniques can contribute to the security of barrier 502.

In some electronic devices 600, the SPU500 may be integrated on a common chip (or chipset) 505, along with an equipment microcontroller or equivalent, or an equipment I / O or communication microcontroller. For example, in one preferred embodiment, the SPU500 may be integrated with one or more other CPUs (eg, CPU 654 in an electronic device) in a single component or package. The other CPU 654 can be any central control logic configuration, such as, for example, a microprocessor, another microcontroller, and / or an array or other parallel processor. This integrated configuration reduces overall cost, reduces overall size, and allows for faster potential interactions between the SPU500 and CPU654. Also, if integrated SPU / CPU components are a standard feature of widely distributed microprocessor lines, integration can result in wider distribution. Incorporation of the SPU500 into the main CPU 654 of the electronic device 600 (or into another device, or device peripheral microcomputer, or other microcontroller) can substantially reduce the normal cost of implementing the VDE100. Things to consider when integrating can include implementation costs, manufacturing costs, the desired degree of security, and small size.

The SPU500 can be integrated with devices other than the CPU. For example, for video and multimedia applications, some performance and / or security benefits (depending on the overall design) can be obtained by integrating the SPU500 into a video controller or chipset. The SPU500 can also be integrated directly into a network communication chip or chipset or the like. Some performance in high-speed communication applications can also be obtained by integrating the SPU500 with a modem chip or chipset. This can facilitate the incorporation of the SPU500 into telecommunications equipment such as stand-alone fax machines. The SPU500 uses CD-ROM devices, set-top cable devices, gaming devices, and distributed information, allows access to that information, makes transactions related to that information, or distributes information. It can be integrated into various other electronic devices that it consumes. SPU500 internal architecture FIG. 9 is a detailed view of the internal structure of an example of the SPU500. The SPU 500 in this example includes a single microprocessor 520 and a limited amount of memory configured as ROM 532 and RAM 534. More specifically, this example of the SPU500 includes a microprocessor 520, an encryption / decryption engine 522, a DMA controller 526, a real-time clock 528, a bus interface unit ("BIU") 530, and read-only memory ("BIU") 530. It is equipped with a ROM) 532, a random access memory (RAM) 534, and a memory management unit (MMU) 540. The DMA controllers 526 and MMU540 are selective, but without them the performance of the SPU500 can be adversely affected. The SPU500 may include a selective pattern matching engine 524, a selective random number generator 542, a selective arithmetic accelerator circuit 544, and a selective compression / decompression circuit 546. The shared address / data bus configuration 536 may move information between these various components under the control of microprocessor 520 and / or DMA controller 526. An additional or alternative dedicated path 538 connects the microprocessor 520 to other components (eg, to the encryption / decryption engine 522 via line 538a, to the real-time clock 528 via line 538b, and via line 538c. Can be connected to the bus interface unit 530, to the DMA controller via line 538d, and to the memory management unit (MMU) 540 via line 538e).

The following chapters examine each of these SPU components in detail.

Microprocessor 520 The microprocessor 520 is the "brain" of the SPU500. In this example, the microprocessor performs a series of steps specified by the code stored (at least temporarily) in ROM 532 and / or RAM 534. The microprocessor 520 in a preferred embodiment is a dedicated central processing configuration (eg, RISC and / or CISC processor unit, microcontroller, and / or other) for executing instructions stored in ROM 532 and / or other memory. Central processing means, or less desirable, but most applications have process-specific control logic). The microprocessor 520 may be a separate element of circuit design (layout) or a separate package within a secure SPU500.

In a preferred embodiment, the microprocessor 520 typically deals with the most security sensitive aspect of the operation of the electronic device 600. For example, microprocessor 520 may manage VDE decryption, encryption, certain content and / or device usage control information, VDE-secured content usage records, and other VDE usage rule-related functions.

Stored in the second memory 652 of each SPU500 and / or electronic device are, for example, ROS602 software, application program 608, object 300 containing VDE controlled property content and related information, and associated with the object. It can be an example of a management database 610 that stores both information and VDE control information. ROS602 includes, in part, software intended to be executed by the SPU microprocessor 520 to control the use of Object 300 with respect to VDE by electronics 600. As described below, these SPU programs include "load modules" for performing basic control functions. These various programs and associated data are primarily executed and processed by microprocessor 520.

Real-time clock (RTC) 528 In a preferred embodiment, the SPU 500 includes a real-time clock circuit (RTC) 528 that provides a reliable, non-tamperable time pace for the SPU. The RTC528 records the time and date of the day (eg, month, day and year) in a preferred embodiment, and thus may have a combination of calendar and clock. Reliable time-based is important for performing time-based time weighing methods, "time-old decryption keys" and other time-based SPU functions.

The RTC528 must receive power for operation. Optimally, the RTC528 power supply may include a small battery or other secure enclosure located within the SPU500. However, the RTC528 may use an externally located battery or other power source that is external to the SPU500. Such an externally located battery provides the RTC528 with relatively uninterrupted power and also keeps at least some of the volatile RAM534 in the SPU500 non-volatile.

In one embodiment, the electronics power supply 659 is also used to power the SPU500. By using any external power source as the sole power source for the RTC528, at least the SPU500 recognizes any interruption (or any significant interruption) in the external power supply and records such interruptions. Unless responding as appropriate, such as disabling the SPU500's ability to do some or all of the VDE process, it significantly reduces the usefulness of time-based security technologies. Power interruptions can be achieved, for example, by using circuits that are activated by poor power. A power failure sensing circuit can power another circuit that contains associated logic for recording one or more power failure events. The capacitor discharge circuit may provide the temporary power needed to operate this logic. Further or / or, the SPU500 may occasionally compare the output of the RTC528 with the clock output of the host electronics 600, if available. If a difference is detected, the SPU500 may respond appropriately, which will disable the recording of the difference and / or at least part of the process performed by the SPU500 under at least some circumstances. Including.

If a power failure and / or RTC528 difference and / or other event indicates a potential tampering, the SPU500 will store the impact of the SPU, such as execution-related information and / or encryption key-related information. One or more pieces of sensitive information can be automatically destroyed or made inaccessible without privileged intervention. To provide additional SPU operation, VDE information exchanges, administrators and / or distributors must replace the corrupted information as appropriate. This can be achieved by remotely downloading update and / or replacement data and / or code. If the process and / or information is disabled and / or destroyed as described above, the electronics 600 will properly administer, exchange and / or distribute to reinitialize the RTC528. May require secure VDE communication with a person. Until then, some or all of the secure SPU500 processes will not work.

It may be desirable to provide a mechanism for configuring and / or synchronizing the RTC528. In a preferred embodiment, when communication occurs between the VDE electronics 600 and another VDE device, the output of the RTC528 is under the control of the party that is approved and controlled to be "senior". Can be compared with controlled RTC528 output time. In the case of a difference, appropriate action may be taken, including resetting the RTC528 of the participant controlled by the "junior" in the communication.

SPU encryption / decryption engine 522 In a preferred embodiment, the SPU encryption / decryption engine 522 provides special purpose hardware (eg, a state machine) for quickly and efficiently encrypting and / or decrypting data. .. In some embodiments, the encryption / decryption function may be performed instead by the microprocessor 520 under software control, but in general performance is provided with a purpose-built encryption / decryption hardware engine 522. Get nervous. If desired, for example, in order to optimally share one or more circuit elements, the microprocessor 520 may include a combination of processor circuits and dedicated encryption / decryption logic that can be integrated together in the same circuit layout.

In general, it is preferable to use a computationally efficient and highly secure "bulk" encryption / decryption technique to protect most of the data and objects handled by the SPU500. It is preferable to use very secure encryption / decryption technology as a step to authenticate the identity of the electronic device 600, which establishes a communication channel and secures any transferred permissions, methods, and management information. .. In a preferred embodiment, the encryption / decryption engine 522 is a symmetric key encryption / decryption circuit (eg, DES, Skipjack / Clipper, IDEA, RC-2, RC-4, etc.) and antisymmetric (asymmetric) or public. Includes both key (PK) encryption / decryption circuits. The public / private key encryption / decryption circuit is mainly used as a phase of secure communication between the SPU500 and the VDE administrator or other electronic device 600, that is, between the VDE secure subsystems. A symmetric encryption / decryption circuit can be used to "bulk" encrypt and decrypt most of the data stored in the auxiliary storage 662 of the electronic device 600 in which the SPU 500 resides. The symmetric key encryption / decryption circuit can also be used to encrypt and decrypt the content stored within the VDE object 300.

DES or public / private key methods can be used for all cryptographic functions. In alternative embodiments, encryption and decryption methods other than DES and public / private key methods may be used for various encryption-related functions. For example, other types of symmetric encryption / decryption techniques that use the same key for encryption and decryption can be used instead of DES encryption and decryption. A preferred embodiment can support multiple encryption / decryption techniques using a number of dedicated circuits within the encryption / decryption engine 522 and / or a processing arrangement within the SPU500.

Pattern matching engine 524 An arbitrary pattern matching engine 524 can be used to obtain special purpose hardware that performs a pattern matching function. One of the possible functions of the SPU500 is to validate / authenticate the VDE object 300 and other items. Validity testing / authentication often compares long data strings to determine if they are the same in a particular way. In addition, in certain forms of use (such as the logical and / or physical (consecutive) relationships of accessed elements), potentially long strings that may possibly be for a particular bit pattern. It may be necessary to search for data), or metric related to other important patterns. The pattern matching can be performed by the SPU microprocessor 520 under the control of software, but the speed of the pattern matching process can be increased by providing the special purpose hardware pattern matching engine 524.

Compression / decompression engine 546 Any compression / decompression engine 546 may be installed within the SPU500 to, for example, compress and / or decompress the content stored in or emitted from the VDE object 300. The compression / decompression engine 546 uses the hardware circuitry to perform one or more compression algorithms and the performance of the compression / decompression operation (which would otherwise operate outside the microprocessor 520, or SPU500. (Performed by the software you are using) can be improved. Decompression is important in the release of data such as video or audio, which is usually compressed before distribution and whose decompression speed is important. In some cases, information useful for monitoring usage (such as record separators or other delimiters) is "hidden" under the compression layer, which is before this information is detected and used within the SPU500. Must be deleted.

Random number generator 542 Any random number generator 542 may provide dedicated hardware circuitry to generate random values (eg, from essentially unexpected physical processes such as quantum noise). Such random values are particularly useful for constructing encryption keys or unique identifiers, and for initializing the occurrence of pseudo-random columns. The random number generator 542 can generate any convenient length of value, including values as small as a single bit per use. Random numbers of any size can be constructed by concatenating the values generated by the random number generator 542. Random keys and seeds generated by the random number generator 542 and iterative encryption by the cryptographic / decryption engine 522 in the SPU500 or cryptographic algorithms can generate cryptographically strong pseudo-random sequences. Such columns can be used, for example, in secret headers to discourage attempts to determine cryptographic keys by cryptographic analysis.

Computational Accelerator 544 Any arithmetic accelerator 544 can be installed in the SPU500 in the form of a hardware circuit that can quickly perform mathematical calculations such as multiplication and exponentiation with large numbers. To assist in the calculations required for certain asymmetric encryption / decryption operations, these calculations may be requested, for example, by the microprocessor 520 or the encryption / decryption engine 522. Such arithmetic accelerators are well known to those of skill in the art. In some embodiments, the independent arithmetic accelerator 544 is omitted and any required computation may be performed by the microprocessor 520 under software control.

DMA controller 526 The DMA controller 526 controls the transfer of information to the address / data bus 536 without having to have the microprocessor 520 handle each individual data transfer. Typically, the microprocessor 520 writes the target, destination address, and number of bytes to be forwarded to the DMA controller 526, which in turn encrypts / decrypts between the components of the SPU 500 (eg, ROM 532 to RAM 534). Data blocks can be automatically transferred between the engine 522 and RAM534, between the bus interface unit 530 and RAM534, and so on. The DMA controller 526 may have a large number of channels to handle a large number of transfers simultaneously. In some embodiments, the independent DMA controller 526 can be omitted and any necessary data movement can be performed by the microprocessor 520 under software control.

Bus interface unit (BIU) 530 The bus interface unit (BIU) 530 communicates information between the SPU500 and the outside world beyond the safety barrier 502. The BIU530 shown in FIG. 9 with appropriate driver software may include the "appliance link" 510 shown in FIG. In a preferred embodiment, the bus interface unit 530 can be modeled following a USART or PCI bus interface. In this example, the BIU530 connects the SPU500 to the electronics system bus 653 shown in FIG. The BIU530 is designed to prevent unauthorized access to internal components and their content within the SPU500. This is done by only allowing the signals associated with the SPU500 to be processed by the control program running on the microprocessor 520 and not supporting direct access to the internal elements of the SPU500.

Memory management unit 540 The Memory Management Unit (MMU) 540, if present, provides hardware support for memory management and virtual memory management capabilities. It also provides improved security by enhancing hardware compartmentalization of secure execution spaces (for example, preventing relatively unreliable tasks from modifying more reliable tasks). Can be done. In connection with the discussion of the architecture of the Safe Processing Environment (SPE) 503 supported by the SPU500, it is described in more detail below.

The MMU540 may also provide hardware-level support features related to memory management, such as address mapping.

SPU memory architecture In a preferred embodiment, the SPU500 uses three types of general purpose memory: (1) Internal ROM 532; (2) Internal RAM534; and (3) External memory (typically RAM and / or disk supplied by the host electronics) The internal ROM 532 and RAM 534 in the SPU500 provide a safe operating environment and execution space. Due to cost limits, chip size, complexity and other limits, it may not be possible to have enough memory inside the SPU500 to store all the information the SPU needs to process safely. Due to the practical limits of the ROM 532 and RAM 534 capacities that can be contained within the SPU500, the SPU500 stores information in external memory and, if necessary, moves this information in and out of the safe internal memory space. obtain. In this case, the safeguard steps performed by the SPU are typically small, safely packaged elements that can be "paged in" to, and "paged out" from, limited available internal memory space. Must be divided. Memory outside the SPU500 may not be safe. Since external memory may not be secure, the SPU500 may encrypt and cryptographically seal code and other information before storing it in external memory. Similarly, the SPU500 typically has to decrypt encrypted code and other information obtained from external memory before processing (eg, executing) based on it. In a preferred embodiment, there are two common approaches used to address potential memory limitations within the SPU500. In the first case, the small, safely packaged element represents the information contained in the safety database 610. In the second case, such an element may represent a protected (eg, encrypted) virtual memory page. Virtual memory pages can correspond to information elements stored in safety database 610, but this is not required in the SPU memory architecture of this example.

Each of these three SPU memory resources is discussed in more detail below.

SPU internal ROM The SPU500 read-only storage element (ROM) 532, or comparable purpose device, provides a safe internal non-volatile storage device for specific programs and other information. For example, ROM 532 may store a "kernel" program such as SPU control firmware 508, and if desired, encryption key information and certain key "load modules". The "kernel" program, load module information, and encryption key information allow control of certain basic functions of the SPU500. Components that are at least partially dependent on the configuration of the device (eg POST, memory allocation, and dispatcher) are loaded into ROM 532 with additional load modules that are determined to be required for a particular installation or application. obtain.

In a preferred embodiment, the ROM 532 may include a combination of a masked ROM 532a with an EEPROM and / or equivalent "flash" memory 532b. EEPROM or flash memory 532b is used to store items such as specific encryption keys that need to be updated and / or initialized. A further advantage of installing EEPROM and / or flash memory 532b is that any load module and library functionality permanently stored in the SPU500 can be optimized based on typical applications at a particular site. These items can also be stored in NVRAM534b, but EEPROM and / or flash memory 532b is more cost effective.

The masked ROM 532a can be less costly than the flash and / or EEPROM 532b and can be used to store permanent portions of the SPU software / firmware. Such permanent parts may include code that interfaces with hardware elements such as RTC528s, encryption / decryption engines 522, interrupt handlers, and key generators. Some operating systems, library calls, libraries, and many core services provided by the SPU500 can also be built into the masked ROM 532a. In addition, some more commonly used executables can also possibly be built into the masked ROM 532a. Items that need to be updated or lost when the SPU500 is unpowered should not be stored in the masked ROM 532a.

In some circumstances, RAM534a and / or NVRAM534b (NVRAM534b is, for example, a conventional RAM that is constantly powered) may perform at least part of the role of ROM532.

SPU internal RAM The SPU500 general purpose RAM534 provides, among other things, a safe execution space for safe processing. In a preferred embodiment, the RAM 534 includes different types of RAM, such as a combination of high speed RAM 534a and NVRAM (nonvolatile RAM) 534b. While RAM534a can be volatile, NVRAM534b is preferably battery-backed or otherwise non-volatile (ie, does not lose its contents when powered off). Is placed in.

The fast RAM534a stores the active code to be executed and the associated data structure.

The NVRAM534b preferably contains specific keys and summary values that are preloaded as part of the initialization process that the SPU500 communicates with the VDE administrator, as well as convertible or convertible related to the operation of the SPU500. Information can also be stored. For security reasons, certain highly sensitive information (eg, certain load modules such as internally generated private keys and certain cryptographic key related information) is loaded into or internally generated by the SPU500. Sometimes it needs to be, but once loaded or internally generated, it must not leave the SPU. In this preferred embodiment, the SPU 500's Non-Volatile Random Access Memory (NVRAM) 534b can be used to securely store such highly sensitive information. NVRAM534b is also used by the SPU500 to store data that can be converted frequently, but must not be lost when the power is turned off or in power down mode.

NVRAM534b is preferably a flash memory array, but in addition to or instead, electrically erasable programmable read-only memory (EEPROM), static RAM (SRAM) with sufficient speed and cost efficiency. ), Bubble memory, 3D holographic or other electro-optical memory, or other writable (eg, randomly accessible) non-volatile memory.

SPU external memory The SPU500 can store specific information in a memory device outside the SPU. If available, the memory of electronics 600 can also be used to support any device external portion of the SPU500 software. Certain benefits can be gained by having the SPU500 use external memory. As an example, the size of the internal memory of the SPU 500 can be reduced by using non-volatile read / write memory, such as the non-volatile portion of RAM 656 and / or ROM 658, within the host electronics 600.

Such external memory can be used to store SPU programs, data and / or other information. For example, a VDE control program, at least in part, is loaded into memory, communicated to the SPU500, and decrypted in it before execution. Such controls are re-encrypted and communicated back to external memory that can be stored for subsequent execution by the SPU500. A "kernel" program and / or some or all non-kernel "load modules" may be stored by the SPU500 in external memory. Since the safety database 610 can be relatively large, the SPU500 can store some or all of the safety database 610 in external memory and partially call the SPU500 as needed.

As mentioned earlier, the memory outside the SPU500 may not be safe. Therefore, when security is required, the SPU500 must encrypt the security information before writing it to the external memory and decrypt the security information read from the external memory before use. Because the cryptographic layer relies on the security processes and information (eg, cryptographic algorithms and keys) that reside within the SPU500, the cryptographic layer effectively "extends" the SPU security barrier 502 to the outside of the SPU500. Protect the information stored in a certain memory.

The SPU500 can use a wide variety of different types of external memory. For example, the external memory may include an electronic device auxiliary storage device 652 such as a disk; external EEPROM or flash memory 658; and / or external RAM 656. The external RAM 656 may include external non-volatile (eg, constantly voltageed) RAM and / or cache RAM.

By using the SPU500's local external RAM, the access time to information stored outside the SPU is significantly improved. For example, external RAM can be used for: C Buffering memory image pages and data structures (assuming transfers to flash or hard disk during a significant power or system failure) before storing them in flash memory or an external hard disk; To provide an encryption and decryption buffer for the data emitted from the C VDE object 300. As a step to provide a secure virtual memory environment for the C SPU500, cache the "swap blocks" and VDE data structures currently in use. C For example, caching other information to reduce the frequency of SPU access to auxiliary storage 652 and / or for other reasons.

Dual-port external RAM can be particularly effective in improving the performance of the SPU 500, as it can reduce the data movement overhead of the SPU bus interface unit 530 and the SPU microprocessor 520.

The SPU500's local external flash memory can be used to significantly improve access times to virtually all data structures. Since the most available flash storage devices have a limited write life, the flash storage device needs to consider the number of writes that occur during the life of the flash memory. Therefore, flash storage of frequently written temporary items is not preferred. If the external RAM is non-volatile, transfer to flash (or hard disk) may not be necessary.

The external memory used by the SPU500 can include two categories: External memory dedicated to C SPU500, and C Memory shared with electronic device 600.

In some VDE embodiments, sharing memory (eg, electronics RAM656, ROM658, and / or auxiliary storage 652) with CPU654 or other element of electronics 600 can be VDE safety database management file 610, and SPU500. It is the most cost-effective method for storing information that needs to be stored outside of. The host system hard disk auxiliary memory 652 used for general purpose file storage may also be used, for example, to store the VDE management file 610. The SPU500 may be given exclusive access to external memory (eg, the local bus high speed connection provided by BIU530). It is possible to have both dedicated and shared external memory. ****** The hardware configuration of an example of the electronic device 600 has been described above. The following sections describe an example of the software architecture of the electronic device 600 provided by the preferred embodiment, including the structure and operation of the preferred embodiment "Rights Operating System" ("ROS") 602. Rights operating system 602 The rights operating system (ROS) 602 in a preferred embodiment is a compact, secure, event-driven, service-based, component oriented distributed multi-processing operating system environment with VDE information security control information, components, and It integrates the protocol with traditional operating system concepts. As with traditional operating systems, the ROS 602, provided in a preferred embodiment, is a piece of software that manages the hardware resources of a computer system and extends the scope of management capabilities to input and / or output devices, including communication devices. It is a department. Also, like traditional operating systems, the preferred embodiment ROS602 provides a coherent set of basic features and abstraction layers to hide the differences between specific hardware embodiments and the complexity of many of their details. provide. In addition to these characteristics found in many or most operating systems, ROS602 offers secure VDE transaction management and other advantageous features not found in other operating systems. The following is a partial list of some of the advantageous features provided by ROS 602 in preferred embodiments: A standardized interface provides a coherent set of basic features Simplify C programming C You can run the same application on many different platforms Event driven C Facilitates functional decomposition C extensible C Fit state transitions and / or process-oriented events C Simplify task management C Simplify internal processing communication Service base C Enables simple and transparent scalability Simplify C multiprocessor support C Hide machine dependencies C Facilitates network management and support Component-based architecture C Processing based on independently deliverable safety components The C processing control component model can tolerate a different set of steps that can be reconfigured based on requirements. C components can be added, removed, or modified (with permission) C Complete control information across predefined and user-defined application events C Independent executables allow individual control of events safety C secure communication C Safety control function C Safe virtual memory management C Information control structure protected from exposure C data elements are validated, interrelated, and access controlled C components are independently encrypted and validated C components are strongly interrelated to prevent unauthorized use of the element C Validate control structures and secure executables before using them to protect against tampering Integrate safety considerations at the CI / O level Provides on-the-fly decoding of information on C emission C Enables a secure commercial trading network C Features flexible key management Scale changeability C High resiliency for many different platforms Supports simultaneous processing in a C multiprocessor environment C Supports many collaborative processors C Supports a small number of hosts or secure processors C control structures and kernels are easily portable to different host platforms and different processors within the target platform without recompiling. C Support remote processing C Remote Procedure Calls can be used for internal OS communication Highly integrated C Highly integrated with the host platform as an additional operating system layer C Allow unsafe storage of secure components and information using the OS layer "above" the traditional OS platform C Can be seamlessly integrated with the host operating system to provide a general-purpose paradigm for transaction management and content access C integration can take many forms: operating system layers for desktops (eg, DOS, Windows®, Macintosh®); operating system interfaces for device drivers and network services (eg Unix). (Registered Trademarks) and NetWare); and dedicated component drivers for "low-end" settops are part of many examples and can be integrated into traditional and real-time operating systems. Distributed C Provides control information and mutual control information distribution and mechanism Supports conditional execution of controlled processing on any C-distributed, asynchronously-arranged VDE node C Controlled delegation of rights in a distributed environment C Supports handling and control chains Management environment for C distributed, sometimes connected, and otherwise asynchronously networked databases C Real-time and time-independent data management C Supports "agent" processing Transparent C Can be seamlessly integrated into existing operating systems C Can support applications not specifically written for its use Network friendly C internal OS structure may use RPC to distribute processing The C subnet is a general background for operating systems that can operate seamlessly as a single node or independently. An "operating system" provides a control mechanism for organizing computer system resources so that programmers can more easily create applications for computer systems. The operating system does this by providing commonly used features and helping to ensure compatibility between different computer hardware and architectures (eg, which may be manufactured by different sellers). The operating system also allows computer "peripheral" manufacturers to more easily supply compatible equipment to computer manufacturers and users.

Computer systems are usually made up of several different hardware components. These hardware components include, for example: Central processing unit (CPU) for executing instructions; An array of main memory cells (eg, "RAM" or "ROM") for storing execution instructions and data that operates or parameterizes them; One or more auxiliary storage devices (eg, hard disk drive, floppy (registered trademark) disk drive, CD) organized to reflect a named element (the "file system") for storing the image of the main memory cell. -ROM drive, tape reader, card reader, or "flash" memory).

Most computer systems also include input / output devices such as keyboards, mice, video systems, printers, scanners, and communication devices.

Software referred to as an "operating system" to organize the execution power of a CPU into available RAM, ROM, and auxiliary storage and to provide features commonly used when used by programmers. One of them is usually included along with the other components. Typically, this one piece of software is designed to start running after power is on the computer system and the hardware diagnostics are complete. After that, all use of the CPU, main memory, and auxiliary memory devices is usually managed by this "operating system" software. Also, most computer operating systems typically extend their management capabilities to I / O and other peripherals, including the commonly used features associated with these devices. Including the mechanism.

By managing CPU, memory, and peripherals through the operating system, a consistent set of abstraction layers to obscure basic functionality and hardware details makes it easier for programmers to create complex applications. .. In addition, managing computer hardware resources with an operating system can hide many differences in design and equipment requirements between different manufacturers. In addition, it can support basic hardware and peripherals from different manufacturers with considerably less work, making it easier to share applications with other users with the same operating system. ROS602, an operating system that offers significant benefits ROS602 is an "operating system". ROS602 manages the resources of electronics 600 and provides a set of commonly used features to programmers writing applications 608 for electronics. The "ROS 602" in a preferred embodiment manages the hardware (eg, CPU, memory, secure RTC, and encryption / decryption engine) within the SPU500. ROS can also manage hardware (eg, CPU and memory) in one or more general purpose processors in electronics 600. The ROS602 also manages other electronics hardware resources such as peripherals attached to the electronics. For example, referring to FIG. 7, the ROS 602 may manage a keyboard 612, a display 614, a modem 618, a disk drive 620, a printer 622, and a scanner 624. The ROS 602 may also manage a secure database 610 and a storage device used to store the secure database 610 (eg, "auxiliary storage device" 652).

The ROS602 supports a large number of processors. The ROS 602 in a preferred embodiment supports a number of local and / or remote processors. Supported processors may include at least two types (one or more electronics processors 654 and / or one or more SPU500). Host processor CPU 654 may provide storage, database, and communication services. The SPU500 may provide cryptographic and secure processing execution services. The various control and execution structures supported by ROS602 may require that the processing of control information occur within a controllable execution space--this controllable execution space may be provided by the SPU500. Additional hosts and / or SPU processors can increase efficiency and / or capacity. The ROS602 may access, coordinate and / or manage additional processors in the remote of electronics 600 (eg, through a network or other communication link) to provide additional processor resources and / or capabilities.

ROS602 is service based. In a preferred embodiment, the ROS services provided using the host processor 654 and / or the secure processor (SPU500) are linked using a "remote procedure call" ("RPC") internal processing request structure. Cooperative processors may request internal processing services that are minimally time-dependent and can be distributed to cooperating processors on the host's network using the RPC mechanism. The multiprocessor architecture provided by ROS602 can be easily extended to support any number of hosts or secure processors. This extensibility supports a high level of resiliency. Also, depending on the service, the function may be performed differently on different equipment. For example, a small device that is underutilized by one user can perform a database service that uses a technology that is significantly different from a very large device that is underutilized by many users. This is another aspect of resiliency.

ROS602 provides a distributed processing environment. For example, it allows information and control structures to automatically and securely traverse sites as needed to fulfill a user's request. Communication between VDE nodes under the distributed processing feature of ROS602 may include internal processing service requests as described above. The ROS602 supports controlled processor condition and / or state-dependent execution within any VDE node. The location where the process is performed and the control structure used is supported by the process, which is locally resident, remotely accessible, or supports execution in a remote system.

ROS602 provides, for example, the distribution of control information, including the distribution of control structures required to allow an "agent" to operate in a remote environment. Therefore, ROS602 provides a facility for passing execution and / or information control as part of the requirements that arise for "agent" processing.

If desired, the ROS602 can independently distribute control information over very narrow bandwidth connections that may be "real-time" connections. The ROS 602 provided by the preferred embodiment is "network friendly" and can be implemented with any level of network protocol. Some examples include email and direct connections near "Layer 5" in the ISO model.

The ROS602 distribution process (and related audits of distribution information) is a controlled event in which it uses such a control structure. This "reflected" distribution processing mechanism allows ROS602 to securely distribute rights and permissions under control and effectively limit the usage characteristics of information content. Controlled delegation in a distributed environment and the safety treatment technology used by ROS602 to support this approach offer significant benefits.

The specific control mechanism within ROS602 is "mutual". Mutual control mechanisms place one or more control components that interact in a controlled manner with one or more components in the same or other location in one or more locations. For example, usage controls related to object content at a user's location have mutual control at the distributor's location that governs the distribution of usage controls, auditing of usage controls, and the logic for handling user requests associated with usage controls. Can be done. Usage control at a user's location (in addition to controlling one or more usage aspects) may provide format requests related to auditing for the distributor and usage control for processing by the distributor. .. The processing at both ends of the mutual control can be controlled by yet other processing (eg, the distributor may be limited by the budget for the number of production of the usage control mechanism). Mutual control mechanisms can extend to many sites and to many levels (eg, from creator to distributor to user) and in any relationship (author / distributor, distributor / user, user / user,). Users / creators, users / creators / distributors, etc.) can also be considered. Mutual control mechanisms are often used in VDE100 to show relationships and agreements in a distributed environment.

ROS602 can be scaled. Most of the ROS602 control structure and kernel are easily portable to various host platforms without recompiling. Any control structure can be distributed (or redistributed) if the licensing authority permits this type of activation. The viable reference within ROS602 is portable to the target platform. In different examples of ROS602, referrals can be performed with different resources. For example, in one example of ROS602, a task is performed using SPU500, while in another example of ROS602, a host processing environment that is run in a protected memory that emulates the SPU in software. Can be used to perform the same task. ROS602 control information is portable as well; in many cases, event handling structures are passed between the machine and the host platform as easily as between collaborative processors within a single computer. Equipment with different usages and / or resources with available ROS602 functions can perform these functions in very different ways. Without sufficient resources, some services can be omitted altogether. As explained elsewhere, ROS602 "knows" which services are available and how to continue based on a given event. Not all events may be manageable if resources are missing or inadequate.

The ROS 602 is component based. Many of the functionality provided by ROS 602 in preferred embodiments may be based on "components" that can be safely and independently delivered, replaced, and modified (eg, under properly safe conditions and approval). .. In addition, "components" can be made up of elements that they can deliver independently. The ROS602 may assemble these elements together at run time (using a structure referred to as a "channel" provided by the preferred embodiment). For example, a "load module" for execution by the SPU500 can be collected and assembled by one or more "method cores", method parameters, and ROS602 to perform tasks such as billing or metering. Other related data structures can be referenced. Different users may have different combinations of elements, some of which may be customizable by a properly authenticated user. This increases flexibility, allows the element to be reused, and provides other benefits.

ROS602 is very safe. ROS602 provides a mechanism to protect information control configurations from exposure by end users or conduit hosts. The ROS602 can protect information, VDE control structures, and control executables by using strong cryptographic and validation mechanisms. These cryptographic and validation mechanisms are designed to provide high protection against undetected tampering. The ROS 602 encrypts the information stored in the auxiliary storage device 652 in order to prevent unauthorized modification. ROS602 It also encrypts and validates its various components separately. ROS602 correlates control and data structure components to prevent elements from being used unauthenticated. These features allow the ROS602 to distribute elements independently and integrate unsafe "other" OS features 606 with VDE features 604.

The ROS 602 provided by the preferred embodiment extends the scope of traditional capabilities, such as access control list (ACL) structures, to user and process defined events, including state transitions. The ROS602 may provide full control information for pre-defined and user-defined application events. These control mechanisms include "go / no-go" permissions and any event-specific execution that allows full flexibility in the processing and / or control of events. This structure allows events to be controlled individually, for example, allowing weighing and budgeting to be provided using independent execution. For example, ROS602 extends the ACL structure to control any granularity of information. Traditional operating systems provide a static "go / no-go" control mechanism at the file or resource level; ROS602 uses a flexible control structure and is a range of control concepts by common techniques. Extends from the largest subelement to the smallest subelement. ROS602 controls printing of one paragraph of a document file, for example.

The ROS 602 provided by the preferred embodiment allows the secure modification and update of the control information governing each component. Control information can be provided to the end user in template formats such as method options. The end user can then customize the actual control information used in the guidelines provided by the distributor or content creator. Preferably, the modification and update of the existing control configuration is also an event that can be controlled subject to audit and control information.

The ROS 602 provided by the preferred embodiment is validated prior to use of the control structure and secured execution. This validation verifies that the control structure and execution have not been tampered with by the end user. Validity checks also allow ROS602 to safely execute components containing files and other operating system structure fragments. The ROS 602 provided by the preferred embodiment integrates security considerations at the I / O level (below the access level) of the operating system and provides "on-the-fly" decryption of information on emission. These features allow the unsafe storage of ROS602 safety components and information using the OS layer "above" the traditional operating system platform.

The ROS602 is highly integrated with the host platform as an additional operating system layer. Therefore, ROS602 can be created by "adding" to an existing operating system. This involves hooking the VDE "add-on" to the host operating system at the device driver and network interface level. ROS602 may also include a completely new operating system that integrates both VDE and other operating system features.

Exactly, there are at least three common approaches to integrating VDE functionality into a new operating system, possibly based on an existing operating system, to create a rights operating system 602: (1) Redesign the operating system based on VDE transaction management requirements; (2) Compile VDE API functionality into an existing operating system; and (3) Integrate the VDE interpreter into the existing operating system.

The first approach is most effectively applied when a new operating system is designed or when there are plans for a significant upgrade of an existing operating system. For the design of new operating systems that provide an optimal and efficient way to integrate "traditional" operating system capabilities with VDE capabilities, the design requirements list adds the transaction management and security requirements provided by the VDE capabilities. Can be done. For example, an engineer responsible for designing a new version or example of an operating system may have requirements for VDE weighing / transaction management (if any) in addition to the requirements for shaping the design approach, specifications, and actual implementation. May include. This approach provides "seamless" integration and capability of VDE functionality by incorporating weighing / transaction management functionality into system design and embodiments.

The second approach involves taking an existing set of API (Application Programmer Interface) features and incorporating references in the operating system code into VDE feature calls. This is similar to how the current Windows® operating system is integrated with DOS, which doubles as a starting point and an important part of the kernel foundation of the Windows® operating system. This approach also provides a high degree of "seamless" integration (although not as "seamless" as compared to the first approach). The advantage of this approach is that it incorporates low-cost weighing / transaction management functionality into new versions or examples of operating systems (using existing code embodied within the API, and also an API functionality approach. It involves being achieved (by influencing the design of the element in which the weighing / transaction management functionality is incorporated with the design implications of.

The third approach does not incorporate VDE functionality related to weighing / transaction management and data security directly into the operating system code, but instead implements weighing / transaction management functionality by adding newly generated capabilities to the operating system. It differs from the first two approaches in that it does. In this case, the interpreter, including weighing / transaction management capabilities, is integrated with other operating system code in "standalone" mode. This interpreter can take scripts or other inputs to determine what the weighing / transaction management function should do, in what order, under what circumstances or conditions.

Instead of (or in addition to) integrating VDE functionality with / into the electronics operating system, it is possible to provide specific VDE functionality as an application running on traditional operating systems. ROS software architecture FIG. 10 is a block diagram of an example software configuration / architecture for the Rights Operating System (ROS) 602 provided by the preferred embodiment. In this example, the ROS602 is an operating system (OS) core 679, user application program interface (API) 682, redirector 684, intercept 692, user notification / exception interface (Notification / Exception). Includes Interface) 686, and file system 687. ROS602 in this example also includes one or more Host Event Processing Environments (HPE) 655 and / or one or more Safe Event Processing Environments (SPE) 503 (these environments are generic). Can be referred to as the "protected processing environment" 650).

The HPE655 and SPE503 are independent computing and processing environments that may include their own operating system kernel 688, which contains code and data processing resources. A given electronics 600 may include a number of SPE503 and / or a number of HPE655. HPE655 and SPE503 may process information in a secure manner and provide safe processing support for ROS602. For example, each may perform secure processing based on one or more VDE component assemblies 690 and provide secure processing services to each OS kernel 680.

In a preferred embodiment, the SPE503 is a safe processing environment provided by the SPU500, at least in part. Therefore, the SPU500 provides a hardware tamper-proof barrier 503 that surrounds the SPE503. The SPE503 provided by the preferred embodiment is preferably: C Small and compact C For example, it can be loaded into a resource-constrained environment such as the minimally configured SPU500. C Can be updated dynamically C Extendable by authenticated users Can be integrated into C object or procedural environment C safe In a preferred embodiment, the HPE655 is a safe processing environment supported by a processor other than the SPU, such as an electronic device CPU654 general purpose microprocessor or other processing system or device. In a preferred embodiment, the HPE655 can be considered to emulate the SPU500 in that the software can be used to provide some or all of the processing resources provided by the SPU in the hardware and / or firmware. The HPE655 in one preferred embodiment of the invention has all functions and is fully compatible with the SPE503, i.e. the HPE655 handles all of the service calls that the SPE503 can handle. From an external interface perspective, SPE and HPE are "plug compatible" (except that HPE does not provide as much security as SPE) because it is possible.

HPE655 may be offered in two types (safe and unsafe). For example, if electronics 600 use all the resources of a high-speed general purpose processor or computer to efficiently run unaffected VDE tasks, it may be desirable to install an unsafe version of HPE655. Such an unsafe version of HPE655 can be run under the supervision of an example of ROS602, including SPE503. Thus, the ROS602 runs all safety operations within the SPE503 and does not require safety, but may be required under the potentially large resources provided by a general purpose computer or processor that supports HPE655. HPE655 may only be used for processing (or running more efficiently). The unsafe and safe HPE655 can work with the secure SPE503.

The HPE655 features a software-based tamper-proof barrier 674 that makes them more secure (as shown in Figure 10). Such a software-based tamper-proof barrier 674 can be created by software running on a general purpose CPU 654. Such a "safe" HPE655 can be used by ROS602 to perform processing that does not require the degree of safety provided by the SPU500, while still requiring safety. This has many advantages, especially in architectures that offer both SPE503 and HPE655. While the SPU502 is used to perform all safeguards accurately, one or more HPE655s are additionally safeguarded with a host processor or other general purpose resource that may be available within the electronics 600. Can be used to provide (although it may be less secure than SPE in some cases). Any service may be provided by such a secure HPE655. In a preferred embodiment, certain aspects of "channel processing" appear to have elements that can be easily exported from SPE503 to HPE655.

Use any software and / or hardware memory management resources of the electronic device 600 to "protect" the operation of the HPE655 from other processes, functions, and so on. Such a software-based tamper-proof barrier 674 can provide a fairly high degree of security, but typically the hardware-based tamper-proof barrier provided by the SPU500 (at least in part). Not as safe as 502. Many because the assistance of hardware safety features such as those provided by the SPU500 enhances safety more effectively (and due to other factors such as performance gains from purpose-built circuits within the SPU500). Or for most high safety applications, it is preferable to have at least one SPE503. However, in applications where lower safety is tolerated and / or the cost of the SPU500 is not tolerated, the SPE503 is omitted and instead all safety is handled by one or more secure HPE655s running on the generic CPU654. Can be done. Some VDE processes may not allow this type of reduced-safety electronics to be performed if the particular process involved provides inadequate security.

Only operations performed completely within SPE503 (in some cases HPE655) can be considered truly secure. Memory and other resources outside the SPE503, as well as the HPE655 used to store and / or process the code and / or data used in safe processing, are the SPE503 / HPE655 from unsafe processing to safe processing code and / Or unless you can protect your data, you should only accept and handle encrypted information.

In a preferred embodiment, OS "core" 679 includes kernel 680, RPC manager 732, and "object switch" 734. API682, HPE655, and SPE503 can communicate "event" messages with each other via OS "core" 679. They can also communicate messages directly with each other without going through OS "Core" 679.

The kernel 680 can manage the hardware of the electronic device 600. Interacts with other device peripherals such as inputs / outputs and / or keyboards 612, displays 614, "mouse" pointing devices and voice recognizers 613, modems 618, printers 622, and adapters for network 672. Appropriate drivers and hardware managers may be provided for this. Kernel 680 is also responsible for initially loading the remainder of ROS602 and can manage various ROS tasks (and associated underlying hardware resources) during execution. OS kernel 680 can also manage and access safety database 610 and file system 687. OS kernel 680 also provides execution services for applications 608a (1), 608a (2), and other applications.

RPC Manager 732 provides routine and resource management / integration messaging for ROS680. For example, receive and route "calls" to / from API682, HPE655 and SPE503.

Object switch 734 may manage the construction, dismantling, and other operations of VDE object 300.

The user notification / exception interface 686 (which may be part of API 682 or other application linked to the API) in a preferred embodiment provides a "pop up" window / display to display 614. This allows the ROS602 to communicate directly with the user without having to pass the information to the application 608 to communicate. For applications that are not "VDE-aware" applications, the user notification / exception interface 686 may provide communication between the ROS 602 and the user.

API 682 in a preferred embodiment provides application 608 with a standardized and documented software interface. API682 may partially translate the operating system "call" generated by application 608 into a remote procedure call ("RPC") that identifies an "event". RPC Manager 732 routes these RPCs to kernel 680 or elsewhere (eg, HPE655 and / or SPE503, or remote electronics 600, processor, or VDE participant) for processing. API 682 can also be serviced by passing an RPC request to application 608, which registers to receive and process a particular request.

API682 preferably provides a standardized and documented "Applications Programming Interface". Provides a concise set of functional calls that application programs can use to access the services provided by ROS602. In at least one preferred example, API 682 includes two parts: an application program interface with VDE function 604; and an application program interface with other OS function 606. These parts can be (eg) interwoven in the same software or provided as two or more discrete pieces of software.

Some applications, such as application 608a (1) shown in Figure 11, may be "VDE-aware" and therefore have direct access to both of these parts of API 682. Figure 11A shows an example of this. A "VDE-aware" application may include an explicit call to ROS602, for example, requesting the creation of a new VDE object 300, weighing the use of the VDE object, and storing the information in a VDE-protected format. Thus, a "VDE-aware" application can initiate (improve and / or extend in some cases) the VDE functionality provided by ROS602. In addition, the "VDE-aware" application eliminates the more direct interface between the user and ROS602 (eg, the "pop-up" display provided by the user notification / exception interface 686, unless suppressed, and instead the application and Can be provided (by providing a more "seamless" interface that integrates ROS messages).

Other applications, such as application 608b shown in Figure 11B, may not be "VDE aware" and therefore may not "know" how to directly access the interface to VDE feature 604 provided by API 682. Absent. To provide this, the ROS 602 may include a "redirector" 684 that allows such a "non-VDE-aware" application 608b to access VDE objects 300 and function 604. The redirector 684 in the preferred embodiment translates an OS call directed to "another OS function" 606 into a call to "VDE function" 604. As a simple example, the redirector 684 intercepts the "open file" call from application 608b, determines if the file to be opened is contained within the VDE container 300, and is included. Makes the appropriate VDE function call to file system 687 to open the VDE container (and in some cases determines the file name that can be stored in VDE object 300 and the control structure associated with VDE object 300. Raise an event to HPE655 and / or SPE503 to establish and register with VDE object 300 etc.). In this example, without the redirector 684, non-VDE-aware applications such as the 608b can only access part of API 682, which provides an interface with other OS features 606, and therefore no VDE features. ..

This "translation" feature of the Redirector 684 provides "transparency". This is a way to "transparent" the VDE feature to application 608 (b) without the complexity and details associated with making one or more calls to VDE feature 604. To be provided in. This "transparency" characteristic aspect of ROS602 has at least two important advantages: (a) Allows applications not specifically written for VDE Function 604 (Non-VDE Recognized Applications) to access important VDE functions; and (b) Reduce the complexity of the interface between the application and ROS602.

The second advantage (reduced complexity) is that it makes it easier for application authors to create applications, so even if it is a "VDE-aware" application 608a (2), it is one of the calls that call VDE function 604. The part may be requested at the "other OS features" call level and designed to be "translated" into a VDE feature call by the redirector 684 (in this case, the redirector 684 is considered part of API 682). FIG. 11C illustrates this. Other calls that call VDE function 604 can be passed directly without translation by the redirector 684.

Revisiting Figure 10, the ROS620 also forwards and / or receives one or more real-time data feeds 694 (which can be done, for example, via cable 628), and also one or more such data. Similar to the transparency obtained by the redirector 684 on this type of information, providing a "translation" feature for real-time data sent and / or received to the electronic device 600 while properly rooting the feed. It may include an "interceptor" 692 that imparts "transparency" (and / or may generate one or more real-time data feeds). Safety ROS components and component assemblies As mentioned above, the ROS 602 in the preferred embodiment is a component-based architecture. ROS VDE function 604 may be based on a compartmentalized, independently loadable and executable "component assembly" 690. These component assemblies 690 can be delivered independently and safely. The component assembly 690 provided by the preferred embodiment includes code and data elements that can be delivered independently. Therefore, each component assembly 690 provided by the preferred embodiment comprises an independently and safely deliverable element that can be communicated between VDE-safe subsystems using VDE-safe communication technology.

These component assemblies 690 are the basic functional units provided by ROS602. Component assembly 690 runs to perform operating system or application tasks. Thus, one component assembly 690 can be considered part of the ROS operating system 602 and another component assembly can be considered an "application" that runs with the support of the operating system. In any system that incorporates "applications" and "operating systems," the boundaries between these aspects of the entire system can be ambiguous. For example, commonly used "application" features (such as determining the structure and / or other attributes of the content container) can be incorporated into the operating system. In addition, "operating system" features (such as task management or memory allocation) can be modified and / or replaced by new applications. In a preferred embodiment of ROS 602, the component assembly 690 requires a general thread to perform the activation intended by the user, which may be "application-like" and in some cases. It is to provide functions that are "operational system-like" in some cases.

The component 690 is preferably designed to be easily separable and independently loadable. The ROS602 puts these elements together to form a viable component assembly 690 before loading and running the component assembly (eg, in a safe operating environment such as SPE503 and / or HPE655). ROS602 provides an element identification and query mechanism that contains the information needed to automatically and safely configure elements into component assembly 690 before and / or during execution.

The ROS602 application structure and control parameters used to form the component assembly 690 may be provided by different parties. The components forming the component assembly 690 can be delivered at different times and / or by different parties because they can be delivered independently and safely (delivery can be performed in the local VDE safety subsystem, ie, modifications. Requests through the use of such a secure subsystem of control information by a chain of content control information that handles participants for the preparation of a controlled set of control information constitutes an independent and secure delivery). For example, a content creator may create a ROS602 application that defines the circumstances required to license the content contained in the VDE object 300. This application can query structures provided by other parties. Such queries use, for example, the content creator structure to weigh user work; define the credit budget that must be in the control structure for the financial part of the content distribution transaction, for example. It can take the form of a control path that uses a configuration created / owned by a financial provider to handle credit value that must be done by an authorized person, establishing audit processing, etc.) .. As another example, a distributor may price one user more favorably than another by delivering different data elements that specify prices to different users. This attribute, which supports multi-party control information that can be delivered securely and independently, is an e-commerce, ie, collection of independent parties such as content creators, other content providers, financial service providers, and / or users. ) Is required to enable the definition of content and / or device control information sets that indicate the requirements.

In a preferred embodiment, the ROS 602 constitutes a component assembly 690 of elements that can be safely and independently delivered based in part on content parameters (eg, objects, users). Thus, for example, ROS602 may safely configure different elements together and form in different component assemblies 690 for different users performing the same task on the same VDE object 300. Similarly, ROS602 forms different component assemblies 690 by configuring different sets of elements that can contain one or more of the same components, i.e., can be reused, for the same user performing the same task on different VDE objects 300. obtain.

The component assembly organization provided by ROS602 is "in that the component assembly 690 can contain one or more component" subassemblies "that are self-loadable and executable component assemblies 690. It is "recursive". These component "subassemblies" can also consist of one or more component "subassemblies". In the general case, component assembly 690 may include N-level component subassemblies.

Thus, for example, component assembly 690 (k) may include component subassembly 690 (k + l). Also, the component subassembly 690 (k + l) may include the component subassembly 690 (3), and so on, up to the N level subassembly 690 (k + N). The ability of ROS602 to build component assembly 690 from other component assemblies is significant, for example, in terms of code / data reusability and the ability to allow different parties to manage different parts of the entire component. Provide benefits.

Each component assembly 690 in a preferred embodiment comprises a different component. 11D-11H are abstract depictions of the various different components that can be configured to form the component assembly 690 (k) shown in FIG. 11I. These similar components can be configured in different ways (eg, more or less components) to form different component assemblies 690 that provide completely different functional effects. FIG. 11J is an abstract depiction of the same components being combined together in different ways (eg, adding components) to form a different component assembly 690 (j). The component assemblies 690 (k) and 690 (j) each contain a common feature 691 that mates with the "channel" 594 defined by ROS602. This "channel" 594 combines the component assembly 690 and interfaces with the (remaining) ROS 602.

ROS602 safely produces component assembly 690. As visually shown in Figures 11I and 11J, different elements, including component assembly 690, should only "fit" as intended by the VDE participant who created the element and / or identified the component assembly. Can be. ROS602 includes safety protection that prevents non-approved persons from modifying the element and non-approving persons from replacing the element. It is conceivable that a non-approved person will create a new element with the same "shape" as one of the elements shown in Figures 11D-11H and attempt to replace the original element with that new element. One of the elements shown in Figure 11H shall establish the price for using the content in the VDE object 300. If an unapproved person could replace his "price" element with the price element intended by the VDE content distributor, he would price zero instead of the price the content distributor is trying to charge. be able to. Similarly, if an element has an electronic credit card established, one can charge his or her spending to another (or non-existent) credit card if it can be replaced with a different element. It can have serious consequences. These are just a few examples of the importance of ROS 602 to ensure that a particular component assembly 690 is safely formed. ROS602 provides a wide range of protection against many "threats" regarding the safe handling and execution of component assembly 690.

In a preferred embodiment, the ROS 602 constitutes a component assembly 690 based on the following types of elements: Permission record ("PERC") 808; Method "core" 1000; Load module 1100; Data elements (eg, user data elements (UDE) 1200 and method data elements (MDE) 1202); and Other component assembly 690.

Briefly, the PERC808 provided by the preferred embodiment is a record corresponding to the VDE object 300 that identifies to the ROS602, and in particular the element ROS are combined together to form the component assembly 690. Thus, PERC808 essentially contains a "list of configuration instructions" or "plans" that specify which elements and ROS602 are configured together to form a component assembly and how the elements are connected together. .. The PERC808 may contain data or other elements that are part of the component assembly 690.

PERC808 may query one or more method "core" 1000N. The method "core" 1000N can define the basic "method" 1000 (eg, "control", "billing", "weighing", etc.).

In a preferred embodiment, the "method" 1000 is a set of basic instructions related to the operation of one or more electronic devices 600, and information related to the basic instructions, the context of use in implementation and / or preparation for implementation. Provide data, requirements and / or relationships. The basic instructions may include, for example: C Types of machine code commonly used in computer programming; pseudocode used by interpreters or other instruction processing programs running on the computer; C A sequence of electronically shown logical actions used with electronics 600; C or other electronic representation of instructions, source code, object code, and / or pseudocode, as the term is commonly understood in the art.

Information related to a basic instruction may include, for example, data inherently associated with the basic instruction, such as an identifier for a combined basic instruction, and essential data, addresses, constants, and the like. The information may also include, for example, one or more of the following: C Information that identifies relevant basic instructions and essential data for access, correlation, and / or validation purposes; C Required and / or optional parameters for the use of basic instructions and essential data; C Information that defines relationships with other methods; C Data elements that can contain data values, information fields, etc .; Information that identifies and / or defines relationships between C data elements, basic instructions, and / or essential data; C Information that identifies the relationship with external data elements; C Information that, if present, identifies relationships such as internal and external data elements, methods; and C If necessary, additional instructions and / or additional information required for the action or attempt to complete the basic instructions and essential data intended by the user of the method containing the essential data.

Such information related to the method, in part or in whole, may be stored separately from the basic instructions and essential data. Even if these components are stored separately, the method can still provide other information, as well as basic instructions, regardless of whether one or more sets of basic instructions and essential data are accessible at a given point in time. And one or more sets of essential data, the latter containing other information to refer to one or more sets of basic instructions and essential data, and get encompassed.

The method core 1000'may be parameterized by the "event code" to allow different methods to respond to different events. For example, the METER method can store usage information in a metric data structure and respond to "use" events. The same METER method can report the metric data structure to the VDE information exchange or other VDE participants and respond to "management" events.

In a preferred embodiment, the method core 1000'can "contain" one or more "load modules" 1100 and one or more data elements (UDE1200, MDE1202), either explicitly or by reference. In a preferred embodiment, the "load module" 1100 is part of a method that reflects basic instructions and essential data. The load module 1100 in a preferred embodiment may include executable code and may include data elements associated with the executable code (DTD 1108). In a preferred embodiment, the load module 1100 gives program instructions that are actually "executed" by the hardware to perform the processing defined by the method. Load module 1100 may include or reference other load modules.

The load module 1100 in a preferred embodiment is modular and "code pure" so that individual load modules can be re-entered and reused. Because components 690 can be updated dynamically, they may be individually addressed within the global public namespace. In view of these design goals, the load module 1100 is preferably a small, individually named, addressable code (and code) pure module. A single method can provide different load modules 1100 that perform the same or similar functionality on different platforms, making the method resizable and / or portable across a wide range of different electronics.

The UDE1200 and MDE1202 may store data for input to or from executable component assembly 690 (or data describing such inputs and / or outputs). In a preferred embodiment, the UDE1200 can be user-dependent and the MDE1202 can be user-independent.

The component assembly example 690 (k) shown in Figure 11E includes method cores 1000', UDE1200a and 1200b, MDE1202, load modules 1100a-1100d, and component assembly 690 (k + 1). As mentioned earlier, PERC808 (k) defines, among other things, "configuration instructions" for component assembly 690 (k) and partially or wholly describes some of the components configured to create component assemblies. Can be included in or referenced in.

One of the load modules 1100b shown in this example itself contains multiple load modules 1100c and 1100d. Some load modules in this example (eg, 1100a, 1100d) include one or more "DTD" data elements 1108 (eg, 1108a, 1108b). The "DTD" data element 1108 can be used, for example, to signal the load module 1100a of the data elements contained in the MDE1202 and / or UDE1200a and 1200b. In addition, the DTD1108 is used as part of an application that is used to inform the user of the information needed and / or manipulated by one or more load modules 1100, or other component elements. obtain. Such application programs may also include functionality for creating and / or manipulating UDE1200, MDE1202, or other component elements, subassemblies, and so on.

The components within component assembly 690 can be "reused" to form different component assemblies. As mentioned earlier, FIG. 11F is an abstract depiction showing an example of the same components used to construct the reused component assembly 690 (k) (eg, different PERC808 (l)). Form a different component assembly 690 (l) (with some additional components identified by different sets of "configuration instructions" provided by. Although the component assembly 690 (l) is formed from the same components as some of the components used to form the component assembly 690 (k), these two component assemblies do completely different things. It can be done with different methods.

As mentioned above, the ROS 602 provides several layers of safety to ensure the safety of the component assembly 690. One of the key safety layers is to ensure that a particular component assembly 690 is formed, loaded and executed only in a safe execution space, for example installed within the SPU500. The components 690 and / or the elements containing them may be stored on external media encrypted using the key generated by the local SPU500 and / or the key provided by the distributor.

ROS602 also provides tagging and ordering schemes that can be used within the loadable component assembly 690 to detect tampering due to replacement. Each element, including component assembly 690, can be loaded into the SPU500, decrypted using the encryption / decryption engine 522, and then tested / compared to ensure that the appropriate elements were loaded. Several independent comparisons can be used to ensure that there were no unapproved substitutions. For example, public and private copies of element IDs can be compared to ensure they are the same and prevent significant replacement of elements. In addition, validation / correlation tags stored under the encryption layer of loadable elements can be compared to ensure that they match one or more tags provided by request processing. .. This prevents the use of non-approved information. As a third protection, the device assignment tag (device) stored under the encryption layer of the loadable element to ensure that it matches the expected corresponding tag value of the SPU500. The assigned tag) (eg sequence number) is checked. This prevents replacement of old elements. Typically, validation / correlation tags are only passed to safety wrappers to prevent this information from being exposed to plain text outside the SPU500.

The ROS602 safety component-based architecture has significant advantages. For example, it allows a limited resource execution environment as provided by the relatively low cost SPU500. It also offers a very high level of configurability. In fact, ROS602 allows for an almost infinite variety of content types, content provider objectives, transaction types and client requirements. In addition, the ability to dynamically configure independently deliverable components at run time based on specific objects and users provides a high degree of flexibility and facilitates distributed databases, processing, and execution environments. Or enable.

One aspect of the benefits of the component-based architecture provided by ROS602 concerns the ability to "stage" functionality and capabilities over time. Once designed, implementing ROS602 is a finite task. Many aspects of functionality can remain undeveloped until the market entity requires the implementation of the corresponding VDE application functionality. As a result, the investment and complexity of initial product implementation can be reduced. The process of "surface" the full range of capabilities for authorization, authentication, and artificial intelligence applications provided by ROS602 can be realized over time. Also, the functionality of the already designed ROS 602 can be constantly modified or enhanced to meet the needs or requirements of the modification. A more detailed discussion of the rights operating system 602 architecture FIG. 12 shows an example of the detailed architecture of ROS602 shown in FIG. ROS602 may include a file system 687 that includes a commercial database manager 730 and an external object container 728. Commercial database manager 730 may maintain safety database 610. Object container 728 stores VDE object 300, provides access to VDE object 300, and / or maintains VDE object 300.

FIG. 12 also shows that ROS602 may provide one or more SPE503 and / or one or more HPE655. As mentioned earlier, the HPE655 "emulates" an SPU500 device, and such an HPE655 replaces (or in addition to) the physical SPU500 for systems that require higher throughput. Can be integrated. Some security can be extinguished because the HPE655 is protected by operating system security and may not be able to provide reliable safeguards. Therefore, in a preferred embodiment, at least for more secure applications, all safety processes are within the physical SPU500 rather than the HPE655, which uses software running elsewhere in the electronics 600. It should be carried out within SPE503, which has a run space.

As mentioned earlier, the three basic components of ROS602 are kernel 680, remote procedure call (RPC) manager 732 and object switch 734. These components, and how they interact with the rest of the ROS 602, are described below. Kernel 680 Kernel 680 manages the basic hardware resources of electronic device 600 and controls the basic tasking provided by ROS602. The kernel 680 in a preferred embodiment may include a memory manager 680a, a task manager 680b, and an I / O manager 680c. Task manager 680b initializes executable tasks and / or manages their initialization and may schedule them to be executed by the processor on which ROS602 is running (eg CPU654 shown in Figure 8). .. For example, Task Manager 680b may include or accompany a "bootstrap loader" that loads other parts of ROS602. Task manager 680b can manage all tasks related to ROS602, including tasks with application program 608. The memory manager 680a manages the allocation, delocation, sharing, and / or use of memory in electronics 600 (eg, RAM656 shown in Figure 8) and is required for electronics and / or related applications, for example. Can provide virtual memory capabilities. The I / O Manager 680c can manage all of the inputs to and from the ROS 602 and interact with drivers and other hardware managers that provide communication and interaction with physical equipment. RPC Manager 732 The ROS 602 in a preferred embodiment is designed around a "service-based" remote procedure call architecture / interface. All functions performed by ROS602 may use this common interface to request services and shared information. For example, SPE503 provides processing for one or more RPC-based services. In addition to supporting the SPU500, the RPC interface enables dynamic integration of external services and provides an OSIan array of configuration options using existing operating system components. The ROS602 also communicates with external services via the RPC interface to seamlessly provide distributed and / or remote processing. In the case of minor changes to ROS602, the IPC protocol, which passes a relatively simple message, can be used to save resources. This may limit the configuration of the ROS602 service, but this possible limitation may be tolerated by some electronic devices.

The RPC configuration does not know or specify in the call processing where the service is physically delivered, which system or device serves the request, or how the service request is fulfilled. Allows the service to be called / requested. This feature supports families of services that can be scaled and / or customized for a particular application. Service requests can be continued and serviced by different processors and / or different sites as easily as they could be continued and serviced by the local service system. In a preferred embodiment, the same RPC interface is used by ROS602 to request services inside or outside the operating system, so that the distributed and / or request for remote processing is on top of it. (overhead) Virtually no additional operating system is required. Remote processing is easily and easily integrated as part of the same service call used by ROS602 to request locally based services. In addition, the use of a standard RPC interface (RSI) allows the ROS602 to be modularized, allowing different modules to present a standardized interface with the rest of the operating system. Such a modular and standardized interface allows different sellers / operating system programmers to independently create different parts of the operating system and flexibly update and / or platform-based ROS602 functionality. / Or allow it to be modified.

RPC Manager 732 manages the RPC interface. RPC Manager 732 receives a service request from a service requester in the form of one or more "remote procedure calls" (RPCs) and routes the service request to a service provider that can service the request. For example, if rights operating system 602 receives a request from a user application via user API 682, RPC Manager 732 may route the service request to the appropriate service via the "RPC Service Interface" ("RSI"). .. The RSI is the interface between the RPC Manager 732, the service requester, and the resources that accept and service requests.

The RPC interface (RSI) is used in a preferred embodiment for some major ROS602 subsystems.

The RPC services provided by ROS 602 in a preferred embodiment are divided into sub-services, i.e. individual cases of specific services, each of which can be individually tracked by the RPC manager 732. This mechanism allows a large number of specific service cases on relatively high throughput systems while maintaining a common interface across the spectrum of implementation. The subservice concept extends to support a large number of processors, a large number of SPE503s, a large number of HPE655s, and a large number of communication services.

The preferred embodiment of ROS 602 provides the following RPC-based service providers / requesters, each with an RPC interface or "RSI" that communicates with the RPC Manager 732: SPE device driver 736 (this SPE device driver is connected to SPE503 in a preferred embodiment); HPE device driver 738 (this HPE device driver is connected to the HPE 738 in a preferred embodiment); Notification Service 740 (This notification service is connected to the user notification interface 686 in a preferred embodiment); API Service 742 (This API Service is connected to User API 682 in a preferred embodiment); Redirector 684; Safety database (file) manager 744 (this safety database or file manager 744 may connect to and interact with commercial database manager 730 and safety file 610 through cache manager 746, database interface 748, and database driver 750); Name Service Manager 752; Output Management Object Manager 754; Input Management Object Manager 756; Gateway 734 to Object Switch 734 (this is the path used for direct communication between RPC Manager 732 and Object Switch 734); and Communication manager 776.

The types of services provided by HPE655, SPE503, User Notification 686, API742, and Redirector 684 have already been mentioned above. Below is a brief description of the types of services provided by OS resources 744, 752, 754, 756, and 776: Safety database manager 744 serves requests for access to safety database 610; Name Service Manager 752 serves requests related to user, host, or service ID; Output Management Object Manager 754 serves requests related to output management objects; Input Management Object Manager 756 serves requests related to Input Management objects; and Communication manager 776 serves requests related to communication between electronic device 600 and the outside world. Object switch 734 Object switch 734 handles, controls, and communicates with VDE object 300 (both locally and remotely). In a preferred embodiment, the object switch may include the following elements: Stream router 758; Real-time stream interface (which can be connected to real-time data feed 694) 760; Time-dependent stream interface 762; Intercept 692; Container Manager 764; One or more routing tables 766; and Buffering / storage 768.

The stream router 758 routes from / to the "real-time" and "time-dependent" data streams handled by the real-time stream interface 760 and the time-dependent stream interface 762, respectively. The intercept 692 intercepts an I / O request with a real-time information stream, such as a real-time feed 694. The routing performed by the stream router 758 can be determined by the routing table 766. The buffering / storage 768 provides temporary store-and-forward, buffering, and related services. Container Manager 764 (typically with SPE503) can process VDE objects 300, such as constructing, deconstructing, and locating parts of an object.

The object switch 734 communicates with other parts of the ROS 602 via the object switch interface (OSI). In a preferred embodiment, the object switch interface may resemble, for example, an interface for Unix® sockets. Each "OSI" interface shown in Figure 12 is capable of communicating with the object switch 734.

ROS602 includes the following object switch service providers / resources, each capable of communicating with object switch 734 via "OSI": Output Management Object Manager 754; Input Management Object Manager 756; Gateway 734 (RPC Manager 732 translates RPC calls into object switch calls and vice versa so that they can communicate with object switch 734 or other elements with OSI, for example to provide and / or request services. ); External Service Manager 772; Object Submission Manager 774; and Communication manager 776.

Simply put Object Container Manager 770 provides services related to access to Object Container 728; External Service Manager 772 provides services related to external requests and receipts, such as from network resources or other sites; The Object Submission Manager 774 provides services related to how the user application interacts with the Object Switch 734 (the Object Submission Manager provides an interface to the application program 608, so the User API 682 Can be considered part of); and Communication manager 776 provides services related to communication with the outside world.

In a preferred embodiment, the communication manager 776 may include a network manager 780 and a mail gateway (manager) 782. The mail gateway 782 may include one or more mail filters 784, for example, to automatically route VDE-related mail between the object switch 734 and the external mail service. The external service manager 772 may interface with the communication manager 776 via the service transport layer 786. The service transport layer 786a may allow the external service manager 772 to communicate with external computers and systems using various protocols managed using the service transport layer 786.

The characteristics of the various subsystems of ROS680 shown in FIG. 12 and the interfaces to them are described in detail below. RPC Manager 732 and its RPC service interface As mentioned above, the basic system services provided by ROS602 are called by using the RPC Service Interface (RSI). This RPC service interface provides a comprehensive, standardized interface for the different service systems and subsystems provided by ROS602.

RPC Manager 732 routes the service requested by RPC to the appropriate RPC service interface. In a preferred embodiment, upon receiving the RPC call, the RPC manager 732 determines one or more service managers to serve the request. RPC Manager 732 then routes the service request to the appropriate service (via the RSI associated with the service) for work by the appropriate service manager.

For example, if the SPE503 serves the request, the RPC manager 732 routes the request to RSI736a, which passes the request to the SPE device driver 736 and proceeds to SPE. Similarly, if HPE655 serves the request, RPC Manager 732 routes the request to RSI738a and proceeds to HPE. In one preferred embodiment, the SPE503 and HPE655 may provide essentially the same service so that the RSI736a and 738a are different cases of the same RSI. Once a service request is received by SPE503 (or HPE655), SPE (or HPE) typically dispatches the request internally using its own internal RPC manager (discussed briefly later). Processing within SPE503 and HPE655 can also generate RPC requests. These requests are processed internally by SPE / HPE and, if not internally serviceable, passed out of SPE / HPE for dispatch by RPC Manager 732.

Remote (and local) procedure calls can be dispatched by RPC Manager 732 using the "RPC Service Table". The RPC service table shows where requests for a particular service are routed for processing. Each row of the RPC service table in the preferred embodiment contains a service ID, a service location, and an address to which control is passed to service the request. The RPC service table can also contain control information that indicates which case of the RPC dispatcher controls the service. Both the RPC manager 732 and the installed SPE503 and HPE655 can have a symmetric copy of the RPC service table. If the RPC service is not found in the RPC service table, it is either rejected or passed to the external service manager 772 for remote service.

If RPC Manager 732 finds a row corresponding to the request in the RPC service table, it can dispatch the request to the appropriate RSI. The receiving RSI accepts the request from RPC Manager 732 (which may have looked-up the request in the RPC service table) and processes the request according to the internal nature associated with the particular service.

In a preferred embodiment, the RPC service interface supported by RPC Manager 732 is to support add-on service modules developed by third-party sellers and to make ROS 602 easier to program and scale. Can be standardized and published in. The RSI of the preferred embodiment follows the DOS and Unix® device driver model for block devices almost entirely so that common code can be developed for many platforms with minimal effort. An example of one possible set of entry points is listed in the table below.

<tables num="1"><img file="JP4995980B2_D0001.tif" /></tables>

Road In a preferred embodiment, the service (and the associated RSI presented to RPC Manager 732) can be activated during boot by an installation boot process that issues an RPC LOAD. This process reads the RPC service table from the configuration file, loads the service module if it is run time loadable (as opposed to the kernel linked device driver), and then for the service. Call the LOAD entry point. A successful return from the LOAD entry point indicates that the service is properly loaded and ready to accept the request. RPC LOAD call example: SVC LOAD (long service id) This LOAD interface call is called by RPC Manager 732 during rights operating system 602 initialization. Allows the service manager to load any dynamically loadable component and initialize the equipment and memory required by the service. The service number when the service is loaded is passed as a service id parameter. In a preferred embodiment, the service returns 0 if the initialization process completes successfully, and returns an error number if any error occurs. mount Once the service is loaded, it may not work perfectly for all subservices. Some subservices (eg, communication-based services) may require the establishment of additional connections or additional modules to be loaded. If the service is defined as "mountable," RPC Manager 732 calls the MOUNT subservice entry point with the requested subservice ID prior to opening the subservice example. RPC MOUNT call example: SVC MOUNT (long service id, long subservice id, BYTE^* buffer) This MOUNT interface call directs a service and prepares a specific subservice. This may include networking, communications, other system services, or services related to external resources. The service id, and subservice id parameters can be specific to the particular service requested. A buffer parameter is a memory address that references a control structure that is appropriate for a particular service. open Once the service is loaded and "mounted", certain cases of the service can be "opened" for use. By "opening" a service case, memory can be allocated to store control and status information. For example, in a BSD socket-based network connection, a LOAD call initializes software and protocol control tables, a MOUNT call identifies network and hardware resources, and OPEN actually opens the socket for remote installations.

Some services, such as the commercial database manager 730 that underlies secure database services, may not be "mountable." In this case, the LOAD call can connect to the database manager 730 and ensure that the record is readable. The OPEN call can create an example of the internal cache manager 746 for recording various classes. RPCOPEN call example: SVC OPEN (long service id, long subservice id, BYTE ^*buffer, int (^*receive) (long request id)) This OPEN interface call directs a service to open a particular subservice. The service id and subservice id parameters are specific to the particular service requested, and the buffer parameter is the memory address that references the appropriate control structure for the particular service.

An optional receiving parameter is the address of the notification callback function that is called by the service as soon as the message is ready for the service to retrieve it. One of the calls to this address is made for each input message received. If the caller passes NULL to the interface, the software will not issue a callback for each message. Close, unmount, and unload The opposite of OPEN, MOUNT, and LOAD calls are CLOSE, UNMOUNT, and UNLOAD. All of these interface calls return any allocated resources to ROS602 (eg, Memory Manager 680a). RPC CLOSE call example: SVC CLOSE (long svc handle) This LOAD interface call closes the open service "handle". A service "handle" describes a service and subservice that the user wants to close. If the CLOSE request is successful, the call requests 0 (no handle) becomes disabled), otherwise it returns the error number. RPC UNLOAD call example: SVC UNLOAD (void) This UNLOAD interface call is called by RPC Manager 732 during shutdown of rights operating system 602 or resource reallocation. Any open connection closes the service, flushes the buffer, and allows any operating system resource that could be allocated to be released. The service returns 0. RPC UNMOUNT call example: SVC UNMOUNT (long service id, long subservice id) This UNMOUNT interface call directs the service to deactivate a particular subservice. service The id and subservice id parameters are specific to the particular service requested and must be premounted using the SVC MOUNT () request. The call releases all system resources associated with the subservice prior to its return. Read and write READ and WRITE calls provide the basic mechanism for sending information to a mounted and opened service and receiving a response. For example, a service has a request written in the form of an RPC request, and when the response comes out, it can be read by the RPC manager 732. RPC READ call example: SVC READ (long svc handle, long request id, BYTE ^*buffer, long size) This READ call reads the message response from the service. The svc handle and request id parameters uniquely identify the request. The result of the request is stored in the user-specified buffer until its limit bytes (size bytes) are reached. If the buffer is too small, the first limit byte of the message is stored in the buffer and an error is returned.

If the message response is returned exactly to the caller's buffer, the function returns 0. Otherwise, an error message will be returned. RPC WRITE call example: SVC write (long service id, long subservice id, BYTE ^*buffer, long size, int (^*receive) (long request id)) This WRITE call writes a message to the service and subservice specified in the service id / subservice id parameter pair. The message is buffered (and usually fits the VDE RPC message format) and has a limit byte length. The function returns the request id for the message (if its delivery is accepted) or returns the error number. If the user identifies the receive callback function, all messages related to the request are sent to the request specific callback routine instead of the generated message callback. Input / output control IOCTL (Input / Output Control) calls provide a mechanism for querying and controlling the status of loaded services. Each service type responds to specific generic IOCTL requests, all required class IOCTL requests, and service-specific IOCTL requests. RPC IOCTL call example: ROI SVC IOCTL (long service id, long subservice id, int command, BYTE^*buffer) This IOCTL feature provides a generalized control interface for RSI. The user specifies the service id parameter and the subservice id parameter that he wants to control. Specifies the control command parameters and the buffer in which the command parameters can be written / read. Below is an example of a list of commands and the appropriate buffer structure.

<tables num="2"><img file="JP4995980B2_D0002.tif" /></tables>

* * * * * We have described the comprehensive RPC service interface provided by the preferred embodiments. The following description relates to specific examples of services provided by ROS602. SPE device driver 736 The SPE device driver 736 provides an interface between ROS602 and SPE503. Since the SPE503 in the preferred embodiment is run within the boundaries of the SPU500, one aspect of this device driver 736 is to provide low-level communication services with the SPU500 hardware. Another aspect of the SPE device driver 736 is to provide the RPC Service Interface (RSI) 736a, especially to the SPE503 (this same RSI can be used to communicate with the HPE655 via the HPE device driver 738). ..

The SPE RSI736a and driver 736 isolate the calling process within ROS602 (or outside ROS) from the detailed services provided by SPE503 by providing a set of basic interface points that provide a concise feature set. This has several advantages. For example, a full line of scaled SPU500 that provides common functionality to the outside world but can differ in detailed internal structure and architecture is acceptable. The characteristics of the SPU500, such as the amount of memory resident in the device, the processor speed, and the number of services supported within the SPU500, can be determined by a particular SPU manufacturer and can differ between one SPU configuration and the other anyway. To maintain compatibility, the SPE device drivers 736 and RSI736a provide compliance with the basic common RPC interface standard that "hides" the detailed configuration differences of the SPU500 and / or SPE503 that can be supported.

To provide such compatibility, the SPE RSI736a in the preferred embodiment follows a simple block-based standard. In a preferred embodiment, the SPE RSI736a can be modeled after the packet interface of a network Ethernet® card. This standard closely models the block mode interface characteristics of the SPU500 in preferred embodiments.

SPE RSI736a allows RPC calls from RPC Manager 732 to access certain services provided by SPE736. To achieve this, SPE RSI736a provides a set of "service notification address interfaces". They provide an interface to the outside world for the individual services provided by SPE503. By pointing the RPC call to the SPE RSI736a and identifying the corresponding "service known address" in the RPC call, any calling process within ROS602 can access the services provided to these SPEs. The identified "service known address" causes the SPE503 to internally route an RPC call to a particular service within the SPE. The following is a list of examples of SPE service failures for which individual service recognition addresses can be provided: Channel service manager Authentication Manager / Secure Communication Manager Safety database manager The channel service manager is the primary service provider and the access point to SPE503 for the remaining ROS602. Event processing is primarily managed by this service (from a processing perspective outside of SPE503), as described below. Authentication Manager / Secure Communication Manager provides login / logout services for ROS602 users and manages (typically encrypted or protected) communications related to component assembly 690, VDE object 300, etc. Can provide direct service for. Information display requests (eg, financial budget balances) may be provided by a direct service request to the safety database manager within SPE503. The Authentication Manager / Security Communication Manager and Security Database Manager cases, even if available, may provide only a subset of the information and / or capabilities available for the processing running within the SPE503. As mentioned above, most (and possibly all) service requests that enter the SPE are routed to the channel service manager for processing. Most control structures and event-handling logic involve component assembly 690 under the control of the channel service manager, as described in more detail below.

The SPE503 must be accessed via the associated SPE driver 736 in this example. Generally, calls to the SPE driver 736 are made in response to RPC calls. In this example, the SPE driver RSI736a may translate an RPC call directed to control or verify information about the SPE driver 736 into a driver call. The SPE driver RSI736a may pass an RPC call directed to the SPE503 with the driver 736 via the SPE.

The following table shows an example of the SPE device driver 736:

<tables num="3"><img file="JP4995980B2_D0003.tif" /></tables>

Below is a more detailed example of each SPE driver call listed in the table above. Example of "SPE information" driver call: SPE info (void) This feature returns a pointer to the SPE INFO data structure that defines the SPE device driver 736a. This data structure may provide specific information about the SPE device driver 736, RSI736a, and / or SPU500. An example of the SPE INFO structure is shown below:

<tables num="4"><img file="JP4995980B2_D0004.tif" /></tables>

SPE "Initialization Interface" Driver Call Example SPE initialize interface (int (fcn)^*receiver) (void)) Unless the destination service is over-ridden using the set notify () call, the receiver function passed by the parameter is called for every packet received from the SPE503. The receiving function allows ROS602 to identify the format for packet communication between RPC Manager 732 and SPE503.

In a preferred embodiment, this feature returns "0" if the interface initialization succeeds and returns nonzero if the interface initialization fails. If the function fails, the code explaining the reason for the failure is returned as a function value. Example of SPE "termination interface" driver call SPE terminate interface (void) In a preferred embodiment, this feature shuts down the SPE driver 736, clears all notification addresses, and terminates all outstanding requests between the SPE and the ROS RPC manager 732. This feature also resets the SPE503 (eg, by a warm reboot of the SPU500) after all requests have been resolved.

The termination of driver 736 is done by ROS602 when the operating system begins to shut down. Also, if SPE503 and ROS602 are out of sync so that all processing in the SPE must be reset to the known state, it will be necessary to issue a call. SPE "Reset Interface" driver call example: SPE reset interface (void) This feature resets driver 736, terminates all pending requests between SPE503 and ROS RPC Manager 732, and clears all stats counts. This feature does not reset the SPU500, but simply restores the driver 736 to a known stable state. SPE "Get Statistics" driver call example: SPE get stats (long service id) This feature generally returns statistics for a particular service notification interface or SPE driver 736. This feature returns a pointer to a stats buffer that contains NULL if there are no stats (either because the interface has not been initialized or because the receiver address has not been identified). An example of an SPE STATS structure can have the following definitions:

<tables num="5"><img file="JP4995980B2_D0005.tif" /></tables>

If the user identifies the service ID, the statistics associated with the packets sent by that service are returned. If the user specifies 0 as a parameter, total packet statistics for the interface are returned. SPE "Clear Statistics" driver call example: SPE clear stats (long sevice id) This feature clears the statistics associated with the identified SPE service id. If the service id is not specified (that is, the caller passes it as 0), the global statistics are cleared. This feature returns 0 if the stats are cleared successfully and gives an error number if an error occurs. SPE "Set Notification Address" driver call example: SPE set notify (long service id, int (fcn)^*receiver) (void)) This feature sets a notification address (receiver) for a particular service. If the notification address is set to NULL, the SPE device driver 736 sends a packet notification to the specified service to the default notification address. SPE "Get Notification Address" driver call example SPE get notify (long service id) This feature returns the notification address associated with the name service, or NULL if a specific notification address is not specified. SPE "Send Packet" driver call example: send pkt (BYTE)^*buffer, long size, int (far^*receive) (void)) This feature sends packets stored in a "length" size buffer. Send 0 if the packet was sent successfully, otherwise send the error code associated with the failure. Redirector Service Manager 684 The Redirector 684 is primarily used when ROS602 is provided by an "add-on" to an existing operating system, or, as explained earlier, when "transparent" operation is desired for some VDE functionality. It is part of the software. In one embodiment, kernel 680, part of communication manager 776, file system 687, and part of API service 742 are DOS, Windows®, UNIX®, Macintosh®. It can be part of an existing operating system such as System, OS9, PSOS, OS / 2, or other operating system platforms. The rest of the ROS602 subsystem shown in Figure 12 can be provided as "add-ons" to existing operating systems. Once these ROS subsystems are supplied and "add-on", the integrated whole contains the ROS 602 shown in Figure 12.

In this type of integration description, ROS602 continues to be supported by the existing OS kernel 680, but supplements (or replaces) many of its features by providing additional add-on parts, such as a virtual memory manager. Can be.

Also, in this integration description, an add-on part of API service 742 that easily integrates with existing API services is provided to support VDE function calls. The existing API service with integrated add-on parts supports an improved set of operating system calls, including both calls to VDE feature 604 and calls to non-VDE feature 606 (see Figure 11A). The add-on portion of API service 742 can translate VDE feature calls into RPC calls for routing by RPC Manager 732.

The ROS602 may provide "add-ons" and / or alternatives that can easily integrate with the standard communications manager 776 provided by existing operating systems. The redirector 684 may provide this integrated functionality.

This leaves the requirement to integrate ROS602 with the existing file system 687. The Redirector 684 provides this integrated functionality.

In this integrated description, the existing operating system file system 687 is used for all access to auxiliary storage. However, the VDE object 300 can be stored in auxiliary storage in the form of an external object container 728, file system 687, or remotely accessible through the communication manager 776. The object switch 734 makes a request to the object container manager 770 if it wants to access the external object container 728, and the object container manager 770 makes a request to the object container 728 or the redirector 692 (which in turn accesses the object in file system 687). Root to).

In general, the redirector 684 maps the VDE object container 728 content to an existing call to file system 687. Redirector 684 provides existing OS level information about VDE object 300, including mapping objects to existing OS namespaces. This allows seamless access to VDE-protected content using the "normal" file system 687 access technology provided by existing operating systems.

In the integrated description described above, each existing target OS file system 687 has different interface requirements, which allows the redirector mechanism 684 to be "hooked". Redirectors 684 typically use low-level network and file access "hooks" because today's off-the-shelf operating systems provide support for network-based volumes, file systems, and other devices (eg, printers, modems, etc.). Can be used to integrate with existing operating systems. "Add-ons" to support VDE feature 602 can be integrated into existing operating systems using these existing hooks. User Notification Service Manager 740 The User Notification Service Manager 740 and the associated User Notification Exception Interface (pop-up) 686 provide the ROS 602 with improved communication capabilities with users of electronic device 600. Not all applications 608 can be designed to respond to messages from ROS 602 passed through API 682, giving ROS 602 the ability to communicate with the user in any state of the application anyway. Important or desirable. User notification service manager 740 and interface 686 provide ROS 602 with a mechanism to communicate directly with the user instead of or in addition to passing return calls through API 682 and application 608. This is similar to, for example, the ability of the Windows® operating system to display a user message in a "dialog box" "on" the running application, regardless of the state of the application.

The 686 blocks of user notifications in a preferred embodiment can be implemented as application code. The implementation of interface 740a is preferably formed on top of the notification service manager 740, which can be implemented as part of API service manager 724. The notification service manager 740 in the preferred embodiment provides notification support for dispatching specific notifications to the appropriate user processing via the appropriate API returns or other aisles. This mechanism allows notifications to be routed to any approved process rather than simply returning to the process that identified the notification mechanism. API Service Manager 742 The API service manager 742 of the preferred embodiment is implemented as a service interface with the RPC service manager 732. All user API requests are formed on top of this basic interface. API Service Manager 742 provides an example of a service for each user application that is preferably running.

In a preferred embodiment, most RPC calls to ROS functionality supported by API Service Manager 742 can be mapped directly to service calls with some additional parameter checking. This mechanism allows developers to create their own extended API libraries with added or modified functionality.

ROS602 is formed by integrating an "add-on" with an existing operating system In the aforementioned description, the API service 742 code is shared by the application programmer's implementation decision and / or the type of electronic device 600. You can get (for example, a resident in a host environment like a Windows® DLL), or you can link directly to your application's code. Notification Service Manager 740 can be implemented within API 682. These components interface with the notification service component 686 to provide a transition between the system and user space. Safety Database Service Manager ("SDSM") 744 There are at least two techniques that can be used to manage the safety database 600: C commercial database approach; and C site record number approach.

Either method may be selected based on the number of records the VDE site has stored in the safety database 610.

The commercial database approach uses a commercial database to securely store wrapped records in a commercial database. This technique is preferred when the number of records stored in the safety database 610 is large. This approach provides fast access, efficient updates, and easy integration into the host system at the cost of resource usage (most commercial database managers use many system resources).

The site record number approach uses the "site record count" ("SRN") to locate the records in the system. This system is preferred when the number of records stored in the safety database 610 is small and does not appear to change significantly over time. This technique enables efficient use of resources with limited update capacity. The SRN further allows the grouping of similar data records for faster access and improved performance.

Since the VDE100 can be significantly scaled up, different electronics 600 can suggest one of many methods. For example, in a limited environment such as a set top, PDA, or other low-end electronics, there may be a preferred SRN scheme that limits the amount of resources (memory, and processor) required. When VDEs are deployed in more powerful electronics 600 such as desktop computers, servers, and information exchanges, commercial database systems are more desirable because they provide high performance in resource-constrained environments.

One of the differences between database records between the two approaches is whether the records are identified using the full VDE ID or SRN. To translate between the two systems, the SRN reference can be replaced with a VDE ID database query each time it occurs. Similarly, the VDE ID used as an index or query for other items can be replaced with the appropriate SRN value.

In a preferred embodiment, the off-the-shelf database manager 730 is used to maintain a secure database 610. ROS602 interacts with commercial database manager 730 through database driver 750 and database interface 748. The database interface 748, located between ROS 602 and the database commercial database manager 730 of an external third-party seller, allows any database seller to implement the VDE compliant database driver 750 on their products. It can be an open standard.

ROS602 can encrypt the records of each secure database 610 so that the secure layer provided by VDE is "above" the commercial database structure. In other words, the SPE736 can write safety records in size and format that can be stored within the database record structure supported by the commercial database manager 730. Commercial Database Manager 730 can be used to organize, store, and retrieve records. In some embodiments, it is desirable to use a proprietary and / or newly created database manager instead of the commercial database manager 730. However, the commercial database manager 730 provides some advantages, such as the ability to use existing database management products.

The safety database service manager (SDSM) 744 calls the underlying commercial database manager 730 to obtain, modify, and store the records in the safety database 610. In a preferred embodiment, the "SDSM" 744 forms a layer "above" the structure of the commercial database manager 730. For example, all VDE security information is sent to the commercial database manager 730 in encrypted form. The SDSM744 may provide records management, caching (using cache manager 746), and related services of the commercial database system 730 and / or record manager (above), along with cache manager 746 and database interface 748. The database interface 748 and cache manager 746 in the preferred embodiment do not present their own RSI, but the RPC manager 732 communicates with them through the secure database manager RSI744a. Name Service Manager 752 Name Service Manager 752 supports three subservices: User Name Service, Host Name Service, and Service Name Service. Username services can provide mapping and discovery between usernames and user ID numbers, and can also support other aspects of user-based resources and information security. The host name service maps and searches between the names of other processing resources (and other host electronics, for example) (for example, with other information such as addresses, communication connection / routing information) and the VDE node ID. provide. Service name services provide mapping and discovery between service names and other directly related information such as connection information (eg, remote service routing and contact information) and service IDs.

The name service manager 752 in the preferred embodiment is connected to the external service manager 772 so that the external service routing information can be provided directly to the external service manager. Name service manager 752 is also connected to safety database manager 744, allowing name service manager 752 to access name service records stored in safety database 610.

External service manager 772 and service transport 786 External Service Manager 772 provides protocol support capabilities to interface with external service providers. The external service manager 772, for example, obtains external service routing information from the name service manager 752 and makes contact with a specific external service (for example, other VDE electronics 600, financial information exchange, etc.) through the communication manager 776. initialize. External service manager 772 uses service transport layer 786, which provides the communication protocols and other information needed to provide communication.

There are some important use cases for External Service Manager 772. For some VDE objects, some or all of their content is not operated by a user who has or wants to obtain some usage rights to the VDE object. Can be stored in the object container 728 of. In this case, the external service manager 772 may manage the connection to the electronic device 600 in which the desired VDE object (or its contents) is stored. In addition, the file system 687 can be a network file system (eg, Netware, LANtastic, NFS, etc.) that allows access to VDE objects using the redirector 684. Object switch 734 also supports this capability.

Many different techniques are possible when accessing VDE objects using the external service manager 772. Make VDE objects worldwide web by including, for example, related headers, content tags, host ID-to-URL conversion (using, for example, Name Service Manager 752), and an instance of HTTP-aware service transport layer 786. It can be formatted for protocols (HTML, HTTP, and URL).

In other examples, the external service manager 772 is used to provide remote event handling services, smart agent execution services (to provide and locate these services), public key certificate services, and remote name services. , And other remote functions supported by the ROS 602 RPC (such as having an RSI) or by using a protocol supported by the service transport layer 786, locate, connect, and it. Can be used. Outgoing management object manager 754 Outgoing managed object manager 754 receives managed objects from object switch 734, object container manager 770, or other sources and sends them to another VDE electronics. Outgoing management object manager 754 manages the sending of outgoing objects to the correct destination. The outgoing management object manager 754 can acquire the routing information from the name service manager 752 and send the object using the communication service 776. Typically, the Outgoing Management Object Manager 754 keeps records in a secure database 610 (eg,) that reflect when the object was successfully sent, when the object should be sent, and other information about the object's sending. , Keep in shipping table 444) (in cooperation with SPE 503). Incoming call management object manager 756 The incoming call management object manager 756 receives a management object from another VDE electronic device 600 via the communication manager 776. Incoming call management object manager 756 can route objects to object container manager 770, object switch 734 or other destinations. Typically, the incoming call management object manager 756 keeps a secure database of records that record received objects, objects that are expected to be received, and other information about the objects that are received and / or objects that are expected to be received. Keep in 610 (eg receive table 446) (in cooperation with SPE 503). Object Container Manager 770 The object container manager 770 is a form of database or file manager. The object container manager 770 manages the storage of the VDE object 300 in the object container 728, in the database, or in the file system 687. Object Container Manager 770 has the ability to browse and / or search for information about objects (such as content summaries, abstracts, reviewer annotations, schedules, promotional materials, etc.) using, for example, the INFORMATION method associated with VDE Object 300. Can also be provided. Object Submission Manager 774 The object submission manager 774 in a preferred embodiment provides an interface between application 608 and object switch 734, thus providing an API in some respects. Can be considered part of 682. For example, Object Submission Manager 774 may allow a user application to create a new VDE object 300. Object submission manager 774 may also allow incoming / outgoing managed object managers 756 and 754 to create VDE objects 300 (administrative objects).

FIG. 12A shows how the object submission manager 774 should be used to facilitate the generation of the new VDE object 300 by communicating with the user of the electronic device 600. FIG. 12A shows that, in a preferred embodiment, object creation can take place in two stages: object definition stage 1220 and object creation stage 1230. The role of Object Submission Manager 774 is represented by two different "user input" illustrations (774 (1) and 774 (2)) shown in Figure 12A.

The Object Submission Manager 774 provides the user interface 774a as one of its roles or instances. The user interface 774a allows the user to create an object configuration file 1240 that specifies specific characteristics of the VDE object 300 to be created. For example, this user interface 774a allows the user to specify that the user wants to create an object, allows the user to design the content that the object has, and also within the object. It may allow the user to specify other specific aspects of the information contained in (eg, rules and control information, identifying information, etc.).

Part of the object definition task 1220 in a preferred embodiment may be to analyze the content or other information contained in the object. The object-defined user interface 774a is an object switch for calls that define or organize the content as user-specified "atomic elements" by analyzing the "content" or other information contained within the created object. Can be issued for 734. As described elsewhere herein, for example, this "atomic element" organization may break down content into paragraphs, pages or other subdivisions specified by the user. , Explicit (eg, insert control characters between each "atomic element") or implicit. Object switch 734 can receive static and dynamic content (eg, by non-time-dependent stream interface 762 and real-time stream interface 760) and access stored content or other information stored within file system 687. You can search for this.

The result of object definition 1240 can be an object configuration file 1240 that specifies specific parameters for the object being created. Such parameters may include, for example, map tables, key management specifications, and event method parameters. The object construction stage 1230 can take the information or content contained in the object configuration file 1240 and the new object as inputs, build the object based on those inputs, and store the object in the object container 728.

The object construction stage 1230 can assemble or modify the container using the information in the object configuration file 1240. Typically, this process creates one or more PERC 808s, public headers, secret headers, encrypts the content, and puts them all in a new object (or in a record associated with the new object) in a secure database. A series of events stored in (inside 610) are communicated to SPE 503.

The object configuration file 1240 can be passed to the container manager 764 in object switch 734. The container manager 734 is responsible for building the object 300 based on the object configuration file 1240 and additional user input. The user can interact with object construction 1230 through the object submission manager 774 in another instance 774 (2). In this further user interaction provided by Object Submission Manager 774, the user may specify permissions, rules and / or control information applied to or associated with the new object 300. To specify permissions, rules and control information, generally, as mentioned earlier, the object submission manager 774 and / or the container manager 764 in object switch 734 (eg, through gateway 734) is the SPE. By issuing a call to 503, the SPE is forced to retrieve the appropriate information from the secure database 610, generate the appropriate database entry, and store that database entry in the secure database 610 and / or its. It may be necessary to have the object switch provide the database entry in an encrypted and protected form and include it in the object. The above information provided by SPE 503 includes one or more PERC 808s, one or more method cores 1000', one or more load modules 1100, UDE 1200 and, in addition to encrypted content or other information. / Or contains one or more data structures such as MDE 1202, various key blocks, tags, public and private headers, and error collection information.

Container Manager 764 may work with SPE 503 to build Object Container 302 based, at least in part, on parameters for new object content or other information specified by Object Configuration File 1240. The container manager 764 can then insert content or other information (encrypted by SPE 503) that should be contained within the new object into container 302. Container Manager 764 may also insert appropriate permissions, rules and / or control information into Container 302 (this permissions, rules and / or control information may be at least partially inserted by user interaction through Object Submission Manager 774). Can be defined and at least partially SPE A secure data control structure can be created by processing with 503). The container manager 764 can then write the new object to the object container 687, and the user or electronics can "register" the new object by putting the appropriate information in the secure database 610. Communication subsystem 776 As mentioned above, the communication subsystem 776 can be a conventional communication service that provides a network manager 780 and a mail gateway manager 782. A mail filter 784 may be provided to automatically route object 300 and other VDE information to / from the outside world. The communications subsystem 776 may support real-time content feeds 684 from cables, satellites or other ranged communications links. Safe processing environment 503 As previously described with reference to FIG. 12, in a preferred embodiment, the electronics 600 each have one or more SPEs 503 and / or one or more HPEs. Includes 655. Each of these secure processing environments provides a protected execution space for performing tasks in a secure manner. These secure processing environments can fulfill the service requests passed from ROS 602 and are themselves provided by other services within ROS 602 or by other VDE electronics 600 or computers. It is also possible to generate a service request that is satisfied by the service to be provided.

In a preferred embodiment, the SPE 503 is supported by the hardware resources of the SPU 500. The HPE 655 may be supported by general purpose processor resources and may rely rely on software technology for security / protection. Thus, the HPE 655 gives the ROS 602 the ability to assemble and run specific component assemblies 690 on general purpose CPUs such as microcomputers, minicomputers, mainframe computers or supercomputer processors. In a preferred embodiment, the overall software architecture of SPE 503 can be the same as that of HPE 655. The HPE 655 may "emulate" the SPE 503 and associated SPU 500. That is, it is necessary to support the same set of service requests from ROS 602 (although ROS 602 may be restricted from sending certain secure tasks to HPE that should only be performed within SPU 500). Each can have various services and resources.

Some electronics 600 configurations may include both SPE 503 and HPE 655. For example, the tasks that HPE 655 can perform do not require much (or no) security protection, and the SPE 503 can perform all tasks that require a high degree of security. This ability to provide serial or concurrent processing with multiple SPEs and / or HPE arrangements provides additional flexibility and due to limited resources within the SPU 500 for practical or cost-effective reasons. You can overcome the limitations. The cooperation between SPE 503 and HPE 655 can lead to a more efficient, cost-effective and safe overall processing environment to support and provide the secure processing required by VDE 100 in certain applications. As an example, the HPE 655 can provide the entire process that allows the user to interact with the released object 300 "content", but accesses a secure object and releases information from that object. SPE 503 is used for.

FIG. 13 shows the software architecture of a secure processing environment (SPE) 503 of a preferred embodiment. This architecture can also be applied to a preferred embodiment of Host Processing Environment (HPE) 655. Protected processing environment (PPE) 650 can broadly refer to SPE 503 and / or HPE 655. Hereinafter, unless the context indicates otherwise, any reference to "PPE 650", "HPE 655" and "SPE 503" can refer to all of them.

As shown in FIG. 13, in a preferred embodiment, the SPE 503 (PPE 650) includes the following service manager / critical functional blocks. Kernel / dispatcher 552 C Channel Service Manager 562 C SPE RPC Manager 550 C Time Base Manager 554 C Encryption / Decryption Manager 556 C Key and Tag Manager 558 C Summary Service Manager 560 C Authentication Manager / Service Communication Manager 564 C Random value generator 565 C Secure Database Manager 566 C Other services 592 Each of the above important functional blocks of PPE 650 will be described in detail below. I.SPE Kernel / Dispatcher 552 The kernel / dispatcher 552 provides an operating system "kernel" that runs and manages the hardware resources of the SPU 500. This operating system "kernel" 552 is an SPU It provides 500 self-sustaining operating systems and is also part of the entire ROS 602 (which can have multiple OS kernels, each containing one OS kernel for each SPE and HPE controlled / managed by ROS). The kernel / dispatcher 552 provides SPU task and memory management, supports internal SPU hardware interrupts, provides specific "low level services", manages "DTD" data structures, and is an SPU bus interface unit. Manage 530. The kernel / dispatcher 552 also includes a load module execution manager 568 that can load the program into a safe execution space for execution by the SPU 500.

In a preferred embodiment, the kernel / dispatcher 552 may include the following software / functional components:

Load Module Execution Manager 568 Task manager 576 Memory manager 578 Virtual memory manager 580 "Low level" service manager 582 Internal interrupt handler 584 BIU Handler 586 (may not exist in HPE 655) Service interrupt queue 588 DTD interpreter 590 Preferably, at least part of the kernel / dispatcher 552 is stored in the SPU firmware loaded in the SPU ROM 532. An example of the memory map of SPU ROM 532 is shown in Fig. 14A. This memory map shows the various components of the kernel / dispatcher 552 (and other SPE services shown in Figure 13) that reside in SPU ROM 532a and / or EEPROM 532b. The NVRAM 534b memory map example shown in Figure 14B shows Task Manager 576 and other information loaded into NVRAM.

One of the functions performed by the kernel / dispatcher 552 is to receive RPC calls from ROS RPC Manager 732. As mentioned earlier, the ROS kernel RPC manager 732 can route RPC calls to the SPE 503 (via the SPE device driver 736 and its associated RSI 736a) for action by the SPE. .. The SPE kernel / dispatcher 552 receives these calls and either processes them or hands them over to the SPE RPC Manager 550 for routing within the SPE 503. It is also possible to generate RPC requests by processing based on SPE 503. Some of these requirements can be processed internally by SPE 503. If these requests are internally unserviceable, they can be passed through the SPE kernel / dispatcher 552 to the ROS RPC Manager 732 outside the SPE 503 and routed to a service outside the SPE 503. ..

A. Kernel / dispatcher task management Kernel / Dispatcher Task Manager 576 schedules and monitors tasks performed within SPE 503 (PPE 650). SPE 503 supports many types of tasks. A "channel" (a special type of task that controls the execution of component assembly 690 in a preferred embodiment) is treated by Task Manager 576 as a type of task. The task is submitted to Task Manager 576 for execution. Task manager 576 then ensures that the SPE 503 / SPU 500 resources needed to perform the task are available, and arranges for the SPU microprocessor 520 to perform the task.

Any call to the kernel / dispatcher 552 gives the kernel the opportunity to take control of SPE 503 and modify one or more tasks that it is currently performing. Therefore, the kernel / dispatcher task manager 576 of the preferred embodiment "swaps out" any or all of the currently active tasks (in connection with the virtual memory manager 580 and / or the memory manager 578) from the execution space. You can "swap in" additional or different tasks.

SPE task processing managed by Task Manager 576 can be "single task processing" (meaning that only one task can be active at a time) or "multiple task processing" (multiple tasks can be active at a time). Meaning). In a preferred embodiment, the SPE 503 may support single task processing or multiple task processing. For example, the "high-end" implementation of SPE 503 (such as in a server device) preferably involves multiple task processing using "preemptive scheduling". Desktop applications may also be required to perform several tasks at the same time, but desktop applications may be able to use the relatively simple SPE 503. For set-top applications, it may be possible to support the execution of only one task at a time using a relatively simple SPE 503 implementation. For example, SPU A typical 500 set-top implementation is simple with a single "aggregate" load module that combines subsets of VDE methods so that different methods can be executed in a single task processing environment. Can weigh, budget, and charge. However, an execution environment that supports only single-task processing can limit the use of relatively complex control structures. A single-task processing version of such an SPE 503 gets a smaller runtime RAM size requirement in exchange for flexibility in the number and types of weighing and budgeting operations. Such SPE 503 implementations can also be limited to weighing one object 300 at a time (depending on memory limits). Of course, by modifying and combining, it is possible to improve the capacity beyond a simple single task processing environment without incurring the additional cost required to support "full multiple task processing".

In a preferred embodiment, each task in SPE 503 is represented by a "swap block" that can be considered a "task" in a traditional multi-tasking architecture. A "swap block" in a preferred embodiment is a bookkeeping mechanism used by Task Manager 576 to track tasks and subtasks. Swap blocks correspond to chunks of code and related references that "fit" within the secure execution environment provided by the SPU 500. In a preferred embodiment, the swap block is a shared data element (eg, load module 1100 and UDE). 1200), contains a list of references to secret data elements (method data and local stacks), as well as swapped process "context" information (eg, registers set for that process when not processing). .. Figure 14C shows several "swap blocks" of several different tasks / methods such as "Channel" task, "Control" task, "Event" task, "Weighing" task, "Budget" task, and "Billing" task. Here is an example of a snapshot of SPU RAM 532 that stores an example of. Depending on the size of the SPU RAM 532, a "swap block" can be swapped out of RAM and temporarily stored in secondary storage 652 until its execution can continue. Therefore, an SPE operating in multiple task processing mode The 503 may have one or more "sleeping" tasks. In its simplest form, this is the active task currently being processed and another task that is "sleeping" and "swapped out" from the active execution space (eg, under which the active task above runs). There is a control task). The kernel / dispatcher 522 can swap out tasks at any time.

The task manager 576 may use the memory manager 578 to facilitate the execution of the swap process. Tasks can be swapped out of safe execution space, for example by reading appropriate information from RAM and other storage inside the SPU 500 and writing a "swap block" to secondary storage 652. By reading the swap block from secondary storage 652 and writing the appropriate information back into SPU RAM 532, kernel 552 can swap the task back into a safe execution space. Secondary storage 652 is not secure, so before SPE 503 writes its swap blocks to secondary storage, each swap block is encrypted (for example, with a secret value known only inside the SPU 500). It must be cryptographically sealed (using an initialized one-way hash function). Before returning the swap blocks to a secure execution space for further execution, the SPE 503 must decrypt and verify the cryptographic seal of each swap block read from secondary storage 652. It doesn't become.

To load a "swap block" into SPU memory, perform one or more "paging operations" to modify any "dirty pages" (ie, SPE 503) associated with a previously loaded swap block. It may be necessary to save the page first, then flush it, and then load all the pages needed for the new block context.

Preferably, the kernel / dispatcher 522 manages the "swap block" with the service interrupt queue 588. These service interrupt queues 588 allow the kernel / dispatcher 552 to track tasks (swap blocks) and their status (running, "swapped out", or "sleeping"). In a preferred embodiment, the kernel / dispatcher 552 may maintain the following service interrupt queue 588 to facilitate the management of "swap blocks".

RUN queue SWAP queue SLEEP queue Tasks that are fully loaded into the run space and are waiting for a run cycle from microprocessor 502 and / or in use are in the RUN queue. Tasks that are "swapped" out (for example, waiting for other swappable components to be loaded) are referenced in the SWAP queue. Tasks that are "sleeping" (for example, because they are blocked on some resource other than the processor cycle or are not needed at that time) are referenced in the SLEEP queue. The Kernel / Dispatcher Task Manager 576 may migrate tasks between RUN and SWAP queues, for example, based on a "round robin" scheduling algorithm. The "round robin" scheduling algorithm selects the next task waiting for service, swaps in all the pieces that need to be paged in, and then executes the task. The kernel / dispatcher 552 task manager 576 can migrate tasks between the SLEEP queue and the "awake" (ie, RUN or SWAP) queue, if desired.

In a multi-task processing environment, when two or more tasks try to write to the same data structure, it may result in "deadlock" or "task starvation". A "multiple thread" task processing arrangement can be used to prevent "deadlock" or "insufficient tasks". The kernel / dispatcher 552 of a preferred embodiment may support "single thread" or "multiple thread" task processing.

For single-threaded applications, the kernel / dispatcher 552 "locks" individual data structures as they were loaded. Once "locked", no other SPE 503 task can load them and is "blocked", waiting for the data structures to become available. As a practical matter, using a single thread SPE 503 can limit the ability of external vendors to create the load module 1100. Because there is no guarantee that there will be no "deadlock" by other VDE processes that external vendors know little or no. Also, contextual swapping of partially updated records can compromise system integrity, allow unmeasured use, and / or cause deadlocks. In addition, such "locking" can introduce potentially uncertain delays to processes that are typically time-critical, limit the throughput of the SPE 503, and increase overhead [overhead].

Apart from this problem, there are other serious processing problems with the creation of a single thread version of SPE 503 that may limit their usefulness or capability in certain situations. For example, multiple concurrency tasks may not be able to work with the same data structures that are often needed within a single thread SPE 503. This can effectively limit the number of concurrent tasks to one. In addition, single-threadedness can eliminate the ability to create an accurate total budget based on multiple concurrent tasks. This is because multiple concurrent tasks may not be able to effectively share the same total budget data structure. Unithreading can also eliminate the ability to support an audit process at the same time as other processes. For example, real-time feed processing may have to be shut down to audit budgets and measurements associated with the monitoring process.

One way to provide a more feasible "single thread" capability is for the kernel / dispatcher 552 to use a virtual page handling algorithm to "dirty pages" when writing to the data area. Is to track. A "dirty page" can be swapped in and out using a task swap block as part of the local data associated with that swap block. If a task exists, a "dirty page" is used using a three-way merge algorithm (ie, merging the original data structure, the current data structure, and the "dirty page" to form a new current data structure). "(SPU It is possible to merge with the current data structure (which may have been updated by 500 other tasks). During the update process, data structures can be locked as pages are compared and swapped. This virtual paging solution may be feasible in some applications as a way to enable single thread, but the use of such single thread implementations is a dedicated hardware due to the vendor restrictions mentioned above. It may be limited to clothing. Any implementation that supports multiple users (eg, "smart home" settops, many desktops and certain PDA applications, etc.) may face the limitations of single thread devices in certain situations.

It is preferred that these restrictions are unacceptable when using the full "multithread" data structure write capability. For example, some sort of "two-phase commit" process used by database vendors can be used to allow sharing of data structures between processes. To implement this "two-phase commit" process, each swap block may have the page address of an additional block of memory used to store the changed information. The change page is a local copy of one of the data elements written by the SPE process. In a preferred embodiment, the modified page reference associated with a particular data structure is stored locally in the swap block.

For example, SPE 503 may support 2 (change page) / data structures. This limitation can be easily modified by resizing the swap block structure so that the update algorithm can handle all of the change pages. The above "commit" process can be called when the swap block that references the modified page is about to be destroyed. The commit process is the original data element that was originally loaded (for example, UDE).₀), Current data element (eg UDE)_n), And for modified pages, merge them and copy new data elements (eg UDE)_{n + 1}) Is created. The DTD interpreter 590 allows the difference to be determined using the DTD of that data element. If no other swap block references it, the original data element is discarded (eg, determined by its DTD usage count).

B. Kernel / dispatcher memory management The memory manager 578 and virtual memory manager 580 of the preferred embodiment manage the ROM 532 and RAM 534 memory in the SPU 500 of the preferred embodiment. The Virtual Memory Manager 580 increases the amount of "virtual" RAM available in the SPE safe execution space beyond the amount of physical RAM 534a provided by the SPU 500 by providing a full "virtual" memory system. .. Memory Manager 578 manages memory in a secure execution space and controls memory access, allocation, and deallocation. If an SPU MMU 540 is present, the SPU MMU 540 supports a virtual memory manager 580 and a memory manager 578 in a preferred embodiment. In some SPU 500 "minimum" configurations, there may be no virtual memory capacity and all memory management functions may be handled by the memory manager 578. SPE using memory management It is also possible to facilitate the implementation of the security provided by 503. For example, in some classes of SPU 500, the kernel memory manager 578 can use a 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 the VDE component assembly 690 from invasion by "rogue" load modules.

In addition, the memory management provided by the memory manager 578, which operates at least in part based on the hardware-based MMU 540, can safely implement and implement a memory architecture that provides multiple protection domains. In such an architecture, the memory is divided into multiple domains. The plurality of domains are widely separated from each other and share only a specific memory area under the control of the memory manager 578. Execution processes cannot access memory outside that domain and can only communicate with other processes through services provided and mediated by privileged kernel / dispatcher software 552 within the SPU 500. Can not. Such an architecture is more secure when implemented at least partially by the hardware in the MMU 540, which cannot be modified by any software-based process running within the SPU 500.

In a preferred embodiment, access to services performed within ROM 532 and access to physical resources such as NVRAM 534b and RTC 528 is with privileged kernel / dispatcher software 552 and hardware within the MMU 540. Mediated by combination. ROM 532 and RTC 528 requests are privileged to protect critical system component routines (eg RTC 528).

Memory Manager 578 is responsible for allocating and deallocating memory, supervising the sharing of memory resources between processes, and enforcing memory access / usage restrictions. Typically, the SPE Kernel / Dispatcher Memory Manager 578 initially allocates all memory to kernel 552, allowing only process-level access to a page when it is loaded by a particular process. Can be configured in. In one example of the SPE processing system configuration, memory manager 578 allocates memory using a simplified allocation mechanism. The list of each memory page accessible within SPE 503 can be represented, for example, using a bitmap allocation vector. In a memory block, a group of contiguous memory pages can start at a particular page number. The size of a block is measured by the number of memory pages it occupies. Memory allocation can be recorded by setting / clearing the appropriate bits in the allocation vector.

A "dope vector" can be prepended to the memory block to facilitate memory management functions. The "dope vector" may have information that allows the memory manager 578 to manage its memory blocks. In the simplest form, a memory block can be configured as a "dope vector" in front of the block's actual memory area. This "dope vector" may include block numbers, support for dynamic paging of data elements, and markers for detecting memory overwrites. The memory manager 578 can track memory blocks by their block numbers and translate the block numbers into addresses before use. All access to the memory area can be automatically offset by the size of the "dope vector" when translating from block memory to physical address. Also, the "dope vector" can be used by the virtual memory manager 580 to facilitate the management of virtual memory.

In a preferred embodiment, the ROM 532 memory management task performed by the memory manager 578 is relatively simple. All 532 pages of ROM can be flagged as "read-only" and "non-paging". EEPROM 532B memory management can be slightly more complex than this. This is because it may be necessary to keep a "burn count" for each EEPROM page. It may be necessary to protect the SPU EEPROM 532B from any uncontrolled writes in order to prolong the limited writable life of this type of memory. Furthermore, the EEPROM page and the memory management address page may not be the same size.

Preferably, SPU NVRAM 534b is RAM with a battery that has less access restrictions. The memory manager 578 can ensure that the control structures that must be located in NVRAM 534b are not relocated during the "garbage collection" process. As mentioned above, the memory manager 578 (and MMU 540, if any) can protect NVRAM 534b and RAM 534a at the page level to prevent unauthorized modification by other processes.

Virtual Memory Manager 580 paging programs and data between SPU external memory and SPU internal RAM 534a. Data structures and executable processes are likely to exceed the limits of any SPU 500 internal memory. For example, PERC 808 and other basic control structures are quite large, and "bitmap metric" can be very large or very large. There can be two final solutions to this.

(1) Subdivide the load module 1100 (2) Support virtual paging The load module 1100 can be "subdivided" because often the load module is split into separate components and only that subset needs to be loaded to run. In this example, the load module 1100 is the smallest pagingable and viable element. Such a load module 1100 can be split into separate components (eg, executable code and multiple data description blocks), in which it is necessary to load to execute a simple load module. There is only one. This configuration allows the load module 1100 to load only the first executable code and then load data description blocks within other system pages on demand. Too big SPU Many of the load modules 1100 with executable sections that do not fit within the 500 can be rebuilt into two or more smaller standalone load modules. Explicit load module references allow large load modules to be manually "split" into multiple "chained" load modules.

Although some of the above restrictions can be relaxed using "demand paging", in a preferred embodiment virtual paging is used to manage large data structures and executables. The virtual memory manager 580 "swaps" information (eg, executable code and / or data structures) from / to SPU RAM 534a and provides other related virtual memory management services, thereby. Achieves full virtual memory management capability. Virtual memory management can be important in enabling large and / or multiple tasks to be performed in a resource-constrained SPU 500 configuration.

C.SPE Load Module Execution Manager 568 The SPE (HPE) Load Module Execution Manager (LMEM) 568 loads executables into memory managed by Memory Manager 578 and executes them. The LMEM 568 provides a mechanism to track the load modules currently loaded in the protected execution environment. The LMEM 568 also provides access to basic load modules and code fragments that are stored within the SPE 503 and are therefore always available to the SPE 503. The LMEM 568 can be called, for example, by a load module 1100 attempting to run another load module.

In a preferred embodiment, the load module execution manager 568 has a load module executor (program loader) 570, one or more internal load modules 572, and a library routine 574. The load module executor 570 loads the executable into memory and executes it (for example, after receiving a memory allocation from memory manager 578). The internal load module library 572 may provide a set of commonly used basic load modules 1100 (eg, stored in ROM 532 or NVRAM 534b). Library routine 574 may provide a set of commonly used fragments / routines (eg, bootstrap routines) performed by SPE 503.

Library routine 574 may provide a standard set of library functions in ROM 532. It is possible to use a list of standard library features as well as their entry points and parameters. The load module 1100 may call these routines (eg, using interrupts prepared for that purpose). Library calls can reduce the size of load modules by centralizing widely used code and increasing the degree of code reuse. Preferably, all load modules 1100 used by SPE 503 are referenced by the load module execution manager 568, which maintains and scans the list of available load modules and selects and executes the appropriate load modules. If there is no load module in SPE 503, the task will be "slept" and LMEM The 568 may require the load module 1100 to be loaded from secondary storage 562. This request causes the secure database manager 566 to retrieve the load module and related data structures, and the encryption / decryption manager 556 before storing the load module in the memory allocated by the memory manager 578. It can be in the form of a call that decrypts the load module.

More specifically, in a preferred embodiment, the load module 1100 is executed by passing the name of the desired load module 1100 (eg, VDE ID) to the load module execution manager 568. The LMEM 568 first searches the list of "in memory" and "built-in" load modules 572. If the desired load module 1100 cannot be found in the list, LMEM 568 issues an RPC request requesting a copy from secure database 610. This RPC request can be processed by the ROS Safety Database Manager 744 shown in Figure 12. The load module execution manager 568 may then request the memory manager 578 to allocate memory pages for storing the load module 1100. The load module execution manager 568 may copy the load module into its memory page and queue the page for decryption and security checks by the encryption / decryption manager 556 and the key and tag manager 558. After decrypting and checking the page, the load module execution manager 568 checks the validation tag, inserts the load module into the list of paged modules, and returns the page address to the caller. The caller can then call the load module 1100 directly or allow the load module execution module 570 to make that call.

FIG. 15a shows a detailed example of possible formats for channel 594, including channel header 596 and channel detail records 594 (1), 594 (2), ... 594 (N). The channel header 596 is in the channel ID field 597 (1), the user ID field 597 (2), the object ID field 597 (3), and the "rights" (ie, PERC 808 and / or the "user rights table" 464. Field 597 (4) with a reference or other identification for the collection of events supported by the referenced method, event queue 597 (5), and channel detail record ("CDR"). Can have one or more fields 598 that cross-reference a particular event code in. The channel header 596 may also include a "jump" or reference table 599 that allows addressing of elements within one or more related component assemblies 690. CDR Each of 594 (1), ... 594 (N) can correspond to a specific event (event code) to which channel 594 can respond. In a preferred embodiment, these CDRs are each method core 1000N (or fragment thereof), the load module 1100, and the data structures required to handle the corresponding events (eg, URT, UDE 1200 and / or MDE). 1202) and may be included explicitly and / or as a reference. In a preferred embodiment, one or more CDRs (eg, 594 (1)) may refer to URT464 as a control method and data structure.

FIG. 15b shows an example of a program control step performed by the SPE 503 to "open" channel 594 in a preferred embodiment. In a preferred embodiment, channel 594 handles events for a particular VDE object 300, a particular authorized user, and a particular "right" (ie, event type). These three parameters can be passed to SPE 503. Some of the SPE kernel / dispatcher 552 running within "channel 0" built by low-level service 582 in the "bootstrap" routine allocates (blocks) available channels supported by the processing resources of SPE 503. 1125) Can initially respond to "open channel" events. This "Channel 0" "Open Channel" task then issues a series of requests for the secure database manager 566 to get a "blueprint" to build one or more component assemblies 690 associated with channel 594. Can (block 1127). In a preferred embodiment, the "blueprint" is PERC May include 808 and / or URT464. Using the "object, user, rights" parameter passed to the "open channel" routine, the object registration table 460 records, the user / object table 462 records, the URT464 records, and the PERC Blueprints can be obtained by "chaining" 808 records with each other. Preferably, this "open channel" task calls Key and Tag Manager 558 to validate and associate the tags associated with the various records above, thereby authenticating and matching those tags. Make sure you do. The process of the preferred embodiment can then write the appropriate information to channel header 596 (block 1129). Such information may include, for example, user IDs, object IDs, and references to "rights" that the channel will process. The process of the preferred embodiment can then use a "blueprint" to access the appropriate "control methods" (eg, from the secure database 566 and / or the load module execution manager library 568) (block 1131). .. This control method can be used to effectively supervise the execution of all other methods 1000 in channel 594. The process then gets the control method "bind" to the above channel (block 1133). This step may include combining the information from URT464 into the channel as the data structure of the control method. The process can then pass an "initialization" event within channel 594 (block 1135). This "initialization" event can be created by Channel Service Manager 562, the process that issued the original call requesting the service performed by the created channel. Alternatively, the control method itself, which has just been attached to the channel, can effectively generate an initialization event that is passed to itself.

In response to this "initialization" event, the control method may construct channel detail records 594 (1), ... 594 (N) used to handle further events other than the "initialization" event. .. Control methods that run "inside" the channel can access various components that need to build related component assembly 690 based on the "blueprint" accessed in step 1127 (block 1137). Related channel detail records that identify method core 1000N, load module 1100, and related data structures needed to respond to events (eg UDE 1200 and / or MDE). By constructing 1202), each of the above components is coupled to channel 594 (block 1139). The number of channel detail records depends on the number of events that the "rights" identified by the "blueprint" (ie, URT464) can serve. During this process, the control method builds a "swap block" which effectively sets up all the required tasks and gets the required memory allocation from kernel 562. The above control method issues a call that causes the secure database manager 566 to search for the required components from the secure database 610 and a call that causes the encryption / decryption manager 556 to decrypt the search encryption information, if necessary. And then issue a call to the key and tag manager 558 to verify that all search components are valid. Each of the various component assemblies thus constructed 690 has a channel header event code / pointer by constructing the appropriate swap block referenced by the channel detail records 594 (1), ... 594 (N). "Joined" to the channel via record 598. When this process is complete, channel 594 is fully constructed and ready to respond to further events. As a final step, the process in Figure 15b may free up resources by deallocating the "initialize" event task if desired.

When channel 594 is constructed in this way, channel 594 responds to incoming events. Channel service manager 562 is responsible for dispatching events to channel 594. Whenever a new event arrives (for example, by an RPC call), Channel Service Manager 562 examines the event to determine if there is already a channel that can handle that event. If a channel exists, Channel Service Manager 562 passes the event to that channel. In order to handle the event, it may be necessary for Task Manager 576 to "swap in" certain "swappable blocks" that are considered active tasks by the channel detail record. In this way, the executable component assembly 690 formed during the channel open process shown in Figure 15b is placed in the active safe execution space and the specific component activated in response to the event code received. The assembly is selected. The activated task then performs the desired function in response to the event.

When destroying a channel, the various swap blocks defined by the channel detail record are destroyed and the identity in the channel header 596 is wiped clean, which causes the channel to "wiped clean". Can be reassigned by the Channel 0 and Open Channel tasks.

D.SPE interrupt handler 584 As shown in Figure 13, the kernel / dispatcher 552 also provides an internal interrupt handler 584. These facilitate the management of SPU 500 resources. Preferably, for all critical components, the SPU 500 runs in "interrupt" or "polling" mode. In polling mode, the kernel / dispatcher 552 can poll each section / circuit within the SPU 500 and emulate interrupts for them. In a preferred embodiment, preferably the following interrupts are supported by the SPU 500. C RTC 528 "Chick" Interrupt from C-bus interface 530 C Power supply error interrupt C watchdog timer interrupt C Interrupt from encryption / decryption engine 522 C memory interrupt (eg from MMU 540) When an interrupt occurs, the interrupt controller in the microprocessor 520 can cause the microprocessor to start executing the appropriate interrupt handler. An interrupt handler is a piece of software / firmware provided by the kernel / dispatcher 552 that allows the microprocessor 520 to perform certain functions when an interrupt occurs. Interrupts can be "vectorized" so that different interrupt handlers can be effectively executed by different interrupt sources.

A "timer tick" interrupt occurs when the real-time RTC 528 "pulses". By processing the timer tick interrupt by the timer tick interrupt handler, the internal device data / time is calculated and the timer event for channel processing is generated.

The bus interface unit 530 can generate a series of interrupts. In a preferred embodiment, the USART-modeled bus interface 530 is in various states (eg, "receive buffer full", "send buffer empty", and "status word change". ) Is interrupted. The kernel / dispatcher 552 serves a send buffer empty interrupt by sending the next character from the send queue to bus interface 530. The kernel / dispatcher interrupt handler 584 may serve a receive buffer full interrupt by reading a character, attaching it to the current buffer, and processing the buffer based on the state of the service engine of bus interface 530. Preferably, the kernel / dispatcher 552 handles the status word change interrupt and addresses the appropriate send / receive buffer accordingly.

When the SPU 500 detects an urgent power error condition, it generates a power supply error interrupt. This may require a quick action to prevent information loss. For example, in a preferred embodiment, the power anomaly interrupt moves all newly written information (ie, "dirty pages") into the non-volatile NVRAM 534b and marks all swap blocks as "swapped out". Mark and set the appropriate power anomaly flag, thereby facilitating the recovery process. The kernel / dispatcher 552 can then periodically poll for "power anomaly bits" in the status word until the data is cleared or power is completely removed.

The SPU 500 in this example has a conventional watchdog timer that periodically generates a watchdog timer interrupt. The watchdog timer interrupt handler performs an internal device check to confirm that no unauthorized modification has occurred. By comparing the watchdog timer's internal clock with the RTC 528, it is confirmed that the SPU 500 is not paused or probed, and other internal checks on the operation of the SPU 500 are performed to detect tampering.

When the processing of one block of data is completed, the encryption / decryption engine 522 generates an interrupt. The kernel interrupt handler 584 adjusts the processing status of the encrypted or decrypted block and passes the block to the next processing stage. The next block, scheduled to perform the encryption service, then moves its key into the encryption / decryption engine 522 and initiates the next encryption process.

A memory management unit 540 interrupt occurs when a task attempts to access memory outside its assigned area. The memory management interrupt handler takes the necessary action by trapping the request (eg, by initiating a transfer of control to memory manager 578 and / or virtual memory manager 580). Generally, the task fails, a page fault token is generated, or the appropriate virtual memory page is paged in.

E. Kernel / Dispatcher Low Level Service 582 The low-level service 582 in a preferred embodiment provides a "low-level" function. In a preferred embodiment, these functions may include, for example, power-on initialization, device POST, and failure recovery routines. In a preferred embodiment, the low-level service 582 may also provide download response challenges and authentication communication protocols (either by themselves or in combination with Authentication Manager / Service Communication Manager 564) and (alone or in combination). Can provide certain low-level management of SPU 500 memory devices such as EEPROM and FLASH memory (in combination with Memory Manager 578 and / or Virtual Memory Manager 580).

F. Kernel / Dispatcher BIU Handler 586 In a preferred embodiment, the BIU handler 586 manages the bus interface unit 530 (if any). The BIU handler 586 may maintain, for example, the BIU530 read and write buffers and provide BIU startup initialization and the like.

G. Kernel / Dispatcher DTD Interpreter 590 In a preferred embodiment, the DTD interpreter 590 handles data format issues. For example, the DTD interpreter 590 can automatically open data structures such as the UDE 1200 based on formatting instructions contained within the DTD.

The SPE kernel / dispatcher 552 above supports all other services provided by SPE 503. Other services will be described below. II. SPU Channel Service Manager 562 In a preferred embodiment, the "channel" is the basic task processing mechanism of SPE 503 (HPE 655). ROS 602 provides an event-driven interface for "methods". A "channel" allows component assembly 690 to serve events. A "channel" is a conduit for passing an "event" from a service supported by SPE 503 (HPE 655) to the various methods and load modules specified to handle those events. In addition, it supports the assembly of component assembly 690 and the interaction between component assemblies. More specifically, one of the data structures maintained by the channel manager 593, the "channel" 594, is one or more load modules 1100 and a data structure (eg, UDE). "Combine" 1200 and / or MDE 1202) into one component assembly 690. The channel service manager 562 can also cause the load module execution manager 569 to load the component assembly 690 for execution and also pass events to channel 594 for response by the component assembly 690. In a preferred embodiment, event processing is treated as a message to channel service manager 562.

FIG. 15 shows how the channel service manager 562 of the preferred embodiment constructs the channel 594 and shows the relationship between the channel and the component assembly 690. Briefly, SPE Channel Manager 562 establishes "Channel" 594 and its associated "Channel Header" 596. Channel 594 and its header 596 contain data structures that "join" or reference elements of one or more component assemblies 690. Thus, in a preferred embodiment, channel 594 is a mechanism for gathering or assembling the elements shown in FIG. 11E into a component assembly 690 that can be used for event handling.

Channel 594 is set up by Channel Service Manager 562 in response to the occurrence of an event. Once the channel is created, channel service manager 562 may issue functional calls to load module execution manager 568 based on channel 594. The load module execution manager 568 loads the load module 1100 referenced by channel 594 and requests execution service by the kernel / dispatcher task manager 576. The kernel / dispatcher 552 treats the event handling request as a task and does this by executing the code in the load module 1100 referenced by the channel.

An identifier for the event (eg, "event code") may be passed to the channel service manager 562. Channel Service Manager 562 parses one or more method cores 1000'that are part of the component assembly 690 that Channel Service Manager assembles. By performing this decomposition process, the channel service manager 562 determines which method and data structure is called by an event of that type. Channel manager 562 then issues a call (for example, to secure database manager 566) to get the methods and data structures needed to form component assembly 690. These called methods and data structures (eg, load module 1100, UDE 1200 and / or MDE) 1202) are each decrypted using the encryption / decryption manager 556 (if necessary) and then validated using the key and tag manager 558 respectively. Channel Manager 562 builds any necessary "jump table" to effectively "link" or "join" elements into a single cohesive executable, which allows the load module to be a component assembly. You can refer to the data structure and any other load module in. Channel manager 562 may then issue a call that causes LMEM 568 to load the executable as an active task.

FIG. 15 shows that channel 594 can reference another channel. The channel manager 594 allows any number of channels 594 to be formed and interact with each other.

A "channel header" 596 in a preferred embodiment queues events from the channel event resource, processes these events, and releases the appropriate task specified in the "channel detail record" for processing. Data structures and related control programs (or references to them). A "channel detail record" in a preferred embodiment links an event to a "swap block" (ie, a task) associated with that event. A "swap block" may refer to one or more load modules 1100, UDE 1200 and secret data areas needed to handle the event correctly. A swap block and a corresponding channel detail item are created for each of the different events that the channel can respond to.

In a preferred embodiment, the channel service manager 562 may support the creation and maintenance of channel 562 by supporting the following (internal) calls.

<tables num="6"><img file="JP4995980B2_D0006.tif" /></tables>

SPE RPC Manager 550 As described with reference to FIG. 12, in a preferred embodiment, the ROS 602 architecture is based on remote procedure calls. Each ROS 602 has an RPC manager 732 that passes RPC calls between services that present an RPC service interface (RSI) to the RPC manager. In a preferred embodiment, SPE 503 (HPE 655) is also formed based on the same RPC concept. Each SPE 503 (HPE 655) may have multiple internal modular service providers that present the RSI to the RPC Manager 550 inside the SPE (HPE). These internal service providers may use RPC service requests to communicate with each other and / or with ROS RPC Manager 732 (and thus with any other service provided by ROS 602 and external services).

The RPC manager 550 in the SPE 503 (HPE 655) is not the same as the RPC manager 732 shown in Figure 12, but performs a similar function in the SPE (HPE). That is, the RPC manager 550 receives the RPC requests and passes them to the RSI presented by the service executing the request. In a preferred embodiment, the request is passed between the ROS RPC manager 732 and the outside world (ie, the SPE device driver 736) via the SPE (HPE) kernel / dispatcher 552. The kernel / dispatcher 552 can serve a particular RPC request on its own, but generally passes the received request to the RPC manager 550 and routes it to the appropriate service inside the SPE (HPE). In an alternative embodiment, the requirement is ROS Rather than routing through RPC Manager 732, it is passed directly between HPE, SPE, APIs, notification interfaces and other external services. Determining which embodiment to use is part of the scalability of the system. That is, under a variety of traffic loads and system configurations, one embodiment is more efficient than another. Responses by the service (and additional service requests that the service itself can generate) are provided to the RPC Manager 550 and routed to other services inside or outside the SPE 503 (HPE 655).

The SPE RPC Manager 550 and its integrated service manager dispatch remote procedure calls using two tables, the RPC service table and the optionally optional RPC dispatch table. The RPC service table shows where requests for a particular service are routed and processed. In a preferred embodiment, this table, built within SPU RAM 534a or NVRAM 534b, lists each RPC service "registered" within SPU 500. Each row in the RPC service table has a service ID, its location and address, and a control byte. For simple implementations, the control byte only indicates whether the service is provided internally or externally. For more complex implementations, the control bytes can represent instances of a service (eg, in a multitasking environment, each service can have multiple "instances"). In a preferred embodiment, the ROS RPC Manager 732 and SPE 503 may have a symmetric copy of the RPC service table. If the RPC service is not found in the RPC service table, SPE 503 rejects it or passes it to ROS RPC Manager 732.

The SPE RPC Manager 550 accepts requests from the RPC service table and processes the requests according to the internal priorities associated with a particular service. In SPE 503, the RPC service table is extended by the RPC dispatch table. The RPC dispatch table of the preferred embodiment is organized as a list of load module references for each RPC service internally supported by SPE 503. Each row in the table permanently resides in the SPU 500 with the load module ID that services the call, whether an external caller can make the call, and the load module needed to service the call. It has a control byte that indicates whether or not it is. If SPU firmware 508 is loaded inside SPU 500, the RPC dispatch table will be in SPU ROM. It can be built in 532 (or EEPROM). If the RPC dispatch table is in EEPROM, the RPC dispatch table flexibly allows updates to the service without load module location and version control issues.

In a preferred embodiment, the SPE RPC Manager 550 first determines the location of a service manager that can service the request by referring to the (against) service request to the RPC service table. The RPC manager 550 then routes and acts the service request to the appropriate service manager. The service request is processed by the service manager in SPE 503 using the RPC dispatch table, which dispatches the request. When the RPC manager 550 determines the location of the service reference in the RPC dispatch table, the load module servicing the request is called and loaded using the load module execution manager 568. The load module execution manager 568 performs all required context configurations and then either hands over control to the requested load module or, if necessary, requests to load control from external management file 610. May be issued first. SPU Time Base Manager 554 Time-based manager 554 supports calls for the real-time clock (RTC) 528. In a preferred embodiment, the time-based manager 554 is always loaded and ready to respond to time-based requests.

The table below lists examples of basic calls that can be supported by time-based manager 554.

<tables num="7"><img file="JP4995980B2_D0007.tif" /></tables>

SPU Encryption / Decryption Manager 556 Encryption / Decryption Manager 556 supports calls to various encryption / decryption techniques supported by SPE 503 / HPE 655. The encryption / decryption manager 556 may be supported by the hardware-based encryption / decryption engine 522 in the SPU 500. Encryption / decryption techniques not supported by the SPU encryption / decryption engine 522 are provided as software by the encryption / decryption manager 556. The primary bulk encryption / decryption load module is preferably always loaded, and the load modules required for other algorithms are preferably paged in as needed. Therefore, if the primary bulk encryption / decryption algorithm is DES, only the DES load module needs to be permanently resident in RAM 534a of SPE 503 / HPE 655.

The following is an example of an RPC call supported by the encryption / decryption manager 556 in a preferred embodiment.

<tables num="8"><img file="JP4995980B2_D0008.tif" /></tables>

The call parameters passed include the key to use, the mode (encryption or decryption), any initialization vector required, the desired cryptographic processing (eg, the type of feedback), and the identifier of the cryptographic instance to use (eg, the type of feedback). identification), as well as the start address, destination address and length of the block to be encrypted or decrypted. SPU Key and Tag Manager 558 The SPU Key and Tag Manager 558 supports key storage, key and management file tag lookup, key swirling, and calls to generate random keys, tags and transaction numbers.

The following table shows an example of a list of SPE / HPE key and tag manager service 558 calls.

<tables num="9"><img file="JP4995980B2_D0009.tif" /></tables>

In a preferred embodiment, keys and tags can be safely generated within SPE 503 (HPE 655). Typically, key generation algorithms are specific for each type of encryption supported. The generated key is checked for cryptographic weaknesses before use. Preferably, the request for the key and tag manager 558 to generate a key, tag and / or transaction number takes some length as its input parameter. The request produces a random number (or other suitable key value) of the requested length as output.

The Key and Tag Manager 558 may support calls to retrieve specific keys in the key storage area inside the SPU 500 and any keys stored outside the SPU. The basic format of these calls is to request a key by key type and key number. Many of the keys are updated regularly by contact with the VDE administrator and are kept in SPU 500 in NVRAM 534b or EEPROM. Because these memories are safe, updatable, and non-volatile.

The SPE 503 / HPE 655 may support both public key type keys and bulk encryption type keys. Public key (PK) encryption type keys stored by SPU 500 and managed by Key and Tag Manager 558 include, for example, device public keys, device private keys, PK certificates, and certificate public keys. It can be. In general, public keys and certificates can be stored in external non-secured memory if desired, but device private keys and certificate public keys can be stored in the internal SPU 500 EEPROM or NVRAM. Should only be stored within 534b. The types of bulk encryption keys used by the SPU 500 include, for example, generic bulk encryption keys, administrative object private header keys, static object private header keys, mobile object private header keys, download / initialization keys, and backup keys. , Trail keys, and management file keys can be included.

As mentioned above, the key and tag manager 558 of a preferred embodiment supports the requirement to adjust or swivel a key to create a new key. This new key is created, for example, in a site and / or time-dependent deterministic way. Key swirling is an algorithmic process that acts on a key and some set of input parameters to create a new key. Key swirling can be used, for example, to increase the number of keys that can be used without creating additional key storage space. Key swirling can also be used, for example, as a process of "aging" the key by incorporating the value of the real-time RTC 528 as a parameter. It is possible to make the key site-specific by incorporating the site ID aspect as a parameter using the key swirl.

Key and Tag Manager 558 may also provide services related to tag generation and management. In a preferred embodiment, the transaction and access tags are preferably stored by SPE 503 (HPE 655) in protected memory (eg, in NVRAM 534b of SPU 500). These tags can be generated by the key and tag manager 558. These tags can be used, for example, to check access rights to data elements, validate data elements, and correlate data elements. For example, these tags can be used to ensure that components of secure data structures have not been tampered with externally to the SPU 500. The Key and Tag Manager 558 may also support tracking and communication tags. SPU Summary Service Manager 560 SPE 503 is SPU Maintain audit tracking in reprogrammable non-volatile memory within 500 and / or secure database 610. This audit tracking can consist of an audit summary of budgetary activity for financial purposes and a security summary used by the SPU. When a request is made to the SPU, it is recorded (logs) that the request has occurred, and it is noted whether the request was successful or unsuccessful. All successful requests are summed up and stored in the SPU 500 for each type. Failure information, including the elements listed below, may be saved along with the details of the failure.

<tables num="10"><img file="JP4995980B2_D0010.tif" /></tables>

This information can be analyzed to detect cracking attempts or to determine usage patterns that deviate from expected (and budgeted) norms. Audit trail histories within the SPU 500 are maintained until the audit is reported to the appropriate party. This makes it possible to add a legitimate failure analysis and an attempt to cryptanalyze the SPU.

The summary service 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 SPE 503 behavior. Event summaries are maintained, analyzed and used by SPE 503 (HPE 655) or VDE Administrators to identify and limit unauthorized use of electronic device 600, if possible. In a preferred embodiment, such parameters may be stored in safe memory (eg, in NVRAM 534b of SPU 500).

In a preferred embodiment, there are two basic structures in which the summarization service is used. One of them (the "event summary data structure") is VDE administrator specific and tracks events. The event summary structure can be maintained and audited during regular contact with the VDE administrator. The other is used by VDE administrators and / or distributors for the overall budget. The VDE administrator may register the event summary and the overall budget summary when the electronics 600 are initialized. The overall budget summary is reported to the VDE administrator and is used by the VDE administrator to determine the distribution of the budget consumed in the event of (eg) corruption of secure management file 610. File. Participants who receive the appropriate permissions may register the process (eg, a particular budget) with the Summarization Service Manager 560. The summary service manager 560 then (eg NVRAM) Protected memory space (in 534b) can be reserved and desired usage and / or access parameters can be maintained. Access to each summary and its modifications can be controlled by its own access tags.

The following table shows an example of a list of PPE Summary Service Manager 560 service calls.

<tables num="11"><img file="JP4995980B2_D0011.tif" /></tables>

In a preferred embodiment, the event summary data structure uses a fixed event number to index into a lookup table. Look-up tables have values that can be configured as counters or counters + limits. Counter mode can be used by VDE administrators to determine how to use the device. The limit mode can be used to limit attempts at unauthorized modification and use of the electronic device 600. If the limit is exceeded, the SPE 503 (HPE 655) will deny user-requested service until it is reset by the VDE administrator. Calls to the system-wide event summarization process are preferably built into all load modules that handle related events.

The following table shows examples of events that can be weighed separately by the event summary data structure of the preferred embodiment.

<tables num="12"><img file="JP4995980B2_D0012.tif" /></tables>

Another "overall currency budget" summary data structure maintained by the summary service manager 560 of the preferred embodiment allows registration of the VDE electronics 600. The first entry is used for the overall currency budget consumed value and is registered by the VDE administrator. The VDE administrator first initializes SPE 503 (HPE 655). A particular currency consumption load module and an audit load module that completes the consumption currency budget audit process may call the summary service manager 560 to update the currency consumption value. Specially approved load modules may have access to the global currency summaries and additional summaries may be registered by individual providers. SPE Authentication Manager / Service Communication Manager 564 Authentication Manager / Service Communication Manager 564 supports user password validation and "ticket" generation and validation calls. Authentication Manager / Service Communication Manager 564 is also an SPE Supports secure communication between the 503 and an external node or device (eg VDE administrator or distributor). Authentication Manager / Service Communication Manager 564 may support the following examples of authentication-related service requests in a preferred embodiment.

<tables num="13"><img file="JP4995980B2_D0013.tif" /></tables>

Not included in the table above are calls to secure communications services. The secure communication service provided by manager 564 provides secure communication based on the public key (or other) challenge-response protocol (eg, in connection with the low-level service manager 582, if desired). obtain. This protocol is described in more detail elsewhere herein. If the device can be used by more than one user, the ticket identifies the user with respect to the electronic device 600. Tickets are requested by the VDE software application and returned to the VDE software application using a ticketing protocol (eg, Kerberos). The VDE component may require that a ticket be presented to allow certain services. SPE Safety Database Manager 566 Secure Database Manager 566, SPE Memory-Secure Database External to 503 Find, maintain, and store secure database records in 610. Many of the secure database files 610 are in encrypted form. Therefore, all secure information retrieved by Secure Database Manager 566 must be decrypted by Encryption / Decryption Manager 556 before use. The secure information generated by SPE 503 (HPE 655) that must be stored outside the secure execution environment (for example, records of use) is also stored by the secure database manager 566 in their secure database file 610. Before being stored, it is encrypted by the encryption / decryption manager 556.

For each of the VDE items loaded in SPE 503, the secure database manager 566 of the preferred embodiment has a master list of VDE item IDs to ensure that the item provided is the current item. You can search and then check the corresponding transaction tag for the transaction tag within that item. The secure database manager 566 can keep a list of VDE field IDs and transaction tags in a "hash structure" that can be paged into SPE 503 to quickly determine the location of the appropriate VDE field IDs. Can be done. Look-up table approaches can be used in relatively small systems. In either case, the list should be structured as a pagingable structure that allows the location of VDE item IDs to be quickly determined.

A "hash-based" approach can be used to sort the list into "hash buckets". You can then access the "hash bucket" to locate items in the list faster and more efficiently. In the "hash-based" approach, VDE item IDs are "hashed" in a subset of the complete item IDs and then grouped together as pages in a "hashed" table. Each "hashed" page may contain the rest of the VDE item ID and the current transaction tag for each item associated with that page. The "hash" table page number can be derived from components of the VDE field ID such as distribution ID, field 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) can be configured site by site by the VDE distributor to provide optimal hash page usage. An example of the hash page structure is shown below.

<tables num="14"><img file="JP4995980B2_D0014.tif" /></tables>

In this example, each hash page may contain all of the VDE field IDs and transaction tags that have the same distributor ID, field ID, and user ID fields (site IDs are fixed for a given electronics 600). .. Therefore, these four pieces of information can be used as hash algorithm parameters.

The "hash" pages can have themselves updated frequently and should have a transaction tag that is checked each time the "hash" page is loaded. Also, transaction tags can be updated each time a "hash" page is exported.

As an alternative to the hash-based approach, if the number of updatable items can be kept small (as in the case of the dedicated consumer electronics 600), each updatable item is unique as part of the VDE item ID. Assigning a sequential site record number may allow the use of a lookup table approach. Only a small number of transaction tag bytes are required for each item, and table transaction tags for all frequently updatable items can be kept in protected memory such as SPU NVRAM 534b. Random value generator 565 Random value generator manager 565 can generate random values. If a hardware-based SPU random number generator 542 is present, the random number generator manager 565 can use the hardware-based SPU random number generator 542 to help generate random values. Other SPE RPC services 592 Other approved RPC services SPU by having them "register" themselves in the RPC service table and adding their entries to the RPC dispatch table. Can be included within 500. For example, one or more component assemblies 690 can be used to provide additional services as part of SPE 503 and its associated operating system. Requests not registered in these tables are passed outside of SPE 503 (HPE 655) for external services. Consideration of performance of SPE 503 The performance of the SPE 503 (HPE 655) is C Complexity of component assembly to use C Number of concurrent component assembly processes C Available internal SPU memory capacity Speed of C block cipher / decryption algorithm Is a function of.

Along with the number of concurrent component assembly processes, component assembly complexity is probably a major factor in determining performance. The combination of these factors determines the amount of code and data (minimum device size) that must reside in the SPU 500 at any given time, which allows the process to be in a number of device size "chunks". It will also be decided if it should be split. Segmentation essentially increases the runtime size over simpler models. Of course, it is possible to implement a limited-feature version of the SPU 500 with a much smaller amount of RAM 534. Although an "aggregate" load module like the one above eliminates the flexibility of configuring a VDE structure, it also limits the ability of participants to update individual elements that would otherwise be separated. , Can result in a smaller minimum device size. A very simple weighing version of the SPU 500 can be built to operate with minimal device resources.

The impact of the amount of RAM 534 inside the SPU 500 on the performance of the SPE 503 is probably greater than in any other aspect of the SPU. The flexible nature of the VDE process allows the use of numerous load modules, methods, and user data elements. It is impractical to store many of these items in ROM 532 in the SPU 500. Most of the code and data structures needed to support a particular VDE process need to be dynamically loaded into the SPU 500 for that particular VDE process when that process is called. The operating system within the SPU 500 can then page in the VDE items needed to carry out that process. The amount of RAM 534 in the SPU 500 directly determines the number of page swaps required to run a VDE process and how large any single VDE load module + required data can be. To do. SPU I / O speed, encryption / decryption speed, and the capacity of internal memory 532 and 534 directly affect the number of page swaps required on the device. Insecure external memory can reduce the latency of swapped pages loading into the SPU 500, but will still cause significant encryption / decryption inconvenience for each page.

To maintain security, the SPE 503 must encrypt and cryptographically seal each block that is swapped out to a storage device external to the supporting SPU 500, and likewise. When blocks are swapped into the SPU 500, each block must be decrypted, its cryptographic seal verified, and validated. The data movement and encryption / decryption overhead for each swap block has a significant impact on SPE performance.

If the processor does not move data through the encryption / decryption engine 522, the impact of the performance of the SPU microprocessor 520 on the performance of the SPE 503 supported by that processor may not be significant. VDE safety database 610 The VDE 100 stores separately deliverable VDE elements in a secure (eg, encrypted) database 610 delivered to each VDE electronics 610. In a preferred embodiment, database 610 may store and / or manage VDE items of three basic classes.

VDE object VDE process elements, and VDE data structure The following table lists some examples of VDE items stored in secure database 610 or managed by information stored in secure database 610.

<tables num="15"><img file="JP4995980B2_D0015.tif" /></tables>

Each electronic device 600 may have an instance of a secure database 610 that keeps VDE items secure. FIG. 16 shows an example of a secure database 610. The secure database 610 shown in this example contains the following VDE protected items:

C One or more PERC 808, C method 1000 (including static and dynamic methods "core" 1000 and MDE 1202), C Static UDE 1200a and Dynamic UDE 1200b, as well C load module 1100 The secure database 610 may also include the following additional data structures that are used and maintained for administrative purposes:

C "Object Registry" 450 that references object storage 728 with one or more VDE objects. C name service record 452, and C configuration record 454 (including site configuration record 456 and user configuration record 458) In a preferred embodiment, the secure database 610 does not include a VDE object 300, eg, refers to a VDE object stored on file system 687 and / or in a separate object container 728. However, a good "first step" in understanding VDE-protected information would be the description of the VDE object 300.

VDE object 300 VDE 100 provides a media-independent container model that encapsulates content. FIG. 17 shows an example of a "logical" structure or format 800 of object 300 provided by a preferred embodiment.

The generalized "logical object" structure 800 shown in FIG. 17 used in a preferred embodiment supports the delivery of digital content by any media currently in use. In a preferred embodiment, the "logical object" is the content and computer software and / or methods used to manipulate, record, and / or control the use of the content and / or the content. It can collectively refer to permissions, restrictions, administrative control information and / or requirements applicable to computer software and / or methods. Logical objects may or may not be stored, and may or may not be present or accessible in any given electronic device 600. The content portion of a logical object can be organized as information contained, not included, or partially contained within one or more objects.

Briefly, in a preferred embodiment, the "logical object" structure 800 of FIG. 17 is a "private body" 806 with a public header 802, a secret header 804, and one or more methods 1000. , Contains a permission record (PERC) 808 (which may contain one or more key blocks 810) and one or more data blocks or regions 812. These elements may be "packaged" within the "container" 302. In a preferred embodiment, this generalized logical object structure 800 is used for different types of VDE objects 300, which are classified according to their content type and location.

The concept of "container" is a convenient metaphor for naming a collection of elements required to use content or perform administrative types of activities. Container 302 typically contains identifying information, control structures and content (eg, property or administrative data). The term "container" is often used (eg, Bento / OpenDoc and OLE) and is stored in the secondary storage system of a computer system or via a communication network on the "server" secondary storage system. Represents a collection of information that can access a computer system. The "container" 320 provided by the preferred embodiment is not thus limited or limited. For VDE 100, this information does not need to be stored together, received at the same time, updated at the same time, used only for a single object, Or it does not have to be owned by the same entity. Rather, VDE In 100, the concept of containers has been broadened and generalized to provide real-time content and / or online interactive that has been delivered to electronic devices by broadcast over cables or communicated by other electronic means of communication. Content is also included.

Therefore, the "complete" VDE container 302 or logical object structure 800 may not be present at the user's location (or any other location in that regard) at any given time. A "logical object" may exist for a specific period (or multiple periods) rather than all at once. This concept includes the notion of a "virtual container" in which important container elements can exist in multiple locations and / or over multiple time periods in some order (overlapping or non-overlapping). .. Of course, the VDE 100 container may be stored with the required control structures and content. It represents a continuum ranging from all content and control structures residing within a single container to locally inaccessible content or container-specific control structures.

Typically, at least some of the data that represents an object is encrypted and therefore its structure is unrecognizable, but within the PPE 650, logically seeing the object as a "container" 302. Can be done. This is because its structure and components are automatically and transparently decrypted.

The container model merges well with ROS 602 provided by event-driven processes and preferred embodiments. In this model, content is easily subdivided into smaller pieces, but stored to maintain the structural richness inherent in unencrypted content. To. Object-oriented container models (such as Bento / OpenDoc or OLE) also require "hooks" to insert the required operating system-integrated components and to define various content-specific methods. "Is provided in large numbers.

More specifically, the logical object structure 800 provided by the preferred embodiment includes a public (or unencrypted) header 802. This header 802 identifies the object as well as one or more owners of rights within the object and / or one or more distributors of the object. The secret (or encrypted) header 804 may contain some or all of the information in the public header, and in a preferred embodiment, by a service information exchange, VDE administrator, or SPU 500 by the user. Contains additional data that inspects and identifies the validity of the object 300 when attempting to register the object as a user. Alternatively, information identifying one or more rights owners and / or distributors of objects is placed in encrypted form within the encrypted header 804, along with the additional valid and identifiable data described above. Can be done.

The logical object structure 800 may also include a "secret body" 806 that has or references a set of methods 1000 (ie, a program or procedure) that controls the use and distribution of the object 300. The ability to optionally incorporate different methods 1000 into each object is important for making VDE 100 highly configurable. Method 1000 performs the basic function of defining what a user (including distributors, client administrators, etc.) can and cannot do with an object 300, if appropriate. Thus, while other objects can be controlled by much more complex (eg billing and usage restrictions) methods, one object 300 has a newspaper stand for reading the newspaper for a week after the newspaper is published. It may have relatively simple methods, such as allowing unlimited viewing for a fixed fee for a fixed period (like price).

The logical object structure 800 shown in FIG. 17 may also include one or more PERC 808s. PERC 808 governs the use of object 300 and identifies the methods or combinations of methods that must be used to access or use an object or its contents. The permission record 808 for an object may include a key block 810 that may contain a decryption key for accessing the contents of the encrypted content stored within the object 300.

The content portion of the object is typically divided into parts called data blocks 812. The data block 812 can have all kinds of electronic information such as "content" including computer programs, images, sounds, VDE management information and the like. The size and number of data blocks 812 can be selected by the creator of that property. Data blocks 812 do not have to be all the same size (size can be affected by content usage, database format, operating system, security and / or consideration). Security is enhanced by using at least one key block 810 for each of the data blocks 812 in the object, but it is not required to do so. Key block 810 can also span parts of multiple data blocks 812, consistently or quasi-randomly. This spanning provides additional security by applying one or more keys to shredded or seemingly random pieces of content contained within an object 300, database, or other information entity. obtain.

Many of the objects 300 distributed by physical media and / or by "out-of-channel" means (eg, redistributed from one customer to another after receipt) have key block 810 protected by that key block. It may not be included in the same object 300 used to transfer the content. This is because a VDE object can have data that can be electronically copied from outside the confines of the VDE node. If the content is encrypted, then the copy is also encrypted, and the copyr cannot gain access to the content unless the copyr has the proper decryption key. For objects where security is of particular importance, permission records 808 and key block 810 are frequently distributed electronically using secure communication techniques (described below) controlled by the sender and receiver VDE nodes. Will be done. As a result, permission records 808 and key block 810 are, in a preferred embodiment, frequently stored only on the registered user's electronics 600 (and they themselves are also part of the registration / initialization process for the user. Will be delivered). In this example, the permission record 808 and key block 810 for each property are encrypted with a secret DES key that is stored only in the secure memory of the SPU 500, and the key block is not used for any other user's VDE node. Can be made possible. Alternatively, the key block 810 can be encrypted with the end user's public key so that these key blocks can only be used with the SPU 500 containing the corresponding private key (or any other). Acceptable encryption / security technology is available).

In a preferred embodiment, one or more keys used to encrypt each permission record 808 or other management information record will be used each time the record is updated (or for a particular one or more event). Will be changed later). In this case, the updated record is re-encrypted with one or more new keys. Alternatively, the one or more keys used to encrypt and decrypt the management information may be "time-varying" keys that automatically become invalid after a period of time. Combinations of aging keys with other event triggered keys may also be desirable. For example, the key may change after a certain number of accesses and / or after a certain period of time or at an absolute time. It is also possible to use the above techniques in combination for a given key or key combination. A procedure in a preferred embodiment for constructing a time-varying key is the SPU RTC. A one-way swivel algorithm using specific parts of real-time values provided by the 528 and input parameters including user and site information. To cause aging, such as techniques that use only periods related to user or site information, absolute time, and / or a subset of activities related to the use / decryption of VDE-safe content or the use of the VDE system. Other techniques can also be used.

The VDE 100 supports a number of different types of "objects" 300 with the logical object structure 800 shown in Figure 17. In a sense, objects can be categorized by whether the protection information is combined with the protected information. For example, a container that is bound to a particular VDE node by its control is called a "static object" (see Figure 18). A container that is not tied to a particular VDE node by its control information and has sufficient control and permissions to allow full or partial use at several sites is referred to as a "moving object". Called (see Figure 19).

In another sense, an object can be classified according to the nature of the information it has. A container that holds information content is called a "content object" (see Figure 20). Containers that contain transaction information, audit tracking, VDE structures and / or other VDE control / administrative information are called "administrative objects" (see Figure 21). Some containers that contain executable code that operate under VDE control (as opposed to being VDE control information) are called "smart objects". Smart objects support user agents and control their execution at remote sites. There are also other classifications of objects by location, type, and access mechanism associated with that content. This may include combinations of the above types. Some of these objects supported by VDE 100 are described below. Some or all of the data block 812 shown in FIG. 17 may include "embedded" content, administrative, static, moving and / or other objects.

1. Static object FIG. 18 shows an example of a "stationary object" structure 850 provided by a preferred embodiment. The "Static Object" structure 850 is intended to be used only with certain VDE electronics / installations that have received explicit permission to use one or more parts of that quiesce object. Therefore, the static object structure 850 does not have a permission record (PERC) 808, which is a separate device / instrument (eg, at different times, through different paths, and / or by different parties). Supplied and / or delivered to ration 600. It is possible to use the generic PERC 808 with many different stationary objects.

As shown in FIG. 18, the public header 802 is preferably "plaintext" (ie, unencrypted text). The secret header 804 is preferably encrypted using at least one of a number of "secret header keys". The secret header 804 preferably has one copy of the identification information element from the public header 802 so that if the identification information in the plaintext public header is tampered with, the system will be tampered with. You can determine exactly what you are trying to modify. Method 1000 can be contained within a section called "secret body" 806 in the form of object-local methods, load modules, and / or user data elements. This secret body (method) section 806 is preferably encrypted with one or more secret body keys contained within a separate permission record 808. Data block 812 has (informational or administrative) content that can also be encrypted using one or more content keys provided within permission record 808.

2. Moving object FIG. 19 shows an example of a "moving object" structure 860 provided by a preferred embodiment. Moving objects are objects that have enough information to allow at least partial use of at least some of their content when they reach a VDE node.

The moving object structure 860 is the same as the static object structure 850 shown in FIG. 18, except that it has a permission record (PERC) 808 in the secret header 804. Having a PERC 808 in the moving object structure 860 makes it possible to use moving objects in any VDE electronics / participants 600 (according to Method 1000 and the included PERC 808).

The "move" object is a VDE object 300 of a class that can specifically support "out-of-channel" distribution. Thus, the moving object has a key block 810 and is transportable from one electronic device 600 to another. Moving objects may come with a budget associated with very limited use, which allows users to use content (such as computer programs, games, or databases) in whole or in part. You can decide whether to obtain a license, further license, or purchase object content. Alternatively, the moving object PERC 808 may be, for example, (a) Budgets and / or allow the use of at least one type of Object Content, reflecting previously purchased rights or credits for future licensing or purchase. (b) Budgets that employ (and can debit) the remaining (available) credits stored and managed at the local VDE node to enable the use of object content, and / or (c) Reflect one or more maximum usage criteria before the report to the local VDE node (and optionally the information exchange) was requested, and then reset. A budget that may allow one or more further uses and / or modifications within one or more of the original budgets, Or you can use it to refer to budget records.

If the user wants to continue using the moving object after the available budget is exhausted, as in the case of the standard VDE object 300, or to an electronic device with a different moving object (or a copy thereof). If the new device is moved and does not have an available credit budget to meet the requirements required by permission record 808, the user contacts the information exchange service to obtain an additional budget. You may be required to do so.

For example, the moving object PERC 808 may have a reference to the required budget VDE1200 or budget options that are deemed available and / or expected to be available. Budget VDEs are consumer VISA, MC, AMEX, or other "generic" budgets that are object-independent and applicable to the use of specific or multiple classes of moving object content (eg Blockbuster Video). You can refer to any movie object from a class of moving objects that can be rented. Budget VDE itself may request one or more classes of objects that can be used with it, and one object may specifically refer to one or more specific general budgets. In such cases, the VDE provider typically provides the information in such a way as to enable correct reference as well as billing and consequential payment.

As long as the device has the correct budget or budget type (eg, sufficient credit available from information exchanges such as VISA budgets) for one or more users or user classes to the general public or specific, or The moving object itself has a sufficient budget Allowance) or with appropriate approval, the move object can be used in the receiving VDE node electronics 600 (eg, the move object can be used for one or more specific installations or installation classes or users or user classes. Allowance (stipulation), where classes correspond to installations or specific subsets of users stored in a secure database 610 and represented by predefined class identifiers). After receiving the moving object, if the user (and / or installation) does not have the appropriate budget and / or approval, the user will use the information stored by the electronic device 600 (using the information stored in the moving object). ), You will be informed of which one or more parties the user can contact. The party may form an alternative list of information exchange providers for moving objects (from which the user selects the desired contact).

As mentioned above, moving objects allow the object 300 to be distributed "out of channel". That is, an object can be distributed from one individual to another, either unauthorized or not explicitly authorized. "Out of channel" includes, for example, a path of distribution that allows a user to redistribute an object directly to another individual. For example, an object provider may allow a user to redistribute a copy of an object to a friend or colleague of that user (eg, by physical delivery of storage media or delivery over a computer network). This allows a friend or colleague to be allowed to use the object if it meets any particular criteria required to use the object.

For example, if a software program is distributed as a moving object, users of the program are usually free to do so if they want to supply the software or a usable copy of the software to a friend. Moving objects have great commercial value. This is because useful content can be distributed primarily by users and electronic bulletin boards, with little or no distribution overhead other than registration with "original" content providers and / or information exchanges.

"Out-of-channel" distribution may also allow the provider to receive payment for use and / or maintain at least some control over the redistributed objects in another way. Such specific criteria may include, for example, a registered presence in an authorized third-party financial user VDE node, such as a credit card with a credit that is fully available for its use.

Therefore, if the user has a VDE node, if the user has the appropriate available budget available (and, if necessary, assigned to the user) on the user's VDE node. , And / or if the user or the user's VDE node belonged to a specially approved group of users or installations, and / or if the moving object had its own budget. , The user may be able to use the move object.

The contents of the move object are encrypted, and the contents of the move object can only be used under approved circumstances, unless the move object secret header key used for the object is corrupted. This can be a relatively easy task for moving objects, for example when compared to permissions and / or budget information. This is because many objects share the same key, which can give the cryptanalyst both more ciphertext information to analyze and a stronger motivation to perform cryptanalysis.

In the case of a "moving object", the owner of the content may distribute the information with some or all of the key block 810 contained within the object 300 in which the content is encapsulated. Placing the key inside the distributed object 300 provides a security mechanism by breaking or cryptanalyzing the encryption algorithm used to protect the secret header (eg, by determining the key to encrypt the header). Increased risk of exposure to attempts to break through. Breaking through security usually requires considerable skill and time, but if it is broken, a large number of individuals whose algorithms and keys are exposed and have objects protected by the same keys and algorithms. Allows unauthorized use of protected information. As a result, placing the key within the distributed object 300 is "time dependent" (decreasing in value after a certain period of time) or content whose value is somewhat limited, or , Commercial value of putting the key inside the object (eg, convenience for the end user, long-distance communication or other means of delivering the key and / or permission information and / or support for the object going out of the channel It can be limited to cases where the relatively low cost of eliminating the ability to attack) outweighs the cost of aggression against advanced hackers. As mentioned elsewhere, key security can be increased by using swivel techniques to avoid storing "true" keys inside moving objects, but in most cases. Keep objects independent of these values by using a shared secret provided as input to almost or all VDE nodes by the VDE administrator, rather than the site ID and / or time of day. ..

As shown in FIG. 19 and mentioned earlier, the moving object preferably has a permission record 808 that provides at least some budget (typically one, the other, or both). As mentioned above, the permission record 808 may have a key block that stores important key information. PERC 808 has or may refer to budgets that may have valuable quantities / values. Such budgets can be stored within the mobile object itself or delivered separately and protected by highly secure communication keys and administrative object keys and administrative database technology.

Method 1000 contained in a moving object typically includes an installation procedure for "self-registering" the object using the permission record 808 within the object (eg, the REGISTER method). This is based on the number of objects that have a time limit and the objects (or properties) that end users are not charged or only charged for a given amount (eg, the number of end users who actually accessed the public information). Or objects that the information issuer is charged for) and objects that require a widely available budget and that can particularly benefit from off-channel distribution (eg, properties of credit card-derived movies, software programs, games, etc.) Can be particularly useful with (budget for objects with). Such moving objects may be supplied with or without budget UDE.

In publishing software, which is one use of moving objects, potential customers use the software in demonstration mode before paying a license fee or paying more than the initial trial fee. , Or, if possible, the use of full program functionality within a limited period of time may be permitted by the included permission records. For example, use a time-based billing method and a budget record with a small time budget pre-installed to allow full use of the program for a short period of time. Various control methods can be used to avoid unauthorized use of object content. For example, setting a minimum registration period for moving objects to a reasonably long period (eg, 1 month, 6 months, or 1 year) to prevent users from repeatedly using budget records in the same moving object. Can be done.

Another way to control the use of a moving object is to include a time-varying key in the permission record embedded within the moving object. This is to prevent mobile objects from being used after a certain date without re-registration and is generally useful for mobile objects, such as telecommunications, networks or (both one-way and two-way cables). Especially useful for moving objects that are electronically distributed by telecommunications (including). This is because the delivery date and time of such a moving object aging key can be set to correspond exactly to the time when the user took ownership of the object.

Moving objects can also be used to facilitate "movement" from one electronic device 600 to another. A user can move a move object containing one or more permission records 808, for example, from a desktop computer to the same user's notebook computer. It is possible for a moving object to register its user within the object itself and then make it available only to that user. The move object may maintain separate budget information, one for the base distribution budget record and another for the registered user's "active" distribution budget record. In this way, it is possible to copy an object and hand it over to another potential user, who then makes it a portable object for that user.

The moving object may be in a container with other objects. For example, a move object container is one or more content objects to register content objects in the end-user object registry and / or to provide a mechanism for enforcing permissions and / or other security features. And can have one or more administrative objects. The included administrative objects can be used to install the required permission records and / or budget information within the end user's electronics.

Content object FIG. 20 shows an example of the VDE content object structure 880. Content object 880 generally has or provides informational content. This "content" can be any kind 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, communication messages and / or signals, and at least one or more of them. Contains other information used or manipulated by your computer. Also, for transactions between banks, electronic purchase communications, and electronic commerce and communications such as the transmission of electronically signed contracts and other legal documents, audits and confidential commercial records. VDE for authentication, control and / or audit It is also possible to configure 100. The information used in these transactions can also be referred to as "content". As mentioned earlier, this content does not have to be physically stored in the object container and can be served separately at different times (eg, real-time delivery by cable).

The content object structure 880 in the particular example shown in FIG. 20 is a type of stationary object because it does not contain PERC 808. In the case of this example, the content object structure 880 contains at least one embedded content object 882 as shown in FIG. 5A as at least part of its content 812. Content object structure 880 may also include administrative object 870. Thus, the objects provided by the preferred embodiments may include one or more "embedded" objects.

Administrative object FIG. 21 shows an example of a managed object structure 870 provided by a preferred embodiment. A "administrative object" generally has methods related to permissions, administrative control information, computer software and / or VDE 100 behavior. It may further or optionally have records of use and / or other information used or related to the operation of VDE 100. Administrative objects can be distinguished from content objects, for example by the absence of VDE-protected "content" that is open to end users. Since an object may have other objects, a single object may have one or more content objects and one or more administrative objects. Administrative objects can be used to send information between electronic devices for update, usage reporting, billing and / or control purposes. Administrative objects are VDE 100 management and VDE It has information that helps maintain 100 correct behaviors. Generally, administrative objects are transmitted between VDE information exchange services, distributors, or VDE nodes such as client administrators and end-user electronics 600.

The administrative object structure 870 in this example includes a public header 802, a secret header 804 (including "PERC" 808), and a "secret body" 806 with method 1000. The administrative object structure 870 in this particular example shown in FIG. 20 is a type of moving object because it has a PERC 808, but the PERC 808 may be excluded from the administrative object to be a stationary object. The administrative object structure 870 does not store the information content, but stores the "administrative information content" 872. The administrative information content 872 may include, for example, a plurality of records 872a, 872b, ... 872n, each corresponding to a different "event". Each record 872a, 872b, ... 872n may include an "event" field 874 and optionally a parameter field 876 and / or a data field 878. These administrative content records 872 are VDEs. By 100, it can be used to specify the events that can be processed in the middle of a transaction. For example, an event designed to add a record to a secure database contains parameter 896, which indicates how and where the record should be stored, as well as data field 878, which has the record to add. obtain. In another example, a financial transaction between the creator and recipient of a managed object, such as a purchase, purchase order, invoice, etc., may be represented by a collection of events. Each event record 872 can be, for example, an instruction set executed by the end user's electronics 600 to make additions or changes to the end user's secure database 610. Events can perform a number of basic administrative functions, for example: Adding an object to an object registry, including providing related user / group records, rights records, permission records and / or method records; (Rolling audit tracking information, for example, in a tighter summary format Clear audit records (by up) "or by actually clearing; adding or updating permission records 808 for previously registered objects; adding or updating budget records; adding or updating user rights records; and , Add or update load modules.

In a preferred embodiment, the administrative object is transmitted from, for example, a distributor, a client administrator, and perhaps an information exchange or other financial services provider to the end user, or, for example, by an object creator, a distributor or service. Can be sent to an information exchange. For example, a managed object can increase or adjust the budget and / or permissions of the receiving VDE node to which the managed object is sent. Similarly, administrative objects that have audit information within the data area 878 of event record 872 may be sent from the end user to the distributor and / or information exchange and / or client administrator. Distributors and / or information exchanges and / or client administrators may themselves make transmissions to object creators or other participants in the object processing chain.

Method Method 1000 in a preferred embodiment supports many of the processes that users come across when using objects and communicating with distributors. Method 1000 can also identify which method fields are visible to the user (eg, usage events, user request events, user response events, and user display events). In addition, if distribution capabilities are supported in the method, the method can display the distribution activity, user-distributor communication about the method, method modification, and which method fields are visible to the distributor. And can support any distribution database checking and recording (eg distribution events, distributor request events, and distributor response events).

Given the generality of existing method structures and the diversity array of possibilities for method assembly, generalized configurations can be used to establish relationships between methods. Since method 1000 may be independent of the object that requests them during any given session, it is not possible to define relationships within those methods themselves. In a preferred embodiment, "control methods" are used to define the relationships between the methods. Control methods can be object-specific and address the requirements of individual objects in each session.

Object control methods establish relationships between other methods. These relationships are parameterized with explicit method identifiers when building a recordset during the registration process that reflects the desired method options for each required method.

An "aggregate method" in a preferred embodiment represents a collection of methods that can be treated as a single unit. For example, a collection of methods for a particular property can be stored within a single set of methods. This kind of aggregation can be useful from a practical point of view. This is because it can reduce the bookkeeping overhead and improve the efficiency of the entire database. In other cases, the methods can be aggregated because they are logically coupled. For example, two budgets may be linked so that one of the budgets represents the overall limit and the second budget represents the limits currently available for use. This can happen, for example, if a large budget is released with a short overtime.

For example, instead of using three separate methods, one set method that includes weighing, billing, and budgeting processes can be used. Such an aggregate method may refer to a single "load module" 1100 that performs all the functions of three separate load modules and uses only one user data element that contains weighing, billing and budget data. By using one aggregate method instead of three separate methods, the total memory requirement, database search, decryption, and number of user data element writes to the secure database 610 can be minimized. The disadvantage of using one aggregate method instead of three separate methods is that there is some loss of flexibility on the part of the provider and the user. This is because it is no longer possible to exchange various functions individually.

Figure 16 shows Method 1000 as part of a secure database 610.

A collection of basic instructions and information about them, the "method" 1000 according to a preferred embodiment is a context used in issuing and / or preparing to perform basic instructions regarding the operation of one or more electronic devices 600. It provides data, requirements and / or relationships. As shown in FIG. 16, the method 1000 in a preferred embodiment is in a secure database 610. C method "core" 1000N, C Method Data Element (MDE) 1202, C User Data Element (UDE) 1200, and C Data Description Element (DTD), Represented by.

The method "core" 1000N in a preferred embodiment may include or reference one or more data elements such as MDE 1202 and UDE 1200. In a preferred embodiment, the MDE 1202 and UDE 1200 may have the same general properties. The main difference between these two types of data elements is that UDE can be tied to a particular method and a particular user or group of users, while MDE can be tied to a particular method but be user-independent. Is. In a preferred embodiment, these MDE and UDE data structures 1200 and 1202 are used to provide input data to method 1000, to receive data output by the method, or both. The MDE 1202 and UDE 1200 can be delivered independently of the method cores 1000N that reference them, or the data structures can be delivered as part of the method cores. For example, the method core 1000N in a preferred embodiment is one or more MDE 1202 and / or UDE. It can have 1200 (or part of it). Method cores 1000N may optionally or additionally reference one or more MDE and / or UDE data structures delivered independently of the method cores that reference them.

The method core 1000N in a preferred embodiment also refers to one or more "load modules" 1100. The load module 1100 in a preferred embodiment may include executable code as well as one or more data structures called "data descriptor" ("DTD") information. This "data descriptor" information may provide, for example, data input information to the DTD interpreter 590. The DTD may allow the load module 1100 to access the MDE and / or UDE data elements 1202 and 1200 (eg, read and / or write).

Method Core 1000'may also refer to one or more DTD and / or MDE data structures that have a description of their behavior in text format suitable for inclusion as part of an electronic contract. References to the DTD and MDE data structures may be made within the secret header of Method Core 1000'or may be specified as part of the event table described below.

FIG. 22 shows an example of the format for Method Core 1000N provided by the preferred embodiment. The method core 1000N in a preferred embodiment has a method event table 1006 and a method local data area 1008. The method event table 1006 lists "events". Each of these "events" refers to a "load module" 1100 and / or PERC 808 that controls the processing of an event. Each event in the above list is associated with any statistical data needed to parameterize the load module 1000 or permission record 808 and the reference to the method user data area 1008 needed to support the event. The data that parameterizes the load module 1100 can, in part, be thought of as a particular functional call to that load module, and the corresponding data element is the input and / or output data for that particular functional call. Can be considered.

The method core 1000N may be specific to a single user or shared among multiple users (eg, depending on the uniqueness of that method core and / or a particular user data element). You may. Specifically, each user / group has its own UDE 1200 and can use the shared method core 1000N. This configuration makes it possible to reduce database overhead compared to associating the entire Method Core 1000N with a single user / group. To allow a user to use a method, that user may be sent a method core 1000N that identifies the UDE 1200. If that method core 1000N already exists in the site's secure database 610, then only UDE 1200 may need to be added. Alternatively, the method can generate any UDE 1200 required at the registration time.

The examples shown in Figure 22 of Method Core 1000N provided by the preferred embodiment are public (unencrypted) header 802, secret (encrypted) header 804, method event table 1006, and method local data. Includes region 1008.

The following table shows an example of possible field layouts for Method Core 1000N Public Header 802.

<tables num="16"><img file="JP4995980B2_D0016.tif" /></tables>

An example of possible field layouts for secret header 804 is shown below.

<tables num="17"><img file="JP4995980B2_D0017.tif" /></tables>

With reference to FIG. 22 again, the method event table 1006 in a preferred embodiment may have 1 to N method event records 1012. Each of these method event records 1012 corresponds to a different event to which method 1000 represented by method core 1000N can respond. Method 1000 in a preferred embodiment can behave quite differently depending on the event it responds to. For example, the AUDIT method may store information in the audit tracking UDE1200 in response to events that correspond to the user's use of objects and other resources. This same AUDIT method sends the stored audit tracking to the VDE administrator in response to management events such as timer expirations within the VDE node and requests from other VDE participants to report audit tracking. Or you can report to other participants. In a preferred embodiment, each of these different events can be represented by an "event code". This "event code" is passed to the method as a parameter when the method is called and can be used to "look up" the appropriate method event record 1012 in the method event table 1006. The selected method event record 1012 will then be used with the appropriate information (eg, load module 1100, data element UDE and MDE1200, 1202 and / or) used to build the component assembly 690 that will be executed in response to the event that occurred. PERC808) is specified.

Thus, in a preferred embodiment, each method event record 1012 may have an event field 1014, an LM / PERC reference field 1016, and any number of data reference fields 1018. In a preferred embodiment, event field 1014 may include an "event code" or other information that identifies the corresponding event. The LM / PERC reference field 1016 is a safety database that identifies load modules 1100 and / or PERC808 that provides (or references) executable code that executes methods in response to events by being loaded and executed. can provide a reference (or other "pointer" information) to a secure database) 610. The data reference field 1018 may contain information that references UDE1200 or MDE1202. These data structures may be contained within the method local data area 1008 of method core 1000N or may be stored as independent deliverables in the safety database 610.

The following table is an example of a more detailed field layout possibility for method event record 1012:

<tables num="18"><img file="JP4995980B2_D0018.tif" /></tables>

Load module FIG. 23 shows an example of a load module 1100 provided in a preferred embodiment. In general, the load module 1100 represents a group of basic functions used for control operations.

The load module 1100 contains code and static data (functionally equivalent to code) and is used to perform the basic operations of the VDE100. The load module 1100 is generally shared by all control structures for all objects in the system, but proprietary load modules are also acceptable. The load module 1100 is passed between VDE participants within the managed object structure 870 and is typically stored in the safety database 610. They are always encrypted and are authenticated in both of these cases. When method core 1000N references load module 1100, the load module is loaded into SPE503, decrypted, passed to the microprocessor of the electronics and executed within HPE655 (if it is where it is executed), or Or it is kept in the SPE (if it is where it runs). If SPE503 is not present, the load module will be decrypted by HPE655 before execution.

The creation of load modules by the party is preferably controlled by the certification process or the ring SPU architecture. In this way, the process of creating a new load module 1100 itself is controlled, as is the process of replacing, updating, or deleting a load module already stored in the secure database 610. It becomes a process.

The load module 1100 can perform its function only when it is run in the protected environment of SPE503 or HPE655. This is because only then is it possible to access the protected elements on which the load module 1100 operates (eg, UDE1200, other load modules 1100). The start of execution of the load module in this environment is tightly controlled by a combination of access tags, validation tags, encryption keys, digital signatures, and / or correlation tags. In this way, the load module 1100 can only be referenced if the caller knows its ID and asserts a shared secret correlation tag specific to that load module. The decryption SPU may match the local access tag of the load module with the identification token after decryption. These technologies make any physical replacement of the load module 1100 detectable at the next physical access of the load module. Further, in a preferred embodiment, the load module 1100 may be "read only". Making the load module 1100 a "read-only" attribute prevents rewriting by a load module that has been tampered with in an unsafe space.

The load module need not be directly controlled by the PERC808 that controls them, nor does it need to contain time / date information or expiration date. The only control consideration in a preferred embodiment is that one or more methods 1000 have a correlation tag (the value of a protected object created by the owner of the load module, their method against an approved party). It is distributed to include and its access and use is controlled by one or more PERC808). If method core 1000N references load module 1100 and asserts the correct correlation tag (and the load module satisfies SPE503's internal tampering check), the load module can be loaded and executed. , Or it can be obtained from another system, sent to another system, updated or deleted by another system.

As shown in FIG. 23, the load module 1100 in a preferred embodiment includes a public (unencrypted) header 802, a secret (encrypted) header 804, a secret body 1106 containing encrypted executable code, and one. It may consist of the above data description element (DTD) 1108. The DTD1108 may be stored in the load module 1100 or may be a reference to a static data element in the safety database 610.

The following is an example of a possible field layout for load module public header 802:

<tables num="19"><img file="JP4995980B2_D0019.tif" /></tables>

Many load modules 1100 contain code that runs on SPE503. There is also a load module 1100 that contains code that runs on the HPE655. This allows Method 1000 to run in either environment. For example, the INFORMATION method 1000 may be constructed to run only in the SPE503 safe space for government-class safety, or only in the HPE655 for commercial applications. As mentioned above, the public header 802 may include an "execution space code" field that indicates where the load module 1100 should be executed. This functionality allows for different SPE instruction sets as well as different user platforms, allowing methods to be built independently of the underlying load module instruction set.

The load module 1100 operates on three main data areas. That is, the stack, load module parameters, and data structures. The stack and execution memory size required to execute the load module 1100 is preferably described in the secret header 804, as well as the load module call, the stack image on return, and the data description from any return data area. Stacks and dynamic regions are described using the same DTD mechanism. The following is an example of a possible field layout for load module secret header 1104:

<tables num="20"><img file="JP4995980B2_D0020.tif" /></tables>

Each load module 1100 may also use DTD1108 information to provide the information needed to support building methods from the load module. This DTD information includes the definitions of the names and data types of all method data fields supported by the load module, expressed in languages such as SGML, and the acceptable range of values that can be placed in the fields. Other DTDs may describe the functionality of the load module 1100 in English, for example for inclusion in electronic contracts.

The next section of the load module 1100 is an encrypted executable body 1106 that contains one or more blocks of cryptographic code. The load module 1100 is preferably coded with a "native" instruction set in its execution environment for efficiency and compactness. The SPU500 and platform providers may offer various versions of the standard load module 1100 so that their products can cooperate with the content of the distribution mechanism considered in the VDE100. In a preferred embodiment, a native mode load module 1100 is created and used rather than an interpreted or "p-code" solution to optimize the performance of a finite resource SPU. However, when sufficient SPE (or HPE) resources are present and / or when the platform has sufficient resources, these other implementation approaches improve the cross-platform usefulness of the load module code.

The following is an example field layout for the load module DTD1108:

<tables num="21"><img file="JP4995980B2_D0021.tif" /></tables>

An example of how the load module 1100 can use the DTD1108: C Increment the value of the data element in the data area DTD4 (defined by the name in DTD3) by the value in DTD1 C Set the value of the data element in the data area DTD4 (defined by the name in DTD3) to the value in DTD3 C Calculates the atomic element from the event in DTD1 from the table in DTD3 and returns it in DTD2 C Calculates the atomic element from the event in DTD1 from the equation in DTD3 and returns it in DTD2 Create a load module from the load module creation template referenced in C DTD3 Modify the load module in DTD3 with the content in C DTD4 C Destroy a load module named in DTD3 Commonly used load modules 1100 may be built into the SPU500 where space allows. The VDE process with the built-in load module 1100 shows significantly improved performance over the process that has to find, load and decrypt the external load module. The most useful load modules 1100 that can be built into the SPU are scaler meters, fixed-price billing, budgeting, and load modules for the aggregate method that performs these three processes. ..

User data element (UDE) 1200 and method data element (MDE) 1202 User data element (UDE) 1200 and method data element (MDE) 1202 in a preferred embodiment store data. There are many types of UDE1200 and MDE1202 provided in preferred embodiments. In a preferred embodiment, each of these different types of data structures shares a common overall format, including common header definitions and naming schemes. Other UDE1200s that share this common structure include a "local name service record" (discussed immediately below) and account information for connecting to other VDE participants. These elements are not necessarily associated with individual users and may therefore be considered MDE1202. All UDE1200 and all MDE1202 provided in the preferred embodiment may be stored in a common physical table in the safety database 610 if desired (as shown in FIG. 16), and the database access process. May be commonly used for access to all of these different types of data structures.

In a preferred embodiment, the PERC808 and user rights table records are of the UDE1200 type. There are many other types of UDE1200 / MDE1202, including, for example, weighing, weighing tracking, budgeting, budget tracking, and audit tracking. Different formats for these different types of UDE / MDE are defined by the SGML definition contained in DTD1108, as described above. Method 1000 uses these DTDs to properly access the UDE / MDE1200, 1202.

The safety database 610 stores two types of items. That is, it is static and dynamic. Static data structures and other items are used for virtually static information. It contains the load module 1100, PERC808 and many components of the method. These items are not updated frequently and contain an expiration date, which can be used to prevent "old" copies of information from being replaced by newly received items. These items may be encrypted using a site-specific safety database file key when stored in the security database 610 and decrypted using that key when loaded into the SPE.

Dynamic items are used to support safe items that must be updated frequently. The UDE1200 for many methods must be updated and written out from SPE503 after each use. Weighing and budgeting are common examples of this. Expiration dates cannot be effectively used to prevent replacement by previous copies of budget UDE1200. To secure these frequently updated items, transaction tags are generated and included in the encrypted item each time the item is updated. A list of all VDE item IDs and the current transaction tag for each item is maintained as part of safety database 610.

FIG. 24 is an example of a User Data Element (UDE) 1200 provided in a preferred embodiment. As shown in FIG. 24, the UDE 1200 in a preferred embodiment has a public header 802, a secret header 804, and a data area 1206. The layout of each of these user data elements 1200 is generally defined by the SGML data definitions contained within the DTD1108 associated with one or more load modules 1100 running on the UDE1200.

The UDE1200 is preferably encrypted with a site-specific key once it is loaded into the site. This site-specific key masks validation tags that can be obtained from a cryptographically strong pseudo-random sequence by SPE503 and updated each time a record is written back to safety database 610. To do. This technology provides a reasonable guarantee that the UDE1200 will not be tampered with or replaced the next time it is requested by the system.

Weighing and budgeting are probably the most commonly found data structures in the VDE100. These are used to count and record events and to limit events. The data structure for each measure and budget is determined by the content provider or distributor / redistributor authorized to change the information. However, weigh-in and budget generally have common information stored in a common header format (eg, user ID, site ID and related identifying information).

The content provider or distributor / redistributor may specify a data structure for each metric and budget UDE. These data structures can change depending on the particular application, but some have a high degree of commonality. The following table lists some of the common data structures in the METER and BUDGET methods:

<tables num="22"><img file="JP4995980B2_D0022.tif" /></tables>

The information in the above tables is not complete or inclusive and is intended to provide some examples of the types of information that can be stored in metric and budget related data structures. The actual structure of a particular metric and budget is determined by one or more DTD1108s associated with the load module 1100 that creates and manipulates that data structure. The list of data types allowed by the DTD interpreter 590 in the VDE100 is extensible to a properly approved party.

FIG. 25 shows an example of a particularly advantageous type of UDE1200 data area 1206. This data area 1206 defines a "map" that can be used to record usage information. For example, the weighing method 1000 is one or more "usage maps". map) Data area 1206 may be maintained. A usage map can be a "bitmap used" in the sense that it stores one or more bits of information (ie, a single-dimensional or multidimensional bit image) that corresponds to each use of several types or categories. Usage maps are an efficient way to refer to previous uses. For example, the usage map data area can be used by the metric method 1000 to record all relevant parts of the information content paid for use by the user, which later leaves the same part of the information content. It supports a very efficient and flexible means of enabling users to use it. This can enable certain VDE-related security features such as "contiguousness", "logical relevance", "randomization of use" and other usage types. Usage maps are also analyzed for other usage patterns (eg, volume discounting, which allows a user to re-access information content that has been paid for unlimited use in the past). obtain.

The "use map" concept provided by the preferred embodiment can be linked to the concept of "atomic element". In a preferred embodiment, the use of the object 300 can be measured in "atomic element" units. In a preferred embodiment, an "atomic element" in a metric context defines a unit of use that is "significant enough" to be recorded in the metric. The definition of what constitutes an "atomic element" is determined by the creator of object 300. For example, one "byte" of information content contained in object 300 may be defined as an "atomic element", one record in a database may be defined as an "atomic element", or it may be published electronically. Each chapter of the book may be defined as an "atomic element".

Object 300 may have a set of multiple atomic elements that overlap each other. For example, access to any database in multiple databases may be defined as an atomic element. At the same time, access to any record, record field, sector of information, and / or bytes contained in any of the databases can also be defined as an "atomic element". In the case of electronically published newspapers, every 100 words of one article may be defined as an "atomic element", while articles longer than a certain length may be defined as another set of "atomic elements". Some parts of the newspaper (eg public notices, job listings, etc.) may not be mapped to atomic elements.

A preferred embodiment provides virtually unlimited capabilities for the creator of an object with respect to the definition of atomic element types. The definition of such an atomic element can be very flexible to include a variety of different content uses. Examples of atomic element types supported in a preferred embodiment are bytes, records, files, sectors, objects, a fixed amount of bytes, continuous or relatively contiguous bytes (or other predefined). There are logically related bytes, including some logical relationship, depending on the unit type), topic, location, or other user-specified logical relationship. Content authors preferably have the flexibility to define other types of atomic elements.

A preferred embodiment of the present invention provides an EVENT method to provide a mapping between usage events and atomic elements. In general, there can be one EVENT method for each of the different sets of atomic elements defined for object 300. In many cases, the object 300 detects at least one type of atomic element for billing-related weighing and at least another type of atomic element for non-billing-related weighing (eg, fraud detection). (Used to charge advertisers, and / or collect data about end-user behavior).

In a preferred embodiment, each EVENT method in the usage-related context serves two functions: (1) mapping the accessed event to a set of zero or more atomic elements, and (2) measuring object usage. To provide information to one or more METER methods for. The definition used to define the mapping between this access event and the atomic element can take the form of a mathematical definition, table, load module, or other form. When the EVENT method maps an access request to "zero" atomic elements, the event accessed by the user is not mapped to any atomic element based on the particular applicable atomic element definition. This is the case, for example, if the owner of the object is not interested in weighing usage based on such access (for example, because the owner of the object considers such access to be insignificant in terms of weighing). possible.

The "usage map" may use a "bitmap image" in order to store usage history information with high efficiency. Each storage element in the usage map can correspond to an atomic element. Different elements in one usage map can correspond to different atomic elements (eg, one map element corresponds to the number of bytes read and another map element corresponds to whether a particular chapter was opened or not. Corresponding, yet another map element may correspond to other usage events.) One of the features of the usage map provided in a preferred embodiment of the present invention is that the importance of the map element is specified, at least in part, by its position in the usage map. Thus, in the usage map provided in a preferred embodiment, the information presented or encoded by the map element is a function of its position (physical or logical) in the map structure. .. As a simple example, a 12-chapter usage map for a novel may consist of 12 elements, one element for each chapter of the novel. When the user opens Chapter 1, one or more bits in the element corresponding to Chapter 1 can be changed in value (eg set to "1"). In this simple example, if the owner of a content object, including a novel, is only interested in weighing which chapter was opened by the user, then the user sets the corresponding chapter to the usage map element that corresponds to that chapter. It can be set to "1" when first opened and kept at "1" no matter how many more times the user opens the chapter. The owner of the object or any other interested VDE participant can open which chapter (s) by the user by simply examining the compact usage map to determine which element is set to "1". You can know who was killed quickly and efficiently.

Suppose the owner of a content object wants to know how many times a user has opened each chapter of a novel. In this case, the usage map may contain 12 elements, such that in the case of a 12-chapter novel, each has a one-to-one correspondence with a different one of the 12 chapters of the novel. Each time the user opens a particular chapter, the corresponding METER method can increment the value contained in the corresponding usage map element. In this way, an account can be easily maintained for each chapter of the novel.

The position of the element in the usage map may encode a multivariable function. For example, the elements in the usage map may be arranged in a two-dimensional array as shown in Figure 25B. The different array coordinates may correspond to independent variables such as atomic elements and time. As an example, suppose the owner of a content object distributes an object that contains a collection of audio recordings. In addition, the owner of the content object wants to track the number of times the user listens to each recording in the collection, and to track the monthly usage. Therefore, the content object owner wants to know how many times the user listened to the recording for each recording during January, as well as this same information for February, March, etc. And. In this case, the usage map (see Figure 25B) can be defined as a two-dimensional array of elements. One dimension of the array may encode the audio recording number. Another dimension of the array may encode the moon. During January, the corresponding METER method increments the elements in the array in the "January" column in the array and selects which element to increment as a function of the recording number. When January comes to an end, the METER method stops writing to the array element in the January column and instead writes the value to another set of array elements for February--again in this column. Select a specific array element in as a function of recording number. This concept can be extended to N dimensions, which encode N different variables.

Usage map metric is thus an efficient means of referencing previous use. Usage map metrics include testing for continuity (including relative continuity), testing for logical relevance (including relative logical relevance), randomization of use, and other usage patterns. , Can enable some VDE related security features. For example, the degree or nature of the "randomness" of content use by a user can serve as a potential indicator of attempts to avoid VDE content budget limits. Users or groups of users can use multiple sessions to reconstruct substantive or all of a given valuable content unit without violating continuity, logical relevance, or quantity limits. You might try to extract the content in this way. For example, the amount of information content that a user has paid for unlimited access (or unlimited access within a certain amount of time) in the past, that is, the amount of unlimited access after use of a certain amount of any or a particular atomic unit. You can analyze your usage map to determine other patterns of usage for pricing, such as allowing you to re-access to. Another useful analysis is counting for multiple uses for a given atomic unit.

A further example of map weighing is a record of all applicable atomic elements that the user has paid for use (or has been weighed for use--even if payment or billing has not yet been made). May be stored. Such a usage map can support a very efficient and flexible means of allowing the same atomic element to be used later by the user.

Further use map, fraudlent of the same object Usage) can be maintained to detect. For example, objects can be stored so that sequential access to long blocks never occurs. The METER method then records all applicable atomic element access, for example, during any specified time increment (eg 10 minutes, 1 hour, 1 day, 1 month, 1 year or other period). be able to. At the end of the specified time increment, the usage map is analyzed to check for unusually long contiguous sets of blocks accessed, and / or to each of the usage maps to the applicable atomic element. It can be analyzed at the start of access. If no abuse is detected after each period-based analysis, the usage map can be cleared (or partially cleared) and the entire or part of the mapping process can be started anew. If unauthorized use is suspected or detected, the information can be recorded and the object can be decommissioned. For example, the user may be required to contact the content provider. The content provider then further analyzes the usage information to determine whether further access should be granted.

Figure 25c shows a particular type of "wide bitmap" usage record 1206. Here, each entry in the usage record corresponds to usage during a particular time period (for example, this month's usage, last month's usage, last month's usage, etc.). As such, the illustrated use record comprises an array of "flags" or field 1206, and each element in the array is used to indicate use in different time periods in this particular example. At the end of a period, by shifting all elements 1206 in the array by one position, usage information (or purchase of user access rights) in a series of multiple periods can be reflected in a series of continuous array elements. In the particular example shown in Figure 25c, the entire wide array 1206 is shifted by one array position each month, the oldest array element is removed, and a new array element is inserted into the new array map corresponding to the current period ("" turned " in). In this example, record 1302 tracks use access rights and / or use-related behaviors during this month of the calendar and the five months immediately preceding this month. The corresponding billing and / or billing method 406 inspects the map and decides to use it in connection with billing and / or security monitoring for current usage based on formulas that use usage data stored in records. Then update the wide record to indicate the relevant array element, such as when a use has occurred. Wide bitmaps can be used for many other purposes, such as maintaining element-by-element usage counts, or the above-mentioned functions such as continuity, relevance, or a combination of functions.

Audit tracking maps can be generated at any frequency determined by control, weighing, budgeting, and billing methods, as well as the load modules associated with these methods. Audit tracking has a structure similar to weighing and budgeting, and includes user-specific information in addition to information about the usage event that caused the audit tracking to be generated. Similar to weighing and budgeting, audit tracking has a dynamic format defined by the content provider or its authorized designee and shares the basic element type with the weighing and budgeting shown in the table above. doing. In addition to these types, the following table gives examples of other important data fields found in audit tracking:

<tables num="23"><img file="JP4995980B2_D0023.tif" /></tables>

Audit tracking records may be automatically combined into a single record to leave header space. The join process can occur, for example, under the control of a load module that creates individual audit tracking records.

Overview of permission records Figure 16 also shows that PERC808 can be stored as part of safety database 610. The permission record (PERC) 808 is located at the highest level of the data-driven control hierarchy provided by the preferred embodiment of VDE100. Basically, there is at least one PERC808 for each information and / or transaction content distributed by VDE100. Therefore, in a preferred embodiment, there is at least one PERC808 for each VDE object 300. Some objects have multiple corresponding PERC808s. PERC808 controls how access and / or operational permissions are distributed and / or how content and / or other information is used elsewhere. PERC808 also specifies the "rights" of VDE participants in or to content and / or other information.

In a preferred embodiment, no end user shall use or access the VDE object unless permission record 808 has been delivered to that end user. As mentioned above, the PERC808 is delivered as part of the traveling object 860, or separately (eg, within a managed object). The electronic device 600 must not access the object in the absence of the corresponding PERC808 and can only use the object and related information permitted by the control structure contained in the PERC.

Simply put, PERC808 stores information about methods, method options, decryption keys and rights for the corresponding VDE object 300.

PERC808 contains control structures that define high-level movement categories or classifications. These high-level categories are called "rights". The "rights" control structure itself provides an internal control structure that references "method" 1000. The internal structure in PERC808 of a preferred embodiment organizes the "methods" required to perform each of the actions allowed for an object or associated control structure (including actions performed on the PERC itself). .. For example, PERC808 contains a decryption key for an object, and the use of the key is controlled by the methods that PERC requires to perform actions related to the exercise of "rights".

A PERC808 for an object is typically created when the object is created, and any substantial modification of PERC in the future is defined by the same (or different) PERC, if allowed, by the methods associated with the behavior. It is controlled using the distribution rights (s) that are granted.

FIG. 22 shows the internal structure present in an example of PERC808 provided in a preferred embodiment. All of the illustrated structures represent (or reference) a collection of methods needed to process the corresponding object in a particular way. PERC808 is organized as a hierarchy, and the basic elements of that hierarchy are: "Rights" record 906 "Control set" 914 Required methods record 920 and Required Method Options 924.

There are other elements that can be included in the PERC808 hierarchy that describe rules and rule options to support rule set negotiation, as well as control information to protect smart objects and user personal information with privacy filters. .. These other elements may include: Option rights record Optional control set Optional method record Rights record with permissions Permissioned rights control set Permission-granted method record Required DTD description Optional DTD description Permission-granted DTD description These separate fields may control other processes that form the basis of negotiations or decisions about their behavior with respect to the content of these fields. Rights negotiations, smart object control information, and related processes may use these fields for more precise control of their behavior.

The PERC808 shown in FIG. 26 includes a PERC header 900, CS0 (control set 0) 902, a private body key 904, and one or more rights subrecords 906. The control set 0902 in a preferred embodiment contains information common to one or more "rights" associated with the object 300. For example, a particular "event" method or methods may be identical for usage rights, extraction rights and / or other rights. In this case, "control set 0" 902 may refer to this event in common across multiple "rights". In practice, it is possible to store different instances of commonly used events within each of multiple "rights" records 906 of PERC808, so the provision of "control set 0" 902 is an optimization. ..

Each rights record 906 defines one different "right" that corresponds to one object. "Rights" record 906 is the highest level of organization existing in PERC808. There can be several different rights within PERC808. "Rights" are the main functional divisions desired by participants in the VDE100 basic architecture. represents partition). For example, the right to use an object and the right to distribute the right to use an object form a major functional group within the VDE100. Examples of possible rights are access to content, the right to distribute permissions to access content, the ability to read and process audit tracking related to content and / or control structures, content and / or related controls. The right to conduct transactions related to or not related to the structure (banking transactions, catalog purchases, tax collection, EDI transactions, etc.), and all or part of the internal structure of PERC created for distribution to other users. Has the ability to change. PERC808 includes rights record 906 for each type of object access / use rights granted by PERC.

Usually, for VDE end users, the most frequently granted right is the right to use. Other types of rights include "extraction rights", "audit rights" to access end-user audit tracking information, and "distribution rights" to distribute objects. Each of these types of rights can be realized in the form of different rights record 906 (or different PERC808s corresponding to one object may be used to grant different rights).

Each rights record 906 has a rights record header 908, a CSR (control set for rights) 910, one or more right keys 912, and one or more control sets 914. Each "right" record 906 has one or more control sets 914 that are mandatory or selectable options for controlling an object in exercising that "right". Therefore, at the next level, inside "Rights" 906, there is a control set 914. Each control set 914 itself has a control set header 916, a control method 918, and one or more required method records 920. Each required method record 920 itself has a required method header 922 and one or more required method options 924.

In VDE100, there are two types of control sets 914: a common mandatory control set that is given a digitizer called "control set 0" or "control set for rights" and a set of control set options. "Control set 0" 902 includes a list of required methods common to all control set options so that commonly required methods do not have to be duplicated within each control set option. The "Control Set for Rights (" CSR ")" 910 contains a similar list of control sets within a given right. "Control set 0" and any "control set for rights" are therefore referred to as optimizations, as described above. The same functionality can be achieved for a control set by listing all common required methods in each control set option and omitting "control set 0" and any "control set for rights".

One of the control set options, "Control set 0", and the appropriate "Control set for rights", together form the complete control set required to exercise the rights.

Each control set option contains a list of mandatory methods 1000 and represents different ways in which rights can be exercised. Only one of the possible full control sets 914 is used for any one exercise of rights in a preferred embodiment.

Each control set 914 contains as many required method records 920 as necessary for the creator and / or distributor to meet all the requirements for exercising their rights. Both multiple ways in which a right can be exercised or multiple sets of controls governing the way a given right is exercised are supported. As an example, a single control set 914 may require multiple weighing and budgeting methods to read the content of an object, and different weighing and budgeting to print the content of an object. Both reading and printing the contents of an object can be controlled in a single control set 914.

Alternatively, two different control set options also support weighing and budgeting the number of bytes read using one control set option, and weighing and budgeting the number of paragraphs read using the other control set option. By supporting budgeting, you can support reading the content of an object. At one point in time one or the other of these options becomes active.

Typically, each control set 914 references one set of related methods, so different control sets may provide different sets of method options. For example, one control set 914 may represent one type of distinct metric methodology, and another control set may represent another completely different metric methodology.

At the next level, inside the control set 914, there is a required method record 920. In a preferred embodiment, method record 920 includes or references method 1000. Method 1000 is a collection of "events", references to load modules associated with these events, static data, and any other separately derivable data elements (eg UDE) that may be needed to handle the events. A reference to the safety database 610 for automatic retrieval of. Control set 914 contains a list of mandatory methods that must be used to exercise a particular right (ie, a rights-related processing event). Required method record 920, listed in control set 914, indicates that there must be a method for exercising the rights supported by the control set. For required methods, refer to "Load Module" 1100 described below. Simply put, the load module 1100 is a piece of executable code that can be used to execute required methods.

Each control set 914 may have control method record 918 as one of its mandatory methods. The referenced control methods may define relationships between some or all of the various methods 1000 defined by control set 906. For example, control methods can indicate which mandatory methods are functionally grouped together to handle a particular event, and the order in which to handle the mandatory methods. Therefore, the control method is the one in which the required method referenced by record 920 (a) (1) (i) is called first, and its output is referenced by record 920 (a) (1) (ii). You can specify things like go to the required methods. In this way, the metric method can be tied to one or more billing methods, and the billing methods can be individually tied to different budget methods and the like.

Required method record 920 specifies one or more required method options 924. The required option is the lowest level of control structure in PERC808 in a preferred embodiment. By parameterizing the required methods and specifying the required method option 924 independently of the required methods, the required methods can be reused in many different situations.

For example, mandatory method record 920 may indicate that the actual budget method ID must be chosen from the list of budget method IDs in the mandatory method options list for that mandatory method. The required method record 920 in this case does not include the method ID for information about the type of required method and only indicates that a method is required. Required method option 924 contains the method ID of the method used if this required method option is selected. As a further optimization, the actual method ID may be stored if there is only one option for a particular required method. This reduces the size of this data structure.

PERC808 also contains a basic decryption key for object 300 and any other "rights" (eg, for encoding and / or decoding audit tracking). .. It may include a key to decrypt the object content or a key to decrypt a part of the object, including other keys that can be used to decrypt the content of the object. Key use is controlled by control set 914 in the same "rights" 906 in PERC808.

More specifically, the PERC808 shown in FIG. 26 includes a secret body key 904 and a rights key 912. The secret body key 904 is used to decrypt the information contained in the secret body key 806 of the corresponding VDE object 300. Such information includes, for example, method 1000, load module 1100 and / or UDE1200. The right key 912 is a key used to exercise a right in a preferred embodiment. Such a key 912 includes, for example, an encryption key that allows the method specified by PERC808 to decrypt the content and release it to the end user by the VDE node. These rights keys 912 are unique to object 300 in a preferred embodiment. In a preferred embodiment, its use is preferably budget controlled. Detailed example of PERC808 26A and 26B show an example of PERC808 in a preferred embodiment. In this example, PERC header 900 has: Site record number 926, Field 928, which specifies the length of the secret body key block, Field 930, which specifies the length of PERC, Expiration date / time field that specifies the expiration date and / or time of PERC 932, Last modified date / time field 934, which specifies the last day and / or time when PERC808 was modified, Original Distributor ID field 936, which specifies who originally distributed the PERC and / or corresponding objects. Last Distributor field 938, which specifies who was the last distributor of the PERC and / or object. Object ID field 940, which identifies the corresponding VDE object 300, Field 942, which specifies the class and / or type of PERC and / or instance ID for the record class to distinguish between PERCs of the same type that may differ in the partsiculars. Field 944, which specifies the number of "rights" subrecords 906 in PERC, and Validity test tag 948.

The PERC808 shown in FIGS. 26a and 26b also has a secret body key stored in the secret body key block 950.

This PERC808 has a control set 0 subrecord 914 (0) commonly used by all rights 906 within the PERC. This control set 0 record 914 (0) may have the following fields: Control set 0 Length field 952 that specifies the length of the record Field 954 that specifies the number of required method records 920 in the control set Access tag fields 956 and access tag fields that specify access tags to control record modification One or more required method records 920.

Each required method record 920 may itself have: Required Method Length field 958 that specifies the length of the record Field 960 that specifies the number of method option records for the required method record 920 Access tag fields 962 and specify access tags to control record modification One or more required method option records 924.

Each method option subrecord 924 may have: Length field that specifies the length of the method option record 964 Length field 966 that specifies the length of the data area (if any) that corresponds to the method option record Method ID field 968 that specifies the method ID (eg type / owner / class / instance) Correlation tag field 970 that specifies the correlation tag to associate with the method specified in field 968 Access tag field 972 to specify an access tag to control the modification of this record Method-specific attribute field 974 Data area 976 and Check value field 978 for validation The PERC808 in this example also has one or more rights records 906 and an overall check value field 980. FIG. 23b is an example of the rights record 906 shown in FIG. 16a. In this particular example, rights record 906a has rights record header 908 with: Length field 982 that specifies the length of rights key block 912 Length field 984 that specifies the length of rights record 908 Expiration date / time field 986 that specifies the expiration date and / or time of the rights record Rights ID field 988 that identifies the right Number fields 990 that specify the number of control sets 914 in rights record 906, and Access tag field 992 that specifies the access tag to control the modification of the rights record.

Right record 906 of this example has: Control Set (CSR) 910 for this right Rights key block 912 One or more control sets 914, and Check value field 994. Object registry With reference to Figure 16 again, the safety database 610 provides a data structure that supports a "lookup" mechanism for "registered" objects. This "lookup" mechanism allows electronics 600 to associate the VDE object 300 with PERC808, method 1000 and load module 1100 in a secure manner. In a preferred embodiment, this lookup mechanism is based in part on the data structure contained within the Object Rigidity 450.

In one embodiment, the object re Soo bird 450 has the following tables: -Object registration table 460; -Subject table 462; -User rights table ("URT") 464; · Administrative event log 442; · Shipping table 444; and · Receiving table 446.

The object registry 460 in this embodiment is a database of information about the registered VDE objects 300 and the rights of users and user groups with respect to these objects. When electronics 600 receive an object 300 containing a new budget or load module 1100, the electronics typically need to add the information contained in the object to the safety database 610. Also, when any new VDE object 300 arrives at the electronics 600, the electronics must make the object accessible by "registering" with the object registry 450. The list and record for the new object 300 is, in a preferred embodiment, constructed when the object is "registered" by the electronic device 600. Information about the object can be obtained from the object's encrypted secret header, the object body, and the encrypted name service record. This information may be derived or extracted from object 300 by SPE503 and may then be stored as an encrypted record in safety database 610.

In one embodiment, the object registration table 460 has an information identification object in an object storage (repository) 728. These VDE objects 300 stored in the object storage section 728 are not a necessary part of the safety database 610 in this embodiment. This is because objects typically introduce their own security (if needed) and are maintained using a mechanism different from that used to maintain a safety database. The VDE object 300 may not be strictly part of the safety database 610, but the object registry 450 (and especially the object registration table 460) refers to the object, resulting in the object being a safety database. It will be "incorporated" within 610. In a preferred embodiment, the electronic device 600 can be disabled by storing the corresponding registration record in the object registration table 460 to use the object 300 which is not properly registered.

The subject table 462 in this embodiment establishes a correspondence between the object referenced by the object registration table 460 and the user (or user group) of the electronic device 600. Subject table 462 provides many of the attributes of an access control list (ACL), as described below.

User rights table 464 in the embodiment provides permissions and other information specific to a particular user or user group, as well as a combination of objects described in subject table 462. In an example embodiment, the permission record 808 (also shown in FIG. 16 and stored in the safety database 610) may provide a universe of permissions for a particular object-user combination. The records in the user rights table 464 may specify a subset of this entire permission, for example, based on the choices made by the user during the interaction during object registration.

The administrative event log 442, the shipping table 444, and the receiving table 446 provide information about the receipt and delivery of the VDE object 300. These data structures follow administrative objects sent and received by electronic device 600, including, for example, simplified and detailed forms of the purpose and behavior of administrative objects. In short, the shipping table 444 contains a shipping record for each administrative object that has been (or is scheduled to be) sent to another object participant by electronics 600. The reception table 446 in a preferred embodiment includes a reception record for each management object received (or scheduled to be received) by electronic device 600. The administrative event log 442 may include event log records for each sent administrative object and each received administrative object, and may include details about each different event specified by the received administrative object.

Administrative object shipping and receiving FIG. 27 shows an example of a detailed format for shipping table 444. In a preferred embodiment, the shipping table 444 includes a header 444A and any number of shipping records 445. Header 444A contains information used to maintain shipping table 444. Each shipping record 445 in the shipping table 444 provides details about the shipping event (ie, whether it is a completed shipment of the administrative object to another VDE participant or a scheduled shipment of the administrative object. ).

In the safety database 610 of this embodiment, the shipping table header 444A is a site record number 444A (1), a user (or group) ID 444A (2), a series of reference fields 444A (3) to 444A (6), It may include validation tags 444A (7) to 444A (8), and check value fields 444A (9). A series of reference fields 444A (3) to 444A (6) refer to a particular recent ID that digitizes the list of shipping records 445 in shipping table 444. For example, field 444A (3) is outgoing the completed administrative object. Referencing the "first" shipping record representing shipping), field 444A (4) may refer to the "last" shipping record representing the completed departure side shipping of the administrative object. In this example, "first" and "last" may, as desired, refer to the time or order of shipment, as an example. Similarly, fields 445A (5) and 444A (6) may refer to the "first" and "last" shipping records of the scheduled departure party shipment. The validation tag 444A (7) may provide validation from the name service record in the name service record table 452 corresponding to the user (group) ID in the header. This allows access from the shipping record back to the name service record that describes the sender of the object described in the shipping record. The validation tag 444A (8) provides validation for the "first" departure shipping record referenced by one or more pointers 444A (3) to 444A (6). Other validation tags may be provided for validation of scheduled shipping records.

The illustrated shipping record 444 (1) includes site record numbers 445 (1) (A). It also contains the first and last scheduled shipping dates / times 445 (1) (B), 445 (1) (C), and provides a window of times used to schedule administrative object shipments. Fields 445 (1) (D) specify the actual date / time of the completed shipment of the administrative object. Fields 445 (1) (E) identify which administrative object in object storage 728 belongs to this particular shipping record by providing the ID of the administrative object that was or should be shipped. To do. Reference fields 445 (1) (G) provide a name service record that specifies the actual or intended recipient of the administrative object that was or should be shipped in the name service record table 452. refer. This information in the name service record table 452 informs object switch 734, for example, that the starting administrative object manager 754, shown in Figure 12, sends the administrative object to its intended recipient. Sufficient routing information may be provided to make this possible. Fields 445 (1) (H) can specify the purpose of the shipment of the administrative object (eg, using a set of bit flags), and fields 445 (1) (I) can specify the status of the shipment. Reference fields 445 (1) (J), 445 (1) (K) may refer to "previous" and "next" shipping records 445 in the linked list (in a preferred embodiment, one has completed). There may be two linked lists, one for the shipping record and one for the scheduled shipping record). Fields 445 (1) (L) to 445 (1) (P) go to the record in the management event log 442 pointed to by the validation tag, pointer 445 (1) (F), respectively, from header 444A. Validity check tag, field 445 ( 1) Validity check tag to the name service record referenced by (G), validation tag from the previous record referenced by 445 (1) (J), and reference by field 445 (1) (K). A validity check tag for the next record to be created may be provided. Check value fields 445 (1) (Q) may be used to check the validity of shipping record 445.

FIG. 28 shows an example of one possibility of the detailed format of receive table 446. In one embodiment, the receiving table 446 has a structure similar to that of the shipping table 444 shown in FIG. 27. Thus, for example, the receive table 446 may have a header 446a and a plurality of receive records 447, each containing details about a particular receive or scheduled receive of the administrative object. Reception table 446 may include two linked lists, one for completed reception and the other for scheduled reception. Each inbound table record 447 may refer to an entry in the name service record table 452 that specifies the sender of the administrative object and may point to each entry in the administrative event log 442. Receipt record 447 may also include additional details regarding scheduled and / or completed receipts (eg, scheduled or actual receipt date / time, purpose of receipt, and status of receipt). Each may also include a validation tag to validate a reference to a record in another safety database.

FIG. 29 shows an example of the detailed format of the administrative event log 442. In a preferred embodiment, the administrative event log 442 has event log records 442 (1) ... 442 (N) for each sent administrative object and each received administrative object. Each administrative event log record may have a header 443a and subrecords 442 (J) (1) ... 442 (J) (N) from 1 to N. In a preferred embodiment, the header 443a is a site record number field 443A (1), a record length field 443A (2), an administrative object ID field 443A (3), a field 443A (4) that specifies the number of events, a shipping table 444. Alternatively, it may have a validation tag 443A (5) from receive table 446 and a checksum field 443A (6). The number of events specified in field 443A (4) corresponds to the number of subrecords 442 (J) (1) ... 442 (J) (N) in the administrative event log record 442 (J). Each of these subrecords specifies information about a particular "event" that is affected or corresponds to the administrative object specified in fields 443 (A) (3). Administrative events are kept in the administrative event log 442, allowing the reconstruction (and preparation for construction or processing) of administrative objects sent or received from the system. This allows the lost administrative object to be reconstructed later.

Each sub-record contains a sub-record length field 442 (J) (1) (a), a data area length field 442 (J) (1) (b), an event ID field 442 (J) (1) (c), and a record. Type field 442 (J) (1) (d), record ID field 442 (J) (1) (e), data area field 442 (J) (1) (f), and check value field 442 (J) ( 1) It may have (g). In the data area 442 (J) (1) (f), what information in the safety database 610 is affected by the event specified in the event ID field 442 (J) (1) (c), or what It can be used to indicate if a new safety database item has been added, and the result of the event may be specified.

The object registration table 460 in a preferred embodiment includes records corresponding to each VDE object 300 in the object storage unit (storage location) 728. When a new object arrives or is detected (eg, by a redirector 684), the electronic device 600 in a preferred embodiment creates an appropriate object registration record and stores it in the object registration table 460. , "Register" the object. In a preferred embodiment, the object registration table stores information that is user-independent and depends only on the objects registered in a given VDE electronics 600. The registration behavior is typically managed by the REGISTER method associated with the object.

In this example, subject table 462 associates a user (or group of users) with a registered object. Subject table 462 in the example acts as an access control list by specifying which users are authorized to access which registered VDE object 300.

As mentioned above, the safety database 610 stores at least one PERC808, which corresponds to each registered VDE object 300. PERC808 specifies a set of rights that can be exercised to use or access the corresponding VDE object 300. In a preferred embodiment, the user selects a subset of the rights granted by the corresponding PERC808 and / or by specifying parameters or selections corresponding to some or all of the rights conferred by the PERC808. It is possible to "customize" that access right. These user choices are described in the user rights table 464 in a preferred embodiment. The user rights table (URT) 464 has URT records, each corresponding to one user (or user group). Each of these URT records specifies a user selection for the corresponding VDE object 300. These user selections, either independently or in cooperation with PERC808, use one or more methods 1000 to exercise the rights granted to the user by PERC808 in the manner specified by the selection contained within the URT record. Can be referred to.

FIG. 30 is an example showing how these various tables interact with each other to provide a safety database lookup mechanism. The object registration table 460 illustrated in FIG. 30 has a plurality of object registration records 460 (1), 460 (2), .... These records correspond to VDE objects 300 (1), 300 (2) ... stored in the object storage location 728. FIG. 31 shows an example of the format of the object registration record 460 provided by the preferred embodiment. Object registration record 460 (N) may contain the following fields: Site record number field 466 (1) Object type field 466 (2) Author ID field 466 (3) Object ID field 466 (4) Reference field 466 (5) that references subject table 462 Attribute field 466 (6) Minimum registration interval field 466 (7) Tags 466 (8) to subject table records, and Check value field 466 (9).

The site record number field 466 (1) specifies the site record number for this object registration record 460 (N). In one embodiment of the safety database 610, each record stored in the safety database is identified by a site record number. This site record number can be used as part of the database lookup process to track all records in safety database 610.

Object type field 466 (2) can specify the type of VDE object 300 (eg content object, administrative object, etc.).

The creator ID field 466 (3) in this example can identify the creator of the corresponding VDE object 300.

The object ID field 466 (4) in this example uniquely identifies the registered VDE object 300.

Reference field 466 (5) in a preferred embodiment identifies a record in subject table 462. Using this reference, electronics 600 may determine all users (or user groups) authorized to access the corresponding VDE object 300 listed in subject table 462. Tag 466 (8) can be used to validate that the subject table record accessed using field 466 (5) is the appropriate record to be used with object registration record 460 (N).

Attribute field 466 (6) may store one or more attributes or attribute flags corresponding to VDE object 300.

The minimum registration interval field 466 (7) can specify how many times an end user can re-register with an information exchange service, VDE administrator, or VDE provider as a user of VDE object 300. One reason to prevent frequent re-registration is to foreclose the user from reusing the budget amount on a traveling object until a specified amount of time has elapsed. The minimum registration interval field 466 (7) may be left unused if the object owner does not want to restrict re-registration.

Check value field 466 (9) contains validation information used to detect corruption or alteration of record 460 (N) to ensure the safety and integrity of the record. I'm out. In a preferred embodiment, many or all fields in record 460 (N) (as well as other records in safety database 610) are wholly or partially encrypted and / or Each record contains redundantly stored fields (once in unencrypted form and once again in encrypted form). The encrypted and unencrypted versions of the same field are cross-checked at various times to detect fraudulent or altered records.

As mentioned above, reference field 466 (5) refers to subject table 462 and, in particular, one or more user / object records 460 (M) in the subject table. FIG. 32 shows an example of the format for the user / object record 462 (M) provided in this example. The record 462 (M) may have a header 468 and a subject record section 470. The header 468 may include a field 468 (6) that references the "first" subject record 470 contained in the subject registration table 462. The "first" subject record 470 (1) can itself contain a reference field 470 (5) that references the "next" subject record 470 (2) in the subject registration table 462, and so on. This "linked list" structure allows a single object registration record 460 (N) to refer to subject records 470 from 1 to N.

The subject registration table header 468 in this example has a site record number field 468 (1) that can uniquely identify the header as a record in the safety database 610. Header 468 may also have author ID field 468 (2), which may be a copy of the content of object registration table author ID field 466 (3). Similarly, the subject registration table header 468 may have an object ID field 468 (5), which may be a copy of the object ID field 466 (4) in the object registration table 460. These fields 468 (2), 468 (5) explicitly (explicitly) map the user / object registration record to a particular VDE object 300.

The header 468 may also have a tag 468 (7) that allows validation. In one configuration example, the tag 468 (7) in the user / object registration header 468 may be the same as the tag 466 (8) in the object registration record 460 (N) pointing to this user / object registration header. The correspondence between these tags 468 (7) and 466 (8) allows validation of matching of object registration records and user / object registration headers.

The user / object header 468 also indicates the original distributor ID field 468 (3), which indicates the original distributor of the corresponding VDE object 300, and the last distributor in the processing chain of the object, before it was received by electronics 600. Contains the final distributor ID field 468 (4).

Header 468 also contains tag 468 (8), which allows validation between the header and the "first" subject record 470 (1) referenced by field 468 (6).

Subject record 470 (1) is a field that references site record number 472 (1), user (or user group) ID field 472 (2), user (or user group) attribute field 472 (3), and user rights table 464. 472 (4), field 472 (5) that references the "next" subject record 470 (2) (if any), tag 472 (6) used to perform validation by header tag 468 (8). , The "next" subject record referenced by tag 472 (7), field 472 (5), which is used to perform validation by the corresponding tag in the user rights table record referenced by field 472 (4). It has a tag 472 (9), which is used by the tag to perform validation, and a check value field 472 (9).

User or user group ID 472 (2) identifies a user or user group who is authorized to use the object identified in field 468 (5). Thus, fields 468 (5) and 472 (2) together form the core of the access control list provided by subject table 462. The user attribute field 472 (3) may specify an attribute that belongs to the use / access of object 300 by the user or user group specified in field 472 (2). Any number of different users or groups of users can be added to the access control list, each with a different set of attributes 472 (3), by providing an additional subject record 470 in the "linked list" structure. ..

Subject record reference field 472 (4) refers to one or more records in user rights table 464. FIG. 33 shows an example of a preferred format for user rights table record 464 (k). The user rights record 464 (k) may have a set of URT headers 474, record rights headers 476, and user selection records 478. The URT header 474 is a site record number field, a field 474 (2) that specifies the number of rights records in the URT record 464 (k), and a field 474 (3) that references the "first" rights record (ie, rights record header 476). ), Tag 474 (4) used for lookup validation from subject table 462, tag 474 (5) used for lookup validation against rights record header 476, and check value field 474 ( Has 6).

The rights record header 476 in a preferred embodiment is a site record number field 476 (1), a rights ID field 476 (2), a field 476 (3) that references the "next" rights record 476 (2), a user-selected record. Field 476 (4) that references the first set of 478 (1), tag 476 (5) that allows validation by URT header tag 474 (5), validation by user-selected record tag 478 (6). It may have a tag 476 (6) to enable it, and a check value field 476 (7). The rights ID field 476 (2) may specify, for example, the type of rights conveyed by rights record 476 (eg, rights to use, rights to distribute, rights to read, rights to audit, etc.).

One or more user selection records 478 referenced by rights record header 476 display user selections that correspond to access and / or use of the corresponding VDE object 300. There is typically one rights record 476 for each right granted to the corresponding user or user group. These rights govern the use of VDE Object 300 by that user or group of users. For example, a user may have "access" and "extract" rights but not "copy" rights. Other rights controlled by rights record 476 (derived from PERC808 using the REGISTER method in a preferred embodiment) include distribution rights, audit rights, and pricing rights. right). When the object 300 is registered with the electronic device 600 and registered with a specific user or user group, the user may be allowed to choose from the various methods of use displayed on the PERC808. For example, the VDE object 300 may require two weighing methods. That is, one for billing purposes and another for accumulating data on promotional materials used by users. The user may be allowed to choose from a variety of weighing / billing methods. For example, VISA payment or MasterCard payment; Billing based on the amount of material retrieved from the information database, billing based on usage time, and / or both. Users may receive discounts on hourly and / or pay-as-you-go billing if they agree to provide certain details regarding the search for that content to a third party (eg, for demographic purposes). When registering an object and / or a user for that object, the user will be asked to select a particular weighing method as the "active weighing method" for the first weighing to be obtained. VDE distributors can narrow the universe of choices available for users to a subset of the original selection array defined by PERC808. These user selection and configuration settings are stored in user selection records 480 (1), 480 (2), 480 (N). The user selection record does not have to be explicitly stated in the user rights table 464, instead the user selection record 480 references specific VDE methods and / or information that parameters those methods (eg, site reference). It is also possible (by number). References to method 1000 by such user-selected record 480 must be validated by the validation tag contained within the user-selected record. In this way, the user selection record 480 in a preferred embodiment may select one or more methods 1000 for use with the corresponding VDE object 300 (as shown in FIG. 27). These user-selected records 480 can, by themselves, fully define the method 1000 and other information used to build the appropriate component assembly 690 to implement the method. Alternatively, the user / object record 462 used to reference user rights record 464 can be component-assembled by referencing PERC808, which corresponds to VDE object 300. It may provide additional information needed to build the Buri 690 and / or access other VDE objects 300. For example, PERC808 can be accessed to obtain the MDE1202 belonging to the secret body and / or rights key for decryption and / or encryption of the selected method, object content, and the user rights record is PERC. It can also be used to provide a checking ability to ensure that only the rights approved by the current authorization implemented within are communicated.

In one embodiment of the invention, a conventional database engine can be used to store and organize the secure database 610, the cryptographic layer described above being "on top" of the traditional database structure. of) may be located. However, if such a traditional database engine is unable to organize the records in the safety database 610 to support the security considerations mentioned above, the electronic device 600 encrypts another indexing structure. It may be maintained in a modified form. These other indexing structures can be maintained by SPE503. This embodiment requires the SPE503 to decrypt the index and search the decrypted index block for a suitable "site record ID" or other pointer. The SPE503 may then request the indicated record from a traditional database engine. If the record ID cannot be checked against the record list, the SPE503 may need to ask for the data file itself so that it can find the desired record. The SPE503 then performs proper authentication to ensure that the file has not been tampered with and a proper block is returned. The SPE503 should not simply pass the index to a traditional database engine (unless the database engine itself is secure). This is because doing so allows the requested record to be exchanged for an incorrect record.

FIG. 34 shows an example of how the site record numbers described above can be used to access various data structures in the safety database 610. In this example, the safety database 610 also has a site record table 482 that stores a plurality of site record numbers. The site record table 482 may store, so to speak, a "master list" of all the records in the safety database 610. These site record numbers, stored in site record table 482, allow access to any record in safety database 610. In this way, some of the site records in the site record table 482 index the records in the object registration table 460, and the other site record numbers in the site record table index the records in the user / object table 462. , Yet another site record number in the site record table may access the record in URT464, and yet another site record number in the site record table may access PERC808. In addition, each of the method cores 1000'may have a site record number so that the site record table 482 can be accessed.

FIG. 34A shows an example of site record 482 (j) in site record table 482. Site record 482 (j) provides additional information about the record pointed to by field 484 (1), which indicates the type of record, field 484 (2), which indicates the owner or creator of the record, and site record 482 (j). Class field 484 (3) and instance field 484 (4); specific descriptor field 484 (5) indicating some specific descriptor (eg object ID) associated with the record; table or other site record Identification of the referenced data structure (identification) 484 (6); References and / or offsets within the data structure that indicate where the record starts; Validity checks to validate the record being looked up. It may have a tag 484 (8) and a check value field 484 (9). Both fields 484 (6) and 484 (7) may provide a mechanism for the record referenced by site record 484 (j) to actually be physically located in safety database 610.

Update safety database 610 FIG. 35 shows an example of process 1150 that can be used by an information exchange, VDE administrator or other VDE participant to update the safety database 610 maintained on the end user's electronics 600. For example, process 1500, shown in Figure 35, is used to collect "audit tracking" records in safety database 610 and / or to provide new budgets and permissions (eg PERC808) at the request of the end user. obtain.

Typically, the end user's electronics 600 may initiate communication with the information exchange (block 1152). This contact can be established, for example, in response to a user command or automatically. It may be initiated via the electronic highway 108 and may be initiated between electronic devices via other communication networks, for example by LAN, WAN, bidirectional cable or portable media exchange. The process of exchanging management information does not have to take place during a single "online" session, but over a period of time, based on several different one-way and / or two-way communications, on the same or different means of communication. You may. However, process 1150, shown in Figure 35, allows end-user electronics 600 and other VDE participants (eg, information exchanges) to exchange two-way real-time interactive communications over telephone lines, networks, electronic highways 108, and so on. , A concrete example.

The end-user electronics 600 generally contacts a particular VDE administrator or information exchange. The identification of a particular information exchange is based on the VDE object 300 that the user wants or has already accessed. For example, suppose a user has already accessed a particular VDE object 300 and has run out of budget for further access. The user is the VDE administrator, distributor and / or financial information exchange (financial) responsible for that particular object. A request can be made to automatically contact the clearhouse) with the user's electronics 600. The identification of the appropriate VDE participants to contact is provided in this example by the information in, for example, UDE1200, MDE1202, object registration table 460 and / or subject table 462. The electronics 600 may have to contact multiple VDE participants (for example, to distribute audit records to one participant and obtain additional budget or other permissions from another). Contact 1152 may, in one example, be scheduled based on the shipping table 444 of FIG. 27 and the administrative event log 442 of FIG.

Once contact is established, end-user electronics and information exchanges typically authenticate each other and agree on a session key for use in real-time information exchange (block 1154). Once a secure connection is established, the end user's electronics determine whether they have administrative objects containing audit information to be sent to the information exchange (eg, based on shipping table 444). Can be (decision block 1156). Audit information belonging to several VDE objects 300 may be placed within the same administrative object for transmission, and different administrative objects may contain audit information about different objects. Assuming that the end-user's electronics have at least one such administrative object to send to this particular information exchange (the "yes" exit of decision block 1156), the electronics have now been established. Send the administrative object to the information exchange via secure real-time communication (block 1158). As a concrete example, a single administrative object may have audit information that belongs to multiple VDE objects such that the audit information for each different object compromises another "event" within the administrative object. Can be sent as a management object that contains.

The information exchange receives the administrative object and processes the content to determine if the content is "valid" and "legitimate". For example, the information exchange analyzes the audit information it contains to determine whether it indicates a misuse of the VDE object 300 in question. As a result of this analysis, the information exchange may generate one or more responsive administrative objects and send them to the end user's electronics 600 (block 1160). The end-user electronics 600 may handle events that update its safety database 610 and / or SPU500 content based on received administrative objects (block 1162). For example, if the audit information received by the information exchange is valid, the information exchange may request that the audit information sent to the electronic device be deleted and / or compressed, and the administrative object be the end user's electronic device. Can be sent to 600. Alternatively or additionally, the information exchange may request additional information from the end-user electronics 600 at this stage (eg, retransmitting certain information that was corrupted during the initial transmission, previously. Is the transmission of additional information that was not sent). If the information exchange detects unauthorized use based on the audit information received, it may send administrative objects that revoke or otherwise modify the end user's right to further access the associated VDE object 300.

The information exchange may, in lieu or additionally, send an end-user electronic device 600 a management object instructing the electronic device to display one or more messages. These messages may inform the user of certain conditions and / or request additional information from the user. For example, the message tells the end user to contact the information exchange directly by phone or other means to resolve the displayed issue and enter a PIN, or the user is contacted by a new service company and the associated VDE object. Can be instructed to re-register. Alternatively, the message may tell the end user that a new license needs to be obtained for the object and inform the user of costs, status and other relevant information.

During the same or different communication exchanges, the same or different information exchanges may handle end-user requests for additional budget and / or permissions belonging to VDE Object 300. For example, an end-user electronics 600 (eg, in response to a user input request for access to a particular VDE object 300) gives the information exchange budget and / or other permissions to allow access. A requesting, administrative object can be sent (block 1164). As mentioned above, such requests are related to multiple requested budgets and / or other permissions for one or more administrative object forms, eg, the same or different VDE objects 300. It can be sent as a single administrative object with an "event". When an information exchange receives such a request, should it be granted the requested budget and / or permission by checking the end user's credits, financial records, business agreements and / or audit history? Decide whether or not. Based on this analysis, the information exchange may send one or more response management objects that cause the event user's electronics 600 to respond and update their safety database (blocks 1166, 1168). This update may include, for example, replacing an expired PERC808 with a new one, modifying the PERC to provide additional (or less) rights, and so on. Steps 1164 to 1168 may be repeated multiple times in the same or different communications to provide further updates to the end user safety database 610.

FIG. 36 shows an example of how a new record or element can be inserted into the safety database 610. The loading process 1070, shown in Figure 35, checks each loaded data element or item to ensure that it has not been tampered with, replaced, or replaced. In process 1070 shown in Figure 35, the first step to be taken is to check whether the current user of electronics 600 is authorized to insert the item into the safety database 610 (block 1072). .. This test, in a preferred embodiment, loads the appropriate method 1000 and other data structures such as UDE1200 into the SPE503 (or uses the one already loaded) to ensure that it is loaded into the safety database 610 (block 1074). It can include authenticating user authorization to make changes. If the user is authorized to make the changes to the safety database 610, SPE503 decrypts the element that should be added to the safety database (block 1076) and damages or corrupts it. Its completeness can be checked by determining (block 1078). The element is a given management file key Using key), it can be checked to make sure it is decrypted correctly and the checked value can be validated. Also, public and secret header ID tags (if any) can be compared to ensure that the correct elements are supplied and not replaced, and unique element tag IDs are compared against a given element tag. Can be done. If any of these tests fail, the element is automatically rejected, error corrected, and so on. If the element is found to be complete, the SPE503 can re-encrypt the information (block 1080), for example with a new key (see description in Figure 37 below). In the same process step, the appropriate tags are preferably provided and the information is encrypted within a security wrapper containing the appropriate tags (block 1082). By retaining the appropriate tag information, the SPE503 may authenticate the item by performing a validity check or otherwise when the item is later read back from safety database 610 (block 1084). The now secure element in the security wrapper can then be stored in the security database 610.

FIG. 37 shows an example of process 1050, which is a database in a preferred embodiment and is used to safely access items stored in safety database 610. In a preferred embodiment, the SPE503 first accesses and reads an item from the safety database 610 record. in). The SPE503 "opens" by reading this information in encrypted form from the secure database 610 and decrypting it based on the access key stored internally in the protected memory of the SPU500 (block 1053). Can be "unwrapped" (block 1052). In a preferred embodiment, this "unpacking" process 1052 comprises sending a block of information to the encryption / decryption engine 522 along with a management file key and other necessary information required for decryption. The decryption engine 522 can return "plaintext" information, which the SPE503 checks to ensure that the object is not compromised and that the object is the correct object to be used (block). 1054). To ensure that the read element has not been replaced and protect against other security threats, the SPE503 can then check all correlation and access tags (block 1054). Part of this "checking" process involves checking tags obtained from safety database 610 against tags contained within secure memory or SPU500 (block 1056). These tags, stored within the SPU500, can be accessed from the SPU's protected memory (block 1056) and can now be used to further check unpacked objects. When this "checking" process 1054 does not show any improperity (and block 1052 also shows that the object has not been tampered with or otherwise damaged), the SPE503 will access the item. Others used (block 1058). Once the item has been used, the SPE503 may need to be stored in the safety database 610 again if the item has changed. If the item has been modified, SPE503 will darken the item in its modified form. Encrypts / decrypts the appropriate required information (eg, the appropriate same or different management file key and data) so that the object is properly encrypted while being sent to the encryption / decryption engine 522 for encryption. Provide to the engine (block 1060). At this stage, a unique new tag and / or encryption key can be used to uniquely tag and / or encrypt the item security wrapper (block 1062; see also detailed description below in Figure 37). The SPE503 keeps a copy of the key and / or tag in the protected memory of the SPU500 so that the SPE can decrypt and validate the object when it is read from the safety database 610 again. May be good (block 1064).

In a preferred embodiment, the key for decrypting the secure database 610 records is maintained only in the protected memory of the SPU500. Each index or record update leaving the SPU500 is time stamped and encrypted with a unique key determined by the SPE503. For example, before the record in safety database 610, the key identification number should be "in plain" so that the SPE503 can determine which key to use the next time the record is retrieved. view) "may be placed. The SPE503 can maintain the site ID of the record or index, the key identification number associated with it, and the actual key in the list inside the SPE. At some point, this internal list may fill up. At this point, SPE503 may call a maintenance routine that re-encrypts the items in safety database 610 that contain the modified information. Some or all of the items in the data structure containing the modified information can be read, encrypted, and then re-decrypted using the same key. These items may then be issued the same key identification number. These items can then be exported from SPE503 to safety database 610 again. The SPE503 can then clear the internal list of item IDs and corresponding key identification numbers. The process of assigning different keys and new key identification numbers to each new or modified item can then be started again. By using this process, the SPE503 can protect the data structure (including the index) of the safety database 610 from replacement by old items and index replacement of the current item. This process also allows the SPE503 to validate the retrieved item ID against an encrypted list of expected IDs.

FIG. 38 is a flowchart showing this process in more detail. Whenever an item in security database 610 is updated or modified, a new encryption key can be generated for the updated item. Encryption with the new key is done to add security and prevent improper use of backup copies of secure database 610 records. The new encryption key for each updated secure database record 610 record may be stored in the secure memory of the SPU500, along with the identification of the relevant secure database record (s).

SPE503 may generate a new encryption / decryption key for each new item that it attempts to store in secure database 610 (block 1086). SPE503 can use this new key to encrypt it before storing it in a secure database (block 1088). The SPE503 ensures that the key is retained so that the record can be read and decrypted later. In a preferred embodiment, such a decryption key is maintained in a protected non-volatile memory (eg NVRAM534b) within the SPU500. Since this protected memory has a finite size, there may be no room for the protected memory to store a new key. In a preferred embodiment, this condition is tested by determination block 1090. If there is no room in memory to store new keys (or in other events, such as when the number of keys stored in memory exceeds a certain number or the timer expires). A preferred embodiment accommodates these situations by re-encrypting other records in secure database 610 with the same new key to reduce (or change) the number of encryption / decryption keys used. deal with. In this way, one or more items in security database 610 can be read from security database (block 1092) and decrypted using the old key that was used to encrypt when it was last stored. obtain. In a preferred embodiment, one or more "old keys" are selected and all secure database items encrypted with the old keys are read and decrypted. These records can now be re-encrypted with the new key generated for the new record in block 1086 (block 1094). The old key used to decrypt other records can now be removed from SPU protected memory (block 1096) and the new key can be stored in its place (block 1097). All in secure database 610 encrypted with old key (s) The old key (s) will not be removed from secure memory by block 1096 unless SPE503 is confident that the record was read in block 1092 and re-encrypted in block 1904 with the new key. .. All records encrypted (or re-encrypted) with the new key can now be stored in secure database 610 (block 1098). If the decision block 1090 decides that there is room to store the new key in the SPU500 protected memory, then the actions of blocks 1092, 1094, 1096 are unnecessary and the SPE503 simply puts the new key in the protected memory. Can be stored in (block 1097) and newly encrypted records can be stored in secure database 610 (block 1098).

The security of the files in safety database 610 can be further improved by subdividing the records into "compartments". Different encryption / decryption keys can be used to protect different "partitions". This strategy can be used to limit the amount of information encrypted with a single key in the secure database 610. Another technique for increasing the security of the security database 610 is to encrypt different parts of the same record with different keys so that one or more keys are required to decrypt these records. Is to do.

Backup of safety database 610 The safety database 610 in a preferred embodiment is backed up at periodic or other time intervals to protect the information contained in the safety database. This safety database information is of substantial value to many VDE participants. The backup of the safety database 610 must be done without causing great inconvenience to the user and should not be a security breach.

The safety database 610 needs to be backed up when the electronic device 600 is powered on, when the SPE503 is first invoked, the periodic time interval, and the "audit rollup" value maintained in the SPE503, etc. Established by one or more content publishers and / or distributors and / or information exchange service providers and / or users when the summary service information exceeds user settings or other thresholds. Can be checked if triggered by the conditions to be. Users may be prompted to back up if they have not backed up by a certain point in time, or after a period of time or usage. Alternatively, the backup may proceed automatically without user intervention.

With reference to FIG. 8, the backup storage unit 668 and the storage medium 670 (for example, magnetic tape) may be used to store the backup information. Of course, any non-volatile medium (eg, one or more floppy (registered trademark) disks, writable optical disks, hard drives, etc.) may be used for the backup storage unit 668.

There are at least two scenarios for backing up safety database 610. The first scenario is "site-specific" and uses the security of the SPU500 to support the restore of backup information. This first method is the safety database 610 due to, for example, the failure of the secondary storage device 652, file damage due to user error, or any other event that may damage or corrupt the safety database 610 in part or in whole It is used when there is damage to the database. This first site-specific backup scenario assumes that the SPU500 is still functioning properly and is available to restore backup information.

The second backup scenario assumes that the user's SPU500 is no longer operational and needs to be replaced or has already been replaced. This second approach stores authorized VDE administrators and other authorized VDE participants to prevent loss of critical data and / or to help users recover from errors. Allows access to backup information.

Both of these scenarios are provided by the example program control steps performed by ROS 602 shown in FIG. FIG. 39 shows an example of backup routine 1250 performed by electronic device 600 to back up safety database 610 (and other information) to backup storage 668. When the backup is initiated, backup routine 1250 generates one or more backup keys, as described above (block 1252). Backup routine 1250 then reads all secure database items and decrypts each item using the original key used for encryption before it is stored in secure database 610 (block 1254). Also, since the SPU500 is the only place in the instance of the secure database 610 where the key to decrypt this information is stored, and one of the scenarios provided by the backup routine 1250 is the SPU500. In case of complete failure or destruction, backup routine 1250 performs this reading and decryption step 1254 so that recovery from backup does not rely on knowledge of these keys in the SPU. Rather, backup routine 1250 uses the newly generated backup key (s) to encrypt each secure database 610 item (block 1256) and writes the encrypted item back to backup vault 668 (block 1258). ). This process continues until all items in the safety database 610 have been read, decrypted, encrypted with the newly generated backup key (s) and written back to the backup vault (one or more). The test is done by decision block 1260).

A preferred embodiment also reads the simplified service audit information stored by the SPE simplified service manager 560 in the protected memory of the SPU500 and encrypts this information with the newly generated backup key (s). Write the simplified service information in backup storage 668 (block 1262).

Finally, the backup routine 1250 saves the backup key (s) generated in block 1252 and used for encryption in blocks 1256 and 1262 in the backup storage unit 668. To cover both of the restore scenarios described above, backup routine 1250 does this in two secure ways. The backup routine 1250 deciphers the backup key (s) (along with other information such as the backup time and other appropriate information to identify the backup), additional keys (s) that only the SPU500 can decrypt. Can be encrypted using multiple). This encrypted information is then written to backup storage 668 (block 1264). For example, this step may include multiple encryptions using one or more public keys, where only the SPU500 knows the corresponding private key. Alternatively, a second back-up key generated by the SPU500 and held only by the SPU can be used for final encryption in place of the public key. Block 1264 preferably contains multiple encryptions to make it difficult to attack the security of the backup by "cracking" the encryption used to protect the backup key. Block 1262 has encrypted simplified service information on the backup, but preferably does not have the SPU device private key, shared key, SPU code or other internal security information. This is to ensure that this information is never available to the user, even in encrypted form.

The information stored in block 1264 is sufficient for the same SPU500 that performed (or at least partially performed) backup routine 1250 to recover the backup information. But this information is useless except for this same SPU500. This is because only this SPU knows the specific key used to protect the backup key. Backup keys (s) under the protection of one or more additional key sets that can be read by an authorized VDE administrator to cover the other possible scenario where the SPU500 will fail irreparably. Backup routine 1250 provides an additional step (block 1266) to save). For example, block 1266 can encrypt the backup key using the "download authorization key" received from the VDE administrator during the initialization of the SPU500. This encrypted version of the key is also written back to storage 668 (block 1266). It can be used to support backup file restoration in case of SPU500 failure. That is, a VDE administrator who knows the "download authorization (or other) key (s)" used in block 1266 may be able to recover the backup key (s) in the backup vault 668. The backup safety database 610 can then be restored to the same or different electronic device 600.

In a preferred embodiment, the information saved in the backup file by routine 1250 can only be restored after receiving the backup approval from an authorized VDE administrator.

In most cases, the restore process is simply to restore the safety database 610, with some tweaks for use since the backup occurred. This may require the user to contact additional providers to submit audit and billing data and receive a new budget that reflects the behavior from the last backup. The current simplified service information maintained within the SPU500 may be compared to the simplified service information stored on the backup to determine or estimate the most recent usage behavior.

In case of SPU500 failure, an authorized VDE administrator must be contacted to initialize the replacement SPU500 and to decrypt the backup file. These processes allow both SPU failures and updates to new SPUs. In the case of a restore, a backup file is used to restore the information needed by the user's system. In the case of updates, the backup file can be used to validate the update process.

The backup file may, in some cases, be used to transmit management information between electronic devices 600. However, in a preferred embodiment, it may be possible to limit the transportability of some or all of the information between electronic devices with appropriate approval. Some or all of the backup files may be packaged within a managed object and sent for analysis, transportation, or other use.

As a more detailed example of what needs to be restored from a backup file, the electronics 600 has suffered a hard disk failure or other accident that wipes out or corrupts some or all of the safety database 610. , Suppose the SPU500 is still functional. The SPU500 may contain all the information needed to restore the secure database 610 (eg secret key, etc.). However, ROS602 can prevent the restoration of the secure database until the restore approval is received from the VDE administrator. Restoration approval may have, for example, a "secret value" that must match the value expected by SPE503. If desired, the VDE administrator will only provide this restore approval after, for example, the simplified service information stored within the SPU500 has been placed in a management object for analysis and sent to the administrator. You may do so. Under certain circumstances, VDE administrators are fraudulent by users. It may be required that a (partial or complete) copy of the backup file be entered into an administrative object and sent to the VDE administrator to check for traces of activity). Once approved, the restore process may require adjusting the restored budget records to reflect the behavior from the last backup, as described above.

FIG. 40 shows an example of a program-controlled restoration routine 1268 performed by electronics 600 to restore the safety database 610 based on the backup provided by the routine shown in FIG. 38. This restoration can be used, for example, when electronics 600 have failed but can be recovered or "reinitialized", for example by contacting the VDE administrator. In a preferred embodiment, restore routine 1268 can approve a restore because the SPU500 does not allow the restore from backup unless and until approved by the VDE administrator. Start by establishing secure communication with the administrator (block 1270). Once the SPU500 and VDE administrator authenticate each other (part of block 1270), the VDE administrator says "work in". Progress) and simplified values can be extracted from the SPU500's internal non-volatile memory (block 1272). The VDE administrator can use this extracted information, for example, to help determine if there was a security breach, and a failed SPU500 effectively "dumps" its content to the VDE administrator. Allows VDE administrators to work with content. The SPU500 may encrypt this information, package it in one or more administrative objects, and supply it to the VDE administrator. The VDE administrator may then request a copy of some or all of the current backup of safety database 610 from the SPU500 (block 1274). This information can be packaged by the SPU500 into, for example, one or more administrative objects and sent to the VDE administrator. Upon receiving the information, the VDE administrator may determine the simplified values and other information stored during the backup by reading the simplified service audit information from the backup volume (ie, the information stored in block 1262 in Figure 38). .. The VDE administrator may also determine the time and date of the backup by reading the information stored in block 1264 of Figure 38.

At this point, the VDE administrator may restore the simplified values and other information based on the information obtained from block 1272 and the backup (block 1276). For example, the VDE administrator may reset the SPU's internal simplifications and counters to match the final backup. These values may be adjusted by the VDE administrator based on the "work in progress" recovered in block 1272, the amount of time elapsed since the backup, and so on. The purpose is typically to seek to provide an internal SPU value equal to the value that would have been taken if failure had not occurred.

The VDE administrator can then authorize the SPU500 to recover the safety database 610 from the backup file (block 1278). This restore process replaces all 610 safety database records with records from the backup. The VDE administrator can adjust these records as needed by passing commands to the SPU500 during or after the restore process.

The VDE administrator then calculates the bill based on the recovered value (block 1280) and takes other actions to recover from SPU downtime (block 1282). Typically, the purpose is to charge the user and adjust other VDE100 values belonging to the failed electronics 600 for use that occurred after the last backup but before the failure. This process allows the VDE administrator to obtain reports and other information belonging to the use of the electronic device prior to the failure from the other VDE administrator and compare it with a safety database backup to determine which use and other events. Includes determining if it has not yet been considered.

In another embodiment, the SPU 500 may have sufficient internal non-volatility to allow some or all of the safety database 610 to be stored. In this embodiment, fraudulent use of one or more additional integrated circuits that may be contained within a secure enclosure, such as a non-tamperable metal container or some chip pack form, that includes multiple integrated circuit elements. Additional memory is provided by preventing and / or proof of alteration attempts and / or by disabling the SPU500 or related critical keys and / or other control information in the event of tampering. obtain. The same backup routine 1250 shown in Figure 38 can be used to back up this type of information. The only difference is that block 1254 can read the secure database item from the SPU's internal memory and it may not be necessary to decrypt it before encrypting it with the backup key.

Event-driven VDE process As mentioned above, the rights operating system (ROS) 602 according to preferred embodiments can be "event driven". This "event-driven" capability facilitates integration and scalability.

An "event" is an event at any time. Examples of "events" include the user typing a key on the keyboard, the arrival of a message or object 300, the timer expiring, or a request from another process.

In a preferred embodiment, the ROS 602 responds to an "event" by performing the process in response to the "event". ROS602 dynamically creates active processes and tasks in response to the occurrence of an event. For example, ROS602 may create one or more component assemblies 690 and initiate their execution to perform one or more processes in response to the occurrence of an event. Active processes and tasks may end when ROS602 responds to the event. This ability to dynamically create (and finish) tasks in response to events provides great flexibility and is virtually infinite with limited execution resources, such as those provided by the SPU500. Allows a wide variety of different processes to take place in different contexts.

Since an "event" can be any type of event, there are an infinite number of different events. Therefore, any attempt to categorize events into different types is only an overview. With this in mind, the events offered / supported by preferred embodiments can be divided into two broad categories: -User-initiated events and -A system-started event.

In general, a "user-initiated" event is an event that is attributed to the user (or user application). A common "user-initiated" event is a user's request to access object 300 or other VDE-protected information (eg by pressing a button on the keyboard or transparently using the redirector 684). Is.

A "system-initiated" event is generally an event that cannot be attributed to the user. Examples of system-initiated events are a timer that indicates that information must be backed up to non-volatile memory expires, a message is received from another electronics 600, and another process (system-initiated event and / Or a service call that may have been initiated to respond to a user-initiated type).

Provided in a preferred embodiment, the ROS 602 responds to an event by specifying and initiating a process for handling the event. These processes are based on Method 1000 in a preferred embodiment. Given the infinite number of different types of events, a preferred embodiment supports an infinite number of different processes for handling events. This flexibility is supported by dynamically creating component assemblies from independently deliverable modules such as data structures such as Method Core 1000', Load Module 1100, and UDE1200. Although no matter how the infinite potential process types supported / provided by the preferred embodiment are categorized, the processes can be broadly categorized into the following two categories: · Processes related to the use of VDE-protected information, and -Processes related to VDE management. "Use" and "administrative" processes The "use" process has something to do with the use of VDE-protected information. Method 1000, provided in a preferred embodiment, may provide a process of creating and maintaining a control chain for the use of VDE-protected information. One specific example of a "use" type process is a process that allows a user to open a VDE object 300 and access its content. Method 1000 may provide detailed usage-related processes, such as release of content to users on demand (if allowed), and updates of weighing, budgeting, audit tracking, and so on. Use-related processes are often user-initiated, but some of the use-related processes can be system-initiated. Events that trigger VDE usage-related processes can be referred to as "use events."

The "administrative" process helps the VDE100 continue to function and provides a process that helps support the transaction management "infrastructure" that keeps the VDE100 operating safely and efficiently. To do. Administrative processes may provide, for example, processing related to some aspect of creating, modifying and / or destroying VDE-protected data structures, establishing and maintaining VDE processing and control chains. For example, a "administrative" process may store, update, modify, or destroy information contained within the safety database 610 of VDE electronics 600. Administrative processes may also provide communication services that establish, maintain and support secure communication between different VDE electronics 600. An event that induces a management process can be called a "management event".

Reciprocal method Some VDE processes are paired based on how they interact with each other. One VDE process may "request" processing services from another VDE process. A process that requests a processing service can be called a "request process". A "request" is an "event" because it induces processing by the other VDE process in the pair. A VDE process that responds to a "request event" can be called a "response process". The "request process" and "response process" can be referred to as "reciprocal processes".

A "request event" can have, for example, a message issued by one VDE node electronic device 600, or a process for certain information. The corresponding "response process" may respond to a "request event", for example by sending the requested information in a message. The response itself can be a "request event" if it induces an additional VDE "response process". For example, receiving a message in response to a earlier request can trigger a "reply process". This "response process" is a special type of "response process" that is triggered in response to a "response" from another "response process". During a given VDE transaction, there can be any number of "request" and "response" process pairs.

The "request process" and its companion "response process" may be performed on the same VDE electronics 600, and these two processes may be performed on different VDE electronics. Communication between two paired processes may be by secure (VDE-protected) communication, "out of channel" communication, or a combination of the two.

Figures 41a-41d are a set of examples showing how processing and control chains are enabled using "reciprocal methods". The processing and control chain is partly constructed using one or more pairs of "mutual events" that cooperate in a request-response expression. In a preferred embodiment, pairs of reciprocal events can be managed in one or more "reciprocal methods". As mentioned above, a "mutual method" is a method 1000 that can respond to one or more "mutual events". Reciprocal methods include two halves of cooperating processes that can be safely performed on VDE nodes that are physically and / or temporally separated. Reciprocal processes can have a flexibly defined information passing protocol and information content structure. Reciprocal methods may in fact be based on the same or different method core 1000'running on the same or different VDE nodes 600. The VDE nodes 600A and 600B shown in FIG. 41a may be the same physical electronic device 600 or separate electronic devices.

FIG. 41a shows an example of the behavior of a pair of reciprocal events. At VDE node 600A, method 1000a is handling an event that has a request that must be handled at VDE node 600B. A method 1000a (eg, based on the associated load module 1100 and component assembly 690 containing data) that responds to this "request" event is shown as 1450 in Figure 41a. Process 1450 creates a request (1452) and, optionally, some information or data that is sent to the other VDE node 1000b and processed by the process associated with the reciprocal event. Requests and other information may be transmitted by any transport mechanism described elsewhere herein.

Receiving a request by VDE node 600b includes a response event at that node. Upon receiving the request, the VDE node 600b may respond to the response event by performing the "reciprocal" process 1454 defined by the same or different method 1000b. Reciprocal process 1454 may be based on component assembly 690 (eg, one or more load modules 1100, data, and optionally other methods present in VDE node 600B).

FIG. 41b extends the concept shown in FIG. 41a to include a response back from VDE node 600B to VDE node 600A. As shown in Figure 41a, the process is initiated by the reception and processing of the request event and information 1452 by the response process 1454 in the VDE node 600B. Response process 1454, in cooperation with another request process (1468), sends response 1469 back to the starting VDE node 600A as part of its processing. The corresponding reciprocal process 1470 provided by method 1000A may respond to and process this request event 1469. In this way, two or more VDE nodes 600A, 600B cooperate to pass configurable information and requests between methods 1000A, 1000B running on the node. The first and second request-response sequences [(1450, 1452, 1454) and (1468, 1469, 1470)] can 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 implemented as two methods in the same or different method core 1000'. Method 1000 can be parameterized by an "event code" to provide different behavior / results for different events, or to provide different methods for different events.

Figure 41c shows the extension of the control mechanism in Figures 41a-41b to three nodes (600A, 600B, 600C). Each request-response pair operates as described in Figure 41b, with several pairs linked together to form a control and processing chain between several VDE nodes 600A, 600B, 600C. This mechanism can be used to extend the control and processing chain to any number of VDE nodes using nodes of any configuration. For example, the VDE node 600C may communicate directly with the VDE node 600A and directly with the VDE 600B. The VDE600B itself communicates with the VDE node 600A. Alternatively, the VDE node 600C may communicate directly with the VDE node 600A, the VDE node 600A may communicate with the VDE node 600B, and the VDE node 600B may communicate with the VDE node 600C.

Method 1000 can be parameterized by a set of events that specify related or cooperative functionality. Events may be logically grouped by function (eg, use, distribution, etc.) and in cooperation with each other (in conjunction with each). other) It may be a set of reciprocal events that specify the processes that can operate. Figure 41d illustrates a set of "mutual events" that support collaborative processing between several VDE nodes 102, 106, 112 in a content distribution model that supports budget distribution. The processing and control chain in this example is enabled using a set of "mutual events" specified within the BUDGET method. Figure 41d shows how the behavior of reciprocal events within the illustrated BUDGET method (1510) works together to establish a processing and control chain between several VDE nodes. The BUDGET method 1510 in this example responds to "use" event 1478 by performing "use" process 1476, which defines the mechanism by which the process is budgeted. The BUDGET method 1510 may specify a process of use 1476, for example, comparing the weighing count with a budget value and failing if the weighing count exceeds the budget value. You can also write an audit follow-up that describes the result of the BUDGET decision. Budget method 1510 may respond to a "distribution" event by performing a distribution process 1472, which defines the process and / or control information for further distribution of the budget. The "request" event 1480 can be responded to by performing a request process 1480, which specifies how the user may request distribution rights and / or use from the distributor. The "Response" event 1482 may be responded to by performing response process 1484, which specifies how the distributor responds to requests from other users who have distributed part (or all) of its budget. The "reply" event 1474 may be replied by performing a replies process 1475, which specifies how the user should respond to a message that reassigns or denies (more) budget.

In a preferred embodiment, control of event handling, reciprocal events, and related methods and method components is provided by PERC808. These PERCs (808) may refer to administrative methods that govern the creation, modification and distribution of data structures and administrative methods that allow access, modification and further distribution of these items. In this way, each link in the processing and control chain, for example, customizes audit information, changes budget requirements for using content, and / or further distributes these rights on the distribution chain. It may have the ability to control in the manner specified by the predecessor member (element).

In the example shown in FIG. 41d, the distributor of the VDE distributor node (106) may request a budget from the content creator of another node (102). This request may be made in the context of secure VDE communications, or may be passed in "off-channel" communications (eg, by telephone or letter). Creator 102 may decide to allocate the budget to Distributor 106 and handle the distribution event (1452 in BUDGET method 1510 on VDE node 102). As a result of processing this distribution event in the BUDGET method, a secure communication (1454) between the VDE nodes 102 and 106 that allows the author 102 to send a budget granting usage and redistribution rights to the distributor. , Can be obtained. The distributor's VDE node 106 may respond to the receipt of budget information by processing the communication using response process 1475B of BUDGET method 1510. Response event processing 1475B, for example, can install budget and PERC808 within the distributor VDE106 node to allow the distributor to access content or processes whose access is at least partially controlled by the budget and / or PERC. To. At some point, Distributor 106 may also wish Distributor 106 to use the content to which it has been granted access.

After registering the use of the Content Object, User 112 is required to utilize the array of "Use" Process 1476C to open, read, write, and / or close the Content Object, for example, as part of the Usage process. Will be.

Distributor 106 may wish to obtain additional budget once the entire budget has been used up. In that case, Distributor 106 may initiate a process using the BUDGET method request process (1480B). Request process 1480B may initiate communication (1482AB) with content creator VDE node 102, requesting that it provide more budget and possibly usage behavior details to date (eg, audit tracking). Content creator 102 uses the response process (1484A) in the creator's BUDGET method 1510A to handle the "get more budget" request event 1482AB. Response process 1484A may, for example, determine whether the usage information indicates the correct use of the content and / or is reliable enough for the distributor to deserve more budget. The BUDGET Method Response Process 1484A may also initiate a financial transaction to send a fund from the Distributor to pay for the above use, or may distribute the budget to Distributor 106 using Distribution Process 1472A. A response to Distributor 106 that grants more budget (or denies more budget) may be sent immediately in response to request communication 1482AB or later as part of another communication. When the response communication is received at the distributor's VDE node 106, it can be processed using the response process 1475B in the copy held by the distributor of BUDGET method 1510B. Response process 1475B may then process the additional budget as described above.

In addition to posting budget information, the processing and control chain may also pass control information that governs the way the budget is used. For example, the control information specified in the above example may also include control information that describes the processes and restrictions that apply to the distributor's redistribution of the right to use the author's content objects. Thus, when the distributor responds to a budget request from the user using the distribution process 1472B in the copy owned by the distributor of the BUDGET method 1510B (similar to the communication between VDE nodes 106 and 102 described above). Communication between the user VDE on VDE node 112 and the distributor on node 106), a distribution and request / response / response process similar to that described above can be initiated.

Thus, in this example, a single method provides multiple dynamic behaviors based on different "induced" events. For example, a single BUDGET method 1510 may support any or all of the events listed below:

<tables num="24"><img file="JP4995980B2_D0024.tif" /></tables>

<tables num="25"><img file="JP4995980B2_D0025.tif" /></tables>

Example of reciprocal method process A. Budget FIGS. 42a, 42b, 42c and 42d are flowcharts showing examples of process control steps performed as typical examples of the BUDGET method 2250 provided in a preferred embodiment, respectively. In a preferred embodiment, the BUDGET method 2250 may operate in one of four different modes: Use (Fig. 42a) Administrative requirements (Fig. 42b) Administrative response (Fig. 42c) Administrative response (Fig. 42d) In general, the "use" mode of the BUDGET method 2250 is called in response to an event related to the use of an object or its contents. The "administrative request" mode of the BUDGET method 2250 is called by or for the user in response to some user action that requires contact with the VDE financial provider, and the task is basically to VDE the administrative request. Send it to your financial provider. The "administrative response" mode of the BUDGET method 2250 responds to the receipt of the administrative request sent from the VDE node to the VDE financial provider by calling the "administrative request" of the BUDGET method 2250 in Figure 42b. It is done in. The VDE financial provider sends an administrative object to the VDE user node as a result of a call to the "administrative response" of BUDGET method 2250. Finally, the "administrative response" call of the BUDGET method 2250 in Figure 42b responds to the receipt of the administrative request sent by the "administrative response" call of the method shown in Figure 42c, in response to the line at the user VDE node. It is said.

In a preferred embodiment, the same BUDGET method 2250 performs each of the four different step sequences shown in FIGS. 42a-42d. In a preferred embodiment, these various different modes can be called by passing different event codes to the BUDGET method 2250. Of course, it is possible to use four separate BUDGET methods instead of a single BUDGET method with four different "dynamic personalities", but in a preferred embodiment the same BUDGET method. Is used for each of these four types of calls to achieve a particular effect.

Looking at Figure 42a, the "use" call to the BUDGET method 2250 first primes the budget audit tracking (blocks 2252, 2254) and then gets the DTD for the budget UDE. It is used to get and read the budget UDE (blocks 2256 ~ 2262). The BUDGET method 2250 in this "use" call then determines if the budget audit date has expired and terminates it if it has expired (the "yes" exit of decision block 2264, blocks 2266, 2268). ). Unless the budget audit date has expired, the method can then update the budget with atomic elements and event counts (which may also use other information) (blocks 2270, 2272), and then the budget user. Save audit records to the Budget Audit Tracking UDE before termination (end point 2278) (blocks 2274, 2276).

Looking at Figure 42b, the first six steps (blocks 2280-2290) are performed by the user VDE node in response to some user behavior (eg request to access new information, new budget request, etc.). It can be done. This "administrative request" call of BUDGET method 2250 may provide audit tracking (blocks 2280, 2482). The method can then queue the request for proper budget management processing (blocks 2284, 2286). Finally, the method can save the appropriate audit tracking information (blocks 2288, 2290). After some time, the user VDE node can provide communication audit tracking (blocks 2292, 2294) and then write budget management requests to the management object (block 2296). This step can obtain information from the safety database as needed from sources such as budget UDEs, budget audit tracking UDEs (s), and budget management request records (s). 2298).

Block 2296 may then communicate the administrative object to the VDE financial provider, or block 2296 may pass the administrative object to another communication process or method that makes arrangements for such communication to occur. .. If desired, method 2250 may then save the communication audit tracking (blocks 2230, 2302) before termination (end point 2304).

FIG. 42c is a flow chart illustrating an example of a process control step performed by an example BUDGET method 2250 provided in a preferred embodiment operating in "administrative response" mode. The steps shown in Figure 42c are performed by a VDE financial provider that has received a management object, including, for example, a budget management request created by Figure 42b (block 2296) (and communicated to, for example, the VDE administrator). ..

Upon receiving the administrative object, the BUDGET method 2250 may provide budget communication and response audit tracking at the VDE financial provider site (blocks 2306, 2308), then unpack the administrative object in it. Retrieve budget requests (s), audit tracking (s), and records (s) (block 2310) contained in. This information retrieved from the administrative object is written by the VDE financial provider into its secure database (block 2312). The VDE financial provider then retrieves the budget request (s) and determines the response method that must be executed to process the request (blocks 2314, 2316). The BUDGET method 2250 can send the event (s) contained in the request record (s) to the appropriate response method and generate the response record and response request based on the RESPONSE method (block 2318). The process that takes place in block 2318 may satisfy the budget request by writing the appropriate new response record to the VDE financial provider's security database (block 2320). The BUDGET method 2250 can then write these budgetary response records into the administrative object (blocks 2322, 2324) and then communicate back to the user node that initiated the budget request. The BUDGET method 2250 can then save the communication and response processing audit tracking information to the appropriate audit tracking UDE (s) before termination (end point 2330) (blocks 2326, 2328).

FIG. 42d is a flowchart showing an example of a program control step performed by the representative BUDGET method 2250, which operates in the administrative response mode. The steps shown in Figure 42d can be performed, for example, by a VDE user node that has received an administrative object containing budget-related information. The BUDGET method 2250 may first provide budgetary and communication audit tracking (blocks 2332, 2334). The BUDGET method 2250 then extracts the records and requests from the administrative object that received them and writes the response records to the VDE-safe database (blocks 2336, 2338). The VDE user node then saves budgetary and communication audit tracking information in the appropriate audit tracking UDE (s) (blocks 2340, 2341).

After some time, the user VDE node can retrieve the response record from the safety database to determine which method is needed for its processing (blocks 2344, 2346). The VDE user node may optionally provide communication audit tracking to record the processing results of response events (blocks 2342, 2343). The BUDGET method 2250 can then send the event (s) contained in the reply record (s) to the REPLY method, inserting the safety database record, inserting a new budget record, deleting the old budget record and / or Generate / update as needed, such as applying changes to budget records (blocks 2348, 2350). BUDGET method 2250 can then delete the response record from the safety database (blocks 2352, 2353) before writing audit tracking (blocks 2354, 2355) and ending (end point 2356). B. Registration 43a-43d are flowcharts showing an example of a program control step performed by a representative example of the REGISTER method 2400 provided in a preferred embodiment. In this example, the REGISTER method 2400 performs the step example shown in Figure 43a when operating in "use" mode, and the step example shown in Figure 43b when operating in "administration request" mode. Perform the steps shown in Figure 43c when operating in "Management Response" mode, and perform the steps shown in Figure 43d when operating in "Management Response" mode.

The steps shown in FIG. 43a can be performed on the user VDE node, for example, by or for the user in response to some action. For example, a user can request himself to access an object that has not yet (that is, is still) properly registered. In response to such a user request, the REGISTER method 2400 performs a registration audit tracking UDE (blocks 2402, 2404) in advance before determining whether the requested object has already been registered (decision block 2406). be able to. If the object is already registered (a "yes" exit to decision block 2406), the REGISTER method can exit (at the end point 2408). If the object has not yet been registered (a "no" exit to decision block 2406), the REGSITER method 2400 can access the VDE node's safety database PERC 808 and / or registered MDE (block 2410). REGISTER method 2400 is this PERC A suitable registration record set can be extracted from the 808 and / or registered MDE (block 2412) and determines if all of the requested elements required to register the object are present. Can be done (judgment block 2414). If something (at least one) is missing (a "no" exit to decision block 2414), REGISTER method 2400 queues the registration request to the communication manager and then queues. The REGISTER method can be suspended until the requested request is satisfied (blocks 2416, 2418). Block 2416 may have the effect of communicating, for example, a registration request to a VDE distributor. When the request is satisfied and the registration request record is received (block 2420), the test for decision block 2414 is met ("yes" exit to decision block 2414) and REGISTER method 2400 can proceed. At this stage, REGISTER method 2400 is the PERC accessed in block 2410. Allows the user to select registration options from the set of method options allowed by 808 (block 2422). To give one simple example, PERC The 808 allows users to pay with VISA or Mastercard, but not with American Express. Block 2422 can display a prompt asking the user to choose between paying with their Visa card or paying with their Mastercard (block 2424). The REGISTER method 2400 preferably checks the validity of the registration option selected by the user and, if the initial user option is invalid, requests the user to select another option (block 2426, "No" exit for decision block 2428). Once the user has completed the selection of all requested registration options and all of those selections are valid (yes exit to decision block 2428), REGISTER method 2400 corresponds to this object and this user. The PERC is a user registration table (URT) that specifically represents the user registration selections made by this user. Can be written with 808 and / or other registration information required by the registration MDE (blocks 2430, 2432). REGISTER method 2400 can then write the registration audit record to the safety database (blocks 2432, 2434) before exiting (at termination point 2436).

Figure 43b shows an example of the "administrative request" mode of REGISTER method 2400. This management request mode is performed on the VDE user system to generate the appropriate management objects to communicate with the VDE distributor or with other appropriate VDE subscribers requesting registration information. It can be. Thus, for example, the step shown in FIG. 43b can also be performed as part of block 2416, which "queues the record of registration requests" shown in FIG. 43a. To make a registration management request, REGISTER method 2400 can first perform communication audit tracking in advance (blocks 2440, 2442) and then access the safety database to obtain registration data (block 2444). Accessing the safety database in this way allows, for example, owners and / or publishers of registered objects to find demographics, users themselves, or other information about them. As a specific example, consider the case where the currently registered object is a spreadsheet software program. The distributor of the object may want to know what other software the user has registered with. For example, a distributor may be willing to offer a preferential price if the user registers a "braid" of a large number of software products distributed by that same distributor. Thus, the type of information solicited by the "user registration" card contained in most standard software packages should, in the preferred embodiment, be solicited and automatically obtained at the time of registration. Can be done. To protect a user's right to privacy, REGISTER Method 2400 can pass such user-specific data through a privacy filter (block 2446). This filter is less so that the user can prevent certain information from being revealed to the outside world. Both can be partially customized by the user. The REGISTER method 2400 can write the resulting information to the managed object along with the appropriate registration request information that identifies the object and other appropriate parameters (blocks 2248, 2450). The REGISTER method 2400 can then pass this managed object to the communicator. The REGISTER method 2400 can then save the communication audit tracking (blocks 2452, 2454) before exiting (at the end point 2456).

FIG. 43c contains a step of REGISTER method 2400 that can be performed by the VDE distributor as soon as it receives the registration management object sent by block 2448 in FIG. 43b. The REGISTER method 2400, in this "management response" mode, first performs appropriate audit tracking in advance (blocks 2460, 2462), then unwraps the received management object and makes the relevant (one or more) registration requests. Configuration information can be written to the safety database (blocks 2464, 2466). The REGISTER method 2400 then retrieves the management request from the safety database and determines which response method should be run to process the request (blocks 2468, 2470). If the user does not provide enough information to register the object, REGISTER method 2400 may fail (blocks 2472, 2474). Otherwise, REGISTER method 2400 sends the (one or more) events contained in the appropriate (one or more) request records to the appropriate response method, and the response records and response requests (eg, (1)). One or more) PERC and / or UDE) can be generated and written to the safety database (blocks 2476, 2478). REGISTER method 2400 can then write the appropriate registration management response record to the management object (blocks 2480, 2482). Such information includes, for example, one or more replacement PERCs. There are 808s, methods, UDEs (one or more), etc. (block 2482). This allows, for example, to distribute a limited rights permission that gives the user only enough information to register the object, and then replace the limited rights permission with a wider range of permissions as soon as it is registered. Allows the user to grant more complete access to those objects. REGISTER method 2400 can then save communication and response processing audit tracking (blocks 2484, 2486) before exiting (at termination point 2488).

Figure 43d shows the steps that can be taken by the VDE user node as soon as it receives the management object generated / transmitted by block 2480 in Figure 43c. The steps shown in Figure 43d are very similar to the steps shown in Figure 42d for the management response processing of the BUDGET method. C. Audit FIGS. 44a-44c are flowcharts showing some examples of program control steps performed by a representative example of AUDIT method 2520 provided in a preferred embodiment. Similar to the examples described above, the AUDIT method 2520 provides three different modes of operation in the preferred embodiment. FIG. 44a shows the various steps performed by the AUDIT method in "management request" mode, FIG. 44b shows the various steps performed by this method in "management response" mode, and FIG. 44c shows the "management". It shows the various steps taken by this method in "Reply" mode.

The AUDIT method 2520, which operates in "administrative request" mode as shown in Figure 44a, is typically performed, for example, on a VDE user node, either by the user or based on a request for the user. For example, the user may have requested an audit, or the timer to start communicating audit information to the VDE content provider or other VDE subscriber may have expired. In a preferred embodiment, different audits may be performed by different VDE subscribers for the entire same process. The invocation of a particular "audit" method 2520 may be initiated for any one (or all) of the VDE subscribers involved. As soon as the AUDIT method 2520 is implemented, this method can pre-audit the management audit tracking (thus, in the preferred embodiment, the audit process itself can be audited) (blocks 2522, 2524). AUDIT method 2520 can then queue administrative processing requests (blocks 2526, 2528) and store audits of administrative audit tracking in the safety database (blocks 2530, 2532). After some time, AUDIT method 2520 pre-performs communication audit tracking (blocks 2534, 2536) and then makes (one or more) audit management requests to a specific UDE, (one or more) audit tracking UDE. You can write to one or more managed objects (blocks 2538, 2540) based on (one or more) managed records stored in and / or the safety database. AUDIT method 2520 can then store the appropriate information in the communication audit tracking (blocks 2542, 2544) before exiting (at termination point 2546).

Figure 44b shows an example of a step generated by block 2538 in Figure 44a and performed by a VDE content provider, finance provider, or other audit VDE node as soon as it receives a communicated managed object. AUDIT method 2520 in this "management response" mode first pre-audits communication and response audit tracking (blocks 2550, 2552), then unwraps the received management object and contains it (blocks 2550, 2552). Audit requests (one or more), audit tracking (one or more), and audit records (one or more) can be retrieved and stored in a secured database (blocks 2554, 2556). AUDIT method 2520 can then retrieve those (one or more) audit requests from the safety database and determine the response method to run to process those requests (blocks 2558, 2560). At this stage, AUDIT method 2520 sends the (one or more) events contained in the (one or more) request records to the appropriate response method, and based on this method, the (one or more) response. Recordings and requests can be made (blocks 2562, 2564). The processing block 2562 may include communication to the outside world.

For example, AUDIT method 2520 may call an external process at this point, for example to make an electronic property transfer to the user's bank account or other bank account. The AUDIT management response can also call an external process that interfaces the VDE to one or more existing computer systems, if desired. This external processing can be passed through the user's account number, PIN, balance dollars, or any other information set up or associated with the VDE audit tracking currently being processed. This external process can communicate with non-VDE hosts and the information passed through them can be used as part of these communications. For example, external processing can generate an automated clearing house (ACH) record in a file submitted to a bank. This mechanism can provide the ability to automatically credit or debit bank accounts in any financial entity. This same mechanism can be used to communicate with existing credit card (eg, VISA) networks by submitting a VDE-based billing amount to the billing account.

Once the appropriate (one or more) audit response records have been generated, AUDIT method 2520 writes the (one or more) audit management records to the management object and communicates with the VDE user node that generated the audit request. Can be returned (blocks 2566, 2568). AUDIT method 2520 can then store communication and response processing audit information in appropriate audit tracking (one or more) before exiting (at termination point 2574) (blocks 2570, 2572).

FIG. 44c shows an example of a step that can be performed again by AUDIT method 2520 on the VDE user node as soon as it receives the managed object generated by block 2566 in FIG. 44b. Steps 2580-2599 shown in Figure 44c are similar to the steps shown in Figure 43d for REGISTER method 2400 in "administrative response" mode. Simply put, these steps update the safety database record by receiving and extracting the appropriate response record from the managed object (block 2584) and then processing the received information appropriately. Accompanied by taking other necessary actions (blocks 2595, 2596). An example of a content-based method driven by an event VDE Method 1000 is designed to provide a very flexible and highly modular approach to safe processing. The complete VDE process for servicing "user events" can typically be configured as a combination of several methods 1000. For example, a typical process for reading content or other information from object 300 may involve the following methods:

EVENT method METER method BILLING method BUDGET method Figure 45 shows the VDE in response to an event. This is an example of a series of methods that are sequentially performed by 100. In this example, when an event occurs, EVENT method 402 determines if it is significant by "determining the importance" of that event. Not all events are significant. For example, if EVENT method 1000 in control processing dictates that usage should be metered based on the number of pages read, a user who wants to read less than one page of information. The request "event" may be ignored. In another example, if the system event represents a request to read some number of bytes, and the EVENT method 1000 is part of a control process designed to weigh paragraphs. this EVENT method, by evaluating the read request, the requested bytes, had paragraph of shoes can decide whether it is expressed. This process may involve mapping to "atomic elements" which will be described in more detail below.

The EVENT method 402 filters out events that are not significant to the specific control method associated with it. The EVENT method 402 can pass the event whose importance is determined to the METER process 1404. This process weighs or discards the event based on its own specific criteria.

In addition, this preferred embodiment achieves an optimization called "pre-check". The EVENT method / process 402 performs this "pre-check" based on information about weighing, billing, and budgeting to determine if processing based on an event is allowed. For example, suppose that when a user accesses the content of certain information, the budget is already exceeded and no further access is permitted. Although the BUDGET method 408 can make such a determination, the recording and processing performed by the BUDGET method 404 and / or the BILLING method 406 is, for example, charged to the user for access that is actually denied. You may have to "redo" to prevent this. It may also be more efficient to perform a "pre-check" within the EVENT method 402 in order to reduce the number of transactions that must be "redoed".

The METER method 404 can store audit records in, for example, the weighing "tracking" UDE 1200, and information about that event can also be stored in the weighing UDE 1200. For example, the METER method 404 can increment or decrement the "weighing" value in the weighing UDE 1200 each time the content is accessed. These two different data structures (Weighing UDE and Weighing Tracking UDE) are maintained, for example, to allow reporting records that are maintained separately from records that are kept for internal operations. Can be done.

Once an event has been weighed by METER method 404, the weighed event can be weighed by BILLING method 406. BILLING method 406 determines how much budget is consumed by the event and keeps a record useful for mediation between weighing and budget. Thus, for example, the BILLING method 406 can read the budget information from the budget UDE, record the billing information in the billing UDE, and write one or more audit records to the billing tracking UDE. Although some billing tracking information may duplicate weighing and / or budget tracking information, that billing tracking information, for example, allows content creator 102 to expect a fixed amount of payment. It is useful and also serves as an arbitration check that mediates the metering tracking information sent to author 102, for example, with the budget tracking information sent to an independent profitable provider.

The BILLING method 406 can then pass the event to the BUDGET method 408. The BUDGET method 408 sets a limit and records information on transactions associated with that limit. For example, the BUDGET method 408 can store budget information in the budget UDE and audit records in the budget tracking UDE. The BUDGET method 408 can result in a "budget balance" field in the budget UDE that is decremented by the amount specified by the BILLING method 406.

Once the various methods 402, 404, 406 and 408 have processed the event, the information may be revealed or other actions may be taken.

As mentioned above, the PERC 808 in the preferred embodiment may be provided with a "control method" that actually "supervises" the performance of other requested methods in the control process. FIG. 46 shows how the requested methods / processes 402, 404, 406 and 408 of FIG. 45 can be organized and controlled by control method 410. Control method 410 calls an event for rapid processing, or all other methods 402, 404, 406 and 408, or in response to an "event". Supervise the process.

Control methods work at the level of control set 906 in PERC 808. These methods provide a flow of structure, logic and control between the acquired heterogeneous methods 1000. This mechanism allows content providers to generate any chain of processes they desire, and the specific chain of processes that downstream redistributers (within the permissible limits). It is also possible to modify it. This concept of control methods provides great flexibility.

FIG. 47 shows an example of the set method 412, which aggregates the METER method 404, the BUDGET method 406, and the BILLING method 408 into the set processing flow. Aggregate method 412 can, for example, combine various elements of weighing, budgeting and billing into a single method 1000. The aggregate method 412 makes it possible to improve efficiency as a result of batch processing of METER method 404, BUDGET method 406, and BILLING method 408, but it reduces flexibility because it reduces modularity.

Many different methods can be executed at the same time. FIG. 48 shows an example of event processing according to a preferred embodiment using a large number of METER methods 404 and a large number of BUDGET methods 1408. Several events can be applied to a number of different requested methods that act independently or cumulatively. For example, in the example shown in FIG. 48, the weighing method 404a can maintain a weighing tracking and weighing information record that is independent of the weighing tracking and weighing information records maintained by the METER method 404b. Similarly, the BUDGET method 408a can maintain records independently of the records maintained by the BUDGET method 408b. Some events can still be handled by the weighing method 404a and the BUDGET method 408a, bypassing the BILLING method 408. A wide variety of combinations, each consisting of a different variant, are possible. Typical example of VDE method Method 1000 has a virtually infinite number of combinations, some of which can be specified by the user, but in a preferred embodiment, the more basic object manipulations and others provided by VDE 100. Some basic "use" type methods are preferably used to control most of the functions of. For example, typically the following high-level methods will be provided for object manipulation.

OPEN method READ method WRITE method CLOSE method The OPEN method is used to control the opening of a container so that it has access to its contents. The READ method is used to control access to the contents of a container. The WRITE method is used to control the insertion of content into a container. The CLOSE method is used to close an open container.

Some auxiliary methods are provided to perform some of the steps required by the OPEN, READ, WRITE and / or CLOSE methods. Such auxiliary methods include:

ACCESS method PANIC method ERROR method DECRYPT method ENCRYPT method Contents DESTROY method INFORMATION method OBSCURE method FINGERPRINT method EVENT method CONTENT method EXTRACT method EMBED method METER method BUDGET method REGISTER method BILLING method AUDIT method The ACCESS method can be used to physically access the content associated with an open container, which can be anywhere. The PANIC method can be used to disable at least some of the VDE nodes if a security breach is detected. The ERROR method can be used to manipulate the error situation. The DECRYPT method is used to decrypt the encrypted information. The ENCRYPT method is used to encrypt information. The content DESTROY method is used to destroy the ability to access specific content in a container. The INFORMATION method is used to provide public information about the contents of the container. The OBSCURE method is used to reduce the value of the content read from the opened container (eg, write the word "SAMPLE" on top of the displayed image). The FINGERPRINT method is used to indicate who revealed the content from a secure container by marking the content. Event methods are used to transform an event into a different event in response to another method. open FIG. 49 is a flowchart showing an example of processing control steps according to a preferred embodiment for an example of the OPEN method 1500. Different OPEN methods have different detailed steps. However, the OPEN method shown in FIG. 49 is representative of the "open" method with a relatively large number of features provided by the preferred embodiment. FIG. 49 shows a macroscopic view of the OPEN method. Taken together, FIGS. 49a-49f show an example of detailed program-controlled steps performed to implement the method shown in FIG. 49.

The processing of the OPEN method starts from the "open event". This open event is triggered by a user application or by an operating system interrupt or various other mechanism that gains or interrupts control. For example, a user application can make a request to access certain contents stored in a VDE container. As another example, another method may issue a command.

In the example shown, the open event is handled by control method 1502. Control method 1502 can also call other methods to handle the event. For example, control method 1502 can also call EVENT method 1504, METER method 1506, BILLING method 1508, and BUDGET method 1510. Not all OPEN control methods call such additional methods, and the OPEN method 1500 shown in Figure 49 is just a representative example.

Control method 1502 passes the description of the open event to EVENT method 1504. EVENT method 1504 is significant, for example, in the sense that it determines if an open event has been granted permission and that the open event must be processed by METER method 1506, BILLING method 1508 and / or BUDGET method 1510. Is determined. The EVENT method 1504 maintains audit tracking information within the audit tracking UDE and can use the Event Method Data Element (MDE) to determine event permissions and significance. The EVENT method 1504 can also map open events to "atomic elements" into counts that can be processed by METER method 1506, BILLING method 1508 and / or BUDGET method 1510.

In the OPEN method 1500, once the EVENT method 1504 is called and its return is successful, the control method 1502 then calls the METER method 1506 and passes the atomic element and the count returned by the EVENT method 1504 to that METER method. be able to. METER method 1506 can maintain audit tracking information in the audit tracking UDE of the METER method and measurement information in the UDE of the METER method. In a preferred embodiment, the METER method 1506 returns the metric value to the control method 1502 if it succeeds in completing.

In a preferred embodiment, control method 1502 calls BILLING method 1508 as soon as it receives notification that METER method 1506 has completed successfully. Control method 1502 can pass the metric value provided by METER method 1506 to BILLING method 1508. The BILLING method 1508 can read and update the billing information maintained in the map MDE of the BILLING method and maintain and update the audit tracking in the audit tracking UDE of the BILLING method. The BILLING method 1508 can return the billing amount and the completion code to the control method 1502.

If the BILLING method 1508 is successfully completed, the control method 1502 can pass the billing price provided by the BILLING method 1508 to the BUDGET method 1510. The BUDGET method 1510 can read and update the budget information in the UDE of the BUDGET method and maintain the audit tracking information in the audit tracking UDE of the BUDGET method. The BUDGET method 1510 can return the budget amount to control method 1502 and (for this type of event) a completion code that indicates whether the open event has exceeded the user's budget.

Upon completion of BUDGET method 1510, control method 1502 can generate a channel and finalize read / use control information in preparation for a later call to the READ method.

Figures 49a-49f are more detailed descriptions of the OPEN Method 1500 example shown in Figure 49. Referring to Figure 49a, in response to an open event, control method 1502 first determines the identifier of the object to be opened and the identifier of the user who requested the object to be opened (block 1520). Control method 1502 then determines if the object to be opened is registered with this user (determination block 1522). In a preferred embodiment, this determination is, at least in part, a PERC associated with a particular object and a particular user as determined by block 1520. This is done by reading the 808 and User Rights Table (URT) elements (block 1524). If the user is not registered for this particular object (a "no" exit to decision block 1522), control method 1502 calls the REGISTER method for that object, and once registration is complete, OPEN method 1500 is used. Can be resumed (block 1526). Block 1526 of the REGISTER method can be independent or time-independent. For example, it may take a relatively long time to complete the REGISTER method (for example, before the VDE distributor or other subscriber responsible for providing the registration registers the user for this particular object. , When you want to do a credit check for that user, etc.).

Suppose a correct URT exists for this user and object, and that object indicates that it is registered for this user (a "yes" exit to decision block 1522), and control method 1502 says that the object is already this. It can be determined whether it is open to the user (determination block 1528). This test avoids creating redundant channels to open objects that are already open. Assuming the object has not yet been opened (a "no" exit to decision block 1528), control method 1502 creates a channel and attaches the appropriate open control element to that channel (block 1530). This method reads the appropriate open control elements from the safety database (or, for example, a container in the case of a moving object) and controls these specific appropriate open control elements to open to this user. "Connect" or "connect" control elements. Thus, block 1530 associates an event with one or more appropriate method cores, appropriate load modules, appropriate user data elements, and appropriate method data elements read from the safety database (or container). (Block 1532). At this point, control method 1502 implements the open event (which started the OPEN method to start), the object ID and user ID (as determined by block 1520), and the safety database "transaction" (block 1536). Specifies the channel ID of the channel generated by block 1530 for subsequent EVENT method 1504, METER method 1506, BILLING method 1508 and BUDGET method 1510 for. Before doing so, control method 1502 pre-audits (block 1533), even if the transaction fails or is interfered with.

The detailed steps taken by the EVENT method 1504 are shown in Figure 49b. The EVENT method 1504 can first perform event audit tracking (block 1538) if necessary. This allows you to write to the audit tracking UDE of the EVENT method (block 1540). The EVENT method 1504 can then use the map MDE to perform a step (block 1542) of mapping open events to atomic element numbers and counts. The map MDE for the EVENT method can be read from the safety database (block 1544). This mapping process performed by block 1542 can, for example, determine whether an open event can be weighed, charged, or budgeted, and can be weighed, charged, and / or budgeted for an open event. It can be converted into some separate atomic element to create. As an example, block 1542 can make a one-to-one mapping between an open event and an "open" atomic element and provides one open atomic element for every five times the object is opened. You can only do it. The map block 1542 preferably returns an open event, an event count, an atomic element number, an object ID, and a user ID. This information can be written in the audit tracking UDE of the EVENT method (blocks 1546, 1548). In a preferred embodiment, a test (decision block 1550) is then performed to determine if the EVENT method has failed. Specifically, the determination block 1550 can determine whether or not an atomic element number has been generated. If no atomic element number has been generated (this is, for example, this open event is METER method 1506, BILLING method 1508 and / or BUDGET.

Control method 1502 determines whether it failed or succeeded by testing the completion code returned by EVENT method 1504 (decision block 1552). If the EVENT method fails (a "no" exit to decision block 1552), control method 1502 "rolls back" the secure database transaction (block 1554), indicating that the OPEN method has failed. Return itself (block 1556). In this context, "rolling back" a safety database transaction means, for example, "undoing" the changes made to the audit tracking UDE by blocks 1540, 1548. However, in a preferred embodiment, this "rollback" made by block 1554 "does not undo" the changes made to the control method audit UDE by blocks 1532, 1534.

Assuming the EVENT method 1504 is successfully completed, the control method 1502 then calls the METER method 1506 shown in Figure 49c. In a preferred embodiment, METER method 1506 pre-performs metric audit tracking, if necessary (block 1558). This typically involves writing the METER method to the audit tracking UDE (block 1560). METER method 1506 then modifies the metric UDE by reading the METER method UDE from the safety database (block 1562) and adding the appropriate event count to the metric contained in the metric UDE (block 1564). Then rewrite the modified weighing UDE to the safety database (block 1562). In other words, block 1564 reads the weighing UDE, increments the weighing count it contains, and writes the modified weighing UDE back into the safety database. In a preferred embodiment, the METER method 1506 can then write the metric audit tracking information to the METER method's audit tracking UDE, if necessary (blocks 1566, 1568). The METER method 1506 preferably determines whether the metric increment was successful by performing a test next (determination block 1570). METER method 1506 returns to control method 1502 with a completion code (eg success or failure) and a metric determined by block 1564.

Control method 1502 tests whether the METER method was successful, for example by examining the completion code (determination block 1572). If the METER method fails (a "no" exit to decision block 1572), control method 1502 "rolls back" the secure database transaction (block 1574) and returns with an indication that the OPEN method has failed. (Block 1576). Assuming the METER method is successful ("yes" exit to decision block 1572), control method 1502 calls BILLING method 1508 and passes the metric value provided by METER method 1506 to this method.

An example of the steps performed by the BILLING method 1508 is shown in Figure 49d. BILLING method 1508 can perform billing audit tracking in advance by writing to the audit tracking UDE of the BILLING method in the safety database (block 1580), if necessary (block 1578). The BILLING method 1508 can then use the map MDE of the BILLING method read from the safety database to map atomic element numbers, counts and weighed values to billing amounts (blocks 1582, 1584). For example, by providing a map MDE of an independent BILLING method that includes price list information, this billing process allows for separately deliverable pricing. The resulting charges generated by block 1582 may be written to the audit tracking UDE of the BILLING method (blocks 1586, 1588) or returned to control method 1502. In addition, the BILLING method 1508 can determine if the billing amount was correctly selected by block 1582 (determination block 1590). In this example, the tests performed by block 1590, broadly speaking, require more than just looking at the amount returned. This is because the billing amount can be changed in some unpredictable methods specified by the map MDE of the BILLING method. The control then returns to control method 1502. This method determines whether the BILLING method succeeded or failed by testing the completion code provided by the BILLING method 1508 (block 1592). If the BILLING method fails (a "no" exit to decision block 1592), control method 1502 "rolls back" the secure database transaction (block 1594), Returns the indication that the OPEN method failed (block 1596). If the test performed by decision block 1592 shows the success of the BILLING method (a "yes" exit to decision block 1592), control method 1502 can call BUDGET method 1510.

Other BILLING methods can use site, user and / or usage information, for example, to finalize pricing information. For example, information about the existence or absence of an object can be used to determine the purchase of a "matching item", competitive discounts, and so on. Usage levels can be broken down into BILLING methods that determine price breaks for different levels of usage. The BILLING method has the property of redeeming currencies, allowing purchases and / or pricing to be made in many different currencies. There are many other possibilities that can be incorporated into the BILLING method to determine the amount of budget consumed by an event.

An example of the detailed control steps performed by the BUDGET method 1510 is shown in Figure 49e. The BUDGET method 1510 can perform budget audit tracking in advance by writing to the budget tracking UDE, if necessary (blocks 1598, 1600). The BUDGET method 1510 can then perform a billing operation by adding the billing amount to the budget price (block 1602). This operation can be done, for example, by reading the UDE of the BUDGET method from the safety database, modifying it, and then writing it back to the safety database (block 1604). The BUDGET method 1510 can then write budget audit tracking information to the audit tracking UDE of the BUDGET method (blocks 1606, 1608). In this example, the BUDGET method 1510 can finally determine if the user has run out of budget by determining if the budget price calculated by block 1602 is out of range (determination block 1610). it can. If the user runs out of budget (a "yes" exit to decision block 1610), the BUDGET method 1510 can return the "failed complete" code to control method 1502. The BUDGET method 1510 then returns to the control method 1502, which tests whether the completion code of the BUDGET method was successful (decision block 1612). If the BUDGET method fails (a "no" exit to decision block 1612), control method 1502 "rolls back" the secure database transaction and returns itself with the indication that the OPEN method failed ("No" exit). Blocks 1614, 1616). Assuming that control method 1502 determines that the BUDGET method was successful, this control method can perform the additional steps shown in Figure 49f. Wear. For example, control method 1502 can write open audit tracking, if necessary, by writing audit information to the audit UDE previously performed in block 1532 (blocks 1618, 1620). Control method 1502 can then determine read event processing (block 1622) using the user rights table and PERC associated with the object and the user to determine the channel (block 1624). This channel may be shared among users of VDE Node 600 if desired, or may be used only by designated users.

Control method 1502 then tests, in a preferred embodiment, whether the read channel establishment was successful (determination block 1626). If the read channel was not successfully established (a "no" exit to decision block 1626), control method 1502 "rolled back" the secured database transaction and the OPEN method failed. Give a display (blocks 1628, 1630). Assuming the read channel is successfully established (yes exit to decision block 1626), control method 1502 can commit the secure database transaction (block 1632). This step of "consigning" a security database transaction, in a preferred embodiment, removes, for example, the intermediate price associated with the security transaction that has just taken place, and in some cases secures the modified UDE and MDE. Accompanied by writing to the database. Once a secure transaction has been entrusted by block 1632, it is generally not possible to "roll back" it. Control method 1502 can then "disassemble" the channel for open processing (block 1634) before exiting (block 1636). In some configurations, such as a multitasking VDE node environment, the open channel may be used at any time by any OPEN method that is constantly maintained and started. In other embodiments, the channel for open processing may be reconfigured and restarted each time the OPEN method is started. reading 50 and 50a to 50f show examples of processing control steps for performing a representative example of the READ method 1650. Comparing FIG. 50 with FIG. 49, it can be seen that, as described for the OPEN method 1500, the overall high-level processing is typically performed for the READ method 1650 as well. Therefore, when the READ method 1650 calls the control method 1652 in response to a read event, the control method executes the EVENT method 1654, the METER method 1656, the BILLING method 1658, and the BUDGET method 1660 in response. .. In a preferred embodiment, the READ control method 1652 can request a method for fingerprinting and / or obscuring the content before revealing the decrypted content.

50a to 50e are the same as those of FIGS. 49a to 49e. Of course, the same user data elements can be used for both the OPEN method 1500 and the READ method 1650, but the method data elements for the READ method can be quite different. In addition, user data elements may have different auditing, weighing processing, billing and / or budgeting criteria as opposed to open processing for reads.

Referring to Figure 50f, the READ control method 1652 must determine which key should be used to decrypt the content if it is trying to reveal the decrypted content to the user (block). 1758). The READ control method 1652, in part, is the PERC for that object. Based on 808 (block 1760), this key determination can be made. The READ control method 1652 then actually obtains the encrypted content to be decrypted by calling the ACCESS method (block 1762). This content is decrypted using the key determined by block 1758 (block 1764). The READ control method 1652 can then determine if a "fingerprint" is desirable (determination block 1766). If fingerprinting of its contents is desired (a "yes" exit to decision block 1766), the READ control method 1652 can call the FINGERPRINT method (block 1768). Otherwise, the READ control method 1652 determines if it is desirable to obscure the decrypted content (determination block 1770). If so, the READ control method 1652 can call the OBSCURE method to perform this function (block 1772). Finally, the READ control method 1652 can outsource a secure database transaction (block 1774), dismantle the read channel if desired (not shown), and terminate it (block 1776). writing 51 and 51a to 51f are flowcharts showing an example of processing control steps used to implement a representative example of the WRITE method 1780 in a preferred embodiment. The WRITE method 1780 uses the control method 1782 to call the EVENT method 1784, METER method 1786, BILLING method 1788, and BUDGET method 1790 in this example. Thus, in a preferred embodiment, writing information into a container (by overwriting information already stored in the container or by adding information to the container) can open the container or read it from the container. It can be weighed, charged, and budgeted in the same way that it is weighed, charged, and budgeted. As shown in Figure 51, the end result of the WRITE method 1780 typically reflects the new content by encrypting the content and updating the content and related information container table to reflect that content. Writing to an object.

Figure 51a for the WRITE control method 1782 is similar to Figures 49a and 50a for the OPEN and READ control methods, respectively. However, FIG. 51b differs slightly from the corresponding open and lead diagrams. Specifically, block 1820 is done if the WRITE EVENT method 1784 fails. This block 1820 reflects the new data by updating the map MDE of the EVENT method. This requires that the information written by block 1810 be read by block 1678 of the READ method in Figure 51b based on the map MDE of the same (but now updated) EVENT method.

Looking at Figure 51f, once the EVENT, METER, BILLING and BUDGET methods successfully return to the WRITE control method 1782, the WRITE control method writes the audit information to the audit UDE (blocks 1890, 1892) and then the contents. Determines (based on PERC and selectable arithmetic algorithms for the object and user) which key should be used to encrypt its contents before it is written into the container (blocks 1894, 1896). .. The CONTROL method 1782 then encrypts the content (block 1898) and writes the encrypted content to the object (block 1900) by calling the ENCRYPT method, for example. The CONTROL method 1782 then reflects the newly written information by updating the table containing the contents (and related information) for the container (block 1902) and after entrusting the safety database transaction (block 1904). , Return (block 1906). Close FIG. 52 is a flowchart showing an example of processing control steps for performing a representative example of the CLOSE method 1920 in a preferred embodiment. The CLOSE method 1920 is used to close an open object. In a preferred embodiment, the CLOSE method 1920 performs audit tracking in advance and writes audit information to the audit UDE (blocks 1922, 1924). The CLOSE method 1920 can then destroy the current (one or more) channels used to support and / or process one or more open objects (block 1926). As mentioned above, some types of installations (eg, multi-user or multi-tasking) do not require the step of breaking the channel. This is because the channel may be left running to process additional objects for the same user or different users. The CLOSE method 1920 also releases the appropriate records and resources associated with the object at this point (block 1926). The CLOSE method 1920 may then (if necessary) write audit tracking to the audit UDE before exiting (blocks 1928, 1930). Event FIG. 53a is a flow chart illustrating an example of processing control steps provided by a more general example of the EVENT method 1940 provided by the preferred embodiment. Examples of the EVENT method are given in FIGS. 49b, 50b and 51b described above. The EVENT method 1940 shown in Figure 53a is somewhat more generalized than the example above. Similar to the EVENT method example above, the EVENT method 1940 receives an event identifier along with the event count and event parameters. The EVENT method 1940 can perform EVENT audit tracking in advance (if necessary) by first writing the appropriate information to the audit tracking UDE of the EVENT method (blocks 1942, 1944). The EVENT method 1940 can then get the map DTD of the EVENT method from the safety database and load it (blocks 1946, 1948). The map DTD of this EVENT method describes the format of the map MDE of the EVENT method that is subsequently read and accessed immediately (by blocks 1950, 1952) in this example. In a preferred embodiment, the MDE and UDE may have any of a variety of different formats, which may be flexibly specified or dynamically modified depending on the installation, user, etc. .. In fact, the DTD describes how to read from the EVENT method's map MDE for the EVENT method 1940. The DTD is also used to specify how the method should write to the MDE and DTD. Thus, the DTD can be used to implement a privacy filter, for example by preventing certain confidential user information from being written to data structures that may be reported to third parties.

Block 1950 (Mapping events to atomic element numbers and event counts using the map MDE) is, in a sense, the heart of the EVENT method 1940. This step "maps" the event to the "atomic element number" to which the method subsequently called responds. An example of a processing control step performed by what can be called a representative example of this "mapping" step 1950 is shown in FIG. 53b.

The example in Figure 53b shows the process of converting a READ event associated with requesting a byte range 1001-1500 from a piece of concrete content into the appropriate atomic element. The mapping process of the EVENT method according to this example (block 1950 in FIG. 53a) can be described in detail as the typical process shown in FIG. 53b.

The EVENT method mapping process 1950 first determines the structure and content of the MDE by examining the event code (READ) in the EVENT method MDE (1952) using the EVENT method map DTD (1948). You can then test to determine if the event code was found in MDE (1956). If not found ("no" branch), the EVENT method mapping process may end without mapping the event to atomic element numbers and counts (1958). If the event is found in the MDE ("yes" branch), the EVENT method mapping process then sets the range of events (for example, bytes 1001-1500) to the event range mapping table stored in the MDE. Compare with atomic elements (block 1960). The result of this comparison may be one or more atomic element numbers, or the event range may not be found in the mapping table. The result of this comparison is then tested (block 1962) to determine if any atomic element number was found in the table. If not found ("no" branch), the EVENT method mapping process may end without selecting any atomic element numbers or counts (1964). If the atomic element number is found, this process can then calculate the atomic element count from the event range (1966). In this example, this process can calculate the number of bytes requested by subtracting the high byte range from the low byte range (eg 15000-1001 + 1 = 500). The mapping process of the EVENT method according to this example can then be terminated (block 1968) and return the atomic element number and count (one or more).

The EVENT method 1940 can then write the audit tracking of the EVENT to the audit tracking UDE of the EVENT method, if necessary (blocks 1970, 1972). The EVENT method 1940 can then be prepared to pass the atomic element number and event count (at exit point 1978) to the calling CONTROL method (or any other control process). But before that, the EVENT method 1940 can test whether an atomic element has been selected (determination block 1974). If there are no atomic elements selected, the EVENT method may fail (block 1974). This can happen for several reasons. For example, the EVENT method may fail to map an event to an atomic element if the user does not have permission to access a specific area of content not described by the EVENT method's MDE. This mechanism can be used, for example, to distribute customized versions of a piece of content, and by modifying the MDE of the EVENT method delivered to the user, to different versions of that content object. It can be used to control access. A specific use of this technique would be to control the distribution of versions of content fragments in different different languages (eg English, French, Spanish). Billing FIG. 53c is a flowchart showing an example of the processing control step performed by the BILLING method 1980. Examples of the BILLING method are also given in FIGS. 49d, 50d and 51d described above. The BILLING method 1980 shown in Figure 53c is somewhat more generalized than the above example. Like the BILLING method in the example above, the BILLING method 1980 also receives the weighed value and determines the amount to be charged. The BILLING method 1980 can first perform BILLING audit tracking (blocks 1982, 1984) by first writing the appropriate information (if necessary) to the audit tracking UDE of the BILLING method. The BILLING method 1980 can then get the map DTD of the BILLING method from the safety database and load it (blocks 1985, 1986). This map describes the map MDE of the BILLING method (eg, a price list, a table, or a parameter to a billing algorithm) that should be used by this BILLING method. The map MDE of the BILLING method can be delivered either as part of a content object or as a separately deliverable component that is combined with control information at registration.

The map MDE of the BILLING method can describe, in this example, the pricing algorithm to be used in this BILLING method (eg, a $ 0.001 charge per byte of emitted content). Block 1988 (Mapping Weighed Values to Billed Amounts) behaves like block 1950 in the EVENT method. That is, this block maps the weighed value to the billing price. Processing step 1988 also queries the safety database (restricted by privacy filters) to determine if any other object or information (eg, user information) exists as part of the algorithm of the BILLING method. judge.

The BILLING method 1980 then writes the BILLING audit tracking to the BILLING method's audit tracking UDE (blocks 1990, 1992) and returns to the CONTROL method (or other control process) calling the billing amount, if necessary. You can be ready to do it. But before that, the BILLING method 1980 can test whether the billing amount has been determined (determination block 1994). The BILLING method can fail if there is no fixed charge (Block 1996). This means that if the user is not authorized to access a specific area of the pricing table described by the MDE of the BILLING method (for example, information that does not exceed $ 100.00 can be purchased from this content object). ), It may occur. access FIG. 54 is a flowchart showing an example of a program control step performed by the ACCESS method 2000. As mentioned above, the ACCESS method can be used to access the content embedded in the object 300, i.e. to write, read, or perform other operations or processing. In many cases, this ACCESS method can be relatively simple. This is because objects can be stored, for example, in readily accessible local storage. However, in a general example, the ACCESS method 2000 would have to go through a more complex procedure to get the object. For example, an object (or part of an object) may only be available at a remote site and provided in the form of a real-time download or feed (for example, in the case of broadcast transmission). Even if the object is stored locally on the VDE node, it can be stored as a secure object, a protected object, so that the calling process is not directly accessible. The ACCESS method 2000 establishes various connection, routing, and security requirements required to access an object. These steps accompany the calling process so that it only needs to issue an access request, and when a particular ACCESS method corresponding to the object or class of objects actually accesses the object. It may be transparent to the process being called so that all details and logistics can be manipulated.

The ACCESS method 2000 can perform ACCESS audit tracking in advance (blocks 2002, 2004) by first writing to the ACCESS audit tracking UDE (if necessary). The ACCESS method 2000 can then read and load the DTD of the ACCESS method to determine the format of the ACCESS MDE (blocks 2006, 2008). The MDE of the ACCESS method, in a preferred embodiment, specifies source and routing information for a particular object to be accessed. Using the DTD of the ACCESS method, the ACCESS method 2000 can load correction parameters (eg, by phone number, account ID, password and / or request script in a remote resource dependent language).

The ACCESS method 2000 reads the MDE of the ACCESS method from the safety database, reads it according to the DTD of the ACCESS method, and loads the encrypted content source and routing information based on this MDE (blocks 2010, 2012). This source and routing information specifies the location of the encrypted content. The ACCESS method 2000 then determines if a connection to this content is available (determination block 2014). This "connection" can be, for example, an online connection to a remote site, a real-time information feed, or, for example, a path to a secure / protected resource. If a connection to this content is not currently available (a "no" exit to decision block 2014), ACCESS method 2000 takes steps to open that connection (block 2016). If the connection fails (for example, because the user does not have permission to access the protected and secure resource), ACCESS Method 2000 displays the failure and returns (Terminal 2018). On the other hand, if the open connection is successful, the ACCESS method 2000 gets the encrypted content (block 2020). The ACCESS method 2000 then exits (end point 2026) after writing the ACCESS audit tracking to the audit tracking UDE of the ACCESS method in the safety database (blocks 2022, 2024), if necessary. Decryption and encryption FIG. 55a is a flowchart showing an example of a processing control step performed by a representative example of the DECRYPT method 2030 provided by the preferred embodiment. In a preferred embodiment, the DECRYPT method 2030 obtains or withdraws a decryption key from the appropriate PERC 808 and uses it to decrypt a block of encrypted content. DECRYPT method 2030 is passed a pointer to a block of encrypted content or where the encrypted block is stored. DECRYPT 2030 selects a key number from a key block (block 2032). For security, content objects may be encrypted with more than one key. For example, a movie may be encrypted with the first key during its first 10 minutes and with the second key during the next 10 minutes (and so on). These keys are stored in a structure called a "key block" in PERC 808. This selection process involves determining the correct key to use from the key block in order to decrypt the content. The process for this selection is similar to the process used by the EVENT method to map the event to the atomic element number. DECRYPT method 2030 can then access the appropriate PERC 808 from safety database 610 and load the key (or "seed") from PERC (blocks 2034, 2036). This key information may be an actual decryption key used to decrypt the contents, or may be information that enables derivation and calculation of at least a part of the decryption key. If necessary, DECRYPT method 2030 will be used in block 2034 for PERC. Calculate the decryption key based on the information read from 808 (block 2038). The DECRYPT method 2030 then actually decrypts a block of encrypted information using the decryption key thus obtained and / or calculated (block 2040). DECRYPT method 2030 outputs the decrypted block (or a pointer to where it can be found) and exits (end point 2024).

FIG. 55b is a flowchart showing an example of the processing control step performed by the representative example of the ENCRYPT method 2050. The ENCRYPT method 2050 is passed as input a block of information to be encrypted (or a pointer to where it can be found). The ENCRYPT method 2050 can then determine the encryption key to use from the key block (block 2052). When selecting an encryption key, it is determined whether the key for a specific block with contents to be written already exists in the key block stored in PERC 808. If the key already exists in the key block, the appropriate key number will be selected. If such a key does not exist in the key block, a new key is calculated using an algorithm suitable for the encryption algorithm. This key is then PERC so that DECRYPT method 2030 can access the key and decrypt the content stored in its content object. Stored in the 808 key block. The ENCRYPT method 2050 then obtains, derives, and / or calculates the encryption key used to encrypt the information block by accessing the appropriate PERC (blocks 2034, 2036, 2038 in Figure 55a). Blocks 2054, 2056, 2058 similar to. The ENCRYPT method 2050 then actually encrypts the information block with the obtained and / or derived encryption key (block 2060) and then before exiting (termination point 2062). Prints an information block or a pointer to where it can be found. Contents FIG. 56 is a flowchart showing an example of a processing control step performed by a representative example of the CONTENT method 2070 provided by the preferred embodiment. CONTENT Method 2070, in a preferred embodiment, uses safeguards to create a "list" of protected content. For example, the CONTENT method 2070 can be used to extract insecure (public) information from secure content. Such public information extracted includes, for example, summaries, indexes, content lists, file directories, schedules for which content becomes available, or excerpts such as movie "trailers".

The CONTENT method 2070, in the first place, does the content to be provided and retrieved must be extracted from the secure content, or is the content already available in the object in the form of a static value? (Judgment block 2070). Some objects may include, for example, pre-stored summaries, indexes, content lists, etc., apparently provided for the purpose of being extracted by CONTENT Method 2070. If the object contains such a static value (a "static" exit to decision block 2072), CONTENT method 2070 simply reads the content information of this static value from the object (block 2074), hopefully. For example, after decoding, this content description is clarified (block 2076). On the other hand, if CONTENT method 2070 has to pull this list / description from a secure object (a "pull" exit to decision block 2072), the CONTENT method secures the information from the container according to the list algorithm. Can be read into and listed (block 2078). Extraction and embedding FIG. 57a is a flowchart showing an example of a processing control step performed by a representative example of the EXTRACT method 2080 provided by the preferred embodiment. EXTRACT method 2080 is used to copy or extract content from an object and put that content into a new object. In a preferred embodiment, EXTRACT method 2080 simply removes the content from one container and places it in another, without revealing the content at all. Here, both of these containers can be safe. What is different from the content extraction reveals is that the content is never exposed to the outside of a safe container. Extraction and embedding are complementary functions. That is, in extraction, the content is taken out of a container and a new container is created that includes the extracted content and some specific control information associated with the content. Embedding, on the other hand, takes the contents of an existing container and stores it (that is, its complete object) in another container, directly and / or by reference, and associates it with the existing contents. The obtained control information is integrated with the new content information.

The EXTRACT method 2080 first performs an audit UDE in advance (blocks 2082, 2084). The EXTRACT method then calls the BUDGET method to see if the user has enough budget (and is granted that right) to extract the content from the original object (block 2086). If the user's budget does not give permission to this extraction (a "no" exit to decision block 2088), EXTRACT method 2080 writes a failure audit tracking (block 2090) and exits (end point 2092). If the user's budget gives permission to this extraction (a "yes" exit to decision block 2088), EXTRACT method 2080 makes a copy of the extracted object, including specific rules and control information (block 2094). ). In a preferred embodiment, this step involves calling a method that actually controls the copy. This step, for example, is a specific PERC associated with the original object. Depending on the 808, it may or may not involve decryption and encryption. The EXTRACT method 2080 then checks whether the right to approve the extract to be initiated grants permission to any changes in control (determination block 2096). In some cases, the PERC associated with the original object to get the extraction right An exact copy of the 808 (or PERC included for this purpose) may be required to be placed in a new (destination) container (a "no" exit to decision block 2096). If no permission is granted to change control, extraction method 2080 simply writes audit information to the audit UDE (blocks 2098, 2100) before exiting (termination point 2102). On the other hand, if the extraction right gives the user permission to change control (yes to decision block 2096), the EXTRACT method 2080 (for example, the distributor who generated / authorized the extraction right from the user). You can call a method or load module that requests new or modified control information from the user (from, or from some other source) (blocks 2104, 2106). The EXTRACT method 2080 can then generate a new PERC that reflects these user-specified control information by calling the method or load module (block 2104). This new PERC is placed in a new (destination) object, the audit step is performed, and then the process ends.

FIG. 57b is an example of a process control step performed by a representative example of the EMBED method 2110 provided in a preferred embodiment. The EMBED method 2110 is similar to the EXTRACT method 2080 shown in Figure 57a. However, EMBED method 2110 performs a slightly different function. That is, this method writes an object (or reference) to the destination container. Blocks 2112 to 2122 shown in FIG. 57b are similar to blocks 2082 to 2092 shown in FIG. 57a. At block 2124, EMBED method 2110 writes the source object to the destination container. At the same time, the control information of the container of this destination may be extracted or changed. One option is to just leave the control information for the destination container as it is and include the entire set of control information associated with the embedded object in addition to the control information for the original container. There is. However, for optimization, a preferred embodiment provides a technique that allows the control information currently associated with the embedded object to be "summarized" and incorporated into the control information of the destination container. To do. Block 2124 can call a method that summarizes or modifies this control information. The EMBED method 2110 then, if approved, allows the user to embed objects and / or desties by performing steps 2126-2130 similar to steps 2096, 2104 and 2106 shown in Figure 57a. Allows you to change and / or specify the control information associated with the Nation's container. The EMBED method 2110 then writes the audit information to the audit UDE (blocks 2132, 2134) before exiting (termination point 2136). Ambiguity FIG. 58a is a flowchart showing an example of a processing control step performed by a representative example of the OBSCURE method 2140 provided by the preferred embodiment. The OBSCURE method 2140 is typically used to reveal safe content in a devalued form. For example, the OBSCURE method 2140 can emit a high resolution image in low resolution so that the viewer can identify the image but not enjoy its full value. As another example, the OBSCURE method 2140 obscures its value by placing a label that obscures it over the image (eg, "COPY", "PROOF", etc.). The OBSCURE method 2140 can "obscure" text, images, audio information or other types of content.

The OBSCURE method 2140 first calls the EVENT method to determine if its contents are suitable for ambiguous and within that range (block 2142). If this content is not suitable for ambiguity, the OBSCURE method exits ("no" exit of decision block 2144, end point 2146). Given that this content should be ambiguous (a "yes" exit to decision block 2144), the OBSCURE method 2140 determines if it has been previously called to obscure this content. (Judgment block 2148). Assuming that OBSCURE method 2140 has never been called for this object / content (a "yes" exit to decision block 2148), OBSCURE method 2140 reads the appropriate OBSCURE method MDE from the safety database. Load ambiguous expressions and / or patterns from the MDE (blocks 2150, 2152). The OBSCURE method 2140 then performs the appropriate ambiguous transformation based on the pattern and / or expression loaded by block 2150 (block 2154). The OBSCURE method can then be terminated (terminating block 2156). fingerprint FIG. 58b is a flowchart showing an example of a processing control step performed by a representative example of the FINGER PRINT method 2160 provided by the preferred embodiment. In a preferred embodiment, the FINGERPRINT method 2160 will "mark" the revealed content with a "fingerprint" identifier indicating who revealed the content, and / or check for such a mark. It works. This makes it possible to later determine who revealed the unsafe content by examining the content. The FINGERPRINT method 2160 can insert a user ID into a data stream that represents information in audio, video or binary format, for example. The FINGERPRINT method 2160 is shown in Figure 58a, except that the transformation performed by block 2174 of the FINGERPRINT method "fingerprints" the revealed content rather than obscuring it. Much like the OBSCURE method 2140.

Figure 58c identifies the object, and / or property, and / or user who requested the revealed content and / or the date and time of the revealed content, and / or other criteria for the revealed content. It shows an example of a "fingerprint" procedure 2160 that inserts a "fingerprint" 2161 into the revealed content.

Such fingerprints 2161 can be "buried". That is, it is typical, depending on the format of the file, the sophistication and / or versatility of the insertion algorithm, and the unmarked content of the original fingerprint (for comparison of the inverse engineering of the (one or more) algorithms). Inserted to hide fingerprints from typical users, advanced "hackers" and / or all users. The inserted or embedded fingerprint 2161 may, in the preferred embodiment, be at least partially encrypted for greater security. The fingerprint 2161 thus encrypted can be embedded in the revealed content given in the form of "plaintext".

Fingerprint 2161 can be used for a wide variety of purposes. Such objectives include often interrelated objectives, such as demonstrating the misuse of revealed material or demonstrating the source of the revealed content. Software privacy is a good example of how fingerprint engraving can be very useful. Fingerprints also provide content providers for most types of electronically delivered information, including movies, audio recordings, multimedia, information databases, and traditional "literary" material. It can help protect your rights. Fingerprint engraving is desirable as an alternative to or as a reinforcement of copyright protection.

Software application piracy often occurs when an individual gives a copy to a third party rather than making an illegal copy for use on another computer owned by that individual. Occurs in. This often starts a chain of illegal copies (or more accurately, a pyramid). This is because the copy is handed over from person to person. Most individuals (as many people still do) participate in widespread "casual" piracy, fearing that implanting the fingerprint 2161 will result in identification. It is easy to discourage. In some cases, the content may help protect the rights of the content provider by being checked for the presence of the fingerprint by the fingerprint engraving method.

Different fingerprints 2161 can provide different levels of security (eg, one fingerprint 2161 (1) is readable / identifiable by a commercial organization, while another fingerprint 2161 (2) is. , Only more reliable agencies can be readable). Methods for generating the more secure fingerprint 2161 can use more complex cryptographic techniques (eg, digital signatures) and / or ambiguity in location methodologies. Embedding two or more fingerprints 2161 in different locations and / or using different technologies helps protect the fingerprinted information from hackers. If the technology used to provide a safer fingerprint results in an undesired amount of overload, the safer fingerprint should be used cyclically rather than every time the content is revealed. May be done. That said, it can be more effective to use it every time. This is because the main purpose of fingerprinting is deterrence (ie, deterrence on the part of the creator of an illegal copy due to concerns that the copy may be discovered).

For example, an approved party (eg, a distributor, service person, client administrator, or information exchange with the VDE appliance 600) may embed a copy of the fingerprint 2161 for easy identification. unknown. It may also embed one or more additional copies or variants of a fingerprint 2161 (eg, a fingerprint with information that describes some or all of the relevant identifying information). In that case, these one or more additional fingerprints 2161 can be maintained in a more secure method.

Fingerprint engraving can also protect privacy-related matters. For example, the algorithms and / or mechanisms required to identify fingerprint 2161 can only be made available, especially through reliable agents.

Fingerprint engraving 2161 can take many forms. For example, in the case of an image, the color per N pixels (spread over the entire image or a subset of that image) is not visually recognizable (at least to a normal, no-means observer). As you can see, it can be slightly shifted. These shifts can be interpreted by analyzing the image (with or without access to the original image). Here, a color (or gradation) shift that occurs or does not occur each time corresponds to one or more binary "on or off" bits in digital information storage. Also, the N pixels may be arranged in a predetermined order (consistently), or quasi-randomly (although at least in part) by the object creator, object provider, client administrator, and so on. / Or may be lined up (as interpreted by the VDE administrator).

Also, some applications have similar benefits (ie, storing information in a form that is normally unrecognizable as a result of some modification of the source information) and other image (ie, video, audio, etc.) modifications. May be appropriate. For example, if the frequency of the stored audio information is subtly modulated in some way, this frequency is usually unrecognizable to the listener, but is still identifiable with the correct tools. be able to. Certain properties of information memory can be modified to change the polarity of some information optically stored so that similar results can be achieved, within subtle but interpretable limits. Other changes utilizing other electronic, magnetic, and / or optical properties can also be utilized.

The content stored in a file that uses a graphical format (eg, a Microsoft Windows® Word Processing File) provides a significant opportunity to "buried" the fingerprint 2161. Content, including images and / or audio, provides the opportunity to embed fingerprints 2161 that are difficult for unauthorized individuals to identify. Because, in the absence of a "non-fingerprinted" original used for comparison, the nature of the original is usually unknown and a large amount of data is used for both image and audio data (as such). In that case, it is not particularly sensitive to tiny changes), so even if you make subtle and tiny changes in one or more time cases of audio frequency, or in one or more video images, etc.) Such changes themselves are usually indistinguishable. Formatted text documents, especially those created using graphical word processors, such as Microsoft Windows® or Apple Macintosh® word processors, and their DOS and Unix® equivalents. In the case of, the fingerprint 2161 can be unobtrusively inserted into some of the document data representations (header fields or other invisible data fields) that are normally invisible to the end user.

Yet another form of fingerprint engraving (which may be particularly suitable for some text documents) utilizes and controls the shape of letters for a given font. Individual characters can have slightly different visual shapes that contain some sort of "fingerprint" information. Such variations in the shape of a given letter are usually indistinguishable. This is partly because there are many small changes in multiple versions of the same font available from different different suppliers, and partly because such changes are very small. Because it is a small one. For example, in a preferred embodiment, Adobe Type You can use a program like Align. The program, in its off-the-shelf version, supports the ability of users to modify font characters with a wide variety of methods. By modifying the mathematical definition of a font character at the command of the user, a specific modification set is applied to the character or font. The content of the information is too subtle for the user to recognize under normal circumstances, but still allows some or all characters to be modified in a way that allows the fingerprint 2161 to be properly encoded (of the user). It may be used analogically (as an option for selection). The use of a wide variety of subtly different versions of a given character in a single document makes it possible to improve the ability to have information fingerprinted by fonts in relation to transactions.

Other examples of applications for fingerprint engraving include:

1. Select several replaceable code fragments in a software program so that they behave more or less identically, but when analyzed, they make a difference that details the fingerprint information. ..

2. Using a database, make a choice to format some fields (for example, dates) so that they appear in different ways.

3. Adjust the background and reorder some events in the game. This includes recognizing or subtly changing the timing and / or order of appearance of the various elements of the game, or slightly changing the appearance of the various elements of the game.

The fingerprinting method 2160 is typically performed (if any) at the time the content is revealed from the content object 300. However, it may be done immediately after the object is distributed in order to "mark" the content in its encrypted form. For example, a network-based object repository can have a fingerprint 2161 embedded in the contents of an object before sending it to the requester. In that case, the fingerprint information makes it possible to identify the requester / end user of the content. This helps detect the "fake" electronic device 600 used to reveal the content without approval. Destruction FIG. 59 is a flowchart showing an example of a processing control step performed by a representative example performed by the DESTROY method 2180 provided by the preferred embodiment. DESTROY method 2180 deprives the user of the ability to use the object by destroying the URT that the user requests to access the object. In a preferred embodiment, the DESTROY method 2180 can first write audit information to the audit UDE (blocks 2182, 2184). The DESTROY method 2180 then calls the WRITE and / or ACESS methods to write information that degrades (and thus destroys) the header and / or other important parts of the object (block 2186). The DESTROY method 2180 can then mark one or more of the damaged control structures (eg, URT) by writing the appropriate information to the control structure (blocks 2188, 2190). Finally, DESTROY method 2180 can write additional audit information to the audit UDE before it exits (end point 2196) (blocks 2192, 2194). panic FIG. 60 is a flowchart showing an example of a processing control step performed by a representative example of the PANIC method 2200 provided by a preferred embodiment. PANIC method 2200 can be called when a security breach is detected. PANIC method 2200 can be, for example, one or more of the control structures (eg, URT) associated with the user and object when the channel currently used to access the object is destroyed and damaged. Marking allows users to prevent further access to the objects they are currently accessing (blocks 2206 and 2208-2210, respectively). Because the control structure is damaged, the VDE node contacts the administrator to get a valid control structure (one or more) before the user can access the same object again. Need to be taken. When a VDE node contacts an administrator, the administrator can request enough information to be reassured that no security breaches will occur. If a security breach occurs, take appropriate steps to ensure that such breach does not occur again. Measurement FIG. 61 is a flowchart showing an example of a processing control step performed by a typical example of the METER method provided by the preferred embodiment. The METER method has already been described with reference to FIGS. 49, 50 and 51, but the METER method 2220 shown in FIG. 61 is probably a somewhat more representative example. In a preferred embodiment, METER method 2220 first performs audit tracking in advance by accessing the METER audit tracking UDE (blocks 2222, 2224). The METER method 2220 can then read the DTD for the metering UDE from the safety database (blocks 2226, 2228). METER method 2220 can then read the weighing UDE from the safety database (blocks 2230, 2232). The METER method 2220 then tests the resulting metric UDE to determine if it has expired (determination block 2234). In a preferred embodiment, each metered UDE may be marked with an expiration date. If the current date / time is after the expiration date of the weighing UDE (yes exit to decision block 2234), METER method 2220 records the failure in the audit record, indicates a failure state, and exits. (Blocks 2236, 2238).

Assuming that the metric UDE has not yet expired, metric method 2220 can update it with an atomic element and, for example, the event count passed from the EVENT method to the METER method (block 2239, 2240). METER method 2220 can then store the weighing usage audit record in the weighing audit tracking UDE (blocks 2242, 2244) before exiting (at the end point 2246). Other safety features provided by the preferred embodiment The VDE 100 provided by the preferred embodiment is safe enough to help ensure that safety is not compromised except in the case of a successful "brute force attack". have. Thus, the time and cost required to succeed in such a "forced attack" exceeds virtually any value that can be derived. In addition, the security provided by VDE 100 separates the internal workings of VDE. Therefore, a successful "forced attack" will only invade a tightly bounded subset of the protected information, not the entire system.

The following is a list of some of the safety aspects and features provided by the preferred embodiments.

· PPE 650 safety and what it does Safety of safety database 610 -Security of encryption / decryption performed by PPE 650 · Key management, encryption / decryption keys and the security of shared secrets Authentication / security of external communication · Safety Database backup safety -Safe propagation capability of VDE internal information between 600 electronics · The security of permissions to access VDE safety information · Security of VDE object 300 · VDE safety integrity Some of these safety aspects and considerations have already been described. In the following, the safety features of the preferred embodiments, which are not covered elsewhere, will be discussed in more detail. Key management and shared secrets The VDE100 uses a key and a shared secret to ensure security. In a preferred embodiment, the following characteristics are realized for the use of the key.

· Different encryption systems / key types Secure key length Key generation -Key "swirl" and key "aging" Each of these types will be described below. A. Public key and symmetric key cryptosystem The process of hiding or transforming information to hide its essence is called encryption. Encryption produces a "ciphertext". The process opposite to the encryption process for restoring the essence from the ciphertext is called "decryption". Cryptographic algorithms are mathematical functions used for encryption and decryption.

The most modern cryptographic algorithms use "keys". This "key" specifies one of the provided conversion series (family). The key allows you to use a standard, public, and already tested cryptographic algorithm while ensuring that the concrete transformations performed using this algorithm remain confidential. Thus, the confidentiality of a particular transformation depends not on the confidentiality of the algorithm, but on the confidentiality of the key.

Key-based algorithms can be broadly divided into the following two forms. In the PPE 650 according to the preferred embodiment, one or both of these can be used.

Symmetric key, and Public key ("PK") A symmetric algorithm is an algorithm in which the encryption key can be calculated from the decryption key (and vice versa). In many such systems, the encryption and decryption keys are the same. Also known as the "secret-key" algorithm, the "single key" algorithm, or the "shared secret" algorithm, these algorithms are used before the ciphertext created by the sender is decrypted by the receiver. Require both the sender and the receiver to agree on the key. This key must be kept secret. The security of the symmetric algorithm lies in the key. Leaking this key to the outside means that in such an encryption system, anyone can encrypt and decrypt the information. See Schneier's Applied Cryptography, page 3. Examples of symmetric key algorithms that can be used in preferred embodiments include DES, Skipjack / Clipper, IDEA, RC2 and RC4.

In a public key cryptosystem, the key used for encryption is different from the key used for decryption. Moreover, deriving one key from the other is computationally infeasible. The algorithms used in these cryptosystems are called "public keys" because one of these two keys can be made public without compromising the security of the other key. Also, they are sometimes referred to as "asymmetric" cryptographic systems. This is because those systems use different keys for encryption and decryption. Public key algorithms include, for example, RSA, El Gamal and LUC.

The PPE 650 according to the preferred embodiment operates based solely on the symmetric key cryptosystem, based solely on the public key cryptosystem, or based on both the symmetric key cryptosystem and the public key cryptosystem. Can be done. The VDE 100 does not require any special encryption algorithm. The architecture provided by the preferred embodiment can support a number of algorithms, including PK and / or secret key (non-PK) algorithms. In some cases, the choice of encryption / decryption algorithm will depend on various business decisions such as cost, market demand, compatibility with other commercially available systems, and export laws.

The preferred embodiment is independent of a particular type of cryptosystem and independent of (one or more) encryption / decryption algorithms, but in a preferred example for secure communication between PPE 650s. A PK encryption system is used for, and a secret key encryption system is used for "huge" encryption / decryption between VDE objects 300. A large amount by using a secret key encryption system for a "huge" encryption / decryption system (eg, Skipjack, RC2 or RC4, which is a DES implementation with many keys and many paths). The efficiency of encrypting and decrypting information will be improved, and the PPE 650, which does not have PK capability, will be able to process the VDE object 300 in a wide variety of applications. By using a PK encryption system for communication, it is no longer necessary to rely on a secret shared external communication key to establish communication, and PPE It is possible to realize a challenge / response that does not depend on the shared internal secret to authenticate the 650, and it is possible to realize a certification process that can be used by the public without depending on the shared secret key. There are many benefits.

Some content providers want to limit the use of their content to PK implementations. Such a request is, for example, in the form of a load module that examines what is required for such an object in the REGISTER method for the specific or general PK capabilities of the PPE 650 before allowing continued registration. By providing in, the availability of PK capabilities in PPE 650 and the specific nature or type of PK capabilities can be supported by making it a factor in registering the VDE Object 300.

The VDE100 does not require any specific algorithm, but it is highly desirable that all PPE 650s can use the same algorithm for a large amount of encryption / decryption. If the vast amount of encryption / decryption algorithms used to encrypt the VDE object 300 is not standardized, it is possible that not all VDE electronics 600 can manipulate all VDE objects 300. If all or part of the vast amount of standardized encryption / decryption algorithms is not implemented by the hardware-based encryption / decryption engine 522, but instead in the form of software, then several different There will be a performance difference between the PPE 650 and the associated electronics 600. In order for the encryption / decryption engine 522 to support algorithms that do not implement all or part of them, a component assembly that implements such algorithms must be available for the PPE 650. B. Key length Increasing the length of the key can increase security. A "forced" attack on a cryptosystem involves trying all possible keys. The longer the key, the more possible keys you should try. At a key length, given the computational resources currently available, a forcible attacker would need a huge amount of time to try every possible key, which is not very practical.

The VDE 100 provided by the preferred embodiment can accommodate and utilize a large number of different lengths of keys. The key length used by the VDE 100 in a preferred embodiment is determined by the algorithm (one or more) used for encryption / decryption, the desired level of security, and throughput requirements. As the key length increases, it is generally necessary to further improve the processing power in order to guarantee a high-speed encryption / decryption response time. Therefore, there is a trade-off between (a) safety and (b) processing time and / or resources. Hardware-based PPE encryption / decryption engines 522 can achieve faster processing times than software-based encryption / decryption, so a hardware-based approach generally uses longer keys. Becomes possible.

In a preferred embodiment, a 1024-bit modulus (key) RSA encryption system may be used for PK encryption / decryption. You may also use 56-bit DES for "huge" encryption / decryption. The 56-bit key provided by standard DES may not be long enough to provide sufficient security, at least for the most sensitive VDE information, so many to achieve further security. Multiple DES encryption with multiple DES keys may be used. DES can be much more secure if it is operated to use multiple paths with different keys. For example, three paths with two or three separate keys are much more secure. This is because it can effectively increase the length of the key. RC2 and RC4 (an alternative to DES) can be exported up to a 40-bit key size, but just to achieve DES level security, the key size will probably need to be much longer. The 80-bit key length provided by the NSA's Skipjack may be appropriate for most VDE security requirements.

The ability to dynamically download code and other information to the PPE 650 allows the key length to be adjusted and dynamically changed even after a huge number of VDE electronics 600 have been used. If the VDE administrator has the ability to communicate efficiently with each PPE 650, such ex post facto dynamic changes can be made and cost effective. By downloading a new or improved cryptosystem to the existing PPE 650, it is possible to replace or add to the repertoire of cryptosystems available within the PPE, making older PPEs available. It will be possible to maintain compatibility with the information protected by the new PPE and / or the newly launched VDE Object 300 and other VDEs. For example, to reinforce the hardware-based functionality of the encryption / decryption engine 522 by providing different key length capabilities, the software encryption / decryption algorithm is always PPE. It can be downloaded to the 650. For greater flexibility, the PPE encryption / decryption engine 522 may be configured to anticipate a large number of paths and / or variable and / or longer key lengths. In addition, it is desirable to provide the PPE 650 with the ability to generate longer PK keys internally. C. Key generation The key generation technique provided by the preferred embodiment allows the PPE 650 to generate keys and other information that are "known" only to itself.

The security of encrypted information lies in the security of the key used to encrypt it. If cryptographically weak processing is used to generate the key, the overall security will be weakened. A good key is a random bitstring, such that every possible key in the key space is equally likely. Thus, the key should generally be derived from such a source, for example, by an cryptographically secure pseudo-random number generator seeded from a reliable random source. Such a key generator is described, for example, in Schneier's Applied Cryptography (John Wiley and Sons, 1994), p. 15. If the keys were generated outside a given PPE 650 (eg by another PPE 650), then those keys were validated to make sure they were obtained from a reliable source before they were used. It must be. To verify the key, "proof" may be used.

The PPE 650 according to the preferred embodiment also provides automatic key generation. For example, the PPE 650 according to the preferred embodiment can generate its own public / private key pair that is used to protect PK-based external communications and is also used for other reasons. The PPE 650 can also generate its own symmetric key for a variety of purposes during and after initialization. Since the PPE 650 provides a secure key environment, in the preferred embodiment most key generation can occur within the PPE (although to allow the PPE to authenticate the initial download message to itself. The initial PPE key used during manufacturing or installation is a possible exception).

Good key generation depends on randomness. The PPE 650 according to a preferred embodiment may include a hardware-based random number generator 542 with the properties required to generate reliable random numbers, as described above with reference to FIG. These random numbers "seed" a cryptographically strong pseudo-random number generator (eg, DES calculated in output feedback mode) to generate additional key values derived from a random seed. Can be used for. In a preferred embodiment, the random number generator 542 may consist of a "noise diode" or other physical-based random number source (eg, radioactive decay).

If, in PPE 650, there is no random number generator 542 available, SPE 503 will generate a cryptographic algorithm (eg, output) to generate a pseudo-random number sequence derived from a secret value protected inside the SPE. DES) in feedback mode can be used. Although these numbers are pseudo-random numbers rather than true random numbers, they are cryptographically derived from unknown values outside the SPE 503, which can be quite satisfactory for some applications.

In an embodiment that incorporates the HPE 655 without the SPE 503, the software of the random number generator 565 is from an unpredictable external physical event (disk I / O completion, or high resolution timing of the user keystrokes of the attached keyboard 612). A highly reliable random number can be derived.

Conventional techniques may be used to generate PK and non-PK keys based on such "seed". Thus, if performance and manufacturing costs allow, the PPE 650 will, in a preferred embodiment, generate its own public / private key pair based on such a random or pseudo-random "seed" value. This key pair can then be used for external communication between the PPE 650 that generated the key pair and any other PPE that wants to communicate with it. For example, the generating PPE 650 could leak the public key of this key pair to another PPE. This allows other PPE 650s that use the public key to encrypt messages that can only be decrypted by the generating PPE (the generating PPE "knows" the corresponding "private key". The only PPE). Similarly, the generating PPE 650 can also use its private key to encrypt messages. This private key allows the other PPE to authenticate that the generating PPE sent a message if the other PPE successfully decrypted it using the generating PPE's public key.

Before one PPE 650 uses a public key generated by another PPE, public key cryptography should be used to issue a certificate of authentication for that public key. A public key certificate is someone's public key that is "signed" by a trusted entity, such as an authenticated PPE 650 or VDE administrator. The certificate says it is communicating with a certified PPE, even though it is not (for example, it is actually communicating with someone who is trying to break the security of the PPE 650). Used to thwart attempts to blame the PPE 650. In a preferred embodiment, one or more VDE administrators may constitute a certification authority. By "signing" both the public key generated by the PPE 650 and information about the PPE and / or the corresponding VDE appliance 600 (eg, site ID, user ID, expiration date, name, address, etc.) The VDE Administrator Certification Authority can prove that the information about the PPE and / or VDE electronics is correct and that its public key belongs to a particular VDE mode.

Certificates play an important role in the reliability of digital signatures. It is also important in the public key authentication communication protocol (described later). In a preferred embodiment, these certificates provide information about the reliability / safety level of a particular VDE appliance 600 (eg, whether it has a hardware-based SPE 503, or an unreliable software emulation type. Do you have an HPE 655 instead?) May be included. This information can be used to avoid sending very secure information to unreliable / unsafe VDE installations.

Certificates are decommissioning rogue) Can also play an important role in users and / or sites. By including the site and / or user ID in the certificate, the PPE can evaluate this information as an aspect of authentication. For example, if a VDE administrator or information exchange meets certain criteria (eg, untrusted and / or otherwise suspicious users and / or listed on the site), an ID (or) If you come across a certificate with (other information), you can choose one of several actions based on these criteria, such as denying communication, communicating disabled information, or notifying the user of the status. .. Certificates also typically ensure, for example, that the site and / or user must be in constant contact with the VDE administrator, and / or allow the certification key to be changed on a regular basis. , The certificate contains an expiration date to confirm that it must be rewritten on a regular basis. Sites and / or more certificates based on different keys so that one or more "backup" certificates can be used even if a given certificate key is compromised. It can be issued to the user. If a certification key is compromised, the VDE administrator refuses to authenticate based on the certificate issued with such a key and is compromised in subsequent interactions with VDE subscribers. A signal can be sent after authenticating with a "backup" certificate that invalidates all uses of the key and any certificates associated with that key. One or more new "backup" certificates and keys may be created and sent to authenticated sites / users after such a breach.

If a large number of certificates are available, some of those certificates can be backed up. Alternatively, or in addition, by selecting a certificate from a group of certificates with a given certificate (eg, using RNG 542), the certificate associated with the compromised certificate key is used. It is possible to reduce the possibility of being struck. In addition, more than one certificate may be used for a given certificate.

Different based on different mathematical foundations in order to take defensive measures against the possibility that the proof algorithm will be violated (eg, due to unpredictable advances in the mathematical foundations underlying this algorithm). Different algorithms may be used for multiple certificates.

Another technique that can be used to reduce the likelihood of being compromised is to keep the "public" value on which those certificates are based (in PPE 650's protected storage) secret. There is a way to deny an attacker access to a value that would help the attack. Although these values are nominally "public," they need to be known only to those members (ie, PPE 650) who actually check the validity of the certificate.

In a preferred embodiment, the PPE 650 may issue its own certificate, or the certificate may be obtained externally (eg, from a certification authority, such as a VDE administrator). Good. Regardless of where this digital certificate was issued, the certificate will eventually allow other VDE electronics 600 to access (and trust) this public key. Registered by the VDE Administrator Certification Authority. For example, the PPE 650 can communicate its public key and other information to a certification authority. In response, the certification authority uses the certification authority's private key to encrypt its public key and other information. Other installations 600 can trust this "certificate". This is because this certificate is authenticated using the public key of the certification authority for its decryption. As another example, the certification authority can use this public key to encrypt the public key received from the generating PPE 650 and to encrypt the certification authority's private key. The certification authority can then send this encrypted information back to the generating PPE 650. PPE for generation The 650 can then use the certificate authority's private key to internally create the digital certificate. The generator PPE 650 can then destroy a copy of the certification authority's private key. The outbreak PPE 650 then sends out a digital certificate, if desired, for storage in a certificate storage location at the VDE administrator (or anywhere else). This certification process can also be performed using an external key pair generator and certificate issuer, but depending on the nature of the security equipment, it may be somewhat less secure. In such cases, the PPE 650 should use a manufacturing key to limit the degree of exposure to other associated keys.

The PPE 650 may require more than one certificate. For example, a certificate may be needed to have other users verify that the PPE is authenticated and to identify the PPE. In addition, some certificates may be required for individual users of the PPE 650. These certificates can incorporate both user and site information, or can include only user information. In general, a certification authority requires a given user to present a valid site certificate before creating a certificate. Each user needs his or her own public / private key pair to obtain a certificate. VDE administrators, information exchanges, and other subscribers can require authentication for both sites (PPE 650) and users that are typically communicating or otherwise interacting. The above process for key generation and certification to PPE 650 may be used to create a site / user certificate or user certificate.

The certificates mentioned above may be used to prove the origin of the load module 1100 and / or the authenticity of the management operation. The security and assurance techniques described above can be used to reduce the likelihood of any such certificate (including certificates other than the identity certificate of the VDE Electronics 600) being compromised. D. Key aging and swirling The PPE 650 also has the ability to generate a secret key and other information shared among a large number of PPE 650s in a preferred embodiment. In a preferred embodiment, such secret keys and other information are among a large number of VDE electronics 600 without any need for the shared confidential information to be explicitly communicated between the electronics. Can be shared. More specifically, the PPE 650 responds to seed information shared among a large number of VDE electronics 600 and derives the key based on deterministic processing, the so-called "key swirl". Convolution) technology is used. Many electronics 600 "know" what their "seed" information is, and also "know" the deterministic process used to generate a key based on this information. Each electronic device can independently generate a "true key". This allows a large number of VDE electronics 600s to share the same common secret key without the security being compromised by communicating the common secret key over an insecure channel. ..

Cryptographic keys should not be used for an unspecified period of time. The longer a key is used, the more likely it is to be compromised, and if the key has been compromised and is still being used to protect new information, it is. It is also more likely to be lost. Also, the longer a key is used, the more information it protects, so if anyone makes the necessary effort to destroy it, it can be gained. Sexual rewards are also higher. Moreover, the longer a key is used, the greater the amount of ciphertext available to an attacker attempting to destroy the key using a ciphertext-based attack. See Schneier, pp. 150-151. Key swirling, in a preferred embodiment, efficiently modifies the keys stored in the security database 610, based on periodic routines or other criteria, while simplifying peripheral key management issues associated with key changes. Provides a method to do. In addition, key swirling can also be used to achieve a "time-aged key" (discussed below) for setting an "expiration date" for key use and / or validity.

FIG. 62 shows an example of a realization of key turning in a preferred embodiment. The key swirl uses a combination of site ID 2821 and the high-order bits of RTC 528 to produce the time-dependent site-specific value "V" on a large scale (eg, hour or day). It can be done. This value "V" can be used as a key for the encryption process 2871 that converts the swivel seed value 2861 into the "current swivel key" 2862. The seed value 2861 can be a universal range or a secret value shared within a range of groups. This value can also be stored in secure key storage (eg, protected memory in PPE 650). The seed value 2861 is installed during the manufacturing process and can be updated at any time by the VDE administrator. There may be multiple seed values 2861 corresponding to different sets of objects 300.

The current swivel key 2862 represents the coding of site ID 2821 and the current time. This converted value 2862 is for another cryptographic process 2872 that converts the key 810 stored in the object's PERC 808 into a true private body key 2863 that matches the contents of the object. Can be used as a key.

The "turning function" performed by blocks 2861 and 2871 can be, for example, a one-way function that can be performed independently at both the content creator's site and the content user's site. If the content user does not use the exact same swivel function and the exact same input values (eg, time and / or site and / or other information) used by the content creator, it is done by the content user. The result of the swirl function may differ from the result of the content creator. If the result is used by the content creator as a symmetric key for encryption, the content user will not be able to decrypt unless the content user's result is the same as the content creator's result.

The time component of the input to the key swivel function can be derived from the RTC 528 (note that slight differences in RTC synchronization between VDE appliances will not cause different electronics to use different time components. Please be careful to ensure that). Different parts of the RTC 528 output can be used to give multiple keys different durations. Alternatively, some tolerance may be introduced during the process to try out several different key values. For example, the "granularity" parameter can be adjusted so that the time tolerance is set in days, weeks, or other time periods. As an example, if "time subdivision" is set to 2 days and the margin of error is ± 2 days, then three real-time input values can be tried as inputs to the swivel algorithm. Each of the resulting key values can be tested to determine which of the possible keys is actually in use. In this example, these keys would have a lifespan of only 4 days.

Figure 63 shows how a properly swirled key is picked up to compensate for the skew between the user's RTC 528 and the author's RTC 528. The sequence of the swivel key 2862 (a-e) can be generated by using a plurality of different input values 2881 (a-e). These input values are derived as the values of site ID 2821 and RTC 528 ± differential values (eg -2 days, -1 day, no Δ, +1 day, +2 days). The swivel step 2871 (a-e) is used to generate the sequence of keys 2862 (a-e).

The author's site, on the other hand, uses a swivel step 2871 (z) based on its RTC 528 value (adjusted to correspond to the intended validity time of the key). A swirled key 2862 (z) can be generated. This key can then be used to generate the content key 2863 on the object PERC 808. To decrypt the contents of an object, the user site attempts to generate the parent content key 810 by using each of its sequences of swivel keys 2862 (a-e). When this is attempted, one of the keys 2862 (a ~ e) matches and decrypts the key 2862 (z) as long as the author's site RTC 538 is within an acceptable margin of error compared to the user's site RTC 528. It will succeed in conversion. In this example, the match is determined by the validity of the decrypted output, not by a direct comparison of the keys.

The key swirl described above does not necessarily have to use both the site ID and the time as one value. Some keys may be generated based on the current real time. Other keys may be generated based on the site ID. Yet other keys may be generated based on both the current real-time and site ID.

Key swirl may be used to provide a "time-aged" key. These "time-aged" keys provide an automatic mechanism that allows the keys to expire and be replaced with "new" keys. These keys are for all or part of an object without requiring the user to re-register and leaving great control in the hands of the content provider or administrator. limited rights of time to allow the use of a limited period of time to provide a method for providing the benefits. If the security database 610 is secure enough, similar capabilities can also be achieved by checking the expiration date / time associated with the key. However, this requires the use of a larger storage space for each key or each group of keys.

In a preferred embodiment, the PERC 808 can include an expiration date and / or an expiration time. After this expiration date / time, access to their corresponding VDE-protected information is no longer authorized. Alternatively, or in addition to this, after a duration associated with some aspect of the use of the electronics 600 or one or more VDE objects 300, the PERC 808 regains the right to use the (one or more) objects. Alternatively, the user can be forced to send audit history information to an information exchange, distributor, client administrator or object creator to retain it. The PERC 808 can impose such time-based constraints by checking / forcing parameters that limit the past availability of key usage and / or approved use. A "time-aged" key can be used to enforce or enhance this type of time-related access control on VDE-protected information.

A "time-aged" key can be used to encrypt / decrypt a set of information during a limited period of time. Therefore, it is necessary to re-register, receive new permissions, or pass audit information. Otherwise, a new key will not be provided and made available to the user. Time-aged keys can also be used to improve the security of the system. This is because one or more keys are automatically replaced based on time aging criteria. Therefore, cracking the safety database 610 and locating one or more keys can result in no real value. Yet another advantage of using time-aged keys is that they can be dynamically generated. This eliminates the need to store the decryption key in secondary and / or secure memory.

The "time-aged" key, in the preferred embodiment, is not the "true key" that can be used for encryption / decryption, but the PPE 650 refers to other information to generate the "true key". A piece of information that can be used to do this. The other information may be time-based, based on the specific "ID" of the PPE 650, or both. Because the "true key" is never exposed and always occurs in a secure PPE 650 environment, and a secure PPE is required to generate a "true key". The VDE 100 can use "time-aged" keys to significantly enhance the security and flexibility of the system.

The process of "aging" a key is, in a preferred embodiment, a time-aged "true key" and (b) a function of some other information (eg, real-time parameters, site ID parameters, etc.). It inevitably involves generating a "true key". This information is combined / transformed (eg, using the "key swirl" technique described above) to restore or provide the "true key". Since the "true key" can be restored, this avoids storing the "true key" in the PERC 808, and multiple different "true keys" are the same in the PERC 808. It can be made to correspond to information. Since the "true key" is not stored in the PERC 808, accessing the PERC does not allow access to the information protected by the "true key". Thus, a "time-aged" key allows content creators / providers to impose restrictions (eg, site-based and / or time-based) on access to information. Access to information is, in a sense, one or more PERCs It is or supplements the permissions provided by the 808. For example, a "time-aged" key can impose an additional time limit on access to certain protected information. This additional time limit is independent of any information or permissions contained within PERC 808, but instead is based on one or more time and / or site ID values.

As an example, time-aged encryption keys allow anyone who purchases an electronically published newspaper in the form of a "provisional subscription" to access each edition of the newspaper for a week. Can be used for. After a week, the encryption key no longer works. In this example, users can purchase one or more new PERC 808s or update one or more existing permission records to access non-versions obtained during the week. I need to receive it. Access to these other editions can also be manipulated using a completely different pricing structure (eg, a "regular" subscription rate as opposed to a free or minimal "provisional" subscription rate).

In a preferred embodiment, a time aging-based "true key" can be generated using a unidirectional or reversible "key swirl" function. The input parameters to the swirl function are the supplied time-aged key, the user and / or site-specific value, and a specified portion of the time value from RTC 528 (eg, a certain number of high-order bits) or a given method. Can include a value derived from such a time value and a block or record identifier that can be used to ensure that the time-aged key is unique. The output of the "key swirl" function can be a "true key" used for decryption purposes until it is destroyed. Running this function with a time-aged key and an inappropriate time value typically only results in a useless key that cannot be decrypted.

The generation of new time-aged keys can be triggered based on some value in absolute or relative time elapsed (eg, based on real-time values from a clock such as RTC 528). The swivel then produces the wrong key. Also, decryption is not performed until the time-aged key is updated. The criteria used to determine when a new "time-aged key" should be created are themselves based on time or other input variables to achieve yet another level of security. May be changed. Thus, the swivel function and / or the event that implements it can be modified, shifted, or used with variable quantities as parameters.

The following are examples of the use of time-aged keys.

1) The creator creates a "true key" and uses it to encrypt the content.

2) As an input parameter to "reverse turn" by the creator a) "True" key, b) Time parameters (eg, valid high-order time bits for RTC 528) and c) Other optional information (eg site ID and / or user ID) To generate a "time-aged key", perform a "reverse turn".

3) The author distributes the "time-aged" key to the content user (if the author does not use the swivel algorithm already available for the content user's PPE 650, then the swivel algorithm and / or parameters Also need to be distributed).

4) Content User's PPE 650, a) "Time aged" key, b) Higher time bits, and c) Other requested information (same as 2c) To combine.

Content The user's PPE 650 performs a swivel function (ie, the reverse of the "reverse swivel" algorithm in step (2) above) to obtain the "true" key. If the time and / or other information provided is "wrong", the swivel function does not generate a "true" key and the contents cannot be decrypted.

Any key block associated with VDE Object 300 or any other item may be specified by the object creator during the object configuration process, or, where appropriate, by the distributor or client administrator. As specified, it can be either a regular key block or a time-aged key block.

The "time-aged" key can also be used as part of a protocol for achieving secure communication between PPE 650s. For example, instead of providing a "true" key to the PPE 650 for communication, the VDE 100 can also supply only a "partial" communication key to the PPE. These "partial" keys can be supplied to the PPE 650, for example during initialization. A given algorithm can generate a "true key" used to encrypt / decrypt information for secure communication. This given algorithm can "age" these keys in the same way on all PPE 650s. Alternatively, the PPE 650 may be required to contact the VDE administrator at a given time so that a new set of partial communication keys can be downloaded to the PPE. If the PPE 650 does not generate or otherwise obtain a "new" partial key, the PPE 650 is disabled for communication with other PPEs (PPE is a VDE administrator for reinitialization purposes). Another "fail safe" to ensure communication with safe) "keys may be provided). By keeping two sets of partial keys within the PPE 650, a fixed amount of overlap time can be achieved across all VDE instruments 600. The older of these two sets of partial keys can be updated periodically.

In a preferred embodiment, the following additional types of keys (discussed below) can also be "aged".

Individual message keys (ie, the key used for a particular message), Static and mobile object shared keys for management, Secure database key, and Secret body key and secret content key Initial installation key management Figure 64 shows the flow of the universal range, or "parent" key, during the generation of the PPE 650. In a preferred embodiment, the PPE 650 is maintained by a secure non-volatile key storage device 2802 (eg, SPU 500 non-volatile RAM 534B or HPE 655) initialized with a key generated by the manufacturer and the PPE itself. Includes a protected storage device).

The manufacturer has (ie, knows) one or more public key 2811 / private key 2812 key pairs that are used to sign the site identification certificate 2821 and to verify its validity. And protect it from disclosure or modification). For each site, the manufacturer generates a site ID 2821 and a site characteristic list 2822. In addition, the manufacturer also has public keys 2813, 2814 to check the validity of the load module and initialization code download. For added security, there may be multiple such certification keys, or each PPE 650 may be initialized with only one subset of such keys of each type. ..

As part of the initialization process, the PPE 650 may internally generate one or more pairs of site-specific public and private keys 2815, or the manufacturer may generate and supply them. Good. These are used by the PPE 650 to prove their identity. Similarly, a site-specific database key 2817 (one or more) for that site is generated. If necessary (ie, if random number generator 542 is not available), a random number initialization seed 2818 is generated.

Initialization may begin by generating a site ID 2821 and characteristic 2822 and a site public key 2815 / private key 2816 pair (one or more). These values can be combined and used to generate one or more site identity certificates 2823. The site identity certificate 2823 can be generated by the public key generation process 2804 and can be stored in both the PPE protected key storage 2802 and the manufacturer's VDE site certificate database 2803.

Certification process 2804 can be done either by the manufacturer or inside the PPE 650. If done by PPE 650, PPE temporarily receives the identity proof private key 2812, issues certificate 2823, stores the certificate in local key storage 2802, and then transmits it to the manufacturer. To do. The PPE 650 must then erase a copy of the proof-of-identity private key 2812.

Subsequently, initialization may require the PPE 650 or the manufacturer to generate (one or more) site-specific database keys 2817 and (one or more) site-specific seed values 2818. These are stored in the key storage device 2802. In addition, (one or more) download certification keys 2814 and load module certification keys 2813 may be supplied by the manufacturer and stored in key storage 2802. These can be used by the PPE 650 to check the effectiveness of all further communications with external entities.

At this point, the PPE 650 is further initialized with executable code and data by downloading the information proved by the load module key 2813 (one or more) and the download key 2814 (one or more). Can be transformed. In a preferred embodiment, these keys are used to digitally sign the data loaded into the PPE 650, which guarantees its validity. Also, additional keys (one or more) encrypted with the site-specific public key 2815 (one or more) are used to encrypt such data and protect it from disclosure. Can be done. Installation and update key management Figure 65 shows an example of further key installation by either the manufacturer or a subsequent update by the VDE administrator. The manufacturer or administrator may use the default or new value for (one or more) private header key 2831, (one or more) external communication key 2832, management object key 2833, or other (one or more) shared key 2834. A value can be supplied. These keys can be universal range in the same sense as the global certification keys 2811, 2813 and 2814. Alternatively, these keys may be limited to use within a defined group of VDE cases.

To perform this installation, the installer extracts the destination site's (one or more) identity certificate 2823 and extracts the (one or more) site's public key 2815 from it. These (one or more) keys can be used in the encryption process 2841 to protect the installed keys. These (one or more) keys installed are then transmitted inside the PPE 650 at the destination site. Inside the PPE 650, the decryption process 2842 can use the site's private key 2816 (one or more) to decrypt the transmission. The PPE 650 then stores the installed or updated key in key storage 2802. Use of object-specific keys Figures 66 and 67 show the use of keys to protect the data and control information associated with the VDE object 300.

FIG. 66 shows the static content object 850. The control information is derived from the management object 870. These objects can be received by the PPE 650 (eg, retrieved from the object storage location 728 over the network or retrieved from local storage). The managed object decryption process 2843 can retrieve the PERC 808 that controls access to the content object 850 by decrypting the managed object 870 with the secret header key 2815 (one or more). The secret body key 810 (one or more) is then extracted from the PERC 808 and used by the content decryption process 2845 so that its contents can be used outside the PPE 650. In addition, database key 2817 (one or more) is used by encryption process 2844 in preparation for storing PERC in a secure database 610 external to PPE 650. When later accessing the content object 850, PERC The 808 is retrieved from safety database 610, decrypted with database key 2817 (one or more), and then used directly rather than extracted from managed object 870.

FIG. 67 shows a similar process involving the moving object 860. The main difference between Figure 66 and Figure 67 is that PERC 808 is stored directly inside the moving object 860, thus providing (one or more) secret header keys 2831. It can be used immediately after the decoding process 2843. This secret header key 2831 is used to process the contents in the moving object 860. Change of secret key Although FIGS. 64 to 67 show preferred public key embodiments, they can also be used to help understand the secret key version. In the secret key embodiment, private key cryptography is performed instead of proof processing and public key encryption / decryption, and PPE 650 cases and other parties (eg, instead of public key / private key pairs). , Individual secret keys shared with (one or more) load module suppliers, PPE manufacturers, etc.) are used. In addition, the certification process 2804 is not performed in the secret key embodiment, and neither the site identity certificate 2823 nor the VDE certificate database 2803 exists. Key type A detailed description of the key types described below further describes embodiments of secret keys. However, this gist is not intended to be a complete description. The PPE 650 according to a preferred embodiment can use different types of keys and / or different "shared secrets" for different purposes. Some key types apply to public / secret key implementations, others apply only to secret key implementations, and other key types apply to both of them. The table below lists examples of various keys and "shared secret" information used in preferred embodiments. This information also lists where it is used and stored.

<tables num="26"><img file="JP4995980B2_D0026.tif" /></tables>

Parent key A "parent" key is a key used to encrypt other keys. The initial key, or "parent" key, can be provided within the PPE 650 to communicate with other keys in a secure way. During the initialization of the PPE 650, the code and shared key are downloaded to the PPE. This code corresponds to the "master key" because it contains a safe turn algorithm and / or coefficients. The shared key can also be considered a "parent key".

If public key cryptography is used as the basis for external communication with the PPE 650, a parent key is required during the PPE public key pair proof process. This parent key can be, for example, a private key used by the manufacturer or VDE administrator to establish a digital certificate (encrypted public key and other information on the PPE). The parent key may also be, in another example, the private key used by the VDE administrator to encrypt the entry in the certificate storage location. Once certified, external communication between the PPEs 650 can be established using a certificate of communication with the PPE.

If the shared secret key is used as the basis for external communication, the initial secret key is required to establish external communication for PPE 650 initialization. This initial secret key is a "parent key" in the sense that it is used to encrypt other keys. During the PPE initialization process, a set of shared partial external communication keys (described above) may be downloaded. Also, these keys are used to establish subsequent external PPE communication. Manufacturing key The manufacturing key is used during manufacturing of the PPE to prevent manufacturing staff from knowing the PPE-specific key information that is downloaded to the PPE during initialization. For example, a PPE 650 operating as part of a manufacturing facility can generate information to download to an initialized PPE. This information is for PPE During communication between 650, it must be encrypted to maintain its confidentiality. Otherwise, the manufacturing staff will be able to read this information. The production key is used to protect this information. The production key can also be a variety of other keys that are downloaded to the PPE, such as a certified private key, a PPE public / private key pair, and / or other keys such as a PPE-specific shared secret key. Can be used to protect. The production key is also the "parent key" because it is used to encrypt other keys.

The production key may be based on a public key or a shared secret. Once the information is downloaded, the currently initialized PPE 650 can destroy (or simply not use) this production key. The production key can be connected to the PPE 650 at the time of production or sent to the PPE as its first key and may be destroyed after it is no longer needed. As shown in the table above and in the discussion in the previous section, if the PK capability is provided on the PPE, no production key is required. Certificate key pair The certification key pair can be used as part of the "certification" process for the PPE 650 and VDE electronics 600. This certification process, in a preferred embodiment, can be used to allow a VDE appliance to present one or more "certificates" that certify that it (ie, its key) can be trusted. .. As mentioned above, this "certification" process is a VDE that has been certified by a single PPE 650. Used to "prove" that it is a PPE, that it has a certain level of safety and capability set (eg, that it is hardware-based, not just software-based). sell. Simply put, the "certification" process may involve the use of a certificate private key from a certificate key pair to encrypt a message that contains the public key of another VDE node. The private key of the certification key pair is preferably used to issue a PPE certificate. This key is used to encrypt the PPE public key. The PPE certificate may be stored in the PPE or in the certificate storage location.

Depending on the authentication technology chosen, the public and private keys of the certificate key pair may also need to be protected. In a preferred embodiment, one or more public public keys are distributed between the PPEs so that they can be used to decrypt the certificate as an aspect of authentication. In a preferred embodiment, the public key is used inside the PPE 650, so the public key does not need to be available in clear text. In any case, it is important that such keys are maintained and transmitted in integrity (eg, during initialization and / or update by the VDE administrator). If the confidentiality of the public key is maintained (ie, it is only available in clear text inside the PPE 650), it will be much more difficult to crack it. The private key of a certification key pair should be kept confidential and should only be stored (ie, not distributed) by the certification authority.

In a preferred embodiment, different certificate key pairs may be used to enable the ability to differentiate multiple installations with different levels / degrees of reliability / security from each other (eg, different). Multiple certification keys may be used to prove SPE 503 and then to prove HPE 655). PPE public / private key pair In a preferred embodiment, each PPE 650 may have its own unique "device" (and / or user) public / private key pair. Preferably, the private key of this key pair is generated within the PPE and is never exposed to the outside of the PPE in any form. Thus, in certain embodiments, the PPE 650 may be provided with an internal capability to internally generate a key pair. If the PPE internally generates a key pair for its own public key cryptosystem, the manufacturing keys mentioned above may not be needed. However, if desired for cost reasons, the key pair may be exposed only during the manufacture of the PPE 650 and may then be protected with the craft key. PPE If the 650 allows the public key pair to be generated internally, it will be possible to hide this key pair. However, for some applications, the cost of deploying a public key key pair generator within the PPE 650 may be more important. Initial secret key The initial secret key can be used as the parent key only by the secret key, based on the PPE 650, to protect the information downloaded to the PPE during initialization. This key is generated by the PPE 650 and sent from the PPE to a secure manufacturing database encrypted with the manufacturing key. In response, the secure database sends back a unique PPE manufacturing ID encrypted with the initial secret key.

This initial secret key is likely to be much longer than the key used for "standard" encryption due to the special role it plays in PPE initialization. As a result, decryption overhead occurs only during this initialization process, so multiple paths through the decryption hardware with the selected portion of this key are acceptable. PPE Manufacturing ID The PPE manufacturing ID falls within the category definition of "shared secret" rather than "key". This ID can preferably be used by the safety database 610 to uniquely identify the PPE 650 and determine the initial secret key of the PPE during the PPE initialization process. Site ID, shared code, shared key and shared secret The VDE site ID, along with the shared code, key and secret, is preferably downloaded to the PPE 650 during the PPE initialization process or generated internally by the PPE as part of that process. In a preferred embodiment, most or all of this information is downloaded.

The PPE site ID uniquely identifies the PPE 650. This site ID is preferably unique so that it can uniquely identify the PPE 650 and distinguish it from all other PPEs. This site ID provides a unique address that, in a preferred embodiment, can be used for a variety of purposes (eg, providing an "address privacy" feature). In some cases, this site ID can be the public key for PPE 650. In other cases, the PPE site ID can be assigned during manufacturing and / or initialization processing. For PPE 650s that do not have public key capabilities, it may not be desirable to use the device's secret key as a unique site ID. Because this exposes too many bits of the key. Therefore, a different sequence of information should be used as the site ID.

The shared code contains these code fragments that provide at least part of the control program to the PPE 650. In a preferred embodiment, during PPE production, a basic code fragment is installed that allows the PPE to bootstrap and initiate the initialization process. This fragment can be replaced with updated control logic during the initialization process or during the subsequent download process.

The shared key can be downloaded to the PPE 650 during the initialization process. These keys can be used, for example, to decrypt the secret headers of many object structures.

When the PPE 650 is operating in secret key only mode, the initialization and download process can import the shared secret into the PPE 650. These shared secrets can be used to allow the PPE 650 to authenticate the identity of other PPEs and / or users during communication processing. Download authorization key The download authorization key is received by the PPE 650 during the initialization download process. This key is also used to approve PPE 650 code updates, key updates, and by protecting the backup of PPE's secure database 610, even if the PPE fails (for example) by the VDE administrator. It can also be used to make it recoverable. This key can also be used with the site ID, time and swivel algorithms to derive a site ID specific key. The download authorization key can also be used to encrypt the key block used to encrypt the backup of secure database 610. In addition, PPE It can also be used to create site-specific keys that will be used to enable future downloads to the 650. This download authorization key is not shared among all PPE 650s in the preferred embodiment. That is, this key is unique to the functionality performed by an approved VDE administrator. External communication keys and related secret and public information There are some cases where a key is needed when the PPE 650 communicates. The process of establishing secure communication may also require the use of relevant public and confidential information regarding communication with the electronic device 600. External communication keys and other information are used to support and authenticate secure communications. These keys, in a preferred embodiment, include a pair of public keys. However, a shared secret key may be used in place of or in addition to it. Management object key In a preferred embodiment, the managed object shared key can be used to decrypt the secret header of managed object 870. For managed objects, permission record 808 may be present in the secret header. In some cases, permission record 808 may be distributed as (or within) a managed object that provides the right to process the contents of other managed objects. The permission record 808 preferably contains a key for the secret body. Also, the key for accessible content can be the budget referenced in permission record 808. The managed object shared key can be introduced as a component of time and can be replaced if it expires. Static object key The quiesced object shared key can be used to decrypt the quiesced object 850's secret header. As mentioned earlier, in some cases permission record 808 may be present in the quiesced object's secret header. If present, this permission record 808 may contain a key for the secret body, but not for its contents. These shared keys can be introduced with time as a component and can be replaced if they expire. Move object shared key The mobile object shared key can be used to decrypt the private header of the mobile object 860. In a preferred embodiment, the move object may also include permission record 808 in its secret header. This permission record 808 preferably contains a key for the secret body and a key for the content that can be accessed when permission is granted by the permission record 808. These shared keys can be introduced with time as a component and can be replaced if they expire. Safe database key PPE The 650 preferably generates these secure database keys and never exposes them to the outside of the PPE. These keys are site-specific in preferred embodiments and can be "aged" as described above. As mentioned above, each time an updated record is written to the secure database 610, a new key can be used and kept in the key list in the PPE. Periodically (when there is no more room in the internal list), the PPE 650 can generate new keys that encrypt new or old records. Depending on the size of the security database 610, a group of keys can be used instead of a single key. Secret body key The secret body key is unique to object 300 and does not depend on the key information shared between PPE 650s. These keys are preferably generated by the PPE 650 when the secret text is encrypted and can incorporate real-time as a component that "ages" them. These keys are received in permission record 808 and their usage can be controlled by the budget. Content key The content key is unique to object 300 and does not depend on the key information shared between PPE 650s. These keys are preferably generated by the PPE 650 when the contents are encrypted, and time can be incorporated as a component that "ages" them. These keys are received in permission record 808 and their usage can be controlled by the budget. Approval shared secret Access to and use of information within the PPE 650 or safety database 610 can be controlled using authorization "shared secrets" rather than keys. Approval shared secrets can be stored within the records they approve (permission records 808, budget records, etc.). The approved shared secret can be formed when the corresponding record is created. Approved shared secret is approved PPE Can be generated by 650. It can also be replaced when a record update occurs. Approved shared keys have some property associated with the "capacity" used in capability-based operating systems. Access tags (discussed below) are, in the preferred embodiment, an important set of approved shared secrets. Backup key As mentioned above, a backup of safety database 610 consists of reading all of the safety database records and the current audit "rollup" stored both on the PPE 650 and externally. The backup process then decrypts and re-encrypts this information with a new set of generated keys. These keys, backup time, and other appropriate information to identify this backup can be encrypted multiple times and stored in the backup file along with the previously encrypted secure database file and rollup data. .. These files are then PPE All can be encrypted using the "backup" key generated and stored within the 650. This backup key 500 can be used by PPE to restore the backup, if necessary. These backup keys are also securely encrypted (eg, using the download authentication key and / or the VDE administrator's public key) and stored within the backup itself, if the PPE 650 fails. But allow the VDE administrator to restore the backup. Encrypted seal Seals are used to protect the integrity of information when it can be altered outside the control of the PPE 650, either accidentally or as an attack on the security of the VDE. Two specific applications are the calculation of check values for database records and the protection of swapped out data blocks from the SPE 500.

There are two types of seals. There are two types of sealing, one that does not use a key, which is also known as an encrypted hash method, and the other that uses a key. Both of these use cryptographically strong hash functions such as MD5 and SHA. Such a function takes an input of any size and produces a hash or "digest" of a fixed size. This digest has the property that it is infeasible to calculate two inputs that produce the same digest, and it is infeasible to calculate one input that produces a specific digest value. Here, "infeasible" refers to a work function based on the size of the digest value represented by bits. If, for example, a 256-bit hash function is called powerful, it averages around 10 ^ 38 (2) by the time it is likely that a duplicated or specified digest value will be generated. ^ 128) must be calculated.

The keyless seal can be used as a check value in database records (eg PERC 808) and similar applications. The non-key seal can be calculated based on the contents of the record body and the seal stored in the rest of the record. The combination of the seal and the record can be encrypted to protect it within the storage device. If someone modifies the encrypted key (for example, the part that represents the data or the part that represents the seal) without knowing the encryption key, the decrypted content will be different and the decrypted inspection The value will no longer match the digest calculated from the record's data. Even if a hash algorithm is known, it is not feasible to modify the record data and its seals accordingly. Because both of them are encrypted.

A key seal can be used as a protection against data stored outside an unencrypted protected environment. It can also be used as validity proof between two protected environments. A keyed seal is calculated in the same way as a non-keyed seal, except that the sealed data is placed with a logically prefixed secret initial value. Thus, since the digest value depends on both the secret and the data, the data itself is visible to the attacker, but it is not feasible to calculate a new seal corresponding to the modified data. A key seal can protect data in storage using a single secret value, or protect data transitioning between two environments that share a single secret value. You can also do it.

The choice between a keyed seal and a non-keyed seal depends on the nature of the data being protected and also on whether the data is further protected by encryption. There is. Tag addition Tagging is especially useful to support relevant information on the secure storage and secondary storage 652 of critical component assemblies. The integrated use of "tagging" information with cryptographic strategies limits the configuration, management and operation of VDE nodes, as well as the use of VDE's protected content (although partially enabled). , And / or the use of inexpensive mass storage devices that securely store the information to be recorded becomes possible.

When encrypted or otherwise secured information is delivered to the user's secure VDE processing area (eg, PPE 650), some of this information is used as a "tag". Can be done. This tag is first decrypted or otherwise unsecured and then compared to the expected value to ensure that the information represents the expected information. To do. Therefore, this tag can be used as part of the process of verifying the identity and correctness of the received and VDE-protected information.

There are three classes of tags that can be provided in the control structure according to the preferred embodiment.

Access tag Validity test tag Correlation tag Each of these tags has a different purpose.

Access tags can be used as a "shared secret" between a VDE-protected element and an authorized entity to read and / or modify the tagged element (one or more). This access tag may be decomposed into separate fields to control different activities independently. If the access tag is used by an element like Method Core 1000, the management event that affects such element is the access tag (or of that access tag) for the affected (one or more) elements. Must have (part), and when the event is processed, its tag must be asserted. If the access tag is securely maintained (for example, created inside the PPE 650 when the element is created and revealed from the PPE 650 only in an encrypted structure), it will be distributed only to approved parties. Structural modifications can be controlled more safely. Of course, control structures (eg PERC 808) can further limit the modifications or other actions that appear in the management event and determine their importance.

Correlation tags are used when one element references another. For example, a creator may be required by a budget owner to obtain permission and establish a business relationship before referencing the budget within the creator's PERC. After such a relationship is created, the budget owner puts one or more correlation tags as one aspect that allows the creator to generate a PERC that references the budget owner's budget. Can be sent to the creator.

Validity test tags can be used to help detect attempted record replacement on the part of the tamperer.

In some respects, the tags in these three classes overlap in terms of their functionality. For example, correlation tag mismatches can prevent certain classes of modification attempts that could normally be prevented by access tag mismatches before the access tag is inspected. In a preferred embodiment, in some cases, this duplication can be utilized to reduce overhead, for example by using the access tag in a role similar to that of the validation tag described above.

In general, tagging procedures involve changing (one or more) encryption keys and (one or more) security techniques within SPE 503, and / or unique (one or more). ) Accompanied by providing a stored tag. These procedures are the information stored in the inexpensive mass storage device 652 described above and are made available within the hardware SPU 500 with VDE protected content and management database information. , Authentication, decryption, or other security database 610 information used for analysis. VDE node hardware (eg, PPE) is typically used to change validation tags. In 650), it involves storing one or more information elements corresponding to the tag change. Storing information outside the physically safe and reliable environment of a hardware SPE is a means that enables significant cost savings for safe storage. In addition, the security of the stored important management database information is enhanced by adding tags to the information in this way. Frequent "modifications" of such tags (eg, each time a given record is decrypted) can prevent "correct" information from being replaced by "incorrect" information. .. This is because such a replacement does not have information that matches the tagged additional information stored in the hardware SPE when the information is retrieved later.

Another effect of tagging information is the use of tags to help force and / or validate information and / or control mechanisms acting between two or more parties. is there. If information is tagged by one party and then passed to one or more other parties, the communication and / or transactions between those two parties with respect to the tagged information A tag can be used as the associated, expected value. For example, if a tag in a data element passed by Party A to Party B is associated, Party B reveals information (and / or part of it) associated with that data element to Party A by Party B. Party A can be required to prove that it knows the correct value for at least some of its tags (and vice versa). In another example, the tag is used by party A to verify that the information sent by party B is actually associated with the tagged data element (and / or part of it). Can be done (and vice versa). Establishing a secure and authenticated communication channel The two parties (eg PPE A and B) are occasionally used only by these two parties who have established communication channels known to both parties to be free of eavesdropping and tampering, and who know each other's identity exactly. You need to make sure that you are.

The following is an example of the process of establishing such a channel and clarifies how the requirements for security and authentication are established and validated by both parties. This process is abstractly described in terms of claims and credit that each party must establish and is not considered as a specification for a particular protocol. In particular, the individual substeps of each step are not required to be implemented using individual actions. In practice, the establishment and validation of relevant proofs are often combined into a single operation.

The sub-steps need not be performed in the order detailed below, unless the claim cannot be validated before it has been made by the other party. Since the "transmission" of information itself can be divided into several sub-steps, the steps can include more additional communication between the two parties, implied by the enumerated sub-steps. Also, there is no need to protect claims or proofs from exposure or alteration during transmission. Knowledge of claims, including specific communication proposals and notifications of their receipt, is not considered protective information. If the proof is modified, the proof becomes invalid and the process ends in failure.

Standard public or private key cryptography (eg, X.509, Authenticated Diffie-Hellman, Kerberos) can be used to implement this process. In this preferred embodiment, steps of a three-way X.509 public key protocol are used.

The first two steps of this illustrated process are:

A. (Pioneer step): Establish a means for A to create validity-testable claims.

B. (Pioneer step): Establish a means for B to create validity-testable claims.

With these two steps, each party, for example, by using a public key signing scheme that allows both parties to hold a private key and use a public key that is itself authenticated by the digital signature of the certification authority. There is a surefire way to create a claim that can be validated by the party.

The next steps are as follows:

A (suggestion step): 1. Determine the ID of B.

2. Obtain a means to check the validity of the claims made by B.

3. Create a unique ID for this particular proposed communication.

4. Create a communication proposal that identifies both parties and a particular communication.

5. Create a proof that can be tested for the validity of the A ID and the source of the communication proposal.

6. Deliver communication proposals and related proofs to B.

These steps establish the ID of the corresponding party B and suggest communication. Since establishing communication requires validation of the claims made by B, A must be provided with a means of checking the validity of these claims. This communication proposal and all relevant communications must be clearly distinguishable from all other such communications, as the establishment of communications must be specific to the specific requirements for A's communications. Must be. B needs to test the validity of the proposal as a legitimate proposal from A, so it must provide a proof that the proposal is valid.

The next steps are as follows:

B (receipt notification step) 1. Extract the ID of A from the communication proposal.

2. Obtain a means to check the validity of the claims made by A.

3. Check the validity of A's claim regarding the source of the ID and communication proposal.

4. Determine the unique ID of the communication proposal.

5. Determine that the communication proposal is not a copy of the previous proposal.

6. Create a receipt notification that identifies this particular communication proposal.

7. Create a proof that can be tested for the validity of B's ID and the source of the receipt notification.

8. Deliver receipt notifications and related proofs to A.

These steps establish that Party B has received A's communication proposal and is ready to act on it. Since B needs to test the validity of the proposal, B must first determine its source and test its validity. B must ensure that the response relates to a particular proposal and that the proposal is not a replay. If B accepts the offer, he must prove that B's own ID and B have received the particular offer. The next steps are as follows:

A (establishment step): 1. Check the validity of B's claim receipt notice for A's particular proposal.

2. Extract the ID of a specific communication proposal from the receipt notification.

3. Decide that the receipt notification is related to an open communication proposal.

4. Create a unique session key used for the proposed communication.

5. Create a proof that A created the session key.

6. Create a proof that the session key is associated with a particular communication proposal.

7. Create a proof that you have received B's receipt notification.

8. Protect the session key from exposure during transmission.

9. Protect the session key from being modified during transmission.

10. Deliver the protected session key and all proofs to B.

These steps allow A to identify the session key and tie it to all future communications related to A's particular communication proposal. A must create a key, prove that A created it, and prove that it connects to a particular proposed communication. In addition, A must prove that the session key is generated in response to B's receipt notification that the proposal has been received. The session key must be protected from exposure or alteration and must prevent an attacker from translating into a different value. Transmission potential between PPE 650 in VDE equipment In one preferred embodiment, the VDE object 300 and other secure information are reliably transmitted from one PPE 650 to another PPE 650, if appropriate, using the various keys outlined above. Can be done. VDE 100 uses the redistribution of VDE management information to exchange ownership of VDE objects 300, allowing them to move between electronic devices 600.

The permission record 808 of the VDE object 300 contains rights information that can be used to determine whether the entire object, in part or in part, can be redistributed. If the VDE object 300 can be redistributed, the electronics 600 must typically have a "budget" and / or other permissions that allow the device to redistribute the object. .. For example, an electronic device 600 authorized to redistribute an object may create a managed object that contains a budget or right that is less than or equal to the budget or right owned by the device. Some managed objects can be sent to other PPE 650s. A PPE 650 that receives one of the managed objects may have the ability to use at least part of the budget or rights to the associated object.

Transfer of ownership of VDE object 300 is a special case where all permissions and / or budgets for VDE objects are redistributed to different PPE 650s. Some VDE objects may require that all object-related information be delivered (for example, it is possible to "sell" all rights to the object). However, some VDE objects 300 may prohibit such transfers. In the case of a transfer of ownership, the first provider of VDE Object 300 used an approved shared secret with contact from the new owner, notification of the transfer, and reapproval before the transfer of ownership was completed. May require validation.

When electronics 600 receive a component assembly, the encrypted part of the assembly may contain values known only to the party that supplied the assembly or the PPE 650. This value may be stored with information that eventually needs to be returned to the assembly supplier (eg, auditing, billing and related information). When a component supplier requests that information be reported, the supplier provides that value, which causes the local electronics 600 to check this value against the originally supplied value and the request is valid. Can be convinced. When a new component is received, the value is checked against the old component and can determine if the new component is valid (for example, the new value for use in the next reporting process is the new component). Can be included with). VDE security integrity PPE 650 can be compromised by many methods. The security goal provided by the VDE 650 is to reduce the chances of a system being compromised and, if compromised, to minimize the negative impact.

The basic cryptographic algorithms used to achieve VDE 100 are assumed to be secure (strong in cryptography). These include private key cryptography of content, public key signing for authenticity verification, and public key cryptography for privacy between PPE 650 or between PPE and VDE administrators. Direct attacks on these algorithms are assumed to exceed the attacker's capabilities. Some of this is probably a safe assumption for the home version of VDE 100, as the basic building blocks for control information have long enough keys and are well provable.

The risks of the following threats or attacks can be significant: · Unauthorized creation or modification of component assemblies (eg budgets) · Unauthorized mass exposure of content Invasion of one or more keys · Hardware PPE software embroidery Substitute old record for new record Introducing "villainous" (ie non-genuine) load modules Replay attack Disable "fingerprint" · Unapproved exposure of individual content items -Redistribution of individual content items When one or more encryption keys are compromised, significant potential security breaches can occur. However, as mentioned above, VDE The encryption keys used by the 100 are so variable and partitioned that in most cases a single key compromise gives the attacker limited value. For example, if the certificate private key is exposed, an attacker can pass the challenge / response protocol as described above, but faces the next level of security, where initialization challenge / response or external. You need to crack one of the communication keys. If initialization challenge / response security is also disabled, the initialization code and various initialization keys are also exposed. However, understanding the code and data is required to find the shared VDE key and copy the key generation (rotation) algorithm. In addition, accurate real-time clock values must be maintained by spoofing. If an attacker can successfully achieve all of this, all secure communications to fake PPE can be compromised. If the communication associated with the object's permission record 808 is sent to a fake PPE, the object can be compromised.

Knowing the PPE download authorization key and the algorithm used to extract the key that encrypts the key for backing up the secure database 610 can compromise the entire secure database of a particular electronic device 600. However, in order to use this information to compromise the content of VDE object 300, it is also necessary to understand the proper VDE attributes. In one preferred embodiment, the secret body key and content key stored in the security database 610 are "aged" by including a time element. Time is circulated along with the stored value to get the "real key" needed to encrypt the content. If this process is also compromised, the content or methods of the object can be exposed. In this preferred embodiment, a "fake" PPE must be used to take advantage of this information, as the backup of the safety database 610 will not be returned to the PPE 650 without the intervention of an approved VDE administrator. ..

In this preferred embodiment, an external communication shared key is used with a site ID and time based key rotation algorithm. In the event of a breach, all of the steps required to enable communication with the PPE 650 are also known and this knowledge must be utilized. In addition, at least one of the managed object shared keys must be compromised in order to gain access to decryption permission record 808.

Violation of the managed object shared key is of no value unless the "cracker" also has knowledge of the external communication key. All managed objects are encrypted with a shared external communication key, site ID and unique key exchanged over time. Knowledge of the internal details of the PPE 650 is required to further decrypt the contents of the managed object.

The secret header of a quiesced object (or another quiesced object that uses the same shared key), if compromised, provides an attacker with access to the content until the shared key "ages" and the secret header cannot be decrypted. To do. Neither the object's secret body nor its contents, nor its permission information 808, is exposed until it is compromised. The secret headers of these objects remain compromised until the key "ages" and the secret header cannot be decrypted.

The secure database encryption key of this preferred embodiment is frequently modified and site specific. The outcome of a file or record breach in Safety Database 610 depends on the breached information. For example, permission record 808 contains the key for the exposure body and content of VDE object 300. When the permission record 808 is compromised, each aspect of this object protected by the key provided by the permission record is also compromised, if the algorithm that produces the "real key" is also known. Once the secret body key is known, the object's secret body is compromised until the key "ages" and expires. If this key "aging" process is also violated, the infringement will last forever. Since the secret body can contain methods shared by many different objects, these methods can also be compromised. When a breach is detected, all managed objects that provide budget and permission records should update the compromised method. The methods stored in safety database 610 are simply replaced by the more recent version, so the compromised version becomes unusable once the update is complete.

If the content key is compromised, the key-encrypted portion of the content is also compromised until the key "ages" and expires. If the key "aging" process is also violated, the infringement will last forever. If multiple levels of encryption are used, or if some of the content is encrypted with different keys, knowing one key is not enough to unlock some or all of the content.

Once an approved shared secret (eg, an access tag) is known, the record containing the secret can be modified by authorized means if the "cracker" knows how to use the secret properly. In general, external communication keys, managed object keys, and managed files must also be "cracked" before the shared secret becomes useful. Of course, detailed knowledge of the protocol is also required to use this information.

In this preferred embodiment, the PPE 650 can detect if it has been compromised. For example, a discrepancy is apparent by comparing the information stored in SPE 503 (eg, overview service information) with the information stored in safety database 610 and / or transmitted to VDE participants (eg, VDE information exchange). It becomes. When the PPE 650 (or the VDE administrator watching or communicating with it) detects that it has been compromised, it is updated by initialization with new code, keys and new encryption / decryption. An algorithm can be used. This limits the exposure of the VDE object 300 that was present when the encryption scheme was broken. If new code and keys are not downloaded, it is possible to request the PPE 650 to stop functioning after a period of time. It is also possible to force the VDE administrator to perform the update. Also, the desire to get a new VDE object 300 can provide users with an incentive to update their PPE 650 at regular time intervals.

Finally, due to the end-to-end nature of the VDE application, content 108 flows in one direction and reports and invoices 118 are generated in the other direction. It is possible to perform a match check. Can such checks be performed at Information Exchange 116 to indicate fraud (eg, over-acquiring protected content without the corresponding payment and usage records without the corresponding billing record)? Alternatively, the actual usage pattern can be detected. The detailed usage reports and the availability of usage records and reports in electronic form can help build advanced fraud detection mechanisms, thereby keeping fraud-related costs at acceptable levels. it can. PPE initialization Each PPE 650 must be initialized before use. Initialization can be done at the manufacturer's site after the PPE 650 is installed in the field, or both. The manufacturing process for the PPE 650 typically involves embedding sufficient software within the PPE that allows the device to be more fully initialized later. This manufacturing process is, for example, PPE Includes testing bootstrap loaders and challenge-response software that are permanently stored within the 650, as well as loading the PPE's unique ID. These steps provide a basic VDE-capable PPE 650, which can be further initialized (eg, after being installed in electronics 600 and installed in the field). In some cases, the manufacturing process may be combined with a further initialization process to produce the "VDE Installation" PPE 650. The above-mentioned outline in relation to FIGS. 64 and 65 has been described in more detail above.

FIG. 68 shows an example of the steps to initialize the PPE 650, which can be done in one preferred embodiment. Some of the steps shown in this flowchart can be performed at the manufacturing site and some can be performed remotely via contact between the VDE administrator and the PPE 650. Alternatively, all of the steps shown in the figure may be performed at the manufacturing site, or all of the steps shown may be performed via remote communication between the PPE 500 and the VDE administrator.

If the initialization process 1370 takes place at the manufacturing site, the PPE 650 is first mounted on the test bench. The manufacturing test bench can first reset the PPE 650 (eg with power-on clear) (block 1372). If this reset is done at the manufacturing site, the PPE 650 preferably runs a special test bench bootstrap code that thoroughly tests the operation of the PPE from a software point of view and fails if there is a change in the PPE. A secure communication exchange between the manufacturing test bench and the PPE 650 can then be established using the first challenge-response dialogue, preferably provided as part of the test bench bootstrap process. Once this secure communication is established, the PPE 650 may report the results of the bootstrap test performed to the manufacturing test bench. If the test with PPE 650 is successful, the manufacturing test bench will PPE the new code. Download to 650 and update the internal bootstrap code (block 1376), which results in the test bench not going through the test bootstrap process to the end the next time it undergoes a reset (block 1376). The production test bench then loads the new firmware into non-volatile memory inside the PPE, which provides additional standard and / or customized capabilities (block 1378). For example, the manufacturing test bench may preload the PPE 650 with a load module suitable for a particular production lot. This step allows the PPE 500 to be factory customized for a particular application.

The manufacturing test bench can then load the unique equipment ID into the PPE 650 (block 1380). This causes the PPE 650 to have a unique ID that can be used in the next conversation.

In this preferred embodiment, blocks 1372 to 1380R are typically performed at the manufacturing site. Blocks 1374 and 1382 to 1388 are manufacturing sites and can be done after or both after the PPE 650 has been installed.

To further initialize the PPE 650, once secure communication has been established between the PPE and the manufacturing test bench or VDE administrator (block 1374), the required keys, tags or certificates are loaded onto the PPE 650. Be done (block 1382). For example, a manufacturing test bench may load that information into the PPE 650 so that the PPE can be initialized later. Some of these values can be generated inside the PPE 650. The manufacturing test bench or VDE administrator can initialize the PPE real-time clock 528 to the current real-time value (block 1384). This gives the time and date criteria for the PPE 650. The production test bench or VDE administrator can then initialize the summary values maintained inside the PPE 500 (block 1386). If the PPE 650 is already installed as part of the electronics 600, the PPE may initialize the safety database 610 at this point (block 1388).

FIG. 69 shows an example of a program control step performed by the PPE 650 as part of the firmware download process (see Figure 68, block 1378). The PPE download process is used to load externally provided firmware and / or data elements into the PPE. Firmware loading includes two forms: permanent loading for software that stays within the PPE 650 and short-term loading for software that is loaded for execution. The relevant process for storage in safety database 610 is done for the element sent to VDE electronics 600.

The PPE 650 automatically performs some checks to ensure that the firmware downloaded to the PPE has not been tampered with, replaced or transliterated before the load is complete. The download routine 1390 shown in the figure shows one example of such a check. When the PPE 650 receives a new firmware item (block 1392), it checks this item to make sure it is properly decrypted with the given download or management object key (depending on the element source) (decision). Block 1394). Once the firmware is properly decrypted (exit "YES" in decision block 1394), the firmware as a check value can be calculated and compared to the check value stored under the firmware encryption wrapper (decision block). 1396). If the sum of these two checks is the same (exit "YES" in decision block 1396), the PPE 650 compares the firmware-related exposure and secret header identification tags to indicate that the appropriate firmware has not been provided and transliterated. Make sure (this step is not shown). If this test also passes, PPE The 500 can calculate the firmware's digital signature (assuming the digital signature is supported by the PPE 650 and the firmware is "signed"), check the calculated signature, and under the firmware encryption wrapper. Make sure it is the same as the digital signature (blocks 1398, 1400). If any of these tests fail, the download will be interrupted ("failed" end 1401).

If all of the above tests pass, the PPE 650 decides whether to store the firmware in the PPE (eg, internal non-volatile memory) or in the safety database 610 (decision block 1402). If the firmware is stored inside the PPE (exit "YES" in decision block 1402), the PPE 500 may simply store the information internally (block 1404). If the firmware is stored in safety database 610 ("NO" exit of decision block 1402), the firmware is tagged with a unique PPE specific tag designed to avoid transliteration of records (block 1406), then appropriate. It can be encrypted with a secure database key and released to secure database 610 (block 1408). Network SPU 500 and / or VDE Electronics 600 If many computers are interconnected by a local or wide area network, it is possible that one or a few of them are VDE electronics 600. For example, a VDE-enabled server has one or more SPUs Can include 500. This centralized VDE server can provide all the required VDE services in the network or share the VDE services with the VDE server node. That is, it may perform a few, some, or most of the VDE service activities. For example, a user's non-VDE computer may issue a request over the network for VDE protected content. In response to this request, the VDE server may access the appropriate VDE object 300, release the requested content, and deliver the content to the requested user over network 672. Such an arrangement allows the capabilities of VDE to be easily integrated into the current network without the need for modification or replacement of various computers and other devices connected to the network.

For example, a VDE server with one or more protected processing environments 650 may communicate over a network with workstations that do not have a protected processing environment. The VDE server can perform all secure VDE processing and release the resulting content and other information to workstations in the network. With this arrangement, the workstation does not require any hardware or software modifications.

However, some applications require higher security, flexibility and / or performance, which can be obtained by connecting multiple VDE electronics 600 to the same network 672. Since commonly used local area networks constitute insecure channels that can be tampered with and / or eavesdropped, it is desirable for the most secure applications to protect information that is communicated across the network. It would be possible to use conventional network security techniques to protect VDE-emitted content or other VDE information transmitted across network 672 between VDE electronics 600 and non-VDE electronics. However, there are some advantages to deploying a large number of networked VDE electronics 600 in the same system.

As mentioned above in connection with FIG. 8, a large number of VDE electronics 600 may communicate with each other through network 672 or other communication passages. Networking such VDE electronics 600 has several advantages. For example, it has the potential to centralize VDE resources, store and / or aggregate weighing information on server VDEs, and efficiently deliver information and services across network 672 to a large number of electronics 600.

For example, in a local area network topology, the "VDE server" electronics 600 may store VDE protection information and make it available to one or more additional electronics 600 or computers that may communicate with the server through network 672. .. As an example, the object storage location for storing VDE objects was maintained within a centralized server, and each user of many networked electronics 600 was centralized through network 672 as needed. You can access the object storage location. When a user needs access to a particular VDE object 300, this user's electronics 600 can issue a request over network 672 and get a copy of the object. The "VDE server" may deliver all or part of the requested object 300 in response to this request. Providing such a centralized object storage location 728 has the advantage of minimizing the high storage requirements for each electronic device 600 connected to network 672, eliminating redundant duplication of the same information. It eases the burden of information management and provides additional physical and / or other security for particularly important VDE processes and / or information that takes place on the server. Providing such security on a VDE node can be commercially impractical depending on the business model.

It is also desirable to centralize the safety database 610 in the topology of the local area network. For example, in the case of a local area network, the server for safety database 610 can be centrally deployed. Each of several electronic devices 600 connected to the local area network 672 may issue a request for records in the safety database 610 through the network and receive these records over the network. Records may be provided in encrypted form over the network. The "key" needed to decrypt the record can be shared by transmitting across the network in a secure communication exchange. Centralizing the safety database 610 within network 672 minimizes or eliminates secondary storage and / or other memory requirements for each of the networked electronics 600, avoiding redundant information storage. It is possible to provide a centralized backup service, and there are potential advantages such as alleviating the burden of information management.

One method to obtain many examples of low-cost, convenient placement of VDE electronics 600 across a network would be to deploy software that defines HPE 655 on network workstations. This arrangement does not require any hardware modifications to the workstation. HPE 655 can be defined using software only. SPE 503 and / or HPE 655 can also be deployed within the VDE server. This arrangement has the advantage of being able to process the distributed VDE network (except for loading new programs) without the need to customize or modify the workstation. VDE functionality that requires a high level of security can be constrained to SPU-based VDE servers. A "safe" HPE-based workstation can perform VDE functions that require a lower level of security, and its activities can be coordinated with the VDE server.

Therefore, it may be advantageous to deploy a large number of VDE electronics 600 in the same network. It may also be advantageous to deploy multiple VDE electronics 600 within the same workstation or other electronics 600. For example, the electronic device 600 may include a large number of electronic devices 600, each of which has an SPU 500 and is capable of performing VDE functions.

For example, one or more VDE electronic devices 600 may be used as input / output devices in a computer system. This eliminates the need to decrypt information within one device and move it in an unencrypted form through a bus or other insecure channel to another device, such as a peripheral. Peripheral device itself is SPU If the VDE electronics 600 has 500, the VDE protection information can be reliably sent to the peripheral through an insecure channel for processing on the peripheral (eg, decoding). Giving peripherals the ability to handle VDE protection information directly also increases flexibility. For example, peripherals in VDE electronics 600 may control the use of VDE object 300. For example, you can measure usage or other parameters related to the information that the device processes, and to gather more information about the use of VDE objects, audit trials and other information that are specific to the processing that the device performs. You may collect it. By deploying a large number of collaborative VDE electronic devices 600, performance is improved because it is not necessary to transfer the encrypted information to the VDE electronic device 600 and then transfer it to the non-VDE device again in the unencrypted form. Can be done. VDE protection information can be transferred directly to the device of interest, and if this device is VDE capable, the information can be processed without the need to involve other VDE electronics 600.

FIG. 70 shows an example of an arrangement 2630 with a large number of VDE electronics 600 (1), 600 (2), 600 (3), ..., 600 (N). VDE electronics 600 (1) ... 600 (N) are connected to each other through a communication passage 2631 (eg, workstation system bus, telephone line or other wire, cable, backplane, network 672, or other communication mechanism). Can communicate. Each of the illustrated electronic devices 600 may have the same general structure as shown in FIG. That is, CPU (or microcontroller) 654, SPU 500, RAM 656, ROM, respectively. 658, and system bus 653 may be included. Each of the illustrated electronic devices 600 may have an interface / controller 2632, which can be considered to be the particular type of I / O controller 660 and / or communication controller 666 shown in FIG. This interface / controller 2632 provides an interface between the electronics system bus 653 and the appropriate electrical connector 2634. Each electrical connector 2634 of electronics 600 (1), ... 600 (N) provides a connection to a common network 672 or other communication passages.

The illustrated electronic device 600 has a similar structure but can perform different special tasks. For example, electronics 600 (1) may include a workstation central processing unit that is responsible for managing the overall operation of the workstation and providing computational resources. The electronic device 600 (2) may be a mass storage device 620 for the same workstation and may include, for example, a storage mechanism 2636 capable of reading information from and writing information from secondary storage device 652. The electronics 600 (3) may be a display device 614 responsible for performing display tasks and may include a display mechanism 2638 such as a graphics controller and associated video or other display device. The electronics 600 (N) can be a printer 622 that prints related tasks, including, for example, a printing mechanism 2640.

Each of the electronic devices 600 (1), ... 600 (N) has different modules of the same workstation device, all contained in a common housing, or each electronic device is located within a different system component. Can be done. For example, the electronic device 600 (2) may be located in the disk controller unit, the electronic device 600 (3) may be placed in the housing of the display device 614, and the electronic device 600 (N) may be placed in the housing of the printer 622. Can be deployed. With reference to FIG. 7, the scanner 626, the modem 618, the telecommunications means 624, the keyboard 612 and / or the voice recognition box 613 may each include a VDE electronics 600 with its own SPU 500. Some other examples include RF or wireless interface controllers, series interface controllers, LAN controllers, MPEG (video) controllers, and so on.

Since each of the electronic devices 600 (1) ... 600 (N) can be VDE-enabled, each has the ability to encrypt and / or decrypt VDE protection information. This means that information transmitted across network 672 or other communication paths 2631 connecting to electronics can be VDE protected (eg, as mentioned above, information is VDE managed and / or content objects. Packaged and encrypted in the form of). One of the consequences of this arrangement is that eavesdroppers who eavesdrop on communication passage 2631 will not be able to obtain any information other than in VDE protection. For example, the information to be printed generated by the electronic device 600 (1) is packaged in the VDE content object 300 and transmitted to the printing electronic device 600 (N) through the passage 2631. Since this information is transmitted in a protected form, there is little benefit to an attacker stealing this information. In order to access this information in the unprotected form, the electronics 600 (1) or 600 (N) (or SPU 500 (1), 500 (N)) must be compromised.

Another advantage offered in the illustrated arrangement is that each of the electronics 600 (1), ... 600 (N) can perform its own weighing, control and / or other VDE-related functions. For example, electronics 600 (N) may perform other VDE control functions related to weighing and / or printed information, and electronics 600 (3) may perform other VDE control functions related to weighing and / or displayed information. VDE control function of, electronic device 600 (2) may perform other VDE control functions related to information stored in and / or retrieved from the weighing and / or mass storage means 620, and electronic device 600. (1) may perform other VDE control functions related to the information to be weighed and / or processed.

In one particular arrangement, each of the electronic devices 600 (1), ... 600 (N), the information received or sent by the electronic device is the following information using the device's SPU 500: Can receive a command indicating that it is to process. For example, electronic device 600 (N) may receive a command indicating that the information it is trying to receive for printing is in VDE protection (or the information itself sent to the device indicates this). Upon receiving this command or information, the electronic device 600 (N) will be SPU. The information received using the 500 can be encrypted and the information the SPU provides to the printing mechanism 2644 for printing can be weighed. Additional commands may be sent to electronic device 600 (N) to disable the decryption process. Alternatively, a 600 (N) VDE-safe lower system may determine that the information should not be decrypted and / or printed. Additional commands may exist, for example, to load an encryption / decryption key, to load a "limit", to establish a "fingerprint" requirement, and to read a weighed use. .. These additional commands may be sent in encrypted or unencrypted form as needed.

For example, suppose an electronic device 600 (1) wants to create information and print it with a VDE-enabled printer 622. The SPU 500 (1) now establishes secure communication with the SPU 500 (N) through passage 2631 to reconfigure the SPU 500 (N) with the next block of data and store it as a decryption key and restriction. May provide commands to command. The SPU 500 (1) may further send a command to the SPU 500 (N) to process the subsequent encrypted print stream with the decryption key and related restrictions (or this command may be). Can be sent by CPU 654 (1) to microcontroller 654 (N)). Electronic device 600 (1) may then begin sending encrypted information to passage 672 for decryption and printing by printer 622. Immediately after each printer 622 receives a new block of information, the SPU 500 (N) first checks that the limit is greater than zero. SPU 500 (N) then increments the used weighing value to be maintained and decrements the limit value. If the limit is non-zero, the SPU500 (N) decodes the received information and provides it to the printing mechanism 2640 for printing. If the limit is zero, the SPU500 (N) does not send the received information to the print mechanism 2640 or decrypt it. The printer 622 may return to "unsafe" mode as soon as it receives the command to stop. In this mode, the printer prints everything it receives through passage 2631 without allowing VDE processing.

The SPU 500 (N) associated with the printer 622 does not need to be located in the printer housing, but may instead be located, for example, in the I / O controller 660 (see Figure 8). This may provide at least some of the advantages similar to those described above without the need for a special VDE-enabled printer 622. Alternatively, the SPU 500 (N) can be deployed both in the printer 622 and in the I / O controller 660 that communicates with the printer, harmonizes with I / O control, and is associated with the central processing electronics 600 (1). It can provide an advantage in eliminating the processing load from the printer. When multiple VDE cases occur within an electronics, one or more VDE-safe subsystems can be the "central" subsystem. That is, a "secondary" VDE case passes encrypted usage-related information through one or more secure central and lower systems, which allows this central and lower system to directly control the storage of usage-related information. .. Certain control information can also be centrally stored by the central subordinate system, and all or part of such information is reliably provided to the secondary secure subordinate system in response to its secure VDE requirements. Portable electronic device The electronic device 600 provided by the present invention can be portable. FIG. 71 shows one example of the portable electronic device 2600. The mobile device 2600 may include a mobile housing 2602, which in one example can be approximately credit card size. The housing 2602 may be connected to the outside world, for example, via an electrical connector 2604 having one or more electrical contact pins (not shown). Connector 2604 may electrically connect the external bus interface 2606 inside housing 2602 to a pair of connectors 2604a in host system 2608. The external bus interface 2606 comprises, for example, a PCMCIA (or other standard) bus interface, allowing the mobile device 2600 to interface and communicate with the host system 2608 through the bus 2607. Host 2608 can be almost any device you can imagine, such as a computer, pay phone, another VDE electronics 600, a TV, an arcade video game, or a washing machine.

Housing 2602 can prevent tampering (see SPU Barrier 502 tamper-proof description above).

The portable device 2600 of this preferred embodiment includes one or more SPUs 500 that can be located within the housing 2602. The SPU500 may be connected to the external bus interface 2606 by bus 2610 in housing 2602. The SPU 500 communicates with host 2608 (via the external bus interface 2606) through this internal bus 2610.

The SPU 500 is preferably powered by a battery 2612 or other portable power source located within the housing 2602. The battery 2612 can be, for example, a small battery of the type found in wristwatches or credit card sized calculators. Battery 2612 may be complemented (or replaced) by solar cells, rechargeable batteries, capacitive storage batteries, and the like.

Random access memory (RAM) 2614 is preferably deployed within housing 2602. RAM 2614 can be connected to SPU 500, but not directly to bus 2610. As a result, the content in RAM 2614 is only accessed by the SPU and not by the host 2608 (unless it is done through it if allowed by the SPU). As shown in Figure 9, RAM 2614 can be part of RAM 534 in the SPU 500. However, it does not necessarily have to be in the same integrated circuit or other package that houses the rest of the SPU.

The RAM 534 of the mobile device 2600 may include, for example, information that can be used to individually identify each case of the mobile device. This information can be used in authentication, verification, decryption and / or encryption processes (eg, as at least part of key or password information).

In one embodiment, the portable device 2600 may be provided with means to perform substantially all the functions of the VDE electronic device 600. Thus, for example, the mobile device 2600 may include means for storing and using permissions, methods, keys, programs and / or other information and may operate as a "standalone" VDE node.

In another embodiment, the portable device 2600 may perform the VDE function of the preferred embodiment when coupled to an additional external electronic device 600. Certain information such as database administration permissions, methods, keys and / or other important information (such as at least some of the other VDE programs such as administration, user interface, analytics), portable device 2600 (eg as a record). Can be stored in an external VDE electronic device 600 that can share information with.

One possible "standalone" configuration for a mobile device 2600 arrangement that can prevent tampering is one or more processors (500, 2616) and / or other computing units and / or other control logic, as well. Includes a tamper-proof package (housing 2602) with random access memory 2614. Processors 500, 2616 may execute permissions and methods entirely within (or at least in part) the mobile device 2600. The mobile device 2600 may have the ability to encrypt information before it is transmitted outside the housing 2602 and / or to decrypt the information received when the information is received from outside the housing. This version of the device may also have the ability to reliably store at least some of the permissions, methods and / or key information in a mobile housing 2602 that can prevent the tampering of non-volatile memory.

Another version of the mobile device 2600 obtains permissions and / or methods and / or keys from the local VDE electronics 600 external to the mobile device 2600 to control and manage the user's use of VDE protected objects, if not restricted. obtain. Such a portable device 600 may be contained within, received by, installed within, or directly connected to another electronic device 2600.

One example of a "minimal" configuration for portable area 2600 could include the SPU 500 and battery 2612 within housing 2602 (in this case the external bus interfaces 2606 and RAM 2614 could be integrated into the SPU blocks shown respectively). .. In other more advanced examples of the mobile device 2600, any or all of the following optional components may also be included within the housing 2602.

One or more CPUs 2616 (with related support components such as RAM-ROM 2617, I / O controller (not shown)), One or more display devices 2618, One or more keypads or other user input buttons / control information 2620, One or more removable / replaceable memory devices 2622, and One or more printers 2624.

In such advanced versions, the display device 2618, keypad 2620, memory device 2622 and printer 2624 may be connected to bus 2610. Alternatively, it may be connected to the CPU 2616 via the CPU's I / O port / controller section (not shown). Display 2618 can be used to display information from SPU 500, CPU 2616 and / or host 2608. The keypad 2620 can be used to enter information into the SPU 500, CPU 2616 and / or host 2608. Printer 2624 can be used to print information from any / all of these sources. The removable / replaceable memory 2622 includes a memory medium such as a memory cartridge or bulk storage to provide additional long-term or short-term storage. The memory 2622 can be easily removed from the housing 2602 if desired.

In one embodiment, the mobile device 2600 may have a "smart card" form factor (the "smart card" form factor may provide some advantages, but the housing 2602 form factor is "conventional". It can be the same as or different from a smart card). Alternatively, such portable electronics 2600s are packaged in, for example, PCMCIA card configurations (etc.) that are becoming very popular in personal computers and are expected to become common in desktop computers and Personal Digital Assistants. obtain. One advantageous form factor for the portable electronics housing 2602 can be, for example, a credit card or a Type 1, 2 or 3 PCMCIA card (or any other derived from it) with slightly larger dimensions. Such form factors are conveniently portable, for a wide range of computers and consumer equipment, as well as in commercial facilities such as retail stores and banks, and public communication points such as telephones or other telecommunications "booths". Can be inserted into the receptacle of.

The housing 2602 can be inserted into or removed from a port, slot or receptacle provided by another host 2608, which can be physically (otherwise operably) connected to a computer or other electronic device. The portable device connector 2604 can be configured to be easily removable so that the device 2600 can be moved to another computer or other electronic device in a different location and physically connected to that device or otherwise actuated. You can make a connection.

The Portable Electronics 2600 provides a valuable and relatively easy way for users to move permissions and methods between various (compatible) electronic devices 600, such as between notebook computers, desktop computers and office computers. obtain. Also, for example, a high-capacity optical disc where a consumer visits a neighbor's house and shows the neighbor a movie for which the consumer is licensed to watch, or perhaps the consumer is licensed for unlimited playback. It can also be used to let neighbors hear the audio recordings in.

The portable electronics 2600 can also serve as a "smart card" for finance and other transactions that users use in a variety of other applications, such as commercial applications. The portable electronics 2600 may possess, for example, information on permissions and / or methods used to approve (and possibly record) commercial processes and services.

One advantage of using the VDE mobile device 2600 in this preferred embodiment for financial transactions, such as those typically performed by banks and credit card companies, is that VDE is a financial information exchange (VISA, MasterCard or Americal Express, etc.) can significantly reduce operating costs. Costs can be reduced at information exchanges because local weighing and budget control is performed at the user site by using VDE electronic devices 600 such as mobile devices 2600, which involves the information exchange for each transaction. Because there is no more. In contrast to current requirements, information exchanges can perform their function by updating records on a regular basis (such as once a month). Audit and / or budget "rolling up" is between connections initiated to convey such audit and / or budget information, and / or connections that occur at regular or relatively regular intervals. It can be done through and / or during credit renewals, purchases, or transactions of other mobile devices 2600.

Information exchange VDE digital allocation transactions only require occasional approvals and / or audits to central services or other management "roll-ups" rather than much more costly connections during each session. Information by reducing communication costs, equipment that handles simultaneous processing of information, and the written portion of transaction processing costs, as there is no need to maintain "written tracking" of credit card purchases (approval and transfer of credit card vouchers). Substantial cost savings (and potentially user cost savings) at the exchange can be achieved. By using the portable device 2600 in this way, it becomes possible to carry out credits for developing an allocation process using the computing power of each VDE electronic device 600. These credit cost and processing benefits can also be applied to the use of non-smart cards and non-portable VDE electronics 600.

Costs because the VDE 100 can be configured as a highly secure commercial environment, and because the authentication process supported by VDE uses a digital signature process that provides a formal validity check equivalent to paper documents and handwritten signatures. It is no longer necessary for the mobile device 2600 to maintain paper tracking for such transactions. Auditable billing and control mechanisms are built into VDE 100 and automated, replacing traditional electronic interfaces to VISA, MasterCard, AMEX and bank debit accounts with other digitally distributed products and services. Substantial operating costs at information exchanges can be saved.

If desired, the mobile device 2600 may maintain a mobile electronic history for the consumer. The cell phone history can be moved or operably connected to, for example, an electronic "dock" or other receptacle on a computer or other consumer-hosted device 2608. Host equipment 2608 has, for example, at least part of the control logic in the form of a microcomputer and stores information in methods organized by, for example, taxes and / or other transaction categories (such as use or activity type). Can be an electronic organizer. By using this arrangement, consumers do not have to maintain manual tracking transactions without receipts and can nevertheless maintain very secure electronic audit tracking of transactions and statement of accounts. The statement of statement may reliably include, for example, the digital signature of the user and, optionally, the digital signature of the service or product provider.

When a mobile device 2600 is "docked" to a host 2608, such as a personal computer or other electronic device (such as an electronic organizer), the mobile device 2600 can convey interim audit information to the host. In one embodiment, this information is read directly or indirectly to a computer or electronic organizer and / or tax management program (eg, Quicken or Microsoft Money and / or Turbo Tax and / or Andrew Tobias' Managing Your Money). be able to. This automation of receipt management can be a great benefit to consumers. Because receipts are difficult and time consuming to manage and maintain, receipts are often lost or forgotten, and credit card billing usually does not provide sufficient data or significant transaction parameters for purchase items. Credit card billing details are generally inadequate for billing and repayment.

In one embodiment, the portable device 2600 is secure with a retail terminal that includes the VDE electronics 600 or is capable of communicating with the retailer's or third party provider's VDE electronics 600 (encryption and / in this example). Or it can support two-way communication (or authenticated). For example, during such secure two-way communication between each participant's secure VDE sub-system, each mobile device 2600's secure VDE sub-system authenticates and provides appropriate credit or debit card information to the retail terminal's VDE. Can be provided to safety infrastructure. During the same or different communication sessions, the terminal also goes to the VDE secure subsystem of the mobile device 2600 with details about retail transactions (eg, purchased goods and prices, retail facility digital signatures, retail terminal identifiers, tax information, etc. ) Can be reliably sent back.

For example, a host 2608 receptacle for receiving and / or adhering to a mobile device 2600 may be incorporated into or operably connected to a terminal in a retail store or other commercial facility. The host terminal 2608 may be operated by either an employee of a commercial facility or a holder of the mobile device 2600. For example, a host terminal can be used to enter specific information, such as who was invited to a dinner, why it was purchased, or the category to which each information belongs, with a specific keyboard and / or voice. The information is then automatically "dissected", paving the way to a well-maintained (eg, encrypted) database management record within the mobile device 2600. These "dissections" and routing are reliably controlled by VDE-safe infrastructure processes, such as the type (category) of category information and / or facility class and / or expense information (or other uses) entered by the user. Can be based. Categorization can be provided by retailers, for example, by reliably transmitting electronic categorical information, for example as part of electronic receipt information, or by printing hard copy receipts using a printer 2624. This categorization process can be done on the mobile device 2600 or by a retailer and is regularly "rolled up" and communicated to the holder of the mobile device 2600.

Retailers, information exchanges or other commercial organizations are involved in automating the dissection of information into records and / or for database information "rolling up" and / or mobile devices 2600 or one or more. One or more general classifications of transaction types that can be used in VDE nodes (eg, as specified by government tax collection rules) can be maintained and used by reliably communicating to device 2600. In such an example, the host 2608 may, for example, be equipped with an auxiliary terminal, or be equipped with a commercial facility cash register or other retail trading equipment, or may be incorporated directly therein. Auxiliary terminals can be driven by menus and / or icons, allowing the user to make categorization choices very easily. Also, some transaction types may provide templates that can guide users by identifying useful or necessary transaction-specific information (eg, business dinner objectives and / or dinner attendees). .. For example, a user selects a business icon, eg a business trip, sale, meal, management or purchase icon, enters highly specific information and / or keywords or other codes to carry transaction details. It can be downloaded to device 2600. This information may also be stored by commercial establishments and communicated to appropriate governments and / or business organizations for validation of reported transactions (high level security VDE auditing, communications, certification and validity). Sexual tests should be fully trusted and should not require the maintenance of parallel audit history, but parallel maintenance is supported and is maintained for at least a limited period of time, so the portable device 2600 and / or history and / or history and / Or backup information may be provided in the event of loss or "failure" of the VDE installation associated with one or more VDE devices 2600 used by device 2600 to maintain state information records, eg retail. Necessary transactions related to transactions involving the device 2600 maintained by the terminal For information, retail terminals either communicate such information to information exchanges for storage (and / or other acts), or send such information on a regular basis, eg, at the end of a business day. For example, it can be reliably communicated to an information exchange or information exchange agent in the form of a VDE content container object. Such transaction history (and all required VDE-related state information such as available credits) can be maintained, and if necessary, reconstruct the information within the mobile device 2600 and replace it with the user of the device 2600. It can be used to deploy equipment or to properly reset inside information in the data. At this time, such replacements and / or resets provide all necessary transaction and status information.

In retail stores, the auxiliary terminal host 2608 may take the form of a mobile device presented to the user, for example, at the end of a meal. The user inserts his mobile device 2600 into a smart card receptacle such as a PCMCIA slot and enters additional information. This information may adequately describe the transaction and meet the required electronics 600 identification procedures. If sufficient credit is available, the transaction is accepted and transaction-related information is returned directly from the auxiliary terminal to the mobile device 2600. This is a very convenient mode of credit usage and record management.

The portable device auxiliary terminal can be "online" and is electronically returned to a commercial facility and / or a third party information gathering point by using cellular, satellite, radio frequency or other means of communication. Auxiliary terminals are checked by a commercial party in response to receiving certain identification information at the collection point, and then the mobile device 2600 is based on other information such as a bad credit record or theft of the mobile device 2600. Can be returned to the auxiliary terminal as to whether or not to accept. Such mobile auxiliary terminals also allow other commercial facilities, such as gas stations, rental car return areas, town and stadium salespeople, bars, and clerk and other staff to trade at locations other than traditional cash register locations. It can also be very useful in other commercial establishments where efficiency can be optimized by being able to complete.

As mentioned above, the mobile device 2600 may occasionally communicate with other electronic devices 600, such as the VDE administrator. Communication during a mobile device 2600 use session is based on internally stored parameters that direct the connection to take place during the current session (or next or other session) of mobile device use. The mobile device 600, if appropriate, requires real-time dates to communicate (eg, before, during, or immediately after, perhaps before, during, or after other processes considered by the user for the transaction or its session). Or you may have information about the time of day or period. Such communication can be realized immediately and can be secure VDE two-way communication, during which information is communicated to the central information handler. Certain other information may be transmitted to the mobile device 2600 and / or the computer or other electronic device to which the mobile device 2600 is connected. Other information transmitted in this way may allow or prevent the considered process from proceeding and / or make the mobile device 2600 at least partially unusable or available. The information transmitted to the mobile device 2600 may include one or more modifications to permissions and methods such as resetting or increasing one or more budgets, adding or removing certain permissions.

The permissions and / or methods (ie, budget) possessed by the mobile device 2600 may be assigned in relation to the "burden" of another, stationary, or other portable VDE electronics 600. In one embodiment, the holder of mobile device 2600 or the user of other VDE electronics 600 and / or VDE electronics 600 may act as a financial "guarantor" for transactions made by another party. The holder's mobile device 2600 records a "burden", which means that during secure communication with the information exchange, information is exchanged until all or part of the debt liability of the other party is paid or met. It may be recorded and maintained by a place and / or other financial services party. Or, in addition to this, the burden can also be maintained within the mobile device 2600 and represents the guarantor's ancillary debt. Depending on the format, the burden may be included in determining the credits available to the guarantor. Credit transfer, acceptance and / or records management and related processes can be reliably maintained by the security characteristics provided by the aspects of the invention. The mobile device 600 can be the only place for permissions and / or methods for one or more VDE objects 300. Alternatively, the portable device may have a budget for these objects that is independent of the budget for these objects found in another non-portable VDE electronics 600. It to this Ri, budget, for example, is moved without the need for a "burden" and the budget of the arbitration.

The Portable VDE Electronics 2600 (similar to the other VDE Electronics 600s mentioned above) allows for information on credit history details, an overview of approvals, and the reuse of certain VDE protection information at no cost or at low cost. You may have usage history information (eg, some audit of relevant summary information such as transaction history or use of certain types / classes of information). Such use or cost of use may depend, at least in part, on the previous use, or usage, of one or more objects or object classes of VDE protection information.

The mobile device 2600 may also possess certain information that can be used for identification, at least in part. This information is used in a fixed order (eg, a pattern based on a pseudo-random algorithm) to verify the ID of the owner of the mobile device 2600. Such information includes, for example, the maiden name of one's own or wife's and / or other relatives, the social security number of one's own and / or another's, birthday, hospital of birth, and other identification information. obtain. Alternatively, it may provide or include one or more passwords or other information used to identify or verify / authenticate an individual's ID, such as voice prints and retinal scan information. For example, the mobile device 2600 can be used as a smart card with various permission and / or method information for approval and budgeting. This information can be reliably stored within the Mobile Device 2600 of the Safety Database 610 Arrangement. When a user purchases or seeks a license for an electronic device, or attempts to approve a process using a "smart card," the mobile device 2600 asks or scans the user for self-certification information. Or other technology that may use the entered information (user's fingerprint, retina or voice analysis, or, for example, mapping and / or matching to information reliably stored within the mobile device 2600 of the provided features, etc. ) Can be started. The mobile device 2600 may use different questions at different times (and / or may provide multiple questions or requests to scan or enter self-certification information), thereby allowing one or more ID "tests". Prevents individuals who have the proper information for "" from successfully using the mobile device 2600.

The mobile device 600 may also have the ability to transfer electronic currency or credits to another mobile device 2600 or to another personal account, for example using secure VDE communication of related content between secure VDE subsystems. Such transfers can be accomplished, for example, by telecommuting to a bank or going to a bank where credits and / or currency can be transferred to another account. Transfers can also be made by using two cards at the docking station of the same mobile device 2600. For example, a credit trading workstation may include two PCMCIA slots and suitable credit and / or currency transfer application software. This software can ensure that one mobile device 2600 is debited and another mobile device "credited" (ie, debiting one device debits the corresponding credit and / or currency to the other. It can occur by issuing to the equipment of). One mobile device 600 may provide, for example, an authenticated credit to another user. By using two "smart card" mobile devices 600, the user who provides "credit" and "smart card" can safely go through the transaction process. In this process, the user provides proper self-certification (eg password) and identifies a "public key" that identifies another "smart card" mobile device 2600. The other mobile device 2600 may use an acceptance process to provide proper self-certification for digital signatures (and credit and / or currency senders may also digitally sign transaction certificates, thereby sending them. The act is not denied and this certificate may be attached to credit and / or currency as VDE container content). Transactions may include, for example, user interface interactions that specify interest rates and / or other terms for transfers. A template for a normal transaction type may be used in which the credit provider is asked about certain parameters that describe the agreement between the parties. Receiving mobile device 2 600 can be asked repeatedly or as a whole about acceptance of conditions. The VDE negotiation technology described anywhere in this application may be used in the transfer of electronic credits and / or currencies to another VDE smart card or other VDE installation.

These VDE electronic 600 / mobile device 2600 credit transfer features significantly automate these processes by extending credit control and credit availability calculations initiated by credit cards and extended by debit cards. This can significantly reduce the indirect costs of managing certain electronic credits and / or monetary activities. Due to the automation of credit expansion and / or currency transfer, as well as the benefits of the relevant allocation process described above, as well as the lack of requirements for centralized processing and telecommunications during each transaction, many consumers and other electronic currencies and For / or credit users, credit and / or currency is actually an efficient, reliable and portable product.

In one embodiment, the portable device 2600 or other VDE electronics 600 can also automate many tax collection functions. The VDE Electronics 600, with high security, records financial transactions, identifies the nature of transactions, identifies required sales or related government transaction taxes, debits taxes from the credits available to users, and Ensure that this information is communicated directly to one or more government agencies at regular intervals (eg monthly) and / or transfer this information to, for example, a financial information exchange, with one or more information exchanges. One or more secure encrypted (or insecure, information exchange-calculated, or computer-calculated) information audit packets (eg, VDE content container and secure VDE communication technology used). Can be forwarded to the appropriate participating government agency. VDE With 100 overall integrity and security, electronic reporting of tax-related information (derived from one or more e-commercial activities) is valid and straightforward, assured by a consistent, centralized method. It can also serve as a source for checking the validity of information about transfers of sales tax collection (eg, tax-related information in which funds are transferred directly to the government by commercial manipulation and / or reported is tax information. Transferred in a way that cannot be tampered with by other parties in the VDE aisle dealing with. Government agents randomly select transactions or reported transactions for certain commercial operations. Some or all of the items may be selected. This can be used to ensure that all appropriate collection funds required for taxes are actually paid to the government by commercial operations, and also. It can also be certain that the final user is subject to appropriate taxes on transactions (including receiving interest from bank accounts, investments, gifts, etc.).

The financial and tax process of the Mobile Device 2600 may include the template mechanism described anywhere in this specification. While such electronic credit and / or currency management capabilities can be of particular interest if at least partially managed by using the mobile device 2600, credit and / or transit transfers and similar features are It is also applicable when the non-portable VDE electronic device 600 is connected to or installed inside a computer or other electronic device. User Notification Exclusion Interface ("Pop-up") 686 As mentioned above, User Modification Exception Interface) 686 can be a set of user interface programs that handle common VDE functions. These applications are in the form of VDE templates and are specifically designed based on certain key choices that are appropriate for certain VDE user models, and certain assumptions about important messages that must be reported certain events. .. The main function of the "pop-up" user interface 686 is to provide a simple and consistent user interface, for example, weighing events and exclusions (eg, conditions that cannot be automated or are arguably undesirable). Allows the user to configure certain aspects of the operation of his electronics 600, and, where appropriate, interactively controls whether the user goes through a certain trading process. Is to be able to do. If the object contains an exclusion method, this method controls how the "pop-up" user interface 686 handles exclusions for a particular class.

The "pop-user" interface 686 can typically handle tasks that cannot be assigned to a particular object 300, for example, as described below. -Log to electronics 600 and / or enter an activity or activity class related to VDE. Configure the electronics 600 for registered users and / or for installation in general, taking into account user preferences, and automatically handle certain types of exclusions. If appropriate, select an instrument for the user to use with specific characteristics. -Providing an interface for communication with other electronic devices 600, including requesting and / or purchasing or leasing content from distributors, requesting information exchange credits and / or budgets from information exchanges. To do, send information to and / or receive information from other electronic devices, etc.

Figure 72A shows an example of the functionality of a common logon VDE electronics 600 that may use user interface 686. "Logon" can be done by entering a username, account name and / or password. As shown in this example, the configuration option provided by the "Pop-up" user interface 686 dialog is "Login in Setup", which, if selected, powers or resets the user's electronics 600. The VDE login procedure is automatically started each time. Similarly, the "pop-up" user interface 686 may provide an interface option called "login by type". If selected, it will automatically open each time a certain type of object or application of a particular content type is opened, for example a file in a certain directory, a computer application or file with a certain self-certification extension. Start the procedure.

Figure 72B shows an example of a "pop-up" user interface 686 dialog that is launched when a user action is "trapped". In this case, the user is informed about the cost of the user's actions and is alerting the user about the requested object 300 and the cost of using this particular object. In this example, the interface dialog provides more detailed information about the object, including full text, a list of related files, and a history of past use of the object, including possibly the object or the remaining right to use the related discount. Buttons may be provided that allow the user to request.

The "CANCEL" button 2660 in Figure 72B cancels the user's trapped request. "CANCEL" is the default for this dialog in this example and can be invoked by, for example, the return and enter keys on the user's keyboard 612, "mouse clicks" on the buttons, voice commands, or other command mechanisms. The "APPROVE" button 2662 is a button that must be explicitly selected by mouse click or other command procedure, allowing the user to acknowledge the cost and move on. The "MORE OPTIONS" control 2664 extends the dialog to another level of detail that offers more options. An example of this is shown in Figure 72C.

FIG. 72C shows a secondary dialog presented to the user by the pop-up user interface 686 when the MORE OPTIONS button 2664 of FIG. 72B is selected by the user. As illustrated, this dialog contains many buttons for getting more information and performing various tasks.

In this particular example, the user is, for example, session dollar limit (field 2666), total transaction dollar limit (field 2668), time limit (minutes) (field 2670) and "unit limit" (paragraph, page, etc.). It is permissible to set "limits" such as "number of units" (field 2672). When the user completes the selection, "click" the OK button (2674) to confirm the restriction selection and enable them.

Therefore, pop-up user interface dialogs are used to identify user preferences, such as setting limits on budgets and / or other aspects of object content usage during a session, over a period of time, or for a period of time. Can be provided to. Dialogs can also be provided to select object-relational usage options such as selecting instruments and budgets to be used with one or more objects. The choice of options can be applied to objects of multiple types (ie, classes) by associating the instruction with one or more self-certifying parameters associated with one or more desired types. User-specific configuration information can be used to set default values that should be used in various situations, and to limit the frequency or type of situations in which a user's use of an object is interrupted by the "pop-up" interface 686 dialog. .. For example, a user may process the requested information if it does not exceed $ 25.00, if the total charge for the entire current session (and / or day, and / or week, etc.) does not exceed $ 200.00, and pending for the user. And if the sum of unpaid charges does not exceed $ 2500.00, it can be specified that the user's request for VDE protected content should be processed automatically without interruption (caused by exclusion).

Pop-up user interface dialogs can also be used to inform the user about significant conditions and events. For example, interface 686 can be used for: -Confirm with the user to send the audit information to the information exchange. -Inform the user that the budget is low and needs to be replenished. -Confirm with the user to back up the safety database 610. And · Notify users about the expiration of PERC or other date / time events.

Another important "pop-up" user interface 686 feature is properties that can be licensed or purchased from locally stored VDE protected objects and / or from one or more various remote content providers. Or include a dialog that gives you the flexibility to browse a library of objects. Such features can be selected when the user's computer is connected to a remote distributor or information exchange electronics 600, or by selection (property, resource location, or a class of object or resource, etc.) Can be provided by activating an electronic connection to a remote source after). The browsing interface allows this electronic connection to be made automatically when the user selects an item, or the connection itself can be explicitly activated by the user. See Figure 72D for an example of such a "browsing" dialog. Smart object VDE The 100 extends its control capabilities and features to "information agents." In general, an "information agent" acts as a messenger, allowing the process of dispatching this messenger to achieve the results identified by the first process. Information agents that can act in the absence of a dispatch process are particularly advantageous to allow the dispatch process to access the resources of remote electronics through the agent. In such a scenario, the dispatch process may create an agent (eg, computer program and / or control information related to the computer program) that identifies a particular desired task and dispatch this agent to a remote system. Upon reaching the remote system, the "agent" may use the resources of the remote system to perform the specified task. This allows the dispatch process to substantially extend its capabilities to remote systems where this process does not exist.

The use of "agents" in this way increases flexibility. The dispatch process can identify certain desired tasks through the agent that do not exist or are not available in the remote system. Moreover, the creditworthiness is further increased by using such an agent. The dispatch process only needs to "trust" the agent, not the entire remote system.

Software agents require a high level of control and accountability to be effective, safe and useful. Agents in the form of computer viruses have devastating effects around the world. Therefore, a system that allows an agent access should be able to control the agent or prevent it from damaging critical resources. In addition, the system that allows the agent to access should have a mechanism that can fully trust the agent and / or retain the true dispatcher of the agent responsible for the agent's activities. Similarly, the dispatch process should be able to adequately limit and / or control the authority of the dispatching agent. Otherwise, you should be responsible for the unexpected activity of the agent (for example, the agent will accumulate a huge amount of invoices due to the inaccurate orders subsequently given by the process of dispatching the agent. May).

These prominent problems with software agents have not been fully addressed in the past. The open and flexible control structures provided by VDE 100 address these issues by providing the desired control and accountability for software agents (eg, agent objects). For example, VDE 100 actively controls content access and use, provides payment guarantees for content used, and enforces budget limits for accessed content. These controls are well suited to control the activities of the dispatched agent by both the process of dispatching the agent and the resources accessed by the dispatched agent.

One aspect of this preferred embodiment provided by the present invention provides a "smart object" that includes an agent. In general, a "smart object" can be a VDE object 300 that contains some type of software program ("agent") for use with VDE control information in the VDE electronics 600. A basic "smart object" can include, for example, a VDE object 300 (physically and / or as virtual) that includes:

Software agent, and At least one rule and / or control related to the agent that governs the behavior of the software agent.

While this basic structure is sufficient to define a "smart object," Figure 73 provides an example of a particularly advantageous smart object structure for reliably managing and controlling the behavior of software agents, containers and controls. Shows the combination with information.

As shown in FIG. 73, the smart object 3000 is composed of a container 300, and one or more other containers (300z, 300y, etc.) are embedded in the container. Container 300 may further include rules and control information for accessing and using these embedded containers 300z, 300y, etc. The container 300z embedded in the container 300 makes the object 3000 a "smart object". This includes "agents" managed and controlled by VDE 100.

The rules and control information 806f related to container 300z governs the environment in which the agent can be released and executed at a remote VDE site, including, for example, execution limits based on execution costs. This rule and control information may be specified entirely within the container 300z and / or may be delivered as part of the container 300 or as part of another container (in the container 300 or as a separately serviceable container). And / or may already exist at a remote VDE site.

The second container 300y is optional and contains content that describes where the agent stored in the container 300z can run. Container 300y may also contain rules and control information 806e that describe the methods by which the contents of container 300y are used or modified. Yet another Rule 300y (1) contained within this rule and control information 806e and / or container 300y may describe a search and routing mechanism that can be used to direct the smart object 3000 to the desired remote information resource. Container 300y may contain and / or reference rules and control information 300y (1) that identifies methods that may pay for the use and modification of searches and routing.

Container 300x is an optional content container that is initially "empty" when the Smart Object 3000 is dispatched to a remote site. It contains rules and control information 300x (1) for storing content retrieved by the execution of the agent contained in container 300z. Container 300x also includes a limit on the value of the content stored in the search container, which limits the amount of content searched.

Other containers within Container 300 may include managed objects that include audit and billing tracking that describe the behavior of the Agent in Container 300z and the charges incurred to run the Agent on a remote VDE node. The exact structure of the Smart Object 3000 depends on the type of agent controlled, the resources required to run it, and the type of information retrieved.

The example smart object 3000 shown in Figure 73 can be used to control and manage the behavior of agents within the VDE 100. The following detailed description of the smart object trading example shown in FIG. 74 is helpful, but not limited to. In this special case, the user performs a library search using a "Very Fast and Efficient" software agent and is written about a subject of interest (eg "fire flies"). Suppose you are trying to create a smart object 3000 that searches for a book. The search method is designed to return the list of books to the user. The search method in this example uses no more than $ 10.00 to find a suitable book, no more than $ 3.00 for library access or communication charges to enter the library, and more than $ 15.00 for searching for information. Use no amount. All information related to the search or use is returned to the user and the user does not allow the information belonging to the user or agent to be released to a third party.

In this example, the dispatched VDE electronic device 3010 constitutes a smart object 3000 similar to the smart object shown in FIG. 73. The rule set of 806a is specified as a control set containing the following elements:

1. The smart_agent_execution event, which identifies that the smart agent is stored in an embedded container 300z and has rules that control the execution identified in this container. 2. The smart_agent_use event, which identifies the smart agent to operate with the information and parameters stored in container 300. 3. The routing_use event, which identifies that the information routing information is stored in container 300y and has rules to control this information stored in this container, and 4. Written information is stored in containers 300y, 300x or 300w depending on its type (routing, retrieval or management), and these containers have individual rules that control how the information is written. An information_write event that identifies.

The rule set of control set 806b contains rules that identify the rights desired by this smart object 3000. In particular, this control set specifies that the software agent desires:

1. Right to use the "Run Agent" service at a remote VDE site. Specific billing and pricing information for this right is held in container 300z.

2. Right to use the "Software List" service on remote VDE sites. Specific billing and pricing information for this is held in container 300y.

3. The right to use the "Information Locator Service" on a remote VDE site.

4. The right to return the information to the user free of charge (the fee for releasing the information, payment is made by the VISA budget).

5. The right to return all audit information in a readable form only by the sender.

The rule set of control set 806c specifies that container 300w specifies the handling of all events related to its use. The rule set of control set 806d specifies that container 300x specifies the handling of all events related to its use. The rule set of control set 806e specifies that container 300y specifies the handling of all events related to its use. The rule set of control set 806f specifies that container 300z specifies the handling of all events related to its use.

Container 300z has been identified as containing "very fast and efficient" agent content, which is relevant to the following set of rules.

1. A usage event that identifies the scale and VISA budget that limits execution to $ 10.00 charged to the owner's VISA card. Usage audit is required, which is stored in object 300w under the control information identified by this object.

After the container 300z and its set have been identified, they will be configured and embedded within the smart object container 300.

Container 300y is identified as a content object that has two types of content. Content type A is routing information, which is essentially read / written. Content type A pertains to a set of rules that identifies:

1. A usage event that does not specify any action for the release of content. This has the effect that there is no charge for the use of the content.

2. A write event that identifies the scale and VISA budget that limits the write value to $ 3.00. The billing method used by the write is left unspecified and can be specified by a control method that uses this rule.

3. Usage audit is required and can be stored in object 300w under the control information specific to this object.

Content type B is used by software agents to identify parameters for agents. This content is specified as the string "fire fly" or "fire flies". Content type B pertains to the following set of rules.

1. A usage event that identifies that usage is only performed by a software agent or routing agent. The software agent has read-only permissions, and the routing agent has read / write access to the information. There are no charges associated with the use of information, but two scales, one by reading and one by writing, are retained to track the use of information by various steps in the process.

2. Usage audit is required and can be stored in object 300w under the control information specific to this object.

After the container 300y and its control set have been identified, they will be configured and embedded within the smart object container 300.

Container 300x is identified as a content object whose content is empty. It contains a control set that includes the following rules:

1. A write_without_billing event that identifies the scale and general budget that limits the amount of writes to $ 15.00.

2. Usage audit is required and can be stored in object 300w under the control information specified in this object.

3. An empty usage control set that can be filled by the owner of the information using a given method (method option).

After the container 300x and its control set have been identified, they will be configured and embedded within the smart object container 300.

Container 300w is identified as an empty managed object by a control set that includes the following rules:

1. A usage event that identifies that the information contained in the managed object can only be released to the creator of the Smart Object Container 300.

2. No other rules can be attached to the managed content of container 300w.

After the container 300w and its control set have been identified, they will be configured and embedded within the smart object container 300.

At this point, the smart object configuration is complete and ready to be dispatched to a remote VDE site. Smart objects are sent via passage 3014 (eg, using email or other transmission mechanisms) to a remote VDE site that includes the information locator service 3012. The smart object is registered at the remote site 3012 for the "item locator service". A control set of containers related to the "Item Locator Service" is selected and the rules contained therein are launched at remote site 3012. The remote site 3012 then reads the contents of container 300y under the control of rule sets 806f and 300y (1) and allows the local information list to be written to container 300y according to these rules. The item locator service writes a three-item list to the smart object, then "re-registers" the smart object (which contains location information at this point) and writes it to the smart object via aisle 3018. Send to site 3016 identified in the list. In this example, the user may have a particular email for transmission, and a list of remote sites that may have the desired information is stored as a forwarding list.

Upon arriving at the second remote site 3016, the Smart Object 3000 is registered with this second site. Site 3016 provides VDE-compatible agent execution and software description listing services as a service to smart objects. The site publishes these services and identifies that it costs $ 10.00 to start an agent and $ 20 per unit to return all information. The registration process compares the published service information with the rules stored within the object and determines that there are no unacceptable duplicates. Audit information for all of these activities is written to the managed object 300w. The registration process fails (the object is not registered) and the smart object is transferred by site 3016 to the next VDE site 3020 in the list via aisle 3022.

Upon arriving at the third remote site 3020, the Smart Object 3000 will be registered on this site. Site 3020 provides VDE-compatible agent execution and software description listing services as a service to smart objects. The site publishes these services and identifies that it costs $ 1.00 to start the agent and $ 0.50 per unit to return all the information. The registration process compares the published service information with the rules stored within the object and determines that there are acceptable duplicates. The registration process creates a URT that identifies the agreed control information. This URT is used in combination with other control information to run the software agent under VDE control.

The agent software starts and reads its parameters from the container 300y. Then it starts searching the database and gets 253 "hits" in the database. A hit list is written to the container 300x, along with a complete control set that identifies the granularity of each item and the price of each item is $ 0.50. When the search is complete, the budget for using the service will increase by $ 1.00, reflecting the usage fee for this service. Audit information for all of these activities is written to managed object 300w.

The remote site 3020 returns the "full" smart object 3000 to its original source (user) at VDE node 3010 via aisle 3024. The smart object 3000 is registered and database recording becomes available. The control information identified in container 300x is, at this point, a mixture of the initial control information and the control information identified by the service for remote release of this information. The user then extracts 20 records from the Smart Object 3000, and $ 10.00 is charged to the VISA budget at the time of extraction.

The Smart Agent VDE example above described the Smart Object 3000 and certain organizations of the containers that make it up. Organizations of other VDE and smart object related control information and parameter data can also be created and used for the same purposes as attributed to object 3000 in the example above. Negotiations and electronic contracts An electronic contract is an electronic form of a contract that includes the rights, restrictions and obligations of the party making the contract. In many cases, an electronic contract can surround the use of digitally provided content, such as a permit to watch a digitally distributed movie. However, electronic contracts do not have to be conditioned on the existence or use of electronic content by one or more parties to the contract. In this simplest form, electronic contracts include rights and controls governing how these rights are exercised.

Electronic contracts, like traditional contracts, can be negotiated between parties (conditions submitted by one or more parties are simply accepted by one or more other parties (coherent contract), and / or this. Other parties may have the right to choose some of these conditions (other conditions are mandatory). Negotiation is defined in the dictionary as "the act of reconciling with mutual consent." This preferred embodiment provides an electronic negotiation process in which one or more rights and related controls can be established through electronic negotiation of automated conditions. Negotiation usually requires the exact identification of rights and the controls associated with these rights. PERC and URT structures provide an accurate electronic representation of rights and mechanisms that can be used to provide controls related to these rights. Therefore, VDE provides a "vocabulary" and mechanism that allows users and authors to identify their wishes. The automated process interprets these desires and negotiates to reach a common waypoint based on these desires. The results of this negotiation are briefly described in the structure, which can be used to control and implement the results of electronic contracts. VDE makes this process even more possible by providing a secure execution space that ensures that the negotiation process is complete and confidential in its operation. The negotiation process can also be performed in methods that prevent the negotiation from being tampered with externally.

In general, the ultimate desired feature of contracts (and especially electronic representations of contracts) is that contracts are accurately recorded in a non-performance form. Traditionally, this involves creating a written document (contract) stating the rights, restrictions and obligations of all parties involved. This document is read and signed by all parties as an exact representation of the contract. Electronic contracts, by their very nature, are not initially submitted in writing. VDE allows such contracts to be accurately written electronically and then electronically signed to prevent default. Further, in this preferred embodiment, a mechanism is provided that allows the terms of the electronic contract to be described in a human readable manner.

VDE provides a concise mechanism for identifying a control set that a VDE site can interpret. Machine-interpretable mechanisms are often not human-readable. VDEs often operate the negotiation process on behalf of at least one human user. Therefore, it is desirable that the negotiation be expressed in a "human readable form". All VDE data structures for objects, methods and load modules have provisions that identify one or more DTDs within those structures. These DTDs can be stored as part of the item or can be stored independently. The DTD describes one or more data elements (MDE, UDE or other related data elements) that may contain a natural language description of the function of this item. These natural language descriptions provide a language-independent, human-readable description for each item. A collection of items (eg, the BUDGET method) can be associated with natural language text that describes its function and forms the terms of an electronically identified and enforceable contract. A collection of conditions (control set) defines a contract related to a particular right. Therefore, VDE enables the electronic identification, negotiation and implementation of electronic contracts that humans can understand and comply with.

VDE 100 enables the negotiation and implementation of electronic contracts as described below. Allows concise identification of rights and control information that allows common vocabulary and procedures for negotiation. -Provide a safe processing environment for negotiation. -Provide an allocation environment in which the specification of rights and controls can be reliably allocated. Provides a secure processing environment in which negotiated contracts are electronically received and signed by the process of negotiating contracts. -Provide a mechanism to ensure the implementation of negotiated electronic contracts. Negotiation type One simple form of negotiation is to request that one party form a "coherent" contract. There are few, if any, options that can be selected by the other party in the negotiation. There is only one option on the receiving side of the request. That is, whether to accept or reject the condition (control information) in the request. If you accept the condition, you are entitled to the conditional right of specified control information. If you reject the condition, you are not entitled. The PERC and URT structures can support on-demand negotiations. That is, a PERC or a set of controls from PERC is presented as a request, and the recipient can accept or reject the request (select from now if permitted method options are presented).

A common example of this type of negotiation today is the purchase of software under the condition of a "shrink packaging license". Many widely available electronic distribution methods use this type of negotiation. CompuServe is an example of an online service that operates with the same method. The choice is easy. That is, they either pay a specific fee or do not use the service or software. VDE's ability to provide PERCs and URTs that describe rights and control information, and allows content owners to provide REGISTER methods that allow users to choose from a given set of method options. By supporting this type of negotiation. In this scenario, the REGISTER method can contain components that are a simple negotiation process.

A more complex form of negotiation is similar to "haggling." In this scenario, most of the terms are fixed, but one or more terms (eg price or payment terms) are not. There are elements that have options, restrictions, and room for negotiation for these conditions. VDE electronic negotiation between the two parties can be used to determine the desired, permitted, and selectable conditions. The result of electronic negotiation can be the final set of rules and control information that identifies the completed electronic contract. One simple example is a buyer paying method (VISA, MasterCard or American). This is a scenario of purchasing the above software with the ability to select Express). A more complex example is a purchase information scenario where the price paid depends on the amount of information about the user being returned along the usage audit tracking. In this second example, the right to use the content may relate to two control sets. One control set may describe a fixed (higher) price for the use of content. Another control set may describe a fixed (lower) price for the use of content with field specifications that require the addition of control information and the collection and return of user's personal information. In both of these cases, PERC's selectable and allowed fields and control sets may describe options that can be selected as part of the negotiation. To negotiate, one party proposes a control set containing specific fields, control information and restrictions identified by PERC. The other party either takes it out of the proposed control set and accepts it, rejects them, or proposes an alternative control set that can be used. The negotiation process may use PERC's allowed, required, and selectable specifications to determine the acceptable parameter area for the final rule set. Upon reaching consent, the negotiation process may create a new PERC and / or URT that describes the outcome of the negotiation. The resulting PERC and / or URT can be "signed" (eg, using a digital signature) by all of the negotiation processes involved in the negotiation to prevent default of the contract at a later date.

Still other examples of negotiated elements are electronic cash, purchase orders, purchase certificates (gift certificates, coupons), bids and specifications, budget "rollbacks" and mediation, currency exchange rates, stock purchases. , And there is a billing rate.

The PERC sets used to support the second example above are shown in Figure 75A (PERC sent by the content owner), Figure 75B (PERC created by the user to present the user's choices and rights), and. Figure 75C (PERC for controlling the negotiation process) shows.

These PERCs can be used with any of the negotiation processes and protocols described below in this section.

Figure 75A shows an example of a PERC 3100 that could be created by a content provider to describe their rights options. In this example, PERC contains information about one USE right. Two alternative control sets 3102a, 3102b are presented for the rights in this example. Control set 3102a permits the use of content without returning information about the user, and another control set 3102b permits the use of content and collects "response card" type information from the user. Both control sets 3102a and 3102b can use a common method set for most of the control information. This common control information is represented by CSR 3104 and CSO 3106.

This PERC 3100 control set 3102a demonstrates a mechanism by which a user can use content without providing the content provider with information about the user. This control set 3102a identifies well-known sales control methods as well as required methods and method option sets. Specifically, in this example, control set 3102a defines a BUDGET method 3108 (eg VISA, MasterCard or American Express) and a BILLING method 3110 (eg $ 100.00 per charge) that specifies the charge.

This PERC 3100 control set 3102b presents another mechanism by which the user obtains content. In this example, control set 3102b identifies different sales control methods as well as required methods and method option sets. This second control set 3102b identifies the BUDGET method 3116 (eg VISA, MasterCard or American Express), the pricing method 3110 (eg $ 25.00 for a lower one-time fee), and the desired and required field set. AUDIT method 3114 is specified. The required and desired field specification 3116 can take the form of a DTD specification. Here, for example, the field names are listed.

The content creator "prioritizes" one of the two control sets (eg, control set 2) over the other. In this case, the negotiation process first "suggests" a "priority" control set, and if the other party in the negotiation "rejects" this "priority" control set, it is withdrawn and "non-priority". Can be replaced with the control set of.

In this example, these two control sets 3102a, 3102b may share a common BUDGET method specification. The BUDGET method specification can be included in the CSR 3104 or CSO 3106 control set if desired. Selecting control set 3102a (used without returning information) assembles a unique component assembly as identified by PERC 3100. Specifically, in this example, the "sale" CONTROL method 3118, the $ 100 fixed-price BILLING method 3110, and the rest of the control information specified by CSR 3104 and CSO 3106 are selected. The user also needs to identify an acceptable BUDGET method selection (eg from VISA, MasterCard and American Express). By selecting control set 3102b, "sell by response card" CONTROL method 3120, BILLING method 3116 (eg $ 25 fixed charge), and required field DTD Different component assemblies are assembled using the AUDIT method 3114 that requires the fields listed in 3116. The process may also select all available fields from the fields listed in the desired field DTD3116. The rest of the control information is identified by CSR 3104 and CSO 3106. When selecting control set 3102b, the user must also identify an acceptable BUDGET method selection (eg, from a list that includes VISA, MasterCard, and American Express).

Figure 75B shows an example of a control set 3125 that can be used by a user to identify a user's wishes and requirements in the negotiation process. This control set has a USE rights section 3127 that includes the aggregated CSR budget specification 3129 and two control sets 3131a, 3131b for use of the content. Control set 3131a requires the use of specific CONTROL method 3133 and AUDIT method 3135. The identified AUDIT method 3135 is parameterized by a list of fields 3137 that can be released in audit tracking. Control set 3131a may also identify BILLING method 3139, which may cost no more than a certain amount (eg $ 30.00). The control set 3131b in this example describes a particular CONTROL method 3141 and, if this option is selected, may refer to the BILLING method 3143, which may cost no more than a certain amount (eg $ 150.00).

Figure 75E shows a higher level diagram of the electronic contract 3200 formed as a "result" of the negotiation process described above. The electronic contract 3200 may include a number of clauses 3202 and a number of digital signatures 3204. Each clause 3202 may include PERC / URT such as item 3160 described above and shown in Figure 75D. Thus, each "clause" 3202 of electronic contract 3200 corresponds to component assembly 690 that can be assembled and executed by VDE electronics 600. Like a regular contract, the electronic contract 3200 may have as many contract clauses 3202 as necessary to embody "agreement" between "party". Each of Clause 3202 is electronically negotiated and may therefore embody some of the "agreement" (eg, "eclectic") between the parties. The electronic contract 3200 is "self-executive" in the sense that it can be literally executed by the machine, the VDE electronics 600 assembling the component assembly 690 as specified by the various electronic clauses 3202. The electronic contract 3200 is automatically "implemented" using the same VDE mechanism described above used with the component assembly 690. For example, assuming that clause 3202 (2) corresponds to a payment or BILLING condition, its corresponding component assembly 690 will automatically determine if the payment condition is correct when assembled by the user's VDE electronics 600. , When correct, automatically access the appropriate payment mechanism (eg, a virtual "credit card" object for the user) and adjust for that payment to be made. As another example, assuming that electronic contract clause N3202 (N) addresses the user's obligation to provide audit information to a particular VDE participant, by electronic contract 3200, the VDE electronic device 600, for example, the safety database 610. Assemble the corresponding component assembly 690 that can access the appropriate audit tracking within and provide audit tracking within the managed object to the correct participants. Figure 75F shows Clause 3 202 (N) indicates that, for example, the component assembly 690 that adjusts the transaction 3206 to have multiple steps can be identified. Some of these steps (eg, steps 3208 (4), 3208 (5)) reach, for example, whether content usage exceeds a certain amount, whether a certain period of time has passed, or a certain calendar day. It can be conditional in tests such as whether it has been done (eg 3208 (3)).

The digital signature 3204 shown in the electronic contract of FIG. 75E may include, for example, a conventional digital signature using public key technology as described above. Some electronic contracts 3200 do not include the digital signature 3204. However, it requires the user's electronics 600, which is the party of the electronic contract 3200, to digitally sign the electronic contract so that the user cannot later refuse to fulfill the contract for evidence purposes. It is desirable to do. If there are multiple parties in the same contract, each digitally "signs" the same electronic contract 3200, much like many parties in a contract recorded in a written document sign the document with an ink pen. obtain.

Each of Clause 3202 of Electronic Contract 3200 will ultimately be PPE It may correspond to a collection of data and code that can be executed by the 650, but in some cases it may be necessary to provide a human-readable version of the electronic contract. This need can be achieved by providing the text within one or more DTDs associated with the component assembly 690 used to "self-execute" the contract, as described above. Such texts describe, for example, what the corresponding electronic contract clause 3202 means or embraces from a functional point of view, and / or represent what or what the legal obligations under the contract are. Can be described in legally feasible terms. A "template" (described somewhere herein) can be used to supply such text from a text library. Expert systems and / or artificial brain capabilities can be used to establish syntax rules that combine different text elements into a coherent, human-readable contract document. Such texts, if necessary, reviewed and modified by "human" agents, customized for specific contracts between parties, and / or embodied internally, VDE electronics. Additional legal obligations can be added by increasing the "self-execution" electronic obligations enforced by the relevant component assembly 690 performing in 600. Such text may be displayed automatically by the execution of the electronic contract or upon request, or may be used at any time to produce a printed, human-readable version of the contract. Such a document version of the Electronic Contract 3200 does not need to be inked by the contracting party (if not desired). This is because the Digital Signature 3204 provides a sufficiently secure and credible basis for providing mutual consent of the parties to all terms of the contract.

In this preferred embodiment, the negotiation process is performed within the PPE 650 under the direction of another PERC that identifies the process. Figure 75C shows an example of PERC 3150 identifying the negotiation process. PERC The 3150 has a single right 3152 for negotiation and two authorized control sets 3154a, 3154b for this right. The first control set 3154a can be used for "trusted negotiation". That is, it shows the desired negotiation CONTROL method (negotiation) as a reference, and the two UDEs used by this CONTROL method (in fields 3157a, 3157b) as a reference. These UDEs can be, for example, PERC3100, 3125 shown in FIGS. 75A and 75B. A second control set, 3154b, can be used by a "multi-negotiation" process to manage negotiations and can provide two negotiation methods, "negotiation 1" and "negotiation 2." Both negotiation processes can be described as the required methods (Negotiation 1 and Negotiation 2) 3156, 3158 with PERC3100, 3125 as inputs, respectively. The CONTROL method 3158 for this control set in this example can identify the name of the service used by the two negotiation processes to communicate with each other and can manage the creation of the URT resulting from the negotiation.

When the negotiation process identified by PERC3150 shown in Figure 75C is performed, it may be deployed with PERC3100, 3125 as inputs that can be used as the basis for negotiation. In this example, the selection of the type of negotiation process (trusted negotiation or multi-negotiation) can be made by running the VDE node. The PERC 3150 shown in FIG. 75C can be created, for example, by the RESISTER method in response to a registration request from the user. The process identified by this PERC3150 is then used by the RESISTER method, which can initiate negotiation of the terms of the electronic contract.

During the negotiation process of this example, the PERCs 3100, 3125 shown in Figures 75A and 75B serve as input data structures compared by the component assemblies created based on the PERC 3150 shown in Figure 75C. The component assemblies identified by the control set are assembled and compared as the negotiation progresses, starting with the required "conditions", proceeding to the preferred / desired "conditions", and then the allowed "conditions". Move to. Method option selection is made using the desired methods and method options specified in PERC 3100, 3125. In this example, the control set for the PERC 3100 shown in Figure 75A can be compared to the PERC 3125 shown in Figure 75B. A "match" completes the negotiation successfully and produces a "result".

In this embodiment, the result of such negotiation is usually written as URT and can be "signed" by the negotiation process to indicate that consent has been reached. These digital signatures provide a means of indicating that a (virtual) "meeting of minds" has been reached (one of the traditional legal preconditions for a contract to exist). An example of URT 3160 that should have been created by the above example is shown in Figure 75D. This URT 3160 (which itself can be a PERC 808) contains a control set 3162 that reflects the "agreement" and "conditions" in the negotiation. In this example, the "agreeed" condition is the condition required by the entered PERC 3100, 3125 in the sense that it must be "as favorable" as the condition required by these PERCs. Must "match". The negotiation results shown are, in a sense, the PERC of Figure 75A, for example. Includes "negotiated" control set 3162, which corresponds to control set 3102a in 3100 and control set 3131a in Figure 75B. Thus, the resulting "negotiated" control set 3162 contains the required AUDIT method 3166, which corresponds to the desired BUDGET method 3142 of control set 3125, but the BUDGET required by control set 3100. Contains the required BUDGET method 3164 that is "within" the control set range allowed by method 3112. Similarly, the resulting negotiated control set 3162 contains the required AUDIT method 3166, which requires both the AUDIT method 3114 required by the PERC 3100 and the AUDIT method 3135 required by the PERC 3125. Follow. Similarly, the resulting negotiated control set 3162 contains the required BILLING method 3170, which method is PERC. "Match" or follow each of the BILLING method 3116 required by the 3100 and the BILLING method 3170 required by the PERC3125.

Another class of negotiation is that the rules are not fixed and only the desired goals are specified. The negotiation process for this type of negotiation can be very complex. It may utilize artificial brains, fuzzy logic, and / or related algorithms to reach goals. VDE supports these types of processes by providing a mechanism for concisely identifying rights, control information, fields and goals (in the form of desired rights, control information and fields). Goals for these types of processes can be identified as one or more sets of controls that include an optional, permitted, or desired element named specific element. Negotiation type The negotiation in this preferred embodiment can be constructed by any of the following:

1. Shared knowledge 2. Trusted negotiator 3. "Zero-based" knowledge Shared knowledge negotiations are based on the knowledge of all parties and regulations related to the negotiations. Negotiation by request is a simple example of negotiation by shared knowledge. The requester presents a list of requests that are collectively accepted or rejected. The request list contains the complete set of knowledge needed to accept or reject each item in the list. VDE encodes and reliably passes requests, and by providing a mechanism that can be reliably processed between and by secure VDE subsystems that use VDE-safe processing and communication capabilities, this class of negotiation is electronic. Allows it to be done. Another type of shared knowledge negotiation used by VDE involves exchanging information between two or more negotiation parties. That is, the negotiation process individually determines the desired final spending based on the individual properties. The process can then negotiate any differences between them. Shared knowledge negotiations may require only one negotiation process (as in request-type negotiations) or may involve more than one collaborative process. Figures 76A and 76B show scenarios where two negotiation processes are used for shared knowledge negotiation.

Figure 76A shows a single negotiation process 3172 that takes any number of PERC 808s (supplied by different parties, for example) as input to the negotiation. The negotiation process 3172 runs on the VDE node under the supervision of "negotiation process rules and control information" that may be supplied by another PERC (eg PERC 3150 shown in Figure 75C). Process 3172 produces one or more PERC / URT 3160 as a result of negotiation.

Figure 76B shows a number of negotiations, each taking a PERC 808 from one party and another PERC 3150 controlling the negotiation process, and each producing a negotiated "result" PERC / URT 3160 as output. The processes 3172A to 3172N are shown. Processes 3172A-3172N can run in the same or different VDEs and can communicate using a "negotiation protocol".

Single and multiple negotiation processes can be used for a particular VDE site. The negotiation process has a name and can be accessed using well-known method names. PERC and URT can be transmitted to a remote VDE site in a managed or smart object for processing at the site, like the control PERC and REGISTER methods that control negotiation.

Multi-negotiation processes require the ability to communicate between these processes 3172, including secure communication between secure processes (safety subsystems) that reside at physically distant VDE sites. VDE generalizes interprocess communication to a reliably provided service that can be used if required by the configuration. Interprocess communication uses a negotiation protocol to exchange information about rule sets between processes 3172. One example of a negotiation protocol includes the following negotiation "primitive function".

WANT condition set desired Accept the ACCEPT condition set Reject the REJECT condition set Propose another condition set instead of the OFFER condition set Claim that the HAVE condition set is possible or desirable QUIT Insist on termination of negotiation without reaching consent End AGREEMENT negotiation and pass rule set for signature The WANT primitive function retrieves information about rights and the control set (or part of the control set) and claims to other process 3172 that certain conditions are desired or required. Request negotiation is a simple example of the WANT primitive function used to assert a request. The protocol in this example can introduce REQUIRE, a sophisticated form of the WANT primitive function. In this example, REQUIRE allows a party to set the conditions that it determines are necessary to form a contract. WANT, on the other hand, allows parties to set desired but non-essential conditions. Thereby, "must have" and "want to have" can be classified.

In this example, the WANT primitive function must always be returned by an ACCEPT, REJECT or OFFER primitive function. The ACCEPT primitive function allows the negotiation process 3172 to accept the condition set. The REJECT primitive function allows process 3172 to reject the proposed condition set. Negotiation ends when the required set of conditions is rejected. OFFER allows the submission of counter-proposals.

The HAVE, QUIT and AGREEMENT primitive functions allow the negotiation protocol to pass information about the rule set. Negotiation by shared knowledge is initiated, for example, by insisting that all negotiation processes 3172A-3172N HAVE (my PERC) to other processes. HAVE is also used in the event of a stalemate, and one process 3172 needs to be informed about the options allowed to the other process 3172. QUIT indicates that the negotiation ends unsuccessfully without reaching consent. AGREEMENT indicates that the consent was successful and passes the resulting "negotiated" PERC / URT 3160 to another process 3172 for signature.

In a "trusted negotiator" negotiation, all parties agree to provide their requests and preferences to the "trusted" negotiator and be bound by the negotiator's decisions. This is similar to binding arbitration in today's society. VDE enables this negotiation mode by providing an environment in which "trusted" negotiation services can be formed. VDE ensures that PERC is a "trusted" negotiation service with a set of rules that specify how negotiation is done, as well as a mechanism that allows the request, desire and limitation to be concisely identified (eg to PERC). Provides a transfer mechanism. This negotiation mode is also made possible by providing a secure execution environment to prevent the negotiation process from being tampered with. Reliable negotiator services can be used on VDE sites where the integrity of the site is well known. A trusted remote negotiation service can be used by a VDE site that does not have sufficient computational resources to run one or more negotiation processes. That is, it is possible to establish a communication link to a VDE site that provides this service and allows this service to handle negotiations on its behalf.

Negotiating with "zero-based" knowledge shares some features of the zero-based knowledge protocol used for authentication. Methods for constructing protocols that can determine whether a remote site is the holder of a particular item, whether or not the item is exchanged or exposed, are well understood in the art. This type of protocol can be built between two negotiation processes running at least one VDE site that uses the control set as its knowledge base. The negotiation process can exchange information about their control sets and make requests and alternatives for using their individual rule sets. For example, negotiation process A negotiates the right to read a book communicating with negotiation process B. Negotiating Process A specifies that it is preferable to pay no more than $ 10.00 for the right to read a book and between $ 5.00 and $ 6.00 for this right. Process A's rule set also specifies that the $ 5.00 option allows the release of the reader's name and address. Process B's rule set specifies that it wants to pay $ 50.00 for its right to read the book and will offer the book for $ 5.50 if the user agrees to release information about himself. Negotiation can proceed as follows.

Process A &lt;-&gt; Process B WANT (right to read, unlimited)-&gt; &lt;-HAVE (reading rights, unlimited, $ 50) OFFER (right to read, provide user information)-&gt; &lt;-HAVE (reading right, user information Offer, $ 5.50) ACCEPT (right to read, user information Offer, $ 5.50)-&gt; In the above example, Process A specifies that it desires the right to read a book without restriction or other information release. This starting position is specified as a PERC rights option that Process A uses as a rule. Process B checks this rule and determines that unrestricted reading rights are actually granted at a price of $ 50. Process B replies to Process A that this condition is available. Process A receives this response and checks it against the control set in PERC that Process A uses as the rule base. Process A cannot accept this proposal because $ 50 falls outside the $ 10 limit specified for this rule set. Process A creates a counter-proposal that combines unrestricted reading rights with the release of the reader's name and address (as described in another selectable rights option). The name and address fields are described in the DTD referenced by the PERC of Process A. Process B checks its rules of PERC and determines that an unrestricted read right in combination with the release of personal information is an authorized option. Process B compares the field to be released described in the DTD provided by Process A with the desired field in the PERC DTD of the situation and determines that there was an acceptable match. Process B then sends to Process A a proposal to grant unrestricted rights with the release of specific information for $ 5.50. Process A compares the rights, constraints and fields to the rule set and determines that $ 5.50 is in the range of $ 5 to $ 6 stated to be acceptable to the rule set. Process A accepts this proposal as is. The proposal will be sealed by both parties by "signing" a new PERC that describes the outcome of the final negotiation (unrestricted rights, release of user information, $ 5.50). The new PERC may be used by the owner of Process A to read the Content (Book) subject according to the conditions described. Another handling model chain As mentioned in connection with Figure 2, one example of a VDE handling and control chain used, for example, for content distribution, is the four "participant" cases of VDE 100. The first of these participant cases is Content Creator 102, which is manipulated by publishers, writers, rights owners, or copyright distributors who prepare information for distribution to consumers. The second participant case is VDE Rights Distributor 106, who can distribute rights and manage and analyze consumer use of VDE approval information. The third participant case is the content user 112, which is manipulated by the user (including the end user and the distributor) when the user uses the information. The fourth participant case is the Financial Information Exchange 116, which enables VDE-related information exchange activities. Yet another participant, the VDE administrator, may provide support to keep the VDE 100 working properly. With proper approval and installation of the Rights Operating System components, any VDE electronics 600 can play any or all of these participant roles.

Copyright is one example of a raw material for VDE 100. To convert this raw material into a final product, publishers, writers or rights holders can convert digital information (such as ebooks, databases, computer software and movies) into protected digital packages called "objects". To use. Only consumers (or others along the owning chain, such as redistributors) who have permission from Distributor 106 can open these packages. VDE packaged content is provided by content creator 102 and / or content distributor 106, or other VDE participants in the content distribution aisle, ie, usually not restricted participants, but in VDE safety packages. It can be bound by "rules and control information" provided by participants "closer" to the creation.

Once the content is packaged in "objects", the digital distribution process can begin. Since the information package itself is protected, it can be freely distributed on CD-ROM discs or over computer networks, or broadcast over cables or over broadcast waves. Informal "off-channel" exchanges between end users of protected packages are not dangerous to content ownership. This is because only authorized individuals can use these packages. In practice, such "off-channel" distribution is encouraged by some content providers as a marginal cost method of market penetration. Consumers who are approved for use (eg, Visa Information Exchange Prepaid Allowing a Certain Dollar Usage) are free to license an off-channel VDE protection package provided by their neighbors, for example.

The end user must have permission to open the VDE package and use its contents. Distributor 106 can grant such permissions, and is very flexible (if permitted by higher control information) to limit or otherwise identify methods that use the package content. Can be done. Distributors 106 and financial information exchange 116 also typically have financial responsibilities (these can be the same organization under certain circumstances, if desired). These ensure that the required payments from the end user meet the requirements of their own and other participants. This is achieved through the use of auditing.

Distributors 106 using VDE 100 may include software publishers, database publishers, cable, television and radio broadcasters, and information distributors in other electronic forms. The VDE 100 supports all forms of electronic distribution, including distribution by broadcast or telecommunications, or by physical transfer of electronic storage media. It also supports the delivery of content in a homogeneous form that seamlessly integrates information from multiple distribution types through permissions, control mechanisms and separate delivery of content.

Distributors 106 and financial information exchanges 116 can themselves be audited on the basis of secure records of their management activities, and a reliable "trusted" process chain ensures the integrity of the entire digital distribution process. It will be certain. This allows content owners to verify, for example, that they are receiving appropriate compensation based on actual content use or other agreed upon basis.

Since the end user 112 is the end consumer of the content in this example, the VDE 100 is designed to provide protected content in an uninterrupted and transparent method as long as the end user is within the permissions limits received. Has been done. The activity of the end user 112 can be weighed so that it can be audited by the distributor 106. The audit process can be filtered and / or generalized to satisfy user privacy concerns. For example, weighed and recorded VDE content and / or device usage information is filtered prior to reporting to Distributor 106, which does not expose unnecessary information about Content User 112 and / or its use. Can be done.

VDE 100 empowers content providers to recreate key aspects of their traditional distribution strategies in electronic form and innovatively build new distribution mechanisms that are relevant to their individual needs and environment. .. VDE 100 supports relevant participants in the distribution chain and enables desired pricing strategies, access and redistribution permissions, usage rules, and related management and analysis procedures. VDE 100's reusable functional primitive functions can be flexibly combined by content providers to reflect their distribution objectives. As a result, content providers can supply information through established distribution channels and create their own personalized distribution channels.

The table below outlines the roles of the various participants in Virtual Distribution Environment 100.

<tables num="27"><img file="JP4995980B2_D0027.tif" /></tables>

Among these various VDE participants, "redistributors," "VDE administrators," "independent audit processors," and "agents" are, in some respects, supported by many "traditional" business models. A "new" participant with nothing to do. For other VDE participants (ie content providers, content owners, distributors, auditors, information exchanges, network providers and financial providers), traditional distribution models are often within the virtual distribution environment 100. It has a counterpart to the "traditional" business model in the sense that it involves non-electronic participants who perform some of the same business roles that they perform.

The VDE Distributor 106 may also include a "last user" who provides electronic information to other end users. For example, FIG. 77 shows another example of the handling and control chain of the virtual distribution environment 100 provided by the present invention. Compared to Figure 2, Figure 77 includes a new Client Administrator participant 700. In addition, FIG. 77 shows several different content users 112 (1), 112 (2), ..., 112 (n), all of which may depend on the "jurisdiction" of the client administrator 700. Client Administrator 700 is, for example, a company that relies on organization-specific "rules and control information" to distribute rights to employers or other organization participant units (such as departments, departments, networks and / or groups). Or it could be another rights distributor within another organization. The client administrator 700 may form rules and control information for distribution depending on the "rules and controls" specified by author 102 and / or distributor 106.

As mentioned above, VDE Administrator 116b is a trusted VDE node that supports VDE 100 and keeps it working properly. In this example, VDE administrator 116b may provide, among other things, any or all of the following:

VDE device initialization service VDE device reinitialization / update service Key management service "Hot list" of "Rogue" VDE site Certificate approval service Public key registration · Client Participant Unit Content Budget and Other Approval All VDE 100 participants have the intrinsic ability to participate in any role. For example, a user can collect current protected packages, add their own packages (create new content), and create new products. Users may choose to act as their distributor or transfer this responsibility to others. These capabilities are especially important in the object-oriented paradigm that is entering the market today. The creation of composite objects, the joining and embedding of objects, and other multi-source processes have created a need for these capabilities of VDE. VDE The distribution process provided by 100 is symmetric. The end user may redistribute the received information to other end users if they obtain permission from and follow the rules established by the distribution chain VDE control information that controls the redistribution. Also, the end user may put content owned by others into a newly published work and distribute these works individually, within the same rules and permission constraints. Royalty payments for new works can be accessed, tracked and electronically collected at any stage of the chain by the publisher, distributor or end user.

Independent financial providers can play an important role in VDE 100. The role of VDE lenders is similar to the role played by organizations such as VISA in traditional distribution scenarios. In any distribution model, it is important to approve payments for the use of goods or services and to audit the consistency and irregularity of use. VDE At 100, these are roles fulfilled by independent financial providers. Independent financial providers may also provide audit services to content providers. Therefore, budgets or restrictions on use and records of audits or use may be processed by Information Exchange 116 (and may be placed in place by Information Exchange). The information exchange can then collect usage payments from user 112. Any VDE user 112 may be entitled to process information or perform services on its behalf to the extent permitted by superior control information. Arrangements in which one VDE participant works on behalf of another VDE participant are called "proxy". Auditing, distribution and other important rights may be "represented" if authorized by the content provider. One special type of "surrogate" is the VDE administrator 116b. The VDE administrator is an organization (which can also act as a financial information exchange 116) with permission to manage (eg, "intervene" and reset) some or all of the VDE secure subsystem control information for VDE electronics. Is. This control can only be extended to allow new equipment in the VDE substructure, to repair otherwise inoperable equipment that has been "crushed", and to update the VDE on a regular basis. Further description of object creation, distribution methods, budgets, and audits The VDE node electronic device 600 in a preferred embodiment may have the ability to perform object creation, distribution, audit collection and use control functions according to the present invention. Incorporating this range of capabilities into each of the many electronic devices 600 provided by the preferred embodiments constitutes a secure, reliable, virtual trading / distribution management environment for installation integration, electronic trading. It is important for the general goal of creating a single (or outstanding) standard for weighing, control, and billing. Generally speaking, at least in the general purpose VDE node electronics 600, given that certain key features generally or frequently disappear, various differences are made to satisfy a wide range of applications for electronic trading / distribution management. Products and different standards come out. There is no need to implement a single consistent set of tools and a single "reasonable" reliable security and commercial distribution environment to respond to the urgent need of evolving "electronic highways". Certain forms of certain electronic devices 600, including VDE nodes incorporating embedded dedicated VDE microcontrollers, such as certain forms of video cassette players and cable TV converters, do not necessarily have full VDE capability. It may or may not be needed. However, a preferred embodiment provides many distributed and discretely located electronic devices 600. Each of the electronic devices 600 should have writing ability, distribution, extraction, auditing, and audit reduction ability in addition to object writing ability.

The VDE object writing ability provided by the preferred embodiment provides the author with various menus for incorporating methods into, for example, the VDE object 300. The menu includes, Menus for weighing and / or billing methods that specify how the use of the content portion of the VDE object should be controlled. Menus related to extraction methods that restrict and / or allow users of a VDE object to extract information from that object, and newly created and / or pre-existing VDE content with such information. Menus that can include putting in a container, Audit methods, a menu that identifies whether some form of audit information should be generated and communicated back to object providers, object creators, administrators, and / or information exchanges in some secure manner, and A menu that distributes methods that control how objects are distributed, for example, controlling the distribution rights of different participants by where they are in the chain of handling VDE content containers. A menu that distributes methods that include.

Copyright also distributes administrative budgets, object distribution control keys, and audit control keys for distributors and authors, distributors and / or themselves, and / or other authorized to perform audit functions. It may include procedures for distribution to VDE participants. Copyright may also include procedures for selecting and distributing distribution methods, audit methods, and audit reduction methods. The above methods include, for example, methods for the distributor to securely write and / or control the budget for redistributing the object to the next content handling participant in the VDE chain.

The content of Object 300 created by the author may be generated with the assistance of a VDE-aware application program or a non-VDE-aware application program. The content of objects created by the author in combination with such programs includes text, formatted text, images, moving images, audio, computer software, multimedia, electronic games, electronic training materials, and various types of files. Etc. can be included without any restrictions. The writing process encapsulates the content generated by the author within an object, encrypts the content with one or more keys, and adds one or more methods to the object by the user (and / or authorized users only). It may specify the audit and / or payment parameters required for the permitted use and / or the above use. The writing process can also include some or all of the aspects of distributing an object.

In general, in a preferred embodiment, the author may:

A. Identify what content should be included in the object.

B. Identify content-based methods that include:

Information--Typically, abstract, promotional, identifying, scheduling, and / or other information about the content and / or author.

Content--For example, file lists and / or other information resources including content, time, variables, etc.

C. Identify control information (typically a collection of methods associated with each other by one or more authorization records, including any method that defines a variable), and an initial approved user list that includes, for example: To do.

Control information for access and extraction Control information for distribution Control information for audit processing If the VDE node receives administrative budget information from the object provider for distributing the object and associated distribution key information, the VDE node electronics 600 may distribute the object, for example, on behalf of the object provider.

If the VDE node receives one of the required administrative budgets, audit methods, and audit key information (eg, used to decrypt audit tracking) from the object provider, the VDE node electronics 600 will be of the object provider. Audit records may be received and processed instead. The VDE electronic device 600 having audit capability can control the execution of the audit reduction method. In a preferred embodiment, "audit reduction" means that the object provider (eg, any object provider on the object handling chain) is either an object distributor, an object creator, a client administrator, and / or audit information. A process that extracts information from audit records and / or processes identified as being reported to a user in. This may include, for example, an advertiser who may be required to pay for the use of the object content by the user. In one embodiment, for example, an information exchange places budgets, audit methods, and / or audit key information for objects, objects, classes of objects, or other groupings located at the user site or at the object provider site. May have the ability to "add" to. This ensures that the desired audit process is performed in a "trusted" manner. Participants in a chain that handles VDE content containers and / or content container control information objects may be another party in the chain that handles usage audit information related to the use of object content (eg, information exchanges, advertisers, or market research). And / or can act as a "proxy" for parties interested in certain customer usage information. This may be necessary to ensure that budgets, audit methods, and / or audit information is collected and / or provided to the additional parties in an appropriate manner for the other parties mentioned above. This can be done by identifying the information, eg, by adopting specification information provided by the other parties mentioned above. Object creation and initial control structure In a preferred embodiment of VDE, the object creation and control structure design process supports the basic configurabililty of control information. This allows the VDE100 to support a complete range of possible content types, distribution paths, usage control information, audit conditions, and users and user groups. VDE object creation in a preferred embodiment employs a VDE template in which the atomic element at least partially represents a modular control process. The user may employ VDE creation software (a GUI programming process in a preferred embodiment) and a VDE template to create a VDE object 300. Creating a VDE object 300, for example, splits the object, puts "metadata" (eg, author's name, creation date, etc.) inside the object, and puts the rights and / or object content associated with the object, for example, the publisher and / Or it is done by assigning it to a content creator. When the object creator performs this process, it usually performs a content specification procedure that requires the required data. When satisfied, the content specification process can proceed, for example, by inserting data into a template and encapsulating the content. Moreover, in a preferred embodiment, the object may also automatically register its presence in a secure subsystem of the local VDE node electronics 600. And template instructions and atomic methods (atomic) As a result of interaction with method), at least one authorization record 808 may be created with one or more control structure pieces that may contain one or more methods, budgets and / or others. The registration process may require a budget to be created for the object. If the object creation process identifies the initial distribution, the managed object may also include one or more authorization records 808, other control structures, methods, and / or load modules.

Permit record 808 can identify various control relationships between objects and users. For example, the VDE100 supports both single access (eg, a one-to-one relationship between a user and a rights user) and group access (any number of people can be approved as a group). A single permit record 808 specifies both single and group access. The VDE100 may provide "sharing", a process that allows multiple users to share a single control budget as a budget. The concept of additional control structures includes distribution, redistribution, and auditing, the last of which supports the reduction and / or transfer of weighing and budget information. All of these processes are usually securely controlled by one or more VDE secure subsystems. Templates and classes VDE templates, classes, and flexible control structures include movies, audio recordings and live performances, magazines, phone-based retail, catalogs, computer software, information databases, multimedia, commercial communications, advertising, market research, infomartials, games. Supports frameworks for organizations and individuals to create, modify, sell, distribute, redistribute, consume, and use CAD / CAM services for numerically controlled machines. As the context surrounding these classes changes or evolves, the templates provided by preferred embodiments of the present invention can be modified to accommodate these changes for broader use or more focused activity.

VDE100's work may provide three inputs to the creation process: templates, user inputs, and object content. Templates are a set of control instructions and / or a set of control instructions for object control software that can create (and / or modify) VDE objects within the process of creating VDE objects by interacting with user instructions and provided content. Acts as data. Templates are usually specifically associated with object creation and / or control structures. A class represents a group of users that can include "natural" groups within an organization, such as department employees, specific security clearance levels, or lists for special cases of individuals and / or VDE nodes.

For example, a template can be represented as a text file that defines a particular structure and / or component assembly. Templates with structures and / or component assemblies can serve as VDE object writing or object control applications. The creation template can consist of many sub-templates, which at the lowest level represent the "atomic level" of the description of the object specification. Templates can represent one or more models that describe various aspects of a content object and how the object should be created. How an object should be created involves adopting secure atomic methods used to create, modify, and / or destroy permit records 808 and / or related budgets.

Templates, classes (including user groups that employ objects under group access), and object "independent" permission records (permissions that can be associated with multiple objects) and structures that support budgeting and auditing as separate VDE processes. Flexible control structures, including, aid in focusing on the flexible and configurable capabilities provided by the present invention in the context of a particular industry and / or business and / or application. VDE streamlines and includes distribution scenarios currently adopted in a wide range of powerful industries (partially by using application or industry specific templates). Thus, existing industries and / or applications and / or businesses manipulate familiar concepts related to content types, distribution methods, pricing mechanisms, content and / or related management activities and user interactions, budgets, and so on. It is important to provide a framework for behavior and / or structure to make this possible.

VDE templates, classes, and control structures are inherently flexible and configurable, reflecting a range of information distribution and secure storage conditions, enabling efficient application to new industries as they emerge, and are extant. It reflects the evolution and / or change of the industry and / or business it does, and also supports one or more user groups that may be associated with certain permits and / or budgets and object types. Flexibility of VDE templates, classes, and basic control structures is enhanced by using VDE integration and control methods that have complex conditional process impacts on object control. The present invention truly achieves a content control and audit architecture that, when adopted integrally and with VDE managed objects and VDE security deployments and processes, can be configured for most commercial distribution embodiments. The present invention therefore fully supports the conditions and preferences of content providers without forcing them to fit into a predetermined application model. The present invention allows content providers to specify content rights, control information, and flow (and return of audit information) through distribution channels. Modification of object content (addition, hiding, modification, removal, and / or extension) Adding new content to an object is an important aspect of the work provided by the present invention. The provider may wish to allow one or more users to add, hide, modify, remove, and / or extend the content provided by the provider. In this way, other users may add value to existing content, modify it for new purposes, maintain it, and / or make other modifications. The ability to add content to empty and / or newly created objects is also important.

When providing content and accompanying control information, the provider may choose to add control information that allows and / or limits addition, modification, concealment, and / or erasure of the content. This control information may relate to:

The nature and / or location of content that can be added, hidden, modified, and / or erased, Parts of content that can be modified, concealed, erased, and / or added. Control of added, hidden, and / or modified content Secure control information required for the next use of VDE container content in the chain and / or at a local location, Provider-specified notices and / or content parts must be accompanied by addition, concealment, erasure and / or modified content and / or the fact that the above addition, concealment, modification and / or erasure has occurred. Condition, Restrictions and / or conditions relating to content that can be removed, concealed, and / or erased from content, including the amount and / or degree of addition, concealment, modification, and / or erasure of content. Safe management, Notifying the provider that alterations, concealment, additions, and / or erasures have occurred, and / or the nature of what has happened above, and Other control information about modifying, adding, hiding, and / or erasing provider content.

Providers may use this control information to establish opportunities for other users to add value to and / or maintain existing content in a controlled manner. For example, software development tool providers may be able to add comments and / or similar and / or comment tools to the objects they provide. The movie provider may allow comments and / or promotional materials to be added to the material. Providers that provide CAD / CAM specifications to machine tool owners allow other users to modify objects containing instructions related to the specifications to improve and / or translate the above instructions for use on the user's equipment. Can make it possible. The database owner allows other users to add and / or remove records from the provided database object in order to allow flexibility and / or maintenance of the database. obtain.

Another advantage of introducing control information is the opportunity for providers to allow users to modify content for new purposes. Providers allow other users to serve content in new settings.

To attach this control information to the content, the provider may be provided with methods for objects that control the addition, hiding, modification and / or erasure of the content, and if permitted, design and execute the above methods. obtain. The design and execution of one or more of these methods can be done using the VDE software tools combined with the PPE650. The provider may then attach the method to the object and / or provide the method separately. Permit record 808 may include conditions related to control information combined with other control information. Alternatively, another permit record 808 may be used.

An important aspect of adding or modifying content is the selection of encryption / decryption keys and / or other relevant aspects to secure new or modified content. Providers may create and / or select encryption / decryption keys and / or other relevant aspects to secure new and / or modified content in the methods associated with these processes. The technique to be used can be specified. For example, a provider may include a set of keys, a technique for generating a new key, a reference for a load module that generates a key, a protocol for securing content, and / or other similar information.

Another important effect is the management of new keys if they are created and / or used. The provider may require such keys and a reference as to which key must be used to be transmitted to the provider. Alternatively, the provider may allow the key and / or security strategy to remain outside the provider's knowledge and / or control. The provider may also opt for an intermediate position where some keys must be transmitted but others are out of the provider's knowledge and / or control.

Another aspect related to key management is the management of permissions related to objects resulting from the addition, hiding, modification, and / or erasure of content. Providers relate to VDE rules and control information regarding allowing a chain of VDE control information users to access and / or manipulate VDE managed content, and / or the objects obtained. It may or may not allow you to obtain some or all of the rules and control information. For example, the provider allows the first user to control access to new content in the object, thereby allowing any other user who wants to use that part of the content from the first user. It may be possible to need to receive. This may or may not, at the discretion of the provider, require the user to obtain permission from the provider to access the object.

Keys related to additions, alterations, concealment, and / or erasures may be stored in a separate authorization record or record 808. The authorization record 808 may be delivered to the provider and may be mixed with existing authorization records. Alternatively, it may remain alone under the control of the new content provider. The creation and content of the initial authorization record 808, as well as any control information about the authorization record, is collected by methods related to the activity by the provider. Subsequent modifications and / or uses of the above authorization record may include the method of the provider, the actions of the user, or both. The ability of the user to modify and / or use the authorization record 808 depends, at least in part, on the superior control information associated with the authorization record of the provider. Distribution control information To enable a wide range of flexible commercial trading environments, providers have the ability to establish reliable control information for the distribution process without unduly limiting the potential of the next party in the control chain. Should be. The distribution control information provided by the present invention enables flexible positive control. Neither provider is required to include any particular control or use any particular strategy, except as required by higher-level control information. Rather, the invention may provide the provider as a comprehensive control component (eg, as a subset of the provider's specific marketable components contained within the VDE application and / or directly compatible with the VDE application). Allows you to choose from and establish a structure suitable for a given handling / control chain. The provider can also establish control information for control information that allows and limits the provider's control information to be modified by other users.

The management system provided by the present invention produces management "events". These "events" correspond to activities that are initiated by either the system or the user and correspond to processes that may be protected within the VDE. These processes copy authorization records, copy budgets, read audit tracking records, copy methods, update budgets, update authorization records, update methods, back up admin files, manage Includes activities such as repairing files. Reading, writing, modifying, updating, processing, and / or erasing information for any part of the VDE record is a management event. A management event can represent the process of performing one or more of the above activities on one or more parts of one or more records.

When the VDE electronics 600 encounters a management event, the event is typically processed with the VDE PPE 650. Management events are often conducted by content providers (including, for example, content creators, distributors, and / or client administrators), as is often the case with events that are generally associated with accessing and / or using content. , Objects, groups of objects and / or classes identified as an aspect of the specified control.

For example, if a user initiates a request to distribute permission to use an object from a desktop computer to a notebook computer, one of the management events generated is a copy of the permission record corresponding to the object. It can be to create. If this management event is detected by ROS602, there may be an EVENT method for this type of event. If the EVENT method exists, there can also be weighing, billing, and budget associated with the EVENT method. Weighing, billing, and budgeting may allow providers to allow and limit the copying of authorization records 808.

For example, weighing, billing, budgeting and / or audit records may be generated and / or updated while processing the control program. The audit record may record information about the management event and the environment surrounding the processing of the event. For example, the audit record may include a reference to the user and / or system activity that initiated the event, success or failure of processing the event, date and / or time, and / or related information.

With reference to the above example of a user with both a desktop computer and a notebook computer, a permit record provider may require an audit record each time a scale that copies the permit record is processed. .. Audit records provide providers with flexible, configurable control and / or recording environment options.

In some environments, it may be desirable for the provider to limit which aspects of the control component can be modified, updated, and / or erased . "Atomic element specifications" can be used to limit the applicability of events (and thus the rest of the control process, if any) to some "atomic elements" of the control components. For example, if permit record 808 is decomposed into "atomic elements" on the field shown in FIG. 26, the event processing chain may identify only this field within the atomic element specification, eg, for an expired date / time. The information may be limited to a certain number of alterations. In another embodiment, the permit record 808 can be decomposed into atomic elements based on the control set. In this embodiment, the event chain can be limited to events that act on a control set.

In some environments, it may be desirable for the provider to control how the management process takes place. The provider controls and identifies in the distribution record stored in the secure database 610, for example, how a given event should be processed in relation to a given method and / or record. You may choose to include the information used with assembly 690. For example, if the provider wants to allow the user to make a copy of the authorization record 808, the provider may want to change the authorization record internally. For example, in a user having the above desktop computer and notebook computer, the provider allows the user to make a copy of the information necessary to operate the notebook computer based on the information existing in the desktop computer. However, it is possible that further copies of the above information may not be allowed to be made by the Notebook VDE node. In this embodiment, the above distribution control structure continues to exist on the desktop computer, but the operational information sent to the notebook computer lacks the distribution control structure required for distribution from the notebook computer. .. Similarly, a distribution control structure may be provided by a content provider to a content provider who is a distributor. In the distributor above, the control structure allows a number of copies from the VDE content container object to be taken along with the associated copy of the authorization record. However, permission records have been modified (for example, per content provider specification) to prevent end users who receive a copy made by the distributor from making further copies for distribution to other VDE nodes. Ru.

The above embodiment focused on one particular event (copying) in one possible case, but under any control relationship considered by the present invention, the recording and / or method. Similar processes can be used for reading, writing, modifying, updating, processing, and / or erasing. Other examples include budget copy, scale copy, budget update, scale update, audit tracking compression, and so on. Creating custom methods In a preferred embodiment of the invention, the method can be created "at will" or can be named for another method. These two modes contribute to greater configuration adjustability, flexibility, and aggressive control of the VDE distribution process. Creating a method generally involves identifying the required attributes or parameters for the data portion of the method, and then "typing" the method. The typing process typically involves selecting one or more load modules to process any data portion of the method. In addition to the method itself, the process of creating a method can also result in method option sub-records, which should be included in the authorization record and are variants of the authorization record, and notations in the distributed records. In addition to any of the "standard" load modules required to execute the method, additional load modules and the data used with these load modules can be identified, if permitted. These event handling structure controls control the distribution of methods.

For example, consider the case of a security budget. One form of a typical budget could be to limit users to 10 megabytes of decrypted data per month. The user may want to move the right to use the associated VDE content container object to the notebook. Budget creators can limit notebooks to the same amount, half the original amount, the amount assigned to an object, based on the number of moves, and so on. The distribution method (or internal event handling structure) associated with the budget allows the budget creator to make decisions regarding the methodology and parameters involved. Needless to say, different distribution methods may be required for method redistribution or formal distribution. The integration of these selections is stored in the authorization record for the method.

An example of the process steps used to move budget records could be:

1) Check the budget to move (for example, to determine the number of moves allowed).

2) Copy the static field to a new record (for example, as a burden).

3) Decrement the Decr counter within the old record (original budget).

4) Increment the Encumbrance counter in the old record.

5) Write the distribution record.

6) Write the distribution event ID in the new record.

7) Increment the mobile scale.

8) Decrement the mobile budget.

9) Increment the Decr counter within the new record. Budgeting In a preferred embodiment, the user operates a graphical user interface budget distribution application (eg, a VDE template application) to create a budget. The user fills in any required fields such as budget type, maturity cycle, audit, etc. Budgets can be specified by dollars, Deutsche Mark, yen, and / or any other monetary or content measurement scheme and / or organization. The output of the application according to the preferred embodiment is usually three basic elements: annotations in the distribution part of the secure database 610 for each budget record created, actual budget records, and method option records to include in authorization records. Has. In some environments, existing method options are used, so the budgeting process may not result in the creation of method options. Normally, the entire output is protected by storage within a secure database 610 and / or one or more managed objects.

These are two basic modes of operation for budget distribution applications in preferred embodiments. In the first case, the operator has unlimited authority to identify the budget. Budgets arising from this type of activity can be freely used to control any aspect of the distribution process to which the operator has rights. The above rights include use on a "security" budget, such as an amount that limits certain aspects of use. For example, if the operator is an "ordinary person," the operator may use these budgets to control the use of objects on their own based on a personal accounting model or schedule. If the operator is a VISA-approved person, the budget obtained can have a wide impact on the entire distribution system. The core idea is that this mode is strictly controlled by the operator.

The second mode of operation is used to create an "alias" budget. These budgets are linked to budgets that already exist in the operator's system. When an operator deals with a budget, it also causes a burden on the budget. When these types of budgets are created, the output will have two method option subrecords linked together, namely a method option subrecord for the name budget and a method option subrecord for the newly created budget. Including. Alias budgets are often used in place of the original budget if the budget creator is authorized to modify method options within the appropriate required method records of the authorization record.

For example, suppose a company user (client administrator) has a company VISA budget in electronics 600. The user wants to distribute the budget to a network of internal users with various existing budgets and conditions. Users also want to limit the use of the company's VISA budget to certain objects. To do this, users nickname a company's budget the VISA budget. The user then modifies the permission record (if approved) for all objects that the company allows the user to operate so that it recognizes the company's budget in addition to or in place of the Visa budget. To do. The user then distributes the new authorization record and budget to other users. Audit data from these users is then reduced to the burden on the company's VISA budget, which results in regular billing.

In another embodiment, the customer wants to control the family's purchase of electronic devices with a VISA card and prevents children from playing an excessive number of video games, but on the other hand the use of encyclopedias. Wants to allow unlimited. In this case, the customer can create two budgets. The first budget can be aliased to a VISA card and used only for encyclopedia objects (referenced as individual encyclopedia objects and / or one or more classes of encyclopedia objects). The encyclopedia object refers to the alias budget in a clearly modified permit record. The second budget can be, for example, a time budget that the customer redistributes to the family for use in a video game object (video game class). In this case, the second budget is, for example, a "self-replenishing" security / control budget that allows use for two hours a day. The first budget works in the same way as in the example above. A second budget will be added as a new required method for permit recording for video games. Since the time budget is needed to access the video game, an effective control path that requires a second budget is introduced. That is, only permit records modified to allow family budgets can be used by children for video games and are limited to two hours a day. Sharing and distribution of rights and budgets Move The VDE concept of "movement" provided by the preferred embodiment covers the case of "friendly sharing" of rights and budgets. A typical case of "move" is a user who owns several machines and wants to use the same object on more than one machine. For example, a user owns a desktop computer and a notebook computer. These subscribe to electronic newspapers that the user wants to read on either machine, i.e. the user wants to transfer rights from one machine to the other.

An important concept within "movement" is the idea of an independent act. The electronic device 600 to which the rights are transferred may independently contact the distributor or information exchange. For example, the above user may want to take a notebook on a long trip and contact the information exchange and distributor without having to connect locally to the desktop.

To support independent operation, the user defines an account at a distributor or information exchange independent of the electronic device 600 used for connection. Transactions can be independently traced and arbitrated between multiple machines between the end user and the information exchange or distributor. The basic behavior of rights, budgets, and movement of bitmaps or combinatorial instruments between machines is also supported.

Redistribute Redistribution forms a UDE intermediate ground between "friendly sharing" of "movement" and formal redistribution. Redistribution can be considered "anonymous distribution" in the sense that it does not require any special interaction between creators, information exchanges, or distributors and redistributors. Needless to say, the creator or distributor has no ability to limit or interfere with redistribution.

Unlike the "move" concept, redistribution does not suggest independent behavior. The redistributor contributes as a point of contact to the user who receives the redistributed rights and / or budget. These users do not know or have access to the redistributor's information exchange (or and / or distributor) account. The redistributor shall contribute as an auditor of his / her right to redistribute and / or budget, etc., unless specifically refused by the distributor and / or restrictions from the information exchange. The redistributor (the recipient of the redistributed rights and / or budget) imposes a relatively unquantifiable workload on the information exchange and at the risk that the redistributor can audit himself. (Responsible for all rights and / or budgets to be redistributed), auditing the rights and budgets of the redistributor by the redistributor is considered the default case in a preferred embodiment. ..

distribution The distribution contains three entities. Creators are usually the source of distribution. Creators can typically set up a control structure "context" to control the rights sent to the distribution network. Distributors are users who form a link between the end user of an object (content) and the creator of the object (content). Distributors provide two-way conduits for rights and audit data. Information exchanges may provide independent financial services such as credit and / or billing services and may contribute as distributors and / or creators. Through the authorization and budgeting process, both of these parties may establish precise control over the type and extent of rights use and / or audit activity.

burden The "burden" is a special type of VDE budget. When any type of budget distribution occurs, a "burden" can be generated. The burden is indistinguishable from the original budget for the purpose of exercising the right (eg, payment for use), but within the distribution record with respect to the amount of the burden and all the information needed to complete the sending record to track the location of the burden. Is identified in its own style. For exercise purposes, the burden is the same as the original budget, but for tracking purposes it is identifiable in its own way.

In a preferred embodiment of the invention, the distribution event ID is used by the user VDE node and the information exchange to track and arbitrate the burden, even in the case of asymmetric audits. That is, the "new" budget is unique from a tracking perspective, but indistinguishable from a usage perspective.

The irrecoverable burden is a good intermediate control for the VDE distribution process. Appropriate "grace periods" may be introduced in which the burden must be reclaimed. After this period, actual charges or payments may occur. However, even after the interval has expired and charges and / or payments have been made, the burden may remain and may support later mediation. In this case, the auditor may allow the user to earn credits, or the user may connect to the VDE node containing the burdened budget and collect the amount as internal credits. In some cases, lost audit tracking invalidates redistribution privileges if the burden is not reclaimed within the "grace period", if grace period violations are repeated, or if the unrecovered burden is excessively high. Distributors can be concerned enough to do so.

Burden can be used in various distribution modes. When used with budget aliases, the burden provides significant additional distributability. When aliasing a budget, the user puts himself in the control passage of the object. That is, the aliased budget can only be used with a permit record modified to recognize it. The burden does not have such a limitation.

For example, a user may want to limit children's use of the VISA budget for electronic VDE nodes. In this case, the user may generate a burden on the children's VISA budget for the family aliased budget and another burden for the wife, which is the transparent burden of the original VISA budget. BigCo may use a similar mechanism that distributes the VISA budget to the top of the department and distributes the aliased BigCo budget directly to the user.

Account number and user ID In a preferred embodiment, the user is assigned an account number at the information exchange to control access to the information exchange. Account numbers provide a unique "instance" value for secure database records from an outsider's perspective. From the perspective of 600 electronics sites, a user, group, or group / user ID provides its own instance of recording. For example, from a VISA perspective, your gold card belongs to the account number 123456789. From the point of view of an electronics site (eg a server in a company), a gold card can belong to user ID 1023. In an organization with multiple users and / or user groups using VDE nodes, such users and / or user groups are likely to be assigned their own user IDs as well. Different budgets and / or other user rights can be assigned to different users and / or user groups, and / or VDE control information can be electronic content and / or VDE control information in different ways by users assigned such different IDs. / Or can be given for equipment use. Needless to say, both the information exchange and the local site may have both pieces of information, but the "data used" vs. the "comment data" are different based on perspective.

In the case of the preferred embodiment of "move", the account number stored with the right remains. In a preferred embodiment of other forms of distribution, a new account number is required at the distribution destination. This corresponds to a method that can be automatically generated by the system or developed by the distributor or redistributor. Distributors maintain account numbers (and associated access secrets) within each distribution destination's local name service. Conversely, the distribution destination name service may store account numbers based on the user ID of each distributor. In the case of transfer, this record is usually moved with other records or generated during distribution in other forms.

Organizations (including families) can automatically assign their own user IDs when creating control information (eg, budgets) for new users or groups of users.

Condition record Conditional records in the object's private header to establish the conditions and possible options for exercising the rights associated with the object before one or more required authorization records for the VDE Content Container object are received. Can exist. This record helps users establish what they have and what they need from the distributor before making a connection. If the conditions or possibilities for exercising a particular right change since the object became public, a modified condition record may be included with the object (if available and permitted) in the container. Alternatively, the distributor may request a new condition record before registration is initiated. Distributors maintain a collection of conditional records and / or a "catalog" of descriptive information online, corresponding to objects for which they may acquire rights and / or have the ability to empower other users. And / or can be distributed to users.

Passing the audit In a preferred embodiment of VDE, there can be at least two types of audits. For budget distribution, billing records that generally reflect budget consumption need to be collected and processed. For permission distribution, usage data associated with the object is also frequently needed.

To enforce control over an object, the creator can establish basic control information related to the object. This is done in the formation of permits, the distribution of various security, administrative and / or financial budgets, and the level of permitted redistribution. The distributor (and redistributor) may also control this process within the rights, budget, etc. (upper control information) received by the distributor.

For example, the object creator may identify that additional required methods can be freely added to the authorization record, allowing unlimited redistribution of this right without establishing any budget for this activity. .. As another example, the creator may allow the usage rights to be transferred by the distributor to six sub-distributors. Each of the above sub-distributors is 10, 000 copies may be distributed, but redistribution rights are not allowed to be assigned to sub-distributor (re-distributor) customers. As another example, the creator may authorize that usage rights be transferred to only 10 VDE nodes with only one level of distribution (without redistribution). Content providers and other contributors of control information control, through the use of authorization records and / or the use of component assemblies, the rights authorized by other users to act as agents within the authorization records sent. Have the ability. The above capabilities exist as long as the right to control one, some, or all of these rights of other users is granted or limited (depending on the control information distribution model). It is possible and often desirable to use VDE to build a mixed model in which the distributor is restricted from controlling certain rights of the next user and is allowed to control other rights. is there. VDE control of rights distribution in some VDE models, in part or in whole, is controlled by the electronic content control information provider, at least for one or more "levels" of the distribution chain. The electronic content control information provider is not a provider of related content, or provides only a part of the content controlled by the content control information. For example, in one model, an information exchange can also serve as a rights distribution agent that provides one or more rights to participants in a value chain. The above one or more rights may be "attached" to one or more rights to use the information exchange credits. (If the information exchange is, at least in part, a financial information exchange, such a control information provider may reflect the rights of other users in lieu of or in addition to this.) Content creators or other content control information providers may create budgets for users (such as distributors). This creates an unlimited number of authorization records for the content object, but the user does not report usage at one or more expected points in time and / or after a period of time (does not provide an audit report). If (and / or the user does not pay for use, or violates any other aspect of the contract between the user and the content provider), this right and / or other materiality through the expiration / termination process. Right to use is revoked. This termination (or suspension or other identified outcome) is accomplished, for example, by the expiration of a time-aged encryption key employed to encrypt one or more aspects of control information. This same termination (or other identified consequences such as budget cuts, price increases, message display on the user's screen, message to the administrator, etc.) is also the process by which the user or user VDE installation was monitored. Can be the result of not completing. The above monitored processes are electronic currency payments for use, inability to back up important stored information (eg content and / or device usage information, control information, etc.), proper passwords or (Repeating not using other identifiers, etc.) is included.

In general, a collection of audit information collected for reporting to an Audit &amp; Supervisory Board Member may be carried out by an expiration and / or other termination process. For example, a user's VDE node may (a) be instructed by an external source not to perform a task anymore, or (b) hold information in its control structure informing it that it is no longer performing a task. Either (c) is no longer able to perform a task. A task is one or more due to the user (or installation) not reporting the audit information to the Audit &amp; Supervisory Board Members and / or not receiving the secure receipt confirmation and / or approval of the audit information. It may include an operation start operation. If the Audit &amp; Supervisory Board Member fails to receive audit information from the user (or other events that should occur do not occur properly), for example, one or more used as a security component in one embodiment of the invention. It is possible that a time-aged key suddenly accelerates (completes) its aging, which means that one or more processes related to the time-aged key can no longer be performed. Approved access tags and modified access tags To allow a user VDE installation to send audit information to a VDE audit party, such as an information exchange, VDE allows the VDE audit party to securely and electronically communicate with the user VDE installation and perform the above audits. Depending on the rights of the party, it is possible to ask questions about the installation for certain or all information stored within the secure subsystem of the installation. (The parties usually do not have access to securely stored information that the party has not explicitly authorized to access. One content provider is usually associated with content provided by different content providers. The Audit Party is not authorized to access Content Usage Information.) The Audit Party provides a secure secret (eg, Secret Tag) that represents the set of Auditor's rights to access certain information maintained by the above subsystem. Show clearly. If the subsystem checks the validity of the tag, the audit party may receive audit information that it is authorized to request and receive.

There is great flexibility in implementing audit tracking conditions. For example, a creator (or any other content provider or control information provider or auditor in the object or audit report handling chain) allows changes by the auditor for event tracking, but anyone other than the creator has them. It is possible to limit the redistribution of this right to, for example, 6 levels without allowing the tracking to be read. Instead, the creator or other controlling party gives the distributor, for example, the right to process 100,000 audit records (and / or, for example, the right to process 12 audit records from a given user). Can be given to the distributor before reporting. The creator or other control party may, if desired, allow (and / or request) separate (and / or request) audit "packets" containing audit information (and different, subset forms, duplicate, or identical information). Some parts of the audit information should be processed by the distributor, and other parts of the audit information may be creators and / or other auditors (each identical, duplicate, subset form, or It should be returned to (receive different audit information). Similarly, as far as permitted by, for example, the Object Creator, the Distributor (or other Content and / or Control Information Provider) may have audit information after, for example, approximately 50,000 audit records have been processed (or any other). A number of audit records and / or after some time and / or at a predetermined date) may need to be returned by the redistributor. In a preferred embodiment, the audit rule, like any other control structure, is not restricted by the participants who distribute (such as audit) the higher "superior" objects and / or control information to identify the rule. , Can be identified at any stage of the handling distribution chain.

Audit information scheduled for different corporate auditors can be encrypted with one or more different encryption keys. The encryption key is securely provided by each Audit &amp; Supervisory Board Member's VDE node and communicated as a necessary step during object registration, for example, to be included in the user's authorization record. This provides additional security (beyond passwords and / or other identifying information and other VDE security features) to further ensure that auditors have access to only approved audit information. In one embodiment, an encrypted (and / or unencrypted) "packet" of audit information (eg, in the form of a managed object) can be directed to a different auditor. The different auditors mentioned above include information exchanges and / or other content providers and / or other audit information users, including, for example, market analysts and / or list providers. Information is successfully sent from information exchanges to redistributers, and from distributors to publishers / object creators, for example, through a single chain of handling users, as specified by the VDE audit control structure and parameters. obtain. Alternatively, encrypted (or usually less suitable but unencrypted) audit packets may need to be distributed directly from the user to multiple auditors. Some of the above Audit &amp; Supervisory Board Members are responsible for "passing" audit packets to other Audit &amp; Supervisory Board Members. In another embodiment, audit information may be sent, for example, to an information exchange. The information exchange may then redistribute all and / or an appropriate subset of the above information (and / or some processed results) to one or more other parties. The redistribution is done using the VDE secure objects created by the information exchange.

An important function of the Audit &amp; Supervisory Board Member (receiver of audit information) is to return the management event to the user VDE node after acknowledging that the audit information has been received and / or "recognized". In a preferred embodiment, two processes can be performed following the receipt and / or acceptance of audit information. The first event either clears the audit data on the VDE node that prepared the audit report, or compresses or adds it to one or more summary values. The second event or event set "announces" the receipt of the audit, modifies the maturity date, key updates and / to the relevant security (eg termination and / or other outcome) control information of the VDE node. Or provide other things. In most cases, these events are sent to the site shortly after the audit tracking is received. In some cases, this transmission may be delayed, for example, first to allow audit tracking and / or processing of payments by the user to the auditor or other parties.

In a preferred embodiment, the audit event for the content object and the separately distributed method / component assembly are similar, but not necessarily the same. For example, key updates for a budget can control billing tracking encryption rather than object content decryption. Billing tracking for budgets is, in all respects, method event tracking. In one embodiment, this tracking may include sufficient reference to the burden distribution record to allow mediation by the information exchange. This happens, for example, if the grace period has passed and the expired burden is "returned" to the creator, and the budget creator allows the uncollected burden to eventually generate automatic credits.

Delivery of audit records through the aisle may be partially guaranteed by the reverse (return of information) audit method. Many VDE methods have at least two pieces: a part that manages the process of generating audit information at the user's VDE node, and a part that then acts on the audit data. In one embodiment dealing with audit information assigned to multiple corporate auditors, a single container object is received by the information exchange (or other corporate auditors). This container is (a) some kind of encrypted audit information used by the information exchange itself, and (b) some other encrypted information directed to one or more other auditor parties. Audit information may be included. The two sets of information can have the same, overlapping, and partially different, or completely different information content. Alternatively, the VDE node of the information exchange may be able to work with some or all of the audit information provided. Audit information may be in some form of summarization and / or analysis that has been further processed at the information exchange, in part or in whole. And / or the audit information, combined with other information, forms the extracted information set or at least part of it, and is inserted into at least one or more partially secure VDE objects. May be communicated with (further) audit parties. When the audit information container is safely processed by the reverse (return) audit method at the VDE node of the information exchange, the VDE node of the information exchange safely transports the audit information to other corporate auditors and the above information. You may create one or more VDE-managed objects that separately process secure audit information identified as being used by the exchange. Secure audit processing and credit information distribution between VDE participants typically occurs within a secure VDE black box. That is, the audit information is a secure VDE

This type of reverse audit method can identify the handling of returned audit information, including, for example, local processing of audit information and / or secure delivery of audit information to one or more audit parties. Depending on the criteria that may be set by one or more other auditing parties and / or content providers and / or control information providers as may be required and during the authorization record specification and / or modification process. If the audit information is not sent to one or more audit parties, for example, the audit party, eg, the content provider, fails to inform that the required audit information has been successfully transferred, resulting in the party's VDE node. Some performance of transmission via the above may be lost (eg, the ability to further perform one or more VDE management business functions with respect to the above audit or party related objects). In this preferred embodiment, when the object is received by the auditor, the object is automatically registered and the contents of the authorization record are placed in the auditor's VDE node's secure management database.

One or more authorization records that control the creation and use of audit report objects (and may also control other aspects of object use) are audit information report exchanges (or between users and auditors or audit agents). It can be received by the user's system during other electronic interactions). Each of the authorization records received may control the following audit report objects: After reporting audit information, new authorization records may be required on the user's VDE node to refresh their ability to manage audit reporting and audit information transport for the next audit reporting cycle. In the above embodiment, allowing an auditor to supply one or more authorization records to a user for the purpose of an audit report is such that the auditor (such as an information exchange) has some sort of identified authorization record itself. May need to be received from "upstream" auditors (eg, content and / or other content control information providers). The information provided by these upstream permit records can be integrated into one or more permit records in the auditor's VDE (eg, Information Exchange) installation. The above installation manages a permission record creation cycle that creates management objects, including permission records directed to users, during the exchange of audit information reports. If the upstream Audit &amp; Supervisory Board Members do not receive and / or process the required audit information, this upstream Audit &amp; Supervisory Board Member shall be given to the Information Exchange (in this example) one or more objects (or). It may not be possible to provide the required authorization record information that allows the distributor to support the next authorization record creation / audit cycle for (object class). As a result, the VDE node of the information exchange may not be able to record and generate permissions for the next cycle for the user and / or perform any other important process. Overall, this VDE audit report control process includes event-driven VDE activity at both the receiver and sender of the intended audit information, and is a secure PPE65.

In a preferred embodiment, at least one authorization record is recorded each time a user registers a new object with his or her own VDE node and / or instead of a remote information exchange and / or distributor's VDE node. Provided to partially control the use of the above objects. Authorization records can be provided dynamically (using the secure subsystem of the VDE installation) during the secure UDE registration process and / or at some point thereafter, eg, 1 It can be received via these separate secure VDE communications. The secure communication includes, for example, a physical arrangement containing or carrying the information. At least one process associated with providing one or more authorization records to a user can trigger a weighing event. As a result of the weighing event, audit information is created to reflect the user's VDE node, information exchange, and / or distributor's authorization record providing process. This weighing process may not only record that one or more permit records have been created. The weighing process may also record the name of the VDE node, username, associated object identification information, time, date, and / or other identification information. Part or all of this information may be part of the audit information securely reported by the information exchange or distributor, for example, to audit content creators and / or other content providers. This information may be arbitrated by secure VDE application software on the receiving Audit &amp; Supervisory Board Members' site with respect to the user's audit information sent to the Audit &amp; Supervisory Board Members by the Information Exchange or Distributor. One or more weighed authorization records created for a user (and / or VDE node) to manage one or more VDE objects of some sort and / or manage the creation of VDE object audit reports. For each (or record set), it is desirable for Audit &amp; Supervisory Board Members to receive the corresponding audit information embedded in at least a partially encrypted audit report. There can be. Weighing the creation of authorization records, the process of reporting secure encrypted audit information, and the secure VDE subsystem arbitration of the weighing information that reflects the creation of audit reporting permissions, including registration and / or received audit report details. , And one or more secure VDE installation expired and / or other termination and / or other outcome processes, when combined, complete VDE's secure audit reporting process as a reliable, efficient commercial environment. Improve sex. Safe document management example VDE100 can be used to provide a secure document management environment. Below are some examples of how this can be achieved.

In one example, suppose a law firm wants to use VDE100 to manage documents. In this example, a law firm that is part of the litigation team may use VDE in the following manner:

1. A form that securely controls access to confidential client records and / or other uses of the above client records.

2. A form that securely controls access to documents and memorandums prepared by law firms, distribution of the above documents and memorandums, and / or other rights relating to the above documents and memorandums.

3. A form that safely controls access to incident-related investigation materials and other uses of the above investigation materials.

4. A form that securely controls access to incident-related records, documents and memos, and other uses of the above records, documents and memos, including distribution.

5. A form that securely controls how other law firms on the litigation team may use and modify the legal documents (brief) distributed for comment and review.

6. A form that assists in managing billing to clients.

Law firms may also use VDEs (thinking that courts can also use VDEs) to electronically submit legal documents to courts. This use includes audit verification of the submitter's ID (eg, a digital signature) and other information related to the submission procedure described above.

In this embodiment, the law firm receives the document from the client's secure subsystem installed on the VDE within the VDE content container. Alternatively or additionally, the law firm may receive a paper document that can be scanned and electronically and / or receive an electronic document that has not yet been placed in the VDE container. You may. Documents in electronic form are stored as VDE containers (objects) associated with a particular client and / or incident. The VDE container mechanism supports a hierarchical instruction scheme for organizing files and other information within a container. This mechanism can be used to systematize electronic copies of documents within a container. A VDE container is associated with specific access control information and rights described in one or more permission control (PERC) information sets associated with the container. In this example, only law firm personnel who have a VDE instance, the appropriate PERC, and a VDE object containing the desired document may use the document. Alternatively or additionally, law firm personnel may use VDE instances installed on the law firm's network server. In this case, the personnel must be identified by the appropriate PERC (to use the server VDE installation) and have access to the document containing the VDE object. Basic access control to electronic documents is made possible by using a secure subsystem installed on one or more user VDEs.

VDE can be used to provide basic usage control in several ways. First, allow multiple containers to be "embedded" within a single object. Embedded objects allow you to "nesting" control structures within a container. VDE also extends usage control information to any level of granularity (rather than the file-based level provided by traditional operating systems) and is related to any information that can be described as a VDE-controlled process. It also provides flexible control information about the action. For example, simple control information may be associated with viewing one or more parts of a document, and additional control information may edit, print and copy the same and / or one or more different parts of these identical documents. Can be related to doing.

In this embodiment, the "client" container includes all documents provided by the client (documents received in other containers are safely extracted using the VDE extraction embedding capability and embedded in the VDE client container. Can be). Each document in this embodiment is stored as an object in the client VDE container which is a parent. The "client" container also has some other objects embedded inside. One is for each lawyer to store notes about the client, one (or more) is for findings and relevant information, and at least one is a letter produced by a law firm. , For duplicates of work papers and legal documents. The client container may also contain other information about the client, including electronic records of billing, time, closings and payments. Embedding a VDE object within a parent VDE content container provides a convenient way to securely categorize and / or store different information that shares similar control information. All documents provided by the client may be subjected to, for example, the same control structure regarding use and non-disclosure. The attorney's memo is provided for control information, for example, its use may be limited to the attorney who created the memo and the attorney who has explicitly granted access to it. Embedded containers also provide a convenient mechanism for controlling different collections of information. For example, a survey object can be stored in the form of a VDE "smart object" (or derived from it) that contains the results of the survey performed by the object. Findings about one aspect of the case, searched from the LEXIS site given by VDE, can be encapsulated as a single smart object. The results of another session related to another (or the same) aspect of the case can be encapsulated as different objects. In this embodiment, the smart objects are delivered completely discretely and separately.

The control structure can also be used to manage the grouping of any desired granularity and / or logical document content by document, page, paragraph, topical related material, etc. In this embodiment, the following assumptions are made. Documents provided by clients are controlled at the page level, attorney notes are controlled at the document level by attorney, court records and legal documents are controlled at the document level, and investigation information is controlled when the investigation is conducted. Controlled at some level specified by the content provider. Certain highly confidential information located within the various content described above is identified as a subject only for display and additional comments by its lead partner, the Attorney, and is the creator and / or embedding of the given content. Only one has the right to use it in any other way (printing, extracting, distributing, etc.).

In general, the contents of the container in this embodiment are controlled with respect to the distribution of rights. This control information is associated at the document level for all internally created documents, at the page level for client level documents, and at the level specified by the content provider for research documents.

VDE control information can consist of either complex or simple structures, depending on the wishes of the participants. In some cases, the VDE Creator wants to use it (and is supported by the VDE application that manages the rules and control information specifications, either directly or through a VDE component assembly that has proven to be compatible with the application. Apply a set of control structure definitions.

In this embodiment, the law firm sets up a standard VDE client content container for a new client at the time of accepting the case. The law firm's VDE administrator establishes a VDE group for new clients and is authorized to work on the case with the law firm's lawyer VDE. Add an ID and, if appropriate, provide one or more user template applications. These templates are, for example, for user selection of additional and / or alternative control functions (if permitted by superior control information), entry of control parameter data, and / or execution of user-specified administrative tasks. Provides one or more user interfaces and associated structures. The administrator uses the creation tool according to a predetermined creation template to create the container. This creation template identifies the usage pattern (including distribution control information) of the above document. Each electronic document from the client (letter, memorandum, email, spreadsheet, etc.) is then added to the container as a separately embedded object. Each of the new objects is created with a creation template that satisfies the default control structure specified for the container required for each of the new objects of a given type.

Each lawyer may enter notes into an object stored within the client's VDE container as he or she works on the case. These notes can be taken using a VDE-aware word processor already used by law firms. In this embodiment, the VDE director securely maps requests for word processor files to VDE containers and their objects using a VDE control process running on one or more VDE PPEs. The attorney's memo object is created with the help of an attorney using the default creation template for the document type if the document type cannot be determined automatically from the content. This allows VDE to automatically detect and protect notes at a predetermined level, such as the document, page, or paragraph level.

Surveys can be managed automatically using VDE. Smart objects can be used to perform secure searches and, if necessary, to pay for and retrieve information from VDE-enabled information resources on information highways.

Examples of such resources may include LEXIS, Westlaw, and other legal databases. The information, once retrieved, can be securely embedded within the VDE content client container. If the smart object still contains unreleased information, the entire smart object can be embedded within the client's VDE container. This means that unreleased information is subject to dual VDE control conditions, that is, requirements for releasing information from smart objects (payment and / or audit requirements), and certain types of client information. Place under conditions related to access to or other use of the above client's information.

Legal documents and other filings can be controlled in a manner similar to a lawyer's memo. The filing can be edited using a law firm's standard word processor. This editing is done with the usage control structure controlling who can review, modify, and / or add to the document (or, in more advanced examples, some part of the document). VDE may also support electronic filing of legal documents by stamping time / date and providing a reliable source for validation of filed documents.

When clients and lawyers wish to exchange confidential information by email or other means, VDE will use the information to be privileged, properly controlled, improperly released and / or used. It can play an important role in ensuring that it will not be done. Materials (content) stored within the VDE content container object are usually encrypted. In this wrapped state, the VDE object is distributed to the recipient without the risk of unauthorized access and / or other use. One or more authorized users who receive an object are the only party that can open and view the object and / or manipulate and / or modify its content, and VDE's secure audit is all this way. Guarantee the recording of user content activity. VDE also allows, if necessary, revoke the right of privileged confidentiality between the client and the attorney, for example, after the administrator has reviewed the user's usage audit information. Example of a large organization In a more general example, an organization (eg, a corporate or government agency) with thousands to hundreds of thousands of employees and a large number of offices over a large area belongs to that organization (or association). Suppose you want to control the distribution of. This information can take the form of official documents, email messages, text files, multimedia files, etc., which are collectively referred to as "documents".

Such documents may be handled by humans (referred to as "users") and / or computers acting on behalf of the users. Documents can exist in both electronic form for storage and transmission and document form for manual handling.

These documents may originate entirely from the organization, or may be created in whole or in part from information received from outside the organization. Authorized individuals within the organization may choose to release all or part of the document to entities outside the organization. Some of these entities may or may not employ VDE100 for document control. Document control policy Organizations as a whole may have well-defined policies regarding control of access to documents and / or control of other uses of documents. This policy can be based on a "lattice model" of the flow of information. In the flow of information, a document is characterized as having one or more hierarchical "classification" security attributes 9903 and zero or more non-hierarchical "compartment" security attributes, all of which together constitute a sensitivity security attribute.

Classification attributes can specify the overall level of document sensitivity as elements in an ordered set. For example, in government relations, the set of "unclassified", "confidential", "secret", and "top secret" may be appropriate, and in corporate relations, "public", "internal", "confidential", and "registered confidential". "The set may be appropriate.

Compartment attributes specify the relationship between a document or a particular activity within an organization, such as a department's subdivision (eg, Research, Development, Marketing), or a particular project within an organization. obtain.

Each person using the electronic device 600 is assigned a set of allowed sensitivity attributes to specify one or more parts of these documents or a document type by an authorized user. The document or part may be processed in one or more ways by the person's electronics. The sensitivity attribute of a document must belong to a user set of allowed sensitivity values in order to be accessible.

In addition, the organization may wish to allow the user control over certain documents for which the user has a defined responsibility. For example, a user (originating user) may want to impose an "author-controlled" ("ORCON") constraint on a document. The above constraints are placed, for example, so that a document can be transmitted and used only by certain other users specified by that user (and only by certain expressly approved methods). Such restrictions are imposed if the "distribution list" can be modified after the document has been created, especially if someone has requested that the document be transmitted from the creator to a recipient other than the approved recipient's original list. Can be flexible. Outgoing users are allowed to distribute to specific users, specified user groups, specified regions, users authorized to act within specific organizational roles, or any or all of these attributes. You may want to.

In this embodiment, the organization is also more likely that access to the document is restricted as described above, but some or all of the information in the document can be extracted and redistributed without further restriction by the recipient. You may want to allow users to specify weak distribution constraints.

Organizations and / or outgoing users may want to know for what use or where the document is distributed. Organizations may want to know where documents with certain protection attributes are distributed, for example, based on geographic information stored in site configuration records and / or name service records. ..

The user may wish to request a "return receipt" for the distributed document, or how the document is handled by the recipient (eg, viewed, printed, edited). And / or stored), for example, to identify one or more audit requirements (or methods known to have audit requirements) in the PERC associated with the document. Depending on what you may want to know. User environment In an organization (or association) as described above, users may have access to a variety of electronic devices 600 for processing and managing documents. This can include personal computers, powerful single user workstations, and server or mainframe computers that are connected or disconnected from the network. Each electronic device participating in the use and management of VDE protected documents is enhanced by a secure subsystem of VDE that supports SPE503 and / or HPE655 to provide support for the control information described in this example. Can be done.

HPE655 may be sufficient for some organizations with relatively low threats to safe operation. Other organizations (eg government security agencies) may need to adopt SPE503 in all situations where VDE protection documents are processed. Improved environmental and technology choices are different in different organizations. Even if different types of PPE650 are used in an organization to meet different requirements, they can be compatible with each other and work on documents of the same type (or subset of the same type). obtain.

The user may use an application program customized to work with VDE to work with VDE protected documents. Examples of the above application programs may include a VDE-aware document viewer, a VDE-aware email system, and similar applications. These programs make VDE-protected documents available, but their content is copied, stored, viewed, modified, and / or transmitted, and / or distributed outside of certain electronic devices. To limit the degree, it may communicate with the PPE650 component of the user's electronics 600.

Users may wish to employ off-the-shelf (COTS) operating systems and application programs to process VDE-protected documents. One approach to permitting the use of COTS application programs and operating systems is to enable the above use for documentation only, without restrictions on redistribution. The standard VDE operating system redirector allows users to access VDE-protected documents in a manner equivalent to accessing files. However, with such an approach, a chain of controls that weigh and / or audit use can be "broken" to some extent when protected objects become available to COTS applications. VDE's fingerprinting technology can be used to facilitate further tracking of any released information.

Various techniques can be used to protect the printing of protected documents, such as server-based decryption engines, special fonts for "fingerprinting".

Another approach to support COTS software is that COTS operating systems and application programs can run, but no information is permanently stored or transmitted except under the control of a VDE, 1 In order to create the above "virtual machine" environment, VDE software running on the user's electronic device is used. Such an environment may allow VDEs to manage all VDE protection information, but may allow unlimited use of COTS applications to process information within a limited environment. The entire content of such an environment can be treated by VDE100 as an extension to any VDE-protected document loaded into the environment. The transmission of information outside the environment is governed by the same rules as the original document. "Coarse" control capability As mentioned above, organizations may use VDE enhanced control capabilities to manage security, distribution, integrity, and control of the entire document. Some examples of these abilities may include:

1) A communication channel connecting two or more electronic devices 600 may be assigned a set of permitted sensitivity attributes. Only documents whose sensitivity attributes belong to this set are allowed to be transmitted over the channel. This can be used to support the Trusted Computer System Evaluation Criteria (TCSEC) Device Labels requirement.

2) Writable storage devices connected to or embedded in electronics 600 (eg, fixed disks, diskettes, tape drives, optical disks) may be assigned a set of allowed sensitivity attributes. Only documents whose sensitivity attributes belong to this set are allowed to be stored on the device. This can be used to support the TCSEC Device Labels requirement.

3) The document may have a list of users associated with the document, representing the users who are allowed to "handle" the document. This user list may represent, for example, only users who can view the document. Other users cannot manipulate the content, even if they receive the document container. This can be used to support standard ORCON handling warnings.

4) A document may have attributes that require explicit permission from the author to specify its author and allow the content of the document to be viewed. A request for this permission can be made when a document is accessed by a user, or when, for example, one user distributes the document to another. Without permission, the document cannot be manipulated or used.

5) A document may have attributes that require each use of the document to be reported to the author of the document. This can be used by authors to gauge the distribution of documents. If necessary, it may be necessary for the report to be well done before any use of the document is allowed to ensure that its use is known to the controlling party at the time of use. Alternatively, for example, the report may be made in a deferred ("batch") format.

6) The document may have attributes that require each use of the document to be reported to the Central Document Tracking Information Exchange. This is to track a particular document, to track a document with a particular attribute (eg sensitivity), to identify a document used by any particular user and / or user group, and so on. , Can be used by tissues. If necessary, for example, it may be necessary for the report to be successful before any of the documents are allowed to be used.

7) A VDE protected document may have attributes that require each use of the document to generate a "return receipt" to the author. The person using the document asks a specific question in order to generate a return receipt, for example, by showing why the document is interesting, or by showing knowledge (after reading) about the return receipt of the document content. It may be necessary to answer. This can be used to ensure that the document was handled by a person rather than by an automated software mechanism.

8) The content of the VDE-protected document may be made available to application programs that do not recognize VDE so that it is identifiable (traceable) to the user who released the content in a unique manner. Therefore, even if the released form of the document is further distributed, its source can be determined. This can be done by adopting a VDE "fingerprint engraving" for content release. Similarly, a printed VDE-protected document, even if copied, can be marked in a unique VDE-fingerprinted format so that the person who originally printed the document can be determined.

9) Use of VDE-protected documents may be permitted under budgetary control that restricts access to the document content or other use of the above content (based on size, access time, etc.). This can help prevent large-scale disclosure by limiting the number of VDE documents accessible to an individual during a fixed period. For example, one such control allows a user to view up to 100 pages a day but print only 10 pages a day for some particular classification level document, printing at 9am on weekdays. It is allowed only from 5 o'clock to 5 o'clock. As a further example, the user has a certain amount of logic in the use of VDE protected documents, for example (under normal or any reasonable circumstances) to identify that one or more types of excess database usage has occurred. It may be limited to relatively "consecutive" and / or some other pattern that is relevant in relation to the subject, such as limiting the use of database records based on the amount of records that share an identifier in the field. As a result, VDE content providers can limit the use of VDE content to acceptable usage characteristics, such as attempts by users to improperly use information database resources (eg, for VDE administrators or organizational supervisors). Can be prevented and / or identified (by generating an exception report).

These controls provide some examples of how VDE can be used to provide a flexible and interactive environment for tracking and managing sensitive documents. Such an environment can trace the flow of documents from person to person directly, by physical location, organization, and so on. It also allows you to answer specific questions such as "Which person outside the R &amp; D department received the R &amp; D controlled document?" Tracking can be immediate and accurate, as control information can be transmitted with each copy of the VDE protected document to ensure that the central registry is updated and / or the author is informed of the use of the document. Can be.

This contradicts traditional means of tracking paper documents. According to conventional means, a paper-based system of receipts that is typically collected and handled manually is used. Documents are individually copy-numbered and signed, but once distributed, they are not actively controlled. In traditional paper-based systems, it is practically impossible to determine the actual location of a document. What control can be shown can only be determined if all parties strictly adhere to the handling rules (which are inconvenient at best).

The above situation is not very convenient for processing documents within the context of normal computer and network systems. The systems can enhance access control information based on user identity and can provide auditing mechanisms for tracking access to files, but these are low-level mechanisms that do not allow tracking or control of content flow. In such a system, it is not possible to determine where or where the document content came from, as the document content can be freely copied and manipulated. Moreover, while the controls within a normal computer operating system operate at an abstract low level, the operating system-controlled entities are not necessarily the same as the user-operated entities. This in particular confuses audit tracking with a large amount of information describing activities that are not of interest. "Fine" control ability In addition to controlling and managing the entire document, users may employ customized VDE-aware application software to control and manage individual modifications of the document. Examples of these abilities include:

1) VDE Content Users may be allowed to add more information to the VDE document to indicate the proposed alternative wording. This proposed change is visible to all other users of the document (in addition to the original text), but can only be incorporated into the actual text (for example) by the owner of the document.

2) VDE user groups may be allowed to modify one or more parts of a document in such a way that individual changes can be clearly traced to the particular user who made it. The right to modify certain parts of a document, and the extension of different sets of rights to different users, allows an organization or secure environment to provide different permissions that give different rights to users of the same content.

3) User groups can create VDE documents in a way that increases in volume by building them from individual contributions. These contributions can be grouped together within a single controlled document, but each contribution is individually identified, for example by being embedded within the VDE content container as an embedded container object.

4) VDE control and management capabilities can be used to track activity associated with individual document areas, for example recording how many times each section of a document has been viewed. Example: VDE protected content storage location With the advent of "digital highways," there will be more debate about the distribution of content on networks, especially public networks such as the Internet. Content may be made available via public networks in several ways, including:

To "email" content to users on request or in response to prior purchases (sending tokens representing electronic fund or credit debt to purchase goods).

Support content that can be downloaded from the organization's own content storage location. Such storage locations include, for example, a large number of products (such as software programs) and / or a large amount of information resources that are typically organized in one or more databases.

Supporting public storage locations where other parties can deposit products for redistribution to customers (usually done by making electronic copies for distribution to customers in response to requests. ).

One possible VDE node involves the use of one or more "storage locations". For example, the storage location can act as a location from which VDE participants can search for VDE content containers. In this case, the VDE user may use the network to gain access to a "server" system that allows one or more VDE users to access the object storage location that contains the VDE content container.

Some VDE participants create or serve content and / or VDE content container objects, after which other participants access known and / or effectively organized locations (for search). Content and / or content objects may be stored in the storage location as obtained. For example, VDE storage locations (part of VDE storage locations, multiple VDE storage locations, and / or providers of content to such storage locations) are of a type by sending an email to a list of network users. Can advertise that VDE protected content is available. If the network user has a secure VDE subsystem in the electronics, the network user may choose to access such storage location directly or through one or more smart agents. The network user then browses (and / or electrically searches) the offer of VDE-managed content available at the storage location, for example using an application program, downloads the desired VDE content container, and such container. Can be used. If the storage location successfully attracts users who are interested in such content, the VDE Content Provider determines that such storage location is the preferred location for making the content easily accessible to the user. Can be done. When a storage location such as CompuServe stores content in an unencrypted (plaintext) form, the storage location "sends" by putting the "send" content within the VDE content that has the desired control information. Content can be encrypted "as needed" and VDE's secure communication technology can be adopted to communicate the content to VDE participants.

The VDE storage location may also provide other VDE services. For example, a storage location may choose to provide financial services in the form of credits from the storage location, which can be used to pay fees associated with the use of VDE objects obtained from the storage location. Separately or in addition to this, the VDE storage location is on behalf of the VDE Creator or other participants (eg, Distributor, Redistributor, Client Administrator, etc.) with respect to usage information reported by the VDE User. Audit information exchange service can be provided. Such services may include analyzing such usage information, producing reports, collecting fees, and so on.

A "full-service" VDE storage location can be very attractive to both providers and users of VDE-managed content. Providers of VDE-managed content may wish to place the content in a location familiar to the user, provide credit, and / or provide audit services for the user. In this case, the provider will go through administrative processes related to making the content available in a "retail" fashion, collecting audit information from many VDE users, sending invoices and receiving fees, etc. You can focus on creating content rather than overseeing it. VDE users can understand that the convenience of a single location (or multiple storage locations arranged together) is appealing when trying to find content that interests them. In addition, the full-service VDE repository is for reporting usage information resulting from the use of VDE-managed content received from the VDE repository and / or for example updated software (eg, VDE-aware applications, load modules, component assemblies). , Non-VDE-aware applications, etc.) can act as a single location to receive. The VDE Storage Services are broadcast and / or CD-to configure an integrated array of content resources that can be browsed, searched, and / or filtered to meet the content needs of VDE users. Can be used with VDE content delivery on physical media such as ROM.

Public storage systems can be established and maintained as non-profit or commercial services. The organization providing the service may charge the service fee for each content to the user, for example on a transaction basis and / or on a percentage basis of the fee and / or at the user's expense. Storage services may provide content creators, publishers, distributors, and / or value providers with VDE writing tools, and the rules and controls that govern some or all of the guidelines for those above to control the use of content. Is now available to put such content into a VDE content container object.

The storage location may be maintained in one location or distributed to various electronic devices such as various servers (such as video servers) that are in different locations but can constitute a single resource. .. The placement of the VDE storage location may employ secure communication of the VDE and a secure subsystem of the VDE node (The Processing Environment of the Protection Division). Content that includes a given chunk or unit of information that the user wants can be scattered across various physical locations. For example, content that describes a company's closing price and stock activity (bids, lows, highs, etc.) is World Wide in New York. Content that resides on a web server and represents a company's analysis (corporate history, personnel, products, markets, and / or competitor considerations) can be located on a Dallas server. Content may be stored using the VDE mechanism for secure use and auditing. Content is well available on one or more of these sites in other forms of security (eg, physical security, passwords, protected operating systems, data encryption, or other technologies suitable for a content type). If so, it can be maintained in a clear form. In the latter case, the content is at least partially encrypted and placed inside the VDE container when it is sent out of the storage location, which enables secure communication followed by VDE user usage control and usage result management. To do.

The user may request information about the company, including stocks and other information. This request can be routed, for example, first through a directory or a more sophisticated database deployment located in Boston. This arrangement contains pointers to both New York and Dallas storage locations, and content can be retrieved from both storage locations. This information content can be routed directly to users in, for example, two containers (eg, a VDE content container object from Dallas and a VDE content container object from New York). These two containers may form two VDE objects within a single VDE container when processed by the user's electronics (the single VDE container above is the content from Dallas and New York respectively). Can contain two content objects including). Instead, such objects can be integrated together to form a single VDE container in Boston, which allows information to be delivered to the user in a single container, simplifying registration and control at the user site. To become. Information content from both locations may be stored as separate information objects or grouped together as a single integrated information object (a field and / or category of an information form or template may be: One resource can be filled and other fields and / or categories can be filled with information provided by different resources). The distributed database manages such a distributed storage location resource environment to secure the storage, transmission, auditing and / or use of information through the electronic implementation of VDE-controlled VDEs. Can be used. In this case, VDE can be used to provide both a consistent content container and content container service.

An example of one possible storage location 3300 is shown in Figure 78. In this embodiment, storage location 3302 is connected to network 3304, where authors 3306A, 3306B, 3306C and 3306D, publisher 3308, and one or more end users 3310 communicate with storage location 3302 and each other. Allows you to communicate. The second network 3312 allows publishers 3308, authors 3306E and 3306F, editors 3314, and librarians 3316 to communicate with each other and with local storage 3318. Publisher 3308 is also directly connected to author 3306E. In this example, the author 3306 and the publisher 3308 are connected to storage location 3302 to place the content in an environment where the end user 3310 can access a wide range of content from a common location.

In this embodiment, the storage location has two main functional areas: a content system 3302A and an information exchange system 3302B. The content system 3302A includes a user / author registration system 3320, a content catalog 3322, a search mechanism 3324, a content storage unit 3326, a content reference 3328, and a transmission system 3330. The sending system 3330 includes a control packager 3322, a container packager 3334, and a trading system 3336. The information exchange system 3302B includes a user / author registration system 3338, a template library 3340, a control structure library 3342, a distribution system 3344, an approval system 3346, a billing system 3352, and an audit system 3360. Approval system 3346 includes financial system 3348 and content system 3350. The billing system 3352 includes a paper system 3354, a credit card system 3356, and an electronic fund transfer system (EFT) 3358. The audit system 3360 includes a receipt system 3362, a response system 3364, a trading system 3366, and an analysis system 3368.

In this example, Author 3306A electronically creates content that Author 3306A intends to make widely available to many end users 3310 and to protect his rights through the use of VDE. Author 3306A indicates a desire to transmit a message to storage location 3302 and register it in storage location for distribution of his content. In response to this message, the user / author registration system 3320 of the content system 3302A and the user / author registration system 3338 of the information exchange system 3302B transmit a request for registration information to the author 3306A using the network 3304. These requests may be made in online interactive mode or transmitted to author 3306A in batch format. Author 3306A then completes the requested information and transmits it to storage location 3302 in batch format. Alternatively, some aspects may be treated online (as basic identifying information) and other information may be exchanged in batch format.

Registration information related to the content system 3302A includes, for example:

A request that author 3306A should provide information about the type and / or category of content proposed to be stored and accessed using the storage location.

Other forms of identifying information required by the abstract and / or storage location. This is because the author 3306A generally takes advantage of other information (promotional material, detailed information about the format of the submitted content, users who may use the submitted content) along with the content submission. In addition to giving an opportunity to indicate whether it includes equipment conditions that must or must be met in order to.

Regarding where the content is located (whether it is stored in a storage location, in the location of author 3306A, somewhere else, or in multiple combined locations), author 3306A Request to get information from.

Which common search characteristics should be associated with content submission (eg, whether abstracts are automatically indexed so that users in the storage location can search, content titles, abstracts, promotional materials. , Relevant dates, performer and / or author names, or other information related to content submission can or should be used in and / or in response to searches in the content typelist, etc. ). And / or How content stored in and / or passing through the storage location should be sent out (container standards, encryption conditions, transaction conditions, other control standards, etc. for content transmission).

The information requested by the author 3306A by the information exchange user / author registration system includes, for example:

VDE templates that author 3306A can or must use to accurately format control information. The format is such that, for example, the audit system 3360 of the information exchange system 3302B is properly authorized to receive and / or process usage information related to the content submitted by author 3306A.

In part or all of the VDE component assemblies created and / or used by author 3306A in connection with the submitted content, it may or must be used (and / or included for reference) by author 3306A. VDE control information available from Information Exchange 3302B (which may or must be included).

A form in which any fund distribution related to the use of the content provided by, through, or collected by the Storage Location Information Exchange System 3302B should be made.

Forms and / or criteria that authorize the use of submitted content and / or financial transactions related to the content.

An acceptable form of billing for the use of Content and / or content-related information (such as analytical reports that may be used by others).

How should the audit information generated by VDE be received?

How to manage the response to the request from the user.

How transactions related to the receipt of audit information should be formatted and approved.

What form of analysis should be performed on usage information. And / or If there is a situation in which usage information and / or analysis results from VDE control content usage information should be managed, what is the situation (who can or must be delivered)? Whether or not, the form of delivery, any control information related to the use of such information, etc.).

Storage location 3302 receives the completed registration information from author 3306A and uses this information to create an account profile for author 3306A. In addition, software related to the writing process may be transmitted to author 3306A. This software allows, for example, author 3306A to place content within a VDE content container with proper control. Proper control means that many of the decisions associated with creating such containers are automatically made to reflect the use of storage location 3302 as a content system and / or information exchange system. (The above decisions are, for example, the location of the content, the content and / or the party to contact to update the control associated with the content, the party to which audit information can and / or must be transmitted and this. Communication channels for such communications, the characteristics of audit information collected during use, acceptable forms of payment for the use of content, how often audit transmissions are required, how often billing, content-related abstracts. And / or other forms of identification information, the nature of at least a portion of the content usage control information, etc.).

Author 3306A uses the VDE authoring application to identify the controls and content he wants to put inside the VDE content container and creates such a container, depending on any requirements of storage location 3302. .. The VDE-authored application can be, for example, an application provided by the storage location 3302, which can help ensure that the storage location content control conditions are adhered to. The above control conditions are one or more types of component assemblies or other VDE control structures and / or required parameter data, applications received from another party, and / or created by author 3306A in whole or in part. For example, include the application that was used. Author 3306A then uses network 3304 to transmit the container and any deviations from the author 3306A's account profile that may be related to the content to storage location 3302. The storage location 3302 receives the submitted content and then, in this embodiment, the content is within the content and / or storage location control information conditions, depending on some account profile conditions, deviations and / or desired options. Determines whether it was created in, and therefore whether it should be placed in the content storage or referenced by a location pointer or the like. In addition to placing the submitted content within the content storage or referencing the location of such content, storage location 3302 also includes search mechanism 3324, content reference 3328, sending system 3330, and / or information exchange. Note the characteristics related to the above submitted content within the system related to the template and control structure, approval, billing and / or payment, distribution, and / or usage information of the system 3302B.

During the writing process, author 3306A may use the VDE template. Such templates can be used as an aspect of VDE writing applications. For example, such a template can be used in building a container as described above. Alternatively or additionally, such a template may also be used when the submitted content is received at storage location 3302. References to such templates can be incorporated by author 3306A as part of building a container for submitted content. (In this sense, a container delivered to a storage location can, in a sense, be "incomplete" until the storage location "completes" the container through the use of the indicated template.) References may be needed for use by storage location 3302. (Use by storage location 3302 is, for example, to put VDE control information in place to meet one aspect of the storage location business or security model. One aspect of the storage location business or security model is. For elements of content needed to interact with other VDE control structures to provide control related to certain weighing, billing, budgeting, and / or other uses and / or distribution of storage locations. Corresponding one or more map tables, etc.) For example, if the content submitted by author 3306A consists of periodicals, the template delivered to the author by storage location 3302 when the author registers in the storage location will be such a periodical by the author. It can be used as an aspect of a writing application that is manipulated when creating a VDE content container for. Templates designed to be used in alternatives or in addition to periodicals may be in storage location 3302, such templates as a whole or part of the control structure associated with the container. Can be used by the storage location to define the template. For example, a VDE template designed to assist in forming a control structure for a periodical may (especially) indicate:

Usage control should include a meter method that records each article in the publication opened by the user.

In order to open a periodical, a fixed flat rate should be applied regardless of the number of articles opened. And / or A record of all ads viewed by the user should be maintained.

If the content is maintained in a known and / or identifiable format, such a template identifies any map table that may be needed to support such recording and billing practices. Because of this, it can be used during the initial construction of the container without the intervention of author 3306A. If such a VDE template is not available to author 3306A, author 3306A reconstructs the submitted container by storage location to contain the VDE control information specified in a template or a classification level template (eg). , Can choose to indicate that it should be increased. If the format of the content is known and / or identifiable by the storage location, the storage location may be able to automatically reconstruct (or "complete") such a container.

One factor in the potential financial relationship between the storage location and author 3306A may be related to the use of the submitted content by the end user 3310. For example, author 3306A states that the storage location is a storage location service (eg, making content available to end users 3310, providing electronic credits, performing billing activities, collecting fees, etc.). In exchange for maintaining, you may negotiate an arrangement with a storage location that allows you to secure 20% of the total revenue generated by the end user 3310. Financial relationships can be recorded within the control structure in a flexible and configurable way. For example, the financial relationships mentioned above reflect the financial terms of author 3306A and the need to separate revenue from storage location for 20% VDE container and / or Can be created within the installation control structure. In the above case, all billing activity related to the use of the submitted content can be processed by the storage location, and iterative methods related to the various component assemblies required to use the submitted content of author 3306A. A control structure representing can be used to calculate 20% of revenue. Alternatively, the storage location may independently and safely add and / or modify the control structure from author 3306A to reflect rising prices. In some cases, author 3306A may not be directly involved (or do not know the actual price) of the actual price that the storage location imposes on the activity used. Author 3306A is only interested in the amount of revenue and the characteristics of the usage analysis information that Author 3306A identifies for his own purposes within the VDE control information that governs the use and outcome of the use of the VDE control content. It is possible that there is.

Another aspect of the author-retention relationship may include the characteristics of transaction recording conditions related to the delivery of VDE-controlled content and the receipt of VDE-controlled content usage audit information. For example, author 3306A may require the storage location to keep a record of each user who receives a copy of the content from the storage location. Author 3306A may also need a collection of information about the environment for delivering content to such users (eg, time, date, etc.). In addition, the storage location may choose to make such transactions for internal use (eg, determining usage patterns for optimizing the system, detecting fraud, etc.).

In addition to recording information regarding the delivery of such VDE-controlled content, author 3306A may have required or required that the storage location undergo some sort of VDE container-related process. For example, author 3306A may wish to deliver different abstracts and / or other descriptive information to users at different classification levels. In addition, Author 3306A may wish to deliver promotional material in the same container as the submitted content, for example, depending on the characteristics of use presented by a particular user (the above characteristics of use are, for example, eg. Whether the user has ever received content from author 3306A, whether the user has subscribed to author 3306A's material well, and / or promotional material delivered to certain VDE content end users. Author 3306A and / or other patterns that may be relevant to the end user, used to assist in determining the mixture). In another embodiment, author 3306A may require VDE fingerprinting on such content before it is transmitted to the end user.

In addition to the form and / or characteristics of the content delivered to the end user, the author may also require that certain encryption-related processes be performed by the storage location as part of the delivery of the content. For example, author 3306A said that the storage location required each copy of the content to be sent out to be encrypted with a different encryption key to help maintain better protection of the content. It is possible. (Better protection of the content above means that, for example, if an encryption key is "cracked" or misdisclosed, its "damage" can be limited to a portion of a particular copy of some deliverable content. In other embodiments, the cryptographic function needs to use completely different cryptographic algorithms and / or techniques to meet environmental requirements (eg, to comply with restrictions for export). May include. In yet another embodiment, the encryption-related process modifies the encryption technique and / or algorithm based on the reliability and / or non-tamperability level of the VDE site to which the content is delivered. Can include.

In addition to the transaction information collected when content is sent from the VDE storage location to the end user, the storage location is associated with usage information, requests, and / or responses from and / or end user 3310 to end user 3310. It may be necessary to retain transaction information. For example, author 3306A ends in connection with the transmission and reception of information about the use of author 3306A's content (eg, end-user reports of audit information, end-user requests for additional authorization information, etc.). It may be necessary to keep a record of some or all of the connections made by user 3310.

Some of the VDE-managed content provided to the end user 3310 via the storage location may be stored in the content storage. Other information may be stored elsewhere and referenced via a content reference. When a content reference is used, the storage location is consistent, for example, with the content of all storage locations, whether stored in the content storage or elsewhere (such as another site). Alternatively, the user interface may be managed as presented to be selected by the end user 3310 in a uniform manner, such as the same user interface. When the end user requests delivery of content that is not stored in the content storage, the VDE storage location is the information stored in the content reference (eg, the network address where the content can be located, the URL, the file system reference, etc.). ) Can be used to find the actual storage site for the content. After the content is found, the content may be transmitted over the network to the storage location, or may be transmitted directly from the storage location to the requesting end user. In some situations (eg, when a container needs to be modified, encryption must be changed, financial transactions are required prior to release, etc.), such VDE managed content and / or VDE content. Further processing by the storage location may be required to prepare the container for transmission to the end user.

It provides a manageable user interface to the content available to the end user 3310 of the VDE storage location and provides management information used in determining the control information packaged within the VDE content container sent to the end user 3310. Therefore, the storage location of this embodiment includes the content catalog 3322. This catalog is used to record information related to VDE content within the content storage and / or content available through the storage location reflected in the content reference. The content catalog 3322 may consist of content titles, abstracts, and other identifying information. In addition, the catalog may also be in the form of an electronic contract and / or contract VDE template application (one or more opportunities to provide optional selectable control structures and / or associated parameter data). The contracts and applications are available to the end user 3310 via a storage location for a given content, for example in determining options and / or requirements for: Which type of information is recorded during the use of the content, the amount charged for the activity of using the content, whether the usage information was recorded and / or whether it is available to the storage location and / or the content provider. Differences in billing amounts based on, rights to redistribute in connection with such Content, reporting frequency of audit transmissions, forms of credit and / or currency that may be used to pay any fees associated with the use of such Content, Discounts related to the use of a certain amount, discounts, sales, etc. available due to the existence of rights related to other content from the same and / or different content providers. In addition, the VDE Content Catalog 3322 may show some or all of the component assemblies required to utilize the content. Content is a message between the end user's system and storage location

In this embodiment, in order to use the VDE storage location, the end user must register in the storage location. In the case of the author, in a manner similar to that described above, the VDE end user transmits a message from his VDE installation to the storage location over the network, and the end user provides a service provided by the storage location (eg,). Indicates that you want to use (such as accessing content stored in and / or referenced by the storage location, using credits provided by the storage location, etc.). In response to this message, the user / author registration system of the storage location content system 3302A and the user / author registration system of the information exchange system 3302B request information from the end user (eg, online and / or). Transmit (by batch interaction). The information requested by the user / author registration system of the content system 3302A may include the type of content the user wants to access, the characteristics of the user's electronic device 600, and the like. The information requested by the user / author registration system of the information exchange system 3302B is whether the user wants to establish a credit account with the information exchange system 3302B, what other users are for billing purposes. Users regarding their preference for the release and handling of usage analysis information, whether they want to use credit forms, what other information exchanges may be used by end users while interacting with content obtained from the storage location. Can include any general rules established by. Once the end user completes the registration information and transmits it to the storage location, the storage location can build the user's account profile. In this embodiment, such requests and responses are handled by secure VDE communication between the secure VDE subsystems of the sending and receiving parties.

To take advantage of the storage location, the end user may run the application software. In this embodiment, the end user may use a standard application program (eg, a World Wide Web browser such as Mosaic) or use the application software provided by the storage location after the registration process is complete. May be good. If the end user chooses to utilize the application software provided by the storage location, it may be possible to avoid some complexity of the interaction that would occur if the standard package was used. Standard packages are often relatively easy to use, but customized packages that incorporate VDE recognition can provide a more user-friendly interface. In addition, certain characteristics of the storage location may be incorporated into the interface to simplify the use of the service (eg, similar to the application program provided by America Online).

The end user may connect to the storage location using a network. In this embodiment, the authentication process occurs after the user connects to the storage location. Is this process done by the user (eg, through the use of login and password protocols) or is it established by a secure subsystem of the end user's electronics that interacts with the storage electronics in VDE authentication? Can be done by either. In either case, the storage location and the user must first make sure they are connected to the correct other party. In this embodiment, when secure information flows between the two parties, VDE secure authentication must occur and a secure session must be established. On the other hand, if the information to be exchanged is already secure and / or available without authentication (eg, some catalog information, a container that is already encrypted and does not require special treatment. Etc.) may use a "weaker" form of login / password.

Once the end user connects to the VDE storage location and authenticates, the user interacts with the user interface software to view the storage location's content catalog 3322 (eg, a list of publications, software, games, movies, etc.). Browse, find content of interest with the help of search mechanisms, schedule content delivery, query account status, availability of usage analysis information, billing information, registration and account profile information, and more. If the user is connected to acquire the content, the terms of use for that content may be delivered to the user. If the user is connected to deliver usage information to the storage location, information about that transmission may be delivered to the user. Some of these processes are described in more detail below.

In this embodiment, when the end user requests content from the VDE storage location (eg, by selecting from a menu of available options), the content system 3302A will have the content in either the content reference and / or the content storage. Find out. The content system 3302A then refers to the information stored in the content catalog 3322, the end user's account profile, and / or the author's account profile to create a VDE content container to meet the end user's requirements. Determine the exact nature of the container format and / or control information that may be required for. Whether the transaction or transaction can then be processed by the sending system accessing the information exchange system 3302B to collect any additional control structures that should be contained in the container and deliver the content to the end user. Determine the characteristics of the author and / or end user account profile that can affect either. If the transaction is approved and all the elements required for the container are available, the control packager will form a package of control information suitable for the end user's request, and the container packager will package and content this control information. Form the appropriate content (including permissions that can be delivered with the container, incorporating any cryptographic conditions, etc.). Transactions related to content delivery are recorded by the sending system's trading system, if required by the storage location or the author's account profile. When the container and any transactions related to delivery are completed, the container is transmitted over the network to the end user.

The end user may use the credit and / or currency securely stored in the end user's secure subsystem with VDE installed to pay the billing amount associated with the use of the VDE Content received from the storage location. .. And / or the user may maintain a secure credit and / or currency account in a remote storage location, including a "virtual" storage location where payments are made by the end user to receive the Content. The latter approach provides greater guarantees for storage locations and / or payments to content providers, especially if the end user has only an HPE-based secure subsystem. In this embodiment, if the end user's electronic credit and / or currency account is maintained in the storage location, the account will be charged based on the end user receiving content from the storage location. Further charges for such remote end-user accounts may be based on the end-user use of the received content and on the content usage information communicated to the storage location information exchange system 3302B.

In this embodiment, the end user authorizes (a content provider whose content can be acquired through the use of storage locations to use currency and / or credits to pay usage fees associated with the provider's content. If you have not established a relationship with a financial provider and / or the end user wants a new source of such credit, the end user will request credit from the storage location information exchange system 3302B. Can be done. If the end user is granted credit, the storage location grants credit in the form of a credit amount associated with the budget method managed by the storage location (eg, recorded in one or more UDEs). Periodically, usage information related to such budget methods is transmitted by the end user to the storage location audit system. After such transmission (but possibly before disconnection), the amount of credit is recorded for processing by the billing system and is available to the end user, depending on the business practice of the storage location. The amount can be replenished with the same or subsequent transmission. In this embodiment, the storage location information exchange has a billing system based on a paper system that collects the credit amount via e-mail, a credit card system that collects the credit amount by charging one or more credit cards, and a bank. Supports an electronic fund transfer system that collects credits by debiting directly from your account. The storage location may automatically make payments determined by the distribution system for the amount owed to the author by using similar means. Further details regarding the audit process are given below.

As described above, the end user 3310 in this embodiment periodically contacts the VDE storage location to transmit content usage information (eg, regarding budget consumption, recording of other usage activities, etc.) and budget. To replenish, modify account profiles, access usage analytics information, and perform other administrative and information exchange activities. In some cases, the end user may want to contact the storage location for further control structure. For example, if an end user requests and obtains a VDE content container from a storage location, that container will typically be for content, author terms and account profiles, end user account profiles, content catalog 3322, and / or delivery. Delivered to end users along with environment-friendly control structures (delivery environments are, for example, first delivery from a particular author, subscription, promotion, presence and / or absence of certain advertising material. , Requests made for the user by the user's local VDE instance, etc.). In this example, some containers were not expected to be done by the end user (and other criteria), even though the containment location could have attempted to deliver all relevant control structures. Could include a control structure that can afford to add options that the end user nevertheless wants to do (which did not automatically choose to include in the container). In this case, the end user may wish to contact the storage location and request additional control information (including, for example, the control structure) needed to utilize the content under such options.

For example, an overall control structure that includes an option for the end user to record the number of times a type of access has been made to the container and the basic usage charges for such access. Allows end users to pay for access to a particular container based on the time spent using the container's content by acquiring a VDE content container with And further, if the end user did not originally receive control to support the use of the latter form, the storage location may deliver such control later, i.e. when requested by the user. In another embodiment, the author has a control structure that the user can or must receive in order to use a content container with a modified control structure (eg, sales, new discount model, modified business strategy). It may have been changed (to reflect such things). For example, one or more control structures associated with a VDE content container may require a "refresh" to subsequently approve such a structure, or the control structure may expire. obtain. This allows the VDE content provider (if desired) to modify and / or add VDE control information at the end user's site on a regular basis (using a secure subsystem of the local VDE). To do.

The audit information (for the use of content received from the storage location) of this embodiment is safely received from the end user 3310 by the receipt system 3362 of the information exchange. As mentioned above, this system may process audit information, send some or all of the output of such processing to the billing system, and / or transmit such output to the appropriate content authors. .. The transmission of such audit information uses a secure VDE passage that reports information handling techniques. Audit information is also sent to the analysis system to generate analysis results of the use of end-user content for use by end-users, storage locations, third-party market researchers, and / or one or more authors. Can be sent. The results of the analysis are a single audit transmission, part of the audit transmission, a collection of audit transmissions from a single end user and / or multiple end users 3310, or the subject of analysis (eg, a given content element or element). It can be based on some combination of audit transmissions based on the usage pattern of a collection of, the usage of a category of content, payment history, demographic usage patterns, etc. Requested and / or required by the end user to send information to the end user, for example to replenish the budget, deliver usage controls, update authorization information, and interact with the information exchange. Response system 3364 is used to transmit certain other information and / or messages that have been made. While the end user connects to and transmits the information exchange, certain transactions (eg, time, date, and / or purpose of connection and / or transmission) are recorded by the audit system's transaction system, thereby. Reflect storage location and / or author requirements.

Certain audit information may be transmitted to the author. For example, the author 3306A may need to transmit certain information gathered from the end user to the author 3306A without being processed by the audit system. In this case, the fact of transmission is recorded by the audit system, but author 3306A does not allow (or allow) the location to access, process, and / or use this information. In addition to) it is possible that the author chose to perform his own usage analysis. In this embodiment, the storage location is in the storage location budget generated by payment of fees for the use of the content provided by author 3306A received from one or more end users 3310. Some of the relevant usage information may be provided to Author 3306A. In this case, author 3306A analyzes usage patterns by comparing certain usage information related to the content with usage information about the storage location budget for the content (eg, analyzing usage in terms of pricing). , Detect potential scams, generate user profile information, etc.). The usage fees collected by the Information Exchange to be paid to Author 3306A in connection with the Content of Author 3306A are determined by the Information Exchange's distribution system. The distribution system may include (in complete or in summary form) usage information regarding payments to author 3306A resulting from such a decision. Such payment and information reporting is a fully automated process that takes place within the VDE pathway leading from the end user's VDE secure subsystem to the information exchange's secure subsystem to the author's secure subsystem. It can be a sequence.

In this embodiment, the end user 3310 transmits VDE authorization and / or other control information to storage location 3302 to allow access to usage information collected by the audit system used by the analytics system and / or Ban. This may, in part, help guarantee the end user's right to privacy in connection with the use of such information. Some containers may require that usage information be made available to end users for analytical purposes as part of the control structure. Other containers give end users the option of allowing usage information to be used for analysis or prohibiting such use of such information partially or entirely. Some users may choose to allow the analysis of certain information and prohibit permission for other information. In this embodiment, the end user 3310 may choose, for example, to limit the granularity of the information that can be used for analytical purposes (eg, the number of movies the end user has watched over a period of time. It is possible that the analysis is allowed but not the use of certain movies, the end user may allow the release of the ZIP code for artificial statistical analysis but not the use of names, addresses, etc. Get, etc.). The author and / or storage location 3302 may choose to charge a lower fee to the end user 3310, for example, if the end user agrees to release some usage information for analytical purposes.

In this embodiment, storage location 3302 may receive content created by more than one author. For example, author B, author C, and author D may each create a portion of the content delivered to end user 3310 within a single container. For example, author B creates a reference work, author C creates a comment for author B's reference work, and author D creates a set of illustrations for author B's reference work and author C's comment. possible. Author B combines the content of author C and author D to add additional content (eg, the reference work above), puts such content in a single container, and the single container is the storage location. It is possible that it will be transmitted to 3302. Alternatively, each author may transmit his or her own work separately to storage location 3302. In that case, indicate that the template should be used to combine the author's respective work before sending the container to the end user. Further instead, a container that reflects the entire content structure is transmitted to storage location 3302, and some or all of the content is delivered to storage location 3302 for storage within the content storage. , May be referenced in the content reference.

When end users utilize container content, content usage information can be separated, for example, according to a control structure that systematizes usage information based on, at least in part, the author who created the segment. Alternatively, the author and / or VDE storage location 3302 may negotiate one or more other technologies that securely divide and / or share usage information according to VDE control information. In addition, the control structure associated with the container is based on the use of specific parts of the container, the use of the entire container, the specific pages used, or other mechanisms negotiated (or agreed) by the author. It is possible to run a model that varies the usage fees associated with a part. Usage information, analysis results, distribution, and reports of other information exchange processes also agree with the consent reached by participants in storage location 3302 (authors, end users 3310, and / or storage location 3302) with respect to such processes. It can be generated in a format that reflects the content. These consents may be the result of VDE control information negotiations between these participants.

In this example, one type of author is Publisher 3308. In this embodiment, publisher 3308 communicates with a VDE-based local storage location 3302 over an "internal" network and with a public storage location 3302 over the network described above. Publisher 3308 may create or provide content and / or VDE control structure templates delivered to local storage location 3302 used by other participants with access to the "internal" network. These templates can be used to describe the structure of the container and to anyone in the publisher 3308's organization to deliver to storage location 3302 (and / or to publications referenced by storage location 3302). It may describe what actions can be taken with respect to related, content created within the organization. For example, Publisher 3308 may include the structure of the content and the type of information that the periodical may contain (eg, text, graphics, multimedia representation, advertising, etc.), the relative location of the content and / or the order of presentation, of a segment. With respect to length etc., it can be determined to have a certain format (and controlled by using the above template). In addition, Publisher 3308 is, for example, the only party that editors of publications may allow to write to containers, and the librarian of an organization may be the only party that can index and / or abstract content. Can be determined (via the distribution of appropriate permits). In addition, Publisher 3308 may, for example, allow only one or more parties to finalize the container in a form available for delivery to storage location 3302 (eg, the above permission is storage). This is done by maintaining control over the types of permissions, including distribution permissions, that storage location 3302 may need to perform the next distribution activity related to the location's end user 3310).

In this example, the author 3306E is directly connected to the publisher 3308, allowing the publisher 3308 to provide an author template that establishes the characteristics of the container for the content of the author 3306E. For example, if author 3306E creates a book distributed by publisher 3308, publisher 3308 provides control method options for author 3306E selection and provides a VDE control structure for securely distributing the work of author 3306E. You can define a VDE control structure template. Author 3306E and Publisher 3308 may adopt VDE negotiations for template characteristics, specific control structures, and / or parameter data used by Author 3306E. Author 3306E may then use a template to create a control structure for the content container. Publisher 3308 may then deliver these works to Storage Location 3302 under a VDE Extended Agreement that includes an electronic contract between Author 3306E and Publisher 3308, as well as an electronic contract between Storage Location 3302 and Publisher 3308. ..

In this embodiment, Publisher 3308 may also make the work of Author 3306E available to local storage location 3302. The editor authorizes Author F to create a portion of the content of the publication (eg, by distributing appropriate permissions). In this embodiment, the editor may review and / or modify the work of author F and further include it in a container (available at local storage location 3302) with content provided by author 3306E. The editor may or may not be permitted by Publisher 3308 to modify the content of Author 3306E (whether or not it is permitted occurs between Publisher 3308 and Author 3306E. It depends on Publisher 3308's decision to extend such rights to the editor if the negotiations obtained and permission to modify the Content of Author 3306E are retained by Publisher 3308 in a redistributable form). The editor also uses a process that allows the author to write directly to the container, and / or (b) content from other authors by searching the container from the local storage location 3302 for inclusion. May include. Local storage 3302 may also be used for other materials used by the publisher 3308's organization, such as databases, other reference work, internal documentation, draft work for review, training videos, and so on. Such materials may be adopted within the VDE container collection of content created by the editor, with appropriate permission.

In this embodiment, the librarian is responsible for creating and / or editing inverted indexes, keyword lists (eg, from restricted vocabulary), content abstracts, revision histories, and so on. Publisher 3308 may, for example, grant only librarians permission to create this type of content. Publisher 3308 may also require this creation and / or editing to occur prior to the release of content to storage location 3302. Example--Evolution and transformation of VDE managed content and control information The VDE content control architecture allows content control information (such as control information governing content usage) to be formatted to comply with multiple party VDE control information requirements. Forming such multi-party content control information is typically a control that is safely contributed by the parties that play a role in the content handling and control model (eg, content creators, providers, users, information exchanges, etc.). Includes safely extracting control information from information. To combine multiple pieces of separately managed VDE content into a single VDE container object (especially such separately managed content pieces have different, eg, conflicting content control information). In some cases), control information for multiple parties may be required. In order for VDE-managed content pieces to be combined in this way, control information requirements, including rules for any combination of each VDE-managed content piece, are met, and between such multiple control information sets. It often requires the ability of VDE to securely derive content control conditions that reflect an acceptable match.

As a result of the combination of VDE-managed content pieces, a VDE-managed content complex can be generated. VDE-managed content must be executed in response to the content management information associated with the content piece and processed through the use of one or more secure VDE subsystems PPE650. VDE's ability to support embedding or combining VDE-managed content pieces to create combined products with various VDE content pieces allows VDE content providers to optimize VDE electronic content products. .. The combination of VDE-managed content pieces can result in VDE content containers that "hold" separate, nested VDE content containers that occur together and / or at the same time.

VDE's ability to create content containers that hold different pieces of VDE content pieces that were previously managed separately allows VDE content providers to develop their products. The content control information for the above product reflects a value proposition that is consistent with the purpose of the content piece provider and also with the purpose of the content integrator who can create a content combination as a commercial distribution product. .. For example, a content product "sent" to a commercial channel (such as a network storage location) by one content provider may be incorporated into a VDE content container by a different content provider and / or end user (the product from which such inclusion was sent). To the extent permitted by the content control information of. These different content providers and / or end users may, for example, submit different control information that regulates the use of such content. These different content providers and / or end users will also, with appropriate approval, display some parts of the content sent out and the content received (and / or created by themselves) from other parties in different ways. Can be combined to create different content collections.

VDE thus allows copies of a given piece of VDE-managed content to be securely combined into different content integrations. Each of the above integrations reflects the product strategy of different VDE content integrators. VDE's ability to integrate content creates a wide range of competing electronic content. The competing electronic contents may provide an entire different content collection and employ different content control information for content that may be common to such multiple products. Importantly, VDE can safely and flexibly edit the content in the VDE content container, extract the content from the VDE content container, embed the content in the VDE content container, and combine the content in the VDE content container. It is to support shaping and reshaping things. Such capabilities allow the VDE support product model to evolve by sequentially reflecting the requirements of the "next" participant in the electronic commercial model. As a result, a given VDE-managed content can participate in many different content containers and content control information commercial models as it travels through handling and branching aisles.

VDE content and electronic contracts related to such content can be adopted and manipulated in turn in a commercial way that reflects traditional business practices for non-electronic products (VDE is compared to most of these traditional models. Although it supports higher flexibility and efficiency). VDE control information is limited only by VDE control information adopted by content creators, other providers, and other aisles of handling and control participants, the "natural" and unobstructed flow of the electronic content product model and above. Allows you to create models. VDE takes this flow of VDE products and services through a network of creators, providers and users who successfully and securely shape and reshape the product complex through content combination, extraction, and editing within a virtual distribution environment. And provide.

VDE provides a means of securely combining content provided at different times, from different sources, and / or to represent different content types. These content types, timings, and / or different sources can be employed to form complex content arrays within the VDE content container. For example, a VDE content container may include a plurality of different content container objects, each of which contains different content whose use can be at least partially controlled by the owner's VDE content control information set.

VDE content container objects can be "successfully" embedded within a "parent" VDE content container through the use of a secure VDE subsystem. This embedding process involves creating an embedded object, or including a previously separate and currently embedded object within a VDE content container, at least by appropriately referencing the above object as its location.

Content objects embedded within the parent VDE content container (1) Within the VDE safety subsystem PPE650, previously created embedded in a parent VDE content container by securely converting from an independent object to an embedded object by the secure processing of one or more VDE component assemblies. Can be a VDE content container. In this case, the embedded object may be provided for content control information that includes one or more permission records associated with the parent container, but does not have unique content control information that is separate from the content identification information, for example. In some cases, or the embedded object may be more heavily controlled by unique content control information (eg, permission records).

(2) It may contain content extracted from another VDE content container (along with content control information) in the form of an embedded VDE content container object so that it can be applied to inclusion in the parent VDE content container. In this case, extraction and embedding can be safely performed within the VDE-safe subsystem PPE650, and the desired content can be retrieved (or copied) from the source VDE content container and either of such content can be retrieved. It can be done using one or more VDE operations that can be embedded in or will be embedded in the parent VDE content container and can be placed in a new or existing container object.

(3) It can contain content that is created first and then placed in a VDE content container object. This accepting container may already be embedded in the parent VDE content container and may already contain other content. The container in which such content is placed is a VDE-aware application that interacts with the content, and safely creates such a VDE container, and safely puts such a container in the destination parent container. It can be specified with a secure VDE subsystem that places such content in a VDE container after embedding. Alternatively, the content can be specified without using a VDE-aware application and then manipulated with a VDE-aware application to manage the movement of the content to the VDE content container. Such applications can be VDE-aware word processors, desktop and / or multimedia publishing packages, graphics and / or presentation packages, and the like. Such applications may also include operating system features (eg, VDE-aware operating systems or Microsoft. It can be a mini-application that works with O / S, such as a Windows® compatible packaging application), and moving content from "outside" the VDE to inside the VDE object is, for example, a mouse. It can be based on the "drag and drop" metaphor that accompanies "dragging" a file into a VDE container object using a pointing device. Alternatively, the user can "cut" some of the content, first place the content on the "clipboard", then select the target content object and paste that content into such an object. Can be "pasted" into a VDE container. Such processing carries the content under the control of the VDE content control information and the VDE safety subsystem, either by or with the content at a location on the target object, such as the end of the object, or a field identifier. Content can be automatically placed on a part of the object corresponding to the identifier, or the embedding process allows the user to scan and search the content of the target object and / or the content table and / or other directories, indexes, etc. A possible user interface can be popped up. Such processing may further allow the user to make specific decisions regarding VDE content control information that applies to such embedded content (budget limited use, reporting corridors, registration requirements, etc.). And / or with the choice of a particular location to embed the content, all such processing must be done transparently to the extent practically applicable. Content can be automatically placed by or in part of the object corresponding to the identifier carried by or with the content, such as a field identifier, or by its embedding process, the content of the target object and / or a table of content and / Or a user interface that allows the user to scan and search other directories, indexes, etc. may pop up. Such processing may further allow the user to make specific decisions regarding VDE content control information that applies to such embedded content (budget limited use, reporting corridors, registration requirements, etc.). And / or with the choice of a particular location to embed the content, all such processing must be done transparently to the extent practically applicable. Content can be automatically placed by or in part of the object corresponding to the identifier carried by or with the content, such as a field identifier, or by its embedding process, the content of the target object and / or a table of content and / Or a user interface that allows the user to scan and search other directories, indexes, etc. may pop up. Such processing may further allow the user to make specific decisions regarding VDE content control information that applies to such embedded content (budget limited use, reporting corridors, registration requirements, etc.). And / or with the choice of a particular location to embed the content, all such processing must be done transparently to the extent practically applicable.

(4) It can be accessed in conjunction with one or more operating system utilities for embedding and linking objects, such as those according to the Microsoft OLE standard. In this case, the VDE container can be associated with an OLE "link". Access to a VDE-protected container, including reading content from a VDE-protected container and writing content to that container, is the control information associated with the protected content from an OLE-aware application. Can be passed to VDE-aware OLE applications that work with and access that protected content.

VDE-aware applications can also interact with component assemblies within the PPE, allowing direct editing of VDE container content, whether the content is in a parent or embedded VDE content container. It becomes. This can include, for example, the use of a VDE-aware word processor to directly edit (add, delete, or modify) the contents of a VDE container. The secure VDE processing that underlies the editing of VDE container content can be largely or completely transparent to the editor (user), and transparently, the editor can view some or all of the content in the VDE content container hierarchy. It can be safely scanned and searched (using VDE-aware applications), and one or more of the VDE content containers embedded in the VDE content container hierarchy can be safely modified.

The embedding process for all VDE embedded content containers usually involves securely identifying the appropriate content control information for the embedded content. For example, VDE installation and / or VDE content control information for a VDE content container, securely and transparently to the embed (user), one or more parts (eg, all parts) of the pre-"placed" content in the container. The same content control information can be applied to edited (eg, modified or added) container content as it applies to (including) and / or VDE control information between control sets. The control information generated by the negotiation can be safely applied and / or the previously applied control information can be applied to its content. The application of control information can occur regardless of whether the edited content is in a parent or an embedded container. Securely apply content control information (this content control information can be applied automatically and / or unnoticed) This same feature is achieved by extracting and embedding the content of the VDE container object, ie moving the VDE container object. Alternatively, it can be used for content embedded in a VDE container by copying and embedding. The application of content control information is typically secure within one or more VDE safety subsystems PPE650. This process may use a VDE template that allows the user to specify VDE content control information for specific or all embedded content through an easy-to-use GUI user interface tool, with different control functions. An alternative that can be represented by different pictorial (symbolizing) icons and that such functionality can be applied to increments of VDE-protected content, such as embedded objects listed in the object directory display. Menu schemes, such as selecting from control methods (eg, between different metric forms)

Inside a new VDE content container object that is embedded in a parent VDE container by extracting content from the VDE content container, or editing VDE content using a VDE-aware application, or creating VDE content. Content that can be placed is provided. Alternatively, such content may be placed directly in an existing content container. All of these processes can be managed by processing VDE content control information within one or more VDE installation safety subsystems.

The VDE content container object may be embedded in the parent object by the control information referenced by the parent object permission record that reveals the location and / or content of the embedded object. In this case, it may be required that there is little or no modification to the existing content control information of the embedded object. VDE's securely managed content that is relocated to a VDE content container is, for example, encrypted or protected content during the relocation / embedding process (eg, a secure, non-tamperable barrier). It can be relocated by using the safety measures of the VDE subsystem that can continue to maintain the relocated content (by 502).

Embedded content (and / or content objects) can be contributed by different parties, and VDE content and content control information integration securely managed by the use of one or more secure VDE subsystems. By processing, it can be integrated into the VDE container. This process may include, for example, one or more of the items described below.

(1) Securely apply instructions that control embedding and / or use of the presented content, and the instructions have been securely placed in place by the content provider and / or users of its VDE container, at least in part. It is an instruction. For example, the user and / or provider may interact with one or more user interfaces that provide content embedding selection and / or control options (eg, in the form of VDE templates). Such options include any one or more controls of content and / or content control parameter data (previously the content was unavailable, the cost of using the content, and / or a continuous sales discount for the software program. Options for whether or not one or more controls should be applied to one or more parts of the input (such as pricing control parameters) Can include. Once required and / or optional content control information has been established by the provider and / or user, it may be partially or fully automatically applicable to specific or all content embedded in the VDE content container. It can function as control information.

(2) Secure VDE managed negotiation activities, including the use of user interface interactions between the user of the receiving VDE installation and the VDE content control information associated with the content presented for embedding. For example, such related control information may suggest some content information, and the recipient of the content may, for example, receive, select from, reject, provide alternative control information, and / or some content. Apply conditions to the use of control information (eg, one or more when the content is used by one or more users and / or when the usage of the content exceeds a certain level. Can receive control of).

(3) VDE content control information for the received VDE content container and / or VDE installation, and the presented content (control information in the permission record of the contributed VDE object, a component assembly, one or more UDEs and / or MDEs. A secure and automated electronic negotiation process for VDEs with content control information related to (such as parameter data in).

The content embedded in the VDE content container can be embedded in the form of (1) and / or (2) below.

(1) A form of content that is directly and securely integrated into the existing content of the VDE content container (which may be a parent or embedded content container) without forming a new container object. .. The content control information associated with the embedded content must be consistent with any pre-embedded content control information that at least partially controls the establishment of the control information required after embedding. The content control information for the embedded content, which is directly integrated in this way, may be integrated into the control information for the VDE container (for example, one or more permission records containing the content control information). And / or may form part of the control information.

(2) VDE content A form of content that is integrated into a container in one or more objects nested within the container object. In this case, the control information for this content may be carried by the content control information for the parent VDE content container. Alternatively, this control information may be partially or wholly by, for example, one or more permission records contained therein and / or particularly related to one or more content containing nested VDE objects. Can be carried to. Such nesting of VDE content that contains objects within the parent VDE content container may use multiple levels. That is, the VDE content container itself nested in the VDE content container may contain one or more nested VDE content containers.

The VDE content container may have a nested structure containing one or more nested containers (objects). This one or more nested containers (objects) are themselves containers and / or one or more types of content, such as text, images, audio, and / or other types of electronic information. Can include (object content can be specified, for example, by content control information that references a byte offset position on the storage medium). Such content is stored, communicated, and stored in stream form (such as dynamically accumulating and / or flowing) and / or in static form (fixed complete file, such as defined). / Or can be used. Such content is obtained by extracting a subset of the content of one or more VDE content containers, and the resulting one or more VDE content containers are created directly. VDE-secured content is extracted from each of one or more locations within one or more VDE content containers (for example, by using a VDE-aware application or an operating system with extraction capabilities). Can then be securely embedded in a new or existing VDE content container by the process of performing VDE control in the safety subsystem PPE650. Such extraction and embedding (VDE "exporting") involves a VDE exporting system that provides secure protection, including safe execution.

VDE activities related to VDE exporting and embedding involve making one or more conversions of VDE content from one secure form to one or more other secure forms. Such conversion can be done with or without moving the converted content to a new VDE content container (eg, without further VDE processing that suppresses the use of at least one part of the content). The result of the conversion process or other output is not revealed in unprotected form by a component assembly running within the PPE). An example of such a conversion process is that the content information converted on the content information is not retained at all, or a part or all of the content information is retained while the mathematical transformation is performed, and mathematical transformation is performed. It can be accompanied by producing results such as results. Another example of such a conversion is to convert the format of a document (eg Word). Perfect to Word format for Windows® or SGML document to Postscript document conversion), video format modification (eg QuickTime video format to MPEG video format), artificial intelligence processing Includes other processes of doing (for example, creating a summary report by analyzing text) and obtaining VDE-protected content from other VDE-protected content.

FIG. 79 shows an example of an arrangement for a commercial VDE user. The user in this example creates, distributes, redistributes, and uses content with various methods. This example shows how certain aspects of content-related control information can evolve as control information is passed through a chain of processing and control. These VDE users and controls are described in more detail below.

Creator A in this example creates a VDE container and provides relevant content control information (especially), including references to some possible "types" of VDE control information. To help illustrate this example, some of the VDE control information passed to another VDE participant is described in the following more detailed description in three categories: distribution control information, redistribution control information, And group into usage control information. In this example, the fourth category of control information to be embedded can be considered as an element of all three categories mentioned above. Other groups of control information are possible (VDE does not require this method to organize the control information). Content control information related to this example of a container created by Creator A can be found in Figure 80, C._AShown as. Figure 80 further shows the VDE participants who may receive enable control information related to Creator A's VDE content container. Some of the control information in this example will be described in more detail below.

Some of the distribution control information specified by Creator A (in this example, control information primarily related to the creation, modification, and / or use of control information by the Distributor) is (a) the Distributor by Creator A. In addition, each user who is using the contents of the container will be paid a fee of $ 10 per user per month, and (b) 100 people without the distributor replenishing the budget. Budgeting so that more than independent users cannot be allowed to access such content (eg, not being able to create more than 100 permission records representing content access rights), and (c) Includes that distribution rights cannot be transferred in enabling control information created for distribution to other participants (eg permission records and related component assemblies).

Some of the content redistribution control information specified by Creator A (in this example, created by the distributor to the extent permitted by the senior participants in the processing and control chain, and the user / provider (in this example). , And control information related to controls and / or other requirements related to redistribution activities by such users / distributors), (a) controls that enable content access. The information includes a requirement that it can be redistributed by the user / distributor at only two levels, and further the first redistributor is restricted to two levels of redistributable and the first redistributor delivers permissions. Each redistribution is restricted to the second redistributor to whom it is assigned, with one level added, and users who receive permission from the second redistributor cannot make further redistributes. It requires the value to be decremented by one (such a limitation is, for example, by including a requirement that prompts one or more of the following methods as one aspect of the VDE control method associated with creating new permissions: It can be enforced. This one or more methods will (i) find the current level of redistribution stored as, for example, an integer value in the UDE associated with the one or more methods, and (ii) the level of redistribution. If the value is compared to the limit value and (iii) the level value of such redistribution is less than the limit value, then such to the user as one aspect of the content control information related to the VDE managed content. Before delivering the UDE, increase the redistribution level value by one, and if the redistribution level value is the same as the limit value, the process defaults). And (b) no other special restrictions are imposed on the redistributor.

Some of the usage control information specified by Creator A (in this example, the control information that the Creator requires the Creator to provide in the control information passed to the user and / or the user / Distributor), eg, (a) the movement of content (the form of distribution described herein) is not permitted, and (b) the distributor calculates the number of users who have accessed the container within a month, and , To prevent further use after the rental has expired, provide (at least) sufficient weighing information within the usage permission (eg, processing and reporting chain, and / or expiration date and / or permission record or other Required Control information is required to be stored (by the use of a time-aged encryption key, by the use of a metric method designed to report access usage to Creator A).

In this example, some of the extraction and / or embedding control information specified by Creator A has redistribution rights related to the protected content of the VDE provided by Creator A for which the extraction and / or embedding of the content. Except for users who do not have it, it may include the requirement that it be not allowed by parties in the chain of controls associated with the processing and this control information. Alternatively, or in addition, with respect to different parts of the content, the control information that enables certain extractions and / or embeddings, along with the redistributable rights described in this example, is the user / distributor (user / distributor is the user content). It may include aggregators, and user content aggregators may be provided for use by (which may create their own content products by providing content created and / or received from different sources).

Distributor A in this example uses a basic approach that Distributor A prefers over other approaches when providing content control information to enable to users and / or users / distributors who prefer to rent content access rights. Selected. In this example, some of the control information provided by the creator allows Distributor A to directly implement this preferred approach, and (eg, Distributor A permits such an approach, and No other control configuration may allow this preferred approach (unless successful VDE negotiations have been completed, supporting appropriate control information). In this example, much of the control configuration received by Distributor A comes from the VDE negotiation process, which shows Distributor A's choice for distribution control information that approves the creation of usage control information that reflects rental-based usage rights. (And reflects the results of the VDE negotiation process). Such distribution control information creates control information for distribution to users and / or users / distributors, resulting in a control configuration provided by the creator in a method that "rents" access rights. Distributor A can introduce and / or modify it. In addition, Distributor A in this example processes the user / distributor's request for redistribution rights, and thus Distributor A grants such rights as one aspect of the control information created by Distributor A. Distribution control information that has been negotiated (or agreed) with the creators that are allowed to be included will also be selected.

In this example, the distributor A and the creator A can use VDE to negotiate the distribution relationship (for example, VDE negotiation). In this example, Creator A creates a VDE content container and relevant control information that represents Creator A's desire to receive a reward based on the rental of usage rights, and such control information is distributed by the distributor. Distributor A makes any negotiated modifications to further indicate that Creator A has imposed acceptable limits on the redistribution control information that A can use to process requests from users / distributors. It can accept the distribution control information of Creator A without.

After receiving the enable distribution control information from Creator A, Distributor A is enabled by Distributor A (if permitted or not blocked by more senior control information) by manipulating the application program. You can specify some or all of the details of usage control information for the user and / or the user / distributor. Distributor A may determine, for example, that a price of $ 15 per user per month serves Distributor A's business objectives for the user's payment for Creator A's container. Distributor A must specify usage control information that meets the requirements for distribution control information given to Distributor A by Creator A. For example, Distributor A may include the required expiration date and / or time-aged encryption key in the control information specification, depending on the requirements of Creator A. If Distributor A does not include such information in the control information specification (or does not meet other requirements), it will be referenced in the creator A's permission record and actually create this control information. A control method that is safely exercised within the PPE650 to do so is, in this example, a preferred method (eg, a suggested value in a field) until acceptable information is included in Distributor A's control information specification. It is not executed by a method based on the check of, a method based on the requirement that a specific method is included in the permission, etc.).

In this example, user A can set up an account with distributor A so that user A can receive VDE-managed content usage control information from distributor A from distributor A. By receiving the content usage control information from the distributor A, the user A can access the content of the creator A and use the content. Usage control information is passed through (and is added to and / or modified by that chain) a chain of processing that includes Distributor A, so Distributor A can use the content of Creator A. In this example, the usage control information requested from is a complex of control information from creator A and distributor A. For example, a weighing method that generates an audit record if a user accesses Creator A's VDE-controlled content container and that user has not previously accessed the container in the same month (eg, its). Stores the user's last access date in the UDE associated with the open container event referenced in the method core of the weighing method, and determines if the access was made in the same month on the next access. Can be established (by comparing its dates). Created, modified, referenced in one or more permission records by Distributor A to reflect one or more charges and / or charges for monthly use as described above, and / Or a control method related to opening a container for Creator A that invokes a parameterized budget method (this control method is also created and / or provided by Creator A, for example, or is provided by Distributor A. In creation and / or provided), Distributor A may utilize such a weighing method. If Distributor A specifies use and / or redistribution control information to the extent permitted by Creator A's senior control information, then a new set of control information (D in Figure 80)._A(C_A), But the control information associated with that container by Distributor A is delivered to the User and / or User / Distributor (in this example, User A, User B, and User / Distributor A). Sometimes it can be associated with Creator A's VDE content container.

In this example, user A can receive control information related to creator A's VDE content container from distributor A. This control information is used in extended contracts between User A and Distributor A (eg, regarding fees related to the use of Content, limited redistribution rights, etc.) and between Distributor A and Creator A. Features, scope, and processing of extended contracts (eg, VDE's controlled content usage information and / or the use and / or creation of content control information that Distributor A receives from Creator A or that Creator A receives from Distributor A. , Reporting, and / or with respect to other aspects, or contracts in other VDE content use information processing). Such extended contracts can be enforced by processes operating within the secure subsystem of each participant's VDE installation. In this example, the portion of such an extended contract that represents Creator A's control information, such as modified by Distributor A, is D._A(C_A), For example, according to (a) a control configuration (eg, one or more component assemblies, one or more permission records, etc.) and (b) the requirements stated in such control information. A record of usage information generated while using the Content and (c) as a result of such use (such results electronically, securely and invoices delivered by the use of VDE). It may also include receiving automatically, including payments (such invoices are obtained from the use), payments (automatic electronic credits "performed" in response to such use and / or payments in electronic currency. ) And (d) User A and / or other activities that are the result of such use and / or such control information by the VDE safety subsystem of User A's VDE installation. Including.

Control information D_A(C_A), User A can enforce his own control information (within the limits of senior content control information) when using Creator A's VDE content container. This control information is provided to User A before continuing if, for example, (a) a threshold (eg, a quantity limit, eg, a self-imposed limit on the amount of spending per activity parameter) is exceeded. Details relating to User A's use of the Transactions, Sessions, Time-based, and / or other thresholds, and (b) Creator A's Content, so that may have to give explicit approval. User A's privacy requirements for records and / or transmissions of related uses, (c) storage of value remaining in Creator A's Content Container and / or electronic credits and / or electronic currency that may be lost due to system default or other causes. It may include backup requirements that User A imposes on itself to help ensure local storage of. The right to perform in some or all of these examples of User A's control information may be negotiated with the distributor in some cases. Other control information so specified to the user may be enforced independently of any control information received from any content provider, one or more classes of content and / or use of electronics, or all classes. Can be set to relate to the user's control information, more generally the control information of the VDE installation. A complete set of VDE control information that can be in place while User A uses Creator A's content container is shown in Figure 80._A(D_A(C_A)). This set can represent control information generated by creator A, modified by distributor A, and further modified by user A, all of which provide more senior control information. It follows control information from the party in the value chain and therefore, for this example, has a "complete" VDE extension agreement between User A, Distributor A, and Creator A for Creator A's VDE Content Container. Configure. User B, for example, from Distributor A such control information D_A(C_A) Can also be received, and by adding its own control information in the approved method, set U_B(D_A(C_A)) Can be formed.

User / Distributor A can also receive VDE control information related to Creator A's VDE content container from Distributor A. User / Distributor A may, for example, both use the content of Creator A as a user and act as a redistributor of control information. In this example, control information D_A(C_A) Allows and limits these two activities. D_A(C_ATo the extent permitted by), User / Distributor A controls the use of User / Distributor A (in a manner similar to that described above in relation to User A and User B) and User. / Controls the control information redistributed by Distributor A (in a format similar to the format described above in connection with Distributor A), D_A(C_A) Based on its own control information, ie UD_A(D_A(C_A)) Can be created. For example, user / distributor A is UD_A(D_A(C_A)) When redistributing to User / Distributor B, User / Distributor B should report to User / Distributor A specific usage information that was not requested by either Creator A or Distributor A. Can be requested. Alternatively, or in addition, User / Distributor B may, for example, be based on the number of hours (minutes) that User / Distributor B uses the Content of Creator A (Distributor A for User / Distributor B's use). May agree to pay User / Distributor A a fee for using Creator A's Content (rather than a monthly fee charged to User / Distributor A).

In this example, the control information UD that allows user / distributor A to further redistribute control information related to the content of creator A to user / distributor B._A(D_A(C_A)) Can be distributed to user / distributor B. User / Distributor B is a new set of control information, UD_B(UD_A(D_A(C_A))) Can be created. Control information UD_A(D_A(C_A)) Allows user / distributor B to redistribute, due to restrictions on redistribution from creator A in this example, set UD_B(UD_A(D_A(C_A))) Is further prohibited from including redistribution rights (eg, providing redistribution rights to User B) because of the chain of processing from Distributor A to User / Distributor A (Distribution). And the continuation of the chain from User / Distributor A to User / Distributor B (the first level of redistribution) and the further continuation of the chain to another user are two levels of redistribution. Represent and, as a result, set UD_B(UD_A(D_A(C_A))) Cannot include further redistribution rights in this example.

As shown in FIG. 79, User B may use the content from both User / Distributor B and Distributor A (among others). In this example, as illustrated in FIG. 80, user B may receive control information related to the content of creator A from distributor A and / or user / distributor B. In both cases, User B applies his own control information (if such control information permits) D._A(C_A) And / or UD_B(UD_A(D_A(C_A))) Can be established respectively. The resulting set of control information, U_B(D_A(C_A)) and / or U_B(UD_B(UD_A(D_A(C_A)))) Can represent different control scenarios, each scenario may benefit User B. As described in connection with the previous example, along the chain of processing involving User / Distributor A, the fee is based on the number of minutes User B uses the Content of Creator A (and User / Distributor A). (Requires Distributor A to pay a monthly fee of $ 15 per User, regardless of User B's usage during the month) User B received control information from User / Distributor B. Maybe. This may be more preferable in some circumstances than the fees required by the direct use of control information provided by Distributor A, but a depleted chain of redistributables, and, for example, UD._B(UD_A(D_A(C_A))) May also have the inconvenience of additional usage information reporting requirements. Two sets of control information, D_A(C_A) And UD_B(UD_A(D_A(C_A))) And allow (eg, deregistration and re-registration of different sets of control information related to a container (or the same content that has different control information and / or is provided by different content providers). Re-registering multiple copies of), processing and D_A(C_A) And UD_B(UD_A(D_A(C_A))) As one aspect of the extended contract for the chain of control reflected in), the registration interval in the object registry used by the secure subsystem of User B's VDE installation to prevent within a certain time interval. User B may have both sets of registered control information (eg, does not require use-enforced exclusion) and may utilize the more desirable set under certain usage scenarios.

In this example, Creator B creates a VDE content container and sets the VDE control information in Figure 81._BAssociate with a container as shown as. Figure 81 also shows VDE participants who may receive enable control information related to Creator B's VDE content container. In this example, the control information can indicate that: The Distributor of Creator B's Content must (a) pay Creator B $ 0.50 per kilobyte of information decrypted by the User and / or User / Distributor authorized by such Distributor, ( b) While Creator B maintains the requirement to receive $ 0.50 per kilobyte of decrypted content, users and / or users / distributors are allowed to embed their content container in another container. There is no limit to the number of possible control information sets that can be generated for users and / or users / distributors, and (d) at certain time intervals (eg, at least once a month). , Must report information regarding the number of such distributed control information, (e) controls that allow users and / or users / distributors to move their control information up to three times. Information can be created, (f) Redistribution of control information by the user / distributor can be allowed up to three levels of redistribution, (g) User who receives the redistributed control information from the user / distributor 1 You can allow up to one move per person.

In this example, Distributor A provides Creator B with control information that allows Distributor A to distribute control information related to the VDE container described above in relation to Creator B to users and / or users / Distributors. Can be requested from. As mentioned earlier, Distributor A has established a business model that favors "rental" of access rights to users and users / distributors who receive access rights from Distributor A. Creator B's distribution control information in this example does not enforce a model that includes a "rental" of rights, but rather bases the payment amount on the amount of content decrypted by the user or user / distributor. In this example, by using VDE, Distributor A can negotiate with Creator B to include different usage information recording models allowed by Creator B. This model may be based on the inclusion of one or more metric methods in the control structure associated with the Creator B container that records the number of bytes decoded by the end user, but based on such decoding. Instead of charging the user, Distributor A proposes to charge the user by the "rental" model, and agrees that the control information of creator B can be charged to the user by the "rental" model. Then, the amount paid to Creator B is determined based on the information recorded by the byte decryption weighing method and / or the accumulation of payments from the user.

Creator B, for example, (a) acts as an auditor (eg, using the VDE safety subsystem at Distributor A's site to relate to the processing of audit information received by Distributor A from users of Creator B's content. Trust the control method to do, and in addition, safely calculate how much Distributor A should repay to Creator B, and pay Creator B in credits and / or currency owned by Distributor A, for example. Can accept such a new control model with Distributor A (paying to Creator B using a mutually acceptable budget method to manage) and (b) perform any auditing function related to this content. Based on Distributor A's consent to the third party, such new control model may be accepted, and (c) information related to one or more metric methods that record the number of bytes decrypted by the user, Such a model can be accepted and / or if it is securely packaged by Distributor B's VDE safety subsystem and securely sent to Creator B in addition to Distributor A using VDE communication technology. , (D) Accept other mutually acceptable conditions. C_BControl information created by Distributor A based on modifications made by Distributor A, such as permitted by Distributor A, is, in this example, D._A(C_B).

User A sets control information D_A(C_B) Can be received from Distributor A. As mentioned above in relation to the content received from Creator A through a chain of processes involving Distributor A, User A is D._A(C_B) To the extent permitted, control information of itself, control information D_A(C_B), Thereby setting the control information U_A(D_A(C_B)) Can be created. Control information set D_A(C_B) Is control information C that requires payment of $ 0.50 per kilobyte of decrypted information._BContent decrypted from Creator B's container by User A (to allow Distributor A to correctly calculate the amount to be repaid to Creator B for User A's use of Creator B's content accordingly). One or more weighing methods that record the number of bytes in, and a "rental" model related to User A's use of Creator B's content (eg, Distributor A, User A's Creator B's content. For example, a weighing method related to additional control information that records each month of use and charges User A $ 10 per month for each such month in which User A uses such content. It may include additional weighing methods related to record of use such that Distributor A may collect sufficient information to safely generate charges based on (which may be included).

User / Distributor A has control information C directly from Creator B._BCan be received. In this case, Creator B may negotiate with User / Distributor A by using VDE and may be the same as described above in relation to the distribution relationship established between Creator B and Distributor A. , Or control information that can be different C_BCan be delivered as a set. For example, User / Distributor A may for content decrypted by User / Distributor A (and any participant who receives distributed and / or redistributed control information from User / Distributor A). Control Information C, including the requirement that User / Distributor A pay Creator B for a price of $ 0.50 per kilobyte._BCan be received. As mentioned above, User / Distributor A can also receive control information related to Creator B's VDE content container from Distributor A. In this example, User / Distributor A pays a "rental" fee through a chain of processing to Distributor A and a fee based on the amount of decryption through the chain of processing towards Creator B. You can choose between payment and payment. In this example, C_BAnd D_A(C_B) May have the ability to choose to use either or both. As mentioned above in relation to the chain of processes involving Creator A and Distributor A, User / Distributor A is C._BAnd / or D_A(C_B) To the extent permitted, by adapting its own control information to set control information UD_A(C_B) And UD_A(D_A(C_B)) Can be formed respectively.

As shown in FIG. 81, in this example, user B obtains control information related to creator B's VDE content container from six different sources, namely, C directly from creator B._B, D from distributor A_A(C_B), UD from user / distributor B_B(UD_A(D_A(C_B))) and / or UD_B(UD_A(C_B)), D from distributor C_C(C_B), And / or D from Distributor B_B(D_C(C_B)) Can be received. This represents six chains of processing through which User B can enter into extended contracts with other participants in this example. Two of these chains go through User / Distributor B. Based on the VDE negotiation between User / Distributor B and User B, an extended contract that reflects conditions that allow User B to use one or both sets of control information (dominates both parties). Can be reached (if permitted by the control information to be used). In this example, two chains of processing and control can be "unified" at the location of user / distributor B and then passed to user B (and, if control information allows, by user B). Branch again later based on distribution and / or redistribution).

In this example, Creator C is the control information C associated with the VDE content container created by Creator C, as shown in Figure 82._CCreate one or more sets of. Figure 82 further shows the VDE participants who may receive the enable control information related to the creator C's VDE content container. The content in such a container is organized into a set of text items in this example. In this example, the control information refers to one or more component assemblies that describe the items in such a container (eg, a map table and / or algorithm that describes the extent of each item). ) Can be included. C_CFurther may include, for example: (a) Creator C receives $ 1 for each item accessed by the User and / or the User / Distributor by the Distributor, and upon payment, the User shall access such items for only 6 months. The requirement to ensure that is allowed (for example, with a map-type metric method that ages once a month, a time-aged decryption key, an expiration date associated with the relevant permission record, etc.). (b) Control information that allows items from Creator C's container to be extracted and embedded in another container for $ 10 per extraction / embedding, (c) Extracted / embedded Control information that prohibits items from being extracted again, (d) Control that allows the distributor to create a control information that enables up to 1000 users or users / distributors per month. Information, (e) control information that requires information about the number of users and users / distributors enabled by one distributor to be reported to Creator C at least once a week, (f) users. Or control information that allows the distributor to move user / distributor-enabled control information up to once, and (g) allow user / distributor redistribution to two levels. Control information.

In this example, Distributor B can establish a distribution relationship with Creator C. Distributor B in this example also prefers to distribute control information to users and users / distributors based on the number of accesses made by such VDE participants for payments to Distributor B. It could have been established. In this example, Distributor B distributes a modified set of control information to the user and / or the user / Distributor._B(C_C) Can be created. This set D_B(C_C) Is based on, for example, a negotiation using VDE to establish a $ 0.10 per user charge for users and / or users / distributors who receive control information from Distributor B. sell. For example, C_COne or more to ensure that sufficient information can be gathered from the user and / or the user / distributor to ensure that Distributor B pays Creator C accurately based on Map type weighing method is C_CIf included in, such methods are set D_B(C_C), And may include one or more additional weighing methods (and other required control structures such as billing and / or budgeting methods), thereby setting D._B(C_C), But record each access to ensure that Distributor B also receives a fee based on each access.

The client administrator in this example is, for example, a set D of content control information different from the management information received by user B from distributor B._B(C_C) Can be received. For example, a client administrator can use VDE to set control information for content from any creator, who may provide the client administrator with content control information enabled by Distributor B for these creators. Can be negotiated with Distributor B to establish. For example, the client administrator is a set of control information D that reflects the result of VDE negotiation between the client administrator and distributor B._B(C_C) Can be received. The client administrator is D_B(C_C), And a new set that may contain control information that may only be available to users and users / distributors (eg, colleagues, employers, consultants, etc.) who are in the same organization as the client administrator. CA (D_B(C_C)) Can be formed. To enforce such an arrangement, CA (D_B(C_C)) Is, for example, a control structure that inspects name service information related to a user or user / distributor during registration, is managed by the client administrator, and establishes new budget methods, etc. required for the use of the content. Can include.

The distributor may provide the client administrator with the right to redistribute, which gives the administrator the right to create a permission record for a piece of content (the right to redistribute that content). , Can only be redistributed within the administrator's organization, and cannot be redistributed to other parties. Similarly, such administrators can redistribute such "restricted" rights to departments and / or other administrators within their organization by extending such "restricted" rights, and redistribute such rights. By doing so, the content may be used based on one or more restricted lists of individuals and / or classes and / or other categories of organizational personnel as defined by the administrator. This VDE's ability to limit redistribution to one or more parties and / or classes and / or other classifications and / or installations of VDE users is as long as such control is permitted by senior control information. Content can be adapted by any VDE content provider.

User D in this example can receive control information from either the client administrator, user / distributor C, or both. User / Distributor C, for example, per department managed by User / Distributor C, which allows User / Distributor C to maintain an additional level of control over User D's actions. Control information UD including budget method_C(CA (D)_B(C_C))) Can be distributed to User D. In this example, UD_C(CA (D)_B(C_C))) Can include multiple levels of organizational control (eg, control originating from the client administrator and additional control originating from the user / distributor C), in addition to the controls arising from the commercial distribution channel. In addition, or / or, sufficient control information (eg, user) that helps the client administrator ensure that control information flows through the client administrator's organization in accordance with policies, procedures, and / or other management processes. The client administrator distributes a class of control information to user D, even if it has control information (distributed to user / distributor C) that allows redistribution to users such as D). Can be rejected.

In this example, user E can receive control information from the client administrator and / or distributor B. For example, user E may have an account with distributor B, even if some control information could be received from the client administrator. In this case, User E may be allowed to request and receive control information from Distributor B without limitation, or as an organizational policy, the Client Administrator may be the scope of interaction between User E and Distributor B. Control information may be located in a location associated with User E's electronics. In the latter case, the client administrator is that User E is not available to the client administrator, is available to one or more specific classes of distributors and / or creators, and / or has a fixed price point. It is possible to limit the registration of control information in the safety subsystem of User E's electronics, which has a cost for use (eg $ 50 per hour of use). Alternatively, or in addition, the client administrator receives, for example, a price (or other control information criterion) preferred by user E over the price (or other criterion) available in the control information from the client administrator. Such control information can be restricted from user E receiving from distributor B.

In this example, Creator D uses a VDE content container primarily designed to integrate with other content, such as content provided to Creator B and Creator C (eg, using the VDE extraction / embedding process). Can be created by). Figure 83 shows a VDE participant who may receive enabled control information related to the VDE content container created by Creator D. Control information related to the content of Creator D (C in Figure 83)_D) Can include, for example: (a) Distributor must pay either $ 1.50 per user per open or $ 25 per unlimited open per user, (b) Created by Creator D, etc. 20% discount for users who have prepaid for unlimited opening of certain content (eg, determine if any of such other containers have been registered, and in addition, rights to this container Performed by including one or more billing methods that analyze the user's VDE installation safety database to determine the characteristics of the rights owned by the purchasing user), (c) Distributor C._DThe requirement to report the number of users and users / distributors enabled by the control information created in accordance with, after exceeding 1000, (d) the number of moves by users and / or users / distributors by the distributor. The requirement to limit to one-time only, (e) the distributor to limit the user / distributor to the level of redistribution not exceeding 4, and (f) the distributor to other distributions. You may create enable control information that allows you to create control information as a distributor, but the distributor may not pass this capability to such an enabled distributor, and is so enabled. Audit information related to the use of control information by a distributed distributor is passed directly to Creator D by such an enabling distributor without any processing, and Creator D does such an enabling distribution. A requirement that the Distributor be able to create enabling control information that further requires the person to pay 10% of the payments that Creator D receives from such an enabled Distributor.

In this example, Distributor C is the VDE content container from Creator B, Creator C, and Creator D, and a set of related control information C._B, C_CAnd C_DCan be received. Distributor C may utilize embedded control information and other control information to create a new container with two or more VDE objects received from Creator B, Creator C, and Creator D. In addition, or, Distributor C, for each of such received containers, user and / or User / Distributor (C)._DIn the case of, the control information to be enabled to be distributed to the distributor) can be created. For example, Distributor C may create a container (eg, an embedded container) that contains content parts from Creator B, Creator C, and Creator D, within which each such part distributes. Based on usage activity involving users and / or users / distributors enabled by Person C, each such creator records sufficient information to ensure that payments from Distributor C are received safely and securely. And may have access and use-related control information that allows the auditor to collect sufficient information. In addition, Distributor C can use VDE to negotiate with some or all of such creators._B, C_CAnd / or C_DFor each such creator, based on, and from each of the different models for a collection of content usage information and related (eg, public notice) information regarding payments to such creators by Distributor C. While maintaining the model, Distributor C charges users and / or users / distributors for a "fixed" fee (eg, calculated from a joint model on a monthly or per-access basis). Based on this, you can enable a model that provides comprehensive control information for the entire container.

In this example, Distributor B, from Creator E, VDE Content Container and related Content Control Information C, as shown in Figure 83._ECan be received. C_EDistributor B may extract a portion of the content of such a container, if permitted by. Distributor B may then embed this part in a container received from Distributor C, including, for example, a collection of VDE objects created by Creator B, Creator C, and Creator D. Depending on the specific restrictions and / or permissions on the set of control information received from each creator and distributor C, distributor B may, for example, place such extracted parts into the container received from distributor C. It can be embedded as a separate VDE object, or directly into the content of the "in-place" object from Creator B, Creator C, and / or Creator D. Alternatively, or, in addition, Distributor B, if C_EIf you allow, you may choose to distribute such extracted parts of the content as separate VDE objects.

In this example, user B can receive a VDE content container from distributor C, which consists of VDE objects created by creator B, creator C, and creator D. In addition, User B contains VDE content that contains one or more extracted / embedded pieces of content created by Creator E, as well as the same content created by Creator B, Creator C, and Creator D. The container can be received from Distributor B. User B makes decisions regarding the choice of which of such containers to use, including which of the embedded containers he wants to use, for example, the characteristics of such extracted / embedded parts. (For example, multimedia presentations showing potential areas of interest in the rest of the content, other elements of descriptive and / or descriptive content, related work, delivered as content elements improved Application software, etc.); Quality, usefulness, and / or price (or other attributes of control information) of such parts; container and / or content received from Distributor B and Distributor C in this example. It can be based on other requirements that distinguish control information.

User B may receive content control information from Distributor B for such a VDE content container that allows the user to add and / or modify the content contained therein. User B may request the ability to annotate content, for example in a container that uses a VDE-aware word processor or other application. If permitted by senior control information, some or all of the content may be available to User B for modification and / or addition. In this case, User B acts as a VDE creator of the added and / or modified content. User B may, for example, provide new control information for such content or manage such content (based on control information related to such containers and / or contained objects). May be required (or desired) to utilize existing control information (or control information contained by senior members in the chain of processing for this purpose).

In this example, the VDE100 was used to enable an environment that includes, for example, content distribution, redistribution, aggregation (extraction and / or embedding), reaggregation, modification, and use. The environment in this example allows for a competitive model in which both control information and content can be negotiated and through which control information and / or content can have different things based on the chain of processing passed. Become. In addition, the environment in this example allows content to be added to and / or modified by VDE participants who receive control information that enables such activities. .. Example-Content distribution through content VDE chain processing Figure 84 illustrates a particular aspect of the relatively simple model 3400 of VDE content distribution, including several categories of VDE participants. In this case, for the sake of brevity for reference purposes, various parts of the content are represented as separate items in the form of VDE content container objects. One or more such content parts can be integrated into a single object and can be extracted in whole or in part by the user (which can be the content of any VDE content container if permitted by the content control information). .. In this example, the publisher of historical / educational multimedia content is creating a VDE content container by using content objects available from three content resources. -A video library 3402 product on optical discs available to publishers, including video clip VDE objects representing diverse historical scenes. An internet container 3404 that stores historical text and image resources in VDE objects, which can be downloaded by publishers and other users. An audio library 3406 available on optical discs, including a variety of performance and audio (eg, historical narration) pieces that can be used alone or with other educational and historical material.

The information provided to library 3402, container 3404, and library 3406 may be provided to different issuers 3408 (a), 3408 (b) -3408 (n). Issuer 3408 then provides user 3410 with some or all of the information obtained.

In this example, the video library 3402 control information allows the issuer to extract the object from the video library product container, the object has a license cost of less than $ 50, and the duration is less than 45 minutes, and the extraction If each of the other objects you have created is 20,000 copies each, and you require all video objects to have VDE fingerprints on the double issue, extract content control information that makes each extracted object available for one year. Allow that. Audio library 3406 has established similar controls that fit the business model. The Internet container 3404VDE containerizes the selected object content, including encryption, when the selected object content flows out of the container in response to the user's request to download the object online. Vessel 3406 may be fingerprinted with the identification of the VDE installation received in the content prior to encryption and communication with the publisher, and when duplicated by the publisher or other content user, of the content. Further user identification fingerprint engraving may be required.

Under conditions and circumstances negotiated (or agreed) with the resources provided, publisher 3408 in this example selects a variety of content pieces to combine to form a VDE object container product for the customer's teacher. Publisher 3408 (A) has a video object (represented by a circle) extracted from the video library 3402, a text and image object (represented by a diamond) extracted from the Internet container 3404, and an audio library 3406. Combines one performance song and historical narration (represented by a rectangle) extracted from. Issuer 3408 (B) extracts objects in a similar array that are compounded with Issuer 3408 (B)'s product, and a graphic element created by Issuer 3408 (B) to further enhance the product ( (Represented by a hexagon) is added. Publisher 3408 (C) also creates a product by combining objects extracted from Internet Container 3404 and Audio Library 3406. In this example, all publisher products on each optical disc, in the form of VDE content container objects with embedded objects, are delivered to modern high schools for installation on the high school computer network.

In this particular example, the end user 3410 is a teacher and uses the teacher's VDE node safety subsystem to access the VDE installation on the teacher's high school server, which supports the publisher's product (alternative). In the example, the high school maintains only server-based VDE installations). The teacher licenses VDE products from one or more publishers, extracts the desired objects from the VDE product content container, and / or extracts the extracted VDE content in the form of a VDE content container, moderately on the computer in the teacher's classroom. And / or download for efficient storage. Teachers can store the extracted content in the form of VDE content containers on server mass storage (and / or if it is desirable and useful to the end user, and even acceptable pricing and / or other conditions and / or According to the situation and / or senior content control information, the teacher may store the extracted information in the teacher's node and / or server storage means in a "clear" unencrypted format). This allows the teacher to play and / or use selected parts of the publisher's product, and as shown in the two cases in this example, the teacher created the content on the object. And / or more students can be added. End user 3410 (2) has selected, for example, video piece 1 received from publisher A, and publisher A has received the object from the video library. The piece is also available from issuer 3408 (B), but probably not under favorable conditions and circumstances (such as support consulting telephone lines), so end user 3410 (3) also has video piece 3 from issuer 3408 (A). I have received it. In addition, end user 3410 (3) issues an audio history narration corresponding to the content of history reference piece 7. Received from liner 3408 (B). End user 3410 (3) has also received the corresponding historical reference piece 7 (book) from publisher 3408 (2), and publisher 3408 (2) has received the book from internet container 3404. In this case, the end user 3410 (3) licenses the history reference piece 7 from publisher 3408 (2) instead of publisher 3408 (1) carrying the same book, so it probably costs less. Imposed on books. As a teacher, end user 3410 (3) selects the items she finds most suitable for her class and, through the use of VDE, extracts such items from the resources available to her at will. It is possible (in this case, extracting objects from a variety of optical products provided by the publisher and available on the local high school network server). Example--Distribution of content control information within an organization Figure 85 represents two VDE content containers, Container 300 (A) and Container 300 (B), which are distributed to VDE Client Administrators 3450 in a large organization. As shown in the figure, container 300 (A) and container 300 (B) carry specific control information upon arrival at the company that specifies the usage rights available to the organization. Further, as shown in Figure 85, the client administrator 3450 manages specific departments of the organization, such as sales and marketing manager 3452 (1), planning manager 3452 (2), and research and development manager 3452 (k). Distribute a particular subset of these rights to 3452. In each case, the client administrator 3450 decides which usage options are available to each department and what the budget is.

FIG. 85 is a simplified example, for example, the client administrator 3450 may further add the VDE control created by the client administrator 3450 and / or modify and / or delete it in position control (control information). (If permitted by), and / or even the available financial budget (or other budget) may be split between specific use activities. In this example, the departmental manager has the same rights to determine the rights of the departmental end user, as the client manager has with respect to the department. In addition, in this example (but not shown in Figure 85), the client administrator 3450 and / or the content provider also results in end-user content usage and / or end-user use of all or certain classes. It is possible to determine specific control information that is directly controlled (including related distribution rights). In the example shown in Figure 85, there are only three levels of VDE participants in the organization.

Client administrator 3450 Department manager 3452, and End user 3454 Is.

In another example, VDE supports many levels of VDE management (including overlapping groups) within an organization (eg, department, department, project, network, group, end user, etc.). In addition, the administrator in the VDE model can itself be a VDE content user.

Within an organization, VDE installations can be performed on each end user 3454 nodes and can be server-only or other complex user computers, or other electronics, or a mixed environment. Decisions regarding mixed use of VDE servers and / or nodes may be based on organizational and / or content provider security, performance, overhead costs, or other reasons.

In this example, communication between VDE participants in Figure 85 uses VDE secure communication technology between VDE secure subsystems that support PPE, and other VDE secure system components within the organization. Used for VDE installation. Example--Other content distribution examples Creators of VDE-protected content can interact with other VDE participants in many different ways. VDE Creator 102 may, for example, distribute content and / or content control information directly to users, distribute content and / or content control information to commercial content containers, and distribute content and / or content control information to corporate content. It can be distributed to containers and / or content and / or content control information can be distributed to other VDE participants. If Creator 102 does not interact directly with all users of the Creator's content, the Creator grants distribution permissions to allow VDE participants to further distribute the content and / or content control information to other VDE participants. Can be transmitted to. Creators may also, for example, by not restricting the redistribution of control information, or by allowing VDE participants to act as "conduit" for one or more permission records that can be passed on to other parties. , VDE content and / or content control information may be permitted for further distribution, and its permission record may include identification of the first receiving party and / or the second receiving party.

Figure 86 shows the possible placement of VDE participants. In this example, the creator 102 has one or more application software programs and one or more VDE secure to place the unencrypted content in a VDE protected format (eg, in one or more VDE content containers). Subsystems can be used. In addition, Creator 102 may generate one or more distribution permissions 3502 and / or use permissions 3500 as aspects of control information associated with such VDE protected content. Such distribution and / or use permissions 3500, 3502 can be the same (eg, all distribution permissions can have substantially the same characteristics), or the participants from whom they were generated. It can vary based on the categories and / or classes of, the environment in which they are requested and / or transmitted, changes in the content control model of either the creator 102 or the recipient, etc.

In this example, creator 102 transmits VDE-protected content to user 112a, user 112b, and / or user 112c (eg, over a network, over broadcast, and / or through transfer of physical media). In addition, Creator 102 uses VDE secure communication technology to transmit use permissions to such users. User 112a, user 112b, and user 112c may use such VDE-protected content within the limits of the control information specified by the use permissions received from creator 102. In this case, the creator 102 may manage, for example, all aspects of such user activity related to the VDE protected content transmitted by the creator 102 to the user. Alternatively, the creator 102 may include a reference, for example, to control information that must be available to the user and is not provided by the creator (eg, a component assembly managed by another party).

A 200g commercial content container may receive VDE-protected (or otherwise securely delivered) content and distribution, permissions and / or other content usage control information from Creator 102 in this example. Since the commercial content container 200g can store the content safely, the user can obtain such content from the container 200g when any required condition is met. Distribution permission 3502 is, for example, redistributable permission and / or use permission 3500 for a commercial content container 200g, using a specific restricted VDE-protected subsystem described in the content control information received from creator 102. It may be possible to generate 3502 (eg, not to exceed a certain number of copies, to request a specific payment to Creator 102 by 200g of commercial content container, content to the recipient of such permission. Request to meet specific reporting requirements regarding usage information, etc.). Such content control information may be stored in the container installation and may be applied to the unencrypted content as it is transmitted from the container in response to the user's request, which content is such. Placed inside the VDE container as a step in the secure process of communicating content to users. Redistributable permissions, for example, allow recipients of such permissions to generate a certain number of usage permissions that are subject to certain restrictions (eg, limited to members of the same family, other business organizations, etc.). Can be allowed. The container 200g may be required to collect and report content usage information from all VDE participants to whom the container has distributed permissions, for example, by control information received from creator 102.

In this example, power user 112d may use desktop computer 3504 to receive VDE protected content and redistribution permissions from 200g of commercial content container. The power user 112d then connects to the VDE safety subsystem of such desktop computer 3504 to generate usage permissions for, for example, desktop computer 3504, laptop computer 3506, and / or set-top appliance 3508. Application software may be used (assuming the redistribution permission received from the commercial content container 200g permits such activities). Power users 112d may impose their own restrictions on such usage permissions (eg, based on user identification information) if permitted by senior control information (eg, from Creator 102; modified by container 200g). (Restricts the use of set-top equipment by certain members of the Power User 112d's family to a certain number of times per day, usage, etc.) Power User 112d then grants such VDE-protected content and usage permissions. It can be transmitted to laptop computer 3506 and settop appliance 3508 using VDE secure communication technology. In this case, power user 112d redistributes permissions from the desktop computer 3504 to the set-top appliance 3508 and laptop computer 3506, which regularly reports content usage information to the desktop computer. Can be required. The desktop computer may then collect and / or process the user usage information and report the user usage information to the container 200g.

Users 112e and / or 112f may receive usage permissions and VDE protected content from the commercial content container 200g. Such users may be able to use such content in a manner approved by such usage information. In contrast to power users 112d, these users may not be required and / or receive redistribution permission from the container 200g. In this case, if such transfer and / or is permitted by the usage permissions received from the container 200g, these users may transfer some or all usage permissions to the other electronics 600. Gain and / or the user may be able to transfer some of the rights to other electronics. In this case, such other instruments may be able to report usage information directly to the container 200 g.

In this example, the company content container 702 within company 700 may receive VDE protected content and distribution permissions from creator 102. The distribution permissions received by Company Container 702 may include, for example, restrictions limiting the distribution activity of Container 702 within Company 700.

Vessel 702 may use, for example, an automated system that operates in conjunction with the VDE safety subsystem to receive and / or transmit VDE protected content and / or redistributable and / or use permissions. In this case, the automated system, for example, by company policy, department, to determine permission characteristics and / or content delivered to various parties (company groups and / or individuals) within the company 700. You can rely on standards defined by your policies and user preferences. Such a system may, for example, automatically generate redistribution permissions for the departmental content container 704 in response to company 700 receiving distribution permissions from creator 102, and / or user 112j and / or user. Can generate usage permissions for 112k.

The departmental container 704 may automatically generate usage permissions for user 112g, user 112h, and / or user 112i. Such users may access content from the company content container 702, even though they receive usage permissions from the departmental container 704. In this case, user 112g, user 112h, and / or user 112i may receive usage permission from a departmental container 704 that includes departmental restrictions, in addition to the restrictions imposed by senior control information (in this example, eg, for example. From Creator 102. If modified by Company Container 702, may be further modified by Departmental Container 704, in addition to Company and / or Departmental Policy and Company 700's Company Personnel Consent, Reflects VDE extension agreement, including commercial requirements of Creator 102 and Company 700). Example- "Virtual Silicon Container" As mentioned above, the VDE in one example provides a "virtual silicon container" (virtual black box), and several different cases of the SPU500 are synthetic locations and "virtually" present in the electronics 600. Can communicate securely together to provide a secure hardware environment. FIG. 87 represents the model 3600 of a virtual silicon container. This virtual container model 3600 includes content creator 102, content distributor 106, one or more content redistributers 106a, one or more client administrators 700, one or more client users 3602, and one or more clearing house 116. .. Each of these diverse VDE participants has an electronic appliance 600 that includes, at least in part, a protected processing environment 655 that may include a silicon substrate semiconductor hardware element safety processing unit 500. The various SPU500s encapsulate each part of the virtual distribution environment and then together form the virtual silicon container 3600. Example--Testing / Testing The scheduled SAT exam for senior high school students is Educational Testing Prepared by Service. The test will be placed in the VDE container until 1:00 PM EST on November 15, 1994, due to be announced. The SAT will provide one copy of the container for each school or other location where the exam will be conducted. Schools or other locations (planned test sites) can generate distributed "managed" electronics and / or test managers (such as test organizations) and test VDE content containers for 200 test sites. You will have a test container that securely contains VDE identification for your budget. Each container generated at the planned test site may have a permission record on the network of the planned test site containing safety identification information for each electronic device 600, as well as identification for students taking the test, for example. Used by test takers. Student identification can be, for example, in the form of a secure PIN password entered by the student prior to taking the test (the test monitor or administrator can verify the student identification by entering the PIN password). Of course, the identification can take automatic speech recognition, handwriting recognition (signature recognition), fingerprint information, visual recognition, or one or more similar recognition formats, which are of the test taker (and / or test monitor / administrator). It can be used to verify the ID and / or be stored in a VDE container, etc., or in a location pointed to by specific container information, along with test results. This identification can be stored in encrypted or unencrypted form. When stored in encrypted form or other protected form, certain summary information, such as error correction information, may be stored with the identification information to authenticate the associated test as corresponding to the identification.

As the student takes the test using a computer terminal, the selected answer can be quickly and safely stored (but the answer can be changed by the student during the test time). When the test is complete, the student's answer is securely stored in the VDE reporting object, along with the test reference, and the VDE reporting object is passed over the network to the test administrator and management electronics 600. All test objects for all students are then the summary information showing the average and average scores, and the desired information to summarize, and / or the test objects sent for communication to the Educational Testing Service. It can be placed within the VDE object 300 along with other relevant information (which may be secured by the VDE 100), including information that can act as an authentication. For example, specific information may be sent separately from each student's summary object, including information that helps test the validity of the object as a "genuine" test object.

Applying VDE to a test run scenario can significantly eliminate the cheat that results from accessing the test prior to the test run (usually the test is stolen by the teacher or test administrator). In ETS, an individual who has access to a test may be limited to part of the test in order to eliminate the risk of the "whole" theft of the test. Completely authentic test results can be stored for a reasonable period of time, so using VDE can prevent processing errors or other operations on the test answer.

Overall, the use of VDE100 for electronic test execution provides the benefits of electronic test execution without the substantial risks associated with electronic storage, electronic communication, and electronic processing of test materials and test results. To enable. Performing electronic tests greatly improves efficiency and significantly reduces the cost of performing and processing tests by eliminating the human processing of printing, shipping, shipping, and testing. At the same time, the electronic test run allows the user to receive a copy (encrypted or unencrypted) of the test results when the test period expires. This prevents individuals who have taken the test from losing the test results or improperly processing the test results. Electronic test runs using the VDE100 can also make it possible to reliably manage the timing-related variables of test runs (eg, exact start, duration, and stop time). Of course, proper use of the VDE100 for the test run process can prevent improper access to the test content prior to the test run, and who takes which test, when, with which electronics, Ensure that the test, where you plan to take the test, is properly audited and certified. Loss, theft, improper time adjustment, or retesting with other variables can be avoided or eliminated.

VDE-assisted test runs can, of course, be used for safety / certification purposes, for employment (eg, job application) applications, and for many different applications, including for conducting a full range of evaluation tests. For example, an airway pilot, or truck, train, or bus driver, can take a test promptly prior to departure or during a trip, along with a test to assess alertness to fatigue, drug use, etc. A particular test may have different order and / or combination of test activities each time it is taken or for each group. The test or master test can be stored in a VDE container (the order of the test questions and which question can be determined by the processing safely performed on the PPE650). Test responses can be encrypted when they occur and can be stored locally for aggregated (or other test results) transmission or transmitted dynamically (eg, central test management). To the computer). If the test taker "fails" the test, he or she is probably required by a local PPE650 to issue control commands that affect some parts of the vehicle's electrical control system, or to operate the vehicle. Either a local PPE that does not compound or provide certain key information will prevent subsequent operation of the vehicle. Example--equipment rental Through the use of the present invention, rather than purchasing a given device for unlimited use, obtain the device (VCR, TV, microwave oven, etc.) and be charged according to one or more aspects of use. Electronic appliances can be "rented" or provided to selected customers. For example, a microwave oven may be charged each time it is used to prepare an item and / or for the time it is used. Either at all times or on a regular basis, the telephone jack can be attached to a cheap modem that is operationally mounted in a microwave oven (or the modem serves multiple items and / or a burglar alarm, lighting. And / or can be placed in a position that acts as a temperature control, etc.). Alternatively, such appliances may utilize the network formed by the power cables to transmit and receive signals.

At regular intervals, usage information (in summary format and / or detailed format) may be automatically sent to a remote information utility that collects information about equipment use (utility is specific brand, specific). Equipment types and / or brands and / or collections of types can be serviced). Usage information can be sent in VDE format (eg VDE object 300). If the information utility itself does not perform a billing function, the information utility may then distribute the information to a financial clearing house or / or information that "belongs" to each instrument manufacturer and / or lender (retailer). Can be sent to them or their agents. In this way, a new business can be able to use the equipment for leasing, and leasing the equipment can be similar to leasing a car.

Equipment can also be managed by safety identification by installing VDE (PIN, voice or signature recognition, etc.). This may be required each time the unit is used or according to regular criteria. Use of safety identification if the PPE650 issues one or more orders that prevent the use of some or all of the functions of the device (or fails to provide specific information that is important for compounding or operation of the device). Failure or failure to use according to timely criteria can render the instrument incapacitated. This feature can greatly reduce the susceptibility of electronic devices to theft. In addition, VDE-affiliated use is the "registration" of a VDE safety subsystem in a given appliance with a VDE safety subsystem in a controlled position in a home or business setting. This control position also allows children to play R-designated movies through VDE telecommunications and / or centralized management (eg, recognition of data indicating that a given movie, song, channel, game, etc. is R-designated. Responsible for limiting viewing on either television or video cassettes, and allowing parents to limit viewing or listening to their children). Such control positions are, for example, water, gas, electricity consumption, telephone usage, etc. (through the use of PPE650 integrated within the control means to measure and / or control such consumption, or Collects and collects information about processing, usage control (eg usage restrictions), and / or delivery to the VDE secure subsystem for billing, either through one or more signals, generated by a non-VDE system. Such information can be transmitted to one or more utilities and paid for such consumption using VDE-secured electronic currency and / or credits and the like.

In addition, one or more budgets for use can be managed by the VDE, which uses a photocopier to make more copies of certain rented equipment, eg, more than specified by the duty cycle. It can prevent inappropriate and overuse that leads to malfunction of the device such as storage. Such improper use informs the user that they should upgrade to a more robust model, eg, a message on the display panel or on the TV screen, or a message in the form of a communication from the central clearing house. Appears as.

Although the present invention has been described in the context of what is currently considered to be the most practical and preferred embodiment, the invention is not limited to the disclosed embodiments and is rather attached. It is intended to include various modifications and equivalent arrangements included in the intent and scope of the claims.