throbber
Trials@uspto.gov
`571-272-7822
`
`
`Paper No. 28
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GOOGLE, LLC
`
`vs.
`
`UNILOC 2017 LLC
`____________
`
`IPR2020-00463
`Patent 8,194,632 B2
`____________
`
`Record of Oral Hearing
`Held Virtually: Thursday, May 13, 2021
`____________
`
`
`
`Before DAVID C. MCKONE, JESSICA C. KAISER, and
`SHARON FENICK Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`IPR2020-00463
`Patent 8,194,632 B2
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`CORY BELL, ESQ.
`ERIC GARNER, ESQ.
`SIDNEY KESSEL, ESQ.
`FINNEGAN
`Two Seaport Lane
`Boston, MA 02210-2001
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`JEFFREY HUANG, ESQ.
`McKOOL SMITH
`865 South Figueroa St.
`Suite 2900
`Los Angeles, CA 90017
`
`
`
`The above-entitled matter came on for hearing on Thursday, May 13,
`2021, commencing at 1:02 p.m. EST, by video/by telephone.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`2
`
`
`

`

`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
`26
`
`IPR2020-00463
`Patent 8,194,632 B2
`
`
`P R O C E E D I N G S
` JUDGE FENICK: Good morning. This is an inter partes
`review, IPR 2020-00463, captioned Google, LLC, versus Uniloc 2017,
`LLC, regarding Patent 8,194,632 B2.
` I'm Judge Fenick and with me are Judges McKone and
`Kaiser. I'd like to start by getting the parties' appearances.
`Can we -- can I find out who is appearing this afternoon on behalf
`of the Petitioner, please?
` MR. BELL: Yes, Your Honor. This is Cory Bell on behalf
`of Petitioner Google. With me on video is Eric Garner, who is
`lead counsel for Google. Also on the telephone, we have backup
`counsel Sidney Kessel and in-house counsel for Google, Joe Scher.
` THE COURT: Thank you. And can I hear who is here on
`behalf of the Patent Owner, please?
` MR. HUANG: Good afternoon, Your Honor. My name is
`Jeffrey Huang for Patent Owner Uniloc, and with me is in-house
`counsel for Uniloc, Steve Peterson.
` JUDGE FENICK: Thank you.
` We set forth the procedure for today's hearing in our
`oral hearing order, which is Paper 25. As a reminder, each party
`has 45 minutes of total time to present its arguments. Petitioner
`has the burden of proof and will go first. Patent Owner will
`present opposition arguments. Then, to the extent Petitioner has
`reserved time, the Petitioner will have time to present arguments
`in rebuttal and after that, to the extent that Patent Owner has
`reserved surrebuttal time, the Patent Owner may present its
`
`3
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`surrebuttal.
` We have access to papers, exhibits, and demonstratives
`in this case, and so, for clarity in the transcript and also so we
`can view what you are referring to, when you refer to a portion of
`the record or to a demonstrative, if you let us know the document
`and page number you're referring to.
` Counsel should unmute only when speaking. This remote
`nature of the hearing may result in an audio lag. So if you can
`observe a pause prior to speaking so we avoid speaking over each
`other.
` If at any time during the hearing you have technical or
`other difficulties, please let us know immediately so we can make
`adjustments. We have technical support listening in, and we will
`try and keep our eyes out and ears out for technical problems as
`well.
` As noted in the hearing order, although we are all
`appearing remotely and there's no physical courtroom, members of
`the public have the option to attend and may be listening to the
`audio of the hearing, as a request for the public line as been
`made. In the oral hearing order, we requested that if there was
`any concern about the disclosure of confidential information at
`this hearing, you were to contact the board. We did not receive
`any such notice.
` But will the Petitioner please confirm that you do not
`intend to discuss any confidential information today?
` MR. BELL: Confirmed for Petitioner.
` THE COURT: Thank you.
`4
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
` And, Patent Owner, could you also confirm that?
` MR. HUANG: Yes, confirmed.
` THE COURT: Thank you. Unless there are any questions,
`we're going to start. Patent Owner, are there any questions at
`this time?
` MR. HUANG: No, Your Honor.
` THE COURT: Thank you.
` Any questions on behalf of Petitioner at this time?
` MR. BELL: No, Your Honor.
` THE COURT: Okay. Thank you.
` Petitioner, would you like to reserve any amount of time
`for rebuttal?
` MR. BELL: Yes. 15 minutes, please.
` THE COURT: 15 minutes. Okay. I'll endeavor to tell
`you when 30 minutes have elapsed then.
` MR. BELL: Thank you.
` THE COURT: And you can proceed when you're ready.
` ARGUMENT ON BEHALF OF PETITIONERS
` MR. BELL: Thank Your Honors. I think it's important to
`start with the relevant technology in this case. So if we start
`with line 2 of our demonstratives, we have laid out the background
`in the '632 patent and its process of establishing network
`connections. It works in this particular system where you have
`three devices: A stationary terminal, which we circled in blue,
`125. That can be something such as a laptop, a desktop, or a
`workstation. There's proximate mobile device. That's the
`cellphone, 110, which we circled in red. And then there's a
`5
`
`
`

`

`IPR2020-00463
`Patent 8,194,632 B2
`remote device, 115, which we circled in green, such as a smart
`phone or a PDA.
` And in the system, the stationary terminal and the
`remote device want to establish network connection over the
`internet, 120. And the way that the particular embodiment that
`relates to the claims here works is that the connection is
`initiated through a different channel. In particular, the
`stationary terminal has a Bluetooth connection with the proximate
`mobile device, which then has the ability to communicate with the
`remote mobile device over a cellular network, such as through SMS.
` And the way that it works is the stationary terminal
`provides to the proximate mobile device a -- its IP address and
`the telephone number of the remote mobile device over that
`Bluetooth connection, and then the proximate mobile device can
`take that received information and send an SMS message that
`includes that IP address to the remote mobile device.
` And if they go to slide 3, we can see how this lines up
`with the claims. In step 1-A, we have that concept of
`establishing the communication link. That's that orange box
`between the stationary terminal in blue and the proximate mobile
`device in red. Then we have that transmitting of that IP address
`and the telephone number. That's that blue arrow between the blue
`box and the proximate mobile device in red. Then the proximate
`mobile device establishes communication with the remote device.
`That's at 1-C. That's akin to sending the SMS message to the
`telephone number of the remote device that includes the IP address
`of the stationary terminal.
`
`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
`26
`27
`
`6
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
` And then, finally, in step 1-D, that network address is
`used to establish a connection to the stationary terminal.
` Turning now to slide 4, there are three claims at issue:
`Claim 1, Claim 8, and Claim 15. Of these claims, there's just two
`parts that are in dispute. I have highlighted them on the slide.
`In Element 1-B, it relates to the content of that invitation
`message. So that's the message that's sent between the stationary
`terminal, that laptop or computer, to the proximate mobile device.
`And in particular, whether or not that would include a remote
`device identifier.
` And then in Step 1-C, there's a related element that
`requires the establishing of the communication between the
`proximate mobile device and remote device, B, using that remote
`identifier.
` Turning now to Slide 5, there's two separate grounds
`that we have for these claims. One is based on Conley alone, and
`the other is based on Conley and Bu. The RFC3261 for the session
`initial protocol, or SIP.
` Starting with Conley, if we go to Slide 7, I think it's
`important that we start with the preamble so we can say the ground
`work of kind of what's being mapped to what here. And Conley
`discloses a system very similar to the '632 patent where it wants
`to set up a network connection between two devices over a network
`such as the internet. And it does so by sending in a
`communication over the primary channel. In Conley, the particular
`devices we mapped to the stationary terminal was the first device,
`that laptop or tabletop computer, 140, in Conley.
`7
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
` And the remote device is this collection of 112 and 142,
`shown in the green box on the right. The reason that box includes
`both elements is shown on Slide 8. And in particular, Conley
`discloses that those devices, that telephone device and the
`computer, can be integrated into a single device, such as a
`cellphone with a built-in PDA or a PDA that has both cellphone and
`internet connectivity.
` And you have to remember that this is pre-iPhone era;
`right? So the PDA with cellphone is akin to the modern or more
`common smart phone. And this is the same thing that the '632
`patent discloses. Its remote can be something like a smart phone
`or a PDA.
` Going to be to Element 1-A, this element is not in
`dispute. This is, again, discussion of establishing a
`communication link in the '632 patent. It was Bluetooth, and
`Conley discloses the same thing. Between its first device and its
`local telephone device, which can be a cellphone, it establishes a
`Bluetooth connection.
` Now we get on to the dispute between the parties in
`Element 1-B. And in Element 1-B, the part of this thing that is
`in dispute again is this content of the invitation message. So
`first looking back at the embodiment in the '632 patent, what
`happens again is that there's in Bluetooth connection between the
`stationary terminal in blue and the proximate mobile device in
`red. And over that Bluetooth connection, the stationary terminal
`sends its IP address, which is the claims network address, and the
`cellphone number of the remote device, which is the claims remote
`8
`
`
`

`

`IPR2020-00463
`Patent 8,194,632 B2
`device identifier. This allows that proximal mobile device to
`send an SMS message containing that IP address to the cellphone
`number of the remote device.
` And in the petition, our argument is that Conley teaches
`or suggests the exact same thing. A computer that has the
`Bluetooth connection over which it sends its IP address, which is
`the claimed network address and the cellphone number of the remote
`device, to the proximate cellphone, which then is enabled to send
`an SMS message containing that IP address to the cellphone number
`of the remote device.
` JUDGE FENICK: Mr. Bell --
` MR. BELL: It's not in dispute -- yep. Yes, Your Honor.
` JUDGE FENICK: I understand from the arguments and from
`what you have shown on your Slide 8 that you're saying the remote
`device is both telephone 112 from Conley and device 142.
` Does Conley indicate that those are -- form a unified
`device or is Conley indicating that they -- they're housed in the
`same unit? In other words, is it a telephone with a cellphone
`number and a device with a remote device identifier? Because for
`your read here, you're using -- for the remote device identifier,
`you're using the phone number of the telephone 112 and not
`anything that relates to the remote device 142, if we look at them
`separately.
` So I guess my question is, what in Conley leads you to
`think that they're in some way one device as opposed to two
`devices that have just been contained in one enclosure, for
`example?
`
`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
`26
`27
`
`9
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
` MR. BELL: So, I mean, Conley paragraph 21 expressly
`discloses that they can be in a single integrated unit. That
`means that they're in a single device. It's a cellphone with a
`built-in PDA. So -- and if you look in particular at Claim 11, it
`also discloses that the -- one of the devices comprises both the
`personal digital assistant having a cellphone and internet
`connectivity. So the device has the capabilities of both acting
`like a PDA and acting like a cellphone. So the telephone number
`that identifies that device, that collective integrated unit
`identified as a whole. And that's actually the exact same thing
`that the patent discloses as the only example of a remote device
`identifiers. It's a telephone number that relates to a PDA or a
`smart phone.
` JUDGE FENICK: Paragraph 21 of Conley, the part that you
`have excerpted says that the telephone and device are a single
`integrated unit. The rest of that sentence says that there is a
`secure link, which may be accomplished by a direct connection. So
`is that a direct connection between two parts one of device or
`between two elements that are integrated into one container?
` MR. BELL: Well, I think it's a single device. It says
`that the computer and phone are a single, integrated device in
`paragraph 26, for example. And all it's saying is that you have a
`direct connection. If you have a PDA and a cellphone, you're
`going to have your standard processer that does its processing,
`but you're also going to have to have your radio that has the
`cellphone capability. The fact that they're all on the same unit
`means that, if you're identifying one part of that unit, you're
`10
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`identifying that whole unit. They're not separate things that
`need to be separately identified.
` JUDGE FENICK: Okay. Thank you.
` MR. BELL: So if we turn to Slide 13 and talking about
`what's in dispute here, which is the concept of a remote device
`identifier, we have a lot of unrebutted expert testimony that
`Conley system would teach or suggest that you would provide the
`remote device identifier in that initial communication between the
`computer in blue and the local cellphone in red.
` First, he has the testimony just generally that a person
`of skill would have understood that the stationary terminal would
`have provided the information necessary to forward the IP address
`to the remote device. This is because anyone with a basic
`understanding of networking, which a person of skill would have,
`would understand that you have to tell things where they're going.
`You can't just mail a letter without putting an address on it.
` But it goes even further, talking about the specific
`embodiment in Conley we're talking about, which is SMS. So if you
`go to slide 14, he testified that a person of skill would
`understand and have understood that SMS messages would require a
`destination address. This is because SMS has a minimum set of
`information that you have to provide to send an SMS message, and
`one of those things is the destination address. And the expert
`didn't just make this statement and pull it out of the ether; he
`backed himself up with a contemporaneous textbook.
` If you go to slide 15, we can see the excerpt of the
`textbook that he has that says the same thing that he says, is
`11
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`that the minimum SMS header consists of the 13 bytes, including
`the 8 byte destination address.
` Then the expert goes even further to talk about what a
`person of ordinary skill in the art would have understood to be
`happening in the exact circumstances in Conley, which is where you
`have a computer using a cellphone as a radio.
` So if we go to Slide 16, he testified that a person of
`skill would have understood that, when the computer sends an SMS
`message via a connect telephone, the computer provides the SMS
`message with the complete SMS_SUBMIT Transfer Protocol Data Unit,
`along with the command to send the message. And once again, the
`expert backed himself up with a textbook that was contemporaneous,
`and we can see on Slide 17 -- I have excerpted it for you -- we
`can see first that SMS_SUBMIT Transfer -- Transport Data Unit --
`that's a tongue-twister -- or TPDU; I'll just use that from now
`on -- includes -- still includes the destination telephone number.
` And if we go to Slide 18, and looking at what the
`textbook says, you transmit between the PC and the air modem,
`which is the cellphone, we have that complete TPDU being sent,
`along with the command to send the message, just like the expert
`testified. Accordingly --
` JUDGE McKONE: Could I ask a question? I'm sorry to
`interrupt you. Is this an argument that the phone number or
`destination address is inherent in SMS communications? I
`understand Patent Owner has characterized this as an inherency
`argument. Do you disagree with that characterization?
` MR. BELL: We did not argue inherency in the petition.
`12
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`If it was inherent, that would be an anticipation case. We argued
`that it is par -- or suggested by the inclusion -- par or
`suggested by the use of SMS. It is very close to being inherent,
`if it's not inherent.
` But what Patent Owner has done here is something that's
`pretty common where the Patent Owner comes in and tries to argue
`that, if something is not expressly taught, it must be inherent in
`order to be, you know, rendered obvious. But that's not the case.
`Instead, the board has to consider what's taught or suggested the
`a person of skill in the art. And, here, we only have evidence
`from one expert talking about what would have been taught and
`suggested or understood by a person of skill in the art.
` So they're just trying to sidestep the considerations
`that the board has to make, which is beyond inherency, which is --
`requires you to consider what the teachings and suggestions are of
`a particular reference. And the expert provided specific
`testimony on what you would get from a disclosure of SMS and this
`particular architecture that was being used in Conley, since that
`was the kind of things that was already being taught in the
`textbook, how to implement.
` JUDGE FENICK: Do your arguments --
` MR. BELL: However --
` JUDGE FENICK: Do your arguments relate only to the SMS
`embodiment and not to the voice connection embodiment?
` MR. BELL: Correct, Your Honor. We are relying on the
`SMS embodiment. As Your Honors noted in the institution decision,
`there are a number of different ways Conley discloses working.
`13
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`One is by having a voice channel, and the other is by using a data
`channel. And this is actually an important point that Uniloc
`tries to confuse, but, in Conley, when it's talking about having
`established communications, you have to think about what Conley
`actually discloses. And, in Conley, what's happening is you have
`two devices that want to talk, but they don't know each other's IP
`addresses. That's at paragraph 21.
` And then what happens is that it has to use an
`established means of communication to talk, which is in paragraph
`22. And in SMS, established means of communication just means
`that they know how to talk to each other, because you don't need a
`permanent circuit to be able to send the information. You can
`just address it as the expert opined.
` Finally, Element 1c on Slide 19, I believe we already
`addressed Your Honor's questions on this about the combination of
`devices 112 and 142 but the argument about the remote device
`identifier in Element 1c relates to that same thing. Uniloc's
`arguments don't respond directly to this fact that Conley
`discloses that you could integrate those into a single device.
` And with that, unless Your Honors have questions on the
`common ground alone, I'll turn to the Conley RFC combination.
`Very good.
` So the RFC, as Your Honor was just talking about, the
`SMS embodiment we're relying upon in the Conley alone ground, the
`RFC ground talks about the different type of primary channel that
`Conley discloses, and that's specifically an IP telephony network.
`And the RFC 3261 relates to the session initiation protocol, which
`14
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`is one of the well-known standards used to set up and communicate
`over IP telephony networks. And, in fact, it has a very similar
`type of handshake process to that disclosed by Conley.
` So if we go to Slide 21, I have copied a picture of the
`handshake process from the RFC on how it sets up a sub session.
`And in this session, they're trying to set up a direct media
`session between Alice's cellphone so that's, you know, a computer
`application, and Bob's phone, that's shown in purple. And how it
`does this is by using something called an invite that is forwarded
`through the IP telephony network. So it goes first to the
`Atlanta.com proxy and then the Biloxi.com proxy because, at that
`point in time, Alice and Bob don't know each other's direct
`addresses; they just know their SIP URIs, so they have to flow
`through the network.
` Going to Slide 22 where the modification comes in is
`this Element 1b where we were relying upon Conley's small amount
`of information that's being transmitted over this Bluetooth
`connection between Conley, which is connected to the primary
`channel through a cellphone. So it's starting its communication
`onto that channel through that Bluetooth connection.
` And going to Slide 23, when we start going to SIP,
`there's a very specific type of invitation message that's
`disclosed by that standard. And I have included it in the red --
`in the orange box on the left.
` And in our combination, which is shown on page 24, all
`we're saying is that you could use this known SIP invitation
`message as the small amount of information in Conley. And there's
`15
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`a reason for that.
` If you go to Slide 25, if you are using IP telephony and
`you're using the SIP invitation messages, those SIP invitation
`messages already have the information that the claim requires and
`that Conley requires. It has a remote device identifier, so
`that's a piece of information that's telling the invite how to get
`through the IP telephony network, the primary channel in Conley,
`to the remote device. And then you have the network addresses of
`Alice, your stationary terminal, that's originating the content.
` As we explained in the petition, the SIP standard
`discloses that both of these could include the direct IP address
`of Alice. And, in fact, in the RFC, the ultimate -- the ultimate
`result is that Alice and Bob can directly connect using each
`other's IP addresses.
` And turning to Element --
` JUDGE McKONE: Is Conley -- it's the telephone channel,
`is it a cellphone channel; am I correct there?
` MR. BELL: In Conley, there is a couple of different
`channels. One of the channels that -- the channel in this case is
`the IP telephony network. So it's not requiring the cellular
`network to be used, although you could use IP telephony over a
`cellular network.
` JUDGE McKONE: So it's your position, then, that the
`RFC3261 is an example of an IP telephony network that would have
`been used with Conley?
` MR. BELL: So, yes. The RFC does not actually disclose
`an IP telephony network. It describes the format of messages that
`16
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`are used in IP telephony networks to set up and tear down media
`sessions. And it's not just for IP telephony. SIP actually goes
`much broader. It can be used to set up video calling and all
`kinds of things beyond IP telephony. It's just the one that's
`commonly used for IP telephony.
` So we're saying that, since you're already using the
`primary channel, the example of the primary channel is this type
`of network, it would have been obvious to an expert -- in fact,
`Conley is directing pointing the expert to -- or a person of
`ordinary skill in the art to those types of messages, since
`they're already compliant and understood by that type of network.
` JUDGE McKONE: Okay.
` MR. BELL: On Slide 26, again, the SIP URI, that address
`for Bob is used in the SIP network because the way that it works
`is you flow through the network using that SIP URI by going
`through your various connections to the different points in the IP
`telephony network.
` Now we get to motivation to combine, and as Your Honors
`correctly noted, the expert provided a number of motivations that
`combined RFC with Conley here, and I think the most important,
`with which is the one that cuts through all of the arguments here,
`and that is that Conley expressly said that you could use IP
`telephony as the primary channel. So it gave a person of skill a
`direct path to protocols such as a SIP protocol in the RFC.
` There's also a number of other points that were made by
`the expert, including the benefits of standardization, including
`the commonalities between SIP and Conley, about they both use
`17
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`hand-safe protocols, that they both talked about having being able
`to set up these higher bandwidth types of communication sessions,
`and that they relate to different parts of the system. As we just
`talked about, the RFC tells you the format or the language in
`which you talk about -- in which the computers talk over an IP
`telephony network, and Conley specifies that you want to use an IP
`telephony network.
` Getting to, I think, Uniloc's main argument is that an
`invite message is too big to be used as a small amount of
`information in Conley, that's just not consistent with Conley.
`And, in fact, Uniloc doesn't really flesh out what they think a
`small amount of information could or could not be. Conley gives a
`number of examples of things of all different sizes that could be
`included in that information, such as additional information like
`security information, tokens, signatures, even a whole public key
`certificates. That's in paragraph 32, 34, 38, and 40.
` So it's not just an IP address that is the limit of a
`small amount of information in Conley. And, in fact, when you
`look at Conley, what it's really talking about is the distinction
`between something like a small amount of information like an
`initiation message and a large document or a video conference.
`That's the distinction it's drawing. And that's bared out by the
`fact that you have a low bandwidth channel and a high bandwidth
`channel, and the fact that one of the examples of the low
`bandwidth channel is IP telephony just suggests that messages that
`are compliant with that technology would not be something that
`would be too large to be used with that technology.
`18
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
` JUDGE FENICK: With respect to the combination, it seems
`like the SIP invite message includes the data that Conley is
`working to provide to the remote device. Conley's local device is
`trying to provide to -- in other words, if you already have all
`the information about the remote device, including phone number
`and the IP address, I guess the question is why are you using --
`why are you using the established telephonic channel to send this
`invite rather than sending it the way a SIP invite might otherwise
`be sent, you know, through an IP connection from the two computer
`devices?
` MR. BELL: That's a very good question, Your Honor. And
`I think the key comes back to Conley. So, in Conley, it's talking
`about a situation where you don't know each other's IP addresses.
`And when you're at the stage of sending an invite message, Bob's
`SIP URI -- the stationary terminal does not have knowledge of
`Bob's IP address. It only knows Bob's SIP URI. It's not until it
`gets this OK response message -- if you go back to Slide 21, for
`example -- that it receives Bob's reply that includes the IP
`address of Bob. So it actually does not know how to communicate
`with Bob directly over the internet until it does this initial
`exchange.
` And that was our reason for our combination is that
`Conley could have just used those invite messages, and a person of
`ordinary skill would have understood that, that, when you provided
`that, it give Bob Alice's IP address. And, at that point, that
`triggers Conley's system, because Conley discloses at that point,
`in paragraph 23, that you can do a service discovery protocol
`19
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`request on that IP address and then you can set up the connection
`over the secondary channel.
` JUDGE FENICK: Thank you.
` MR. BELL: And if Your Honors don't have any further
`questions, I don't have anything further.
` JUDGE FENICK: Yeah, I do. I'm sorry. In the
`Conley-only ground, I'd like to ask about the part of the -- of 1c
`that talking about establishing communication. So 1c, for
`example, on your Slide 19, says that the proximate mobile device
`establishes communication with a remote device using the remote
`device identifier.
` Conley's method -- so the flowchart, for example, given
`Figure 4 of Conley -- describes the process as waiting until user
`is in conversation. As a matter of fact, it explicitly, I think,
`says that if the user isn't, then it just kind of endlessly loops
`around.
` So how do you square that with the requirement in this
`claim limitation that the proximate mobile device establishes
`communication with the remote device using the remote device
`identifier.
` MR. BELL: So, Figure 4 in the flowcharts are of course
`in Conley indicated that it's just exemplar embodiments. And
`they're all tied to this voice channel embodiment where you need
`to have this established circuit connection set up where this is
`the whole thing of the conversation, right, is you need to be in
`conversation over a voice channel so that you can encode the
`information to go over it. You don't need to do that in the SMS
`20
`
`
`

`

`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
`26
`27
`
`IPR2020-00463
`Patent 8,194,632 B2
`embodiment.
` And when you look at what it talks about for having
`established communication in Conley -- I'm sorry, I'm just going
`to get to the

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

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.

throbber

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.

Become a Member

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

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket