Patent Application
20060225055
1. Field of the Invention
The present invention generally relates to processing of grammar-based expressions, such as rights expressions, and the like, and more particularly to a method, system, and device for optimizing processing of expressions, including indexing of expressions, such as rights expressions, and the like.
2. Discussion of the Background
Declarative Meta languages have been promoted heavily in the information technology industry since the early 1990s by industry leaders such as Microsoft, IBM, and Sun Microsystems. Since that time, an increasing number of systems and applications have adopted the use of Meta languages. One such Meta language, XML, has become the de facto standard.
By themselves, Meta languages typically do not carry machine-interpretable semantics. However, there has been a great industry demand for machine-interpretable semantics to automate business transactions and facilitate interoperability across devices, platforms, and systems. Driven by this demand, enterprises and industry standard groups have developed rights expression grammars to overlay a Meta language. Such grammars capture the semantics of rights expressions. Analogous to the relationship between a clause and the grammar in a natural language, a rights expression can be a specific clause based on and compliant with the rights expression grammar.
Exemplary rights expression grammars can include eXtensible rights Markup Language (XrML), MPEG Rights Expression Language (REL) (MPEG REL), Open Digital Rights Language (ODRL), Open Mobile Alliance (OMA) REL (OMA REL), Content Reference Forum Contract Expression Language (CRF CEL), OASIS eXtensible Access Control Markup Language (XACML), OASIS Security Assertion Markup Language (SAML), and the like. Exemplary rights expressions can include XrML licenses that govern the use of Microsoft RMS-enabled Office documents, XML licenses that govern the use of Digital Rights Management (DRM) enabled Windows Media content, SAML assertions in Web Services applications, CEL-based electronic contracts (eContracts) for CRF-targeted business scenarios, and the like.
Rights expressions can be used in a wide variety of systems and applications, including agreements between business entities, permissions granted by rights holders to distributors and consumers, policies and rules governing computer system behaviors, digital identification, digital certificate, a token that asserts an entity's identity and attributes, a token that asserts an entity's privileges in a government or enterprise security environment, and the like. Exemplary objectives of rights expressions include facilitating human-to-machine and machine-to-machine communications, enabling precise and unambiguous machine interpretation, and the like. However, the syntax and semantics of rights expression grammars are not always designed for optimal real-time processing efficiency, as transformation of an original rights expression format into a machine-internal representation often may be required.
In addition, digital signatures often are imposed on rights expressions to authenticate the integrity of the rights expressions. For privacy protection, rights expressions may be further protected by cryptographic means, such as by encryption techniques, and the like. To mitigate size, bandwidth, or other constraints, rights expression may be encoded in different formats. For example, a rights expression may be encoded in a binary format to reduce the size of the rights expression in a mobile communication environment. However, transformations, digital signatures, security protection, encoding, and other potential formatting can introduce undesirable overhead with respect to the processing of rights expressions.
As grammar-based rights expressions become the prevalent means for communicating and enforcing rights terms on machine-interpreted and/or enforced transactions, many systems and applications may need to process large volumes of rights expressions efficiently. For example, a consumer's personal computer may contain thousands of licenses, each of which governs the use of one specific digital work or a group of digital works. In another example, a rights clearing center may manage and process millions of electronic licenses and contracts in response to frequent queries. In a further example, a large retailer may implement an automated contract issuance and management system that stores contractual agreements (e.g., expressed in a contract expression language) between the retailer and hundreds or thousands of suppliers. However, such an application would undesirably require a gigantic database of digital contracts.
In addition, a rights expression management system may need to satisfy a fixed response-time requirement. For example, the rights expression management system may need to deliver rights expressions in the form of authorization tokens, and the like, for viewing of streaming video on consumption devices in fixed interval, such as every second, and the like. However, such an application could be undesirably hindered when trying to process large volumes of rights expressions.
Further, in a rights expression processing system, rights expressions may be stored sequentially in a persistent repository and captured in an original Meta language syntax. The rights expressions may be binary encoded, digitally signed, security protected, formatted by other means, and the like. Triggered by a processing request, the rights expression processing system would process the rights expressions in a linear fashion, typically including the following steps.
A processing step can include selecting rights expressions relevant to a processing request. The processing request typically encompasses specific context. For example, a request might impose the query, “does music distributor X have the permission from record company Y to sell its content in territory Z”. In this case, “X”, “Y”, “Z”, and “sell” can be used as filters to select the relevant rights expressions. In other words, such a processing request is interested in the rights expressions that satisfy the noted filtering criteria. Depending on the type of processing request, the system may need to find the first rights expression that matches the query, a subset of rights expressions that match the query or all rights expressions that match the query.
A processing step can include validating rights expressions, wherein set of matching rights expressions from the selecting step are validated and verified. The validating step can include reversing a binary encoding process, decrypting, verifying a digital signature to confirm integrity, validating the syntax of rights expressions against a grammar, and the like.
A processing step can include interpreting rights expressions, including extracting the semantic meaning from rights expressions to construct information used for a response to a processing request. The interpreting also step may involve retrieving and processing other related rights expressions, if any, needed for the response. For example, a usage right may only be granted if the principal possesses another (pre-requisite) right. In this case, the system must search for and verify that the principal does possess the required pre-requisite right before granting the usage right.
A processing step can include responding to a processing request. For example, after the above processing steps have been completed, the responding step can include determining if conditions, obligations, and the like, associated with rights expressions have been satisfied in order to respond to the processing request.
However, the above-noted processing steps can be computing resource and processing intensive, especially when dealing with rights expressions that are complicated, lengthy, dependant on other rights expressions, and the like. Accordingly, without a systematic method to organize and manage high volumes of rights expressions, it can be very difficult, and in some instances impossible, to respond to query, event, authorization, other processing requests, and the like, in a timely manner. Thus, methods and systems for processing rights expressions typically are not practical or efficient, when managing thousands or even millions of rights expressions.
Therefore, there is a need for a method, system, and device that addresses the above and other problems with Digital Rights Management (DRM) systems, and methods. The above and other needs are addressed by the exemplary embodiments of the present invention, which provide a method, system, and device for processing of expressions, including rights expressions. The exemplary embodiments include indexing of expressions, including rights expressions, so that, when given a processing request, expressions with no potential of satisfying the processing request are eliminated from the search space before the expression processing begins. During the processing of a request and subsequent chaining requests (e.g., additional requests resulting from dependencies among expressions), the expression processor processes only expressions with the potential of satisfying the processing request. Advantageously, such processing greatly reduces the number of relevant expressions that need to be processed in association with the processing request and, among other things, leads to reduced response time. The indexing can be based on semantic and/or syntactic values of the expressions being processed. The process of analyzing and organizing expressions so that prospective expressions can be quickly queried and retrieved later is part of an exemplary expression index maintenance process that can be performed independently of a real-time request evaluation process (e.g., during an expression storage sub-process, through a batch process, and the like). Advantageously, the overhead processing time for the exemplary expression index maintenance process can be excluded from the processing time of evaluating a request. In addition, the exemplary embodiments can be used to process numerous types of expressions, including rights expressions, and the like.
Accordingly, in exemplary aspects of the present invention, a method, system, and device for indexing expressions for use in a system for processing the expressions are provided, and including indexing an expression using a semantic value; receiving a query; generating a list of prospective expressions from indexed expressions based on the query; and processing the prospective expressions.
Still other aspects, features, and advantages of the present invention are readily apparent from the following detailed description, simply by illustrating a number of exemplary embodiments and implementations, including the best mode contemplated for carrying out the present invention. The present invention also is capable of other and different embodiments, and its several details can be modified in various respects, all without departing from the spirit and scope of the present invention. Accordingly, the drawings and descriptions are to be regarded as illustrative in nature, and not as restrictive.
The embodiments of the present invention are illustrated by way of example, and not by way of limitation, in the figures of the accompanying drawings, in which like reference numerals refer to similar elements, and in which:
An improved method, system, and device for optimizing processing of expressions, including indexing of expressions, such as rights expressions, and the like, are described. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the exemplary embodiments of the present invention. It is apparent to one skilled in the art, however, that the present invention can be practiced without these specific details or with an equivalent arrangement. In some instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
The exemplary embodiments generally include indexing of expressions, for example, based on semantic and/or syntactic values of the expressions. The exemplary embodiments can include an Expression Index Engine that indexes expressions, including rights expressions, and generates a list of prospective expressions based on a query.
Referring now to the drawings, wherein like reference numerals designate identical or corresponding parts throughout the several views, and more particularly to
Accordingly, the Rights Expression Processor 102 receives the processing request 110. The Rights Expression Processor 102 processes the processing request 110 by selecting expressions relevant to the processing request 110, validating the expressions, evaluating the expressions, and responding to the processing request 110. To retrieve the expressions relevant to the processing request 110, the Rights Expression Processor 102 issues a repository request 112 to an Expression Repository 104.
The Expression Repository 104 stores and retrieves expressions. Upon receiving the repository request 112, the Expression Repository 104 converts the repository request 112 to an index query 116 for use in invoking the Expression Index Engine 106.
The Expression Index Engine 106 analyzes an indexed collection of expressions and retrieves a set of expressions that satisfy the index query 116. The set of expressions is returned to the Expression Repository 104 as a query result 118. The Expression Repository 104 returns the query result 118 to the Rights Expression Processor 102 as a set of prospective expressions 114 with the potential to satisfy the processing request 110. The Rights Expression Processor 102 then performs additional processing on the prospective expressions 114 to identify matching expressions 108 that satisfy the processing request 110.
Advantageously, the Expression Index Engine 106 and components thereof can be used in connection with any suitable form of expression. In an exemplary embodiment, the Expression Index Engine 106 is used in connection with rights expressions, and in which case can be referred to as a Rights Expression Index Engine. The other exemplary components are similarly described using interchangeable language, such as the Expression Repository 104 and Rights Expression Repository, Expression Processor and the Rights Expression Processor 102, and the like.
The exemplary embodiments describe an abstract model by defining concepts, terminologies, methods, and the like, associated with indexing expressions, including rights expressions, and querying indexed expressions. Such an abstract model serves as a reference on which various exemplary systems for indexing rights expressions, querying indexed rights expressions, and the like, for a variety of rights expression languages can be implemented.
In an exemplary embodiment, an evaluation unit can be an expression element that represents some logical grouping of other expression elements. One example of an evaluation unit in the domain of rights expressions is an authorization unit. An authorization unit is a rights expression element that represents a logical grouping of rights expression elements that allows some identity or entity to exercise some right or action on some resource. For example, in the MPEG REL, an authorization unit can be expressed using a grant element. Similarly, in ODRL, for example, an authorization unit can be expressed using an agreement element. Other grammar based rights expression languages also have similar logical representation. Each rights expression element can have a type associated with therewith. Each rights expression element also can represent some semantic meanings that are specific to the rights expression language in which the rights expression is expressed.
In an exemplary embodiment, a dimensional element can be an expression element of an evaluation unit that is being used to compute an indexed value. The evaluation unit can be independently indexed by one or more dimensional elements based on values and types of the dimensional elements. The selection of dimensional elements can be based on the anticipated processing request 110, such that dimensional elements have corresponding input parameters with the processing request 110. When the indexed values of the dimensional elements within an evaluation unit match the indexed values of the input parameters of the processing request 110, the evaluation unit has the potential to satisfy the processing request 110.
In its simplest form, an evaluation unit can include a single dimensional element. In this case, the dimensional element is the evaluation unit and vice versa.
The exemplary embodiments include an exemplary expression indexing method defined in terms of an authorization unit as an example. However, the exemplary expression indexing method can be applied more generally to any suitable evaluation unit, and the term authorization unit and evaluation unit can be used interchangeably.
Many rights expression languages have their own optimized methods for representing the information stored in the expressions. For example, as in the MPEG REL, grants with the same principal can be grouped together into a grant group so that the principal need not be declared repeatedly in each grant. Similarly, as in ODRL, agreement expressions can inherit permissions and constraints from another expression. Such optimization reduces the number of expressions employed to represent the required statements.
Before an authorization unit can be indexed, the authorization unit can be processed so as to be self-contained. In an exemplary embodiment, such processing can include determining expressions that are semantically associated with the authorization unit, but are syntactically defined outside of the authorization unit, and then distributing the determined expressions into the authorization unit so that the authorization unit is made to be self-contained. A general mechanism for such processing is further described in U.S. patent application Ser. No. ______ (Attorney Docket No. 111325-510100) of Thanh T A, et al., filed on Aug. 17, 2004, entitled “METHOD AND SYSTEM FOR PROCESSING GRAMMAR-BASED LEGALITY EXPRESSIONS,” and incorporated by reference herein.
In an exemplary embodiment, a rights expression element can be specified, for example, as a static expression, which has an actual, static value explicitly specified within the element or as a variable expression, which references a variable definition with zero or more constraints. A static value that satisfies the constraints can be bound to the variable expression.
In an exemplary embodiment, a primary index key value of a dimensional element can include a hash value computed from the type and value of the dimensional element or a hash value computed from the type of the dimensional element and a unique value assigned to the dimensional element, and the like. Authorization units including a particular dimensional element with the same primary index key value can be collected into the same collection indexed by such primary index key value. The use of the assigned unique value can be employed when the actual value of the dimensional element cannot be determined at the time of indexing, such as when the value for a variable expression can not be assessed. Such assigned unique value can be termed a unique potential match value. Exemplarily methods of determining the primary index key value of a dimensional element and arranging authorization units into collections are described below.
For example, for each dimensional element, authorization units that include variable expressions for the corresponding dimensional element can be collected into one potential match collection indexed by the hash value computed from the type value of the dimensional element and the unique potential match value. Since a variable expression serves as a place holder for some static values and the binding of a static value to a variable expression is not determined until the interpretation process, the unique potential match value can be used.
Furthermore, a rights expression language can define the presence of an expression element to be optional. Consequently, a dimensional element within an authorization unit can be left unspecified. For each dimensional element, authorization units that do not have the corresponding dimensional element also are collected into the potential match collection indexed by the hash value computed from the type value of the dimensional element and the unique potential match value. In this case, the unique potential match value is used because a static value can not be determined for an unspecified dimensional element and the semantic of an unspecified element is not clearly defined at the time of indexing. An unspecified element may have the semantic of allowing any suitable expression element to match, allowing no expression element to match or defining an error if the expression element is actually required, but not specified by mistake. Authorization units belonging to the potential match collection qualify as potential matches to an index query.
Several expression elements may appear syntactically different, but may represent the same semantic meaning. For example, a person being identified by social security number 123-45-6789 can be syntactically expressed differently using the following expressions:
In this example, the grammatical structure for the person element requires only that the ssn element be present. The name and licenseNumber elements are optional elements, and there is no fixed ordering among such elements. Accordingly, an optional element can include an expression element that is not required to be specified explicitly according to the grammatical structure of an expression language.
The syntactic value of an expression element can be based strictly on the static string value (commonly referred to as the static value) of the expression element. For example, the syntactic value for the exemplary Expression 1 can be the following string:
When indexing a dimensional element based on a syntactic value of the dimensional element, the hash value computed from a static value of the dimensional element and the element type of the dimensional element represent a primary index key value of the dimensional element. For each dimensional element, authorization units that include the dimensional element with the same static value are collected into the same set indexed by the type and value of the dimensional element.
The semantic value of an expression element can be a static value determined by applying some transformation rules so that related expression elements having different syntactic values, but representing the same semantic meaning, have the same static value. The determined static value based on semantic meaning is called the seed syntactic value.
The criteria for determining a seed syntactic value depend on the context of an element. One way to determine the seed syntactic value is to remove optional elements and attributes. Also, when an instance of a dimensional element includes multiple children elements and the position of the children elements is not semantically significant and can vary, the children elements can be rearranged into a default, fixed position, before calculating the seed syntactic value. Alternatively, an exemplary system can include a semantic-specific plug-in architecture, where each plug-in has specific knowledge of the semantic context of an element to determine the appropriate seed syntactic value. Such alternatives are just some of many possible exemplary embodiments of methods that can be used to determine the seed syntactic value when indexing a dimensional element based on the semantic value of the dimensional element.
Using the exemplary embodiments to represent a person being identified by the social security number 123-45-6789 by removing optional elements to determine the seed syntactic value yields the following seed syntactic value for which a primary index key value can be computed.
When indexing a dimensional element based on a semantic value of the dimensional element, authorization units that include the same dimensional element type with the same semantic value, but possibly different syntactic values, can be collected into the same collection indexed by the hash value computed from the type value of the dimensional element and a seed syntactic value as the primary index key value.
For an index query 116 relating to an authorization request, the expected query result 118 is a collection of prospective authorization units that have potential to match the authorization request. Such collection of prospective authorization units can be determined by the intersection of collections of authorization units for all dimensional elements denoted as ∩(M(d1), M(d2), . . . M(dn)). However, the intersection operation can be substituted with other suitable mathematical operations as applicable to the processing request, such as union of collections of authorization units for all dimensional elements, collections of authorization units with at least N number of matching dimensional elements, collections of authorization units that statistically exceed a certain percentage of inclusion in previous query results, collections of authorization units that statistically exceeds a certain percentage of uses, other suitable operations or combinations thereof, and the like. For each dimensional element Di, M(di) is the collection of all authorization units that include rights expression elements corresponding to the dimensional element type of Di, with element values that semantically and syntactically match or potentially match the type and value of di, where di is an input element from the processing request 110 that corresponds to the dimensional element Di.
Authorization units that include rights expression elements corresponding to the dimensional element Di whose indexed value matches the indexed value computed from the element type and value of di, are considered matches with di and are placed into the M(di) collection. In addition, authorization units that include rights expression elements corresponding to the dimensional element Di whose indexed value matches the indexed value computed from the element type of di and the unique potential match value, are considered potential matches with di and also are placed into the M(di) collection. In effect, for each dimensional element Di, such exemplary steps eliminate authorization units that do not match the input element di. The next step involves determining the intersected collection by extracting only those authorization units that are present in all of the M(d1), M(d2), . . . M(dn) collections. This further eliminates authorization units that do not match the input elements d1, d2 . . . dn.
To ensure that the index collections are up to date, the collections need to be re-indexed when a rights expression is modified, added to or removed from a rights expression repository. For example, when an authorization unit is removed from the rights expression repository, the primary index key value for each dimensional element within the affected authorization unit is recalculated. The collections including the authorization unit are retrieved using the calculated primary index key value for each dimensional element. Then, the authorization unit is removed from the collections. When an authorization unit is modified, the original authorization unit is removed from the collection. Then, the modified authorization unit is added back to the collection using the previously defined process. In general, updating and removing authorization units need to maintain referential integrity between the primary index key value and the collections including the authorization units.
The process of analyzing and organizing expressions, and ensuring that the index collections are up to date so that prospective expressions can be quickly queried and retrieved later is called an expression index maintenance process. Since an expression index maintenance process is typically performed independently (e.g., at different times) from the request authorization process, the processing time for expression index maintenance can be excluded from the authorization processing time. Not having to perform expression index maintenance as a part of an authorization process, advantageously, can reduce the time and resources required for the authorization process. Authorization process efficiency is desirable, since authorization is typically a real-time process.
The exemplary embodiments include the components of the Expression Index Engine 106 and the interactions of the components with each other and with input data.
In
A Dimensional Element Value Handler 208 can determine the syntactic or semantic value of a dimensional element. If the Expression Index Engine 106 is implemented to index authorization units based on syntactic value, the value of the dimensional element is the static value of the rights expression. If the Expression Index Engine 106 is configured to index authorization units based on semantic value, the Dimensional Element Value Handler 208 calculates the seed syntactic value of the dimensional element and uses the seed syntactic value as the value of the dimensional element.
Semantic Extension Plug-Ins 214-216 are associated with a particular dimensional element type and have specific knowledge of how to compute the seed syntactic value appropriately, such as according to the grammar. The Dimensional Element Value Handler 208 can delegate the task of calculating the seed syntactic value to one of the Semantic Extension Plug-Ins 214-126. The Dimensional Element Value Handler 208 can have one or more registered Semantic Extension Plug-Ins 214-216. Once a Semantic Extension Plug-Ins has calculated the seed syntactic value, the Dimensional Element Value Handler 208 can compute a hash value based on the type information and the seed syntactic value of the dimensional element. The hash value is the primary index key value used in indexing collection of authorization units.
An Index Collection Manager 210 manages the indexed collections of authorization units by providing updating the collection using the hash value as the primary index key value. The indexed collections can include repository references to the authorization units, rather than the actual authorization units themselves. The Index Collection Manager 210 also provides query functionality to retrieve a collection of authorization units given the hash value as the primary index key value.
A Prospective Query Handler 212 retrieves the collection of authorization units that potentially match with the processing request. The Prospective Query Handler 212 can have one or more registered Query Handler Plug-Ins 218-220 to specifically determine the collection of potential matched evaluation units as applicable to the processing request. For example, the Intersection Query Handler Plug-In 218 retrieves the collection of authorization units associated with each dimensional element that is part of an authorization request, and then determines the collection of authorization units that represents the intersection of the retrieved collections. Further exemplary embodiments, can include zero or more of the described components, depending on a given implementation.
At step S304, the Rights Expression Repository 104 records the licenses in a storage mechanism and invokes the Index Maintenance Component 202 to add rights expressions to the index collection. At step S306, the Index Maintenance Component 202 invokes the Evaluation Unit Preprocessor 206 for each authorization unit to ensure that the authorization unit is self-contained.
At step S308, the Index Maintenance Component 202 invokes the Dimensional Element Value Handler 208 for each dimensional element within the self-contained authorization unit to determine the hash value computed from the type information and value of the dimensional element. At step S310, the Dimensional Element Value Handler 208 can employ a Semantic Extension Plug-In 214 to determine the seed syntactic value of the dimensional element.
At step S312, the Index Maintenance Component 202 uses the hash value as primary index key value and invokes the Index Collection Manager 210 to add a reference to the authorization unit to the indexed collection. Further exemplary embodiments, can include zero or more of the described steps, depending on a given implementation.
At step S406, the Rights Expression Repository 104 issues a query to retrieve prospective authorization units. To form the query, the Rights Expression Repository 104 uses the input parameters from the authorization request that correspond to the dimensional elements of the authorization unit. At step S408, the Index Query Component 204 invokes the Dimensional Element Value Handler 208 for each dimension element in the query to determine the hash value computed from type information and value of the dimensional element.
At step S410, the Dimensional Element Value Handler 208 can employ a Semantic Extension Plug-In 214 to determine the seed syntactic value of the dimensional element. At step S412, the Index Query Component 204 invokes the Prospective Query Handler 212 to determine the collection of authorization units that potentially match with the processing request. At step S414, the Prospective Query Handler 212 can employ an Intersection Query Handler Plug-In 218 to retrieve the intersected collection based on the hash values.
At step S416, the Intersection Query Handler Plug-In 212 invokes the Index Collection Manager 210 for each hash value computed from the dimensional element to retrieve the collection of authorization units with the hash value as the primary index key value. Then, the Intersection Query Handler Plug-In 212 can determine the intersected collection by extracting authorization units that are present in all of the collections of authorization units retrieved from the Index Collection Manager 210. Further exemplary embodiments, can include zero or more of the described steps, depending on a given implementation.
The exemplary embodiments are applicable to expressions conveyed in any suitable manner, including any suitable rights expression language. For example, the rights expressions can be expressed in the MPEG REL. In the MPEG REL, an authorization unit is represented as a grant element. Within a grant element, the indexing is based on the semantic value of dimensional elements D1=Principal, D2=Rights, and D3=Resource.
As an illustration of the exemplary indexing process, given the pseudo MPEG REL licenses in Table 1, the Expression Index Engine 106 indexes the rights expressions based on their semantic values, such that the primary index key values and their associated collections of grants are as shown in Table 2.
To uniquely identify an authorization unit, Table 1 uses a convention of concatenating the labels that lead to the authorization unit or grant. For example, L1.Gg1.G2 represents the second grant of first grantGroup within the first license, which is the grant that allows John to play “Let's Rock CD.” In Table 2, each row represents an instance of a dimensional element being indexed and the corresponding authorization units. For example, in the first row of Table 2 both L1.Gg1.G1 and L1.Gg1.G2 include the Principal element type with keyHolder John. For brevity, the short form “keyHolder John” is used instead of the entire keyHolder element related to John. Note that even though the syntactic value of keyHolder John in L1.Gg1.G1 is different from L1.Gg1.G2 due to the different ordering of the KeyName and RSAKeyValue elements, their semantic values are the same.
For an index query, the Expression Index Engine 106 retrieves the intersection of grants for Principal=D1, Rights=D2, and Resource=D3, denoted as ∩(M(d1), M(d2), M(d3)). For example, given an interpretation request “can John Copy Let's Rock CD” and the index table depicted in Table 2, d1 equals a static value of the principal dimensional element D1, d2 equals a static value of the rights dimensional element D2, and d3 equals a static value of the resource dimensional element D3. The Expression Index Engine 106 retrieves the ∩(M(d1=John), M(d2=Copy), M(d3=Let's Rock CD)), as follows:
M(d1=John)=L1.Gg1.G1, L1.Gg1.G2, L3.G1, L4.G1
M(d2=Copy)=L1.Gg1.G1, L2.G1, L4.G1
M(d3=Let's Rock CD)=L1.Gg1.G1, L1.Gg1.G2, L3.G1, L2.G1, L4.G1
Consequently, the Rights Expression Processor 102 need only process the processing request 110 against the prospective rights expressions L1.Gg1.G1 and L4.G1, instead of processing L1.Gg1.G1, L2.G1, L3.G1, and L4. G1. However, the prerequisiteRights element in L1.Gg1.G1 causes a chain request of “can John Own Let's Rock CD.” In this case, the Expression Index Engine 106 retrieves the ∩(M(d1=John), M(d2=Own), M(d3=Let's Rock CD)), as follows:
M(d1=John)=L1.Gg1.G1, L1.Gg1.G2, L3.G1, L4.G1
M(d2=Own)=L3.G1, L4.G1
M(d3=Let's Rock CD)=L1.Gg1.G1, L1.Gg1.G2, L3.G1, L2.G1, L4.G1
∩(M(d1=John), M(d2=Own), M(d3=Let's Rock CD))=L3.G1, L4.G1
Consequently, the Rights Expression Processor 102 need only process the processing request 110 against the prospective rights expressions L3.G1 and L4.G1, instead of processing L1.Gg1.G1, L1.Gg1.G2, L2.G1, L3.G1, and L4.G1.
Using such an indexing scheme, advantageously, only rights expressions that have the potential to match the processing request 110 need be processed against the processing request 110 by the Rights Expression Processor 102.
The above-described devices and subsystems of the exemplary embodiments of
One or more interface mechanisms can be used with the exemplary embodiments of
It is to be understood that the devices and subsystems of the exemplary embodiments of
To implement such variations as well as other variations, a single computer system can be programmed to perform the special purpose functions of one or more of the devices and subsystems of the exemplary embodiments of
The devices and subsystems of the exemplary embodiments of
All or a portion of the devices and subsystems of the exemplary embodiments of
Stored on any one or on a combination of computer readable media, the exemplary embodiments of the present invention can include software for controlling the devices and subsystems of the exemplary embodiments of
As stated above, the devices and subsystems of the exemplary embodiments of
While the present invention have been described in connection with a number of exemplary embodiments and implementations, the present invention is not so limited but rather covers various modifications and equivalent arrangements, which fall within the purview of the appended claims.
