Protect Revenues, Not Bits: Identify Your Intellectual Property
by Branko Gerovac and Richard J. Solomon
ABSTRACT
Work-in-progress by the television and motion picture community for a digital imaging header is described. This is not a utopian solution for all media and applications, but such a header would aid in tracking, auditing, and particularly identifying imaging bitstreams, an important parameter for intellectual property protection.
"The New World Order is no longer about bullets, but about bits." -- the villain in Sneakers. ((c)1992. Universal Pictures Inc.)The Sneakers villain missed the whole point of the digital revolution: One makes money -- lots of it -- not by stealing bits, or by altering them, or by just moving them around. That's penny ante stuff. Big money is made by adding value to the bitstream. Until we understand the concept of value-added, toiling in the minutiae of digital information protection can be fairly unproductive.
The stored program computer has changed the basic concepts of what intellectual property is about. Combined with high-speed digital telecommunications, high-performance computing permits an ease of storage, retrieval, manipulation, and transmission -- and replication -- completely at odds with our notions of "copy" rights based on 400 years of the printing press. The idea of a machine that can program itself to hide its tracks, copy ad infinitum and effortlessly without introducing a single bit error, and send its output around the world at the speed of light without consuming the original is still something that the average person finds difficult to comprehend (despite widespread and growing use of tens of millions of these devices). [1]
While other distributive mechanisms have made it more difficult to protect creative rights over the centuries, computer/communications poses a unique dilemma because of the increasing scale, speed, and power of digitally-based network technologies. But before we discuss the subtleties of computer technology and some potential tools for controlling the flow of digitized works, it is important to note that the goals of information owners, distributors, vendors and packagers are as diverse as the implementations and applications. There is no total "solution," technical or otherwise, to the intellectual property "problem." Yet, by narrowing our focus we can devise some useful strategies which would facilitate electronic distribution and still maintain sufficient income streams to compensate artists, investors, and network providers.
If we are concerned with money flows -- that is, with whether the intellectual property owner gets paid or not -- then, as in all successful businesses, the key is to recognize what generates revenue and what is trivial. However, if we are concerned with artistic rights, privacy rights, cultural heritage, or accuracy in presentation, then our goals may be different and the technical fixes may also be different.
In this paper we describe work in progress by the television and motion picture community for a digital header. This is not a utopian solution for all media and applications, but such a header would aid in tracking, auditing, and particularly identifying imaging bitstreams.
Not that the other goals are not important. It is recognized that digital information flows not only change the concept of intellectual property, but change the way the global society works and interacts. For example, it is obvious that any system for tracking the flow of intellectual property, or the reverse flows of compensation, creates audit trails of metainformation. This is an inherent offshoot of tracking value-added bitstreams, and it has intrinsic value itself. That is, metainformation can be more valuable (to whomever controls its use) than the information being audited!
Kenneth Phillips deals with the intersection of intellectual property protection and metainformation in another paper at this workshop.
THE LOCUS OF CONTROL
The concept of copyright is rooted in the technology of print.[2] Until the computer, all other distributive mechanisms were merely mild disturbances to the idea that property rights could be physically controlled by control of the press, for the other mechanisms had similar features to the press in that the device, transmitter, record pressing plant, film duplicating machinery, etc., could be located in space, time, and pocketbook. Computer/communications changes all that.
The press pre-dated the idea of a "copy right," and it is not irrelevant to point out that the recognition that there could be a property right in text, and a practice of paying royalties[3] emerged when the printing press reached a stage of development where it threatened the sovereign's hegemony. King Phillip and Queen Mary of England, in 1557, in an effort to stop seditious and heretical ideas from being circulated in their realm, limited the right of printing to members of the Stationers' Company. The Company was given the right to search for and seize anything printed contrary to statute or proclamation with draconian measures prescribed for violators and resistors.[4] By 1565, the Company created a system of copy rights for their members, thereby both privatizing the state function of censorship (surely more efficient with a profit motive) and simultaneously creating a novel monopolistic business practice.
Copyright attorneys tend to dismiss the historical background as a distraction, yet this misses the critical point of copyrights as an intellectual property gatekeeper -- determination of the locus of control using a technology which served as a barrier to entry to the marketplace. Because numerous copies were made in one place -- on huge and relatively expensive presses -- it was feasible to identify the source, number, and often the destination of printed materials by human oversight. So, the printshop, at that time in history, was the practical point to apply control, whether for profit or against heresy, or both. Yet, even then "the increasing number of works made it impossible to acknowledge every sermon, almanac, and ballad."[5] For modes of reproduction where such an easy locus did not exist, the concept of copyright was not applied under common law. Until quite recently, copyright was not applied to conversation, speeches, jokes, or singing of songs, whether in private or public. (Perhaps we may consider, along with the technologies of mass replication, that the associated technologies of selective audio and image capture may have extended the locus of control.) Copyright, until the modern age, remained a specific protection applied to (or with) a specific technology; though in democratic and free nations it was rarely used successfully for censorship, but instead to protect fiduciary and other rights.
PAPER VS. BITS
The technology which permitted audit and control was not so much the press itself, but the mechanism of pressing ink to paper media. We have seen the evolution of technology increasingly strain the use of copyright laws as a societal device to funnel money back to the property owners, as well as effective protection against fraud, alteration, etc. First came cheaper presses, then photographic devices, machine typesetting and the steam-driven press, audiographs, mimeographs, cinematography, television, xerography, and then broadband appliances of all types. Each changed the loci, the economics, and the manipulation of media, making infringements harder to police and even harder to define.
With the computer and its appliances, if not now, soon we will be able to seemingly make a perfect duplicate of anything, from the Gutenberg Bible to the Elgin marbles, without consuming the original. Property rights used to deal with tangible property; the physical incarnation of a bit may be in tangible form at some instant in time, but they are volatile, elusive, and the process that manipulates bits inherently covers up its tracks as it copies the bits from one register to another, from one part of memory to another, from one end of a network to another -- that is just the way a von Neumann machine[6] works. In any open network of millions upon billions of programmable logic devices, an audit path not only is a messy concept, but it is meaningless except for very tiny slices of time. There is no such thing as an "original" because all "copies" are originals, as well.
The machine is at once a series of processes, concepts, and syntheses of human (and maybe machine) intelligence -- so mixed that it is difficult to separate its parts from the whole. And since the Turing definition of this stored-program machine still holds, the machine can change its own instructions, redefining itself, and becoming a new machine in a twinkling. A network of such machines permitting instantaneous transfer of digitized information is not what the Stationers' architects had in mind when they privatized heresy control. The idea of the nationwide -- or global -- "machine room," whereby for some small slice of time in the middle of the night, every unused processor, PC, and switch on the Gigabit network performs some part of a virtual process, begs the questions of digital copy rights, much less finding the control locus for auditing.
What are we to make of this confusion? Basically that we are upon a wonderful new way to add value, not subtract, steal, or transfer value.
2[32]
The law of geometric increase is the critical publishing idiosyncrasy in the digital environment. If you electronically mail a copyright article to two correspondents, and then they each send a copy to two others, ... and if each recipient retransmits the article, say, every 15 minutes (only a stroke of a key on a computer terminal) to two others, how long before the whole world sees it?[7] Two to the thirty-second power is 4.29 billion (not coincidentally, the same as the address space for a 32-bit central processor).
How then can we convert the added value of the bitstream into a revenue stream? The tool that needs to be developed to identify proper use of the revenue stream can be the same tool used to uncover improper rights infringements. Small, self-identifying blocks of data in a designated bitstream may work in a mass media environment if only because to sell, distribute, and create a demand for mass productions you cannot hide. The SMPTE[8] header/descriptor is such a tool.
THE SMPTE HEADER/DESCRIPTOR WORK-IN-PROGRESS[9]
Early in the FCC's advanced television selection process there was recognition that "HDTV is not just about Television."[10] This eventually prompted a cross-industry harmonization effort to encourage future ATV/HDTV[11] standards to be interoperable with computer and telecommunication practices. The issues that we have noted for the protection of intellectual property, that in digital systems "bits are bits," and that distinguishing one kind of data from another is key to use of the data, found their parallels in the HDTV process as well.
It is now accepted by the FCC Advisory Committee on Advanced Television Systems (ACATS) that in order to share high-resolution image data across systems and industry boundaries a universal header/descriptor is required. A header structure also must support digital transmission of video sideband information (closed captioning and secondary audio programming) as well as potential new types of information (image coding parameters and digital copyright signatures). That is, the header must be "extensible" for future needs not anticipated today. This is easily done by designing a structure without limiting the contents of the header/descriptor itself.
In 1990, the FCC formally adopted "interoperability" as a ATV selection criteria; FCC Planning Subcommittee Working Party 4 (PS/WP4) was directed to establish interoperability criteria and to evaluate HDTV proponent systems accordingly. In parallel with this formal governmental process, two Society of Motion Pictures and Television Engineers (SMPTE) task forces were formed: the Header/Descriptor task force to investigate issues and solutions related to identification and description of digital video streams, and the SMPTE Hierarchy task force to investigate scalability and other broader architectural issues. Membership of the SMPTE task forces was open to anyone in the world, and numerous trans-oceanic teleconferences for the working meetings were held in this regard. Electronic mail via the worldwide Internet has been heavily used to keep all interested parties informed, including non-members of the task forces. Fax distribution lists supplemented the e-mail; the use of electronics contributed to speeding up the process.
The SMPTE task forces provided input to PS/WP4 as well as set the stage for future SMPTE standards and recommended practices. The Header/Descriptor task force finished its work and produced a final report on January 3rd, 1992, which appeared in the June issue of the SMPTE Journal. In April, a SMPTE working group was formed to take the task force report and produce a standard.
The FCC working party has considered a family of standards with the header common to all environments. The header plays a central role coordinating content, transmission methods, and application types.
Headers (and descriptors) are fundamentally data representation objects which enable exchange and proper interpretation of data in heterogeneous environments. The proposed SMPTE structure is but a small part of a greater architectural framework for advanced, digital information systems and networks. The general structure under study provide guidance for the identification of digital intellectual property, as well.
The definitions and structures discussed are derived from current practice in the telecommunications and computer industry. When television standards were set in the early 1940s and 1950s, the need for such practice was not prevalent in broadcasting environments, however the introduction of sophisticated tape editing, digitized capture and storage, and the use of video in many other areas other than over-the-air broadcasting has created a set of ad hoc standards that are on the evolutionary path to true interoperability. So things like the SMPTE time code should be seen as an early element of header architecture.
HEADER OBJECTIVES
The following objectives form the basis for the Header's design criteria that drive the definition. Design ramifications and implications are sometimes the result of the interaction among two or more objectives. Thus, the descriptions here are to be taken as a whole.
Unambiguous Self Identification
The header should uniquely identify the encoding employed for the body of a message and thereby indicate how the data is to be interpreted.
Ramifications
-
Uniqueness. Identifiers must be unique both internationally and across
industries. When an identifier is extracted from the data stream, there should
be no ambiguity as to meaning.
Completeness. The header format must be "fully defined", to avoid ambiguity. Were the format not fully defined, it would not be possible to guarantee the extraction of the identifier.
Sufficiency. Only the identifier should be "necessary and sufficient" to determine how to proceed with interpretation of the payload. A compliant machine may need additional information (or programming) to interpret the payload, but the identifier should fully determine how to proceed.
All video (and associated) data streams should incorporate the header.
Ramifications
-
Compliant Low Cost Receivers. The desire for broad use of video services
translates into the need to minimize cost to the user and thus to the user's
equipment. Low cost receivers (especially in the near term) may be limited in
their ability to handle the full scope and flexibility that the header
mechanism will provide. Universality requires that: (a) low cost
implementations must be considered in the header design; (b) all compliant
receiver implementations must recognize the header, and properly interpret
those fields appropriate for its operation; and (c) all compliant data streams
must incorporate the minimal header.
- a minimal implementation must recognize the header length field and
interpret it to determine message length -- a minimal implementation must
recognize the universal identifier field (and subfields) and interpret it to
determine whether the data is appropriate to its operation
- all operations must be specified/specifiable using the header mechanism,
i.e., no out-of-band data streams -- no implementation will incorrectly
interpret header fields
The minimum requirements for a "header compliant receiver" are:
Compactness. Use of the header should incur a relatively small overhead on the underlying data stream. Compactness is a relative requirement.
Compliant Data Stream. A minimally compliant data stream implementation should include a properly and fully encoded minimal header designating message length and identification.
Sovereignty. Though it is certainly desirable for universality and interoperability that there be a small number of standards spanning across national boundaries, economic communities, and trade agreements, it is only realistic to assume that there will be political desires for sovereignty in standards designations. Though this is not a technical issue (per se), and cannot be guaranteed by the header design, the structure of the identifier field and its relationship to international standards organizations need to be carefully considered and appropriate allowances made.
Standards Compliance. Universality is enhanced by recognizing the past and existing work of standards bodies in relation to the design of the header. Where existing standards and practices are applicable to meeting design objectives, they should be considered.
Interactive (two-way) and Broadcast (one-way) Communication. The header and protocol should support both interactive (two-way) and broadcast (one-way) communication. The major implication here is the need for a control protocol to manage information exchange in both kinds of environments.
High Bandwidth/Low Latency Application. The header and protocol should support full motion (e.g., high bandwidth), live action (e.g., low latency), as well as off-line (e.g., post production and storage) applications.
The header should be designed to last for a long time. SMPTE suggests 30-50 years, based on the apparent lifetime of today's TV systems, but if we consider how many documents used daily in law, religion, literature and general culture date back hundreds, even thousands of years, we might want to consider the impact of designing a digital structure that could be at least decoded by our heirs many generations hence.
Ramifications
-
Forward Looking Specification Spaces. Longevity has ramifications for both
header length and identifier fields. Both need to be consistent with current
needs, yet have large enough "specification spaces" to be appropriate for the
future.
Maximum Length. Typically, a header will be associated with a frame or group of frames. (Occasionally, much shorter messages will be used in some situations for general control and information.) The "length field" must be able to specify message size appropriate for current uses, yet accommodate likely advances in technology. The major factors determining message size are: number of frames, raster size, pixel size, and compression factor. Today, typical message sizes for imagery are on order of 1 MB -- some applications are smaller, some larger. To support resolutions that match high quality film or high resolution wall-size displays may require on order of 1 GB.
Number of Unique Identifiers. The number of potential coding schemes to be specified by the IDENTIFIER FIELD is harder to gauge. Only a relatively small number of coding schemes are often envisioned, perhaps a few hundred, and hopefully, the number of standards will be small. However, technology will permit coding schemes to proliferate. Further, a structured identifier value (rather than a simple numerical ordering) may be helpful in administering and interpreting identifier values.
Identifier Immutability. The value of an identifier and its referenced standard, once assigned, must be "immutable." Practically, it is not possible to update unambiguously the meaning of an identifier across hundreds of millions of machines during a transition. Mutability also entails considerations of universality, longevity, and low cost implementations.
Identifier Registry. To achieve effective harmonization, one or more organizations need to be the central authority to allocate and catalog standard identifiers, and/or a well-defined registration process needs to exist. Perhaps the intellectual property organizations (WIPO, UNESCO) could coordinate this with the ITU and ISO.[12] Registration procedures are largely outside the scope of design of the header. However, universality suggests that attention in the design be given to international standards, standards bodies, and processes. Longevity and unique identification objectives, in combination, indicate that an identifier and its specified encoding once assigned and registered should not be reassigned or redefined.
Experimental and Pre-Standardization Uses. It is desirable to provide a well-defined method to use the header structure without preregistering a specific identifier, and thereby, without needlessly littering the identifier name space and without delaying experimental/research activities due to registration processes. Thus, experimental systems would use special identifiers, and thus, would exist in a closed environment for which the particular identifier has meaning. In the open environment, experimental identifiers could contain embedded interpretation information, or an identified source (instead of a registry) could be queried for instruction on how to interpret the payload.
The header should permit optimal sharing of data streams across generation, carrier, and equipment technologies and services.
Ramifications
-
Well-Formed Public Definition. A header that permits interoperability is
well defined and publicly available. Only then can equipment and application
producers comply with header requirements. And only then can a user be assured
that equipment and material from a variety of sources can be used
together.
Varied Requirements. Different applications place different requirements on a video data stream. For example, some applications will require very high resolution, others not; some applications will require special objective color spaces; others will simply need to appear nice; some applications will need multichannel high-quality audio, others will be silent; etc. Such varied requirements are a major factor in needing to support a large number of standards identifiers.
Alternate Standards. Several standards setting bodies are developing and evaluating imaging standards.
Historical Conventions. Several uses/conventions are historically significant and represent a body of existing material and experience, e.g., 24 Hz (frames per second) film, NTSC/PAL/SECAM video production, synthetic imaging, computer graphics, animation, special effects, simulation, etc. Though a header design does not address these specifically, the header should be able to accommodate existing usage.
Transcoding. Given the variety of potential encodings/standards, it will be necessary to translate from one encoding to another.
The header should be able to incorporate future unforeseen technological and algorithmic advances and improvements in quality, performance, and functionality without obsoleting existing components and infrastructure.
Ramifications
-
Large Numbering Scheme. To enable longevity, the header design should
provide a large enough numbering scheme to incorporate future unforeseen
alternatives, improvements, and advances in quality, performance, and
functionality: 1) the specification space of the header (the length and
identifier fields) should be big enough to accommodate future expansion; and,
2) extensibility should not obsolete existing compliant equipment and
transports.
Flexibility. Given the variety of applications and transmissions environments envisioned, the header must be flexible both in its design and use.
At a given time, uniform generation, transmission, and display characteristics can support a range of quality and cost. Though more a property of the particular data encoding, the header format should permit scalable encodings.
ABSTRACT SYNTAX NOTATION
The SMPTE Header is derived from an existing ISO/ITU(CCITT) standard in common use within the computer and telecommunications industries called Abstract Syntax Notation 1 (ASN.1). ASN.1 is a comprehensive and extensible tool for describing data interchange in heterogeneous transmission and storage environments. One of it features is that ASN.1 does not exclude other standards, but acknowledges existence of alternative methods and provides a mechanism with which to identify and reference any data, whether defined in ASN.1 or not.[13]
It is much like a programming language, such as C, Pascal, or PostScript. A collection of software tools and utilities to support ASN.1 has been developed. Built in data types include primitives (integer, Boolean, string, etc.), and constructors (sequence, choice, etc.) that can be used to build arbitrarily complex data structures. This process is recursive: types can be constructed from other constructed types. Thus arbitrarily complex structures and substructures may be defined. Furthermore, components of constructed types may be optional, allowing for even greater flexibility.
ASN.1 supports the notion of embedding, which allows one or more data structures to be contained within another. Thus, a sequence of frames can be embedded within an outer header (or envelope) that labels a program segment. This can be taken to coarser granularity -- shots, scenes, programs, etc. Similarly, it can be taken to finer granularity to embed audio tracks, closed captioning, descriptors, etc. within individual frames.
Two valuable features of ASN.1 include:
- Separation of data description (Abstract Syntax) and data encoding
(Transfer Syntax or Encoding Rules). Data structures are described in a
human-readable syntax and automatically translated into bits and bytes for
transfer. So,
- Deployed ASN.1 compliant systems may interpret new structures without
hardware modification.
-
The SMPTE Header is a compatible subset of the ASN.1 EXTERNAL type. All ASN.1
compliant protocol interpreters can extract and interpret an EXTERNAL without
ambiguity. Its definition is quite flexible, but some components are optional
allowing for a minimal header that is simple, compact, and easily recognized.
The ASN.1 notation for EXTERNAL is formally defined in ISO 8824.
EXTERNAL is a constructed type, meaning a sequence of primitive ASN.1 types, and is encoded with the same basic tag, length, value format described above.
A tag value of 40 decimal (or 28 hexadecimal) identifies the EXTERNAL type and indicates the value is defined outside the current ASN.1 context thus the identifier component indicates what standard to apply in decoding the value. Length indicates the number of octets (octet is the ASN.1 terminology for an 8-bit byte) occupying the remaining message (total message size less octets used for EXTERNAL tag and length) and is encoded in the usual manner as described above.
Thus all SMPTE headers start with the EXTERNAL type tag and length fields. The EXTERNAL tag and length fields for a 1010 octet EXTERNAL value (a 1000 octet payload prepended with 10 octets of identifier) would occupy 4 octets with the following hexadecimal representation:
EXTERNAL tag indicates beginning of the header [ tag ] | EXTERNAL length occupies the next 2 octets(s) [ length ] | | EXTERNAL value occupies the next 1010 octets [ ... ] | | | EXTERNAL value [ value ] | | | | 28 82 03F2 xx ... xxThe EXTERNAL value is a sequence of three fields: direct-reference, indirect-reference, and payload. Each field is a primitive ASN.1 type, and is encoded using the usual tag, length, and value format (see section 3.3). The direct-reference and indirect- reference fields are optional; A header may contain one or the other, or both. Tag fields are used to indicate the inclusion of optional fields:
[ tag= 28 ] [ length ] [ direct ref ] [ indirect ref ] [ payload ]
-
direct-reference. The direct-reference option contains the universal
identifier. It is of type OBJECT IDENTIFIER and it uniquely identifies the
payload encoding. Identifiers are registered and administered internationally
by ISO, CCITT, and their constituent organizations. Identifier administration
is described in section 5.
indirect-reference. The indirect-reference option is an integer alias for a full length identifier. It is a more compact and efficient method of identifying frequently transmitted data. Identifier-to-integer mappings are established at the time of transmission, either though bi-directional negotiation or though implied assignment by including both direct- and indirect-reference options together in the same header on a periodic basis.
payload. The payload field is an octet string encoded according to the method identified in the direct- or indirect-reference fields. The payload field is the octet-aligned option defined in the formal ASN.1 EXTERNAL type specification.
The header's direct-reference field contains a universal identifier indicating how the payload is encoded. Identifier values are assigned, registered, and administered either (1) by CCITT and ISO, or (even WIPO, UNESCO, etc.) in the course of standards development; or (2) by delegated member bodies, companies, or national organizations (such as SMPTE, IEEE, etc.), who assume responsibility for administering a portion of the identifier space.
Identifier Hierarchy
Identifiers are organized in a hierarchy. The root (prefixes) of the identifier hierarchy is:
Identifier | | |-- CCITT[0] | |- recommendation[0] : CCITT committees | |- question[1] : CCITT Study Groups | |- administration[2] : country PTTs (country code) | |- network operator[3] : X.121 organizations | |-- ISO[1] | |- standard[0] : ISO standards | |- registration authority[1] : ISO authorities | |- member body[2] : member bodies (country code) | |- identified organization[3] : organizations | |- ... | |- SMPTE[52] : delegated to SMPTE | `-- joint ISO CCITT[2] : delegated to ANSIA few prefixes are of particular interest. iso.standard registers all ISO standards. ccitt.administration and iso.memberbody are assigned to sovereign bodies (identified by their international telephone country code). Portions of iso.organization are delegated by ISO to organizations and companies so that the individual organizations can manage the assignment of their own portion of the identifier space.
Header Examples
The following examples show two commonly used header configurations. The first example shows a header for a message containing 1000 octets of Px64 encoded imagery. Only the direct-reference form of identification is used and the identifier is 0.0.8.261 (Px64) as shown above. This example puts together many of the examples shown in previous sections. The complete header is encoded in 14 octets (about 1% of the total message) and has the following hexadecimal representation:
EXTERNAL tag indicates the header is a constructed ASN.1 sequence | EXTERNAL length occupies the next 2 octets(s) | | EXTERNAL value occupies the next 1010 octets | | | OBJECT IDENTIFIER tag indicates use of direct-reference opt. | | | | OBJECT IDENTIFIER occupied the next 4 octet(s) | | | | | OBJECT IDENTIFIER is 0.0.8.261 (Px64) | | | | | | payload tag | | | | | | | payload length in next 2 octets | | | | | | | | payload occupies next 1000 octets | | | | | | | | | 28 82 03F2 06 04 00088205 81 82 03E8The next example shows a header for a 100-octet long payload with only the indirect-reference option used, value (1), could be an alias for a copyright descriptor. The complete header is encoded in 7 octets (about 7% of the total message) and has the following hexadecimal representation:
EXTERNAL tag indicates the header is a constructed ASN.1 sequence | EXTERNAL value occupied next 105 octets | | INTEGER tag indicates use of indirect-reference option | | | indirect-reference value in next octet | | | | indirect-reference value is 1 | | | | | payload tag | | | | | | payload occupies next 100 octets | | | | | | | 28 69 02 01 01 81 64EXAMPLE OF COPYRIGHT NOTATION
Following is a trivial example of how one might describe a copyright notice in ASN.1. It serves only to elicit formal definition of a universal digital copyright notice structure by a joint body of intellectual property, communications, and computing experts:
Copyright ::= SEQUENCE
{
version INTEGER
{
version-0.1(0)
},
years SEQUENCE OF NumericString,
bylines SEQUENCE OF PrintableText,
rights ENUMERATED
{
all-rights-reserved(0)
},
permission PrintableText OPTIONAL,
disclaimer PrintableText OPTIONAL,
payment-method ElectronicPaymentStandard OPTIONAL,
}
NOTES1. These concepts were outlined in detail for the Congressional Office of Technology Assessment by one of the authors (Solomon) as a contractor on their study of intellectual property, published in 1985. See R. Solomon, "Computers and the Concept of Intellectual Property," in Martin Greenberger, ed., Electronic Publishing Plus, Knowledge Industry, 1985. Also see R. Solomon & Jane Yurow, "The New Electronic Technologies and International Intellectual Property Issues," Office of Technology Assessment , U.S. Congress, May 1985; and, R. Solomon, "Intellectual Property and the New Computer-Based Media," Office of Technology Assessment, U.S. Congress, August 1984.
2. "The right only began to assume importance when the invention of printing made the multiplication of `copies' of a work infinitely quicker and cheaper than the painstaking products of monkish scribes, as well as appreciably more accurate than the compositions of most professional scriveners." I. Parsons, "Copyright and Society," in A. Briggs, ed., Essays in the History of Publishing, 1974.
3. Payments to the Crown for the privilege of publishing via print.
4. Grossman, Bernard A. "Cycles in Copyright," New York Law School Review, 22:2&3 (1977). G. Blagden, The Stationers' Company, 1960.
5. Grossman, op. cit., p. 263.
6. Or a Type 4 Turing machine, depending on whom you wish to give the intellectual credit.
7. R. Solomon, in a paper co-authored with the late Ithiel de Sola Pool, first described this in a different context for the OECD in a discussion of transborder data flows. See "Intellectual Property and Transborder Data Flows", Stanford Journal of International Law, Summer 1980; and The Regulation of Transborder Data Flows", Telecommunications Policy, September 1979.
We leave it to the reader to calculate how long it takes to reach the whole world if every 15 minutes the number of recipients doubles.
8. Society of Motion Picture and Television Engineers (U.S.).
9. The details of the header structure is still work-in-progress which is being brought to this forum for comment and suggestions. The precise formats, fields, descriptors, etc., are subject to substantive change as the standardization process proceeds We invite comments and suggestions.
10. Generally ascribed to Prof. William F. Schreiber of MIT, circa 1986.
11. Advanced Television and High-Definition Television.
12. World Intellectual Property Organization, United Nations Economic and Social Commission, International Telecommunication [NO `S'] Union, International Standards Organization.
13. ASN.1 is derived from work at Xerox Palo Alto Research Center (PARC) on Courier in the late 1970s. A 1984 version was used in the first draft of the CCITT X.400 series of recommendations on message handling systems. ISO and CCITT jointly developed ASN.1 in 1988 for the presentation layer of the Open Systems Interconnect model.
ASN.1 is now widely used in a range of international standards activities, including the CCITT X.500 directory service, and both OSI and Internet network management protocols, the Common Management Information Protocol and Simple Network Management Protocol respectively. This suggests the possibility that television systems may be networked devices that may fit into a common network management framework.
14. For a formal description of ASN.1 refer to ISO 8824/8825 and CCITT X.208/209. A more accessible description can be found in: Marshall T. Rose, The Open Book: A Practical Perspective on OSI, Prentice Hall, 1990.
BIOGRAPHY
Branko Gerovac is with the Digital Equipment Corp., Maynard, Mass. and an associate of the MIT Program on Digital Open High Resolution Systems.
Richard J. Solomon is Associate Director of the MIT DOHRS Program at the Center for Technology, Policy and Industrial Development, Cambridge, Mass.
