US20080016103A1 - Techniques for Defining, Using and Manipulating Rights Management Data Structures - Google Patents

Techniques for Defining, Using and Manipulating Rights Management Data Structures Download PDF

Info

Publication number
US20080016103A1
US20080016103A1 US11/779,835 US77983507A US2008016103A1 US 20080016103 A1 US20080016103 A1 US 20080016103A1 US 77983507 A US77983507 A US 77983507A US 2008016103 A1 US2008016103 A1 US 2008016103A1
Authority
US
United States
Prior art keywords
data structure
rights management
descriptive data
rule
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US11/779,835
Inventor
Edwin Hall
Victor Shear
Luke Tomasello
David Van Wie
Robert Weber
Kim Worsencroft
Xuejun Xu
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intertrust Technologies Corp
Original Assignee
Intertrust Technologies Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US08/805,804 external-priority patent/US5920861A/en
Application filed by Intertrust Technologies Corp filed Critical Intertrust Technologies Corp
Priority to US11/779,835 priority Critical patent/US20080016103A1/en
Publication of US20080016103A1 publication Critical patent/US20080016103A1/en
Abandoned legal-status Critical Current

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/10Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102Entity profiles
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]
    • G06F21/107License processing; Key processing
    • G06F21/1073Conversion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/101Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying security measures for digital rights management
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99941Database schema or data structure
    • Y10S707/99943Generating database or data structure, e.g. via user interface

Definitions

  • 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.
  • DigiBoxTM 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.
  • 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 DigiBoxTM 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 DigiBoxTM 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.
  • content rightsholders including any parties who have system authorized interests related to such content, such as content republishers or even governmental authorities
  • 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.
  • 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).
  • 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 100 A. A publisher of fashion magazines 106 can distribute the fashion magazines within another container 100 C. 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.
  • optimization e.g., maximum efficiency, minimum overhead
  • 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.
  • Uniformity, flexibility, compatibility and interoperability are other considerations that come into play in the computer field, particularly in regards to systems supporting customization.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the machine readable descriptive data structure provides a description that reflects and/or defines corresponding structure(s) within the rights management data structure.
  • 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.
  • 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
  • a machine readable descriptive data structure may be created by a provider to describe the layout of the providers 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.).
  • 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
  • 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.
  • an easy-to-use interface for example, an icon display for each of the key media elements
  • 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.
  • 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.
  • 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.
  • user nodes can interact with different DDSs to automatically adjust to the requirements of the commercial or other rights models associated with such DDSs.
  • 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.
  • FIGS. 1A and 1B show example content containers
  • FIGS. 2A and 2B show example content containers associated with example descriptive data structures
  • FIG. 3 shows an example descriptive data structures creation and usage process
  • FIG. 4 shows another example creation and usage process
  • FIG. 5 shows an example system architecture using descriptive data structures
  • FIG. 5A shows an example process performed by the FIG. 5 system
  • FIG. 6 shows an hierarchical descriptive data structure organization
  • FIG. 6A shows an example of how descriptive data structures can be used with atomic transaction data
  • FIG. 7 shows an example descriptive data structure format
  • FIG. 8 shows an example descriptive data structure creation graphical interface
  • FIG. 9 shows an example process for tracking descriptive data structure rights management related data
  • FIG. 10A shows an example use of descriptive data structures to provide interoperability between environments.
  • FIG. 10B provides more detail about how the FIG. 10A example descriptive data structure may be organized.
  • FIGS. 2A and 2B show the example containers 100 a , 100 c of FIGS. 1A, 1B associated with machine readable descriptive data structures 200 and 200 ′.
  • a descriptive data structure 200 is associated with content container 100 a .
  • This descriptive data structure 200 may be used to define the content (and certain other characteristics) of container 100 a .
  • descriptive data structure 200 defines a number of sections of newspaper style content 102 such as, for example, the headline (descriptor 202 a ), the issue date (descriptor 202 b ), the lead story (descriptor 202 c ), breaking news (descriptor 202 d ), image(s) (descriptor 202 e ), advertisement (descriptor 202 f ), and section (descriptor 202 g ).
  • the descriptive data structure definitions 202 in this example do not contain or specify the particular contents of corresponding portions of the newspaper 102 , but instead define more abstractly, a generic format that a newspaper style publication could use.
  • the FIG. 2A example descriptive data structure headline definition 202 a does not specify a particular headline (e.g., “Yankees Win the Pennant!”), but instead defines the location (for example, the logical or other offset address) within the container data structure 100 a (as well as certain other characteristics) in which such headline information may reside.
  • descriptive data structure 200 is generic to a class or family of newspaper style content publications, it can be reused. For example, each daily issue of a newspaper might be created using and/or associated with the same descriptive data structure 200 .
  • the descriptive data structure 200 allows easy creation, usage and manipulation of newspaper style content 102 .
  • a different descriptive data structure 2001 may be used to define another class of content publications 106 such as fashion magazines.
  • the descriptive data structure 200 ′ for this content class reflects a different format (and possibly other characteristics) as compared to the descriptive data structure 200 shown in FIG. 2A .
  • the example descriptive data structure 200 ′ may not define such formatting.
  • descriptive data structure 200 ′ for defining a class of fashion magazine content may define issue date (descriptor 204 a ), a magazine title (descriptor 204 b ), the name of a photographer (descriptor 204 c ) and associated artwork designation (descriptor 204 d ).
  • FIGS. 2A and 2B examples show descriptive data structures 200 , 200 ′ being delivered within content object containers 100 a , 100 c along with associated content 102 , 106 .
  • descriptive data structure 200 can be independently delivered in its own separate container along with associated rules controlling its access and/or use.
  • descriptive data structures 200 could be stored in a library and delivered on an as needed basis in secure or insecure form depending on particular requirements.
  • FIGS. 2A and 2B are printed publication content examples, the use of descriptive data structures 200 is not so limited. To the contrary, descriptive data structures 200 can be used to define the format and/or other characteristics associated with a wide variety of different types of digital information including for example:
  • FIG. 3 shows an example process for creating and using descriptive data structures 200 .
  • a layout tool 300 is used to create descriptive data structure 200 .
  • This layout tool 300 may be, for example, a software-controlled process interacting with a human being via a graphical user interface.
  • the resulting descriptive data structure 200 (which may be stored on a mass storage device or other memory) can then be used to facilitate any number of other processes to create or interpret stored data.
  • the descriptive data structure may be used in a creation process 302 .
  • the creation process 302 may read the descriptive data structure and, in response, create an output file 400 with a predefined format such as, for example, a container 100 corresponding to a format described by the descriptive data structure 200 .
  • a viewing process 304 may use the descriptive data structure 200 to locate important items in the output file 400 for display.
  • a browsing process 306 may use the descriptive data structure 200 to locate items within the stored output file 400 such as, for example, key words or other searchable text.
  • Descriptive data structure 200 may supply integrity constraints or rules that protect the integrity of corresponding content during use of and/or access to the content.
  • FIG. 4 shows a more detailed example descriptive data structure creation and usage process.
  • the layout tool 300 may accept user input 310 provided via a graphical user interface 312 .
  • the output of the layout tool 300 may be a descriptive data structure 200 in the form of, for example, a text file.
  • a secure packaging process 302 a may accept container specific data as an input, and it may also accept the descriptive data structure 200 as a read only input.
  • the packager 302 a could be based on a graphical user interface and/or it could be automated.
  • the packager 302 a packages the container specific data 314 into a secure container 100 . It may also package descriptive data structure 200 into the same container 100 if desired.
  • a viewer 304 may view data 314 with the assistance of the descriptive data structure 200 and in accordance with rules 316 packaged within the container applying to the data 314 and/or the descriptive data structure 200 .
  • FIG. 5 shows an example secure system architecture suitable for use with descriptive data structure 200 .
  • an electronic appliance 500 of the type described in the above-referenced Ginter et al. patent specification may be provided within a tamper resistant barrier 502 .
  • Electronic appliance 500 may include an application program interface (API) 504 .
  • One or more applications 506 may communicate with electronic appliance 500 via API 504 .
  • the application 506 may execute on the secure electronic appliance 500 .
  • Each application 506 may include a descriptive data structure interpreter 508 .
  • electronic appliance 500 may access secure container 100 and—in accordance with rules 316 —access the descriptive data structure 200 and content 102 it contains and provide it to application 506 .
  • the interpreter 508 within application 506 may, in turn, read and use the descriptive data structure 200 .
  • application 506 may be polymorphic in the sense that it can take on personality or behavior as defined at least in part by descriptive data structure 200 .
  • FIG. 5A shows an example detailed process performed by the FIG. 5 example secure system architecture.
  • application 506 asks appliance 500 to retrieve the descriptive data structure 200 from container 100 (block 550 ).
  • Electronic appliance 500 reads the descriptive data structure 200 and, subject to the conditions specified by associated rules 316 , provides the descriptive data structure 200 to the application 506 (block 552 ).
  • Application 506 then 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 says (block 556 ).
  • the application 506 extracts or obtains the descriptive data structure information it needs or wants from interpreter 508 (block 558 ). For example, suppose the application 506 wants to display the “headline” information within newspaper style content shown in FIG. 2A . Application 506 may ask interpreter 508 to provide it with information that will help it to locate, read, format and/or display this “headline” information.
  • interpreter 508 may provide application 506 with an element identification (e.g., a hexadecimal value or other identifier) that corresponds to the headline information within the newspaper style content (block 558 ).
  • Application 506 may then ask electronic appliance 500 to provide it with the Headline (or other) content information 102 within container 100 by providing appropriate content information to electronic appliance 500 via API 504 (block 560 ).
  • application 506 may pass the electronic appliance 500 the element ID that interpreter 508 provided to the application.
  • interpreter 508 can tell application 506 enough information so that the application knows how to request the information it wants from the electronic appliance 500 .
  • the electronic appliance may then access information 102 within container 100 , and deliver (in accordance with the rules 316 within the container) the requested information to the application 506 (block 562 ).
  • the application 506 may then use the information electronic appliance 500 provides to it, based at least in part on what interpreter 508 has told it about the content information (block 564 ).
  • the descriptive data structure 200 may provide characteristics about the way application 506 should handle the information 102 . Descriptive data structure 200 can, for example, tell application 506 to always display a certain field (e.g., the author or copyright field) and to never display other information (e.g., information that should be hidden from most users).
  • DDS 200 can also provide complete presentation or “visualization” information so that an information provider can, for example, control the look and feel of the information when it is displayed or otherwise rendered.
  • Descriptive data structure 200 may provide encodings of other characteristics in the form of metadata that can also be used by application 506 during a process of creating, using or manipulating container 100 .
  • the DDS 200 can be used to generate a software program to manipulate rights management structures. For example, a DDS 200 could serve as the ‘instructions’ that drive an automated packaging application for digital content or an automated reader of digital content.
  • FIG. 6 shows one example of how a descriptive data structure 200 may describe and define an arbitrarily complex, information structure such as, for example, an hierarchical container 100 .
  • container 100 includes properties 600 ( 1 ), 600 ( 2 ).
  • Property 600 ( 1 ) may include n attributes 602 ( 1 ), 602 ( 2 ) . . . 602 ( n ).
  • Property 600 ( 2 ) may include any number of attributes 604 ( 1 ), 604 ( 2 ), and it may also include an additional property 606 .
  • Property 606 may, in turn, include its own attributes 608 ( 1 ), 608 ( 2 ) . . . .
  • Associated descriptive data structure 200 may be organized as a tree structure list 250 providing a recursive structure to reflect the recursive structure of the contents of container 100 .
  • list 250 may include “branches” in the form of “property” descriptors 252 ( 1 ), 252 ( 2 ) corresponding to properties 600 ( 1 ), 600 ( 2 ).
  • Each property descriptor 252 may, in turn, include a list 254 of attributes and may include additional property descriptors 256 in the same recursive, hierarchical arrangement as is reflective of the example content container structure.
  • DDS 200 may be used to describe arbitrarily complex, hierarchical or non-hierarchical data structures of any dimension (1 to n).
  • FIG. 6A shows that descriptive data structure 200 can be used in conjunction with any kind of information such as, for example, events or methods defining an “atomic transaction” such as a real estate transaction.
  • a container 100 includes one or more descriptive data structures 200 and associated control set(s) 316 relating to a sequence of “events” 700 that define a real estate transaction.
  • the DDS 200 may, for example, include a number of different entries 200 A- 200 N pertaining to each different “event” within the transaction (e.g., “offer”, “acceptance”, “purchase/sales”, “inspection”, “mortgage”, etc.). These entries 200 A-N may, for example, define where in container 100 the event can be found.
  • the entries 200 A- 200 N may also include metadata that provides additional characteristics corresponding to the event (for example, how certain information related to the event should be displayed).
  • FIG. 7 shows an example of how descriptive data structure 200 may be formatted.
  • descriptive data structure 200 may comprise a list such as a linked list.
  • Each list entry 260 ( 1 ), 260 ( 2 ), . . . may include a number of data fields including, for example:
  • the object name field 262 may include a constant that may corresponds to or describes a type of information.
  • object name field 262 may act as a “handle” to the content or data; it may be an indirect reference to the content or data; and/or it may be used to look up the content or data.
  • the DDS 200 may include or reference any type of data or metadata.
  • the DDS 200 uses the object name field 262 to points or refers to metadata.
  • This metadata can define certain characteristics associated with the object name. For example, such metadata may impose integrity or other constraints during the creation and/or usage process (e.g., “when you create an object, you must provide this information”, or “when you display the object, you must display this information”).
  • the metadata 264 may also further describe or otherwise qualify the associated object name.
  • the DDS 200 uses object name 262 to refer to metadata stored elsewhere—such as in a container 100 .
  • This referencing technique provides several advantages. For example, one situation where it may be useful to store the metadata in a secure container 100 separately from DDS 200 is in situations where it is desirable to make the DDS readily accessible to an outside application but to protect the associated metadata. For example, consider the case of handling web spider queries. A web spider may query the DDS 200 for a particular object name 262 . If the object name is found, then the web spider may request the corresponding metadata. The web spider may have ready access to the metadata, but may only be able to access the associated metadata from the container 100 under appropriate conditions as controlled by a corresponding secure electronic appliance 500 based on associated rules 316 .
  • storing metadata separately from the DDS 200 may allow the same DDS to be used with different metadata in different contexts.
  • a DDS 200 contains an Object Name, for example KEYWORDS.
  • the DDS Object Name KEYWORDS refers to container 100 A's KEYWORDS metadata.
  • the DDS Object Name KEYWORDS refers to container 100 B's KEYWORDS data.
  • FIG. 7 shows an example DDS 200 that includes metadata field 264 and also refers to metadata within a container 100 using the object name 262 . Either or both techniques may be used.
  • the DDS 200 thus allows value chain participants to protect the integrity of content, by enabling the specification of integrity constraints.
  • DDS 200 integrity constraints provide a way to state rules about the content. For example, DDS 200 can specify that an article of a newspaper cannot be viewed without its headline being viewed. The corresponding integrity constraint can indicate the rule ‘if there is an article, there must also be a headline”. Another example is a photograph that is part of a magazine and the credit that goes with it. The integrity constraint rule provided by DDS 200 might be ‘do not present this photograph without its associated credit’.
  • DDS integrity constraints give value chain participants a tool for protecting the use of the DDS 200 , ensuring that content represented by a particular DDS contains all the essential components—that it is representative of the DDS. This gives providers a way to set up conventions and enforce standards of use. There are many possible integrity constraints. The following are a few examples:
  • FIG. 8 shows an example descriptive data structure creation graphical user interface 312 .
  • the graphical user interface 312 may prompt the user for the object name.
  • the graphical user interface 312 may provide options for specifying the associated metadata 264 .
  • the options shown in FIG. 8 may, for example, include:)
  • Metadata are non-limiting examples. Other metadata characteristics and attributes may be used.
  • FIG. 9 shows one example arrangement for using the infrastructure described in co-pending related U.S. patent application Ser. No. 08/699,712 (referenced above) for descriptive data structures 200 .
  • the arrangement shown in FIG. 9 may be useful in a number of different contexts.
  • a provider 600 of descriptive data structures 200 may want to know which descriptive data structures 200 are the best liked by his customers so he or she can improve the quality of his products.
  • a provider 600 may charge customers for using descriptive data structures 200 on a per use or other basis.
  • some descriptive data structures 200 or classes of DDS 200 may be restricted to use only by authorized users or classes of authorized users.
  • FIG. 9 shows a DDS provider 600 who delivers a DDS 200 and an associated control set 316 to a value chain participant 602 .
  • Controls 316 may provide rules and associated consequences for controlling or otherwise affecting the use or other aspects of what value chain participant 602 can do with DDS 200 .
  • the controls 316 and DDS 200 may be packaged within a container 100 .
  • Value chain participant 602 may get the container 100 containing DDS 200 directly from DDS provider 600 ; alternatively, the provider can provide it a rights and permissions clearinghouse 604 and participant 602 and get it from the clearinghouse (or elsewhere) (see container 100 B).
  • Value chain participant 602 can use DDS 200 to author content 102 .
  • Participant 602 can package content 102 with associated controls 316 A in a container 100 A.
  • Participant 600 may, if he desires, include DDS 200 and associated controls 316 a , 316 b with content 102 in the same container—or depend on the provider 600 and/or rights and permissions clearinghouse 604 to independently deliver the DDS and its controls to end users 606 in another container 100 c for example.
  • End users 606 ( 1 ), . . . , 606 ( n ) use DDS 200 (in accordance with controls 316 ) in conjunction with content 102 (for example, to read, browse or otherwise access the container content).
  • Controls 316 , 316 A may require user appliances to provide usage data 610 to a usage clearinghouse 612 .
  • the usage clearinghouse 612 can provide usage data 610 A related to access and/or usage of DDS 200 to DDS provider 600 , and may independently provide usage data 610 B related to access and/or usage of content 102 to value chain participant 602 .
  • Descriptive Data Structures can be Used to Achieve a Degree of Interoperability Between Rights Management Environments
  • Descriptive data structures 200 provided in accordance with the present invention can provide a degree of interoperability between source and target rights management environments, and/or to provide a bridge to achieve at least some degree of interoperatibility between a rights management environment and the outside world.
  • Descriptive data structures 200 can provide at least a partial bridge to achieve a degree of compatibility and interoperability.
  • a provider that defines an object within a source rights management environment may create a descriptive data structure for use by processes within one or more target rights management environments.
  • an object creator or other provider can specify, within a descriptive data structure 200 , certain rules, integrity constraints and/or other characteristics that can or should be applied to the object after it has been imported into a target rights management environment.
  • the target rights management environment can choose to selectively enforce such rules, constraints and/or other characteristics depending on the degree to which it can trust the source environment. For example, objects imported from an EDI system employing X.12 security may be more trustworthy than objects presented from environments with lesser (or no) security.
  • a provider that creates an object outside of any rights management environment can create a descriptive data structure 200 for use if and when the object is imported into one or more rights management environments.
  • the target rights management environment(s) can use such descriptive data structure(s) to help efficiently understand and handle the object.
  • a descriptive data structure created within a rights management environment can be exported to one or more applications outside of the rights management environment and used to assist the application(s) in interpreting exported content or other information.
  • FIG. 10A shows an example of how descriptive data structures 200 may be used to provide interoperability.
  • a DDS creation tool 800 creates a DDS 200 that includes one or more target data blocks 801 .
  • the DDS creation tool 800 may be based on, and/or incorporate some or all of the capabilities of layout tool 300 and provide interoperability capabilities in addition to features associated with layout tool 300 .
  • DDS creation tool 800 may not incorporate any of the capabilities of layout tool 300 , and may create DDS 200 solely for interoperability purposes.
  • DDS creation tool 800 may, for example, be an application program with a graphical user interface, a background process that only displays a user interface when being configured by a user, a portion of an operating system, a portion of a computer's firmware, a server process that may act independently or as part or all of a “gateway” between one system and another (e.g., a public network and a private network, two or more private networks, a local area network and a wide area network, etc.), or any other desirable implementation or integration.
  • a gateway between one system and another (e.g., a public network and a private network, two or more private networks, a local area network and a wide area network, etc.), or any other desirable implementation or integration.
  • Target data block 801 may provide information used to provide interoperability with a particular target environment 850 .
  • a single DDS 200 can, in one example, provide interoperability with N different target environments 850 by including N target data blocks 801 ( 1 ), . . . 801 (N) each corresponding to a different target environment 850 ( 1 ), . . . 850 (N).
  • each target data block 801 includes rule (control) information.
  • Rule information may, for example, relate to operations (events) and/or consequences of application program functions 856 within the associated target environment 850 such as specifying:
  • the target data block 801 may also include additional information if desired that gives directions to a DOS parser 852 and/or a translator 854 within a corresponding target environment 850 .
  • FIG. 10B shows one detailed example of how target information may be organized within DDS 200 .
  • DDS creation tool 800 creates a DDS header 805 that references one or more target record headers 807 .
  • DDS header 805 may, for example, include a “number of targets” field 809 indicating the number of target data blocks 801 within the DDS 200 , a “offset to first target data portion” field 811 that provides the location of the first target data block 801 ( 1 ) within the DDS 200 , a source message field 812 A that identifies the source environment, and an optional creator seal 812 B that may be used to verify the integrity and authenticity of the DDS 200 .
  • Source message field 812 A may include a source ID that may be used to help verify the source environment of DDS 200 , and an optional source seal (that may or may not be present in the source message).
  • Each target data block 801 within DDS 200 may begin with a target record header 807 including a “target ID” field 813 , a “length” field 815 , a “offset to next target data portion” field 817 , an optional creator seal 819 , and an optional source message 821 .
  • the “target ID” field 813 may specify a unique identification number or value corresponding to the associated target data block 801 and/or identifying the intended target environment(s), the “length” field 815 may specify the length of the target data block 801 , and the “offset” field 817 may specify the location (relative or absolute) of the next target data block 801 within the DDS 200 (and may take on a null value for the last target data block).
  • the optional creator seals 812 B, 819 may be cryptographic seals that help to ensure that the DDS 200 and target records 801 , respectively, have not be altered since they were created, and also the identity of the DDS 200 's and/or source creator.
  • the optional source messages 812 C and 821 may be information that helps to ensure that a target environment knows which source environment created DDS 200 .
  • DDS creation tool 800 may, upon creating the DDS 200 , cryptographically seal it and each target data block 801 for integrity using appropriate cryptographic processes, for example by first running a cryptographic hash function (e.g., SHA, MD5, etch) on the data and then encrypting the resulting hash value using a private key of the DDS creator associated with an asymmetric cryptosystem (e.g., RSA, El Gamal, etc.).
  • a cryptographic hash function e.g., SHA, MD5, etch
  • a private key of the DDS creator associated with an asymmetric cryptosystem (e.g., RSA, El Gamal, etc.).
  • the DDS creator preferably should ensure that the public key associated with the encrypting private key is certified (e.g., encrypted with a private key of a certifying authority) and available for use by target environments to validate the seal (e.g., by including a certificate in DDS 200 , publishing the certificate on a public network, etc.)
  • certified e.g., encrypted with a private key of a certifying authority
  • target environments e.g., by including a certificate in DDS 200 , publishing the certificate on a public network, etc.
  • source messages 812 C, 821 should preferably represent information provided by the source environment that may help a target environment identify the source environment, and further may also help to ensure that the DDS 200 was actually created by the source environment (and therefore may, for example, be trusted to the extent that the source environment is trusted).
  • a source environment may have a protected processing environment (PPE) of the form described in the above referenced Ginter, et al. patent application.
  • PPEs may have cryptographic keys (e.g., a private key of a public key/private key pair) available that may be used to encrypt a cryptographic hash taken of the DDS header 805 or target block header 807 , as appropriate.
  • a target environment would need to acquire a corresponding cryptographic key (e.g., a public key of a public key/private key pair) using trusted techniques (e.g., delivery in a certificate signed by a trusted certifying authority) in order to evaluate such a source message.
  • DDS creation tool 800 may have been equipped with cryptographic keys when it was manufactured, and may use these cryptographic keys instead of keys from a PPE, although generally this technique would be more susceptible to tampering by an experienced computer hacker and might therefore be somewhat less trusted by target environments.
  • the source message may contain a unique identifier that corresponds to the source environment.
  • the DDS creation tool 800 may then package the resulting DDS 200 into a secure container 100 along with an associated object 830 .
  • DDS creation tool 800 may embed DDS 200 within, or otherwise associate the DDS with, an object 830 ′ that provides a method for releasing the DDS to the target environment parser 852 .
  • the DDS 200 and its associated object 830 may then be delivered to one or more target environments 850 for processing.
  • Target environment parser 852 (and/or translator 854 ) may, for example, be part of an application program, part of an operating system, or part of a utility program used by, or in conjunction with, an application program and/or an operating system.
  • the target environment parser 852 receives the DDS 200 and parses it to locate the target data block 801 ( k ) corresponding to the target environment 850 ( k ). Parser 852 may then determine, from the corresponding target data block 801 , the rules the target data block contains. Parser 852 preferably understands enough about the structure of DDS 200 to find (e.g., using the header information shown in FIG. 10B ) the appropriate target data block 801 corresponding to it, and also to understand the rules within the target data block.
  • the target environment parser 852 doesn't need to understand any additional rules 316 that may be packaged within container 100 or otherwise delivered with object 830 , but it may use any such additional rules if desired (e.g., when it finds no target data block 801 within DDS 200 for the particular target environment 850 (for example, if it is capable of understanding some other target data block 801 whose rules are based on a published specification and/or standard)).
  • the target environment parser 852 may obtain applicable target rules from target data block 801 and provide these rules to application program functions 856 .
  • Application program functions 856 may define any operation pertaining to object 830 such as for example:
  • the target rules provided by parser 852 may be used, for example, to permit, require and/or prevent certain operations; to define the extent to which certain operations can be performed (e.g., limit number of copies, define extent of cut, the rules that should be applied to cut information in subsequent use, etc.); and/or to define the consequences of performing a particular operation (e.g., charge the user for printing or otherwise using and/or accessing all or part of object 830 , maintain records of the time and/or number of such operations performed, etc.).
  • Parser 852 may also, or alternatively, provide some or all of the rules it obtains from target data block 801 to other arrangements for applying the rules such as, for example, the “other rights management functions” block 858 .
  • Block 858 may provide any kind of rights management functions.
  • Translator 854 may be used if needed to allow the application program functions 856 and/or the “other rights management” block 858 to understand the rules. As one example, translator 854 may be used to further elaborate, parameterize and/or secure the rule information obtained from target data block 801 so they are more or fully compatible with the “other rights management functions” block 858 .

Abstract

A descriptive data structure provides an abstract representation of a rights management data structure such as a secure container. The abstract representation may describe, for example, the layout of the rights management data structure. It can also provide metadata describing or defining other characteristics of rights management data structure use and/or processing. For example, the descriptive data structure can provide integrity constraints that provide a way to state rules about associated information. The abstract representation can be used to create rights management data structures that are interoperable and compatible with one another. This arrangement preserves flexibility and ease of use without compromising security.

Description

    CROSS-REFERENCE TO RELATED APPLICATIONS
  • This is a continuation of commonly assigned copending U.S. application Ser. No. 11/256,518, filed Oct. 20, 2005, which is a continuation of U.S. application Ser. No. 09/819,063, filed Sep. 28, 2000 (now U.S. Pat. No. 7,062,500), which is a continuation of U.S. application Ser. No. 09/300,778, filed Apr. 27, 1999 (now U.S. Pat. No. 6,138,119), which is a continuation of U.S. application Ser. No. 08/805,804, filed Feb. 25, 1997 (now U.S. Pat. No. 5,920,861), all of which are incorporated herein by reference. This application is related to commonly assigned U.S. application Ser. No. 08/388,107, filed Feb. 13, 1995 (now abandoned); and U.S. application Ser. No. 08/699,712, filed Aug. 12, 1996 (now abandoned), both of which are incorporated herein by reference into this application.
  • 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™” container developed by InterTrust Technologies Corp. of Sunnyvale Calif. The Ginter et al. patent specification referenced above describes many characteristics of this DigiBox™ 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™ 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™ 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 providers 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 Saudi 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 use of language elements and interpretation of such language by nodes described in Ginter, et al., where such language includes elements descriptive of display, rights, and program interaction elements, priorities and parameter data.
    BRIEF DESCRIPTION OF THE DRAWINGS
  • These and other features and advantages of presently preferred example embodiments in accordance with the invention may be better and more completely understood by referring to the following detailed description along with the drawings, of which:
  • FIGS. 1A and 1B show example content containers;
  • FIGS. 2A and 2B show example content containers associated with example descriptive data structures;
  • FIG. 3 shows an example descriptive data structures creation and usage process;
  • FIG. 4 shows another example creation and usage process;
  • FIG. 5 shows an example system architecture using descriptive data structures;
  • FIG. 5A shows an example process performed by the FIG. 5 system;
  • FIG. 6 shows an hierarchical descriptive data structure organization;
  • FIG. 6A shows an example of how descriptive data structures can be used with atomic transaction data;
  • FIG. 7 shows an example descriptive data structure format;
  • FIG. 8 shows an example descriptive data structure creation graphical interface;
  • FIG. 9 shows an example process for tracking descriptive data structure rights management related data;
  • FIG. 10A shows an example use of descriptive data structures to provide interoperability between environments; and
  • FIG. 10B provides more detail about how the FIG. 10A example descriptive data structure may be organized.
  • DETAILED DESCRIPTION OF PRESENTLY PREFERRED EXAMPLE EMBODIMENTS
  • FIGS. 2A and 2B show the example containers 100 a, 100 c of FIGS. 1A, 1B associated with machine readable descriptive data structures 200 and 200′. Referring to FIG. 2A, a descriptive data structure 200 is associated with content container 100 a. This descriptive data structure 200 may be used to define the content (and certain other characteristics) of container 100 a. In the example shown, descriptive data structure 200 defines a number of sections of newspaper style content 102 such as, for example, the headline (descriptor 202 a), the issue date (descriptor 202 b), the lead story (descriptor 202 c), breaking news (descriptor 202 d), image(s) (descriptor 202 e), advertisement (descriptor 202 f), and section (descriptor 202 g).
  • The descriptive data structure definitions 202 in this example do not contain or specify the particular contents of corresponding portions of the newspaper 102, but instead define more abstractly, a generic format that a newspaper style publication could use. For example, the FIG. 2A example descriptive data structure headline definition 202 a does not specify a particular headline (e.g., “Yankees Win the Pennant!”), but instead defines the location (for example, the logical or other offset address) within the container data structure 100 a (as well as certain other characteristics) in which such headline information may reside. Because descriptive data structure 200 is generic to a class or family of newspaper style content publications, it can be reused. For example, each daily issue of a newspaper might be created using and/or associated with the same descriptive data structure 200. By abstractly defining the data format and other characteristics of newspaper style content 102, the descriptive data structure 200 allows easy creation, usage and manipulation of newspaper style content 102.
  • Referring to FIG. 28, a different descriptive data structure 2001 may be used to define another class of content publications 106 such as fashion magazines. The descriptive data structure 200′ for this content class reflects a different format (and possibly other characteristics) as compared to the descriptive data structure 200 shown in FIG. 2A. For example, since fashion magazines typically do not include headlines or breaking news, the example descriptive data structure 200′ may not define such formatting. Instead, descriptive data structure 200′ for defining a class of fashion magazine content may define issue date (descriptor 204 a), a magazine title (descriptor 204 b), the name of a photographer (descriptor 204 c) and associated artwork designation (descriptor 204 d).
  • The FIGS. 2A and 2B examples show descriptive data structures 200, 200′ being delivered within content object containers 100 a, 100 c along with associated content 102, 106. However, other forms of association may be used. For example, descriptive data structure 200 can be independently delivered in its own separate container along with associated rules controlling its access and/or use. Alternatively, descriptive data structures 200 could be stored in a library and delivered on an as needed basis in secure or insecure form depending on particular requirements.
  • In addition, although FIGS. 2A and 2B are printed publication content examples, the use of descriptive data structures 200 is not so limited. To the contrary, descriptive data structures 200 can be used to define the format and/or other characteristics associated with a wide variety of different types of digital information including for example:
  • images
  • sound
  • video
  • computer programs
  • methods
  • executables
  • interpretables
  • currency objects
  • currency containers for currency objects
  • rules
  • any computer input
  • any computer output
  • other descriptive data structures
  • any other information.
  • Example Process for Creating and Using Descriptive Data Structures
  • FIG. 3 shows an example process for creating and using descriptive data structures 200. In this example, a layout tool 300 is used to create descriptive data structure 200. This layout tool 300 may be, for example, a software-controlled process interacting with a human being via a graphical user interface. The resulting descriptive data structure 200 (which may be stored on a mass storage device or other memory) can then be used to facilitate any number of other processes to create or interpret stored data. For example, the descriptive data structure may be used in a creation process 302. The creation process 302 may read the descriptive data structure and, in response, create an output file 400 with a predefined format such as, for example, a container 100 corresponding to a format described by the descriptive data structure 200. A viewing process 304 may use the descriptive data structure 200 to locate important items in the output file 400 for display. A browsing process 306 may use the descriptive data structure 200 to locate items within the stored output file 400 such as, for example, key words or other searchable text. Descriptive data structure 200 may supply integrity constraints or rules that protect the integrity of corresponding content during use of and/or access to the content.
  • FIG. 4 shows a more detailed example descriptive data structure creation and usage process. In this example, the layout tool 300 may accept user input 310 provided via a graphical user interface 312. The output of the layout tool 300 may be a descriptive data structure 200 in the form of, for example, a text file. A secure packaging process 302 a may accept container specific data as an input, and it may also accept the descriptive data structure 200 as a read only input. The packager 302 a could be based on a graphical user interface and/or it could be automated. The packager 302 a packages the container specific data 314 into a secure container 100. It may also package descriptive data structure 200 into the same container 100 if desired. A viewer 304 may view data 314 with the assistance of the descriptive data structure 200 and in accordance with rules 316 packaged within the container applying to the data 314 and/or the descriptive data structure 200.
  • Example Architecture for Using Descriptive Data Structures
  • FIG. 5 shows an example secure system architecture suitable for use with descriptive data structure 200. In this example, an electronic appliance 500 of the type described in the above-referenced Ginter et al. patent specification may be provided within a tamper resistant barrier 502. Electronic appliance 500 may include an application program interface (API) 504. One or more applications 506 may communicate with electronic appliance 500 via API 504. In some examples, the application 506 may execute on the secure electronic appliance 500. Each application 506 may include a descriptive data structure interpreter 508. In use, electronic appliance 500 may access secure container 100 and—in accordance with rules 316—access the descriptive data structure 200 and content 102 it contains and provide it to application 506. The interpreter 508 within application 506 may, in turn, read and use the descriptive data structure 200. In addition, application 506 may be polymorphic in the sense that it can take on personality or behavior as defined at least in part by descriptive data structure 200.
  • FIG. 5A shows an example detailed process performed by the FIG. 5 example secure system architecture. In this example, application 506 asks appliance 500 to retrieve the descriptive data structure 200 from container 100 (block 550). Electronic appliance 500 reads the descriptive data structure 200 and, subject to the conditions specified by associated rules 316, provides the descriptive data structure 200 to the application 506 (block 552). Application 506 then 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 says (block 556). The application 506 extracts or obtains the descriptive data structure information it needs or wants from interpreter 508 (block 558). For example, suppose the application 506 wants to display the “headline” information within newspaper style content shown in FIG. 2A. Application 506 may ask interpreter 508 to provide it with information that will help it to locate, read, format and/or display this “headline” information.
  • As another example, interpreter 508 may provide application 506 with an element identification (e.g., a hexadecimal value or other identifier) that corresponds to the headline information within the newspaper style content (block 558). Application 506 may then ask electronic appliance 500 to provide it with the Headline (or other) content information 102 within container 100 by providing appropriate content information to electronic appliance 500 via API 504 (block 560). For example, application 506 may pass the electronic appliance 500 the element ID that interpreter 508 provided to the application. Even though application 506 may have no direct knowledge of what is inside container 100 (and may only be able to access the container 100 through a secure VDE node provided by appliance 500), interpreter 508 (by looking at descriptive data structure 200) can tell application 506 enough information so that the application knows how to request the information it wants from the electronic appliance 500.
  • The electronic appliance may then access information 102 within container 100, and deliver (in accordance with the rules 316 within the container) the requested information to the application 506 (block 562). The application 506 may then use the information electronic appliance 500 provides to it, based at least in part on what interpreter 508 has told it about the content information (block 564). For example, the descriptive data structure 200 may provide characteristics about the way application 506 should handle the information 102. Descriptive data structure 200 can, for example, tell application 506 to always display a certain field (e.g., the author or copyright field) and to never display other information (e.g., information that should be hidden from most users). DDS 200 can also provide complete presentation or “visualization” information so that an information provider can, for example, control the look and feel of the information when it is displayed or otherwise rendered. Descriptive data structure 200 may provide encodings of other characteristics in the form of metadata that can also be used by application 506 during a process of creating, using or manipulating container 100. The DDS 200 can be used to generate a software program to manipulate rights management structures. For example, a DDS 200 could serve as the ‘instructions’ that drive an automated packaging application for digital content or an automated reader of digital content.
  • Example Description(s) Provided by Descriptive Data Structure
  • FIG. 6 shows one example of how a descriptive data structure 200 may describe and define an arbitrarily complex, information structure such as, for example, an hierarchical container 100. In this particular example, container 100 includes properties 600(1), 600(2). Property 600(1) may include n attributes 602(1), 602(2) . . . 602(n). Property 600(2) may include any number of attributes 604(1), 604(2), and it may also include an additional property 606. Property 606 may, in turn, include its own attributes 608(1), 608(2) . . . . Associated descriptive data structure 200 may be organized as a tree structure list 250 providing a recursive structure to reflect the recursive structure of the contents of container 100. For example, list 250 may include “branches” in the form of “property” descriptors 252(1), 252(2) corresponding to properties 600(1), 600(2). Each property descriptor 252 may, in turn, include a list 254 of attributes and may include additional property descriptors 256 in the same recursive, hierarchical arrangement as is reflective of the example content container structure. DDS 200 may be used to describe arbitrarily complex, hierarchical or non-hierarchical data structures of any dimension (1 to n).
  • FIG. 6A shows that descriptive data structure 200 can be used in conjunction with any kind of information such as, for example, events or methods defining an “atomic transaction” such as a real estate transaction. In this FIG. 6A example, a container 100 includes one or more descriptive data structures 200 and associated control set(s) 316 relating to a sequence of “events” 700 that define a real estate transaction. The DDS 200 may, for example, include a number of different entries 200A-200N pertaining to each different “event” within the transaction (e.g., “offer”, “acceptance”, “purchase/sales”, “inspection”, “mortgage”, etc.). These entries 200A-N may, for example, define where in container 100 the event can be found. The entries 200A-200N may also include metadata that provides additional characteristics corresponding to the event (for example, how certain information related to the event should be displayed).
  • Example Descriptive Data Structure Formatting
  • FIG. 7 shows an example of how descriptive data structure 200 may be formatted. As mentioned above, descriptive data structure 200 may comprise a list such as a linked list. Each list entry 260(1), 260(2), . . . may include a number of data fields including, for example:
      • an object name field 262,
      • one or more metadata fields 264 (which may be part of and/or referenced by the descriptive data structure); and
      • location information 266 (which may be used to help identify the corresponding information within the container data structure 100).
  • The object name field 262 may include a constant that may corresponds to or describes a type of information. For example, object name field 262 may act as a “handle” to the content or data; it may be an indirect reference to the content or data; and/or it may be used to look up the content or data The following are examples of object names:
  • General Purpose Object Names
      • NUMBER
      • STRING
      • DATE
      • TITLE
      • DESCRIPTION
      • AUTHOR
      • PROVIDER
      • MIME_TYPE
      • VERSION
      • URL
      • EMAIL
      • NEWGROUP
      • FILE_NAME
      • KEYWORDS
      • CREATION_DATE
      • MODIFICATION_DATE
      • LAST_ACCESS_DATE
      • NATIVE_PLATFORM
      • SIZE
      • CONTENT
      • PREVIEW
      • THUMBNAIL
      • TEXT
      • ARTWORK
      • ILLUSTRATION
      • UNKNOWN
      • TEMPLATE
      • BILLING_NAME
      • CONTAINER
  • Book-style Object Names
      • DEADLINE_DATE
      • TITLE_PAGE
      • PROLOGUE
      • INTRODUCTION
      • ABSTRACT
      • TABLE_OF_CONTENTS
      • CHAPTER
      • CHAPTER_NUMBER
      • INDEX
  • Electronic Mail-style Object Names
      • FROM
      • TO
      • CC
      • SUBJECT
      • MESSAGE_BODY
      • ENCLOSURE
  • Newspaper-style Object Names
      • ISSUE_DATE
      • ARTICLE
      • COLUMN
      • COVER_STORY
      • LEAD_STORY
      • BREAKING_NEWS
      • ADVERTISEMENT
      • SECTION
      • EDITORIAL
  • The DDS 200 may include or reference any type of data or metadata. In one example, the DDS 200 uses the object name field 262 to points or refers to metadata. This metadata can define certain characteristics associated with the object name. For example, such metadata may impose integrity or other constraints during the creation and/or usage process (e.g., “when you create an object, you must provide this information”, or “when you display the object, you must display this information”). The metadata 264 may also further describe or otherwise qualify the associated object name.
  • In one preferred example, the DDS 200 uses object name 262 to refer to metadata stored elsewhere—such as in a container 100. This referencing technique provides several advantages. For example, one situation where it may be useful to store the metadata in a secure container 100 separately from DDS 200 is in situations where it is desirable to make the DDS readily accessible to an outside application but to protect the associated metadata. For example, consider the case of handling web spider queries. A web spider may query the DDS 200 for a particular object name 262. If the object name is found, then the web spider may request the corresponding metadata. The web spider may have ready access to the metadata, but may only be able to access the associated metadata from the container 100 under appropriate conditions as controlled by a corresponding secure electronic appliance 500 based on associated rules 316. As another example, storing metadata separately from the DDS 200 may allow the same DDS to be used with different metadata in different contexts. Suppose for example that a DDS 200 contains an Object Name, for example KEYWORDS. When DDS 200 is associated with container 100A, then the DDS Object Name KEYWORDS refers to container 100A's KEYWORDS metadata. Conversely, if later this same DDS 200 is associated (e.g., packaged with) a different container 100C, then the DDS Object Name KEYWORDS refers to container 100B's KEYWORDS data.
  • Although it is preferred to use object name 262 to refer to metadata stored elsewhere, there may be other instances where there is a need or desire to explicitly include metadata within the DDS 200. For purposes of illustration, FIG. 7 shows an example DDS 200 that includes metadata field 264 and also refers to metadata within a container 100 using the object name 262. Either or both techniques may be used.
  • The DDS 200 thus allows value chain participants to protect the integrity of content, by enabling the specification of integrity constraints. DDS 200 integrity constraints provide a way to state rules about the content. For example, DDS 200 can specify that an article of a newspaper cannot be viewed without its headline being viewed. The corresponding integrity constraint can indicate the rule ‘if there is an article, there must also be a headline”. Another example is a photograph that is part of a magazine and the credit that goes with it. The integrity constraint rule provided by DDS 200 might be ‘do not present this photograph without its associated credit’.
  • DDS integrity constraints give value chain participants a tool for protecting the use of the DDS 200, ensuring that content represented by a particular DDS contains all the essential components—that it is representative of the DDS. This gives providers a way to set up conventions and enforce standards of use. There are many possible integrity constraints. The following are a few examples:
      • Required: a is required as part of the content
      • Optional: a is an optional component of the content
      • Required relationship: if a is present, then b must be present, or if a is present b, c and d must be present. Conversely, if b is not present, then a is not allowed to be present. Relationships in this category are 1:m where m>0.
      • Optional relationship: If a is present b may or may not be present. If b is present, then a is guaranteed to be present. Relationships in this category are 1:n, where n>=0.
      • Repetition: a must occur n times where n>1. This could be specified with ranges of values, etc.
      • Other rules and/or requirements.
      • Metadata 264
    Example Graphical Interface for Creating Descriptive Data Structures
  • FIG. 8 shows an example descriptive data structure creation graphical user interface 312. In this example, the graphical user interface 312 may prompt the user for the object name. In addition, the graphical user interface 312 may provide options for specifying the associated metadata 264. The options shown in FIG. 8 may, for example, include:)
      • “construction type” metadata (upon object construction, the information is required; upon object construction, the object creation tool is to always or never prompt for the information);
      • display metadata (e.g., always display the associated information (e.g., for copyright notices, author names and the like) or always or never make the information visible; and/or
      • layout “hints” and field definitions (e.g., text, text block, integer, file, image or other data type).
  • The above metadata descriptions are non-limiting examples. Other metadata characteristics and attributes may be used.
  • Example Process Using Descriptive Data Structures
  • FIG. 9 shows one example arrangement for using the infrastructure described in co-pending related U.S. patent application Ser. No. 08/699,712 (referenced above) for descriptive data structures 200. The arrangement shown in FIG. 9 may be useful in a number of different contexts. For example, a provider 600 of descriptive data structures 200 may want to know which descriptive data structures 200 are the best liked by his customers so he or she can improve the quality of his products. Or, a provider 600 may charge customers for using descriptive data structures 200 on a per use or other basis. In still another example, some descriptive data structures 200 or classes of DDS 200 may be restricted to use only by authorized users or classes of authorized users.
  • FIG. 9 shows a DDS provider 600 who delivers a DDS 200 and an associated control set 316 to a value chain participant 602. Controls 316 may provide rules and associated consequences for controlling or otherwise affecting the use or other aspects of what value chain participant 602 can do with DDS 200. The controls 316 and DDS 200 may be packaged within a container 100. Value chain participant 602 may get the container 100 containing DDS 200 directly from DDS provider 600; alternatively, the provider can provide it a rights and permissions clearinghouse 604 and participant 602 and get it from the clearinghouse (or elsewhere) (see container 100B).
  • Value chain participant 602 can use DDS 200 to author content 102. Participant 602 can package content 102 with associated controls 316A in a container 100A. Participant 600 may, if he desires, include DDS 200 and associated controls 316 a, 316 b with content 102 in the same container—or depend on the provider 600 and/or rights and permissions clearinghouse 604 to independently deliver the DDS and its controls to end users 606 in another container 100 c for example.
  • End users 606(1), . . . , 606(n) use DDS 200 (in accordance with controls 316) in conjunction with content 102 (for example, to read, browse or otherwise access the container content). Controls 316, 316A may require user appliances to provide usage data 610 to a usage clearinghouse 612. The usage clearinghouse 612 can provide usage data 610A related to access and/or usage of DDS 200 to DDS provider 600, and may independently provide usage data 610B related to access and/or usage of content 102 to value chain participant 602.
  • Descriptive Data Structures can be Used to Achieve a Degree of Interoperability Between Rights Management Environments
  • Descriptive data structures 200 provided in accordance with the present invention can provide a degree of interoperability between source and target rights management environments, and/or to provide a bridge to achieve at least some degree of interoperatibility between a rights management environment and the outside world.
  • Different rights management environments may have substantially incompatible mechanisms for defining rights pertaining to an object. Descriptive data structures 200 can provide at least a partial bridge to achieve a degree of compatibility and interoperability. For example, a provider that defines an object within a source rights management environment may create a descriptive data structure for use by processes within one or more target rights management environments. For example, an object creator or other provider can specify, within a descriptive data structure 200, certain rules, integrity constraints and/or other characteristics that can or should be applied to the object after it has been imported into a target rights management environment. The target rights management environment can choose to selectively enforce such rules, constraints and/or other characteristics depending on the degree to which it can trust the source environment. For example, objects imported from an EDI system employing X.12 security may be more trustworthy than objects presented from environments with lesser (or no) security.
  • In another example, a provider that creates an object outside of any rights management environment can create a descriptive data structure 200 for use if and when the object is imported into one or more rights management environments. The target rights management environment(s) can use such descriptive data structure(s) to help efficiently understand and handle the object. Further, a descriptive data structure created within a rights management environment can be exported to one or more applications outside of the rights management environment and used to assist the application(s) in interpreting exported content or other information.
  • FIG. 10A shows an example of how descriptive data structures 200 may be used to provide interoperability. In the FIG. 10A example, a DDS creation tool 800 creates a DDS 200 that includes one or more target data blocks 801. In one example, the DDS creation tool 800 may be based on, and/or incorporate some or all of the capabilities of layout tool 300 and provide interoperability capabilities in addition to features associated with layout tool 300. In another example, DDS creation tool 800 may not incorporate any of the capabilities of layout tool 300, and may create DDS 200 solely for interoperability purposes. DDS creation tool 800 may, for example, be an application program with a graphical user interface, a background process that only displays a user interface when being configured by a user, a portion of an operating system, a portion of a computer's firmware, a server process that may act independently or as part or all of a “gateway” between one system and another (e.g., a public network and a private network, two or more private networks, a local area network and a wide area network, etc.), or any other desirable implementation or integration.
  • Target data block 801 may provide information used to provide interoperability with a particular target environment 850. A single DDS 200 can, in one example, provide interoperability with N different target environments 850 by including N target data blocks 801(1), . . . 801(N) each corresponding to a different target environment 850(1), . . . 850(N).
  • In this example, each target data block 801 includes rule (control) information. Different target data blocks 801 can provide different rule information for different target environments 850. The rule information may, for example, relate to operations (events) and/or consequences of application program functions 856 within the associated target environment 850 such as specifying:
      • permitted and/or required operations;
      • nature and/or extent of operations permitted and/or required operations; and/or
      • consequences of performing permitted and/or required operations.
  • The target data block 801 may also include additional information if desired that gives directions to a DOS parser 852 and/or a translator 854 within a corresponding target environment 850.
  • FIG. 10B shows one detailed example of how target information may be organized within DDS 200. In this example, DDS creation tool 800 creates a DDS header 805 that references one or more target record headers 807. DDS header 805 may, for example, include a “number of targets” field 809 indicating the number of target data blocks 801 within the DDS 200, a “offset to first target data portion” field 811 that provides the location of the first target data block 801(1) within the DDS 200, a source message field 812A that identifies the source environment, and an optional creator seal 812B that may be used to verify the integrity and authenticity of the DDS 200. Source message field 812A (which can be optional) may include a source ID that may be used to help verify the source environment of DDS 200, and an optional source seal (that may or may not be present in the source message). Each target data block 801 within DDS 200 may begin with a target record header 807 including a “target ID” field 813, a “length” field 815, a “offset to next target data portion” field 817, an optional creator seal 819, and an optional source message 821. The “target ID” field 813 may specify a unique identification number or value corresponding to the associated target data block 801 and/or identifying the intended target environment(s), the “length” field 815 may specify the length of the target data block 801, and the “offset” field 817 may specify the location (relative or absolute) of the next target data block 801 within the DDS 200 (and may take on a null value for the last target data block).
  • The optional creator seals 812B, 819 (and source seals) may be cryptographic seals that help to ensure that the DDS 200 and target records 801, respectively, have not be altered since they were created, and also the identity of the DDS 200's and/or source creator. The optional source messages 812C and 821 may be information that helps to ensure that a target environment knows which source environment created DDS 200.
  • Referring again to FIG. 10A, DDS creation tool 800 may, upon creating the DDS 200, cryptographically seal it and each target data block 801 for integrity using appropriate cryptographic processes, for example by first running a cryptographic hash function (e.g., SHA, MD5, etch) on the data and then encrypting the resulting hash value using a private key of the DDS creator associated with an asymmetric cryptosystem (e.g., RSA, El Gamal, etc.). If sealing is used, the DDS creator preferably should ensure that the public key associated with the encrypting private key is certified (e.g., encrypted with a private key of a certifying authority) and available for use by target environments to validate the seal (e.g., by including a certificate in DDS 200, publishing the certificate on a public network, etc.)
  • If source messages 812C, 821 are used, they should preferably represent information provided by the source environment that may help a target environment identify the source environment, and further may also help to ensure that the DDS 200 was actually created by the source environment (and therefore may, for example, be trusted to the extent that the source environment is trusted). For example, a source environment may have a protected processing environment (PPE) of the form described in the above referenced Ginter, et al. patent application. Certain of such PPEs may have cryptographic keys (e.g., a private key of a public key/private key pair) available that may be used to encrypt a cryptographic hash taken of the DDS header 805 or target block header 807, as appropriate. In such an example, a target environment would need to acquire a corresponding cryptographic key (e.g., a public key of a public key/private key pair) using trusted techniques (e.g., delivery in a certificate signed by a trusted certifying authority) in order to evaluate such a source message. In another example, DDS creation tool 800 may have been equipped with cryptographic keys when it was manufactured, and may use these cryptographic keys instead of keys from a PPE, although generally this technique would be more susceptible to tampering by an experienced computer hacker and might therefore be somewhat less trusted by target environments.
  • In addition, or alternatively (for example, if cryptographic techniques are not appropriate or desired), the source message may contain a unique identifier that corresponds to the source environment.
  • The DDS creation tool 800 (see FIG. 10A) may then package the resulting DDS 200 into a secure container 100 along with an associated object 830.
  • In another example, DDS creation tool 800 may embed DDS 200 within, or otherwise associate the DDS with, an object 830′ that provides a method for releasing the DDS to the target environment parser 852. The DDS 200 and its associated object 830 may then be delivered to one or more target environments 850 for processing.
  • Target environment parser 852 (and/or translator 854) may, for example, be part of an application program, part of an operating system, or part of a utility program used by, or in conjunction with, an application program and/or an operating system. The target environment parser 852 receives the DDS 200 and parses it to locate the target data block 801(k) corresponding to the target environment 850 (k). Parser 852 may then determine, from the corresponding target data block 801, the rules the target data block contains. Parser 852 preferably understands enough about the structure of DDS 200 to find (e.g., using the header information shown in FIG. 10B) the appropriate target data block 801 corresponding to it, and also to understand the rules within the target data block. The target environment parser 852 doesn't need to understand any additional rules 316 that may be packaged within container 100 or otherwise delivered with object 830, but it may use any such additional rules if desired (e.g., when it finds no target data block 801 within DDS 200 for the particular target environment 850 (for example, if it is capable of understanding some other target data block 801 whose rules are based on a published specification and/or standard)).
  • The target environment parser 852 may obtain applicable target rules from target data block 801 and provide these rules to application program functions 856. Application program functions 856 may define any operation pertaining to object 830 such as for example:
  • cut
  • copy
  • print
  • paste
  • save
  • change
  • delete
  • any other operation
  • The target rules provided by parser 852 may be used, for example, to permit, require and/or prevent certain operations; to define the extent to which certain operations can be performed (e.g., limit number of copies, define extent of cut, the rules that should be applied to cut information in subsequent use, etc.); and/or to define the consequences of performing a particular operation (e.g., charge the user for printing or otherwise using and/or accessing all or part of object 830, maintain records of the time and/or number of such operations performed, etc.).
  • Parser 852 may also, or alternatively, provide some or all of the rules it obtains from target data block 801 to other arrangements for applying the rules such as, for example, the “other rights management functions” block 858. Block 858 may provide any kind of rights management functions. Translator 854 may be used if needed to allow the application program functions 856 and/or the “other rights management” block 858 to understand the rules. As one example, translator 854 may be used to further elaborate, parameterize and/or secure the rule information obtained from target data block 801 so they are more or fully compatible with the “other rights management functions” block 858.
  • A useful data structure definitional method and arrangement has been described in connection with its most practical and presently preferred example embodiments. The present invention is not to be limited to those embodiments, but on the contrary, is intended to encompass variations and equivalents as defined within the spirit and scope of the claims.

Claims (15)

1. A data processing method comprising the steps of:
creating a machine readable descriptive data structure; and
using the descriptive data structure to interoperate with at least one rights management data structure, wherein the using step includes formatting display of at least one part of the at least one rights management data structure at least in part in accordance with the descriptive data structure.
2. A method as in claim 1 wherein the creating step includes providing metadata within the descriptive data structure, and the using step comprises displaying at least some information from the rights management data structure at least in part in accordance with the metadata.
3. The method of claim 1, wherein the creating step includes creating at least one integrity constraint, and the using step includes enforcing the integrity constraint.
4. The method of claim 2, wherein the creating step is performed using a graphical user interface and the graphical user interface provides options for specifying the metadata.
5. The method of claim 2, wherein the metadata includes information specifying that specified information must be displayed if some or all of the information from the rights management data structure are displayed.
6. The method of claim 2, wherein the metadata is stored outside the descriptive data structure in a second rights management data structure.
7. The methods of claim 3, wherein the integrity constraint protects the integrity of corresponding content during use of or access to the content.
8. The method of claim 3, wherein the integrity constraint provides rules about using the descriptive data structure.
9. The method of claim 1, wherein the descriptive data structure includes organization information at least in part describing a required or a desired organization of a content section of a secure container
10. The method of claim 1, wherein the rights management data structure is a secure container.
11. A data structure embodied on a computer-readable medium, the data structure comprising:
information that identifies, at least in part, a digital object;
a first rule, the first rule specifying rights pertaining to the digital object;
a second rule, the second rule specifying rights pertaining to the object,
wherein the second rule specifies said rights using a different mechanism from the first rule.
12. A data structure as in claim 11, further comprising:
a third rule, the third rule specifying rights pertaining to the object, the third rule specifying said rights using a different mechanism from the first rule and the second rule.
13. A data structure as in claim 11, in which the first rule and the second rule express the same rights.
14. A data structure as in claim 11, in which the first rule is interpretable by a first rights management system, and the second rule is interpretable by a second rights management system.
15. A data structure as in claim 14, in which the first rights management system and the second rights management system employ substantially incompatible mechanisms for specifying rights pertaining to objects.
US11/779,835 1997-02-25 2007-07-18 Techniques for Defining, Using and Manipulating Rights Management Data Structures Abandoned US20080016103A1 (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US11/779,835 US20080016103A1 (en) 1997-02-25 2007-07-18 Techniques for Defining, Using and Manipulating Rights Management Data Structures

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US08/805,804 US5920861A (en) 1997-02-25 1997-02-25 Techniques for defining using and manipulating rights management data structures
US09/300,778 US6138119A (en) 1997-02-25 1999-04-27 Techniques for defining, using and manipulating rights management data structures
US09/819,063 US7062500B1 (en) 1997-02-25 2000-09-28 Techniques for defining, using and manipulating rights management data structures
US11/256,518 US20060053158A1 (en) 1997-02-25 2005-10-20 Techniques for defining, using and manipulating rights management data structures
US11/779,835 US20080016103A1 (en) 1997-02-25 2007-07-18 Techniques for Defining, Using and Manipulating Rights Management Data Structures

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
US11/256,518 Continuation US20060053158A1 (en) 1997-02-25 2005-10-20 Techniques for defining, using and manipulating rights management data structures

Publications (1)

Publication Number Publication Date
US20080016103A1 true US20080016103A1 (en) 2008-01-17

Family

ID=36588994

Family Applications (5)

Application Number Title Priority Date Filing Date
US09/819,063 Expired - Lifetime US7062500B1 (en) 1997-02-25 2000-09-28 Techniques for defining, using and manipulating rights management data structures
US11/256,518 Abandoned US20060053158A1 (en) 1997-02-25 2005-10-20 Techniques for defining, using and manipulating rights management data structures
US11/779,835 Abandoned US20080016103A1 (en) 1997-02-25 2007-07-18 Techniques for Defining, Using and Manipulating Rights Management Data Structures
US11/926,972 Abandoned US20080114790A1 (en) 1997-02-25 2007-10-29 Techniques for Defining, Using and Manipulating Rights Management Data Structures
US13/430,572 Abandoned US20130055408A1 (en) 1997-02-25 2012-03-26 Techniques for defining, using and manipulating rights management data structures

Family Applications Before (2)

Application Number Title Priority Date Filing Date
US09/819,063 Expired - Lifetime US7062500B1 (en) 1997-02-25 2000-09-28 Techniques for defining, using and manipulating rights management data structures
US11/256,518 Abandoned US20060053158A1 (en) 1997-02-25 2005-10-20 Techniques for defining, using and manipulating rights management data structures

Family Applications After (2)

Application Number Title Priority Date Filing Date
US11/926,972 Abandoned US20080114790A1 (en) 1997-02-25 2007-10-29 Techniques for Defining, Using and Manipulating Rights Management Data Structures
US13/430,572 Abandoned US20130055408A1 (en) 1997-02-25 2012-03-26 Techniques for defining, using and manipulating rights management data structures

Country Status (1)

Country Link
US (5) US7062500B1 (en)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120072829A1 (en) * 2009-05-20 2012-03-22 Bgs Crossmedia Sarl System for generating ready-to-print documents
US20120259769A1 (en) * 2006-12-14 2012-10-11 Robert Cary Maleeny Apparatus, systems, and methods to facilitate the interaction between parties
US20160080524A1 (en) * 2014-09-17 2016-03-17 Oracle International Corporation Mobile runtime conditional sections for surveys
EP3133507A1 (en) 2015-03-31 2017-02-22 Secude AG Context-based data classification
US10943030B2 (en) 2008-12-15 2021-03-09 Ibailbonding.Com Securable independent electronic document
US11032280B1 (en) * 2017-12-13 2021-06-08 Amazon Technologies, Inc. Proxy for controlling access to services

Families Citing this family (117)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7165174B1 (en) * 1995-02-13 2007-01-16 Intertrust Technologies Corp. Trusted infrastructure support systems, methods and techniques for secure electronic commerce transaction and rights management
DE69637799D1 (en) 1995-02-13 2009-02-12 Intertrust Tech Corp Systems and procedures for secure transaction management and electronic legal protection
US6948070B1 (en) 1995-02-13 2005-09-20 Intertrust Technologies Corporation Systems and methods for secure transaction management and electronic rights protection
US6157721A (en) 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US7133846B1 (en) 1995-02-13 2006-11-07 Intertrust Technologies Corp. Digital certificate support system, methods and techniques for secure electronic commerce transaction and rights management
US5892900A (en) 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5943422A (en) 1996-08-12 1999-08-24 Intertrust Technologies Corp. Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels
US6658568B1 (en) 1995-02-13 2003-12-02 Intertrust Technologies Corporation Trusted infrastructure support system, methods and techniques for secure electronic commerce transaction and rights management
US7912856B2 (en) * 1998-06-29 2011-03-22 Sonicwall, Inc. Adaptive encryption
US6408336B1 (en) 1997-03-10 2002-06-18 David S. Schneider Distributed administration of access to information
US8914410B2 (en) * 1999-02-16 2014-12-16 Sonicwall, Inc. Query interface to policy server
US7821926B2 (en) 1997-03-10 2010-10-26 Sonicwall, Inc. Generalized policy server
FR2787902B1 (en) * 1998-12-23 2004-07-30 France Telecom MODEL AND METHOD FOR IMPLEMENTING A RATIONAL DIALOGUE AGENT, SERVER AND MULTI-AGENT SYSTEM FOR IMPLEMENTATION
US6870550B1 (en) * 1999-04-26 2005-03-22 Adobe Systems Incorporated Digital Painting
US6876991B1 (en) 1999-11-08 2005-04-05 Collaborative Decision Platforms, Llc. System, method and computer program product for a collaborative decision platform
US7191392B1 (en) * 2000-03-23 2007-03-13 Virpack.Com System and method for the creation of virtual information packages
US7855229B2 (en) * 2000-08-24 2010-12-21 University Of Tennessee Research Foundation Treating wasting disorders with selective androgen receptor modulators
US20020184490A1 (en) * 2001-06-05 2002-12-05 Storage Technology Corporation Anti-piracy network storage device
US20070157079A1 (en) * 2001-08-31 2007-07-05 Baker Jeffrey T Apparatus and method for negotiating and generating contract documents on-line
AU2003244378A1 (en) * 2002-02-05 2003-09-02 Matsushita Electric Industrial Co., Ltd. Method of distributed ipmp device messaging and carriage of rights in mpeg ipmp content
ATE526784T1 (en) * 2002-02-27 2011-10-15 Opentv Inc METHOD AND DEVICE FOR PROVIDING A HIERARCHICAL SECURITY PROFILE OBJECT
US8108313B2 (en) * 2002-03-14 2012-01-31 Contentguard Holdings, Inc. Rights expression profile system and method using templates
US20030217280A1 (en) * 2002-05-17 2003-11-20 Keaton Thomas S. Software watermarking for anti-tamper protection
CN1656803B (en) * 2002-05-22 2012-06-13 皇家飞利浦电子股份有限公司 Digital rights management method and system
US8131649B2 (en) * 2003-02-07 2012-03-06 Igware, Inc. Static-or-dynamic and limited-or-unlimited content rights
US7779482B1 (en) * 2003-02-07 2010-08-17 iGware Inc Delivery of license information using a short messaging system protocol in a closed content distribution system
US20100017627A1 (en) 2003-02-07 2010-01-21 Broadon Communications Corp. Ensuring authenticity in a closed content distribution system
US7712034B2 (en) 2003-03-24 2010-05-04 Microsoft Corporation System and method for shell browser
US7769794B2 (en) 2003-03-24 2010-08-03 Microsoft Corporation User interface for a file system shell
US7421438B2 (en) 2004-04-29 2008-09-02 Microsoft Corporation Metadata editing control
US7823077B2 (en) 2003-03-24 2010-10-26 Microsoft Corporation System and method for user modification of metadata in a shell browser
US7240292B2 (en) 2003-04-17 2007-07-03 Microsoft Corporation Virtual address bar user interface control
US7627552B2 (en) 2003-03-27 2009-12-01 Microsoft Corporation System and method for filtering and organizing items based on common elements
US7526483B2 (en) * 2003-03-27 2009-04-28 Microsoft Corporation System and method for virtual folder sharing including utilization of static and dynamic lists
US7925682B2 (en) 2003-03-27 2011-04-12 Microsoft Corporation System and method utilizing virtual folders
US7650575B2 (en) 2003-03-27 2010-01-19 Microsoft Corporation Rich drag drop user interface
EP1477892B1 (en) * 2003-05-16 2015-12-23 Sap Se System, method, computer program product and article of manufacture for inputting data in a computer system
US7949877B2 (en) * 2003-06-30 2011-05-24 Realnetworks, Inc. Rights enforcement and usage reporting on a client device
US8024335B2 (en) 2004-05-03 2011-09-20 Microsoft Corporation System and method for dynamically generating a selectable search extension
JP4439880B2 (en) * 2003-11-13 2010-03-24 パナソニック株式会社 Content distribution system, content server, content receiving device, content distribution method, recording medium, and program
JP4487607B2 (en) * 2004-03-23 2010-06-23 ソニー株式会社 Information processing system, information processing apparatus and method, recording medium, and program
US7694236B2 (en) 2004-04-23 2010-04-06 Microsoft Corporation Stack icons representing multiple objects
US7657846B2 (en) 2004-04-23 2010-02-02 Microsoft Corporation System and method for displaying stack icons
US7313575B2 (en) * 2004-06-14 2007-12-25 Hewlett-Packard Development Company, L.P. Data services handler
JP4728610B2 (en) * 2004-08-04 2011-07-20 株式会社リコー Access control list attachment system, original content creator terminal, policy server, original content data management server, program, and recording medium
US7707498B2 (en) * 2004-09-30 2010-04-27 Microsoft Corporation Specific type content manager in an electronic document
US7783619B2 (en) * 2004-10-27 2010-08-24 Elsevier B.V. Methods and software for analysis of research publications
US7512814B2 (en) * 2004-11-09 2009-03-31 Fortiva Inc. Secure and searchable storage system and method
US7730394B2 (en) * 2005-01-06 2010-06-01 Microsoft Corporation Data binding in a word-processing application
US7945590B2 (en) * 2005-01-06 2011-05-17 Microsoft Corporation Programmability for binding data
US7617234B2 (en) * 2005-01-06 2009-11-10 Microsoft Corporation XML schema for binding data
US7668873B2 (en) * 2005-02-25 2010-02-23 Microsoft Corporation Data store for software application documents
US7752224B2 (en) * 2005-02-25 2010-07-06 Microsoft Corporation Programmability for XML data store for documents
US7818350B2 (en) 2005-02-28 2010-10-19 Yahoo! Inc. System and method for creating a collaborative playlist
US20060212804A1 (en) * 2005-03-15 2006-09-21 Microsoft Corporation Method and system for formatting web pages having constrained dynamic regions on content templates
US8326659B2 (en) * 2005-04-12 2012-12-04 Blackboard Inc. Method and system for assessment within a multi-level organization
US8195646B2 (en) 2005-04-22 2012-06-05 Microsoft Corporation Systems, methods, and user interfaces for storing, searching, navigating, and retrieving electronic information
US7505990B2 (en) * 2005-05-05 2009-03-17 International Business Machines Corporation Method for defining and generating document management applications for model-driven document management
US20060288402A1 (en) * 2005-06-20 2006-12-21 Nokia Corporation Security component for dynamic properties framework
US7665028B2 (en) 2005-07-13 2010-02-16 Microsoft Corporation Rich drag drop user interface
US20070033190A1 (en) * 2005-08-08 2007-02-08 Microsoft Corporation Unified storage security model
US7953696B2 (en) * 2005-09-09 2011-05-31 Microsoft Corporation Real-time synchronization of XML data between applications
US8150960B2 (en) * 2005-11-23 2012-04-03 Microsoft Corporation Event forwarding
US7873615B2 (en) * 2005-12-14 2011-01-18 Sap Ag Control object based report generation using a central class
US20070150299A1 (en) * 2005-12-22 2007-06-28 Flory Clive F Method, system, and apparatus for the management of the electronic files
US8156566B2 (en) * 2005-12-29 2012-04-10 Nextlabs, Inc. Associating code to a target through code inspection
US8832048B2 (en) 2005-12-29 2014-09-09 Nextlabs, Inc. Techniques and system to monitor and log access of information based on system and user context using policies
US7716240B2 (en) * 2005-12-29 2010-05-11 Nextlabs, Inc. Techniques and system to deploy policies intelligently
US7933964B2 (en) 2006-02-16 2011-04-26 Microsoft Corporation Shell sessions
US8745489B2 (en) * 2006-02-16 2014-06-03 Microsoft Corporation Shell input/output segregation
US8086535B2 (en) * 2006-04-04 2011-12-27 Apple Inc. Decoupling rights in a digital content unit from download
US10102351B2 (en) * 2006-04-04 2018-10-16 Apple Inc. Decoupling rights in a digital content unit from download
JP2009535735A (en) 2006-05-02 2009-10-01 ブロードオン コミュニケーションズ コーポレーション Content management system and method
US8869066B2 (en) 2006-07-06 2014-10-21 Addthis, Llc Generic content collection systems
US20080010453A1 (en) * 2006-07-06 2008-01-10 Laurence Hamid Method and apparatus for one time password access to portable credential entry and memory storage devices
US20080126385A1 (en) * 2006-09-19 2008-05-29 Microsoft Corporation Intelligent batching of electronic data interchange messages
US20080071806A1 (en) * 2006-09-20 2008-03-20 Microsoft Corporation Difference analysis for electronic data interchange (edi) data dictionary
US8108767B2 (en) * 2006-09-20 2012-01-31 Microsoft Corporation Electronic data interchange transaction set definition based instance editing
US8161078B2 (en) * 2006-09-20 2012-04-17 Microsoft Corporation Electronic data interchange (EDI) data dictionary management and versioning system
US20080126386A1 (en) * 2006-09-20 2008-05-29 Microsoft Corporation Translation of electronic data interchange messages to extensible markup language representation(s)
US8056092B2 (en) 2006-09-29 2011-11-08 Clearspring Technologies, Inc. Method and apparatus for widget-container hosting and generation
US7624276B2 (en) 2006-10-16 2009-11-24 Broadon Communications Corp. Secure device authentication system and method
US9218213B2 (en) 2006-10-31 2015-12-22 International Business Machines Corporation Dynamic placement of heterogeneous workloads
US7716596B2 (en) * 2006-11-08 2010-05-11 International Business Machines Corporation Dynamic input field protection
US7613915B2 (en) 2006-11-09 2009-11-03 BroadOn Communications Corp Method for programming on-chip non-volatile memory in a secure processor, and a device so programmed
US20080168081A1 (en) * 2007-01-09 2008-07-10 Microsoft Corporation Extensible schemas and party configurations for edi document generation or validation
US20080168109A1 (en) * 2007-01-09 2008-07-10 Microsoft Corporation Automatic map updating based on schema changes
US20080222232A1 (en) * 2007-03-06 2008-09-11 Allen Stewart O Method and Apparatus for Widget and Widget-Container Platform Adaptation and Distribution
US8266274B2 (en) * 2007-03-06 2012-09-11 Clearspring Technologies, Inc. Method and apparatus for data processing
US9009728B2 (en) * 2007-03-06 2015-04-14 Addthis, Inc. Method and apparatus for widget and widget-container distribution control based on content rules
US7890320B2 (en) * 2007-04-17 2011-02-15 Microsoft Corporation Tower of numeric types
US9405585B2 (en) * 2007-04-30 2016-08-02 International Business Machines Corporation Management of heterogeneous workloads
US20080320600A1 (en) * 2007-06-21 2008-12-25 Matthew Pandiscia Secure document management system and apparatus
US8341104B2 (en) * 2007-08-16 2012-12-25 Verizon Patent And Licensing Inc. Method and apparatus for rule-based masking of data
US8209378B2 (en) * 2007-10-04 2012-06-26 Clearspring Technologies, Inc. Methods and apparatus for widget sharing between content aggregation points
US8001604B2 (en) * 2007-11-06 2011-08-16 International Business Machines Corporation Method and apparatus for masking child user authorizations from adverse use against a parent user
US9552491B1 (en) * 2007-12-04 2017-01-24 Crimson Corporation Systems and methods for securing data
US8156538B2 (en) * 2007-12-18 2012-04-10 Microsoft Corporation Distribution of information protection policies to client machines
US8126931B2 (en) * 2008-06-13 2012-02-28 Sap Ag Method and apparatus for displaying the composition of a data structure during runtime
US20100100605A1 (en) * 2008-09-15 2010-04-22 Allen Stewart O Methods and apparatus for management of inter-widget interactions
US9811511B1 (en) * 2009-11-11 2017-11-07 West Corporation Method and apparatus of creating customized computer-based user dashboard interfaces
US9213860B2 (en) 2010-09-03 2015-12-15 James Kenneth Everett System, method, and database for personal information management with advanced access controls
US8869048B2 (en) * 2010-09-14 2014-10-21 Microsoft Corporation Declarative and multi-mode wizard framework
US9081893B2 (en) * 2011-02-18 2015-07-14 Microsoft Technology Licensing, Llc Dynamic lazy type system
US8627097B2 (en) 2012-03-27 2014-01-07 Igt System and method enabling parallel processing of hash functions using authentication checkpoint hashes
US20140067775A1 (en) * 2012-09-05 2014-03-06 salesforce.com,inc System, method and computer program product for conditionally performing de-duping on data
EP2741462A1 (en) * 2012-12-06 2014-06-11 ST-Ericsson SA Methods for opportunistic sensing
USD754162S1 (en) * 2013-01-04 2016-04-19 Level 3 Communications, Llc Display screen or portion thereof with graphical user interface
USD768659S1 (en) * 2013-01-04 2016-10-11 Level 3 Communications, Llc Display screen or portion thereof with graphical user interface
EP3410422A1 (en) * 2014-06-18 2018-12-05 James Collier Methods and apparatus for cryptography
US10432642B2 (en) 2015-09-25 2019-10-01 T-Mobile Usa, Inc. Secure data corridors for data feeds
US10432641B2 (en) * 2015-09-25 2019-10-01 T-Mobile Usa, Inc. Secure data corridors
US10747895B2 (en) 2015-09-25 2020-08-18 T-Mobile Usa, Inc. Distribute big data security architecture
USD796528S1 (en) 2015-11-19 2017-09-05 Samsung Electronics Co., Ltd. Display screen or portion thereof with graphical user interface
US10289854B1 (en) 2016-09-23 2019-05-14 Amdocs Development Limited Apparatus, computer program, and method for generating an intermediate entitlement specification for controlling access to service or content
US10726038B2 (en) * 2017-05-24 2020-07-28 MphasiS Limited System and method for optimizing aggregation and analysis of data across multiple data sources
US10805082B2 (en) * 2017-06-30 2020-10-13 Futurewei Technologies, Inc. ID-based data plane security for identity-oriented networks

Citations (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4141005A (en) * 1976-11-11 1979-02-20 International Business Machines Corporation Data format converting apparatus for use in a digital data processor
US4881197A (en) * 1987-02-13 1989-11-14 Addison Fischer Document composition system using named formats and named fonts
US4952082A (en) * 1987-05-24 1990-08-28 Brother Kogyo Kabushiki Kaisha Text processing system for cyclically shifting format memory
US5201047A (en) * 1989-12-21 1993-04-06 International Business Machines Corporation Attribute-based classification and retrieval system
US5201046A (en) * 1990-06-22 1993-04-06 Xidak, Inc. Relational database management system and method for storing, retrieving and modifying directed graph data structures
US5280479A (en) * 1991-06-18 1994-01-18 Matra Communication Device for insertion of digital packets in a transmission channel
US5285494A (en) * 1992-07-31 1994-02-08 Pactel Corporation Network management system
US5355474A (en) * 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
US5392220A (en) * 1990-04-13 1995-02-21 U.S. Philips Corporation Method and system for organizing data
US5392390A (en) * 1992-04-10 1995-02-21 Intellilink Corp. Method for mapping, translating, and dynamically reconciling data between disparate computer platforms
US5463772A (en) * 1993-04-23 1995-10-31 Hewlett-Packard Company Transparent peripheral file systems with on-board compression, decompression, and space management
US5537526A (en) * 1993-11-12 1996-07-16 Taugent, Inc. Method and apparatus for processing a display document utilizing a system level document framework
US5553216A (en) * 1993-02-26 1996-09-03 Fujitsu Limited Structured database system together with structure definition frame storing document body data
US5553282A (en) * 1994-12-09 1996-09-03 Taligent, Inc. Software project history database and method of operation
US5572673A (en) * 1993-12-01 1996-11-05 Sybase, Inc. Secure multi-level system for executing stored procedures
US5581686A (en) * 1992-12-01 1996-12-03 Microsoft Corporation Method and system for in-place interaction with contained objects
US5629980A (en) * 1994-11-23 1997-05-13 Xerox Corporation System for controlling the distribution and use of digital works
US5638504A (en) * 1994-03-21 1997-06-10 Object Technology Licensing Corp. System and method of processing documents with document proxies
US5692180A (en) * 1995-01-31 1997-11-25 International Business Machines Corporation Object-oriented cell directory database for a distributed computing environment
US5715403A (en) * 1994-11-23 1998-02-03 Xerox Corporation System for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammar
US5724425A (en) * 1994-06-10 1998-03-03 Sun Microsystems, Inc. Method and apparatus for enhancing software security and distributing software
US5758152A (en) * 1990-12-06 1998-05-26 Prime Arithmetics, Inc. Method and apparatus for the generation and manipulation of data structures
US5761678A (en) * 1996-06-26 1998-06-02 International Business Machines Corporation Creation of clone storage area with identification of base storage area and deferred cloning of metadata
US5765152A (en) * 1995-10-13 1998-06-09 Trustees Of Dartmouth College System and method for managing copyrighted electronic media
US5778385A (en) * 1994-09-21 1998-07-07 Kodak Limited Link manager for managing links integrating data between application programs
US5878421A (en) * 1995-07-17 1999-03-02 Microsoft Corporation Information map
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5910987A (en) * 1995-02-13 1999-06-08 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5913037A (en) * 1996-07-03 1999-06-15 Compaq Computer Corporation Dynamic management information base manager
US5920861A (en) * 1997-02-25 1999-07-06 Intertrust Technologies Corp. Techniques for defining using and manipulating rights management data structures
US5943422A (en) * 1996-08-12 1999-08-24 Intertrust Technologies Corp. Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels
US5982956A (en) * 1995-03-29 1999-11-09 Rank Zerox Secure method for duplicating sensitive documents
US5987471A (en) * 1997-11-13 1999-11-16 Novell, Inc. Sub-foldering system in a directory-service-based launcher
US5991876A (en) * 1996-04-01 1999-11-23 Copyright Clearance Center, Inc. Electronic rights management and authorization system
US5995756A (en) * 1997-02-14 1999-11-30 Inprise Corporation System for internet-based delivery of computer applications
US6006332A (en) * 1996-10-21 1999-12-21 Case Western Reserve University Rights management system for digital media
US6026166A (en) * 1997-10-20 2000-02-15 Cryptoworx Corporation Digitally certifying a user identity and a computer system in combination
US6044205A (en) * 1996-02-29 2000-03-28 Intermind Corporation Communications system for transferring information between memories according to processes transferred with the information
US6061726A (en) * 1997-05-27 2000-05-09 Novell, Inc. Dynamic rights assignment apparatus and method using network directory services
US6122403A (en) * 1995-07-27 2000-09-19 Digimarc Corporation Computer system linked by using information in data objects
US6135646A (en) * 1993-10-22 2000-10-24 Corporation For National Research Initiatives System for uniquely and persistently identifying, managing, and tracking digital objects
US6157721A (en) * 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US7047241B1 (en) * 1995-10-13 2006-05-16 Digimarc Corporation System and methods for managing digital creative works

Family Cites Families (99)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US3609697A (en) 1968-10-21 1971-09-28 Ibm Program security device
US3573747A (en) 1969-02-24 1971-04-06 Institutional Networks Corp Instinet communication system for effectuating the sale or exchange of fungible properties between subscribers
US3845391A (en) 1969-07-08 1974-10-29 Audicom Corp Communication including submerged identification signal
US3798359A (en) 1971-06-30 1974-03-19 Ibm Block cipher cryptographic system
US3798605A (en) 1971-06-30 1974-03-19 Ibm Centralized verification system
US3798360A (en) 1971-06-30 1974-03-19 Ibm Step code ciphering system
US3796830A (en) 1971-11-02 1974-03-12 Ibm Recirculating block cipher cryptographic system
GB1414126A (en) 1971-11-22 1975-11-19 Key Tronic Ltd Secutity for computer systems
US3790700A (en) 1971-12-17 1974-02-05 Hughes Aircraft Co Catv program control system
US3931504A (en) 1972-02-07 1976-01-06 Basic Computing Arts, Inc. Electronic data processing security system and method
US3806874A (en) 1972-04-11 1974-04-23 Gretag Ag Identification system for individuals
US3829833A (en) 1972-10-24 1974-08-13 Information Identification Co Code element identification method and apparatus
US3911397A (en) 1972-10-24 1975-10-07 Information Identification Inc Access control assembly
GB1494736A (en) 1974-01-21 1977-12-14 Chubb Integrated Syst Ltd Token-control
US3924065A (en) 1974-04-05 1975-12-02 Information Identification Inc Coherent, fixed BAUD rate FSK communication method and apparatus
US3946220A (en) 1974-06-10 1976-03-23 Transactron, Inc. Point-of-sale system and apparatus
US3970992A (en) 1974-06-25 1976-07-20 Ibm Corporation Transaction terminal with unlimited range of functions
US3956615A (en) 1974-06-25 1976-05-11 Ibm Corporation Transaction execution system with secure data storage and communications
US3906448A (en) 1974-08-01 1975-09-16 Rca Corp Fault detection facilitating means for card reader of identification card reading system
US4270182A (en) 1974-12-30 1981-05-26 Asija Satya P Automated information input, storage, and retrieval system
US3946200A (en) 1975-02-24 1976-03-23 Gca Corporation Proportional temperature controller
US3958081A (en) 1975-02-24 1976-05-18 International Business Machines Corporation Block cipher system for data security
US4112421A (en) 1975-04-16 1978-09-05 Information Identification Company, Inc. Method and apparatus for automatically monitoring objects
US4217588A (en) 1975-04-16 1980-08-12 Information Identification Company, Inc. Object monitoring method and apparatus
US4209787A (en) 1975-04-16 1980-06-24 Gould Inc. Method for monitoring the location of monitored objects
US4071911A (en) 1975-04-22 1978-01-31 Continental Can Co. Inc. Machine control system with machine serializing and safety circuits
US3996449A (en) 1975-08-25 1976-12-07 International Business Machines Corporation Operating system authenticator
US4196310A (en) 1976-04-09 1980-04-01 Digital Data, Inc. Secure SCA broadcasting system including subscriber actuated portable receiving terminals
JPS533029A (en) 1976-06-30 1978-01-12 Toshiba Corp Electronic computer
US4048619A (en) 1976-09-07 1977-09-13 Digital Data Inc. Secure two channel sca broadcasting system
GB1561482A (en) 1976-11-18 1980-02-20 Ibm Protection of data processing system against unauthorised programmes
US4104721A (en) 1976-12-30 1978-08-01 International Business Machines Corporation Hierarchical security mechanism for dynamically assigning security levels to object programs
US4120030A (en) 1977-03-11 1978-10-10 Kearney & Trecker Corporation Computer software security system
US4162483A (en) 1977-04-01 1979-07-24 Intech Laboratories, Inc. Bilateral master station-plural satellite station signalling apparatus
US4200913A (en) 1977-04-13 1980-04-29 International Business Machines Corporation Operator controlled programmable keyboard apparatus
GB1553027A (en) 1977-05-12 1979-09-19 Marconi Co Ltd Message signal scrambling apparatus
DE2840980C3 (en) 1977-10-08 1982-05-06 Tokyo Electric Co., Ltd., Tokyo Electronic cash register and electronic cash register system
US4168396A (en) 1977-10-31 1979-09-18 Best Robert M Microprocessor for executing enciphered programs
US4278837A (en) 1977-10-31 1981-07-14 Best Robert M Crypto microprocessor for executing enciphered programs
US4405829A (en) 1977-12-14 1983-09-20 Massachusetts Institute Of Technology Cryptographic communications system and method
US4259720A (en) 1978-01-09 1981-03-31 Interbank Card Association Security system for electronic funds transfer system
US4262329A (en) 1978-03-27 1981-04-14 Computation Planning, Inc. Security system for data processing
US4246638A (en) 1978-09-14 1981-01-20 Thomas William J Method and apparatus for controlling usage of a programmable computing machine
US4253157A (en) 1978-09-29 1981-02-24 Alpex Computer Corp. Data access system wherein subscriber terminals gain access to a data bank by telephone lines
US4265371A (en) 1978-10-06 1981-05-05 Trafalgar Industries Inc. Foodstuff vending apparatus employing improved solid-state type control apparatus
US4232317A (en) 1978-11-01 1980-11-04 Freeny Jr Charles C Quantized hyperbolic and inverse hyperbolic object location system
US4305131A (en) 1979-02-05 1981-12-08 Best Robert M Dialog between TV movies and human viewers
FR2448825A1 (en) 1979-02-06 1980-09-05 Telediffusion Fse SYSTEM FOR TRANSMITTING INFORMATION BETWEEN A TRANSMISSION CENTER AND RECEIVING STATIONS, WHICH IS PROVIDED WITH A MEANS OF CONTROLLING ACCESS TO THE INFORMATION TRANSMITTED
FR2448824A1 (en) 1979-02-06 1980-09-05 Telediffusion Fse VIDEOTEX SYSTEM PROVIDED WITH INFORMATION ACCESS CONTROL MEANS
US4598288A (en) 1979-04-16 1986-07-01 Codart, Inc. Apparatus for controlling the reception of transmitted programs
US4236217A (en) 1979-04-20 1980-11-25 Kennedy Stanley P Energy utilization or consumption recording arrangement
US4465901A (en) 1979-06-04 1984-08-14 Best Robert M Crypto microprocessor that executes enciphered programs
US4309569A (en) 1979-09-05 1982-01-05 The Board Of Trustees Of The Leland Stanford Junior University Method of providing digital signatures
US4319079A (en) 1979-09-13 1982-03-09 Best Robert M Crypto microprocessor using block cipher
FR2469760A1 (en) 1979-11-09 1981-05-22 Cii Honeywell Bull METHOD AND SYSTEM FOR IDENTIFYING PEOPLE REQUESTING ACCESS TO CERTAIN MEDIA
US4321672A (en) 1979-11-26 1982-03-23 Braun Edward L Financial data processing system
US4328544A (en) 1980-01-04 1982-05-04 International Business Machines Corporation Electronic point-of-sale system using direct-access storage
US4375579A (en) 1980-01-30 1983-03-01 Wisconsin Alumni Research Foundation Database encryption and decryption circuit and method using subkeys
US4306289A (en) 1980-02-04 1981-12-15 Western Electric Company, Inc. Digital computer having code conversion apparatus for an encrypted program
US4361877A (en) 1980-02-05 1982-11-30 Sangamo Weston, Inc. Billing recorder with non-volatile solid state memory
US4529870A (en) 1980-03-10 1985-07-16 David Chaum Cryptographic identification, financial transaction, and credential device
JPS56140452A (en) 1980-04-01 1981-11-02 Hitachi Ltd Memory protection system
EP0067998B1 (en) 1980-09-26 1986-04-16 Bo LÖFBERG Method for processing an information signal and means for carrying out the method
US4442484A (en) 1980-10-14 1984-04-10 Intel Corporation Microprocessor memory management and protection mechanism
US4513174A (en) 1981-03-19 1985-04-23 Standard Microsystems Corporation Software security method using partial fabrication of proprietary control word decoders and microinstruction memories
US4446519A (en) 1981-05-26 1984-05-01 Corban International, Ltd. Method and apparatus for providing security for computer software
US4578530A (en) 1981-06-26 1986-03-25 Visa U.S.A., Inc. End-to-end encryption system and method of operation
US4433207A (en) 1981-09-10 1984-02-21 Best Robert M Cryptographic decoder for computer programs
US4471163A (en) 1981-10-05 1984-09-11 Donald Thomas C Software protection system
US4593353A (en) 1981-10-26 1986-06-03 Telecommunications Associates, Inc. Software protection method and apparatus
US4442486A (en) 1981-11-25 1984-04-10 U.S. Philips Corporation Protected programmable apparatus
US4454594A (en) 1981-11-25 1984-06-12 U.S. Philips Corporation Method and apparatus to secure proprietary operation of computer equipment
US4553252A (en) 1981-12-21 1985-11-12 Egendorf Harris H Counting computer software cartridge
US4458315A (en) 1982-02-25 1984-07-03 Penta, Inc. Apparatus and method for preventing unauthorized use of computer programs
AU542447B2 (en) 1982-02-27 1985-02-21 Fujitsu Limited System for controlling key storage unit
GB2119992B (en) 1982-05-06 1985-10-30 Tokyo Shibaura Electric Co Automatic transaction machine
US4484217A (en) 1982-05-11 1984-11-20 Telease, Inc. Method and system for remote reporting, particularly for pay television billing
US4494156A (en) 1982-05-14 1985-01-15 Media Systems Technology Selectable format computer disk copier machine
US4525599A (en) 1982-05-21 1985-06-25 General Computer Corporation Software protection methods and apparatus
US4462076A (en) 1982-06-04 1984-07-24 Smith Engineering Video game cartridge recognition and security system
US4523271A (en) 1982-06-22 1985-06-11 Levien Raphael L Software protection method and apparatus
US4590552A (en) 1982-06-30 1986-05-20 Texas Instruments Incorporated Security bit for designating the security status of information stored in a nonvolatile memory
US4462078A (en) 1982-08-02 1984-07-24 Ron Ross Computer program protection method
US4558176A (en) 1982-09-20 1985-12-10 Arnold Mark G Computer systems to inhibit unauthorized copying, unauthorized usage, and automated cracking of protected software
US4562305A (en) 1982-12-22 1985-12-31 International Business Machines Corporation Software cryptographic apparatus and method
US4528643A (en) 1983-01-10 1985-07-09 Fpdc, Inc. System for reproducing information in material objects at a point of sale location
US4588991A (en) 1983-03-07 1986-05-13 Atalla Corporation File access security method and means
US4593376A (en) 1983-04-21 1986-06-03 Volk Larry N System for vending program cartridges which have circuitry for inhibiting program usage after preset time interval expires
US4597058A (en) 1983-05-09 1986-06-24 Romox, Inc. Cartridge programming system
US4573119A (en) 1983-07-11 1986-02-25 Westheimer Thomas O Computer software protection system
US4584641A (en) 1983-08-29 1986-04-22 Paul Guglielmino Copyprotecting system for software protection
US4562306A (en) 1983-09-14 1985-12-31 Chou Wayne W Method and apparatus for protecting computer software utilizing an active coded hardware device
US4558413A (en) 1983-11-21 1985-12-10 Xerox Corporation Software version management system
US4584639A (en) 1983-12-23 1986-04-22 Key Logic, Inc. Computer security system
US4577289A (en) 1983-12-30 1986-03-18 International Business Machines Corporation Hardware key-on-disk system for copy-protecting magnetic storage media
US4609777A (en) 1984-02-22 1986-09-02 Gordian Systems, Inc. Solid state key for controlling access to computer software
US4599489A (en) 1984-02-22 1986-07-08 Gordian Systems, Inc. Solid state key for controlling access to computer software
US4562495A (en) 1984-07-02 1985-12-31 Verbatim Corporation Multiple system disk
US5276901A (en) * 1991-12-16 1994-01-04 International Business Machines Corporation System for controlling group access to objects using group access control folder and group identification as individual user

Patent Citations (46)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4141005A (en) * 1976-11-11 1979-02-20 International Business Machines Corporation Data format converting apparatus for use in a digital data processor
US4881197A (en) * 1987-02-13 1989-11-14 Addison Fischer Document composition system using named formats and named fonts
US4952082A (en) * 1987-05-24 1990-08-28 Brother Kogyo Kabushiki Kaisha Text processing system for cyclically shifting format memory
US5201047A (en) * 1989-12-21 1993-04-06 International Business Machines Corporation Attribute-based classification and retrieval system
US5392220A (en) * 1990-04-13 1995-02-21 U.S. Philips Corporation Method and system for organizing data
US5201046A (en) * 1990-06-22 1993-04-06 Xidak, Inc. Relational database management system and method for storing, retrieving and modifying directed graph data structures
US5758152A (en) * 1990-12-06 1998-05-26 Prime Arithmetics, Inc. Method and apparatus for the generation and manipulation of data structures
US5280479A (en) * 1991-06-18 1994-01-18 Matra Communication Device for insertion of digital packets in a transmission channel
US5355474A (en) * 1991-09-27 1994-10-11 Thuraisngham Bhavani M System for multilevel secure database management using a knowledge base with release-based and other security constraints for query, response and update modification
US5392390A (en) * 1992-04-10 1995-02-21 Intellilink Corp. Method for mapping, translating, and dynamically reconciling data between disparate computer platforms
US5285494A (en) * 1992-07-31 1994-02-08 Pactel Corporation Network management system
US5581686A (en) * 1992-12-01 1996-12-03 Microsoft Corporation Method and system for in-place interaction with contained objects
US5553216A (en) * 1993-02-26 1996-09-03 Fujitsu Limited Structured database system together with structure definition frame storing document body data
US5463772A (en) * 1993-04-23 1995-10-31 Hewlett-Packard Company Transparent peripheral file systems with on-board compression, decompression, and space management
US6135646A (en) * 1993-10-22 2000-10-24 Corporation For National Research Initiatives System for uniquely and persistently identifying, managing, and tracking digital objects
US5537526A (en) * 1993-11-12 1996-07-16 Taugent, Inc. Method and apparatus for processing a display document utilizing a system level document framework
US5572673A (en) * 1993-12-01 1996-11-05 Sybase, Inc. Secure multi-level system for executing stored procedures
US5638504A (en) * 1994-03-21 1997-06-10 Object Technology Licensing Corp. System and method of processing documents with document proxies
US5724425A (en) * 1994-06-10 1998-03-03 Sun Microsystems, Inc. Method and apparatus for enhancing software security and distributing software
US5778385A (en) * 1994-09-21 1998-07-07 Kodak Limited Link manager for managing links integrating data between application programs
US5629980A (en) * 1994-11-23 1997-05-13 Xerox Corporation System for controlling the distribution and use of digital works
US5715403A (en) * 1994-11-23 1998-02-03 Xerox Corporation System for controlling the distribution and use of digital works having attached usage rights where the usage rights are defined by a usage rights grammar
US5553282A (en) * 1994-12-09 1996-09-03 Taligent, Inc. Software project history database and method of operation
US5692180A (en) * 1995-01-31 1997-11-25 International Business Machines Corporation Object-oriented cell directory database for a distributed computing environment
US5982891A (en) * 1995-02-13 1999-11-09 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5910987A (en) * 1995-02-13 1999-06-08 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5915019A (en) * 1995-02-13 1999-06-22 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US5917912A (en) * 1995-02-13 1999-06-29 Intertrust Technologies Corporation System and methods for secure transaction management and electronic rights protection
US5982956A (en) * 1995-03-29 1999-11-09 Rank Zerox Secure method for duplicating sensitive documents
US5878421A (en) * 1995-07-17 1999-03-02 Microsoft Corporation Information map
US6122403A (en) * 1995-07-27 2000-09-19 Digimarc Corporation Computer system linked by using information in data objects
US5765152A (en) * 1995-10-13 1998-06-09 Trustees Of Dartmouth College System and method for managing copyrighted electronic media
US7047241B1 (en) * 1995-10-13 2006-05-16 Digimarc Corporation System and methods for managing digital creative works
US6044205A (en) * 1996-02-29 2000-03-28 Intermind Corporation Communications system for transferring information between memories according to processes transferred with the information
US5991876A (en) * 1996-04-01 1999-11-23 Copyright Clearance Center, Inc. Electronic rights management and authorization system
US5761678A (en) * 1996-06-26 1998-06-02 International Business Machines Corporation Creation of clone storage area with identification of base storage area and deferred cloning of metadata
US5913037A (en) * 1996-07-03 1999-06-15 Compaq Computer Corporation Dynamic management information base manager
US5943422A (en) * 1996-08-12 1999-08-24 Intertrust Technologies Corp. Steganographic techniques for securely delivering electronic digital rights management control information over insecure communication channels
US6157721A (en) * 1996-08-12 2000-12-05 Intertrust Technologies Corp. Systems and methods using cryptography to protect secure computing environments
US5892900A (en) * 1996-08-30 1999-04-06 Intertrust Technologies Corp. Systems and methods for secure transaction management and electronic rights protection
US6006332A (en) * 1996-10-21 1999-12-21 Case Western Reserve University Rights management system for digital media
US5995756A (en) * 1997-02-14 1999-11-30 Inprise Corporation System for internet-based delivery of computer applications
US5920861A (en) * 1997-02-25 1999-07-06 Intertrust Technologies Corp. Techniques for defining using and manipulating rights management data structures
US6061726A (en) * 1997-05-27 2000-05-09 Novell, Inc. Dynamic rights assignment apparatus and method using network directory services
US6026166A (en) * 1997-10-20 2000-02-15 Cryptoworx Corporation Digitally certifying a user identity and a computer system in combination
US5987471A (en) * 1997-11-13 1999-11-16 Novell, Inc. Sub-foldering system in a directory-service-based launcher

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120259769A1 (en) * 2006-12-14 2012-10-11 Robert Cary Maleeny Apparatus, systems, and methods to facilitate the interaction between parties
US9275363B2 (en) * 2006-12-14 2016-03-01 Robert Cary Maleeny Apparatus, systems, and methods to facilitate the interaction between parties
US10943030B2 (en) 2008-12-15 2021-03-09 Ibailbonding.Com Securable independent electronic document
US20120072829A1 (en) * 2009-05-20 2012-03-22 Bgs Crossmedia Sarl System for generating ready-to-print documents
US20160080524A1 (en) * 2014-09-17 2016-03-17 Oracle International Corporation Mobile runtime conditional sections for surveys
US9706013B2 (en) * 2014-09-17 2017-07-11 Oracle International Corporation Mobile runtime conditional sections for surveys
EP3133507A1 (en) 2015-03-31 2017-02-22 Secude AG Context-based data classification
US11032280B1 (en) * 2017-12-13 2021-06-08 Amazon Technologies, Inc. Proxy for controlling access to services

Also Published As

Publication number Publication date
US7062500B1 (en) 2006-06-13
US20080114790A1 (en) 2008-05-15
US20060053158A1 (en) 2006-03-09
US20130055408A1 (en) 2013-02-28

Similar Documents

Publication Publication Date Title
US7062500B1 (en) Techniques for defining, using and manipulating rights management data structures
EP1657618B1 (en) Techniques for defining, using and manipulating rights management data structures
AU2002234254B2 (en) Method and apparatus for managing digital content usage rights
US20090241199A1 (en) Systems and methods for creating, manipulating and processing rights and contract expressions using tokenized templates
AU2002234254A1 (en) Method and apparatus for managing digital content usage rights
WO1997014087A1 (en) System and methods for managing digital creative works
EP1318463A1 (en) Electronic virtual components description import in intranet catalogs
US7660789B2 (en) Entity agent
Gladney et al. Safeguarding digital library contents and users
Borbinha et al. NEDLIB glossary
Evans An architecture for enforcement of usage contracts in distributed multimedia systems.
Subramanian et al. Digital asset management: Concepts and issues

Legal Events

Date Code Title Description
STCB Information on status: application discontinuation

Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION