O
`Umted States Patent
`
`[19]
`
`Kremen et al.
`
`US005706434A
`
`[11] Patent Number:
`
`5,706,434
`
`[45] Date of Patent:
`
`Jan. 6, 1998
`
`5,193,110
`
`=
`
`1
`
`5,406,557
`5,420,916
`5,535,375
`5,546,584
`
`379/94
`
`3/1993 Jones et a1,
`gloaftié 3 31-
`‘
`"
`.33“
`'
`
`gig 3:11» -
`-- 39~‘;"§g}’4g‘1’
`4/1995 Baudoin
`370/407
`hi.
`5/1995 S ki
`379/230
`
`..
`7/1996 Ezheiuect a1.
`395/500
`
`.. 395/683
`8/1996 Lundin eta].
`
`.
`.
`Prim
`ry Exammer——Kenr1cth S. K1111
`Attorney, Agent, or F1'rm—Me1'cha11t, Gould, Smith. Edell,
`Welter & Schmidt, P.A.
`
`ABSTRACT
`[57]
`A method and apparatus is provided to accomplish creation
`an<:1tser:111%1<1)f datztah0:11:11: amongtvanousbcom1;1h1cat1o:
`pro oco s.
`e me 0 an appara us can e us
`1n suc
`applications as an on-Line classified advertising system on
`fvjizgfif fr: V1‘1':::‘:1:C’:‘,‘(i1:x“;i:“e°:
`ing request dlegodes the Ieguest using configurations from a
`conftguration database in order to identify which protocol
`was used to transmit the request’ and generates from the
`request a corresponding abstract data object. A data proces-
`sor merges data from a main database with the abstract data
`object, An object formatter formats the ahstract data object
`11:)c1uduf1g the merged data. An OIJJCCI dhehverer formats 1th:
`0 ject or outgoing transrnissiou accor "ng to a protoco 0
`-
`-
`-
`-
`«
`-
`2: ::1::f1:f:ef:13?‘t‘;:;t'$J3:cii"1§:frtI:;’;‘t:e?f °bJe°tdchVmI may
`'
`
`31 Claims, 11 Drawing Sheets
`
`[54]
`
`INTEGRATED REQUEST-RESPONSE
`SYSTEM AND METHOD GENERATING
`RESPONSES TO REQUEST OBJECTS
`FORMATTED ACCORDING TO VARIOUS
`COMMUNICATION PROTOCOLS
`_
`[751 1“"e“*°“i Gal‘! KNEW? KW“ 5”“
`19'-1111161111811: Wh Of 3311 Francisco:
`Peng Tsin Ong, Redwood City; Scott
`M. Fraize, San Francisco; Piyush
`.
`.
`g:]'J3fs“"’”’ Shah’ Mm V“”°3’* “H °f
`‘
`
`[73] Assignee: Electric Classifieds, Inc., San
`Francisco. Cahf.
`
`[21] APPL No_._ 498,943
`[22]
`F1134:
`JUL 5. 1995
`[51]
`Int. C16
`[52] U'S' Cl’
`
`[56]
`
`........................ G06)?‘ 15/163
`395/20039; 395/200‘ 14;
`395,2OO'18; 395/500; 395/285; 395/610
`[58] Field of Search ............................... 395/200.18, 500,
`395/831’ 285* 20009’ 20014’ 610
`.
`Refemnces cued
`U3 PATENT DOCUMENTS
`10/1971 McNaughton et a1.
`..
`3,614,328
`6/1988 Smrgis et a1.
`..
`4,751,669
`2/1989 Maeda er al.
`4,805,119
`11/1990 Barker et al.
`4,969,093
`5,165,030 11/1992 Barker .............
`
`370/62
`345/115
`364/518
`395/300
`395/500
`
`
`
`-S->
`configuration
`
`object
`
`‘ dmabue
`
`eliveret
`
`CBS 1037
`
`CBS V. Helferich
`
`(cid:38)(cid:37)(cid:54)(cid:3)(cid:20)(cid:19)(cid:22)(cid:26)(cid:3)
`(cid:38)(cid:37)(cid:54)(cid:3)(cid:89)(cid:17)(cid:3)(cid:43)(cid:72)(cid:79)(cid:73)(cid:72)(cid:85)(cid:76)(cid:70)(cid:75)(cid:3)
`(cid:38)(cid:68)(cid:86)(cid:72)(cid:3)(cid:44)(cid:51)(cid:53)(cid:21)(cid:19)(cid:20)(cid:22)(cid:16)(cid:19)(cid:19)(cid:19)(cid:22)(cid:22)
`
`Case |PR2013-00033
`
`

`
`U.S. Patent
`
`Jan. 6, 1998
`
`Sheet 1 of 11
`
`5,706,434
`
`outgoing
`object
`
`abstract DFL-
`embedded
`
`DPL object
`
`main database
`
`data
`- rocessor
`
`unformatted DFL
`object (processed)
`
`object
`formatter
`
`

`
`U.S. Patent
`
`Jan. 6, 1998
`
`Sheet 2 of 11
`
`5,706,434
`
`/
`
`From: anneflwhatsamatta-u.edu
`To:
`server@foobar.oom
`
`Please send me my favorite table of figures
`
`Incoming Request for Object
`
`FIG. 2A
`
`

`
`U.S. Patent
`
`Jan. 6, 1993
`
`Sheet 3 of 11
`
`5,706,434
`
`/J
`
`Hello, [merge USER_NAME]. <P>
`[if [capability TABLES]
`{<CENTER>Here is the table you
`requested:-=P>
`[include THE__TABLE]<lCENTER>}
`{I am sorry. but your client
`doesn't support tab|es.}] <P>
`[include THE__FOOTER]
`
`Abstract DFL-Embedded DPL Object
`
`FIG. 2B
`
`

`
`U.S. Patent
`
`Jan. 6, 1998
`
`Sheet 4 of 11
`
`5,706,434
`
`/‘
`
`Hello. Anne. <P>
`<CENTER>Here is the table you
`requosted:<P>
`<TR><TH><lTH><TH>x<ITH><TH>Y<rl”H><ITR>
`<TR>-<TH>A<(TH><TD>X<l'l'D><TD>Y</TD></1'R>
`<TR><TH>B<rl’H><TD>x<ITD><TD>Y~<rTD><rrR>
`<n'ABLE><ICENTER> <P>
`<B>-Copyright 1995 Foobar Corp. <IB>
`
`Unformatted DFL Object (Processed)
`
`FIG. 2C
`
`

`
`U.S. Patent 1
`
`Jan. 6, 1993
`
`Sheet 5 of 11
`
`5,706,434
`
`Hallo, Anne.
`
`Here is the table you requested:
`
`XI Yl
`
`COPYRIGHT 1995 FOOBAR CORP.
`
`Concrete Object (Client-Specific)
`
`FIG. 2D
`
`

`
`U.S. Patent
`
`Jan. 6, 1998
`
`Sheet 6 of 11
`
`5,706,434
`
`

`
`U.S. Patent
`
`Jan. 6, 1998
`
`Sheet 7 of 11
`
`5,706,434
`
`
`
` =__.EcE=9<_--59
`
`<m
`GE
`
`..:..__o
`
`>>>>>>
`
`
`
`2525$5.2.....~.o.<mo
`
`
`
`
`
`
`
` IIIMIIIMIIIIIIII_.=oE:E<L.~:oE:E<4xtoqogo.__IILIII8%28SKI.~O~w0..bEQ
`
`
`
`
`
`

`
`U.S. Patent
`
`Jan. 6, 1998
`
`Sheet 8 of 11
`
`5,706,434
`
`
`
` IIl=l__EuE:9<_..ma
`
`rm
`LI...
`MNM
`
`..._III
`
`IIIII:IIIII..__Néoqem_tfioqem_£._§.o.
`
`ma
`
`mm.0_u_
`
`
`
`.mn_<omE.xo<m
`
`3mozaomo
`
`
`
`....~.o_<momm._m<»
`
`
`

`
`U.S. Patent
`
`Jan. 6, 1993
`
`Sheet 9 of 11
`
`5,706,434
`
`Configuration
`Rule Sets
`
`38
`
`‘ J Request Handlers
`
`_ _ __ _ 33 __ _ _ _
`
`Request Decoding
`
`FIG. 4
`
`

`
`U.S. Patent
`
`5
`
`0
`
`43Au,
`
`6u
`7.,mO_n_
`
`
`%_w s.___...._=B_2.6.,\.._.._.._.x.o_.2o_6..E_m=oEEoo
`NV«nook..
`
`
`
`than_
`
`M_HH._mm_oo2o._m_Sm>w_...oIu.232
`
`_O0O~O._lfl>w2OI_
`
`..
`
`_
`
`
`

`
`U.S. Patent
`
`Jan.6,1993
`
`Sheet11of11
`
`5,706,434
`
`

`
`1
`
`2
`
`5,706,434
`
`INTEGRATED REQUEST-RESPONSE
`SYSTEM AND METHOD GENERATING
`RESPONSES TO REQUEST OBJECTS
`FORMATTED ACCORDING TO VARIOUS
`COMMUNICATION PROTOCOLS
`
`FIELD OF THE INVENTION
`
`The present invention generally relates to a method and
`apparatus to accomplish creation and sewing of data objects,
`and more particularly a method and apparatus to accomplish
`creation and serving of data objects in which users and client
`applications (the recipients of the data objects) have a
`diverse set of properties and capabilities such as the use of
`different protocols and data languages in clients and difier-
`ent characteristics of users such as, for example, gender, age,
`interests. and preferences.
`
`BACKGROUND OF THE INVENTION
`
`Open Systems Interconnection (OSI)
`Communications Model
`
`As will be appreciated by those skilled in the art, com-
`munication 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) pro-
`vides 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 com-
`puter. The corresponding layers in Open Systems A and B
`are called peer layers and communicate through peer pro-
`tocols. These peer protocols provide communication support
`for a user’s application, performing transaction related tasks
`such as debiting an account, dispensing currency, or cred-
`iting 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
`
`10
`
`20
`
`25
`
`30
`
`35
`
`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 appli-
`cation (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 con-
`trol 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, 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, 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 compo-
`nents adhere to the OSI design structures. For example,
`many different OSI physical
`layer components (e.g., a
`parallel bus, 21 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.
`
`40
`
`45
`
`50
`
`55
`
`Standard Data Communication Network Protocols
`
`Standard data communication network protocols, such as
`that which is described above, olfer 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
`
`65
`
`

`
`5,706,434
`
`3
`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 communica-
`tions 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 lmows every
`version of every protocol or every dialect of every data
`language. Thus, coordination between a server and these
`clients can be a diflicult problem. Electronic mail (email) on
`the Internet, for example. uses Simple Mail Transport Pro-
`tocol (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 diflicult. For example. email
`clients differ in how wide each line of a message may be
`(e-mail messages used by the PRODIGY e-mail client are 60
`characters wide. whereas those used by the AMERICA
`ONLINE e-mail 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
`intemet—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 difierent 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 oflicial 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 materializ-
`ing. These protocols and languages either solve new oom-
`munications problems (such as H'I'I‘P 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 W).
`
`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.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`65
`
`4
`’I‘wo-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 con-
`sumed by the masses. The two—way nature of data commu-
`nications 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 new
`demands more personalized attention. For example. if a peer
`provides another with lmowledge 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 fol-
`lowing 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 RELATED ART
`
`The ability to create and serve objects has been around
`ever since the birth of flre client/sewer 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 onmaking 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. N0. 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—tl1e 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 sewers, even
`if their software can be used on difierent 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.
`
`

`
`5,706,434
`
`5
`
`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 pro-
`prietary 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 Wiewers” in a one-way com-
`munications 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 eifort has not been focused on
`protocol-independence and language-independence of this
`abstracted data.
`
`SUMMARY OF THE INVENTION
`
`This invention is directed to an apparatus and method for
`generating abstract data objects from requests received from
`any one of a plurality of communication protocols. In the
`apparatus and method. a request is received from any one of
`a plurality of communication protocols. Additional function-
`ality of the apparatus and method determines which of the
`communication protocols was used to transmit the request,
`and generates from the request, using results of the
`determining, a corresponding abstract data object,
`the
`abstract data object being independent of the plurality of
`communication protocols.
`A further apparatus and method in accordance with the
`invention includes. in addition to the elements described
`above, functionality for generating from the abstract data
`object a data object which is formatted for transmission
`according to a communication protocol of an intended
`recipient of the data object.
`A further apparatus in accordance with the invention
`includes a main database, configuration database, and mod-
`ules coupled to the databases. The main database stores data
`to be merged with objects. The configuration database stores
`configurations for use in decoding requests and formatting
`objects. A request decoder, coupled to the configuration
`database. receives an incoming request, decodes the request
`using the configurations in order to identify which protocol
`was used to transmit the request, and generates from the
`request a corresponding abstract data object. A data
`processor, coupled to the main database, the configuration
`database, and the request decoder, receives the abstract data
`object from the request decoder and merges data from the
`main database with the abstract data object An object
`formatter, coupled to the configuration database and the data
`processor, receives the merged abstract data object from the
`data processor and fonnats the abstract data object including
`the merged data. An object deliverer, coupled to the con-
`figuration database and the object deliverer, receives the data
`object from the object formatter and formats the data object
`for outgoing transmission according to a protocol of an
`intended recipient of the data object.
`BRIEF DESCRIP'I‘ION OF THE DRAWINGS
`
`FIG. 1 is a diagram of a preferred architecture and flow
`chart for implementing the present invention.
`FIG. 2A is an example of an incoming request for object.
`FIG. 2B is an example of an abstract DFL-embedded DPL
`object. DFL and DPL stand for “data formatting language”
`and “data processing language” respectively.
`
`6
`FIG. 2C is an example of an unformatted DFL object
`(processed).
`FIG. 2D is an example of a concrete object (client-
`specific).
`FIG. 2E is an example of an outgoing object.
`FIG. 3A is an example of property rules in a configuration
`database for use in processing objects.
`FIG. 3B is an example of capability rules in a configu-
`ration database for use in processing objects.
`FIG. 4 is a flow chart of a preferred request decoding
`process.
`FIG. 5 is a diagram of a preferred request decoder
`, architecture.
`FIG. 6 is a diagram showing examples of two ways of
`processing and formatting an abstract DFL-embedded DPL
`object.
`
`DETAILED DESCRIP'I‘ION
`Overview
`
`The present invention solves at least the aforementioned
`problems. In short. the present invention provides a method
`and defines an apparatus for creating and serving custom
`objects “on-the-fly” (dynamically) for requests coming from
`users and clients through various protocols and in various
`languages. An example of an implementation of the present
`invention is referred to as dynamic object creation and
`serving (DOCS). As shown in FIG. 1, a DOCS method has
`four preferred main phases, each of which is performed by
`a particular module in an apparatus implementing DOCS:
`request decoding and object creation 11, data processing 12,
`object fonnatting 13, and object delivery 14. In addition to
`modules for these four phases in a DOCS implementation,
`there are typically two database modules: a main database
`module 16 and a configuration database module 15. The
`main database module 16 provides a read-write memory for
`storing and serving non-configuration data. The configura-
`tion database module 15 stores configurations for the other
`modules.
`
`DOCS also uses two different internal languages: a data
`processing language (DPL) and a data formatting language
`(DFL). A DFL is a means for specifying concrete, client-
`independent objects. A DPL is a means for specifying
`abstract objects. Usually, abstract objects are defined by
`embedding DFL code and code fragments within the DPL.
`The data processor 12 then takes abstract objects defined in
`a DFL-embedded DPL and outputs plain DFL objects for an
`object formatter.
`An object is defined herein as a collection of data. An
`object may be an image, audio, video, text, or a document
`containing a combination of the above because an object
`may contain sub-objects. A request is an object itself, but
`maintains the name “request" to distinguish itself from other
`objects in DOCS or other implementations. The term
`“request” also serves as a name for the category of incoming
`objects that would result in some sort of processing being
`performed by a DOCS system, although a “request” does not
`necessarily have to be a request in a human sense. For
`example, through a “request” a client may inform a DOCS
`system of a particular piece of information (e.g., user X is 5
`foot, 11 inches tall). Explicitly this is not a request, but
`implicitly the “request” is asking that a DOCS system store
`the information for reference in future “requests” and pro-
`vide the client with some sort of acknowledgment.
`
`Phase One: Request Decoding and Object Creation
`A request comes in to a DOCS server 9 from a client 10
`through one of a plurality of communication protocols (e.g.,
`
`20
`
`25
`
`30
`
`35
`
`45
`
`50
`
`55
`
`65
`
`

`
`5,706,434
`
`7
`Simple Mail Transfer Protocol (SMTP). Hypertext Transfer
`Protocol (H'I'I‘P), Request For Comments 822 (RFC822), or
`Hypertext Markup Language (HTML)). A protocol is any
`means for conununication; for example, a process for send-
`ing a message which could include data format. As used
`herein. “protocols” include languages for communication.
`Even though some clients are similar in that they speak
`the same protocol they may dilfer in dialect. For example, on
`the World Wide Web. all clients typically use the HTTP
`protocol and HTML (Hypertext Markup Language), though
`different clients use different versions of HTTP and speak
`ditferent dialects of HTML. To solve the problem of coor-
`dinating communication across multiple protocols and
`dialects. the request decoder has sub-modules which know
`each desired protocol and can recognize properties of vari-
`ous clients (such as preferred data language dialects). As
`used herein, “properties” includes properties and capabili-
`ties. A capability is a type of property which specifies, for
`example. how a client can format data or perform other
`functions.
`
`Rule sets are used to decode properties of clients. As in a
`conventional expert system. these rule sets may be encoded
`logical rules and heuristics that tell how to recognize prop-
`erfies from protocols and request clues and how to deal with
`particular clients (see FIGS. 3A and 3B). After identifying
`what object was requested. the request decoder 11 also
`informs the main database 16 of any information updates
`from the incoming request. To finish the phase, the request
`decoder creates and passes an abstract DFL-embedded DPL
`skeleton object to the data processor 12.
`
`Phase Two: Data Processing
`
`The data processor 12 receives the abstract DFL-
`embedded DPL message template from the request decoder
`11 and retrieves any needed information from the main
`database 16 (such as a classified advertisement or the results
`of a database search) to merge with the abstract object
`skeleton. When executed. the DPL object performs merging
`substitutions and other manipulations on the abstract skel-
`eton object. Properties of users and clients as well as data
`retrieved from the main database 16 and configuration
`database 15 can all aflect how the DPL object is assembled.
`The result of all of this manipulation is an object defined in
`DFL, which is then passed on to the object formatter 13.
`
`Phase Three: Object Formatting
`
`The object formatter 13 receives a merged, but
`unformatted, DFL object from the data processor. The object
`formatter 13 then converts the client-independent DFL data
`object description into a concrete, client-dependent object
`ready for outgoing transport. This conversion is accom-
`plished by using a set of filters (dependent upon properties
`of the client) that take a DFL object and convert it to a
`particular concrete format such as RFC822 or HTML using
`a set of configured formatting rules (see FIG. 6). The
`concrete formats themselves may be forms of a DFL (e.g.,
`HTML is a DFL). Therefore, the main DFL should be
`abstract and powerful enough to express structures in any of
`the possible DFLs of the concrete formats. Also, because the
`DFL object is originally embedded as code and code frag-
`ments within a DPL object, some of the object formatting
`can actually be done by the data processor. This is because
`the outputted DFL object can vary depending upon inputs to
`the DPL object. The object fomtatting phase is not meant to
`be the only formatting phase, just preferably the final
`formatting phase before object delivery.
`
`8
`Phase Four: Object Delivery
`
`While the request decoder 13 is much like a receiver for
`a server using a DOCS methodology. the object deliverer 14
`is much like a transmitter. Like the request decoder 11. the
`object deliverer 14 has submodules that understand different
`communication protocols. but instead of being designed to
`decode incoming objects. it is designed to format outgoing
`objects for transmission. Object formatting and object deliv-
`ery could alternatively be performed in one stage or a single
`process.
`
`10
`
`Main Database
`
`The main database 16 is typically used to store informa-
`tion from incoming requests, record outgoing transactions,
`and serve data to be placed in outgoing objects.
`
`Configuration Database
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`65
`
`The configuration database 15 is typically used to store
`configurations for decoding requests and formatting objects.
`The configuration database 15, though logically separate
`from the main database 16, could actually be physically
`stored in the same place as the main database 16 (e.g., in
`relational database tables). although this is not necessary.
`
`Data Processing Language (DPL)
`
`A DPL is a language whose function is to organize,
`substitute, and otherwise manipulate data. A DPL may or
`may not he a specialized language, though it may be driven
`to be a specialized language by particular needs for data
`manipulation. Usually, a DPL should be robust in function
`and offer basic conditional and control structures (such as
`IFs, loops, and procedure calls) so that these abilities are
`available in the creation of objects.
`
`Data Formatting Language (DFL)
`
`A DFL is a language whose primary function is to
`organize the presentation of data. A DFL could be imple-
`mented with a markup language (such as SGML or HTML).
`or a sophisticated programming language (such as the
`POSTSCRIPI‘ language). There is no requirement that the
`DPL and DFL be separate languages. It is possible that they
`could be the same language (e.g., the POSTSCRIPT lan-
`guage could be both a DPL and a DFL because it offers both
`data manipulation abilities and data fonuatting abilities).
`
`DESCRIPTION OF A PREFERRED
`EMBODJMENT
`
`In a preferred embodiment of the invention disclosed
`herein, a system operates using a programmed computer
`having the UNIX operating system. The exemplary embodi-
`meut uses a SPARCCENTER 2000 server. Other computer
`hardware and operating systems capable of running on a
`network may be used with some modifications to software
`(e.g., an IBM-Compatible 80486 personal computer having
`the MICROSOFI‘ WINDOWS NT operating system, or a
`Digital Equipment Corporation VAX 11/780 having the
`VMS operating system). Although a preferred embodiment
`uses both the Perl and C programming languages, other
`programming languages may be used to implement the
`present invention. A preferred embodiment of the invention
`also has program modules for the various phases of a DOCS
`method.
`
`The modules shown in FIG. 1 are an example of an
`implementation of the phases of a DOCS method. FIGS.
`
`

`
`5,706,434
`
`9
`2A—2E illustrate an example of processing a request
`throughout the modules shown in FIG. 1.
`
`Request Decoding
`
`The request decoder 11 and object deliverer 14 share
`various protocol modules for communication. There are. for
`example, two protocol modules: one for SMTP electronic
`mail communication and one for H'ITP-based World Wide
`Web comm