Method for the automated processing of a transaction, represented by a structured file
Patent Information
- Application Number
- PCT/EP2026/061086
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-04-16
- Filing Date
- 2026-04-16
- Publication Date
- 2026-10-22
Smart Images
Figure EP2026061086_22102026_PF_FP_ABST
Abstract
Description
[0001] Description
[0002] Title of the invention: Method for the automated processing of a transaction, represented by a structured file.
[0003] GENERAL TECHNICAL FIELD
[0004] The present invention relates to the field of computerized data exchange. More specifically, it concerns a method for the automated processing of a transaction between a sending entity and a receiving entity, represented by a structured file.
[0005] STATE OF THE ART
[0006] Invoices, and in general documents exchanged between companies (letters of order, quotes, mandates, orders, etc.) have now been massively dematerialized.
[0007] We know of electronic data interchange (EDI) techniques, in which a stream of structured data is transmitted alternatively or in addition to the document, for example the invoice in PDF, for automated processing.
[0008] In particular, application FR 24 / 09534 proposes an ingenious method for implementing a transaction between a sending entity and a receiving entity, relating to a task required by one entity from the other. This task is defined by a form comprising multiple fields, enabling the generation of a structured file that does not conform to a predetermined structured file model chosen based on a type of formal form / document (invoice, purchase order, etc.) or even a type of transaction. On the contrary, this structured file is "universal," i.e., it applies regardless of the document type, including non-conventional documents. Thus, the method is completely agnostic in that it makes no distinction between types of transactions or documents, and a transaction is implemented in a similar way regardless of the document type.
[0009] While this process is entirely satisfactory, its universality paradoxically becomes a disadvantage if automated data processing is desired on the receiving entity's side—that is, more than simply automatically importing the data into the fields, but rather implementing a predetermined action. In a simple transaction such as invoicing, for example, the user can be asked to approve or reject the invoice, and if so, a corresponding payment can be automatically prepared in response to the invoice.
[0010] Indeed, automated processing is generally only possible if the received structured file is recognized, i.e., corresponds to an expected model for which a predetermined action has been defined, corresponding to a form template defining said task, applied as input. And since the process described in application FR 24 / 09534 allows complete freedom over the structured file, theoretically, a virtually infinite number of expected models would be necessary, whereas the very purpose of this process is to avoid the rigidity of templates.
[0011] For example, to return to the invoicing example, we can already have simple invoices and complete invoices, and therefore two expected templates (templates 1 and 2). Then, the invoice can be sent plainly, or with a report of the work completed, or conversely, with a document transmitted (such as an official letter) if it is a transmission invoice (with templates 3 and 4 respectively). We thus need 4 additional templates corresponding to the various combinations of a template 1 or 2 with a template 3 or 4, and so on.
[0012] This solution is satisfactory but proves inflexible and inflexible, as the data must be communicated exactly according to models or templates to be accepted. While multiple templates can be created for each of the entities involved, this is laborious. The present invention improves the situation by maintaining the flexibility of a universal structured file while avoiding the need for multiple templates for automated processing.
[0013] PRESENTATION OF THE INVENTION
[0014] The present invention therefore relates, in a first aspect, to a method for the automated processing of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities from the other, characterized in that it comprises the implementation, by a client device of the receiving entity, of the following steps:
[0015] (a) Obtaining a structured file representative of the transaction, said structured file consisting of one or more elementary objects of a category chosen from a finite list of categories of objects describing an aspect of the task, called the first list, of which at least one object describing an event associated with the task including an action code chosen from a finite list of possible action codes, each defining a type of action expected in the automated processing of said transaction, called the second list;
[0016] (b) Extraction of data from the fields of said structured file, including said action code;
[0017] (c) Implementation of at least one expected action determined according to said extracted action code, on the other extracted data.
[0018] According to advantageous and non-limiting characteristics:
[0019] The said structured file is generated from the contents of the fields of a form defining the said task, obtained at the level of a first client device of the sending entity, the said client device of the receiving entity being a second client device, step (a) comprising making the said message available to the said second client device, by at least one server connected to the said first and second client devices by a communication network.
[0020] The process includes a preliminary step (aO) of generation by said at least one server of said structured file comprising the transcription of said contents of the field(s) of said form into the object fields of said structured file.
[0021] Each category of object in said first finite list is defined by a predefined set of object fields, each elementary object itself being composed of blocks defining subsets of said predefined set of object fields, and of links between fields of the blocks.
[0022] The object categories in the first list are:
[0023] - Descriptive object of a part involved in said task;
[0024] - Descriptive object of an asset involved in said task;
[0025] - Descriptive object of an event associated with the task;
[0026] - Descriptive object of an accounting aspect of said task;
[0027] - Descriptive object of a document associated with said task.
[0028] The possible action codes from the second list are:
[0029] - Code defining an expected action of the type providing information;
[0030] - Code defining an expected action of the information reception type; - Code defining an expected action of the execution type;
[0031] - Code defining an expected action of the confirmation type;
[0032] - Code defining an expected action of the "taking charge" type;
[0033] - Code defining an expected action of the verification type.
[0034] The descriptive object of an event associated with the task also includes a code of the event chosen from a finite list of possible event codes, called the third list, said event code being independent of said action code, step (b) also including the extraction of said event code.
[0035] The expected action implemented in step (c) is entirely defined by the combination of the action code and the event code. An action code is extracted for each descriptive object of an event associated with the task, step (c) comprising, for each descriptive object of an event associated with the task, the determination of the expected action and the implementation of said determined expected action.
[0036] A second server of the receiving entity implements a data management system of the receiving entity, step (b) comprising the automatic export of data from the fields of said structured file to said data management system of the receiving entity.
[0037] According to a second aspect, the invention proposes a client device for a receiving entity, characterized in that it is configured to:
[0038] - Obtain a structured file representing a transaction between an issuing entity and said receiving entity, relating to a task required by one of the entities, from the other, said structured file being made up of one or more elementary objects of a category chosen from a finite list of categories of objects describing an aspect of the task, called first list, of which at least one object describing an event associated with the task including an action code chosen from a finite list of possible action codes each defining a type of action expected in an automated processing of said transaction, called second list;
[0039] - Extract data from the fields of said structured file, including said action code;
[0040] - Implement at least one expected action determined according to said extracted action code, on the other extracted data.
[0041] According to a third and a fourth aspect, the invention provides a computer program product comprising code instructions for the execution of a process according to the first aspect for the automated processing of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other; and a computer-readable storage means on which is stored a computer program product comprising code instructions for the execution of a process according to the first aspect for the automated processing of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other.
[0042] PRESENTATION OF THE FIGURES
[0043] Other features and advantages of the present invention will become apparent from the following description of a preferred embodiment. This description will be given with reference to the accompanying drawings, in which:
[0044] [Fig. 1] Figure 1 is a diagram of a system for implementing the process according to the invention;
[0045] [Fig. 2a] Figure 2a illustrates a first example of a structured file used in the process according to the invention;
[0046] [Fig. 2b] Figure 2b illustrates a second example of a structured file used in the process according to the invention;
[0047] [Fig. 2c] Figure 2c illustrates a third example of a structured file used in the process according to the invention;
[0048] [Fig. 3] Figure 3 is a flowchart illustrating the steps of an embodiment of the process according to the invention;
[0049] DETAILED DESCRIPTION
[0050] Architecture
[0051] The present invention relates to a method for the automated processing of a transaction between an sending entity (which we will simply call "sender") and a receiving entity (which we will simply call "receiver"), in this case represented by a structured file, and typically defined originally by a form comprising a plurality of fields, in a system such as represented in Figure 1. The structured file will be described later.
[0052] The sender and receiver are the first and second entities and are typically two companies (but could be public bodies, government agencies, patent or trademark offices, individuals, etc.), with the sender initiating the transaction and the receiver being the recipient. It should be noted that in practice, a larger number of entities may be involved, with varying roles.
[0053] Preferably, the transaction relates to a task (i.e., a service) required of one of the sending and receiving entities by the other. This task may be future or already completed. Even more preferably, the task is an intellectual service, particularly a legal one, and in particular an intellectual property service. However, this scope will not be limited, and any service may advantageously be the subject of a transaction in accordance with this process. The mere exchange of information between the entities may also be considered a task.
[0054] In most transactions, the sender requires the receiver to perform the task, i.e. the sender is a requester (in other words the client) and the receiver a service provider, but it is entirely possible that the said transaction is subsequent to the completion of the task and therefore does not in itself require any future task (for example the transaction may be the transmission of a final report or an invoice, or even a simple acknowledgment of receipt).
[0055] Furthermore, this process primarily concerns a transaction "defined by a form comprising multiple fields," meaning it is not, for example, a simple database operation but rather a transaction binding both entities. This form advantageously represents a document, referred to as a formal document (or even is said document), that is, an "official" document from the first entity, such as an accounting document, a letter of instruction, a report, etc. It is understood that an email remains such a formal document because it binds its sender. To rephrase further, there will generally be a form whose fields describe the required task, and often a formal document representing this form in an official and formatted manner, so that the eventual formal document also describes the task but in a more formalized way.Note that later in the description, we will mention other documents called "annexes," which are separate from the formal document. These documents do not define the task but are necessary for its implementation. In all cases, the form represents (i.e., describes) the task to which the transaction relates, and it is understood that the formal document could be generated from this form.
[0056] As such, the form is in natural language (and not a simple computer instruction).
[0057] Furthermore, "transaction" will be understood here in a broad sense, and will not only refer to a financial transaction, but to any transaction that may involve the sender and the receiver and that may, where appropriate, be described by a form (from which a formal document can advantageously be generated), and in particular:
[0058] - a request for a quote
[0059] - the provision of the quote
[0060] - a request to implement a task
[0061] - the transmission of official documents
[0062] - an acknowledgement of receipt
[0063] - a report
[0064] - an invoice
[0065] - etc.
[0066] The present process, as we will see, is entirely flexible and not limited to a predetermined list of transactions. We can even imagine "hybrid" transactions; for example, a final report including an invoice. We will focus, as a preferred example, on the field of intellectual property, with the following transaction examples described later:
[0067] - invoicing
[0068] - report of response to a notification
[0069] - instruction to enter the national phase of a PCT application
[0070] In all cases, with reference to Figure 1, there is at least one second client device 20 of the second entity for the implementation of the process, and advantageously at least one first client device 10 of the first entity and / or a server 1, 2, 3, connected via a network 30 such as the internet.
[0071] You can have up to three servers:
[0072] - a first server 1 of the first entity (sender)
[0073] - a second server 2 of the second entity (receiver)
[0074] - a third server 3 from a trusted third party.
[0075] Typically, server 1, 2 is a corporate server and client devices 10, 20 are employee workstations (PCs with an interface). Potentially, all client devices 10, 20 of an entity and their corresponding server 1, 2 are connected within a local network 30.1, 30.2 (possibly via VPN), with server 1, 2 potentially acting as a gateway to the wide area network 30. Furthermore, it is entirely possible that the first server 1 is the same as the first client device 10 and / or that the second server 2 is the same as the second client device 20.
[0076] All connections are preferentially encrypted and secured (user authentication on their client device 10, 20).
[0077] Each server / device 1, 2, 3 has, where applicable, data processing means (typically a processor), denoted 11, 21, 31 respectively for the first client device 10, the second client device 20 and the third server 3, and data storage means (memory, for example flash), denoted 12, 22, 32 respectively for the first server 1, the second server 2 and the third server 3. Preferably, the first server 1 of the first entity and / or the second server 2 of the second entity implements a data management system of the first / second entity, i.e. internal software of the entity controlling a business database stored on the storage means 12, 22 of the server 1, 2. In the preferred embodiment in the field of intellectual property (IP), said data management system is software called IPMS (IP management system).It could also be an e-billing system or even an accounting system. In any case, the data management system can be off-the-shelf, and the two entities can have different systems.
[0078] Automated transaction processing means the implementation by the second client device 20 of the receiving entity, without human intervention, of at least one expected computer action, parameterized by the data contained in said structured file, aimed at automating the task in a certain way.
[0079] This action may be all or part of the task itself, if it is simple and required by the first entity from the second entity (for example, a request for information), but it may also be any action related to the task, including:
[0080] - electronic payment of an invoice;
[0081] - the issuance of an acknowledgement of receipt;
[0082] - the request for human intervention;
[0083] - the automatic generation of a document (for example, a letter template)
[0084] - an automatic modification of the data of said a data management system of the second entity (i.e. in said business database stored on the storage means 22 of server 2);
[0085] - Etc.
[0086] Structured File: In a known manner, the present process takes as input a structured file representing the said transaction whose automated processing is required, as explained, generally containing the data from a form from which this structured file can be generated, in particular in accordance with application FR 24 / 09534. This advantageously allows a universal structured file, adaptable in an agnostic way to any type of transaction of interest to a person skilled in the art.
[0087] The structured file is in a predefined markup language, for example JavaScript Object Notation (JSON), which is a textual data format derived from the object notation of the JavaScript language, but other languages can be used, for example based on XML, HTML, CSV, etc.
[0088] The said structured file representing a transaction consists of one or more elementary objects of a category chosen from a finite list of categories of objects describing an aspect of the task, called the first list, i.e. each category is linked to an aspect of the task.
[0089] The first list is chosen to allow for a comprehensive description of every task; it is defined once and for all. Preferably, it consists of the following five categories:
[0090] - The descriptive object of a party involved in the said task (or stakeholder), which we will refer to as "party" for convenience. This party is, in practice, a distinct entity from the first and second entities, and in particular, either a natural person or a legal person (the descriptive object of a party may thus be of two different types). For example, in the case of an intellectual property transaction, the party involved in the said task may be an applicant, a patent holder, an inventor, a licensee, an alleged infringer, an opponent, an agent, a patent office, etc. - The descriptive object of an asset involved in the said task, which we will refer to as "asset" for convenience, including a title or other legal object. For example, in the case of an intellectual property transaction, the asset involved in the said task may be a contract, a disclosure of invention, a patent application, a patent, a trademark, a design, etc.
[0091] - A descriptive object of an event associated with the task, which we will refer to as "event" for convenience, in particular a past or future (expected) event during the completion of the task. The event is generally past if the task has already taken place and expected if the task is yet to be done, and typically constitutes a deadline. In all cases, the event is generally defined by a date. For example, in the case of an intellectual property transaction, the event could be a priority date, a filing date, a publication date, a delivery date, an official deadline, an internal deadline, etc.
[0092] - Descriptive object of an accounting aspect of said task, in other words, any financial data, which we will designate "account" for convenience, generally a quote, a provision, an invoice or an order;
[0093] - A descriptive object of a document associated with said task, i.e., an attachment, which may contain any document or a link to that document (if, for example, it is hosted online), an object of this type being itself a container. The attached document is, in particular, the formal document that defines the transaction. Alternatively or in addition, it may be any other "supplementary" document necessary for the transaction; for example, in the case of an intellectual property transaction, the attachment may be the text and / or drawings of an application / patent, an official letter (notification), a letter of instructions, etc. "Constituted" means that there are no other elementary categories besides those in the aforementioned finite list.
[0094] To rephrase, the structured file preferably contains only elementary objects from a category chosen from:
[0095] - Descriptive object of a part involved in said task
[0096] - Descriptive object of an asset involved in said task
[0097] - Descriptive object of an event associated with the task
[0098] - Descriptive object of an accounting aspect of said task
[0099] - Descriptive object of a document associated with said task.
[0100] We assume here that the file contains at least one minimal object of the descriptive object category for an event associated with the task (event object), including an original "action code" field, as shown in Figure 2a. This action code is itself chosen from a finite list of possible action codes, each defining a type of action expected in the automated processing of the transaction, referred to as the second list. It is understood that this type of action is a technical code independent of the task, i.e., a procedural code and not a business logic code. As will be explained later, we could have a long second list of possible action codes, but in a particularly clever implementation of the present method, which will be described later, a very short second list (only 6 to 10 different codes) is practically sufficient for all the automated processing one might desire.Again, this is due to the fact that action codes are procedural technical codes, which generally apply to all tasks.
[0101] Advantageously, the second list is thus comprised of the following action codes:
[0102] - At least one code defining an expected action of the information provision type (preferably exactly one, or two with a possible "missing data" error code)
[0103] - At least one code defining an expected action of the information reception type (preferably exactly one, or two with a code for transmitting the missing data in response to the error code above)
[0104] - At least one code defining an expected execution-type action (preferably exactly one)
[0105] - At least one code defining an expected action of the confirmation type (preferably exactly one)
[0106] - At least one code defining an expected action of the handling type (preferably exactly one, or two with a possible error code "refusal" and / or "cancellation")
[0107] - Code defining an expected action of the verification type (potentially two, with the result of the verification).
[0108] Note that the action code is selected by the issuing entity and preferably action codes are expressed according to their point of view:
[0109] - The code defining an expected action of the information provision type is typically a code designated "question," indeed this code is applied when the sending entity has a request for information, and therefore wants a response providing the requested information (and any missing data, if applicable); - The code defining an expected action of the information reception type is typically a code designated "transmission," indeed this code is applied when the sending entity transmits a notification of any kind (or missing information), and therefore wants to be aware of it;
[0110] - The code defining an expected action of the execution type is typically a code designated "decision", indeed this code is applied when the issuing entity sends instructions, and therefore wants these instructions to be executed;
[0111] - The code defining an expected action of the confirmation type is typically a code designated "report", indeed this code is applied when the issuing entity makes a report, and therefore wants to be confirmed that everything is ok; - The code defining an expected action of the handling type is typically a code designated "acknowledgment of receipt", more in substance than in form.Indeed, this code is applied when the issuing entity issues an instruction, and therefore wants the receiving entity to update its workflow accordingly, for example by modifying the status, creating a new file, or even closing the file, and for the receiving entity, although not yet having to respond, to confirm that it has the elements to do so (or on the contrary the possible cancellation / refusal code); - The code(s) defining an expected action of the verification type are typically a code designated "data conformity" in English DCC for data conformity check, indeed this code is applied when the issuing entity wants, in a more technical way, to verify that data conforms to an expected content or format and to respond with another code (by a boolean or by a value different from the one verified by the sender).For example, we can have the following exhaustive list of 10 action codes:
[0112] A0100 | Request For Information (Supply Action)
[0113] A0200 | Transmission (Receiving Action)
[0114] A0300 | Instruction (Execution Action)
[0115] A0400 | Instruction Reception (Action taken)
[0116] A0500 | Postponement (Confirmation action)
[0117] A0600 | Missing Details Request (Supply Action)
[0118] A0700 | Missing Details Transmission (Action reception)
[0119] A1100 | Data Conformity Check Request (Verification Action) A1200 | Data Conformity Check Response (Verification Action) A2000 | Instruction Refusal or Cancellation (Supported Action) We preferentially have a single action code field per event object, but we can have several event objects each with their own action code (as in Figure 2b or 2c).
[0120] Preferably, the event object(s) also include an "event code" field, chosen from a plurality of event codes in another finite list, called the third list. This event code is known and identifies the event in question; that is, it is linked to the task. It is completely independent of the action code.
[0121] Note that the event code can be called a task code, as in English this code is designated as a task code, but we prefer the term "event code" to avoid any confusion with the task itself, which is represented by the transaction. Indeed, those skilled in the art will understand that this code uniquely defines only the event (and therefore a "step" in the task's execution) and not the entire task represented by the transaction. A task can also be represented by a structured file containing multiple event objects and therefore multiple event codes. For example, the same transaction might involve recording or even transmitting an activity report (the first event of the task associated with the transaction, triggered upon receipt) and paying an invoice (the second event of the task associated with the transaction, triggered upon receipt).
[0122] Preferably, each event object in said structured file includes exactly one action code and one event code.
[0123] Preferably, each category of object is defined by a predefined set of object fields, and even more preferably, each elementary object is itself composed of so-called "card" blocks defining subsets of said predefined set of object fields, and of links between fields of the blocks, possibly in a hierarchical manner.
[0124] In particular, according to the figures, the said action code of the minimal event object is for example in an event detail block and / or the event code is in a deadline block also including a date by which the event must have been accomplished if it is a future event.
[0125] According to an alternative embodiment, the reverse can be provided with said action code of the minimal event object which is in the deadline block and / or the event code in the event detail block, possibly associated with a country code (jurisdiction) or any other descriptive parameter of the asset (for example, a patent or a trademark) for which a task must be performed.
[0126] Each field of each object is preferably standardized, with the possible exception of the action code field, which is an original element. To rephrase, we have a list of fields defined by one or more standards, for example ISO-8601 for dates, ISO-639-1 for languages, ISO3166-1 for countries, ISO-4217 for currencies, etc.
[0127] Note that some fields can be open, i.e. accept any value (according to an expected format - number, text, date, etc.) or be closed, i.e. accept only a list of possible values (for example the legal form of a legal entity).
[0128] Preferably, the set of predefined sets of object fields with the exception of the action code (which includes the task code) is defined in a common standard, for example the AFNOR NF X50-276 standard for intellectual property transactions.
[0129] For example, event code T20100 in Figure 2a designates a payment step; that is, the transaction is typically an invoice following the completion of a task. In Figure 2b, the second event object has event code T03500, which designates a notification processing step ("Office Action"). In Figure 2c, we have the codes T02100 for filing a request, T03100 for a request under review, and T05100 for taking charge of annuities.
[0130] In the preferred embodiment in which the task is an intellectual service, particularly a legal one, and in particular an intellectual property service, the following third list may be used as an example.
[0131] - T01100 | Pre-Application | Review, Strategy, Draft (incl. Revisions) - T01200 | Pre-Application | Preparation, Formalities
[0132] - T02100 | Application | Filing
[0133] - T02200 | Application | Correction, Restriction, Regul.
[0134] - T02300 | Application | Publication, Disclosure
[0135] - T02400 | Application | Provisional Protection
[0136] - T02500 | Application | Search
[0137] - T02600 | Application | Entry into Nat. or Reg. Phase
[0138] - T02700 | Application | Voluntary Amend., Limitation
[0139] - T03100 | Examination | Exam. Request (incl. PPH)
[0140] - T03200 | Examination | Acceleration
[0141] - T03400 | Examination | Prior Art (incl. IDS)
[0142] - T03500 | Examination | Office Action (incl. RCE)
[0143] - T03600 | Examination | Oral Proceedings
[0144] - T03700 | Examination | Further Processing
[0145] - T03710 | Examination | Extension of Time
[0146] - T03900 | Examination | Third-Party Observation
[0147] - T04100 | Allowance | Grant / Registration
[0148] - T04110 | Allowance | Patent Term Adjustment (PTA)
[0149] - T04200 | Allowance | Validation
[0150] - T04300 | Allowance | Grant / Registr. Publication
[0151] - T04400 | Allowance | Official Doc. Transmission
[0152] - T05100 | Maintenance | Annuity or Renewal
[0153] - T05200 | Maintenance | Decl. of Use, Working Stat.
[0154] - T06100 | Termination | Abandonment
[0155] - T06200 | Termination | Withdrawal
[0156] - T06300 | Termination | Loss of Rights
[0157] - T07100 | PTO Procedure | Inter Partes- T07110 | PTO Procedure | Inter Partes | Appeal
[0158] - T07200 | PTO Procedure | Ex Parte
[0159] - T07210 | PTO Procedure | Ex Parte | Appeal
[0160] - T07220 | PTO Procedure | Restoration
[0161] - T10050 | Dispute | Jurisdiction
[0162] - T10100 | Dispute | First Instance Litigation
[0163] - T10200 | Dispute | Second Instance Litigation
[0164] - T10300 | Dispute | Supreme Instance Litigation
[0165] - T11100 | Dispute | Formal Notice
[0166] - T11200 | Dispute | Amicable Settlement
[0167] - T11300 | Dispute | Collection of Evidence
[0168] - T11300 | Dispute | Customs
[0169] - T12100 | Legal Analysis | Watch & Monitoring
[0170] - T12200 | Legal Analysis | Search & Intelligence
[0171] - T12300 | Legal Analysis | Legal Opinion & Advice
[0172] - T13100 | Deed | Review, Strategy, Draft (incl. Revisions)
[0173] - T13200 | Recordal | Transfer of Rights or Merger
[0174] - T13210 | Recordal | Change (Name, Address, Inventor, Legal Status)
[0175] - T13220 | Record | Correction (Name, Address, Inventor)
[0176] - T13230 | Recordal | License
[0177] - T13240 | Record | Security Interest
[0178] - T13300 | Deed | Authentication (incl. Legalization)
[0179] - T14100 | Portfolio | Representative Appointment
[0180] - T14200 | Portfolio | Termination of Mandate
[0181] - T14300 | Portfolio | Status
[0182] - T14350 | Portfolio | Monitoring (Register or IP Right)
[0183] - T14400 | Portfolio | Valuation
[0184] - T14500 | Portfolio | Other
[0185] - T20100 | Accounting | Payment It is important to remember that action and event should not be confused: the action code is completely independent of the task (procedural technical code - which can be applied to all tasks), while the event code is linked to the task (business code).
[0186] A naive way to solve the problem would be to try to determine the expected actions based on event codes, but this is practically impossible because these codes certainly provide information on at least one step of the task but prove to be ambiguous.
[0187] For example, the event code T03500 mentioned earlier, which designates a notification processing step ("Office Action"), is used by a sending entity both during the initial transmission of the notification and during the transmission of the response report to that notification. The receiving entity therefore cannot automatically and reliably process a transaction defined by a structured file containing such a T03500 code.
[0188] - One possibility would be to observe the context, for example, the presence of a T20100 code indicating invoicing and therefore suggesting the transmission of a report. However, such an approach requires interpretation and thus involves risk. Furthermore, it's important to remember that the structured file is entirely universal, and new hybrid transactions that are difficult to understand may always arise. Alternatively, external data included in the message but not in the structured file can be used, but this necessitates adjustments on the part of the receiving entity.
[0189] - otherwise human intervention would be required in case of ambiguity, but total automation is not an option.
[0190] Action codes cleverly solve the problem.
[0191] Automated Transaction Processing Method With reference to Figure 3, which represents a preferred embodiment, the present process begins with a step (a) of obtaining at the level of the second client device 20 the second receiving entity of said structured file.
[0192] As explained, preferably the said structured file is generated from the contents of the fields of a form defining the said task, obtained at the level of the first client device 10 of the issuing entity, step (a) preferably comprising making available a message containing the said structured file to the said second client device 20, by at least one server 1, 2, 3.
[0193] The process may therefore include a preliminary step (aO) of generation by said at least one server 1, 2, 3 of said structured file including the transcription of said contents of the field(s) of said form into the object fields of said structured file.
[0194] The person skilled in the art can again consult request FR 24 / 09534 for full details on the generation of said structured file.
[0195] Next, the process includes a step (b) of extracting data from the fields of said structured file, including said action code and, where applicable, said event code of the event object(s).
[0196] This step can be triggered by message retrieval, or manually by the user.
[0197] This step (b) can be performed in many different ways, depending on the level of instrumentation of the second entity and the type of transaction. Preferably, when there is a second server 2 of the second entity implementing a data management system of the second entity, step (d) includes the automatic import of said field data into said data management system of the second entity (i.e., their storage in said business database stored on the storage means 22 of server 2). Finally, the process includes a step (c) of implementing at least one expected action, i.e., automated transaction processing, determined according to said extracted action code, on the other extracted data.
[0198] To rephrase, we use the action code to determine the action to be performed and we implement this action on the other data extracted from the message.
[0199] Step (c) may, where appropriate, include the generation by the second client device 20 of computer instructions defining the action(s) expected for the server 2, if it is the server that will in practice carry out all or part of these actions.
[0200] Preferably, an action code is extracted for each descriptive object of an event associated with the task. Step (c) comprises, for each descriptive object of an event associated with the task, the determination of the expected action and the implementation of said determined expected action. In other words, if there are multiple event objects, a complex action is automatically determined as a combination of expected actions to be implemented. This allows for the automatic processing of any transaction represented by any structured file, however complex it may be.
[0201] Preferably, the expected action is entirely defined by the combination of the action code and the event code; that is, the expected action for an event object is solely a function of said action and event codes. Thus, for each event object, the action and event codes are combined in such a way as to uniquely and definitively determine the expected action. With the second and third lists remaining small, we directly have a very large number of manageable distinct actions—in this case, already more than 300 different actions with the example lists presented above, which could be further expanded in the future. Moreover, since there are as many action code / event code pairs in a transaction as there are event objects, even assuming up to 3 event objects, we already have more than 30 million possible complex actions.It's worth noting that this is possible because the action code (which represents a type of action) and the event code (which represents a step in the task) are independent. Therefore, the combination of an action code and an event code clearly defines the type and context of the action. And since the action code remains integrated into the structured file, it doesn't require any adaptation on the part of the receiving entity. This solution remains compatible with receiving entities that operate manually without any automation (they would simply ignore the action codes).
[0202] As for the practical implementation, the simplest way is to have, as explained, a template for each action code and each event code, because then the number of templates needed is only the sum of the number of elements in the second and third lists (just about sixty in the previous example), and to reconstruct a template of the combination from the two templates (examples will be given later).
[0203] Alternatively, or in addition, templates can be pre-generated for standard combinations to allow for instant processing, or even for all possible combinations (300 in this example). This is a reasonable approach that still allows for the processing of millions of different hybrid transactions. It's clear that the nature of the processing and its degree of automation remain customizable; each receiving entity is free to choose and apply the templates it prefers. Again, this solution is completely universal and modular.
[0204] Example 1 - Invoice Transmission
[0205] With reference to figure 2a, said transaction may be a dry billing, within the framework of any task.
[0206] Here we have only one event object (we may have other objects from other categories which are not represented, such as an accounting aspect object and, where applicable, a document object with the invoice itself), with the action code execution (decision) and the event code T02100 payment.
[0207] Indeed, the issuing entity is simply demanding payment of an invoice.
[0208] We can have a generic execution template, which includes, for example, a transfer module, and a payment template that selects the important accounting information from the extracted fields: the amount, the currency, and the account to be credited. The template generated by this combination is, for example, a template that will construct a transfer of the expected amount in the expected currency to the expected account.
[0209] According to a preferred implementation method, a payment authorization will be requested, and therefore a workflow will be prepared in which:
[0210] - the invoice is displayed to a manager
[0211] - He is asked to confirm or not the payment in an interface - if he confirms, the automatic transfer is initiated.
[0212] Example 2 - Report
[0213] With reference to Figure 2b, said transaction may be the transmission of a response report to a notification including the invoice, as part of a task to respond to said notification.
[0214] Here we have two event objects (we may have other objects from other categories which are not represented, such as for example an active object relating to the patent application under examination, and two document objects with the invoice and the filed response).
[0215] We again have the combination of action code execution (decision) and event code T02100 payment for the billing part, plus the combination of action code confirmation (report) and event code T03500 for the notification part.
[0216] In this latter case, the receiving entity is specifically asked to acknowledge that the task has been completed and to confirm this to the sending entity. The confirmation action code is typically associated with a template for generating an acknowledgment and verifying certain data, such as the existence of the response itself or a date (for example, ensuring that the response date was within the deadline). Additionally, a notification template can be used to select information detailing this response and its notification from extracted fields: notification date, response date, folder, office, etc.
[0217] The template generated for the combination is, for example, a template that checks the response and automatically generates a report if everything matches.
[0218] This can be linked to the invoice payment in the complex action, and a workflow can therefore be prepared in which:
[0219] - the report is formally verified
[0220] - the invoice is displayed to a manager
[0221] - he is asked to read the report (i
[0222] to perform a substantive check (insofar as the formal check has been completed), and then to confirm or reject the payment in an interface
[0223] - If he confirms, the automatic transfer is initiated.
[0224] Example 3 - Entry into the national or regional phase of an international patent application under the PCT
[0225] With reference to figure 2c, the said transaction may be the filing of an application, including a request for review and assumption of annuities, as part of a national phase entry (in this case German - it is therefore assumed that the receiving entity is a German agent).
[0226] This time we have 3 event objects, and generally many other objects of other categories which are not represented, such as an active object relating to the PCT, a party object relating to the applicant, another party object relating to the inventor, an accounting object containing the details of a quote, and a document object with the text of the application.
[0227] In the three event objects we have:
[0228] - a first combination of an execution action code (decision) and the T02100 filing event code for the filing part of the application,
[0229] - a second combination of an execution (decision) action code and the T03100 review event code for the review request,
[0230] - a third combination of an execution action code (decision) and the T05100 annuity event code for the annuity support portion.
[0231] The receiving entity is asked in detail to make the filing before the German office by acting as agent, while requesting the examination and ensuring the payment of the annuities.
[0232] The action execution code is typically associated with a template that allows for the automatic generation of forms, particularly requests for issuing / exams. Additional options include:
[0233] - Filing and examination templates that select information relating to the national phase and its examination from extracted fields: PCT number, filing date, country, etc.;
[0234] - an annuity template that selects the information to identify the payment dates of the annuities and who to bill from the extracted fields: filing date, accounting information, etc.
[0235] The template generated for the combination is, for example, a template that automatically generates the issuance request based on the extracted fields with review required at the filing, and that generates payment deadlines for the annuities.
[0236] We can therefore prepare a workflow in which:
[0237] - The issuance request is prepared - all the documents for the application are presented to a manager (text, figure, tax slip, issuance request, etc.) - they are asked to validate them
[0238] - if he confirms, the documents are uploaded to a DPMA portal - annuity payment deadlines are created for automatic payment.
[0239] Client and server devices
[0240] According to a second aspect, the invention relates to the system comprising the second client device 20 of the receiving entity for implementing the method according to the first aspect
[0241] It can be connected with the first client device 10 of the issuing entity and / or the server(s) 1, 2, 3, via a communication network 30.
[0242] Preferably, the first server 1 of the sending entity implements a data management system of the sending entity and / or the second server 2 of the receiving entity implements a data management system of the receiving entity.
[0243] The second client device 20 is configured to automatically process a transaction between the sending and receiving entities, relating to a task required by one entity from the other, by implementing steps consisting of:
[0244] - Obtain a structured file representative of said transaction, said structured file being made up of one or more elementary objects of a category chosen from a finite list of categories of objects describing an aspect of the task, called first list, of which at least one object describing an event associated with the task including an action code chosen from a finite list of possible action codes each defining a type of action expected in an automated processing of said transaction, called second list; - Extract data from the fields of said structured file, including said action code;
[0245] - Implement at least one expected action determined according to said extracted action code, on or from the other extracted data.
[0246] computer program product
[0247] According to a third and a fourth aspect, the invention relates to a computer program product comprising code instructions for the execution (on at least the second client device 20) of a method according to the first (or second) aspect for the automated processing of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other; as well as computer-readable storage means (for example, a memory of the second client device 20) on which this computer program product is located.
Claims
29 DEMANDS 1. A method for the automated processing of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities from the other, characterized in that it comprises the implementation, by a client device (20) of the receiving entity, of the following steps: (a) Obtaining a structured file representing the transaction, said structured file consisting of one or more elementary objects of a category chosen from a finite list of categories of objects describing an aspect of the task, referred to as the first list, including at least one object describing an event associated with the task comprising an action code chosen from a finite list of possible action codes, each defining a type of action expected in the automated processing of said transaction, referred to as the second list, said action code being a technical code independent of the task; (b) Extracting the data from the fields of said structured file, including said action code; (c) Implementation of at least one expected action determined according to said extracted action code, on the other extracted data.
2. Method according to claim 1, wherein said structured file is generated from contents of fields of a form defining said task, obtained at the level of a first client device (10) of the sending entity, said client device (20) of the receiving entity being a second client device, step (a) comprising making said message available to said second client device (20), by at least one server (1, 2, 3) connected to said first and second client devices (10, 20) by a communication network (30).
3. A method according to claim 2, comprising a preliminary step (aO) of generating said file by said at least one server (1, 2, 3) structured including the transcription of said contents of the field(s) of said form into the object fields of said structured file.
4. A method according to any one of claims 1 to 3, wherein each category of object in said first finite list is defined by a predefined set of object fields, each elementary object itself being composed of blocks defining subsets of said predefined set of object fields, and of links between fields of the blocks.
5. A method according to any one of claims 1 to 4, wherein the object categories of said first list are: - Descriptive object of a part involved in said task; - Descriptive object of an asset involved in said task; - Descriptive object of an event associated with the task; - Descriptive object of an accounting aspect of said task; - Descriptive object of a document associated with said task.
6. A method according to any one of claims 1 to 5, wherein the possible action codes from said second list are: - Code defining an expected action of the type providing information; - Code defining an expected action of the information reception type; - Code defining an expected action of the execution type; - Code defining an expected action of the confirmation type; - Code defining an expected action of the "taking charge" type; - Code defining an expected action of the verification type.
7. A method according to any one of claims 1 to 6, wherein said descriptive object of an event associated with the task also includes a code of the event chosen from a finite list of possible event codes, said third list, said event code being independent of said action code, step (b) also comprising the extraction of said event code.
8. Method according to claim 7, wherein said expected action implemented in step (c) is entirely defined by the combination of the action code and the event code.
9. A method according to any one of claims 1 to 8, wherein an action code is extracted for each descriptive object of an event associated with the task, step (c) comprising, for each descriptive object of an event associated with the task, the determination of the expected action and the implementation of said determined expected action.
10. A method according to any one of claims 1 to 9, wherein a second server (2) of the receiving entity implements a data management system of the receiving entity, step (b) comprising the automatic export of data from the fields of said structured file to said data management system of the receiving entity.
11. Client device (20) of a receiving entity, characterized in that it is configured to: - Obtain a structured file representing a transaction between a sending entity and said receiving entity, relating to a task required by one of the entities from the other, said structured file being made up of one or more elementary objects of a category chosen from a finite list of categories of objects describing an aspect of the task, said first list, of which at least one descriptive object of an event associated with the task including an action code chosen from a finite list of possible action codes each defining a type of action expected in an automated processing of said transaction, said second list, said action code being a technical code independent of the task; - Extract data from the fields of said structured file, including said action code; - Implement at least one expected action determined according to said extracted action code, on the other extracted data.
12. Product computer program comprising code instructions for the execution of a process according to any one of claims 1 to 10 for the automated processing of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other, when said program is executed on a computer.
13. Computer-readable storage means on which is recorded a computer program product comprising code instructions for the execution of a process according to any one of claims 1 to 10 for the automated processing of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other.