Drafting patent specifications with a global filing strategy in mind often requires navigating fundamentally different disclosure philosophies. In many originating jurisdictions outside the United States, particularly in parts of Europe and Asia, applicants are accustomed to drafting specifications that focus almost exclusively on what is new, with known features mentioned only briefly or incorporated by reference at a high level. This approach reflects a legal framework in which the invention is understood primarily through the claims, and where functional claiming is generally tolerated so long as the claims are supported by a credible technical contribution. However, when that same drafting style is imported into the U.S. system without adjustment, it can create serious and sometimes fatal vulnerabilities under 35 U.S.C. § 112.

The U.S. patent system, administered by the United States Patent and Trademark Office, places a uniquely strong emphasis on the relationship between claimed function and disclosed structure. Section 112(a) requires that the specification contain a written description of the invention and enable a person of ordinary skill in the art to make and use it, while Section 112(b) requires claims to particularly point out and distinctly claim the subject matter regarded as the invention. Layered on top of these general requirements is Section 112(f), which governs so-called means-plus-function claiming. When a claim element is expressed in functional terms without reciting sufficient structure, the claim is construed to cover only the corresponding structure, material, or acts described in the specification and equivalents thereof. If no such structure is disclosed, the claim is indefinite.

This statutory framework creates a sharp contrast with drafting practices that assume a generic “device,” “unit,” or “module” will be understood to encompass whatever conventional hardware or software is needed to perform the stated function. In the U.S., particularly after decisions such as Williamson v. Citrix Online, courts and the Office are far more willing to treat such terms as placeholders for means-plus-function limitations when they are coupled with purely functional language. Once Section 112(f) is triggered, the specification must do more than name a function or invoke a well-known result; it must disclose the structure that actually performs that function and clearly link that structure to the claim language.

This requirement is especially unforgiving in the context of software-related inventions. Examiners in Technology Center 2100 and 2600 routinely treat software elements as functional, and the case law is explicit that when a general-purpose computer is used to perform a claimed function, the corresponding structure is not the computer itself but the algorithm that the computer executes. The Federal Circuit has repeatedly held that the algorithm may be expressed in many forms—flowcharts, mathematical formulas, prose descriptions, or other logic—but it must be present in the specification. Simply stating that a processor “executes an algorithm,” or naming an algorithmic category without explaining how it operates in the claimed context, is not sufficient. The Manual of Patent Examining Procedure reflects this doctrine clearly, particularly in MPEP §§ 2181 and 2183, which tie indefiniteness and written description failures directly to missing algorithmic disclosure for computer-implemented means-plus-function limitations.

These principles are illustrated starkly in a recent decision by the Patent Trial and Appeal Board, Appeal No. 2025-002632, involving a stereo camera system for a motor vehicle. The claims recited an “evaluation device comprising at least one processing unit” configured to evaluate stereo images using a “stereo camera algorithm,” evaluate images using a “mono algorithm,” determine image depth information, and check whether depth information from different images corresponded. On its face, this is precisely the type of language that often survives comfortably in non-U.S. practice, particularly where stereo vision and depth estimation techniques are widely known in the art. Claim 1 is set forth in full below:

1. A stereo camera device for a motor vehicle, comprising:
   a first and a second mono camera, the first and second mono cameras each having at least one optical system and an image sensor for sensing images; and an evaluation device,
   wherein the image sensor of the first mono camera and the image sensor of the second mono camera are connected to the evaluation device in order to transmit image data of the sensed images;
   the evaluation device comprising at least one processing unit designed:
   to evaluate a first stereo image from the image data transmitted to the first and second mono camera, using a stereo camera algorithm;
   to evaluate a second stereo image from the image data transmitted to the first mono camera, using a mono algorithm;
   to determine image depth information from each of the first and the second stereo images; characterized in that the evaluation device is designed to check that the image depth information that has been determined from the first and the second stereo images corresponds.

The problem for the applicant, as the Board repeatedly emphasized, was that the specification did not disclose the structure necessary to perform these functions. The application did not describe a computer architecture, did not meaningfully discuss software implementation, and did not provide algorithmic details for how the stereo camera algorithm, mono algorithm, depth determination, or correspondence checking were actually carried out. Even where algorithm names were mentioned, they were invoked only at a conceptual level, without flowcharts, equations, logical steps, or other description that would demonstrate possession of the claimed functionality. The Board agreed with the Examiner that the “evaluation device” and “processing unit” were generic, non-structural terms and therefore fell within Section 112(f). Because the specification failed to disclose corresponding structure for each claimed function, the claims were held indefinite under Section 112(b), lacking written description under Section 112(a), and non-enabled.

What makes this outcome particularly instructive is that the defect was incurable at the prosecution stage. A lack of corresponding structure for a means-plus-function element is not a matter that can be fixed with attorney argument or claim interpretation; it is a disclosure failure. The only theoretical remedy would have been to amend the claims to remove the functional elements that lacked support. But those very elements were central to the asserted novelty of the invention. As the case demonstrates, once prosecution reaches this point, applicants are often forced to choose between abandoning the claims entirely or accepting affirmance of the rejection.

From a global drafting perspective, it is easy to imagine how this application came to be written as it was. In Europe, for example, an application focusing on the conceptual combination of stereo and mono image evaluation to detect system faults might well be viewed as sufficiently disclosed, especially if the algorithms themselves are considered standard and the inventive contribution lies in their comparative use. The European Patent Office generally does not impose an algorithm-level disclosure requirement analogous to U.S. means-plus-function doctrine, and functional claiming is assessed through the lens of clarity and sufficiency rather than strict structural correspondence. As a result, the same level of detail that doomed the U.S. case might not have raised serious objections abroad.

The lesson for practitioners drafting with a global audience in mind is not that one system is right and the other wrong, but that a lowest-common-denominator specification is often the safest course. Even if certain algorithms, processing techniques, or data flows are well known, the U.S. system frequently demands that those details be spelled out, particularly when they are recited as functions in the claims. This is especially true when multiple known algorithms are combined, sequenced, or cross-checked, because the inventive step may reside precisely in how those algorithms interact. Naming them is not enough; the specification should explain how they are linked, what inputs and outputs are used, and how intermediate results are generated and compared.

For software-heavy inventions, this often means resisting the instinct to streamline the specification by omitting “obvious” implementation detail. In the U.S., those details are not mere background; they are often the structural backbone that keeps functional claims alive. A few additional pages describing algorithmic steps, data structures, or processing logic can make the difference between a robust claim set and a fatal Section 112 rejection that cannot be cured after filing. The PTAB decision discussed above is a clear reminder that when drafting for the United States, functional language without disclosed structure is not merely risky—it can be dispositive.