The following quoted text (indented at the bullet) is taken from the statement of prior art in US Patent 5,706,434 entitled Integrated request-response system and method generating responses to request objects formatted according to various communication protocols and filed in 1995 by Electric Classifieds, Inc.

• Open Systems Interconnection (OSI) Communications Model
  
  As will be appreciated by those skilled in the art, communication networks and their operations can be described according to the Open Systems Interconnection (OSI) model. This model includes seven layers: an application, presentation, session, transport, network, link, and physical layer. The OSI model was developed by the International Organization for Standardization (ISO) and is described in "The Basics Book of OSI and Network Management" by Motorola Codex from Addison-Wesley Publishing Company, Inc., 1993 (First Printing September 1992).
  
  Each layer of the OSI model performs a specific data communications task, a service to and for the layer that precedes it (e.g., the network layer provides a service for the transport layer). The process can be likened to placing a letter in a series of envelopes before it's sent through the postal system. Each succeeding envelope adds another layer of processing or overhead information necessary to process the transaction. Together, all the envelopes help make sure the letter gets to the right address and that the message received is identical to the message sent. Once the entire package is received at its destination, the envelopes are opened one by one until the letter itself emerges exactly as written.
  
  In a data communication transaction, however, each end user is unaware of the envelopes, which perform their functions transparently. For example, an automatic bank teller transaction can be tracked through the multilayer OSI system. One multiple layer system (Open System A) provides an application layer that is an interface to a person attempting a transaction, while the other multiple layer system (Open System B) provides an application layer that interfaces with applications software in a bank's host computer. The corresponding layers in Open Systems A and B are called peer layers and communicate through peer protocols. These peer protocols provide communication support for a user's application, performing transaction related tasks such as debiting an account, dispensing currency, or crediting an account.
  
  Actual data flow between the two open systems (Open System A and Open System B), however, is from top to bottom in one open system (Open System A, the source), across the communications line, and then from bottom to top in the other open system (Open System B, the destination). Each time that user application data passes downward from one layer to the next layer in the same system more processing information is added. When that information is removed and processed by the peer layer in the other system, it causes various tasks (error correction, flow control, etc.) to be performed.
  
  The ISO has specifically defined all seven layers, which are summarized below in the order in which the data actually flows as they leave the source:
  
  Layer 7, the application layer, provides for a user application (such as getting money from an automatic bank teller machine) to interface with the OSI application layer. That OSI application layer has a corresponding peer layer in the other open system, the bank's host computer.
  
  Layer 6, the presentation layer, makes sure the user information (a request for $50 in cash to be debited from your checking account) is in a format (i.e., syntax or sequence of ones and zeros) the destination open system can understand.
  
  Layer 5, the session layer, provides synchronization control of data between the open systems (i.e., makes sure the bit configurations that pass through layer 5 at the source are the same as those that pass through layer 5 at the destination).
  
  Layer 4, the transport layer [also known as the Transmission Control Protocol (TCP) layer], ensures that an end-to-end connection has been established between the two open systems and is often reliable (i.g., layer 4 at the destination "confirms the request for a connection," so to speak, that it has received from layer 4 at the source).
  
  Layer 3, the network layer [also known as the Internet Protocol (IP) layer], provides routing and relaying of data through the network (among other things, at layer 3 on the outbound side an "address" gets slapped on the "envelope" which is then read by layer 3 at the destination).
  
  Layer 2, the data link layer, includes flow control of data as messages pass down through this layer in one open system and up through the peer layer in the other open system.
  
  Layer 1, the physical interface layer, includes the ways in which data communications equipment is connected mechanically and electrically, and the means by which the data moves across those physical connections from layer 1 at the source to layer 1 at the destination.
  
  The particular focus of the following discussion is on media access control (MAC) for communication networks which is performed in the OSI network and data link layers. It will be appreciated by those skilled in the art that various applications and components operating in the other OSI layers may be interchangeably used with the particular MAC described below so long as these applications and components adhere to the OSI design structures. For example, many different OSI physical layer components (e.g., a parallel bus, a serial bus, or a time-slotted channel) can be used in conjunction with the same MAC so long as each of the OSI physical layer components passes the particular information required by OSI design parameters to the OSI data link layer.
  
  Standard Data Communication Network Protocols
  
  Standard data communication network protocols, such as that which is described above, offer new abilities and corresponding technological problems. Standard network protocols suites such as the Transmission Control Protocol/Internet Protocol suite (TCP/IP) allow for the easy creation of transport-layer protocols. These transport protocols and accompanying data languages allow for a diverse set of client applications which communicate using them. This ability to support a diverse client base is a boon to the commercial and mainstream potential of data communications networks because diversity is a necessary condition for a product in the marketplace. Diversity, in some cases being helpful, can also be a problem. The main problem with the diverse client base is that not every client knows every version of every protocol or every dialect of every data language. Thus, coordination between a server and these clients can be a difficult problem. Electronic mail (email) on the Internet, for example, uses Simple Mail Transport Protocol (SMTP) and adheres to the Request for Comments 822 (RFC822) message standard.
  
  Common email clients for the Internet are Udora, Elm, PINE, PRODIGY Mail, and AMERICA ONLINE Mail. The protocols and languages used are all generally the same email clients. However, each client has different properties and capabilities which make the general process of creating and serving objects via email difficult. For example, email clients differ in how wide each line of a message may be (email messages used by the PRODIGY e-mail client are 60 characters wide, whereas those used by the AMERICA ONLINE email client are 49). They also differ in terms of what extensions they support--some email clients support the Multipurpose Internet Mail Extensions (MIME), but most do not. Similarly, the World Wide Web (WWW), an internet-distributed hypermedia (text, image, sound, video) network, primarily uses Hypertext Transfer Protocol (HTTP) and Hypertext Markup Language (HTML) for its communication.
  
  The WWW has the same problem as email with regard to clients. There exist different versions of HTTP and different dialects of HTML, and most clients do not know all of them. For example, Netscape Communications Corporation has put forth its own extensions to HTML for features such as background images behind text and centered text. These features are not official industry standards but are becoming just as good in the sense that they are de facto standards. Another problem of the easy creation of new transport-layer protocols is that new transport-layer protocols and data languages (either standard or custom) continue materializing. These protocols and languages either solve new communications problems (such as HTTP and HTML enhancing the Internet with hypermedia), or better solve older ones (e.g., Sun Microsystems' new HOT JAVA extensions to HTML and the JAVA programming language promise to be the next best feature for the WWW).
  
  The Importance of an Integrated System
  
  With the diversity of data communication protocols and languages, there is a tendency for engineers to try to build a system for each of the many protocols and languages, rather than to build a single system to address all of them. This is because in a certain sense it is easier to write an individual system with a more limited domain than an integrated system with a more expanded domain; one does not have to expend the effort necessary to abstract out the common features across a diverse set. However, it is very expensive to maintain many individual systems and usually much cheaper to maintain a single integrated system. Also, it is much more difficult to maintain feature parity and share data between many individual systems as opposed to within an integrated system. An additional benefit of an integrated system would be that, because the step has already been taken to abstract out common features of various protocols and languages, it is much easier to adapt to newer ones, which will most likely be abstractly similar enough to the older ones to allow for easy integration.
  
  Two-Way Communication and the Drive Towards Peer-To-Peer Mass Communications
  
  New communication models emerging from usage of data communications networks such as the Internet are causing changes in the relationship between data producers and data consumers. It used to be that with the one-to-many, one-way model of television and radio, content was produced by a small elite of entertainer-business persons and was consumed by the masses. The two-way nature of data communications networks, however, allows for the more intimate participation of the consumer. Even to the point of blurring the distinction between consumer and producer: because of the ability to participate, the old consumer can now be both a consumer and a producer on networks such as the Internet. Relationships on data communications networks are much flatter and more egalitarian in the sense that each participant is a peer (both a producer and consumer). One important outgrowth of this elevated status of the individual on a data communications network is that the individual now demands more personalized attention. For example, if a peer provides another with knowledge about him or herself (e.g., geographic location, gender, age, interests), then he or she expects that responses should take this knowledge into account. A peer can no longer be treated like a demographic average as in the world of television and radio.
  
  The Technological Problems in Need of Solution
  
  Given these new data communications networks and their technological and social implications, it is evident that new systems should provide solutions, for example, to the following problem: How does one design an integrated system that uses multiple protocols and data languages and serves data in a way that takes advantage of knowledge about clients and users?
  
  Description of the Prior Art
  
  The ability to create and serve objects has been around ever since the birth of the client/server model. Also, the notion of providing services to general users through data communications networks has been around at least since the early days of VideoTex. However, this technology was limited and was more focused on building specialized VideoTex terminals that fit some particular mold required by particular servers (see, for example, U.S. Pat. No. 4,805,119) rather than being focused on making servers be flexible in handling a variety of client types. This is probably due to the fact that work on VideoTex was done by individuals with the television frame of mind--content would be created in a central way and then broadcast to the masses. The cultural importance of peer-to-peer communications was not fully recognized at that time.
  
  Integrated services platforms have been developed for telephone networks (see, for example, U.S. Pat. No. 5,193,110) but still only focus on telephone calls (essentially a single protocol as opposed to many). In recent years, a number of online service providers--the Prodigy Service Company, America Online, CompuServe, and others--have developed their own means to create and serve objects in a similar vein. Technologically, these companies are not all that different from the older VideoTex companies. They require users to obtain custom software clients which speak custom protocols in order to interact with their servers, even if their software can be used on different personal computers to make their services personal computer-independent (see, for example, U.S. Pat. No. 5,347,632). Because of these custom clients and protocols, these services are mutually incompatible.
  
  What is not addressed by services like these is the growing usage of standard communication protocols and languages (like SMTP, HTTP, and HTML) in providing services to standard clients. Ultimately, this usage of proprietary clients and protocols leads to self-destruction in a marketplace which demands standardization, decentralized control, and diversity. With regard to the personalization of service, attention has lately been paid to the need to support customized content to clients, such as customized television commercials (see, for example, U.S. Pat. No. 5,319,455). But one can see limitations in the philosophy of this work in that clients are still seen as "viewers" in a one-way communications model, rather than as participants in a two-way model. Also, technologies have been developed to abstract data and present it in dynamic ways based upon user parameters (see, for example, U.S. Pat. Nos. 5,165,030 and 4,969,093). However, this effort has not been focused on protocol-independence and language-independence of this abstracted data.
  
  
  [emphasis added]
  

I am filing this entry in the Reference Library to this blog.