`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________
`
`GOOGLE LLC,
`Petitioner,
`
`v.
`
`BLACKBERRY LTD.,
`Patent Owner.
`__________
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`__________
`
`Record of Oral Hearing
`Held: September 17, 2018
`__________
`
`
`
`Before SALLY C. MEDLEY, ROBERT J. WEINSCHENK, and
`AARON W. MOORE, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`
`APPEARANCES:
`
`ON BEHALF OF THE PETITIONER:
`
`
`PHILLIP W. CITROEN, ESQ.
`NAVEEN MODI, ESQ.
`JOSEPH E. PALYS, ESQ.
`Paul Hastings LLP
`875 15th Street, NW
`Washington, DC 20005
`202-551-1991 (Mr. Citroen)
`phillipcitroen@paulhastings.com
`
`
`
`ON BEHALF OF THE PATENT OWNER:
`
`
`SAMUEL A. DILLON, ESQ.
`CHING-LEE FUKUDA, ESQ.
`SHARON LEE, ESQ.
`Sidley Austin, LLP
`1501 K Street, NW
`Washington, DC 20005
`202-736-8298 (Mr. Dillon)
`samuel.dillon@sidley.com
`
`
`
`
`The above-entitled matter came on for hearing on Monday,
`
`September 17, 2018, commencing at 1:00 p.m. at the U.S. Patent and
`Trademark Office, 600 Dulany Street, Alexandria, Virginia.
`
`
`
`2
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`P R O C E E D I N G S
`- - - - -
`JUDGE MOORE: Good afternoon. We're here now for
`argument in our case number IPR2017-1619 and 2017-1620. It's
`entitled Google LLC versus Blackberry LTD, and it concerns United
`States Patent Number 8489868. Would counsel for the parties please
`introduce yourselves, starting with the Petitioner.
`MR. CITROEN: Good afternoon, your Honor. My name is
`Phillip Citroen, appearing on behalf of the Petitioner. Here with me
`today is Joe Palys and Naveen Modi.
`MR. DILLON: On behalf of the Patent Owner, my name is
`Sam Dillon. With me is Sharon Lee and also our lead counsel Ching-
`Lee Fukuda.
`JUDGE MOORE: Thank you, welcome to the Board. Per our
`hearing order, each side will have 90 minutes to argue. The Petitioner
`will argue first and may reserve rebuttal time. The Patent Owner may
`not reserve rebuttal time. I will remind the parties that the Petitioner
`bears the burden of proving any proposition of unpatentability by a
`preponderance of the evidence.
`I will also remind the parties that this hearing is open to the
`public, and a full transcript of it will become part of the record.
`Please remember to also mention the numbers of the slides as you
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`3
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`refer to them so it's reflected clearly in the record. And with that, I'll
`invite Petitioner to begin.
`MR. CITROEN: Good afternoon, your Honor. May it please
`the Board, my name is Phillip Citroen. As I mentioned, I am here on
`behalf of the Petitioner. Before I go on, I will reserve about 30
`minutes for rebuttal. Also, I will be referring to Petitioner's
`demonstratives. I do have hard copies, if anyone would like a copy,
`I'm happy to bring it up.
`MR. DILLON: We're fine, no thank you.
`MR. CITROEN: Okay. So with that, if we can go to slide 2
`please. So for the Board's convenience, we've listed the grounds that
`have been instituted in the 1619 proceeding. If we can go to slide 3,
`we've also presented here the grounds that were instituted for the 1620
`proceeding.
`In our view, based on the evidence that was relied on for
`purposes of instituting these two proceedings, as well as the additional
`evidence that is now in the record further supporting Petitioner's
`positions, we believe that the Board should enter a final written
`decision in these proceedings canceling the claims at issue based on
`these grounds. My goal today is to explain why.
`So we can go to the next slide 4, please. So here we have
`Independent Claim 1. There's another Independent Claim as well, 76.
`For purposes of today and these proceedings, it's essentially identical.
`
`4
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`The main difference is it's directed to a method instead of a mobile
`device.
`The main point that I want to make here is that these claims,
`while relatively long, describe a simple process which is allowing an
`application to access a Sensitive API to which access is restricted
`based on a valid digital signature.
`It's also important to note that the concepts in this claim
`related to generating and validating a digital signature and using a
`public-private key pair was conventional in the art for decades before
`the 868 patent was issued. So what's left then in these claims is the
`application of these fundamental concepts in the context of restricting
`access to APIs on mobile devices. But as the record shows, this was
`not a new concept at the time.
`So the Patent Owner, in response, has presented a shotgun
`approach to these proceedings raising numerous arguments. At the
`end of the day they all fail, and there's a few reasons I want to
`highlight up front for that.
`First of all, a major flaw in Patent Owner's arguments,
`especially with respect to the 1620 proceeding, is that they ignore
`what was so well known in the art at the time of the alleged invention.
`For example, how conventional digital signatures worked, how private
`keys worked.
`
`5
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`Another problem with many of Patent Owner's arguments is
`that they ignore the full disclosure of the prior art references. And
`finally, another issue is that they raise claim construction arguments
`that are unsubstantiated. They're not supported by the record.
`So I'd like to focus on a few of these issues, a few of these
`arguments that the Patent Owner has raised. And I think it may be
`helpful given there are a lot of slides that we submitted, to present a
`road map for the Board to see what the issues are that we'd like to
`address today. So if you could actually jump to slide 6, please.
` So here are three claim construction issues that have been
`raised. Today I plan to just focus on the first two, and I will just note
`up front that these two claim construction issues are really just
`specific to the 1619 proceeding. I'll just note one typo here, these
`should be IPR 2017.
`If we can go to slide 26. Here we've presented the issues that
`were raised by the Patent Owner with respect to the 1619 proceeding,
`and this involves the Garst reference. So for this particular
`proceeding, I'm going to focus on the first two limitations of the
`Independent Claims and then Claim 112, one of the Dependent
`Claims.
`And if we can go to slide 47, here we have the issues for the
`1620 proceeding which involves the Lin reference. And for this one, I
`
`6
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`plan to also focus on the first three limitations that are recited there,
`which are part of the Independent Claims.
`And then for the Dependent Claims, there's a lot of issues that
`have been raised. I'm just going to focus on Claims 13 and 88, and
`Claim 98.
`Of course, if there's anything else that the Board wants me to
`address -- and actually before I go on -- I'm mostly going to address
`the public availability issue that was raised by the panel for the Gong
`reference. So with that, if there's any other issues that your Honors
`would like me to address, please let me know. I'm happy to answer
`any questions with respect to any additional issues I don't address on
`my opening presentation.
`So with that, let's go to slide 7, please. So as I mentioned, the
`first issue I'd like to address is some claim construction points, the
`first two in particular. Both of these only relate to the 1619
`proceeding and were raised to try to get around the Garst reference.
`So first for this proceeding, the signed software application
`term. We can go to slide 8. The Patent Owner argues that this has a
`very narrow meaning. You can see they essentially argue that the
`signature is of the software application. One thing I want to point out
`though is that the construction that's actually proposed here doesn't
`clearly express what the Patent Owner is actually arguing.
`
`7
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`What they're arguing is that the signature needs to be created
`using the software application source code. That's what's being
`argued here. What we don't know is whether Patent Owner's
`construction requires all of the source code to be used to generate the
`digital signature, whether a portion of the source code can be used to
`generate the digital signature, and if it's the latter, what we don't know
`is what portion needs to be used. Does it matter and how much?
`Does it matter if it's one line of source code? Does it need to
`be a certain percentage of source code? These are issues that are not
`expressed in this construction. That's unclear.
`JUDGE MOORE: Do we have to know that though? Is there
`a reason why we have to know that?
`MR. CITROEN: Well I think it's important when we get to
`Garst. You'll see that they take to the position that what we point to in
`Garst, which is actually a piece of the source code, they say isn't
`enough to meet this limitation. So the unclear construction that they
`provide is important because it needs to be -- expressly say to what
`this construction means in order to figure out whether the prior art
`reference actually meets their construction.
`So this is part of the problem we have with Patent Owner's
`construction is just this unclear construction that's provided. But as I
`mentioned, what I think we'll hear today is whatever this construction
`
`8
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`means, it at least excludes what they say in Garst is not application
`and source code. It's not sufficient to meet this construction.
`Beyond these issues of clarity, Patent Owner's construction is
`also wrong because it's inconsistent with the claims and the
`specification of the 868 patent.
`So if we can go to slide 9 and actually look at the claim
`language here. So there's a lot of words highlighted, but if I can direct
`your attention to the first wherein clause. It says, wherein a signed
`software application includes a digital signature generated using a
`private-public key pair.
`So something that I think's important to note here is that when
`you talk about signing something, that is referring to a process of
`creating a digital signature, and that's actually recited here. A digital
`signature generated using a private key of a private key-public key
`pair, significantly what you don't see here is any indication of what
`type of information is actually used to generate the digital signature.
`It doesn't state what the key is actually applied to. And it certainly
`doesn't state that you have to apply the key to source code of the
`software application.
`So based on the claim language itself, information other than
`source code may be used to generate the digital signature of the signed
`software application, which makes sense given a software application
`can include information other than source code.
`
`9
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`JUDGE WEINSCHENK: Does this spec give us any
`examples where the signature isn't generated from the source code?
`MR. CITROEN: I think it does, your Honor. Actually, let's
`jump to, I think it's the next slide, slide 10. I think the understanding
`that we have of the claim language is consistent with this particular
`paragraph which is in the specification of column 4, line 36 to 55.
`Here it gives me an example in this portion of signing the
`software application code. But the important point is that it's
`expressly stated that this is only an example. And the highlighted
`portion -- let me just walk through this a little bit. I don't want to get
`too much into the weeds, but I think it's helpful to go through and see
`what this paragraph is actually explaining.
`So if you look at the top portion that is highlighted there,
`you'll see that it's prescribing what a signed software application is. It
`actually uses the language that's in the claims. It explains that it has a
`digital signature. But what this highlighted portion doesn't tell you is
`what is actually being signed. What's being used to generate the
`digital signature? That's not specified in the highlighted portion at the
`top. That is explained -- what's used to generate the digital signature,
`is explained in the rest of the paragraph.
`So if you look at the portion following the top highlighted
`section, you'll see that it explains that you -- to create the digital
`signature, you sign information using private key 18. And twice in
`
`10
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`this section it states that the software application is generated using
`the source code twice as an example only. The first time it's not
`highlighted, it's toward the middle, it says for example. According to
`one signature scheme, it goes on to explain that you can sign the
`application itself.
`The next part is a highlighted section at the bottom, and I think
`this is probably more helpful for the Board. It explains that in some
`signature schemes, a private signature key is used to encrypt a hash of
`information to be signed. And that's the important part, and
`information to be signed. And then it gives again, as an example only,
`such as Software Application Y14.
`JUDGE MOORE: Doesn't the key have to be tied to the
`software? Doesn't the signature have to be tied to the application?
`MR. CITROEN: Yes and it could be --
`JUDGE MOORE: You're signing the application, right. The
`signature is there to substantiate that is in fact the application from the
`source's signature.
`MR. CITROEN: Understood, and I think that's right. I think
`there has to be an association with the application. But the question
`is, what information actually needs to be used to generate that digital
`signature? The argument that the Patent Owner is taking is that the
`claims only go to this example here, which is signing the source code.
`But there's other information tied to an application as well that may
`
`11
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`not be the source code, but you could also use to generate a digital
`signature. There's always --
`JUDGE MOORE: Is that described somewhere in this
`specification?
`MR. CITROEN: No, I don't believe so. I'd have to take a
`look to be sure. But that's something that's generally known in the art.
`I think there's actually -- if I can point you to slide 32 really quickly.
`You can see, and this is just another reference in the prior art,
`describing Java which a programming language.
`You can see the JAR file is actually packaging all of the
`portions of the software application, including class files which is the
`source code, images, sounds, and other data. This is one reference
`that gives some explanation what a software application is, in fact. It's
`not just code itself. You have other pieces that can be part of the
`software application.
`So with that, at least open the possibility, particularly given
`the claim language doesn't state what is actually being used to
`generate the digital signature. And the fact that the specification
`broadly states that you can generate a digital signature for "the signed
`software application using information." It only gives source code as
`an example.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`
`12
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`JUDGE WEINSCHENK: But am I correct that that's the only
`example given in the spec is using the source code to generate the
`signature?
`MR. CITROEN: Well, I'd say it's broader than that because it
`says you can sign information. If you look, and I'm sure Patent
`Owner will want to make this point today, the specific examples it
`gives later are referring to the source code of the application. But
`when it's actually defining what a signed software application is
`before doing that, it uses information as the key to explain what is
`actually being used to generate the digital signature here. So I think
`it's important to remember that the claim language is broad here.
`JUDGE WEINSCHENK: So the information is broader than
`source code?
`MR. CITROEN: Absolutely.
`JUDGE MOORE: But it can't be any information, right? It
`has to be information that's connected to the application somehow.
`MR. CITROEN: Absolutely. That's right, your Honor. I
`think it does -- there has to be -- that's never been our position. We
`don't think, you know, you can just throw any digital signature on and
`that would be sufficient. There does have to be an association with
`the application.
`And I think, you know, one thing -- I'll get to this later -- but
`one thing I will point out now is that at the end of the day, it doesn't
`
`13
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`really matter whether this construction is adopted, because we think
`it's disclosed by both Garst by itself, and the combination of Garst and
`Gong reference. And there's support in the petition, and we have
`expert testimony that supports that position as well.
`But from just a claim construction standpoint, we think the
`proper construction is broader that what the Patent Owner is
`proposing here. So with that, can we go to slide 15 please, Joe?
`The next claim construction issue I want to discuss here is the
`Sensitive API/Non-Sensitive API. We can actually go to 14, slide 14
`please. And here you have the constructions proposed by the parties,
`and also the constructions adopted by the Board. And you can see
`here what Patent Owner argues with respect to these terms, except
`they must be narrowly construed to refer to APIs that do or do not
`implicate a security concern.
`This is almost the same construction that they proposed with
`their preliminary response. That the focus there being as well whether
`or not the API implicates a security concern. In the institution
`decisions, the Board rejected that argument, instead adopting a
`construction that is more aligned with the claim language and a
`specification of the 868 patent.
`And as you can see from Petitioner's proposed constructions
`here, we think the Board got it right in the institution's decisions, and
`
`14
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`believe that the Board should maintain the constructions that it
`adopted in its institution decision.
`So I think it's helpful to look at the claim language of slide 15
`quickly. So first, you can see the highlighted portion on the left side
`for Claim 1 where at least one API comprises a Sensitive API to its
`access is restricted. There is no mention of security whatsoever in the
`highlighted portion or anywhere else in this claim.
`Instead, what the claims are describing here is a concept
`related to access restrictions. If it's a Sensitive API, you restrict
`access to it. If it's a Non-Sensitive API, there are no access
`restrictions. This is what the claims are directed to. And it's also
`consistent with the preamble of Claim 1, which isn't highlighted, but
`you can see that the preamble states that the, cause the mobile device
`to inform operations for controlling access to an application platform
`of the mobile device. Again, emphasizing that the point here, with
`respect to these limitations, is whether or not you're getting access to
`an API.
`If we can go to slide 16. And this understanding of these
`terms is supported by what the other claims describe, and is also what
`the specification describes, and here is an example. Claim 117, you
`actually had a digital signature that is not successfully verified. Yet,
`in addition to denying access to a Sensitive API, you're allowing
`access to a Non-Sensitive API.
`
`15
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`If we go to the next slide, the specification uses these terms in
`the same way. So jumping to the second highlighted portion here, to
`protect against unauthorized access to the Sensitive APIs. So again, I
`know this is only one excerpt, but the specification consistently states
`that with Sensitive APIs, you're restricting access. There's not a
`similar description for Non-Sensitive APIs. You do not restrict access
`to specific Non-Sensitive APIs as we do for Sensitive APIs.
`So what types of APIs then may be classified as sensitive? I
`think it's very helpful to point out that the top portion here of this
`paragraph explains that any API may be classified as sensitive. Any
`API would certainly include APIs that do not implicate security
`concerns. And this rationale is consistent with the objectives that are
`actually specified in the 868 patent.
`If you go to the next slide, Joe. This is slide 18. On the left
`side you can see the objectives in column 1, line 36 to 50, of the 868
`patent. Here you can see that the objectives for a co-signing scheme
`is not only to protect against destructive code, such as Trojan horses,
`but also to ensure that an application will properly interact with native
`applications and resources. And there's also a few objectives listed
`here. We're just generally controlling the types of software
`applications that are put onto devices.
`We can go to slide 19, please. There's another problem with
`Patent Owner's construction as well, and that's highlighted by some of
`
`16
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`the testimony of Patent Owner's expert, Dr. Ligler. First, the
`specification does not provide any guidance or a standard for a person
`who is skilled in the art to understand the scope of this term under
`Patent Owner's construction.
`In fact the phrase "security concern" doesn't appear anywhere
`in the specification of the 868 patent, and the term "security" isn't
`described anywhere in the specification with respect to APIs. It's just
`not there.
`Instead, and you can see this in slide 19, according to the
`Patent Owner's expert, the decision whether to classify an API as
`sensitive is less up to the subjective judgment of the API author, or
`some other entity.
`If we can go to slide 20. And this is all coming from Exhibit
`1046. So slide 20 is another portion of the transcript for Dr. Ligler at
`page 130, line 40 and 13. Here, Dr. Ligler actually states that if you
`have two authors of an API, they may actually disagree whether that
`API implicates a security concern or not. In this situation, he
`proposed that maybe a third party could come in and indicate whether
`or not they believe that the API implicates a security concern.
`So, because there's no objective way to actually determine
`whether an API implicates a security concern, Patent Owner's
`construction is not only unsupported by the claims and the
`
`17
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`specification, but also raises indefinite in these questions with respect
`to these terms.
`So at the end of the day, at most what the specification is
`describing is a system for restricting access for APIs, and it's up to the
`API author to decide which APIs that may be. But it's not limited to
`APIs that implicate a security concern.
`JUDGE WEINSCHENK: I assume you'll get to this, but does
`this issue matter? Does the prior art teach this limitation even under
`Patent Owner's construction?
`MR. CITROEN: We believe it does. In our petition, we have
`an obvious position that states, and I will get to this, that even if the
`construction is adopted, that the combination of Garst and Gong
`would disclose this limitation. You would have at least one of the
`APIs on the mobile device be a Sensitive API for security purposes,
`and I will get to that.
`So if we can go to slide 27, please. So I'm now jumping to the
`substantive issues with respect to the prior art. In particular, I'm going
`to the 1619 proceeding, and this is related to the Garst reference as the
`primary reference, and I want to talk about the "Signed Software
`Application" term first.
`As a reminder, we just talked about this, but Patent Owner
`proposes a specific construction for this term, which is essentially
`requiring signing the application source code. They don't have an R-
`
`18
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`unit with respect to the prior art if their construction is not adopted.
`So there's really no dispute if this construction is adopted, but the
`prior art discloses it.
`But even if Patent Owner's construction is adopted, Petitioner
`has shown that Garst, both alone and in combination with Gong, does
`disclose a signed software application.
`So if we can go to slide 28, I'd like to start with just Garst
`alone. I won't spend too much time because I think it's pretty clear
`from both the figure and some of the excerpts here. You can see that
`Garst explicitly or clearly explains that the license agreement string
`904 and the license key string 902 is actually part of the application
`program's source code, and you can see that clearly in Figure 9.
`You have application program 900, and then within the cost
`and declaration section of the application program, you have both
`string 902 and 904. And just as a quick reminder, key string 902, that
`is the digital signature, and that is generated using the agreement
`string 904.
`JUDGE MOORE: Is it the Patent Owner's position that it's
`not the application that's signed though, it's the license agreement
`string that's signed?
`MR. CITROEN: I think that is their position, but the problem
`with that position is Garst explicitly explains that the license
`agreement string is actually part of the application program. He
`
`19
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`actually inserts it into the program, and the highlighted portions
`explain that. The first portion of the top right. It explains, excuse me,
`the top right. So this is Garst, column 9, 17 to 21. It explains the
`string 902 and license agreement string 904, which is the agreement
`string, is inserted into the application program's source code.
`Then if you go down to the bottom portion, which is also from
`Garst, column 9, line 48 to 58, it states that the two strings are
`compiled into the executable form of the application program. And
`for Java it even explains it would be the byte code. And it states that
`this binds the license key string and the license agreement string into
`the executable code of the application program. So the argument that
`it's not part of the code itself is directly in conflict with what Garst
`itself explains.
`JUDGE MOORE: Well it's in the code but the key is
`generated from the string as opposed to, for example, generated from
`the application as a whole?
`MR. CITROEN: That is correct. So you, in Garst, you do not
`take all of the source code. Again, and this is part of the problem we
`have with the construction, it's unclear whether you have to sign all of
`the source code. If that's required, what Garst is explaining is that you
`sign the agreement string portion of the source code. That's what
`Garst explains.
`
`20
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`If the argument is that the agreement string is something that
`you're signing and inserting into the code, even though it explicitly
`states that it becomes part of the code, then at that point again you're
`questioning well, what does the construction mean then? So does it
`matter when you then start signing pieces? Does it matter when the
`code that's being signed is inserted into the complete program?
`This just shows again that it's unclear what the construction is
`and where the line is between signing the code and not signing the
`code.
`
`JUDGE MOORE: So the questions seems to be, what does it
`mean to be signed, right? Because, I mean here it seems to me like
`they're arguing that the signing is essentially generating this unique
`key corresponding to something. So they're signing the license
`agreement string, and then they just happen to put that stuff in the
`application.
`So what does it mean to be signed, right? Is it a signed
`application if you have a signature that validates something else that is
`just put in there, or does it have to be of the application itself?
`MR. CITROEN: I think that is the question, and I think the
`issue again is the construction. What the question is, and maybe to
`restate slightly what you said, is what information needs to be used to
`create the digital signature for the signed software application? And if
`you go down that road and start questioning, okay, is it something
`
`21
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`that's already in the code or not? Would that then exclude a situation
`where you had different pieces of code that are separately signed and
`then combined into one final source code package? I don't know.
`Based on the construction itself, how broad it is, and the lack
`of clarity, how vague it is, this is sufficient. Garst explicitly states that
`it's part of the executable form. It is the final program that's actually
`run on the device. That's the program. That's the source code. And
`when the source code runs, it actually uses the strings to check
`whether the application as a whole can access the API.
`JUDGE MOORE: I think the key validates the license
`agreement text, right, not the application?
`MR. CITROEN: That's correct. But again the question is, is
`it verifying a portion of the source code? The answer is yes, because
`the agreement string in the software that you're receiving is actually
`part of the cost and declaration of the source code application. It is
`part of the code.
`JUDGE WEINSCHENK: I just want to make sure I'm
`following exactly here. So we have plain language that says the
`signed software application includes a digital signature. That here is
`the license key string.
`MR. CITROEN: The digital signature is the licensed key
`string, that's correct.
`
`22
`
`
`
`Case IPR2017-01619
`Case IPR2017-01620
`(Patent 8,489,868 B2)
`
`
`JUDGE WEINSCHENK: And it's generated using a private
`key, and the private key is the license agreement string?
`MR. CITROEN: No. The private key is the API vendor's
`private key which is not, I believe it's not showing in Figure 9 here.
`That's shown elsewhere.
`JUDGE WEINSCHENK: Okay.
`MR. CITROEN: The license agreement string is the text that
`becomes part of the software program, part of the source code. That
`portion of the source code is used to create the key string which is the
`digital signature.
`So even if Garst alone doesn't disclose this limitation, our
`petition lays out an obviousness combination that's based on Garst and
`Gong. So I'd like to mo
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
