`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SNAP INC.,
`Petitioner,
`
`v.
`
`VAPORSTREAM, INC.,
`Patent Owner.
`____________
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`____________
`
`Record of Oral Hearing
`Held: March 27, 2019
`____________
`
`
`
`Before JUSTIN T. ARBES, STACEY G. WHITE, and
`JENNIFER MEYER CHAGNON, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`HEIDI KEEFE, ESQ.
`Cooley, LLP
`3175 Hanover Street
`Palo Alto, California 94304-1130
`650-843-5001
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`MICHAEL F. HEIM, ESQ.
`DOUGLAS WILSON, ESQ.
`Heim, Payne & Chorush, LLP
`Heritage Plaza
`1111 Bagby Street
`Suite 2100
`Houston, Texas 77002
`713-221-2001 (Heim)
`512-343-3622 (Wilson)
`
`
`
`
`The above-entitled matter came on for hearing on Wednesday,
`
`March 27, 2019, commencing at 1:00 p.m. at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`
`2
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE ARBES: Good afternoon. This is the oral hearing in six
`cases: Cases IPR2018-00200, 312, 369, 397, 404, and 408. Can counsel
`please state your names for the record?
`MS. KEEFE: Good afternoon, Your Honors. Heidi Keefe on
`Behalf of Petitioner Snap. And with me at counsel table is my colleague
`Yuan Liang, L-I-A-N-G.
`MR. WILSON: Good afternoon, Your Honor. For Patent Owner,
`Douglas Wilson, who will be arguing. My partner, Michael Heim, who will
`also be arguing.
`We have with us Blaine Larson, our partner, and also Bill Mahone, a
`director at Vaporstream.
`JUDGE ARBES: Thank you. Per the Trial Hearing Order, each
`party will have 90 minutes of total time to present arguments for all of the
`cases.
`
`The order of presentation is Petitioner will present its case first
`regarding the challenge claims for all of the cases. You may reserve time
`for rebuttal, but not more than 45 minutes.
`Patent Owner then will respond to Petitioner's presentation and may
`reserve some of its own time for sur-rebuttal. Petitioner then may use any
`
`3
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`remaining time to respond. And finally, Patent Owner may use any
`remaining time for a brief sur-rebuttal.
`A few reminders before we begin. One, to ensure that the transcript
`is clear, and because we have one judge participating remotely, please only
`speak at the podium and try to refer to your demonstratives by slide number.
`Also, if either party believes that the other party is presenting an
`improper argument, we ask you to please raise that during your own
`presentation rather than objecting and interrupting the other side.
`Finally, we received Patent Owner's list of objections to some of
`Petitioner's demonstratives. We will not preclude Petitioner from using the
`demonstratives it submitted today. I would just remind the parties that
`demonstrative exhibits are merely visual aids.
`They are merely designed to assist at the hearing today. They're not
`briefs, they're not evidence. And if there are any substantive arguments
`today that are improper, those arguments will not be considered.
`Any questions from either party? Okay. And just to make sure,
`Judge White, can you hear us?
`JUDGE WHITE: Yes, I can.
`JUDGE ARBES: Thank you. Okay, counsel for Petitioner, you
`may proceed. Would you like to reserve time for rebuttal?
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`4
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`MS. KEEFE: Thank you, Your Honor. Yes, I'd like to reserve 45
`minutes, although I'm deeply hoping that it won't require that much time,
`either before or after.
`JUDGE ARBES: Okay.
`MS. KEEFE: Thank you, Your Honors. I think both parties have
`approached all of the collective cases as essentially receive side or send side.
`And so I wanted to do the presentation today, essentially as though
`that were exactly the case. And so we'll start with the send side patents.
`And the send side patents are patent 739, 885 and 155. And I've
`merely clicked through Slides 2, 3, 4 and 5, to demonstrate which patents are
`incorporated into the send side.
`As Your Honors are well aware, all of these patents deal generically,
`and I'll refer to the 739 patent, which is on Slide 3, all of these patents can be
`lumped together because the send side patents all talk about having two
`separate displays at the sender side.
`One display on which content is entered, another display on which
`the recipient address is entered. A message ID is then associated with the
`content and the recipient address so that it can be found later, even though
`they have been separated in their send, and then each thing, the content and
`the recipient, are transmitted separately.
`All the claims require essentially the same elements. And so what
`we're looking for is to make sure that there are two separate displays. One
`5
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`which allows you to enter content, which is set separately, and another
`display, which allows you to enter recipient address information. Which is
`that separate, sent separately also, but that there be some form of message
`identifier, which can then be used later to correlate or relate the two.
`And that only makes sense, because if they're sent separately, later
`on when someone wants to be able to view it, you need to be able to make
`sure that you're giving them the right information.
`The prior art that's used as the primary reference in all of our
`combination is Namias. And I apologize, I don't know how it's actually
`pronounced, I've been saying Namias. What do you say?
`MR. WILSON: Both Namias and Namias.
`MS. KEEFE: Okay. So either Namias or Namias, however you
`prefer. The Namias reference is the primary because, Namias very plainly
`and very clearly shows, this is on Slide 7, a figure, which is the first display.
`In that first display, content is uploaded. In other words, here, a
`viewer wishing to send a video to another person, uses Figure 4a, Display
`Number 1, in order to pick the video that they want to send.
`And they even had an ability to preview it by pushing play so they
`can see what the video is. When the user has decided, yes, this is exactly
`the video that I want to send, they hit the button, send this video.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`
`6
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`After send, this video is clicked, and only after send this video is
`clicked, is the user presented with Figure 5, which now requires the user to
`enter, input, recipient address information on a completely separate screen.
`Namias is extremely clear on the two separate displays being used to
`enter the two different pieces of information. But Namias isn't quite as
`clear on what happens after the user decides, yes, this is the right content,
`yes, this was the right recipient and hits send in Figure 5.
`And so, for the combination, Petitioners chose to use the Saffer
`reference. Saffer is another reference which has, as its goal, the
`transmission of video content from a sender to a recipient. Analogous art,
`electronic messages being used to get a video from one place to another.
`Saffer picks up where Namias leaves off. And so the Namias
`screens are to show the displays. Then, when we have to talk about how the
`message is transmitted, what happens essentially under the hood, we look to
`the Saffer reference.
`And one of the best examples in Saffer is Figure 3 itself. Figure 3
`itself specifically contemplates that once video is received, they know that
`there is video in the system, the system in Saffer says, before I do anything, I
`know I'm going to have video, so go get me a video ID from the video
`server.
`
`This is on Slide 8 at Box 100, as highlighted.
`
`7
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`That's before the video is even received. It basically gets a video ID
`down. So this now going to be the ID for that content.
`The next step is that Saffer converts the video file to a .WMV, movie
`format file, and renames it using the video ID that it had just received. And
`it appends .WMV so people know that this is essentially a movie file.
`Only after that is done is the video actually uploaded to the server,
`that's through the FTP file. And then in the final step, the server, in Saffer,
`inserts the URL, the video access address, into a text email message. So
`that when it is sent, the user has access to the content information that is now
`residing on the video server.
`And so we now see that video is sent separate from recipient
`information, we know that from the display screens. And we know that
`Saffer handles it in the same way.
`In fact, perhaps most instructive is Saffer's own Figure 1. May I
`have the ELMO please?
`In Saffer's Figure 1, we plainly see that email and video content are
`being sent and received separately through the Saffer system. And so these
`are, in fact, separate transmissions. Separate sends.
`From the user's computer, up to the email server, stored at the email
`server in the new way with the new information, separate from the fact that
`they video has been uploaded to the video server, emailed with the link, goes
`down to the computer, to the recipient, recipient then clicks and receives a
`8
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`video from the video server. So we have separate displays, separate
`transmissions. And the video ID is, itself, an identification that correlates
`the recipient with the sent information.
`The last piece of the combination, though I don't think it's necessary,
`is if the argument is that that video ID doesn't have enough about the
`recipient in exactly the same place, then we look to the Smith reference,
`which teaches the use of personalized URLs, or PURLs, P-U-R-Ls, in order
`to take the video ID that already exists and append to it the recipient's name
`so that you have a more robust identifier that correlates to in one place as to
`opposed to, in some other look up table.
`For the second ground, and I'm sorry, may I go back to the slides
`please? For the second ground we continue to use Namias as our primary
`reference. But for the under the hood portion, Namias has the two screens.
`But how do we get it from A to B? We use RFC 2821.
`In the RFC, which essentially just dedicates how email is sent, we
`see exactly the concept of sending recipient information separate from
`content information.
`In the SMTP protocol at Appendix D, there is listed a series of
`scenarios. And the header D, which is in Snap's Exhibit 1008 at Page 73,
`the beginning of the entire section reads, ”Scenarios, this section presents
`complete scenarios of several types of SMTP sessions. In the examples,
`
`9
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`‘C:’ indicates what is said by the SMTP client, and ‘S:’ indicates what is
`said by the SMTP server.”
`As we see, in Slide 9, D-1, a typical SMTP transaction scenario
`specifically tells us that the first thing that happens in SMTP, each of the
`actions has to follow exactly one after the other, as dictated here.
`And when the client sends up mail from smith@bar.com, we know
`from the beginning session that we're trying to send a message from
`smith@bar.com to Jones, Green and Brown at host foo.com, the command
`mail from, smith@bar.com is received, and the server says, okay.
`The next, RCPT to: jones@foo.com. So recipient equals to
`jones@foo.com is sent up. The server checks to see if that's a valid address
`and says, okay.
`In the next line, RCPT to: green@foo.com is sent up but the server
`says, there is no such user here. In other words, don't bother with me
`anymore, I'm not going acknowledge this person, they don't exist. And then
`again, we repeat someone who does exist with RCPT to: brown@foo.com.
`Once all of the RCPT to commands are received, only for those
`where the message okay is received, do we go on.
`In the next command, the client sends data. And the data that's sent
`is completely separate from the RCPT to commands, which include recipient
`identifier information.
`
`10
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`And the reason for this is simple. If in fact the recipient is invalid,
`why upload the information for that person? Far easier to just look at the
`outside of the letters, the envelope, and make sure that that's a valid recipient
`before saying, go ahead and send the content back up to me.
`Because you can image a situation in the old days when there were
`no valid addresses and it would be a lot easier to not have to ship all of the
`content up and then ship all the content back down. It's far easier to simply
`say, I see no one that's valid and therefore there is no need to exchange
`content information at all.
`JUDGE WHITE: Look, Counselor.
`MS. KEEFE: Yes, Your Honor.
`JUDGE WHITE: Let's look at the data command. The material
`you have on Slide 9, which is in the reference of the D-1 area, it just says
`blah, blah, blah for the data that's being sent up.
`And so, if you look earlier in the reference there is a discussion of
`the data command on Page 18 of the reference which seems to indicate that
`mail content is what is sent by the data command. And then if you page up
`just slightly above that, you'll see that mail content is defined as message
`content, which includes message headers and the possibly structured
`message body.
`So, what actually is being sent? It seems like the reference might be
`indicating that you're getting both the header information and the data there.
`11
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`MS. KEEFE: I appreciate Your Honor's question, but that's actually
`not what's happening in this exact scenario.
`One of the reasons that I read out of the header of the entire
`Appendix D scenarios, was that D-1, D-2, D-3 specifically indicates that
`they are presenting a complete scenario of types of SMTP sessions.
`In the session at D-1, the data is simply blah, blah, blah, dot, dot, dot,
`et cetera, et cetera. That's text. It's just content that's being sent between
`the command of data received. The server then says, start your input and
`end it with carriage returns. Data is then input, and that's all that's required.
`What Your Honor is talking about on Page 18 is also then shown in,
`for example, D-3, another scenario which does contemplate the inclusion of
`header information. And so, that is a different scenario.
`D-1 does not require it whatsoever. D-1 just says, give me the
`recipient information and then give me data. And that data is something
`they used, blah, blah, blah and et cetera, I believe, just to indicate here is text
`that's being uploaded, and that's all that it really is. So it doesn't require
`header information.
`You Honor, even --
`JUDGE WHITE: So is your --
`MS. KEEFE: Go ahead, please.
`JUDGE WHITE: Is your position then that the information on Page
`18 is not defining the data command?
`12
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`MS. KEEFE: That's correct, Your Honor, it is not defining the data
`command. It is indicating information that could be included with data, but
`not necessarily that which must be included with data.
`And we understand that, when you put that in conjunction with D-1
`being another complete scenario of information that can be transmitted using
`SMTP.
`Even if, even if Your Honor were to say, I prefer to think that header
`information is always included, although I don't think it's required, and that's
`evidenced by the D-1 example, that still would preclude the preclusion,
`forgive my multiple negatives, it would not preclude the preclusion of
`recipient information by virtue of using the BCC command.
`And what happens there is that even though there may be some
`header information, for example, the two or even the subject, which are
`listed as the only required header information that must be utilized, the
`recipient information is 100 percent excluded from inclusion because of the
`possibility of using the BCC command.
`And the whole reason for that, is that you don't necessarily want that
`information included with content for the accidental fact that it would be
`forwarded then to the people who you didn't want to have their addresses to
`be public. Another reason would be that people don't want there to be a
`reply all to numerous invitees or to addressees that people didn't want
`involved in that.
`
`13
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`And so, I hope I've answered, Your Honor's, question. I think it
`absolute satisfies both. D-1 does not require header information, it is a
`complete scenario. But even if it did, the BCC scenario still says that
`recipient does not have to be included. And that's all included as well in
`our expert's declaration.
`The arguments posed by Patent Owner take on essentially four
`arguments. The first is that there should be no combination between
`Namias and Saffer because, if a person of ordinary skilled in the art
`combined Namias with Saffer, they would necessarily use Saffer's screen,
`which would then not yield separate displays.
`But, Your Honor, that makes no sense. If we were saying that in
`order to use Saffer, we had to use Saffer screens, there would be no reason to
`use Namias in the first place. The combination is Namias for the user
`interface and Saffer for the back end. For the way that that information is
`transmitted, once it's been received by those dual displays.
`They also mentioned, Patent Owner also mentions --
`JUDGE WHITE: Well, Counselor?
`MS. KEEFE: Please.
`JUDGE WHITE: Counsel, I think that is Patent Owner's point, that
`they're saying that you haven't provided a reason why someone would
`combine them because one would look at Saffer and see a complete system
`and just go with that. I think that's what Patent Owner's argument is.
`14
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`And they're saying that you have not explained what the benefits are
`of bringing the two together.
`MS. KEEFE: Thank you, Your Honor, for that question. In fact,
`we did present evidence, absolutely, of why the user would use the Namias
`system instead of the Saffer single display screen.
`Namias is a simple, straightforward wizard based user interface that
`helps someone unfamiliar with technology do all of the steps that are
`required. There's actually a quote in our reply declaration that contemplates
`the notion that it's better to have multiple screens with less information than
`fewer screens with more information. Because that can be confusing to a
`user.
`
`In fact, Michael Shamos, the expert originally hired by Patent Owner
`in this case, in IPR2018-00200, in Exhibit 2001 at Paragraph 31,
`acknowledged that the Namias screens and interface are very simple. And
`so there is a motivation to use the Namias screens. It helps users who don't
`necessarily understand how to walk through these contemplated steps.
`Our expert, Dr. Chatterjee, specifically talked about the fact that
`there are over 22 different options on the single screen of the Saffer
`reference, leaving someone not sure whether they needed to leave things
`unclicked or clicked and which boxes to fill in and which not, versus the
`Namias screens which very simply walk the user through, upload just the
`
`15
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`content, then upload the recipient address, then if you need to pay you pay,
`and then you continue to go.
`JUDGE ARBES: Counsel, wasn't Saffer's Figure 6, for example --
`wasn't that kind of the standard way of showing that sort of information,
`putting all of that in one screen? To, subject, body of the email?
`That seems, in some respects, simpler than having multiple screens,
`
`right?
`
`MS. KEEFE: I think it depends on the user and it depends on the
`person. There are not, while it may be beneficial for some, because they
`think that they would rather have it all on one screen at one time, I know, for
`example, when my parents use computers, it's far easier for them to have a
`wizard type scenario to walk through the things that they have to do, so that
`they don't get confused by multiple options on a single page.
`And that's exactly what Dr. Chatterjee offers in Paragraphs 92
`through 104 of his declaration. These are design choices, that's also listed
`in Paragraphs 39 through 41 of the reply declaration of Dr. Chatterjee, again,
`indicated that while it may be sometimes beneficial to have a single screen,
`and some people may prefer that, other people may prefer the simple wizard
`like setups over the form setup of just one major screen.
`And if there is even one benefit that can be appreciated, then that can
`be at least a motivation to try, if not an absolute motivation to combine,
`which we think it is here.
`
`16
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`JUDGE ARBES: What about the Patent Owner's point that we need
`to consider the references as a whole, and when you have a reference like
`Namias and bringing in another reference that does it in kind of a
`fundamental different respect, showing it in one screen instead of the multi-
`screen way, that that goes maybe against the combination, that a person of
`ordinary skill in the art would not look to a reference like that because it is
`so fundamentally different?
`MS. KEEFE: Right.
`JUDGE ARBES: How do you respond to that?
`MS. KEEFE: I absolutely disagree, Your Honor, 100 percent. The
`user of Saffer is not for its user interface. It's not for the way that the user is
`presented with the information. It's solely used when Namias says, I have
`the information from the sender, now how is it transmitted.
`Namias doesn't speak in detail to the transmission steps. And so,
`one of ordinary skill would look to Saffer, who gives far less details about
`the actual screen, there is just a grab of the screen, and gives more details
`about the back end, for example Figure 1, and the flow diagram that
`specifically tell us how that information is sent after its been received.
`And so, there is no teaching away at all. In fact, if the combination
`is read properly and appropriately, where Namias is for the dual screen and
`Namias teaches the user how to input the information, first content, then
`recipient, Saffer only takes over after that. And so, there is no teaching
`17
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`away by virtue of the fact that Saffer received its information on a single
`screen.
`
`JUDGE WHITE: So, Counselor, are you relying only on this ease
`of use argument or are you also relying on the arguments regarding possible
`savings in storage, bandwidth and the like?
`MS. KEEFE: So, we're actually relying on all of it, Your Honor.
`We're relying on the fact that, for example, there's also -- Saffer also talks
`about the possibility, because of its transmission ability and the way that it
`transmits information, to optimize its transmission for whatever recipient
`device is on the back-end. And that's in Chatterjee's original declaration at
`Paragraph 103.
`There's also the benefit of being able to make sure that you're taking
`into account size constraints, that you're saving bandwidth and you're saving
`downloads. Because you're sending them as a stream or as something that
`streamed instead of something that's simply attached.
`And so, Saffer teaches all of those benefits as well. In fact, the only
`thing that Patent Owner complains about is that there may be a time where,
`because in Saffer the person was somehow downloading the information,
`streaming it over and over and over again, there may not be a saving in that
`one situation, they do not refute the fact that there would be a saving in
`bandwidth, on all of the occasions where, for example, the URL or the link
`
`18
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`was not clicked at all when no one went into it. Or when you began
`watching and then stopped.
`Those are all things that are not refuted by Patent Owner at all and
`are other simple, easy reasons for the combination. Because Saffer teaches
`streaming. Streaming alone is a really good reason to look to the
`transmission style and type of Saffer, after having used the input screens of
`Namias.
`JUDGE WHITE: Counselor, if I understand Patent Owner's point, I
`think they're arguing is that there are more scenarios where there would be
`an increase in bandwidth and storage needs then there are situations where
`there would be a decrease. Because they see a situation where you do the
`multiple streams if it's a particularly popular video as a place where you can
`have an increase in the data needs and the situation where you have to make
`multiple people receiving the same video and they're each streaming it all
`over again and saving it all over again, that you could just have more and
`more data out there.
`And that one of skilled in the art would not design the system in the
`hopes that people wouldn't be looking at the videos that they're sending.
`So, while there might be an incident where there could be a savings, that
`wouldn't be one that you would have in mind while you're designing a
`system for people to view the videos.
`
`19
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
`
`
`MS. KEEFE: Yes, Your Honor, again, I'm sorry, but I disagree.
`The fact that that could be one scenario, that is not the 95 percent of all
`scenarios.
`And in fact, Dr. Chatterjee specifically addresses this fact in his
`reply declaration at Paragraph 8, where he contemplates the notion that a
`designer of a system that wanted its materials to be viewed over and over
`again, could actually build in that that information would then be cached
`down at the recipient's device. So that didn't have to keep going back up to
`the server.
`So even in the multiple view scenario, it was well-known at the time
`to cache local versions of materials that had been downloaded so that you
`didn't have to continually ping the server for that. Therefore, you still
`maintain the betterment of the system by virtue of all of those times when
`someone didn't happen to look at the download at all, or only looked at a
`portion of the download.
`Simultaneous advantages and disadvantages are not enough to teach
`away from a combination. Common sense says that everyone has used
`URLs, everyone understands this streaming and that there could easily be
`that caching on the other end. We can't ignore that either.
`But I also don't agree with the fundamental premise, that that would
`overwhelm or outweigh all of the benefits from not having to send the
`information down until it's requested. If you could envision, for example, a
`20
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`
`
`Case IPR2018-00200 (Patent 8,886,739 B2)
`Case IPR2018-00312 (Patent 9,306,885 B2)
`Case IPR2018-00369 (Patent 9,313,155 B2)
`Case IPR2018-00397 (Patent 9,306,886 B2)
`Case IPR2018-00404 (Patent 8,935,351 B2)
`Case IPR2018-00408 (Patent 9,338,111 B2)
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
