(12) United States Patent
`Huang et al.
`
`USOO6438576B1
`(10) Patent No.:
`US 6,438,576 B1
`(45) Date of Patent:
`Aug. 20, 2002
`
`(54) METHOD AND APPARATUS OF A
`COLLABORATIVE PROXY SYSTEM FOR
`DISTRIBUTED DEPLOYMENT OF OBJECT
`RENDERING
`
`(75) Inventors: Yun-Wu Huang; Philip S.-L. Yu, both
`of Chappaqua; Kun-Lung Wu,
`Yorktown Heights, all of NY (US)
`(73) Assignee: International Business Machines
`Corporation, Armonk, NY (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`
`(*) Notice:
`
`(21) Appl. No.: 09/280,746
`(22) Filed:
`Mar. 29, 1999
`(51) Int. Cl. ................................................ G06F 15/16
`(52) U.S. Cl. ......................... 709/202; 709/201; 707/10;
`707/104
`(58) Field of Search ................................. 709/202, 201,
`709/303; 707/10, 104
`
`(56)
`
`References Cited
`U.S. PATENT DOCUMENTS
`
`5,572,643 A 11/1996 Judson ....................... 709/218
`5,673,322 A * 9/1997 Pepe et al. .................... 380/49
`5,742,768 A * 4/1998 Gennaro et al.
`5,751,957 A * 5/1998 Hiroya et al................ 709/203
`5,793.964 A * 8/1998 Rogers et al. ...
`... 709/202
`5,826,025 A * 10/1998 Gramlich ............. ... 709/217
`5,862,481. A * 1/1999 Kulkarni et al. .....
`... 455/432
`5,918,013 A * 6/1999 Mighdoll et al. ........... 709/217
`6,122,666 A
`9/2000 Beurket et al. ............. 709/226
`6,275,937 B1 * 8/2001 Hailpern et al. ............ 713/188
`OTHER PUBLICATIONS
`“MIME (Multipurpose Internet Mail Extensions) Part One:
`Mechanisms for Specifying and Describing the Format of
`Internet Message Bodies,” Network Working Group N.
`Borenstein Request for Comments: 1521 Bellcore, Obso
`letes: 1341, Category: Stadards Track, pp. 1-75 (Sep.1993).
`T. Krauskopf, J. Miller, P. Resnick and W. Tresse, “PICS
`Label Distribution Label Syntax and Communication Pro
`tocols,” Version 1.1, REC-PICS.labels-961031, W3C Rec
`ommendation, pp. 1-31 (Oct. 31, 1996).
`
`
`
`C. Evans, C.D.W. Feather, A. Hopmann, M. Presler-Mar
`shall, and Paul Resnick, “PICSRules 1.1.” Last Modified
`Aug. 28, 1997, pp. 1-23.
`Group WatchDog Version 1.2, User's Guide, Feb. 16, 1994,
`Group Wege & Partner EDV-Unternehmensberatung
`GmbH, Karlsruhe.
`Ortega, A. et al., A Framework for Optimization of a
`Multiresolution Remote Image Retrieval System, IEEE
`1994, pp. 672–679.
`Wallace, Gregory, “The JPEG Still Picture Compression
`Standard", IEEE, vol. 38, No. 1, Feb. 1992, 17 pgs.
`Fox, Armando et al., “Adapting to Network and Client
`Variation Using Infrastructural Proxies: Lessons and Per
`spectives”, IEEE, Aug. 1998, pp. 10-19.
`
`* cited by examiner
`
`Primary Examiner Krisna Lim
`(74) Attorney, Agent, or Firm-Gail Zarick, Esq.; Perman
`& Green, LLP
`ABSTRACT
`(57)
`A distributed object rendering method and System for a
`collaborative data network is disclosed. The data network,
`which may include the Internet, has attached computing
`nodes, including object requestor nodes, object Source
`nodes, and intermediate nodes which may be proxy servers.
`The method can allow each participating proxy Server to
`adapt to the dynamic load conditions of itself as well as
`proxies, as well as to dynamic traffic conditions in the data
`network. The determination of which proxy or set of proxies
`is to perform object rendering and caching is based on a
`distributed, collaborative method that is adopted among the
`proxies. The criteria for Such a method can include the
`bandwidth and current load of the network links among
`proxies, and/or the respective CPU usage of the proxies. If
`an object rendering can be staged, e.g., different resolution
`rendering, it can be performed by more than one of the
`proxies. The determination of which proxy performs which
`Stage of the multistage rendering can also be adaptive to the
`dynamic load conditions, as well as network conditions.
`
`41 Claims, 5 Drawing Sheets
`
`Akamai Ex. 1005
`Akamai Techs. v. Equil IP Holdings
`IPR2023-00330
`Page 00001
`
`

`

`U.S. Patent
`
`Aug. 20, 2002
`
`Sheet 1 of 5
`
`US 6,438,576 B1
`
`n
`
`O
`n
`wn
`
`vis
`CN
`yers
`
`
`
`O
`CN
`vals
`
`ve
`
`-
`
`S
`
`1.
`D
`1.
`L
`Of
`
`CN
`v
`
`val
`
`O
`
`v-
`y
`
`O
`
`ve
`
`3
`
`IPR2023-00330 Page 00002
`
`

`

`U.S. Patent
`
`Aug. 20, 2002
`
`Sheet 2 of 5
`
`US 6,438,576 B1
`
`
`
`LsandayLoargo
`
`dtTdNVH
`
`YIYSON3Y
`
`LOArao
`
`SHOVO
`
`YIOVNVA
`
`‘207
`YFIGNVHLOArgO91901“£0z
`
`
`
`
`AYOWAN
`
`
`
` ™ChE‘LLL‘OLL
`
`LO¢
`
`COs
`
`IPR2023-00330 Page 00003
`
`IPR2023-00330 Page 00003
`
`

`

`U.S. Patent
`
`Aug. 20, 2002
`
`Sheet 3 of 5
`
`US 6,438,576 B1
`
`
`
`| 02
`
`ZO
`
`909,
`
`EXIOANI
`
`0
`
`3XOANI
`
`IPR2023-00330 Page 00004
`
`

`

`U.S. Patent
`
`Aug. 20, 2002
`
`Sheet 4 of 5
`
`US 6,438,576 B1
`
`Ç07
`
`/07
`
`& ATTWOOT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2023-00330 Page 00005
`
`

`

`U.S. Patent
`
`Aug. 20, 2002
`
`Sheet 5 of 5
`
`US 6,438,576 B1
`
`809
`
`
`
`}}30WNWW 3HOWOON
`
`Z09| 09
`
`SE),
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`909G09
`
`& ÅTTWOOT
`
`ON
`
`IPR2023-00330 Page 00006
`
`

`

`US 6,438,576 B1
`
`1O
`
`15
`
`25
`
`35
`
`40
`
`1
`METHOD AND APPARATUS OF A
`COLLABORATIVE PROXY SYSTEM FOR
`DISTRIBUTED DEPLOYMENT OF OBJECT
`RENDERING
`CROSS-REFERENCE TO RELATED PATENT
`APPLICATIONS
`This Patent Application is related to co-pending U.S.
`patent application Ser. No.: 08/979,748, now U.S. Pat. No.
`6,275,937 issued Aug. 14, 2001, filed Nov. 26, 1997, entitled
`“Collaborative Server Processing of Content and Meta
`Information with Application to Virus Checking in a Server
`Network,” by B. Hailpern et al. This Patent Application is
`also related to co-pending U.S. patent application Ser. No.:
`09/027,832, now U.S. Pat. No. 6,122,666 issued Sep. 19,
`2000, filed Feb. 23, 1998, entitled “Method for Collabora
`tive Transformation and Caching of Web Objects in a Proxy
`Network', by J. Beurket et al.
`FIELD OF THE INVENTION
`This invention relates to data networks and, more
`particularly, to an ability to perform distributed object ren
`dering on a data network. Specifically, a plurality of col
`laborative proxy servers perform distributed object render
`ing So that object contents can be displayed on or consumed
`by various kinds of client devices, based on their respective
`device capabilities and Specifications.
`BACKGROUND OF THE INVENTION
`AS the Internet becomes ever more popular, more non
`personal computer (PC) devices, Such as So-called Smart
`phones and PDAS (personal digital assistants), are connected
`to the Internet, either by wired or wireless connections. The
`Internet is becoming the so-called pervasive computing
`environment, where various kinds of information
`appliances/devices, as well as PCs and other Server
`computers, are all connected. In Such a pervasive computing
`environment it is expected that the individual applianceS/
`devices will have different computing powers and display
`capabilities. For example, Some devices may be capable of
`displaying color imageS while others can only display black
`and-white images. Also, Some devices may have large,
`easily viewed displays while others may have only a rela
`tively much Smaller display. It can thus be appreciated that
`in Such a pervasive computing environment the same infor
`mation objects may have to be rendered in different forms or
`resolutions according to different device display Specifica
`tions. Various techniques have been developed to represent
`information in various resolutions. In “A Framework for
`Optimization of a Multiresolution Remote Image Retrieval
`System” by A. Ortega et al., Proceedings of IEEE InforCom,
`1994, a System was disclosed to transmit images and Video
`in multiple resolutions. In “The JPEG Still Picture Com
`pression Standard,” by G. Wallace, IEEE Transactions on
`Consumer Electronics, vol. 38, no. 1, February 1992, the
`JPEG image compression Standard was described to repre
`Sent images in multiple different resolutions.
`The rendering of an object into different forms or reso
`lutions can be performed in different locations. One possible
`location is within the content Servers. However, the content
`Servers may easily become overloaded, especially with a
`large number of different client requests all coming to the
`Same content Servers. Another possible location to render the
`object is within a client machine which will actually con
`Sume the object. However, this is an undesirable Solution
`Since many typical client machines tend to be too limited in
`computing power to perform the necessary rendering func
`tion.
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`Alternatively, the rendering can be done by one or more
`proxy servers, which are positioned in the data network
`between the content servers and the client devices. In this
`Scenario the device-specific information can be piggybacked
`on the meta-information associated with the objects, and the
`proxy server can perform object rendering according to the
`meta-information. Once the object rendering is performed
`by the proxy server the result can be cached (Stored) at the
`proxy Server. In this case any Subsequent requests for the
`Same object, from the same kind of device, can be served
`directly from the Stored copy in proxy server cache. As a
`result, the repeated rendering of the object for the same kind
`of device can be avoided. In order to improve the response
`time, many PC servers, such as the IBM NETFINITY
`Servers, are being deployed in the Internet as a network of
`proxy servers (IBM and NETFINITY are both registered
`trademarks of the International Business Machines
`Corporation). These proxy servers can work collaboratively
`in object rendering and caching.
`For example, in the above-referenced commonly assigned
`U.S. Patent Application by B. Hailpern et al., entitled
`“Collaborative Server Processing of Content and Meta
`Information with Application to Virus Checking in a Server
`Network,” a method was disclosed to perform virus check
`ing based on the meta-information on the proxy network by
`choosing one proxy server. This approach discloses a
`method to perform certain computations on the object based
`on the meta-information by one of the proxies in the
`network. No Specific attention was paid to the aspect of
`caching the objects after the computation. Also, the com
`putation is done completely by the chosen proxy Server, and
`is not done by more than one proxy server in a distributed
`way.
`In the above-referenced commonly assigned U.S. Patent
`Application by J. Beurket et al., entitled “Method for Col
`laborative Transformation and Caching of Web Objects in a
`Proxy Network,” a method was proposed to locate one or
`more Specialized proxies to perform the transformation and
`caching. Once the transformation/rendering is done and
`cached, all Subsequent requests for the desired resolution are
`Served by these specialized transformational proxies. In this
`approach the caching and rendering of an object is com
`pletely done on the same Specialized proxies, and the
`rendering of objects is not readily performed in different
`Stages or collaboratively by more than one different proxies
`in a distributed way.
`In an approach described by A. Fox, entitled "Adapting to
`Network and Client Variation Using Infrastructural Proxies:
`Lessons and Perspective,” IEEE Personal Communications,
`pp. 10-19, August 1998, a method was disclosed to perform
`datatype-specific distillation on a cluster of proxies. Object
`rendering and caching are all performed by the Specific
`cluster of proxies. A centralized manager is used to perform
`load balancing among the proxies in the cluster. A drawback
`of this approach is that object rendering and caching is
`completely done on the Same cluster of proxies, and is not
`done in a distributed way. Other proxies in the network, but
`not in the same cluster, cannot participate in Some of the
`Stages in the object rendering process.
`In View of the foregoing, it can be appreciated that there
`exists a need for a collaborative proxy System that can
`deploy object rendering in a distributed fashion. Prior to this
`invention, this need was not fulfilled.
`OBJECTS AND ADVANTAGES OF THE
`INVENTION
`It is a first object and advantage of this invention to
`provide a collaborative proxy System that performs object
`rendering in a distributed fashion.
`
`IPR2023-00330 Page 00007
`
`

`

`3
`It is another object and advantage of this invention to
`provide a technique to distribute object rendering processing
`throughout a proxy network, and to not concentrate the
`object rendering processing in only Specialized object ren
`dering proxies.
`It is a further object and advantage of this invention to
`provide a collaborative proxy network wherein object pro
`cessing tasks, Such as rendering, are distributed in an adap
`tive fashion based on, for example, dynamic loading char
`acteristics of the proxy network.
`SUMMARY OF THE INVENTION
`The foregoing and other problems are overcome and the
`objects and advantages are realized by methods and appa
`ratus in accordance with embodiments of this invention.
`In accordance with the teachings of this invention a
`distributed object rendering method for a collaborative data
`network is disclosed. The data network, which may include
`the Internet, has attached computing nodes, including object
`requestor nodes, object Source nodes, and intermediate
`nodes which may be proxy servers. The method can allow
`each participating proxy server, which may be referred to
`Simply as a “proxy' and in the plural form as “proxies', to
`adapt to the dynamic load conditions of itself as well as
`proxies, as well as to the dynamic traffic conditions in the
`data network. The determination of which proxy or set of
`proxies is to perform object rendering and caching is based
`on a distributed, collaborative method that is adopted among
`the proxies. The criteria for Such a method can include the
`bandwidth and current load of the network links among
`proxies, and/or the respective CPU usage of the proxies. If
`an object rendering can be staged, e.g., different resolution
`rendering, it can be performed by more than one of the
`proxies. The determination of which proxy performs which
`Stage of the multistage rendering can also be adaptive to the
`dynamic load conditions, as well as network conditions.
`As a result, a participating proxy, upon Serving an object,
`first determines if object rendering processing is needed
`based on the client device type. If the object rendering
`processing is found to be required, then based on the
`requested object type and the collaborative information
`about other proxies in the network, the participating proxy
`can choose to (a) perform the complete object rendering by
`itself, (b) perform a partial rendering if the rendering process
`can be staged, or (c) do nothing and let another proxy
`perform the rendering task. The objective is to distribute the
`rendering processing throughout the proxy network, not just
`in the Specialized object rendering proxies.
`This invention thus provides a distributed, dynamic, hier
`archical rendering method in a network comprised of inter
`connected computing nodes. The method includes Steps of,
`at an object requesting node or at a proxy node coupled to
`the object requesting node, including with an object request
`certain meta-information describing the capabilities of the
`object requesting node (referred to herein as receiver hint
`information (RHI) or as requestor-specific capability
`information); at an intermediate node, receiving an object
`request and forwarding the request to another intermediate
`node (or to a Source of the requested object), if the requested
`object is not available locally, while modifying the RHI to
`include information for Specifying its local condition for
`providing the rendering Service; otherwise, the intermediate
`node determines the required rendering, and invokes a
`selection function to determine, based on the RHI, what part
`or Subset of the required rendering is to be carried out by the
`intermediate node. The intermediate node then performs the
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,438,576 B1
`
`4
`rendering and passes the rendered object to the requesting
`node. As a part of this invention another intermediate node
`that receives a partially rendered object invokes a Selection
`function to determine, based on the RHI, what portion (or
`all) of the remaining required rendering is to be carried out
`by this intermediate node, and then performs the rendering
`and passes rendered object to the requesting node.
`At an intermediate node having a less detailed version of
`the requested object the method includes Such information in
`the RHI, forwards the request to another node, and at another
`intermediate node that has a more detailed version of the
`requested object, the node decides whether to return the
`more detailed version of the requested object, without fur
`ther local rendering, or to instead perform Some rendering
`and return a partially rendered object, or to instead return a
`completely rendered object.
`The local condition information can include the loading
`and/or capacity of the node (Such as CPU utilization), and
`can be a function of the network delay (from the requesting
`node). The local condition information can further include a
`type of rendering that can be performed at the node (which
`can depend on the Software available at the node). The local
`condition information can further include the Storage avail
`ability at the local node.
`A Selection method is provided for each intermediate node
`to decide dynamically and independently of other nodes
`what portion of the required rendering to perform locally
`using the RHI information. The selection method can
`include steps of (a) dividing a remaining rendering operation
`into Steps; (b) Selecting one or more rendering Steps to be
`performed locally in order to optimize a given objective
`function, using the RHI information as an input parameter;
`and (c) performing the one or more rendering steps selected
`for the current node. The objective function can be to
`perform the rendering Steps with the most bandwidth reduc
`tion first, and/or to perform the rendering StepS. So as to
`reduce load unbalancing among the remaining nodes on the
`path to the requesting client device node. The objective
`function can also be an estimated response time from this
`node to the requesting node, based on the RHI information.
`Alternatively, the Selection method can includes Steps of
`(a) dividing the remaining rendering operation into steps; (b)
`assigning, in accordance With an assignment plan, the ren
`dering Steps to other nodes on a path to the requesting client
`device node to optimize the given objective function using
`the RHI information as the input parameter; and (c) per
`forming the rendering Step or Steps that are assigned to the
`current node. It is also within the Scope of the teaching of
`this invention to pass the assignment plan as meta informa
`tion associated with the rendered object to a next node,
`which is then free to modify the assignment plan according
`to local considerations, Such as CPU loading at the next
`node.
`The rendered object and/or the received object can be
`passed to a cache manager for a caching consideration, Such
`as a cost to produce the rendered object.
`In general, different intermediate nodes can choose to use
`different Selection functions for rendering, and each inter
`mediate node may choose a different Selection function
`depending upon the local condition of the node (e.g., CPU
`loading).
`Each node may also periodically collect load Statistic
`information from neighboring nodes, instead of including
`the information in the RHI associated with each request.
`BRIEF DESCRIPTION OF THE DRAWINGS
`The above set forth and other features of the invention are
`made more apparent in the ensuing Detailed Description of
`
`IPR2023-00330 Page 00008
`
`

`

`S
`the Invention when read in conjunction with the attached
`Drawings, wherein:
`FIG. 1 is a block diagram of an Internet environment in
`accordance with an exemplary embodiment of the present
`invention.
`FIG. 2 is a block diagram which illustrates a proxy
`environment in accordance with an exemplary embodiment
`of the present invention.
`FIG. 3 is a flowchart diagram which illustrates the con
`figuration of proxy Servers in accordance with an exemplary
`embodiment of the present invention.
`FIG. 4 is a flowchart diagram which illustrates operations
`of a proxy server when it receives an object request in
`accordance with an exemplary embodiment of the present
`invention.
`FIG. 5 is a flowchart diagram which illustrates operations
`of a proxy server when it receives an object in accordance
`with an exemplary embodiment of the present invention.
`DETAILED DESCRIPTION OF THE
`INVENTION
`FIG. 1 is a block diagram illustrating the overall archi
`tecture of a proxy network in accordance with an exemplary
`embodiment of the present invention. AS is shown, various
`clients 130, 131 may be connected through proxy servers (or
`proxies) 110, 111, 112 to access information objects in the
`content servers 120, 121. The clients, proxies and content
`Servers may be all connected through a network 101, Such as
`the Internet. The proxies 110, 111, 112 are generally
`employed to improve access times, and to provide Services
`Such as caching and content filtering. For example, an ISP
`(Internet Service Provider) may comprise a hierarchical
`network of proxy servers 110, 111,112 positioned at various
`locations (e.g., local, regional and national proxy servers).
`Alternatively, and also be example, there may be one or
`more proxy servers that function within a private or Semi
`private local area network (LAN) or wide area network
`(WAN), and the one or more proxy servers may be located
`behind a firewall that provides security for the LAN or
`WAN.
`Object renderings are performed by the proxies 110, 111,
`112 based on objects retrieved from the content servers 120,
`121. The Specific device capabilities, referred to herein as
`receiver hint information (RHI), as well as the object data
`type (generally referred to herein as object-specific descrip
`tor information) are included Such as by being appended to
`the meta-information associated with requests and requested
`objects. The RHI can be included with an object request by
`the requesting client device 130, 131, or by one of the
`proxies (e.g., the first proxy coupled to the requesting
`device.) In the latter case the proxy 110, 111, 112 can access
`a table of device capabilities, based on an identifier of the
`requesting device Sent with the request, and can construct
`the RHI based on the stored information in the table. As an
`example, and assuming an ISP arrangement, the local proxy
`Server has access to a table wherein are Stored the charac
`teristics (e.g., type of display, size of graphics memory, etc.)
`of the various client devices that can be serviced by the local
`proxy. The table entry for a particular client device 130, 131
`can be stored when the device first registers with the ISP.
`Thereafter, the local proxy server receives an identifier of the
`client device when the client device makes a request,
`accesses the table, and constructs the appropriate RHI for
`inclusion with the object request. In a similar manner the
`Source of the requested object can add the object-specific
`descriptor information to the returned object, or this infor
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,438,576 B1
`
`6
`mation can be added by the proxy Server local to the Source
`of the requested object (for the case where a proxy server
`does not fulfill the request from a copy of the object stored
`in the proxy, as described in further detail below.)
`In a presently preferred embodiment of this invention the
`RHI is implemented using PICSTM (“Platform for Internet
`Content Selection”) information, and this aspect of the
`invention is discussed in further detail below.
`When a requested object passes through the proxy
`network, any proxy server 110, 111, 112 can perform a
`complete or partial rendering based on the associated RHI.
`For example, if the entire rendering process can be parti
`tioned into two or more Steps, a given one of the proxy
`Servers (e.g., 110) may decide to perform only one of the
`rendering Steps, and to then forward the partially rendered
`object to another proxy server (e.g., 111). The proxy server
`110 also modifies the RHI to reflect the processing that it
`performed, and forwards the modified RHI as well to the
`proxy server 111. Furthermore, local conditions about a
`given one of the proxy servers 110, 111, 112, such as the
`CPU load and the network traffic load, can also be included
`in the RHI and passed along through the network 101. These
`aspects of the invention are discussed below in further detail.
`In an exemplary embodiment of this invention the clients
`130, 131 may include, for example, a personal computer
`(PC), a workStation, a Smart phone, a personal digital
`assistant (PDA), etc. Proxy servers 110, 111, 112 may
`comprise a PC server, a RISC SYSTEM/6000 server, or a
`S/390 server running, for example, Internet Connection
`Server (ICS) available from IBM (RISC SYSTEM/6000,
`S/390, and Internet Connection Server are all trademarks of
`the International Business Machines Corporation). The net
`work 101 may be, for example, the Internet, the World Wide
`Web, an Intranet and local area networks (LANs). Content
`servers 120, 121 may include a PC server, a RS/6000 server,
`or an S/390 server running Lotus Go Web server, or Lotus
`Domino Go server (Go Web and Domino Go are trademarks
`of Lotus Development Corporation).
`FIG. 2 is a block diagram illustrating a general proxy
`environment in accordance with an exemplary embodiment
`of the present invention. Proxy server node 201 (which
`could be, by example, any one of the proxy servers 110, 111,
`112 of FIG. 1) is used to represent a computing node that can
`Service requests through a network 212, Such as the network
`101 of FIG. 1. Proxy server node 201 preferably includes a
`CPU 211, memory 202 such as RAM, and storage devices
`210 Such as disk Storage devices or, more generally, a direct
`access storage device (DASD). The proxy server logic 203
`may be stored within the memory 202, and is preferably
`embodied as computer readable and executable code which
`is loaded from disk 210 into memory 202 for execution by
`CPU211. The proxy server logic 203, which is described in
`more detail with reference to FIG. 3, includes an object
`handler 204 (described in further detail in FIG. 5) and an
`object request handler 205 (described in further detail in
`FIG. 4). An object renderer 206, which performs object
`rendering according to the RHI associated with a particular
`object, may also be included in the proxy server logic 203.
`Object renderer may be a computer program which renders,
`by example, a color image into a black-and-white image, or
`one that reduces a complex HyperText Markup Language
`(HTML) text into a simple HTML text containing only a
`summary of the HTML headers. Proxy server logic 203 may
`also include a cache manager 207 which maintains a local
`copy of the partially rendered or completely rendered
`objects in order to avoid repeating Some object rendering
`operations with the same proxy Server.
`
`IPR2023-00330 Page 00009
`
`

`

`7
`FIG. 3 is a flow chart diagram that depicts the general
`operations of the proxy Server node 201 when it is receiving
`input in accordance with an exemplary embodiment of the
`present invention. At step 301, the proxy server node 201
`waits for the input. Depending on the input received, dif
`ferent actions are taken. If the input received is an object
`request at step 302 (e.g., a HyperText Transfer Protocol
`(HTTP) request from a PDA-type of client 130, 131), then
`the object request handler 205 is invoked at step 303. The
`HTTP is generally used for retrieving document contents
`and/or descriptive header information. A detailed implemen
`tation of object request handler 205 is described in FIG. 4.
`If the input received is an object, Step 304, (e.g. an object
`returned to the present proxy server node 201 in response to
`a request made by the proxy server node 201) the object
`handler 206 is invoked at step 305. A detailed implementa
`tion of the object handler 206 is described in FIG. 5. For
`other types of requests, such as file transfer protocol (FTP)
`requests, a miscellaneous handler is invoked at Step 306.
`After invoking the appropriate handler, control returns to
`step 301 to wait for the next input to the proxy server node
`201 from the network 212.
`FIG. 4 is a flow chart diagram illustrating the operations
`of the object request handler 205 in accordance with an
`exemplary embodiment of the present invention. At Step
`401, the object request handler 205 checks with the cache
`manager 207 to determine if the requested object is available
`in the cache. It should be noted that the cache may contain
`a leSS detailed version of the requested object, or it may
`contain a more detailed version. A leSS detailed version of
`the object does not Satisfy the requirement and a request for
`the object must be sent out, typically to the appropriate one
`of the content servers 120, 121 or to another proxy server.
`However, a more detailed version of the object may be
`further rendered by the proxy server 110, 111, 112 in order
`to Satisfy the request. If the requested object cannot be found
`in the cache, at step 404, the proxy server 110, 111, 112
`modifies the associated RHI to indicate its ability for pro
`Viding rendering Services and then sends the request and the
`modified RHI to another proxy server or to the content
`server 120, 121, depending on the position of the proxy
`Server in the entire proxy chain.
`If a copy of the requested object can be found in the local
`cache, at Step 402, the proxy Server checks the cached object
`against the RHI to see if any further rendering is necessary.
`Note that the RHI contains the capability specification of the
`receiving device (i.e. the device that originally requested the
`object that was just found in the cache). By checking the
`RHI, the proxy server 110, 111, 112 can determine if any
`further rendering is necessary. If no further rendering is
`necessary, the proxy Server modifies the RHI to indicate its
`local condition for providing rendering Services and returns
`the object at step 403. If further rendering is found to be
`necessary, based on the RHI or the requesting device, then
`the proxy server executes at step 405 a selection function to
`determine whether or not it wishes to perform the rendering
`locally. If the proxy Server decides not to perform any
`rendering locally, the proxy server modifies the RHI to
`indicate its local load condition for providing Such rendering
`services and returns the object along with the modified RHI
`at step 406. If the proxy server instead decides to perform the
`rendering locally, it checks the RHI at step 407 to determine
`if it wishes to complete the entire rendering process, or just
`Some part of the required rendering process. If the proxy
`Server wishes to perform only a portion of the rendering
`process, then it executes at Step 409 another Selection
`function to determine which part of the rendering process to
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,438,576 B1
`
`8
`perform. In either case, and after making the decision to
`perform local rendering at step 405, the proxy server 110,
`111, 112 calls the object renderer 206 to perform the object
`rendering at Step 408. After the rendering proceSS is com
`plete (either a complete or partial rendering), the cache
`manager 207 is called at step 410 to determine whether or
`not to cache a copy of the rendered object locally. The proxy
`server 110, 111, 112 then modifies the RHI at step 406 to
`reflect its local condition and returns the rendered
`(completely rendered or partially rendered) object along
`with the modified RHI.
`Those skilled in the art will appreciate that, at step 404, a
`proxy server 110, 111,112 may indicate in the RHI that it has
`a leSS detailed version of the requested object in the cache,
`and then Send a request for the object to another proxy
`Server. A proxy server that has Stored a more detailed version
`of the requested object may then decide to Send the more
`detailed object to the requesting proxy server, or it may
`instead Send whatever information that is needed in order for
`the requesting proxy server to render the object to the
`necessary resolution. Alternatively, the proxy server 110,
`111, 112 containing the more detailed version of the
`requested object may decide to per