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-00717
`
`Patent 8,874,677 B2
`
`
`
`DECLARATION OF RAJEEV SURATI, Ph.D.
`
`
`
`1
`
`PATENT OWNER'S EXHIBIT 2007
`
`
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`WHATSAPP INC. and FACEBOOK, INC.
`
`Petitioner
`
`v.
`
`TRIPLAY, INC.
`
`Patent Owner
`
`____________
`
`IPR2016-00717
`
`Patent 8,874,677 B2
`
`
`
`DECLARATION OF RAJEEV SURATI, Ph.D.
`
`
`
`1
`
`PATENT OWNER'S EXHIBIT 2007
`
`
`
`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 the Exchange
`
`
`
`2
`
`
`
`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,
`
`
`
`3
`
`
`
`including: UnifySquare, which is a unified communications/realtime collaboration
`
`consultancy that focuses 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
`
`
`
`4
`
`
`
`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 Petition for Inter Partes Review of U.S. Patent No. 8,874,677, No.
`
`IPR2016-00717 (the “Petition”). I have also considered the exhibits to the Petition
`
`(Exs. 1001-1021), which include a Declaration of David Klausner, to Patent
`
`Owner’s Preliminary Response (Exs. 2003-2006, as well as my own Declaration,
`
`Ex. 2002), and Patent Owner’s additional exhibits related to the Patent Owner
`
`Response including the deposition of David Klausner (Exs. 2008-2009).
`
`III. OVERVIEW AND LEGAL STANDARDS
`
`14.
`
`I have been asked to consider the Petition and offer my opinion on
`
`whether claims 1, 2, 11, 13, 14, 16, 17, 20 and 21 are obvious over Coulombe [Ex.
`
`1003] in view of Bellordre [Ex. 1004] and Friedman [Ex. 1005]. I have also been
`
`asked to accept, for purposes of this declaration, the assertions in the Petition that
`
`claims 11, 16, and 17 are materially identical to claims 1, 14, and 2, respectively
`
`(Pet. at 32-34) and that claims 13, 20, and 21 are materially identical to claims 1,
`
`14, and 2, respectively (id. at 34-38). In view of my acceptance of these assertions,
`
`I have offered an opinion for claims 1, 14 and not provided a separate invalidity
`
`analysis for claims 11, 16, and 17 or claims 13, 20, and 21.
`
`15.
`
`I have been informed by counsel that claim terms are given their
`
`broadest reasonable construction that is consistent with the specification of the
`
`
`
`5
`
`
`
`patent in which it appears and the understanding of a person of ordinary skill in the
`
`art at the appropriate time.
`
`16.
`
`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 to a
`
`person having ordinary skill in the art.
`
`17.
`
`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.
`
`18.
`
`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
`
`
`
`6
`
`
`
`claimed invention does.
`
`19.
`
`I further understand that a prior art reference must be considered in its
`
`entirety, i.e., as a whole, including portions that would lead away from the claimed
`
`invention. Accordingly, I understand that it is improper to rely on isolated
`
`teachings of the prior art without considering the overall-context within which the
`
`teachings are presented. I have also been informed that the failure to consider the
`
`prior art references as a whole in assembling the elements of a claimed invention is
`
`indicative of impermissible hindsight.
`
`IV. SUMMARY OF U.S. PATENT NO. 8,874,677
`
`20. The ’677 patent “relates to [the] field of electronic messaging and to
`
`cross-platform messaging.” (Ex. 1001 [’677 patent] at 1:5-6.) In particular, the
`
`’677 patent recognizes the existence of cross-platform compatibility issues
`
`associated with electronic message “layout” and “format.” With respect to layout,
`
`“[t]he 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.)
`
`21.
`
` Fig. 2 (reproduced below), depicts certain elements of an exemplary
`
`“messaging system” that includes an “access block” 21 (highlighted blue) and
`
`
`
`7
`
`
`
`“media block” 23 (highlighted green):
`
`
`
`22. The “access block” 21 includes “a users’ gateway 211 and 3rd party
`
`applications’ gateway 214 supporting communication with communication devices
`
`and 3rd party 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 further optionally comprising a template module 51
`
`operatively coupled with the database 26.” (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.)
`
`
`
`8
`
`
`
`23. 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 also 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 whose delivery 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.)
`
`24. 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, when requested, an adapted version of the media item is
`
`“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
`
`
`
`9
`
`
`
`successful downloading,” “transmitted to the destination device with the help of
`
`streaming protocols, e.g., RTSP, RTP, etc.” (Id. at 14:4-10.)
`
`25. The links to the media items that are replaced as part of the
`
`repackaging decisions are further 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. (See, e.g., Ex. 2005 [Computer Desktop Encyclopedia, Version 18.3 (3rd
`
`Quarter 2005)] defining a “hyperlink” as a “link [which] 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 cell-phone 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 PC describes a “List of clickable media thumbnails.”
`
`(Ex. 1001 [’677 patent] at Col. 21, Table 2.) The clickable links/icons replacing
`
`the media are further shown in Figures 11 and 12, which show exemplary layouts
`
`for a cell-phone and PC respectively.
`
`
`
`10
`
`
`
`
`
`26. The ’677 patent contains no disclosure of the use of links for delivery
`
`of media other than in the context of a repackaging decision in which links are
`
`inserted in place of the media in the message.
`
`V. LEVEL OF ORDINARY SKILL IN THE ART
`
`27.
`
`It is my opinion that a person of ordinary skill in the art at the time of
`
`the invention of the ’677 patent (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.
`
`28. At the time of the invention of the ’677 patent, I was a person of more
`
`than ordinary skill in the art defined above based on my qualifications and
`
`experience. However, my opinions have been rendered based on the perspective of
`
`a person of ordinary skill in the art as of the time of the invention.
`
`
`
`11
`
`
`
`29.
`
`I have reviewed the Klausner Declaration [Ex. 1002] and note that his
`
`proposed level of ordinary skill in the art is similar to my own. Applying his
`
`proposed level of ordinary skill in the art would not alter my opinions as expressed
`
`herein.
`
`VI. THE SCOPE AND CONTENT OF THE PRIOR ART
`
`A. Coulombe [Ex. 1003]
`
`30. The Coulombe reference “relates to interoperability between terminal
`
`devices using session initiation protocol (SIP) messages and, more particularly, to
`
`multimedia content adaption.” (Ex. 1003 [Coulombe] at ¶ 1.) As discussed in
`
`Coulombe, SIP supported communications based on a “session” as well as those
`
`that were not session based. (See, e.g., Ex. 1003 at ¶¶ 65, 67 & 68.) The problem
`
`described in Coulombe, and the solution it proposed, relates to the differences
`
`between those two types of communications. (See, e.g., id. at ¶¶ 64-70.)
`
`31. The protocol for session-based SIP communications is described in
`
`RFC 2543 (“SIP: Session Initiation Protocol,” IETF, March 1999) [Ex. 2003]
`
`(which is referenced at ¶ 56 of Coulombe). 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.
`
`
`
`12
`
`
`
`(Ex. 2003 [RFC 2543] at abstract.) Media types include video. (See, e.g., Ex.
`
`2003 [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. (See Ex. 2003 [RFC 2543] at § 1.1; see also Ex. 1003
`
`[Coulombe] at ¶ 67 (“capability negotiation occurs between two clients during
`
`session establishment (using SDP (Session Description Protocol)”.)
`
`32.
`
`In a session-based communication, Coulombe notes that transcoding
`
`could be done for “multimedia sessions (audio or video calls) where codecs or the
`
`bandwidths between users do not match.” (Ex. 1003 [Coulombe] at ¶ 69.) 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. 2008 [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. 1003 [Coulombe] at ¶
`
`69.) Thus, 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. 2008 [Klausner Dep. Tr.]
`
`
`
`13
`
`
`
`at 25:19-15.)
`
`33. The only non-session based SIP protocol in place as of Coulombe’s
`
`filing date was an instant messaging protocol. The then-existing version of the
`
`protocol governing SIP instant messaging, “SIP Extensions for Instant Messaging”
`
`(also known as SIMPLE) [Ex. 2004] is referenced at ¶ 69 of Coulombe. 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 case.” (Ex. 2004 at 3.) SIP instant messages “do not
`
`create any implied session” or have “any concept of call state.” (Ex. 2004 at 5.)
`
`34. 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.
`
`1003 [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.)
`
`
`
`14
`
`
`
`Instant messaging placed the obligation on the sender to deliver what the recipient
`
`could support. Without the ability to know the capability of the recipient, it was
`
`not possible to “fill the gap.”
`
`35. At Paragraphs 64 to 70, Coulombe sets out the elements of a solution
`
`that he contends “are novel compared to present SIP-related specifications.” (Ex.
`
`1003 [Coulombe] at ¶¶ 64-70.) As all these paragraphs emphasize, the problem
`
`Coulombe was seeking to solve relates to the capability negotiation differences
`
`within SIP between session-based and non-session 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.)
`
`36. 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 so that content can be adapted. (Id. at ¶ 59.) Specifically,
`
`the “Capability Negotiation Manager” is responsible for “resolving terminal
`
`capability information” and Coulombe describes several mechanisms to do so.
`
`(Ex. 1003 [Coulombe] at ¶¶ 59 and 74-79.)
`
`
`
`15
`
`
`
`37. 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.” (Id. at ¶¶ 65 & 68.)
`
`38. The incorporation of existing session-based capabilities is also
`
`confirmed by the fact that SIP proxy/registrar 12 is the SIP proxy specified in RFC
`
`2543 (the SIP session-based protocol described above). (Id. 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.” (Id. 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)
`
`39. As Mr. Klausner admits, a POSITA would understand that the SIP
`
`proxy/registrar 12 in Coulombe would “include all the functions set out in RFC
`
`2543” including the “configuring media streams described at B1 of the RFC.” (Ex.
`
`2008 [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
`
`
`
`16
`
`
`
`“fill in the gap” for session-based communications meant, 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.)
`
`B.
`
`Friedman [Ex. 1005]
`
`40. Friedman
`
`is entitled “Systems and Methods
`
`for Processing
`
`Attachments Associated with Electronic Messages” and addresses an improved
`
`method for processing “attachments that are received through one or more message
`
`transport services….” (Ex. 1005 [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. (Id. at 2:23-36.).
`
`41. A description of prior art is set out at Fig. 1, which is reproduced
`
`below:
`
`
`
`17
`
`
`
`
`
`(Id. 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
`
`specifying a particular directory in which the attachment is saved.” (Id. at 2:2-6.)
`
`This step if shown at block 115. (Id. at Fig. 1.)
`
`42. However, “[i]f the recipient decides to open the attachment, as
`
`
`
`18
`
`
`
`determined in decision block 120, the recipient has to, typically, double-click on
`
`the attachment icon associated with the email in the Microsoft® Outlook® mail
`
`program illustrated in block 130).” (Id. at 2:7-11 & Fig. 1.) Then, “[i]f an
`
`association is already present, the appropriate application program is launched, and
`
`the contents of the attachment are displayed in the launched application program
`
`(block 135).” (Id. at 2:11-14 & Fig. 1.) For example, double-clicking on a
`
`Microsoft® Word document causes Microsoft® Word to launch and text will be
`
`displayed in a Microsoft® Word window. (Id. at 2:14-18.) Alternatively, as
`
`illustrated a block 25, a user can decide to look at the attachment at a later date.
`
`(Id. at 2:19-23 & Fig. 1.)
`
`43. The stated problem with the above is that “to access an attachment in
`
`a received email message, a recipient typically has to know that a button, icon, or
`
`other element, needs to be selected followed by numerous other steps that may be
`
`involved in opening the attachment.” (Id. at 2:27-30.) Per Friedman, while such
`
`“traditional methods may be adequate for knowledgeable or experienced users of
`
`electronic mail clients or programs, a more straightforward and less arcane
`
`management structure is desired.” (Id. at 2:30-34.) Accordingly, Friedman states
`
`that “a heretofore unaddressed need exists in the industry to address the
`
`aforementioned deficiencies and inadequacies.” (Id. at 2:34-36.)
`
`44. The basic operation of the improved messaging client is described in
`
`
`
`19
`
`
`
`Figures 5A and 5B and the accompanying text. In Block 305 of Fig. 5A, an
`
`electronic message including an attachment is received. (Id. at 7:60-8:2.) The
`
`attachments are referred to as “objects” and can include images, audio files and
`
`video files, as well as text files. (Id. at 8:2-12.) In Block 305, the processing
`
`system “automatically detaches and saves the contents of the object, partially or
`
`wholly, without any manual intervention on the part of the message recipient.” (Id.
`
`at 8:30-35.) This “automatic access is carried out irrespective of the type of
`
`electronic message transport or the type of the attachment.” (Id. at 8:36-38.) “In
`
`Block 315, a thumbnail graphic is generated for a portion of the object, for
`
`example, the first page of a text document.” (Id. at 8:59-60.) Elsewhere, Friedman
`
`depicts a thumbnail graphic 525 of a video file labeled “Riddick.mov.” (Id. at Fig.
`
`4 and 7:19-21)
`
`45.
`
` At Block 305, the various thumbnail graphics generated from
`
`received messages are displayed on the graphical user interface associated with the
`
`electronic messaging client. (Ex. 1005 [Friedman] at 9:7-9). Interface 500 of Fig.
`
`4 (depicted below) is an example of such an interface:
`
`
`
`20
`
`
`
`
`
`“Once the thumbnail graphic is displayed, the attachment is more easily operated
`
`on by the user….” (Ex. 1005 [Friedman] at 9:9-11.) For example, in Block 335,
`
`the user can “open the attachment [by] … double-clicking … the thumbnail
`
`graphic.” (Id. at 9:23-25.) In addition, in block 330, “the user can more easily
`
`carry out a move or a copy operation by acting upon the thumbnail graphic.” (Id.
`
`at 9:12-14.)
`
`46. Friedman notes that the claimed messaging client application for
`
`detaching and displaying thumbnail graphics can be “located in a client device, a
`
`server device or a combination thereof.” (Id. at 4:33-35.) It also states that Server
`
`235 may contain “network-related software and also network based software,
`
`which in certain instances may be downloaded into client devices.” (Id. at 4:20-
`
`22.) For example, “the user may download a web browser software or an e-mail
`
`
`
`21
`
`
`
`software program.” (Id. at 4:25-27.) Friedman also discloses that “software
`
`described in this disclosure may be resident in several elements of the network,
`
`whether they be client devices or servers.” (Id. at 4:27-30.)
`
`47. However, nothing in Friedman would suggest to a POSITA that the
`
`functioning of the improved email client operates any differently if it is resident on
`
`the server, a client or a combination of the two. Friedman does not disclose a
`
`messaging system. All the discussion in Friedman with respect to the improved
`
`processing of attachments refers to processing performed after the email client has
`
`received the message from the “transport service.” (See, e.g., id. at Abstract
`
`(“received through transport services”); 2:40-42 (“processing attachments that are
`
`received through one or more message transport services”); 2:45-46 (“an electronic
`
`message received through one of a plurality of message transport services”); 7:10-
`
`12 (“Display area 510 … shows multiple thumbnail graphics that were received via
`
`multiple message transport services”); 10:26-27 (“received through a plurality of
`
`message transport services”).) Examples of message transport services listed in
`
`Friedman are “email, IM and P2P.” (Id. at 9:50-51.)
`
`48. A POSITA would understand that a received email message can be
`
`accessed and processed in accordance with the Friedman application processing
`
`invention when the Friedman program resides on the server as long as the client
`
`has access to the server. The Friedman attachment process program functions the
`
`
`
`22
`
`
`
`same whether it is on a client or a server device. The only difference is where the
`
`program resides.
`
`C. Bellordre [Ex. 1004]
`
`49. Bellordre is entitled “Method of Processing a Multimedia Message, a
`
`Storage Medium, and an Associated Processing System” and describes a method of
`
`processing multimedia messages between telecommunication terminals. (Ex. 1004
`
`[Bellordre] at Abstract.)
`
`50.
`
`“The messaging processing system comprises a telecommunications
`
`terminal 2 of a party sending a multimedia message, a multimedia server 4, an
`
`application server 6, a streaming server 8, and a telecommunications terminal 10 of
`
`the recipient of the multimedia message sent by terminal 2.” (Id. at ¶ 42.) These
`
`various elements of the disclosed system are detailed at Fig. 1, which is reproduced
`
`below.
`
`
`
`
`
`23
`
`
`
`51. Fig. 2 of Bellordre details the method of the system. The described
`
`process begins with the multimedia message server 4 sending a multimedia
`
`message from terminal 2 to application server 6. (Id. at ¶ 82.) Then, if the
`
`recipient 10 is authorized to use the processing method of the invention,
`
`application server 6 will extract audio or video objects to be sent in streaming
`
`mode. (Id. at ¶¶ 89-90.)
`
`52. The application server 6 will also adapt the audio or video objects, if
`
`necessary. (Id. at ¶ 93.) This adaptation is done by audio-visual processing
`
`module (AVPM) 40. (Id.) AVPM searches the storage for the technical features
`
`54 of terminal and modifies them to the technical features of the terminal 10. (Id.
`
`at ¶ 61.) After completion of the adaptation, AVPM 40 sense the processed audio
`
`or video object to the streaming server 8. (Id. at ¶ 62.)
`
`53. At the streaming server 8, an SDP definition file containing the
`
`address of the storage location for the audio or video object is created and sent to
`
`application server 6. (Id. at ¶¶ 98-99.) After receipt, the application server 6
`
`substitutes the SDP definition file for the video or audio object that was previously
`
`extracted. (Id. at ¶ 101.) Then, after additional processing at the application server
`
`6, the substitute message is sent to multimedia server 4, which then communicates
`
`the substituted message to the terminal 10 receiving the message. (Id. at ¶¶ 105-
`
`106.) Finally, when the terminal receives the substitute message, the terminal
`
`
`
`24
`
`
`
`makes a request for the audio or video object and server 8 sends the audio or video
`
`object to the terminal 10 using the downloading mode (progressive downloading or
`
`streaming) appropriate to the sampling of the audio visual content. (Id. at ¶¶ 107-
`
`109.)
`
`VII. VALIDITY ANALYSIS
`
`54.
`
`It is my opinion that the Petitioner has failed to prove by a
`
`preponderance of the evidence that a POSITA would have been motivated
`
`motivate to combine Coulombe, Bellordre and Friedman to render claims 6, 7
`
`and15 obvious.
`
`55.
`
`Instead, it is my opinion that the Petitioner has simply selected bits
`
`and pieces of these prior references to fit the challenged claim language, without
`
`considering each reference as a whole or offering any reasoning that would have
`
`prompted a POSITA to consider the proposed combination in the first place.
`
`56.
`
`I understand it is considered impermissible hindsight to use the claims
`
`as a guide for invalidity. It is my opinion that, without the claims as a guide, a
`
`POSITA would not have known what pieces of the references to select, what
`
`pieces of the references to ignore, or how to modify and put together the pieces
`
`selected to arrive at the claimed invention.
`
`57. Claim 1 is an independent claim. Claim 14 depends from claim 1 and
`
`claim 2 also depends from claim 1. As set forth below, the Petition has failed to
`
`
`
`25
`
`
`
`provide a motivation for the combination. In addition, because claims 14 and 2
`
`depend from claim 1, it is my opinion that the Petition does not set forth a claim of
`
`obviousness for claims 14 and 2.
`
`58. Before I go through the combinations and motivations for each
`
`limitation, it is useful to look first at claim 1 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 1. A chart showing that is set for the below:
`
`Summary Chart Of Petition’s Claim 1
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
