`
`US6421733
`
`Title:
`
`System For Dynamically Transcoding Data Transmitted Between Computers
`
`Abstract:
`
`A system for dynamically transcoding data transmitted between computers is implemented in an
`apparatus for use in transmitting data between a network server (10) and a network client (12)
`over a communications link (14).. The apparatus includes a parser (22) coupled to a transcode
`service provider (24).. The parser (22) is configured to selectively invoke the transcode service
`provider (24) in response to a predetermined selection criterion.
`
`Specification:
`
`Background of the Invention
`
`This application claims the benefit of U.S. Provisional Application No. 60/041,366, filed
`MarchMar. 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 particular to a system for dynamically transcoding data transmitted
`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 businesses 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
`
`Equil EX2008
`Akamai Techs. v. Equil IP Holdings
`IPR2023-00330
`
`
`
`
`
`computer before that content is provided to a client computer. 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 computers.
`
`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 network-
`residentnetworkresident 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 therefore a need for a so-
`called "smart" proxy capable of examining the data passing through it, whether it be a request
`intended for an external network device or network content 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
`infrastructure.
`
`SUMMARY OF THE INVENTION
`
`Embodiments of the present invention relate to devices, systems and methods for
`transcoding information transmitted 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 Drawines
`
`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 invention.
`
`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
`communications link 14 may comprise, for example, a so-called "slow network" using, for
`example, POTS (Plain Old Telephone 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. Combinations of these access methods are also
`possible. For example, network client 12 may use a POTS or wireless 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 communicates with computers resident on
`Internet 18 through server/network communications link 16, which may comprise 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 particular 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 Transfer 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 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 returning 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
`selectively transcode content based on a predetermined selection criterion. For example, one or
`more transcode service providers 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 SerialSer. No. 08/772,164
`entitled "System for Enhancing Data Access Over a Communications Link," filed on
`DecemberDec. 20, 1996, and SerialSer. No. 08/799,654 entitled "Method and Apparatus for
`Scaling Image Data," filed on FebruaryFeb. 11, 1997, both of which are assigned to Intel
`Corporation. For purposes of illustrating 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 transcoding functions.
`
`As shown in FIG. 3, transcoding server 34 may also include a server-side cache memory
`30 managed by a 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 components in the system. This feature is especially beneficial where
`transcoding server 34 also interacts with "enabled" network clients equipped with specialized
`transcoding software. 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 network 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, &StreamEntry, . . . ); CloseEntry(Entry); CloseStreamEntry(StreamEntry);
`GetProperties(Entry, &Properties, . . . ); SetProperties(Entry, &Properties, . . . );
`Read(StrearnEntry, &OutStream, . . . ); Write(StreamEntry, &InStream, . . . ).
`
`CreateEntry(URL, &Entry, ...);
`
`GetEntry(URL, &Entry);
`
`CreateStream(Entry, &StreamEntry, ...);
`
`GetStream(Entry, &StreamEntry, ...);
`
`CloseEntry(Entry);
`
`CloseStreamEntry(StreamEntry);
`
`GetProperties(Entry, &Properties, ...);
`
`SetProperties(Entry, &Properties, ...);
`
`Read(StreamEntry, &OutStream, ...);
`
`Write(StreamEntry, &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 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
`components in the various embodiments described herein may be readily implemented in other
`system components.
`
`The CreateEntryOCreateEntry ( ) 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 CreateEntryOCreateEntry ( ) and GetEntry() ( ) calls set
`locks on associated cached objects until a CloseEntry() ( ) 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 perform any required cache operations, such as object
`retrieval and/or storage.
`
`After a cache entry is created or opened by a CreateEntryOCreateEntry ( ) or
`GetEntryOGetEntry ( ) 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 processing
`include reducing user latency through incremental painting 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 information 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 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 following calls: GetObject(URL,
`InParams, &OutParams, &OutStream, ...);
`
`
`
`
`
`
`
`. . . ); GetScaledObject(URL, InParams, &OutParams, &OutStream, Stage,
`
`-.);
`
`PutObjectfURL PutObject(URL, InParamStruct, &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 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 service 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
`capabilities. 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 parameter 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 CreateEntryOCreateEntry
`( ) 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 GetScaledObjectOGetScaledObject ( ) (or GetObject()). ( )). This case will always
`result in a cache hit. This thread then works simultaneously with the separate thread in the
`
`
`
`
`
`
`
`PutObject() ( ) 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 embodiments 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 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 selection 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,
`processor type, memory/disk configuration, modem or network interface type, installed add-in
`boards (for example, hardware compression/decompression), software configuration (for
`example, availability of pre-installed software decompression 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
`identification 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 guaranteed bandwidth links like ATM
`(Asynchronous Transfer Mode), or dynamically measured/predicted for so-called "best effort"
`links like many IP (Internet Protocol) links); (5) proxy characteristics, including system load,
`available storage, physical location/proximity, and identity (owner); (6) user preferences,
`including preferred content quality/speed tradeoff, language, content rating, exclusion list,
`inclusion list, data type-specific preferences (for example, "never download" images),
`include/exclude advertising, amount of advertising desired, offensive language removal, whether
`the user's defined or learned preferences may be disclosed (and to whom), custom rules or
`programs for filtering/transcoding/processing data, and shared preferences with either another
`
`
`
`
`
`
`
`user or a group of users (any of the foregoing user preferences may be explicitly defined or
`system predicated, such as based on usage statistics compiled over time); (7) group preferences,
`including results from collaborative rating systems, whether manual (for example, a prior user
`manually assigned a rating to a Web page after viewing it) or automatic (for example, given a
`large number of users who accessed a link on a given page, the probability of any given user
`subsequently following that link); (8) content provider preferences, including the degree of
`alteration desired for its content, the prioritization for download and display of different content
`types, cache restriction or prioritization parameters such as update frequency or replacement
`preferences, the types of users to target, rules or programs to run for customizing content (for
`example, news or advertising, custom language translation software) based on user or client
`characteristics, desire for receiving certain types of user or group data collected (for example,
`demographics or access patterns), and type of payment/reward offered in exchange for such
`information; and (9) other preferences, including software vendor rules or programs for
`dynamically checking content created or distributed using unauthorized software and companies'
`desire to enforce correct usage of certain types of content (for example, trademarks and logos).
`
`Applying the above-listed selection criteria, or combinations thereof, embodiments of the
`present invention may be used to provide a virtually limitless range of dynamic transcoding
`services. For example, client and/or proxy physical proximity, in combination with demographic
`data, may be used for extremely targeted advertising. Such advertising may be added to any
`content passing through a proxy, for example, or some other mechanism. This can in turn be
`tailored even further based upon the user's willingness to tolerate advertising or share
`demographic information, as well as the advertiser's ability/willingness to subsidize or otherwise
`reward the user for participation.
`
`Embodiments of the present invention may be advantageously used to reduce the amount
`of data that is transmitted to network client 12, thereby promoting faster downloading and
`rendering of content. Suitable transcoding techniques include lossy compression and transcoding
`to a more efficient (and perhaps not widely supported) format specifically for the transmission.
`Similarly, HTTP remote proxy 36 may be configured to "predigest" Web sites or groups of sites
`to produce extremely condensed overviews of large amounts of content (for example, a tree
`structure, pages with only first-level or first- and second-level headings, thumbnails of pages, or
`only parts of a page or site that have changed since the user's last visit). Such applications may
`be especially advantageous for poorly-connected or computationally limited devices such as
`PDAs (Personal Digital Assistant), since this predigestion can be performed on a well-connected
`proxy server with an abundance of computational power, and the concise result can be easily
`downloaded and rendered on the more limited device.
`
`Embodiments of the present invention may alternatively be used for dynamic translation
`of data, such as Web pages, to a user's native language (determined by user preference or
`automatically by the physical location of network client 12 or transcoding server 34). Such a
`capability greatly simplifies the task of making content truly global, as well as reduces storage
`and maintenance required at the content provider (that is, only one copy of the content need be
`maintained, rather than different copies for each of a plurality of different languages).
`
`Embodiments of the present invention may be used to block certain types of content or to
`automatically censor offensive language (similar to a "beep" used for television broadcasts).
`
`
`
`
`
`
`
`Only the particular offensive parts of the content (for example, obscene words) may be removed,
`or entire Web sites may be blocked. Similarly, transcoding server 34 may be configured to scan
`content for certain words or phrases to ensure that trademarks or logos are used correctly (for
`example, as a source identifier rather than a generic product designation). This feature may be
`offered as a service to companies or organizations, who would supply a list of words or phrases
`to flag. A similar capability could be used to automatically insert links into the content upon
`detection of certain words or phrases. For example, Intel Corporation might want to
`automatically add a link to its corporate Website whenever the name "Intel" is used in a Web
`page. Using an embodiment of the present invention, such links can be dynamically added to the
`content before it is displayed to a user. In a similar vein, an embodiment of the present invention
`may be used to scan for content that was created or distributed using unlicensed software. This
`feature may be implemented using special keys (binary bit patterns) embedded in the content or
`headers put in by the content creation or distribution software. The scanning logic and logic for
`taking a predetermined responsive action, such as denying service or posting a warning, may
`optionally be supplied by the vendor of the software in question or configured into transcoding
`server 34.
`
`Embodiments of the present invention may also be used to scan content for computer
`viruses prior to sending such content to network client 12. For example, an existing virus
`scanning routine may be installed on transcoding server 34, possibly as a plug-in module.
`Transcoding server 34 may then be configured to invoke the virus scanning routine to ensure any
`content transmitted to network client 12 is free of viruses. A significant advantage provided by
`such an embodiment is that virus scanning software need only be maintained on transcoding
`server 34, rather than on a plurality of network clients 12. In this way, the benefit of upgrades to
`the virus checking software may be efficiently and timely provided to large numbers of users,
`thus avoiding the problem of any particular user relying on outdated virus scanning software.
`
`Embodiments of the present invention may also be used to produce custom content on
`demand in accordance with user-specific preferences and/or associations with collaborative
`rating systems. In a variation on such an embodiment, transcoding server 34 can collect
`preferences and append them as part of a client request transmitted to a content provider so that
`the dynamic content generation can be done at the content server. Likewise, a proxy provider
`(for example, an Internet Service Provider (ISP)), can collect and make available to content
`providers information such as user preferences and data access statistics, as well as content
`provider specific statistics (for example, how many users from a given region or a given profile
`accessed a particular Web site, and at what time, in the past month). Such information may be
`used for applications such as targeted advertising.
`
`Embodiments of the present invention may further be used to a