WO2002039225A2

WO2002039225A2 - Methods for rule driven requirements process for rights enabled systems

Info

Publication number: WO2002039225A2
Application number: PCT/US2001/046820
Authority: WO
Inventors: Miles A. Cato; Teresa L. Dorr; Robert Thomas P. Neri; Robert P. Weber
Original assignee: Aspsecure Corporation
Priority date: 2000-11-07
Filing date: 2001-11-07
Publication date: 2002-05-16
Also published as: WO2002039225A3

Abstract

A method for building a digital rights management system is disclosed, comprising the steps of: (i) specifying rule types for controlling and manipulating digital information for transporting said information among two or more persons; (ii) specifying a rendering program for controlling and manipulating said message in accordance with said rules; (iii) specifying a support application for securing and transporting said message; and (iv) specifying a packager for packing said message for transport by said support application.

Description

Specification

METHODS FOR RULE DRIVEN REQUIREMENTS PROCESS FOR RIGHTS ENABLED

SYSTEMS

PRIORITY CLAIM

This application claims priority to a provisional application entitled "Rule Driven Requirements Process for Rights Enabled Systems" filed on November 7, 2000, having an application number 60/246,379.

BACKGROUND OF THE INVENTION

Field of the Invention

The present invention generally relates to methods for building digital rights management systems, and, in particular, methods for building digital rights management system for transporting electronic messages.

Description of the Prior Art

In developing digital rights management (DRM) software applications it is important to gather DRM product definitions, in order to provide for successful product delivery, product deployment, and product operations.

A DRM technology system protects content on a persistent basis throughout its commercial lifecycle. It does this by binding rules governing content use with governed content. A DRM system creates a zone — independent of time, place, or device — where digital content is governed by technology and where rights-holders, including enterprise and government, are free to exchange and protect their content through the freedom to establish differing rules reflecting their individual and institutional interests.

Within this technical protection zone, digital information such as contracts, records, forms, and documentation can be exchanged and governed via a virtually limitless range of rules. This freedom is also available for the implementation of a richly diverse range of policies that govern usage, and any consequences of usage, in relation to groups of any nature, such as government, enterprise, or even special interest groups. For example, to accommodate statutory limitations on copyright, special consumption rules can be created, either through law or through accepted practice of rightsholders, for particular consumers or classes of users: for schools and universities; for libraries and archival institutions; and for consumers with special needs such as the blind. More specifically, referring to Fig. 1 and Fig 2 a scenario illustrating a present DRM system development methodology is detailed Here, the first step provides the means to develop a product definition. This step involves vision creation and definition. This details how the DRM product will evolve from concept to detailed requirements and how the DRM product is to be built and how it will operate over time The second step provides for product development and details the steps needed to build a DRM product based on detailed specifications This also includes the comprehensive testmg steps, certification process, interaction with various value-chain participants, and packaging for deployment. The third step provides for product deployment and details the steps required to deploy and install a DRM product at the client site, including product supporting software registration and activation, training and operational turnover This does not necessarily include the digital information rendering software, which is to be deployed to the end-user sites The fourth and final step provides for product operations and details the how the operational group deals with deployment of the rendering software to the consumer sites, the consumer registration and activation, the development and packaging of digital mformation, digital information access, use and support This also includes the processing of resulting operational transactions and the disbursements of gathered usage information and financials, including payment authoπzation and processmg

SUMMARY OF THE INVENTION

It is therefore an object of the present invention to provide methods for building a digital πghts management system

Briefly, in a presently preferred embodiments of the present invention, a method for building a digital πghts management system, comprising the steps of: (i) specifying rule types for controlling and manipulating digital information for transporting said information among two or more persons, (n) specifying a rendeπng program for controlling and manipulating said message m accordance with said rules, (in) specifying a support application for secuπng and transporting said message; and (iv) specifying a packager for packing said message for transport by said support application

An advantage of the present invention is that it provides methods for building a digital rights management system

The product process flow depicts the processes that TrustData Solutions follow in delivering digital rights management (DRM) solutions to its clients In this document, each of the processes is detailed to the extent necessary for the reader to achieve a basic understanding of the TrustData Solutions Methodology™

The methodology described herein is applicable to any rules-based digital rights management ("DRM") technologies, and/or any electronic commerce technologies that entails the application of plural rules to at least one electronic commerce transaction, non-hmitmg examples of which mclude DRM technologies disclosed in US Patents to Stefik and/or Stefik et al. (see below), US patents issued to Ginter et al., to Shear, et al, and/or to Hall et al. (see below) and also includes commercially announced and or available products with at least some DRM capabilities from Adobe, Microsoft, ContentGuard, SoftLock, MediaDNA, I terTrust Technologies Corporation, IBM, and/or any other providers of rules-based digital rights management technologies and/or technologies that associate and/or attach rules with digital information and have means of enforcing said associated rules. The methodology described here may also be compatible with applications based on and/or interacting with software and/or hardware instantiations of the Common Security Data Architecture, its APIs and services, as described, for example, in Common Security: CDSA and CSSM, Version 2 (with corrigenda) ISBN: 1-85812-202-7, Document Number C914, UK: The Open Group, May 2000, presently available at: http://www.opengroup.Org/pubs/catalog/c914.htm#medium3 which is incorporated herein by reference. The methodology described herein may also be applicable to entities providing clearinghouse, TCB administration and other DRM-related data center services, including, but not limited to Reciprocal, Inc. Magex, Massive Media, Mecurix, Fasoo, Preview Systems, and others offering DRM-enabled clearinghouse services. Our currently preferred embodiment is the digital rights management software platform products from InterTrust Technologies Corporation and/or the subject matter of patents assigned to InterTrust, including U.S. Pat. No. 5,982,891 issued to Ginter et al.; U.S. Pat. No. 5,949,876 issued to Ginter et al.; U.S. Pat. No. 5,920,861 issued to Hall et al.; U.S. Pat. No. 5,917,912 issued to Ginter et al.; U.S. Pat. No. 5,915,019 issued to Ginter et al.; U.S. Pat. No. 5,910,987 issued to Ginter et al.; U.S. Pat. No. 5,892,900 to Ginter et al.; and IPO Publication WO9,810,381 Al to Shear et al.; which are incorporated herein by reference. Other DRM-related patents include without limitation US Pat. No. 5,715,403 issued to Stefik on 2/03/1998; US Pat. No. 5,638,443 issued to Stefik et al. on 6/10/1997; US Pat. No. 5,634,012 issued to Stefik et al. on 5/27/1997; US Pat. No. 5,629,980 issued to Stefik et al. on 5/13/1997; US Pat. No. 5,845,281 issued to Benson et al. on 12/1/1998, which are incorporated herein by reference. The processes described herein may be used regardless of the language, syntax, and/or semantics used for rule expression.

These and other features and advantages of the present invention will become well understood upon examining the figures and reading the following detailed description of the invention.

IN THE DRAWINGS Fig. 1 illustrates the first portion of a process flow chart for building a digital rights management application;

Fig. 2 illustrates the second portion of a process flow chart for building a digital rights management application;

Fig. 3 illustrates the sub-processes in the product scooping step; Fig. 4a illustrates the Rights Approach in the Requirement Definition sub-process;

Fig. 4b illustrates the User-Interface Approach in the Requirement Definition sub-process; and

Fig. 4c illustrates the Combined Approach in the Requirement Definition sub-process.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

In a presently preferred embodiments of the present invention, the product process flow illustrated in Figs. 1 and 2 divided into 4 groups. The first group is Product Definition. This group involves vision creation and definition. This division details how the product evolves from concept to detailed requirements on how the product is to be built and how it will operate over time. The Product Development group details the steps in developing the product based on detailed specifications. This also includes the comprehensive testing steps, certification process with InterTrust Technologies, interaction with various value-chain participants, and packaging for deployment. The Product Deployment group discusses the steps required to deploy and install the product at the client site, including product supporting software registration and activation, training and operational turnover. This does not necessarily include the digital information rendering software, which is to be deployed to the end-user sites. The Product Operations group deals with deployment of the rendering software to the consumer sites, the consumer registration and activation, the development and packaging of digital information, digital information access, use and support. This also includes the processing of resulting operational transactions and the disbursements of gathered usage information and financials, including payment authorization and processing. Each step of the groups is described in detail below. The heading paragraph provides the name of

Process Step, the Involved Parties and a reference to the figures.

Product Definition Group

Process Step/Involved Parties/Reference: Conceptualize Product; Client & TrustData Solutions (optionally); Fig. 1 at 10.

This process involves assessing the need for DRM solutions to resolve or enable businesses to thrive in a digital commerce environment, non-limiting examples of which include business-to-consumer, business- to-business, govemment-to-government, government-to-consumer, and government-to-business. This is typically initiated through a sales process whereby TrustData Solutions' prospects are educated in DRM and related electronic commerce processes and/or applications, and its potential impact on the prospects' business and revenue models.

Process Step/Involved Parties/Reference: Product Scoping; Client & TrustData Solutions: Fig. 1 at 12. This process details the vision of the DRM solution in the form of one or more products and services. This vision is scoped into manageable parts for product and or service delivery. See the more detailed discussion below for further explanation.

Process Step/Involved Parties/Reference: Requirements Definition: Client & -TrustData Solutions: Fig. 1 at 14.

This is the detailing of the requirements for the DRM application. Requirements should include identifying what would be required from a clearinghouse perspective (applications typically run in data centers for processing usage and financial transactions as well as applications, applets, or specific application functions for the local IRP installation for querying the IRP and/or the information stored in a Protected Database ("PDB") associated with an IRP instance). See the more detailed discussion below for further explanation.

Process Step/Involved Parties/Reference: Product Development: TrustData Solutions; Fig. 1 at 16. This process deals primarily with the development of the packaging applications that may, among other features and/or functions, enable definition of the rule(s) governing the authorized use of any kind of digital information, securely associating the rule(s) with the protected digital information, and packaging the rules and/or digital information in a cryptographically secure container, and rendering DRM applications based on the detailed requirements gathered. The development process leverages existing pre-built software (i.e., components) and other 3rd party technologies as necessary to hasten the product delivery, where practical.

Process Step/Involved Parties/Reference: Product Localization: Client (and or TrustData Solutions); Fig. 1 at 18. Depending upon the needs of the client and the cultural influences of the digital information packagers and/or providers, and of end-user, the product may need localization for deployment and usage. This effort may or may not be shared between TrustData and the client.

Process Step/Involved Parties/Reference: Client Site Application Testing; Client & TrustData Solutions:

Testing the application is best achieved at the client site where variables in a production environment can be simulated and monitored. This process involves setting up the test environment identical to the production environment. Special requirements (i.e., cryptographic key spaces) from a key manager, such as InterTrust Technologies Corporation, are needed to achieve client-site testing. Process Step/Involved Parties Reference: IRP Software Customization; Deployment Manager; Fig. 1 at 22.

Since in the preferred embodiment, an InterTrust deployment manager ("DM") is responsible for one or more trusted client (TCB) administrative and key management services, a DM may need to customize the IRP software and/or related applications and/or related applets for the purposes of the TrustData prospect/customer as it relates to the needs of the end-user. The TrustData customer may also need to have the user interface to the IRP customized for their purposes. These IRP interface customizations (in the form of applets) are identified during the requirements definition process.

Process Step/Involved Parties/Reference: Rights Wallet (Applets) Provisioning; Clearinghouse; Fig. 1 at 24. This process is the development of the mini-applications of applets that enable the end-user to monitor, dispute, etc. transactions generated as a result of the authorized access and use of governed digital information. Other applets to be developed also involve user registration and activation. Users may be individuals or processes within or operated by the TrustData customer organization and/or may be end-users interacting with governed digital information in accordance with associated rules.

Process Step/Involved Parties/Reference: Define Identity Characteristics ("Membership Cards"^"); Client & TrustData Solutions.

In the preferred embodiment, the IRP software evaluates requests to access and/or use protected digital information in accordance with criteria established by the client and/or a provider of clearinghouse services. Among the criteria that may be used are the presence and/or absence of digital credentials, a non- limiting example of which may be one or more "Membership Cards", digital files or objects that represent, warrant, and/or attest to some fact or facts, such as class membership. This step identifies one or more Membership Cards that need to be instantiated, distributed, and used in at least one rule associate with and governing at least some digital information and/or consequences of governed use. (membership card process not shown in accompanying process flow charts).

Process Step/Involved Parties/Reference: CH Application Development / Customization: Clearinghouse: Fig. 1 at 28. This process involves the development of the applications that process the transactions generated by the authorized access and use of protected digital information. The types of applications developed may also include billing, disbursing financials, and aggregating transactions, and applications that interact with banking, settlement, funds transfer, fraud detection, and other payment related functions and services. Process Step/Involved Parties/Reference: InterTrust Certification: Trust Data Solutions. Clearinghouse. Deployment Manager; Fig, 1 at 30. 32. 34, and 36.

All applications based on the InterTrust digital commerce DRM platform technologies are certified by InterTrust or an approved designee. This certification process involves InterTrust to review and test all applications based on their standards that interact with the trusted computing base (e.g., an IRP installation) and/or with data center services such as financial and/or usage information clearinghouses and or deployment management services. In general, these standards are based upon: (1) ensuring that the rights of the digital information creator, provider, distributor, and/or end-user are persistently enforced whenever and/or wherever use is requested and (2) ensuring the integrity of the protected digital information is not violated.

Process Step/Involved Parties/Reference: Package for Deployment; Client, TrustData Solutions. Clearinghouse; Fig. 1 at 38, 40, and 42.

This process involves preparing the TrustData developed product or service to be installed into a production or operational environment.

Product Deployment

Process Step/Involved Parties/Reference: Install IRP Software; Client and TrustData Solutions; Fig. 1 at 44. This process involves gaining access to an InterRights Point (IRP) installation from various sources. This could be downloaded from the Internet or other network or provided through optical media including CD-ROM and/or DVD. The InterRights Point may also be already installed on the designated user device (workstation, laptop, PDA, etc.) There may be an instance where the TrustData Product Installation process also installs the IRP software. This would depend on how the TrustData product deployment is structured.

Process Step/Involved Parties/Reference: Activate IRP Software; Deployment Manager: Fig. 1 at 46. This activation process is required for an IRP installation to become operational. It requires basic some information from the user so that the Deployment Manager can provide additional services such as time service, name service, cryptographic key and/or digital certificate management services, backup & migrate, etc.

Process Step/Involved Parties/Reference: Register & Setup Budgets: Client & TrustData Solutions: Fig. 1 at 48.

For the client to properly utilize the DRM-enabled application in conjunction with one or more commerce clearinghouses, the client needs to register as a user with those one or more clearinghouses. Budgets, if necessary, will be setup as appropriate. Process Step/Involved Parties/Reference: CH Registration: Clearinghouse; Fig. 1 at 50.

This process is initiated when users register and setup their budget. The clearinghouse will provide them with the information the IRP needs for communicating with the clearinghouse

Process Step/Involved Parties Reference: Product Installation; Client & TrustData Solutions: Fig. 1 at 54.

This process is the installation of the DRM digital information packaging and the Rights Wallet applications that constitute the user interface with the InterRights Point trusted client software.

Process Step/Involved Parties Reference: Product Training: Client & TrustData Solutions: Fig. 1 at 56.

This process is used to familiarize the users with the packaging application. This is in preparation for the cutover to complete use by the client.

Process Step/Involved Parties/Reference: Deploy CH Applications; Clearinghouse: Fig. 1 at 52. This process involves the implementation of the commerce clearinghouse application at their operational site(s). This application processes the transactions generated by the authorized access and/or use of digital information.

Product Operations Process Step/Involved Parties/Reference: Deploy Rendering Application; Client; Fig. 2 at 58.

This DRM product requires proper packaging if ft is to be deployed to end-users over the Internet, over any other network, or through magnetic and/or optical media. This process of deploying includes incorporation of some install process and any additional setup requirements requested by the client.

Process Step/Involved Parties Reference: Install IRP Software; End-user; Fig. 2 at 60.

This process involves gaining access to an InterRights Point (IRP) installation from various sources. In this embodiment, the trusted computing base is an InterRights Point from InterTrust. This could be downloaded from the Internet or provided through optical media such as CD-ROM and/or DVD. This may also be already installed on the designated user device (workstation, laptop, PDA, portable media player, etc.) There may be an instance where the installation process for a digital information rendering application also installs the IRP at the same time. This would depend on how the rendering application's deployment is structured. Note that after installing the IRP in concert with the rendering application, it still has to be activated by the Deployment Manager (see Activate IRP in Product Deployment.) Process Step/Involved Parties/Reference: Install Rendering Application; End-user; Fig. 2 at 62.

This process is the installation of the DRM-enabled rendering application and Rights Wallet IRP interface applications unto the end-user's device. This process may also invoke or include the installation of the IRP.

Process Step/Involved Parties/Reference: Register & Setup Budgets; End-user: Fig. 2 at 64.

For the end-user to properly utilize the DRM application in conjunction with one or more commerce clearinghouses, they need to register as a user. Budgets, if necessary, will be setup as appropriate. One non- limiting example of a budget creation process would be to collect credit card or other account information from the end-user, charge the account an agreed-upon amount, and represent that amount in a budget object representing the agreed upon amount that is then sent in an encrypted secure container to the end-user's InterRights Point. In addition, any services that the end-user requires to properly operate the DRM application will be registered via membership tokens into the end-user's Protected Database. Based on the requirements of the application, authentication tokens may also be issued and registered. The level of authentication required can range from a simple user id and password to biometric authentications such as retina scans and fingerprints.

Process Step/Involved Parties Reference: Membership Card Management; Client & TrustData Solutions; optionally a clearinghouse. This process is initiated with the client's rules governing the use of protected information depend upon, or are conditional on at least one digital credential, which in the preferred embodiment is a Membership Card. This process distributes one or more membership cards to the appropriate users in cryptographicly secure containers, which in the preferred embodiment are DigiBox secure containers. The container is registered with the IRP and the Membership Card(s) stored in the Protected Database (PDB) (membership card process not shown in accompanying process flow charts).

Process Step/Involved Parties Reference: Develop Digital Information; Digital Information Provider or Creator: Fig. 2 at 68.

This process is involves the creation or provisioning of digital information by authors or stewards of such information. These individuals or groups will define or make known the rights to be applied to the digital information.

Process Step/Involved Parties/Reference: Package Digital Information; Client: Fig. 2 at 70. This is the process in which digital information is actually packaged into safe containers for consumption.

Process Step/Involved Parties/Reference Access & Use of Protected Digital Information: End-user; Fig 2 at 22.

When end-users view, play, pπnt, etc. protected digital mformation in a DRM-enabled commerce environment, they are considered to be consuming and/or interacting with such digital information.

Process Step/Involved Parties Reference Process CH Transactions: Clearinghouse; Fig. 2 at 74. Generally, the authorized use of protected digital information may create financial and/or audit transactions that need to be processed. DRM-enabled commerce clearinghouses process these transactions and follow-through with the necessary steps to process and/or report the collected financials or usage information to down-stream or other authorized participants.

Process Step/Involved Parties/Reference: Process Usage Information; Client; Fig. 2 at 76

If the TrustData client requires that usage mformation be forwarded to them, the commerce clearinghouses will do so The applications used to manage and/or report usage transaction information may be applications developed independent of the DRM applications and are not necessaπly certified by InterTrust These type of applications include data warehousing, reporting, sampling, marketing, etc

Process Step/Involved Parties/Reference Disburse Funds; Financial Institution: Fig 2 at 78

DRM-enabled commerce clearinghouses are not necessarily financial institutions although they may have business relationships with each other When commerce clearinghouses process financial transactions, they may aggregate any micro-payments based on thresholds and then may request the financial institution to disburse the appropriate funds The monies are disbursed m various ways depending on the agreements among value-chain participants

Process Step/Involved Parties/Reference. Collect Monies, Client, Digital Information Provider. Fig 2 at 80 and 82 After the financial institution disburses the funds, the digital information provider, distπbutor, creator, and/or client can collect any monies owed them accordingly Activity Details

Product Scoping Concept

This activity is a facilitated dialog with the participants that may include not only TrustData client's personnel, but also representatives of one or more value chains in which the client participates. A set of questions to survey the product scoping process participants should be developed ahead of time to keep the discussion in focus and process effective. Questions and ensuing discussion should be based on the objectives listed below.

From a project management perspective, scoping allows us to plan, initiate, execute, control, and evaluate projects that focus on the right solutιon(s). It helps ensure that expectations are properly set withm the context of the solution(s).

In a typical information systems development scoping session, the topic of the discussion centers on a function or set of functions within a business area of one that crosses business areas. From there, the core business objects involved within the scope are identified along with its supporting neighborhood business objects. Then the function(s) is then decomposed into smaller processes to ascertain if they are within the scope being defined.

The TrustData DRM-enabled Product Scoping takes a different path from that of a typical information systems scoping session, i conducting a Product Scoping effort, much of the discussion centers on confirming the business objectives and strategies to achieve the stated objectives. The information is reviewed to understand further the implications of potentially creating new business models to leverage the use of DRM-enabled software products and related commerce processes. Many businesses are limited to known or conventional business and revenue models because these companies do not know about DRM, what it is, its capabilities, and what value it can provide to the business and its customers and/or suppliers. Once a basic understanding is achieved, focus then shifts to issues of the existing client business models where DRM can be applied. The application of DRM technology is always linked to the bottom line and to the satisfaction of the value-chain participants in the client business' commerce cycle.

Some of the techniques used in conducting this activity include brainstormmg and timeboxing. The brainstorming technique has proven very useful in scoping sessions and is primarily used when finding creative ways to solve business issues where DRM-enabled software products and services can be utilized. Timeboxing provides a means to categorize the work or ideas generated from the brainstorming effort. This categoπzation provides the basis on which decisions are made about what the team will do over the length of the session. The benefits of these techniques include increased team motivation, user confidence and a more predictable return on investment. Timeboxing is a means of setting a deadline by which the objective(s) of a session must be met, rather than descπbmg when a task must be completed. Therefore, pπoritization of the work at hand is critical. This means categonzmg work in the following order: (i) Must-do tasks / must-have requirements: this defines the minimum number of tasks that result in the maximum number of must-have requirements; (ii) Should-do / should-have: this defines the tasks that need to be completed for requirements that can be deferred to subsequent release of the product; (iii) Coidd-do / co ld-have: this defines the tasks that can be included for requirements if effort is available but not at the expense of the above; and (iv) Want- to-do / want-to-have: this defines the tasks for those requirements that are not mandatory for the business.

Product Scoping Objectives

The scoping session is designed to achieve the following objectives: (1) Determine the type of DRM-enabled application to build including its general features, functions, and high-level requirements; (2) Determine the boundaries of a business area in question as it applies to the application of DRM technology; (3) Determine a preliminary estimate the size of the project(s) within those boundaries; (4) Assess the overall risks involved in both the application to which DRM is being applied and the DRM application itself; (5) Identify the assumptions and constraints within which the DRM application is to be built, deployed, and used; and (5) Lastly, to set the expectations of all those involved. It is important to note, that a single scoping project may result in multiple and separate subsequent projects. Each will need to be addressed either separately but in conjunction with the other projects defined during the scoping session. Further, participants in the session may have differing views on a solution as well as on the problem and or issues at hand, which will need to be brought to consensus.

Product Scoping Participants

Ideally, the participants in this session should be a mix of business and technology personnel from the client business. The business personnel are the primary participants and are supported by the technical personnel. This is to ensure that the participants focus on the business value of the technology instead of only on the technology and its capabilities.

Product Scoping Activity Tasks

This activity is divided in three main sets of tasks (please refer to Fig. 3).

The first set of tasks in conducting a scoping session is to confirm the current busmess. This set of tasks will level-set all participants in what business(es) the client is involved in, the applications employed, the products and/or services they provide, how they interact with their prospects and clients, and their revenue model. It is important to understand all the above, at this time, in order to frame how and where DRM can be applied to add the highest possible value to their busmess, including potentially revising their revenue model to take advantages of new ways to make revenue. The second set of tasks is to confirm the business vision. Here, the long-term vision of the organization is detailed, clarified and put in context of eCommerce. In understanding this, the client reviews their eCommerce strategy, which may result in revising their revenue model based on the potential application of DRM. Only after there is an understanding of the client's current business and future vision can the DRM solution be determined. Here, the applications wherein DRM will potentially be applied are identified, explained, and demonstrated. Once understood, a discussion on where to apply DRM should ensue and be documented. If a new application is to be built, then the concepts, features, and functionality are discussed. It is important to note that the application of DRM is always placed in context of business value. The application should also be put in context of the digital commerce vision of the client.

The time it takes to execute the scoping process typically depends on the information gathered during initial discussions with the client. Such information determines what steps the client has taken in resolving the issues leading to the scoping session.

Product Scoping Deliverables

The deliverable of this activity is the Product Vision and Development document. This document includes the vision, scope, risks, development approach, cost, assumptions, constraints and proposed project plan.

Requirements Definition

Requirements Definition Concept

This activity is a formal facilitated session with the participants. Unlike Product Scoping, this activity does not employ a full-blown brainstorming technique. However, it employs the timeboxing technique more rigorously throughout the entire activity.

The focus of a typical software requirements gathering project is to document the functionality of the intended system. The TrustData approach takes the identified requirements and drills down to the user interface, internal functionality and the DRM application's interactions with external systems. It takes the conceptual solution and evolves it to an implementable design. Understanding the requirements before any endeavor is essential especially when building applications. In a typical application development scenario (non-object oriented), the requirements gathered upfront are those that deal with the process and data. Processing requirements tend to deal with how a business process (i.e. order taking, order fulfillment, etc.) is accomplished on a step-by-step basis. This is detailed in either a series of sub-systems or programs with the output of one being the input to the next step. Data requirements on the other hand are aggregated and detailed by defining the relationships between each piece of information to another (i.e. First Name, Last Name, Appellation, Street Address, etc.) Often times, these relationships are manifested conceptually in "entity relationship diagrams" and physically in database schemas. The relationship between process and data are detailed in program code. In an objected oriented requirements definition approach, requirements are gathered through use- cases. Use-case scenarios depict how the "actors" interact with each other and with processes. Actors can be defined as users, application systems, or outside influencing factors that have an impact or interaction with the application being developed. This technique is coupled with sequence diagrams to depict the sequence of processing based on the actor's interaction. Other diagramming techniques are used to evolve the requirements into a full-blown application: Essentially, the application is built based on how the user needs to interact with the application.

In the above scenarios or requirements development approaches, the application of techniques for enhancing security and/or trust, if they are applied at all, is after the fact and based on what a specific set users need to do versus another set of users. The use of methods for enhancing security and/or trust may also be based on withholding or granting access to enter, retrieve, modify, and remove information at various levels of detail (i.e. field, field-set, record, record-set, file, screen, panel, window, etc.).

In the TrustData DRM Requirements Definition approach, the DRM controls applied to digital information are manifestations of the rights of the digital provider as they relate to the use of the digital information in which they have rights and/or interests. The controls applied to the digital information are defined upfront not based on what the users of the digital information or end-users want to do with the information or how they interact with the process and/or information but as defined by those with rights and/or interests in digital information or rights-holders, non-limiting examples of which may include the information creator, information distributor, and/ox information provider. Likewise, controls are not based on withholding or granting access as in the application of security but rather based on an interaction and on a mutual agreement between the rights-holder(s) and the information user on the "offerings" provided by the rights-holder(s) to the information user at the time the protected digital information is to be accessed and utilized. In this context, the controls become the norm of the DRM-enabled application rather than the process and/or data. Once the specific controls are known and understood then the DRM-enabled application(s) and related clearing services, if any, is built around them.

Requirements Definition Objectives

The requirements definition activity is designed to achieve the following primary objectives that include, but are not limited to: (i) identify, define, and confirm the DMR rules (controls, conditions and use consequences); (ii) layout the user interface for both packaging rules and/or protected information and for protected information rendering applications; (iii) identify, define, and confirm the support requirements such as those for clearinghouse and administrative (operational) purposes; and (iv) lastly, identify localization requirements, if necessary.

In defining the DRM functionality required, the workflow or navigation is also designed. It is in the flow of the application where the DRM controls will be realized. It is important to note that a when functionality is defined, it is possible that multiple releases of the application may be necessary due to the complexity or scope of the functionality. If this is the case, priorities need to be identified based on the business needs. These priorities will influence the development and implementation phases of the overall project plan.

Requirements Definition Participants

Ideally, the participants in this session should be a mix of business and technology personnel. The business personnel are the primary participants and are supported by the technical personnel. This is to ensure that the participants focus on the business value of the technology instead of only on the technology.

Requirements Definition Activity Tasks

The time it takes to execute the requirements definition process typically depends on the information gathered during the scoping process. Such information determines clarity of the client's vision of the final application(s). There are at least three approaches to the TrustData Requirements Definition activity (please refer to Appendix D.) These are detailed below. In each of the approaches, only the core sets of tasks will be detailed.

• Rights Approach

In the presently preferred embodiment, Referring to Fig. 4a, the rights approach in gathering requirements is based on starting the activity by understanding what controls need to be applied to the digital information (or combinations of different types of digital information) irrespective of how the controls are to be applied. The first set of tasks in this approach is to specify rights. In a typical DRM Requirements Gathering scenario, the client participants know very little about how to do this - what constitutes digital rights, how rights are defined, and how they may be manifested in the DRM-enabled finished software product and/or related DRM-enabled services. Therefore, it becomes imperative that these participants understand the concepts and terminology to successfully complete this set of tasks. Once an understanding is achieved, specifying controls and consequences can proceed. In specifying controls, the intents that may be offered and or granted to the information user may be coupled with conditions that the rights-holder wants the user to agree on prior to accessing and using the protected digital information. These controls also may be associated or coupled with resulting actions or use consequences. Any associated use consequences may be invoked or initiated based on the information user's response to the conditions of use and access.

Once the rights are documented by this process, the next set of tasks is to specify the rendering application. This application renders the digital information in accordance with the rules associated with the protected mformation that have been agreed to by the user. In one non-limited example, the rules may require the rendering application to prevent modification of the protected digital information, thereby protecting the integrity of the protected information. In another non-limiting example, the rules may specify that only certain users may modify some or all of the protected digital information. The set of tasks to gather requirements for this application allows the participants to visualize how the rights are to be manifested through the user's interaction with the rendering application. A graphical user interface (GUI) is designed with the intention of helping to navigate the user along a pre-defined set of actions based on, related to, and or reflective of the specified rights. As the GUI is defined, the internal functionality of the rendering application is also detailed. Like the GUI, the specified rights also control the internal functionality, which also incorporates the defined consequences. In another embodiment, the controls may determine the behavior of a standard third party application that has provisions for communications with and control by another application. One non-limiting example includes the DRM interface provided by NextPage (www.nextpage.com) in several of their information management applications.

The use consequences defined earlier may result in one or more subsequent transaction records, non- limiting examples of which include audit and or financial transaction records and related transactions using and/or based on these records. These transactions need to be processed by DRM-enabled clearinghouse services, processes, and/or applications. The applications that process these transactions are detailed in the set of tasks called specify DRM support applications. In understanding how the transactions are to be processed, it is imperative that the participants understand the e-commerce cycle. Hence the participants need to be trained. Once they understand the flow, then the transaction processing requirements for the rights-enabled commerce clearinghouse applications are detailed including how the audit and/or financial transactions need to be processed. The processing may depend on the requirements of upstream value-chain participants, including what information they want aggregated, how and when they will receive the information or the transfer of any resulting monies from the financial transactions through one or more financial clearing and/or money transfer services. Additionally, a commerce clearinghouse may have its own requirements regarding consumer registration and setup. These are gathered and detailed at this time as well. Other DRM support applications that pertain to allowing the digital information user review and potentially dispute transactions generated based on accessing and using protected digital information also needs to be addressed. These and other similar mini-applications or applets that are part of the Rights Wallet are identified, defined, and detailed at this time. The last set of tasks as part of the core set is to specify the packaging application. This application enables the content creator or provider to package the digital mformation regardless of format for governed use and access. The requirements gathered will differ based on whether the packaging application needs to have a graphical user interface or be an m-line packager. The former enables the information creator, distributor, provider or other rights holder a means to package digital contents on a small scale, mai.ual basis. The latter, however, is designed to background processing where there may be a need for high-volume processing with little manual intervention. The packager may also be required to package both digital information and controls together or separately depending also on the following: (1) type of content, (2) the relationship of multiple contents to each other and to associated controls, and (3) how the content needs to be managed over time with regard to the controls. Hence detailing the packager requirements as a whole is based on the specified rights and administrative requirements of those πghts over time.

• User Interface approach

In another embodiment, Referring to Fig. 4b, the user interface approach in gatheπng requirements is based on a common starting the activity by understanding what is the desired user expeπence. The first set of tasks in this approach is to specify the rendering application. This application renders the digital information in accordance with the rules associated with the protected mformation that have been agreed to by the user, hi one non-limited example, the rules may require the rendering application to prevent modification of the protected digital information, thereby protecting the mtegπty of the protected information. In another non-limiting example, the rules may specify that only certain users may modify some or all of the protected digital mformation. The set of tasks to gather requirements for this application allows the participants to visualize how the rights are to be manifested through the user's interaction with the rendering application. A graphical user interface (GUI) is designed with the intention of helping to navigate the user along a pre-defined set of actions based on, related to, and or reflective of the specified rights. As the GUI is defined, the internal functionality of the rendering application is also detailed. Like the GUI, the specified rights also control the internal functionality, which also incorporates the defined consequences. In another embodiment, the controls may determine the behavior of a standard third party application that has provisions for communications with and control by another application. One non-limiting example includes the DRM interface provided by NextPage (www.nextpage.com) in several of their information management applications.

The next set of tasks in this approach is to specify rights. In a typical DRM Requirements Gathering scenario, the client participants know very little about how to do this - what constitutes digital rights, how rights are defined, and how they may be manifested in the DRM-enabled finished software product and/or related DRM-enabled services. Therefore, it becomes imperative that these participants understand the concepts and terminology to successfully complete this set of tasks Once an understanding is achieved, specifying controls and consequences can proceed. In specifying controls, the intents that may be offered and or granted to the mformation user may be coupled with conditions that the rights-holder wants the user to agree on prior to accessing and using the protected digital information These controls also may be associated or coupled with resulting actions or use consequences Any associated use consequences may be invoked or initiated based on the information user's response to the conditions of use and access.

The next step is to specify the packaging application. This application enables the content creator or provider to package the digital information regardless of format for governed use and access. The requirements gathered will differ based on whether the packaging application needs to have a graphical user interface or be an m-hne packager The former enables the information creator, distπbutor, provider or other rights holder a means to package digital contents on a small scale, manual basis. The latter, however, is designed to background processing where there may be a need for high-volume processing with little manual intervention. The packager may also be required to package both digital information and controls together or separately depending also on the following (1) type of content, (2) the relationship of multiple contents to each other and to associated controls, and (3) how the content needs to be managed over time with regard to the controls. Hence detailing the packager requirements as a whole is based on the specified nghts and administrative requirements of those πghts over time.

The use consequences defined earlier may result in one or more subsequent transaction records, non- limiting examples of which include audit and/or financial transaction records and related transactions using and/or based on these records. These transactions need to be processed by DRM-enabled clearinghouse services, processes, and/or applications. The applications that process these transactions are detailed m the last set of tasks called specify DRM support applications. In understanding how the transactions are to be processed, it is imperative that the participants understand the e-commerce cycle. Hence the participants need to be trained Once they understand the flow, then the transaction processing requirements for the πghts-enabled commerce cleaπnghouse applications are detailed including how the audit and or financial transactions need to be processed The processing may depend on the requirements of upstream value-chain participants, including what information they want aggregated, how and when they will receive the mformation or the transfer of any resulting monies from the financial transactions through one or more financial cleaπng and or money transfer services Additionally, a commerce clearinghouse may have its own requirements regarding consumer registration and setup. These are gathered and detailed at this time as well Other DRM support applications that pertain to allowing the digital information user review and potentially dispute transactions generated based on accessing and using protected digital information also needs to be addressed. These and other similar mini-applications or applets that are part of the Rights Wallet are identified, defined, and detailed at this time • Combined Approach

Referring to Fig. 4c, the combined approach in gathering requirements is a hybrid approach that combines the elements of rights approach with the user interface approach. As a first step in a typical DRM Requirements Gathering scenario, the client participants know very little about how to do this - what constitutes digital rights, how rights are defined, and how they may be manifested in the DRM-enabled finished software product and or related DRM-enabled services. Therefore, it becomes imperative that these participants understand the concepts and terminology to successfully complete this set of tasks. Once an understanding is achieved, specifying controls and consequences (also know as rights) along with rendering specifications can proceed j ointly .

In specifying rules, the intents that may be offered and/or granted to the information user may be coupled with conditions that the rights-holder wants the user to agree on prior to accessing and using the protected digital information. These controls also may be associated or coupled with resulting actions or use consequences. Any associated use consequences may be invoked or initiated based on the information user's response to the conditions of use and access.

As a concurrent and interactive task with rule specification, the clients also specify the rendering application. This application renders the digital information in accordance with the rules associated with the protected information that have been agreed to by the user. In one non-limited example, the rules may require the rendering application to prevent modification of the protected digital information, thereby protecting the integrity of the protected information. In another non-limiting example, the rules may specify that only certain users may modify some or all of the protected digital information. The set of tasks to gather requirements for this application allows the participants to visualize how the rights are to be manifested through the user's interaction with the rendering application. A graphical user interface (GUI) is designed with the intention of helping to navigate the user along a pre-defined set of actions based on, related to, and or reflective of the specified rights. As the GUI is defined, the internal functionality of the rendering application is also detailed. Like the GUI, the specified rights also control the internal functionality, which also incorporates the defined consequences. In another embodiment, the controls may determine the behavior of a standard third party application that has provisions for communications with and control by another application. One non-limiting example includes the DRM interface provided by NextPage (www.nextpage.com) in several of their information management applications.

The use consequences defined earlier may result in one or more subsequent transaction records, non- limiting examples of which include audit and or financial transaction records and related transactions using and/or based on these records. These transactions need to be processed by DRM-enabled clearinghouse services, processes, and/or applications. The applications that process these transactions are detailed in the set of tasks called specify DRM support apphcations. In understanding how the transactions are to be processed, it is imperative that the participants understand the e-commerce cycle.

Once they understand the flow, then the transaction processing requirements for the rights-enabled commerce clearinghouse apphcations are detailed including how the audit and/or financial transactions need to be processed. The processing may depend on the requirements of upstream value-chain participants, including what information they want aggregated, how and when they will receive the information or the transfer of any resulting monies from the financial transactions through one or more financial cleanng and/or money transfer services. Additionally, a commerce clearinghouse may have its own requirements regarding consumer registration and setup These are gathered and detailed at this time as well. Other DRM support applications that pertain to allowing the digital information user review and potentially dispute transactions generated based on accessing and using protected digital mformation also needs to be addressed These and other similar mmi-apphcations or applets that are part of the Rights Wallet are identified, defined, and detailed at this time.

The last set of tasks as part of the core set is to specify thepackaging application. This application enables the content creator or provider to package the digital information regardless of format for governed use and access The requirements gathered will differ based on whether the packaging application needs to have a graphical user interface or be an in-line packager. The former enables the information creator, distπbutor, provider or other πghts holder a means to package digital contents on a small scale, manual basis. The latter, however, is designed to background processing where there may be a need for high-volume processing with little manual intervention. The packager may also be required to package both digital mformation and controls together or separately depending also on the following- (1) type of content, (2) the relationship of multiple contents to each other and to associated controls, and (3) how the content needs to be managed over time with regard to the controls. Hence detailing the packager requirements as a whole is based on the specified rights and administrative requirements of those rights over time.

Requirements Definition Deliverables

The deliverable of this activity is the Requirements Definition Document This document details the functionality and how said functionality is implemented. It also includes the recommended project plan, which details the steps to take in developing the DRM application While the present invention has been described with reference to certain preferred embodiments, it is to be understood that the present invention is not to be limited to such specific embodiments. Rather, it is the inventor's intention that the invention be understood and construed in its broadest meaning as reflected by the following claims Thus, these claims are to be understood as incorporating and not only the preferred embodiment described herein but all those other and further alterations and modifications as would be apparent to those of ordinary skill in the art.

Claims

What we claim are:

CLAIMS 1. A method for building a digital rights management system, comprising the steps of: specifying rule types for controlling and manipulating digital information for transporting said information among two or more persons; specifying a rendering program for controlling and manipulating said information in accordance with said rules; specifying a support application for securing and transporting said information; and specifying a packager for packing said mformation for transport by said support application.