Chapter 15: Practical Advice for the Standards Attorney

This chapter is the judgment layer — why the things you check matter, what goes wrong when you get them wrong, and how the practical mechanics of advising on a standards engagement actually play out. Much of the conceptual framework has been laid out in earlier chapters. This chapter applies it. For the operational prompt list — the lifecycle-organized checklist you can pull up before a particular engagement — see Appendix B.

15.1 Before You Engage: The Checklist

Start With Strategy

The first question in any standards engagement isn't legal. It's strategic. Why standardize at all? What does the client hope to accomplish — define a market, slow a competitor, build a coalition, signal commitment, satisfy a procurement requirement, prevent a worse outcome elsewhere? Without a clear answer, everything that follows — forum choice, IPR policy, governance posture, exclusion strategy — is guesswork.

This sounds obvious, and it gets skipped routinely. Engineers come to legal with "we want to join organization X" or "we want to start a new working group" already framed as the decision. Your first job is to push back one level and make sure there's a coherent strategic theory underneath the request. If there isn't, the engagement will drift, and the legal questions you're being asked to answer will be the wrong questions.

Forum choice and structure matter, but they are secondary. They are the implementation of the strategy. A client that wants to set a market floor needs a different forum than a client that wants to slow a competitor's lock-in. A client that wants to legitimize an existing implementation needs a different structure than one that wants to design something new collaboratively. The forum and the IPR posture should fall out of the strategic answer, not precede it. When the strategy is clear, the legal architecture often becomes obvious. When the strategy is fuzzy, no amount of legal analysis will fix it.

Reading the Governance Documents and IPR Policy

Once the strategic theory is in place, before your client joins a standards body or working group, read the governance documents and the IPR policy. All of them. Not just the patent policy — the bylaws, the membership agreement, the working group charter, the contribution guidelines, and the forms.

This sounds obvious. It's remarkable how often it doesn't happen. A client's engineer joins a working group, starts contributing, and nobody reviews the IP terms until there's a problem. By then, commitments have been made.

When reading, the questions that matter most are about triggers, scope, and exits. What triggers the patent commitment — mere participation, or only contribution? What scope does the commitment cover — just the working group, or the whole organization? What exclusion or disclosure mechanism exists, and what are its timelines? What happens on withdrawal, and what survives it? What tiers of membership exist, and which one is your client joining? What are the voting rules, and which decisions require supermajority or unanimity?

Read the forms too — as discussed in Chapter 10, declaration and disclosure forms can modify the policy terms in ways that aren't reflected in the policy document itself.

Understanding the Scope of Patent Commitments

Map your client's patent exposure before joining. That means having a view of which patents your client holds that might read on the working group's scope, how broad the scope actually is (a narrow technical area, or a broad category that could expand under pressure), whether the commitment reaches optional portions of the spec, whether it sweeps in patents acquired after the commitment is made, and whether it extends to affiliates.

This doesn't require a formal patent search — as discussed in Chapter 7, there's generally no duty to search. But you should have a conversation with your client's patent team about the technology area and whether there are known patents that might be implicated.

Mapping the Organizational Structure

Understand the organization's structure before engaging. Who governs? Who votes? Who chairs the working group? What's the relationship between the working group and the governing board? Is there an association management company involved, and what role do they play?

Understanding the structure tells you where the power is. A working group chair who controls the agenda has more practical influence than a board member who only sees the final deliverable. An association management company that controls the website and membership database has operational leverage that isn't visible in the governance documents.

Identifying Your Representatives and Managing Their Knowledge

Know who your company is sending to the working group. Understand their level of knowledge about your patent portfolio. Make sure they understand the disclosure obligations — that disclosure is mandatory based on actual personal knowledge, not optional, as discussed in Chapter 7.

Ensure your representatives have appropriate training on the legal issues that arise in standards participation — particularly around patents and antitrust. Engineers and product managers who participate in standards bodies are operating in a room full of competitors, making commitments that have IP consequences, and subject to antitrust constraints they may not be aware of. They need to understand, at minimum: what they can and cannot discuss with competitors, how patent disclosure and exclusion obligations work, what triggers a patent commitment, and when to escalate to legal. This doesn't require making them lawyers. It requires making sure they know enough to recognize when they're in territory that needs legal input.

If your company has multiple people attending different working groups within the same organization, coordinate among them. Patent commitments may be working-group-specific, but the organizational rules may create broader implications. And if your representative changes, make sure the replacement is briefed on the commitments already made and the positions already taken.

15.2 During the Engagement

Monitoring Contributions and Their IP Implications

Once your client is participating, monitor what's being contributed — both by your client and by others. Contributions by your client carry IP implications under the policy. Contributions by others shape the spec in ways that may implicate your client's patents.

If the spec evolves in an unexpected direction — toward your client's patent portfolio, into a scope area that wasn't anticipated — that's when you need to evaluate options: raise the concern in the working group, consider an exclusion, or withdraw before the commitment locks in.

Managing the Exclusion Window

If the policy provides an exclusion mechanism (as most RF policies do), understand the timeline and process. Know when the call for patents will happen or, if it's a rolling exclusion, know when the final deliverable is expected.

When the window opens, coordinate with the patent team. Review the spec against known patents. Decide what, if anything, to exclude. If you're going to exclude, follow the procedural requirements — identify the patents, identify the spec sections, and file the exclusion within the deadline. Late exclusions are generally not accepted, and missing the window means the commitment locks in.

If you decide not to exclude — which is the case in the vast majority of engagements — document that decision. If questions arise later, you want a record showing that you evaluated the spec and made a deliberate choice.

Internal Coordination Across a Large Organization

In a large company, the standards team, the patent team, the engineering team, and the business unit may all have different views on a given engagement. The engineer wants to contribute freely. The patent team wants to protect the portfolio. The business unit wants the standard to align with its product roadmap. The legal team wants manageable risk.

Your job is to be the person who sees all the dimensions. Ensure the engineer doesn't make IP commitments the patent team hasn't approved. Ensure the patent team doesn't block engagement the business unit needs. Ensure everyone understands the constraints of the standards process — that voting rules, due process, and consensus requirements may not produce the outcome any single internal stakeholder wants.

This coordination is ongoing, not a one-time event. The spec evolves. The business context changes. The patent portfolio changes. Regular check-ins — not just when there's a crisis — are what prevent surprises.

When to Raise Concerns and How

If you have a concern about the direction of the spec, the governance process, or the behavior of another participant, raise it early and raise it through the process. Standards bodies have mechanisms for addressing concerns — comment periods, objection processes, appeals. Using them is legitimate and expected.

What doesn't work is waiting until the spec is finalized and then objecting. The time to influence the direction is during development, not after publication. And the time to flag a patent concern is during the exclusion or disclosure window, not after the commitment has locked in.

15.3 Risk Management

Patent Portfolio Implications

Standards participation has patent portfolio implications that extend beyond the specific commitment. Participating in a royalty-free working group means committing necessary claims to that standard for free — permanently, in most cases. If your client has a significant patent portfolio in the relevant technology area, the cost of that commitment may be substantial.

Conversely, not participating means not having a voice in the standard that may define the market. And if the standard becomes widely adopted, your client may need to implement it regardless — but without having had the opportunity to influence the result.

The decision to participate is a business decision informed by legal analysis, not a legal decision alone. Your job is to make sure the decision-makers understand the IP implications of participating and not participating.

Successor and Assign Provisions

If your client acquires a company — or is acquired — understand how the patent commitments transfer. Most policies extend to patents "owned or controlled, now or at any time in the future," which means acquired patents get pulled into existing commitments.

In M&A due diligence, check whether the target company has made standards commitments. Those commitments will survive the acquisition and bind the acquiring company's patents. This is an area that's frequently overlooked in deal diligence and can create unexpected exposure post-close.

Withdrawal Mechanics

Understand how to withdraw and what survives. Most policies allow withdrawal from a working group, but the commitment to specifications finalized before withdrawal is permanent. Some policies have notice periods. Some have specific procedures.

If your client's business circumstances change — a shift in business model, an acquisition, a decision to monetize patents — and withdrawal becomes necessary, do it cleanly and in compliance with the policy terms. A messy withdrawal creates governance disputes and damages relationships with other participants. A clean withdrawal, done with appropriate notice and communication, preserves relationships even if the departure is unwelcome.

Aligning Participation, Approval, and Monitoring

Different companies take very different approaches to standards participation, and you should help your client decide where they fall on the spectrum — ideally before they join, not after.

Participation approval. Some companies require formal legal review before anyone joins a working group. Others let engineers join freely and loop in legal only when there's a specific question. Neither approach is wrong, but the implications differ. A formal approval process ensures patent exposure is evaluated before the commitment is made. A lightweight process gets your people into the room faster but risks commitments that haven't been vetted.

Patent review approach. At one end of the spectrum, some companies greenfield an engagement — they join, participate, and never review their patent portfolio against the emerging spec. They accept the patent commitment as a cost of participation and move on. At the other end, some companies conduct formal patent reviews at multiple stages: when the working group is chartered, when the spec reaches a stable draft, and again before finalization. Most companies fall somewhere in between.

The right approach depends on your client's patent portfolio, the technology area, and the business model. A company with few patents in the relevant area can afford to greenfield. A company with a significant portfolio that it monetizes needs more rigorous monitoring. Whatever the approach, be deliberate about it. An unintentional greenfield — where nobody reviews the patents because nobody thought to — is different from a deliberate business decision to accept the exposure.

Ongoing monitoring. Standards engagements run for years. Your client's patent portfolio will change during that time — through new filings, acquisitions, and evolving technology. A patent that didn't read on the spec in year one may read on it in year three as the spec evolves. Periodic check-ins between the standards team and the patent team — not just at disclosure windows but as part of regular engagement management — reduce the risk of surprises.

Patent Exclusions: The Nuclear Option

Exclusions were covered in detail in Chapter 8. From a practical advice perspective, the key point is this: exclusions are the nuclear option. They are highly disruptive to the working group and to your client's relationships with other participants. They should be used only when absolutely necessary.

As discussed in Chapter 8, some organizations use a formal call for patents — a specific notification at a defined stage of the specification process that triggers an exclusion window. Others use a rolling exclusion obligation where participants must track the spec's evolution and exclude before finalization, without a specific trigger. From a management perspective, calls for patents are significantly easier for companies to handle. They produce a concrete notification that can be routed to the patent team, evaluated, and responded to within a defined timeline. Rolling exclusions require your organization to independently monitor the spec's progress and self-initiate the review — which, in a large organization where the standards team and the patent team may not be in regular contact, often means it doesn't happen until someone realizes the spec is about to be finalized. When evaluating which organization to work in, the exclusion model is worth considering as a practical management factor.

When an exclusion is filed, it signals to the community that your client has a patent it intends to assert or monetize — which may be exactly what's happening, but the signal is disruptive regardless. The working group has to evaluate whether to design around the excluded claims, accept them as a cost, or renegotiate the scope. Any of these responses consumes time and political capital.

If your client genuinely needs to exclude, do it narrowly. Identify the specific claims and the specific spec sections. Work in good faith with the working group to find alternatives. And communicate early — don't wait until the deadline to drop a surprise exclusion. The process is designed to handle exclusions, but it handles them far better when the excluding party engages constructively rather than dropping a stack of patent numbers on the table at the last moment.

Patent Disclosures: Good Faith and Practical Timing

For RAND engagements, patent disclosures should be good-faith representations of patents that the owner reasonably believes are necessary claims. Disclose what you genuinely believe reads on the spec. Don't over-disclose — dumping a large volume of marginally relevant patents into the disclosure list creates noise that doesn't serve the community and can slow the development process.

At the same time, try to disclose as early as possible. Early disclosure gives other participants the information they need to make informed decisions about the technology and the licensing landscape. It demonstrates good faith. And it protects your client from later accusations of ambush.

The practical reality is that early disclosure is often difficult. Specs evolve. A patent that seems relevant in a working draft may not read on the final spec, and a patent that seems irrelevant early on may become directly on point as the spec stabilizes. This is why many disclosures happen late in the process — not because participants are gaming the system, but because it's genuinely hard to evaluate whether a patent is a necessary claim until the spec is close to final.

The best approach is a combination: disclose early when you can, but plan for a more thorough review as the spec stabilizes. Document your process. If questions arise later about the timing of a disclosure, you want to be able to show that you made a good-faith effort throughout the engagement, not just at the last minute.

15.4 Drafting Standards-Related Agreements

When to Use Off-the-Shelf Frameworks

For most engagements, use established frameworks — JDF, OASIS, the Community Specification License. The terms are proven, the IP is well-understood, and the startup time is minimal. The legal teams at other participating companies have already reviewed these frameworks, which means less friction in getting to agreement.

The temptation to customize is strong. Resist it unless there's a genuine need. Every customization requires negotiation. Every negotiation takes time. Every bespoke term creates a unique legal instrument that every participant's legal team has to evaluate from scratch. The overhead of customization almost never justifies the theoretical improvement in terms.

When Bespoke Agreements Are Necessary

Sometimes the established frameworks genuinely don't fit. The technology has unusual patent implications. The participant group has specific governance requirements. The engagement involves jurisdictions or industries where the standard frameworks haven't been tested.

In those cases, draft with the standard frameworks as your starting point. Use the same structure, the same concepts, the same terminology. Deviate only where you must. And document why you deviated, because every participant's attorney will ask.

Companies Trying to Reshape Standards to Match Internal Processes

One dynamic that practitioners should recognize: companies routinely try to get standards organizations to adopt policies that mirror their own internal processes. How and when they conduct patent reviews. How they approve participation. What level of company oversight they require over employees' standards activities. Who has authority to sign agreements.

This is natural — people advocate for what they know, and if your internal patent review takes 90 days, you'll push for a 90-day exclusion window. If your company requires VP-level sign-off on patent commitments, you'll push for formal notification procedures that give you time to route the approval.

The problem is that every company's internal processes are different. What works for a company with a large patent team and formal review processes doesn't work for a startup with no patent team at all. What works for a company with centralized decision-making doesn't work for one with distributed authority.

The standards organization's policies need to work for everyone — or at least for the range of participants the organization wants to attract. When you find yourself advocating for a policy change that would make your client's life easier, ask whether it would make the process harder for other participants. If it would, consider whether your client can adapt its internal processes to the organization's rules rather than the reverse. Standards policies should be designed for the ecosystem, not for any single participant.

The Evolution to Modern Modular Frameworks

As discussed in Chapter 11, the history of standards agreements is a progression from bespoke, heavily negotiated bilateral agreements through form consortium agreements to modular, non-negotiable frameworks (JDF, CSL). Each generation reduced the startup time and legal overhead.

If you're advising on a new engagement, the question isn't whether to use a modern framework — it's which one. And if a client or counterpart proposes going back to bespoke drafting for something that a modern framework can handle, push back. The time and money spent negotiating a bespoke agreement is time and money not spent on the technical work. Get to the substance faster.

15.5 Launching a Standard: A Practical Checklist

The role of theater in standards — signaling, perception, and why trust matters more than legal perfection — is covered in depth in Chapter 10. This section focuses on the practical mechanics of getting a spec launch right.

Review the Announcement Like a Legal Document

When advising on a spec launch, review the announcement with the same care you'd review the legal terms. Make sure the public positioning is consistent with the actual IP framework. If the announcement says "open standard" but the IP terms are RAND, someone will notice. If it says "developed collaboratively" but one company controls the governance, that tension will surface. "Open" means something specific to the communities you're addressing, and if your usage doesn't match their expectations, the gap will be exploited.

Coordinate Partner Alignment Early

Coordinating a spec launch across multiple partners — each with their own legal review, their own PR team, and their own messaging preferences — is one of the most logistically challenging aspects of standards work. It's also one of the most important.

The announcement is where the standard enters the public conversation. The partner logos signal the breadth of support. The language frames how the community will evaluate the IP terms. Get it right, and the standard launches with momentum. Get it wrong, and you spend months doing damage control.

Start the coordination early. Share draft language with partner legal teams before the announcement, not after. Give people time to flag concerns. A simple, clear message that everyone can support is better than a perfect message that takes so long to negotiate that the launch window passes.

Ensure Consistency Between Marketing and Legal

The most common launch failure isn't a bad IP framework — it's a gap between what the marketing says and what the legal terms actually provide. The marketing team wants to say "open." The legal terms say "RAND with reciprocity." The press release says "60 partners." The governance gives one company unilateral control. These inconsistencies will be found, and they will be used against you.

Before the launch, have someone — ideally the attorney who knows both the IP terms and the community — read the announcement side by side with the legal documents. Flag every claim in the announcement and verify it against the actual terms. This is a concrete, mechanical step that prevents the most common perception problems.

15.6 The Operational Layer

The reasoning in this chapter is the why. When you need the did-you-check, turn to Appendix B — Standards Engagement Checklist for Counsel. It mirrors the lifecycle of an engagement — before you join, IPR diligence, governance, the membership agreement, internal authorization, designating participants, ongoing hygiene, when things go wrong, and exiting — as a scannable prompt list you can pull up before a particular conversation. The two are designed to be used together: read this chapter once, keep the appendix at hand.