`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`__________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`__________________________________________________________________
`
`
`
`APPLE INC.,
`
`Petitioner,
`
`v.
`
`RFCYBER CORP.,
`
`Patent Owner.
`
`
`Patent No. 10,600,046
`Filing Date: June 2, 2015
`Issue Date: March 24, 2020
`
`Inventors: Xiangzhen Xie, Liang Seng Koh, and Hsin Pan
`Title: METHOD AND APPARATUS FOR MOBILE PAYMENTS
`
`
`__________________________________________________________________
`
`PATENT OWNER’S SUR-REPLY
`
`Case No. IPR2022-01239
`
`__________________________________________________________________
`
`
`
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`TABLE OF CONTENTS
`
`Page(s)
`
`I.
`
`PETITIONER’S COMBINATION DOES NOT RENDER AN E-
`PURSE OBVIOUS .......................................................................................... 1
`A.
`Petitioner Cannot Remedy its Failure to Identify an E-purse in
`the Petition ............................................................................................. 1
`Petitioner Does Not Show that any E-purse Is “maintained
`locally in the mobile device” ................................................................. 3
`1.
`Laracey maintains its balance and other financial
`information on a server, even if out-of-date data were
`stored on the mobile device ........................................................ 3
`Petitioner’s use of Jogu’s “balance update” does not
`remedy Laracey’s deficiencies .................................................... 6
`Laracey Does Not Store Financial Information on the Mobile
`Device .................................................................................................... 7
`A POSITA WOULD NOT COMBINE JOGU AND LARACEY ................10
`II.
`III. CONCLUSION ..............................................................................................13
`
`
`B.
`
`C.
`
`2.
`
`i
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`TABLE OF AUTHORITIES
`
` Page(s)
`
`Cases
`Apple Inc. v. UUSI, LLC,
`No. 2021-1035, 2023 WL 3071643 (Fed. Cir. Apr. 25, 2023) ............................. 2
`MModal LLC v. Nuance Commc’ns,
`846 F. App’x 900 (Fed. Cir. 2021) ............................................................. 1, 2, 10
`
`
`
`
`
`ii
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`EXHIBIT LIST
`
`Exhibit No. Description of Document
`
`2001
`
`2002
`
`2003
`
`Declaration of Alfred C. Weaver, Ph.D.
`
`CV of Alfred C. Weaver, Ph.D.
`
`Transcript of May 11, 2023 Deposition of Gerald W. Smith
`
`
`
`
`
`
`
`
`iii
`
`
`
`Petitioner’s Reply attempts to shift the burden of persuasion by arguing that
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`Patent Owner “must convince this Board” that Petitioner’s combination fails to
`
`render the Challenged Claims obvious. Reply, 3. But it is Petitioner’s burden to
`
`persuade the Board that the claims are obvious. As shown below, Petitioner has
`
`failed to do so, and the Board should issue a Final Written Decision finding all
`
`Challenged Claims not unpatentable.
`
`I.
`
`
`
`PETITIONER’S COMBINATION DOES NOT RENDER AN E-
`PURSE OBVIOUS
`Petitioner Cannot Remedy its Failure to Identify an E-
`A.
`purse in the Petition
`Petitioner has failed to identify any “software” in meeting the e-purse
`
`limitation in its Petition. POR, 14. In its Reply, Petitioner attempts to handwave
`
`away this deficiency. Reply, 20 (“Neither PO nor Dr. Weaver dispute that Laracey’s
`
`mobile device utilizes software for its transaction functionality.”). But Petitioner did
`
`not identify Laracey’s “transaction functionality” software as the claimed e-purse.
`
`Instead, it identified a “stored value account.” Pet., 29; POR, 14.
`
`
`
`The Board should reject Petitioner’s late attempt to backfill its Petition.
`
`MModal LLC v. Nuance Commc’ns, 846 F. App’x 900, 906-07 (Fed. Cir. 2021)
`
`(affirming Board’s rejection of new argument raised on Reply). MModal is
`
`instructive. There, the Petitioner identified specific portions of a reference (Taira)
`
`as disclosing an element. Id. After the Patent Owner rebutted those portions, the
`
`1
`
`
`
`
`Petitioner attempted on Reply to rely on a separate discussion in Taira. Id. at 906.
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`The Board rejected that attempt, and the Federal Circuit agreed, noting that “A
`
`petitioner generally must provide in the petition an understandable explanation of
`
`the element-by-element specifics of the unpatentability challenges, including the
`
`particular portions of prior art supporting those challenges.” (emphasis added)).
`
`Here, Petitioner identified one aspect, and only one aspect, of Laracey as disclosing
`
`the e-purse—the “stored value account.” It cannot now expand that to some
`
`unspecified portion of Laracey’s software. Id. See also Apple Inc. v. UUSI, LLC,
`
`No. 2021-1035, 2023 WL 3071643, at *3 (Fed. Cir. Apr. 25, 2023) (affirming
`
`Board’s decision not to consider “what Apple meant to argue in its Petition”). It
`
`would be manifestly unfair to allow Petitioner, at the last moment, to expand its
`
`invalidity theory and deprive Patent Owner of the opportunity to meaningfully
`
`respond with expert testimony.
`
`
`
`Accordingly, Petitioner should be held to its original mapping of the e-purse
`
`to a “stored value account.” As explained by Dr. Weaver, and uncontroverted by
`
`Petitioner, an “account” is not software; it is a representation of data. POR, 14; Ex.
`
`2001, ¶ 56.
`
`
`
`Similarly, an account does not store financial information. POR, 14-15. And
`
`as explained further below, the financial information of Laracey is stored on the
`
`TMS. POR, 14-22.
`
`2
`
`
`
`The e-purse is a required element of all Challenged Claims. Because
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`Laracey’s “stored value account” does not meet the agreed construction for e-purse,
`
`Petitioner’s challenge must fail, and the Board should issue a Final Written Decision
`
`finding all Challenged Claims not unpatentable.
`
`B.
`
`Petitioner Does Not Show that any E-purse Is “maintained
`locally in the mobile device”
`Laracey maintains its balance and other financial
`1.
`information on a server, even if out-of-date data were
`stored on the mobile device
`In Reply, Petitioner fundamentally misunderstands Laracey’s dynamic
`
`
`
`checkout token. Laracey explains that a merchant POS device may generate a
`
`dynamic checkout token that contains “all of the transaction details.” Laracey,
`
`[0038], [0055]. The user’s payment information cannot be a transaction detail
`
`because the merchant POS never has any payment information and thus cannot
`
`generate a token that includes it. E.g., id., [0003] (“It would be desirable to provide
`
`systems and methods in which payment card information is not stored, captured,
`
`or transmitted by merchants”), [0041] (“By ensuring that actual payment
`
`credentials are not revealed to or stored at a merchant 108 or mobile device 102,
`
`embodiments provide increased account security and reduced potential for fraud or
`
`abuse.”) (emphases added). Every embodiment described in Laracey obtains
`
`financial information from the TMS. E.g., id., Figs. 4A-4C, 9.
`
`3
`
`
`
`Petitioner misconstrues Laracey’s disclosure as silently describing storing
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`financial information on the local device. Reply, 6-9. Key to Petitioner’s argument
`
`is Laracey’s pervasive use of “may.” Id. According to Petitioner, using “may”
`
`indicates that a POSITA would feel free to discard Laracey’s teachings for a system,
`
`never described, that happens to meet the limitations of the Challenged Claims.
`
`Laracey’s use of “may” does not provide support or motivation for a POSITA
`
`choosing to maintain financial information locally and, thus rendering the described
`
`TMS database superfluous.
`
`
`
`Petitioner tacitly admits that there is no disclosure of an embodiment in
`
`Laracey that maintains financial information locally. At best, Petitioner argues that
`
`“Laracey’s system fairly suggests maintaining account information on both the
`
`mobile device and the TMS.” Id., 11 (emphasis added). But even under Petitioner’s
`
`hypothetical and undisclosed Laracey system, it is still the TMS that maintains the
`
`information. As Petitioner admits, “This payment account management system is
`
`used by Laracey to update and synchronize account balances maintained in
`
`separate locations.” Id. (emphasis added). A POSITA would understand that
`
`maintaining financial information entails having the correct non-stale value of the
`
`information. POR, 22. Thus, the payment account management system, which
`
`Petitioner admits is part of the TMS (id.), maintains the actual financial information.
`
`4
`
`
`
`Petitioner’s confusion comes from
`
`its conflation of “stored” with
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`“maintained.” But as explained in the POR, even if Laracey stores potentially
`
`outdated financial information on the mobile device, that information is maintained
`
`in the TMS. POR, 24-25; Ex. 2001, ¶ 71. Indeed, the TMS must “match messages”
`
`from the mobile device with messages from the merchant to send the actual payment
`
`information to the account issuer or agent. Laracey, [0035], [0038] (“In either event
`
`[dynamic or static token], however, the checkout token is used to match messages
`
`from the mobile device 102 with messages from the merchant 108 at the transaction
`
`management system 130.”). As noted above, Petitioner itself admits that the TMS
`
`maintains the actual information, and merely updates the (hypothetically stored)
`
`information on the mobile devices.
`
`
`
`Finally, Petitioner draws a false equivalence between Laracey and Jogu.
`
`Reply, 11-12. Jogu is designed such that the payment account (maintained at the
`
`phone company) is associated with only one phone number (i.e., one device). POR,
`
`8-10. Since there is only one device using the payment account, the data cannot be
`
`stale; all purchases are made through the device itself, and thus the balance in the
`
`device is always correct. POR, 8-10, 28-30.
`
`
`
`Accordingly, for this separate reason, Petitioner’s combination fails to
`
`disclose or render obvious an “e-purse maintained locally in the mobile device” and
`
`5
`
`
`
`
`the Board should issue a Final Written Decision finding all Challenged Claims not
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`unpatentable.
`
`2.
`
`Petitioner’s use of Jogu’s “balance update” does not
`remedy Laracey’s deficiencies
`Petitioner argues that its reference to Jogu’s “balance update” had the effect
`
`
`
`of importing a locally stored balance into the combination. Reply, 12-14. The
`
`Petition, however, does not refer to Jogu at all with respect to the e-purse limitation.
`
`See Pet. at 29-32. Indeed, Mr. Smith explained that the combination uses Jogu only
`
`for the balance verification process. Ex. 2003, 57:17-19 (“But the balance
`
`verification would be Jogu, and the rest would be Laracey -- is the best I can
`
`answer.”); 75:11-15 (“Okay. And in your declaration, you just used Jogu for the
`
`balance verification step. Is that right? A That is correct: S718 in your Figure 22,
`
`balance verification.”).
`
`
`
`The Petition only mentions Jogu’s balance update in the context of the
`
`verification step. Pet. at 34-42. Even, then, the balance update is presented as
`
`updating Laracey’s alleged locally stored balance and not introducing a new locally
`
`stored balance. Pet. at 42 (“As in Jogu, Laracey maintains an account balance and
`
`receives a total invoiced amount from the POS terminal.”).
`
`6
`
`
`
`In any event, including Jogu’s balance update results in the same deficiency
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`as discussed above: Jogu’s balance is maintained on the server and downloaded to
`
`the mobile device. Pet. at 39-40 (describing the balance maintained at the server).
`
`C. Laracey Does Not Store Financial Information on the
`Mobile Device
`Petitioner devotes the bulk of its Reply to arguing that Laracey teaches or
`
`
`
`renders obvious storing financial information locally on the mobile device. See
`
`generally Reply. As shown above, though, regardless of whether Laracey stores
`
`financial information locally, Petitioner failed to identify any e-purse that is
`
`maintained locally.
`
`
`
`Moreover, Laracey does not store the financial information on the local
`
`device. Petitioner first attempts to wave away Laracey’s discussion of a single user
`
`with multiple devices using the system. Reply, 17-18. But this functionality exists
`
`in every embodiment in Laracey. POR, 25-28. Indeed, Laracey’s multiple device
`
`functionality is explicitly discussed—far more disclosure than the supposed local
`
`storage on which the Petition relies. See id.
`
`
`
`Petitioner next, curiously, argues that Laracey must only allow for a single
`
`device because Laracey never mentions the stale data issue. Reply, 19. But, as
`
`explained by Dr. Weaver and in the POR, the stale data issue is a result of
`
`Petitioner’s combination and does not occur in Laracey’s system as described,
`
`7
`
`
`
`
`because Laracey always downloads the current information before processing a
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`transaction. POR, 30-32; Ex. 2001, ¶¶ 82-86.1 Laracey would have no need to
`
`mention a problem that its system avoids. Moreover, the correct inquiry is whether
`
`a POSITA at the time of the invention would be aware that the proposed combination
`
`would cause the stale data problem. Both experts agree that one would. Ex. 2001,
`
`¶¶ 82-86; Ex. 1028, ¶¶ 11-13 (“Dr. Weaver correctly notes that stale data is a
`
`problem when multiple devices have access to the same account.”). Mr. Smith’s
`
`statement on this issue is nonsensical: “I acknowledge that Laracey suggests a user
`
`may register one or more device within Laracey’s system (e.g., Laracey, [0018]),
`
`but a POSITA would not interpret this to mean that a user might register multiple
`
`devices and assign different accounts to each device.” Ex. 1028, ¶11 (emphasis
`
`added). Mr. Smith immediately goes on: “Nothing in Laracey’s disclosure suggests
`
`accommodating the more complicated scenario in which the system allows multiple
`
`devices, potentially simultaneously, to access a single account.” Id. The Reply
`
`ignores the inherent contradiction: i) a POSITA would not interpret Laracey as using
`
`different accounts with different devices and ii) Laracey does not suggest allowing
`
`multiple devices to access a single account). Reply, 19.
`
`
`1 Mr. Smith concurred that Laracey always communicates with the TMS during a
`
`transaction. Ex. 2003, 63:11-15.
`
`8
`
`
`
`Instead, the Reply argues that a “POSITA would have interpreted Laracey to
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`contemplate a system in which each account is used by only a single device.” Id.2
`
`Such an interpretation is contrary to Laracey’s stated goals to allow customers to
`
`have access to all of their payment cards for all transactions. As Laracey explains:
`
`As another example disadvantage, current payment cards are
`typically associated with a single payment account. A cardholder
`may have a number of payment cards, but must make a conscious
`decision regarding which one (or ones, in the case of a split
`tender transaction) of those payment cards to use in a given
`transaction. It would be desirable to provide systems and
`methods which allow a customer to select one or more payment
`accounts for use in conducting a transaction.
`Laracey, [0004]. Petitioner’s interpretation would result in a system where a
`
`customer with multiple devices would essentially have the same problem as prior
`
`cards: the customer would not be able to access all their payment methods without
`
`carrying all devices. Neither Petitioner nor Mr. Smith provide any basis to conclude
`
`that a POSITA would interpret Laracey in such a contradictory and unwieldy
`
`fashion.
`
`
`2 Patent Owner presumes that Mr. Smith’s contradictory testimony is the result of a
`
`typographical error.
`
`9
`
`
`
`Finally, Petitioner argues that the combination of Laracey and Jogu
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`overcomes Laracey’s deficiencies as to the local storage. Reply, 19. First, Petitioner
`
`did not raise this argument in its Petition; instead, it relied solely on an unmodified
`
`Laracey for the e-purse element. Pet., 29-32; see also Ex. 2003, 57:17-19 (“But the
`
`balance verification would be Jogu, and the rest would be Laracey -- is the best I
`
`can answer.”) (emphasis added). Petitioner cannot now expand its theories to use
`
`Jogu for this element. MModal, 846 F. App’x at 906-07. Second, contrary to
`
`Petitioner’s assertion in the Reply (Reply, 19) adding the single-device Jogu causes
`
`the exact stale data issues discussed above. POR, 30-32. In the multiple-device
`
`scenario, storing an account balance locally can result in a separate device using the
`
`same account to change the balance, rendering the local data stale. POR, 30-32.
`
`
`
`Accordingly, a POSITA would not find storing financial data locally to be
`
`disclosed or rendered obvious by Laracey.
`
`II. A POSITA WOULD NOT COMBINE JOGU AND LARACEY
`
`The POR explained that a POSITA would not combine Jogu and Laracey
`
`because Jogu’s offline balance check is incompatible with Laracey’s server-based
`
`balance storage and because there would be no benefit to doing so. POR, 28-32.
`
`
`
`In its Reply, Petitioner mischaracterizes Patent Owner’s arguments. First,
`
`Petitioner asserts that “the proposed combination does not rely on Jogu’s offline
`
`transaction functionality.” Reply, 24. Petitioner further states:
`
`10
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`Instead, the Petition explains that Laracey’s system would have been
`improved by specific features from Jogu, including (1) performing a
`balance check, (2) displaying a denial when the account balance is
`insufficient, (3) generating a payment request only when sufficient
`funds exist, and (4) reducing the account balance on the mobile device
`after a successful transaction to ensure the local balance is accurate.
`Petition, 36-42. None of these functionalities requires Laracey’s
`process to be offline.
`
`Reply, 24. Even if Jogu’s functionalities do not require Laracey to be offline, the
`
`Challenged Claims do. The Reply’s confusion appears to stem from not reading the
`
`critical limitation in full. As explained in the POR, the claims require verifying the
`
`balance without sending a request to a payment gateway. POR, 29-30. ’046 Patent,
`
`cl. 1 (“wherein said verifying the total amount with a balance in the e-purse is
`
`performed within the mobile device without sending the payment request to a
`
`payment gateway”), 12 (“the payment request is denied in the mobile device when
`
`the amount is more than a balance of an electronic purse (e-purse) maintained locally
`
`in the mobile device, the payment request is sent to a payment gateway when the
`
`amount is less than a balance of an electronic purse (e-purse) maintained locally
`
`in the mobile device”); 18 (“wherein the payment request is denied within the mobile
`
`device without sending the payment request to the payment gateway”) (emphases
`
`added).
`
`11
`
`
`
`Patent Owner never argued that the combination was reliant on Jogu’s offline
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`
`
`
`functionality. Instead, a POSITA would not be motivated to use Jogu’s balance
`
`verification step because it is incompatible and lacks any benefit in a Laracey
`
`system. POR, 29-30. The motivating reason for Jogu’s offline balance verification
`
`is that Jogu, unlike Laracey, may be used to make a purchase while not in
`
`communication with any servers. POR, 28-29. A POSITA would not import this
`
`offline balance check into a system where the balance is maintained on the server.
`
`Id., 28-32. And Petitioner explicitly admits that (under its combination) Laracey
`
`keeps a balance on the server and uses that balance to update all alleged copies.
`
`Reply, 11 (“This payment account management system is used by Laracey to update
`
`and synchronize account balances maintained in separate locations.”) (emphasis
`
`added).
`
`
`
`With
`
`that undisputed understanding of Laracey, Petitioner’s stated
`
`motivations to combine fall short. As explained in the POR, the possibility of stale
`
`data (again, undisputed by Petitioner and its expert) renders the first alleged
`
`motivation (to inform a user “of insufficient funds before attempting to proceed with
`
`a transaction that will ultimately fail”) impossible to achieve, as sufficient funds may
`
`likely have been added by other means than Laracey, rendering any hypothetical
`
`balance in the mobile device stale. POR, 31-32. Indeed, the Laracey system itself
`
`does not set out any method to add money to a gift card or stored value account, so
`
`12
`
`
`
`
`any additions must be through other means. Similarly, the alleged motivation to
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`avoid “human error” runs headlong into the same problem. Id.
`
`
`
`Finally, as explained in the POR, Jogu’s offline balance check is incompatible
`
`with Laracey’s explicit steps of downloading the balance and other payment
`
`information. Using an offline balance check would merely check against stale data
`
`and prevent the balance from actually updating (as the update in Laracey’s program
`
`flow comes after where the balance check would happen). POR, 29-32.
`
`
`
`Accordingly, a POSITA would not combine Jogu and Laracey to include
`
`Jogu’s balance check.
`
`III. CONCLUSION
`
`For the foregoing reasons, the Board should issue a Final Written Decision
`
`finding all Challenged Claims not unpatentable.
`
`
`
`Dated: September 1, 2023
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`/
`
`
`/Vincent J. Rubino, III
`Vincent J. Rubino, III (Reg. No. 68,594)
`Lead Counsel for Patent Owner
`Fabricant LLP
`411 Theodore Fremd Avenue,
`Suite 206 South
`Rye, New York 10580
`Tel. 212-257-5797
`Fax. 212-257-5796
`Email: vrubino@fabricantllp.com
`
`13
`
`
`
`
`
` IPR2022-01239
` PATENT NO. 10,600,046
`
`CERTIFICATE OF WORD COUNT
`
`The undersigned hereby certifies that the portions of the above-captioned
`
`PATENT OWNER’S SURREPLY specified in 37 C.F.R. § 42.24 have 2,763 words
`
`in compliance with the 5,600 word limit set forth in 37 C.F.R. § 42.24. This word
`
`count was prepared using Microsoft Word for Office 365.
`
`
`
`Dated: September 1, 2023
`
`
`
`
`
`
`
`
`
`Respectfully submitted,
`
`/
`
`
`/Vincent J. Rubino, III
`Vincent J. Rubino, III (Reg. No. 68,594)
`Lead Counsel for Patent Owner
`Fabricant LLP
`411 Theodore Fremd Avenue,
`Suite 206 South
`Rye, New York 10580
`Tel. 212-257-5797
`Fax. 212-257-5796
`Email: vrubino@fabricantllp.com
`
`14
`
`
`
`
`
`IPR2022-01239
`PATENT NO. 10,600,046
`
`CERTIFICATE OF SERVICE
`A copy of PATENT OWNER’S SUR-REPLY has been served on Petitioner’s
`
`counsel of record as follows:
`
`Paul R. Hart
`Email: paul.hart@eriseip.com
`Email: PTAB@eriseip.com
`ERISE IP, P.A.
`5299 DTC Boulevard, Suite 1340
`Greenwood Village, Colorado 80111
`
`Adam P. Seitz
`Email: adam.seitz@eriseip.com
`ERISE IP, P.A.
`7015 College Boulevard, Suite 700
`Overland Park, Kansas 66211
`
`Attorneys for Apple Inc.
`
`
`
`September 1, 2023
`
`
`
`By:
`
`/Vincent J. Rubino, III /
`Vincent J. Rubino, III (Reg. No. 68,594)
`FABRICANT LLP
`411 Theodore Fremd Avenue,
`Suite 206 South
`Rye, New York 10580
`Tel. 212-257-5797
`Fax. 212-257-5796
`Email: vrubino@fabricantllp.com
`
`
`
`
`
`
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
