Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 1 of 12
`
`IN THE UNITED STATES DISTRICT COURT
`FOR THE WESTERN DISTRICT OF TEXAS
`WACO DIVISION
`
`§
`Case No. 6:21-cv-00916-ADA
`§
`
`§
`JURY TRIAL DEMANDED
`§
`§
`
`§
`§
`§
`§
`§
`§
`
`
`Plaintiff,
`
`Defendant.
`
`
`OPPOSED MOTION FOR ENTRY OF DISPUTED PROTECTIVE ORDER
`
`
`
`
`
`RFCYBER CORP.,
`
`
`
`
`v.
`
`
`APPLE, INC.,
`
`
` 
`
`
`
` 
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 2 of 12
`
` 
`
`I.
`
`INTRODUCTION
`
`Plaintiff RFCyber Corp. (“RFCyber” or “Plaintiff”) respectfully requests that Court enter
`
`its Proposed Protective Order, attached hereto as Exhibit A. RFCyber’s proposed order closely
`
`follows the Court’s default protective order, with only three minor modifications which are
`
`highlighted in Exhibit A. Apple has refused to agree to entry of virtually any provision of the
`
`default protective order. Instead, Apple’s proposal is based on a model protective order from the
`
`Northern District of California, with an extensive wish list of additional restrictions that would
`
`make discovery practically impossible. While Apple ultimately revised its proposal to loosely
`
`follow the format of the default protective order, the substance of its proposal remains unchanged.
`
`See Ex. B (highlights showing departures from the Court’s default protective order). Apple’s
`
`proposal more than doubles the length of the default protective order, adding at least ten entirely
`
`new sections, and at least eleven new subsections regarding source code alone. Apple fails to show
`
`any legitimate interests served by these radical departures from the default order. Instead, Apple’s
`
`new provisions all serve to (1) substantively impede discovery; (2) impose an unreasonable burden
`
`on the Receiving Party; or (3) needlessly complicate the Protective Order, creating the possibility
`
`for abuse. Apple’s attempt to interfere with discovery should be rejected, and the Court should
`
`enter RFCyber’s proposal following its default protective order, attached as Exhibit A.
`
`II.
`
`BACKGROUND
`
`The parties exchanged proposed protective orders in mid-February, 2022. RFCyber
`
`proposed the Court’s default order, while Apple’s proposal followed an N.D. Cal. model,
`
`supplemented with a labyrinthine wish-list of restrictions. Apple maintained that proposal during
`
`and after the parties’ meet and confer teleconference with lead counsel regarding the Protective
`
`Order on March 21, 2022. In view of those discussions, RFCyber agreed to a notice provision for
`
`code reviews, added a provision requiring monitors, keyboards, and mice to be provided to code
`
`2
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 3 of 12
`
` 
`
`reviewers, and adopted a provision governing the procedure for adding review software in an
`
`attempt to compromise with Apple. See Ex. A (highlights denoting added provisions). Apple
`
`responded on April 8, 2022 by adopting Apple’s proposal from an unrelated action involving an
`
`unrelated plaintiff, Jawbone Innovations, LLC v. Apple Inc., 6:21-cv-00984, and improperly
`
`suggesting that Plaintiff’s counsel was obligated to negotiate both protective orders jointly.
`
`Apple’s April 8 proposal, while loosely reformatted based on the Court’s default order,
`
`included the same onerous restrictions as its earlier proposals, and did not include the edits from
`
`RFCyber’s proposal. Realizing the parties were at an impasse, RFCyber suggested the parties file
`
`a joint motion, with each party providing a statement of its position, and provided Apple with
`
`RFCyber’s position on April 22, 2022. Apple initially agreed to provide its portion of the motion
`
`by Thursday, April 28, but then reneged, stating that “Apple requires additional time to prepare its
`
`portion of the joint motion” and “will provide an update on anticipated timing next week.” The
`
`parties again met and conferred on May 2, 2022, at which time Apple was still unable to provide
`
`a date certain for its position. Having exhausted all other options, and with Apple having confirmed
`
`its opposition, RFCyber was left with no choice but to file this Motion opposed.
`
`III. ARGUMENT
`
`The Court’s default protective order already strikes the proper balance between allowing
`
`for efficient discovery and addressing the parties’ legitimate security concerns. RFCyber’s
`
`proposal follows the Court’s default order except for minor changes which were primarily adopted
`
`in the interest of compromise. Apple’s proposal is replete with restrictions that would make
`
`discovery unduly burdensome, if not impossible. Apple has failed to show any legitimate need for
`
`such restrictions.
`
`Apple’s departures from the Court’s default order fall into at least one of three categories,
`
`all of which should be rejected: (1) provisions that substantively impede discovery; (2) provisions
`
`3
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 4 of 12
`
` 
`
`that impose an unreasonable burden on the Receiving Party; and (3) provisions that needlessly
`
`complicate the Protective Order, adding likelihood of abuse and unnecessary disputes. For
`
`example, the following provisions fall into at least one of the first two categories:
`
`Source Code Provisions:
`
`
`
`Apple’s proposal at Section 10(f) would make source code discovery practically impossible
`
`by prohibiting copying of any “Source Code Material” into notes during review. Section
`
`10(m) similarly prohibits use of any “Source Code Material” in discovery correspondence
`
`between the parties. In effect, Apple’s proposal would prevent the parties from using even
`
`the name of any class, variable, function, namespace, or other structure inside the code.
`
`But it is impossible to take effective notes on code or to write effective discovery
`
`correspondence regarding code without referring to some portion of that code (e.g., if
`
`produced code calls a function whose code has not been produced, the Receiving Party
`
`would need to refer to the name of the function to request its code). Apple’s provisions
`
`would allow the Protective Order to be used as a sword and shield to prevent Receiving
`
`Parties from specifically describing deficiencies in source code productions while
`
`simultaneously allowing the Producing Party to pretend confusion as to the code being
`
`requested. These provisions would burden the parties and impede discovery, rather than
`
`serving any legitimate security concern.
`
`
`
`Apple’s proposal at Section 10(b) only agrees not to disable USB ports of the review
`
`computer, rather than providing for monitors, an external keyboard, and an external mouse
`
`as RFCyber proposes. It is impractical for code reviewers to travel with full-size computer
`
`monitors, and far less burdensome for the parties to provide them on-site.
`
`4
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 5 of 12
`
` 
`
`
`
`Apple’s proposal at Sections 10(e)-(f) prohibit a note-taking computer. Requiring
`
`handwritten notes impedes discovery and adds costs by slowing code review. There is no
`
`provision requiring handwritten notes in the Court’s default order, which already addresses
`
`the parties’ security concerns, and Apple fails to justify any such additional restrictions.
`
`
`
`Apple’s proposal in Section 10(d) requires that the “Producing Party approves” any code
`
`review tools, effectively giving the Producing Party unilateral authority to reject any tool,
`
`regardless of the reason. While RFCyber anticipates using standard tools such as
`
`NotePad++, SciTools Understand, Beyond Compare and the like, and informed Apple that
`
`it was open to a prohibition against compilers, Apple’s absolute requirement that it be
`
`allowed to reject any tool for any reason is unworkable. Apple’s suggestion that RFCyber
`
`attempt to list all permitted tools now is equally unworkable, as it is impossible to
`
`enumerate every tool that a reviewer may request in advance of a review,
`
`
`
`Apple’s proposal requires approval from the Producing Party to use source code in expert
`
`reports, briefs, and filings with the Court. For example, Apple’s proposal for Section 10(l)
`
`requires a meet and confer to secure approval from the Producing Party prior to including
`
`source code material in “a filing with the Court,” and seeks to limit the maximum amount
`
`of material used in filings and expert reports. Apple’s proposal at Section 10(n) similarly
`
`requires consent, even for drafts of briefs, expert reports, and other documents which must
`
`be served electronically. Section 10(v) goes on to prohibit creation of images of source
`
`code for any reason (including filings and the like). Setting aside the unnecessary burden
`
`and redundant overlapping provisions of this policy, a Producing Party should not be
`
`allowed to dictate the amount of source code on which a party relies on to prove their case,
`
`5
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 6 of 12
`
` 
`
`for example, at summary judgment. The Court’s default order already addresses any
`
`legitimate concerns by providing for secure review and filing under seal.
`
`
`
`At Section 8, Apple adopts an unduly broad definition of “source code” that would severely
`
`impede discovery without serving any legitimate security concern. In addition to the code
`
`itself, Apple would impose source code restrictions on “Hardware Description Language
`
`(HDL) or Register Transfer Level (RTL) files that describe the hardware design of any
`
`ASIC or other chip, and Computer Aided Design (CAD) files that describe the hardware
`
`design of any component.” This definition would effectively capture various hardware
`
`specifications, requiring unreasonably burdensome on-site and in-person review of any
`
`such documents. The Court’s default order already allows such documents to be designated
`
`as “CONFIDENTIAL – ATTORNEYS’ EYES ONLY,” and Apple fails to show why any
`
`departure from that practice is warranted.
`
`
`
`Apple’s proposal at Section 10(k) rejects the Court’s default provision that an expert’s
`
`access to source code includes their “direct reports and other support personnel.” Apple
`
`fails to articulate any legitimate security concern that justifies the disproportionate costs
`
`and burden of preventing experts from using professional code reviewers on their staff.
`
`
`
`At Section 10(o), Apple imposes unreasonable restrictions on source code printouts. It
`
`seeks to flip the burden to the Receiving Party to show that any printed source code is “no
`
`more than is reasonably necessary for a permitted purpose” and imposes a 14-day waiting
`
`period to even receive printouts. It also limits the Parties to 200 pages of source code
`
`printouts. At Section 10(s), Apple further seeks to limit the Parties to three sets of
`
`photocopies of the printed code, rather than the ten allowed in the Court’s default order.
`
`The Court’s default order already provides for adequate protections and “a reasonable
`
`6
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 7 of 12
`
` 
`
`number of printouts.” Apple fails to demonstrate that such burdensome restrictions on top
`
`of the Court’s default order are appropriate.
`
`
`
`In Section 10(q), Apple seeks to add a provision that a party has “no expectations of privacy
`
`for items left in the [review room] following each inspection session,” allowing a
`
`producing party to inspect any work product inadvertently forgotten in the review room.
`
`This provision does not serve any legitimate interest.
`
`
`
`At Section 10 (t) Apple seeks to impose a requirement that the producing party be notified
`
`10-days in advance of any source code to be used in a deposition, and that the source code
`
`printouts utilized at the deposition be provided by the producing party. Setting aside the
`
`impropriety of forcing the party taking a deposition to rely on documents prepared by the
`
`other side, this provision would unfairly give the producing party advance notice to prepare
`
`witnesses on the exact source code that the deposing party plans on using. This is
`
`tantamount to a mandatory disclosure of protected work product. It is also impractical to
`
`require such advance notice, as the deposing party may not have completed preparations
`
`so far in advance and may not even know what source code it plans to introduce.
`
`Post-Suit Monitoring Provision
`
`
`
`At Section 11, Apple would require that the Parties continue to monitor their outside
`
`consultants and experts for 2 years following the conclusion of this action and
`
`“immediately provide written notice of any change with respect to the Person’s
`
`involvement in the design, development, operation or patenting of mobile payment
`
`hardware or software.” It is unclear what legitimate interest this serves, or how the burden
`
`of such a provision to both RFCyber and its consultants is proportional to any interest. The
`
`Court’s default order already adequately provides for compliance of experts with the
`
`7
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 8 of 12
`
` 
`
`protective order without saddling them with ongoing reporting obligations likely to
`
`severely limit the field of experts willing to be engaged.
`
`One-way Prosecution and Acquisition Bars:
`
`
`
`At Section 13, Apple seeks to impose a prosecution bar that: (1) applies unilaterally to
`
`plaintiff’s counsel; (2) adds an acquisition bar prohibiting counsel from being “involved
`
`with the acquisition of patents” in the area of this case; (3) prohibits prosecution and
`
`acquisition of such patents for any client, as opposed to the represented party; (4) applies
`
`for 2 years following the conclusion of this action, rather than the customary 1 year
`
`reflected in the Court’s default order; and (5) removes the possibility of an ethical wall
`
`allowing attorneys in a firm to continue to work on matters related to the technology at
`
`issue. Apple’s one-way bar is particularly nonsensical, as RFCyber anticipates making its
`
`own source code available for review. Apple fails to show any legitimate interest advanced
`
`by such a draconian prosecution and acquisition bar. 
`
`The remainder of Apple’s departures needlessly complicate the Protective Order, adding
`
`likelihood of abuse and unnecessary disputes. These provisions are of dubious utility, largely
`
`rewriting existing provisions of the Court’s default order to be longer and less clear. They serve
`
`primarily to burden the parties while unnecessarily creating the possibility for abuse and additional
`
`disputes. For example:
`
`
`
`Apple’s proposal at Section 1(d) would impose unduly burdensome procedures on natively
`
`produced documents, requiring, among other things, a burdensome pre-approval process
`
`that would require the Receiving Party to disclose its work product to the other Party before
`
`using natively-produced documents. Such procedures are unnecessary and unwarranted,
`
`8
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 9 of 12
`
` 
`
`particularly as native documents may be designated under this Court’s default order in the
`
`same manner as documents produced as .pdf or .tiff images.
`
`
`
`Apple’s proposal at Section 5(e) removes the Court’s default timetable for objections to
`
`consultants and experts, instead adopting a labyrinthine approach where objection periods
`
`for different disclosures are set under Section 11, and its proposal at Section 12 expressly
`
`allows for late objections upon some unidentified “good cause.” Apple’s proposal allows
`
`for delay and uncertainty without advancing any legitimate interest.
`
`
`
`Apple’s proposal at Section 1(b) would presumptively deem all deposition transcripts of
`
`party and non-party witnesses, “CONFIDENTIAL-ATTORNEYS’ EYES ONY.” Apple
`
`advances no good reason that all deposition transcripts should be presumptively limited to
`
`outside counsel.
`
`
`
`Apple proposes at Section 9(b) that experts’ access to designated materials be limited “to
`
`the extent necessary to perform [their] work” in this action. This provision opens the
`
`possibility of abuse to limit an expert to some subset of documents produced in this action,
`
`without advancing any interest. Notably, Apple could not articulate any issue with giving
`
`an expert access to a litigation discovery database during the parties’ meet and confer –
`
`this provision serves no purpose except to add complication to the protective order.
`
`
`
`Apple’s proposal at Section 6 departs from the Court’s default by requiring the parties to
`
`designate CONFIDENTIAL any documents that “contain or reflect confidential,
`
`proprietary, and/or commercially sensitive information.” Unlike the Court’s default,
`
`Apple’s designation would not be limited to “a good faith belief that the documents,
`
`information, or material contains confidential or proprietary information or trade secrets of
`
`the Party or a Third Party to whom the Party reasonably believes it owes an obligation of
`
`9
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 10 of 12
`
` 
`
`confidentiality.” Apple fails to show any good reason to depart from the Court’s default,
`
`and creates the possibility of a party attempting to designate publicly available documents
`
`“confidential” without any authority or obligation to do so.
`
`As a whole, Apple’s proposed protective order is unworkable. It would disproportionately
`
`burden the parties rather than serving any legitimate security concern. Apple’s assumption that its’
`
`documents are automatically entitled to extremely burdensome restrictions is unjustified, and it
`
`has failed to articulate any legitimate concern that is not already served by the Court’s default
`
`order. RFCyber respectfully requests that the Court enter RFCyber’s proposed protective order,
`
`attached hereto as Exhibit A.
`
`Dated: May 3, 2022
`
`
`
`Respectfully submitted,
`
` /s/Jacob Ostling
`Raymond W. Mort, III
`Texas State Bar No. 00791308
`Email: raymort@austinlaw.com
`THE MORT LAW FIRM, PLLC
`100 Congress Avenue, Suite 2000
`Austin, Texas 78701
`Tel/Fax: 512-865-7950
`
`OF COUNSEL:
`
`Alfred R. Fabricant (Pro Hac Vice to be filed)
`NY Bar No. 2219392
`Email: ffabricant@fabricantllp.com
`Peter Lambrianakos (Admitted Pro Hac Vice)
`NY Bar No. 2894392
`Email: plambrianakos@fabricantllp.com
`Vincent J. Rubino, III (Pro Hac Vice to be filed)
`NY Bar No. 4557435
`Email: vrubino@fabricantllp.com
`Richard M. Cowell (Admitted Pro Hac Vice)
`NY Bar No. 4617759
`Email: rcowell@fabricantllp.com
`Jacob Ostling (Admitted Pro Hac Vice)
`NY Bar No. 5684824
`Email: jostling@fabricantllp.com
`
`10
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 11 of 12
`
` 
`
`FABRICANT LLP
`411 Theodore Fremd Avenue, Suite 206 South
`Rye, New York 10580
`Telephone: (212) 257-5797
`Facsimile: (212) 257-5796
`
`ATTORNEYS FOR PLAINTIFF
`RFCYBER CORP.
`
`
`
`
`
`11
`
`

`

`Case 6:21-cv-00916-ADA-DTG Document 45 Filed 05/03/22 Page 12 of 12
`
` 
`
`CERTIFICATE OF SERVICE
`
`I hereby certify that on May 3, 2022, I electronically filed the foregoing with the Clerk of
`
`Court using the CM/ECF system, which will send notification of such filing via electronic mail to
`
`all counsel of record. Any other counsel of record will be served by first class U.S. mail.
`
`/s/Jacob Ostling
` Jacob Ostling
`
`
`
`
` 
`
`