WO2002039225A2 - Procedes relatifs a un processus de traitement de demandes selon des regles pour systemes valides par droits - Google Patents

Procedes relatifs a un processus de traitement de demandes selon des regles pour systemes valides par droits Download PDF

Info

Publication number
WO2002039225A2
WO2002039225A2 PCT/US2001/046820 US0146820W WO0239225A2 WO 2002039225 A2 WO2002039225 A2 WO 2002039225A2 US 0146820 W US0146820 W US 0146820W WO 0239225 A2 WO0239225 A2 WO 0239225A2
Authority
WO
WIPO (PCT)
Prior art keywords
drm
information
application
requirements
rights
Prior art date
Application number
PCT/US2001/046820
Other languages
English (en)
Other versions
WO2002039225A3 (fr
Inventor
Miles A. Cato
Teresa L. Dorr
Robert Thomas P. Neri
Robert P. Weber
Original Assignee
Aspsecure Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Aspsecure Corporation filed Critical Aspsecure Corporation
Publication of WO2002039225A2 publication Critical patent/WO2002039225A2/fr
Publication of WO2002039225A3 publication Critical patent/WO2002039225A3/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/10—Protecting distributed programs or content, e.g. vending or licensing of copyrighted material ; Digital rights management [DRM]

Definitions

  • 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.
  • DRM digital rights management
  • 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.
  • 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
  • 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
  • the product process flow depicts the processes that TrustData Solutions follow in delivering digital rights management (DRM) solutions to its clients
  • DRM digital rights management
  • 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.
  • DRM digital rights management
  • 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.
  • 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
  • Fig. 4c illustrates the Combined Approach in the Requirement Definition sub-process.
  • 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
  • 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, govence-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.
  • 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.
  • 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.
  • Product Localization Client (and or TrustData Solutions); Fig. 1 at 18.
  • the product may need localization for deployment and usage. This effort may or may not be shared between TrustData and the client.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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.
  • the trusted computing base e.g., an IRP installation
  • data center services such as financial and/or usage information clearinghouses and or deployment management services.
  • 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.
  • This process involves preparing the TrustData developed product or service to be installed into a production or operational environment.
  • 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.)
  • the TrustData Product Installation process also installs the IRP software. This would depend on how the TrustData product deployment is structured.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • InterRights Point This process involves gaining access to an InterRights Point (IRP) installation from various sources.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • PDB Protected Database
  • 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.
  • 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 Process Usage Information; Client; Fig. 2 at 76
  • 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
  • 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
  • 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.
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the application of techniques for enhancing security and/or trust 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.).
  • 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.
  • 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.
  • the controls become the norm of the DRM-enabled application rather than the process and/or data.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the rules may require the rendering application to prevent modification of the protected digital information, thereby protecting the integrity of the protected information.
  • 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.
  • the internal functionality of the rendering application is also detailed.
  • the specified rights also control the internal functionality, which also incorporates the defined consequences.
  • 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 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 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.
  • 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.
  • GUI graphical user interface
  • the internal functionality of the rendering application is also detailed.
  • the specified rights also control the internal functionality, which also incorporates the defined consequences.
  • 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.
  • 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.
  • 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 packaging 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 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 combined approach in gathering requirements is a hybrid approach that combines the elements of rights approach with the user interface approach.
  • 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.
  • specifying controls and consequences also know as rights
  • rendering specifications can proceed j ointly .
  • 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.
  • 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.
  • the rules may require the rendering application to prevent modification of the protected digital information, thereby protecting the integrity of the protected information.
  • 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.
  • the internal functionality of the rendering application is also detailed.
  • the specified rights also control the internal functionality, which also incorporates the defined consequences.
  • 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 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.
  • a commerce clearinghouse may have its own requirements regarding consumer registration and setup These are gathered and detailed at this time as well.
  • 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 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.

Abstract

L'invention concerne un procédé permettant de développer un système numérique de gestion de droits, comprenant les étapes consistant à: (i) spécifier des types de règles pour commander et manipuler des informations numériques afin de transporter lesdites informations entre au moins deux personnes, (ii) spécifier un programme de représentation pour commander et manipuler ledit message en fonction desdites règles, (iii) spécifier une application de soutien pour sécuriser et transporter ledit message, et (iv) spécifier un dispositif d'emballage permettant d'emballer ledit message pour le transporter à l'aide de ladite application de soutien.
PCT/US2001/046820 2000-11-07 2001-11-07 Procedes relatifs a un processus de traitement de demandes selon des regles pour systemes valides par droits WO2002039225A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US24637900P 2000-11-07 2000-11-07
US60/246,379 2000-11-07

Publications (2)

Publication Number Publication Date
WO2002039225A2 true WO2002039225A2 (fr) 2002-05-16
WO2002039225A3 WO2002039225A3 (fr) 2002-11-21

Family

ID=22930416

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/046820 WO2002039225A2 (fr) 2000-11-07 2001-11-07 Procedes relatifs a un processus de traitement de demandes selon des regles pour systemes valides par droits

Country Status (1)

Country Link
WO (1) WO2002039225A2 (fr)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5933498A (en) * 1996-01-11 1999-08-03 Mrj, Inc. System for controlling access and distribution of digital property
US6138119A (en) * 1997-02-25 2000-10-24 Intertrust Technologies Corp. Techniques for defining, using and manipulating rights management data structures
US20010011238A1 (en) * 1998-03-04 2001-08-02 Martin Forest Eberhard Digital rights management system
US6330670B1 (en) * 1998-10-26 2001-12-11 Microsoft Corporation Digital rights management operating system
US20020002674A1 (en) * 2000-06-29 2002-01-03 Tom Grimes Digital rights management
WO2002001326A2 (fr) * 2000-06-27 2002-01-03 Microsoft Corporation Systeme et procede d'interaction client dans une architecture de gestion des droits d'auteur multiniveaux
US20020019814A1 (en) * 2001-03-01 2002-02-14 Krishnamurthy Ganesan Specifying rights in a digital rights license according to events

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5933498A (en) * 1996-01-11 1999-08-03 Mrj, Inc. System for controlling access and distribution of digital property
US6138119A (en) * 1997-02-25 2000-10-24 Intertrust Technologies Corp. Techniques for defining, using and manipulating rights management data structures
US20010011238A1 (en) * 1998-03-04 2001-08-02 Martin Forest Eberhard Digital rights management system
US6330670B1 (en) * 1998-10-26 2001-12-11 Microsoft Corporation Digital rights management operating system
WO2002001326A2 (fr) * 2000-06-27 2002-01-03 Microsoft Corporation Systeme et procede d'interaction client dans une architecture de gestion des droits d'auteur multiniveaux
US20020002674A1 (en) * 2000-06-29 2002-01-03 Tom Grimes Digital rights management
US20020019814A1 (en) * 2001-03-01 2002-02-14 Krishnamurthy Ganesan Specifying rights in a digital rights license according to events

Also Published As

Publication number Publication date
WO2002039225A3 (fr) 2002-11-21

Similar Documents

Publication Publication Date Title
US7069234B1 (en) Initiating an agreement in an e-commerce environment
CN101415001B (zh) 使用安全注解的组合应用
US7167844B1 (en) Electronic menu document creator in a virtual financial environment
US7610233B1 (en) System, method and article of manufacture for initiation of bidding in a virtual trade financial environment
AU2001250580B2 (en) Electronic activity and business system and method
US6629081B1 (en) Account settlement and financing in an e-commerce environment
Ahmad et al. RSM analysis based cloud access security broker: a systematic literature review
US20030120557A1 (en) System, method and article of manufacture for an internet based distribution architecture
Julisch et al. Compliance by design–Bridging the chasm between auditors and IT architects
US10673831B2 (en) Systems and methods for automating security controls between computer networks
US20030126033A1 (en) System, method and article of manufacture for software source authentication for return purposes
WO2001001227A1 (fr) Systeme, procede et article de fabrication s'appliquant a des transactions suivies de ventes de logiciels d'un detaillant internet en vue de communiquer ces transactions a un editeur de logiciels
US8832643B2 (en) Composition of non-functional concerns
Abdallah et al. Blockchain-based solution for pharma supply chain industry
O’Connor et al. 2010 economic analysis of role-based access control
Gutiérrez et al. The practical application of a process for eliciting and designing security in web service systems
WO2001001319A1 (fr) Systeme, procede et article de fabrication d'interface de soutien adaptee au profil du client dans un environnement de distribution de logiciel electronique
WO2002039225A2 (fr) Procedes relatifs a un processus de traitement de demandes selon des regles pour systemes valides par droits
Park et al. A study on cloud-based software marketing strategies using cloud marketplace
Mlelwa et al. Requirement’s for proposed frameworks for secure ecommerce transactions
WO2001001316A2 (fr) Systeme, procede et article de fabrication permettant de distribuer un logiciel electronique, mecanisme de paiement apres telechargement a capacites de cryptage
WO2001001225A1 (fr) Systeme, procede, et article fabrication permettant de generer automatiquement un droit d'utilisation personnalise
Goettelmann Risk-aware Business Process Modelling and Trusted Deployment in the Cloud
Popovici et al. Generation and verification of heterogeneous purchase processes.
Pozder End-to-End Software License Management

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): CA CN JP KR SG US

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

121 Ep: the epo has been informed by wipo that ep was designated in this application
AK Designated states

Kind code of ref document: A3

Designated state(s): CA CN JP KR SG US

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: COMMUNICATION UNDER RULE 69 EPC (EPO FORM 1205A OF 22.07.2003)

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP