Paper No. 24
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`SNAP INC.,
`Petitioner
`
`v.
`
`VAPORSTREAM, INC.,
`Patent Owner
`
`
` ___________________________________________________
`
`Case IPR2018-00312
`Patent 9,306,885 B2
` ___________________________________________________
`
`PATENT OWNER’S RESPONSE UNDER 37 C.F.R. § 42.120
`
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`TABLE OF CONTENTS
`
`
`I. INTRODUCTION ............................................................................................... 1
`II. OVERVIEW OF THE ’885 PATENT ................................................................ 4
`III. OVERVIEW OF PETITIONER’S REFERENCES ........................................... 9
`A. Namias (Grounds 1 and 2) .............................................................................. 9
`B. PC Magazine (Grounds 1 and 2) .................................................................. 12
`
`C. Saffer (Ground 1) ......................................................................................... 13
`D. Smith (Ground 1) .......................................................................................... 18
`E. RFC 2821 (Ground 2) ................................................................................... 19
`F. Hazel (Ground 2) .......................................................................................... 21
`IV. CLAIM CONSTRUCTION ......................................................................... 22
`A. Message Content Including a Media Component ........................................ 22
`B. Correlation .................................................................................................... 25
`V. THE PETITION FAILS TO ESTABLISH THAT THE CHALLENGED
`CLAIMS ARE UNPATENTABLE ................................................................... 26
`A. Petitioner’s Ground 1 References Do Not Render Obvious the Challenged
`Claims ........................................................................................................... 26
`1. Petitioner Has Not Provided An Apparent Reason To Combine The
`References ............................................................................................... 26
`2. Petitioner Has Not Considered The References As A Whole, But Has
`Cherry-Picked Certain Aspects Using Improper Hindsight. ................... 31
`3. The Ground 1 Combination Fails to Teach or Suggest
`Separate Transmissions ........................................................................... 39
`4. Claim 1 Separately Requires that the Message Content Must be
`Transmitted from the Sender Separately From the Header Information. 45
`
`
`
`i
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`5. The Ground 1 Combination Fails to Teach or Suggest
`Separate Displays. ................................................................................... 47
`B. Petitioner’s Ground 2 References Do Not Render Obvious
`the Challenged Claims .................................................................................. 50
`1. The Ground 2 Combination Fails to Teach or Suggest a Correlation. .... 50
`2. The Ground 2 Combination Fails to Teach or Suggest Separate
`Transmissions. ......................................................................................... 52
`a. Petitioner Misconstrues SMTP to Argue Message Content Is Sent
`Separately From a Recipient Address ................................................ 53
`b. Petitioner’s Fall-Back Position Relies on Improper Hindsight .......... 57
`VI. CONCLUSION ............................................................................................ 63
`
`
`
`
`
`
`
`ii
`
`

`

`TABLE OF AUTHORITIES
`
`Case IPR2018-00312
`Patent 9,306,885
`
`
`
`
`
`Cases
`Aqua Prods., Inc. v. Matal,
`872 F.3d 1290 (Fed. Cir. 2017) ........................................................................... 24
`CFMT, Inc. v. Yieldup Int’l Corp.,
`349 F.3d 1333 (Fed. Cir. 2003) ........................................................................... 39
`Genzyme Therapeutic Prods. Ltd. Partnership v. Biomarin Pharm. Inc.,
`825 F.3d 1360 (Fed. Cir. 2016) ..................................................................... 22, 23
`
`In re Cortright,
`165 F.3d 1353 (Fed. Cir. 1999) ........................................................................... 23
`
`In re Mouttet,
`686 F.3d 1322 (Fed. Cir. 2012) ........................................................................... 38
`In re NTP, Inc.,
`654 F.3d 1279 (Fed. Cir. 2011) ........................................................................... 23
`In re Nuvasive, Inc.
` 842 F.3d 1376 (Fed. Cir. 2016) .......................................................................... 61
`In re Rothermel,
`276 F.2d 393 (CCPA 1960) ................................................................................. 32
`In re Wesslau,
`353 F.2d 238 (C.C.P.A.1965) .............................................................................. 32
`InTouch Techs., Inc. v. VGO Communications, Inc.
`751 F.3d 1327 (Fed. Cir. 2014) ........................................................................... 61
`Knowles Elecs. LLC v. Iancu,
`886 F.3d 1369 (Fed. Cir. 2018) ........................................................................... 22
`KSR Int'l Co. v. Teleflex Inc.
`550 U.S. 398 (2007) ............................................................................ 4, 27, 58, 61
`Microsoft Corp. v. Proxyconn, Inc.,
`789 F.3d 1292 (Fed. Cir. 2016) ........................................................................... 23
`
`
`
`iii
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`Panduit Corp. v. Dennison Mfg. Co.,
`810 F.2d 1561 (Fed. Cir. 1987) ..................................................................... 32, 63
`Pers. Web Techs., LLC v. Apple, Inc.,
`848 F.3d 987 (Fed. Cir. 2017) ....................................................................... 34, 61
`
`Polaris Industries, Inc. v. Arctic Cat, Inc.,
`2018 WL 797462 (Fed. Cir. 2018) ...................................................................... 34
`Other Authorities
`35 U.S.C. § 316(e) .................................................................................................. 26
`
`
`
`iv
`
`

`

`LIST OF EXHIBITS
`
`Case IPR2018-003 12
`
`Patent 9,306,885
`
`Exhibit 2001
`
`Declaration of Michael Shamos, PhD. in Opposition to
`Petition for Inter Partes Review of United States Patent No-
`
`9,306,885
`
`Claim Construction Order from Vaporstream, Inc. v. Snap
`Inc., No. 2:17-cv-00220-MLH (CD. Cal. Feb. 27, 2018)
`
`Syntax
`
`Exhibit 2009
`
`Declaration of Dr- Kevin Almeroth in Support of Patent
`Owner’s Response for US. Patent No. 9,306,885
`
`Exhibit 2012
`
`Deposition of Dr- Sandeep Chatterjee
`
`Exhibit 2017
`
`RFC 2396, Uniform Resource Identifiers (URI): Generic
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`I.
`
`INTRODUCTION
`Patent Owner VaporStream, Inc. (“VaporStream”) respectfully opposes
`
`Petitioner Snap, Inc.’s (“Snap”) contentions asserted in its Inter Partes Review
`
`(“IPR”) Petition that US Patent No. 9,306,885 claims 1 and 6 (“the Challenged
`
`Claims”) would have been obvious. See Paper No. 2 (“Petition”). As explained in
`
`detail below, the Challenged Claims are not invalid in light of the cited references,
`
`and the patentability of the claims should be confirmed.
`
`All Challenged Claims depend from ’885 claim 1. First, claim 1 requires
`
`that the identifier of a recipient and the message content including a media
`
`component is not displayed at the same time to the sending user. Ex. 1001 (’885
`
`Patent) at 18:65-19:11. The fact that the recipient identifier and the message
`
`content are not displayed together helps prevent a single screen capture from
`
`obtaining both the recipient identifier and the message content. This eliminates the
`
`possibility that a single screen capture or Print Screen will allow a hacker to obtain
`
`critical header information (e.g., the recipient identifier) together with the media
`
`component. See id. at 9:13-22. Second, claim 1 requires transmitting message
`
`content separately from header information identifying the message recipient. Id. at
`
`19:16-19. Separately transmitting the two components of the electronic message
`
`provides reduced traceability because it reduces the possibility of a hacker
`
`intercepting both components. Id. at 9:22-28, 12:8-12. Third, claim 1 requires a
`
`
`
`1
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`correlation to allow the identifier of a recipient and the message content including
`
`a media component to be related to each other at a later time by the server
`
`computer. Id. at 19:20-24.
`
`Petitioner does not identify any references that, when properly combined,
`
`separately display and transmit a recipient identifier and message content including
`
`a media component. Nor are any of the references concerned with the problem of
`
`preventing capture of both a recipient identifier and message content during the
`
`generation, transmission, and storage of an email message. As a result, Petitioner
`
`must use hindsight to cherry-pick from many different references in an attempt to
`
`arrive at the invention of claim 1.
`
`The Petition alleges two grounds of invalidity based on obviousness under
`
`35 U.S.C. § 103. Specifically, Petitioner alleges that the following four-reference
`
`combination renders the Challenged Claims obvious under Ground 1: (1) U.S.
`
`Patent Application Publication No. 2002/0112005 A1 to Namias (Ex. 1003,
`
`“Namias”); (2) Neil J. Rubenking, Disabling Print Screen (from PC Magazine)
`
`(Ex. 1033, “PC Magazine”); (3) U.S. Patent Application Publication No.
`
`2003/0122922 A1 to Saffer et. al. (Ex. 1004, “Saffer”); and (4) U.S. Patent No.
`
`6,192,407 to Smith et al. (Ex. 1005, “Smith”). And in Ground 2, Petitioner resorts
`
`to a different four-reference combination to argue that the Challenged Claims are
`
`obvious: (1) Namias; (2) PC Magazine; (3) J. Klensin, RFC 2821: Simple Mail
`
`
`
`2
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`Transfer Protocol (Ex. 1008, “RFC 2821”); and (4) Philip Hazel, Exim: The Mail
`
`Transfer Agent (Ex. 1011, “Hazel”).
`
`The Petition is fatally flawed for at least two reasons. First, there is no
`
`apparent reason a person of ordinary skill in the art would be motivated to combine
`
`the particular teachings proposed by Petitioner in the manner claimed, especially
`
`given that the prior art references fail to recognize the problem identified in the
`
`’885 Patent of preventing the capture of both recipient identifier and message
`
`content during the generation, transmission, and storage of an electronic message.
`
`Petitioner asks the Board to conclude a person of ordinary skill would start with a
`
`public kiosk used for sending video messages (Namias) and then modify that
`
`public kiosk according to certain selective teachings from various references on
`
`disparate email clients and protocols (PC Magazine, Saffer, Smith, RFC 2821,
`
`Hazel). Such a combination is illogical when the prior art references are considered
`
`as a whole. Petitioner’s complex concoction of prior art teachings from multiple
`
`unrelated references only makes it more apparent that the invention of the
`
`Challenged Claims would not have been obvious to a skilled artisan in 2005.
`
`When the entire teachings of the references are properly considered, it is
`
`apparent that the prior art selected for the Petition, and the proposed combination
`
`set forth therein, could only have been arrived at through hindsight reconstruction
`
`of the Challenged Claims, without regard to how the references relate to one
`
`
`
`3
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`another, and not on the basis of the teachings and suggestions of the prior art as
`
`required by KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398, 418, 421 (2007) (noting
`
`the “distortion caused by hindsight bias” and that a “patent composed of several
`
`elements is not proved obvious merely by demonstrating that each of its elements
`
`was . . . known in the prior art”).
`
`Second, even when the references are combined as suggested by Petitioner,
`
`they fail to disclose or render obvious multiple claim limitations found in all
`
`Challenged Claims, including: (1) separate transmissions; (2) separate displays;
`
`and (3) a correlation between a recipient identifier and message content.
`
`Because Petitioner has failed to meet its burden of showing the claimed
`
`inventions would have been obvious, the Board should confirm their patentability.
`
`II. OVERVIEW OF THE ’885 PATENT
`The ’885 Patent discloses systems and methods for reducing traceability of
`
`electronic messages. See, e.g., Ex. 1001 (’885 Patent) at Abstract. “Traceability”
`
`refers to the ability to correlate the content of a message with header information
`
`(e.g., the identity of the party to whom it is addressed—the recipient). The ’885
`
`Patent addresses concerns raised by the possibility that the electronic message may
`
`be subject to “[s]urreptitious logging” or interception by unauthorized third parties
`
`who have gained access to the computer of the sender or recipient of the message.
`
`Id. at 2:15-18. Electronic messages may also be “archived” and “copied, cut,
`
`
`
`4
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`pasted, printed, forwarded, blind copied, or otherwise manipulated,” which “may
`
`give a message a ‘shelf-life’ that is often uncontrollable by the sender or even the
`
`recipient.” Id. at 2:7-14.
`
`An electronic message includes header information and message content. Id.
`
`at 3:60-4:18, 7:5-8:3; Ex. 2009 (Almeroth Dec.) at ¶48. Header information may
`
`include the identity of a sender or recipient of an electronic message, or a date/time
`
`associated with the message (e.g., when the message was created or received). Ex.
`
`1001 at 12:66-13:5, 7:7-49; Ex. 2009 at ¶48. In contrast, the content of a message
`
`refers to the body of the message forwarded to the recipient. This content may
`
`include various types of media content, including media components such as
`
`images, video, or audio. Ex. 1001 at 7:52-60; Ex. 2009 at ¶48. The media
`
`component may be embedded in the electronic message or may be attached or
`
`linked as a file. Ex. 1001 at 7:60-63; Ex. 2009 at ¶48.
`
`To address traceability concerns, the patent provides separate displays to
`
`visibly separate the message header and message content. Ex. 1001 at Abstract.
`
`“[S]eparate display of header information and message content prevents a single
`
`screen capture at a user computer from creating a complete record of the electronic
`
`message.” Id. at 18:6-9.
`
`Figures 8 and 9 of the ’885 Patent illustrate the “send side” of the preferred
`
`embodiment with separate displays to prevent capturing recipient identifiers and
`
`
`
`5
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`content information together in a single screen shot or print screen. In particular,
`
`Figure 8 shows an Inbox of a user that “includes a first portion 805 for entering a
`
`recipient address or other identifier for one or more recipients of a message.” Id. at
`
`11:43-45; Ex. 2009 at ¶50.
`
`
`
`After the user enters the recipient address, a message content screen is
`
`displayed to the sending user, as shown below in Figure 9. Ex. 1001 at 11:54-59,
`
`Figure 5 (steps 510, 515). Figure 9 shows an example message content display
`
`screen 900 that “includes a first portion 910 for inputting (step 515 of FIG. 5) a
`
`message content corresponding to the recipient address input at portion 805 of FIG.
`
`8.” Id. at 11:56-59; Ex. 2009 at ¶50. As shown in Figure 9, the message content in
`
`this example consists of the text message, “This is my first message to you.”
`
`
`
`
`
`6
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`
`
`To allow the header information and message content to be handled
`
`separately, “a correlation (e.g., a non-identifying message ID . . .) may be utilized
`
`to associate the two components.” Ex. 1001 at 7:1-3; Ex. 2009 at ¶51. The system
`
`of the ’885 Patent can correlate header information and message content so that it
`
`can store, transmit, and display header information and message content of a
`
`particular electronic message separately with the ability to subsequently correlate
`
`the two. Id. at 8:16-20. This correlation supports separate transmission and
`
`reception of header information and message content. Ex. 2009 at ¶51.
`
`Electronic messages may be transmitted from a sending device to a recipient
`
`through one or more server computers. Ex. 1001 at 4:50-54. The server 100
`
`receives and stores the electronic messages it receives from a sending device. Id. at
`
`
`
`7
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`Figure 1, 6:47-50. The server may “store[] . . . header information and message
`
`content separate from each other to minimize correlation by a third party between
`
`identifying information regarding the electronic message (e.g., identification of
`
`sender, recipient, date/time of message, location of message) in the header
`
`information and the content of the message.” Id. at 6:57-65. In that instance, a
`
`“correlation” is used to associate the header with the content. Id. at 7:2-4. The ’885
`
`specification explains that the correlation may be “a unique 128 bit, randomly
`
`generated number” that is separately stored with each of the header information
`
`and the content. Id. at 8:8-12; Ex. 2009 at ¶52. Thereafter, the system may use a
`
`“database” or a “lookup table” to correlate the separately stored data “at a later
`
`time.” Ex. 1001 at 8:12-20.
`
`An example configuration of a server system 100 is depicted in Figure 1:
`
`
`
`8
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`
`
`III. OVERVIEW OF PETITIONER’S REFERENCES
`A. Namias (Grounds 1 and 2)
`Namias is directed to an interactive video email kiosk for “creating and
`
`sending video email messages such as full motion videos and still snapshots.” Ex.
`
`1003 (Namias) at Abstract. Any user in the vicinity of the kiosk can create a video
`
`
`
`9
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`or photograph and email the result to one or more recipient email addresses for a
`
`fee.
`
`Figure 1 shows a block diagram of the Namias video email kiosk 100. Id. at
`
`[0031]. “The video e-mail kiosk 100 comprises a digital processor 110, a touch-
`
`sensitive screen monitor 120, a digital video camera 130, a microphone 140, audio
`
`speakers 150, a credit card acceptor 160, a cash acceptor 170, and a digital network
`
`communications link 180. Preferably, the digital network communications link 180
`
`is an Internet connection.” Id.
`
`
`
`Figures 2-7 of Namias consist of a sequence of screen displays 200, 300,
`
`400, 450, 500, 600, and 700 that the video email kiosk 100 displays on its touch-
`
`sensitive screen monitor 120 to guide a user through the generation of the video
`
`message. Id. at [0023-29, 0034-42]. The sequence starts with screen display 200,
`
`
`
`10
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`which is displayed when the video kiosk is idle and attempting to entice someone
`
`to use the kiosk to record and send a video or photo to a third party. Id. The
`
`sequence then proceeds through screen displays that allow a customer of the kiosk
`
`to create (displays 300, 400, 450), email (display 500), and pay (display 600) for a
`
`video or still snapshot email message. Id. It ends with screen display 700 that the
`
`kiosk displays after the user has completed a video creation and sending session.
`
`Id.
`
`Figures 8A to 8D contain a flowchart 800 illustrating how video email kiosk
`
`100 changes between screen displays 200, 300, 400, 450, 500, 600, and 700. Id. at
`
`[0043-69]. Namias does not disclose that the header information and message
`
`content are sent separately from the kiosk, and it certainly does not suggest any
`
`hardware or software
`
`that would support separately
`
`transmitting header
`
`information from the video or snapshot content. Ex. 2009 at ¶¶59-60. Namias is
`
`not directed to reduced traceability and never addresses preventing a single screen
`
`capture from obtaining critical header information and transmitted media content.
`
`Id.
`
`
`
`11
`
`

`

`B.
`PC Magazine (Grounds 1 and 2)
`PC Magazine is an article teaching how to disable the Print Screen (“PrtSc”)
`
`Case IPR2018-00312
`Patent 9,306,885
`
`key on a computer running the DOS operating system.1 More specifically, the
`
`article takes advantage of a quirk in the Microsoft DOS operating system to trick it
`
`into believing that the PrtSc key had already been depressed (thereby effectively
`
`disabling it):
`
`DOS uses a flag in low memory to show that the PrtSc interrupt is
`active. That keeps you from accidentally calling it again before it’s
`finished. If you set that flag to say that screen printing is happening,
`the PrtSc key will do nothing.
`
`Ex. 1033 (PC Magazine) at 450. This programming trick will not work for other
`
`operating systems, such as Windows or Linux. Ex. 2009 at ¶61.
`
`PC Magazine does not disclose any connection between disabling the PrtSc
`
`key and reducing the traceability of electronic messages. Id. at ¶62.
`
`
`1 When the PrtSc key and the SHIFT key are simultaneously pressed on a
`
`keyboard, the computer either: (i) prints the screen currently being displayed (if a
`
`printer is attached to the PC); or (ii) saves the screen currently being displayed to
`
`the user’s clipboard (from which it may be stored, printed or pasted into an
`
`application). Ex. 2009 at ¶61, n1.
`
`
`
`12
`
`

`

`C.
`Saffer (Ground 1)
`Saffer discloses a system in which a user sends email messages that include
`
`Case IPR2018-00312
`Patent 9,306,885
`
`video and audio along with text messages to an email recipient. Ex. 1004 (Saffer)
`
`at [0003]. Saffer’s video email system is “configured to operate with pre-existing
`
`email application codes and pre-existing video camera support applications without
`
`invading the basic system codes of either.” Id at [0002]. Figure 1 of Saffer,
`
`reproduced below, illustrates the arrangement of client computers and the
`
`associated network servers required to implement the Saffer system. Id. at [0007].
`
`The system includes a sender’s computer 10, a recipient’s computer 12, a
`
`sender’s email server 14, a recipient’s email server 15, a video server 16, and a
`
`
`
`
`
`13
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`conventional Windows Media Server 18. Id. at [0017]. The sender’s computer 10
`
`includes a video camera 20 and camera control software that communicates with
`
`pre-existing video camera support application(s) residing on the sender’s
`
`computer. Id. at [0018]. The email server 14 includes software that creates email
`
`compose page code “without invading the basic system code of the pre-existing e-
`
`mail application software.” Id. Because Saffer does not invade the basic email
`
`application software code implemented in the client computers and email servers,
`
`Saffer’s email composition screens and transmit methodology are necessarily tied
`
`to conventional email application software, which are integral to the user’s ability
`
`to create and transmit video emails in the Saffer system. Ex. 2009 at ¶64.
`
`Annotated Figure 6 of Saffer, reproduced below, illustrates an email
`
`composition screen displayed on the sender’s computer. Id. at [0012].
`
`
`
`14
`
`

`

`Recuplent Address
`
`JVcbldc: You Mm..- mun Munro Q- Mr'n'ml Inlet?" [0996--m7..-
`t|mwy~¢mp¢vmm
`'
`
`Case IPR2018-00312
`
`Patent 9,306,885
`
`Message content including
`
`a media component
`
`___,-
`...W-.
`My Mun Me'W‘ho—un--'
`-._,
`,
`
`....._~-«
`
`- “.142
`a 5_*_".".-‘I?l
`3 than
`Ai‘l'sm I
`
`Sane“ ngwV-dooEn-al
`
`MZoom wn‘ "chug-7
`Anny... 'W- '1-
`~69
`68
`; u _
`,__,_ __T _ , _,,_._____._.,,- 'fi’T’Y‘t — n~‘-“
`. ¢ -....;--.~_..-d.
`‘ Iomklnrmnt(l)va .
`“anoint. mouMousa~_.r-‘..z..¢c- “Lei- ., _‘
`Message content entry box m_
`
`This composition screen includes “conventional e—mail composition elements.” Id.
`
`at [0024]. Thus, Saffer’s composition screen includes, among other things, a “To:”
`
`field 36, into which a sender inputs one or more recipient addresses for one or
`
`more desired recipients, a “Text Composition” window 44 for inputting message
`
`content, and a “Send” button 50.
`
`In addition to these “conventional” email
`
`elements, Saffer also provides a graphical interface 59 on the composition screen
`
`that includes a window 60 for displaying a video, together with associated control
`
`buttons 66, 68, and 70 that allow the sender to record or edit that video prior to
`
`15
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`sending it as part of an email message. Ex. 1004 at [0024-25]. When the sender
`
`activates the Send button 50, “the camera control software will compress the
`
`recorded media, upload the compressed media to the video server, and retrieve a
`
`video ID from the video server for this uploaded media.” Id. at [0027]. In addition,
`
`“the compose screen code will grab the video ID retrieved from the video server
`
`and insert the video ID along with a URL or link to the video server into the code
`
`and/or text of the email message that will be sent by the sender’s computer 10 to
`
`the e-mail server 14.” Id. Thus, Saffer teaches substituting the recorded or edited
`
`video that previously appeared on the sender’s composition screen with a URL
`
`provided by the video server. The URL identifies the publicly-accessible address
`
`of the video server together with the file name extension (or video ID) of the
`
`particular video that is being sent. Ex. 2009 at ¶67.
`
`An annotated version of Saffer’s Figure 7 is shown below with the URL in
`
`the message screen and the recorded/edited video in the video window.
`
`Specifically, Figure 7 illustrates the composition window containing the code 80
`
`that provides “a hypertext link in the recipient’s email message … to the location
`
`of the media on the video server 16, where the URL defined in this code 80
`
`includes the video ID 82 (in this case ‘jxvTSgpc’) and also the sender’s ID (in this
`
`case ‘ztvideoemail’).” Ex. 2004 at [0028]; Ex. 2009 at ¶68. The recipient’s address,
`
`the video window, and the URL pointing to the storage location of that video are
`
`
`
`16
`
`

`

`shown in Figure 7 of Safler:
`
`Recipient Address
`
`.3wuao. Vou- Mnuou us".- 'wu‘nm warm. Illuuuuwu'o'J-«dfi‘h I Via-moi .
`.. “0.-.... _
`MM La “- I'm:- in u»
`‘
`“yon-aw grasmm'miuuflmn-‘ggwljg
`.IMHvl'iWIMIAMlq-vlmml ; _...t....._.
`.4“.
`
` m
`
`‘lZoomigwn,
`
`.
`
`-- ..-' .4
`
`Case IPR2018-00312
`
`Patent 9,306,885
`
`Message content including
`
`a media component
`'51. ‘2‘, l»:57. ' ____/:-':.}'. " 151wa
`'
`,_ -.—~——r- "nl
`
`" C0929?
`
`la
`
`oloayorfi‘ommunulmm
`
`-
`
`‘ fed-9:090“
`
`sou,“ Ixnewumwmmmm
`
`,,
`
`..
`
`v
`
`l
`
`u i,
`r' M! Shown-'0
`
`bar—”fl“—
`1 541000116!» Monaco
`
`0v loo-:You‘ Vldvrn Hint.
`~1 can".
`
`.
`I-ruet- Dinnlnnullcr PrrlsIb-«Icv at «u-
`_
`I
`'I
`2
`l v mo -ou'
`‘
`“u i : Kl:
`I. v -‘
`I
`-
`~
`..
`
`t
`
`
`
`— ‘I'
`
`i
`. Mlmrown’l‘dcatwui
`Apucadlaw—oJ-
`
`_ \
`
`'L-o- Hr“.
`H
`.7". v .
`., .5.““a
`‘ Howe;- 'la Ofittkmfifi.
`‘9 -‘\«
`rnMAAuum-ou Illun‘ -
`Message content entry box
`
`-
`
`”mf—$QQ8'J94.0.99 Ear:
`
`FIG.7
`
`Thus, Figure 7 shows the display of a sending user that includes both (1) the
`
`header information with the recipient address(es) and (2) message content—
`
`including both text messages (with the URL) and any associated video content. Ex.
`
`1004 at [0028]; Ex. 2009 at 1168. That email message, containing both the recipient
`
`address and message content in the form of the video that is publicly-accessible via
`
`the URL, is then transmitted from the sending user’s computer to the email server.
`
`17
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`Ex. 1004 at [0027]. Thus, Saffer is not directed to reduced traceability, as any third
`
`party with access to the sender’s composition screen shown in Figure 7 of Saffer
`
`has everything it needs to reconstruct both the recipient’s address and the message
`
`content (including the video content). Ex. 2009 at ¶69.
`
`D.
`Smith (Ground 1)
`Smith is directed to a document delivery system that operates in a push
`
`fashion and allows receipt tracking for a set of delivered documents to a potentially
`
`large number of recipients. Ex. 1005 (Smith) at 2:9-12, Abstract. Smith, therefore,
`
`is addressed to a significantly different problem than that solved by the ’885
`
`Patent. Specifically, Smith is concerned with the need for enhanced trackability
`
`(e.g., proof of receipt) in large email distribution systems, while the ’885 Patent
`
`provides a system that implements reduced trackability (traceability) in messages
`
`between a sender and a recipient. Ex. 2009 at ¶70.
`
`Smith notes deficiencies of conventional email systems that typically are
`
`used to transmit unsecured files to a small number of users from a single user. Ex.
`
`1005 at 1:55-60. Smith also notes that conventional email systems lack the ability
`
`to allow for controlled automated distribution to multiple recipients, without
`
`advanced accounting capabilities and receipt acknowledgement. Id. at 1:55-63. To
`
`overcome the noted deficiencies, the Smith system stores documents (referred to as
`
`“binary files”) in a store 42 of a binary file server 12. Id. at 3:37-38; 4:16-37. In
`
`
`
`18
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`response to a user transmitting a set of documents and a list of intended recipients,
`
`the Smith system generates a private URL (referred to as “PURL”) that identifies
`
`both the intended recipient of a document and the documents to be delivered. Id. at
`
`2:23-30; 12:54-13:18; 15:28-41. The server then sends an email message to each
`
`intended recipient that contains a private URL. Id. at 15:9-16. The PURL allows
`
`the recipient to retrieve the set of documents from the store server, while allowing
`
`the system to track a user’s accessing those documents. Id. at 16:21-38.
`
`In the Smith system, “[d]ocuments can be delivered to any recipient 22 who
`
`has an E-mail account and access to the Internet, regardless of the recipient’s
`
`platform or E-mail system.” Id. at 11:21-24. The Smith system sends an email
`
`containing a PURL to a recipient, and the recipient uses the PURL to access the
`
`corresponding documents via hypertext transfer protocol (HTTP) delivery. Id. at
`
`14:55-15:27. “By combining HTTP for the [document] delivery, as well as using
`
`SMTP/e-mail for notification [e.g., via PURL delivery] it is possible to build a
`
`solution that allows the [document] producer to be the driver, or to push, but which
`
`does not suffer from the limitations and legacy issues associated with SMTP/e-
`
`mail.” Id. at 15:4-8; Ex. 2009 at ¶¶71-72.
`
`E. RFC 2821 (Ground 2)
`RFC 2821 is a paper from the Network Working Group of The Internet
`
`Society setting forth a standard protocol for transmitting email, commonly known
`
`
`
`19
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`as the Simple Mail Transfer Protocol (“SMTP”). Ex. 2009 at ¶73. When a SMTP
`
`client has a message to transmit, it establishes a two-way connection with a client
`
`SMTP server. Ex. 1008 (RFC 2821) at 5; Ex. 2009 at ¶73. Once the connection is
`
`established, the client transmits three commands to the server: (1) MAIL, (2)
`
`RCPT, and (3) DATA. Ex. 1008 at 16-17; Ex. 2009 at ¶73. The MAIL command
`
`identifies the sender. Ex. 1008 at 16. The RCPT command identifies the recipient.
`
`Id. at 17; Ex. 2009 at ¶73. The DATA command identifies the entire message,
`
`including the recipient address and message content. Ex. 1008 at 13, 17; Ex. 2009
`
`at ¶73. In fact, RFC 2821 specifies that the DATA command includes both “the
`
`headers and the body.” Ex. 1008 at 10; Ex. 2009 at ¶73. Such headers include
`
`“Date, Subject, To, Cc, From.” Ex. 1008 at 18.
`
`Section D.3 of RFC 2821 discloses an example (reproduced below) where
`
`after the DATA command (“C: DATA”) is issued by the client, the entire message
`
`is transmitted, including the identity of the sender and the recipient (the From and
`
`To fields and the Date) and the message content (the text to Bill regarding the
`
`board of directors meeting). See Ex. 1008 at 74-75; Ex. 2009 at ¶74.
`
`
`
`20
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`
`
`RFC 2821 is not directed to reduced traceability. Ex. 2009 at ¶75.
`
`F. Hazel (Ground 2)
`Hazel is a book describing Exim, a particular mail transfer agent that can be
`
`run on Unix systems. Ex. 1011 (Hazel) at 1; Ex. 2009 at ¶76. Petitioner focuses on
`
`a narrow aspect of Hazel teaching how Mail Transfer Agents (“MTAs”) deliver
`
`email messages to a local mailbox on the server indicated by the recipient’s email
`
`address. Petition at 15-16, 65-67. Hazel is not directed to reduced traceability for
`the same reasons as Blum. Ex. 2009 at ¶78.
`
`
`
`21
`
`

`

`Case IPR2018-00312
`Patent 9,306,885
`
`IV. CLAIM CONSTRUCTION
`Pursuant to 37 C.F.R. § 42.100(b), Patent