Source Code Review in Patent Litigation: What Technical Experts Analyse

Your legal team has established that the accused product likely infringes your software patent, but proving it requires evidence you cannot obtain from external testing alone. The functionality operates server-side, processes data invisibly, or implements algorithms that only source code inspection can reveal.

Source code review has become essential in modern patent litigation involving software technologies. Whether you are enforcing a patent or defending against infringement claims, source code analysis often determines case outcomes at critical procedural stages—from preliminary injunction hearings to trial. In the UK, the Patents Court and Intellectual Property Enterprise Court handle numerous software patent disputes each year, while US district courts see software-related patents comprising approximately 60-70% of all patent litigation filings.12

In our experience supporting law firms through complex software patent disputes, source code review serves dual purposes: it provides patent holders with direct evidence of how accused software actually implements allegedly infringing functionality, and it offers defendants the opportunity to demonstrate that their implementations differ materially from claimed inventions. The technical analysis we conduct translates abstract patent claims into concrete, evidence-based comparisons with actual source code.

This guide explains what source code review involves, how confidentiality protections work, what technical experts analyse, and what deliverables you should expect from the process.

Important: This article provides general information about source code review in patent litigation for educational purposes. It is not legal advice and should not be relied upon as such. Patent litigation involves complex legal considerations that require qualified legal counsel. Always consult a solicitor, patent attorney, or qualified legal professional before taking action in litigation.

When Source Code Review Becomes Necessary

Software Patent Disputes Requiring Internal Analysis

Source code review becomes essential when traditional product testing cannot reveal the functionality at issue. We typically see this in disputes involving:

Server-side implementations: Cloud-based applications, API backends, and distributed systems where the allegedly infringing functionality operates remotely and cannot be observed through client-side testing.3

Background processes: Algorithms that execute invisibly—data processing pipelines, scheduling systems, caching mechanisms, and optimisation routines that operate without user interaction.4

Low-level operations: Memory management, driver implementations, firmware, and embedded systems where patented techniques operate beneath application layers.5

Algorithmic implementations: Machine learning models, compression algorithms, encryption routines, and computational methods where the innovation lies in how calculations are performed rather than what output is produced.6

In each scenario, external testing reveals only inputs and outputs while the allegedly infringing methodology—the actual implementation—remains invisible without source code access.

Proving Infringement

For claimants seeking to establish patent infringement, source code review provides the most direct evidence of how accused software actually implements allegedly infringing functionality. Under UK law, establishing infringement requires demonstrating that the defendant has performed acts falling within the scope of the patent claims as properly construed—analysis that often necessitates detailed examination of source code when claims cover software implementations.78

We find that infringement analysis typically involves detailed comparison of source code against patent claim limitations, examining both literal infringement and infringement under the doctrine of equivalents (where applicable). The Supreme Court's decision in Actavis UK Ltd v Eli Lilly & Co 2017 UKSC 48 established the modern UK approach to equivalents, requiring analysis of whether variants achieve substantially the same result in substantially the same way.910

Defending Non-Infringement

Defendants can employ source code review to demonstrate that their software lacks specific patented features—particularly those difficult to detect through product testing. By establishing that their implementations differ materially from claimed inventions, defendants build strong non-infringement positions.11

We see defendants particularly benefiting from comprehensive source code analysis when:

• Their implementation achieves similar results through fundamentally different technical approaches
• Version control history demonstrates independent development predating the patent
• Third-party open-source components provide alternative explanations for functionality
• Implementation details reveal design choices that fall outside properly construed claim scope1213

Confidentiality and Protective Measures

UK Confidentiality Clubs

In UK patent litigation, source code and other highly confidential commercial information is typically protected through "confidentiality clubs" or "confidentiality rings"—arrangements that restrict access to designated individuals under strict confidentiality obligations.1415

The Patents Court and IPEC routinely establish confidentiality clubs under the court's inherent jurisdiction and CPR Part 31, balancing the need for disclosure against legitimate confidentiality concerns. The leading authority, Warner-Lambert Co LLC v Generics (UK) Ltd 2015 EWHC 2548 (Pat), confirmed that courts will restrict access to confidential information where disclosure to wider parties would cause disproportionate harm.1617

Standard confidentiality club tiers typically include:

Tier	Access Permitted	Typical Members
Outer ring	Non-confidential case materials	All legal team members, client personnel
Inner ring	Confidential materials	External legal advisers, named experts
Source code ring	Source code and highly sensitive technical information	Named experts only, sometimes specific external lawyers

The court retains discretion to adjust these arrangements based on the circumstances of each case, and parties frequently negotiate bespoke confidentiality club structures before formal court orders are required.18

Protective Arrangements for Source Code

Source code disclosure typically involves additional protections beyond standard confidentiality clubs:

Physical access controls: Source code may be made available only at designated locations—typically the producing party's premises or a neutral facility—with restrictions on copying, printing, and electronic transmission.19

Technical safeguards: Stand-alone computers without network connections, disabled USB ports, screen recording prevention software, and secure rooms with restricted entry.20

Personnel restrictions: Named individuals only, often limited to external experts and specific counsel, with in-house lawyers and commercial personnel typically excluded from source code access.21

Documentation controls: Restrictions on the volume of code that can be printed, requirements for redaction of extracts used in court documents, and protocols for handling code in open court proceedings.22

In our experience, negotiating proportionate access arrangements early in litigation prevents later disputes about examination conditions and ensures technical experts can conduct thorough analysis within agreed parameters.

US Protective Order Comparison

US patent litigation handles source code confidentiality through protective orders under Federal Rule of Civil Procedure 26, typically with "Attorneys' Eyes Only" (AEO) designations for highly sensitive materials. Unlike UK confidentiality clubs, US protective orders are formal court orders with contempt sanctions for violations.2324

The Northern District of California's Model Protective Order provides a widely adopted framework for source code materials, establishing detailed protocols for secure review environments, permitted attendees, and documentation restrictions.25 Similar local rules exist in other major patent venues including the Eastern District of Texas and District of Delaware.26

Key jurisdictional differences:

Aspect	UK Approach	US Approach
Legal basis	Court's inherent jurisdiction, CPR Part 31	FRCP Rule 26 protective orders
Enforcement	Contempt of court, professional sanctions	Contempt of court, monetary sanctions
Structure	Confidentiality clubs with tiered access	AEO designations with court oversight
Flexibility	Negotiated arrangements, court oversight	Formal court orders, standardised models

What Technical Experts Analyse

Algorithms and Computational Logic

Technical experts examine how software implements specific algorithms described in patent claims, analysing the mathematical and logical operations that define accused functionality.27

Analysis typically includes:

• Control flow examination: How the software processes inputs through conditional logic, loops, and branching structures
• Data transformation: How information is modified, calculated, or converted between formats
• Optimisation techniques: Specific computational approaches claimed in the patent
• Integration patterns: How algorithmic components interact with broader system functionality2829

For patent eligibility and infringement purposes, experts must evaluate whether analysed algorithms serve claimed functions through the specific technical approaches identified in patent claims—not merely whether they achieve similar end results.30

Data Structures and Organisation

Source code analysis includes detailed examination of how software organises, stores, and manipulates data through specific structural arrangements.31

Key areas of examination:

• Memory organisation: How data is allocated, accessed, and managed in memory
• Storage schemas: Database structures, file formats, and serialisation approaches
• Access patterns: Indexing methods, caching strategies, and retrieval optimisations
• Relationship modelling: How data entities relate to each other within the system32

We observe that data structure analysis frequently reveals implementation details invisible to end users but critical for establishing infringement or non-infringement positions.

Function and Method Implementations

Technical experts conduct detailed analysis of specific function implementations, examining how software modules perform claimed operations and interact with other system components.33

Analysis scope includes:

• Input/output behaviour: What parameters functions accept and what results they return
• Internal logic: How functions process data between input and output
• Side effects: State changes, external system interactions, and resource utilisation
• Error handling: How exceptional conditions are managed34

This analysis extends beyond individual functions to encompass broader software architecture, including component integration, build processes, and version-specific implementations across different software releases.

System Architecture and Integration

Comprehensive source code review includes analysis of overall software system architecture, examining how different components interact, communicate, and share data.35

Architectural analysis covers:

• Component boundaries: How the system is divided into modules and services
• Communication protocols: How components exchange information
• Dependency structures: Which components rely on others
• Deployment configurations: How software is organised for execution36

In cases involving distributed systems, client-server architectures, and complex software ecosystems, architectural analysis proves especially important for understanding whether accused implementations fall within patent claim scope.

Mapping Code to Patent Claims

Element-by-Element Analysis

Patent infringement analysis requires systematic element-by-element comparison between patent claims and accused software implementations. This methodology, established in UK law and required under the structured approach to claim construction, ensures that each limitation is individually assessed rather than evaluating the invention holistically.3738

Claim charts break down patent claims into individual elements and map each limitation against corresponding features in source code, creating systematic technical comparisons. Each claim element receives separate analysis with specific code citations demonstrating presence or absence of claimed features.39

Example claim chart structure:

Claim Element	Claim Language	Source Code Implementation	Technical Analysis
1a	"A method comprising receiving user input..."	/src/input/handler.cpp lines 45-78	Handler class processes input events via...
1b	"processing the input using algorithm X..."	/src/processing/algo.cpp lines 112-156	Algorithm implements X through...
1c	"outputting a result to a display..."	/src/output/renderer.cpp lines 23-67	Renderer class generates display output...

Literal vs Equivalent Implementation

Technical experts evaluate whether accused software literally implements claimed patent elements or whether infringement exists under the doctrine of equivalents through substantial similarity in result, way, and means.40

Following Actavis UK Ltd v Eli Lilly & Co, UK courts apply a structured approach asking:

1. Does the variant achieve substantially the same result in substantially the same way?
2. Would this have been obvious to the person skilled in the art?
3. Would the skilled reader have understood strict literal compliance was intended?4142

The analysis must address each claim element individually, documenting reasoning for each element separately rather than evaluating equivalence for the invention as a whole.

Documentation and Evidence Standards

Effective claim mapping requires comprehensive documentation linking specific source code implementations to patent claim language through detailed technical analysis.43

Documentation requirements include:

• Precise code citations with file paths, line numbers, and version identifiers
• Clear explanation of how identified code corresponds to claim language
• Technical reasoning supporting infringement or non-infringement conclusions
• Visual aids (flowcharts, diagrams) translating code logic for non-technical audiences44

In our experience, thorough documentation at the analysis stage significantly improves the quality of expert reports and reduces the risk of successful challenges to expert methodology at trial.

Process and Methodology

Review Setup and Planning

Source code review setup requires careful planning and coordination between legal counsel, technical experts, and litigation support services. Key considerations include:45

Scope definition:

• Which accused products and versions require analysis
• Which patent claims are asserted
• What functionality is alleged to infringe
• What source code repositories are relevant

Access arrangements:

• Confidentiality club membership and restrictions
• Physical or virtual access protocols
• Duration of access periods
• Documentation permissions46

Timeline coordination:

• Expert report deadlines
• Reply report requirements
• Trial preparation needs
• Interim applications or hearings47

We recommend identifying pertinent code sections and negotiating access to specific versions relevant to infringement claims rather than requesting entire development repositories—focused access typically enables more efficient analysis while reducing confidentiality concerns.

Analysis Methodology

Technical experts employ systematic methodologies combining multiple analytical approaches for comprehensive source code examination:48

Phase 1: Orientation

• Review patent claims and relevant prosecution history
• Understand accused product functionality from available documentation
• Identify likely code locations based on system architecture
• Plan analysis approach based on claim structure

Phase 2: Detailed Analysis

• Examine identified code sections against claim elements
• Trace data and control flow through relevant functions
• Document specific implementations corresponding to claim language
• Identify alternative implementations or design choices

Phase 3: Synthesis

• Compile findings into claim chart format
• Prepare supporting technical explanations
• Identify areas requiring additional investigation
• Draft conclusions with supporting reasoning49

Tools and Techniques

Modern source code analysis employs various tools and techniques:

Static analysis: Examining source code directly without execution to understand structure, dependencies, and logic flow. Includes code browsing, dependency mapping, and pattern searching.50

Dynamic analysis: Observing runtime behaviour through debugging, profiling, and instrumentation to understand actual execution paths and data handling.51

Comparison tools: Specialised software for detecting similarities between codebases, identifying copied code, and mapping source to compiled binaries.52

Documentation tools: Systems for capturing analysis, generating claim charts, and producing technical reports with proper code citations.53

What NOT to Do: Critical Mistakes in Source Code Review

We've seen these common errors undermine otherwise strong technical positions:

1. Analysing Without Understanding Claim Construction

The mistake: Diving into source code analysis before properly understanding how patent claims have been or should be construed.

Why it fails: Source code analysis must map to properly construed claim scope. Analysis based on incorrect claim interpretation wastes time and produces evidence that may be irrelevant or inadmissible.

Better approach: Ensure claim construction is settled or at least provisionally agreed before substantive code analysis begins. Work closely with legal counsel to understand claim scope.54

2. Relying on Superficial Code Matches

The mistake: Identifying code sections that use similar terminology to claim language without analysing whether they perform the claimed functions.

Why it fails: Variable names, function names, and comments may use similar vocabulary to patent claims without actually implementing claimed functionality. Courts and opposing experts quickly identify such superficial analysis.

Better approach: Trace actual data flow and execution logic to demonstrate functional correspondence, not merely textual similarity.55

3. Ignoring Version Control History

The mistake: Analysing only current source code without examining development history.

Why it fails: Version control history can reveal when functionality was implemented (relevant to damages periods), whether code was independently developed or copied, and how implementations evolved over time.

Better approach: Request access to relevant version control history and examine commit records, branch structures, and development timelines.56

4. Producing Analysis That Cannot Be Verified

The mistake: Providing conclusions without sufficient supporting detail for opposing experts to verify the analysis.

Why it fails: Expert analysis that cannot be independently verified is vulnerable to challenge. Courts expect technical opinions to be grounded in identifiable, verifiable evidence.

Better approach: Document analysis methodology, specific code citations, and reasoning chains so that another qualified expert could reproduce the analysis.57

5. Conflating Technical and Legal Conclusions

The mistake: Technical experts expressing legal opinions on infringement or validity rather than providing technical analysis supporting legal conclusions.

Why it fails: Technical experts provide evidence and technical opinions; legal conclusions are for the court. Experts who overreach into legal territory undermine their credibility and may have testimony excluded.

Better approach: Clearly distinguish technical findings ("the code implements X") from ultimate legal questions ("therefore the patent is infringed").58

Deliverables and Expert Reports

Technical Analysis Reports

Technical expert reports in source code analysis cases must provide detailed technical foundations for legal arguments. Under CPR Part 35 and the accompanying Practice Direction, expert reports must:59

• Give details of the expert's qualifications and experience
• Set out the substance of all material instructions
• State the facts or assumptions upon which opinions are based
• Distinguish clearly between facts and opinions
• Identify any matters outside the expert's expertise
• Indicate any opinion that is provisional
• Include a declaration that the expert understands their duty to the court60

Report structure typically includes:

1. Introduction and instructions
2. Expert qualifications and experience
3. Technical background
4. Methodology description
5. Claim-by-claim analysis with code citations
6. Technical conclusions
7. Declaration and statement of truth61

Claim Charts with Code Citations

Detailed claim charts represent core deliverables in software patent litigation. Effective claim charts:62

• Present limitation-by-limitation analysis
• Include precise code citations (file, line numbers, version)
• Provide clear technical explanations accessible to non-experts
• Support conclusions with traceable evidence
• Address each asserted claim and each accused product/version63

Expert Declarations and Witness Statements

In UK proceedings, expert evidence is provided through written reports and oral testimony at trial. Experts may also provide:

• Preliminary opinions for interlocutory applications
• Responsive reports addressing opposing expert positions
• Supplementary analysis as additional materials become available
• Oral evidence subject to cross-examination64

In US proceedings, expert declarations often accompany summary judgment motions, Markman hearings, and other procedural stages, with requirements varying by jurisdiction and case posture.65

Costs and Practical Realities

UK Costs for Source Code Review

Technical expert fees:

Scope	Typical Cost Range	Timeline
Preliminary assessment (1-2 claims, limited code)	£8,000–£15,000	2–4 weeks
Standard analysis (3-5 claims, focused codebase)	£20,000–£40,000	4–8 weeks
Comprehensive review (multiple claims, extensive code)	£50,000–£100,000+	8–16 weeks
Complex multi-product analysis	£100,000–£200,000+	16–24 weeks

Factors affecting costs:

• Volume of source code requiring analysis
• Number of claims and accused products
• Complexity of technology involved
• Availability and format of source code
• Confidentiality club restrictions affecting access
• Expert report requirements and deadlines66

IPEC Cost Considerations

For disputes suitable for the Intellectual Property Enterprise Court, total costs are capped:

• Liability phase: £60,000 maximum recoverable costs
• Damages inquiry: £30,000 additional maximum
• Total exposure: £90,000 maximum adverse costs

These caps make IPEC attractive for lower-value disputes but may constrain available budget for technical analysis. Parties must balance analytical depth against overall litigation economics.67

US Cost Comparison

US patent litigation typically involves higher technical expert costs:

Scope	Typical Cost Range (USD)
Preliminary infringement analysis	$25,000–$50,000
Full infringement report	$75,000–$150,000
Comprehensive analysis (multiple products/claims)	$200,000–$500,000+
Trial testimony and support	$50,000–$100,000 additional

Total patent litigation costs (including all experts, not just technical) range from $500,000 for smaller cases to $3-5 million+ for high-stakes disputes, according to AIPLA survey data.6869

Timeline Considerations

UK timeline factors:

• Pre-action protocol requirements (typically 28 days minimum)
• Disclosure periods and confidentiality club establishment
• Expert report exchange deadlines (set by court)
• Trial windows (typically 12-18 months from issue in Patents Court)

Practical timeline:

Stage	Typical Duration
Confidentiality club establishment	4–8 weeks
Source code access arrangement	2–6 weeks
Primary analysis	6–12 weeks
Report drafting	4–6 weeks
Response to opposing report	3–4 weeks

Planning for adequate analysis time is essential—rushed technical analysis produces weaker evidence and may require costly remedial work.70

Strategic Considerations

Early Technical Assessment

We strongly recommend preliminary technical assessment before substantive litigation investment. Early analysis can:

• Confirm whether infringement claims have technical merit
• Identify potential non-infringement defences
• Inform case strategy and settlement positioning
• Guide discovery priorities and confidentiality negotiations71

The cost of preliminary assessment (£8,000–£15,000) is modest compared to full litigation costs and can prevent wasteful expenditure on cases lacking technical foundation.

Coordinating Technical and Legal Strategy

Effective source code review requires close coordination between technical experts and legal counsel:

Legal counsel responsibility:

• Providing proper claim construction guidance
• Identifying relevant claims and accused products
• Managing confidentiality club arrangements
• Integrating technical findings into legal arguments

Technical expert responsibility:

• Conducting thorough, methodical analysis
• Documenting findings with proper citations
• Explaining technical concepts accessibly
• Maintaining independence and objectivity72

Preparing for Cross-Examination

Technical experts must be prepared to defend their analysis under cross-examination. This requires:

• Thorough documentation of methodology and reasoning
• Ability to explain technical concepts to non-expert judges
• Familiarity with opposing expert positions
• Clear distinction between technical opinions and legal conclusions
• Honesty about limitations and uncertainties73

In our experience, experts who acknowledge appropriate limits to their analysis and demonstrate intellectual honesty fare better under cross-examination than those who overstate their conclusions.

UK vs US: Key Procedural Differences

Aspect	UK Approach	US Approach
Expert duty	Primary duty to court (CPR 35.3)	Retained by party, Daubert requirements
Report format	CPR Part 35 requirements	FRCP Rule 26 requirements
Confidentiality	Confidentiality clubs	Protective orders with AEO designations
Discovery scope	Proportionate disclosure (CPR 31)	Broad discovery (FRCP 26)
Cost recovery	Loser pays (with caps in IPEC)	Each side bears own costs (generally)
Technical judges	Patents Court judges have technical training	District judges typically non-technical

Understanding these differences is essential for multi-jurisdictional disputes and for parties accustomed to one system engaging in the other.74

Conclusion

Source code review is fundamental to modern software patent litigation. Whether you are enforcing patent rights or defending against infringement claims, thorough technical analysis of source code can determine case outcomes at critical procedural stages.

Key Takeaways

When source code review is essential:

• Server-side functionality invisible to external testing
• Algorithmic implementations where the method matters, not just results
• Background processes and low-level operations
• Any dispute where claim scope covers implementation details

Critical success factors:

• Early engagement with qualified technical experts
• Proper confidentiality arrangements protecting sensitive code
• Clear coordination between legal and technical teams
• Systematic element-by-element analysis methodology
• Thorough documentation supporting expert conclusions

Common mistakes to avoid:

• Analysing code before understanding claim construction
• Relying on superficial textual matches rather than functional analysis
• Ignoring version control history and development context
• Producing analysis that cannot be independently verified
• Conflating technical findings with legal conclusions

Cost-benefit reality:

• Preliminary assessment (£8,000–£15,000) can prevent wasteful litigation
• Full analysis costs must be proportionate to dispute value
• IPEC cost caps (£60,000 + £30,000) constrain UK litigation budgets
• Early, focused analysis is more cost-effective than broad late-stage review

In our experience, successful source code review combines technical rigour with practical awareness of litigation constraints. The best analysis is thorough, well-documented, and clearly connected to properly construed patent claims. Rushed or superficial analysis creates vulnerabilities that opposing experts and counsel will exploit.

If you're involved in patent litigation requiring source code analysis, we can help. Our technical analysis services support your legal team with systematic claim mapping, detailed code examination, and expert report preparation. We work alongside your solicitors and patent attorneys—providing the technical foundation they need while they handle legal strategy.

This article is for informational purposes only and does not constitute legal advice. Consult qualified legal counsel before taking any action in patent litigation.

Contact us to discuss how technical source code analysis can support your litigation strategy.

---

Sources

[1] UK Intellectual Property Office. "Patents Court and IPEC statistics 2023/24." Available at: https://www.gov.uk/government/statistics/intellectual-property-office-facts-and-figures

[2] Lex Machina. "Patent Litigation Report 2024: Software-related patents comprise 60-70% of district court filings." Available at: https://lexmachina.com/patent-litigation-report/

[3] Analysis Group. "Coding Analytics & Digital Forensics: Server-side functionality analysis in patent disputes." Available at: https://www.analysisgroup.com/practices/intellectual-property/

[4] Software Analysis Inc. "Technical expert examination of background processes and invisible functionality." Available at: https://www.softwareanalysis.com/services/

[5] IEEE Software. "Low-level implementation analysis in intellectual property disputes." DOI: 10.1109/MS.2023.

[6] World Intellectual Property Organization. "Guide to Patent Litigation: Algorithmic and software patent analysis." Available at: https://www.wipo.int/patents/en/

[7] Patents Act 1977, Section 60: "Meaning of infringement." Available at: https://www.legislation.gov.uk/ukpga/1977/37/section/60

[8] UK IPO. "Manual of Patent Practice - Section 60: Infringement." Available at: https://www.gov.uk/guidance/manual-of-patent-practice-mopp/section-60-meaning-of-infringement

[9] Actavis UK Ltd v Eli Lilly & Co 2017 UKSC 48. Available at: https://www.supremecourt.uk/cases/uksc-2016-0002.html

[10] Bristows. "Actavis v Lilly: UK Supreme Court rewrites the law on patent infringement." Available at: https://www.bristows.com/news/actavis-v-lilly/

[11] UnitedLex. "Source Code Review: Finding contradictory evidence that disproves infringement claims." Available at: https://www.unitedlex.com/solutions/source-code-review/

[12] DisputeSoft. "Patent Litigation: Using source code to demonstrate non-infringement." Available at: https://www.disputesoft.com/services/patent-litigation/

[13] Software Litigation Consulting. "Defensive source code analysis in patent disputes." Available at: https://www.softwarelitigation.com/services/

[14] Civil Procedure Rules, Part 31: "Disclosure and Inspection of Documents." Available at: https://www.justice.gov.uk/courts/procedure-rules/civil/rules/part31

[15] Bird & Bird. "Confidentiality clubs in UK patent litigation." Available at: https://www.twobirds.com/en/insights/

[16] Warner-Lambert Co LLC v Generics (UK) Ltd 2015 EWHC 2548 (Pat). Available at: https://www.bailii.org/ew/cases/EWHC/Patents/2015/2548.html

[17] Pinsent Masons. "Managing confidential information in patent proceedings." Available at: https://www.pinsentmasons.com/out-law/guides/

[18] Patents Court Guide. "Confidentiality arrangements and disclosure." Available at: https://www.gov.uk/government/publications/patents-court-guide

[19] Herbert Smith Freehills. "Source code inspection protocols in IP litigation." Available at: https://www.herbertsmithfreehills.com/insights/

[20] UK IPO. "Guidance on handling confidential materials in IP proceedings." Available at: https://www.gov.uk/government/publications/

[21] Taylor Wessing. "Confidentiality clubs: Who gets access to what?" Available at: https://www.taylorwessing.com/insights/

[22] Hogan Lovells. "Practical guidance on source code disclosure and protection." Available at: https://www.hoganlovells.com/publications/

[23] Federal Rules of Civil Procedure, Rule 26: "Duty to Disclose; General Provisions Governing Discovery." Available at: https://www.law.cornell.edu/rules/frcp/rule_26

[24] U.S. District Court, Northern District of California. "Model Protective Order for Litigation Involving Patents, Highly Sensitive Confidential Information and/or Trade Secrets." Available at: https://www.cand.uscourts.gov/forms/

[25] Nixon Peabody. "Managing source code discovery in patent and high-tech intellectual property litigation." Available at: https://www.nixonpeabody.com/insights/

[26] Patent Local Rules, Eastern District of Texas and District of Delaware.

[27] River Sonic Solutions. "Expert witnessing in Algorithm and Software Patent cases." Available at: https://www.riversonic.com/expert-witness/

[28] GeekExtreme. "What Is A Source Code Expert Witness? Key Roles Explained." Available at: https://www.geekextreme.com/source-code-expert-witness/

[29] IOTA Analytics. "Source Code Analysis methodology in patent disputes." Available at: https://www.iotaanalytics.com/source-code-analysis/

[30] Alice Corp. v. CLS Bank International, 573 U.S. 208 (2014) - Patent eligibility analysis for software claims.

[31] Analysis Group. "Data structure analysis in software patent litigation."

[32] Software Litigation Consulting. "Examining data organisation and storage implementations."

[33] DisputeSoft. "Function and method analysis for patent claim mapping."

[34] IEEE/ISO/IEC 42010-2022. "International Standard for Software Architecture Description." Available at: https://www.iso.org/standard/74393.html

[35] IOTA Analytics. "System architecture analysis in source code review."

[36] Software Litigation Consulting. "Services: Source code examination and software reverse engineering."

[37] Kirin-Amgen Inc v Hoechst Marion Roussel Ltd 2004 UKHL 46 - Purposive claim construction in UK patent law.

[38] Patents Court Guide. "Claim construction and infringement analysis."

[39] Software Litigation Consulting. "Claim Charts Book Part I: Element-by-element analysis."

[40] Cornell Law School. "Doctrine of equivalents in patent law." Available at: https://www.law.cornell.edu/wex/doctrine_of_equivalents

[41] Actavis UK Ltd v Eli Lilly & Co 2017 UKSC 48 - Three-question equivalents test.

[42] UK IPO. "Manual of Patent Practice - Actavis equivalents analysis."

[43] IIPRD. "Claim Chart documentation standards." Available at: https://www.iiprd.com/claim-chart/

[44] Patented.ai. "Source code documentation for patent litigation."

[45] Eurekasoft. "5 best practices for expert source code review in a patent case." Available at: https://www.eurekasoft.com/best-practices/

[46] Lumenci. "From Source Code to Courtroom: Best Practices for Software Patent Litigation." Available at: https://www.lumenci.com/source-code-review/

[47] Patents Court Guide. "Case management and expert evidence timetables."

[48] IOTA Analytics. "Systematic methodology for source code examination."

[49] DisputeSoft. "Patent Litigation: Infringement and invalidity analysis methodology."

[50] Barr Group. "Software Code Comparison Tools." Available at: https://barrgroup.com/embedded-systems/how-to/source-code-comparison/

[51] IEEE Software. "Static and dynamic analysis techniques for software examination."

[52] Software Litigation Consulting. "CodeMatch, BitMatch, and SourceDetective tools."

[53] Analysis Group. "Documentation systems for patent litigation support."

[54] Markman v. Westview Instruments, Inc., 517 U.S. 370 (1996) - Claim construction as matter of law.

[55] Software Litigation Consulting. "Avoiding superficial analysis errors in claim mapping."

[56] UnitedLex. "Version control analysis in source code review."

[57] CPR Part 35 and Practice Direction 35: Expert evidence requirements.

[58] Civil Evidence Act 1972, Section 3: Admissibility of expert opinion.

[59] Civil Procedure Rules, Part 35: "Experts and Assessors." Available at: https://www.justice.gov.uk/courts/procedure-rules/civil/rules/part35

[60] Practice Direction 35: "Experts and Assessors." Available at: https://www.justice.gov.uk/courts/procedure-rules/civil/rules/part35/pd_part35

[61] UK IPO. "Expert evidence in patent proceedings."

[62] Software Litigation Consulting. "Claim chart preparation and presentation."

[63] IIPRD. "Effective claim chart construction."

[64] Patents Court Guide. "Expert evidence and trial procedure."

[65] Federal Rules of Civil Procedure, Rule 26(a)(2): Expert disclosures.

[66] American Intellectual Property Law Association. "AIPLA Report of the Economic Survey 2023 - Expert witness costs." Available at: https://www.aipla.org/detail/journal-issue/economic-survey

[67] Intellectual Property Enterprise Court. "Costs caps and scale costs." Available at: https://www.gov.uk/courts-tribunals/intellectual-property-enterprise-court

[68] AIPLA. "2023 Report of the Economic Survey - Patent Litigation Costs."

[69] Lex Machina. "Patent litigation cost analysis 2024."

[70] UK Ministry of Justice. "Court timetables and case management guidance."

[71] DisputeSoft. "Early case assessment for patent litigation."

[72] Bristows. "Coordinating technical and legal teams in patent disputes."

[73] The Academy of Experts. "Preparing for cross-examination." Available at: https://www.academyofexperts.org/

[74] WIPO. "An International Guide to Patent Case Management for Judges - UK and US comparison." Available at: https://www.wipo.int/patent-judicial-guide/en/

Additional Authority Sources:

[75] Patents Act 1977. Available at: https://www.legislation.gov.uk/ukpga/1977/37/contents

[76] Eli Lilly & Co v Human Genome Sciences Inc 2011 UKSC 51 - Patent validity and sufficiency.

[77] Generics (UK) Ltd v Warner-Lambert Co LLC 2018 UKSC 56 - Patent infringement analysis.

[78] Unwired Planet International Ltd v Huawei Technologies Co Ltd 2020 UKSC 37 - Technology patent disputes.

[79] UK Government. "Intellectual Property Enterprise Court Guide." Available at: https://www.gov.uk/government/publications/intellectual-property-enterprise-court-guide

[80] The Sedona Conference. "Best Practices for ESI Discovery in Patent Litigation."

[81] European Patent Convention, Article 69: "Extent of protection."

[82] Protocol on the Interpretation of Article 69 EPC.

[83] Marks & Clerk. "Software patents in the UK - current landscape."

[84] UK IPO. "Patent examination guidance on computer-implemented inventions."

[85] Federal Rules of Evidence, Rule 702: "Testimony by Expert Witnesses."