UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`WHATSAPP INC. and FACEBOOK, INC.
`
`Petitioner
`
`v.
`
`TRIPLAY, INC.
`
`Patent Owner
`
`____________
`
`IPR2016-00718
`
`Patent 8,874,677 B2
`
`
`
`PATENT OWNER’S RESPONSE
`
`PURSUANT TO 37 C.F.R. § 42.120
`
`Paper No. 23
`
`

`
`TABLE OF CONTENTS
`
`2. 
`
`3. 
`
`I. 
`II. 
`
`INTRODUCTION ................................................................................. - 1 - 
`STATEMENT OF FACTS .................................................................... - 5 - 
`A.  U.S. Patent No. 8,874,677 ........................................................... - 5 - 
`B. 
`Scope Of Prior Art ....................................................................... - 9 - 
`1. 
`Summary chart of Ground One obviousness
`combinations ..................................................................... - 9 - 
`Coulombe (Ex. 1103) ...................................................... - 12 - 
`a) 
`Session-based SIP communications ..................... - 13 - 
`b) 
`Non-session-based SIP communications .............. - 14 - 
`c) 
`The Coulombe solution ........................................ - 15 - 
`d) 
`Session-based SIP, video delivery and
`adaptation .............................................................. - 16 - 
`Friedman [Ex. 1105] ....................................................... - 18 - 
`a) 
`The prior art problem ............................................ - 19 - 
`b) 
`Friedman’s “improved” client for processing
`attachments ........................................................... - 21 - 
`Bellordre [Ex. 1104] ....................................................... - 24 - 
`4. 
`III.  THE LAW GOVERNING OBVIOUSNESS ...................................... - 26 - 
`IV.  PETITIONER HAS NOT PROVED OBVIOUSNESS ...................... - 30 - 
`A. 
`Petitioner Does Not Offer a Sufficient Motivation to Modify
`Coulombe in Accordance with Bellordre to Deliver and Adapt
`Video Because Petitioner Fails to Consider That Coulombe
`Already Supported Video Delivery and Adaptation ................. - 30 - 
`1. 
`Petitioner fails to offer a sufficient motivation to
`modify Coulombe in accordance with Bellordre to
`arrive at claim limitation 6d ............................................ - 31 - 
`Petitioner fails to offer a sufficient motivation to
`modify Coulombe in accordance with Bellordre to
`arrive at claim limitation 6f ............................................. - 40 - 
`Petitioner Fails to Offer a Sufficient Motivation to Combine
`Coulombe with Friedman’s Attachment Processing Methods .. - 44 - 
`
`2. 
`
`B. 
`
`i
`
`

`
`D. 
`
`E. 
`
`Petitioner’s Conclusory Motivations Do Not Support
`Combining Coulombe, Friedman and Bellordre to Arrive at
`the Full Scope of Limitation 6f ................................................. - 51 - 
`The Petition Offers No Motivations to Combine Coulombe,
`Friedman and Bellordre to Arrive at Limitation 6g .................. - 57 - 
`The Petition Reconstructs the Challenged Claims using
`Hindsight ................................................................................... - 59 - 
`CONCLUSION .................................................................................... - 61 - 
`
`
`C. 
`
`V. 
`
`
`
`
`
`ii
`
`

`
`Exhibit
`2107
`2108
`
`2109
`
`TABLE OF EXHIBITS
`
`Description
`Declaration of Rajeev Surati, Ph.D. (“Surati”)
`
`November 10, 2016 Deposition of Mr. David Klausner
`(“Klausner Dep. Tr.”)
`
`Declaration of Mr. David Klausner with respect to IPR2016-
`01659 and IPR2016-01660 Petitions relating to U.S. Patent
`No. 9,049,574 (“Klausner Declaration re: 574-Petitions”)
`
`
`
`
`
`iii
`
`

`
`
`
`TABLE OF AUTHORITIES
`
`
`
`Page(s)
`
`Cases
`
`Cardiocom, LLC v. Robert Bosch Healthcare Sys., Inc.,
`IPR2013-00439, Paper 26 (Jan. 16, 2014) ......................................................................... 31
`
`Hughes Network Sys., LLC v. Elbit Sys. Land and C4I Ltd.,
`IPR2016-00496, Paper 7 (July 14, 2016)..................................................................... 48, 49
`
`In re Kahn,
`441 F.3d 977, 988 (Fed. Cir. 2006).................................................................................... 26
`
`InTouch Techs., Inc. v. VGO Commc’ns, Inc.,
`751 F.3d 1327 (Fed. Cir. 2014).............................................................................. 29, 39, 45
`
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) ............................................................................................... 25, 26, 46
`
`LG Display Co., Ltd. v. Innovative Display Techs. LLC,
`IPR2015-00487, Paper 36 (July 15, 2016)......................................................................... 32
`
`Lupin Ltd. v. Senju Pharm. Co., Ltd.,
`IPR2015-01100, Paper 70 (Sept. 15, 2016) ....................................................................... 34
`
`Minerva Surgical, Inc. v. Hologic, Inc.,
`IPR2016-00680, Paper 8 (Sept. 12, 2016) ................................................................... 32, 51
`
`Praxair Distribution, Inc. v. INO Therapeutics, LLC,
`IPR2015-00889, Paper 54 (Sept. 15, 2016) ........................................................... 28, 39, 45
`
`Runway Safe LLC v. Engineered Arresting Systems,
`IPR2015-01921, Paper 9 (Feb. 29, 2016) .............................................................. 27, 32, 39
`
`Silver Star Capital, LLC v. Power Integrations, Inc.,
`IPR2016-00736, Paper 11 (Aug. 26, 2016) ................................................................. 26, 31
`
`Southside Bancshares, Inc. v. St. Isidore Research, LLC,
`CBM2016-00027, Paper 28 (Aug. 1, 2016) ....................................................................... 56
`
`WhatsApp, Inc. v. TriPlay Commc’ns Ltd.,
`Case Nos. IPR2016-01659 & -01660 .................................................................................. 3
`
`Other Authorities
`
`37 C.F.R. § 42.6(e)................................................................................................................... 59
`
`37 C.F.R. § 42.23(b) ................................................................................................................ 35
`
`iv
`
`

`
`37 C.F.R. §§ 42.24 et seq. ........................................................................................................ 58
`37 C.F.R. §§ 42.24 et seq....................................................................................................... .. 58
`
`37 C.F.R. § 42.65(a)........................................................................................................... 26, 27
`37 C.F.R. §42.65(a) ......................................................................................................... ..26, 27
`
`
`
`v
`
`

`
`I.
`
`INTRODUCTION
`
`Petitioner contends that certain claims of U.S. Patent No. 8,874,677 (“the
`
`Challenged Claims”) are invalid for obviousness and, in its Petition (IPR2016-
`
`00718, “Petition”), alleged three grounds for its contention. Ground One is based
`
`on a combination of the Coulombe, Bellordre and Friedman references that
`
`Petitioner alleges invalidate claims 6, 7 and 15; Ground Two is based on a
`
`combination of the Coulombe, Bellordre, Friedman, Meyer and Ito references that
`
`Petitioner alleges invalidate claims 8 and 10; and Ground Three is based on a
`
`combination of the Coulombe, Bellordre, Friedman, Meyer, Ito, and Surana
`
`references that Petitioner alleges invalidate claim 9.
`
`In its Preliminary Response to the Petition, Patent Owner argued that
`
`Petitioner failed to make a prima facie case for obviousness and, in support of that
`
`argument, offered a Declaration from its technical expert Rajeev Surati, Ph.D. In
`
`particular, for claim 6 (the only independent claim challenged in the Petition),
`
`Patent Owner pointed out that Petitioner offers either wholly conclusory
`
`motivations or no motivations at all for making the four different combinations that
`
`a person of skill in the art (a “POSITA”) would supposedly make to render the
`
`claimed invention obvious. Patent Owner also pointed out that Petitioner did not
`
`explain why a POSITA would have modified Petitioner’s primary invalidity
`
`reference (Coulombe) to add video delivery capabilities from other references
`
`- 1 -
`
`

`
`when Coulombe already teaches a method of video delivery. As for the dependent
`
`claims addressed in Grounds Two and Three, Patent Owner noted that Petitioner
`
`added further references to its combination without articulating any rationale for
`
`doing so.
`
`In its September 8, 2016 institution decision, the Board found that Petitioner
`
`had failed to show a reasonable likelihood of prevailing with respect to the claims
`
`addressed in Grounds Two and Three. Only Ground One was instituted for trial.
`
`(Institution Decision [Paper 17] at 17-20). As to Ground One, while the Board
`
`considered Patent Owner’s contention that “Petitioner’s expert overlooked
`
`Coulombe’s passages teaching delivery of video,” it did not find that argument
`
`persuasive “on the current record.” At the time, the Board refused to give more
`
`weight to Patent Owner’s expert before a full record had been developed. (Id. at
`
`15-16.) The Board also considered Patent Owner’s arguments that Petitioner had
`
`failed to offer sufficient motivation to combine Coulombe, Friedman and
`
`Bellordere; however, it found, “[o]n the present record, and with the understanding
`
`that neither declarant has been deposed,” that Petitioner had “provided sufficient
`
`reason” to combine. (Id. at 16.)
`
`After the institution decision, Patent Owner deposed Petitioner’s expert,
`
`David Klausner. Salient parts of Mr. Klausner’s deposition testimony are being
`
`offered to support this Response, as is a declaration from Patent Owner’s expert,
`
`- 2 -
`
`

`
`Dr. Surati, that considers Mr. Klausner’s testimony. These additional materials
`
`confirm that the arguments Patent Owner made in its Preliminary Response were
`
`correct. The motivations that Petitioner posits for the complete redesign of
`
`Coulombe to meet the claim limitations are not well founded and fail to establish a
`
`case of obviousness for three independent reasons, any one of which is dispositive.
`
`First, Mr. Klausner admits that Coulombe discloses both the delivery of
`
`streaming video and the adaptation of video based on the capability of the
`
`destination device. These admissions are fatal for Petitioner because the Petition
`
`never explains why a POSITA would modify Coulombe to deliver and adapt video
`
`in accordance with the techniques of Bellordre when Coulombe already had such
`
`capability. Nor is the effect of these admissions on the Petition lessened by Mr.
`
`Klausner’s assertion that he considered Coulombe’s video delivery but concluded
`
`that streaming a video does not constitute delivery of the claimed “message.” Mr.
`
`Klausner’s after-the-fact attempt to explain away his failure to consider
`
`Coulombe’s video delivery is not credible. It is also directly contradicted by the
`
`sworn declarations he submitted in IPRs concerning Patent Owner’s U.S. Patent
`
`No. 9,049,574. (WhatsApp, Inc. v. TriPlay Commc’ns Ltd., Case Nos. IPR2016-
`
`01659 & -01660.) In those, he testified that streaming audio is the delivery of a
`
`“message” having the same scope proposed here. (See, e.g., Ex. 2109 [Klausner
`
`Decl. re: 574-Petitions] at ¶¶ 78-79 & 152-53.) Moreover, even if Coulombe’s
`
`- 3 -
`
`

`
`video delivery was not a “message that includes a video,” the Petition would still
`
`fail because it does not explain why a POSITA would be prompted to modify
`
`Coulombe’s streaming video capability in favor of Bellordre’s video delivery
`
`technique. The Petition also relies on Bellordre to disclose “an adapted version of
`
`the video,” but it does not explain why a POSITA would modify Coulombe to
`
`adapt the video in accordance with Bellordre. This omission is especially glaring
`
`given Mr. Klausner’s concession that Coulombe discloses its own video adaptation
`
`capability.
`
`Second, Petitioner’s motivations for modifying Coulombe in accordance
`
`with Friedman to disclose “providing by the media block a clickable icon” are
`
`conclusory statements
`
`that are not based on objective facts or rational
`
`underpinnings. For example, Petitioner contends that Coulombe’s “express
`
`disclosure” of messages that include attachments would motivate a POSITA to
`
`combine Friedman’s email attachment processing system into Coulombe. This
`
`combination, arrived at through hindsight, is Petitioner’s attempt to disclose the
`
`limitation “providing by the media block a clickable icon.” But it is based on
`
`irrational underpinnings, including, in particular, Mr. Klausner’s admission that his
`
`only basis for maintaining that Coulombe contemplated processing attachments is
`
`the fact that the word “attach” appears in Figure 2. That is not supportable: Figure
`
`2 displays adapted images, which are not sent as attachments. The word “attach”
`
`- 4 -
`
`

`
`is simply an artifact on a screen, and it is related to a generic email user interface
`
`having nothing to do with Coulombe’s substantive disclosures. Indeed, given the
`
`absence of any discussion of attachments in Coulombe, a POSITA would have
`
`drawn no conclusions about attachment techniques. The motivations that
`
`Petitioner offers with respect to Friedman are similarly conclusory.
`
`Third, Petitioner argues that a POSITA would cherry-pick components of
`
`Friedman and Bellordre and use those components to reconstruct the Coulombe
`
`adaptation engine. These are hindsight-driven arguments intended to disclose: (i)
`
`converting to an adapted message that includes an icon that may be clicked into an
`
`adapted video; and (ii) an adapted layout for the adapted message. But the
`
`Petitioner offers either purely conclusory motivations to combine Coulombe with
`
`Friedman and Bellordre with respect to (i) or no motivations at all with respect to
`
`(ii). As shown below, Petitioner’s cursory articulations of a rationale for
`
`combining prior art references do not support a finding of obviousness.
`
`II.
`
`STATEMENT OF FACTS
`
`A. U.S. Patent No. 8,874,677
`
`The ’677 patent “relates to [the] field of electronic messaging and to cross-
`
`platform messaging.” (Ex. 1101 [’677 patent] at 1:5-6.) In particular, the ’677
`
`patent recognized the existence of cross-platform compatibility issues associated
`
`with electronic message “layout” and “format.” With respect to layout, “[t]he
`
`- 5 -
`
`

`
`originating and destination devices may have different communication and
`
`displaying capabilities and may use different communication protocols.” (Id. at
`
`11:53-56.) Formats also present compatibility issues because the digital encoding
`
`of a media item at the originating device (e.g. a video encoded in an MPEG
`
`format) may not be supported at the destination device. (Id. at 12:16-21.)
`
`Figure 2 (reproduced below), shows elements of an exemplary “messaging
`
`system” that includes an “access block” 21 (highlighted blue) and “media block”
`
`23 (highlighted green):
`
`The “access block” 21 includes “a users’ gateway 211 and 3rd party applications’
`
`gateway 214 supporting communication with communication devices and 3rd party
`
`
`
`- 6 -
`
`

`
`application(s) via corresponding networks(s) . . . .” (Id. at 13:4-8.) The “media
`
`block” 23 “comprises transcoder 232 operatively coupled with a message manager
`
`231.” (Id. at 16:15-18.) The “media block” is further “configured to select the
`
`format and message layout fitting to the destination device and to convert the
`
`message accordingly before facilitating its delivery to the destination device.” (Id.
`
`at 16:18-20.)
`
`The ’677 patent also recognized that the delivery of electronic messages
`
`containing a video may be limited by available bandwidth and/or the inability of
`
`the receiving device to download the complete message (because it is too large).
`
`(Id. at 14:7-10, 16:30-32, and 16:67-17:3.) Accordingly, the “media block” 23 is
`
`structured to make delivery decisions that can include a “repackage” of the
`
`message in view of the limitations of bandwidth and destination device capabilities
`
`associated with certain messages. (Id. at 16:27-17:4.) The “repackaging”
`
`decisions are controlled by the “message manager” 231 of the “media block” 23,
`
`which may choose to send the converted messages “as one entity” or “as multiple
`
`entities to be re-assembled when received” and/or to replace “one or more media
`
`items” in the message with “corresponding links.” (Id. at 10:55-58.) Thus, media
`
`items, the delivery of which is limited by “communication media [i.e., bandwidth]
`
`and/or destination device” such as video, can be replaced for delivery with
`
`corresponding links. (Id. at 16:64-17:3.)
`
`- 7 -
`
`

`
`Further, when the media items are replaced with links, “media items
`
`contain[ed] in the originated message and/or media items converted” are stored at
`
`the intermediary “messaging system” until the link/icon is clicked. (Id. at 14:1-4.)
`
`Subsequently, an adapted version of the media item is, upon request, “downloaded
`
`to the destination devices via relevant protocols, including but not limited to
`
`HTTP, SMTP, MMS, etc.” or, if the media item is “too large for successful
`
`downloading,” is “transmitted to the destination device with the help of streaming
`
`protocols, e.g., RTSP, RTP, etc.” (Id. at 14:4-10.)
`
`The links to the media items that are replaced as part of the repackaging
`
`decisions are described in the ’677 patent as “clickable icons.” A “clickable icon”
`
`is a graphical hyperlink, such as a graphic image of any size and shape. (Ex. 2107
`
`[Surati] at ¶ 25; see also Ex. 2105 [Computer Desktop Encyclopedia] (defining a
`
`hyperlink as a link that “is displayed either as text or as an icon” and explaining
`
`that text displays as underlined text, “while a graphical hyperlink is a small
`
`graphics image of any size and shape”).) For example, the layout for a cellphone
`
`in Table 2 describes “a list of clickable icons into reduced media” for audio and
`
`video items and a “list of clickable media” for images, and the layout for a PC
`
`describes a “List of clickable media thumbnails.” (Ex. 1101 [’677 patent] at Col.
`
`21, Table 2.) The clickable icons are also shown in Figures 11 and 12, which show
`
`exemplary layouts for a cellphone and a PC, respectively:
`
`- 8 -
`
`

`
`(Ex. 1101 at Figures 11 & 12; see also Ex. 2107 [Surati] at ¶ 25).
`
`B.
`
`Scope Of Prior Art
`
`1.
`
`Summary chart of Ground One obviousness combinations
`
`Before discussing the scope of the three prior art references upon which the
`
`Petition relies for the obviousness combinations in Ground One, it is useful to look
`
`first at claim 6 as a whole in order to determine what references and/or
`
`combinations of references are being relied upon for each of the limitations of
`
`claim 6. A chart showing that is set forth below:
`
`Summary Chart Of Petition’s Claim 6 Combinations
`
`Limitation
` 
`6a A messaging system comprising
`an access block operatively
`coupled
`to a media block,
`wherein
`
`
`References Relied Upon
`Coulombe:
`“discloses
`‘a
`messaging system’”
`
`(Petition at 16)
`
`Coulombe: “SIP Proxy/Registrar”
`(12) discloses an “access block”
`
`
`- 9 -
`
`

`
`(Id. at 17)
`
`Coulombe: “‘Message Adaptation
`Engine’(20) discloses a “media block”
`
`(Id. at 17)
`Coulombe: SIP Proxy/Registrar 12 “is
`configured
`to
`receive an
`initial
`message
`sent by an originating
`communication device to a destination
`communication device”
`
`(Id. at 18-19)
`Coulombe: SIP Proxy/Registrar 12
`receives messages characterized by
`format and layout and data indicative
`of a receiver.
`
`(Id. at 19-21)
`
`Bellordre:
`in
`“message”
`The
`Bellordre “contain[s] … at least one
`…
`video multimedia
`object.”
`messages sent in Bellordre’s streaming
`server system can contain video
`objects.
`
`(Id. at 21)
`Coulombe: Message Adaptation
`Engine
`20
`obtains
`capability
`information from SIP Proxy Registrar
`12 and Message Adaptation Engine 20
`enables conversion of initial message
`to adapted message.
`
`(Id. at 22-27)
`Coulombe: Coulombe
`adaptation
`engine enables the conversion of an
`initial message to an adapted message
`(see 6e) that is modified by 6f-1 and
`
`6b
`
`is
`block
`access
`the
`configured to receive an initial
`messages sent by an originating
`communication device
`to a
`destination
`communication
`device,
`
`6c
`
`the initial message being
`characterized,
`at
`least,
`by
`message
`format,
`an
`initial
`message
`layout,
`and
`data
`indicative of at least one receiver
`associated with
`the
`initial
`message,
`initial message
`the
`6d wherein
`includes a video;
`
`
`6e
`
`6f-
`1
`
`the media block is configured to
`obtain
`data
`indicative
`of
`displaying capabilities of
`the
`destination
`communication
`device and enable conversion …
`of the initial message into an
`adapted message,
`
`the
`
`conversion
`
`wherein
`comprises:
`
`providing, by the media block, a
`
`- 10 -
`
`

`
`clickable icon:
`
`i) based on the video from the
`initial message and
`
`6f-
`2
`
`ii) [a clickable icon] clickable
`into an adapted version of the
`video, wherein
`the adapted
`version of the video is adapted to
`the displaying capabilities of the
`destination
`communication
`device
`
`6g
`
`determining, by the media block,
`an adapted message
`layout,
`comprising the clickable icon;
`and
`
`
`6f-2.
`
`Friedman: “discloses a ‘clickable
`icon’ in the form of a ‘[t]humbnail
`graphic 525.’”
`
`(Id. at 27)
`
`Friedman: “discloses a
`thumbnail
`graphic (525) based on a video
`attachment … from an electronic
`message.”
`
`(Id.)
`Coulombe: Coulombe
`adaptation
`engine enables the conversion of an
`initial message to an adapted message
`(see 6e) that is modified by 6f-1 and
`6f-2.
`
`Friedman: supplies the “generated
`[clickable] thumbnail graphic” and the
`association of the graphic to a video
`
`(Id. at 30)
`
`Bellordre: teaches adapting a video to
`display characteristics of destination
`device.
`
`(Id. at 29-30)
`Coulombe: “discloses ‘determining,
`by
`the media block, an adapted
`message layout.”
`
`(Id. at 32)
`
`Friedman: “discloses generating a
`‘clickable
`icon”
`in
`the
`form of
`thumbnail graphic 525.”
`
`- 11 -
`
`

`
`
`(Id. at 33)
`
`Bellordre: “discloses a technique in
`which a ‘representative image’ of a
`video … can be inserted into an
`adapted message layout.”
`
`(Id. at 33-34)
`Coulombe:
`Proxy/Registrar
`SIP
`transmits message to recipient.
`
`(Id. at 34)
`
`6h
`
`further
`is
`the access block
`configured to enable transmitting
`the adapted message
`to
`the
`destination device associated
`with the at least one receiver.
`
`(See Ex. 2107 [Surati] at ¶ 58.)
`
`The chart shows that four different combinations involving Coulombe,
`
`Bellordre and/or Friedman are required for limitations 6d, 6f-1, 6f-2, and 6g, with
`
`limitations 6f-2 and 6g requiring parts of all three references. With the above
`
`overview of the prior art references and combinations in mind, the relevant scopes
`
`of Coulombe, Friedman and Bellordre are provided below.
`
`2.
`
`Coulombe (Ex. 1103)
`
`The Coulombe reference “relates to interoperability between terminal
`
`devices using session initiation protocol (SIP) messages and, more particularly, to
`
`multimedia content adaption.” (Ex. 1103 [Coulombe] at ¶ 1.) As discussed in
`
`Coulombe, SIP supported communications based on a “session” as well as
`
`communications that were not session-based. (See, e.g., Ex. 1103 at ¶¶ 65, 67, 68.)
`
`The problem described in Coulombe and the solution it proposed relate to the
`
`- 12 -
`
`

`
`differences between those two types of communications. (See, e.g., id. at ¶¶ 64-
`
`70.)
`
`a)
`
`Session-based SIP communications
`
`The protocol for session-based SIP communications is described in RFC
`
`2543 (“SIP: Session Initiation Protocol,” IETF, March 1999) [Ex. 2103] (which is
`
`referenced at ¶ 56 of Coulombe). (Ex. 2107 [Surati] at ¶ 31.) Session-based SIP is
`
`described as:
`
`an application-layer control (signaling) protocol for creating, modifying
`and terminating sessions with one or more participants. These sessions
`include Internet multimedia conferences, Internet telephone calls and
`multimedia distribution….SIP invitations used to create sessions carry
`session descriptors which allow participants to agree on a set of
`compatible media types.
`
`(Ex. 2103 [RFC 2543] at abstract.) “Media types” include video. (Ex. 2107
`
`[Surati] at ¶ 31; see, e.g., Ex. 2103 [RFC 2543] at § B.1 (configuring media
`
`streams).) As the name implies, communications over SIP, as described in RFC
`
`2543, are session-based communications
`
`in which participants negotiate
`
`capabilities in advance of the communication. (Ex. 2107 [Surati] at ¶ 31; see Ex.
`
`2103 [RFC 2543] at § 1.1; see also Ex. 1103 [Coulombe] at ¶ 67 (“capability
`
`negotiation occurs between two clients during session establishment (using SDP
`
`(Session Description Protocol)”.)
`
`In a session-based communication, Coulombe notes that transcoding could
`
`be done for “multimedia sessions (audio or video calls) where codecs or the
`
`- 13 -
`
`

`
`bandwidths between users do not match.” (Ex. 1103 [Coulombe] at ¶ 69; Ex. 2107
`
`[Surati] at ¶ 32.) As Mr. Klausner explained at his deposition, codecs do not match
`
`when “the encoding of the streaming data from the sender is different than what
`
`the recipient can handle or manage.” (Ex. 2108 [Klausner Dep. Tr.] at 24:12-18.)
`
`In session-based communications in which codecs do not match, adaptation of the
`
`content can occur in SIP because “the proxy can use the information in the SDP
`
`file [described above] to “fill the gap” between the two terminals.” (Ex. 1103
`
`[Coulombe] at ¶ 69; Ex. 2107 [Surati] at ¶ 32.) As Mr. Klausner confirmed at his
`
`deposition, “fill in the gap,” means, for example, that when the sender delivers
`
`media encoded in one format and the recipient had a different capability, “the
`
`proxy could transcode it in order to deliver it in a form the recipient was capable of
`
`decoding.” (Ex. 2108 [Klausner Dep. Tr.] at 25:19-15.)
`
`b)
`
`Non-session-based SIP communications
`
`The only non-session-based SIP protocol in place as of Coulombe’s filing
`
`date was an instant messaging protocol. (Ex. 2107 [Surati] at ¶ 33.) The then-
`
`existing version of the protocol governing SIP instant messaging, “SIP Extensions
`
`for Instant Messaging” (also known as SIMPLE) [Ex. 2104] is referenced at ¶ 69
`
`of Coulombe. (Ex. 2107 [Surati] at ¶ 33.) The protocol defines SIP “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
`
`- 14 -
`
`

`
`case.” (Ex. 2104 at 3.) SIP instant messages “do not create any implied session”
`
`or have “any concept of call state.” (Ex. 2104 at 5.)
`
`The lack of a “session” for instant messages created a problem in that
`
`existing SIP functionality for adapting content for “session” communications could
`
`not be used for non-sessions communications. “In [session-based] SIP, capability
`
`negotiation occurs between two clients during session establishment ….” (Ex.
`
`1103 [Coulombe] at ¶ 67.) “Without a session, which is the case for SIP instant
`
`messaging, there [is] no means of knowing the capabilities of user preferences of
`
`the destination terminal.” (Id. (emphasis added).) Thus, as Coulombe observed,
`
`the protocol governing instant messaging makes “no mention of adaption
`
`functionality. It says that if a recipient does not support a certain format, it should
`
`return an error message … containing an Accept header listing the supported
`
`formats. This would tell the sender the valid formats to send.” (Id. at ¶ 69.) In
`
`short, instant messaging put the onus on the sender to deliver what the recipient
`
`could support. (Ex. 2107 [Surati] at ¶ 34.) Without the ability to know the
`
`capability of the recipient, it was not possible to “fill the gap.”
`
`c)
`
`The Coulombe solution
`
`Coulombe sets out the elements of a solution that he contends “are novel
`
`compared to present SIP-related specifications.” (Ex. 1103 [Coulombe] at ¶¶ 64-
`
`70.) As all of these paragraphs emphasize, the problem Coulombe was seeking to
`
`- 15 -
`
`

`
`solve relates to the capability negotiation differences within SIP between session-
`
`based and non-session-based communication. (Id.) To address the limitations of
`
`SIP instant messaging, Coulombe proposed “a method for capability negotiation
`
`regardless if the application is session-based or not.” (Id. at ¶ 68.)
`
`Coulombe’s framework for solving the limitations of SIP instant messaging
`
`framework “comprises three elements in combination: SIP proxy/registrar 12,
`
`Capability Negotiation Manager 16 and Message Adaptation Engine 20.” (Id. at ¶
`
`54.) The Capability Negotiation Manager 16 adds the missing piece so that non-
`
`session-based communications can also resolve capability differences in order for
`
`content to be adapted. (Id. at ¶ 59; Ex. 2107 [Surati] at ¶ 36.) Specifically, the
`
`“Capability Negotiation Manager” is responsible for “resolving terminal capability
`
`information,” and Coulombe describes several mechanisms to do so. (Ex. 1103
`
`[Coulombe] at ¶¶ 59 and 74-79.)
`
`d)
`
`Session-based SIP, video delivery and adaptation
`
`The Coulombe architecture
`
`incorporated existing session-based SIP
`
`capabilities. Indeed, its solution is described as enabling “[c]apabilities negotiation
`
`for session-oriented and non-session oriented applications” and “provid[ing] a
`
`method for capability negotiation regardless if the application is session-based or
`
`not.” (Ex. 1103 [Coulombe] at ¶¶ 65, 68.)
`
`The incorporation of existing session-based capabilities is also confirmed by
`
`- 16 -
`
`

`
`the fact that SIP proxy/registrar 12 is the SIP proxy specified in RFC 2543 (the SIP
`
`session-based protocol described above). (Ex. 2107 [Surati] at ¶ 38; Ex. 1103
`
`[Coulombe] at ¶ 56.) In fact, Coulombe explicitly states that SIP proxy/registrar
`
`12 “performs the operations required by a SIP proxy and registrar specified in RFC
`
`2543.” (Ex. 1103 [Coulombe] at ¶ 56.) In addition, Coulombe lists the Nokia
`
`Sofia proxy/registrar software as an exemplary proxy/registrar and explains that
`
`the foundational elements to perform the described framework were implemented
`
`as extensions to the existing proxy. (Id. at ¶¶ 92-93; Ex. 2107 [Surati] at ¶ 38.)
`
`Mr. Klausner admits
`
`that a POSITA would understand
`
`the SIP
`
`proxy/registrar 12 in Coulombe to “include all the functions set out in RFC 2543”
`
`including the “configuring media streams described at B1 of the RFC.” (Ex. 2108
`
`[Klausner Dep. Tr.] at 21:14-24.) In addition, Mr. Klausner admits that RFC 2543-
`
`compliant servers could process encoded video streams. (Id. at 21:25-22:6.)
`
`Further, as noted above, a POSITA would understand that Coulombe’s ability to
`
`“fill in the gap” for session-based communications means, for example, that media
`
`encoded in one format could be delivered to a recipient that had a different
`
`capability: “the proxy could transcode it in order to deliver it in a form the
`
`recipient was capable of decoding.” (Id. at 25:19-25.)
`
`In short, a POSITA would understand that Coulombe discloses the delivery
`
`of video streams between terminals and the adaptation of video streams between
`
`- 17 -
`
`

`
`terminals. (Ex. 2107 [Surati] at ¶¶ 37-39; Ex. 2108 [Klausner Dep. Tr.] at 21:25-
`
`22:6 and 25:19-25.)
`
`3.
`
`Friedman [Ex. 1105]
`
`Friedman, which
`
`is entitled “Systems and Methods for Processing
`
`Attachments Associated with Electronic Messages,” addresses an improved
`
`method for processing “attachments that are received through one or more message
`
`transport services….” (Ex. 2107 [Surati] at 40; Ex. 1105 [Friedman] at Abstract.)
`
`In particular, Friedman identifies various problems with existing email clients and
`
`proposes an improved electronic message client for managing, displaying and
`
`accessing email attachments received from various services. (Ex. 2107 [Surati] at
`
`40; Ex. 1105 [Friedman] at. 2:23-36.)
`
`- 18 -
`
`

`
`a)
`
`The prior art problem
`
`A description of prior art is set out at Figure 1, which is reproduced below:
`
`
`
`(Ex. 1105 at Fig. 1.) “In block 105, an email recipient operates program, such as
`
`Microsoft® Outlook®, to receive an email message that includes an attached file.”
`
`(Id. at 1:64-66.) The user can then save or open the attachment as shown in blocks
`
`110 and 120. (Id. at 1:67-2:2.) If a user decides to save it, “the recipient manually
`
`selects a ‘save’ option button from an options menu, followed by optionally
`
`specif