Patent Publication Number: US-9898715-B2

Title: Systems and methods for creating, manipulating and processing rights and contract expressions using tokenized templates

Description:
RELATED APPLICATION DATA 
     This application claims priority to U.S. provisional application Ser. No. 60/331,619 filed Nov. 20, 2001, Ser. No. 60/331,622 filed Nov. 20, 2001, Ser. No. 60/359,646 filed Feb. 27, 2002, and Ser. No. 60/359,661 filed Feb. 27, 2002, all of which are incorporated herein by reference in their entirety. 
    
    
     COPYRIGHT NOTICE 
     A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. 
     BACKGROUND OF THE INVENTION 
     Field of the Invention 
     The present invention relates generally to a rights expression manipulation system. In particular, the present invention is directed to systems and methods for creating, modifying, parsing, interpreting and validating licenses and/or rights expressions statements using templates which may or may not include tokens. 
     Discussion of the Related Art 
     Electronically distributing resources or content is developing into a lucrative industry. The term “content” is used broadly herein and includes digital works, such as music, audio files, text files, books, reports, video, multimedia, pictures, executable code, or any combination thereof. Controlling access to content is important when distributing them over inherently insecure networks and infrastructures, such as the Internet, although access control may be also desired in other settings. Failure to control resource access can result in unabated intellectual property right infringement and unrealized profits resulting from lost potential sales. Systems have been developed to help reduce these losses thereby enabling content owners to protect and profit from their digital content. Such systems are utilized to specify the usage rights for content or other things and to enforce the usage rights. 
     Various implementations of Rights Management Systems and rights associated with digital content are known as disclosed by U.S. Pat. No. 5,629,980, No. 5,634,012, No. 5,638,443, and No. 5,715,403. Hence, the details of Rights Management Systems are not discussed specifically herein. As evident from these references, a Rights Management system can take many forms, and can employ varying levels of complexity depending on the security required, the nature of the thing being managed, the complexity of associated rights and conditions, volume and other factors. For example, Rights Management systems have been used to enable the secure distribution of digital media content over the Internet. Examples of such systems and associated paradigms are Pay-per-view, Subscription, and Superdistribution, as well as others. A Pay-per-view paradigm may require the user to pay a fee each time content is viewed. A Subscription paradigm may allow subscribers who pay monthly to download a number of songs per month. A Superdistribution paradigm may encourage the free and widespread distribution of digital content, such as audio or video clips, that can only be opened a limited number of times. 
       FIG. 1  illustrates an exemplary rights management (RM) system  100  and the associated workflow that can be used to distribute digital content. Typically, when a user goes through an activation process, information is exchanged between activation server  102  and client application  106 , and is downloaded and installed in client application  106 . Client application  106  serves as a tamper resistant security component and contains the set of public and private keys  104  that are issued by activation server  102  as well as other components such as any necessary engine for parsing or rendering protected content  108 . 
     The RM system  100  also includes a content preparation application  103  that protects clear content  101  through encryption or other protective mechanisms to thereby provide protected content  108 . The content preparation application  103  also specifies usage rights in a rights label  110  that is associated with protected content  108 . The rights label  110  specifies usage rights that are available to an end-user when corresponding conditions are satisfied. A rights expression language (“REL”), such as XrML™, may be used to specify the rights and conditions set forth in the rights label  110 . The rights label  110  and the appropriate encryption key that was used to encrypt the clear content  101  is then provided to the license server  112 . 
     The license server  112  manages the encryption keys and issues license  114  that allows exercise of usage rights. For example, rights label  110  may include usage rights for viewing protected content  108  upon payment of a fee of five dollars, and viewing or printing protected content  108  upon payment of a fee of ten dollars. Client application  106  interprets and enforces the usage rights that have been specified in license  114  to provide clear content  116  that may be used by the end user. 
     The components and modules of the RM system  100  can be located in one or more than one device. For example, the activation server  102  and the license server  112  could be the same server or other device, or plural separate devices. The protected content  108  may be any type of content including a document, image, audio file, video file, etc. Further details of RM systems are set forth in further detail in the references noted above, and consequently, are not discussed specifically herein. 
     Thus, RM systems not only protect content, but also enable content owners to manage the sale and use of their content by means of licenses. Licenses include rights expressions written in a REL for articulating usage rights and to associate usage rights to content. Licenses may be specified for different stages during the life cycle of digital content. For example, when digital content is released to a distributor, licenses may be specified by content owners to limit distribution of the digital content to a particular region or a period of time, or to restrict how content may be repackaged. Of course, licenses themselves must be protected as well since they are a controlling facet determinative of how content is used. In this regard, licenses are typically digitally signed by the issuers so that their integrity and authenticity may be verified before being interpreted. 
     A license typically includes a grant element, a principal element, a right element, a resource element, and optionally, a condition element. In particular, a license contains one or more grant elements which defines the details of the usage rights granted. The one or more grant elements may specify a principal element, a rights element, a resource element and, optionally, a condition element. The principal element identifies a principal, such as a user, or a group of principals who is/are granted the right to access or use the protected resources, while the rights element names a specific right (e.g., play, view, print, execute, copy) to be given to the principal with regards to accessing or using the protected resources. The resource element specifies the protected resources, and the optional condition element specifies any conditions that are imposed on the right to use the protected resource. 
     A license is typically embodied as a rights expression. A rights expression is a syntactically and semantically correct language construct, based on a defined grammar, to convey rights information. As noted, an example of an REL is XrML™. It is important to note that the term “rights expression,” as used herein, should not be limited to licenses in particular, but refers to any expressions that may be used by the RM system to convey information. Thus, the term “rights expression” and derivatives thereof as used herein generally refers to expressions of licenses, license components and/or fragments, such as the grant element, principal element, right element, resource element, and/or condition element described above, as well as any other appropriate expressions. Moreover, rights expressions may be in a variety of different forms ranging from binary encoded sequences that target resource constrained applications to multi-level REL constructs that describe complex rights information for managed distribution of digital resources and rights granting paradigms, and including representations by symbols, objects, colors or other representations that are undetectable by human senses but which can be detected by machines. 
     SUMMARY OF THE INVENTION 
     A first aspect of the invention is a system for manipulating rights expressions for use in connection with a rights management system. The system comprises a license template module that creates one or more license templates, the license templates each having one or more rights expression statements. The rights expression statements each have one or more first tokens associated therewith, at least one of the first tokens being a place holder for one of a plurality of data items. A license instance creation module replaces at least one of the first tokens in one or more selected license templates with one or more of the data items to generate a license instance. A license instance analysis module compares one or more portions of the license instance with one or more of the license templates to find at least one portion of the license instance which corresponds to at least one of the license templates. The license instance analysis module provides a result set indicating whether at least one corresponding license template exists. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a schematic illustration of a Rights Management system. 
         FIG. 2  is a schematic illustration of an item ticket. 
         FIG. 3  is a functional block diagram of an exemplary rights management system of the preferred embodiment. 
         FIG. 4  is a flowchart of a rights expression processing system in accordance with the preferred embodiment of the present invention. 
         FIG. 5  illustrates a keyholder template of an embodiment. 
         FIG. 6  is an illustration of an example of a rights expression in accordance with the preferred embodiment. 
         FIG. 7  is an illustration of an example of a rights expression in accordance with the preferred embodiment. 
         FIG. 8  is an illustration of an example of a rights expression in accordance with the preferred embodiment. 
         FIG. 9  is an illustration of an example of a rights expression in accordance with the preferred embodiment. 
         FIG. 10  is an illustration of an example of a rights expression in accordance with the preferred embodiment. 
         FIG. 11  is an illustration of an example of a rights expression in accordance with the preferred embodiment. 
         FIG. 12  is type hierarchy that shows relationships between rights expression elements. 
         FIG. 13  is a template example in a pseudo rights expression grammar. 
         FIGS. 14A-14I  are template fragment examples in a pseudo rights expression grammar. 
     
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
     Rights Management (“RM”) systems can be applied to digital content and other items, such as services, goods, and the like. For example, rights and conditions can be associated with any physical or non-physical thing, object, class, category, service, or other items for which access, distribution, execution, or other use is to be controlled, restricted, recorded, metered, charged, monitored or otherwise managed in some fashion. Thus, a RM system can be used, for example, to specify and enforce usage rights and condition for any item such as content, service, software program, goods etc. To extend the concept of rights management to tangible items, an item ticket can be used to associate usage rights with the item. A license or other rights expression is associated with the item ticket  200 , illustrated in  FIG. 2 , through a ticket specification that points to or otherwise indicates the item ticket. The item ticket  200  can be protected with some crypto algorithm or other mechanism for preventing processing or rendering of item ticket  200  except in accordance with an associated license. The item ticket  200 , with the security mechanism unlocked, can be a human readable or computer readable coupon, a code, a document, or the like. Accordingly, the phrase “item ticket” refers to any tangible or intangible indication of an item. The item ticket specifies one or more items and thus, usage rights and conditions can be associated with any item including, objects, classes, categories, and services, for which use, access, distribution, or execution is to be controlled, restricted, recorded, metered, charged, monitored, or otherwise managed in some fashion as previously noted. 
     As illustrated in  FIG. 2 , the item ticket  200  can be prepared by specifying an item reference  202  and any post license conditions  204  that restrict redemption of the item ticket  200 . The item ticket  200  can be linked to the item through the item reference  202 . The term “linked” as used herein refers to any type of association, such as a description, a pointer, or the like. For example, the item ticket  200  can include a unique code associated with an item through a database record. When the code is presented to a vendor, the database is searched and the corresponding item can be delivered. Item ticket  200  can also include a human readable description of the item and any post license condition  204  not yet satisfied such as certain location or time the item ticket  200  may be redeemed. Access to the item  200  can be controlled using a license in the manner described above with respect to content. Further details of Rights Management systems utilizing item tickets are disclosed in U.S. application Ser. No. 10/159,272 entitled METHOD AND APPARATUS FOR DISTRIBUTING ENFORCEABLE PROPERTY RIGHTS that was filed on Jun. 3, 2002, the disclosure of which is incorporated herein by reference. 
     Regardless of the details of the item, and whether the item is digital content, an object, a class, a category, a service, or other items, the task of manipulating licenses and/or rights expressions statements associated with the licenses which are written in a rights expression language (“REL”) is complicated and difficult. It is important to note that the term “manipulating” and derivatives thereof as used herein generally refers to creating, modifying, parsing, interpreting and validating licenses and/or rights expressions statements. 
     The flexibility and wide coverage that comprehensive RELs provide for forming licenses, for example, is attained at a cost, namely an increased level of complexity involved in implementing RM systems based on RELs. Additionally, the adoption of RELs has been hindered because of the learning curve and the difficulty involved in interacting with a REL. REL based systems require system administrators to understand the semantics and syntax of the particular REL upon which the system is based. Conventional approaches for the manipulation, validation and/or interpretation of rights expressions written in an REL typically involves the use of an expression processor or parser, such as an XML parser, for example. Such parsers provide tremendous power of generality and flexibility in the manipulation of REL expressions. 
     In particular, typical parsers provide a systematic representation of the rights expressions and often include a mechanism, such as a programmatic interface, which can be utilized by system administrators to interact with the parser to perform data extraction, expression validation and other manipulation functions, such as read, write, and modification of the REL expressions. One of perhaps many problems associated with these parsers is the lack convenience when they are used as a tool for direct manipulation and/or interpretation of rights expressions, which are bounded not only by language syntax but by semantics defining rights information as well. As mentioned above, the system administrators must understand the REL expressions. 
     For example, XrML is an XML-compliant REL. An XML parser is capable of manipulating any well-formed XML expressions, such as XrML rights expressions. But using an XML parser to directly create and modify XrML expressions, for example, is not convenient. Here, the user would need to fully comprehend XrML from both a syntactic and a semantic perspective, and use that knowledge to directly manipulate the expressions at a very granular level (e.g., the element and attribute levels). From an interpretation aspect, a conventional XML parser does not have the capability of extracting the semantics of a rights expression, since it merely provides a programmatic interface to the syntax used in the expressions as noted above. From a validation perspective, although standard parsers usually provide some limited validation mechanisms, they often demand too many system resources to be able to function properly in some operating system environments. 
     Thus, rights expression manipulating systems and methods should preferably enable users to easily create, modify, validate, parse and interpret rights expressions without requiring detailed knowledge of an REL. Further, these systems should be lightweight and be sufficiently robust so that they can operate in a variety of system architectures and environments while minimizing the amount of system resources needed to function. Consequently, it is desirable to provide license templates and/or template fragments for use with rights expression manipulating systems and methods configured to handle these templates, as set forth herein, where the templates includes rights expression statements and optionally further include tokens associated with at least one of the rights expression statements. 
     The manipulation systems and methods of the present invention uses these token-less or tokenized templates to easily create well-formed, valid licenses or license fragments. Where templates are tokenized, the tokens can be placeholders for data of all complexities, from extremely primitive data, like a string or an integer, to extremely complicated rights expression fragments that can be generated using other templates and then passed in as token values into parent templates. Users with little or no knowledge of an REL can easily generate complex rights expressions in seconds without having to worry whether the syntax or semantics are correct. On the developmental side, they greatly reduce the amount of code that needs to be explicitly written to create rights expressions. Additionally, tokenized templates allows for the creation of a generic and lightweight rights expression creation system that can be used to quickly and easily process rights expressions for any business model. 
     Further, these systems and methods can use templates to allow licenses, whether initially created using these templates or not, to be easily modified, validated, parsed and interpreted. It should be appreciated that the systems and methods of the present invention should not be limited to applications in RM systems, but may be implemented in a variety of environments where an authorization policy structure is employed, including Digital Rights Management Systems, B2B and B2C Contract infrastructures, Web Service Access Management Systems, and Software Function and Object Access Management Systems, for example. 
       FIG. 3  shows a functional block diagram of a rights expression manipulation system  300  that enables rights expressions to be easily created, modified, validated, parsed and interpreted without requiring detailed knowledge of an REL. In embodiments of the present invention, the right expression manipulation system  300  is at least capable of processing documents written in a rights expression language, such as an XML based right expression language (e.g., XrML), although the system  300  is capable of processing other types of rights expression languages. 
     It should be initially noted that whereas the illustrated embodiment is referred to herein as a rights expression manipulation system  300 , the present invention may be implemented in any system or device. In this regard, the rights expression manipulation system  300  may be implemented with any type of hardware and software, and may be implemented using a pre-programmed general purpose computing device. For example, the rights expression manipulation system  300  may be implemented using a personal computer, a portable computer, a thin client, a cell phone, a PDA, a vending machine, or any other device or combination of devices. In embodiments where the system  300  is implemented as software functioning on a general purpose computer, a number of programming languages may be used to configure the system  300  to function as described herein, such as C, C++, Pascal, Assembly language, machine language, JAVA, Smalltalk, CLOS, Ada, or Object Pascal. In embodiments where the rights expression system  300  is implemented as a hardware component, the system  300  may comprise circuitry hard-wired or configured to operate in the manner described herein. 
     The rights expression manipulation system  300  and its associated modules, sub-modules, and memory storages, may be implemented on a single device or as a software component at a single location, or multiple devices or software components at a single or multiple locations, which are connected together using any appropriate communication protocols over any communication medium, such as electric cable, fiber optic cable or any other cable, or in a wireless manner using radio frequency, infrared, or other technologies. Where one or more individual modules and/or sub-modules of the system  300  are implemented as software methods, procedures, functions, applets, or separate programs or applications, a number of means or protocols may be utilized for the modules to communicate with each other, the system  300 , and the client  302 , such as Common Object Request Broker Architecture (“CORBA”), Remote Method Invocation (“RMI”) and Simple Object Access Protocol (“SOAP”). 
     It should also be noted that the rights expression processing system  300  in accordance with embodiments of the present invention is illustrated and discussed herein as having a plurality of modules and sub-modules which perform particular functions. These modules and sub-modules are merely schematically illustrated based on their function for exemplary and clarity purposes only, and do not necessarily represent specific hardware or software. As mentioned above, these modules may be hardware and/or software implemented to substantially perform the particular functions explained. Moreover, two or more of these modules may be combined together within the rights expression manipulation system  300 , or divided into additional modules and/or sub-modules based on the particular function or result desired and/or the particular requirements of the environment they reside in. As such, the present invention as embodied in  FIG. 3  should not be construed to limit the rights expression manipulation system  300  of the present invention or its associated modules. 
     In the illustrated embodiment, the rights expression processing system  300  includes a template creation module  400 , a license creation module  500 , a license analysis module  600 , and a data parsing module  900 . Each of these modules and their associated functions will be described in further detail herein below. Also in this embodiment, a client system  302  is connected to the rights expression processing system  300  using any of the techniques described above, and hence the client  302  may communicate with the modules  400 ,  500 ,  600 ,  900 , and any sub-modules thereof, in the manner described and illustrated herein in accordance with embodiments of the present invention. While the rights expression manipulation system  300  and the client system  302  are shown and described herein as being situated in separate locations, it should be appreciated that the client  302  may be an application or module residing and operating within the rights expression system  300  or residing and operating on the same device as the system  300 . 
     An embodiment of the system  300  for creating templates will now be described with reference to  FIG. 3 . In this embodiment, the template creation module  400  is communicatively coupled to a template storage  402 , which stores one or more templates  304 ,  306  created by the module  400 , as described further herein below. The template storage  402  may be logically organized as a relational database that is stored in a memory in the rights expression processing system  300 , although other storage configurations may be utilized. 
     The operation of the system  300  for creating templates will now be described. A user of the rights management system  300 , such as a system administrator, for example, using an interface implemented by the system  300  or in communication therewith, such as a word processing program or a standard text editor, creates a text file representing the content for each of the templates  304 ,  306 , as described herein, although all the templates could be stored together in one combined file or one or more data structures. Once the textual content that constitutes each of the templates  304 ,  306  is completed, the template creation module  400  stores the templates  304 ,  306  in the template storage  402  for further processing as described and illustrated herein in accordance with embodiments of the invention. It should be noted that the templates  304 ,  306 , as described herein, are expressed using textual content for ease of discussion and illustration. As such, it should be appreciated that templates may be expressed in a variety of other formats, such as any computer-readable format (e.g., binary code) or human-readable format (e.g., MS Word™ document). Templates can be created using known techniques, tools, and editors. 
     Tokenized templates  304 ,  306  will now be described in accordance with another embodiment of the present invention, with continued reference to  FIG. 3 . Generally, templates  304 ,  306  are licenses or license fragments (i.e., elements) that optionally include one or more tokens for use in creating and/or enforcing rights expressions, among other things. The templates are created based upon common business models, although they can be mixed, matched and modified as described further here. Moreover, real world examples are provided further herein below for exemplary purposes. When templates  304 ,  306  include one or more tokens, these tokens serve a variety of functions, such as indicating to the rights expression manipulation system  300  that a token should be replaced with information specific to the grants that a user wishes to issue, or indicating to the system  300  where specific values or other tokens should be placed or extracted from, or what values should be ignored during processing (e.g., validation, interpretation, data parsing), all of which will be described further herein below in accordance with embodiments of the invention. 
     Accordingly, one or more types of templates, such as a general token template  304 , and an identifier based token template  306 , are created, although different types and subtypes of tokenized templates are possible as will be evident to one skilled in the computer science and rights management arts upon a review of this disclosure. Moreover, the types of tokens described herein are merely exemplary and are simply intended to convey to an artisan of ordinary skill the flexibility and broad range of configurations that the tokens may embody, and are therefore not intended to be limiting in any way. 
     As such, the general tokenized templates  304  each include one or more general tokens and the identifier based tokenized templates  306  each include one or more identifier based tokens, although again, one or more of the templates  304 ,  306  do not necessarily need to have any tokens. The rights expression manipulation system  300  is configured as appropriate to be able to process each type of template as mentioned above and described in further detail herein. In embodiments of the present invention, the templates  304 ,  306  are written in an XML based rights expression language (e.g., XrML), although a number of other known or later developed XML or non-XML based rights expression languages may be utilized. Moreover, the templates  304 ,  306  are each well-formed XML documents which assist the rights expression manipulation system  300  to process the templates  304 ,  306  as described herein. The different types of tokens mentioned above (i.e., identifier based and general tokens) used in the templates  304 ,  306  will now be described in accordance with embodiments of the present invention, beginning with the general tokens. 
     In this embodiment, a general identifier is used to represent each of one or more tokens within the general tokenized templates  304 . Further, there are one or more subtypes of general tokens, such as an element general token and an attribute general token. The subtypes will be described herein, beginning with the element type general token. Thus, in this embodiment the general tokens within each of the templates  304  appear the same, except as described herein. For example, template  304  may include a token which is denoted as “cgXrML:token.” In this example, the element “&lt;cgXrML:token comment=“A token”/&gt;” within a template  304  serves as an element node placeholder. In embodiments of the invention, the terms “element” and “element node,” and derivatives thereof, are used interchangeably. The existence of “cgXrML:token” indicates that this entire element node (i.e., “&lt;cgXrML:token comment=“A token”/&gt;”) is a token that is subject to substitution or some other operation. Element tokens can be replaced with another element node (e.g., an XML element) or a string, since element tokens can be placeholders for elements and element values as mentioned above. The “comment” attribute can be used to indicate to the rights expression manipulation system  300  the type of value that should replace the token, for example, during license creation. 
     Another subtype of the general tokens described herein that may be included in general tokenized templates  304  are attribute tokens. Attribute tokens included in a template  304  indicate to the rights expression manipulation system  300  that a value should be substituted for the attribute, for example. The value may be substituted for a portion of the attribute&#39;s value or for the entire value. For example, the syntax for an attribute token in a template  304  could be “&lt;namespace:element attribute=“cgXrML:token”/&gt;”. In this example, the token “cgXrML:token” is the only descriptor in the attribute&#39;s string value. The rights expression manipulation system  300  is configured to interpret an occurrence of “cgXrML:token” within an attribute&#39;s string value as being an attribute token. Alternatively, the syntax for an attribute token in a template  304  could be “&lt;namespace:element attribute=“ISBN#cgXrML:token”/&gt;”, where only a portion of the attribute&#39;s string value is desired to be replaced. As can be seen in the alternative example, the attribute token (i.e., cgXrML:token) forms a portion of the entire attribute&#39;s string value, since the “ISBN#” value is present in the string. Thus, during license creation, for example, which will be described in further detail below, the rights expression manipulation system  300  will substitute a value for just the “cgXrML:token” token and will not affect other text, such as the “ISBN#” value, within the attribute&#39;s string value. For example, passing in the value of “1234” for the token during license creation would result in the following: “&lt;namespace:element attribute=“ISBN#1234”/&gt;”. Unlike the element tokens described above, only strings are accepted as values for attribute tokens. 
     An exemplary partial template with general tokens (e.g., element and attribute tokens) is provided below: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;dsig:Reference URI=“cgXrML:token”&gt; 
               
               
                    &lt;dsig:DigestMethod Algorithm=“cgXrML:token”/&gt; 
               
               
                    &lt;dsig:DigestValue&gt; 
               
               
                       &lt;cgXrML:token comment=“Place holder for a value of type 
               
               
                       DigestValueType that represents the DigestValue”/&gt; 
               
               
                    &lt;/dsig:DigestValue&gt; 
               
               
                 &lt;/dsig:Reference&gt; 
               
               
                   
               
            
           
         
       
     
     The first token in the example above, “&lt;dsig:Reference URI=“cgXrML:token”&gt;”, and the second token, “&lt;dsig:DigestMethod Algorithm=“cgXrML:token”/&gt;”, serve as placeholders for attribute values within the string portions of the tokens. Thus, the rights expression manipulation system  300  is configured to replace the first token with the value of a URI attribute and the second token with the value of an Algorithm attribute during license creation, for example. The third token, “cgXrML:token comment=“Place holder for a value of type DigestValueType that represents the DigestValue”/&gt;” is an element token. In this example, the third token serves as a placeholder for the value of the “dsig:DigestValue element.” 
     The general tokens described above (e.g., element and attribute tokens) for inclusion in one or more of the general tokenized templates  304  may be modified to have a token definition for each type of token when multiple types of tokens are desired. As will be discussed further herein below in connection with one or more embodiments of the present invention, in some circumstances it may be desirable to have tokens in a template  304  that should be substituted for actual values or other tokens, and tokens that should be ignored by the rights expression manipulation system  300  when performing certain processes, such as license interpretation or validation. For instance, an element token that should be ignored by the rights expression manipulation system  300  may be defined as “&lt;cgXrML:ignore_token comment=“A token”/&gt;”. An element token that should be substituted for a value or another element by the manipulation system  300  may be defined as “&lt;cgXrML:sub_token comment=“A token”/&gt;”. An attribute token that should be ignored by the rights expression manipulation system  300  may be defined as “&lt;namespace:element attribute=“cgXrML:ignore_token”/&gt;”. And an attribute token that should be substituted for a value by the manipulation system  300  may be defined as “&lt;namespace:element attribute=“cgXrML:sub_token”/&gt;”. 
     A unique identifier can be used to represent each of one or more tokens within the identifier based tokenized templates  306  so that each particular token can be identified by the rights expression manipulation system  300  during processing as described further herein below, although again, templates  306  do not necessarily need to have any tokens. This may help avoid any problems that may be faced by the manipulation system  300  when using the above-described general tokenized templates  304 , such as requiring that an ordered input list containing element or attribute general tokens be provided to the rights expression manipulation system  300 . Further, as in the case of general tokens described above, there are one or more subtypes of identifier based tokens, such as an element and an attribute identifier based token. Each type will be described herein, beginning with the element type identifier based token. 
     The identifier based tokenized template  306  may include a token that is denoted as “&lt;cgXrML:CGTOKEN TOKENNAME=“tokenName” comment=“A token”/&gt;”, which provides element and element value placeholders for the manipulation system  300  to perform particular functions. The “TOKENNAME” attribute is used to indicate a name or an identifier for that particular token. The “comment” attribute is used to indicate to the rights expression manipulation system  300  what should replace the token, such as another token or a value. The existence and positioning of “cgXrML:CGTOKEN” within the token indicates to the system  300  that this entire element node is a token that is subject to substitution for another token or a value during some processing, for example. Again, element tokens can be replaced with an element node (e.g., XML element) or a string, since element tokens can be placeholders for elements and element values. 
     Another subtype of identifier based token that may be included in identifier based tokenized templates  306  are attribute identifier based tokens, which are different from the identifier based element tokens described above. Attribute tokens included in a template  306  indicate to the rights expression manipulation system  300  that a value should be substituted for the attribute. The value may be substituted for a portion of the attribute&#39;s value or for the entire value. For example, the syntax for an identifier based attribute token in a template  306  could be “&lt;namespace:element attribute=“CGTOKEN:tokenName:CGTOKEN”/&gt;”. In this example, the token “CGTOKEN:tokenName:CGTOKEN” is the only descriptor in the attribute&#39;s string value. The rights expression manipulation system  300  can be configured to interpret any occurrence of “CGTOKEN:tokenName:CGTOKEN” within an attribute&#39;s string value as being an attribute token during processing. Alternatively, the syntax for an attribute token in a template  306  could be “&lt;namespace:element attribute=“ISBN# CGTOKEN:tokenName:CGTOKEN”/&gt;”, where only a portion of the attribute&#39;s string value is desired to be replaced. As can be seen, the attribute token forms only a portion of the entire attribute&#39;s string value. Thus, during license creation, for example, which will be described in further detail below, the rights expression manipulation system  300  will substitute a value for just the “CGTOKEN:tokenName:CGTOKEN” token and will not change any other text (i.e., “ISBN#”) within the attribute&#39;s string value. For example, passing in the value of “1234” for the token during license creation would result in the following: “&lt;namespace:element attribute=“ISBN#1234”/&gt;”. Unlike the general element tokens described above, only strings are accepted as values for attribute tokens. 
     An exemplary partial template with identifier based tokens (e.g., element and attribute tokens) is provided below: 
     
       
         
           
               
             
               
                   
               
             
            
               
                 &lt;dsig:Reference URI=″CGTOKEN:URI:CGTOKEN″&gt; 
               
               
                   &lt;dsig:DigestMethod 
               
               
                   Algorithm=″CGTOKEN:Algorithm:CGTOKEN″/&gt; 
               
               
                   &lt;dsig:DigestValue&gt; 
               
               
                     &lt;cgXrML:CGTOKEN TOKENNAME=”DigestValue” 
               
               
                     comment=″Place holder for a value of type DigestValueType 
               
               
                     that represents the DigestValue″/&gt; 
               
               
                   &lt;/dsig:DigestValue&gt; 
               
               
                 &lt;/dsig:Reference&gt; 
               
               
                   
               
            
           
         
       
     
     The first token in the example above, “&lt;dsig:Reference URI=“CGTOKEN:URI:CGTOKEN”&gt;”, and the second token, “&lt;dsig:DigestMethod Algorithm=“CGTOKEN:Algorithm:CGTOKEN”/&gt;”, represent the string version of a token and serve as placeholders for attribute values. Thus, the rights expression manipulation system  300  is configured to replace the first token, as identified by its identifier (i.e., URI), with the value of the URI attribute during license creation, and the second token, as identified by its identifier (i.e., Algorithm), with the value of the Algorithm attribute. The third token, “&lt;cgXrML:CGTOKEN TOKENNAME=“DigestValue” comment=“Place holder for a value of type DigestValueType that represents the DigestValue”/&gt;”, is an element token. In this example, the third token serves as a placeholder for the value of the “dsig:DigestValue element” and can be located by the system  300  using the identifier (i.e., DigestValue). 
     As described above in connection with the general tokens (i.e., element and attribute tokens), the identifier based tokens (i.e., element and attribute tokens) for inclusion in one or more of the identifier based tokenized templates  306  may also be modified to have a definition for each type of token when multiple types of tokens are desired, with identifier attributes identifying each definition. As will be discussed further herein below in connection with one or more embodiments of the present invention, in some circumstances it may be desirable to have tokens in a template  306  that should be substituted for values or other tokens, and tokens that should be ignored by the rights expression manipulation system  300  when performing some processes, such as license interpretation or validation. For example, an element token that should be ignored by the rights expression manipulation system  300  during some processing may be defined as “&lt;cgXrML:CG_IGNORE_TOKEN TOKENNAME=“tokenName” comment=“A token”/&gt;”. An element token that should be substituted for another element or a value by the manipulation system  300  during some processing may be defined as “&lt;cgXrML:CG_SUB_TOKEN TOKENNAME=“tokenName” comment=“A token”/&gt;”. An attribute token that should be ignored by the rights expression manipulation system  300  may be defined as “&lt;namespace:element attribute=“CG_IGNORE_TOKEN:tokenName:CG_IGNORE_TOKEN”/&gt;”. And an attribute token that should be substituted for a value by the manipulation system  300  may be defined as “&lt;namespace:element attribute=“CG_SUB_TOKEN:tokenName:CG_SUB_TOKEN”/&gt;”. 
     In embodiments of the present invention, one or more templates  304 ,  306  which obey the general syntactic and semantic constructs described above are created and stored in the template storage  402 . A user of the client system  302  may desire using these templates for a number of purposes, such as for generating licenses for some resource or service, or for validating, interpreting and/or extracting data from existing licenses. It should be noted that the user at the client  302  does not necessarily need to be the same user that initially creates the templates  304 ,  306  for storage in the template storage  402 , although it could be the same user. In the more common scenario, the user of the client  302  may not understand the syntax and semantics of a rights expression language, such as XrML, and thus will find one or more of the templates  304 ,  306  helpful for performing a particular task, although some knowledge of the particular rights expression language that the templates are written in may be helpful. 
     The templates  304 ,  306  can be used to address both simple and complex business models. If a user has a simple business model, the user can use one or more templates  304 ,  306  that include only those rights expression elements the business model requires. Thus, one is not forced to use the rights expression elements that are not applicable or needed for their particular business model. For example, a video rental business may require a single right, such as “play,” and two conditions, such as a “flat fee” and a “validity time,” so that the video can only be played during the rental period. One or more templates  304 ,  306  may include the appropriate rights expression elements needed to create licenses for this model, which may be selected and used by a user. If a user has a more complex business model, however, the user may need the full power and flexibility that is provided by a rights expression language, such as XrML. For example, a user may need to verify a consumer&#39;s subscription status, check for the most recent version of a document, allow consumers to lend digital works to others, or address a distribution chain of wholesalers, retailers, and consumers, for example. Thus, templates  304 ,  306  can be used to assist in creating licenses, which will be described further herein below. Further, the templates may be used to address both simple and complex business models. 
     Templates  304 ,  306  provide pre-written rights expressions that can be customized to describe common business models. Further, templates  304 ,  306  may be written in a manner that define portions of complete rights expressions or licenses, hereinafter referred to as “fragment templates,” which users can combine in a plurality of combinations as appropriate to build customized business models and/or to add to other templates as token replacements. The templates  304 ,  306  reduce the effort required on the part of users by removing concerns about the rights expression structure and the amount of rights expressions (e.g., XrML) that are needed to be explicitly written. For example, an eBooks distributor may desire implementing a rights managements system using the rights expression manipulation system  300  that allows the distributor to sell protected content (i.e., eBooks). Moreover, the eBook distributor may have a business model in which consumers pay an upfront flat fee of $25.99 to copy, print, view and extract from an eBook, with no further conditions. 
     The distributor, using client  302  for example, may access the rights expression manipulation system  300  to request textual description summaries of one or more templates  304 ,  306  that are available. The client system  302  can receive these summaries from the system and display them on an associated display device for viewing by the distributor. The distributor may then read the summaries to determine which template is appropriate for their business model. For instance, upon viewing the available templates  304 ,  306 , the user may read the following summary provided by system  300  of an “Unlimited Usage” template and conclude that it matches their business model: 
     
       
         
           
               
               
               
             
               
                   
                   
               
             
            
               
                   
                 Template Catagory: 
                 Consumption 
               
               
                   
                 Template Title: 
                 Unlimited Usage 
               
               
                   
                 Template Description: 
                 This tokenized template represents a 
               
               
                   
                   
                 license that grants some customer the 
               
               
                   
                   
                 right to play some book for some fee. 
               
               
                   
                 Tokens for this template: 
                 CustomerId 
               
               
                   
                   
                 BookId 
               
               
                   
                   
                 Price 
               
               
                   
                   
               
            
           
         
       
     
     In this example, the user selects this template and can use it to request the system  300  to create and issue licenses for eBooks, for example. Thus, the system  300  can generate a license, with unlimited play rights to the purchased eBook, for a paying customer. In this example, the “Unlimited Usage” template includes tokens for the customer id, the book id, and the price. Thus, each time a customer visits the distributor&#39;s eBooks Website to purchases an eBook, for example, the customer&#39;s id, the book&#39;s id, and the book&#39;s price along with the “Unlimited Usage” tokenized template can be passed into the system  300  as a method call. In response, the system  300  generates a license based upon the passed in template and values. Thus, the eBook distributor does not need to worry about learning a rights expression language, such as XrML, so that they can form the correct rights expression that semantically models their use case. 
     The system  300  for creating licenses based upon one or more tokenized templates will now be described with reference to  FIGS. 3-10 . The license creation module  500  is communicatively coupled to the template storage  402 . In this embodiment, the license creation module  500  uses one or more tokenized templates to create a license instance  580  ( FIG. 10 ). Further, in this embodiment, one or more of the tokenized templates include one or more general tokens. 
     The operation of the license creation module  500  will now be described. By way of example only, a user of the client  302  may desire accessing the system  300  to create a license based upon the Pay Per Use tokenized template shown in  FIG. 4 . Thus, the client system  302  will be configured to call the appropriate methods to request the rights expression manipulation system  300  to generate one or more licenses and/or license fragments. Moreover, the client system  302  is configured to supply the appropriate information to the rights expression manipulation system  300  through these method calls, as described further herein. Since some tokenized templates (e.g., Pay Per Use template  560  shown in  FIG. 8 ) include tokens which are to be replaced with other tokenized fragment templates (i.e., keyholder template  540 ), the client  302  will be configured to use the module  500  to prepare license fragment instances based on these templates which will be needed to be passed in to the module  500  as each license instance is generated. Further, the client  302  is configured to present the user with one or more graphical user interfaces to elicit information it will need to send to the license creation module  500  based on the one or more templates it is using to create licenses. By way of example only, the client system  302  may use the following method call to request the module  500  to begin creating a license fragment:
         License=CreateXrML(“keyholder.xml”,[modulus, exponent])       

     Referring to  FIGS. 4 and 5 , beginning at step  504 , the client  302  sends a keyholder template  540 , shown in  FIG. 5 , along with an input list that includes two values in this example, a modulus value and an exponent value. The input list may be variables or files. The module  500  performs a “depth first” search to find tokens in the template which need replacing. 
     Thus, at step  508 , the license creation module  500  begins examining the template  540 ( 1 ), and in particular, examining the nodes to determine whether they are tokens (e.g., element or identifier based). The module  500  is configured to look for the “cgXrML:token” syntax. In this example, the module  500  begins by getting the first or root node, the keyholder node  541  in the template  540 , and examining the node. 
     At decision box  512 , if the module  500  determines that the node  541  is a token, then the YES branch is followed. If the module  500  determines that the node  541  is not a token, which in this example it is not, then the NO branch is followed. Further, since the node is not a token, the module  500  stores the entire node contents into a memory storage for example, although it may store the node into a file which will represent the completed license. 
     At decision box  528 , the module  500  proceeds through the template  540  and determines whether there is another node to examine or if an end of file (“EOF”) marker has been reached. If an EOF marker has been reached, the YES branch is followed and the module  500  stores the license at step  532 . If there is another node, then the NO branch is followed. Steps  508 ,  512 ,  528  are performed until either an EOF marker is reached at step  528  or the module  500  determines that the node being examined is a token and the YES branch is followed. In this example, the module  500  examines a node and determines it is a token (i.e., modulus token  542 ) at step  512 , and thus the YES branch is followed. 
     At decision box  516 , the module  500  examines the token  542  to determine which type of token (i.e., element or attribute) it is depending upon the placement of the “cgXrML:token” syntax within the token. In this example, the token  542  is an element token and not an attribute token, and therefore the token  542  is a placeholder for either an another token element or a value, and thus the NO branch is followed. 
     At step  524 , the module  500  gets the next value from input list, the modulus value in this example, and replaces the entire token  542  with the value. Steps  508 ,  512 ,  528  are repeated until the module  500  finds the next token, the exponent token  544  in this example. Thus, steps  516  is repeated. In this example, the token  544  is also an element token, and thus step  524  is repeated, except the next value from the input list in this example (i.e., the exponent value) is substituted for the entire token  544 . 
     If at decision box  516  the module  500  determines that the node contains a token that is an attribute token, then the next value in the input list would have been used to replace the portion of the XML element having the “cgXrML:token” syntax. 
     One or more of steps  508 ,  512 ,  516 ,  520 ,  524 ,  528  are repeated as appropriate until all of the tokens have been replaced with values from the input list, and the EOF marker is reached at step  528 . At step  532  and referring to  FIGS. 4 and 6 , the module  500  stores the license fragment  546  in a memory, and sends the fragment  546  to the client  302 . The client  302  may then store the license in a license memory  1000  for further processing as described herein. As shown in  FIG. 6 , the keyholder license instance fragment  546  is the same as the template  540  ( FIG. 5 ) upon which it was based, except the values  548 ,  550  have been substituted for the tokens  542 ,  544 , respectively. 
     Referring to  FIGS. 7 and 8 , one or more of steps  508 ,  512 ,  516 ,  520 ,  524 ,  528  are repeated as appropriate to create a digital work license fragment  552  and an issuer license fragment  554 , which will be needed by a Pay Per Use template  560  shown in  FIG. 9  during processing as described herein. Further in this example, a print right template (not illustrated) that does not contain any tokens is available, and may be expressed as “&lt;cx:print/&gt;” in this example. 
     By way of example only, the client system  302  may use the following method call to request the module  500  to begin creating a Pay Per Use license instance  560 :
         License=CreateXrML(“PayPerUse.xml”,[input list])
 
The input list in this example would include the following information:
       

     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 1. [&lt;keyHolder&gt; ... &lt;/keyHolder&gt;] 
               
               
                   
                 2. [&lt;cx:print/&gt;] 
               
               
                   
                 3. [&lt;cx:digitalWork&gt;...&lt;/cx:digitalWork&gt;] 
               
               
                   
                 4. [″USD″] 
               
               
                   
                 5. [“2.00”] 
               
               
                   
                 6. [“139371581”] 
               
               
                   
                 7. [“111111”] 
               
               
                   
                 8. [&lt;issuer&gt; ... &lt;/issuer&gt;] 
               
               
                   
                   
               
            
           
         
       
     
     Where a principal element (e.g., keyholder  540 ), a right element (e.g., “&lt;cx:print/&gt;”), a resource element (e.g., digitalwork  552 ), a value for the currency (e.g., “USD”), a value for the rate (e.g., “2.00”), a value for the bank institution (e.g., “139371581”), a value for the bank account (e.g., “111111”) and an issuer element (e.g., issuer  554 ) form the input list. 
     Referring to  FIGS. 4 and 9 , one or more of steps  508 ,  512 ,  516 ,  520 ,  524 ,  528  are repeated as appropriate until all of the tokens have been replaced with values from the input list, and the EOF marker is reached at step  528 . In particular, the module  500  examines the root node  562 , determines it is not a token at decision box  512 , then repeats steps  504 ,  508 ,  512  until it determines at decision box  512  that the principal node  564  includes a token. Steps  516  and  524  are performed to replace the principal node  564  with the keyholder fragment license instance fragment  540  passed in through the input list. Again, one or more of steps  508 ,  512 ,  516 ,  520 ,  524 ,  528  are repeated as described above to replace tokens  566 ,  568 , except at decision box  516 , the YES branch is followed since the module  500  determines that the currency node  570  is an attribute token, and thus step  520  is performed where the module  500  replaces the “cgXrML:token” syntax in the node with the next value from the input list (i.e., “USD”). One or more steps  508 ,  512 ,  516 ,  520 ,  524 ,  528  are again repeated as appropriate to replace the remaining tokens  572 ,  574 ,  576 ,  578  with the next value from the input list, and a pay per use license instance  580  shown in  FIG. 10  is created and stored by the client system  302  in the license storage  1000 . As shown in  FIG. 10 , the pay per use license instance  580  includes the keyholder fragment  582 , digitalwork fragment  586 , currency fragment  588 , institution fragment  590 , account fragment  592 , and issuer fragment  594 . 
     In an embodiment where tokenized templates have identifier based tokens, such as in the identifier based Pay Per Use tokenized template  596  shown in  FIG. 11 , one or more of steps  508 ,  512 ,  516 ,  520 ,  524 ,  528  are performed except as described herein. A template and a hash table having key/value pairs (i.e., token/value pairs) are passed to the module  500  method call. The input list in this example includes the following information: 
     
       
         
           
               
               
             
               
                   
               
             
            
               
                 Principal 
                 [&lt;keyHolder&gt; . . . &lt;/keyHolder&gt;] 
               
               
                 Right 
                 [&lt;cx:print/&gt;] 
               
               
                 Resource 
                 [&lt;cx:digitalWork&gt; . . . &lt;/cx:digitalWork&gt;] 
               
               
                 RateCurrency 
                 [“USD”] 
               
               
                 RateCost 
                 [“2.00”] 
               
               
                 InstitutionRoutingNumber 
                 [“139371581”] 
               
               
                 AccountNumber 
                 [“111111”] 
               
               
                 Issuer 
                 [&lt;issuer&gt; . . . &lt;/issuer&gt;] 
               
               
                 Principal 
                 [&lt;keyHolder&gt; . . . &lt;/keyHolder&gt;] 
               
               
                 Right 
                 [&lt;cx:print/&gt;] 
               
               
                 Resource 
                 [&lt;cx:digitalWork&gt; . . . &lt;/cx:digitalWork&gt;] 
               
               
                 RateCurrency 
                 [“USD”] 
               
               
                 RateCost 
                 [“2.00”] 
               
               
                 InstitutionRoutingNumber 
                 [“139371581”] 
               
               
                 AccountNumber 
                 [“111111”] 
               
               
                 Issuer 
                 [&lt;issuer&gt; . . . &lt;/issuer&gt;] 
               
               
                 Principal 
                 [&lt;keyHolder&gt; . . . &lt;/keyHolder&gt;] 
               
               
                 Right 
                 [&lt;cx:print/&gt;] 
               
               
                 Resource 
                 [&lt;cx:digitalWork&gt; . . . &lt;/cx:digitalWork&gt;] 
               
               
                 RateCurrency 
                 [“USD”] 
               
               
                 RateCost 
                 [“2.00”] 
               
               
                 InstitutionRoutingNumber 
                 [“139371581”] 
               
               
                 AccountNumber 
                 [“111111”] 
               
               
                 Issuer 
                 [&lt;issuer&gt; . . . &lt;/issuer&gt;] 
               
               
                   
               
            
           
         
       
     
     In this embodiment, the module  500  is configured to be able to identify element tokens and attribute tokens within a template as described above. For each of the token elements returned, the module  500  gets the element&#39;s TOKENNAME identifier (e.g., “Principal”, “Right”, Resource”, “RateCost”, etc.), then examines the input list hash table to find the corresponding TOKENNAME identifier in the hash table to get its corresponding value. The module  500  then uses the value associated with the TOKENNAME to replace the token with. For each of the attribute tokens returned, the module  500  gets the element&#39;s TOKENNAME identifier (e.g., “RateCurrency”, etc.), then examines the input list hash table to find the corresponding TOKENNAME identifier in the hash table to get its corresponding value, and step  520  is performed where the module  500  replaces the “CGTOKEN:RateCurrency:CGTOKEN” syntax in the node with the value in the hash table input list corresponding to the “RateCurrency” key (i.e., “USD”). 
     The recited and illustrated order of processing steps set forth above in connection with this embodiment is merely exemplary and is not intended to limit the claimed processes to any order except as may be specified in the claims. Thus, the module  500  very easily accepts one or more templates and a list of values for tokens. A single line of code provided by the client  302 , such as in the example provided above, can be used by the module  500  to automatically generate licenses that are thousands of lines long. One or more steps  508 ,  512 ,  516 ,  520 ,  524 ,  528  are performed as appropriate to replace the remaining tokens  572 ,  574 ,  576 ,  578  with the appropriate values from the input list. 
     Another embodiment of the system  300  for performing data parsing using one or more tokenized templates will now be described with reference to  FIGS. 3, 5 and 6 . The data parsing module  600  is communicatively coupled to the template storage  402 . In this embodiment, the data parsing module  600  uses the keyholder tokenized template  540  in conjunction with the fragment  546  to extract data from the keyholder license fragment  546 , although other templates may be used to extract data from other license instances and/or license instance fragments. Further, in this embodiment, the keyholder tokenized template fragment  540  includes one or more general tokens as mentioned above earlier. 
     By way of example only, the user of the client  302  is configured to send a request to the system  300 , and in particular the data parsing module  600 , to extract data from one or more licenses, such as the keyholder license fragment  546  in this example. For example, the client  302  may be configured to send the following method call to the module  600  for execution in the manner described herein:
         DataOutputList=ParseXrML([“keyholder_A1.lic”,“keyholder.xml”])
 
Here, the “keyholder_A1.lic” value (e.g., variable, file) that is passed in to the module  600  through the method call represents the keyholder license fragment  546  that the client  302  desires to extract data from, and the “keyholder.xml” value represents the keyholder tokenized template  540  that was used to create the license fragment  546 . Alternatively, the client  302  may omit the template  540  value. In such a case, the module  600  may be configured to analyze the templates stored in the template storage  402  in conjunction with the keyholder license fragment  546  to determine whether any templates match the fragment  546 . This analysis process will be described further herein below. Once a matching template is found, the matched template is used to extract the data from the license as described in further detail below.
       

     In particular, in this example, regardless of whether the keyholder tokenized template  540  is provided to the module  600  by the client  302  or the system  300  found the template  540 , the module  600  begins examining each node in the template  540  and the fragment  54  in parallel. For example, the module  600  examines the keyholder node  541  in the keyholder tokenized template  540  to determine whether it is a token. The module also examines the keyholder node  541  in the keyholder license fragment  546 . Since the keyholder license fragment  546  was created using the keyholder tokenized template  540  described above, the nodes should correspond or an error exception will occur. However, in this example they do correspond. 
     Next, the module  600  determines whether the node  541  is a token or a standard rights (e.g., XML) element. In this example, the module  600  determines that the node  541  in the keyholder license fragment  546  is not a token, and thus proceeds to examine the next node in the keyholder tokenized template  540 . In this example, the module  600  examines the next node, the “&lt;info&gt;” node, and the nodes thereafter, and determines that none of these nodes are tokens. Again, as the module proceeds to examine each node in the keyholder tokenized template  540  it is examining the corresponding node in the keyholder license fragment  546 . Finally, in this example, the module  600  examines a node in the keyholder tokenized template  540  and determines that it is a modulus token  542 . The module  600  at this point then extracts the data from the keyholder license fragment  546  at the location that corresponds to the location of the token  542  that was found. In this example, the module  600  extracts the modulus value  548  from the keyholder license fragment  546 , and stores the value in a temporary memory, for example. The module then repeats the same steps described above and continues to examine each node in the keyholder tokenized template  540  and the keyholder license fragment  546  in parallel until another token is found, in this example exponent token  544 . As described above with respect to the modulus token  542 , the module  600  extracts the exponent value  550  from the keyholder license fragment  546 , and stores the value in a temporary, for example. Once all of data has been extracted, such as when the module  600  detects an EOF marker, the values stored in the temporary memory are sent to the client system  302 . 
     The same process described above may be used to extract data from the pay per use license instance  580  shown in  FIG. 10  using the pay per use tokenized template  560  shown in  FIG. 9 . Thus, the client  302  may make the following method call:
         DataOutputList=ParseXrML([“pay_per_use_A1.lic”,“pay_per_use.xml”])
 
Here, the “pay_per_use_A1.lic” value (e.g., variable, file) that is passed in to the module  600  through the method call represents the pay per use license instance  580  that the client  302  desires to extract data from, and the “pay_per_use.xml” value represents the pay per use tokenized template  560  that was used to create the license fragment  546 .
       

     The same steps described above with respect to extracting data from the keyholder license fragment  546  are performed to extract data from the pay per use license instance  580 . In this example, the tokens in the tokenized template  560  correspond to license fragments which were placed in the license instance  580  as described above. For example, when the module  600  examines the principle node  564  in the pay per use tokenized template  560  and determines it is a token, it examines the corresponding node in the license instance  580 , and finds the “&lt;keyholder&gt;” tag in the keyholder region  582 . Thus, the module is configured to continue reading the data in that region  582  until it encounters a tag which instructs it to stop reading data from that region, such as the “&lt;/keyholder&gt;” tag in this example. In this example, the module  600  provides the client  302  with an output list that includes the following information: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 1. [&lt;keyHolder&gt; ... &lt;/keyHolder&gt;] 
               
               
                   
                 2. [&lt;cx:print/&gt;] 
               
               
                   
                 3. [&lt;cx:digitalWork&gt;...&lt;/cx:digitalWork&gt;] 
               
               
                   
                 4. [″USD″] 
               
               
                   
                 5. [“2.00”] 
               
               
                   
                 6. [“139371581”] 
               
               
                   
                 7. [“111111”] 
               
               
                   
                 8. [&lt;issuer&gt; ... &lt;/issuer&gt;] 
               
               
                   
                   
               
            
           
         
       
     
     In an embodiment where tokenized templates have identifier based tokens, such as in the identifier based Pay Per Use tokenized template  596  shown in  FIG. 11 , the same process described above for extracting data from license instances or license instance fragments can be applied to extract data from license instances, such as the pay per use license instance  580 , or license instance fragments, such as the keyholder license fragment  546 , using identifier based tokenized templates. For instance, in the case of the pay per use license instance  580 , the client  302  makes the method call for execution by the module  600 , but here the client  302  passes the pay per use identifier based tokenized template  596  into the call along with the license instance  580 . 
     In this embodiment, the module  600  is configured to be able to identify element tokens and attribute tokens within a template as described above. For each of the token elements returned, the module  500  gets the element&#39;s TOKENNAME identifier (e.g., “Principal”, “Right”, Resource”, “RateCost”, etc.), then extracts the data from the corresponding location in the license instance. For each of the attribute tokens returned, the module  500  gets the element&#39;s TOKENNAME identifier (e.g., “RateCurrency”, etc.), then extracts the data from the corresponding location in the license instance. 
     Thus in this example, the module  600  extracts the corresponding data from the regions  582 ,  584 ,  586 ,  588 ,  590 ,  592 ,  594  in the license instance  580 . As each portion of data is extracted from each region, the module  600  stores the corresponding TOKENNAME from the token at the corresponding location in the tokenized template  560 . Once all of the data has been extracted from the license instance  580 , the module  600  sends an output list that includes the following information: 
                                    Principal   [&lt;keyHolder&gt; . . . &lt;/keyHolder&gt;]       Right   [&lt;cx:print/&gt;]       Resource   [&lt;cx:digitalWork&gt; . . . &lt;/cx:digitalWork&gt;]       RateCurrency   [“USD”]       RateCost   [“2.00”]       InstitutionRoutingNumber   [“139371581”]       AccountNumber   [“111111”]       Issuer   [&lt;issuer&gt; . . . &lt;/issuer&gt;]                    
In the first column, the TOKENNAME associated with the data is provided, and in the second column the data or the rights expression element (e.g., XML) from the license instance  580  corresponding to the token in the pay per use tokenized template  560  is provided.
 
     Another embodiment of the system  300  for analyzing license instances or license fragment instances using one or more tokenized templates will now be described with reference to  FIGS. 3 and 12-14I . The license analysis module  700  is communicatively coupled to the template storage  402 , and further includes a validation sub-module  800  and an interpretation sub-module  900 . In this embodiment, the license analysis module  700  handles requests from a client system  302 , for example, to validate and/or interpret one or more license instances and/or license instance fragments. The license analysis module sends these requests to the sub-modules  800 ,  900  as appropriate. 
     An embodiment of the system  300  for validating licenses using a validation sub-module  800  will now be described. Referring to  FIG. 12 , a schematic illustration of a type hierarchy, such as a set of inheritance trees, which defines relationships between rights expression elements in the exemplary template shown in  FIG. 13  and the exemplary template fragments  14 A- 14 I. Thus, in this example, KeyHolder and PassportUser elements ( FIGS. 14A, 14B ) are principals; Play, Print, and Save ( FIGS. 14C, 14D, 14E ) are rights; DigitalResource and WebService ( FIGS. 14F, 14G ), and Grant (not illustrated), are resources; and FlatFee and ValidityInterval are conditions ( FIGS. 14I, 14J ). The system  300 , and hence the validation sub-module  800 , are configured to understand these relationships. Moreover, this exemplary hierarchy is stored in a memory in the system  300 . 
     By way of example only, the client system  302  may pass the following method call to the system  300 :
         valid_license=validate([“model_template”,“example_license.lic”])
 
The license analysis module  700  in turn passes the method call to the validation sub-module  800  for execution thereof as described herein. The “model_template” value represents a template (e.g.,  FIG. 13 ) that the client system  302  desires the validation sub-module  800  to use during validation. Alternatively, the client  302  does not need to provide a model template. In this case, the sub-module is configured to perform the validation process described herein using one or more model templates that may be available in template storage  402 . Moreover, once all the elements in the license instance are found to be of the allowable types according to the type hierarchy set forth in  FIG. 12 , then the sub-module  800  determines that the license instance is valid. The “example_license.lic” is a license which a user of the client system  302  desires validating. In this example, the “example_license.lic” license instance that a user of the client  302  desires validating may be expressed using pseudo code in the following manner:
       

     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 License 
               
               
                   
                    Grant 
               
               
                   
                       KeyHolder 
               
               
                   
                          Mai&#39;s Keys 
               
               
                   
                       End KeyHolder 
               
               
                   
                       Play 
               
               
                   
                       End Play 
               
               
                   
                       DigitalResource 
               
               
                   
                    www.edgar.com/docs/XrMLTechTalk.pdf 
               
               
                   
                       End DigitalResource 
               
               
                   
                       FlatFee 
               
               
                   
                          $10 
               
               
                   
                       End FlatFee 
               
               
                   
                    End Grant 
               
               
                   
                    Issuer 
               
               
                   
                       Edgar&#39;s signature 
               
               
                   
                    End Issuer 
               
               
                   
                 End License 
               
               
                   
                   
               
            
           
         
       
     
     Referring to  FIG. 13 , an exemplary model license template expressed using pseudo code is illustrated. In this example, it is assumed that this model template is a valid rights expression that is written in any rights expression language, such as XrML. Further,  FIGS. 14A-14I  illustrate fragment templates that are also valid rights expression elements and are written in any rights expression language, such as XrML. It should be noted that there may be a fewer or greater number of fragment templates other than those illustrated in  FIGS. 14A-14I . The model template shown in  FIG. 13  includes one or more types of tokens, such as a first type of token (i.e., IGNORE_TOKEN) that indicates to the validation sub-module  800  that the associated data should be ignored. A second type of token (i.e., SUBSTITUTE_TOKEN) indicates to the sub-module  800  that the token is a placeholder for another template of a particular type (e.g., principal, right, resource, etc.) as defined in the exemplary hierarchy illustrated in  FIG. 12 . 
     Accordingly, in this embodiment, the validation process begins by the validation sub-module  800  matching elements in the “example_license.lic” license instance with all the combinations of syntax that could be formed by template substitutions as dictated by the type hierarchy illustrated in  FIG. 13 . The sub-module  800  is configured to examine each element in the model template in parallel with each element in the “example_license.lic” license instance. When non-token elements, such as “License” and “Grant”, are encountered in the model template, the sub-module  800  determines whether the associated element in the corresponding location within the license instance is the same. If the corresponding element is not the same, then the sub-module  800  may return a value to the client  302  indicating that the license instance is not valid. Alternatively, the sub-module can be configured to focus on determining whether just the elements associated with the tokens in the model template are the same as the elements in the license instance. Moreover, the sub-module  800  may be configured to ignore variations in character spacing and/or the use of lower or upper case, for example. 
     As the sub-module  800  examines each element in the model template and the license instance, when tokens are encountered in the model template, the sub-module  800  is configured to determine whether the token is an IGNORE_TOKEN or a SUBSTITUTE_TOKEN. If the token is an IGNORE_TOKEN type, then the sub-module  800  ignores any data that is inside of the rights expression or element at that location in the license instance, and compares the elements to determine whether they are the same or match. If the token is a SUBSTITUTE_TOKEN type, then the sub-module  800  will examine the corresponding element in the license instance to determine whether the element is one of the types defined in the hierarchy illustrated in  FIG. 12 . For example, the first token in the model template shown in  FIG. 13  allows the sub-module to substitute any element from the license instance at the corresponding location that is of a type principal. Referring to the type hierarchy in  FIG. 12  and the fragment templates shown in  FIGS. 14A-14I , a KeyHolder template ( FIG. 14A ) or a PassportUser template ( FIG. 14B ) may be substituted. For the next token, any element that is of a type right could be substituted, such as Play ( FIG. 14C ), Print ( FIG. 14D ), or Save template ( FIG. 14E ), and so forth, for each subsequent token in the example model template illustrated in  FIG. 13 . The sub-module compares each element in the license instance with each of the template fragments of the particular type for the token to find a match, while ignoring any data associated with an element in the license instance that corresponds to an IGNORE_TOKEN token in the model template. 
     Referring back to the exemplary “example_license.lic” license instance provided above, the sub-module  800  determines that each of the elements in the instance that correspond to the tokens in the model template are of the same type according to the hierarchy shown in  FIG. 12 . For example, the license instance includes the KeyHolder, Play, DigitalResource and FlatFee elements, which are all defined as being valid element types (e.g., Principle, Right, Resource, Condition) in  FIG. 12 . Accordingly, the sub-module sends a value to the client  302  to indicate that the license instance is valid. Further, the elements in the license instance are in the same position as in the model template, although the sub-module  800  may be configured to ignore the positions of the elements in the license instance. For example, when the module  800  examines the “SUBSTITUTE_TOKEN (principle)” token, it can be configured to search the license instance for any element that is of a type Principle, rather than require an exact match with respect to the position of the token within the license instance. 
     While the sub-module is matching elements in the model template with corresponding elements in the license instance, it stores the matching elements from the model templates together in a memory or as a separate file. Further, an example of the combined template which is produced from merging all of the matching templates that were found to correspond to the elements in the license instance is shown below: 
                                            License           Grant              KeyHolder                IGNORE_TOKEN (keys)                 End KeyHolder                 Play                 End Play                 DigitalResource                IGNORE_TOKEN (URL)                 End DigitalResource                 FlatFee                IGNORE_TOKEN (rate)                 End FlatFee           End Grant           Issuer              IGNORE_TOKEN (signature)           End Issuer              End License                        
This combined template may be useful to the user of client  302  for a number of reasons, such as where the license instance was not generated by the system  300  using one or more tokenized templates and the user desires having a valid, well formed tokenized template to use for easily generating additional license templates. Tokenized templates can be used to validate and/or determine support for the structure or syntax of rights expressions. The validation sub-component  800  is a lightweight validation component that does not require an undue amount of system resources. To add new knowledge to the system  300 , and hence the validation sub-component  800 , the user can simply register additional template(s). This could be as simple as placing the new template(s) within a specific location/directory within the system  300 , such as the templates storage  402 , providing excellent lower end scalability. Devices that require small footprints can easily operate the system  300 , and hence the validation sub-module  800 .
 
     An alternative embodiment of the validation sub-module  800  will now be described. In this embodiment, a model template, such as the template illustrated in  FIG. 13 , would include complete sets of rights expressions rather than tokens (e.g., SUBSTITUTE_TOKEN) that indicate which tokenized fragment templates can be used to compare the license instance elements with. Thus, in this embodiment, the model template would be the same as the model template shown in  FIG. 13 , except that the SUBSTITUTE_TOKEN tokens would be replaced by the actual rights expression elements. The validation process would then involve comparing the elements in the model template(s) with the corresponding elements in the license instance to determine whether they match. If no match is found after comparing the rights expression instance against the model template(s), the validation sub-module  800  sends a value to the client  302  indicating that the license instance is invalid. 
     The recited order of processing steps set forth in connection with the above-described embodiments is not intended to limit the claimed processes to any order except as may be specified in the claims. 
     Another embodiment of the system  300  for interpreting licenses using an interpretation sub-module  900  will now be described with reference to  FIGS. 3 and 14A-14I . By way of example only, a user may desire interpreting the meaning of license instances or license fragment instances, such as licenses  606 . By way of example only, the client system  302  may pass the following method call to the system  300 :
         license_interpretation=interpret([“example_license.lic”])
 
The license analysis module  700  passes the method call to the interpretation sub-module  900  for execution thereof as described herein. The client  302  may optionally pass tokenized templates into the method call that it may want the interpretation sub-module  900  to use during interpretation, although the sub-module  900  may access templates stored in the template storage  402 .
       

     In this embodiment, the interpretation sub-module  900  performs the same process as the validation sub-module  800  to find tokenized templates or tokenized template fragments which match one or more license instances or license fragment instances, except in this embodiment the sub-module  900  stores the names of the files containing the matching template(s). Referring back to the exemplary “example_license.lic” license instance provided above, the sub-module  900  determines that each of the elements in the instance that correspond to the tokens in the model template are of the same type according to the hierarchy shown in  FIG. 12 . For example, the exemplary license instance includes the KeyHolder, Play, DigitalResource and FlatFee elements, which are all defined as being valid element types (e.g., Principle, Right, Resource, Condition) in  FIG. 12 . Accordingly, these elements match the templates shown in  FIGS. 14A, 14B, 14F, 14H . Thus, the sub-module  900  stores the file names of these templates. Further, in this embodiment the sub-module  900  maintains a database in a memory of the system  300  that includes semantic mappings between templates and human-readable descriptions. Thus, as templates are matched, they may be cross-referenced with this database to determine the appropriate meanings of the matched template(s). An exemplary table showing one or more matched templates and their associated meanings is provided below: 
     
       
         
           
               
               
             
               
                   
               
               
                 Template File Name 
                 Description 
               
               
                   
               
             
            
               
                 PayPerView.tem 
                 TOKEN(person) can view TOKEN(book) for 
               
               
                   
                 TOKEN(price). 
               
               
                 ExerciseLimit.tem 
                 TOKEN(person) can play TOKEN(book) only 
               
               
                   
                 TOKEN(exerciseCount) times. 
               
               
                 DistributionRights.tem 
                 TOKEN(distributor) can sell any book 
               
               
                   
                 published by TOKEN(publisher). 
               
               
                 Lending.tem 
                 TOKEN(person) can lend TOKEN(book) to 
               
               
                   
                 any of his friends. 
               
               
                 EmployeeCertificate.tem 
                 TOKEN(person) is a ContentGuard employee. 
               
               
                   
               
            
           
         
       
     
     The interpretation sub-module  900  sends this information to the client  302 . The client  302  is configured to provide this information to a user using a graphical user interface, for example. Thus, the client  302  may be configured to display human-readable descriptions of the templates that match a license instance. User can use this information for a variety of reasons, such as for easily interpreting the meaning of created license instances without requiring users to analyze the rights expression language the license is written in. 
     In an alternative embodiment, the sub-module  900  maintains a database in a memory of the system  300  that includes semantic mappings between templates and method calls. Thus, as templates are matched, they may be cross-referenced with this database to determine the appropriate method call for the matched template(s). In this embodiment, the method calls represent the action that should be performed by the system  300  when the associated template is matched. Thus, this embodiment of the present invention allows the system  300  to map the semantics of a license instance or license instance fragment to semantics expressed via APIs (e.g., methods/functions). An exemplary table showing one or more matched templates and their associated method calls is provided below: 
     
       
         
           
               
               
             
               
                   
               
               
                 Template File Name 
                 Method To Call 
               
               
                   
               
             
            
               
                 PayPerView.tem 
                 PayPerView(TOKEN(person), 
               
               
                   
                 TOKEN(book), 
               
               
                   
                 TOKEN(price)) 
               
               
                 ExerciseLimit.tem 
                 ExerciseLimit(TOKEN(person), 
               
               
                   
                 TOKEN(book), 
               
               
                   
                 TOKEN(exerciseCount)) 
               
               
                 DistributionRights.tem 
                 DistributionRights(TOKEN(distributor), 
               
               
                   
                 TOKEN(publisher)) 
               
               
                 Lending.tem 
                 Lending(TOKEN(person), 
               
               
                   
                 TOKEN(book), 
               
               
                   
                 FLAG_ANYONE) 
               
               
                 EmployeeCertificate.tem 
                 EmployeeCertificate(TOKEN(person), 
               
               
                   
                 “ContentGuard”) 
               
               
                   
               
            
           
         
       
     
     The recited order of processing steps set forth in connection with the above-described embodiments is not intended to limit the claimed processes to any order except as may be specified in the claims. 
     In view of the discussion above, it should now be apparent that the rights expression processing system in accordance with one embodiment of the present invention provides a novel and advantageous system that may be used to manipulate grammar based rights expression, such as for generating, modifying, and validating grammar based rights expressions. 
     While various embodiments in accordance with the present invention have been shown and described, it is understood that the invention is not limited thereto. The present invention may be changed, modified and further applied by those skilled in the art. Therefore, this invention is not limited to the detail shown and described previously, but also includes all such changes and modifications as defined by the appended claims and legal equivalents.