trials@uspto.gov
`
`
`571-272-7822
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2015-00343 Paper No. 29
`Case IPR2015-00345 Paper No. 29
`Case IPR2015-00347 Paper No. 29
`Case IPR2015-00348 Paper No. 29
`April 13, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GOOGLE, INC.,
`Petitioner,
`
`v.
`
`NETWORK-1 TECHNOLOGIES, INC.,
`Patent Owner.
`____________
`
`Case IPR2015-00343 (Patent 8,640,179 B1)
`Case IPR2015-00345 (Patent 8,205,237 B2)
`Case IPR2015-00347 (Patent 8,010,988 B2)
`Case IPR2015-00348 (Patent 8,656,441 B1)
`____________
`
`Held: March 9, 2016
`____________
`
`
`
`
`
`BEFORE: KEVIN F. TURNER, LYNNE E. PETTIGREW, and
`JON B. TORNQUIST, Administrative Patent Judges.
`
`The above-entitled matter came on for hearing on Wednesday,
`March 9, 2016, commencing at 2:05 p.m., at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`571-272-7822
`
`
`
`
`
`
`
`
`
`
`
`Case IPR2015-00343 Paper No. 29
`Case IPR2015-00345 Paper No. 29
`Case IPR2015-00347 Paper No. 29
`Case IPR2015-00348 Paper No. 29
`April 13, 2016
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`GOOGLE, INC.,
`Petitioner,
`
`v.
`
`NETWORK-1 TECHNOLOGIES, INC.,
`Patent Owner.
`____________
`
`Case IPR2015-00343 (Patent 8,640,179 B1)
`Case IPR2015-00345 (Patent 8,205,237 B2)
`Case IPR2015-00347 (Patent 8,010,988 B2)
`Case IPR2015-00348 (Patent 8,656,441 B1)
`____________
`
`Held: March 9, 2016
`____________
`
`
`
`
`
`BEFORE: KEVIN F. TURNER, LYNNE E. PETTIGREW, and
`JON B. TORNQUIST, Administrative Patent Judges.
`
`The above-entitled matter came on for hearing on Wednesday,
`March 9, 2016, commencing at 2:05 p.m., at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`
`
`
`
`
`
`
`
`JAMES J. ELACQUA, ESQ.
`DOUGLAS R. NEMEC, ESQ.
`ANDREW GISH, ESQ.
`Skadden, Arps, Slate, Meagher & Flom LLP
`525 University Avenue
`Palo Alto, California 94301
`
`
`
`
`
`
`
`
`and
`
`RICHARD A. SONNENTAG, ESQ.
`Google, Inc.
`1600 Ampitheatre Parkway
`Mountain View, California 94043
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`GREGORY DOVEL, ESQ.
`Dovel & Luner LLP
`201 Santa Monica Boulevard, Suite 600
`Santa Monica, California 90401
`
`and
`
`CHARLES R. MACEDO, ESQ.
`Amster Rothstein & Ebenstein LLP
`90 Park Avenue
`New York, New York 10016
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
` 2
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`P R O C E E D I N G S
`- - - - -
`JUDGE PETTIGREW: Good afternoon, everyone.
`This is a consolidated hearing for four cases, IPR2015-00343,
`IPR2015-00345, IPR2015-00347, and IPR2015-00348, Google,
`Inc. versus Network-1 Technologies, Inc.
`Each side has 60 minutes to argue. Petitioner, you have
`the ultimate burden of establishing unpatentability, so you will
`argue first. Patent Owner then will present its opposing
`argument. Finally, Petitioner may use any time it has reserved for
`rebuttal to respond to Patent Owner's argument.
`Judge Turner is joining us by video and audio from our
`Silicon Valley office, and won't have the benefit the visual cues
`in the room. So, when you speak about an exhibit or a
`demonstrative, please begin by identifying it with specificity,
`including the particular page or slide number. Also, please be
`sure to speak into the microphone to ensure that Judge Turner can
`hear you.
`Counsel, when you begin your argument, please
`identify yourself and the party you represent for the record.
`Petitioner, you may begin when ready.
`MR. ELACQUA: Thank you, Your Honor.
`
` 3
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`JUDGE PETTIGREW: And do you wish to reserve any
`rebuttal time?
`MR. ELACQUA: Yes, we wish to reserve 35 minutes.
`JUDGE PETTIGREW: Thirty-five minutes?
`MR. ELACQUA: Yes.
`JUDGE PETTIGREW: Thank you.
`MR. ELACQUA: And we have hard copies of the
`slides for the Board, if you would like.
`JUDGE PETTIGREW: Yes, that would be useful,
`thank you.
`JUDGE TURNER: And, Judge Pettigrew, can I just
`confirm that you can hear me fine?
`JUDGE PETTIGREW: We can hear you, Judge
`Turner, thank you.
`JUDGE TURNER: And I apologize to the parties for
`the delay, which perhaps was on our end out here in Silicon
`Valley. So, accept my apologies for our brief delay in getting
`started today.
`JUDGE PETTIGREW: All right, please begin.
`MR. ELACQUA: Thank you. Good afternoon, Your
`Honors. My name is Jim Elacqua and I'm hear this afternoon
`with Doug Nemec and Andrew Gish, also from Skadden, and
`Rich Sonnentag, in-house counsel for Google. We are here today
`representing Google on these four IPRs that involve 90 claims.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 4
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`And this afternoon, I'm going to be using a slide deck, and the
`slide deck is Exhibit 1022 for IPRs 343, 347 and 348, and Exhibit
`1021 for IPR 345. The numbering of the slides is identical for all
`the exhibits.
`Now, even though we have four IPRs and 90 claims,
`there are actually a limited number of issues for the Board to
`decide, and also interesting, the dependent claims are not
`contested for any of the patents and the motivation to combine is
`not contested on any of the obviousness issues. So, that again is
`limiting the number of decisions that the Board is needing to
`make.
`
`There are only really two main limitations contested,
`and if we go to slide 2, we will see that there are three references
`that we are going to be dealing with this afternoon, Ghias,
`Iwamura and Conwell, and the two main limitations are
`nonexhaustive search, regarding all the patents and all the
`references, and the near neighbor terms, which include
`identifying a neighbor and neighbor search. And that involves
`three of the patents, the '988, '179 and '441, and all of the
`references.
`There's another limitation we'll talk about and that's
`determining an action, which only involves the '988 patent and
`the Ghias reference. Now, if we go to slide 3, we will see that all
`of the contested limitations were widely known, and we took the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 5
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`deposition of Dr. Karypis, and Dr. Karypis was at deposition, it
`was offered as an expert by Network-1, and we'll refer to his
`deposition from time to time. But in his deposition, we asked
`him, did Dr. Cox in the disclosure of his patents purport to have
`invented nonexhaustive searching, and he said no. And we also
`asked him if it was known in the art, and he said that that concept
`was known in the art.
`We also similarly asked him about neighbor searching,
`did Dr. Cox invent that, and he said, I don't believe so. And we
`asked if that concept was well known and he agreed that that
`concept was well known.
`So, we're dealing with what these limitations are, they're
`very broadly defined in these claims, and they're also very well
`known in the art. First I would like to discuss the Ghias
`reference, I would like to go reference by reference, I think it's
`easiest that way. And the Ghias reference involves, excuse me,
`the issues, if we go to slide 6, nonexhaustive, identifying a
`neighbor and determining an action. And the Board has actually
`provided us with a claim construction on this issue.
`Next slide. We'll go to slide 6 now, and we will see that
`the claim construction that the Board offered was a search that
`locates a match without a comparison of all possible matches, and
`we'll also see that in the Board's '988 institution decision, the
`Board agreed that anything that was not brute force, any search
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 6
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`that was not considered to be a brute force search, is a
`nonexhaustive search.
`Now, Ghias, the question is, does Ghias teach a
`nonexhaustive search, and Ghias does. If we go to slide 7, we
`will see that Ghias self-identifies a different than brute force
`search, and the Board has properly identified a second search in
`Ghias that also is a nonexhaustive search. So, let's deal with them
`one at a time, quickly.
`The first one is, Ghias, just to give some background,
`represents the queries and the references as a string of characters,
`U, D and S, which represent pitch differences between the notes,
`because after all, we're looking for a musical work. Now, Ghias
`matches a short query to certain melody segments within the
`song, and Ghias actually describes its comparison of the query to
`each reference as nonexhaustive.
`So, let's look at slide 8, and we will see how it does that.
`Ghias tells us, in Exhibit 1010, slide 8, that running times have
`ranged from the order of mn for brute force algorithm to the order
`of kn or the order of nlog(m). Now, what that tells us is what
`Ghias is saying is that what they're using for a search is
`something different than brute force, and as I said, the Board
`recognized and the parties are not disputing that searches that are
`different from brute force are nonexhaustive searches.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
` 7
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`JUDGE PETTIGREW: Is that the comparison of
`excerpts from the melody to a single record that's being discussed
`in column 6?
`MR. ELACQUA: No, that was brought up in a
`different context, but this is the same quote that that issue has
`arisen from. And you're correct, Your Honor, that what they have
`asked here in their office -- in their Patent Owner response, they
`made the statement that this was restricted to a single song, and
`we can deal with that now or we can wait, but, Your Honor, our
`position is that this is not restricted. This is a definition that they
`provided that they're saying the searches that they're using, they're
`using searches other than brute force.
`So, for purposes of our prima facie case here, this
`shows that Ghias actually is using a nonexhaustive search. And
`we do not believe it's limited to a single song. And, in fact, as we
`can show, Ghias actually demonstrates, also, and teaches, that
`you can pack all of the songs into a single file. And to the extent
`that you can pack them all in a single file, you could use that
`same nonexhaustive search.
`Now, we also looked to its second reason why Ghias is
`teaching us a nonexhaustive search and this is one that the board
`found as well, and that is in looking at Ghias, we see that it is
`dealing with a multiple search process, where subsequent
`searches consider progressively narrower sets of references.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 8
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`So, looking at slide 5 for a moment, we'll see that this is
`the way that it actually works in Ghias, with each subsequent
`search looking at a more restricted list. Now, if this list becomes
`too large, what Ghias tells us is that the user can perform a new
`query on the restricted search list, which consists of just the songs
`that were retrieved. So, looking, again, if we look at -- we can
`see that Ghias says this on slide 10.
`Now, looking again, if we look at slide 9, we'll see that
`this restricted list with the new query, the fact is, is that you're not
`considering all possible matches, which is the requirement in the
`claim construction that the Board provided. So, Ghias actually
`provides a nonexhaustive search. And the Board agreed, on slide
`11, we'll see that in the Board's '988 institution decision, the
`Board actually agreed that with this new query on the restricted
`search list, the Board goes on to say, Ghias makes clear that the
`search need not be exhaustive.
`So, again, we presented two reasons, it's self-identifying
`in the way Ghias has presented this as a non-brute force search,
`and also just by the way that the search actually operates.
`I'd like to move on to the second issue for Ghias, which
`is the neighbor search, and the Board has also provided us with a
`definition for neighbor search, which is identifying a neighbor as
`identifying a close but not necessarily exact or closest match.
`That's on slide 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
`
` 9
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`Now, the parties have different positions on this as to
`what a neighbor search includes. Google takes the position that it
`includes searches that always find the closest match. The Patent
`Owner has a new interpretation that they set forth in their
`response that said, oh, no, that wording of the claim construction
`does not include searches that always find the closest match. So,
`with that said, if we go, you can see it in this diagram, those
`searches are called nearest neighbor searches. Our position is that
`they are included in the definition of neighbor search, Patent
`Owner's position is that they are not.
`And there are several reasons why that is wrong. The
`first one is, just as a matter of grammar, if we look at the
`grammar on slide 14, we see that the Board's language reads, "not
`necessarily exact or closest." What Network-1 would have us
`read this to mean is "necessarily not exact or closest." And that is
`not a fair grammatical reading of the words themselves.
`But just as important, we have a contradiction with the
`intrinsic record. The intrinsic record contradicts by the claim
`language itself that it improperly excludes searches that always
`find the closest match, which are nearest neighbor searches. So,
`if we look at slide 15, we will see, in claim 15 of the '988 patent,
`it calls for identification based on a nonexhaustive search
`identifying a neighbor.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
` 10
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`Now, if we go to slide 16, we will see that there are
`three dependent claims, 18, 19 and 20, that both tell us that it is
`based on these new types of searches, kd-trees, vantage point
`trees and middle vantage point trees. But the specification in the
`Cox patents tell us that these particular types of searches are
`nearest neighbor searches. In fact, the '237 patent, which is
`Exhibit 1001, at column 9, lines 7 to 9, tells us that kd-tree
`method, which finds the nearest neighbor with certainty, and it's
`the same for all of these that are listed in these dependent claims.
`Why is that important? Because the fact that it's
`identifying these as a nearest neighbor search, the Cox patents tell
`us -- can we see slide 17, please? The Cox patents tell us, Exhibit
`1021, that the nearest neighbor search always finds the closest
`point to the query. So, the nearest neighbor searches are a type of
`neighbor search, just by a plain reading of the claim language
`itself.
`
`So, Petitioner's interpretation that it excludes finding the
`closest -- always finding the closest match is actually incorrect,
`because the claims call for that specifically.
`Now, there could be no dispute that the Ghias reference
`actually locates a close match. If we look at the slide 18, we will
`see that right within the reference itself, it talks about the output
`as a rank list of approximately matching melodies. It tells us.
`These are close matches. They're approximately matching
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 11
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`melodies. And, of course, figure 1 on slide 18 confirms that and
`shows that the ranked list is part of the output.
`There can be no dispute that there is a close match here.
`And a close match is what it takes to meet the claim language and
`the claim construction that the Board has provided.
`There's one other in Ghias, and that is determining an
`action. Now, I can't believe that this is going to be seriously
`challenged, but I want to just address it. Action really refers
`broadly to any act that a system executes based on the
`identification of a work. So, once the work is identified after the
`search, there is an action.
`What is -- what does Ghias tell us about that? If we
`look at slide 19, Ghias says, "the set of possible actions is
`potentially infinite," and we also asked Dr. Karypis in his
`deposition, and if we look at slide 20, we will see what he said,
`and we asked him the question, and he said, "I cannot really think
`of anything. I mean outside, you know, the constraints of the rest
`of the words in this step." That's not in the scope of what action
`actually means.
`So, I can't believe that there is going actually be a
`serious challenge on this, but if we look at the Ghias patent itself,
`on slide 21, it tells us that the database returns a list of songs, in
`the results of the query, the user can identify the song of interest.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
` 12
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`So, that is the action, and I don't think there is going to be any
`really serious challenge to that.
`JUDGE PETTIGREW: Now, that takes place, at least
`the way it's presented there at the bottom of column 6 and top of
`column 7, after that, starting at line 5 of column 7, it says, "if the
`list is too large, the user can perform a new query on a restricted
`search list," which is one of the things that you said is the
`nonexhaustive search.
`MR. ELACQUA: That's correct.
`JUDGE PETTIGREW: I assume that you're implying
`that after that second search, there is also a display or an output of
`a list of songs.
`MR. ELACQUA: Yes, there could be an action as a
`result of each of the searches or at the end of the search.
`JUDGE PETTIGREW: All right, thank you.
`MR. ELACQUA: I would like to now move to the
`Iwamura reference, which is the second of our references. And
`here we have three issues, the nonexhaustive search issue,
`identifying a neighbor and sublinear. Now, there's a mistake on
`the slide here on slide 22, it should say three claims, not two
`claims for the '237 patent. And I'm going to preview Iwamura for
`just a moment.
`Iwamura represents musical works as a series of
`numbers, and those numbers are relative pitch differences
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 13
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`between adjacent notes. And to compare references, Iwamura
`computes the absolute differences between the query and the
`melody segments.
`Now, what's very important in understanding Iwamura
`is that Iwamura does not compare the query to every reference
`segment, but only makes comparisons where the peak notes
`alone, and peak note is defined as a note that is higher than or
`equal to each of the adjacent notes. So, we're dealing with a peak
`note algorithm.
`Now, the Patent Owner's position here is that matches
`equals songs and matches do not equal melody segments, but this
`is -- this is incorrect, for several reasons, and we'll see that if we
`look at the Patent Owner's response and the diagrams presented to
`illustrate certain positions by Dr. Karypis on slide 26, we will see
`that this is not correct. Because Dr. Karypis actually illustrates
`the nonexhaustive nature of Iwamura's search algorithm by
`putting segments and comparing the segments and actually taking
`the absolute differences which he totals up and circles. And then
`he shifts to the next peak and does the same thing.
`And, further, Iwamura nowhere in its disclosure,
`nowhere, calculates the overall difference or average difference
`between a query and a work over the entire length of a song. It's
`only done the way this is illustrated here, which is, again, from
`the Patent Owner's own response.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 14
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`Finally, at his deposition, Dr. Karypis confirmed that a
`single reference song may contain multiple matches. So, at his
`deposition, we put before Dr. Karypis a query, 5, 4, 3, 2, 1, on
`slide 27, and a reference. And he stated that in that reference, he
`found four portions that match exactly to the query. Now, the
`whole song cannot be the match. If he recognizes and considered
`that what he was matching to were segments and that he found
`four of them matched in that single reference point.
`So, his position on this is very consistent with
`Petitioner's position that we are matching melodies, we're not
`matching entire songs.
`JUDGE TURNER: Counselor, can I ask a quick
`question before you move on?
`MR. ELACQUA: Sure.
`JUDGE TURNER: In Iwamura, the database is made
`up of records; what are those records in Iwamura?
`MR. ELACQUA: The records in Iwamura is a string of
`numbers that represent the differences between the pitches in the
`notes of the song. And the only -- the only segments that are
`actually matched up against the query is when they align with the
`peak note in that string of numbers.
`JUDGE TURNER: But each record is a song. Is that
`correct?
`MR. ELACQUA: That's my understanding.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 15
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`JUDGE TURNER: So, and I guess the follow-up
`question I would have would be in Iwamura, isn't each record
`examined when you search?
`MR. ELACQUA: Each record -- each record or each
`song, yes, is looked at. The question is, in the search, is the
`match of the query to the song or is the match of the query to
`each segment that's aligned with the peak, and in Iwamura, it does
`not ever match the query, which can be, for example, a
`hummed -- a shortened hummed version of the song, or a, you
`know, a version that is played out in a short sequence on a piano
`or something. So, that short query is then compared only to the
`peaks in the notes. It's never compared to the entirety of the song.
`JUDGE TURNER: No, I understand that, but I guess
`my question would be, how is the basic search in Iwamura
`nonexhaustive if it looks at every single song? If it looks at every
`single record, how is that nonexhaustive?
`MR. ELACQUA: Because it's our position that when
`you're talking about possible matches, here in Iwamura, just like
`in Ghias, you're not looking to match the query to the entire song,
`because a match has to be the query to something. And the fact
`that they are just touching a note in the song wouldn't be
`sufficient to say that's actually how the match is being done,
`because the extracted features here are the extracted features are
`coming from the differences in the pitches of the song notes
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 16
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`themselves against each other. And what's being matched is the
`query, which is in this case, that we're showing on 27 an example
`of, would be, you know, five notes with the relative pitch
`differences, and it would only be lined up against the references
`that have the peak notes.
`JUDGE TURNER: So, would it be fair to say that
`Iwamura, the search is exhaustive with respect to the records, but
`nonexhaustive with respect to the features?
`MR. ELACQUA: It's nonexhaustive with respect to
`what is actually being matched. It's nonexhaustive with respect to
`what you're matching it to. You're not matching that query to the
`entire song at one time. You're going through a series -- a
`process which is a searching process of taking the query against
`each segment. That's what's being matched. Those are the
`possible matches that we're dealing with. We're not dealing with
`the entire song.
`We concede that every song is looked at.
`JUDGE TURNER: Okay.
`MR. ELACQUA: But we're not conceding that that's
`the match. That's not the match that we're talking about.
`JUDGE TURNER: Right.
`MR. ELACQUA: In fact, in a brute search, and in fact,
`we can show this. Andrew, can you put up the chart that we
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
` 17
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`have, I will just show as an example, the square box chart. I
`apologize, we've lost the slide presentation.
`I think this might be helpful at this point. Again we're
`dealing with Iwamura and this is another instance where we
`presented this chart to Dr. Karypis at his deposition.
`JUDGE PETTIGREW: I'm sorry to interrupt, this is
`slide 65.
`MR. ELACQUA: Sixty-five. I'm sorry, Judge Turner,
`it's slide 65.
`JUDGE TURNER: Fifty-five?
`MR. ELACQUA: Sixty-five, thank you.
`JUDGE TURNER: Sixty-five, thank you. Got it.
`Thank you.
`MR. ELACQUA: So, here is the query, 5, 4, 3, 2, 1,
`and you see the reference base below it at the top of the box. If
`we were to do a brute force search or an exhaustive search, we
`would do each one of these 16 comparisons. But, in fact, because
`this is a peak note search, there's only two comparisons that are
`actually done, and the two comparisons are number 5, where you
`see the asterisk, because the 5 is lined up with the peak note 6 in
`the reference, which is asterisked at the bottom. And you see
`comparison 11, which is asterisk 5 and asterisk 6.
`And Dr. Karypis, as we will see, has admitted that those
`are the only two comparisons done and the other comparisons are
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 18
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`not complete. They're not -- they're never performed. And, in
`fact, you will also see, if you look at comparison 12, that's an
`exact match. We know that because if you look at the right-hand
`column, where the total absolute differences are, it lists zero. So,
`that shows that it's an exact match. That exact match is never
`performed and never found.
`So, if we were to do an exhaustive search using that
`query against the reference, that's what it would look like, 16
`comparisons and, in fact, the way Iwamura does it, there's only
`two.
`
`I will now move on to the neighbor search. Iwamura
`also has neighbor search as an issue. If we go back to slide 28,
`we will see that, again, we're using the same construction, of
`course, that we used with Ghias. And here, there can be no
`dispute that Iwamura locates a close match. We go to slide 29,
`we'll see that in Iwamura itself, it tells us that "the reference
`melody that gives the least difference is returned as a search
`result."
`
`The last reference that I want to discuss is Conwell, it's
`the last of the three references. And with Conwell, there's only
`two issues, identifying a neighbor, and nonexhaustive search.
`But to really understand Conwell, I believe it's important to
`understand hashing. And I want to make sure that we're all on the
`same page there.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 19
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`So, I would like to provide just a quick review of that.
`Now, a hash is a mathematical algorithm that converts a large file
`into a much smaller number in a deterministic manner. The same
`file will always yield the same hash value. But there are other
`types of hash algorithms. For example, if we have slight
`differences in the input file, in some hash algorithms, you will
`still yield the same hash value. In others, a slight difference in
`the input value will yield a dramatically different hash value.
`So, when looking at Conwell, we first need to decide
`what type of hashing is used in Conwell. Conwell tells us, on
`slide 31, "of course, by suitably designing the algorithm by which
`identifiers are derived, nonidentical versions of the same basic
`content may nonetheless correspond to the same identifier."
`There is extensive published research on such technology, e.g.
`hashing algorithms by which similar or related, but non-identical,
`inputs map to the same hash outputs."
`So, we know that's the type of hashing that's being
`done, and the Board understood that and agreed in its institution
`decision for the 343 IPR at paper 6, page 11, and actually, the
`Patent Owner also agreed in the Patent Owner response, paper 17
`at 21.
`
`JUDGE PETTIGREW: Mr. Elacqua, you are into your
`rebuttal time, would you like to take a few more minutes and
`continue?
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 20
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Patent
`8,010,988 B2); Case IPR2015-00348 (Patent 8,656,441 B1)
`
`
`MR. ELACQUA: Yes, I would like to take a few more
`minutes and finish up here. I have just a few more things to say
`about Conwell. And one is that Conwell actually extracts a hash
`value from a query work and transmits it and then looks it up in
`identifier database using a standard database query. And based
`on that, there is a URL that is sent to the user.
`So, the question is, does Conwell, does it teach a
`neighbor search, and yes, it does teach a neighbor search, because
`the same hash can represent works that are similar, but not
`exactly the same, and this search can locate near matches. So,
`Conwell does perform a neighbor search. And if we look at slide
`34 quickly, the Board actually agreed with that.
`The final issue on Conwell that I will touch on is
`nonexhaustive, we're using the same construction. The sole
`dispute in Conwell is not whether or not the searches for matches
`are using a database query, but whether that database query is
`nonexhaustive. And the position that Patent Owner has been
`taking is that they argue that since it can also possibly be an
`exhaustive database query and not just a nonexhaustive one, it's
`not inherent, but inherency is not really the issue we're saying
`here.
`
`We're saying Conwell literally discloses a
`nonexhaustive search. And we know that because Dr. Cox, the
`inventor of these four patents, tells us. And if we look at slide 36,
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
` 21
`
`
`
`
`
`
`
`Case IPR2015-00343 (Patent 8,640,179 B1); Case IPR2015-
`00345 (Patent 8,205,237 B2); Case IPR2015-00347 (Paten
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
