@l Open Digital Rights Language
`(ODRL)
`Version: 0.8
`Date: 2000-11-21
`
`This Version: <http://odrl.net/ODRL-08.pdf>
`
`Previous Versions: <http://odrl.net/ODRL—07.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.7
`
`|
`
`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 [I-llGGS].
`
`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 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4001
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4001
`
`

`
`
`
`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
`
`@@Ri_l5J
`
`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 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4002
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4002
`
`

`
`
`
`achieved by abstracting and reusing such architectures to enable
`trusted metadata expressions about digital assets.
`
`1.2 About this
`Specification
`
`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.
`
`2 ODRL
`
`2.1 Scope
`
`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 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4003
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4003
`
`

`
`
`
`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 [D01]
`
`ONIX International [ONIX]
`MPEG
`IMS
`
`Dublin Core Metadata Initiative [DCMI]
`
`Propagate Project [PROPAGATE]
`
`|
`
`|
`
`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.
`
`Figure 2. ODRL Foundation Model
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`4 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4004
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4004
`
`

`
`
`
`The Rights entity consists of Usage. Constraint, Narrow, and
`RightsHolder which together enable the expression of digital rights
`over the identified Asset and their Rights Holders (parties). The
`Parties’ Role with respect to their entitlements 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
`using unique identification mechanisms (such as [URI], [D01]. [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.] "Foundation
`Semantics“ on page 12.
`
`The ODRL Foundation Model can be expressed using XML. A pseudo-
`example is shown below:
`<rights>
`<asset>
`
`<uid idscheme="URl">http://byeme.com/myasset.pdf</uid>
`</asset>
`
`2.2.1 Example
`
`<usage>
`<usage-iype>
`
`<oonstraint>
`
`</constraint>
`
`</usage-!ype>
`<usage-type>
`
`<constraint>
`
`</constraint>
`
`</usage-!ype>
`
`</usage>
`<narrow>
`
`<lnarrow>
`
`<rightsholder>
`<party>
`
`<ro|e>
`
`</ro|e>
`
`</party>
`
`</rightsho|der>
`<admin>
`
`</party>
`<party>
`<datetime> .. </datetime>
`</admin>
`
`<Irights>
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`5 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4005
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4005
`
`

`
`
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 22.
`
`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-Fountiallonlllodelrzllavro
`
`ll..'
`
`/
`
`
`
`
`ODRL-FaundatlonI»lodeI::Usage
`
`1,.‘
`
`0.: ODRL-FoundationlnodeI::Constraint
`
`'
`
`ODRL-Foundation!ulodel::Asset
`
`
`
`
`A
`
`A
`
`
`E A
`
`
`
`magnu-
`
`Mod‘
`
`Annotate
`
`
`
`Figure 3. ODRL Usages Model
`
`The Usage entity consists of an aggregation of three abstract entities:
`
`0 Use — indicates a set of usages in which the Asset can be consumed
`(realised with: Display, Print, Play, Execute).
`
`0 Transfer - indicates a set of usages in which the rights over the
`Asset can be transferred (realised with: Sell, Lend. Give).
`
`0 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. For any rights expression,
`all Usages are "and—ed" together including their 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 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4006
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4006
`
`

`
`
`
`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="UR|“>http://byeme.comlmyasset.pdf</uid>
`</asset>
`
`</constraint>
`
`<display/>
`<print>
`<constraint>
`
`</print>
`<annotate/>
`
`</usage>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 22.
`
`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.
`
`0".
`
`ODRL-Foundationllodelzzconstraint I 1
`°
`
`ODRL-Foundationlilodel::Usage
`
`MMuid
`
`A
`
`‘
`
`il5d1en1e
`A
`
`‘
`
`resolution
`
`@
`
`Figure 4. ODRL Constraints Model
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`7 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4007
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4007
`
`

`
`
`
`The Constraint entity consists of an aggregation of six abstract entities:
`
`0 User - indicates a set of constraints which limits usage to identified
`user(s) (realised with: Individual, Group).
`
`indicates a set of constraints which limits usage to
`0 Device —
`physical devices (realised with: Network. CPU, Screen. Storage.
`Printer, Memory).
`
`0 Bounds - indicates a set of constraints which limits usage to a fixed
`number or extent (realised with: Count, Range. IP Address).
`0 Temporal — indicates a set of constraints which limits usage to
`temporal boundaries (realised with: Date Time, Accumulated.
`Interval).
`
`0 Spatial — indicates a set of constraints which limits usage to spatial
`boundaries (realised with: Country).
`0 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 Usage. If a Constraint appears at
`the same level as a number of Usages. then the Constraint applies to
`all of the Usages. Constraints can also have zero or more other
`Constraints. For Usages with multiple constraints, all contraints must
`be “and-ed" together and no conflicts should arise. An error must be
`generated if the latter is true.
`
`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 at all.
`
`|
`
`Complete and formal semantics for the ODRL Constraint Model
`properties and attributes are specified in Section 3.3 "Constraint
`Semantics" on page 16.
`
`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.
`
`<disp|ay>
`<constraint>
`<network>
`<constraint>
`
`<ipaddress start='111.222.333.1" end ="111.222.333.255" I>
`<constraint>
`</network>
`</constraint>
`
`</disp|ay>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 22.
`
`Important Note
`
`2.4.1 Example
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`8 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4008
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4008
`
`

`
`
`
`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
`removed) when re~issuing the Rights expression. This is shown in
`Figure 5.
`
`|
`
`0DRL-FoundalionMode|::Narrow
`
`" ODRL-FoundalionModel::Usage
`
`
`
`ODRL-FoundationModel:zconstraint
`
`2.5.1 Example
`
`Figure 5. ODRL Narrow Model
`
`The Narrow entity is an aggregation of one other existing entity:
`
`0 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="URl'>http://byeme.com/myasset.pdf</uid>
`</asset>
`
`<usage>
`<se||/>
`<Iend/>
`<narrow>
`<constraint>
`
`<country>
`<uid idscheme="|SO3166"> AU </uid>
`
`</country>
`</constraint>
`</narrow>
`
`</usage>
`</righls>
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 22.
`
`2.6 RightsHolder
`Model
`
`ODRL supports the identification of Rights Holders. This is the
`recognised Party, their (optional) Role. and any set of rewarding
`
`In
`
`
`© IPR Systems Pty Ltd, 2000
`
`9 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4009
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4009
`
`

`
`
`
`mechanisms for the usage of the Asset for the Rights Holder. This is
`shown in Figure 6.
`
`|
`
`.. ODRL-FoundaiioniflodelzzParty
`
`ODRL-FoundationModei::Rightsflolder
`
`ODRL-FoundationMode|::Role
`
`2.6.1 Example
`
`Figure 6. ODRL Rights Holder Model
`
`|
`
`The RightsHolder entity is an aggregation of one abstract and one
`existing entity:
`
`0 Money - indicates a set of financial rewards associated with the
`usage of an Asset (realised with: Fixed, Percentage).
`0 Party - indicates the Rights Holder and the role they play.
`
`One or more Parties must be identified with the RightsHolder
`expression. The Role of the Party may also be indicated.
`
`Complete and formal semantics for the ODRL RightsHolder Model
`properties and attributes are specified in Section 3.5 "RightsHolder
`Semantics" on page 21.
`
`The ODRL RightsHo1der Model can be expressed using XML. A
`pseudo-example is shown below in which two identified Rights
`Holders (parties) share the financial rewards with 90% to the Author
`and 10% to the Publisher.
`
`<rightsho|der>
`<party>
`<uid idscheme="X500“>c=FOO;o=Federa| Library;ou=Registry;
`cn=Maria Brown</uid>
`
`<roie>Author</roIe>
`
`<percentage va|ue="90" currency="AUD"/>
`</party>
`<party>
`<uid idscheme="X500”> c=FOO;o=Federal Library;ou=Registry;
`cn=Bye Me Inc</uid>
`
`<role>Publisher</role>
`
`<percentage vaiue='10" currency="AUD"/>
`</party>
`<lrightsholder>
`
`
`© IPR Systems Pty Ltd. 2000
`
`10 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4010
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4010
`
`

`
`
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 22.
`
`2.7 Rights
`AdminiSl|'ali0n
`Model
`
`ODRL supports the Administrative information about the Rights
`expression. This is shown in Figure 7.
`
`0
`
`
`
`
`
`
`
`
`
`2.7.1 Example
`
`Figure 7. ODRL Administration Model
`
`The Administration entity is an aggregation of three other existing
`entities and one new entity:
`
`0 Party — indicates who is responsible for maintenance of this Rights
`expression and the (optional) role they play.
`0 Date Time —
`indicates the valid date range for
`expression.
`
`the Rights
`
`|
`
`0
`
`Issue Date - indicates the date/ time that the Rights expression was
`issued.
`
`0 UID - a unique identification number 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=FO0;o=Federa| Library;ou=Registry;
`cn=Maria Brown</uid>
`
`<ro|e>Rights Cata|oguer</role>
`</pa;-ty>
`<issuedate> 2000-12-31 </issuedate>
`<datetime start="2001-01-01" end="2001-12-31'/>
`
`<uid idscheme='URl"> http://byeme.com/mybook-rights.xm|</uid>
`</admin>
`
`</rig.hts>
`
`
`© IPR Systems Ply Ltd. 2000
`
`11 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4011
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4011
`
`

`
`
`
`Complete and formal syntactical examples are given in Section 4
`"Syntax" on page 22.
`
`3 Semantics
`
`3.1 Foundation
`Semantics
`
`This section details the semantics of all the properties and attributes
`used in the ODRL Models.
`
`Rights
`
`'
`
`The digital expression of intellectual property rights
`over an asset
`
`
`
`
`
`cardinality
`Content (entities)
`
`
`usage
`
`rightsholder
`administration
`asset
`narrow
`
`
`% D
`
`
`
`efinition V
`
`A defined set of actions or operations allowed over
`an asset
`
`
`
`
`cardinality
`Content (entities)
`use
`
`transfer
`reuse
`
`
`
`% ilshtsholder
`Any party that holds any form of Rights over the
`asset
`
`
`
`cardinality
`Content (entities)
`
`Usage Rights
`
`Rights Holder
`
`Asset
`
`|
`
`|
`
`I
`
`|
`
`
`
`
`
`
`
`
`
`
`Definition
`
`Any object (digital or physical) of value which rights
`can be assigned
`Must be uniquely identifiable
`
`cardinality
`Content (entity)
`
`uid - unique identifier
`
`
`
`© IPR Sys_tems Pty Ltd. 2000
`
`12 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4012
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4012
`
`

`
`
`
`|
`
`I
`
`|
`
`
`
`
`
`
`
`
`
`
`
`
`
`uid - unique identifier
`role - role played by the party
`
`The unique identification number/code for the
`entity
`The uid may be applied to assets, parties,
`constraints and admin entities.
`
`idScheme - encoding scheme used for the unique
`identifier value
`
`The role played by the Party
`The role values may be selected from existing
`vocabulary schemes. For example:
`0 marc - MARC Code List for Relators [MARC]
`0 onix - ONIX International Contributor Role
`Code List [0 NIX]
`
`
`
`
`
`
`
`
`
`
`idScheme - identifies the vocabulary scheme used
`for the role value
`
`rights may be assigned over assetsT
`
`
`
`
`
`Content (entities)
`
`
`
`Comment
`
`
`cardinality
`Content
`
`(attribute)
`
`
`
`Comment
`
`
`
`
`
`
`
`cardinality
`Content
`
`(attribute)
`
`
`Party
`
`UID
`
`Role
`
`3.2 Usage
`Semantics
`
`Use
`
`
`
`A set of Usage rights pertaining to the end use of an
`asset
`
`Comment
`
`This entity is abstract and used to group common
`Rights Usages.
`
`cardinality
`Content (entities)
`
`© IPR Systems Pty Ltd, 2000
`
`.
`
`13 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4013
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4013
`
`

`
`
`
`Use: Display
`
`
`
`
`
`
`
`display
`The act of rendering the asset onto a screen or visual
`device
`
`Cardlnallty
`Cenlenl (entitles)
`
`
`
`Use: Print
`
`
`
`
`Im
`Definition
`The act of rendering the asset onto paper or hard
`copy form
`
`
`
`
`
`cardinality
`
`
`
`Use: Play
`
`
`
`
`Use: Execute
`
`
`
`Transfer
`
`
`
`
`
`
`
`
`
`i T
`
`he act of rendering the asset into audio/video form
`
`cardinality
`
`
`
`
`
`
`
`
`
`
`
`
` The act ofrendering the asset into machine-readable
`cardinality
`
`
`form
`
`ldenllfier
`
`Comment
`
`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
`
`
`
`cardinality
`Content (entities)
`
`sell
`lend
`
`
`
`give
`
`
`
`
`
`Transfer: Sell
`
`
`
`
`The act of allowing the asset to be sold for exchange
`of value
`
`cannnamy
`cenaaesi
`
`
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`14 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4014
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4014
`
`

`
`
`
`Transfer: Lend
`
`
`
`
`temporary use then returnedT
`
`
`
`
`
`cardinality
`Content (entities)
`
`constraint (mandatory)
`
`
`
`(without exchange of value)
`
`
`
`Transfer: Give
`
`
`
`Reuse
`
`
`
`
`
`
`
`Definition
`A set of Usage rights pertaining to the re-utilisation
`of an asset
`
`
`Comment
`
`This entity is abstract and used to group common
`Rights Usages.
`
`
`
`cardinality
`Content (entities) modify
`copy
`annotate
`
`
`
`
`
`Reuse: Modify
`
`Reuse: Copy
`
`
`
`cardinality
`
`
`
`
`asset
`
`The act ofchanging pans ofthe asset creating a new
`
`
`
`
`
`
`reuse into another assetT
`
`
`
`
`
`
`
`
`
`
`Reuse: Annotate
`
`
`
`Identifier
`asset creating a new assetT
`
`
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`15 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4015
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4015
`
`

`
`
`
`3.3 Constraint
`Semantics
`
`Constraint
`
`
`
`cardinality
`Content (entities)
`
`A restriction that applies to the Usage of an asset
`
`
`
`user
`device
`
`
`
`
`
`
`bounds
`
`
`
` User
`
`
`
`
`
`
`
`
`
`
`I
`
`temporal
`spatial
`aspect
`
`
`
`Comment
`.
`
`Any human or organisation
`This entity is abstract and used to group common
`Constraints
`
`
`
`cardinality
`Content (entities)
`
`individual
`group
`
`
`
`
`
`User: Individual
`
`
`
`
`
`User: Group
`
`1%
`
`
`
`
`
`of individuals
`
`
`
`
`
`Device
`
`
`
`
`
`omment
`
`This entity is abstract and used to group common
`Constraints
`
`T C
`
`
`
`
`
`
`
`
`
`
`Content (entities)
`
`network
`cpu
`screen
`
`storage
`
`
`
`printer
`memory
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`16 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4016
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4016
`
`

`
`
`
`Device: Network
`
`ange can also be used to limit the network.
`
`
`
`
`
`
`
`
`
`
`SS R
`
`
`
`
`
`
`
`
`
`
`cardinality
`
`
`
`
`
`
`
`
`
`
`An identifiable system with a central processing
`unit (CPU)
`
`uid - unique identifier
`
`Cardinality
`Content (entity)
`
`
`
`
`
`Device: CPU
`
`Device: Screen
`
`
`
`
`
` S
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`S
`
`
`
`
`
`
`
`
`Device: Storage
`
`Device: Printer
`
`Device: Memory
`
`
`
`
`
`
`
`
`
`
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`17 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4017
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4017
`
`

`
`|
`
`[
`
`
`
`Bounds
`
`Comment
`
`cardinality
`
`The numeric limits within which any entity can
`function
`
`This entity is abstract and used to group common
`Constraints.
`
`Content (entities)
`
`Bounds: Count
`
`
`
`
`A numeric count indicating the number of times the
`corresponding entity may be exercised
`
`Comment
`
`
`
`
`
`
`
`
`
`For example. the Print usage may be constraint with
`a count of 1 to 10 meaning that the asset can be
`printed once or up to 10 times. If there is no “start”
`or "end" value, then the count is open-ended.
`Integer. Floats must be supported. Note. “start”
`must always be less than or equal to “end” and one
`must always be present.
`optional
`start - the beginning of the count (inclusive)
`end - the end of the count (inclusive)
`
`
`
`
`
`_
`
`Cardinality
`Content
`lamibutesl
`
`
`
`
`
`Definition
`
`A numeric range indicating the min/ max values of
`the corresponding entity that the constraint applies
`[0
`
`For example. this is used to specify that only pages
`numbered 1 to 10 may be printed (using the subunit
`entity). lfthere is no “min” or “max” value. then the
`range is open-ended. Integer, Floats and negative
`numbers must be supported. Note, "min" must
`always be less than or equal to "max" and one must
`always be present.
`
`Cardinality
`Content
`(attributes)
`
`min - the beginning of the range (inclusive)
`max - the end of the range (inclusive)
`
`Bounds: Range
`
`Bounds: IP
`Address
`
`
`
` A network IP address range
`
`
`
`Comment
`There must be "start" and “end” values specified.
`The IP address format must be supported (Eg
`
`xxx.xxx.xxx.xxx).
`
`
`Cardinality
`Content
`
`(attributes)
`
`start - the beginning of the range (inclusive)
`end - the end of the range (inclusive)
`
`
`
`.
`
`© IPR Systems Pty Ltd, 2000
`
`13 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4018
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4018
`
`

`
`
`
`Temporal
`
`Comment
`
`
`
`
`
`
`The time limits within which any entity can function
`
`
`This entity is abstract and used to group common
`Constraints. [ISO860l] Date format must be
`
`supported for all values.
`
`
`Catdinaiity
`Content (entities) Date Time
`
`
`
`Accumulated
`
`Interval
`
`
`m
`
`Temporal: Date
`Time
`
`
`
`
`
`
`
`
`
`ET
`
`
`
`
`
`
`Content
`
`start - the beginning of the range (inclusive)
`
`end - the end ofthe range (inclusive)
`
`T I
`
`fthere is no “start” and/or "end" value, then the
`
`range is open-ended.
`
`
`
`Temporal:
`Accumulated
`
`Temporal: Interval
`
`Spatial
`
`Spatial: Country
`
`
`iiiemiiiei
`neiniion
`
`
`caiiiiiiaiiiy
`
`
`
`
`
`
`Catdinaiity
`
`Content
`
`Recurring period of time in which rights can be
`exercised
`
`
`
`
`
`
`
`
`
`
`
`
`
`Any geographical range or extent
`This entity is abstract and used to group common
`Constraints.
`
`Comment
`
`Content (entities)
`
`Cardinatity
`
`
`
`
`
`
`
`
`pecified by the [ISO3166] Scheme.
`
`
`mT s
`
`
`
`
`
`
`© IPR Systems Pty Ltd. 2000
`
`19 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4019
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4019
`
`

`
`
`
`
`
`
`
`Aspect
`
` Any distinct feature of the Asset
`Comment
`This entity is abstract and used to group common
`Constraints
`
`
`
`
`
`
`Cardinaltty
`
`Content (entities) Quality
`
`SubUnit
`
`Format
`
`
`
`
`
`
`
`
`
`
`
`
`
`
` Specification of quality aspects of the asset
`C°“““a'"Y
`Content
`tonality - the bit-depth
`
`(attributes)
`resolution - the pixel size
`
`color - the number of colors
`
`
`
`
`
`
` Specification of any sub—part of the asset
`Comment
`The values for the unittype attribute should be from
`a well known vocabulary and the source clearly
`identified.
`
`Aspect: Quality
`
`Aspect: SubUnit
`
`Aspect: Fonnat
`
`
`
`
`
`
`
`
`
`Cardinality
`
`Content
`
`
`unittype (attribute)
`constraint (entity)
`
`Specification of format(s) of the asset
`
`The values are taken from the Internet Media Type
`[IMT] list.
`
`
`
`Comment
`
`Cardinality
`
`
`
`3.4 Narrow
`Semantics
`
`
`
`Narrow
`
`
`%
`
`
`
`Content (entities)
`
`
`
`
`
`
`© IPR Systems Pty Ltd, 2000
`
`20 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4020
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4020
`
`

`
`
`
`
` Rewards in the form of financial payments
`
`Comment
`This entity is abstract and used to group common
`Reward types for Rights Holders
`
`
`
`
`cardinality
`Content (entities)
`
`Fixed
`
`Percentage
`
`
`
`
`
`
`|
`
`
`
`
` A fixed monetary value
`Comment
`The total of the Fixed values for a single asset must
`not exceed the Retail Price.
`
`cardinality
`Content
`(attributes)
`
`amount - the value of the payment (an positive
`integer to two decimal places)
`currency - the currency for the amount (use
`[ISO4217] codes)
`
`
`
`
`
`
`
` A proportion of the value of the asset
`Comment
`The total of the Percentage values for a single asset
`must not exceed 100%.
`
`
`
`cardinality
`Content
`value - a number from 0 to 100 inclusive
` currency - the currency for the amount (use
`(attributes)
`
`[ISO4217] codes)
`
`3.5 RightsHo|der
`Semantics
`
`Money
`
`Money: Fixed
`
`Money:
`Percentage
`
`3.6 Administration
`Semantics
`
`Administration
`
`
`
`Administrative information about the Rights
`expression
`
`issuedate
`
`
`
`© IPR Systems Pty Ltd, 2000
`
`21 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4021
`
`
`
`
`cardinality
`party
`Content (entities)
`
`datetime
`uid
`
`
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4021
`
`

`
`I
`
`|
`
`|
`
`
`
`Administration:
`
`issue Date
`
`
`
`Comment
`
`Cardinal"!
`
`
`
`4 Syntax
`
`The date the Rights expression was issued/ released
`[lSO860l] Date format must be supported for all
`values.
`
`
`
`
`
`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://odr1.net/0.8/
`
`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 the new URI is
`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. Note. only the “xlink:href" attribute is required to be
`recognised to support ODRL expressions.
`
`It is important to recognise that as the ODRL expressions become more
`complicated, the need to partition and express linkages (using XLink)
`becomes paramount in order to have manageable and reusable rights
`expressions. The linking mechanism allows for quite complex
`expressions to be generated whilst preserving the interpretability of
`the overall rights language.
`
`All elements can also have optional Name and Remark elements for
`human-readable documentation. If the human language needs to be
`specified for any elements, then the use of the “xml:lang" attribute is
`recommended.
`
`The XML syntax will be explained via a serious of Use Cases covering
`different content sectors (ebooks, image, audio. video).
`
`
`4.1 Ebook Use
`Case #1
`
`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
`
`
`© IPR Systems Pty Ltd. 2000
`
`22 of 31
`
`Petitioner Apple Inc. — Exhibit 1002, p. 4022
`
`Petitioner Apple Inc. - Exhibit 1002, p. 4022
`
`

`
`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.
`
`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.8I"
`xmlns:xlink="http://www.w3.org/1999/x|ink">
`
`|
`
`<admin>
`
`<party>
`<uid idscheme='DO|'>doi://10.9999/EP/mdiangelo-001</uid>
`<role>Rights Manager</role>
`</party>
`<datetime star1="2000-07-01" end=”2001-06-30'/>
`</admin>
`
`<asset |D="001">
`<uid idscheme='DOI'>doi://