IPTC - NAA
` Information
` Interchange
` M o d e l
` V e r s i o n 4
`
`Petitioner Apple Inc. - Ex. 1037, p. Cover
`
`IPTC
`Comité International des Télécommunications de Presse
`

`

`IPTC - NAA INFORMATION INTERCHANGE MODEL
`
`Version No. 4
`Rev 1 July 1999
`
`Copy No:0000
`
`ALTHOUGH IPTC AND NAA HAVE REVIEWED THE DOCUMENTATION, IPTC AND NAA
`MAKE NO WARRANTY OR REPRESENTATION, EITHER EXPRESS OR IMPLIED, WITH
`RESPECT TO THIS DOCUMENTATION, ITS QUALITY, MERCHANTABILITY, OR FITNESS
`FOR A PARTICULAR PURPOSE. THIS DOCUMENTATION IS SUPPLIED 'AS IS', AND
`YOU, BY MAKING USE THEREOF, ARE ASSUMING THE ENTIRE RISK AS TO ITS
`QUALITY AND SUITABILITY FOR YOUR PURPOSE.
`
`IN NO EVENT WILL IPTC OR NAA BE LIABLE FOR DIRECT, INDIRECT, SPECIAL,
`INCIDENTAL, OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR
`INABILITY TO USE THE DOCUMENTATION, EVEN IF ADVISED OF THE POSSIBILITY OF
`SUCH DAMAGES.
`
`
`This document is copyrighted with all rights reserved. Under the copyright laws, it may not be
`copied, photocopied or reproduced, translated or reduced to any electronic medium or
`machine readable form, in whole or part, without the prior written consent of the International
`Press Telecommunications Council or the Newspaper Association of America. When supplied
`in electronic form this document may be printed in single copy for the sole use of the
`registered purchaser.
`
`Copyright © 1991,1993,1995,1997,1999
`
`Comité International des Télécommunications de Presse
`Sheet Street
`Windsor
`Berks SL4 1BE
`UNITED KINGDOM
`
`Newspaper Association of America
`1921 Gallows Road
`Suite 600
`Vienna
`VA 22182-3900 USA
`
`All Rights Reserved. Fourth edition Rev 1 1999. Produced in the United Kingdom.
`
`Petitioner Apple Inc. - Ex. 1037, p. 1
`
`

`

`TABLE OF CONTENTS
`
`CHAPTER 1. GENERAL
`
`CHAPTER 2. INFORMATION INTERCHANGE MODEL
`
`CHAPTER 3. RECORDS
`
`CHAPTER 4. IMPLEMENTATION GUIDELINES
`
`CHAPTER 5. ENVELOPE RECORD
`
`CHAPTER 6. AP PLICATION RECORD
`
`CHAPTER 7. DIGITAL NEWSPHOTO PARAMETER RECORD NUMBER 3
`
`CHAPTER 8. RECORD NUMBER 4 (NOT ALLOCATED)
`
`CHAPTER 9. RECORD NUMBER 5 (NOT ALLOCATED)
`
`CHAPTER 10. ABSTRACT RELATIONSHIP RECORD NUMBER 6
`
`CHAPTER 11. PRE-OBJECTDATA DESCRIPTOR RECORD
`
`CHAPTER 12. OBJECTDATA RECORD NUMBER 8
`
`CHAPTER 13. POST-OBJECTDATA DESCRIPTOR RECORD NUMBER 9
`
`APPENDIX A. FILE FORMATS (DATASET 1:20)
`
`APPENDIX B. ADDRESSES OF ORGANISATIONS MENTIONED
`
`APPENDIX C. THE IPTC-NAA CODE LIBRARY
`
`APPENDIX D. THE IPTC-NAA COUNTRY CODES
`
`APPENDIX E. INFORMATION PROVIDERS REFERENCE
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`2
`
`July 1999
`
`4
`
`11
`
`13
`
`16
`
`18
`
`24
`
`45
`
`45
`
`45
`
`45
`
`45
`
`46
`
`46
`
`47
`
`49
`
`50
`
`53
`
`54
`
`Petitioner Apple Inc. - Ex. 1037, p. 2
`
`

`

`APPENDIX F. ABSTRACT RELATIONSHIP METHOD IDENTIFIERS
`
`APPENDIX G. OBJECT TYPE NUMBER AND OBJECT TYPE NAME
`RELATIONSHIP
`
`55
`
`56
`
`APPENDIX H. OBJECT ATTRIBUTE NUMBER AND OBJECT ATTRIBUTE NAME
`RELATIONSHIP
`56
`
`APPENDIX I. SUBJECT REFERENCE NUMBER AND SUBJECT NAME
`RELATIONSHIP
`
`57
`
`APPENDIX J. SUBJECT MATTER NAME AND SUBJECT REFERENCE NUMBER
`RELATIONSHIP
`59
`
`APPENDIX K. SUBJECT DETAIL NAME AND SUBJECT REFERENCE NUMBER
`RELATIONSHIP (ECONOMY, BUSINESS & FINANCE)
`
`65
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`3
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 3
`
`

`

`IPTC-NAA INFORMATION INTERCHANGE MODEL PART I
`
`Chapter 1. GENERAL
`
`
`Section 1.1 INTRODUCTION
`
`
`Section 1.2 World-wide standardisation has become an acknowledged requirement
`in the graphics and information industry. In telecommunications, standardisation is
`centred upon the widely accepted seven-layer "Open Systems Interconnection" (OSI)
`model. While the lower five or six layers of this model are filled by other bodies, such
`as telecommunications companies or administrations, the CCITT, the ISO and
`manufacturers, it remains the responsibility of the users of information to define the
`model for the dissemination of data.
`
`Section 1.3 The Newspaper Association of America (NAA) and the International
`Press Telecommunications Council (IPTC) have worked jointly to design a globally
`applicable model for all kinds of data. Every effort has been made for this model to be
`as compatible as possible with ISO and CCITT standards in the fields of application.
`The joint effort will continue for further development and for amendment when
`advisable.
`
`Section 1.4 This model is designed to provide for universal communications
`embracing all types of data, including text, photos, graphics, etc. on a single network
`or a single storage medium. A mechanism is provided to use existing formats during
`transition.
`
`Section 1.5 The model assumes that the sender wishes to transfer a data object,
`such as a photographic image, text or perhaps a combination of many types. An
`envelope is provided around the object for information as to the type of data and the
`file format. Additional information, such as caption, news category or dateline also is
`included. The object itself is transferred, together with information regarding the size of
`the data.
`
`Section 1.6 Thus ANY form of computerised data may be transferred, together with
`pertinent editorial and technical information.
`
`Section 1.7 Older practice consisted primarily of rigidly formatted "headers" with a
`number of required fields denoting such things as story priority or category. The model
`here presented has relatively few required pieces of information. Instead, the informa-
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`4
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 4
`
`

`

`tion about the object consists of "DataSets," each with its own identifier. Only those
`DataSets required for an application are mandatory. Other DataSets are optional and
`are utilised only when the provider deems it necessary to do so.
`
`
`Section 1.8 SCOPE
`
`This document defines:
`-
`The envelope for information.
`-
`The method by which existing standards for news information can be
`included.
`The records for additional information about the object.
`-
`The data structure to be used for presentation of information.
`-
`An application record to provide pertinent editorial information about
`-
` the object to be transmitted.
`-
`Guidelines for implementation.
`
`Section 1.9 FIELD OF APPLICATION
`
`(a) This document applies to the digital data distributed by news service carriers to
`their subscribers or interchanged between individual users.
`
`
`
`Section 1.10 RELATION TO OSI
`
`
`(a) This document describes the standardised representation of news information
`for the applications layer (Layer 7) of the ISO Open Systems Interconnection
`Model (OSI). NOTE: The association to OSI layers may be redefined as OSI
`connectionless application standards are developed.
`
`Section 1.11 MODEL DEVELOPMENT
`
`
`(a) The introduction of new DataSets (or dropping of old) in records 1, 2, 7, 8 and 9
`will occur only after international concurrence.
`
`(b) Records 3 through 6 will be managed by originators of the formats contained in
`record No. 1.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`5
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 5
`
`

`

`TERMS, DEFINITIONS AND NOTATION
`
`For the purpose of this recommendation, the following definitions apply:
`
`Section 1.12 Actuality: The sound of a newsmaker, e.g. from a speech, interview,
`etc. Also known as a "sound bite."
`
`Section 1.13 AIFF: A sound file format for the Apple Macintosh, can be converted to
`WAVE and vice versa.
`
`Section 1.14 alphabetic, alphabetic character: An alphabetic character is member
`of a set of characters representing letters of the alphabet.
`
`Example: In the ISO 646 character set, alphabetic characters are between
`4/1 and 5/10 (A through Z) and between 6/1 and 7/10 (a through z), all
`inclusive. Alphabetic characters are shown in this document enclosed in
`single quotation marks, e.g. 'a', 'T', 'u'.
`A series of alphabetic characters is shown in double quotation marks, e.g.
`"IPTC", "Berlin", "Paris".
`
`Section 1.15 binary number: A series of n data bits bn-1, bn-2 ... b0 where bn-1 is
`the highest order, or most significant bit and b0 is the lowest order, or least significant
`bit. As represented in this document, binary numbers always are expressed from left
`to right with the left-most bit the most significant bit and the right-most bit the least
`significant bit. If the binary numbers are formed by multiple octets, the bits forming any
`octet are presumed to be less significant than those of any octet to the left and more
`significant than those of any octet to the right. For example, if two octets, numbered
`left to right as 1 and 2, are taken together as a binary number, octet No. 1 will contain
`the most significant bits.
`Decimal Interpretation:
`The bit combinations are identified by notations of the form xxx..., where
`xxx... is a number in the range 000-infinity. The correspondence between the
`bits and their value is as follows:
`Bits
` bn-1, bn-2 ... b0
`Weight 2n-1, 2n-2 ... 20
`The least significant bit, i.e. the bit of lowest value always is aligned with the
`least significant bit of the octet or other data frame containing it.
`
`Section 1.16 bit resolution: The accuracy of digitisation, e.g. 8-bit or 16-bit. Along
`with duration, sampling rate and number of channels (mono/stereo), affects the size of
`the audio file.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`6
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 6
`
`

`

`Section 1.17 CCITT: Comité Consultatif International Télégraphique et Téléphon-
`ique. Defunct organisation. Formerly an organisation of telephone and telegraph
`providers with headquarters in Geneva, Switzerland. Replaced in December 1992 by a
`division of the International Telecommunications Union (ITU) Standardization Sector.
`
`Section 1.18 character: A member of a set of elements used for the organisation,
`control or representation of data.
`
`Section 1.19 code table: A table showing the character allocated to each bit
`combination in a code.
`
`Section 1.20 Co-ordinated Universal Time (UTC): The time scale defined by the
`Bureau International de l'Heure (International Time Bureau) that forms the basis of a
`co-ordinated dissemination of standard frequencies and time signals. The mismatch of
`ordering of characters between the name and initials is intentional.
`
`1, The source of this definition is Recommendation 460-2 of the
` Consultative Committee on International Radio (CCIR). CCIR has
` also defined the acronym for Co-ordinated Universal Time as UTC.
`2, UTC is often (incorrectly) referred to as Greenwich Mean Time and
` appropriate signals are regularly broadcast.
`
`Section 1.21 cut: A single audio object within the IIM envelope, e.g. actuality, wrap.
`
`Section 1.22 day: A period of time of 24 hours starting at 0000 and ending at 2400
`(which is equal to 0000 the following day).
`
`Section 1.23 editorial information: Information primarily of interest to editors con-
`cerning the content of the object, such as date and place of creation, name of creator,
`etc. This information is contained in DataSets 2:xx of the Universal Application Record.
`
`Section 1.24 editorial material: Data contained in the object that represents
`observations, opinions or analysis of the provider as opposed to statistical data, that
`simply reports data such as temperatures, sports scores, financial market prices, etc.
`
`Section 1.25 graphic character: A member of a subset of a set of characters. The
`graphic character subset includes all characters that have visual representation,
`normally hand-written, printed or displayed, and that has a coded representation
`consisting of one or more bit combinations. Control codes, space character (ISO 646
`2/0) and DEL (ISO 646 7/15 ) are not graphic characters. The sets of alphabetic and
`numeric characters are subsets of the set of graphic characters. Graphic characters
`are shown in this document enclosed in single quotation marks, e.g. '*', 'T', '-'. A series
`of graphic characters are shown in double quotation marks, e.g. "IPTC-7901",
`"DÜSSELDORF", "$1.99". Note that the visual representation of a graphic character
`depends upon the character set invoked at the time of evaluation.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`7
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 7
`
`

`

`(IPTC): An
`Section 1.26 International Press Telecommunications Council
`organisation of news agencies, newspapers and other news organisations, with
`headquarters in Windsor and formed for the establishment of news transmission
`standards and other activities for the common benefit of its members. (Also known as
`the Comité International des Télécommunications de Presse.)
`
`The address is found in Appendix B.
`
`Section 1.27 International Organization for Standardization (ISO): An international
`body with headquarters in Geneva, Switzerland, to co-ordinate the work of national
`bodies such as ANSI, BSI or DIN. Also involved are IEEE, ECMA and the IPTC. ISO is
`broadly responsible for standards that operate over communications media. The
`mismatch of ordering of characters between the name and initials is intentional.
`
`Section 1.28 ISO 646: A coded set of characters based upon seven significant bits.
`ISO 646 has numerous national versions. Unless otherwise specified, all references
`herein contained are to the International Reference Version.
`
`Section 1.29 ITU: International Telecommunications Union. An organisation of
`telephone and telegraph providers with headquarters in Geneva, Switzerland. The ITU
`reports
`to
`the United Nations Organisation
`(UNO). All
`telecommunications
`administrations and recognised private common carriers belong to the ITU. The
`address is found in Appendix B.
`
`Section 1.30 minute: A period of time of 60 seconds.
`
`Section 1.31 month, calendar: A period of time resulting from the division of a
`calendar year in twelve sequential periods of time, each with a specific name and con-
`taining a specific number of days.
`
`Section 1.32 MPEG: Motion Picture Experts Group, Coding of Moving Pictures and
`Associated Audio for Digital Storage Media, ISO/IEC 11172-3, Part 3 being the section
`concerned with digital audio.
`
`Section 1.33 NAA: The Newspaper Association of America was created on 1 June
`1992 from the American Newspaper Publishers Association (ANPA), the Newspaper
`Advertising Bureau (NAB), and six other newspaper associations. NAA represents
`nearly 2000 newspapers in the United States, Canada, and around the world. The
`address is found in Appendix B.
`
`Section 1.34 numeric, numeric character: The textual representation by means of a
`specific character set of the binary values 0-9 in decimal notation. Numeric characters
`are a subset of the set of graphic characters and are the characters '0', '1', '2', '3', '4',
`'5', '6', '7', '8', '9'. In this document, numeric characters are enclosed in single quotation
`marks. Series of numeric characters are enclosed in double quotation marks, e.g.
`"23", "124".
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`8
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 8
`
`

`

`Section 1.35 object: A term to describe the entire data collection of all records,
`excluding record 1 DataSets concerned with data transmission, for an instance under
`the Information Interchange Model.
`
`Section 1.36 objectdata: A collection of binary data, such as a photo, news graphic
`or text, that is the essence of the data to be presented and contained in Record 8.
`
`Section 1.37 octet: A data frame of eight bits identified by b7, b6, b5, b4, b3, b2, b1 and
`b0 where b7 is the highest order, or most significant bit and b0 is the lowest order, or
`least significant bit.
`
`Unless otherwise specified, all references to bits of octets herein described
`are from left to right with the most significant bit on the left and the least
`significant bit on the right.
`Character Definition by Chart Position:
`The bit combinations are identified by notations of the form xx/yy, where xx
`and yy are numbers in the range 00-15 or x/y where x and y are numbers in
`the range 0-7. The correspondence between the notations of the form xx/yy
`and the bit combination consisting of the bits b7-b0 are as follows:
`
`Bits
`Weight
`
`b7
`8
`
`xx
`
`b6
`4
`
`b5
`2
`
`yy
`
`b4
`1
`
`b3
`8
`
`b2
`4
`
`b1
`2
`
`b0
`1
`
`The bit combinations are identified by notation of the form xxx, where xxx is a
`number in the range 000-255. The correspondence between the notations of
`the form xxx and the bit combination consisting of the bits b7-b0 are as
`follows:
`
`
`Decimal Interpretation:
`
`Bits
`Weight
`
`b7
`128
`
`b6
`64
`
`b5
`32
`
`b4
`16
`
`b3
`8
`
`b2
`4
`
`b1
`2
`
`b0
`1
`
`Section 1.38 outcue: The last spoken words heard on the audio, used to help editors
`and news anchors construct program scripts and resume speaking after the broadcast
`of an audio file.
`
`Section 1.39 OSI model: OSI stands for Open Systems Interconnection, a term used
`to describe the agreed international standards by which open systems communicate.
`The OSI model, jointly defined by CCITT and the ISO, is an architectural model with
`seven layers. Layers 5 through 7 (Session, Presentation, Application) concern the
`functions of interworking. The model is described in the ISO 7498 standard.
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`9
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 9
`
`

`

`Section 1.40 sampling rate: The frequency at which analogue audio signals are
`measured. Each sample is a measure of the signal's level at a discrete time. Along
`with bit resolution, duration and number of channels (mono/stereo), affects the size of
`an audio file.
`
`Section 1.41 scener: An audio report in which a correspondent describes a scene
`being viewed, usually with natural sound background.
`
`Section 1.42 second: A basic unit of measurement of time in the International
`System of Units (SI) as defined in ISO 31-1.
`
`Section 1.43 Unicode: Version 2 of the uniform encoding scheme for written
`characters and text. Published by the Unicode Consortium in ISBN 0-201-48345-9.
`
`Section 1.44 Unstructured Character Oriented File Format (UCOFF): The UCOFF
`consists of a collection of data mapped to the coded character set ISO 646 IRV unless
`defined otherwise in DataSet 1:90. The UCOFF is intended to be a means of
`exchanging data commonly known as "text", including non-printing characters as
`defined within the coded character set. The UCOFF is not intended to be a "catch all"
`means of transmitting unregistered file formats. Implementors or users of formatted
`data should seek appropriate registration.
`
`Section 1.45 UTF-8: Universal Multiple-Octet Coded Character Set
`(UCS)
`Transformation Format-8 as specified in the Unicode Technical Report #4 and outlined
`in RFC 2044. UTF-8 allows Unicode data to be encoded into a varying number of
`octets depending on the integer value assigned to the original character. In particular
`Unicode character values from 0 to 127 are encoded in UTF-8 using the same octet
`values as in ISO 646. May be used when transmitting data through 8-bit oriented
`protocols
`
`Section 1.46 voicer: An audio report which consists solely of a correspondent's voice.
`
`Section 1.47 WAVE: Also known as RIFF WAVE, a file format developed by Microsoft
`and IBM consisting of a header section that describes the recording parameters of the
`audio and the audio data itself. Can be converted to AIFF and vice versa.
`
`Section 1.48 wrap: An audio report which
`the voices of both a
`includes
`correspondent (or correspondents) and a newsmaker (or newsmakers).
`
`Section 1.49 year, calendar: A cyclic period of time in a calendar that is required for
`one revolution of the earth around the sun.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`10
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 10
`
`

`

`Chapter 2. INFORMATION INTERCHANGE MODEL
`
`
`Section 1.1 Functionality
`
`The Information Interchange Model consists of a number of records in a
`structure described below and which detail into five sub-layers, namely:
`-
`Object Envelope Record, DataSets in the range of 1:xx
`-
`Application Records, DataSets in the range 2:xx through 6:xx
`-
`Pre-ObjectData Descriptor Record, DataSets in the range 7:xx
`-
`ObjectData Record, DataSets in the range 8:xx
`-
`Post-ObjectData Descriptor Record, DataSets in the range 9:xx
`
`(a) Functionality of the Object Envelope Record
`
`
`This record is mandatory and envelops all types of objectdata, including data
`encapsulated in previously defined formats or headers, which themselves can be
`enveloped by the 1:xx record, thus enabling the use of older formats within the new
`model. Within record 1:xx, DataSets 1:00, 1:20, 1:22, 1:30, 1:40 and 1:70 are
`mandatory.
`
`
`
` (i) File Formats are valid only by international agreement and are to be found in
`Appendix A to this document.
`
`
`
` (ii) The DataSets will permit a single link to be used for transmission of any type of
`data. The recipient may sort or buffer data temporarily so that the data may be
`sent to the appropriate subsystem.
`
`
`
`
`
`
`
`
`
`(b) Functionality of the Application Records
`
`
`
` (i) Since the model is designed to encapsulate older formats, if required, some
`means must be provided to supply information that otherwise might not be
`provided in those older formats. Records 2:xx through 6:xx provide the
`capability to do this. Records 2:xx through 6:xx may optionally be used
`regardless of whether they duplicate any information that might be contained
`within the envelope record.
`
`(c) Functionality of the Pre-ObjectData Descriptor Record
`
`
`
` (i) Record 7:xx is mandatory and provides a means of describing the size of the
`objectdata file.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`11
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 11
`
`

`

`
`
`
`
`
`
`
`
`(d) Functionality of the ObjectData Record
`
`
`
` (i) Record 8:xx is mandatory and provides the actual objectdata contained in one
`or more DataSets. The object may be sent in one or more packets of DataSet
`8:10, however, the DataSets must occur in sequential order without
`intervening DataSets.
`
`(e) Functionality of the Post-ObjectData Descriptor Record
`
`
`
` (i) Record 9:xx is mandatory and gives the size of the objectdata file.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`12
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 12
`
`

`

`Chapter 3. RECORDS
`
`
`Section 1.1 Ordering of Records
`
`
`(a) Records must be in numerical order. However, DataSets within a record need
`not be in numerical order, unless otherwise specified in the DataSet descrip-
`tion.
`
`Section 1.2 Occurrence of Records
`
`(a) If the provider elects to use Part II of the Model (Records No. 2 through No. 6),
`they should appear only in one iteration, e.g. there should be no more Record
`2s after Record 6.
`
`Section 1.3 Record Structure
`
`(a) Each record is composed of DataSets:
`Record
`DataSet 1 DataSet 2 DataSet 3
`
`Section 1.4 DataSets
`
`
`(a) Each DataSet consists of a unique tag and a data field.
`
`(b) Only a few DataSets have fixed length: all DataSets (except for record 8
`containing the object) have maximum length, although in most cases it is not
`required to fill that length. There is no end-of-DataSet marker.
`
`(c) The tag identifier is globally unique in the usage of records 1, 7, 8 and 9. In
`records 2 through 6 different usage may occur for different types of data.
`
`(d) There are two types of DataSets: standard and extended. A standard tag is
`utilised when the number of octets in the data field is equal to or less than
`32767. Otherwise, the extended DataSet is used.
`
`Standard DataSet
`Tag
`Data Field
`
`Tag
`
`Extended DataSet
`Data Field
`Octet Count
`
`Data Field
`
`
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`
`
`13
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 13
`
`

`

`Section 1.5 Tags
`
`
`(a) General
`
`Tags may be of two types, depending upon whether the length of the data
`field is equal to or less than 32767 (decimal) octets in length.
`
`(b) The Standard DataSet Tag
`
`
`
` (i) If the length of the data field is equal to or less than 32767 octets in length, the
`tag is composed of five octets defined as follows.
`
`Standard DataSet Tag
`2
`3
`Record
`DataSet
`Number
`Number
`
`1
`
`Tag
`Marker
`
`
`
`
`
`
`
` (ii) Octet 1
`is the tag marker that initiates the start of a DataSet and is always position
`1/12.
`
`4 5
`Data Field
`Octet Count
`
`
`
` (iii) Octet 2 is the binary representation of the record number. Note that the
`envelope record number is always 1, and that the application records are
`numbered 2 through 6, the pre-object descriptor record is 7, the object record
`is 8, and the post-object descriptor record is 9.
`
`
`
` (iv) Octet 3 is the binary representation of the DataSet number.
`
`
`
` (v) Octets 4 and 5, taken together, are the binary count of the number of octets in
`the following data field (32767 or fewer octets). Note that the value of bit 7 of
`octet 4 (most significant bit) always will be 0.
`
`(c) The Extended DataSet Tag
`
`If the length of the data field is greater than 32767 octets, the tag is
`composed of five octets defined as follows plus a field describing the length
`of the data field. The length of the Data Field Length Descriptor is provided in
`binary form in the 15 least significant bits of octets 4 and 5 taken together as
`a binary number. The value of the most significant bit (bit 7 of octet 4) always
`is 1 to flag that the extended DataSet is in effect. Otherwise, it is constructed
`the same as the Standard DataSet Tag.
`
`1
`
`Tag
`Marker
`
`2
`Record
`Number
`
`Extended DataSet Tag
`3
`4 5
`DataSet
`Length of
`Number
`Data Field
`Octet Count
`Field
`
`6 . . . n
`Data Field
`Octet Count
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`14
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 14
`
`

`

`Section 1.6 Coded Character Set
`
`
`(a) Record 1:xx shall use coded character set ISO 646 International Reference
`Version or ISO 4873 Default Version .
`
`Section 1.7 Envelope Record DataSets
`
`
`(a) Interpretation
`
`
`
`
`
`
`
` (i) Some DataSets are described as "publishable." The information in such
`DataSets is expected to be composed in such a way that it can be printed or
`otherwise published "as is."
`
`
`
` (ii) Some DataSets are described as "advisory." The information in such DataSets
`is expected to be human-readable. NO machine-readable information should
`be anticipated in these DataSets.
`
`(b) Encapsulation of Older Formats
`
`
`
` (i) If a receiving system reads the file format as an existing header and content
`format such as IPTC7901, it may then interpret DataSet 8:10 (Object) as a
`switch to begin accepting data and interpreting in that format. In such a case,
`that format's end of data signal would function as the signal to return to the
`envelope record level or to return control to lower layers, whichever is
`appropriate.
`
`Likewise, upon finding that the defined format has its own specific application
`records, the DataSets of records 2-6 will be interpreted in the manner specific
`to that format.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`15
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 15
`
`

`

`Chapter 4. IMPLEMENTATION GUIDELINES
`
`This section is for the software engineer or programmer to use as a guideline when
`implementing this model.
`
`Section 1.1 There is no end-of-DataSet marker. If the receiving system has not
`detected a new DataSet in the first octet following the end of the preceding data field,
`as described by the length, the system should assume an error and recover
`accordingly.
`
`Section 1.2 An input program should use the octet counts and not simply search for
`tag markers as delimiters because the fields can contain binary data that may be of
`the same value as the tag markers themselves.
`
`Section 1.3 A program should ignore a DataSet it does not recognise without
`rejecting the otherwise acceptable data or terminating the application program. In this
`manner information that might be provided in new application records will not affect
`unmodified programs.
`
`Section 1.4 A program encountering a DataSet with a repeated tag number should
`assume that it is "more or another of the same", e.g. as where a sequence of subfiles
`(or sub-images) is encountered. If a repeated tag number is encountered for a
`DataSet defined as non-repeatable, an error condition is assumed and handled
`without aborting the program and without aborting data capture, i.e. the data of the
`first-encountered DataSet should be retained. The maximum number of repeats is not
`defined. Where DataSets are repeatable, only one piece of data should be included in
`that DataSet. For example, a DataSet defining news categories should include one
`category per DataSet.
`
`Section 1.5 A single transmission can include multiple objects of various types of
`data. If layer 5 or 6 of the OSI model has not received an end-of-transmission, the
`receiving system should expect to receive a DataSet 1:xx and subsequent DataSets.
`
`Section 1.6 If the Envelope Record File Format DataSet (1:20) identifies an existing
`format, such as NAA 89-3 (ANPA 1312) or IPTC 7901, the system may branch to
`Record 7:xx or to the header fields as identified in the existing format. Programmers
`are advised to look for the presence of the record No. 2 in order to take advantage of
`additional information that it might provide.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`16
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 16
`
`

`

`Section 1.7 If the File Format (1:20) identifies a format that has no means of
`providing pertinent editorial information or whose information is insufficient, the sender
`is expected to use Record No. 2 as herein provided. Programmers should ensure that
`presence of Record No.2, if not expected, does not cause the program to abort or
`reject otherwise acceptable data.
`
`Section 1.8 Image Type (2:130) is designed to be used where the file formats
`utilised by the provider do not otherwise provide that information. If there is a conflict
`between DataSet 2:130 and any DataSet in Record No.3 the Record No.3 DataSet
`takes precedence.
`
`Section 1.9 DataSet 8:10. If the object is sub-divided and placed into multiple
`DataSets 8:10 there may be no correlation between the nature of the object and the
`sub-division structure. The division of the object into subfiles may be necessary
`because of equipment design constraints but has no relation to the object itself.
`
`Section 1.10 The UNO (DataSet 1:100) is new in version 3 of the IIM and specified
`herein as ‘optional’. It should be noted, however, that information provided under
`version 3 generally contains the UNO and that receiving software for version 3 should
`fully support DataSet 1:100. It should furthermore be noted that in future versions of
`the IIM, the UNO might be made mandatory and that DataSets 2:45, 2:47 and 2:50 for
`reference to an object might be removed.
`
`Section 1.11 The Object Type and Object Attribute (DataSets 2:03 and 2:04) and the
`Subject Reference (DataSet 2:12) are new in version 4 of the IIM. With the
`introduction of these new DataSets, that are a method of describing a News Objects
`contents, the DataSets 2:10 and 2:15 are indicated as "Deprecated". Appendices
`G,H,I and J have also been added in version 4.
`
`Section 1.12 DataSet octet sizes do not imply character sizing. The number of
`characters will depend on the encoding method specified. The number of octets
`specified within a DataSet Data Field Octet Count will always be equal to or greater
`than the number of characters of data represented.
`
`Section 1.13 Advice on the use of the Subject reference DataSets is available in the
`separately published IIM Guideline 3 document. See also http://www.iptc.org/iptc for
`latest information.
`
`IPTC-NAA Information Interchange Model Version No. 4.1 Page
`
`17
`
`July 1999
`
`Petitioner Apple Inc. - Ex. 1037, p. 17
`
`

`

`Chapter 5. ENVELOPE RECORD
`
`