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
`
`
`
`DECLARATION OF RAJEEV SURATI, Ph.D.
`
`
`
`001
`
`TriPlay's Exhibit 2002
`
`
`
`____________
`
`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
`
`
`
`DECLARATION OF RAJEEV SURATI, Ph.D.
`
`
`
`001
`
`TriPlay's Exhibit 2002
`
`
`
`TABLE OF CONTENTS
`
`I
`
`QUALIFICATIONS ................................................................................ 1
`
`II MATERIAL CONSIDERED ................................................................... 3
`
`III. OVERVIEW AND LEGAL STANDARDS ............................................ 5
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART ...................................... 7
`
`V.
`
`THE SCOPE AND CONTENT OF THE PRIOR ART ............................ 7
`
`A.
`
`Coulombe ...................................................................................... 7
`
`1.
`
`2.
`
`Overview ............................................................................. 7
`
`SIP and the SIMPLE protocol for instant messaging ............ 9
`
`3. Multimedia Messaging And The Interoperability Problem. 10
`
`4.
`
`5.
`
`6.
`
`The Coulombe messaging system embodiment .................. 11
`
`Coulombe’s teachings regarding web browsing ................. 15
`
`Coulombe Teachings Regarding XHTML ......................... 18
`
`B.
`
`Tittel ............................................................................................ 22
`
`C. Druyan ......................................................................................... 27
`
`1.
`
`2.
`
`3.
`
`The XSLT prior art and the XML input file ....................... 27
`
`The Druyan Invention: Segmenting The Master XSLT
`Style Sheet File 230 To Create Derivative Style Sheets
`Generated At The Time Of Request ................................... 29
`
`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 ................................................ 32
`
`VI. CLAIM CONSTRUCTION ................................................................... 38
`
`i
`
`002
`
`TriPlay's Exhibit 2002
`
`
`
`A.
`
`B.
`
`C.
`
`“select” ........................................................................................ 38
`
`“predefined layout” ...................................................................... 42
`
`“media block and access block” ................................................... 44
`
`VII. VALIDITY ANALYSIS ........................................................................ 49
`
`A.
`
`B.
`
`Claim 1 is not obvious over Coulombe ........................................ 49
`
`Claim 6 is not obvious over Coulombe in view of Druyan and
`Tittel ............................................................................................ 50
`
`1.
`
`2.
`
`3.
`
`4.
`
`5.
`
`Overview ........................................................................... 50
`
`Combining Coulombe with Druyan and/or Tittel cannot
`render claim 6 invalid because none of these references
`disclose “a template” ......................................................... 52
`
`Combining Coulombe with Druyan and/or Tittel cannot
`render claim 6 invalid because none of these references
`disclose “a predefined” layout ............................................ 53
`
`A POSITA would have no reason or motivation to
`combine Coulombe with Tittel ........................................... 55
`
`A POSITA would have had no reason or motivation to
`combine Coulombe with Druya ......................................... 58
`
`a.
`
`b.
`
`A POSITA would find no benefits associated
`with combining Druyan with Coulombe, and Mr.
`Klausner does not identify any benefits or other
`motivations for making the combination .................. 60
`
`A POSITA would not combine Druyan with
`Coulombe because it would change Coulombe’s
`basic principles of operation .................................... 62
`
`
`
`i.
`
`Druyan would hinder Coulombe’s basic
`principle that the content received can be
`
`ii
`
`003
`
`TriPlay's Exhibit 2002
`
`
`
`in any media, have any characteristics, and
`be expressed in any format ............................. 63
`
`ii.
`
`Druyan would hinder Coulombe’s basic
`principles of flexible delivery decisions
`based on characteristics of the content,
`capabilities of devices and user
`preferences ..................................................... 66
`
`6.
`
`A POSITA would have had no reason or motivation to
`combine Coulombe with Druyan and Tittel ....................... 70
`
`
`
`iii
`
`004
`
`TriPlay's Exhibit 2002
`
`
`
`I, Rajeev Surati, Ph.D., declare as follows:
`
`I.
`
`QUALIFICATIONS
`
`1.
`
`I have more than twenty (20) years of experience in electrical
`
`engineering, computer science, and electronic messaging.
`
`2.
`
`I attended the Massachusetts Institute of Technology (MIT) from
`
`1988 to 1999, during which time I earned Bachelor of Science (1992), Master of
`
`Science (1995), and Doctor of Philosophy (1999) degrees in electrical
`
`engineering and computer science.
`
`3.
`
`I am the inventor of US Patent No. 5,943,478, entitled “System for
`
`Popup Messaging over the Internet,” which describes a two-way messaging
`
`system like AOL Instant Messenger and MIT’s Zephyr service built at Internet
`
`scale.
`
`4.
`
`In 1996, I founded a company called Flash Communications,
`
`which focused on technology related to US Patent No. 5,943,478 and associated
`
`technology that I had developed related to pop-up two-way messaging over the
`
`Internet. Flash Communications was sold to Microsoft Corporation in 1998,
`
`and Flash Communications’ messaging technology was incorporated into
`
`Microsoft’s Messenger service and Microsoft Exchange 2000 Instant Messaging
`
`Server.
`
`5. While working at Microsoft between 1999 and 2000, I
`
`implemented an XML-based protocol that formed a basis for the Extensible
`
`Messaging and Presence Protocol (XMPP), which is now an IETF standard for
`
`- 1 -
`
`005
`
`TriPlay's Exhibit 2002
`
`
`
`the Exchange Instant Messaging Server. I participated internally with the
`
`program management team on helping specify this protocol for the IETF
`
`standardization process.
`
`6.
`
`Between 2000 and 2004, I worked as a consultant and investor at
`
`Nexaweb Corporation, where I helped implement several two-way messaging
`
`features over HTTP.
`
`7.
`
`Also in 2000, I started a company known as photo.net, which was a
`
`large online photography community where I worked with many consumer
`
`electronics manufacturers in the digital camera business. I also implemented a
`
`number of multimedia transformation systems in implementing some of the first
`
`photo sharing systems for the internet on photo.net. Notably, the website in
`
`outputting HTML and WML formatted documents allowed me to experience
`
`and understand many of the issues related to layout and format and style sheets
`
`discussed in this declaration.
`
`8.
`
`In 2004,
`
`I
`
`founded another company, Scalable Display
`
`Technologies (SDT). I have been the President and Chairman of SDT since its
`
`founding. SDT operates in the audio-video domain and has licensed software
`
`and firmware to various companies including Sony, Hitachi and NEC. I also
`
`implemented a distributed multimedia content playback system and spend a
`
`great deal of time dealing with multimedia transcoding and rendering systems.
`
`9.
`
`I am on the advisory boards of several technology companies,
`
`including:
`
` UnifySquare, which
`
`is a unified communications/realtime
`
`- 2 -
`
`006
`
`TriPlay's Exhibit 2002
`
`
`
`collaboration consultancy that focusses on telephony and instant messaging
`
`systems that Microsoft sells (Lync, an outgrowth of the company I sold
`
`Microsoft); Paneve, which develops general purpose ASIC coupled with
`
`compiler technology; Nexaweb, which develops realtime web application
`
`frameworks using HTTPS; Antix Labs, which develops compiler technology for
`
`universal gaming platform; Permabit, which develops content addressable
`
`storage; and Evoque, which is an ecommerce enabling platform publisher.
`
`10.
`
`I have received several awards for my contributions as an inventor
`
`and entrepreneur, including the Global Indus Technovator Award 2009 and
`
`Laureate of 2009 Computer World Honors Program.
`
`11. Additional information regarding my qualifications is set forth in
`
`my current curriculum vita, which is attached hereto as Exhibit A.
`
`12.
`
`I have no financial interest in the Petitioner, the Patent Owner, or
`
`the outcome of this proceeding. I am being compensated for my work as an
`
`expert on an hourly basis at the rate of $350 per hour. My compensation is not
`
`dependent on the outcome of these proceedings or the content of my opinions.
`
`II. MATERIAL CONSIDERED
`
`13. The analysis provided in this Declaration is based on my education
`
`as well as my experience in the field of computer systems, generally, and
`
`electronic messaging systems, in particular. In addition to relying upon my
`
`knowledge based on written materials and other information that was known in
`
`2005, I have considered the following additional materials:
`
`- 3 -
`
`007
`
`TriPlay's Exhibit 2002
`
`
`
`•
`
`•
`
`•
`
`•
`
`U.S. Patent No. 8,332,475 (“the ‘475 patent”) [Ex. 1001];
`
`Petitioner’s Petition for Inter Partes Review dated February 14,
`2015
`
`Declaration of David Klausner (“Klausner Decl.”) dated February
`
`14, 2015 [Ex. 1002];
`
`The exhibits attached to the Klausner Decl., namely:
`o
`
`U.S. Patent App. Pub. No. 2003/0236892 to Stephanie
`
`Coulombe (“Coulombe”) [Ex. 1003];
`
`o
`
`o
`
`o
`
`o
`
`o
`
`U.S. Patent No. 6,928,617 to Alexander Druyan et al.
`
`(“Druyan”) [Ex. 1004];
`
`Ed Tittel et al., More HTML for Dummies (2d ed. 1997)
`
`(“Tittel”) [Ex. 1005];
`
`John F. Meech, et al., A Multi-Agent System for Personal
`
`Messaging (“Meech”) [Ex. 1006];
`
`U.S. Patent No. 6,167,441
`
`to Maria Azua Himmel
`
`(“Himmel”) [Ex. 1007]; and
`
`Reply to Office Action dated May 18, 2012 which was filed
`
`in the prosecution history of the ‘475 patent [Ex. 1008].
`
`•
`
`Internet Engineering Task Force (IETF), SIP Extensions for Instant
`
`Messaging dated July 18, 2001 (“Draft version 1 of SIMPLE”)
`
`[Ex. 2003]
`
`•
`
`Jabber Software Foundation, JEP-0071: XHTML-IM dated
`
`- 4 -
`
`008
`
`TriPlay's Exhibit 2002
`
`
`
`September 29, 2004 (“JEP XHTML”) [Ex. 2004]
`
`Transcript of the Deposition of David Klausner dated November 4,
`
`2015 (“Klausner Dep.”) [Ex. 2005]
`
`American Heritage Dictionary, Fourth Edition 2000, Definitions of
`
`“Select” and “Determine” [Ex. 2006]
`
`The Merriam Webster Dictionary (2004), Definitions of “Select”
`
`and “Determine” [Ex. 2007]
`
`The Microsoft Computer Dictionary, Fifth Edition (2002),
`
`•
`
`•
`
`•
`
`•
`
`Definition of “Select” [Ex. 2008]
`
`III. OVERVIEW AND LEGAL STANDARDS
`
`14.
`
`I have been asked to consider the Klausner Declaration and offer
`
`my opinion on two questions: (1) whether claim 1 of the ‘475 patent would have
`
`been obvious in view of Coulombe and (2) whether claim 6 of the ‘475 patent
`
`would have been obvious over Coulombe in view of Druyan and Tittel at the
`
`time the invention was made to a person of ordinary skill in the art. I am
`
`offering the foregoing opinions as to claims 1 and 6 only, because TriPlay’s
`
`counsel advised me that I should accept, for purposes of rendering my opinion,
`
`Mr. Klausner’s statements that claim 1 is representative of claims 1, 12, 23, 37,
`
`39 and 41 and claim 6 is representative of claims 9, 17, 18, 28 and 40.
`
`15.
`
`I have been informed that a patent is obvious if the differences
`
`between the claimed subject matter and the prior art are such that the subject
`
`matter as a whole would have been obvious at the time the invention was made
`
`- 5 -
`
`009
`
`TriPlay's Exhibit 2002
`
`
`
`to a person having ordinary skill in the art.
`
`16.
`
`I understand that a patent claim composed of several elements is
`
`not deemed obvious simply because each of its elements was, independently,
`
`known in the prior art. Instead, it is my understanding that a party contending
`
`that a patent claim is obvious in view of a combination of references must show
`
`that a person of ordinary skill in the relevant field would have had a reason to
`
`combine the elements disclosed in the references in the manner claimed. I also
`
`understand that the mere fact that it is technically possible to combine
`
`references is not enough of a reason to combine them.
`
`17.
`
`I further understand that a patent challenger’s reason for combining
`
`references must include some rational underpinning to support a legal
`
`conclusion of obviousness. Although the obviousness analysis is not confined
`
`by a formalistic conception of the words teaching, suggestion, and motivation, I
`
`understand that it does require identifying a reason or motivation that would
`
`have prompted a person of ordinary skill in the relevant field to combine the
`
`elements in the way the claimed invention does.
`
`18.
`
`I further understand that a person of ordinary skill in the art would
`
`not be motivated to modify a prior art reference if the proposed modification
`
`would render the prior art invention unsatisfactory for its intended purpose. I
`
`also understand that an obviousness allegation cannot be supported by a
`
`combination of references that would require a substantial reconstruction and
`
`redesign of the elements shown in the primary reference or that would change
`
`- 6 -
`
`010
`
`TriPlay's Exhibit 2002
`
`
`
`the basic principle under which the primary reference was designed to operate.
`
`19. Finally, in order to render opinions on two obviousness issues set
`
`out above, I understand that I must first address the following factual issues: (1)
`
`resolving the level of ordinary skill in the prior art; (2) determining the scope
`
`and content of the prior art; and (3) ascertaining the differences between the
`
`claimed invention and the prior art.
`
`IV. LEVEL OF ORDINARY SKILL IN THE ART
`
`20.
`
`It is my opinion that a person of ordinary skill in the art at the time
`
`of the invention of the TriPlay patents (i.e., in 2005) is a person with a bachelor’s
`
`degree in either electrical engineering or computer science, at least two years of
`
`experience designing and implementing messaging systems between user
`
`devices, and at least one year of experience working with format encoding and
`
`layout of images or video.
`
`V. THE SCOPE AND CONTENT OF THE PRIOR ART
`A. Coulombe
`
`1. Overview
`
`21. Coulombe “relates to the interoperability between terminal devices
`
`using session initiation protocol (SIP) messages and, more particularly, to
`
`multimedia content adaption.” (Coulombe, ¶1). It describes a “framework” for
`
`“the adaption of messages between sender and recipient.” (Coulombe, ¶53).
`
`The “goal” of Coulombe is to:
`
`- 7 -
`
`011
`
`TriPlay's Exhibit 2002
`
`
`
`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.
`
`Id. (emphasis added).
`
`22. 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. The “characteristics of the incoming messages” are not
`
`known in advance and can include a variety of characteristics as described in
`
`Coulombe. For example, the “characteristics of the incoming messages” 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
`
`- 8 -
`
`012
`
`TriPlay's Exhibit 2002
`
`
`
`formats for the body of the message other than SIP) (e.g., Coulombe, ¶
`
`86 (received message body could be expressed in XHTML).
`
`2.
`
`SIP and the SIMPLE protocol for instant messaging
`
`23. A person of ordinary skill in the art (POSITA) would understand
`
`that the SIP protocol is used to initiate, modify and terminate network sessions.
`
`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.
`
`24. 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. For example, Coulombe identifies as one of the advantages
`
`of the invention the fact that it works with SIP messages “including Instant
`
`Messages and notification (e.g. Message and Notify method).” (Id., ¶ 42). A
`
`POSITA would understand that the “Message and Notify” methods described
`
`throughout Coulombe (see ¶¶ 42, 58 & 120) is referring to instant messaging.
`
`But most significantly, the only protocol 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.
`
`25. SIMPLE stands for “session
`
`initiation protocol for
`
`instant
`
`messaging and presence leverage extensions.” Draft version 1 of SIMPLE [Ex.
`
`2003] is referenced at ¶ 0069 of Coulombe. The draft SIMPLE protocol defines
`
`- 9 -
`
`013
`
`TriPlay's Exhibit 2002
`
`
`
`“instant messaging” as “the exchange of content between a set of participants in
`
`real time. Generally, the content is short textual messages, although that need
`
`not be the case.” (Draft Version 1 of SIMPLE, pg. 3). Further, the protocol
`
`states the mechanisms needed in an instant messaging protocol are very much
`
`like the mechanisms needed to establish an interactive session, “rapid delivery of
`
`small content to a user at their current location, which may, in general, be
`
`dynamically changing as the user moves.” (Id., pg. 3). These descriptions are
`
`consistent with my opinion as to how a person of ordinary skill in the art would
`
`have understood instant messaging at the time of the invention.
`
`3. Multimedia Messaging And The
`Problem
`
`Interoperability
`
`26. As Coulombe correctly notes, “[i]nteroperability is of paramount
`
`importance in messaging. Users expect that messages will reach their
`
`destination terminal and will be handled properly by the recipient’s terminal.”
`
`(Coulombe, ¶ 2). This is the starting point to the design of a messaging system,
`
`because users will quickly stop using a messaging system that does not reliably
`
`send their messages to recipients in readable or viewable form.
`
`27. The interoperability problem was particularly challenging in 2004-
`
`2005, as the state of the art was far less advanced at the time. This era
`
`significantly pre-dated the 2007 introduction of the iPhone 1. Network
`
`bandwidth for mobile phones in the US was largely being run on 2 and 2.5G
`
`networks and slowly upgrading to 3G networks. Mobile “smart phones”
`
`- 10 -
`
`014
`
`TriPlay's Exhibit 2002
`
`
`
`represented a small fraction of the cellular phone market. The display screens
`
`of mobile phones had orders of magnitude lower resolution. Web browsing was
`
`largely confined to desktop computers. Browsing the Internet using mobile
`
`phones was largely based on the wireless application protocol (WAP), a far
`
`more limited and less pleasing experience. As a consequence of these
`
`limitations, messaging at the time was predominantly text. Sending images and
`
`video content was not common. Moreover, even for text, messaging protocols
`
`paid significant design attention to optimizing the total size of the message to
`
`insure interoperability over bandwidth constrained networks.
`
`28.
`
` As Coulombe recognized, interoperability in the mobile market at
`
`the time was made “more challenging due to the wide diversity of terminal
`
`display characteristics: display size and resolution, available memory, formats
`
`supported, etc.” and because “the network also imposes limitations . . . .”
`
`(Coulombe, ¶ 2).
`
`4.
`
`The Coulombe messaging system embodiment
`
`29. The embodiment describes 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.
`
`- 11 -
`
`015
`
`TriPlay's Exhibit 2002
`
`
`
`
`
`30. 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
`
`communicating with the Capability Negotiation Manager 16 and the Message
`
`Adaption Engine 20. (Coulombe, ¶¶ 57, 58 & Fig. 3).
`
`31. 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 set forth below, Coulombe teaches a very
`
`flexible system that permits the users to assert a high degree of control
`
`- 12 -
`
`016
`
`TriPlay's Exhibit 2002
`
`
`
`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).
`
`32.
`
`“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
`
`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).
`
`33. 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
`
`- 13 -
`
`017
`
`TriPlay's Exhibit 2002
`
`
`
`“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.).
`
`34. 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. 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. In other
`
`words, the message registers that the users is present and online with the device
`
`that is sending the register message. Accordingly, capability information such
`
`as user preferences could be changed any time a user logs onto the system.
`
`35. 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. 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).” (Coulombe, ¶ 82). If the registrar does not have any capability
`
`information, “the proxy will initiate a SIP OPTIONS request to the recipient in
`
`- 14 -
`
`018
`
`TriPlay's Exhibit 2002
`
`
`
`order to learn its capabilities or user preferences.” ((Id.).
`
`36. 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).
`
`37. A number of adaptations are describes
`
`including
`
`format
`
`conversion, media characteristics adaptation, presentation or layout adaptation,
`
`and message size adaption, and details are provided regarding each of these
`
`adaptations. (Coulombe, ¶¶ 86-114). Mr. Klaussner’s Declaration (at ¶¶ 49-51)
`
`provides details regarding the teachings of these adaptions. And since I agree
`
`with Mr. Klausner’s descriptions of the adaption engine (at ¶¶ 49-51 of the
`
`Klausner Decl.), I have not repeated those details here.
`
`5.
`
`Coulombe’s teachings regarding web browsing
`
`38. Coulombe
`
`recognizes
`
`important distinctions between web
`
`browsing and messaging. 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.”
`
`- 15 -
`
`019
`
`TriPlay's Exhibit 2002
`
`
`
`(Coulombe, ¶ 6). 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.).
`
`39. Mr. Klausner discounts the significance of the foregoing teaching
`
`from Coulombe, and, in doing so, reads the teaching far too narrowly. 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 device?”
`
`(Klausner Decl., ¶ 112). Accordingly, he argues that the teaching is irrelevant
`
`to the motivations for combining Druyan and Tittel with Coulombe because that
`
`web browsing concern has nothing to do with the purposes for which he cites
`
`Tittel and Druyan.
`
`40. But the teaching of Coulombe is not limited to a “single issue.”
`
`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.” (Coulombe, ¶ 6). The
`
`methods used in browsing to obtain terminal capabilities is one example of
`
`- 16 -
`
`020
`
`TriPlay's Exhibit 2002
`
`
`
`“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.
`
`41. For example, 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 demarcated the data
`
`contained) as discussed in Druyan are “methods to adapt Web pages to different
`
`end users.” 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. A web
`
`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. 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. In contrast, 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.
`
`- 17 -
`
`021
`
`TriPlay's Exhibit 2002
`
`
`
`42. Thus, Mr. Klausner is mistaken in my opinion in simply dismissing
`
`this teaching by stating that because he thinks there is a single issue: “the web
`
`browsing problem identified in Coulombe, and 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 ….” (Klausner Decl., ¶
`
`112).
`
`6.
`
`Coulombe Teachings Regarding XHTML
`
`43. As I will discuss in more detail, 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.
`
`In order to overcome that issue, Mr. Klausner takes one reference in Coulombe
`
`to XHTML (a form of XML), 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 does.
`
`44. 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
`
`- 18 -
`
`022
`
`TriPlay's Exhibit 2002
`
`
`
`– 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.” (Coulombe, ¶ 110).
`
`45. A POSITA would not draw the conclusions Klausner reaches for
`
`two reasons. 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.
`
`46.
`
` In addition, a POSITA would understand there were two existing
`
`popular protocols for instant messaging in 2004-2005, SIP/SIMPLE and
`
`XMPP/Jabb
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
