Method and system for converting an input signal to an output signal

Abstract

The disclosure relates to a computer-implemented method for converting an input signal to an output signal, the input signal encoding a text to be translated from a first language to a second language and the output signal encoding a translation of said text to be translated, the method comprising obtaining the input signal, using a first large language model, LLM, to generate, using as input a first instruction prompt and at least a part of the input signal, a generated intermediate signal encoding a glossary of a plurality of terms in the text to be translated with corresponding translations in the second language, providing an amended intermediate signal based on the generated intermediate signal, using a second LLM to generate, using as input a second instruction prompt, the input signal and the amended intermediate signal, the output signal, wherein the second LLM is configured, through the second instruction prompt, to use the glossary in the translation of the text to be translated from the first language to the second language, and sending the output signal for storage.

Description

Method and system for converting an input signal to an output signalTechnical Field

[0001] The present disclosure relates to a computer-implemented method for converting an input signal to an output signal, the input signal encoding a text to be translated from a first language to a second language and the output signal encoding a translation of said text to be translated. The disclosure further relates to a system and a computer program product for converting the input signal to the output signal.Background

[0002] Machine translations of texts where consistency in vocabulary is essential, such as patent claims, are surprisingly hard to do well. A major problem is consistency. Most modern machine translators are based on the statistical Transformer architecture, where the model continuously chooses the next most likely word (token, in fact, but the distinction is not important for this explanation) given the words in the original language and the translated words generated so far. Usually, the machine translator uses a transformer encoder - decoder model, where the encoder processes the original text, and the decoder takes the output of the encoder and generates the next token, given the previously generated translated words.

[0003] Because the most likely word is chosen, and the chance is dependent on the actual context, this can give problems. It has been known that machine translators translate the English word "device" to the Dutch word "inrichting" or the Dutch word "apparaat." A patent application with claims 1-6 each including the English word "device" may be translated inconsistently. For example, in the first 5 claims a machine translator may translate the English word "device" to the Dutch word "inrichting", and then suddenly translate "device" to "apparaat" in claim 6. While the translation is still fairly accurate, the sudden change causes issues, because it appears that claim 6 introduces a new term (the "apparaat") different from the "inrichting" of claims 1 - 5, while in the original claims 1 - 6 reference is made to a single “device”.

[0004] Another problem that can occur, is that different words in the original language, are translated to the same word. For example, the English terms “water supply line” and “water delivery line” could both be translated to the Dutch word “watertoevoerlijn”. This would raiseserious problems in the Dutch translation of a patent description or claim, because two separate items have suddenly, in translation, become one and the same.

[0005] In general, for the above and other reasons, existing machine translators work poorly on sequences of interrelated texts such as patent (application) claims or paragraphs in a patent (application) description.Summary

[0006] The disclosure provides a computer-implemented method for converting an input signal to an output signal, where the input signal encodes a text to be translated from a first language to a second language and the output signal encodes a translation of said text. The method includes obtaining the input signal; using a first large language model (LLM) to generate, with a first instruction prompt and at least part of the input signal, a generated intermediate signal encoding a glossary of terms in the text with corresponding translations in the second language; providing an amended intermediate signal based on the generated intermediate signal; using a second LLM, with a second instruction prompt, the input signal, and the amended intermediate signal, to generate the output signal; and sending the output signal for storage. The second LLM is configured, through the second instruction prompt, to use the glossary in translating the text from the first language to the second language.

[0007] According to an embodiment, providing an amended intermediate signal based on the generated intermediate signal involves copying the generated intermediate signal to the amended intermediate signal and incorporating revisions from a user into the amended intermediate signal. This advantageously allows the user to revise only a relatively small amount of text, which yet includes the most vital elements of the translation. This is much more efficient and less error-prone than letting a user review the entire translation.

[0008] In an embodiment, the information of the generated intermediate signal and the amended intermediate signal are stored in a training database for training or finetuning the first LLM. According to an embodiment, the first LLM is trained or finetuned using the training database. This allows the first LLM to “learn” from user-made corrections to its proposed glossary, reducing the need for further corrections.

[0009] In an embodiment, the first LLM is the same as the second LLM. According to an embodiment, a subset of the input signal is used to generate the generated intermediate signal. While using different LLMs can have advantages (e.g. using a more costly, smarter,LLM to generate a glossary than the LLM that generates the translation), using the same LLM allows for an easier implementation.

[0010] In an embodiment, the output signal is generated in one or more batches, with each successive batch using as input a successive subset of the input signal and the amended intermediate signal. This advantageously allows the method to translate any amount of text, including amounts that do not fit all at once in the context size of the used LLM.

[0011] According to an embodiment, the input signal encodes patent or patent application claims. In an embodiment, the input signal encodes a patent or patent application description and claims, and a first subset of the input signal comprises the patent application claims, with the glossary generated based on the first subset of the input signal. According to an embodiment, the input signal encodes a patent or patent application description and claims, and the second LLM is used for the translation of a first subset of the input signal comprising the patent or patent application claims, while a third LLM is used for the translation of a second subset of the input signal comprising the patent or patent application description.

[0012] In an embodiment, the method further comprises using a fourth LLM to generate, with a third instruction prompt, the input signal, the amended intermediate signal, and the output signal, a checking signal encoding a report on the accuracy of the translation.

[0013] In another embodiment, the method further comprises using any number of additional LLMs to generate, with a respective prompt, the input signal, the amended intermediate signal, and the output signal, a series of post-translation edits, including but not limited to grammatical corrections, readability enhancements, etc.

[0014] According to an embodiment, the first instruction prompt includes a custom glossary selected based on the input signal.

[0015] In an embodiment, the first or second or third LLM is one of GPT, Llama-2, Gemini (formerly Bard), and Mixtral Al.

[0016] The disclosure is not limited to any specific LLM snapshot or version. As LLMs evolve, newer versions may be used to implement the described methods. Various snapshots such as claude-3-5-sonnet-20240620, gpt-4o-2024-08-06, o3-mini-2025-01-31 , gpt-4-turbo-2024-04-09, or gpt-4-0613 may be employed. The choice of LLM snapshot maydepend on factors like availability, computational requirements, language pair proficiency, or strengths in handling technical terminology. Multiple snapshots or versions may be used in combination. The LLM may also be a finetuned model, as specified elsewhere in this disclosure, tailored to specific translation tasks or domains.

[0017] The disclosure further provides a system comprising a memory and at least one processor, where the memory stores program instructions which, when executed on the processor, cause the processor to execute any of the methods described above.

[0018] According to an embodiment, the system obtains the input signal from a database server or from a document management system (DMS) server, and the output signal is stored in the DMS server.

[0019] In an embodiment, using the first LLM and the second LLM includes assembling the first and second instruction prompts, sending these prompts to a LLM server, and retrieving a first and second response from the LLM server.

[0020] The disclosure also provides a computer program product comprising instructions which, when executed on a processor, cause the processor to perform any of the methods described above.

[0021] The present disclosure is based on the realisation that general purpose LLMs, not specific translation encoder-decoder transformers, may be better at translating certain legal texts such as patent descriptions and claims. General purpose LLMs can be prompted with detailed instructions. The consistency of the translation can be particularly improved by first instructing the general purpose LLM to generate a glossary for the texts to be translated.

[0022] In the domain of text translation, LLMs like OpenAI’s GPT line of models have shown promise in providing translations that not only capture the literal meaning but also reflect the nuances and context of the source text. Unlike traditional transformer-based translation models used by commercial products like DeepL and Google Translate, which are specifically trained and optimized for translation tasks, LLMs approach translation as part of a broader range of language understanding and generation capabilities. This means that when prompted to translate text, LLMs leverage their extensive training on diverse language data to infer context, cultural nuances, and idiomatic expressions more flexibly.

[0023] The Instructions can comprise specific guidelines, for example to make sure that unique terms in the original language have a unique term in the target language (so, avoid translating both “device” and “apparatus” as “inrichting” in Dutch). Another common pitfall with translations of patent texts is that different languages tend to have different ways of building sentences.

[0024] In a second step, the same or a different LLM is then instructed to translate the texts using that glossary. Again, the instructions can be customized. The instructions can encourage the model to keep the original language sentence structure as much as possible (at the risk of making the translation read a little bit less natural) or, as the opposite, to make the translation read natural (at the risk of introducing ambiguities that are not present in the original text).

[0025] It has been found that this two-step approach yields translations with superior consistency. In addition, it has the additional benefit that the glossary generated in the first check, can be checked, corrected and augmented by a human before the translation is generated in step 2. This allows for a natural way of having a human-assisted machine translation, which plays to the strengths of both humans and LLMs. A human can effectively check a glossary for unforeseen or obscure problems, but is not well equipped to do a large translation while applying said glossary consistently. On the other hand, a large language model can make a first version of the glossary but may miss intricacies of the translation.

[0026] In an embodiment, a training database is provided for storing generated glossaries and amended glossaries, possibly also including the source text as context. Said training database can then be used to train or finetune the LLM responsible for generating the glossary to improve the generated glossaries based on human feedback. In an embodiment, Reinforcement Learning from Human Feedback (RLHF) is employed for this training or finetuning.

[0027] In an optional third step, the same or yet another LLM is then instructed to review the translation and to mark any errors in the use of the glossary. This checking step can be used to provide a double check to see if the glossary has been applied consistently. In an embodiment, a different LLM is used than the LLM that provided the translation.

[0028] In an embodiment, the glossary is generated using a claims set of a patent (application). Then the full specification (description plus claims) is translated using the glossary. This solves the issue that it can be time-consuming (and computationallyexpensive) to generate the glossary on the full specification. After all, the claims will mention the most important terms. Some inconsistencies in terms in the description that are not in the claims can be acceptable. In an embodiment, a different (less computationally and / or financially expensive) LLM is used to translate the description using the glossary, while a precise (and more expensive) LLM is used to generate the glossary and / or the claims translation. In a further embodiment, the description is translated using a more traditional machine translation model, such as the model used by DeepL, that can work with a custom glossary. The custom glossary is then the ad-hoc glossary as determined by the LLM based on the claims.

[0029] The LLM may be able to translate the entire claim set in one go. This would depend on the context size of the LLM. If the combination of the tokens for the instructions, glossary, source text, and translation fit inside the context, this can be done. Alternatively, the source text (the claims or description paragraphs) can be processed in batches, so that for each batch the combination of the tokens for the instructions, glossary, source text batch, and translated text batch will fit in the context window. With current context window sizes typically in the range 1 ,024 - 16,384 tokens (where one token is typically 50% - 75% of an input word, or on average about 4 input characters), the description will generally have to be processed in batches. With new context sizes up to 32k, 128k and beyond, that may no longer be necessary.Brief description of the figures

[0030] The disclosure is illustrated in the following figures:- Figure 1a shows an overview of a transformer architecture as used in LLMs according the prior art;- Figure 1b shows an overview of training an LLM according the prior art;- Figure 1c schematically shows a translation process according the prior art.- Figure 2a-b schematically show a method according the present disclosure;- Figure 3a shows a computer system able to implement the present disclosure;- Figure 3b shows a computer implemented method according the present disclosure ;- Figures 4a-c schematically show how an LLM instruction prompt according the present disclosure is formed;- Figures 5a-b schematically show methods according the present disclosure;- Figure 6 shows an example translated figure page according the present disclosure; and- Figure 7 schematically shows a further LLM instruction prompt according the present disclosure.Detailed description

[0031] Whilst the present examples predominantly relate to translating patent-related content, Applicant found that the method is not particularly limited to this type of content. The same method may be applied in the translation of any text in which consistent use of vocabulary is important. Non-limiting examples include technical manuals and descriptions, legal documents, such as contracts, legal briefs and statutory law texts, scientific research papers, medical reports and financial reports.

[0032] In the context of this disclosure, a large language model (LLM) is a generative artificial intelligence system designed to understand, interpret, and produce human language text. It leverages deep learning techniques, particularly transformer architectures, to generate coherent and contextually relevant text by predicting subsequent tokens in a sequence. An LLM, in operation, takes as input an instruction prompt and generates output text based on that prompt and the model’s previous training and (fine)tuning as encoded in its parameters. Typical LLMs have billions or trillions of parameters.

[0033] Large Language Models (LLMs) such as OpenAI’s, GPT, Meta’s LlaMA, Google’s Gemini (formerly Bard), Mistral Al’s Mixtral, and their contemporaries represent a significant advancement in the field of natural language processing (NLP) and artificial intelligence (Al). These generative Al models are engineered to understand, generate, and interact with human language. The architecture of these models is built upon several foundational elements that work in concert to process and produce human-like text.

[0034] At the core of LLMs lies an architecture 10a comprising several components, as illustrated in figure 1a. The tokenizer 11 is an initial stage which breaks down input text into manageable pieces, known as tokens, which can be words, parts of words, or even punctuation. This process facilitates the model's understanding by converting complex text into a standardized format.

[0035] Post-tokenization, the embedding stage 12 transforms each token into a numerical representation or vector. These embeddings capture semantic and syntactic information about the token, enabling the model to process linguistic nuances.

[0036] The heart of the model's architecture, transformer stages 13, employs self-attention mechanisms to analyse and generate text. These stages allow the model to weigh theimportance of different words in a sentence, considering both the immediate context and broader sentence structure. The final stage involves decoding the processed embeddings to generate text. This step employs algorithms to select the most probable next word or token, based on the context provided by the input and the model's training.

[0037] A standard reference for understanding the detailed architecture and mechanics of such models is the article "Attention Is All You Need" by Vaswani et al., which introduced the transformer model concept.

[0038] The training of LLMs is typically a two-part process 10b, as illustrated in figure 1b. The first step is unsupervised learning 14: Initially, models undergo unsupervised learning, where they are exposed to vast amounts of text data. This phase allows models to learn language patterns, grammar, and context without explicit instructions. The result is a model capable of completing texts based on the input it receives.

[0039] The second step is RLHF 15: Following unsupervised learning, models are finetuned through reinforcement learning. This phase involves training the model to follow instruction prompts more accurately by reinforcing desired output behaviours. For example, if the task is to write an essay, the model is rewarded for producing coherent, on-topic text, thereby teaching it to generate responses that align with human expectations and instructions.

[0040] LLMs exhibit remarkable strengths, including the ability to generate coherent and contextually relevant text across various domains, understand and generate human-like responses in conversations, and adapt to a wide range of linguistic styles and formats. Weaknesses of LLMs include a propensity for generating plausible but inaccurate or nonsensical information (commonly called “hallucination”), difficulty in understanding extremely domain-specific or technical language, and challenges related to ethical concerns and biases inherent in the training data.

[0041] At a technical level, a computer-implemented prior art translation process can be seen as shown in figure 1c. An input signal, encoding the text to be translated, is transformed into an output signal encoding the translated text. The input signal will typically come from a remote computer server, and the output signal is typically sent for to the same or another remote computer server for storage. The encoding can be e.g. ASCII coding of characters, as used in “plain text” computer files, it can be HTML, including meta data and layout features such as font styles, superscript, subscript, equations, etc, or even morecomplicated encodings used in word processing applications, e.g. .doc or .docx Word format, Rich Text Format (RTF), TeX or LaTex formats. Other types of encoding can also be used. What is important is that a signal can be manipulated (copied, transmitted, modified, etc) by a computer, and the encoded content (e.g. words of a text) can be retrieved from it.

[0042] Figure 2a schematically shows a method 20a according to an example of the disclosure, at a high level, and in contrast to the prior art method of figure 1c. According to the example, the input signal 201 is not directly converted into the output signal 204. Instead, first a generated intermediate signal 202, encoding the generated glossary, is created. That intermediate signal is then preferably (but optionally) reviewed and revised by a human user, creating an amended intermediate signal 203, encoding the amended glossary. The output signal 204 is then generated based on the input signal 201 and the amended intermediate signal 203 (which is identical to the intermediate signal 202 in case no review takes place). The output signal 204 can also comprise more than the encoded translation. It can additionally or alternatively encode parts of the input signal, the intermediate signals and the output signal in a manner that will aid review of the final translation by a human user.

[0043] Figure 2b shows an exemplary method 20b according to an example of the disclosure in more detail than the high level view of figure 2a. From hereafter the input signal 201 will simply be called the text (e.g. claims) to be translated, and the output signal 204 will be called the translated text (claims). Likewise, intermediate signal 202 and amended intermediate signal 203 will be called the generated glossary and the amended glossary respectively. Other signals are used as well, e.g. signals encoding the previous translations, background material (such as a patent description) to the text to be translated, results of translation checks, etc. It is understood that, at a technical level, these are also signals that are used as input and / or that are generated by the process. Finally, the instruction prompts that are assembled based on the signals, form signals in their own right. The signals encoding instruction prompts are typically sent over a network to an external server hosting the LLM (although it is also possible to self-host the LLM).

[0044] In step 21 , a custom glossary is created from a custom glossary list and the claims to be translated. The custom glossary can comprise translation patterns that are always to be applied. For example, the word “method” in English claims is to be translated to the Dutch word “werkwijze”, not “methode”. These general rules will be codified in a custom glossary list. The custom glossary list may be dependent on the field of the text to betranslated. For example, there can be different custom glossary lists for mechanical engineering and biotech. The correct custom glossary list can be manually selected or automatically (e.g. using the claims and descriptions to determine the field through a suitable prompt to the LLM).

[0045] Additionally or alternatively, an LLM may be used with a suitable instruction prompts to generate a glossary based on a previous translation. This is illustrated in more detail in figures 5a and 5b, which should be seen as supplementing the method of figure 2. Figure 2 shows method steps, while figures 5a and 5b show how data is input and output in these steps.

[0046] The description corresponding to the claims may be provided for context. The custom glossary can be generated in a variety of ways using heuristic rules, for example by string matching, possibly preceded by stemming (stemming is the process of reducing inflected or sometimes derived words to their word stem, base or root form), words from the claims to words from the custom glossary list. Other rule-based methods include embedding matching, or any of the tools available in the tool set of retrieval augmented generation (RAG). The custom glossary can also be generated by the LLM given a suitable prompt. For this, it is necessary that the LLM has a large context size which preferably can contain the full custom glossary list, the claims, and possibly the description, as well as the prompt for generating the custom glossary. Any of the above methods have as output a concise custom glossary related to the claims.

[0047] In step 22, a first instruction prompt is assembled for generating a glossary (hereafter “generated glossary”). The prompt contains general instructions, the custom glossary, an optional previous glossary (see figure 5a), the claims to be translated, and possibly the description for context. The prompt is then provided to a LLM, which generates as output a generated glossary specifically for the set of claims, integrating the provided custom glossary. An example of such a prompt is schematically shown in figure 4a.

[0048] The instruction prompt will contain instructions for the LLM to generate the generated glossary based on the text to be translated (in the present example, the claims). The instructions may be designed to prevent the LLM from generating the same translation for different terms. For example, if the claims comprise the term “apparatus” and “device”, both should not be translated into the Dutch “inrichting”. Likewise, the instructions can be designed to make translations of compound terms consistent. For example, if the claim refers to “request message” and “reply message”, it would be inconsistent to translate theseto Dutch as “verzoekbericht” and “antwoordboodschap”, respectively (both “bericht” and “boodschap” are synonyms having the same meaning as “message”). For consistency, it should be either “verzoekbericht” and “antwoordbericht” or “verzoekboodschap” and “antwoordboodschap”. A suitable instruction can make the LLM pay attention to this aspect. Another example of instructions can be to instruct the LLM to use Dutch words where possible and to avoid “lending” English words.

[0049] In step 23, the generated glossary from step 22 undergoes a manual review process. Here, a human (hereafter “user”), knowledgeable in both the source and target languages as well as the technical field of the patent, examines the glossary for accuracy, consistency, and completeness. The user may correct errors, fill in missing translations, and refine existing ones to ensure that each term is translated in a way that preserves its original meaning while adhering to the conventions of the target language, as well as the conventional way of working of that user or that user’s employer. This amended glossary serves as the final lexicon for translating the patent claims, ensuring a high level of precision and consistency in the use of technical terms. It is understood that this user revision step may be omitted, or that the user sees no reason to amend the generated glossary. In that case, the amended glossary is the same as the generated glossary, and the procedure can continue as described below.

[0050] In step 24, the translation of the claims is generated by building a second instruction prompt that includes the amended glossary from step 23, and instructing a second LLM (which can be the same as the first) to execute it. The second instruction prompt may specify the desired approach to translation, such as maintaining the original sentence structure as closely as possible or prioritizing natural readability in the target language. Depending on these instructions, the LLM generates a translation of the claims that employs the terms from the amended glossary consistently across the text. This step leverages the LLM's ability to understand and apply complex linguistic rules, producing a translation that is both accurate and faithful to the original text's intent, and above all uses a consistent translation based on the (user approved) glossary.

[0051] In step 25, the translated claims are subjected to a final review process, possibly by another LLM specialized in quality assurance or by a user expert. This step involves checking the translated text against the amended glossary and the original claims to identify any discrepancies, inconsistencies, or errors in the application of the glossary terms. The output is a list of remarks or suggested corrections for each translated claim, providing an opportunity for further refinement of the translation. This step serves as a quality controlmeasure, ensuring that the translated document meets the highest standards of accuracy and consistency. In theory, however, this quality control measure could be omitted from the process.

[0052] In step 26, an optional review by a user takes place. This review will advantageously make use of more information than just the translation. For example, the human user can (re)review the glossary and take the LLM-generated comments from the checking step 25 into consideration. For this human review, the output signal may encode a reviewer's document which contains the review information (see also figure 5a-b).

[0053] This method 20b, while illustrated for the translation of patent claims, is equally applicable to the translation of the full patent specification, including the description and figures, or the aforementioned other materials such as manuals, legal texts, etc. In such cases, a limited amount of key data, such as the claims, generally still provide a foundation for generating the glossary, but the description and potentially the figures can also contribute to the generation of the glossary, directly (looking for terms to translate) or indirectly (to provide context for the understanding of the claims’ terms and the correct translation thereof), ensuring comprehensive coverage of the patent's technical vocabulary. This approach allows for a nuanced, consistent translation that benefits from both the computational efficiency of LLMs and the nuanced understanding of human experts.

[0054] Figure 3a describes an exemplary system 30a according to the present disclosure. The exemplary system 30a comprises several interconnected components: a web client 31 , an application server 32, a database server 33, a LLM server 34, and a Document Management System (DMS) server 35.

[0055] The web client 31 can be a desktop computer, laptop, tablet, or mobile device used by the user, such as a patent attorney, translator, or patent engineer. The web client 31 serves as the interface through which the user interacts with the application server 32, providing inputs such as the selection of the custom glossary list, review, and amendment of generated glossaries, and final approval of translations.

[0056] The application server 32 is the heart of the system. In this particular example, it runs as a web application, but it can of course also be a desktop program, or use a different client-server architecture. The application orchestrates the translation process. It communicates with the database server 33 to fetch texts, with the LLM server 34 to generate and refine glossaries and translations, and with the DMS server 35 to store andmanage the translated documents. The application server 32 is responsible for compiling instruction prompts for the LLM based on user inputs and system parameters, executing the method steps described in Figure 2b, and presenting the generated outputs to the user for review and approval.

[0057] The database server 33 may be a patent database server, which stores (published) patent documents, including claims, descriptions, and figures, which are to be translated. The application server 32 accesses these documents as needed to generate custom glossaries and to provide context for the LLM during the translation process. The server accessible via the European Patent Office (EPO) Representational State Transfer (REST) Application Programming Interface (API) is an example of a database server 33.

[0058] Hosting the general-purpose Large Language Models, the LLM server 34 receives prompts from the application server 32 and returns the generated glossaries and translations. This server provides an API to the LLM. An example of such a server is the server accessible via the OpenAI API.

[0059] The Document Management System (DMS) server 35 interacts with the application server 32 to store the final translated documents along with their associated glossaries. The DMS server 35 can be part of a patent law firm’s docketing system, where the internal records for applications are stored. The DMS server 35 enables easy retrieval, review, and further processing of translated patents, ensuring that the translations are integrated into the firm's workflow and document management practices seamlessly.

[0060] In an embodiment, the application server 32 comprises three parts, a user interfacing (Ul) application 32a, a database (DB) 32b for storing intermediate results and configuration data, and a LLM interfacing application 32c (hereinafter “LLM app”). The Ul application 32a provides the user interface, interacts via a web server (not shown in application server 32) with the user’s web client 31 , receives user inputs, compiles the required instruction prompts based on the inputs, and presents generated glossaries and translations to the user. It may interact with the external database server 33 or external DMS server 35 to obtain inputs based on the user interaction. It may also interact with the DMS server 35 to store translated texts. Typically, translation jobs require multiple, sometimes dozens of instruction prompts. The user-entered information, including the text to be translated, and the generated prompts are stored in the internal database 32b.

[0061] The LLM app 32c, meanwhile, continuously reads the database to see if there are new prompts to be executed by the LLM. If it finds a new prompt, it executes it and stores the result from the LLM in the database 32b. The LLM app 32c is responsible for dealing with the LLM interaction, including fault handling (for example, the API may be temporarily unresponsive, or may return an error message indicating that too many requests or tokens per unit of time have been consumed). In turn, the Ul app 32a monitors the DB 32b, looking for results to the prompts. As the results come in, the translation is presented to the user. Applicant has found that such a division of responsibilities over three cooperating applications works smoothly. That said, different arrangements can also be made to implement the application server 32.

[0062] The internal database (DB) can also be used to store configuration information of the application, such as the instruction prompts templates from which the first, second and third instruction prompts are built. While it is possible to define instruction prompts for translations from any source language to any target language, in practice the dedicated prompts for may be defined for specific language pairs, e.g. for English - Dutch translation, for English - German translation, English - French, Dutch - English, German - Dutch, French - Dutch, and so on. Prompts may store examples of desired (or undesired) translation behaviour, and these examples may be provided in the source and target languages. The instructions may also contain guidelines that are specific to a source or target language. The instructions can be stored in the internal database so that the Ul app can conveniently retrieve them when needed. The Ul app can be coded to, when required to translate text from language A to language B, first look for instructions specifically for A to B translations. If these do not exist, the Ul app can look for A to any language instructions or any language to B instructions. If these also do not exist, the Ul app can retrieve, as a last resort, generic instructions (having generic examples and generic guidelines) for any language to any language.

[0063] The system 30a is designed to leverage the strengths of both humans and LLMs in translating complex patent documents. By generating initial glossaries and translations through the LLM server 34, the system ensures technical accuracy and consistency. Human experts using the web client 31 may review and refine these outputs, leveraging their understanding of the source and target languages, as well as the technical and legal nuances of the documents. This collaborative approach optimizes the translation process, ensuring high-quality outputs while significantly reducing the time and effort required from human translators.

[0064] It should be understood that the division in separate systems is not mandatory. In principle, the entire system could be implemented on a single computer system, running a self-hosted LLM (e.g. an open source Llama or Mixtral model) and having local access to all required input documents. However, the distribution of responsibilities over several servers advantageously allows an efficient design and a good integration in existing workflows (with the DMS integration) and service offerings (with e.g. EPO REST API, LISPTO Bulk Data Storage System (BDSS), Patent Examination Data System (PEDS) API, OpenAI API integration).

[0065] Figure 3b schematically illustrates a computer-implemented method 30b for processing and sending a translation to a server, designed as part of the system for translating legal texts such as patent descriptions and claims using general-purpose Large Language Models (LLMs).

[0066] In step 36, patent documents, claims and / or descriptions, are retrieved from a database server (e.g., database server 33). This step involves downloading the relevant documents to be translated, utilizing connections to patent databases such as those managed by patent offices or proprietary patent databases. The retrieval process is designed to ensure that all necessary textual content is available for the subsequent translation steps, providing a comprehensive base for generating accurate translations. The documents can also be downloaded from a DMS server 35.

[0067] Following the retrieval of patent documents, step 37 involves the generation of a glossary tailored to the specific translation task. This glossary generation is informed by the detailed instructions provided to a general-purpose LLM, as outlined in connection with Figure 2. The generated glossary is then subject to review and potential amendment by a user, such as a patent professional or language expert. This manual intervention allows for the refinement of the glossary, ensuring that it accurately reflects the technical terminology and nuances of the patent text.

[0068] Step 38 focuses on the actual translation of the claims and / or description documents based on the amended glossary prepared in step 37. As explained in connection with figure 2, this step leverages the capabilities of a general-purpose LLM to produce a translation that not only captures the literal meaning of the original text but also respects its technical and contextual nuances. The translation process is guided by the detailed instructions and the amended glossary, facilitating a translation output that meets high standards of accuracy and consistency.

[0069] Finally, in step 39, the completed translation is uploaded to a server for storage or further processing. This server may be part of a Document Management System (DMS), such as server 35, which is integrated into a patent firm's docketing system. The upload process ensures that the translated documents are securely stored and readily accessible for review, approval, or integration into patent applications.

[0070] The method 30b, as depicted in Figure 3b, showcases a systematic approach to translating patent documents, from the initial retrieval of source texts through to the generation of translations and their subsequent integration into a document management framework. This process embodies the inventive concept of utilizing general-purpose LLMs in a structured, human-assisted workflow to achieve translations of superior quality and consistency, particularly suited to the specialized domain of patent documentation.

[0071] Figures 4a - 4c schematically show how first, second and third instruction prompts according to the present disclosure are structured. Figure 4a shows a first instruction prompt, for generating a glossary. It contains a glossary generating instruction part 41 , user specific glossary terms 42 (the custom glossary), and the full or a sample of text to be translated 43. Care should be taken to make sure that all fits within the LLM’s context size. Many models (e.g. GPT-3.5, GPT-4 and turbo variants) require that the output also fits in the context window. In that case, care should also be taken to reserve enough space to fit the requested generated glossary (shown schematically below part 43).

[0072] In case the text to be translated does not fit, together with parts 41 and 42 and any reserved space, inside the context window, there are two options. Either only a sample of the translated text is used to generate the glossary (usually claims are a good sample, it is not needed to process the entire description in looking for important translation terms). Otherwise, the prompt can be compiled and run multiple times, each time with the same instructions 41 and custom glossary 42 (possibly including a previous glossary as explained in connection with figure 5a-b), but with a different sample part 43a, 43b, 43c, ... (not shown). The resulting glossaries are then compiled together and contradictions removed. This can be done manually or via a specific LLM instruction. Applicant has found that, in practice, a single prompt to generate a glossary on a representative sample such as the (independent) claims is usually sufficient.

[0073] An example of a first instruction prompt is as follows:“You are going to translate text to German. To ensure consistency, you will extract key terms from the text to be translated and will create a glossary, defining how certain terms are to be translated. Start by only generating the glossary, and incorporate therein the following custom glossary:{custom glossary}Here is the text:{sample of text to be translated}’’Expected output: {glossary}

[0074] In the above example, “{sample of text to be text}” is a placeholder for the text-to- be-translated, {custom glossary} contains user specific glossary items, and “{glossary}” is a placeholder for the glossary, which is generated by the respective LLM.

[0075] Figure 4b schematically shows the second prompt for generating a translation using a custom glossary. The translation instructions 44 will explain the purpose of the included glossary 45 and instructions on how to apply it. It will typically also contain style instructions as discussed before. The text to be translated 46a is also included in the prompt, leaving enough room for the translation output (not shown).

[0076] When translating descriptions or larger claim sets, it will often not be possible to use just one instruction prompt. In that case, a stack of instruction prompts is created, each with a successive sample of the text to be translated. Each prompt will typically have the same translation instructions 44 and glossary 45, but different samples to be translated 46a, 46b, 46c, etc.

[0077] In figures 4b and 4c, the reserved space for the output is no longer shown, for simplicity. As a rule of thumb, if the translation instructions 44 and generated or amended glossary 45 take up 20% of the prompt, then only 40% of the context size can be used for the text to be translated, leaving the last 40% for the translation output. To have a margin, it is recommended to actually use e.g. 35% for the text to translate, leaving an expected 10% of the context size unused. It should also be borne in mind that translating 1000 tokens of e.g. an English text to German, does not mean the German translation will use 1000tokens. It can be more or less, depending on the language and details of the tokenizer. Therefore, a margin is will allow for an increase in tokens of target language. .

[0078] An example of a second instruction prompt is as follows:“You are going to translate a text to German using the following glossary, which should be applied consistently in the translation:{glossary}Here is the text:{sample #n of text to be translated}’’Expected output: {translation}

[0079] The meanings of the placeholders “{glossary}” and “{sample #n of text to be translated}” are as described hereinbefore, “{translation}” is a placeholder for the translation generated by the respective LLM. Again, examples and more detailed instructions can be used to improve consistency and guide output for automatic processing.

[0080] Figure 4c schematically shows a third instruction prompt for checking translated claims. It comprises checking instructions 47, the amended or generated glossary 48 used in the translation, a sample 49a of the text to translate, and a corresponding translated sample 49’a. Again a stack of instruction prompts will be needed, with typically identical parts 47, 48 and different parts 49a, 49’a, 49b, 49’b, 49c, 49’c, etc.

[0081] An example of a third instruction prompt is as follows:“You have generated a translation of the following text:{sample #n of text to be translated}The translation reads as follows:{translation}You have used the following glossary in the translation:{glossary}Check whether the glossary has been consistently used in the translation of the text. ”Expected output: {check}

[0082] The meanings of the placeholders “{sample #n of text to be translated }”, “{translation}” and “{glossary}” are as described hereinbefore, “{check}” is a placeholder for the output of the check of the translation. Examples of e.g. types of mistakes to watch for and more detailed instructions on what to check can be used to the quality of the check, and to guide output for automatic processing.

[0083] Figure 5a-b illustrates methods 50a and 50b according to the present disclosure, making use of a previous translation if it is available. For example, when translating claims of a divisional application, it makes sense to use the same terms as used in a previous translation 52 of the parent application. Likewise, if an English language European application is based on a Dutch language priority application, it makes sense to translate the granted European claims to Dutch using the same terminology as used in the original Dutch application’s claims 51.

[0084] Figure 5a shows the case when the text of a previous application is available in the original language 51 with a corresponding translation in the target language 52 (this will often be the case for the parent of a divisional application). In that case, an LLM can be instructed to generate a previous glossary 55 which lists the key terms and the previously used translation. Based on the new text 54 to be translated and the custom glossary list 53, the custom glossary 56 may be created as detailed in step 21 of figure 2. The previous glossary 55 and the custom glossary 56 are then used with the new text to be translated 54 to generate the glossary 57, completing step 22. The glossary generating instructions may bias the generated glossary towards the previous glossary or towards the custom glossary, in case there would be differences between the two. The translation 58 is generated based on (amended) glossary 57 and the text to be translated 54, and check results 59 are generated, based on the same inputs, in the manner already described in reference to steps 24 and 25, respectively. The step 23 of amending the generated glossary 57 is omitted in figure 5a and 5b for brevity, but may still take place. Based on one or more of the items 53 - 59, a reviewer's document 591 may be generated for review of thetranslation 58 by a human user. In an embodiment, the reviewer's document comprises the custom glossary, the previous glossary, if any, the generated and amended glossary, the new text 54 and the translation 58 in a side by side view, and check results may be inserted in appropriate places in the side by side view. The reviewer's document aids step 26 of figure 2b.

[0085] Figure 5b shows a case similar to the case of figure 5a, but in this case the step of generating a previous glossary 55 omitted, and the input from any previous text (original language and / or translation) is directly taken into account using the 1stinstruction prompt in generating the generated glossary 57. In fact, the previous text in the original language 51 may not be available. This can for example be the case when the previous text is a priority application in the target language. The generated glossary 57 is directly generated, using a suitable instruction in the first instruction prompt, based on the previous translation 52, the new text to be translated 53 and a custom glossary 56. Again, the glossary generating instructions may bias the generated glossary towards terms from the previous translation 52 or from the custom glossary 56, in case there would be differences between the two.

[0086] A further alternative is when there is no previous text translation 52 at all. In that case the generated glossary 57 is generated based on the custom glossary and the text to be translated 54, using the 1stinstruction prompt.

[0087] The disclosure is further illustrated by the following two examples.Example 1

[0088] The following claim set is translated to Dutch using DeepL (desktop application, version 24.1.2.11804) and using the examples and embodiments of the disclosure (underlining of noteworthy terms added).1. Water supply system for a greenhouse, comprising:- a water supply line connected to a water source- a water delivery line configured to irrigate plants- wherein the water supply line and the water delivery line is connected to a water supply pump.2. The water supply system of claim 1, wherein the water supply line comprises a tap.3. The water supply system of claim 1 or 2, wherein the water supply pump comprises a piston and an electrical engine with power source.

[0089] The DeepL translation is as follows (underlining of noteworthy terms added):1. Watertoevoersysteem vooreen kas, bestaande uit:- een watertoevoerleiding aangesloten op een waterbron- een watertoevoerleiding die geconfigureerd is om planten te irrigeren- waarin de watertoevoerleiding en de watertoevoerleiding verbonden zijn met een watertoevoerpomp.2. Het watertoevoersysteem van eis 1, waarin de watertoevoerleiding een kraan bevat.3. Het watervoorzieninqssysteem van eis 1 of 2, waarbij de watervoorzieninqspomp bestaat uit een zuiger en een elektromotor met krachtbron.

[0090] There are several problems with this translation. In claim 1 , both “water supply line” and “water delivery line” are translated as “watertoevoerleiding”, which even gives rise to the nonsensical “waarin de watertoevoerleiding en de watertoevoerleiding verbonden zijn met...” (“wherein the water supply line and the water supply line are connected to... “. In claim 2, the word “claim” is translated as “eis” (also meaning “demand”), but Dutch patent law requires that the word “conclusie” is used. In claim 3, the term “water supply pump” is translated as “watervoorzieningspomp”, where in claim 1 it was translated as “watertoevoerpump”. Both translations are acceptable as such, but in the present context the inconsistency is problematic, since the Dutch language claims now suggest there are two (slightly differently named) pumps. Likewise, “water supply system” is translated as “watervoorzieningssysteem” in claim 3, while it was translated as “watertoevoersysteem” in claims 1 and 2, suggesting that claim 3 relates to a new system different from the systems of claim 1 and 2. Clearly, for all of the above reasons, this is an unsuitable translation for patent claims.

[0091] The translation according the disclosure delivers the following results. In these examples, the OpenAI model “gpt-4-0613” (“snapshot of gpt-4 from June 13th2023 with improved function calling support”) with 8192 tokens context size was used for all LLM instruction prompts.

[0092] First, the system uses heuristic rules to crosslink the claims with the custom glossary list to identify relevant terms in the custom glossary list, selecting the following terms from the custom glossary list: claim :: conclusie comprises :: omvat comprising :: omvattend configured :: ingericht wherein :: waarbij

[0093] The first instructions then cause the gpt-4 LLM to find relevant terms in the claims to be translated, and generate a proposed glossary including said terms and the proposed translations. The LLM does not provide translations for every mundane word, but is instructed to only identify key terms and to combine the found terms and their proposed translations with the custom glossary. In this example, the generated glossary, which thus incorporates the custom glossary, then reads as follows: claim :: conclusie comprises :: omvat comprising :: omvattend configured :: ingericht wherein :: waarbijWater supply system :: Watervoorzieningssysteem greenhouse :: kas water supply line :: watertoevoerleiding water source :: waterbron water delivery line :: waterafleverleiding irrigate :: irrigeren plants :: planten water supply pump :: watertoevoerpomp tap :: kraan piston :: zuiger electrical engine :: elektrische motor power source :: stroombron

[0094] The original terms and the translated terms are separated by separator which has been chosen as unlikely to occur in texts to be translated. Other separators can be used as well.

[0095] The glossary generating instructions caution the LLM against translating different terms to the same expression. This approach is successful, since the glossary includes “water supply line :: watertoevoerleiding” and “water delivery line :: waterafleverleiding”, unlike DeepL, which used “watertoevoerleiding” for both English terms.

[0096] The resulting translation according the disclosure is:1. Watervoorzieningssysteem vooreen kas, omvattend:- een watertoevoerleiding verbonden met een waterbron- een waterafleverleiding ingericht om planten te irrigeren- waarbij de watertoevoerleiding en de waterafleverleiding verbonden zijn met een watertoevoerpomp.2. Het watervoorzieningssysteem van conclusie 1, waarbij de watertoevoerleiding een kraan omvat.3. Het watervoorzieningssysteem van conclusie 1 of 2, waarbij de watertoevoerpomp een zuiger en een elektrische motor met stroombron omvat.

[0097] None of the problems of the DeepL translation occur in this case. The translation is consistent, and different English terms have different (and consistent) Dutch translations.

[0098] The claims check, which is performed on each original claim I translated claim pair separately, in this case returns a simple list of “no issue found”:Claim 1: no issues foundClaim 2: no issues foundClaim 3: no issues foundExample 2

[0099] Example 2 is the same as example 1 , except that in this case the user decides to make two amendments to the generated glossary.

[0100] The user replaces “Water supply system :: Watervoorzieningssysteem” with “Water supply system :: Watertoevoersysteem” to be more consistent (in “water supply line” and in “water supply pump”, the word “supply” is translated as “toevoer”, not “voorziening”). In addition, the user may prefer the word “krachtbron” instead of “stroombron” as translation of “power source”.

[0101] The amended glossary then reads (with underlining added for the changes, and items unchanged compared to example 1 omitted):[ terms “claims" ... “wherein"]Water supply system :: Watertoevoersysteem[ terms “greenhouse" ... “electrical engine" ] power source :: krachtbron

[0102] The translation comes out with these terms consistently used (underlining added to show the difference with example 1):1. Watertoevoersysteem vooreen kas, omvattend:- een watertoevoerleiding verbonden met een waterbron- een waterafleverleiding ingericht om planten te irrigeren- waarbij de watertoevoerleiding en de waterafleverleiding verbonden zijn met een watertoevoerpomp.2. Het watertoevoersysteem van conclusie 1, waarbij de watertoevoerleiding een kraan omvat.3. Het watertoevoersysteem van conclusie 1 of 2, waarbij de watertoevoerpomp een zuiger en een elektrische motor met krachtbron omvat.

[0103] In an embodiment, the system supports patent figure translations. While typical textual claims and descriptions are processed as text batches, any accompanying figures may be retrieved, converted (e.g., from PDF or external sources) into image data (e.g., base64-encoded), and provided in a prompt to the LLM along with instructions for caption interpretation or figure labelling. The system can batch-process these figures, storing translations or descriptions as separate text outputs.

[0104] Figure 6 shows an example output page 61 of such a translation. The output page 61 comprises the input page 62 in the original language (in this example, the first drawings page of the present application is used as input page 62) and a translation table 63 generated by the LLM using the glossary in the same manner as described earlier in reference to the claims. The example table contains, in the first column the original textual elements found in the figures by the LLM and in the second column a Dutch translation based on the glossary. In this embodiment, the LLM must be an LLM with vision capabilities to interpret and translate the input page 62. Example LLM’s with such capability are OpenAI’s gpt-4o and Anthropic’s Claude 3.5 sonnet.

[0105] Another approach to translating figures involves using Optical Character Recognition (OCR) to identify and extract text elements from the input page. Once the text is recognized, the system can apply the translation process using the established glossary. The translated terms can then be overlaid onto the original figure, replacing or appearing alongside the source language text.

[0106] Figure 7 shows a schematic representation 70 of an instruction prompt layout that takes advantage of recent developments in LLM context size asymmetry. Modern LLMs typically have a much larger input context size (e.g., 128,000 tokens for OpenAI's GPT-4 with vision, or 200,000 tokens for Anthropic's Claude 3.5 sonnet) compared to their output context size (typically 8,000 - 16,000 tokens). The embodiment of figure 7 leverages this asymmetry to provide more context to the LLM during translation, thereby improving consistency.

[0107] The layout 70 includes several components arranged to optimize the use of the available context window. At the top, a section 71 contains the full text to be translated or, more typically for longer documents, a strategic selection thereof. Below this, a section 72 shows the translation generated so far. These sections 71 , 72 expand upon the structure shown in figure 4b by providing additional context to the LLM beyond just the current batch being translated.

[0108] The translation generating instructions and examples are contained in section 73, corresponding to the translation instructions 44 of figure 4b. The amended or generated glossary is stored in section 74, corresponding to the glossary 45 of figure 4b. The current sample to be translated, indicated as "Sample #n" in section 75, corresponds to the sample 46a, 46b, 46c, etc. of figure 4b. The vertical extent of sections 71-75 is indicated by brackets 76, representing the total context size of the LLM.

[0109] For particularly large documents where even the expanded input context size is insufficient to contain the entire text, sections 71 and 72 may be populated strategically. For example, section 71 might contain only the X most recent batches of the text to be translated, where X is chosen based on available context size. Alternatively, section 71 might contain a combination of the first N batches (providing document context) and the most recent M batches (providing local context), where N+M is chosen to fit within the available context size. A similar approach can be applied to section 72, containing either the most recent X batches of translation, or a combination of the first N and most recent M batches of translation.

[0110] The brackets 76 and 77 at the bottom of figure 7 indicate that this layout is repeated for subsequent batches. After processing the current batch containing Sample #n in section 75, the system will process the next batch (indicated by bracket 76) and then the following batch (indicated by bracket 77), each using the same layout structure but with updated content in sections 71-75. This batch-wise processing allows the system to handle documents of any length while maintaining consistency through the broader context provided in sections 71 and 72 for each batch.

[0111] According to an embodiment, the system implements a post-processing step after the initial translation. The post-processor uses the same structure as or a structure similar to that shown in figure 4c, where post-processing instructions 47 replace checking instructions, and where the output will be a corrected version of the translation rather than a checking report. The post-processor may be implemented using the same or a different LLM than used for translation.

[0112] The post-processor receives multiple inputs: post-processing instructions, the glossary used in the translation, a batch of original text in the source language, and a corresponding batch of translated text. The post-processing instructions configure the LLM to perform multiple types of corrections:- grammatical corrections, ensuring proper verb conjugation, agreement between subjects and verbs, etc;- clarity improvements, resolving ambiguous references or unclear sentence structures;- verification and correction of glossary term usage; and- application of language-specific patent claim drafting conventions.

[0113] The post-processing instructions may be customized for specific language pairs and specific types of texts. For patent claims translated from English to Dutch, for example, the instructions direct the LLM to remove articles at the start of dependent claims, so that "The method according to claim 1" becomes "Werkwijze volgens conclusie 1" rather than "De werkwijze volgens conclusie 1". Similar language-specific conventions can be encoded in the instructions for other language pairs.

[0114] In an embodiment, the post-processor processes the translation in batches, similar to the translation step itself. Each batch may comprise one or more claims, or a portion of the description. The post-processor maintains consistency across batches by having access to the glossary and, optionally, to previously post-processed batches.

[0115] The output of the post-processor is a corrected version of the translation. As described above, the differences between the initial translation and the post-processed version may be presented to a human reviewer in a "track changes" format, allowing efficient review and selective acceptance or rejection of the proposed changes. This approach combines the efficiency of automated post-processing with the judgment of a human reviewer who can evaluate whether the proposed changes genuinely improve the translation.

[0116] In an embodiment, the system uses a simplified HTML format as the internal text representation format for both input and output signals. This simplified HTML supports a basic set of tags including div, p, b, i, ol, sup, sub, ul, li, and img (for inline images), providing sufficient markup capabilities for patent-related content while avoiding the complexity of full HTML or word processor formats.

[0117] The simplified HTML format provides several technical advantages. First, it supports the minimal layout features required for accurate representation of technical and scientific content. Chemical formulas, for example, can be correctly rendered using superscript and subscript tags (e.g., "H2O" for water), while mathematical expressions can be properly formatted using a combination of these basic tags. Similarly, the img tag allows for inline representation of chemical structures, mathematical symbols, or other graphical elements that are essential to the technical disclosure but cannot be represented as plain text.

[0118] Second, the simplified HTML format optimizes token usage in the LLM context. Unlike full word processor formats (such as .docx) or complete HTML, which may include extensive styling information, font specifications, and other formatting metadata, thesimplified HTML format minimizes the number of tokens used for formatting. This reduction in formatting-related tokens allows more efficient use of the LLM's context window for actual content translation. For example, a chemical formula that might require dozens of tokens in a .docx format can be represented in just a few tokens using simplified HTML tags. A further advantage is that LLM’s typically have a deep understanding of HTML because it is featured extensively in their (pre-)training dataset, so LLM’s will not fall into the error of, for example, starting to translate HTML tags.

[0119] Third, the simplified HTML format serves as an effective intermediate format for import and export operations. The system implements converters for translating between this simplified HTML format and various input / output formats commonly encountered in patent processing:- Patent office databases typically provide documents in full HTML or XML formats;- Law firm document management systems often work with .docx or PDF files;- Patent registers may provide documents in PDF format with OCR text;- Human reviewers typically prefer to work with .docx files.The simplified HTML format acts as a hub format, allowing the system to implement N input converters and M output converters rather than requiring N*M direct conversion paths between all possible input and output formats.

[0120] For example, when processing an input .docx file, the system first converts it to the simplified HTML format, stripping away unnecessary formatting while preserving essential structure such as paragraphs, lists, and technical notation. The LLM then processes this simplified HTML, maintaining the structure while translating the content. Finally, the translated simplified HTML can be converted back to .docx format, reapplying any necessary styling information according to configurable templates. This approach separates concerns between content translation and document formatting, improving both the efficiency of the translation process and the reliability of the format conversion steps.

[0121] In a further embodiment, the system for generating a glossary and translating patent documents is deployed as an interconnected front-end and back-end application, featuring a user interface, workflow logic, and batch scheduling mechanism. This embodiment can be implemented, for instance, by means of a client-accessible application (e.g., a web application) cooperating with an LLM-based translation service which runs as a background task and continually sends batches to a LLM.

[0122] According to an embodiment, a web-based client interface is provided, allowing multiple users to log in, retrieve textual data (including patent claims, descriptions, and optionally figures), and manage translation jobs. The system may offer “bulk import” of multiple patent cases (e.g., from Excel spreadsheets or via a third-party docketing or document management system such as Equinox). Each bulk import entry triggers the following:- creation of new records containing the relevant patent identifiers;- automatic retrieval of bibliographic data or claim text from external sources (e.g., a publication server); and- generation of an initial or “draft” glossary, followed by user-driven refinement according to the workflow described above.

[0123] A practical implementation may have a configuration layer that can integrate multiple large language model providers (e.g., OpenAI, Anthropic). This “dual library handle” approach enables dynamic selection and switching of LLM endpoints or models at run time. For each job, the system can direct the translation queries (including glossary generation, partial / batch translation prompts, and post-translation checks) to different LLM service back-ends based on user preference, cost, or performance metrics. The same or different LLMs can be used for the glossary extraction step, the main translation step, and the final checking step.

[0124] A further enhancement is the capability to upload or synchronize completed translations back into a third-party DMS or docketing system. The software can:- Query whether an existing translation for a given patent reference already exists in the DMS;- If absent, upload newly generated Word (DOCX) files containing the translated claims (and optionally the translated description and / or annotated figures);- Update the local database fields to reflect the “uploaded” status.

[0125] One embodiment, alluded to earlier in the description of the post-processing step, includes word-processor-oriented mark-up routines that highlight differences between an initial translation and a post-checked or post-processed version, effectively simulating “track changes.” The code uses a specialized HTML differencing algorithm, generating either partially inline or side-by-side comparisons, which can then be converted into DOCX- based redlining or a final annotated Word file. This advantageously allows a human checker of the translation to review the changes made by the post-processing step, and to either accept them as genuine improvements or reject them and go back to the original translation.The inventors have found that post-processing produces changes of which a high fraction (e.g. above 90%) is considered by reviewers an improvement, but which also produces a non-negligible amount (e.g. up to 10%) of changes that are not considered an improvement. Therefore, using track changes functionality of existing word processors to let reviewers accept or reject these changes makes for an efficient workflow.

[0126] In the foregoing description of the figures, the disclosure has been described with reference to specific embodiments thereof. It will, however, be evident that various modifications and changes may be made thereto without departing from the scope of the disclosure as summarized in the attached claims.

[0127] In addition, many modifications may be made to adapt a particular situation or material to the teachings of the disclosure without departing from the essential scope thereof. Therefore, it is intended that the disclosure not be limited to the particular embodiments disclosed, but that the disclosure will include all embodiments falling within the scope of the appended claims.

[0128] In particular, combinations of specific features of various aspects of the disclosure may be made. An aspect of the disclosure may be further advantageously enhanced by adding a feature that was described in relation to another aspect of the disclosure.

[0129] It is to be understood that the disclosure is limited by the annexed claims and its technical equivalents only. In this document and in its claims, the verb "to comprise" and its conjugations are used in their non-limiting sense to mean that items following the word are included, without excluding items not specifically mentioned. In addition, reference to an element by the indefinite article "a" or "an" does not exclude the possibility that more than one of the element is present, unless the context clearly requires that there be one and only one of the elements. The indefinite article "a" or "an" thus usually means "at least one".

Claims

Claims1 . A computer-implemented method for converting an input signal to an output signal, the input signal encoding a text to be translated from a first language to a second language and the output signal encoding a translation of said text to be translated, the method comprising:- obtaining the input signal;- using a first large language model, LLM, to generate, using as input a first instruction prompt and at least a part of the input signal, a generated intermediate signal encoding a glossary of a plurality of terms in the text to be translated with corresponding translations in the second language;- providing an amended intermediate signal based on the generated intermediate signal;- using a second LLM to generate, using as input a second instruction prompt, the input signal and the amended intermediate signal, the output signal, and- sending the output signal for storage, wherein the second LLM is configured, through the second instruction prompt, to use the glossary in the translation of the text to be translated from the first language to the second language.

2. The method according to claim 1 , wherein providing an amended intermediate signal based on the generated intermediate signal comprises copying the generated intermediate signal to the amended intermediate signal and incorporating revisions from a user in the amended intermediate signal.

3. The method according to claim 1 or 2, wherein the information of the generated intermediate signal and the amended intermediate signal are stored in a training database for training or finetuning the first LLM.

4. The method according to claim 3, wherein the first LLM is trained or finetuned using the training database.

5. The method according to any one of claims 1-4, wherein the first LLM is the same as the second LLM.

6. The method according to any one of claims 1-5, wherein a subset of the input signal is used to generate the generated intermediate signal.

7. The method according to any one of claims 1-6, wherein the output signal is generated in batches, each successive batch using as input a successive subset of the input signal and the amended intermediate signal.

8. The method according to any one of claims 1-7, wherein the input signal encodes patent or patent application claims.

9. The method according to any one of claims 1-8, wherein the input signal encodes patent or patent application description and claims, and wherein a first subset of the input signal comprises the patent application claims, and wherein the glossary is generated based on the first subset of the input signal.

10. The method according to any one of claims 1-9, wherein the input signal encodes patent or patent application description and claims, and wherein the second LLM is used for the translation of a first subset of the input signal comprising the patent or patent application claims, and wherein a third LLM is used for the translation of a second subset of the input signal comprising the patent or patent application description.

11. The method according to any one of claims 1-10, further comprising:- using a fourth LLM to generate, using as input a third instruction prompt, the input signal, the amended intermediate signal, and the output signal, a checking signal encoding a report on the accuracy of the translation.

12. The method according to any one of claims 1-11 , wherein the first instruction prompt includes a custom glossary selected based on the input signal.

13. The method according to any one of claims 1-12, wherein the first or second LLM is one of OpenAI’s GPT, Llama-2, Gemini, Mixtral Al, Anthropic’s Claude, remotely or locally hosted.

14. The method according to any one of claims 1-13, further comprising:- using a post-processor to perform corrections on the output signal, wherein the postprocessor uses a third LLM with a third instruction prompt to generate a corrected version of the translation.

15. The method according to claim 14, wherein the post-processor performs at least one of:- grammatical corrections;- clarity improvements;- verification and correction of glossary term usage; and- application of language-specific or region-specific patent claim drafting conventions.

16. The method according to claim 14 or 15, further comprising:- generating a difference output comparing the output signal to the corrected version of the translation; and- presenting the difference output to a user in a track changes format.

17. The method according to any one of claims 1-16, wherein the input signal includes image data of patent figures, and the method further comprises:- using an LLM with vision capabilities to interpret and translate textual elements in the figures; and- generating a translation table containing original textual elements and their corresponding translations.

18. The method according to any one of claims 1-17, wherein generating the output signal in batches comprises:- providing additional context to the second LLM for each batch, wherein the additional context includes:- a portion or the entirety of the full text to be translated; and- a portion or the entirety of the translation generated so far.

19. The method according to claim 18, wherein the additional context is provided within an expanded input context of the second LLM, and wherein the expanded input context is larger than an output context of the second LLM.

20. The method according to any one of claims 1-19, wherein the method further comprises:- processing multiple translation jobs in a batch mode;- automatically retrieving input data for each job from one or more external sources; and- generating an initial draft glossary for each job.

21. The method according to any one of claims 1-20, wherein the input signal and the output signal are encoded in a simplified HTML format supporting a basic set of tags for representing technical and scientific content.

22. The method according to claim 21 , further comprising:- converting between the simplified HTML format and other document formats for input and output operations.

23. The method according to any one of claims 1-22, further comprising:- dynamically selecting an LLM provider or model for each of the first LLM, second LLM, and any additional LLMs used in the method based on at least one of user preference, cost, or performance metrics.

24. A system comprising a memory and at least one processor, said memory storing program instructions which, when executed on the at least one processor, cause said at least one processor to execute any of the methods of claim 1 - 23.

25. The system according to claim 24, wherein the input signal is obtained from a database server or from a document management system, DMS, server, and wherein the output signal is stored in the DMS server.

26. The system according to claim 24 or 25, wherein using the first LLM and using the second LLM comprises, respectively,- assembling the first and the second instruction prompts;- sending the first and second instruction prompts to an LLM server;- retrieving a first and second response from the LLM server.

27. A computer program product comprising instructions which, when executed on a processor, cause said processor to perform any of the methods of claims 1 -23.

Images