`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`SNAP INC.,
`Petitioner,
`
`v.
`
`VAPORSTREAM, INC.,
`Patent Owner.
`____________
`
`Case IPR2018-00416 (Patent 9,413,711 B2)
`Case IPR2018-00439 (Patent 9,413,711 B2)
`Case IPR2018-00455 (Patent 9,313,157 B2)
`Case IPR2018-00458 (Patent 9,313,156 B2)
`____________
`
`Record of Oral Hearing
`Held: April, 17, 2019
`____________
`
`
`
`Before STEPHEN C. SIU, JUSTIN T. ARBES, STACEY G. WHITE, and
`JENNIFER MEYER CHAGNON, Administrative Patent Judges.
`
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`HEIDI KEEFE, ESQUIRE
`YUAN LIANG, ESQUIRE
`Cooley LLP
`3175 Hanover Street
`Palo Alto, CA 94304-1130
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`MICHAEL F. HEIM, ESQUIRE
`DOUGLAS WILSON, ESQUIRE
`Heim Payne & Chorush, LLP
`1111 Bagby Street
`#2100
`Houston, TX 77002
`
`
`
`
`The above-entitled matter came on for hearing on Wednesday, April,
`
`17, 2019, commencing at 1:00 p.m., at the U.S. Patent and Trademark
`Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`2
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE ARBES: Good afternoon everyone, please be seated. This is
`
`the oral hearing in four cases today: Cases IPR2018-00416, 439, 455, and
`458. Can counsel please state your names for the record?
`
`MS. KEEFE: Good afternoon, Your Honors. Heidi Keefe on behalf
`of petitioner Snap. With me at table is Yuan Liang and he will also be
`presenting a portion of the argument. Thank you.
`
`MR. WILSON: Good afternoon, Your Honors. On behalf of patent
`owner, Douglas Wilson of Heim, Payne and Chorush and with me is my
`partner Michael Heim who will also be arguing. And also with us is Avi
`Elkoni who is the chief operating officer and chief technical officer of
`Vaporstream.
`
`JUDGE ARBES: Per the Trial Hearing Order in these cases, each
`party will have 90 minutes of time to present arguments for all four cases.
`The order of presentation is first, petitioner will present its case regarding
`the challenged claims and may reserve time for rebuttal, but no more than 45
`minutes. Patent owner then will respond to petitioner's presentation and can
`address its motions to amend and may reserve some of its time for sur-
`rebuttal.
`Petitioner then my use any remaining time to respond to patent
`owner's presentation regarding the challenged claims and motions to amend,
`and finally patent owner may use any remaining time for a brief sur-rebuttal.
`Again, as before with the previous hearings, a few reminders. To
`ensure that the transcript is clear and because we have two judges
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`3
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`participating remotely, please only speak into the podium. Please speak at
`the podium and refer to demonstratives by slide number when you can.
`If either party believes that the other party is presenting an improper
`argument, we would ask you again to raise that during your own
`presentation rather than interrupting the other side.
`Any questions before we begin today? Okay. Counsel for petitioner,
`you may proceed, and would you like to reserve time for rebuttal?
`
`MS. KEEFE: Yes, Your Honor, I would like to reserve 45 minutes.
`Hopefully I won’t need all of that. And I would also like at the very
`beginning to appreciate and thank the Board's indulgence in allowing this
`hearing to happen here. I have already thanked again patent owner, and my
`mom thanks you when I will see her tonight for dinner so thank you again
`very much for that indulgence.
`Now I know that Judge Siu wasn’t here last time but we actually
`argued about almost all of these receive side and send side limitations last
`time. I will however go through them briefly but please, if there’s any
`questions that you have, feel free to interrupt me at any point because
`obviously what I’m here for most is to make sure that I answer your
`questions, not simply to go through whatever presentation materials we
`have.
`I will start however, with the send side patents. And I’m sure Your
`Honors know, there are essentially three groups, groupings that can be made
`of the patents in these cases. The first here today for the 156 deals with what
`happens on the sending side of sending a video message from one sender to
`another.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`4
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`
`Then we have what happens on the receiving end and then finally as
`kind of a bring it all together we have what I call the server side patents
`which show the end to end transmission. So the beginnings at the sender
`side and the recipient at the receiver side.
`Within the send side patents, we have Claim 1 which is very familiar
`to the other send side patents that we have already discussed which talks
`about associating message content with which includes a media component
`and in the case of all of our references, it’s a video. That will be displayed at
`the sending user device.
`You have to associate an identifier with the recipient of the message
`and make sure that there are two separate displays on the sender side device
`for entering information first about the recipient on one display and content
`on the other display or vice versa.
`That message content is then transmitted including a media
`component from the sending device to a server computer and then the
`identifier of the recipient is also transmitted as well.
`The send side references, the main reference in all of the send side
`claims is the Namias reference. And the Namias reference as we know is a
`kiosk style computer which has at its core a touch screen described in the
`patent as a touch screen enabled by a PC or other processing computer, that
`enables a user who wants to send a video to someone else to through a series
`of wizard type screens send information from a sender to a recipient.
`In Namias Figure 4A, we see the first display screen and in that
`display screen, nothing but the message content is shown. The message
`content is the video that you are going to send.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`5
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`
`Only after the video has been decided, this is the video I definitely
`want to send, the user presses send this video and only thereafter is taken to
`a secondary screen, Figure 5, in which the sender is asked to type in the
`recipients address. And we see that in Figure 5 itself.
`So we have two completely separated displays. One showing content,
`in this case the message, the video, and the other showing the recipient.
`The secondary reference being combined is that of Saffer. Saffer is a
`system that receives a video and in the Saffer system what happens is that
`when the video is sent up to the server, the server says I’m going to take that
`video and I’m going to store it.
`And I’m going to give that video an ID and I’m going to send that ID
`back down to the sender’s computer so that it can be associated with the
`email, shipped back up to the server, and then what is sent to the recipient is
`a link to the video that’s been stored at the service, not the video itself.
`And then finally the reference Smith. Smith is a reference that talks
`specifically about the use of personalized URLs in order to give more
`information to the identifier of a document. So instead of just having the
`link where it just reads the exact location of a document, you can actually
`append a recipients name or other security information to the end of that
`URL so it can be used for tracking information or further security features.
`And finally, the Ford reference which I don’t think we need to talk
`about today.
`The complaints that petitioner -- sorry, the complaints that patent
`owner makes regarding the combination of Namias, Saffer, and in particular
`Smith, is that the complaint is that somehow our reliance on Namias's user
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`6
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`interface to disclose the separate displays is improper hindsight reasoning.
`But that's not true.
`Namias had two separate displays. The claim required two separate
`displays. Namias has separate displays for inputting content and inputting a
`recipient’s information. There is nothing hindsight about looking for
`elements in the prior art, finding the elements in the prior art exist in exactly
`the same way that the claim calls for. That is we have a messaging system
`for sending video.
`How do we do that? We do that with two screens. It’s exactly what
`Namias did. And the petitioners reply at paper 24, 11 through 16
`specifically addresses exactly why it’s not improper hindsight to look at that.
`Also one of ordinary skill in the art would be motivated to combine
`Namias with Saffer and use its URL based delivery technique because again,
`both Namias and Saffer were delivery of video content from a messaging
`sender to a messaging recipient.
`Saffer because it deals with URLs allows for streaming of video
`content and Dr. Chatterjee specifically discussed why it would be beneficial
`to be able to use the streaming technique of Saffer with Namias. Especially
`to conserve bandwidth and conserve potential storage space.
`The argument made by patent owner was well, but there might be
`times when someone might want to view the video a handful of times and
`therefore it might not conserve bandwidth in one instance.
`But that’s not enough to overcome an obviousness combination where
`the motivation to combine does indeed find benefit especially for example in
`those situations where someone doesn’t look at the video at all and therefore
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`7
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`all bandwidth is stored. Or someone wants to start watching the video while
`the rest is being buffered. That also is extremely helpful with streaming
`versus direct transmission.
`Finally, the combination of Namias and Saffer does teach separate
`transmission. When the Namias and Saffer combination is made, the
`attachment, the video, the message content, the video, is replaced with a
`URL which is then sent down to the user. That URL is a link to the
`information. Not the linked information itself.
`And therefore, the combination of Namias and Saffer absolutely
`shows sending separately the transmission of the content versus the recipient
`information which looks an awful lot like and I'll jump forward to Figures
`10 and 11 and this is on Slide 24, looks an awful lot like Figures 10 and 11
`of the patent itself.
`In the 156 patent, what we know on the left hand side is this is the
`recipient information but that is a clickable link. When one clicks on what is
`in the box highlighted in red on Slide 24, that accesses an HTML page.
`The underlying information from that page is then used by the server
`to deliver the information. And wat we see on the right hand side in the
`green box up above is the exact location of that HTML page that is now
`being displayed with the content which is this is my first message to you.
`Dr. Almeroth, patent owners expert concurred that in fact, this was a
`separate transmission within the context of the patent itself. Therefore,
`when Saffer sends down a link, a URL to the information, that is a separate
`transmission exactly as we see in Figures 10 and 11.
`The fact that one could gain access to the information by clicking on
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`8
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`the link or by doing some type of a right click that would show you the
`underlying information behind the URL does not mean that the content has
`been sent simply by seeing the screen that has the URL in it. Otherwise, the
`patent itself would not have taught what they say is a separate transmission
`as agreed by Dr. Almeroth.
`And finally, separate transmission is also taught by RFC 2821 and we
`know that because RFC 2821, this is an alternative ground and now we are
`looking at Slide 31.
`RFC 2821 specifically calls out that when you send an email you have
`to do each line separately. Each is a separate command followed by a
`separate answer command. Answer command and it must follow that format
`and the RFC is clear about that.
`What we see for example in D1 which is a complete example if we
`look at the header above that on -- in RFC 28121, it is a complete example.
`We see that RCPT TO Jones@foo.com, is sent by itself. If that is a valid
`address an okay is returned and the next RCPT TO can be sent. In this case,
`green@foo.com.
`There, no valid email address existed so a no such user was sent back.
`No content has been shipped at this point. These are separate transmissions
`of the recipient information.
`
`JUDGE WHITE: Counselor, let’s just go back through this one more
`time then. If you look in the RFC section 3.3 mail transactions, it says the
`data command initiates a transfer of mail data and if you look up above in
`section 2.3.9 it talks about what message content in mail data is and it says
`that it includes message headers in the possibly structured message body.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`9
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`
`So with that in mind, are we not in a situation where that data
`command would be sending both?
`
`MS. KEEFE: So, Your Honor, the first answer is no. Not within the
`example given at D1. For example, if we look at page 73 of Exhibit 1022 of
`which shows the scenarios of typical SMTP transactions, each one presents a
`complete scenario of that SMPT section.
`Within D1, the very first transaction shown, we see that it’s merely
`data like blah, blah, blah, et cetera, et cetera, et cetera. So this is a scenario
`which would not include headers.
`If you look forward into the remainder of the examples, for example,
`at the D3 and D4, both of those examples specifically include header
`information like date, from, subject and to, and are specifically included as
`the data that is being submitted.
`Therefore, the SMPT knew how to say put the header data in here and
`knew how not to. D1 is an example when it wasn’t required.
`But as we talked about last time, Your Honor, even if you were to find
`that for example header information its better if it's included or not, there is
`still always the BCC operation. And in the BCC operation, recipient
`information does not have to be included.
`And so that’s -- and that’s also set out specifically by Dr. Chatterjee
`and by the SMTP itself which is confirmed by RFC 2822 which specifically
`indicates that the only header fields that are required are the date field and
`the from field, the originator field.
`So even if header information had to be included, the operation of
`BCC mandates that the to information does not have to be included and in
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`10
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`fact would follow within D1 that the to information was not included.
`So if BCC were being operated, then the recipient information would
`not be being sent with the data operation. Does that answer Your Honor’s
`questions?
`
`
`JUDGE WHITE: Yes.
`
`MS. KEEFE: Thank you. I think the last question was whether or not
`the combination of Saffer and Smith taught the claimed correlation. Within
`Smith, the ID of the video is the identification of the content information.
`Adding on Smith places the correlation within the URL itself by then
`appending the name of either the sender or the recipient directly into that
`URL. And therefore the combination of Saffer and Smith would have
`resulted in a system in which the URL of Saffer with the content ID directly
`follows with recipient identifiers such as the recipients email address.
`RFC 2821 also teaches the claimed correlation and this is at slide 73
`and here the data that is used to correlate the recipient information with what
`it is, recipient information, is the phrase RCPT to and I’m in Slide 37 which
`is highlighted in yellow.
`That data thereby correlates this is recipient information which is what
`follows and that is Jones@foo.com. That's now correlated. And then the
`period at the end makes sure that we now tie a bow around, tie a lasso I think
`is the word I used last time, around the data that is going to be correlated
`together with what then goes to those recipients and we see that highlighted
`in green.
`On the receive side patents, we have as you can expect what happens
`on the opposite end where we again have two separate displays for who is
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`11
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`receiving the information, where it comes from, and what the information
`itself is.
`The primary reference being used is the Wren application. This is at
`Slide 41 and in the Wren application, we specifically see sender information,
`time and length in Figure 9A. And in Figure 9B we see the movie that had
`been sent.
`Wren itself was a video messaging application that specifically
`contemplated a one touch usage. That was the primary usage feature of
`Wren. There is an alternative embodiment in which a user may be prompted
`to add additional information but the primary embodiment of Wren is the
`one touch meaning you put your video up, make sure you have the right
`sender that you want to send it to or recipient’s name, click and it goes. No
`further input from a user whatsoever.
`That’s confirmed in paragraph 32, Figure 9 is an illustration of a
`recipient receiving the one touch arbitrary length movie message with video
`and audio. Figure 9 shows the notification of the new message and that
`notification is not the content. It’s just that you have a new movie from
`Jane.
`And Figure 9B shows the movie once the user selects play. Sender
`information separated from content. The argument made is that somehow
`this is not a separate display because it includes the phrase new movie. But
`new movie is not information entered by the sender of the movie.
`In fact, all of Wren talks about one touch being that nothing else is
`being added by the sender and Dr. Chatterjee specifically describes this in
`his declaration and his reply declaration. The logical, the frankly the most
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`12
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`logical if not the only logical conclusion is that new movie is simply what
`the sender, sorry, the receiver’s phone puts in to say this is a movie as
`opposed to for example a voice message or an email.
`So that’s just information indicating as a notice this is what is -- this is
`what it is but it has no content whatsoever. The computer didn’t go in,
`review the movie, figure out what it was and type something in about it or
`prompt the user for any information.
`The combination made is with Berger because the claim requires a list
`of senders as oppose to simply one and in Berger, what we see is messages
`that have been received, multimedia messages including in Figure 1 of
`Berger, videos.
`Videos are absolutely contemplated by Berger and we see that it, what
`Berger lists are what the user has received and from who. So we have
`George Smith for example on the very first line.
`And what the next figure in Berger, Figure 5 shows is that what is
`behind George Smith is actually a URL that includes information about
`George Smith and the document itself so that when you click it you actually
`go to that document.
`And I think it is very important to also look at what it says in number
`three. Number three simply says voice message. No different from new
`movie. So it’s a basic boring description of what the thing is as a
`notification as opposed to any information input by anyone. The
`combination of --
`
`JUDGE WHITE: Counselor?
`
`MS. KEEFE: Please.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`13
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`JUDGE WHITE: In your view, what is sort of the construction of
`
`message content? What are the -- what would actually fall in and out of the
`that term? How broad should we view the term message content?
`
`MS. KEEFE: So, I think, Your Honor, the most logical way to view it
`is that content is separate from header which is exactly what the
`specification of the patent itself contemplates. That content is the, you
`know, that which the user wants the person on the other end to see versus
`header information which is simply information about who is sending it.
`What time it was, where that information is, who it comes from, who
`it goes to. And so content is the information being sent as opposed to
`information about those things.
`And the easiest way within the Namias, Wren, Berger, and the 711,
`156 and 157 patents is that it's what the user puts in. It is what the user
`chooses. The video that they want someone to see. The video that they
`want to record or in the case of Vaporstream, the information that they want
`to make sure that someone on the other end sees. Whatever multimedia is
`being sent.
`
`JUDGE ARBES: What about text --
`
`JUDGE WHITE: Is it really the -- I was going to say is it really the
`question of who actually entered in the information? Because if I’m typing
`in the email address that would arguably fall into the bucket of header
`information so it’s not -- is it really in your mind the question of who types it
`in?
`MS. KEEFE: No, in fact Your Honor, raises -- that's why I was trying
`
`to separate the notion of header information from content information. So
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`14
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`you’re right. It’s not who types it in because it can be an auto complete field
`but it’s what the user wants the recipient to see. And it’s the content versus
`the header.
`So really the differentiator is header is -- I almost think about it as
`metadata versus data. I don’t want to get too far down that road because I’m
`sure that will blow up in my face at some point.
`But the, it's the concept of header information is information about the
`content. When it is, who it's from, when it was sent versus the content itself.
`That which the sender wants the recipient to see.
`
`JUDGE ARBES: But didn’t the --
`
`JUDGE WHITE: Isn’t that a bit imprecise, I mean, what we want the
`user to see? I mean, we want the user to see that there is an email. That’s --
`
`MS. KEEFE: Well, but that is not the content. That’s not the thing
`that the sender is trying to send.
`The sender is trying to send a video and in the patents at issue here,
`156, 157, and 711, the sender is trying to send some form of multimedia.
`And they always distinguish between the message and the message content
`except for one location where Judge Arbes asked me during the last one
`there is one time where it says message instead of message content.
`But is always separating itself from header. And so content is always
`that which is not header. And so that’s probably the best answer I can give
`is that message header information is not message content.
`
`JUDGE ARBES: Counsel, can I ask the reverse?
`
`MS. KEEFE: Sure.
`
`JUDGE ARBES: Do we need to interpret header information? It
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`15
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`appears that the district court interpreted it as properties of a message that is
`not the message content.
`
`MS. KEEFE: Well --
`
`JUDGE ARBES: Defining – so, how do we pinpoint exactly here
`what is header information and what is message content, what can be
`considered in either of those two categories?
`
`MS. KEEFE: I think the best advice or the best guidance, Your
`Honor, comes from the specification itself in column 9. This, I’m looking
`right now at the 711 patent but the same exact language is in all the rest. At
`column 9, line 5 for example says typically a message content such as
`message content 140 which is what is trying to be sent to the recipient, does
`not include information that in itself identifies the message sender, recipient,
`location of the electronic message or time date associated with the electronic
`message.
`And all of those as we know from SMTP are typical header
`information. I don’t think you have to define it as header versus content but
`what we have is a definitional statement or sorry, not definitional, it’s a
`guidance from the patent owner of what it intended message content to be
`which was not in and of itself identifying the sender recipient, location of the
`message and or date time associated with that message.
`And so I would say that includes for example the from, the to, subject
`line, something like a URL that simply shows where the content is or the
`date or time associated with it.
`
`JUDGE ARBES: But how do we know here that the sender did not
`want to communicate the text New Movie?
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`16
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`MS. KEEFE: So what we know is that the embodiment, the primary
`
`embodiment within Wren was for a one touch message being sent. And the
`one touch arbitrary length movie message is always described as the sender
`recording a movie and then just with one click, either a hard button or a soft,
`sending it to a recipient.
`They are not prompted in the one touch method for any further
`information. They're not prompted to type in any text. And therefore --
`
`JUDGE ARBES: But they could have entered that text earlier and
`when I do the one click, it sends the text with the video, right?
`
`MS. KEEFE: I think that while that’s possible, while that’s absolutely
`possible, Your Honor, it would be very strange -- for one thing it would be
`very strange to put subject information above the from, time and length.
`Typical arrangement would have something like subject that had been
`typed in put down below and it would have been after a header field.
`Header field, subject colon which we actually see in 9C which is the email
`message which includes the attachment.
`So they knew how to use a subject that had been provided by the user
`whether it was auto filled from something that had been typed in before or
`something that was typed in on a prompt at that time. And nowhere does
`that show up or a subject field in what we see on the left hand side.
`Instead what I honestly think and what Dr. Chatterjee says is the most
`likely is that this is no different for example than what we see on line 3 of
`Berger which is this is just a description of what it is which is provided by
`the phone itself.
`So I’m looking at a movie as opposed to a voice message. As opposed
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`17
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`to a text message or an email. And that’s just to say this is what it is going
`to be so when you hit play that’s that you are going to get. It’s not going to
`be a voice message. It’s going to be a movie.
`And it also describes every single movie that would ever be
`transmitted using the Wren one touch system and so it just doesn’t make
`sense that what they're saying is that’s what the user typed in because as you
`see in 9C. They say Christmas morning. That’s something that actually is
`descriptive of what is happening.
`
`JUDGE ARBES: Well, but you're saying then that there is a
`difference. There is a difference between Figures 9A and 9C. These are the
`only figures that we have to go on.
`And in some sense, your belief and Dr. Chatterjee’s belief is that
`Figure 9A is inconsistent with the only other description we have.
`Shouldn’t, isn’t the more natural reading to read these together?
`
`MS. KEEFE: So I don’t think they’re inconsistent at all. All it is, is
`that in 9C you actually have subject information that had been entered by
`someone. For example, if we actually look at the title, the words that we are
`looking at, it doesn’t say new movie like in, you know, capital N, little
`movie, New movie like you would be writing a sentence or a description.
`It says cap N new, cap M movies. That’s that this thing is. It’s a New
`Movie. That’s not -- it doesn’t look like something that has been input by a
`user. There is no evidence to show that it was and it specifically talks about
`this being sent with one touch.
`So I think in order if they were consistent, you would have a subject
`line underneath time so that it looked more like 9C if that was in fact
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`18
`
`
`
`IPR2018-00416 (Patent 9,413,711 B2)
`IPR2018-00439 (Patent 9,413,711 B2)
`IPR2018-00455 (Patent 9,313,157 B2)
`IPR2018-00458 (Patent 9,313,156 B2)
`
`something that had been entered by the user.
`So to answer your question, I think it would only make more sense to
`make them consistent if it was something that had been typed in by the user
`that it looked like 9C not that it had a completely different format.
`Instead it only makes sense that the reason it looks different is that
`that isn’t something that had been entered by anyone. That’s just what the
`phone does to say what you are going to be seeing is a movie instead of
`something else. And so it wasn’t entered by a user and therefore isn’t
`content. Wasn’t intended to be content, wasn’t anything that the sure
`intended to send to the recipient.
`
`JUDGE ARBES: A couple additional questions.
`
`MS. KEEFE: Please.
`
`JUDGE ARBES: The Christmas morning line in Figure 9C.
`
`MS. KEEFE: Yes.
`
`JUDGE ARBES: Is that header information your view?
`
`MS. KEEFE: Yes. Because it is a subject. It directly follows the
`colon subject which is the header information and include in the header
`itself. And it des
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
