HK1064763B - Techniques for defining, using and manipulating rights management data structures - Google Patents

Description

Techniques to define, use, and manipulate rights management data structures

The technical field to which the invention belongs

The present invention relates to techniques for defining, creating and manipulating rights management data structures. More specifically, the present invention provides systems and processes for defining and/or describing at least some data characteristics of a secure electronic rights management container (container). The present invention also provides techniques to support the integrity, flexibility, interoperability, user and system transparency and compatibility of rights management data structures.

Background and summary of the invention

Increasingly, secure digital containers are being used to securely store and transfer digital content. One secure digital container model is the "DigiBox" developed by InterTrust technologies, Inc. of Sonerville, California^TM"container. The DigiBox is described in the patent specification of Ginter elal^TMMany features of the container model-a powerful, flexible, generic structure that enables secure, efficient, and interoperable electronic description and regulation of a variety of e-commerce relationships, including rights management interfaces for secure transport, storage, and object and data information within the container.

Briefly, a DigiBox container is a tamper resistant digital container that may be used to package any type of digital information, such as text, graphics, executable software, audio and/or video information. DigiBox^TMThe rights management environment used in the container allows business participants to associate rules with digital information (content). The rights management environment also allows for secure association of rules (including rules and parameter data controls herein) with other rights management information such as rules, audit logs generated during use of digital information and management information to ensure proper operation of the environment, including validation rights and various inter-component protocols. DigiBox^TMThe electronic container may be used to store, communicate, and provide a rights management interface to digital information, associated rules and other rights management information, as well as other objects and/or data within a distributed rights management environment. The design can be used to provide an electronic enhanced chain of processes and controls that include rights management when containers are moved from one entity to another. This functionality helps to support a digital rights management architecture that allows the legitimate holder of content (a party that has any system authorizations related to the content, e.g., content publishing)A merchant or even a government agency) securely controls and manages the content, events, transaction rules, and results of use, including any necessary payment and/or reports of use. The security control and management provides consistent rights protection as content is passed, used, and passed between creators, distributors, redirectors, consumers, distributed payers, and other value chain participants.

For example, a content creator may package one or more digital information with a set of rules into a DigiBox secure container-the rules being variably located in one or more containers and/or client control nodes-and transmit the container to a distributor (distribute). The distributor may add and/or modify rules within the container with parameters allowed by the creator. The distributor may then transmit the container in any allowed (or non-prohibited) manner-e.g., over an electronic network such as the internet. The consumer may download the container and use the container according to the rules within the container. The container is opened and the rules are enforced by the InterTrust software onto a local computer or another InterTrust sensitive device called an InterTrust business node. The consumer may forward the container (or copy) to other consumers who may (where the rules allow) use the content according to the same, different, or other included rules. The use of these rules depends on the rights available to the user, e.g. the user specific identification code, and any class membership (e.g. an employee of a car club or a particular university), and in accordance with these rules, usage and/or payment information is collected by the node and transmitted to one or more clearing houses for payment settlement, and usage information is transmitted to those having rights to accept.

The container model described above has almost unlimited flexibility, and this description is also referred to in the Ginter et al patent Specification (which contains similar other DigiBox/VDE (virtual distributed Environment) models). It can be applied in many different environments and specific implementations. For example, referring to fig. 1A and 1B, a newspaper publisher may distribute newspapers 102 in a container 100A. A fashion magazine publisher may distribute fashion magazines 106 in another container 100C. Similarly, a large-scale banking environment may use a single container, an electronic trading system may use a single container, and so forth.

The InterTrust DigiBox container model allows and facilitates the use of these or other different containers. It provides the convenience of customizing complex containers for different applications and/or classes of applications and/or users intended to meet different needs and business models, and this customization capability is very important, especially when applied to connecting a general, distributed rights management environment as described by Ginter et al. This environment requires practical customizability optimizations, including customizability and transparency to the container model. This customization flexibility has many advantages, such as allowing for optimization (e.g., maximum efficiency, minimum overhead) of complex container designs for each particular application or environment, so as to allow for the simultaneous coexistence of different containers designed for many different purposes (e.g., business models) and for use by rights management clients (nodes) located on consumer electronic devices such as computers or entertainment devices.

Although there are great advantages to supporting a high degree of flexibility, it may create difficulties for the average user. Considering the painting process, the painter draws on a blank canvas because the canvas is initially blank, the painter is completely unconstrained, and the drawing can be a landscape, a figure, a sea view, or any other image — the only constraint being the imagination of the painter. This flexibility allows the painter to create a name such as "Mona Lisa". However, a blank canvas requires great skill to draw a satisfactory work. As a result, an inexperienced artist may not create a good picture if drawing on a blank canvas.

We now consider that an amateur begins to draw, which has no skill to draw a blank canvas into a satisfactory picture, and that an amateur need not spend years learning this skill, and he can go out to buy a "draw by number" drawing kit. Apart from the blank canvas, the amateur draws from the image that has been defined to be drawn and the pre-printed canvas, according to the instructions ("all areas marked 12 are painted dark red and all areas marked 26 are painted bright blue"), the amateur can draw a relatively satisfactory picture with relatively little skill, in order to do so, the amateur must strictly adhere to the instructions pre-printed on the canvas, any deviation may cause the final picture to deteriorate.

Ease of use in the computer field can be analogized to the case of "drawing by number". If it is important for an untrained and/or inexperienced user to use a particular software, the system designer will predefine particular structures and design them into the system, a technique that allows an inexperienced user to use a potentially very complex design without having to fully understand it. But this is usually a strict definition, i.e. a strict limitation on the functionality and flexibility obtainable using the program. As a result, creative problem solutions are limited to provide practical value. In addition, even the use of pre-implemented designs by experienced users can be of great benefit. Since, for example, a user has the ability to program complex programs, this does not mean that it is efficient or appropriate to program a specific purpose, even if such a pre-implemented program is not ideal, experienced users will often use pre-implemented programs if it takes too much time or money to program a new program, if it can be made up in advance. Thus, the greatest overall realized value associated with customization is the ability to achieve customization with great ease and effectiveness, so that the cost does not outweigh the benefits obtained.

Consistency, flexibility, compatibility, and interoperability are other factors that need to be considered in the field of computer applications, especially when it comes to systems supporting customization. The human eye can evaluate distinctiveness when drawing-the property known as "self-party" like Mona Lisa determines to a considerable extent that the drawing is so valuable. In contrast, in the computer field, consistency is desired, at least in general, with the format of the thing. It is highly efficient for a computer to know in advance how to handle and use objects. If a computer does not know in advance how to read or process an input object, we say that the computer and the object are "incompatible," i.e., they cannot work together, and when multiple computers can work together, we say that they are "interoperable," incompatibility and interoperability problems can prevent the computers from talking to another computer and also can prevent data created using another computer.

For example, in the non-computer world, a French person who only knows a little English may find it more meaningful and efficient to describe a complex problem using his native language, French. But when he speaks with another english speaker who does not understand french, they are not "interoperable" in french, and the french speaker can only resort to the far less efficient english language to converse with the english speaker. Of course, this is always much better than he would converse with a german who does not understand both english and french, and who are not "interoperable" in discussing problems. Similarly, because rights management containers may be communicated and used by a large number of different users, groups, and organizations for a large number of different purposes, it is important to provide compatibility and interoperability that if these different parties were each involved in one or more different rights management models, they would like to interoperate efficiently. For example, if a rights management container is used to distribute news mail and is optimized for this purpose, each user of the news mail must have a computer system or software "know" how to read the container and the news mail therein. Since businesses such as posting news mail need to be as efficient and low cost as possible, it is important to optimize, i.e., customize, the rights management container to optimally reflect the needs of these models, and to discard features that are unnecessary for each individual application or class of applications, as these unnecessary features may consume unnecessary computer overhead and/or storage space.

Different newsletter publishers may use different container formats to customize their own particular newsletter and/or content types and/or formats. A newsletter that can read many different newsletters needs to have the ability to read a large number of different formats, and it is also difficult to pinpoint or identify a particular usage format that it will not typically analyze the various different containers delivered efficiently (or will not be appropriate due to security issues).

Publishing standards help achieve a certain level of interoperability for a given type of application, but it typically takes a long time for any particular standard to gain industry-wide acceptance, and standards need to be widely varied for different types of applications. Further, data structures and other criteria are often designed to be the least common leader — that is, they contain some unnecessary fields and requirements or omit some other feature that is optimized in a particular example. If a particular standard is forced to be used, there are always applications that cannot be optimized to be efficient and/or operational.

Once security is a concern, the trade-off between flexibility, ease of use, compatibility, and interoperability is further complicated. To be effective in many electronic commerce applications, electronic container designs must be tamper resistant and secure. It must be assumed that any tool that is widely used to create and/or use containers falls into those attempting to destroy or break the container or to use the electronic information without authorization. Thus, container creation and use tools must be inherently secure, they must protect certain details about the design of the container, and this additional security requirement may make it more difficult to provide ease of use and interoperability of the container.

The above-referenced patent specification describes, in non-exhaustive examples, "templates" as control specification devices (or device sets) and/or data for object control software. See "object creation and initial control structures", "templates and categories" and "object definition files", "information" methods and "content" methods discussed in the Ginter el. The template, at least in some examples, can interact with user instructions and provided content to create (and/or modify) an object. L. discloses that templates, which-along with their structure and/or element group columns-can be used as object authorization and/or object control applications, can be expressed as text files that define specific structure and/or element group columns. Al. templates help to enhance the inherent flexibility and configurability in a particular industrial and/or business and/or application environment, provide an operational framework and/or structure that familiarizes existing industrial and/or application and/or business manipulations with concepts such as content type, distribution, pricing mechanism, user-content interaction and/or related management activities, budgets, and the like, which is beneficial in pursuing an optimized business model and value chain that provides a balance of rights between effectiveness, transparency, and efficiency.

The present invention extends this technology by providing, among other features, a machine-readable descriptive data structure for an associated rights management data structure, such as a secure container. In one example, such a machine-readable descriptive data structure may make a quick abstract representation of the data format in a rights management data structure that may be used to describe a single rights management data structure that is also suitable for a family of data structures that conform to the same format and/or other characteristics defined by the abstract representation. The abstract representation may be used to create a rights management data structure, allowing other rights management nodes to read and understand the data structure and manipulate some or all of the data structure.

The descriptive data structure may be used as a "template" to help create and describe other nodes, a rights management data structure, and to help understand and manipulate the rights management data structure.

In a particularly advantageous design, the machine-readable descriptive data structure may be associated into one or a family of corresponding rights management data structures, and thus may be independent of any particular rights management data structure. For example, a copy of a descriptive data structure may be saved with such a data structure. Alternatively, some or all of the descriptive data structures may be obtained from other locations (e.g., an inventory house or warehouse) and transmitted on an independent basis as needed.

In one example, the machine-readable descriptive data structure provides a description that reflects and/or defines the corresponding structure in the rights management data structure. For example, the descriptive data structure may provide a recursive hierarchical list reflecting and/or defining a corresponding recursive hierarchical structure in the rights management data structure. In other examples, the description provided by the descriptive data structure may communicate with a complex multidimensional data structure having 2, 3, or several dimensions, and the descriptive data structure may directly or indirectly specify where the corresponding defined data type may be found in the associated rights management data structure. The descriptive data structure may further provide metadata describing one or more corresponding rights management data attributes and/or processes for creating and/or using the same. In one example, the entire descriptive data structure may be referred to as metadata.

The machine-readable descriptive data structure may or may not be partially or fully protected depending on the particular application. Some machine-readable descriptive data structures may be encrypted in whole or in part, while other descriptive data structures may remain in "unencrypted" form so that they are readily available. Some machine-readable descriptive data structures, whether encrypted or not, may be partially or fully integrity protected, using a cryptographic hash algorithm in conjunction with a security algorithm to form a seal, and/or by using other protection techniques (including hardware, e.g., secure semiconductor and/or hardware packaging protection). The machine-readable descriptive data structures may be self-encapsulated in a rights management data structure, with rules governing their access and use (e.g., license records) also associated together.

Consistent with embodiments of the invention of how the descriptive data structure is effectively utilized, a machine-readable descriptive data structure may be created by a vendor to describe the vendor's specific rights management data structure, such as the overall plan of a secure container. Such descriptive data structure ("descriptive data structure") templates may be used to create containers, and one or more classes may be selected based on one or more possible descriptive data structures, where one or more classes may be based on parameter data. The descriptive data structure may be loaded and used as a plan for the created secure container, and a vendor may keep the descriptive data structure private, or publish it so that other vendors can create compatible, interoperable containers based on the same descriptive data structure.

The descriptive data structure may also be applied by a container viewer, browser, reader or any other end-user designed to work with the container. A truly suitable viewer, or other application, can handle containers of any format using, at least in part, the descriptive data structure. Thus, the descriptive data structure may be used, at least temporarily, to transform and/or customize a general purpose viewer (and/or other application), or a particular viewer (and/or other application) optimized around one or more container classes. In addition, specific readers may be provided with descriptive data structures for efficient processing to locate key media elements (e.g., cover pages, table of contents, advertising indexes, vocabularies, articles, unprotected previews, prices, and/or rights information for viewing, printing, saving, redistribution, related budgets and/or other parameter information, etc.).

Such specialized readers can seamlessly, transparently, and automatically process to provide a user with an easy-to-use interface (e.g., graphically display each key media element) optimized for a particular application container and/or user. For example, these elements may be displayed or used in different forms based on the identity of the user and/or user node, and taking into account one or more class attributes that affect such automated processing.

For example, two or more descriptive data structures may be associated not only to one or more user and/or node classes, but also to containers and/or container content. Thus, a selection among two or more possible descriptive data structures may be made for a given container and/or container content based on more than one classification and/or more than one classification based on parametric data. In summary, the ease of characterization provided by the custom container model, the ability to recycle storage performance optimizations and the consequent transparency of translation from custom containers (e.g., specific descriptive data structures) to general rights management applications is particularly useful. For example, such customized descriptive data structures can be used as a basis to create customized, optimized displayed container content and/or control information, thereby significantly improving the ease of use, effectiveness, transparency, and optimization of a distributed universal rights management environment. In this environment, user nodes can interact with different descriptive data structures, automatically adjusting to meet the needs of business or other rights models associated with the descriptive data structures.

Some vendors may spend considerable time designing complex container descriptive data structures to describe the overall structure of their containers. Because of this expense in structure and format, descriptive data structures are often of great reuse value in the same or similar applications. Entities can utilize descriptive data structures to ensure consistency and efficiency of created containers. Third party vendors (i.e., vendors other than the one responsible for creating the descriptive data structures) may use these descriptive data structures if they want to create containers that are compatible with other entities. For example, a large-volume newspaper publisher develops a descriptive data structure to read its newspaper, and other small newspapers use the same viewer or other tool in the same container format as the large-volume newspaper, and the descriptive data structure is copyrighted and can be doubly protected by the law and rights management system itself. For example, they may also be protected by their own containers and associated controls, ensuring that the descriptive data structure creator, and/or publisher, and/or other users of the descriptive data structure are managed by a fair rights system in return for their efforts to create and/or use the descriptive data structure.

In addition to the foregoing, features and advantages of the present invention are set forth below:

integrity constraints: the descriptive data structure allows a vendor to protect the integrity of its content by implementing integrity constraints. Integrity constraints provide a way to describe the integrity of rules related to content.

Application generation: the descriptive data structure may be used to generate one or more portions of a software program that manipulates the rights management structure. For example, the descriptive data structure can drive an automated packaging process for the digital content as "instructions" and/or be an automated viewer of the digital content such as display priority and organization (e.g., order and/or plan).

Create a dynamic user interface for the application: the application may read the descriptive data structure to generate an optimized interface for data creation, editing, and/or authoring of a particular model that includes complex content, such as file, audio, video, interactive (e.g., query) elements. The data form may be a container, a database and/or any other digital information organization, such as any simple or complex file format. The application may also learn how best to display an interface for collecting and/or creating content by reading the descriptive data structure.

Dynamic user interface of the display application: the application generates the appropriate interface to display the data by reading the descriptive data structure. The data may be in the form of containers, databases, or any other complex file format. The application may also learn how best to display the interface by reading the descriptive data structure to provide the corresponding content. The application may further learn how to manage display functions including content creation and/or packaging and/or user purpose display, and optimization of interactions with other one or more applications, agents, computing environments, entities (including entity classes) of users and/or user nodes, and the like, by reading the descriptive data structures. For example, the user interface may be optimized to interact differently between the following users: the united states air force fighters are directed to teachers of college social science professions, members of the kihan club (a club of american industrial and commercial people) to members of the church club of the new professor, and united states citizens to saudi arabian citizens. The display content should include appropriate display of the expected class member designation and associated organization, or the cancellation of display of some inappropriate information.

Ability to automatically identify and locate a data field: full-text retrieval, brokering, web spiders, and the like advantageously also have the ability to interact with information contained in one or more regions of the descriptive data structure if it is known that the regions in the data file contain potentially interesting information, and that the information has been provided in a predefined format.

Ability to extract the required data without first-hand knowledge of the data format: full-text searches, proxies, web spiders, and the like are beneficial and also have the ability to interact with information contained in one or more regions of a descriptive data structure, if large data files of any complexity, unknown author, and the like, can be processed without special knowledge.

Efficient, human-machine readable data abstraction: the descriptive data structure may be optimized for processing, transmission and/or storage in a small, convenient, low cost manner.

Reusable, marketable — independent of actual data: the descriptive data structure is of any complexity and thus may take a significant amount of time to create and require specific expertise, which gives the descriptive data structure a value for sale.

Flight definition and redefinition of content planning: the use of planning tools allows for rapid iterative design (planning), including editing and modification, which may be more convenient and less costly than creating the same plan, which may be quite difficult, beyond the skills of many users.

Descriptive data structure properties allow hiding meta-features in the actual data: because the same descriptive data structure is handled by the creation process and the post-creation process, metadata may be placed in a descriptive data structure whose package content is not available. One example of whether a particular field is displayed is "must" or "hide".

Design is automated by a descriptive data structure "demon tool": the descriptive data structure itself can be further automated in a "demon tool" fashion. For example, one descriptive data structure may be designed to help define other descriptive data structures. Descriptive data structures defining other descriptive data structures may represent incomplete descriptive data structures of a book or magazine. The "sprite tool" may provide a series of dialog boxes that are displayed to the user to fill out the information left blank, thereby making it a complete descriptive data structure.

Applications outside of the specific rights management hierarchy: for example, the multimodal application may use the descriptive data structure to decide on the probable attributes and/or needs of particular data, such as what vision and feel should be displayed to the user. If the descriptive data structure contains a word processing document, the multimodal application can create an interface suitable for displaying and editing the document, and if the descriptive data structure contains a plurality of executable programs, the multimodal application may ask the user where the file should be stored.

Umbrella applications are able to handle descriptive data structures and represent unknown file types and processes: an umbrella (or polymorphic) application is capable of operating as a specific data file. This umbrella application can extract and handle things in the data files it is interested in, although it ignores or represents something it does not understand (users and/or value chain partners (e.g., distributors) to control the display of these items).

Real-time translation: it is possible to translate descriptive data structures in real time, substantially increasing their efficiency and timeliness.

Real-time adaptivity: the system can accommodate dynamic data arriving in real time by using a descriptive data structure.

Automatic conversion capability: the descriptive data structure may be used to automatically convert from one format to another.

Simplified system design: the use of descriptive data structures may significantly reduce the need for additional "packager" Application Programming Interfaces (APIs) or other container creation process security wrapper designs. Such "packager" APIs require control or restriction of the container creation process to ensure that all created containers are compatible with each other, thus limiting flexibility and customization capabilities.

Object-oriented template programming environment: through a high-level user interface, the priority and associated parameter data specification may optionally use display-related, interaction-related, rights-related concept objects, which makes it easy to create specific template categories such as build and display hints.

Template languages and the use of translators that support programming through the use of language elements and translation of such languages: al. the nodes described by Ginter are programming supported by using language elements and a translator for that language. The language elements include display description, permissions, program interaction elements, priorities, and parameter data.

Brief description of the drawings

Features and advantages of embodiments of the present invention will become more fully apparent from the following detailed description when taken in conjunction with the accompanying drawings in which:

fig. 1A and 1B show an example of a content container.

Fig. 2A and 2B show examples of content containers associated with descriptive data structures.

FIG. 3 shows an embodiment of a descriptive data structure creation and use process.

FIG. 4 shows another embodiment of a create and use process.

FIG. 5 shows an embodiment system architecture using a descriptive data structure.

FIG. 5A shows an embodiment process performed by the system of FIG. 5.

FIG. 6 shows a hierarchical descriptive data structure organization.

FIG. 6A shows an embodiment of how a descriptive data structure may be used with atomic transfer data.

FIG. 7 shows an illustrative data structure format embodiment.

FIG. 8 shows an illustrative data structure creation graphical interface embodiment.

FIG. 9 shows an embodiment process for tracking descriptive data structure rights management related data.

FIG. 10A shows an embodiment that provides interoperability between environments using descriptive data structures.

FIG. 10B further details the organization of the illustrative data structure shown in FIG. 10A.

Detailed description of the invention

FIGS. 2A and 2B show the example containers 100a, 100c of FIGS. 1A and 1B and their associated machine-readable descriptive data structures 200 and 200'. Referring to FIG. 2A, a descriptive data structure 200 is associated with the content container 100a, the descriptive data structure 200 being usable to define the content (and certain other features) of the container 100 a. In the illustrated example, the descriptive data structure 200 defines a number of columns of newspaper style content 102, such as a title (descriptor 202a), release date (descriptor 202b), important news (descriptor 202c), breaking news (descriptor 202d), picture (descriptor 202e), advertisement (descriptor 202f), and column (descriptor 202 g).

In this example, descriptive data structure definition 202 does not include or specify the specific content of the corresponding area of newspaper 102, but rather more abstractly defines the general format that newspaper-style publishing may use. For example, the example descriptive data structure header definition 202A of FIG. 2A does not specify a particular header (e.g., "the Dou Laver wins the triangular flag!"), but instead defines the location in the container data structure 100a (and other features) where the header information resides. (such as logical or other offset addresses). Because the descriptive data structure 200 is generic to one type or family of newspaper style content publications, it may be reused. For example, each daily newspaper may create a usage-related same descriptive data structure 200. The descriptive data structure 200 allows for convenient creation, use, and manipulation of the newspaper style content 102 by abstractly defining the data format and other characteristics of the newspaper style content 102.

Referring to FIG. 2B, another different descriptive data structure 200 'may be used to define other types of content publications 106, such as fashion magazines, for which the descriptive data structure 200' reflects a different format (or possibly other characteristics) than the descriptive data structure 200 of FIG. 2A. For example, since a typical fashion magazine does not include headlines or breaking news, the example descriptive data structure 200' does not define this format. In contrast, a descriptive data structure 200' defining a type of fashion magazine content might define the release date (descriptor 204a), the magazine name (descriptor 204b), the photographer name (descriptor 204c), and the associated art design (descriptor 204 d).

Fig. 2A and 2B illustrate the delivery of descriptive data structures 200, 200' in content object containers 100a, 100c and related content 102, 106. For example, the descriptive data structure 200 may be independently transmitted in its own container and have its access and/or use controlled by corresponding rules. In addition, the descriptive data structure 200 may be stored in a library and transmitted on an as needed basis in a secure or unsecure form depending on the particular needs.

In addition, although FIGS. 2A and 2B are examples of printed publication content, the application of the illustrative data structure 200 is not so limited. Rather, the descriptive data structure 200 can be used to define formats and/or other characteristics that include a wide variety of different types of digital information, as listed below.

Images

Sound

Video

Computer program

Method of

Executable program

An interpreter

Money object

Money container for money objects

Rules

Arbitrary computer input

Arbitrary computer output

Other descriptive data structures

Any other information

Example Process of creating and Using descriptive data structures

FIG. 3 shows an example process of creating and using the descriptive data structure 200. In this example, the planning tool 300 is used to create the descriptive data structure 200. The planning tool 300 may be, for example, a software controlled process that interacts with a person through a graphical user interface. The resulting descriptive data structure 200 it generates (which may be stored on a mass storage device or other memory) can be conveniently used in any number of other processes to create or interpret the stored data. For example, a descriptive data structure may be used for the creation process 302. The creation process 302 reads the descriptive data structure and in response creates an output file 400 in a predefined format, for example, a container 100 corresponding to the format described by the descriptive data structure 200. The viewing process 304 uses the descriptive data structure 200 to locate and display important items in the output file 400. The browsing process 306 uses the descriptive data structure 200 to locate items such as keywords or other searchable text in the stored output file 400. The descriptive data structure 200 provides integrity constraints or rules to protect the integrity of the corresponding content during content use and/or access.

FIG. 4 gives a more detailed example of a descriptive data structure creation and use process. In this example, the planning tool 300 accepts user input 310 through a graphical user interface 312. The output of the planning tool 300 may be a descriptive data structure 200 in the form of a text file. The secure packaging process 302a accepts container-specific data as input, and it may also accept the descriptive data structure 200 as read-only input. The packager 302a packages the container-specific data 314 into the secure container 100. It is also possible to package the descriptive data structure 200 into the same container 100 if required. The viewer 304 may view the data 314 via the descriptive data structure 200 and according to the rules 316. Rules 316 applied to the data 314 and/or the descriptive data structure 200 are also packed into the container.

Example architecture Using descriptive data structures

FIG. 5 shows an example security system architecture suitable for use with the descriptive data structure 200. In this example, the electronic device 500 located within the anti-tamper shield 502 is of the type described in the above-referenced Ginter et al patent specification. The electronic device 500 includes an Application Programming Interface (API) 504. One or more applications 506 communicate with the electronic device 500 through the API 504. In some cases, the application 506 may be executed in the secure electronic device 500. Each application 506 includes a descriptive data structure interpreter 508. In use, the electronic device 500 accesses the secure container 100 and the descriptive data structure 200 and the content 102 contained therein according to the rules 316 and provides the content to the application 506. The interpreter 508 in the application 506 may in turn read and use the descriptive data structure 200. In addition, the application 506 may be polymorphic, which may exhibit a characteristic or behavior defined at least in part by the descriptive data structure 200.

FIG. 5A details an example of an implementation of the example security system architecture of FIG. 5. In this example, the application 506 asks the device 500 to extract the descriptive data structure 200 from the container 100 (as shown in block 550). The electronic device 500 reads the descriptive data structure 200 and provides the descriptive data structure to the application 506 according to the conditions specified by the corresponding rule 316 (as indicated at block 552). The application 506 asks its interpreter 508 to interpret the descriptive data structure 200 (block 554). The interpreter 508 tells the application 506 what the descriptive data structure 200 is to express (block 556). The application 506 extracts or obtains the descriptive data structure information it needs from the interpreter 508 (block 558). For example, assuming that application 506 wishes to display "title" information for newspaper-style content as shown in FIG. 2A, application 506 may provide information to it from interpreter 508 to assist it in locating, reading, formatting, and/or displaying the "title" information.

As another example, interpreter 508 may provide application 506 with an element identifier (e.g., a hexadecimal number or other identifier) corresponding to the "title" information of the newspaper-style content (block 558). The application 506 then provides the appropriate content information to the electronic device 500 through the API504 to ask the electronic device 500 to feed back the "title" (or other) content information 102 in its container 100 (block 560). For example, the application 506 communicates the element identifier provided by the interpreter 508 to the electronic device 500. Even if the application 506 does not have direct knowledge of the container 100 (perhaps it can only access the container 100 through a secure VDE node provided by the device 500), the interpreter 508 (by looking at the descriptive data structure 200) can tell the application 506 enough information so that it can know how to request the required information from the electronic device 500.

The electronic device accesses the information 102 in the container 100 and transmits (according to the rules 316 within the container) the requested information to the application 506 (block 562), and the application 506 then uses the information provided by the electronic device 500 based at least in part on the information about the content that was told to it by the interpreter 508 (block 564). For example, the descriptive data structure 200 may provide features regarding how the application 506 should process the information 102. The descriptive data structure 200 can tell the application 506 that a particular field (e.g., author or copyright field) is always displayed and no other information (e.g., information that should be hidden from most users) is always displayed. The descriptive data structure 200 can also provide a complete representation or "visualization" of information so that the information provider can control the visual and sensory perception of the information as it is displayed or submitted. The descriptive data structure 200 may provide encoding of other features in the form of metadata that can also be used by the application 506 in creating, using, and manipulating the container 100. The descriptive data structure 200 may be used to generate a software program to manipulate the rights management structure. For example, the descriptive data structure 200 can serve as an "instruction" to drive an automated wrapping application for digital information or an automated reader for digital content.

Descriptive embodiments provided by descriptive data structures

FIG. 6 illustrates how the descriptive data structure 200 describes and defines an information structure of any complexity, such as the cascaded container 100. In this example, the container 100 includes characteristics 600(1), 600 (2). Properties 600(1) include n attributes 602(1), (602), (2), (… 602) (n). Property 600(2) includes any number of attributes 604(1), 604(2) … which also includes an additional property 606. In turn, the attribute 606 may have its own attributes 608(1), 608(2) … associated descriptive data structures that may be organized into the tree list 250 to provide a recurrence structure reflecting the recurrence structure of the container 100 contents themselves. For example, list 250 includes property descriptors 252(1) corresponding to properties 600(1), 600(2), respectively. 252(2) constituent characteristic branches. In turn, each property descriptor 252 contains a list of attributes 254, or possibly additional property descriptors 256, in the same recursive, cascading design to reflect the instance content container structure. The descriptive data structure 200 may be used to describe any complexity, cascaded or non-cascaded data structure of any dimension (1 to n).

FIG. 6A shows that the descriptive data structure 200 may be used to link any type of information such as events or methods that define "atomic transactions" (e.g., real estate transactions). In the example shown in FIG. 6A, the container 100 includes one or more descriptive data structures 200 and their corresponding control sets 316 associated with a series of "events" 700 that define a real estate transaction. For example, the descriptive data structure 200 may include a number of different items 200A-200N (e.g., "submit", "accept", "buy/sell", "check", "mortgage", etc.) associated with different transactions "events". The items 200A-200N define the location of events in the container 100. The items 200A-200N may also include metadata to provide additional features corresponding to the event (e.g., how particular information about the event should be displayed).

Embodiments of descriptive data Structure Format

FIG. 7 illustrates, by way of example, how the descriptive data structure is formatted. As described above, the descriptive data structure 200 may contain a list, such as a linked list. Each entry 260(1), 260(2) may include a series of data fields as follows:

object name field 262

One or more metadata fields 264 (which may be part of and/or referenced by the descriptive data structure)

Location information 266 (which helps identify corresponding information for container data structure 100)

Object name field 262 may contain a constant corresponding to (or describing) a type of information. For example, object name field 262 may serve as a "handle" to content or data; it may be an indirect reference to content or data; it can be used to find content or data. The following are examples of object names:

generic destination object name

Number of

Character string

Date

Title

Description of the invention

Authors refer to

Suppliers of goods

Multipurpose Internet Mail Extensions (MIME) type

Version(s)

Uniform Resource Locator (URL)

Electronic mail

New group

Filename

Key word

Date of creation

Modifying the date

Last date of visit

Local platform

Size and breadth

Content providing method and apparatus

Preview

Draft (thumbbnail)

Text

Works and works

Description of the invention

Is unknown

Form panel

Name of the List

Container with a lid

Book style object name

Expiration date

Banner page

Preamble of preamble

Introduction to

Abstract

Directory table

Badge

Seal number

Index

Electronic mail style object name

From (sender)

To (addressee)

Copying and conveying

Themes

Message body

Package with a metal layer

Newspaper style object names

Date of issuance

Article

Column (III)

Cover story

Important story

Breaking news

Advertising

Node (C)

Society theory

The descriptive data structure 200 may include or reference any type of data or metadata. In this example, the descriptive data structure 200 points to or references metadata with an object name field 262. The metadata may define specific characteristics associated with the object name. For example, metadata 264 may impose integrity or other constraints during creation and/or use (e.g., "when you create an object you need to provide some information", or "when you display an object you need to display some information").

In one example, the descriptive data structure 200 uses the object name 262 to reference metadata stored elsewhere, such as in the container 100. This referencing technique has many advantages, such as, for example, it is useful to store metadata in a secure container 100 that is separate from the descriptive data structure 200, which occurs because one wishes to make the descriptive data structure convenient for accessing external applications while protecting the relevant metadata. For example, consider an example of processing a web spider query that might ask a particular object name 262 of the descriptive data structure 200, and if the object name is found, the web spider would request the corresponding metadata, which the web spider can conveniently access, but only under appropriate conditions, the relevant metadata from the container 100. The condition is controlled by the respective secure electronic device 500 based on the relevant rule 316. Another advantage is that storing the metadata separately from the descriptive data structure 200 may allow the same descriptive data structure to be used for different metadata in different environments. Assume that the descriptive data structure 200 contains object names, such as "keywords". When the descriptive data structure 200 is associated with the container 100A, the descriptive data structure object name "keyword" references keyword metadata in the container 100A. However, if the same descriptive data structure 200 is later associated (e.g., packaged) with a different container 100c, then the descriptive data structure object name "key" references the key data of the container 100B.

Although it may be preferable to use the object name 262 to reference metadata stored elsewhere, there are still other instances where metadata needs to be explicitly contained in the descriptive data structure 200, and for purposes of illustration, the example descriptive data structure 200 shown in FIG. 7 contains both the metadata field 264 and the object name 262 to reference metadata located in the container 100, either technique being used.

Thus, the descriptive data structure 200 allows value chain participants to account for the integrity of protected content by implementing integrity constraints. The descriptive data structure 200 integrity constraints provide a way to describe rules about content. For example, the descriptive data structure 200 may specify that an article of a newspaper cannot be viewed when its title is not viewed, and the corresponding integrity constraint may be expressed as the rule "if there is an article, then there must be a title". As another example, a photograph that is part of a magazine and its description must be entered and exited, and the integrity constraint rule provided by the descriptive data structure 200 may be "do not provide a photograph without a corresponding description".

The descriptive data structure 200 integrity constraints provide a tool for value chain participants to protect the use of the descriptive data structure 200, ensuring that the contents of a particular descriptive data structure representation contains all necessary components. This is exactly the representation of the descriptive data structure. It provides a standardized way for vendors to establish specifications and increase usage, with many possible integrity constraints, to name a few,

must: a is an essential part of the content

And optionally: a is an optional component of the content

The necessary relationship: if a exists, then b also exists, or if a is submitted to b, then c and d must also be submitted, and conversely if b does not exist, then a cannot exist, such relationship is 1: m (m > 0).

An optional relationship: if a is present, b may or may not be present. If b is present, then authorization a is present. Such a relationship is 1: n (n > ═ 0)

Repetition of: a must occur n times (n > 1). Value ranges and the like can be specified herein.

Other rules and/or requirements

Metadata 264

Embodiments of a graphical interface for creating descriptive data structures

FIG. 8 shows an example of a descriptive data structure creation graphical user interface 312. In this example, the graphical user interface 312 displays the user object name. In addition, the graphical user interface 312 provides options for specifying the associated metadata 264, which as shown in FIG. 8 may be:

"build type" metadata (this information is necessary when building an object, and is always or never prompted by the object creation tool when building an object)

Display metadata (e.g., always display related information such as copyright notice, author name, etc., or always or never prompt for that information.)

Planning "hints" and field definitions (e.g., text blocks, integers, files, pictures, or other data types)

The metadata description is not limited to the above examples, and other metadata features and attributes may be used.

Example Process Using descriptive data Structure

FIG. 9 illustrates an example design of an illustrative data structure using the infrastructure described in U.S. patent application 08/699,712 (referenced above), which is usable in many different environments. For example, the supplier 600 of the descriptive data structure 200 wants to know which descriptive data structure 200 is the most liked by its consumer, so that he/she can improve the quality of his/her product. Alternatively, the vendor 600 may require the consumer to use the descriptive data structure 200 on a single-user basis or other basis. In other examples, some descriptive data structures 200 or descriptive data structure 200 classes may be used only by authorized users or authorized user classes.

As shown in FIG. 9, a descriptive data structure provider 600 transmits the descriptive data structure 200 and the corresponding control set 316 to a value chain participant 602. The controls 316 provide rules and their results to control or affect the use or other manipulation of the descriptive data structure 200 by the value chain participants 602. The controls 316 and the descriptive data structure 200 may be packaged into a container 100. The value chain participant 602 may obtain the container 100 containing the descriptive data structure 200 directly from the descriptive data structure provider 600; alternatively, the supplier provides it to the rights permissions clearing house, from which the participant 602 then obtains it (see container 100B in FIG.).

The value chain participant 602 uses the descriptive data structure 200 to create the content 102, and the participant 602 packages the content 102 and the associated controls 316A into a container 100A. The participant 602 may package the descriptive data structure 200 and its associated controls 316a, 316b and the content 102 into the same container if it so desires, or may independently transmit the descriptive data structure and its controls to the end user 606 based on the vendor 600 and/or the rights license clearing house 604.

End user 606(1) … 606(n) uses the descriptive data structure 200 (e.g., reads, views or accesses container content) in conjunction with content 102 and in accordance with controls 316. The controls 316, 316a request that the user device provide usage data 610 to a usage inventory house 612, the usage inventory house 612 provides usage data 610A for accessing and/or using the descriptive data structure 200 to the descriptive data structure provider 600, and provides usage data 610B for accessing and/or using the content 102 independently to the value chain participants 602.

Descriptive data structures for obtaining rights management

A degree of interoperability between environments

The descriptive data structure 200 provided by the present invention may provide a degree of interoperability between a source rights management environment and a target rights management environment and/or provide a bridge to achieve at least a degree of interoperability between a rights management environment and its outside world.

Different rights management environments may have a large incompatible mechanism in defining rights with respect to objects. The descriptive data structure 200 provides at least a partial bridge to achieve a degree of compatibility and interoperability. For example, a descriptive data structure created by a vendor when defining an object in a source rights management environment may be used in the process of one or more target rights management environments. An object creator or another vendor may specify certain rules, integrity constraints, and/or other features in the descriptive data structure 200 that may be applied to an object upon its entry into a target rights management environment that may selectively enforce those rules, constraints, and/or other features based on its level of trust in the source environment. For example, an object imported from an EDI system applying x.12 security may be more trustworthy than an object imported from another environment having less (or no) security.

As another example, a vendor that creates an object outside of any rights management environment may create the descriptive data structure 200 for use if the object is imported into one or more rights management environments. The target rights management environment may utilize the descriptive data structure to efficiently understand and manipulate objects. Further, the descriptive data structures created in the rights management environment may be exported to one or more applications outside of the environment and help these applications interpret the exported content or other information.

FIG. 10A illustrates how the illustrative data structure 200 is used to provide interoperability. In the example shown in FIG. 10A, descriptive data structure creation tool 800 creates descriptive data structure 200 containing one or more target data blocks 801. The descriptive data structure creation tool 800 may be based on and/or include some or all of the capabilities of the planning tool 300, in addition to providing interoperability. Alternatively, the descriptive data structure creation tool 800 does not include any of the capabilities of the planning tool 300, but instead creates the descriptive data structure 200 solely for interoperability purposes. The descriptive data structure creation tool 800 may be an application with a graphical user interface, a background process that displays the user interface only when configured by the user, a portion of an operating system, a portion of computer firmware, a server process that operates independently as part or all of a "gateway" between systems (e.g., public and private networks, two or more private networks, local and wide area networks, etc.), or any other desired implementation or integration.

The target data block 801 provides information for providing interoperability with a particular target environment 850. In some cases, a single descriptive data structure 200 provides interoperability with n different target environments 850 by including n target data blocks 801(1) … 801(n) corresponding to the different target environments 850(1) … 850 (n).

In this example, each target data block 801 contains rule (control) information. Different target data blocks 801 provide different rule information for different target environments 850, which may be related operations (events) and/or results of the application function 856 in the relevant target environment 850, as exemplified below:

allowed and/or required operations

Intrinsic and/or extended operations of allowed and/or required operations

Results of performing the allowed and/or required operations

The target data block 801 may also include additional information to issue instructions to the descriptive data structure parser 852 and/or interpreter 854 located in the corresponding target environment 850, if desired.

FIG. 10B shows a detailed example to illustrate the organization of the target information in the illustrative data structure 200. In this example, the descriptive data structure creation tool 800 creates a descriptive data structure header 805, the descriptive data structure header 805 referencing one or more target record headers 807. As shown, the descriptive data structure header 805 may include the following fields: the "destination number" field 809 is used to indicate the number of target data blocks 801 in the descriptive data structure 200, the "offset to first target data area" field 811 is used to provide the location of the first target data block 801(1) in the descriptive data structure 200, the "source message" field 812A is used to identify the source environment, and the optional "creator seal" field 812B may be used to verify the integrity and validity of the descriptive data structure 200. The "origination message" field 812A (optional) includes an "origination ID" (used to help verify the origination environment of the descriptive data structure 200) and an optional "origination seal" (which may or may not be present in the "origination message" field). At the beginning of each target data block 801 in the descriptive data structure 200 is a target record header 807 that includes a "target ID" field 813, a "length" field 815, an "offset to next target data region" field 817, an optional "creator seal" field 819, and an optional "source message" field 821. The "destination ID" field 813 specifies a unique identification number or value corresponding to the associated destination data block 801 and/or identifying the extended destination environment. The "length" field 815 indicates the length of the target data block 801 and the "offset" field 817 indicates the (relative or absolute) position of the next target data block 801 in the descriptive data structure 200 (for the last target data block, the field takes a null value).

The optional "creator seal" fields 812B, 819 (and "source seal") may be cryptographic seals for ensuring that the descriptive data structure 200 and the target record 801, respectively, have not been altered since creation, and may also identify the creator and/or source of the descriptive data structure 200. Optional source messages 812C and 821 may provide information to help ensure that the target environment knows which source environment created descriptive data structure 200.

Referring back to FIG. 10A, the descriptive data structure creation tool 800, in creating the descriptive data structure 200, may encrypt the encapsulated descriptive data structure 200 and each target data block 801 using a suitable encryption process to complete it. One example of an encryption process is to first run a cryptographic hash function (e.g., SHA, MD5, etc.) on the data and then encrypt the resulting hash value with the private key of the descriptive data structure creator associated with an asymmetric encryption system (e.g., RSA, El Gamal, etc.). If encapsulation is used, the descriptive data structure creator should ensure that the public key as well as the encrypted private key are authenticated (e.g., encrypted with a private key authorized for authentication) and enable the target environment to utilize it to verify the encapsulation (e.g., by including the authentication in the descriptive data structure 200 and issuing the authentication over a public network).

If source messages 812C, 821 are used, they should provide representative information of the source environment to help the target environment identify the source environment and can further help confirm that the descriptive data structure 200 was indeed created by the source environment (and thus it can be extended into environments that trust the source environment). For example, the source environment has a Protected Processing Environment (PPE), which can be of the form described in the above-referenced Ginter et al patent application. Such a protected processing environment has a key (e.g., a private key of a public/private key pair) available for encrypting an appropriate cryptographic hash in the descriptive data structure header 805 or the target data block header 807. In this example, the target environment needs to use a trust technique (e.g., passing a certificate issued by a trusted certificate authority) to obtain a corresponding key (e.g., a public key of a public/private key pair) in order to evaluate the source message. Alternatively, the descriptive data structure creation tool 800 is provided with a key at the time of manufacture that one can use instead of a key from the protected processing environment, although typically this technique is more easily hacked by an experienced computer hacker and thus somewhat less trusted by the target environment.

In addition (if encryption techniques are not appropriate or required), the source message may contain a unique identifier corresponding to the source environment.

The descriptive data structure creation tool 800 (see FIG. 10A) packages the resulting descriptive data structure 200 into the secure container 100 along with the corresponding object 830. Alternatively, the descriptive data structure creation tool 800 embeds or associates the descriptive data structure 200 with the object 830, the 'object 830' providing a method to publish the descriptive data structure to the target environment analyzer 852. The descriptive data structure 200 and its associated objects 830 may be transferred to one or more target environments 850 for processing.

Target environment analyzer 852 (and/or interpreter 854) may be part of an application program, part of an operating system, or part of a utility program used by or associated with the application program and/or operating system. Target environment analysis program 852 accepts descriptive data structure 200 and analyzes descriptive data structure 200 to locate target data block 801(k) corresponding to target environment 850 (k). The parser 852 then determines the rules that the target data block contains based on the corresponding target data block 801. The parser 852 is able to understand the structure of the descriptive data structure 200 well so as to find its corresponding appropriate target data block 801 (with header information as shown in fig. 10B), as well as the rules in the target data block. The target environment parser 852 does not need to understand any additional rules 316 that may be packed into the container 100 or passed along with the object 830; if desired, however, the analysis program may use any such additional rules (e.g., it may be able to learn about a particular target environment 850 by understanding other target data blocks 801 (the rules of which are based on published specifications and/or criteria) when it finds that no target data block 801 in the descriptive data structure 200 corresponds to the particular target environment 850).

The target environment analyzer 852 may obtain the applicable target rules from the target data block 801 and provide these rules to the application function 856. The application functions 856 may define any operations related to the object 830, such as the following:

shearing

Copying

Printing

Pasting

Storage of

Change of

Deletion of

Any other operation

The target rules provided by the parser 852 may be used to permit, request, and/or block certain operations; extended definitions to perform specific operations (e.g., limit copy number, define extended clips, apply to rules for subsequent use of clip information, etc.); the result of performing a particular operation is defined (e.g., the user is required to print, use, and/or access all or a portion of the object 830, a record of the time and/or quantity at which that operation was performed is maintained).

On the other hand, the parser 852 also provides some or all of the rules it obtained from the target data block 801 to other designs to apply the rules, such as the "other rights management functions" block 858. Block 858 may provide any type of rights management function. The interpreter 854 may be used if necessary to let the application functions 856 and/or the "other rights management functions" block 858 understand the rules. In some cases, the interpreter 854 may be used to further refine, parameterize, and/or secure the rule information obtained from the target data block 801 so that they are more or even fully compatible with the "other rights management functions" block 858.

One useful data structure definition method and design is described above in connection with practical and existing embodiments. The invention is not limited to these examples, but on the contrary, it includes various modifications and equivalents defined in the claims, which are within the spirit of the claims.

Claims (22)

1. A method of using a descriptive data structure, arranged in a first data transaction at a first address, the method comprising:

receiving at a communication port of said first data processing arrangement a first secure container from an address remote from said first address, said first secure container having at least (a) content, and (b) at least one rule designed to at least partially govern at least one use or access of said content, said governing comprising at least a requirement to temporarily store some information relating to said use or access;

receiving at the communication port a second secure container from an address remote from the first address, the second secure container having at least (a) a descriptive data structure including information at least partially describing or representing at least one aspect of an organization of contents of the first secure container, and (b) at least one rule designed to at least partially govern at least one use or access of the descriptive data structure;

using the second container rule to access at least a portion of the descriptive data structure; and

using said descriptive data structure portion at least in a single use of the contents of said first secure container;

wherein the use of the descriptive data structure portion further comprises using the organization information for identifying the designated portion of the first secure container content;

the first data processing arrangement further comprises a first computer program having a descriptive data structure interpreter; and

the step of using said descriptive data portion comprises causing the first computer program to be used.

2. The method of claim 1, wherein:

said first computer program comprises a browser and the step of using said descriptive data structure portion further comprises:

the browser using the descriptive data structure for identifying and locating a content portion of the first secure container; the browser causes the located first secure container content portion to be displayed.

3. The method of claim 2, wherein:

the step of the browser using the descriptive data structure for identifying and locating the first secure container content portion further comprises the browser receiving a unit identifier from the descriptive data structure, the unit identifier identifying the first secure container content portion; and

the step of the browser displaying the located first secure container content portion further comprises the browser accessing the first secure container content portion using the element identifier.

4. The method of claim 3, further comprising:

after the identification is completed, at least one rule of the first secure container is used to access the identified first secure container content portion.

5. The method of claim 4, further comprising:

receiving a third secure container at the communication port, the third secure container including (1) metadata associated with the descriptive data structure; and (2) at least one rule designed to govern, at least in part, a one-time use or access of the metadata structure; and

the step of using the descriptive data structure further comprises:

in the descriptive data structure, accessing a reference to metadata;

using at least one rule of the third container to access at least a portion of the metadata; and

using the metadata in a process using the descriptive data structure in connection with use of the third secure container content.

6. The method of claim 5, wherein:

the step of using the metadata comprises using information in the metadata for at least partially deciding whether a portion of the first secure container content should be displayed to a user.

7. The method of claim 6, wherein the use of the metadata comprises:

if some or all of the first secure container contents are displayed, the metadata includes information specifying which designated information must be displayed;

the step of using the metadata includes the step of displaying the specified information.

8. The method of claim 7, wherein:

the designation information includes information identifying at least one owner or creator of the first secure container content portion.

9. The method of claim 5, wherein:

receiving the first secure container from a second data processing arrangement; and

receiving the second secure container and a third secure container from a third data processing arrangement;

the second and third data processing arrangements are located at a separate location from each other and the addresses of both the second and third data processing arrangements are different from the address at which the first data processing arrangement is located.

10. A distributed data processing apparatus comprising:

the first data processing apparatus includes:

a central processing unit;

a first memory storing a descriptive data structure, the descriptive data structure including:

information relating to a first organization of units in a secure container, the information comprising:

information relating to the organization of the units in the secure container; and, information relating to addresses of at least some of said units in said secure container;

a communication device by which the descriptive data structure may communicate with a data processing device different from the first data processing device;

a second data processing apparatus having an address different from that of the first data processing apparatus, the second data processing apparatus comprising:

a central processing unit;

a second memory comprising:

the first safety container includes at least:

a data unit constructed at least in part from information the descriptive data structure has; and at least one rule for at least partially governing at least one aspect of access or use of said data unit;

at least one of said rules requires information that at least one use of at least one of said data units can be at least temporarily recorded; and

at least one computer program designed for a part of said descriptive data structure on said first secure container or on the content of said first secure container, at least in one operation;

said using comprises using at least said information related to unit organization identifying and/or locating at least one said unit in said first secure container;

a communication device by which the second data processing device can receive at least a portion of the descriptive data structure or a copy thereof.

11. The distributed data processing apparatus of claim 10, wherein:

the application includes a browser that uses the information relating to the unit organization information to at least partially control display of at least a portion of the information from the secure container in the first secure container.

12. The distributed data processing apparatus of claim 10, wherein:

the computer program is integrated into an operating system.

13. The distributed data processing apparatus of claim 12, wherein:

the operating system is compatible with at least one version of the microsoft windows operating system.

14. The distributed data processing apparatus of claim 10, wherein:

the descriptive data structure is included in a second secure container;

the second safety container includes at least:

the descriptive data structure; and

at least one rule that at least partially governs at least one use of at least a portion of the descriptive data structure.

15. The distributed data processing apparatus of claim 14, wherein:

the computer program includes means for the second container rule to govern at least one aspect of use of the computer program of the descriptive data structure.

16. The distributed data processing apparatus of claim 15, further comprising:

metadata associated with the first secure container.

17. The distributed data processing apparatus of claim 16, wherein the metadata is stored in the second secure container.

18. The distributed data processing apparatus of claim 16, wherein the metadata is stored in a third secure container.

19. The distributed data processing apparatus of claim 18, further comprising:

a third data processing apparatus, the third data processing apparatus comprising:

a central processing unit;

a third memory, said third memory comprising:

a third secure container including said metadata;

at least one rule for at least partially governing at least one aspect of access or use of the metadata; and

a communication device by which the third data processing device can communicate the third secure container, or a copy of the third secure container, with the second data processing device.

20. The distributed data processing apparatus of claim 10, wherein:

the rules include at least one rule that at least partially controls at least one aspect of the auditing process.

21. The distributed data processing apparatus of claim 10, wherein:

the rules include at least one rule that at least partially controls at least one aspect of budget processing.

22. The distributed data processing apparatus of claim 10, wherein:

the second data processing means comprises a secure electronic device.