Open Digital Rights Language
`(ODRL)
`
`Version: 0.7
`Date: 2000-10-13
`This Version: <http://odrl.net/ODRL-07.pdf>
`Previous Versions: <http://odrl.net/ODRL-05.pdf>
`Editor: Renato Iannella <renato@iprsystems.com>
`
`0 Status
`
`1 Overview
`
`This document is an early draft and a work-in-progress and may be
`updated and/or replaced by other documents at any time.
`
`The intention is to promote this draft document amongst multiple
`communities interested in the expression of Digital Rights
`Management statements and semantic interoperability across these
`communities.
`ODRL will be standardised via an appropriate, open, and non-
`competitive organisation with an open process for the future
`maintenance of the standard. ODRL has no license requirements and is
`available in the spirit of “open source” software.
`
`Comments are welcome to the editors from all interested parties.
`
`Change Bars indicate modifications from Version 0.5
`
`Digital Rights Management (DRM) involves the description, layering,
`analysis, valuation, trading and monitoring of the rights over an
`enterprise’s assets; both in physical and digital form; and of tangible
`and intangible value. DRM covers the digital management of rights -
`be they rights in a physical manifestation of a work (eg a book), or be
`they rights in a digital manifestation of a work (eg an ebook). Current
`methods of managing, trading and protecting such assets are
`inefficient, proprietary, or else often require the information to be
`wrapped or embedded in a physical format [HIGGS].
`
`A key feature of managing online rights will be the substantial
`increase in re-use of digital material on the Web as well as the
`increased efficiency for physical material. The pervasive Internet is
`changing the nature of distribution of digital media from a passive
`one way flow (from Publisher to the End User) to a much more
`interactive cycle where creations are re-used, combined and extended
`ad infinitum. At all stages, the Rights need to be managed and
`honoured with trusted services.
`
`© IPR Systems Pty Ltd, 2000
`
`1 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 1
`
`

`

`1.1 The Bigger
`Picture
`
`Current Rights management technologies include languages for
`describing the terms and conditions, tracking asset usages by
`enforcing controlled environments or encoded asset manifestations,
`and closed architectures for the overall management of rights.
`The Open Digital Rights Language (ODRL) provides the semantics for
`DRM in open and trusted environments whilst being agnostic to
`mechanisms to achieve the secure architectures.
`
`It is envisaged that ODRL will “plug into” an open framework that
`enables peer-to-peer interoperability for DRM services. (See
`[ERICKSON] for an overview of this area). However, ODRL can also be
`used as an mechanism to express rights statements on its own and to
`plug into existing DRM architectures, for example, the Electronic Book
`Exchange [EBX] framework.
`
`The editors consider that traditional DRM (even though it is still a
`new discipline) has taken a closed approach to solving problems. That
`is, the DRM has focused on the content protection issues more than the
`rights management issues. Hence, we see a movement towards “Open
`Digital Rights Management” (ODRM) with clear principles focused on
`interoperability across multiple sectors and support for fair-use
`doctrines.
`
`The ODRM Framework consists of Technical, Business, Social, and
`Legal streams as shown in Figure 1.
`
`ODRM Framework
`
`ODRM Business
`
`ODRM Social ODRM Legal
`
`ODRM Technical
`
`ODRA
`
`ODRL ODRT ODRP
`
`Figure 1. ODRM Framework
`
`The ODRM Technical stream consists of an Architecture (ODRA),
`Trading Protocol (ODRT) and Protection (ODRP) mechanisms with
`ODRL clearly focused on solving a common and extendable way of
`expressing Rights assertions within this Architecture.
`
`The ODRM Architecture exists in other forms that are specific to other
`communities needs, such as Privacy metadata. Hence, ODRA can be
`
`© IPR Systems Pty Ltd, 2000
`
`2 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 2
`
`

`

`1.2 About this
`Specification
`
`2 ODRL
`
`2.1 Scope
`
`achieved by abstracting and reusing such architectures to enable
`trusted metadata expressions about digital assets.
`
`This document, along with its normative references, includes all the
`specification necessary for the implementation of interoperable ODRL
`applications.
`
`The key words must, must not, required, shall, shall not, should, should
`not, recommended, may, and optional in this specification are to be
`interpreted as described in [RFC2119] which defines the significance
`of each particular requirement.
`
`Examples used in this document are for demonstration purposes only.
`
`ODRL complements existing analogue rights management standards
`by providing digital equivalents, and supports an expandible range of
`new services that can be afforded by the digital nature of the assets in
`the Web environment. In the physical environment, ODRL can be used
`to enable machine-based processing for Rights management.
`ODRL is a standard vocabulary for the expression of terms and
`conditions over assets. ODRL covers a core set of semantics for these
`purposes including the rights holders and the expression of
`permissible usages for asset manifestations. Rights can be specified for
`a specific asset manifestation (format) or could be applied to a range of
`manifestations of the asset.
`
`ODRL is focused on the semantics of expressing rights languages.
`ODRL can be used within trusted or untrusted systems for both digital
`and physical assets. However, ODRL does not determine the
`capabilities nor requirements of any trusted services (eg for content
`protection, digital/physical delivery, and payment negotiation) that
`utilises its language. Clearly, however, ODRL will benefit rights
`transactions over digital assets as these can be captured and managed
`as a single transaction. In the physical world, ODRL expressions would
`need an accompanying system with the distribution of the physical
`asset.
`ODRL defines a core set of semantics. Additional semantics can be
`layered on top of ODRL for third-party value added services.
`ODRL does not enforce or mandate any policies for DRM, but provides
`the mechanisms to express such policies. Communities or
`organisations, that establish such policies based on ODRL, do so based
`on their specific business or public access requirements.
`ODRL depends on the use of unique identification of assets. This is a
`very difficult problem to address and to have agreement across many
`sectors and is why identification mechanisms and policies of the assets
`
`© IPR Systems Pty Ltd, 2000
`
`3 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 3
`
`

`

`is outside the scope of ODRL. Sector-specific versions of ODRL may
`address the need to infer information about the asset manifestation
`from its unique identifier.
`ODRL model is based on an analysis and survey of sector specific
`requirements (models and semantics), and as such, aims to be
`compatible with a broad community base. ODRL aims to meet the
`common requirements for many sectors and has been influenced by
`the ongoing work and specifications/models of the following groups:
`• <indecs> [INDECS]
`• Electronic Book Exchange [EBX]
`• IFLA
`• DOI Foundation [DOI]
`• ONIX
`• MPEG
`• IMS
`• Dublin Core Metadata Initiative [DCMI]
`ODRL proposes to be compatible with the above groups by defining an
`independent and extensible set of semantics. ODRL does not depend
`on any media types as it is aimed for cross-sector interoperability.
`
`2.2 Foundation
`Model
`
`ODRL is based on a simple, yet extensible, model for rights
`management which involves the clear separation of Parties, Assets,
`and Rights descriptions. This is shown in Figure 2.
`
`Rights
`
`Administration
`
`Reward
`
`Usage
`
`Constraint
`
`Narrow
`
`Party
`
`uid
`idScheme
`role
`
`Asset
`
`uid
`idScheme
`
`Figure 2. ODRL Foundation Model
`
`The Rights entity consists of Usage, Constraint, Narrow, and Reward
`which together enable the expression of digital rights over the
`identified Asset and their Rights Holders (parties). The Parties’ Role
`with respect to their Rewards can also be expressed.
`
`The description of the Party and Asset entities is outside the scope of
`ODRL. What is in scope is that these entities must be referenced by
`
`© IPR Systems Pty Ltd, 2000
`
`4 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 4
`
`

`

`2.2.1 Example
`
`using unique identification mechanisms (such as [URI], [DOI], [ISBN]
`etc).
`
`The Asset entity (sometimes referred to as a Work, Content, Creation,
`or Intellectual Property), is viewed as a whole entity. If the Rights are
`assigned at the Asset’s subpart level, then such parts would require to
`also be uniquely identifiable. However, ODRL can specify constraints
`on subparts of the asset.
`
`The Rights entity also consists of an Administration entity that
`captures the responsible parties and valid dates of the Rights
`expression.
`Complete and formal semantics for the ODRL Foundation Model
`properties and attributes are specified in Section 3.1 "Foundation
`Semantics" on page 12.
`
`The ODRL Foundation Model can be expressed using XML. A pseudo-
`example is shown below:
`<rights>
`<asset>
`<uid idscheme=”URI”>http://byeme.com/myasset.pdf</uid>
`</asset>
`<usage>
`<usage-type>
`...
`<constraint> ... </constraint>
`</usage-type>
`<usage-type>
`...
`<constraint> ... </constraint>
`</usage-type>
`...
`</usage>
`<narrow> ... </narrow>
`<reward>
`<reward-type>
`<party>
`...
`
`<role> ... </role>
`</party>
`</reward-type>
`...
`</reward>
`<admin>
`<party> ... </party>
`<datetime> .. </datetime>
`</admin>
`</rights>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 21.
`
`© IPR Systems Pty Ltd, 2000
`
`5 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 5
`
`

`

`2.3 Rights Usage
`Model
`
`ODRL supports the expression of Rights Usages. This is the recognised
`set of allowable usage rights over the Asset. This is shown in Figure 3.
`
`ODRL-FoundationModel::Usage
`
`0..*0..*0..* ODRL-FoundationModel::Constraint0..*0..*0..*
`
`
`
`
`
`1..*1..*1..*1..*1..*1..*
`
`0..*0..*0..*0..*0..*0..*
`
`ODRL-FoundationModel::Asset
`
`ODRL-FoundationModel::Narrow
`
`Use
`
`Transfer
`
`Reuse
`
`Display
`
`Print
`
`Sell
`
`Lend
`
`Modify
`
`Annotate
`
`Play
`
`Execute
`
`Give
`
`Copy
`
`Figure 3. ODRL Usages Model
`
`The Usage entity consists of an aggregation of three abstract entities:
`• Use - indicates a set of usages in which the Asset can be consumed
`(realised with: Display, Print, Play, Execute).
`• Transfer - indicates a set of usages in which the rights over the
`Asset can be transferred (realised with: Sell, Lend, Give).
`• Reuse - indicates a set of usages in which the Asset (or portions of
`it) can be re-utilised (realised with: Modify, Copy, Annotate).
`
`A Usage must be associated with one or more Assets. A Usage can be
`associated with zero or more Constraints.
`
`A Usage Right that is not specified in any Rights Expressions is not
`granted. That is, no assumptions should be made in regard to Usage
`Rights if they are not explicitly mentioned.
`
`Additionally, all Usages can be subject to an “Exclusivity” attribute
`that indicates if the constraint is exclusive or not.
`Complete and formal semantics for the ODRL Usage Model properties
`and attributes are specified in Section 3.2 "Usage Semantics" on
`page 13.
`
`Important Note
`
`© IPR Systems Pty Ltd, 2000
`
`6 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 6
`
`

`

`2.3.1 Example
`
`The ODRL Usage Model can be expressed using XML. A pseudo-
`example is shown below in which the identified asset has display,
`print (with constraints), and annotate rights.
`<usage>
`<asset>
`<uid idscheme=”URI”>http://byeme.com/myasset.pdf</uid>
`</asset>
`<display/>
`<print>
`<constraint> ... </constraint>
`</print>
`<annotate/>
`...
`</usage>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 21.
`
`2.4 Rights
`Constraint
`Model
`
`ODRL supports the expression of Rights Constraints. This is the
`recognised set of restrictions on the usage rights over the Asset. This is
`shown in Figure 4.
`
`ODRL-FoundationModel::Constraint
`
`0..*
`
`111111
`
`ODRL-FoundationModel::Usage
`
`User
`
`uid
`idScheme
`
`Device
`
`uid
`idScheme
`
`Range
`
`Temporal
`
`Spatial
`
`Aspect
`
`start
`end
`
`uid
`idScheme
`
`Country
`
`Individual
`
`Group
`
`Network
`
`Count
`
`CPU
`
`Storage
`
`Memory
`
`Date Time
`
`start
`end
`
`Accumulated
`
`Quality
`
`tonality
`resolution
`color
`
`SubUnit
`
`unitType
`
`Screen
`
`IP Address
`
`Printer
`
`Interval
`
`Format
`
`Figure 4. ODRL Constraints Model
`
`The Constraint entity consists of an aggregation of six abstract entities:
`• User - indicates a set of constraints which limits usage to identified
`user(s) (realised with: Individual, Group).
`
`© IPR Systems Pty Ltd, 2000
`
`7 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 7
`
`

`

`• Device - indicates a set of constraints which limits usage to
`physical devices (realised with: Network, CPU, Screen, Storage,
`Printer, Memory).
`• Range - indicates a set of constraints which limits usage to a fixed
`number or extent (realised with: Count, IP Address).
`• Temporal - indicates a set of constraints which limits usage to
`temporal boundaries (realised with: Date Time, Accumulated,
`Interval).
`• Spatial - indicates a set of constraints which limits usage to spatial
`boundaries (realised with: Country).
`• Aspect - indicates a set of constraints which limits usage to distinct
`features of the asset (realised with: Quality, SubUnit, Format).
`
`Additionally, all Constraints can be subject to an “Exclusivity”
`attribute that indicates if the constraint is exclusive or not.
`
`A Constraint is associated with one Usages. Constraints can also have
`zero or more other Constraints.
`
`Any Constraint that is expressed but can not be performed by the
`consuming system, must not be granted. That is, if a system does not
`understand how to guarantee that a specified constraint be honoured
`it must not grant the Usage right an all.
`Complete and formal semantics for the ODRL Constraint Model
`properties and attributes are specified in Section 3.3 "Constraint
`Semantics" on page 15.
`
`The ODRL Constraint Model can be expressed using XML. A pseudo-
`example is shown below in which the display usage right is
`constrained to a particular network within an identified IP address
`range.
`<display>
`<constraint>
`<network>
`<constraint>
`<ipaddress start=”111.222.333.1” end =”111.222.333.255” />
`<constraint>
`</network>
`</constraint>
`</display>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 21.
`
`Important Note
`
`2.4.1 Example
`
`2.5 Rights Narrow
`Model
`
`ODRL supports the expression of Narrowing of Rights. This is the
`ability to specify if the current Rights can be modified (narrowed or
`
`© IPR Systems Pty Ltd, 2000
`
`8 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 8
`
`

`

`2.5.1 Example
`
`removed) when re-issuing a Rights expression. This is shown in
`Figure 5.
`
`ODRL-FoundationModel::Narrow
`
`1..*1..*1..*1..*1..*1..* ODRL-FoundationModel::Usage
`
`ODRL-FoundationModel::Constraint
`
`Figure 5. ODRL Narrow Model
`
`The Narrow entity is an aggregation of one other existing entity:
`• Constraint - indicates any constraints that the Narrow rights must
`conform to.
`Complete and formal semantics for the ODRL Narrow Model
`properties and attributes are specified in Section 3.4 "Narrow
`Semantics" on page 20.
`
`The ODRL Narrow Model can be expressed using XML. A pseudo-
`example is shown below in which sell and lend transfer rights exist for
`the identified asset and narrow rights are applicable and are also
`constrained to a particular country.
`<rights>
`<asset>
`<uid idscheme=”URI”>http://byeme.com/myasset.pdf</uid>
`</asset>
`<usage>
`<sell/>
`<lend/>
`</usage>
`<narrow>
`<constraint>
`<country>
`<uid idscheme=”ISO3166”> AU </uid>
`</country>
`</constraint>
`</narrow>
`</rights>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 21.
`
`© IPR Systems Pty Ltd, 2000
`
`9 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 9
`
`

`

`2.6 Rights Reward
`Model
`
`ODRL supports the expression of Rights Rewards. This is the
`recognised set of rewarding mechanisms for the usage of the Asset
`and the Rights Holders (parties). This is shown in Figure 6.
`
`ODRL-FoundationModel::Reward
`
`
`
`1..*1..*1..*1..*1..*1..*
`
`ODRL-FoundationModel::Party
`
`Money
`
`currency
`
`Fixed
`
`amount
`
`Percentage
`
`value
`
`Figure 6. ODRL Rewards Model
`
`The Reward entity is an aggregation of one abstract entity:
`• Money - indicates a set of financial rewards associated with the
`usage of an Asset (realised with: Fixed, Percentage).
`
`One or more Parties must be identified with the Rewards expression.
`The Role of the Party may also be indicated.
`Complete and formal semantics for the ODRL Reward Model
`properties and attributes are specified in Section 3.5 "Reward
`Semantics" on page 20.
`
`The ODRL Rewards Model can be expressed using XML. A pseudo-
`example is shown below in which two identified parties share the
`financial rewards with 90% to the Author and 10% to the Publisher.
`<reward>
`<percentage value=”90” currency=”AUD”>
`<party>
`<uid idscheme=”X500”>c=FOO;o=Federal Library;ou=Registry;
`cn=Maria Brown</uid>
`
`<role>Author</role>
`</party>
`</percentage>
`<percentage value=”10” currency=”AUD”>
`<party>
`<uid idscheme=”X500”> c=FOO;o=Federal Library;ou=Registry;
`cn=Bye Me Inc</uid>
`
`<role>Publisher</role>
`</party>
`
`2.6.1 Example
`
`© IPR Systems Pty Ltd, 2000
`
`10 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 10
`
`

`

`</percentage>
`</reward>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 21.
`
`2.7 Rights
`Administration
`Model
`
`ODRL supports the Administrative information about the Rights
`expression. This is shown in Figure 7.
`
`ODRL-FoundationModel::Administration
`
`2.7.1 Example
`
`ODRL-FoundationModel::Party
`
`ODRL-ContraintsModel::Date Time
`
`Figure 7. ODRL Administration Model
`
`The Administration entity is an aggregation of two other existing
`entities:
`• Party - indicates who is responsible for maintenance of this Rights
`expression).
`• Date Time - indicates the valid date range for the Rights
`expression.
`Complete and formal semantics for the ODRL Administration Model
`properties and attributes are specified in Section 3.6 "Administration
`Semantics" on page 21.
`
`The ODRL Administration Model can be expressed using XML. A
`pseudo-example is shown below in which the Rights expression is
`managed by the identified party (the Rights Cataloguer) and is valid
`for a two year period.
`<rights>
`<admin>
`<party>
`<uid idscheme=”X500”> c=FOO;o=Federal Library;ou=Registry;
`cn=Maria Brown</uid>
`<role>Rights Cataloguer</role>
`</party>
`<datetime start=”2000-01-01” end=”2001-12-31”/>
`</admin>
`...
`</rights>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 21.
`
`© IPR Systems Pty Ltd, 2000
`
`11 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 11
`
`

`

`3 Semantics
`
`3.1 Foundation
`Semantics
`
`Rights
`
`This section details the semantics of all the properties and attributes
`used in the ODRL Models.
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`rights
`The digital expression of intellectual property rights
`over an asset
`mandatory
`usage
`reward
`administration
`asset
`narrow
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`usage
`A defined set of actions or operations allowed over
`an asset
`mandatory
`use
`transfer
`reuse
`
`Identifier
`Definition
`
`reward
`Any form of value that may be exchanged for
`agreement to the conditions of the rights
`expressions
`optional
`Cardinality
`Content (entities) money
`party
`
`Identifier
`Definition
`
`Comment
`Cardinality
`Content
`
`asset
`Any object (digital or physical) of value which rights
`can be assigned
`Must be uniquely identifiable
`mandatory
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`Usage Rights
`
`Reward
`
`Asset
`
`© IPR Systems Pty Ltd, 2000
`
`12 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 12
`
`

`

`Party
`
`Identifier
`Definition
`
`Comment
`Cardinality
`Content
`
`party
`An identifiable person or organisation to which
`rights may be assigned over assets
`Must be uniquely identifiable
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`role - role played by the party (entity)
`
`3.2 Usage
`Semantics
`
`Use
`
`Identifier
`Definition
`
`Comment
`
`Cardinality
`Content (entities)
`
`use
`A set of Usage rights pertaining to the end use of an
`asset
`This entity is abstract and used to group common
`Rights Usages.
`optional
`display
`print
`play
`execute
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`display
`The act of rendering the asset onto a screen or visual
`device
`optional
`constraint
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`print
`The act of rendering the asset onto paper or hard
`copy form
`optional
`constraint
`
`Identifier
`Definition
`Cardinality
`Content (entities)
`
`play
`The act of rendering the asset into audio/video form
`optional
`constraint
`
`Use: Display
`
`Use: Print
`
`Use: Play
`
`© IPR Systems Pty Ltd, 2000
`
`13 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 13
`
`

`

`Use: Execute
`
`Transfer
`
`Transfer: Sell
`
`Transfer: Lend
`
`Transfer: Give
`
`Reuse
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`execute
`The act of rendering the asset into machine-readable
`form
`optional
`constraint
`
`Identifier
`Definition
`
`Comment
`
`Cardinality
`Content (entities)
`
`transfer
`A set of Usage rights pertaining to the transfer of
`ownership of an asset
`This entity is abstract and used to group common
`Rights Usages
`optional
`sell
`lend
`give
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`sell
`The act of allowing the asset to be sold for exchange
`of value
`optional
`constraint
`
`Identifier
`Definition
`
`Comment
`Cardinality
`Content (entities)
`
`lend
`The act of allowing the asset to be available for
`temporary use then returned
`Time-based constraints are required
`optional
`constraint (mandatory)
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`give
`The act of allowing the asset to be given away
`(without exchange of value)
`optional
`constraint
`
`Comment
`
`Identifier
`Definition
`
`reuse
`A set of Usage rights pertaining to the re-utilisation
`of an asset
`This entity is abstract and used to group common
`Rights Usages.
`optional
`Cardinality
`Content (entities) modify
`copy
`annotate
`
`© IPR Systems Pty Ltd, 2000
`
`14 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 14
`
`

`

`Reuse: Modify
`
`Reuse: Copy
`
`Reuse: Annotate
`
`3.3 Constraint
`Semantics
`
`Constraint
`
`User
`
`User: Individual
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`modify
`The act of changing parts of the asset creating a new
`asset
`optional
`constraint
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`copy
`The act of extracting parts (or all) of the asset for
`reuse into another asset
`optional
`constraint
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`annotate
`The act of adding notations/commentaries to the
`asset creating a new asset
`optional
`constraint
`
`Identifier
`Definition
`Cardinality
`Content (entities)
`
`constraint
`A restriction that applies to the Usage of an asset
`optional
`user
`device
`range
`temporal
`spatial
`aspect
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content (entities)
`
`user
`Any human or organisation
`This entity is abstract and used to group common
`Constraints
`optional
`individual
`group
`
`Identifier
`Definition
`Cardinality
`Content
`
`individual
`An identifiable party acting as an individual
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`© IPR Systems Pty Ltd, 2000
`
`15 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 15
`
`

`

`User: Group
`
`Device
`
`Device: Network
`
`Device: CPU
`
`Device: Screen
`
`Identifier
`Definition
`
`Cardinality
`Content
`
`group
`A number of identifiable party acting as a collection
`of individuals
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`Identifier
`Definition
`Comment
`
`device
`Any electronic or digital equipment
`This entity is abstract and used to group common
`Constraints
`optional
`Cardinality
`Content (entities) Network
`CPU
`Screen
`Storage
`Printer
`Memory
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`
`Identifier
`Definition
`
`Cardinality
`Content
`
`Identifier
`Definition
`Comment
`Cardinality
`Content
`
`network
`An identifiable data network
`If below attributes are not sufficient, then IP Address
`Range can also be used to limit the network.
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`cpu
`An identifiable system with a central processing
`unit (CPU)
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`screen
`An identifiable display output screen device
`For example, a screen reader or braille device
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`© IPR Systems Pty Ltd, 2000
`
`16 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 16
`
`

`

`Device: Storage
`
`Device: Printer
`
`Device: Memory
`
`Range
`
`Range: Count
`
`Identifier
`Definition
`Comment
`Cardinality
`Content
`
`Identifier
`Definition
`Cardinality
`Content
`
`Identifier
`Definition
`Comment
`Cardinality
`Content
`
`storage
`An identifiable storage media device
`For example, a hard disk or removable cartridge
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`printer
`An identifiable hard copy printer
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`memory
`An identifiable memory device
`For example, the clipboard
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`Comment
`
`Identifier
`Definition
`
`range
`The numeric limits within which any entity can
`function
`This entity is abstract and used to group common
`Constraints.
`optional
`Cardinality
`Content (entities) Count
`IP Address
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`(attributes)
`
`count
`A numeric value range
`If there is no “start” or “end” value, then the range is
`open-ended. Integer, Floats and negative numbers
`must be supported. Start/End are also synonyms for
`Minimum/Maximum.
`optional
`start - the beginning of the range (inclusive)
`end - the end of the range (inclusive)
`
`© IPR Systems Pty Ltd, 2000
`
`17 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 17
`
`

`

`Range: IP
`Address
`
`Temporal
`
`Temporal: Date
`Time
`
`Temporal:
`Accumulated
`
`Temporal: Interval
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`(attributes)
`
`ipaddress
`A network IP address range
`There must be “start” and “end” values specified.
`The IP address format must be supported (Eg
`xxx.xxx.xxx.xxx).
`optional
`start - the beginning of the range (inclusive)
`end - the end of the range (inclusive)
`
`Identifier
`Definition
`Comment
`
`temporal
`The time limits within which any entity can function
`This entity is abstract and used to group common
`Constraints. [ISO8601] Date format must be
`supported for all values.
`optional
`Cardinality
`Content (entities) Date Time
`Accumulated
`Interval
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`(attributes)
`
`Identifier
`Definition
`Cardinality
`Content
`
`Identifier
`Definition
`
`Cardinality
`Content
`
`datetime
`A date/time-based range
`If there is no “start” and/or “end” value, then the
`range is open-ended.
`optional
`start - the beginning of the range (inclusive)
`end - the end of the range (inclusive)
`
`accumulated
`The maximum amount of metered usage time
`optional
`data value
`
`interval
`Recurring period of time in which rights can be
`exercised
`optional
`data value
`
`© IPR Systems Pty Ltd, 2000
`
`18 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 18
`
`

`

`Spatial
`
`Spatial: Country
`
`Aspect
`
`Aspect: Quality
`
`Aspect: SubUnit
`
`Identifier
`Definition
`Comment
`
`spatial
`Any geographical range or extent
`This entity is abstract and used to group common
`Constraints.
`optional
`Cardinality
`Content (entities) Country
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`
`country
`Specification of a Country code
`Recommended best practice is to use the codes
`specified by the [ISO3166] Scheme.
`optional
`uid - unique identifier (entity)
`idScheme - scheme used for the uid (attribute)
`
`Identifier
`Definition
`Comment
`
`aspect
`Any distinct feature of the Asset
`This entity is abstract and used to group common
`Constraints
`optional
`Cardinality
`Content (entities) Quality
`SubUnit
`Format
`
`Identifier
`Definition
`Cardinality
`Content
`(attributes)
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`
`quality
`Specification of quality aspects of the asset
`optional
`tonality - the bit-depth
`resolution - the pixel size
`color - the number of colors
`
`subunit
`Specification of any sub-part of the asset
`The values for the unittype attribute should be from
`a well known vocabulary and the source clearly
`identified.
`optional
`unittype (attribute)
`constraint (entity)
`
`© IPR Systems Pty Ltd, 2000
`
`19 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 19
`
`

`

`Aspect: Format
`
`3.4 Narrow
`Semantics
`
`Narrow
`
`3.5 Reward
`Semantics
`
`Money
`
`Money: Fixed
`
`Money:
`Percentage
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`
`format
`Specification of format(s) of the asset
`The values are taken from the Internet Media Type
`[IMT] list.
`optional
`data value
`
`Identifier
`Definition
`Cardinality
`Content (entities)
`
`narrow
`Specifies modification of down-stream Rights
`optional
`constraint
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content (entities)
`
`money
`Rewards in the form of financial payments
`This entity is abstract and used to group common
`Reward types.
`optional
`Fixed
`Percentage
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`(attributes)
`
`Identifier
`Definition
`Comment
`
`Cardinality
`Content
`(attributes)
`
`fixed
`A fixed monetary value
`The total of the Fixed values for a single asset must
`not exceed the Retail Price.
`optional
`amount - the value of the payment (an positive
`integer to two decimal places)
`currency - the currency for the amount (use
`[ISO4217] codes)
`
`percentage
`A proportion of the value of the asset
`The total of the Percentage values for a single asset
`must not exceed 100%.
`optional
`value - a number from 0 to 100 inclusive
`currency - the currency for the amount (use
`[ISO4217] codes)
`
`© IPR Systems Pty Ltd, 2000
`
`20 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 20
`
`

`

`3.6 Administration
`Semantics
`
`Administration
`
`4 Syntax
`
`4.1 Ebook Use
`Case #1
`
`Identifier
`Definition
`
`Cardinality
`Content (entities)
`
`admin
`Administrative information about the Rights
`expression
`optional
`party
`datetime
`
`ODRL can be expressed in [XML] (see [DTD] in Appendix A and [XML
`SCHEMA] in Appendix B for formal definitions). However, it is also
`conceivable that ODRL could be expressed in other syntaxes.
`ODRL is XML Namespace aware as its primary target is use with other
`content description and management systems. The ODRL XML
`Namespace URI for this version is:
`http://odrl.net/0.7/
`The final Version 1.0 ODRL XML Namespace URI will be:
`http://odrl.net/1.0/
`NOTE: These URIs should be considered experimental until the ODRL
`specification is formalised by an appropriate body and a new URI
`assigned.
`ODRL uses XML XLink [XLINK] to refer from XML fragments to other
`fragments. This is used to express the relationship between the core
`ODRL entities such as Asset, Reward, and Usage. Such elements can be
`identified with the standard ID attribute then referred to via XLink’s
`href attribute.
`
`All elements can also have optional Name and Remark elements for
`human-readable documentation.
`
`The XML syntax will be explained via a serious of Use Cases covering
`different content sectors (ebooks, image, audio, video).
`
`Corky Rossi (an author) and Addison Rossi (an illustrator) publish
`their ebook via “EBooksRUS Publishers”. They wish to allow
`consumers to purchase the ebook which is restricted to a single CPU
`only and they are allowed to print a maximum of 2 copies. They will
`also allow the first 5 pages (SubUnits) of the ebook to be viewed online
`for free.
`
`The revenue split is $AUD 10.00 to the Author, $AUD 2.00 to the
`Illustrator and $AUD 8.00 to the Publisher.
`
`© IPR Systems Pty Ltd, 2000
`
`21 of 27
`
`Petitioner Apple Inc. - Exhibit 1028, p. 21
`
`

`

`Massimo DiAngelo from “EBooksRUS Publishers” is responsible for
`maintaining the Rights metadata which has a policy of one year
`validity on all its metadata.
`The XML encoding of this in ODRL would be:
`<?xml version="1.0"?>
`<rights
`xmlns="http://odrl.net/0.7/"
`xmlns:xlink="http://www.w3.org/1999/xlink">
`<admin>
`<party>
`<uid idscheme=”DOI”>doi://10.9999/EP/mdiangelo-001</uid>
`<role>Rights Manager</role>
`</party>
`<datetime start=”2000-07-01” end=”2001-06-30”/>
`</admin>
`<asset ID=”001”>
`<uid idscheme=”DOI”>doi://10.9999/EB/rossi-0001</uid>
`<name> How to Wash Cats </name>
`</asset>
`<usage ID=”002”>
`<asset xlink:href=”#001”>
`<reward xlink:href=”#003”>
`<display>
`<remark> Constrain to a particular CPU only </remark>
`<constraint>
`<cpu/>
`</constraint>
`</display>
`<print>
`<remark> Can only Print 2 Copies </remark>
`<constraint>
`<count start=”0” end=”2”/>
`</constraint>
`</print>
`</usage>
`<reward href=”#003”>
`<fixed amout=”10.00” currency=”AUD”>
`<party>
`<uid idscheme=”DOI”>doi://10.9999/EP/crossi-001</uid>
`<role>Author</role>
`</party>
`</fixed>
`<fixed amout=”2.00” currency=”AUD”>
`<party>
`<uid idscheme=”DOI”>doi://10.9999/EP/arossi-001</uid>
`<role>Illustrator</role>
`</party>
`</fixed>
`<fixed amout=”8.00” currency=”AUD”>
`<party>
`<uid i