 |
Claims  |
|
|
We claim:
1. A method including:
generating a descriptive data structure in a first data processing device characterized by a first security aspect;
specifying information in the descriptive data structure, including information relating to the first security aspect, a first rule, and a second rule;
associating a third rule with the descriptive data structure, the third rule at least in part controlling use of at least a portion of the descriptive data structure;
transmitting the descriptive data structure to a second data processing device;
at the second environment, retrieving from the descriptive data structure
the information relating to the first security aspect, the retrieval being governed at least in part by the third rule; and
determining whether to use the first rule or the second rule based on the information.
2. The method of claim 1, wherein determining includes determining the level of security present at the first data processing device based on the information related to the first security aspect.
3. The method of claim 2, wherein determining includes determining to use the first rule or the second rule, but not both.
4. The method of claim 1, wherein specifying information in the descriptive data structure includes populating a first target block and a second target block.
5. A descriptive data structure embodied on a computer-readable medium or other logic device, including the following elements:
identification information at least in part identifying a first rights management data structure;
organization information at least in part describing the organization of at least some governed information contained within or referenced by the first rights management data structure;
rule information relating to a first rule used to at least in part govern use of at least a portion of the governed information contained within the first rights management data structure; and
a second rule used to at least in part govern use of at least a portion of the descriptive data structure.
6. The descriptive data structure of claim 5, in which the first rights management data structure is a secure container.
7. The descriptive data structure of claim 6, in which the secure container includes:
the governed information; and
the first rule.
8. The descriptive data structure of claim 6, in which the secure container includes the descriptive data structure.
9. The descriptive data structure of claim 5, in which:
the first rule is stored outside the descriptive data structure; and
the rule information includes information regarding the location at which the first rule is stored.
10. The descriptive data structure of claim 5, in which:
the first rule is a display rule at least in part governing the display of at least a portion of the governed information.
11. The descriptive data structure of claim 5, in which:
the governed information includes source information at least in part identifying an author, creator, publisher and/or owner of at least a portion of the governed information; and
the first rule requires display of the source information under circumstances specified by the rule.
12. The descriptive data structure of claim 5, in which:
the first rule constitutes a creation rule at least in part governing the creation of a specific example of the first rights management data structure.
13. The descriptive data structure of claim 12, in which:
the creation rule at least in part specifies information which must be included with the specific example of the first rights management data structure.
14. The descriptive data structure of claim 5, in which:
the descriptive data structure is stored in a second rights management data structure.
15. The descriptive data structure of claim 5, further including:
information relating to the organization of at least some information contained in a second rights management data structure which differs in at least one respect from the first rights management data structure.
16. The descriptive data structure of claim 5, which:
the organization information includes information relating to the location of at least some of the governed information.
17. The descriptive data structure of claim 5, further including:
a first target data block including information relating to a first target environment in which the descriptive data structure may be used.
18. The descriptive data structure of claim 17, further including:
a second target data block including information relating to a second target environment in which the descriptive data structure may be used.
19. The descriptive data structure of claim 5, further including:
a source message field containing information at least in part identifying at least one source for the descriptive data structure.
20. The descriptive data structure of claim 19, in which:
the source identification information includes environment information relating to at least one aspect of an environment in which the descriptive data structure was at least in part created.
21. The descriptive data structure of claim 20, in which:
the environment information includes information relating to security present at the environment.
22. The descriptive data structure of claim 5 further including a source seal.
23. The descriptive data structure of claim 22, in which:
the source seal includes a hash of at least a portion of the descriptive data structure.
24. The descriptive data structure of claim 22, in which:
the source seal is encrypted based on a private key.
25. The descriptive data structure of claim 24, further including:
key location information related to a location from which a public key corresponding to the private key may be obtained.
26. The descriptive data structure of claim 25, in which:
the key location information is contained within a certificate.
27. The descriptive data structure of claim 26, in which:
the certificate is contained in the descriptive data structure.
28. A distributed data processing arrangement including:
a first data processing apparatus including:
a central processing unit; and
a first memory storing (1) a descriptive data structure, the descriptive data structure including information regarding a first organization of elements within a secure container, and (2) a first rule at least in part governing use of at least a
portion of the descriptive data structure; and
a second data processing apparatus including:
a central processing unit; and
a second memory storing a first secure container including:
data elements organized at least in part in accordance with the information contained in the descriptive data structure; and
a rule set made up of at least a second rule, the rule set used to at least in part govern at least one aspect of access to or use of the data elements;
the second rule requiring that information regarding at least one use of at least one of the data elements be at least temporarily recorded.
29. The distributed data processing arrangement of claim 28, in which:
the descriptive data structure is contained in a second secure container, which also includes the second rule.
30. The distributed data processing arrangement of claim 29, further including metadata relating to the contents of the first secure container.
31. The distributed data processing arrangement of claim 30, in which:
the metadata is stored in the second secure container.
32. The distributed data processing arrangement of claim 30, in which:
the metadata is stored in a third secure container.
33. The distributed data processing arrangement of claim 31, further including:
a third data processing apparatus, including:
a central processing unit;
a third memory including:
the third secure container and
a rule used to at least in part govern at least one aspect of
access to or use of the metadata; and
communications means by which the third data processing apparatus may communicate the third secure container, or a copy of the third secure container, to the second data processing apparatus.
34. The distributed data processing arrangement of claim 28, further including:
a computer program designed to use at least a portion of the descriptive data structure in an operation on the first secure container or the contents of the first secure container.
35. The distributed data processing arrangement of claim 34, in which:
the computer program includes means for using a rule from the rule set to govern at least one aspect of the computer program's use of the descriptive data structure.
36. The distributed data processing arrangement of claim 34, which the computer program is designed to use the information regarding the organization of elements within the first secure container to identify or locate at least one of the
elements.
37. The distributed data processing arrangement of claim 34 in which:
the computer program includes a browser which uses the information regarding the organization of elements within the first secure container to control, at least in part, the display of at least some information from the first secure container.
38. The distributed data processing arrangement of claim 34, in which:
the computer program is integrated into an operating system.
39. The distributed data processing arrangement of claim 38, in which:
the operating system is compatible with at least one version of Microsoft Windows.
40. The distributed data processing arrangement of claim 28, in which:
the rule set includes a rule at least in part controlling at least one aspect of an auditing process.
41. The distributed data processing arrangement of claim 28, in which:
the rule set includes a rule at least in part controlling at least one aspect of a budgeting process.
42. The distributed data processing arrangement of claim 28, in which the second data processing apparatus includes a secure electronic appliance.
43. A method of using a descriptive data structure, at a first data processing arrangement located at a first site, including:
receiving a first secure container including governed information;
receiving a first rule set including at least one rule, the first rule set governing at least one aspect of access to or use of the governed information and containing a first rule at least in part governing at least one aspect of an auditing
process involving the governed information;
receiving a second secure container including a descriptive data structure, the descriptive data structure including information at least in part describing or representing at least one aspect of the organization of the first secure container
governed information;
receiving a second rule set including at least one rule, the second rule set governing at least one aspect of access to or use of the descriptive data structure;
using the second rule set to gain access to at least a portion of the descriptive data structure; and
using the accessed descriptive data structure portion to make a use of the first secure container governed information.
44. The method of claim 43, in which using the descriptive data structure portion includes:
identifying a first portion of the first secure container governed information using information from the descriptive data structure.
45. The method of claim 44, in which:
the first portion of the first secure container governed information identifies or describes a second portion of the first secure container governed information.
46. The method of claim 45, in which identifying a first portion is followed by displaying information from the first portion of the first secure container governed information.
47. The method of claim 46, in which displaying information from the first portion of the first secure container governed information includes:
displaying a title of a work contained in the second portion of the first secure container governed information.
48. The method of claim 46, in which displaying information from the first portion of the first secure container governed information includes:
displaying a summary of the second portion of the first secure container governed information.
49. The method of claim 43, in which the first data processing arrangement includes a descriptive data structure interpreter; and
using the accessed descriptive data portion is carried out at least in part through use of the descriptive data structure interpreter.
50. The method of claim 49, in which the descriptive data structure interpreter is integrated with a browser and using the accessed descriptive data structure portion further includes the steps, performed by the browser, of:
using the descriptive data structure to identify and locate a portion of the first secure container governed information, and
causing the display of the located portion.
51. A method of creating a first secure container, including:
accessing a first control, which at least in part governs use of a descriptive data structure;
in compliance with the first rule, accessing the descriptive data structure, which includes or addresses:
organization information at least in part describing a required or desired organization of a content section of the first secure container, and
metadata information at least in part specifying at least one step required or desired in creation of the first secure container;
organizing information contained in the first secure container using the descriptive data structure; and
using the metadata information to at least in part generate or identify a second control designed to govern at least one aspect of access to or use of at least a portion of the information contained in the first secure container.
52. The method of claim 51, in which the descriptive data structure is contained in a second secure container with which the first control is associated and accessing the descriptive data structure includes:
opening the second secure container in compliance with the first control.
53. The method of claim 51, further including:
using the metadata information to at least in part identify or generate a third control to govern an aspect of access to or use of at least a portion of the information contained in the first secure container.
54. The method of claims further including:
associating the third control with the first secure container.
55. The method of claim 51, further including:
receiving the descriptive data structure at a first site from a second site prior to accessing the descriptive data structure; and
creating the first secure container at the first site.
56. The method of claim 55, further including:
receiving the metadata at the first site prior to using the metadata, the metadata being received separately from the descriptive data structure.
57. The method of claim 56, further including:
requesting the metadata by the first site based on information contained in the descriptive data structure.
58. The method of claim 56, wherein receiving the metadata includes:
receiving the metadata at the first site in a second secure container having associated a third control; and
wherein using the metadata in the creation of the first secure container occurs after the first site has complied with a requirement imposed by the third control.
59. The method of claim 51, further including:
storing owner or creator information in the first secure container in compliance with the descriptive data structure.
60. The method of claim 59, further including:
storing copyright ownership information in the first secure container in compliance with the descriptive data structure.
61. The method of claim 60, further including:
storing an advertisement in the first secure container in compliance with the descriptive data structure.
62. The method of claim 61, in which:
the creation of the first secure container includes placing the owner or creator information, the copyright ownership information, and the advertisement in locations specified at least in part by the descriptive data structure.
63. The method of claim 51, in which:
the descriptive data structure includes information specifying fields relating to at least one atomic transaction.
64. The method of claim 63, in which:
the atomic transaction information fields include fields for offer and acceptance information. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
FIELD OF THE INVENTION
This invention relates to techniques for defining, creating, and manipulating rights management data structures. More specifically, this invention provides systems and processes for defining and/or describing at least some data characteristics
within a secure electronic rights management container. The present invention also provides techniques for providing rights management data structure integrity, flexibility, interoperability, user and system transparency, and compatibility.
BACKGROUND AND SUMMARY OF THE INVENTION(S)
People are increasingly using secure digital containers to safely and securely store and transport digital content. One secure digital container model is the "DigiBox.TM." container developed by InterTrust Technologies Corp. of Sunnyvale Calif. The Ginter et al. patent specification referenced above describes many characteristics of this DigiBox.TM. container model--a powerful, flexible, general construct that enables protected, efficient and interoperable electronic description and regulation
of electronic commerce relationships of all kinds, including the secure transport, storage and rights management interface with objects and digital information within such containers.
Briefly, DigiBox containers are tamper-resistant digital containers that can be used to package any kind of digital information such as, for example, text, graphics, executable software, audio and/or video. The rights management environment in
which DigiBox.TM. containers are used allows commerce participants to associate rules with the digital information (content). The rights management environment also allows rules (herein including rules and parameter data controls) to be securely
associated with other rights management information, such as for example, rules, audit records created during use of the digital information, and administrative information associated with keeping the environment working properly, including ensuring
rights and any agreements among parties. The DigiBox.TM. electronic container can be used to store, transport and provide a rights management interface to digital information, related rules and other rights management information, as well as to other
objects and/or data within a distributed, rights management environment. This arrangement can be used to provide an electronically enforced chain of handling and control wherein rights management persists as a container moves from one entity to another. This capability helps support a digital rights management architecture that allows content rightsholders (including any parties who have system authorized interests related to such content, such as content republishers or even governmental authorities)
to securely control and manage content, events, transactions, rules and usage consequences, including any required payment and/or usage reporting. This secure control and management continues persistently, protecting rights as content is delivered to,
used by, and passed among creators, distributors, repurposers, consumers, payment disagregators, and other value chain participants.
For example, a creator of content can package one or more pieces of digital information with a set of rules in a DigiBox secure container--such rules may be variably located in one or more containers and/or client control nodes--and send the
container to a distributor. The distributor can add to and/or modify the rules in the container within the parameters allowed by the creator. The distributor can then distribute the container by any rule allowed (or not prohibited) means--for example,
by communicating it over an electronic network such as the Internet. A consumer can download the container, and use the content according to the rules within the container. The container is opened and the rules enforced on the local computer or other
InterTrust-aware appliance by software InterTrust calls an InterTrust Commerce Node. The consumer can forward the container (or a copy of it) to other consumers, who can (if the rules allow) use the content according to the same, differing, or other
included rules--which rules apply being determined by user available rights, such as the users specific identification, including any class membership(s) (e.g., an automobile club or employment by a certain university). In accordance with such rules,
usage and/or payment information can be collected by the node and sent to one or more clearinghouses for payment settlement and to convey usage information to those with rights to receive it.
The node and container model described above and in the Ginter et al. patent specification (along with similar other DigiBox/VDE (Virtual Distribution Environment) models) has nearly limitless flexibility. It can be applied to many different
contexts and specific implementations. For example, looking at FIGS. 1A and 1B, a newspaper publisher can distribute a newspaper 102 within a container 100A. A publisher of fashion magazines 106 can distribute the fashion magazines within another
container 100C. Similarly, for example, a wholesale banking environment may use yet a further container, an electronic trading system may use a still further container, and so on.
The InterTrust DigiBox container model allows and facilitates these and other different container uses. It facilitates detailed container customization for different uses, classes of use and/or users in order to meet different needs and business
models. This customization ability is very important, particularly when used in conjunction with a general purpose, distributed rights management environment such as described in Ginter, et al. Such an environment calls for a practical optimization of
customizability, including customizability and transparency for container models. This customization flexibility has a number of advantages, such as allowing optimization (e.g., maximum efficiency, minimum overhead) of the detailed container design for
each particular application or circumstance so as to allow many different container designs for many different purposes (e.g., business models) to exist at the same time and be used by the rights control client (node) on a user electronic appliance such
as a computer or entertainment device.
While supporting a high degree of flexibility has great advantages, it can produce difficulties for the average user. For example, think of the process of creating a painting. A master painter creates a painting from a blank canvas. Because
the canvas was blank at the beginning, the painter was completely unconstrained. The painting could have been a landscape, a portrait, a seascape, or any other image--limited only by the painter's imagination. This flexibility allows a master painter
to create a masterpiece such as the "Mona Lisa." However, great skill is required to create a pleasing image starting from a blank canvas. As a result, an inexperienced painter cannot be expected to create a good painting if he or she begins with a
blank canvas.
Consider now an amateur painter just starting out. That person does not have the skill to transform a blank canvas to a pleasing image. Instead of spending years trying to acquire that skill, the amateur can go out and buy a "paint by numbers"
painting kit. Instead of using a blank canvas, the amateur painter begins with a preprinted canvas that defines the image to be painted. By following instructions ("all areas labeled "12" should be painted with dark red," "all areas labeled with "26"
should be painted with light blue"), the amateur can--with relatively little skill--paint a picture that is relatively pleasing to the eye. To do this, the amateur must rigidly adhere to the preprinted instructions on the canvas. Any deviations could
cause the final image to come out badly.
Ease of use problems in the computer field can be analogized to the "paint by numbers" situation. If it is important for untrained and/or inexperienced users to use particular software, the system designers can predefine certain constructs and
design them into the system. This technique allows inexperienced users to make use of potentially very complicated designs without having to fully understand them--but this normally strictly defines, that is severely limits, the functionality and
flexibility available by use of the program. As a result, creative solutions to problems are constrained in order to provide practical value. In addition, even the experienced user can find great advantage in using previously implemented designs.
Because a user can program a complex program, for example, does not mean it is appropriate or efficient to create a program for a specific purpose, even if the previously implemented program is not ideal. If the creation of a new program "costs" more to
create, that is takes too much time or financial resources, the experienced user will normally use a previously implemented program, if available. Therefore, the greatest total amount of value to be realized, related to customization, is to be able to
customize with great ease and efficiency so that the cost of customization will not exceed the benefits.
Uniformity, flexibility, compatibility and interoperability are other considerations that come into play in the computer field, particularly in regards to systems supporting customization. In the painting situation, the human eye can appreciate
uniqueness--and the "one of a kind" nature of a masterpiece such as the Mona Lisa is a big part of what makes a painting so valuable. In contrast, it is often desirable to make uniform at least the overall layout and format of things in the computer
field. It is much more efficient for a computer to know beforehand how to treat and use objects. If the computer doesn't know beforehand how to read or handle an input object, for example, then the computer and the object are said to be "incompatible",
i.e., they cannot work together. Computers are said to be "interoperable" if they can work together. Incompatibility and interoperability problems can prevent one computer from talking to another computer, and can prevent you from using computer data
created by someone else.
For example, in the non-computer world, a Frenchman who knows only a little English as a second language, might find it far more meaningful and efficient to describe a complex problem in his native tongue, French. But if he is speaking to a
second person, an Englishman, and the Englishman does not understand French, the two are not interoperable in French, and the Frenchman must resort to the far less efficient option of speaking in English to the Englishman. Of course, this is far better
than if he was trying to speak to a German who understood neither English nor French. Then the two would be not be "interoperable" in regards to discussing the problem. Similarly, because rights management containers may potentially be exchanged and
used for a large number of different purposes by a large number of different users, groups, and organizations, it is very important to provide compatibility and interoperability if these different parties, each participating in one or more different
rights management models, are to interoperate efficiently. For example, if a rights management container is used to distribute a newsletter and is optimized for this purpose, each reader of the newsletter must have a computer system or software that
"knows" how to read the container and the newsletter it contains. Since commerce, such as distributing newsletters, needs to be as efficient and cost-effective as is feasible, it is important to optimize, that is customize, rights management containers
to optimally reflect the requirements of their models and not to have unnecessary features for each respective application or class of application, since unnecessary features will require unnecessary computing overhead and/or storage space.
Different newsletter publishers may use different container formats customized to their own particular newsletters and/or content types and/or formats. A newsletter reader interested in many different newsletters may need to be able to read a
large number of different formats. It normally will not efficient (or, due to security issues, may not be appropriate) simply to analyze the different containers upon delivery and "try to figure out" or otherwise discern the particular format in use.
Published standards may help achieve a level of interoperability and standards for given types of applications, but it generally takes a long time for any particular standard to achieve industry-wide acceptance and standards will need to vary
widely between categories of applications. Moreover, data structure and other standards are often designed to the lowest common denominator--that is, they will carry fields and requirements not needed by some, and miss others features optimal in certain
cases. There will always be applications that cannot be optimized for efficiency and/or operation if forced to use a specific standard.
Trade-offs between flexibility, ease of use and incompatibility and interoperability can be further complicated when security considerations come into play. To be effective in many electronic commerce applications, electronic container designs
should be tamper-resistant and secure. One must assume that any tools widely used to create and/or use containers will fall into the hands of those trying to break or crack open the containers or otherwise use digital information without authorization.
Therefore, the container creation and usage tools must themselves be secure in the sense that they must protect certain details about the container design. This additional security requirement can make it even more difficult to make containers easy to
use and to provide interoperability.
The above-referenced Ginter et al. patent specification describes, by way of non-exhaustive example, "templates" that can act as a set (or collection of sets) of control instructions and/or data for object control software. See, for example, the
"Object Creation and Initial Control Structures," "Templates and Classes," and "object definition file," "information" method and "content" methods discussions in the Ginter et al. specification. The described templates are, in at least some examples,
capable of creating (and/or modifying) objects in a process that interacts with user instructions and provided content to create an object. Ginter et al. discloses that templates may be represented, for example, as text files defining specific
structures and/or component assemblies, and that
such templates--with their structures and/or component assemblies--may serve as object authoring and/or object control applications. Ginter et al. says that templates can help to focus the flexible and configurable capabilities inherent within
the context of specific industries and/or businesses and/or applications by providing a framework of operation and/or structure to allow existing industries and/or applications and/or businesses to manipulate familiar concepts related to content types,
distribution approaches, pricing mechanisms, user interactions with content and/or related administrative activities, budgets, and the like. This is useful in the pursuit of optimized business models and value chains providing the right balance between
efficiency, transparency, productivity, etc.
The present invention extends this technology by providing, among other features, a machine readable descriptive data structure for use in association with a rights management related (or other) data structure such as a secure container. In one
example, the machine readable descriptive data structure may comprise a shorthand abstract representation of the format of the data within a rights management related data structure. This abstract data representation can be used to describe a single
rights management data structure, or it may be generic to a family of data structures all following the format and/or other characteristics the abstract representation defines. The abstract representation may be used to create rights management data
structures, allow others (including "other" rights management nodes automatically) to read and understand such data structures, and to manipulate some or all of the data structures.
The descriptive data structure can be used as a "template" to help create, and describe to other nodes, rights management data structures including being used to help understand and manipulate such rights management data structures.
In one particularly advantageous arrangement, the machine readable descriptive data structure may be associated with one or a family of corresponding rights management data structures - and may thus be independent of any specific particular
rights management data structure usage. For example, a copy of the descriptive data structure may be kept with such data structures. Alternatively, some or all of the descriptive data structure may be obtained from somewhere else (e.g., a clearinghouse
or repository) and independently delivered on as-needed basis.
In accordance with one example, the machine readable descriptive data structure provides a description that reflects and/or defines corresponding structure(s) within the rights management data structure. For example, the descriptive data
structure may provide a recursive, hierarchical list that reflects and/or defines a corresponding recursive, hierarchical structure within the rights management data structure. In other examples, the description(s) provided by the descriptive data
structure may correspond to complex, multidimensional data structures having 2, 3 or n dimensions. The descriptive data structure may directly and/or indirectly specify where, in an associated rights management data structure, corresponding defined data
types may be found. The descriptive data structure may further provide metadata that describes one or more attributes of the corresponding rights management data and/or the processes used to create and/or use it. In one example, the entire descriptive
data structure might be viewed as comprising such metadata.
The machine readable descriptive data structure may or may not be, in part or in whole, protected, depending on the particular application. Some machine readable descriptive data structures may be encrypted in whole or in part, while others
might be maintained in "clear" form so that they are easily accessible. Some machine readable description data structures, whether encrypted or not, may be in part or wholly protected for integrity using a cryptographic hash algorithm in combination
with a secrecy algorithm to form a cryptographic seal, and/or through use of other protection techniques (including hardware, e.g., secure semiconductor and/or hardware packaging protection means). The machine readable descriptive data structures may
themselves be packaged within rights management data structures, and rules (e.g., permissions records) controlling their access and use may be associated with them.
In accordance with one aspect of how to advantageously use descriptive data structures in accordance with a preferred embodiment of this invention, a machine readable descriptive data structure may be created by a provider to describe the layout
of the provider's particular rights management data structure(s) such as secure containers. These descriptive data structure ("DDS") templates may be used to create containers. A choice among two or more possible DDSs may be based upon one or more
classes and/or one or more classes may be based on parameter data. The DDS may be loaded and used as the layout rules for secure containers being created. The provider can keep the DDS private, or publish it so that other providers may create
compatible, interoperable containers based on the same DDS.
Descriptive data structures can also be used by a container viewer, browser, reader, or any other end user application designed to work with containers. Truly generic viewers or other applications can be written that can process a container in
any format at least in part by making use of descriptive data structures. Thus, a descriptive data structure can be used to at least temporarily convert and/or customize a generic viewer (or other application) into a specialized viewer (or other
application) optimized around one or more classes of containers. Additionally, specialized readers may be provided to efficiently process descriptive data structures to locate key media elements (e.g., cover page, table of contents, advertiser's index,
glossary, articles, unprotected preview, price, and/or rights information regarding viewing, printing, saving electronically, redistributing, related budgets and/or other parameter information, etc.).
Such specialized readers can then seamlessly, transparently, and automatically process to present the user with an easy-to-use interface (for example, an icon display for each of the key media elements) optimized for the specific application,
container, and/or user. Different and/or differently presented, such elements may be displayed or otherwise employed based, for example, on the identity of the user and/or user node, including, for example, taking into account one or more class
attributes which can influence such automated processing.
Two or more DDSs may be associated with a container and/or container contents, as well as, for example, one or more user and/or node classes. A choice among two or more possible DDSs for a given container and/or class of containers and/or
container contents may therefore be based upon one or more classes and/or one or more classes based on parameter data. Overall, this ability to easily characterize, and/or reuse stored, optimized, custom container models and subsequent transparency of
translation from such customized containers (e.g. specific DDSs) to general purpose rights management use is particularly useful. For example, where such customized DDSs can be used as a basis for the creation of customized, optimized display of
container content and/or control information to substantially improve the ease of use, efficiency, transparency, and optimization of a distributed, generalized rights management environment. In such an environment, for example, user nodes can interact
with different DDSs to automatically adjust to the requirements of the commercial or other rights models associated with such DDSs.
Some providers may spend considerable time designing sophisticated container descriptive data structures that describe the layout of their associated containers. With this type of investment in structure and format, the descriptive data
structure will often have significant value in their reuse for the same or similar applications. Entities can use descriptive data structures in-house to ensure consistent and highly efficient creation of containers. Third party providers (i.e., a
provider other than the one responsible for descriptive data structure creation) can use these descriptive data structures when they wish to create containers compatible with other entities. One example is where the publisher of a widely circulated
newspaper develops a descriptive data structure for reading its newspaper. Other, smaller newspapers may want to leverage any viewers or other tools put in place for use with the widely circulated newspaper by adopting the same container format.
Descriptive data structures can be copyrighted and/or otherwise protectable by both law and by the rights management system itself For example, they may also be protected by their own containers and associated controls to ensure that descriptive data
structure creators, and/or distributors and/or other users of such DDSs, receive their fair, rights system managed, return on their descriptive data structure creation and/or use related efforts.
In addition to the foregoing, the following is a list of features and advantages provided in accordance with aspects of this invention:
Integrity Constraints: The descriptive data structure allows the provider to protect the integrity of his or her content, by enabling the specification of integrity constraints. Integrity constraints provide a way to state integrity related
rules about the content.
Application Generation: The descriptive data structure can be used to generate one or more portions of software programs that manipulate rights management structures.
For example, a descriptive data structure could serve as `instructions` that drive an automated packaging application for digital content and/or an automated reader of digital content such as display priorities and organization (e.g., order
and/or layout).
Dynamic user interfaces for creation applications: Applications can read a descriptive data structure to generate an interface optimized for data creation, editing, and/or composition for a specific model, including models involving, for example,
composing complex content from textual, audio, video, and interactive (e.g., querying) elements. The data may take the form of a container, database and/or any other digital information organization as any simple or compound and complex file format.
Applications can also read a descriptive data structure to learn how to best display an interface for collection and/or creation of content.
Dynamic user interfaces for display applications: Applications can read a descriptive data structure to and generate an interface appropriate for data display. This data may be a container, database or any other compound complex file format.
Applications can also read a descriptive data structure to learn how to best display an interface for the presentation of content. Applications can further read a descriptive data structure to learn how to manage display functions related to
interacting--for content creation and/or packaging and/or user display purposes including optimizing any of such interactions--with other one or more other applications, smart agents, computing environments, identity (including any class identities) of
user and/or user nodes, etc. For example, a user interface might be differently optimized for interacting with: a member of the U.S. Air Force versus a faculty member in social sciences at a university; or a member of a Kiwanis Club versus a member of a
Protestant church club, a citizen of the United States versus a citizen of Saudia Arabia, including an appropriate display of expected class membership symbols and related, appropriate organization or suppression of displayed information.
Ability to automatically identify and locate data fields: Full text search, agents, web spiders, and the like, benefit and are able to interact with information contained within one or more areas of a DDS when areas within a data file are known
to contain potentially interesting information and such information is presented in a predefined format.
Ability to extract needed or desired data without first-hand knowledge of data format: Full text search, agents, web spiders, and the like, benefit and are able to interact with information contained within one or more areas of a DDS when large
data files of arbitrary complexity and of unknown origin can be processed without special knowledge.
Efficient, machine/human readable data abstract: The descriptive data structures can be optimally small, convenient, and cost-effective to process, transmit, and/or store.
Reusable, salable--independent of actual data: Descriptive data structures may be arbitrarily complex and therefore potentially time consuming to construct and requiring certain expertise. This gives the descriptive data structure resale value.
On-the-fly definition and redefinition of content layout: Working with a layout tool allows quick iterations (including editing and modifications) of a design (layout) which can be more convenient and cost-effective than creating such a layout,
which also may be quite difficult or beyond the expertise of many users.
Descriptive data structure attributes allow for meta-characteristics not found in actual data: Because the same descriptive data structure is processed by both the creation and post-creation processes, meta-information can be placed into the
descriptive data structure that would otherwise be unavailable in the packaged content. One example of this whether display of certain fields is "Required" or "Hidden".
Enables design automation via descriptive data structure "wizards": Descriptive data structures themselves enable further automation in the way of "wizards". There can, for example, be descriptive data structures that help to define other
descriptive data structures. Descriptive data structures defining other descriptive data structures might represent the incomplete descriptive data structure for a book or magazine, for example. The "wizard" can comprise a series of dialog boxes
displayed to the user to fill in the missing information to make it a completed descriptive data structure.
Applications outside of a particular rights management architecture: For example, polymorphous applications may use descriptive data structures to determine certain data visualizations attributes and/or requirements, such as what look and feel
should be displayed to the user. For example, if a descriptive data structure contains a word processing document reference, the polymorphous application might create an interface appropriate for display and editing of a document. If the descriptive
data structure contains references to many executable programs, the polymorphous application might ask the user where the files should be saved.
Enables umbrella applications to process descriptive data structures and delegate unknown file types and processes: Umbrella (or polymorphous) applications can, for example, act substantially as an operation for a particular data file. This
umbrella application may extract and process those things in the data file that it cares about, while ignoring or delegating (to, for example, user and/or value chain partner (e.g., distributor) to control display of such items) those things it does not
understand.
Runtime interpretation: It is possible to interpret a descriptive data structure at run time, providing materially increased efficiencies and timeliness.
Runtime adaptability: Systems can adapt to dynamic data arriving in real time through use of descriptive data structures.
Automatic conversion capability: Descriptive data structures be used for converting automatically from one format to another.
Simplified system design: The use of descriptive data structures may greatly reduce the need for a secondary "wrapper" application programming interface (API) or other arrangement to securely "contain" the container creation process. Such a
"wrapper" API to control and otherwise restrict the container creation process might otherwise be needed to ensure that all created containers are compatible--thereby limiting flexibility and the ability to customize.
Object oriented template programming environment: The use of display related, interaction related, and rights related concept objects which may be selected through high-level user interface choices and prioritizations and specification of related
parameter data, this enabling very easy creation of certain categories of templates--such as construction and display hint information.
The use of a template language and interpreter involving supporting programming through | | |
