UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`WHATSAPP INC. and FACEBOOK, INC.
`
`Petitioner
`
`v.
`
`TRIPLAY, INC.
`
`Patent Owner
`
`____________
`
`IPR2015‐00740
`
`Patent 8,332,475 B2
`
`
`
`PATENT OWNER’S RESPONSE
`
`
`
`
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`WHATSAPP INC. and FACEBOOK, INC.
`
`Petitioner
`
`v.
`
`TRIPLAY, INC.
`
`Patent Owner
`
`____________
`
`IPR2015‐00740
`
`Patent 8,332,475 B2
`
`
`
`PATENT OWNER’S RESPONSE
`
`
`
`
`
`TABLE OF CONTENTS
`
`I
`
`II.
`
`INTRODUCTION ........................................................................................... 1
`
`SCOPE OF THE PRIOR ART ........................................................................ 2
`
`A.
`
`Coulombe .............................................................................................. 2
`
`1.
`
`2.
`
`3.
`
`4.
`
`Overview ..................................................................................... 2
`
`The Coulombe messaging system embodiment ......................... 4
`
`Coulombe’s teachings regarding web browsing ......................... 8
`
`Coulombe Teachings Regarding XHTML ............................... 10
`
`B.
`
`Tittel .................................................................................................... 14
`
`C. Druyan ................................................................................................. 18
`
`1.
`
`2.
`
`3.
`
`The XSLT prior art and the XML input file ............................. 18
`
`The Druyan invention: segmenting the master XSLT
`style sheet file 230 to create derivative style sheets ................. 21
`
`The significance of the XML source document 210 to
`understanding the scope of Druyan XSLT style
`disclosure and the differences between XSLT style
`sheets and CSS style sheets ....................................................... 23
`
`III. CLAIM CONSTRUCTION .......................................................................... 25
`
`A.
`
`B.
`
`“select” ................................................................................................ 25
`
`“predefined layout” ............................................................................. 29
`
`IV. LEGAL PRINCIPLES ................................................................................... 31
`
`V.
`
`COULOMBE DOES NOT RENDER OBVIOUS CLAIM 1 ....................... 33
`
`VI. COULOMBE IN VIEW OF DRUYAN AND TITEL DOES NOT
`RENDER OBVIOUS CLAIM 6.................................................................... 35
`
`i
`
`
`
`A.
`
`The Proposed Combination Of Coulombe, Druyan, And
`Tittel Fails To Disclose All The Elements Of Claim 6 ....................... 35
`
`1.
`
`2.
`
`The proposed combination of Coulombe, Druyan, and
`Tittel fails to disclose “a layout based on a template.” ............. 35
`
`The proposed combination of Coulombe, Druyan, and
`Tittel fails to disclose “selection and conversion done in
`accordance with at least one predefined layout.” ..................... 37
`
`B. A Person Of Ordinary Skill In The Art Would Have No
`Reason Or Motivation To Combine The References .......................... 39
`
`1.
`
`2.
`
`Overview ................................................................................... 39
`
`A person of ordinary skill in the art would not be
`motivated to combine Coulombe with Druyan ......................... 43
`
`a.
`
`b.
`
`A POSITA would find no benefit to combining
`Coulombe with Druyan, nor does the Petitioner
`offer any such benefit ..................................................... 43
`
`A POSITA would not combine Coulombe with
`Druyan because doing so would hinder
`Coulombe’s basic principles of operation ...................... 46
`
`3.
`
`A person of ordinary skill in the art would not be
`motivated to combine Coulombe with Tittel. ........................... 54
`
`VII. THE FLAWS IN PETITIONER’S INVALIDITY ANSLYSIS AS
`TO CLAIMS 1 AND 6 LIKEWISE DOOM ITS INVALIDITY
`ARGUMENTS AS TO CLAIMS 9, 12, 17-18, 23, 28, 37 AND 39-
`42 ................................................................................................................... 55
`
`VIII. CONCLUSION .............................................................................................. 57
`
`
`
`
`
`ii
`
`
`
`TABLE OF AUTHORITIES
`
`Page(s)
`
`Cases
`CCS Fitness, Inc. v. Brunswick Corp.,
`288 F.3d 1359 (Fed. Cir 2002) ..................................................................... 26
`
`Digital-Vending Servs. Intern., LLC v. Univ. of Phoenix, Inc.,
`672 F.3d 1270 (Fed. Cir. 2012) .................................................................... 29
`
`Graham v. John Deere Co.,
`383 U.S. 1 (1966) .......................................................................................... 31
`
`Innogenetics, N.V. v. Abbott Labs.,
`512 F.3d 1363 (Fed. Cir. 2008) .................................................................... 31
`
`In re Kahn,
`441 F.3d 977 (Fed. Cir. 2006) ................................................................ 31, 41
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ................................................................................ 31, 32
`
`In re Omeprazole Patent Litigation,
`536 F.3d 1361(Fed. Cir. 2008) ..................................................................... 31
`
`Plas-Pak Indus., Inc. v. Sulzer Mixpac AG,
`600 Fed. Appx. 755 (Fed. Cir. Jan. 27, 2015) ........................................ 32, 33
`
`Velander v. Garner,
`348 F.3d 1359 (Fed. Cir. 2003) .................................................................... 31
`
`Other Authorities
`
`The American Heritage Dictionary (2000) .................................................. 26, 27
`
`The Merriam-Webster Dictionary (2004) .................................................... 26, 28
`
`The Microsoft Computer Dictionary, Fifth Edition (2002) ............................... 26
`
`
`
`iii
`
`
`
`I.
`
`INTRODUCTION
`
`Claims 1, 12, 23, 37, 39 and 41 are not obvious over Coulombe because
`
`each of the claims requires that the media block be “configured to select, before
`
`transmitting, at least one message format and message layout . . . .” Petitioner
`
`contends that Coulombe meets this limitation because “determine” and “select”
`
`mean the same thing. They do not. Coulombe’s flexible delivery system does
`
`not have a fixed set of layout choices, and, thus, it necessarily must
`
`“determine,” rather than “select,” a layout.
`
`Claims 6, 9, 17, 18, 28, 40, and 42 are not obviousness over Coulombe in
`
`view of Druyan and Tittel. First, none of the references disclose “a layout based
`
`on a template” or “selection and conversion in accordance with at least one
`
`predefined layout.” As to the latter, Petitioner does not contend that Tittel
`
`discloses a “predefined layout” and admits that the purported predefined layouts
`
`in Druyan (the derivative style sheets) are created after the content has been
`
`requested. In addition, with the benefit of testimony from Petitioner’s
`
`messaging system expert, Dr. Surati, it is apparent that the three asserted prior
`
`art references are fundamentally different from each other, and Petitioner has
`
`not, and cannot, demonstrate a reason why a person of ordinary skill in the art
`
`would combine them. Moreover, Dr. Surati has shown that any combination of
`
`the three would not yield predictable results and would hinder the basic
`
`operation of Coulombe’s flexible messaging system.
`
`For the foregoing reasons, Petitioner has failed to prove that any of the
`
`- 1 -
`
`
`
`challenged claims of the ‘475 patent are obvious.
`
`II.
`
`SCOPE OF THE PRIOR ART
`
`The instituted invalidity grounds rely upon three prior art references:
`
`Coulombe, Druyan, and Tittel. As discussed below, the three references are
`
`fundamentally different in almost every respect.
`
`A. Coulombe
`
`1. Overview
`
`Coulombe “relates to the interoperability between terminal devices using
`
`session initiation protocol (SIP) messages and, more particularly, to multimedia
`
`content adaption.” (Ex. 1003, Coulombe, ¶ 1). It describes a “framework” for
`
`“the adaption of messages between sender and recipient.” (Coulombe, ¶53).
`
`The “goal” of Coulombe is to:
`
`facilitate message adaptation in such a way that incoming messages
`may be made suitable for the recipient’s terminal, user’s preferences
`and network characteristics (but not limited to those characteristics)
`even though the characteristics of the incoming messages may require
`capabilities quite different from that of the intended recipient terminal.
`
`Coulombe’s proposed framework does not place any meaningful
`
`
`
`restrictions on the “characteristics of the incoming messages” that are to be
`
`“made suitable for” the capabilities of the recipient’s terminal or the recipient’s
`
`user preferences. (Ex. 2002, Declaration of Dr. Rajeev Surati (“Dr. Surati
`
`Decl.”), ¶ 22)). The “characteristics of the incoming messages” are not known
`
`in advance and can include a variety of characteristics as described in
`
`Coulombe. (Id.). For example, the “characteristics of the incoming messages”
`
`- 2 -
`
`
`
`can include:
`
`(i) different types of media (e.g. Coulombe, ¶ 7 (media can include images
`
`and audio in addition to text));
`
`(ii) media content encoded in different media formats (e.g. Coulombe, ¶¶ 87
`
`& 88 (formats for images include PNG, GIF and JPEG));
`
`(iii) media content with different media characteristics (e.g. Coulombe, ¶ 7
`
`(images have different resolutions and audio has different sampling
`
`rates)); and
`
`(iv) a SIP message body in which the message content (text, media elements,
`
`etc.) can be expressed using different message formats (i.e., message
`
`formats for the body of the message other than SIP) (e.g. Coulombe, ¶
`
`86 (received message body could be expressed in XHTML). (Id.)
`
`As Patent Owner’s expert Dr. Surati testified, a person of ordinary skill in
`
`the art (POSITA) would understand that the SIP protocol is used to initiate,
`
`modify and terminate network sessions. (Dr. Surati Decl., ¶ 23). While
`
`applications based on SIP in the early 2000s were largely directed to interactive
`
`multimedia sessions, such as Internet phone calls or multimedia conferences,
`
`SIP or extensions to SIP could also be used for instant messaging. (Id.)
`
`Despite Coulombe’s statement that “the invention applies to a wide
`
`variety of SIP message methods” (Coulombe, ¶ 120), a POSITA would still
`
`understand Coulombe as disclosing a system intended to apply primarily to
`
`instant messaging. (Dr. Surati Decl., ¶ 24.) Indeed, the only protocol
`
`- 3 -
`
`
`
`extensions drafted for the use of SIP in the messaging context (which defines a
`
`MESSAGE method) was the SIMPLE protocol for instant messaging, which
`
`Coulombe explicitly references at ¶ 69. (Id.).
`
`2.
`
`The Coulombe messaging system embodiment.
`
`The embodiment described Coulombe’s messaging system framework
`
`“comprises three elements in combination: SIP proxy/registrar 12, Capability
`
`Negotiation Manager 16 and Message Adaptation Engine 20.” (Coulombe, ¶
`
`54). These three elements are depicted in Fig. 3 of Coulombe, a copy of which
`
`is reproduced below.
`
`
`
`The SIP proxy/registrar 12 provides the operation required by a SIP
`
`proxy registrar as specified in the SIP protocol. The SIP proxy/registrar 12 also
`
`performs the functions of sending and receiving messages as well as
`
`- 4 -
`
`
`
`communicating with the Capability Negotiation Manager 16 and the Message
`
`Adaption Engine 20. (Coulombe, ¶¶ 57, 58 & Fig. 3).
`
`The Capability Negotiation Manager 16 “is responsible for resolving
`
`terminal capability information.” (Coulombe, ¶ 59). The term “resolve” is
`
`defined in Coulombe to mean “to obtain or determine terminal capabilities or
`
`user preferences, as explained below, by various possible mechanisms.”
`
`(Coulombe, ¶ 57). As Coulombe declaration supports and Dr. Surati’s
`
`testimony confirms, Coulombe teaches a very flexible system that permits the
`
`users to assert a high degree of control regarding the capabilities of their devices
`
`and their particular preferences for how content sent to them should be adapted
`
`(e.g., a device might support images in several formats but the user’s preference
`
`may explicitly require images be converted to just one of those formats). (Dr.
`
`Surati Decl., ¶ 31.)
`
`At the request of the SIP Proxy/Registrar 12, the Capability Negotiation
`
`Manager 16 resolves the terminal capabilities and user preferences using
`
`different inputs and methods.” (Coulombe, ¶ 75). Coulombe teaches various
`
`methods for providing terminal capabilities and user preferences but notes that
`
`“the system is not limited to them.” (Id.). The terminal can provide its
`
`capabilities and user’s preferences “explicitly in the body of the registration
`
`message (e.g. REGISTER or SUBSCRIBE methods)” or in header fields such
`
`as “User-Agent” (describing the terminal type and software version) or “Accept
`
`header” (listing formats supported such as image formats). (Id., ¶ 76). The
`
`- 5 -
`
`
`
`User-Agent header field can be used as a key to a Terminal Capability Database
`
`containing capability information for that terminal type and software version.
`
`(Id., ¶ 77). In addition, the terminal can send “a list of URLs from which the
`
`process retrieves terminal capability profile documents via the manager 16.”
`
`(Id., ¶ 78).
`
`Coulombe also teaches that “[c]ombining the capabilities or user
`
`preferences obtained by the different methods [is] the most appropriate manner
`
`[for the Capability Negotiation Manager] to make a complete set of capability
`
`information.” (Coulombe, ¶ 59). The combining of capability information
`
`“may involve combining capability descriptors and giving precedence to some
`
`methods over others in the case of duplication of certain capability descriptors
`
`(e.g. Accept header and a Terminal Capability Database may contain the
`
`information about support formats, precedence would normally be given to
`
`Accept header since it is dynamic and special to the user).” (Id.).
`
`With respect to the flexibility of defining capability information, a
`
`POSITA would understand that “registration” in the context of SIP is not
`
`generally a one-time event with occasional updates. (Dr. Surati Decl., ¶ 34.) In
`
`any instant messaging application, a “registration message” is sent every time a
`
`user signs on to the system, since the “registration” message is necessary to
`
`establish the presence of the user’s device before it is available to receive an
`
`instant message. (Id.). In other words, the message registers that the users is
`
`present and online with the device that is sending the register message. (Id.).
`
`- 6 -
`
`
`
`Accordingly, as Dr. Surati testified, capability information such as user
`
`preferences could be changed any time a user logs onto the system. (Id.).
`
`Moreover, even if no capability information is stored in the system based
`
`on prior registration records, Coulombe teaches how to obtain the capabilities of
`
`the destination device even when they were not known at the time of sending a
`
`message to that destination device. (Dr. Surati Decl., ¶ 35). First, after “the
`
`proxy receives a message,” the proxy will “[r]equest[] the recipient’s terminal
`
`capabilities and preferences from the registrar (stored with the registration
`
`information).” (Id.; Coulombe, ¶ 82). If the registrar does not have any
`
`capability information, “the proxy will initiate a SIP OPTIONS request to the
`
`recipient in order to learn its capabilities or user preferences.” (Coulombe, ¶
`
`82).
`
`The Message Adaption Engine 20 “is responsible for adapting the
`
`messages. It takes as inputs the original message along with recipient’s
`
`terminal capabilities or user preferences.” (Coulombe, ¶ 86). Then, based on
`
`the inputs, Message Adaption Engine 20 “will make a determination of what
`
`sort of adaptation or adaptations are required by comparing the capabilities or
`
`user preferences of the intended destination terminal 15 with the incoming
`
`message characteristics (e.g., present resolution, format and size of images, size
`
`of the message, etc.) for each component thereof.” (Id., ¶ 118).
`
`A number of adaptations are described, including format conversion,
`
`media characteristics adaptation, presentation or layout adaptation, and message
`
`- 7 -
`
`
`
`size adaption, and details are provided regarding each of these adaptations.
`
`(Coulombe, ¶¶ 86-114).
`
`3.
`
`Coulombe’s teachings regarding web browsing.
`
`Coulombe recognizes important distinctions between web browsing and
`
`messaging. (Dr. Surati Decl., ¶ 38.) In particular, Coulombe notes that
`
`“methods to adapt Web pages to different end users have been addressed in the
`
`past” but teaches that these methods “can’t be applied directly to all
`
`applications” because the “dynamics of other applications are often very
`
`different from browsing.” (id., Coulombe, ¶ 57). In browsing, the user makes a
`
`request for content, whereas in messaging, there is no request for content and
`
`the message arrives without any warning. (Id.). For Coulombe, the different
`
`dynamics between messaging and browsing meant that the web browsing
`
`solution for determining terminal type (which would be contained in the request
`
`for content) would not work for messaging because there is no similar request in
`
`messaging in which the message recipient provides terminal type information to
`
`the sender. (Id.).
`
`Petitioner’s expert Mr. Klausner discounts the significance of the
`
`foregoing teaching from Coulombe, and, in doing so, reads the teaching too
`
`narrowly, according to Patent Owner’s expert Dr. Surati. (Dr. Surati Decl., ¶
`
`39.) In particular, Mr. Klausner opines that the web browsing teaching in
`
`Coulombe “relates to a single issue – how does the system learn about the
`
`capabilities of the destination device so it can properly adapt the message for the
`
`- 8 -
`
`
`
`device?” (id., Klausner Decl., ¶ 112). Accordingly, he argues that the teaching
`
`is irrelevant to the motivations for combining Druyan and Tittel because that
`
`web browsing concern has nothing to do with the purposes for which he cites
`
`Tittel and Druyan. (Dr. Surati Decl., ¶ 21).
`
`But the teaching of Coulombe is not limited to a “single issue” according
`
`to Dr. Surati. (Dr. Surati Decl., ¶ 40.). Indeed, the paragraph specifically states
`
`that “methods to adapt Web pages to different end users have been addressed in
`
`the past” and that the “solutions can’t be applied directly to all applications”
`
`because the “dynamics of other applications are often very different from
`
`browsing.” (id., Coulombe, ¶ 6). The methods used in browsing to obtain
`
`terminal capabilities is one example of “methods to adapt Web pages to
`
`different end users” but a person of ordinary skill in the art would not read that
`
`teaching as limited to methods relating to terminal capabilities. (Dr. Surati
`
`Decl., ¶ 40.)
`
`For example, as Dr. Surati testified, methods for applying XSLT style
`
`sheets to structured XML file (ones where the names of the tags in the XML,
`
`and the DTD that defines the grammar of the XML file describe and demarcate
`
`the data contained) of the kind discussed in Druyan are “methods to adapt Web
`
`pages to different end users.” (Dr. Surati Decl., ¶41). A POSITA would
`
`understand that the same differences between web browsing and messaging
`
`recognized by Coulombe would likewise come into play in considering the
`
`suitability of such techniques to messaging. (Id.). As Dr. Surati states, a web
`
`- 9 -
`
`
`
`designer has far more control over the structure and content of what a recipient
`
`will receive than a messaging system designer because of the same browsing
`
`versus messaging dynamic discussed in Coulombe, i.e., the content is requested
`
`rather than it arrives without notice. (Id.). This difference makes it much easier
`
`for a web developer to use structured data techniques such as XML as part of a
`
`“method[] to adapt Web pages to different end users” because the designer
`
`knows the data elements and attributes of the web page before it formulates a
`
`response. (Id.). In contrast, Dr. Surati testified that a messaging system
`
`designer of a system like Coulombe has no control over the data elements or
`
`attributes before the message arrive and thus cannot apply the same structured
`
`data techniques in adapting messages to different end users. (Id.).
`
`Thus, Dr. Surati testified that, in his opinion, Mr. Klausner was mistaken
`
`in dismissing this teaching by stating that “the solutions proposed by Coulombe,
`
`have nothing to do with the purpose for which I have cited Druyan and Tittel –
`
`the ability to include style sheet information . . . .” (Dr. Surati Decl., ¶ 42;
`
`Klausner Decl., ¶ 112).
`
`4.
`
`Coulombe teachings regarding XHTML.
`
`According to Dr. Surati, one of several reasons why a POSITA would not
`
`consider combining Coulombe with Druyan is that there is no teaching in
`
`Coulombe that the messages arrive in the form of a structured XML file that is a
`
`necessary input to the XSLT processor described in Druyan. (Dr. Surati Decl., ¶
`
`43). In order to overcome that issue, Dr. Surati observes that Mr. Klausner
`
`- 10 -
`
`
`
`takes one reference in Coulombe to XHTML, which notes that format
`
`conversion can include “conversion of layout formats (e.g. XHTML to WML)”
`
`(Coulombe, ¶ 87), and argues that it stands for something more than it does.
`
`(Id.).
`
`Mr. Klausner begins by stating that “Coulombe explains that incoming
`
`SIP to be adapted might be in XHTML format.” (Klausner Decl., ¶ 112). Mr.
`
`Klausner then goes on to state that “XHTML is a markup language used for web
`
`pages [and that] [i]t that it extends the well-known Hypertext Markup Language
`
`(HTML) and encapsulates the markup codes into an eXtensible Markup
`
`Language (XML) file.” (Id.). From that, he goes on to conclude that “[b]ecause
`
`XHTML incorporates elements and features of HTML – including style sheets –
`
`one of ordinary skill in the art would have viewed the style sheet teachings of
`
`Druyan and Tittel as fully adaptable to the message adaption system disclosed
`
`in Coulombe.” (Klausner Decl., ¶ 110).
`
`A POSITA would not draw the conclusions Klausner reaches for two
`
`reasons. (Dr. Surati Decl., ¶ 45). First, while a POSITA would understand that
`
`the incoming SIP message body could be written in any recognized format
`
`including XHTML, Coulombe neither teaches that incoming messages are
`
`restricted to XHTML nor suggests that XHTML would be anything but one of
`
`many formats handled by the messaging system. (Id.).
`
`In addition, even if Coulombe disclosed a messaging system entirely
`
`based on XHTML, a POSITA would still not draw the conclusions Mr.
`
`- 11 -
`
`
`
`Klausner reached. (Dr. Surati Decl., ¶ 47). Dr. Surati testified that Mr.
`
`Klausner errs in his reading of Coulombe because a POSITA would recognize
`
`that XHTML, as used in messaging, has generally a far more limited feature set
`
`than XHTML to generate web pages. (Id.). Thus, a POSITA would not
`
`understand that the mere receipt of messages in XHTML would render them
`
`compatible with style sheet teachings like those in Druyan and Tittel. (Id.).
`
`The Jabber Software Foundation, in defining the “Requirements” of
`
`XHTML for instant messages, the Jabber Foundation recognized that the
`
`requirements for publishing content on Web pages are “fundamentally
`
`different” and thus “only a reduced set of XHTML features is needed.” (Ex.
`
`2004, JEP XHTML, at pg. 3). The Jabber Foundation offered the following
`
`reasons:
`
`1. IM clients are not XHTML clients: their primary purpose is not
`to read pre-existing XHTML documents, but to read and
`generate relatively
`large numbers of fairly small
`instant
`messages. (emphasis in original).
`
`2. The underlying context for XHTML content in Jabber/XMPP
`instant messaging is provided not by a full XHTML document,
`but by an XML stream, and specifically by a message stanza
`within that stream. Thus the <head/> element and all its children
`are unnecessary. Only the <body/> element and some of its
`children are appropriate for use in instant messaging.
`
`3. The XHTML content that is read by one's IM client is normally
`generated on the fly by one's conversation partner (or, to be
`
`- 12 -
`
`
`
`precise by his or her IM client). Thus there is an inherent limit to
`the sophistication of the XHTML markup involved. Even in
`normal XHTMI documents, fairly basic structural and rendering
`elements such as definition lists, abbreviations, addresses, and
`computer input handling (e.g., <kbd/> and <var/>) are relatively
`rare. There is little or no foreseeable need for such elements
`within the context of instant messaging.
`
`4. The foregoing is doubly true of more advanced markup such as
`tables, frames, and forms (however, there exists an XMPP
`extension that provides an instant messaging equivalent of the
`latter, as defined in Data Forms).
`
`5. Although ad-hoc styles are useful for messaging (by means of the
`'style' attribute), full support for Cascading Style Sheets (defined
`by
`the <style/> element or a standalone
`.css file, and
`implemented via the 'class' attribute) would be overkill since
`many CSS1 properties (e.g., box, classification, and text
`properties) were developed especially for sophisticated page
`layout.
`
`6. Background images, audio, animated text, layers, applets, scripts,
`and other multimedia content types are unnecessary, especially
`given the existence of XMPP extensions such as File Transfer.
`
`those defined by XSL
`transformations such as
`7. Content
`Transformations must not be necessary in order for an instant
`messaging application to present lightweight text markup to an
`end user.
`
`
`(Ex. 2004, JEP XHTML, at pg. 3 (emphasis added unless otherwise indicated)).
`
`- 13 -
`
`
`
`
`
`B.
`
`Tittel
`
`As Dr. Surati testified, a POSITA would find the scope of Tittel to be of
`
`no import to the problems of format and layout adaptions of the type described
`
`in Coulombe. (Dr. Surati Decl., ¶ 50.) The linked external style sheets
`
`described in Tittel are cascading style sheets (CSS). (Id.). CSS was the
`
`predominant type of style sheet in use at the time of the claimed invention, and
`
`CSS was supported by most HTML browsers, as Tittel recognized. (Id.; Tittel,
`
`pgs. 68-69). CSS style sheets applied to HTML documents are strictly
`
`presentational in nature and cannot be used in conjunction with any of the five
`
`adaptions described in Coulombe at ¶¶ 87 to 91, other than arguably some
`
`aspects of ¶ 89, as Dr. Surati explained in testimony below. (Id.).
`
`An important aspect of web page design, as Dr. Surati explained, is
`
`separating the business layer (i.e., the business logic for generating the content
`
`of a web page) from the presentation layer (i.e., the presentation rules for how to
`
`display the content generated by the business rules). (Dr. Surati Decl., ¶ 51).
`
`This separation allows the presentation layer to be modified and maintained
`
`independent of the business logic used to generate the content to be displayed.
`
`CSS is a style sheet language that enables separation of document content from
`
`document presentation by describing the rules for the presentation of a
`
`document written in a markup language (i.e., the rules for how the content is
`
`displayed on a web page). (Id.) As described in Tittel, CSS defines presentation
`
`- 14 -
`
`
`
`rules such as the colors and background of a document, margins and borders of
`
`text boxes, and font properties. (Id.; Tittel, pgs. 61-67).
`
`In addition, as Dr. Surati testified, separation of presentation using CSS
`
`improves content accessibility, provides more flexibility and control in the
`
`specification of presentation characteristics, and enables multiple HTML pages
`
`to share formatting by specifying the relevant CSS in a separate .css file. (Dr.
`
`Surati Decl., ¶ 52.) Thus, for example, aesthetic changes to the graphic design
`
`of a document (or hundreds of documents) can be applied quickly and easily, by
`
`editing a few lines in one file, rather than by a laborious (and thus expensive)
`
`process of crawling over every document line by line. (Id.) Tittel describes how
`
`one might incorporate CSS in html files as a <link> element. (Tittel, pg. 68).
`
`Notably, XHTML allows something similar to that and in xml files one can
`
`always simply add the <?xsl-stylesheet? Type=”text/css” href=”urlof css file”>
`
`instruction, but the type property is “text/css” and the href must point to an
`
`external link as Dr. Surati explained. (Dr. Surati Decl., ¶ 52)
`
`But because CSS style sheets only address the presentation of the
`
`elements, Dr. Surati testified that it is of no relevance to the more sophisticated
`
`format and layout transformations described in Coulombe. (Dr. Surati Decl., ¶
`
`53). CSS style sheets cannot alter the content of the input document. For
`
`example, there is no mechanism in CSS to delete an element, change an element
`
`(e.g., reduce the number of pixels of an image), or change the encoding format
`
`of an element. (Id.).
`
`- 15 -
`
`
`
`Thus, for that reason, Dr. Surati testified that a CSS style cannot: (i)
`
`convert the media content format of a document (e.g., the PNG to GIF and
`
`XHTML to WML conversions described at ¶ 87 of Coulombe); (ii) alter the
`
`media characteristics of a document (e.g., reducing the quality of JPEG images
`
`or the number of colors of GIF images as described at ¶ 88 of Coulombe); (iii)
`
`remove elements of the document or reduce the size of an element in the actual
`
`document (as opposed to the size of how it appears on the display) (e.g.,
`
`removing media elements or reducing size of a document by reducing the size
`
`of its image parts as described in ¶ 90 of Coulombe) or (iv) change the
`
`packaging of the data within a document (e.g., changing how the data is
`
`encapsulated depending on the network used for transport as described in ¶ 91
`
`of Coulombe). (Dr. Surati Decl., ¶ 54.)
`
`According to Dr. Surati, the only aspect of CSS style sheets that would
`
`arguably have any relevance to adaption to different display derives from the
`
`fact that a CSS style sheet can be used to scale the image for display to the
`
`display characteristics of the client (e.g., scaling an image to half its
`
`dimensions). (Dr. Surati Decl., ¶ 55.) However, this use of CSS only changes
`
`how the image appears on the display; it does not change the actual size of the
`
`image sent. (Id.) While the resulting image might look visually acceptable, Dr.
`
`Surati testified that a POSITA would recognize that sending the full image and
`
`changing the size of rendering at the client would not be an acceptable solution
`
`for a couple of reasons. (Id.) First, by sending the entire image (even though it
`
`- 16 -
`
`
`
`will be render at half its size) unnecessary bandwidth is being utilized to send
`
`the image. (Id.) Second, the client would have to engage in substantial
`
`additional processing in the case where it has to scale a larger image rather than
`
`simply receiving the smaller size image to display. (Id.) In the case of scaling,
`
`the decoding would require a larger amount of memory and the processing of
`
`the image would likely require the processing of each of the original
`
`pixels(which there are more of) to perform the scaling. (Id.)
`
`Thus, Dr. Surati testified that a POSITA would understand that style
`
`sheet transformation involving changing the actual elements of the web page
`
`document to be displayed would require XSLT style sheets like the ones
`
`described in Druyan. (Dr. Surati Decl., ¶ 56.) Per Dr. Surati, the process for an
`
`XSLT style involves an XML document input that defines the elements and
`
`attributes of the document to be displayed and an XSLT processor that can be
`
`programmed to perform any type of transformation that may be desired (e.g.,
`
`remove the element, change its format (such as from XHTML to WML),
`
`change it to an entirely different element based on business rules in the XSLT
`
`processor, etc.). (Id.)
`
`In addition, Dr. Surati testified that the fact that Tittel discloses that
`
`external CSS style sheet files can be linked to HTML documents and yield
`
`predictable visual results in a browser would not suggest to a POSITA that any
`
`other types of style sheets, including XSLT style sheets, could be linked to in
`
`HTML documents and provide the types of transformations described in
`
`- 17 -
`
`
`
`Coulombe. (Dr. Surati Decl., ¶ 57.) First, a POSITA would not have been
`
`motivated to use presentation style sheets other than CSS because CSS was the
`
`only type of style sheets generally supported by browsers at the time of the
`
`invention. (Id.). Moreover, a POSITA would understand that presentatio
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
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.
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.
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
