throbber
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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket