(12) United States Patent
`TS0 et al.
`
`USOO6421733B1
`(10) Patent No.:
`US 6,421,733 B1
`(45) Date of Patent:
`*Jul. 16, 2002
`
`(54) SYSTEM FOR DYNAMICALLY
`TRANSCODING DATA TRANSMITTED
`BETWEEN COMPUTERS
`
`(75) Inventors: Michael Man-Hak TS0, Hillsboro;
`OT TO
`Thomas G. Willis, Portland; John W.
`Richardson, Portland; Robert Conrad
`Knauerhase, Portland; Damien
`Macielinski, Portland, all of OR (US)
`(73) Assignee: Intel Corporation, Santa Clara, CA
`(US)
`
`(*) Notice:
`
`5,461,488 A * 10/1995 Witek ......................... 358/402
`5,483,658 A
`1/1996 Grube et al. ................ 395/800
`5,517,612 A 5/1996 Dwin et al. ................. 395/166
`5,543,920 A * 8/1996 Collins et al. .............. 356/402
`5,544,320 A 8/1996 Konrad - - - - - - - -
`- - - 395/200.09
`5,555,192 A * 9/1996 Grube et al................. 364/514
`S568.550 A * 10
`2- Y-Y-2
`/1996 Ur ................................ 380/3
`5,608,800 A * 3/1997 Hoffmann et al. ............ 380/25
`5,673,322 A
`9/1997 Pepe et al. ..........
`... 380/49
`5,684.969 A 11/1997 Ishida ........................ 395/342
`5,694,334 A * 12/1997 Donahue et al. ............ 709/247
`5,701,451 A 12/1997 Rogers et al. .............. 395/600
`5,706.434 A 1/1998 Kremen et al. ........ 395/200.09
`5,724,556 A 3/1998 Souder et al. .............. 395/500
`This patent issued on a continued pros-
`5,727,159 A
`3/1998 Kikinis ........
`... 395/200.76
`ecution application filed under 37 CFR
`5,742,905 A : 4/1998 Pepe et al. .................. 455/461
`153(d), and is subject to the twenty year E R
`E. E. "... 22.
`patent term provisions of 35 U.S.C.
`5,764,235 A
`6/1998 Hunt et al. ................. 345/428
`154(a)(2).
`5,768,510 A 6/1998 Gish ...........
`... 395/200.33
`5,805,735 A 9/1998 Chen et al. ................. 382/239
`0
`-
`5,826,025 A * 10/1998 Gramlich ............... 395/200.47
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 0 days.
`(List continued on next page.)
`OTHER PUBLICATIONS
`(21) Appl. No.: 08/925,276
`Safranek et al, Method for Matching Compresses Video to
`ATM Networks, IEEE 1995.*
`(22) Filed:
`Sep. 8, 1997
`ASSuncao et al., Congestion Control of Video Traffic with
`O
`O
`Transcoders, IEEE 1997.*
`Related U.S. Application Data
`(60) Provisional application No. 60/041,366, filed on Mar. 25,
`(List continued on next page.)
`1997.
`Primary Examiner-Mark H. Rinehart
`(51) Int. Cl." ................................................ G06F 15/16
`& K
`(52) U.S. Cl. ........................ 709/246; 709/217; 358/402 Alth East's "K
`(58) Field of Search ....................... soso.os. (74) Attorney, Agent, or Firm-Kenyon & Kenyon
`395/200.49, 200.36, 200.59, 200.43, 186,
`(57)
`ABSTRACT
`800; 707/1, 2, 6, 9, 13; 380/3, 25; 364/514;
`356/402; 705/26; 709/217, 231, 204, 210-219, A System for dynamically transcoding data transmitted
`240-249, 1, 226, 202, 224; 713/201; 348/722;
`between computerS is implemented in an apparatus for use
`379/201; 358/402
`in transmitting data between a network Server and a network
`client over a communications link. The apparatus includes a
`parser coupled to a transcode Service provider. The parser is
`configured to Selectively invoke the transcode Service pro
`vider in response to a predetermined Selection criterion.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5,347,578 A * 9/1994 Duxbury ...................... 709/79
`5,373.375 A 12/1994 Weldy ........................ 358/523
`
`4 Claims, 9 Drawing Sheets
`
`
`
`NEWORK CIENT
`
`RANSCODING SERVER
`
`Akamai Ex. 1004
`Akamai Techs. v. Equil IP Holdings
`IPR2023-00332
`Page 00001
`
`

`

`US 6,421,733 B1
`Page 2
`
`U.S. PATENT DOCUMENTS
`
`5,832,208 A 11/1998 Chen et al. ................. 713/201
`5.835087 A * 11/1998 Herz et al................... 345/327
`5.835,718 A * 11/1998 Blewett ........
`... 395/200.48
`5.835,896 A * 11/1998 Fisher et al................... 705/37
`5,838,916 A * 11/1998 Domenikos et al. ... 395/200.49
`5,848,413 A 12/1998 Wolff .......................... 707/10
`5,850,433 A 12/1998 Rondeau ..................... 379/201
`5,862,325 A * 1/1999 Reed et al.
`... 395/200.31
`5,870,543 A * 2/1999 Ronning ..................... 395/186
`5,880,792 A * 3/1999 Ward et al.
`... 348/722
`5,889,943 A * 3/1999 Ji et al. ...................... 713/201
`5,897,622 A * 4/1999 Blinn et al. ................... 705/26
`5,909,683 A * 6/1999 Miginiac et al............... 707/13
`5,918,013 A * 6/1999 Mighdoll et al. .
`... 709/217
`5,983,004 A * 11/1999 Shaw et al. .......
`... 709/247
`5.996,022 A * 11/1999 Krueger et al. ...
`... 709/247
`6,151,618 A 11/2000 Wahbe et al. .................. 709/1
`6,158.903 A * 12/2000 Schaeffer et al. .
`... 709/204
`6,161,137 A * 12/2000 Ogdon et al. .....
`... 709/224
`6,185,625 B1
`2/2001 Tso et al. ................... 709/247
`OTHER PUBLICATIONS
`PC Virus Alert, http://byu.edu/csr/www/solutions/handouts/
`pevirus.html 1995.*
`Drehammar. Computer Viruses, Trojans and Logical Boms,
`http://www.student.nada.kth.se/-d95-fcdr/compvir.html.
`1996.*
`
`
`
`Protecting Electronic Health Information. http://ww
`w.nap.edu./readingroom/books/ftriš2fe.html 3/97.*
`Fox et al., Reducing WWW latency and Bandwidth Require
`ments by Real Time Distillation 5/1996.*
`Wu et al. An Efficient JPEG to MPEG-1 Transcoding
`Algorithm. IEEE 6/1996.*
`Fox, Gribble, Chawathe and Brewer, Adapting to network
`and client variation using infrastructural proxies, lessons and
`perspectives, IEEE Personal Communications, Vol. 5, ISS. 4,
`Aug. 1998, pp. 10–19.*
`Zenel and Duchamp, “General purpose proxies: Solved and
`unsolved problems,” Sixth Workshop on Hot Topics in
`Operating Systems, May 1997, pp. 87-92.*
`Fox et al., “Adapting to Network and Client Variability via
`On-Demand Dynamic Distillation,” U of C at Berkeley,
`9/1996.*
`Armando Fox and Eric A. Brewer, “Reducing WWW
`Latency and Bandwidth Requirements by Real-Time Dis
`tillation,” Fifth International World Wide Web Conference,
`May 6–10, 1996.
`Armando Fox et al., Adapting to Network and Client Vari
`ability via On-Demand Dynamic Distillation, University of
`Cal. at Berkeley, Sep. 1996.
`
`* cited by examiner
`
`IPR2023-00332 Page 00002
`
`

`

`18
`
`
`
`
`
`12NETWORKCLIENT
`
`
`
`JNETWORKSERVER
`
`
`
`
`
`U.S. Patent
`U.S. Patent
`
`Jul. 16, 2002
`Jul. 16, 2002
`
`Sheet 1 of 9
`Sheet 1 of 9
`
`US 6,421,733 B1
`US 6,421,733 B1
`
`
`
`so
`
`FIG.1
`
`IPR2023-00332 Page 00003
`
`IPR2023-00332 Page 00003
`
`

`

`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 2 of 9
`
`US 6,421,733 B1
`
`20
`
`22
`
`24
`
`
`
`
`
`
`
`TRANSCODER
`
`PARSER
`
`TRANSCODE
`SERVICE PROVIDERS
`
`FIG.2
`
`IPR2023-00332 Page 00004
`
`

`

`
`
`
`
`
`
`
`
`
`
`uaSMONE
`
`JQOOSNVUL IN3N0
`
`U.S. Patent
`U.S. Patent
`
`Jul. 16, 2002
`Jul. 16, 2002
`
`Sheet 3 of 9
`Sheet 3 of 9
`
`US 6,421,733 B1
`US 6,421,733 B1
`
`0 –CÆ)
`
`
`
`SHIQIAONdJOANIS
`
`
`
`YYOMIEN
`
`IPR2023-00332 Page 00005
`
`IPR2023-00332 Page 00005
`
`

`

`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 4 of 9
`
`US 6,421,733 B1
`
`
`
`YO(440)TWNIDINOWOESYO4HOLIMS13S
`
`GVOINMOGOL3Y3HONO
`
`
`
`JUVMLIOSLNIN
`
`:dyqy>JUSLIN
`
`
`
`
`(OLNY)‘NON
`
`YaSMONE
`
`
`JOVINSINIINIGOOSNVULavo7vay|anon|duvMyOsove|oF
`AMOLOINIG=SNOWdOSAYVNN0Od09MSALid3=Jil
`
`
`CEE
`
`MOCNIM
`
`cy
`
`Vols
`
`IPR2023-00332 Page 00006
`
`IPR2023-00332 Page 00006
`
`
`

`

`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 5 of 9
`
`US 6,421,733 B1
`
`
`
`
`
`
`
`
`
`
`
`MENXES ON|000SNVNI
`
`IPR2023-00332 Page 00007
`
`

`

`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 6 of 9
`
`US 6,421,733 B1
`
`
`
`
`
`
`
`32
`
`BROWSER
`
`HTTP
`LOCAL PROXY
`
`12
`
`TRANSCODE
`SERVICE PROVIDERS
`
`CACHE INTERFACE
`- C
`
`Gocead,
`
`54
`
`NETWORK CLIENT
`
`FIG.6
`
`IPR2023-00332 Page 00008
`
`

`

`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 7 of 9
`
`US 6,421,733 B1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`100
`
`110
`
`120
`
`USER REQUESTS
`URL OBJECT
`
`BROWSER ISSUES
`HTTP REQUEST
`FOR URL OBJECT
`
`HTTP LOCAL PROXY
`CHECKS CACHE
`FOR URL OBJECT
`
`RETRIEVE URL
`OBJECT FROM
`CACHE
`
`BROWSER
`DISPLAYS
`OBJECT
`
`150
`
`FIG.7
`
`IPR2023-00332 Page 00009
`
`

`

`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 8 of 9
`
`US 6,421,733 B1
`
`HTTP LOCAL PROXY
`SENDS REQUEST TO
`HTTP REMOTE PROXY
`
`HTTP REMOTE PROXY
`CHECKS CACHE FOR
`URL OBJECT
`
`160
`
`170
`
`190
`
`RETRIEVE
`URL OBJECT
`FROM INTERNET
`
`RETRIEVE
`CACHED OBJECT
`
`OBJECT
`FOUND
`
`220
`
`RETURN
`ERROR
`
`
`
`
`
`230
`
`CACHE
`RETRIEVED
`OBJECT
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`FIG.8
`
`IPR2023-00332 Page 00010
`
`

`

`U.S. Patent
`
`Jul. 16, 2002
`
`Sheet 9 of 9
`
`US 6,421,733 B1
`
`240
`
`E
`
`TRANSCODE
`OBJECT?
`
`N
`
`TRANSCODE
`OBJECT
`
`SEND OBJECT
`TO HTTP LOCAL
`PROXY
`
`STORE OBJECT IN
`CLIENT-SIDE CACHE
`
`280
`
`
`
`SUPPORTED
`DATA TYPE
`
`N
`
`DECODE OBJECT
`
`260
`
`270
`
`290
`
`Y
`
`BROWSER DISPLAYS
`OBJECT
`
`310
`
`
`
`
`
`SUPPORTED
`DATA TYPE
`
`Y
`
`BROWSER DISPLAYS
`OBJECT
`
`320
`
`330
`
`ADD-N
`DISPLAYS OBJECT
`
`FIG.9
`
`IPR2023-00332 Page 00011
`
`

`

`US 6,421,733 B1
`
`1
`SYSTEM FOR DYNAMICALLY
`TRANSCODING DATA TRANSMITTED
`BETWEEN COMPUTERS
`
`This application claims the benefit of U.S. Provisional
`Application No. 60/041,366, filed Mar. 25, 1997.
`BACKGROUND OF THE INVENTION
`1. Field of the Invention
`The present invention relates generally to the field of data
`communications for personal computers (PCs), and in par
`ticular to a System for dynamically transcoding data trans
`mitted between two computers over a communications link.
`2. Related Art
`The Internet is quickly becoming the preferred data
`communications medium for a broad class of computer users
`ranging from private individuals to large multi-national
`corporations. Such users now routinely employ the Internet
`to acceSS information, distribute information, correspond
`electronically, and even conduct personal conferencing. An
`ever-growing number of individuals, organizations and busi
`neSSes have established a presence on the Internet through
`“web pages” on the World-Wide Web (WWW).
`For a wide variety of reasons, it may be desirable to
`manipulate data transmitted between a local client computer
`and a network Server computer. For example, in certain
`instances it may be advantageous to dynamically add,
`modify or delete content retrieved from an Internet server
`computer before that content is provided to a client com
`puter. Conversely, it may be advantageous to modify a
`content request from a client computer prior to transmitting
`the request to an Internet server computer. While Such
`dynamic manipulation of requests and responses is
`desirable, it is impractical to expect the expansive Internet
`infrastructure to quickly change to accommodate Such a new
`capability. For this reason, it is desirable to implement Such
`new capabilities in a way that does not require changes to
`either existing client computers or Internet Server comput
`CS.
`It is known to deploy a proxy server, or network proxy, as
`an intermediary between one or more client computers and
`an external network Such as the Internet. Network proxies
`are described generally in Ian S. Graham, HTML Source
`Book: A Complete Guide to HTML 3.0 403 (2d ed. 1996).
`One common application for a proxy Server is as a So-called
`“firewall,” wherein the proxy server is responsible for all
`communications with the outside world. In other words,
`local devices are not permitted to communicate directly with
`external network computers, Such as Internet Servers.
`Instead, each local device directs requests for networkresi
`dent data to the proxy server. When the proxy server receives
`Such a request, it forwards the request to the appropriate
`external computer, receives the response from the external
`computer, and then forwards the response to the local
`device. The external computer thus has no knowledge of the
`local devices. In this way, the local devices are protected
`from potential dangerS Such as unauthorized access.
`Existing proxy servers do not manipulate the data passing
`through them. In essence, proxy Servers are merely blind
`conduits for requests and responses. This limitation of
`existing proxy servers restricts these devices from being
`used to full advantage when facilitating communications
`between local devices and network devices. There is there
`fore a need for a So-called "Smart” proxy capable of exam
`ining the data passing through it, whether it be a request
`intended for an external network device or network content
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`being returned to a local device, and dynamically acting
`upon that data. Such a device can be used to transparently
`provide a wide range of Services that were heretofore
`impossible without modifying existing Internet infrastruc
`ture.
`
`SUMMARY OF THE INVENTION
`Embodiments of the present invention relate to devices,
`Systems and methods for transcoding information transmit
`ted between computers, Such as a network Server computer
`and a network client computer.
`According to one embodiment, an apparatus for use in
`transmitting data between a network Server and a network
`client over a communications link includes a parser coupled
`to a transcode Service provider. The parser is configured to
`Selectively invoke the transcode Service provider in response
`to a predetermined Selection criterion.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a Schematic diagram illustrating an environment
`in which embodiments of the present invention may be
`applied.
`FIG. 2 is a Schematic diagram illustrating a transcoder
`module according to an embodiment of the present inven
`tion.
`FIG. 3 is a Schematic diagram illustrating an embodiment
`of the present invention for a non-enabled network client.
`FIG. 4 is a Schematic diagram illustrating an example of
`a user interface for providing a non-enabled network client
`with control over transcoding functionality.
`FIG. 5 is a schematic diagram illustrating an embodiment
`of the present invention for an enabled network client.
`FIG. 6 is a Schematic diagram illustrating a network client
`with transcoding functionality integrated in a browser
`according to an embodiment of the present invention.
`FIGS. 7-9 are flow charts illustrating logic for presenting
`a requested URL object to a network client according to an
`embodiment of the present invention.
`DETAILED DESCRIPTION
`Embodiments of the present invention provide the ability
`to dynamically transcode information transmitted between,
`for example, a network Server computer and a network client
`computer. AS used herein, the term “transcode' applies to
`Virtually any manipulation of data including, but not limited
`to, adding, modifying or deleting data.
`Referring now to FIG. 1, which illustrates an environment
`in which embodiments of the present invention may be
`advantageously applied, a network Server 10 manages the
`transfer of data from the Internet 18 to a network client 12.
`Network client 12 may be any computer having Suitable data
`communications capability.
`Network client 12 communicates requests for information
`to, and receives information from, network server 10 over a
`client/server communications link 14. Client/server commu
`nications link 14 may comprise, for example, a So-called
`“slow network” using, for example, POTS (Plain Old Tele
`phone System) dial-up technology or wireless connections.
`Alternatively, client/server communications link 14 may
`comprise a so-called “fast network,” such as a LAN or WAN
`(Wide Area Network), which is capable of operating at much
`higher speeds than are possible with Slow networkS. Com
`binations of these acceSS methods are also possible. For
`example, network client 12 may use a POTS or wireless
`
`IPR2023-00332 Page 00012
`
`

`

`US 6,421,733 B1
`
`15
`
`25
`
`3
`dial-up connection to a modem bank maintained by an ISP
`(Internet Service Provider), which is in turn connected to
`network server 10 over a LAN. Network server 10 commu
`nicates with computers resident on Internet 18 through
`Server/network communications link 16, which may com
`prise any Suitable communications medium known in the
`art.
`According to a first general embodiment of the present
`invention, illustrated Schematically in FIG. 2, a transcoder
`20 includes a parser 22 and a plurality of transcode Service
`providerS 24. Parser 22 is configured to act upon data
`received by transcoder 20, Such as a request for a network
`object generated by a client device or a reply to Such a
`request provided by a content Server device. In this particu
`lar embodiment, parser 22 is responsible for Selectively
`invoking one or more of transcode Service providers 24
`based upon a predetermined Selection criterion.
`Transcoder 20 may be implemented, for example, as a
`Software module installed in a network proxy, in a client
`device, in a network Server device, or in a content Server
`device. In one particular implementation, illustrated in FIG.
`3, transcoder 20 is installed in a remote transcoding Server
`34 arranged between network client 12 and Internet 18.
`Transcoding Server 34 may comprise, or be a part of, a
`network Server, a Stand-alone computer in communication
`with a network Server, or a distributed System of computers.
`Remote transcoding Server 34 may be coupled, for example,
`to an ISP'S network, a corporate network, or anywhere on
`Internet 18, and may provide multiple users (i.e., clients)
`with a means to obtain content on Internet 18.
`In the particular embodiment illustrated in FIG. 3,
`transcoding server 34 includes an HTTP (HyperText Trans
`fer Protocol) remote proxy 36, capable of accessing Internet
`18 over server/network communications link 16. HTTP
`remote proxy 36 differs from known network proxies, which
`35
`generally are little more than a conduit for requests to, and
`replies from, external Internet resources, in that it is capable
`not only of examining Such requests and replies, but also of
`acting upon commands in the requests by, for example,
`determining whether or not to transcode content. Moreover,
`using transcoder 20, HTTP remote proxy 36 is capable of
`changing content received from Internet 18 prior to return
`ing it to a requesting network client 12, as is explained
`further below.
`Looking more closely at the embodiment in FIG. 3,
`transcoder 20 is coupled to HTTP remote proxy 36. Parser
`22 manages the transcoding of data to be transmitted from
`transcoding server 34 to network client 12. To this end,
`parser 22 controls transcode Service providers 24 to Selec
`tively transcode content based on a predetermined Selection
`criterion. For example, one or more transcode Service pro
`viders 24 may provide the capability to compress and/or
`Scale different types of data content, Such as image, Video,
`or HTML (HyperText Markup Language). Such uses are
`described further in co-pending U.S. patent applications Ser.
`No. 08/772,164 entitled “System for Enhancing Data Access
`Over a Communications Link,' filed on Dec. 20, 1996, and
`Ser. No. 08/799,654 entitled “Method and Apparatus for
`Scaling Image Data,” filed on Feb. 11, 1997, both of which
`are assigned to Intel Corporation. For purposes of illustrat
`ing certain features of the present invention, a number of
`embodiments are described below in terms of content
`Scaling/compression; however, as is explained, transcode
`Service providers 24 may provide a wide variety of transcod
`ing functions.
`As shown in FIG. 3, transcoding server 34 may also
`include a Server-side cache memory 30 managed by a
`
`4
`server-side cache interface 28. Server-side cache memory 30
`may be used to Store both original and transcoded versions
`of content for later transmission to network client 12 without
`the need to re-retrieve the content from Internet 18 or to
`re-transcode the content.
`Transcoding server 34 is coupled to network client 12 by
`client/server communications link 14. Network client 12
`includes a browser 32, such as the Netscape Navigator v.3.0
`browser (although the invention is not limited in this
`respect), which manages the presentation of data to a user.
`In this embodiment, network client 12 is “non-enabled.”
`meaning no specialized transcoding Software is preloaded on
`network client 12.
`Parser 22 may comprise a relatively simple, uniform
`interface to HTTP remote proxy 36, and may provide an API
`(Application Programming Interface) for transcoding data
`received by HTTP remote proxy 36. Parser 22 manages one
`or more transcode Service providers 24 that are accessed
`through a common SPI (Service Provider Interface). In this
`particular embodiment, parser 22 is designed in compliance
`with the Windows Open Systems Architecture (WOSA), and
`may be implemented as a Win32 DLL (Dynamic Link
`Library). The WOSA architecture, described in Readings On
`Microsoft Windows and WOSA (Microsoft Corp. 1995),
`enables additional transcode Service providers 24 to be
`dynamically added to the System to provide new features
`and/or better transcoding algorithms, while at the same time
`not requiring changing or retesting other Software compo
`nents in the System. This feature is especially beneficial
`where transcoding server 34 also interacts with “enabled”
`network clients equipped with Specialized transcoding Soft
`ware. It should be noted that some of the features of parser
`22 described below may be inapplicable to the non-enabled
`client embodiment of FIG. 3; however, transcoding server
`34 may advantageously be configured flexibly enough to
`process requests from both non-enabled and enabled net
`work clients.
`Like parser 22, Server-side cache interface 28 may be
`modeled after a standard Get/Set interface. Server-side
`cache memory 30 essentially "owns” all cached objects, in
`that it manages the properties and Storage of the objects and
`may invalidate any non-locked object at any time; however,
`the actual format of any given cached object is known only
`by parser 22 and its associated transcode Service providers
`24. Thus, for data integrity and transcoding efficiency
`purposes, all access to Server-Side cache memory 30 in this
`embodiment is through parser 22.
`Server-side cache interface 28 may include the following
`calls:
`CreateEntry(URL, & Entry, . . . );
`GetEntry(URL, & Entry);
`CreateStream(Entry, &StreamEntry, . . . );
`GetStream(Entry, &Stream Entry, ...);
`CloseEntry(Entry);
`CloseStream Entry(Stream Entry);
`GetProperties(Entry, &Properties, . . .
`SetProperties(Entry, & Properties, . . . );
`Read(Strearn Entry, & OutStream, . . . );
`Write(Stream Entry, &InStream, . . . ).
`Unlike most cache memories, Server-Side cache interface 28
`and Server-side cache memory 30 enable maintenance of
`multiple representations of a given cached object, with
`descriptive information about each representation included
`in server-side cache memory 30. In addition, server-side
`cache interface 28 and server-side cache memory 30 serve as
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`IPR2023-00332 Page 00013
`
`

`

`US 6,421,733 B1
`
`15
`
`S
`a Synchronization point for multi-threaded accesses to
`cached objects. It should be noted that the illustrated
`embodiment does not require any particular configuration
`for Server-side cache interface 28 and/or Server-side cache
`memory 30. Indeed, functionality attributed to these com
`ponents in the various embodiments described herein may
`be readily implemented in other System components.
`The CreateEntry () call creates and returns a cache entry
`for a specified hypertext object. This call also creates an
`entry Stream for an original version of the hypertext object.
`Similarly, the GetEntry () call obtains a cache entry for a
`hypertext object already existing in cache memory 30. Both
`the CreateEntry () and GetEntry () calls set locks on
`associated cached objects until a Close Entry ( ) call is
`invoked. Once a lock is set, the cached object will not be
`replaced or invalidated by cache interface 28, permitting one
`or more transcode Service providers 24 to safely performany
`required cache operations, Such as object retrieval and/or
`Storage.
`After a cache entry is created or opened by a CreateEntry
`() or GetEntry () call, the CreateStream () or GetStream ()
`calls may respectively create or open an extra Stream entry
`for the cached object. Each extra Stream entry is associated
`with a different transcoded version of the hypertext object,
`which may be retrieved or appended to by one of transcode
`Service providerS 24. Stream-based processing of cached
`objects makes it possible for transcoding Server 34 to begin
`transmitting a transcoded version of a hypertext object to a
`requesting network client 12 even while transcode Service
`provider 24 is appending additional transcoded content to
`that same version. Advantages of this stream-based proceSS
`ing include reducing user latency through incremental paint
`ing of objects and avoiding unnecessary idle time on client/
`Server communications link 14, thereby providing users with
`a more responsive “feel.”
`The GetProperties () and SetProperties () calls retrieve
`and Store information about cached objects, including infor
`mation maintained by transcode Service provider 24 used to
`determine transcoding properties and transcoding Status of a
`cached object. Transcode Service provider 24 may use Such
`information, for example, to determine current compression
`progreSS for Scaled data access and Staged refinements.
`The Read () call reads data from a specified cached object
`data Stream. For example, transcode Service provider 24 may
`invoke this call and tunnel stream data through HTTP
`45
`remote proxy 36 directly to network client 12. The Write ()
`call caches data from a new HTTP data stream. This call will
`append an incoming data Stream received from, for example,
`a Web server or transcode service provider 24, to an opened
`cache Stream which may be concurrently read using the
`Read () call.
`In the present embodiment, parser 22 includes the fol
`lowing calls:
`Get Object (URL, In Params,
`&OutStream, . . . );
`GetScaled Object(URL, InParams, & Out Params,
`&OutStream, Stage,
`Put Object (URL, In ParamStruct, & InStream,
`&OutParams, & OutStream, . . . ).
`AS detailed below, parser 22 uses these calls to manage the
`provision of requested content to network client 12.
`The GetObject () call is used to service non-enabled
`client requests, and returns a non-transcoded (i.e., original)
`version of a specified hypertext object. In this embodiment,
`transcoding server 34 assumes that each HTTP request has
`a unique thread that may be blocked until the request is
`satisfied. Accordingly, the GetObject () call will block until
`
`& Out Params,
`
`6
`it either returns the requested data Stream or indicates failure
`with a cause (e.g., object does not exist). This ability to
`return a So-called Standard hypertext object is advantageous
`for compatibility reasons, enabling embodiments of the
`present invention to be used with existing browsers that do
`not include Support for certain transcoding functionality
`(e.g., advanced data compression), and enabling users to
`Selectively retrieve non-transcoded versions.
`The GetScaledObject () call is similar to GetObject (),
`and is also used to request an object from Server-side cache
`memory 30; however, it adds Support for requesting a
`particular version of that object, Such as a high-quality
`rendition. Unlike traditional caching proxies, transcode Ser
`vice providers 24 can use server-side cache memory 30 to
`Store Several different versions of an object to Support clients
`with different communications and/or presentation capabili
`ties. Thus, an additional "Stage’ parameter may be used to
`indicate which version of the cached object is to be returned
`to network client 12. Where transcode service provider 24 is
`configured to Scale network content, it may use this param
`eter to request a version of a cached object having, for
`example, a default Scaled quality, a refinement to a better
`quality version, or the original non-Scaled version.
`In this embodiment, when network client 12 requests a
`hypertext object, HTTP remote proxy 36 uses either the
`GetObject () or GetScaledObject () call (depending on if
`network client 12 is capable of receiving Scaled/transcoded
`datatypes) to retrieve the hypertext object from parser 22. If
`the hypertext object is not found, parser 22 uses the Crea
`teEntry () call to create an entry (in effect, a placeholder) in
`server-side cache memory 30 for the new object. The new
`entry is returned to HTTP remote proxy 36, which requests
`the hypertext object from Internet 18. As a data stream for
`the hypertext object is returned, HTTP remote proxy 36 calls
`parser 22 using the PutObject () call, passing into this call
`the new entry and the handle to the data Stream to be placed
`into the entry. Parser 22 Selects an appropriate transcode
`Service provider 24 based, for example, on the content type
`of the data Stream. In this context, the term content type
`encompasses a datatype, an HTTP MIME (Multipurpose
`Internet Mail Extensions) type, a content format, and so on.
`The Selected transcode Service provider 24 uses a Separate
`thread to read the incoming data Stream, transcode it, and
`place it within the entry of server-side cache memory 30.
`The current thread immediately returns to HTTP remote
`proxy 36, which once again calls GetScaledObject () (or
`GetObject ()). This case will always result in a cache hit.
`This thread then works simultaneously with the separate
`thread in the Put Object () to tunnel data (either original or
`transcoded) from transcoding server 34 to network client 12.
`Multiple-thread processing improves the efficiency of the
`present embodiment by not waiting for a hypertext object to
`be received in its entirety by HTTP remote proxy 36, or
`added in its entirety to server-side cache memory 30, before
`beginning to Send the object to network client 12. Another
`benefit of multiple-thread processing is that parser 22 may
`efficiently proceSS requests for the same hypertext object
`from multiple network clients 12. The hypertext object need
`only be retrieved from Internet 18 once, and appropriate
`versions may be transmitted to Such multiple network clients
`12 concurrently. It should be noted, however, that embodi
`ments of the present invention may be implemented without
`multiple-thread processing.
`AS noted above, parser 22 may selectively invoke one of
`transcode Service providerS 24 based upon Satisfaction of a
`predetermined Selection criterion. Such Selection criterion
`may comprise, for example, information contained in a
`
`25
`
`35
`
`40
`
`50
`
`55
`
`60
`
`65
`
`IPR2023-00332 Page 00014
`
`

`

`US 6,421,733 B1
`
`15
`
`25
`
`35
`
`40
`
`7
`header portion of a data packet received by transcoding
`server 34, such as a MIME type, a URL (Uniform Resource
`Locator), a last modified time indicator and So on.
`Alternatively, the predetermined Selection criterion may
`comprise information contained in a data portion of Such a
`data packet, Such as particular content, key words, Structures
`(for example, heading levels), and So on. Still further, the
`predetermined Selection criterion may comprise a condition
`of the device on which transcoding server 34 is installed (for
`example, a current processing load), a condition of a device
`to which transcoding Server 34 is coupled, or a condition of
`a communications link. Transcoding Server 34 may provide
`the ability to dynamically update Such predetermined Selec
`tion criteria.
`The following discussion provides still more examples of
`the types of information which may be used to dictate which
`of transcode service providers 24 are invoked. It should be
`noted, however, that these examples are provided by way of
`illustration only, and are not intended to limit in any way the
`Scope of the invention claimed herein. The predetermined
`Selection criterion may comprise: (1) network client 12, Such
`as a display dimension, resolution, number of colors, pro
`ceSSor type, memory/disk configuration, modem or network
`interface type, installed add-in boards (for example, hard
`ware compression/decompression), Software configuration
`(for example, availability of pre-installed Software decom
`pression modules), physical location/proximity (for
`example, as determined by a telephone area code), and user
`identity; (2) characteristics of transcoding Server 34 or Some
`other network Server, including System load and identifica
`tion information (for example, the owner of the server); (3)
`content characteristics, Such as its data type, type of
`encoding/compression, size, and dimension; (4) network
`characteristics, including best-case, worst-case and average
`latency, bandwidth and/or error rates (for example, for
`wireless communications) between network client 12 and a
`proxy, and/or between a proxy and a server (this may be
`predetermined for gua