throbber
(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-00332
`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-00332 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-00332 Page 00003
`
`IPR2023-00332 Page 00003
`
`

`

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

`

`U.S. Patent
`
`Aug. 20, 2002
`
`Sheet 4 of 5
`
`US 6,438,576 B1
`
`Ç07
`
`/07
`
`& ATTWOOT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IPR2023-00332 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-00332 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-00332 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-00332 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-00332 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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket