throbber
UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`_____________
`
`VISA INC., and VISA U.S.A. INC., and APPLE INC.
`Petitioner,
`
`v.
`
`UNIVERSAL SECURITY REGISTRY, LLC,
`Patent Owner
`_____________
`
`IPR2018-01350
`Patent 8,856,539 B2
`____________
`
`Record of Oral Hearing
`Held on November 21, 2019
`_____________
`
`BEFORE: PATRICK R. SCANLON, GEORGIANNA W. BRADEN,
`and JASON W. MELVIN, Administrative Patent Judges.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`APPEARANCES
`
`ON BEHALF OF PETITIONER:
`MATTHEW A. ARGENTI, ESQUIRE
`JAMIE YOO OTTO, ESQUIRE
`WILSON SONSINI GOODRICH & ROSATI
`650 Page Mill Road
`Palo Alto, CA 94304
`650-493-9300
`
`MONICA GREWAL, ESQUIRE
`WILMER CUTLER PICKERING HALE and DORR LLP
`60 State Street
`Boston, MA 02109
`617-526-6223
`
`
`ON BEHALF OF THE PATENT OWNER:
`CHRISTOPHER A. MATHEWS, ESQUIRE
`TIGRAN GULEDJIAN, ESQUIRE
`JAMES M. GLASS, ESQUIRE
`QUINN EMANUEL URQULHART & SULLIVAN, LLP
`865 South Figueroa Street
`10th Floor
`Los Angeles, CA 90017
`213-443-3261
`
`ALSO PRESENT: DANIELLE JACKSON, STEPHEN YOUNG,
`ARTHUR
`HAGOPIAN, KENNETH WEISS.
`
`
`
`The above-entitled matter came on for hearing on November 21, 2019,
`commencing at 1:00 p.m., at the United States Patent and Trademark Office,
`USPTO Madison Building, 600 Dulany Street, Alexandria, VA 22314.
`
`
`
`
`
`
`
`2
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`
`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
`
`(Proceedings begin at 1:00 p.m.)
` JUDGE MELVIN: Okay. Good afternoon. We're here
`for a hearing in IPR2018-01350. Will the parties please make
`their appearances?
` MR. ARGENTI: Good afternoon, Your Honor. Matt
`Argenti from Wilson Sonsini on behalf of Petitioner in the
`matter, Visa. With me at counsel table is Jamie Otto.
` JUDGE MELVIN: Thank you.
` MR. MATHEWS: Good afternoon, Your Honors. Chris
`Mathews on behalf of Patent Owner, USR. With me today are two
`of my partners. Lead counsel, James Glass and Tigran
`Guledjian. Also in attendance from USR, USR CEO Dr. Kenneth
`Weiss, and USR's president, Arthur Hagopian.
` JUDGE MELVIN: Thank you.
` MS. GREWAL: Good afternoon. Monica Grewal on
`behalf of Petitioner, Apple Inc.
` JUDGE MELVIN: Okay. So as you all know, you each
`have 45 minutes and you may reserve time for your rebuttal.
`As you -- as is inherent, we have remote judges, so please
`remember to refer to the written materials and to speak into
`the microphone so that we have a clear record.
` How much time would Petitioner like to reserve?
` MR. ARGENTI: I'd like to reserve 20 minutes.
` JUDGE MELVIN: Okay. And Patent Owner?
` MR. MATHEWS: Right now, I imagine I'd like to
`
`3
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`reserve 10 minutes.
` JUDGE MELVIN: Okay. Okay. Well, I'll set up the
`timer so that your rebuttal will be when the light goes
`yellow, okay? I'll trust that you can manage your time.
` MR. ARGENTI: Before you hit start on the timer, one
`administrative matter.
` JUDGE MELVIN: Of course.
` MR. ARGENTI: Given that we have remote judges
`participating, my plan is to not use the screen to display our
`demonstratives. I'll be referring to them in hard copy form.
`I also have a hard copy I could distribute if it would be
`helpful, but we did file the demonstratives.
` JUDGE MELVIN: Yeah, absolutely. I -- we all have
`copies of the demonstratives. I have no need for them to be
`on the screen, so I'm happy to just use my copy here.
` MR. ARGENTI: Great, thanks.
` JUDGE MELVIN: So whenever you're ready, Mr.
`Argenti.
` MR. ARGENTI: Great. Thank you.
` Good afternoon, Your Honors. Turning to Slide 2 of
`our demonstratives, we see the instituted grounds in this
`proceeding. All of the challenged claims of the '539 Patent
`are obvious in view of the combination of three references,
`Brener, Desai, and Weiss. And as I will explain in a bit, the
`Desai reference is not necessary to find the claims obvious
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`4
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`under the proper interpretation of the claims.
` Turning to Slide 3, the challenged '539 Patent
`relates to a system used to selectively provide personal
`information to authorized parties. As we see in Figure 8 on
`Slide 3, the system can be used to allow a user to purchase
`goods from a merchant without divulging the user's name,
`identity, or sensitive information such as a credit card
`number to the merchant.
` This is accomplished through use of a secret code
`that corresponds to the user. The user provides the secret
`code to the merchant, the merchant passes that on to the
`secure registry system; at which point the secret code is then
`used to determine the customer's account number, name,
`address, other information, and work in conjunction with, for
`example, a bank or a shipping company.
` The '539 Patent also explains that the secure
`registry can be used to maintain the customer's anonymity when
`shipping the goods. The merchant doesn't need to know the
`customer's address, a third party shipper receives the address
`and enables completion of the transaction by shipping the
`goods.
` Now, turning to Slide 4, which is representative
`Claim 1 of the '539 Patent. All of the challenged claims
`specify that that secret code I just mentioned is a
`time-varying multicharacter code. Now, that's nothing new.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`5
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`Patent Owner's own prior art patent disclosed the use of a
`time-varying multicharacter code to authenticate a user years
`before the '539 Patent.
` Now, on Slide 4, the color-coded limitations recite
`actions that the secure registry processor performs. In red,
`we see that the secure registry receives a transaction request
`that includes the code representing the user, and an
`indication of the provider requesting the transaction. And
`the provider in the claim corresponds to the merchant that we
`just saw in Figure 8, for example.
` In blue, the secure registry uses that code to
`determine the identity of the entity or the customer. In
`green, the secure registry determines compliance with any
`access restrictions for the provider for completing the
`transaction. I'm going to come back and talk about that
`limitation more in just a minute.
` And in brown, the secure registry allows or does not
`allow access to information necessary to complete the
`transaction, including account identifying information based
`on the determined compliance with the access restrictions for
`the provider. And then in the last limitation, the claim
`requires that the provider does not receive account
`identifying information, but that that information is given to
`a third party to enable or deny the transaction.
` Turning to Slide 5, Brener discloses almost exactly
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`6
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`what is recited in the claim that we just saw. Brener
`discloses a system for online purchases where a customer
`remains anonymous to a vendor. That's accomplished by
`assigning the customer a code called the customer object,
`that's provided to the vendor and passed to a secure provider
`who maintains a table correspond -- correlating the customer
`object with the customer's identifying information; account
`numbers, name, address.
` Using this table, the system in Brener can work with
`a bank to enable funding for the transaction, and with a
`shipper to enable shipment of the goods. All while
`maintaining anonymity at the vendor. Now, I'm going to flip
`back to Slide 4. I want to jump back to that slide and focus
`on the green limitation that begins, "To execute a restriction
`mechanism."
` You see there's an element there that says, "Based
`at least in part on the indication of the provider and the
`time-varying multicharacter code of the transaction request."
`We explained in the petition that that based on clause could
`be read to mean the access restrictions themselves are based
`on the indication of the provider and the time-varying
`multicharacter code, or it could be read more broadly to mean
`that the transaction is completed based on the indication of
`the provider and the time-varying multicharacter code.
` The specification describes access restrictions that
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`7
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`are based on the identities of the user and the provider. But
`it also describes embodiments where the transaction is
`completed without such access restrictions. So we think the
`broader interpretation is the right one. Under that
`interpretation, you don't need the Desai reference to find the
`claims obvious, Brener satisfies this limitation on its own.
` And I want to make it clear that we're not saying
`that the access restrictions for the provider don't require
`consideration of which party may access the information. What
`we point to in Brener is the role-based access restriction
`where the system gives a third party access to certain
`information, but it doesn't give the vendor access to that
`same information. So the system in Brener knows who the
`vendor is, applies the access restrictions to that vendor, but
`it does not apply to other parties in the transaction.
` JUDGE MELVIN: So on the claim constriction issue,
`it -- I suppose it's your position that “for the provider” is
`doing the work of tying the restriction to the provider and
`that it would be redundant to say “based on, at least, in part”
`-- “based at least in part on the indication of the provider,”
`is doing something else, right? It's about completing the
`transaction, not about the access restriction?
` MR. ARGENTI: I think the way that I would put it
`and the way that I think about it is that the -- yeah, I agree
`that the “for the provider” is doing the work in the access
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`8
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`restrictions and that indicates that the access restrictions
`are applied to the provider. And that the important thing in
`this limitation in green that we're talking about is that it
`considers both the provider and the user, and so the access
`restrictions are based not just on the provider, but on the
`user, if that clause applies to the access restrictions.
` And otherwise, it -- if it only requires that the
`transaction be completed based on the provider and the user,
`you also get that from Brener. Because Brener is considering
`who the provider is when determining that, oh, that's a
`vendor. I'm not going to give them the information, I'll give
`it to a third party. And at the same time, the transaction is
`completed based on who the customer is because that's how you
`figure out the account identifying information in the first
`place.
` Now, turning to Slide 6, on the other hand, if the
`access restrictions themselves must be based on both the
`identity of the provider and the user, you find that taught by
`the prior art when you consider Desai. Desai teaches an
`information exchange system where a user can selectively grant
`access to his data on an element-by-element and user-by-user
`basis. And that is almost essentially the same concept as the
`training that's described in the '539 Patent where the
`training says the user can go into the database and set up
`permissions for particular entities to access particular data.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`9
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`That's exactly what Desai teaches.
` Turning to Slide 7, the only other aspect of the
`claims that Brener does not disclose is the use of a
`time-varying code to identify the user. In Brener, the
`customer object doesn't vary in time, but time-varying codes
`to identify users were well known before the '539 Patent.
`Weiss is one example. Weiss teaches periodically generating
`codes that are used to identify a user. Patent Owner does not
`dispute that Weiss discloses a time-varying multicharacter
`code, as recited in the claims.
` So what does Patent Owner dispute? The only
`limitation in Patent Owner's briefing identified as missing
`from the prior art is Limitation 1.6, which is the requirement
`that the account identifying information is not provided to
`the provider, but is provided to a third party to enable or
`deny the transaction. Brener teaches this is two ways. I'm
`going to jump to Slide 9 here.
` First, Brener discloses Limitation 1.6 in its
`anonymous shipping. As I explained, the vendor in Brener
`doesn't know the customer's name or address, but the secure
`provider sends that information to a third party shipping
`carrier to deliver the package. Now, Patent Owner has two
`arguments as to why this aspect of Brener doesn't meet
`Limitation 1.6. First, Patent Owner argues that the
`transaction in Brener has already been enabled by the time 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
`25
`
`10
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`shipper gets involved. But it's not clear and Patent Owner
`hasn't explained why the shipper cannot also enable the
`transaction.
` JUDGE MELVIN: Well, what about the claim language
`enable or deny? How can the shipper deny the transaction?
` MR. ARGENTI: Well, first I would argue that enable
`or deny doesn't require enable and deny. It says enable or
`deny, so by enabling the transaction, the shipper meets the
`claim requirement. However, even under an alternative
`interpretation where it requires both enabling and denying,
`which again, is inconsistent with the claim limit’s face. It's
`-- it absolutely is possible for a shipper to refuse to
`provide shipment.
` And in fact, Patent Owner's own expert testified
`that a shipping carrier could refuse to provide shipping. And
`that's at Exhibit 1015, Page 67, Lines 17 through 18. And
`that just makes sense, I mean, intuitively. I don't think
`anybody would ever argue or understand that a shipping carrier
`is always bound to carry out a shipment if it doesn't have the
`necessary information. If it doesn't have payment, if it
`doesn't have the product. There are a lot of different ways
`that a shipping carrier could not carry out payment.
` Now, I want to get back to the -- Patent Owner's
`argument as to the transaction already having been enabled.
`Patent Owner's trying to portray what's going on in Brener 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
`
`11
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`two separate transactions, a purchase transaction and a
`shipping transaction. And that also, intuitively, doesn't
`make sense. Nobody thinks when you order something online
`from Amazon that there are two different transactions
`involved, one where you pay Amazon and one where they ship you
`the goods. You pay for the goods; you receive the goods.
`It's a single transaction.
` And that's the same thing as what's going on in
`Brener and in the '539 Patent. I'll also point out that the
`'539 Patent treats purchase and shipment as a single
`transaction. For example, that's Figures 10 and 11 in the
`corresponding discussion at Column 1328 through 1458.
` And finally, Patent Owner's argument is directly at
`odds with Dependent Claim 25, and I believe it also applies to
`Dependent Claim 4, which covers similar limitations. As we
`see on Slide 9, Dependent Claim 25 says that the transaction
`includes a service that includes delivery, and that delivery
`is affected by providing the address to the third party to
`accomplish delivery for the provider. That's exactly what
`we're pointing to in Brener, it's the same thing.
` And moreover, even if the shipping is interpreted to
`be a separate transaction from the purchase somehow, which we
`don't think makes any sense at all, I think the petition also
`establishes that Brener discloses that every limitation of
`Claim 1, we pointed to an aspect of the shipping portion 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
`
`12
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`Brener as satisfying the claim. So even if you want to
`completely bifurcate the shipping from the purchase and say
`that the shipping is its own transaction, we've shown that
`Brener discloses that.
` Now, I'll jump back to Slide 8. Brener also
`discloses Limitation 1.6 through its disclosure that a bank
`receives the customer's account identifying information to
`determine whether the customer has sufficient funds for the
`purchase. Patent Owner argues that the transaction request
`goes from the vendor to the bank, not from the vendor to the
`secure provider to the bank. We don't think that matters in
`the context of the claims, but Brener plainly teaches that the
`bank can receive the request from the secure provider, as we
`see in Slide 8 in the citation to Brener at 14, Lines 16
`through 22.
` Patent Owner also argues that bank in Brener only
`receives linking information from the secure provider, not
`account identifying information. But the linking information
`in Brener is information used to identify a customer's
`account, i.e., account identifying information. Moreover,
`Brener discloses that the linking table can be stored at
`either the secure provider or the bank. For example, at Page
`8, Line 9 through 20, as we've cited on Slide 8, when it's
`stored at the secured provider, the secure provider uses that
`table to provide the account information to the bank.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`13
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
` So Brener discloses that the transaction request can
`go to the secure provider, and it discloses that the secure
`provider sends account information to the bank, regardless of
`whether that's linking information or account information,
`like an account number, and nothing more is required by the
`claims.
` JUDGE MELVIN: Well, when the linking information is
`at the bank, how is that consistent with the claim term --
`where the secure provider has to map the code to the customer
`information?
` MR. ARGENTI: I agree that Brener discloses that the
`linking information can be stored at the bank, but that's not
`the aspect of Brener that we're relying on. We're relying on
`the storage of the linking information at the secure provider.
`And then, either that linking information is provided to the
`bank by the secure provider, or the secure provider uses the
`linking information to look up account information, like an
`account name or number, sends that to the bank.
` JUDGE MELVIN: But if the -- if you're relying on
`sending the linking information from the secure provider to
`the bank, that would have to be consistent with Brener's
`embodiment where the bank is the one doing the mapping, right?
` MR. ARGENTI: Well, but the secure provider has
`already done the mapping between the time-varying
`multicharacter code, which is the modified customer object, 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
`
`14
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`we've proposed.
` JUDGE MELVIN: That's true in certain embodiments of
`Brener.
` MR. ARGENTI: Right.
` JUDGE MELVIN: But in that case, why would the
`secure provider send the linking information to the bank?
` MR. ARGENTI: Because the bank uses that linking
`information to look up, for example, the account number. So I
`think Brener discloses that it can happen in a lot of
`different ways, including a way in which the secure provider
`uses the time-varying multi -- the customer object to look up
`the linking information, provide that linking information to
`the bank, which can then use it to correlate to a -- to an
`account number.
` JUDGE MELVIN: Isn't that the whole purpose of the
`linking information is to correlate the customer number to the
`account information?
` MR. ARGENTI: That is a purpose, yes. But as --
` JUDGE MELVIN: I just don't understand why in Brener
`both mappings would happen -- the mapping would happen at both
`locations? It seems like those are sort of two possibilities.
`Like, Brener clearly contemplates you could use the linking
`information at the secure provider or you could use it at the
`bank.
` But it seems to me like if you're talking about
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`15
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`satisfying Limitation 1.6 with the secure provider sending the
`linking information to the bank, then that would cause a
`problem for Limitation 1.3 because it would be, you know --
`you can't have it both -- it would be mixing Brener's
`embodiments. Maybe that's --
` MR. ARGENTI: Sure. And all I can do is fall back
`on the disclosure in Brener where it provides multiple options
`of ways to do it. And I'm not sure that Brener provides an
`explicit explanation as to why the particular combination that
`you're discussing --
` JUDGE MELVIN: It doesn't clearly delineate these
`two, sort of, approaches.
` MR. ARGENTI: I think that's true, which is an
`important point to make. I think Patent Owner consistently
`presents Brener as presenting these discrete embodiments, and
`Brener's really not written that way. It's written in a way
`that really presents a system and says that there are a lot of
`options in how to set the system up.
` JUDGE MELVIN: Okay.
` MR. ARGENTI: And I also want to get back to the
`point that the linking information is not solely what we're
`relying on as the account identifying information. We're also
`-- it's also clear --
` JUDGE MELVIN: When the mapping is performed at the
`secure registry, then it's the actual account identifying
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`16
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`information --
` MR. ARGENTI: Right.
` JUDGE MELVIN: -- that's provided to the bank?
` MR. ARGENTI: And that is provided to the bank.
` So I'll turn now to Slide 10 and discuss the
`combination of Brener and Weiss. As our expert, Dr. Tygar
`explained, a person of ordinary skill would have found it
`beneficial to incorporate a time-varying aspect into Brener's
`customer objects, resulting in a time-varying code that
`corresponds to the user's identity via the linking information
`stored in the secured database.
` Weiss explains the time-varying codes provide added
`security in the event that they fall into the wrong hands.
`You're not going to be able to use that code in perpetuity.
`You're not going to be able to reuse it. At some point it's
`going to expire and you're going to be able to tell that, hey,
`that's not the right user that's sending me that code. It
`makes perfect sense to incorporate that into Brener's customer
`object to make them more secure.
` Now, Patent Owner's rebuttal is to mischaracterize
`Brener's discloser and our ground of challenge. According to
`Patent Owner, the only combination we proposed was to modify
`Brener's private key authorization code, which, in their view,
`must be a static digital certificate and it just wouldn't work
`to modify. And none of that is accurate. As you see here 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
`
`17
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`Slide 10, our proposed combination was to incorporate a
`time-varying aspect into Brener's customer object. Patent
`Owner has no response to that proposal.
` Turning to Slide 11, Patent Owner, as I mentioned,
`focuses on our example of modifying Brener's private key
`authorization code to include a time-varying aspect. Now,
`according to Patent Owner, again, the private key
`authorization code can only be a digital certificate, but
`that's not true. Brener itself explains that the customer
`object can have both a public and private segment to a digital
`certificate or key; it's not limited to a digital certificate.
` And then, if you look also on Slide 11 at Patent
`Owner's expert testimony, he admitted -- actually, this is not
`an admission, this was in his original declaration submitted
`pre-institution. That the private key authorization code
`discussed in Brener is a digital signature. It was only after
`institution and after Dr. Tygar's testimony, that all of a
`sudden Dr. Jakobsson said, Oh, it's not a digital signature.
`That's not what I meant. It can only be a digital
`certificate. So it's clear that the proposed modification is
`not so limited as Patent Owner proposes. And their rebuttal
`theory can and should be rejected on that basis alone.
` Turning to Slide 12, however, even in the instances
`where the private key authorization code is a digital
`certificate, Patent Owner is wrong that you cannot incorporate
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`
`18
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`a time-varying aspect. The rebuttal argument that Patent
`Owner presents depends on an assumption that the digital
`certificate itself would be made time varying. That's not
`something that we ever proposed in the petition. It was not
`the basis of institution where the Board recognized that we
`were not proposing making the entire customer object time-
`varying.
` And our expert repeatedly explained during his
`deposition, before the Patent Owner response was submitted,
`that Patent Owner was mischaracterizing his testimony. He
`explained that, consistent with our proposal, you could append
`time-varying information to a digital signature or a digital
`certificate. Patent Owner knew that. They knew that that was
`the basis of our expert's testimony before the Patent Owner
`response was due, and they never responded.
` Instead, they chose to attack a straw man, this idea
`that we're proposing modifying a digital certificate to be
`time varying. To this day, Patent Owner has not identified
`any reason that it would be technically infeasible to modify a
`customer object to include a time-varying portion.
` Now, turning to Slide 13. I'll talk about the basis
`for combining the teachings of Brener and Desai.
` JUDGE MELVIN: I have a question about Weiss.
`You know, in the institution decision, we discussed that it
`seemed possible to regenerate public/private pairs, even 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
`
`19
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`incorporate it -- a time-varying aspect. I mean, was that
`incorrect and that really, we should look at the time-varying
`aspect as independent from the private/public key pair itself?
` MR. ARGENTI: I won't stand here and say that that's
`incorrect because I think that that has not been fully
`developed in the record. But I do think that the basis of our
`proposed combination, or at least our response to Patent
`Owner's straw man is that you don't have to change the key
`pairs, you don't have to change the certificate. All you do
`is add a time-varying aspect to the information that's on
`there.
` JUDGE MELVIN: Regeneration is only relevant if the
`time-varying aspect were integral to the key pair?
` MR. ARGENTI: Right. Yes.
` JUDGE MELVIN: All right.
` MR. ARGENTI: So on Slide 13, Dr. Tygar, our expert,
`explained that a person of ordinary skill in the art would
`have been motivated to move beyond Brener's role-based access
`restrictions and apply restricted access on a vendor-by-vendor
`basis, as selected by the user. And that this would have been
`a natural extension of the Brener system, and consistent with
`the benefits of security and anonymity common to both
`references.
` Turning to Slide 14, Patent Owner argues that the
`proposed combination would somehow require a vendor to share
`
`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
`
`20
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`its keys with the bank, but that's not what we proposed and
`it's not consistent with the references. As you see on Slide
`14, Dr. Jakobsson admitted that users in Desai don't need to
`share keys with each other to access information. They each
`have their own keys that are used to access the information
`that they, themselves, have been given access to in the system
`by the registered user. In our combination, the customer
`entity.
` And quickly flipping back to Slide 6, just another
`way of illustrating that point. If you look at Figure 2 on
`Slide 6, you see that there are three entities that receive
`information access, an online vendor, a business contact, and
`a telemarketer. And there's no sharing of keys described in
`Desai or necessary in Desai in order for each of those three
`entities to have their varying levels of information access.
`They each have their own keys in the system.
` Now, turning to Slide 15, the only -- that covers
`the disputed issues for the independent claims. The only
`other claims that Patent Owner addresses are Claims 3 and 24,
`which require that the time-varying multicharacter code is
`encrypted, transmitted to the secure registry system, and then
`decrypted at the secure registry using the users public key.
`Dr. Tygar explained that this is disclosed by Brener through
`its use of RSA technology for digital signatures.
` He explained that a person of ordinary skill in 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
`25
`
`21
`
`
`

`

`Case IPR2018-01350
`Patent 8,856,539 B2
`
`art would understand, digital signatures using RSA encrypt
`data at the sender, and decrypt it at recipient using the
`sender's public key. We thought that would not be a
`controversial point, but Patent Owner came back and argued
`that digital signatures and encryption are two entirely
`different things.
` So we showed that Dr. Tygar's testimony was
`absolutely accurate. We introduced the Schneier reference,
`which is a textbook from the mid-1990s, a well-known textbook
`on cryptography that says exactly what Dr. Tygar said. That
`when you're using RSA for digital signatures, you're
`encrypting on one end and decrypting on the other end. Patent
`Owner did not address or respond to Exhibit 1016 in its
`surreply.
` Finally, on Slide 16, I'll briefly address Patent
`Owner's arguments with respect to secondary considerations of
`non-obviousness. As we know, evidence of commercial success
`requires a nexus with the claimed invention. And beyond a
`ball of conclusory assertion regarding Apple and Visa's
`products somehow demonstrating commercial success of the
`invention, Patent Owner has not even tried to establish a
`connection between the two.
`

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


Or .

Accessing this document will incur an additional charge of $.

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

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket