`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`____________
`
`MICROSOFT CORPORATION,
`Petitioner,
`
`v.
`
`MIRA ADVANCED TECHNOLOGY, INC,
`Patent Owner.
`____________
`
`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`____________
`
`Record of Oral Hearing
`Held: June 21, 2018
`____________
`
`
`
`
`Before MINN CHUNG, MICHELLE N. WORMMEESTER, and
`KAMRAN JIVANI, Administrative Patent Judges.
`
`
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`ANDREW M. MASON, ESQUIRE
`Klarquist Sparkman, LLP
`One World Trade Center
`121 SW Salmon Street
`Suite 1600
`Portland, OR 97204
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`JUNDONG MA, ESQUIRE
`JDK Patent Law, PLLC
`6801 Kenilworth Avenue
`Suite 120
`Riverdale, MD 20737
`
`
`
`The above-entitled matter came on for hearing on Thursday, June 21,
`2018, commencing at 1:30 p.m., at the U.S. Patent and Trademark Office,
`600 Dulany Street, Alexandria, Virginia.
`
`
`
`
`2
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`
` P R O C E E D I N G S
`- - - - -
`JUDGE WORMMEESTER: Good afternoon everyone. We have our
`final hearing in cases IPR2017-01052 which concerns U.S. patent No.
`8,848,892 and IPR2017-01411 which concerns U.S. patent No. 9,531,657.
`I'm Judge Wormmeester. Judges Chung and Jivani are appearing remotely.
`Let's get the parties' appearances, please. Who do we have for Petitioner?
`MR. MASON: Yes, Your Honor. On behalf of Petitioner, Microsoft
`Corporation, Andy Mason of Klarquist Sparkman.
`JUDGE WORMMEESTER: Thank you.
`MR. MA: Your Honor, I'm the attorney for the Patent Owner. My
`name is J.D. Ma, I go by J.D.
`JUDGE WORMMEESTER: Thank you. Welcome. We set forth the
`procedure for today's hearing in our Trial Order but just to remind everyone
`the way this will work. Each party will have 60 minutes to present
`arguments. Petitioner has the burden and will go first and may reserve time
`for rebuttal. Patent Owner will then have the opportunity to present its
`response. Please remember that Judges Chung and Jivani will be unable to
`hear you unless you speak into the microphone. Also when referring to any
`demonstrative, please state the slide number so that they can follow along,
`and this is a reminder that the demonstratives as submitted are not part of the
`record. The record of the hearing will be the transcript. We will give you a
`warning when you're into your rebuttal time or reaching the end of your
`argument time. Any questions before we proceed?
`Okay. Counsel, will you be addressing the cases together or
`separately today?
`
`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
`
`3
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`
`MR. MASON: Yes, Your Honor. I plan to address them together
`since the primary issues seem to affect both IPRs.
`JUDGE WORMMEESTER: Okay, great. Thank you. If you do
`address one as opposed to the other, please remember to identify the case
`you're referring to while you're presenting your arguments. Also, will you
`be reserving any time?
`MR. MASON: Yes, Your Honor. I'll reserve 30 minutes for rebuttal.
`JUDGE WORMMEESTER: Thirty. Okay. All right, you may begin
`when you're ready.
`MR. MASON: Thank you, Your Honor. Can everybody hear me
`okay remotely?
`JUDGE CHUNG: I'm sorry, excuse me. The podium microphone
`needs to be turned on. We can't hear you.
`MR. MASON: Okay, thank you.
`JUDGE WORMMEESTER: Okay. Just to recap for Judges Chung
`and Jivani. Counsel will be presenting the arguments with respect to both
`cases together today and he has reserved 30 minutes for rebuttal.
`JUDGE CHUNG: Very good.
`JUDGE WORMMEESTER: You may start when you're ready.
`MR. MASON: Okay. Can everybody hear me remotely now?
`JUDGE JIVANI: No, still can't hear you.
`
`(Pause.)
`JUDGE WORMMEESTER: Okay, when you're ready.
`MR. MASON: May I proceed? Okay, great. Thank you, good
`afternoon and may it please the Board. We're addressing two IPRs today
`both relating to the 892 and 657 patents, related patents from the same
`
`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
`
`4
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`family. The primary issues today are dispositive as to all grounds in both
`IPRs and so I'm going to be addressing those issues together.
`Specifically, and if we turn to slide 2 of our Microsoft demonstratives
`here we've got the asserted grounds listed and throughout today's
`proceedings I'll refer to the Matsumoto based grounds which have
`Matsumoto as the primary reference and that relates to the issue surrounding
`the construction of contact list. So I'll refer to that as the contact list issue,
`and then as we see on slide 2 there are Sony based grounds which rely on
`Sony as primary reference, and the issue relating to those grounds is what I
`will call the single storage issue throughout today's proceedings.
`So relating to those two issues, there's two points that I'd like to make
`today. One is that with respect to contact list, the Board's construction is
`proper under the BRI under Phillips and under that construction Matsumoto
`satisfies the claim contact list and renders all challenged claims patentable
`under those Matsumoto based grounds.
`The second point which I'll cover is that single storage. It would have
`been obvious for the Sony based grounds to modify Sony to use a single
`storage for both the user information as well as the memo or reminder field
`and under once combined in that manner, all claims are rendered obvious on
`those Sony based grounds.
`So jumping them to slide 4, we'll get into the contact list issue, or
`excuse me, slide 5. I'll turn to slide 5, shows figure 1 of the challenged
`patents. This is cited in both petitions and just going over it briefly, we've
`got within this contact list each row is what's called a contact list entry and
`then there are columns in those rows that have data fields for them. So
`they're conveying this concept of a database or something that's kept 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
`26
`
`5
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`storage.
`The Board, if we turn now to slide 6, in both proceedings
`preliminarily construed contact list and contact list entry in a manner
`consistent with the specification. It looked at column 2 of the specification,
`it considered certain arguments made by Patent Owner and determined that
`the BRI of contact list was an electronic list comprising contact list entries,
`and similarly for contact list entry that was construed as an item in a contact
`list comprising data fields to input contact information details.
`JUDGE CHUNG: Counsel, can you hear me?
`MR. MASON: Yes, I can hear you.
`JUDGE CHUNG: This is Judge Chung from California. So I have a
`question about the -- it's a general question about the standards of the claim
`construction. Would you agree -- you mentioned both Phillips and BRI in
`the beginning of your presentation and my question is would the
`construction of the term contact list or contact list entry be the same under
`either standard, BRI or Phillips?
`MR. MASON: We contend that it would. The parties candidly have
`not briefed the Phillips or District Court construction but we understand that
`the Office is considering maybe moving to that standard and including for
`current proceedings, and so under that standard we've considered it and think
`that the Board's construction would also be proper under Phillips and as
`importantly, Patent Owner's proposed construction would be improper under
`the District Court standard as well.
`JUDGE CHUNG: Okay. Thank you.
`MR. MASON: And so I'll discuss now why the Board's construction -
`- what's proper in view of the intrinsic evidence. So if we turn to slide 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
`
`6
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`slide 7 is 657 patent claim 1. The claim 1 language shows that contact list,
`the Board's construction is proper. Specifically it discusses the computer
`device or this communication device having access to a memory storing a
`contact list.
`So this conveys a few concepts. One, that the contact list is stored in
`memory and that it is accessed. In addition, it's the communication device.
`It's not a user accessing that information, this is conveying this concept that
`the processor of the device is able to use what's in this contact list database
`in whatever means it deems necessary. Nothing here recites that there is a
`user interface. Nothing recites display of the contact list itself and because
`everything in this claim language suggests that the contact list is something
`in storage, something in memory, i.e., a database.
`If we turn then to slide 8, this is claim 1 of the 892 patent. Slightly
`different language but for many of the same reasons it also conveys that this
`contact list is something in storage and supports the Board's construction.
`Then if we turn to slide 9, slide 9 is claim 3 of the 892 patent. There's
`also similar language in claim 9 of the 657 patent, and what claim 3 of the
`892 shows on slide 9 is a couple of things, but the memo data is displayable
`or otherwise playable to show the at least one memo of the memo data. So,
`again, this is referring to what's in the contact list as data and it's saying it's
`displayable. Again, it's not even reciting that this is displayed here, it's just
`saying that it's data and it can be, like anything that's stored in memory in a
`database, things can be done to it, it can be displayed, it can be presented to
`a user but the claim does not affirmatively recite that.
`It also shows that Patent Owner had at its disposal terms such as
`display or show and if it had wanted to during original prosecution or even
`
`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
`
`7
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`during the proceedings, it could have sought to amend the claims to include
`these concepts of displaying or providing a user interface, and I don't know
`that there'd be support for such claims given that this is just a two column
`specification and it doesn't even really contemplate a user interface in that
`specification but nonetheless, Patent Owner has not sought claims that
`require the contact list be a user interface or otherwise display the contact
`list itself.
`Turning now to slide 10, we get into the specification and this is from
`the 892 patent, column 2. There's similar language in the 657 patent as well.
`I should just mention that there's no material differences between the
`specifications of these two patents, so if I'm referring to the 892 here today,
`it'll be a similar citation in the 657 patent.
`So what slide 10 shows is that here they're discussing the contact list
`and they describe it as something very simple. It's provided and it comprises
`of multiple contact list entries. That's reflected in the Board's construction,
`that is has contact list entries, and then column 2 tells us that figure 1 shows
`the contact list template. So look at figure 1 for an example of the contact
`list.
`
`Whilst turning to slide 11, we see figure 1 of the challenged patents
`and figure 1 -- and at the bottom of slide 11 -- the description of figure 1
`which says this is the database structure of the contact list. So the only real
`specific structural example of a contact list in the patent shows a database
`and has a database, further supporting the Board's construction of a contact
`list and so Microsoft submits that under, given all the intrinsic evidence --
`you don't even know to consider the extrinsic evidence -- the proper
`construction of contact list is as the Board construed it in its Institution
`
`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
`
`8
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`decisions.
`If we turn then to slide 12. In the Institution decisions the Board
`found that Matsumoto discloses a contact list under its construction. So
`Patent Owner was on notice of this finding. Best we can tell it has not
`contested this finding, it has instead hinged all its arguments on the claim
`construction issue, and specifically what the Board found in the Institution
`decisions are that Matsumoto's table 200 and table entries disclose the claim
`contact list and contact list entries.
`So if we look at slide 13, slide 13 shows Matsumoto's contact list and
`this is from figure 3 of Matsumoto and I just want to clarify that the
`annotations were added in the petition and I know it says read adaptations in
`original. In any event, they were added in the petition. They were not in
`Matsumoto as originally issued or published. But what we have here in
`Matsumoto is nearly identical to what's show in figure 1 of the challenged
`patents, and if we go back to slide 11 you can see figure 1 has this basic
`structure that has several fields; name, address, phone number and a memo,
`and if we turn to slide 13 Matsumoto has telephone number, name, email
`address, and subject of notes It might be labeled differently but the content
`there is essentially all the same and, importantly, with respect to what's
`recited in the claims, and so based on that record, Petitioners submit that
`Matsumoto renders all challenged claims unpatentable.
`If we turn to slides 15 and 16, slides 15 and 16 have Patent Owner's
`proposed construction of contact list and this is, I think it's 147 words in the
`892 patent and 153 words in the 657. So Patent Owner seeks to turn this
`simple two word phrase into a hundred and fifty word phrase, would seek to
`double the length of it, an already lengthy preamble to the patent. But more
`
`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
`
`9
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`importantly, it proposes a construction that's wholly inconsistent with the
`surrounding claim language, with the specification, with the figures, with all
`of the intrinsic evidence, and so for multiple reasons that construction should
`be rejected.
`JUDGE JIVANI: Counsel, let me pause you there for a minute.
`MR. MASON: Yes.
`JUDGE JIVANI: You mentioned those 150 words and while it may
`be unusual to take a two word or few word phrase and seek construction of
`this length, the length in and of itself is not dispositive, is it?
`MR. MASON: No. I don't think the length is dispositive. I think it's
`worth noting and that's why I focused more on the fact that it really, looking
`at the intrinsic evidence is what's most important. The length is not
`dispositive, I would agree with that wholly, but what Patent Owner's doing
`noting how long it is and noting how doubles an already lengthy preamble
`just shows how much Patent Owner is trying to pack in to what is otherwise
`a very simple phrase and highlights that it's injecting ambiguity and injecting
`uncertainty in the phrase. It's reaching out to extrinsic commercial
`embodiments of other devices in order to pull things into the claim. So I
`wholly agree. It's not dispositive but if you look at all the important
`evidence, i.e., the intrinsic evidence, this construction is improper.
`So I think just staying on slides 15 and 16, I want to emphasize again
`that this is not the broadest reasonable interpretation. I don't even know that
`it would be a reasonable interpretation. It's also not proper under the District
`Court or the Phillips standard as it were. It's inconsistent with the other
`claim language that we discussed which does not reflect a user interface at
`all. It's inconsistent with the specification which seems in one part to
`
`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
`
`10
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`discuss the contact list and shows an example of a contact list as a database
`structure, and then in separate portions of column 2 refers to means for
`accessing that contact list or means for doing something that contact list,
`suggesting that it's another portion of the device that interacts or interfaces
`with this contact list information, with this contact list database in order to
`present it to the user. So for all those reasons, this claim construction should
`be rejected.
`And with that I'm going to jump. Slides 18 and 19 reflect that the
`Board has already largely rejected these proposed constructions in the
`Institution decisions for the same reasons the Board should reject those
`constructions now, and if there's nothing further on the contact list issue
`from the Board I'm going to move then to the single storage issue.
`So turning now to slide 22. So this is the Sony based grounds again
`that involved the single storage issue and just stepping back, we addressed
`this in the petition. Its primary embodiment describes having its contact list
`or I think it's a phone book that Sony refers to it as, the phone book is
`separate from another table or database that can store the memos or the
`reminders, and those two databases are linked in a manner such that when a
`phone call is received and there's a reminder linked to the contact for that
`phone number, the reminder is displayed on the screen.
`We acknowledge that that primary embodiment was a two storage
`embodiment, but what we said was in view of Sony itself or further in view
`of Matsumoto it would have been obvious to put everything into a single
`storage embodiment and once you have the single storage embodiment,
`Patent Owner's arguments all fall away because you have everything in a
`single storage and so you're not going to have the past value issue raised by
`
`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
`
`11
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`Patent Owner or the mismatches that were identified by Patent Owner and
`accordingly the challenged claims should be found unpatentable.
`I think I'll turn now to slide 24 which again emphasizes -- this is the
`petition at 50 where we explain why a skilled artisan implementing Sony
`would have found it obvious to use a single storage for the contact list and
`memo, namely the single storage versus two storage solutions would have
`been seen as interchangeable, it would have been seen as a design choice to
`a skilled artisan so just based on that alone it would have been obvious for
`somebody looking at Sony to implement it as a single storage database.
`If we turn to slide 26 Mr. Rysavy, Petitioner Microsoft's expert,
`explained the interchangeability and then on slide 27 he also explained the
`motivation. This would have been simpler to code (phonetic) it, to have a
`single storage would have been much simpler to do than a double storage
`limitation. So if you were coding up or implementing the Sony storage, you
`would have done it as a single storage. A POSITA would have been
`motivated to do it that way and that's enough to find the combination.
`If we look at Patent Owner's arguments that they've raised, Patent
`Owner addresses Sony and Matsumoto independently and alleges points
`why they don't satisfy the claimed contact list. However, Patent Owner
`never addresses the combination, the modification of Sony in view of
`Matsumoto, and in this vein I just want to turn back to -- it's slide 13. And
`so this is what Matsumoto shows. Slide 13 shows figure 3 of Matsumoto
`and again, we've got everything in a single storage and this is how
`modifying Sony in view of Matsumoto, this is what a skilled artisan would
`have arrived at. Once you have everything in a single database, there's no
`mismatch issue, there's no past value problem as alleged by Patent Owner.
`
`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
`
`12
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`We dispute that those would even be problems or that Sony somehow
`teaches to implement a broken version of its system but even to the extent
`that those were known problems or known issues, that actually would have
`motivated a POSITA to choose the Matsumoto implementation when
`implementing the Sony system. So for those reasons it would have been
`obvious to make this modification to Sony and with that modification Sony
`satisfies the contact list limitations and the combination renders all
`challenged claims unpatentable on these grounds.
`If the Board has no further questions at this time I will reserve the
`remainder of my time for rebuttal. Thank you.
`
`(Pause.)
`MR. MA: May it please the Board. Thank you for giving us the
`opportunity to present our case. I guess I don't need to reserve time for
`rebuttal so I will just use up all my time and please feel free to interrupt me
`if you have any questions.
`JUDGE WORMMEESTER: Thank you.
`MR. MA: Thank you. I assume you are familiar with the main
`functionality discussed in both patents. Basically it relates to a memo
`function meaning a memo was pre-recorded and associated with a phone
`number and the ideal situation is that if a phone number comes in or dial up
`the memo will be displayed right at the moment of the dialing or receiving.
`For this memo function there are different ways of implementing it.
`For this case in order to correctly understand and interpret the claimed
`invention, currently there is only one issue remaining in both IPRs and that
`is the claim construction of the "contact list." Before I delve into the details
`of interpreting that term, I just want to quickly review the case laws. I'm 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
`26
`
`13
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`slide 1.
`You know, for this Board the standard is the broadest reasonable
`interpretation. Here there are two words that are key, one is broadest, the
`other is reasonable. The reason why the word reasonable is extremely
`important is because if that interpretation is possible but it's not reasonable,
`then that claim construction should not be adopted. So on this slide there are
`three case laws that have been used to govern the claim construction under
`that standard. The Phillips case says very clearly the claims must be
`reviewed in view of the specification and the specification is the single best
`guide to the meaning of a disputed term, meaning that you can't just jump
`over the specification and go to something else and look for clues for the
`meaning of that term. The second --
`JUDGE CHUNG: Counsel.
`MR. MA: Yes.
`JUDGE CHUNG: Let's just speed up --
`MR. MA: Okay, yes.
`JUDGE CHUNG: -- and cut to the chase. Phillips case also mentions
`that you start claim construction with the language of the claim. So in our
`Institution decision we preliminarily determined that contact list may include
`user interface but does not necessarily require it and but you are arguing
`based on the brief, papers you submitted and based on the demonstratives
`you're arguing that this meaning of the term contact list is narrower than our
`claim construction. You are arguing that a contact list requires a user
`interface; is that correct?
`MR. MA: Well, actually I think the claim construction adopted by the
`Board is totally wrong under Phillips, and especially under the recent case of
`
`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
`
`14
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`In re Smith and also, Your Honor, I just want to clarify that I disagree with
`your reading of Phillips. Phillips didn't say that somehow you can jump into
`the claim language without even first making sure that you construed the
`specification as a whole to find the meaning of a term at issue. So in other
`words --
`JUDGE CHUNG: Well I mean --
`MR. MA: -- the claim language should be afterthought, should be
`secondary and the claim language is only applicable if, for example, you
`cannot discern the meaning of a term after reading the specification as a
`whole from the perspective of those skilled in the art.
`JUDGE CHUNG: Counsel.
`MR. MA: Yes.
`JUDGE CHUNG: I don't think it's necessary to spend too much time.
`MR. MA: Oh, okay.
`JUDGE CHUNG: We are talking about standard of the BRI and not
`under Phillips, so my question was that is it your position that a term contact
`list requires a user interface (indiscernible?)
`MR. MA: Well, that's not the standard. The standard (indiscernible)
`In re Smith --
`JUDGE CHUNG: No, no (indiscernible.)
`MR. MA: No. Basically the broadest reasonable interpretation
`should be something that corresponds to the invention intended by the
`specification. Let me actually switch to --
`JUDGE CHUNG: That wasn't my question. I wasn't really talking
`about -- asking you a question about the standard of the claim construction.
`I was asking about your position regarding construction of the term contact
`
`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
`
`15
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`list.
`
`MR. MA: Oh, my --
`JUDGE CHUNG: So I'm asking --
`MR. MA: Yes.
`JUDGE CHUNG: -- is it your position that the term contact list
`requires a user interface?
`MR. MA: My position is the contact list requires the specification
`from the perspective of those skilled in the art under the established standard
`in In re Smith and in Phillips. There are two elements. One is the case law,
`the other is the understanding got to be from those skilled in the art upon
`reading the specification as a whole.
`JUDGE CHUNG: So, yes. Upon reading the specification, but is it
`your position that the contact list requires the user interface?
`MR. MA: Yes, yes. With these two perspectives or the standard
`established, yes, that's our position. Because we --
`JUDGE CHUNG: So one of the issues I have with the position is that
`if you look at the claim language of claim 1, you know, the 892 patent.
`MR. MA: Yes. Actually let me see, I can open up a PDF file.
`JUDGE CHUNG: So claim 1 recites the communication device
`having access to a saved contact list --
`MR. MA: Yes.
`JUDGE CHUNG: -- right? If your argument is that contact list
`requires a user interface, I'm not sure how you save a user interface? I
`mean, just as background, you know. I designed user interfaces in the
`industry for ten years, as a technical engineer before I went to law school
`and during all those years I never understood how to save a contact list -- I
`
`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
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`mean a user interface, I'm sorry. So user interface is generally understood as
`something that's displayed on the screen on the display monitor. So, you
`know, I'm asking --
`MR. MA: Can I answer?
`JUDGE CHUNG: -- if the claim recites the contact, saving the
`contact list, how do you save -- and you're arguing that contact list requires a
`user interface -- how do you save a user interface?
`MR. MA: Can I address that, Mr. Chung?
`JUDGE CHUNG: Sure.
`MR. MA: Okay. Clearly I understand that everybody has their
`personal understanding of certain things like, for example, I'm a software
`engineer for 12 years and you mentioned yourself were for many years. My
`understanding of this will be different from yours, from my perspective. But
`here's the thing, is that before we're even jumping to the claim language,
`right, unless for example we cannot reconcile what the specification calls for
`and what the claim language calls for, then we should not directly jump into
`the claim language. We should first go to the specification because the
`specification is the single best guide under the case law.
`JUDGE CHUNG: So let's go to the specification (phonetic).
`MR. MA: Can I continue? I'm sorry, Judge Chung, I haven't finished
`yet. So here's the thing. I understand your concern. Basically you're saying
`hey, wait a second, how could something be saved having user interface.
`You see the thing, right, is that it's very common. In fact our expert has
`declared, no actually has opined that a feature having user interface is
`routinely referred to as something saved in a computer or in a device. In
`other words, a saved contact list must be construed as a contact list as
`
`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
`
`17
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`properly construed that is saved to your computer. You see, there's is no
`conflict between a feature having user interface versus a feature saved in a
`device that does not have user interface.
`JUDGE CHUNG: So this leads me to my next question, which is
`does the specification describe saving a user interface?
`MR. MA: You mean having user interface or saving user interface?
`JUDGE CHUNG: Saving interface.
`MR. MA: Well, something saved doesn't mean that the specification
`has to describe how to save it. You see, that's not the essence of the
`invention.
`JUDGE CHUNG: But you just said the specification is the best
`guide.
`MR. MA: Yes. That's what I'm here for. Why the specification in
`this case is the best guide? Because first of all the specification said very
`clearly, it's a feature. Not only it's a feature, it's a common feature. In fact
`all the other claim construction language that's put up out there, they all
`derived from this thing called common feature, right? So like I can give you
`one good example. Gmail, right? You hear the word gmail, oh that carries a
`tremendous amount of information which can maybe span five books.
`Why? Because everybody who uses gmail knows what an inbox looks like,
`where the inbox is, how you, for example, move to the read email first, how
`you, for example, set up the search. So one word can convey to you a
`tremendous amount of information.
`So, here in our case we have common feature, right? A common
`feature in the context of entering and saving contact information. This will
`recall so many information from those skilled in the art because they look at
`
`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
`
`18
`
`

`

`Case IPR2017-01052 (Patent 8,848,892 B2)
`Case IPR2017-01411 (Patent 9,531,657 B2)
`
`this thing called common feature, the first thing in their mind is they got to
`have user interface because in the context of a communication device like a
`smart phone, if you have no user interface, how could it be a feature, right?
`And second, it's common. What is common? For example, pretty
`much 99.9 percent of the phones you have something that can allow you to
`enter information, viewing contact information, things like that. So that
`would immediately convey that information to those skilled in the art and
`that is why the claim construction is constructed that way.
`There hasn't been a common contact list on any user phone that cannot
`do speed dial. At least Petitioner hasn't brought up any example of a contact
`list on any kind of a calling device or communication device for phone
`communication that does not have a feature called speed dialing. So that's
`the reason why those skilled in the art, when they just look at the first
`paragraph of the specification they would immediately understand what the
`term contact list requires in clause 4, because otherwise this invention is just
`another subject matter having no difference to, for example, like Matsumot