In the vast, echoing chambers of the European Patent Office, where the air itself seemed composed of regulations and the light filtered through panes etched with the weary history of countless applications, there existed a problem. It was a problem that gnawed at the edges of computational progress, a persistent inefficiency that troubled the abstract entity known only as the inventor. The inventor, not a man with a face or hands, but a confluence of thought, a persistent spark housed within the sprawling corporate structure, perceived this problem as a fundamental flaw in the very fabric of distributed machine learning. It was the cumbersome, often debilitating process of training artificial minds when the task was shared among many. The existing methods, cataloged with a dry, almost dismissive tone in the application’s introductory paragraphs, were burdened by inherent weaknesses. There was the method that relied upon a central, monolithic “parameter server.” This server, a digital heart meant to collect and combine the fragmented learnings of numerous computational nodes, suffered from “a relatively high performance requirement… and is prone to cause a shutdown.” The inventor envisioned this server straining under an unbearable load, a single point of failure threatening the entire edifice of training. Then there was the alternative, a method where parameters were passed from one node to another, a sequential aggregation. This approach, while avoiding the single server bottleneck, demanded “more data to be stored and a large data transmission volume.” The inventor saw this as a different kind of burden, a digital bloat, a clogging of the network’s vital pathways with redundant information. This duality of inefficiency – the risk of central collapse or the certainty of distributed excess – was the problem, the vexing knot that the inventor sought to untangle with the submission of a meticulously drafted patent application.
The solution, as articulated in the formal language of the application, was a method, a process, a series of steps designed to navigate the complexities of distributed learning with greater grace and resilience. It was titled, with a certain bureaucratic grandeur, “MODEL PARAMETER FUSION METHOD AND APPARATUS.” This method was not a physical object, but an instruction set, a blueprint for interaction within a “machine learning system.” This system, as envisioned in the application’s claims and elaborated upon in its sprawling description, was composed of abstract or concrete “nodes,” organized into “at least one parameter collection group and at least one parameter delivery group.” Each collection group, in a gesture of organizational symmetry, corresponded to at least one delivery group. The nodes themselves, the individual computational units, were the laborers in this digital vineyard, each training a model on a local portion of the vast, labeled dataset. The essence of the inventor’s proposed method lay in a conditional, localized approach to combining the “model parameters” generated by these nodes. The critical moment arrived “when any parameter collection group meets an intra-group combination condition.” This condition, a trigger embedded within the system’s logic, signaled that a sufficient number of nodes within a particular collection group – specifically, ‘M’ nodes, where ‘M’ was bound by a minimum threshold ‘s’ and the total number of nodes in the group – had completed their current training cycle. At this juncture, the parameters from these ‘M’ nodes were to be “combined,” a process left mathematically abstract in the claims but hinted at in the description as potentially involving a separate device or one or more nodes within the group. The result of this combination was a “first model parameter,” a localized distillation of the group’s collective learning. This “first model parameter” was then dispatched, sent forth with purpose, to ‘N’ nodes within a corresponding parameter delivery group. The description spoke of further complexities, of “inter-group combination conditions,” leading to “second” and “third” model parameters, and even a process of “regrouping,” a dynamic reassignment of nodes to different collection and delivery groups based on a “preset condition,” perhaps time elapsed or some other internal metric. The inventor’s hope, a silent aspiration woven into the technical narrative, was that this intricate dance of conditional combination and targeted delivery would “resolve a problem that model parameter combination has a high performance requirement for a parameter server, and a large data transmission volume, and a dynamic calculation resource adjustment is resolved.” It was a vision of a more fluid, less burdened system, a system capable of adapting to the inherent uncertainties of distributed computation.
The application, a fragile vessel carrying the inventor’s hopes, embarked upon its journey through the labyrinthine corridors of the European Patent Office. It passed through various departments, each adding a stamp, a date, a reference number, until it finally arrived before an Examining Division. This division, a specialized unit within the Office’s vast structure, was tasked with assessing the application’s compliance with the arcane requirements of the European Patent Convention, particularly the elusive concept of inventive step as defined by Article 56. The Examining Division, after a period of silent contemplation within its bureaucratic cell, issued its decision. It was a refusal, a formal rejection that landed upon the inventor like a heavy, unexpected weight. The reasoning, articulated with the cold, impersonal logic characteristic of the Office, was based on a dissection of claim 1, the primary claim defining the scope of the invention. The Examining Division considered that the only features of claim 1 possessing a truly technical character were the presence of “a calculation server and a machine learning system,” entities they deemed “known for instance from D1,” a prior art document. The core of the inventor’s method, the intricate dance of parameter combination and distribution, was dismissed as being, in itself, “a non-technical, abstract mathematical method for ‘adapting parameters of an abstract model, using abstract parameter groups exchanged between abstract nodes of the model’.” They invoked the established principle, citing “T 49/99,” that “information modelling was not a technical activity.” Furthermore, they found it was “not derivable from claim 1 that any technical effect is achieved by this method,” specifically rejecting the appellant’s assertion that it achieved the technical effect of “alleviating a requirement of high performance on a parameter server while reducing the amount of data transmission also.” Since the method, in their view, did “not solve a technical problem,” its implementation on a known system like that described in D1 was considered “obvious,” thus concluding that “claim 1 lacked an inventive step, Article 56 EPC.” The door to patent protection, at least as guarded by the Examining Division, was firmly shut, the inventor’s creation deemed a mere abstract concept, unworthy of the Office’s tangible protection.
But the inventor, or rather, the persistent spark of ingenuity, refused to accept this judgment. The bureaucratic process, though daunting, allowed for an appeal. Through the formal channels, a statement of grounds of appeal was submitted, a counter-narrative challenging the Examining Division’s decision. The appellant, speaking on behalf of the inventor, argued vehemently against the characterization of the invention as purely abstract. The invention, they contended, “does not relate to modelling per se, but rather [to] a method for structuring and operating a model parameter combination apparatus involving the conception and implementation of a complex system that unquestionably includes features of a technical character.” They insisted that the claimed method yielded a tangible, “advantageous technical effect of reducing the amount of processing and data transmission required with respect to the cited prior art.” This effect, they asserted, was undeniably technical, citing a more recent decision, “G 1/19,” which they argued had “superseded and replaced” the earlier precedent relied upon by the Examining Division. They pointed to the specific mechanisms of the method – the “intra-group (…) conditional combining of model parameters and the sending of the first model parameter to nodes in a parameter delivery group corresponding to the condition-meeting parameter collection group features” – as inherently technical, imbuing the entire method with a technical character. Since the cited prior art, D1, contained “no teaching pointing towards the claimed solution,” they maintained that “claim 1 was inventive.” Addressing the Examining Division’s skepticism regarding the derivability of the technical effects from the claim, the appellant argued that “the skilled person in the fields of machine learning and model parameter combination would […] be capable of straightforwardly working the invention based on the claim wording alone so as to solve the […] formulated objective technical problem of how to provide an improved machine learning system and method, and would experience no doubt as to credibility of [sic] substantially all embodiments encompassed by that claim wording exhibit these performance-improving effects upon which the invention is based.” During the oral proceedings, a formal hearing before the Board of Appeal, a higher tribunal within the Office, the appellant reiterated their points, emphasizing that the invention tackled a practical computational problem, aiming to improve transmission efficiency and prevent server overload through conditional local parameter combination, irrespective of whether the nodes were physical computers or software instances. They further highlighted the dynamic node selection as a means to handle faulty nodes and enhance scalability.
The Board of Appeal, a panel of technical and legal minds, sat in judgment. They reviewed the application, the Examining Division’s decision, and the appellant’s arguments. Their decision, the culmination of this stage of the bureaucratic process, was delivered with the same impersonal authority that permeated the Office. The appeal was dismissed. The Board, in their detailed “Reasons for the Decision,” systematically dismantled the appellant’s case, finding that “the subject-matter of claim 1 lacks an inventive step, Articles 52 (1) and 56 EPC.”
Their reasoning began with an assessment of claim 1 itself. They found it to be “far from reflecting the method proposed in the description.” The claim’s language, they noted, created an ambiguity regarding the relationship between the “machine learning system,” the “nodes,” and the singular “calculation server.” This ambiguity, in the Board’s interpretation, allowed the terms “machine learning system” and “nodes” to be “interpreted in the context of that claim as referring to an abstract system with abstract nodes ‘of the model’, like a neural network or a graphical model with nodes.” While acknowledging that the description used “nodes” to refer to “different ‘calculation servers’,” the Board maintained that “claim 1 does not exclude such a broad interpretation.” This interpretation was supported by the claim’s reference to multiple nodes but only one calculation server, and by the appellant’s own admission during the oral proceedings that “claim 1 encompassed a realisation of the whole method by a single computer (‘the calculation server’), the ‘nodes’ being all realised in software.” Thus, the Board concluded, “claim 1 encompasses embodiments in which a single technical entity ‘the calculation server’, which may be a conventional computer system, is used to carry out all the claimed method steps.”
Moving to the core of the method, the Board characterized the remainder of claim 1 as defining “an abstract computation method, involving abstract ‘nodes’ having ‘model parameters’ … and exchanging parameters between them under certain conditions.” They pointed out the lack of specificity, noting that “claim 1 does not even specify that the nodes perform computations.” The described operations – “combining model parameters of M nodes in the parameter collection group” and “sending… the first model parameter” – were seen as part of this abstract computation. The critical “intra-group condition” remained undefined in the claim, merely referencing a condition met by a minimum number of nodes, but the nature of this “condition” was left open.
Based on this interpretation, the Board found it was “not apparent to the board that this abstract computation method contributes to solving a technical problem by producing a technical effect within the context of claim 1.” They systematically addressed the appellant’s arguments regarding technical effects, finding them “not convincing.” The computation of “model parameters” for an abstract “machine learning system,” even if the model was complex or “improved,” was deemed to lack technical character. Effects related to “high performance requirements” of a parameter server or “large transmission volume” were found to be “not derivable from claim 1.” The Board reasoned that since “Claim 1 does not specify how the nodes are technically implemented,” no conclusions could be drawn from the claim about how the operations would affect performance or transmission volume. This lack of derivability was further compounded by claim 1’s failure to “specify under which ‘condition’ a ‘first model parameter’ is obtained … nor what the purpose of the nodes in the ‘parameter delivery group’ is.” The Board explicitly stated, “As these alleged effects are not derivable from claim 1, it can be left open whether they would qualify as technical effects following G 1/19.” Similarly, effects relating to taking into account “faulty” nodes and scalability were deemed “not derivable from claim 1,” again due to the lack of specified technical implementation and the undefined “condition” and purpose of the delivery group.
The Board’s conclusion was stark: “The board judges therefore that claim 1 encompasses a straightforward technical implementation of an abstract computation method on a conventional computer system, where the abstract computation method makes no technical contribution in the context of claim 1 and thus cannot support the presence of an inventive step within the meaning of Article 56 EPC.” Consequently, “It follows that the subject-matter of claim 1 lacks an inventive step.” The appeal was dismissed, the inventor’s creation deemed, in the final analysis, an abstract concept lacking the necessary technical grounding within the claims to be considered inventive. The Board added, as an “obiter dictum,” a passing remark, that “even if the method were interpreted more narrowly in the light of the description, it would not appear to be derivable from it that the technical effects alleged by the appellant are achieved over a technical infrastructure for distributed machine learning like the one disclosed in D1, for the reasons given in points 10.2 and 10.3 of the communication pursuant to Article 15 (1) RPBA dated 14 November 2024.”
The dismissal of the appeal, a final stamp in the lengthy dossier, offered a form of practical guidance, albeit a harsh one, for those who would dare to navigate the bureaucratic maze of the European Patent Office with inventions rooted in the abstract world of computation. The inventor, a silent observer of this process, could glean a crucial, if painful, lesson. The Office, and particularly its Boards of Appeal, demand clarity and technical specificity in the claims. It is not enough for an invention to solve a problem or have potential technical effects; these effects must be directly and unequivocally derivable from the technical features explicitly recited in the claims. The ambiguity that allowed the Board to interpret “nodes” as abstract entities, detached from concrete computational hardware, proved fatal. Future applications must ensure that the claims clearly define the technical nature of the components and their interactions. The “condition” that triggers a crucial step cannot be left as an abstract concept; its technical basis and how it contributes to a technical outcome must be spelled out within the claims. The function of different groups or components, like the “parameter delivery group,” must be described in terms of their technical role within the system. The guidance, etched into the record of the dismissed appeal, is a reminder that within the European Patent Office, the abstract must be firmly tethered to the technical. A method, however innovative in its computational logic, must demonstrate its technical character through the specific means by which it is implemented and the tangible technical effects it achieves, all clearly and unambiguously defined in the claims. Without this grounding, it risks being lost in the bureaucratic ether, deemed a mere abstract concept, and denied the protection it seeks. The path to patentability, it seems, is paved not with abstract ideas, but with clearly defined technical features and demonstrably derivable technical effects, all articulated with meticulous precision within the confines of the claims.
Practical guidance, whispered from the void:
- Define the technical contribution explicitly in the claims. Do not rely on interpretation from the description alone.
- Avoid ambiguous mappings between abstract and physical entities. If nodes are software threads, say so. If they are physical servers, say so.
- Anchor your claim language in tangible effects. Transmission volume, fault tolerance, computational efficiency—if they matter, claim them with clarity and causality.
- Specify the mechanism. Don’t merely “combine”; state how. Don’t just “send”; describe the structure, timing, and rationale.
- Beware of abstraction. The closer you dance with generality, the more likely the Office will dismiss you as a theorist of diagrams.
- When citing G 1/19, show how your method engages with the hardware, not just how it manipulates information.
- Write as if the Office doubts you. Because it does.
Based on T 0080/23 (Model parameter combination/HUAWEI).