A method for implementing a transaction, defined by a form comprising at least one field.

Abstract

The present invention relates to a method for implementing a transaction between a sending entity and a receiving entity, defined by a form comprising a plurality of fields, including: Obtaining the contents of the fields of said form; Generating a structured file representing the transaction containing said data from the fields of said form, consisting of elementary objects of categories each defined by a predefined set of standardized object fields, each elementary object being composed of blocks defining subsets of said predefined set of object fields, and links between fields of the blocks; said generation 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; Making available a message encapsulating said structured file;Extraction and processing of data from the fields of said structured file, in order to implement said transaction. Fig. 1;

Description

Title of the invention: Method for implementing a transaction, defined by a form comprising at least one field.

[0001] GENERAL TECHNICAL FIELD

[0002] The present invention relates to the field of computerized data exchange. More specifically, it concerns a method for implementing a transaction between a sending entity and a receiving entity, defined by a form comprising at least one field.

[0003] STATE OF THE ART

[0004] Invoices, and in general documents exchanged between companies (letters of order, quotes, mandates, orders, etc.) have now been massively dematerialized.

[0005] While this has made it possible to significantly reduce the cost and environmental impact of their emission compared to paper, it is noted that dematerialization practices are still highly heterogeneous and that their processing remains long and tedious.

[0006] For example, the classic process for processing an electronic invoice is as follows • generation of the invoice in PDF format by the service provider (using their data management system) • Sending the invoice to the customer by email • receiving and manually entering invoice information into a customer-specific data management system for payment.

[0007] Manual entry is tedious and sometimes outsourced.

[0008] Solutions exist that aim to avoid this manual data entry, notably through OCR of the PDF or by integrating a QR code onto the invoice to be scanned. However, this implies the development of additional modules or versions, multiplied by the number of service providers, and this solution is sometimes prone to errors due to the "optical" phase.

[0009] Alternatively, electronic data interchange (EDI) techniques have been proposed, in which a structured data stream is transmitted alternatively or in addition to the document, for example the invoice in PDF format, for automated processing.

[0010] These techniques are satisfactory but require either that the data management systems of the two entities involved be the same or compatible, or that the data in the documents should be structured in a standardized way, particularly to meet regulatory requirements.

[0011] This solution is satisfactory but proves to be inflexible and inflexible, as the data must be communicated exactly according to models or templates to be accepted. Multiple templates can be created, one for each of the entities involved, but this is laborious.

[0012] The present invention improves the situation. PRESENTATION OF THE INVENTION

[0013] The present invention therefore relates, in a first aspect, to a method for implementing a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities from the other, defined by a form comprising a plurality of fields, characterized in that it comprises the implementation of the following steps:

[0014] (a) Obtaining at the level of a first customer device of the issuing entity contents of the fields in said form;

[0015] (b) Generation of a structured file representing the transaction containing said data from the fields of said form, 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;

[0016] each object category of said finite list being defined by a predefined set of object fields, such that each field of each object category is standardized, 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;

[0017] said generation 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;

[0018] (c) Making available to a second customer device of the receiving entity of a message encapsulating said structured file, by at least one server connected to said first and second client devices by a communication network;

[0019] (d) Extraction and processing by said second client device of the data from fields of said structured file, so as to implement said transaction.

[0020] According to advantageous and non-limiting features:

[0021] The object categories of said finite 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.

[0022] Each object in the category descriptive object of a part defines an entity distinct from the sending and receiving entities and includes a natural person block or a legal person block depending on the nature of said distinct entity.

[0023] Each object in the descriptive object category of an event includes a past event block or an expected event block during the completion of the task.

[0024] Step (a) includes the generation of a document defining said task, said structured file including at least one object of the descriptive object category of a document containing said document or a link to said document.

[0025] Said message includes a header and the structured file as the message body.

[0026] Said message consists of the header, said body, and an activity log tracing a history of actions in the creation and implementation of the transaction.

[0027] Step (a) also includes the designation of the receiving entity.

[0028] Step (b) further includes the generation of said header before said structured file depending on the designation of the receiving entity.

[0029] Step (d) includes retrieving said message by the second client device from said server, preferably following a request issued by said second client device.

[0030] A first server of the issuing entity implements a data management system of the issuing entity.

[0031] Step (a) includes the automatic import of contents of the fields of said form from said data management system of the issuing entity.

[0032] A second server of the receiving entity implements a data management system of the receiving entity.

[0033] Step (a) includes the automatic export of data from the fields of said structured file to said data management system of the receiving entity.

[0034] Step (a) includes the prior identification of one or more elementary objects and one or more blocks composing said identified elementary objects, necessary for the definition of the transaction, in particular by choosing a form template, and obtaining the contents of all the fields necessary to construct said elementary objects and the identified blocks.

[0035] The elementary object(s) and the block(s) composing said elementary objects, necessary for the definition of the transaction, are pre-selected by the receiving entity.

[0036] According to a second aspect, the invention relates to a method for implementing a sequence of transactions between at least a first entity and a second entity, relating to a task required by one of the first and second entities, with on the other hand, including the execution, for each transaction of said sequence, of the process according to the first aspect for the implementation of said transaction, such that the set of messages made available at each step (c) forms a conversation.

[0037] According to a third aspect, the invention relates to a system comprising at least a first client device of a sending entity, a second client device of a receiving entity and at least one server, connected by a communication network, characterized in that they are configured to, in order to implement a transaction between the sending entity and the receiving entity, relating to a task required by one of the entities, from the other, defined by a form comprising a plurality of fields: • Obtain the contents of the fields of said form at the level of the first client device; • generate a structured file representing the transaction containing the data from the fields of said form, 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:

[0038] each object category of said finite list being defined by a predefined set of object fields, such that each field of each object category is standardized, 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, said generation 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. • make available to the second client device a message encapsulating said structured file; • Extract and process, by said second client device (20), the data from the fields of said structured file, so as to implement said transaction.

[0039] According to a fourth and a fifth aspect, the invention provides a computer program product comprising code instructions for executing a process according to the first aspect for implementing a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities from the other, defined by a form comprising a plurality of fields; and a computer-readable storage means on which is stored a computer program product comprising code instructions for executing a process according to the first aspect for implementing a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other, defined by a form comprising a plurality of fields. PRESENTATION OF THE FIGURES

[0040] 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:

[0041] [Fig. 1] [Fig. 1] is a diagram of a system for implementing the method according to the invention;

[0042] [Fig.2] [Fig.2] is a flowchart illustrating the steps of an embodiment of the method according to the invention;

[0043] [Fig.3a] [Fig.3a] illustrates a first example of implementation of the process according to the invention;

[0044] [Fig. 3b] [Fig. 3b] illustrates a second example of implementation of the process according to the invention;

[0045] [Fig.3c] [Fig.3c] illustrates a third example of implementation of the process according to the invention;

[0046] [Fig.3d] [Fig.3d] illustrates a fourth example of implementation of the process according to the invention;

[0047] [Fig. 3e] [Fig. 3e] illustrates a fifth example of implementation of the process according to the invention. DETAILED DESCRIPTION

[0048] Architecture

[0049] The present invention relates to a method for implementing a transaction between an sending entity (which will be called simply "sender") and a receiving entity (which will be called simply "receiver"), defined by a form comprising a plurality of fields, in a system as represented in [Fig. 1].

[0050] The sender and receiver are first and second entities and are typically two companies (but could be public bodies, government agencies, patent or trademark offices, individuals, etc.), the sender being the entity initiating the transaction and the receiver being the entity receiving it. It should be noted that in practice, a larger number of entities may be involved, with varying roles (see below for examples with third and fourth entities).

[0051] Preferably, the transaction relates to a task (i.e., a service) required of one of the sending and receiving entities by the other. The task may be future or already completed. Even more preferably, the task is an intellectual service, particularly a legal one, and in particular a service of ownership. intellectual. However, we will not be limited to this area, and any service may advantageously be the subject of a transaction in accordance with this process. The mere provision of information between entities may also be considered a task.

[0052] In most transactions, the sender requires the receiver to perform the task, i.e. the sender is a requester (in other words the customer) and the receiver a service provider, but it is quite 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).

[0053] It should be noted that in a preferred mode, which will be described later, there can be a sequence of transactions between two entities, which may, if necessary, take turns acting as sender and receiver. For example, there may be a first transaction in which a first entity A orders a service from an entity B defined by a first document (letter of instruction), and a second transaction in which B transmits a report of said service to A after having performed it (this report being the second document). It is understood that: • in the first transaction, the first entity A has the role of sender and the second entity B has the role of receiver; • in the second transaction, the second entity B has the role of sender and the first entity A has the role of receiver.

[0054] Note that even in a sequence of transactions it is possible to have two consecutive transactions in the same direction (for example, suppose a letter of instruction involving two actions of the second entity, followed by two reports for the two tasks).

[0055] Furthermore, a sequence of transactions may involve more than two entities, these entities taking turns acting as sender / receiver. For example, after the first transaction, the second entity B may order a new service (subcontracting) from a third entity C defined by a second form (letter of instruction - for example, if the initial service concerns a foreign patent office, a local council is ordered to perform it), B then being the new sender and C the new receiver.

[0056] For convenience, in the following description, in the case of a simple transaction, the first entity will be arbitrarily considered to be the sender and the second entity the receiver.

[0057] Moreover, the present method specifically relates to a transaction "defined by a form comprising a plurality of fields," that is to say, it is not, for example, a simple operation on a database but rather a A transaction involving both entities. This form advantageously represents a document, called 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 always 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 we will mention later in the description other documents called "annexes," which are documents different from the formal document, which do not define the task but are necessary for its implementation. In all cases, the form is representative of (i.e.described) the said task to which the transaction relates, and it is understood that the said formal document could be generated from this form.

[0058] As such, the form is in natural language (and not a simple computer instruction). It should be noted that the formal document represented by the form may be dematerialized, that is, only in electronic form, and transmitted simultaneously with the transaction or even reconstructed afterward. In other words, the document does not necessarily need to have been generated before the transaction, but must be able to be generated at any time. Indeed, as will be seen, the data transmitted via this process may be equivalent to said formal document.

[0059] 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 can be described by a form (from which a formal document can advantageously be generated), and in particular: • a request for a quote (the formal document is a description of the service requested) • the provision of the quote (the formal document is the quote) • a request to implement a task (the formal document is a letter of order) • the transmission of official documents (the formal document is the said official document) • an acknowledgement of receipt (the formal document is a message acknowledging receipt of another formal document) • a report (the formal document is the report) • an invoice (the formal document is the invoice) • etc.

[0060] As will be seen, the present process is entirely flexible and is not limited to a predetermined list of forms / transactions. One can even imagine "hybrid" transactions combining several standard forms. For example, we will see the case of a final report including an invoice.

[0061] We will focus, as a preferred example, on the field of intellectual property, with the following examples of transactions which will be described later: • instructions for filing a patent application • annuity payment instruction • annuity payment report • sequence of transactions in the case of a foreign extension of a patent application • sequence of transactions in the case of a response to official notification

[0062] In addition, with reference to [Fig.1], there is at least one server 1, 2, 3 for the implementation of the process, at least one first client device 10 of the first entity and at least one second client device 20 of the second entity, connected via a network 30 such as the internet.

[0063] Up to three servers can be used:

[0064] - a first server 1 of the first entity (sender)

[0065] - a second server 2 of the second entity (receiver)

[0066] - a third server 3 of a trusted third party.

[0067] Typically, server 1, 2 is an enterprise server and client device 10, 20. The employee workstations (PCs with an interface). Potentially, all client devices 10, 20 of an entity and the corresponding server 1, 2 are connected within a local network 30.1, 30.2 (possibly via VPN), with server 1, 2 serving as a gateway to the wide area network 30. It is also 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.

[0068] All connections are preferentially encrypted and secured (user authentication on his client device 10, 20).

[0069] 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 (a memory, for example flash), denoted 12, 22, 32 respectively for the first server 1, the second server 2 and the third server 3.

[0070] 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 database of Business data is stored on storage devices 12 and 22 of server 1 and 2. In the preferred embodiment in the field of intellectual property (IP), this data management system is an IPMS (IP Management System). It could also be an e-billing system or even an accounting system. In all cases, this data management system can be off-the-shelf, and the two entities can have different systems.

[0071] According to a first embodiment, the present method is implemented centrally by said third server 3, located in the wide area network 30. Client devices 10, 20 connect to it (where applicable via the possible first and second servers 1, 2) advantageously by means of a web portal. Alternatively, if there are first / second servers 1, 2 with a data management system of the first / second entity, these servers 1, 2 can be accessed by the client devices 10, 20 for the purpose of interacting with the third server 3 by means of dedicated application programming interfaces (APIs). As will be seen, these APIs allow direct communication with the data management systems. Alternatively again, said client devices 10, 20 can be capable of directly receiving structured input files in a predefined markup language from the servers 1, 2.

[0072] Said predefined markup language is for example JavaScript Object Notation (JSON), which is a textual data format derived from the object notation of the JavaScript language, but other languages ​​may be used for example based on XML, HTML, RPA, CSV, etc.

[0073] According to a second embodiment, the present method is implemented in a decentralized manner by said first and second servers 1, 2. In particular, each server 1, 2 can perform certain steps of the present method, in particular those which concern the entity (for example generation and sending of a message on the side of the first entity, and reception and processing of the message on the side of the second entity), in particular in an ESB (enterprise service bus) type operation in which said messages are exchanged asynchronously and placed in queues managed by the recipient servers 1, 2.

[0074] The three servers can be combined in a hybrid mode (depending on the entities and their computing capabilities).

[0075] Principle

[0076] In a known manner, the present method proposes the generation of a so-called main structured file (which can be like the input structured file in a predefined markup language, such as XML or JSON, but also in a language owner), containing the data of said form and therefore representing said document, by means of which the transaction will be implemented.

[0077] What is unusual is that the structured file 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, the structured file is "universal," i.e., it applies to any type of document, including non-conventional documents. Furthermore, the process is completely agnostic in that it makes no distinction between types of transactions or documents.

[0078] Moreover, this allows a transaction to be implemented in a similar way regardless of the type of document.

[0079] To do this, 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, i.e. each category is linked to an aspect of the task.

[0080] Said list is chosen so as to allow for an exhaustive description of any task; it is defined once and for all. Preferably, it consists of the following five categories: • The descriptive object of a party involved in said task (or stakeholder), which we will refer to as "party" for convenience, said party being in practice a distinct entity from the first and second entities, and in particular either a natural person or a legal person (said descriptive object of a party may thus be of two different types). For example, in the case of an intellectual property transaction, said party involved in said task may be an applicant, a patentee, an inventor, a licensee, an alleged infringer, an opponent, an agent, a patent office, etc. • A descriptive object of an asset involved in 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, said asset involved in said task may be a contract, a disclosure of invention, a patent application, a patent, a trademark, a design, etc. • 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 delay. In all cases, the event is generally defined by a date. For example, in the case of an intellectual property transaction, said event may be a priority date, a filing date, a publication date, a delivery date, an official deadline, an internal deadline, etc. • 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; • A descriptive object of a document associated with the task, i.e., an attachment, which may contain any document or a link to that document (if, for example, it is hosted online). Such an object is 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.

[0081] By "constituted", it is understood that there are no other elementary categories than the categories of said finite list.

[0082] To rephrase, said structured file preferentially contains only elementary objects of a category chosen from: • 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.

[0083] No category is essential, the file can contain only one object of a single category, several objects of several categories, including where appropriate several (different) objects of the same category.

[0084] Indeed, as will be seen, this structuring into a limited number of categories, as few as five, proves sufficient to represent any document defining any transaction. These categories are also complementary and can be linked to each other.

[0085] It is sufficient that each category of object be defined by a predefined set of object fields, such that each field of each object is standardized. 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.

[0086] Note that some fields can be open, i.e. accept any value (according to an expected format - number, text, date, etc.) or closed, i.e., only accept a list of possible values ​​(for example, the legal form of a legal entity).

[0087] Preferably, the set of predefined sets of object fields is defined in a common standard, for example the AFNOR NF X50-276 standard for intellectual property transactions.

[0088] The fact that each field of each object is standardized cleverly ensures that there will never be an unknown field and therefore that the recipient of the structured file will systematically be able to understand it and implement the corresponding transaction, without needing any model, regardless of the original form or formal document.

[0089] One drawback of the unlimited flexibility of this solution is that it can be complicated to select the correct object fields to complete due to their large number.

[0090] The present method cleverly solves this problem by providing that each elementary object is itself composed of blocks called "cards" defining subsets of the predefined set of fields of the object, and links between fields of the blocks, possibly in a hierarchical manner. To put it another way, the blocks are composed either of fields of the object or of links to other blocks, so that the blocks structure the predefined set of fields of the object. For each category of elementary object, there can be rules defining possible combinations of blocks, mandatory fields, possible links, etc.

[0091] The idea is to significantly reduce the number of combinations by providing a few alternative blocks for each object. Then, you simply select a few blocks intuitively, and this automatically defines the fields to be completed. Furthermore, the links between blocks automate part of this process.

[0092] Whereas objects constitute generic technical structures, applicable to all possible cases and in particular all domains, blocks are preferentially business-oriented, which further facilitates their selection. In other words, a global collection of possible blocks can be provided, including, in each domain, a few blocks adapted to the transactions encountered in that domain. To rephrase, the transaction is freely constructed by selecting from the blocks. It is also understood that, unlike the list of objects, which is fixed, the list of blocks can always evolve in order to cover a new transaction.

[0093] For example, in the IP domain: - A party object can include a legal entity block (fields ID, name, legal form, country of registration...) OR a natural person block (fields ID, title, first name, middle name, last name, nationality...), an address block (fields street, number, postal code, city, region, country...) where applicable a contact block (telephone number, email address...) where applicable an administrative information block (fields type of legal entity, jurisdiction, company registration number, etc.) - An asset object may include a profile block (fields for asset type, jurisdiction, extension method, status, etc.), where applicable a description block (fields for title, language, etc.), where applicable a contribution block (fields for contributor name, internal reference, etc.) - an event object can include, as explained, either a past event block or an expected event block (in both cases with event code, title, official date / delay, internal date / delay fields) - An account object can include at least one accounting entry block (with fields such as type, order number, issue date, amounts, currency, tax, etc.) and, for example, a more detailed cost accounting block. - An attachment object can include, in addition to the attachment itself (i.e., the document, whether it's the formal document or an appendix), a description block (with fields such as document ID, title, extension, language, hash, etc.). Note that the attachment can be presented only via a link.

[0094] Each of these elementary objects will be discussed in detail later, but it will be seen that any transaction between a sending entity and a receiving entity, defined by a form comprising at least one field, can be represented in this way.

[0095] We will not be limited to any organization of blocks / fields in said objects.

[0096] Note that, as we will see, each client device 10, 20 can itself have models defining for standard documents the list of corresponding fields, i.e. the fields expected to implement a given transaction defined by such a standard document, or even directly the corresponding blocks, but these models are only there to facilitate the work of users (insofar as we generally will always have more or less the same tasks) and remain optional (we can always define any original transaction of our choice).

[0097] Note that in an advantageous approach which can be described as No-Code (see below), the expected fields / blocks can be predefined by the receiving entity according to the task to be performed, and the user creates his transaction in the interface, directly with the block / fields which the receiving entity wishes to retrieve, and server 3 offers APIs or Web forms which correspond to the expectations of the receiving entity.

[0098] The present solution thus enables the implementation of transactions in a universal manner and presents no implementation difficulties. It should be noted that, unlike existing solutions that involve defining rules and specific configuration for each pair of entities, this one requires no setup (initialization) and works directly as long as the objects, blocks, and fields are shared. This allows for the direct creation of a community of entities capable of communicating (one-to-N approach).

[0099] Method for implementing a transaction

[0100] With reference to [Fig. 2], which represents a preferred embodiment, the present method begins with a step (a) of obtaining, at the level of the first client device 10, the first entity emitting content data for said field of said form. Preferably, step (a) also includes the designation of the second receiving entity (this can be automatic, particularly in the case of conversations – see below).

[0101] This step (a) can, as explained, be implemented in many ways.

[0102] According to a first manual mode, the user simply enters the contents of the fields of his choice.

[0103] According to a second semi-automated mode, the user has already generated the document and imports it. An OCR mechanism detects the fields and extracts their contents.

[0104] According to a third, fully automated mode, which is particularly preferred, especially if the first server 1 implements a data management system of the first entity, the first client device 10 can obtain the contents of said fields from the data management system of the first entity in the form of a structured input file, or by using APIs.

[0105] The objective is to generate in step (b) a structured file representing the transaction containing said data from the fields of said form in the form of one or more elementary objects, so that any arbitrary combination of fields is not necessarily possible.

[0106] More precisely, each elementary object is defined by a predefined set of object fields, some of which may be mandatory. Thus, for each elementary object in the structured file, the content of all mandatory fields must be obtained in step (a). It will be understood that it is possible, and even common, for certain fields to appear multiple times (i.e., in several elementary objects): for example, in the case of a request filing instruction transaction, there is an asset object defining the request, with a title field, and an attachment object for the text of this request, with the same title field.

[0107] Thus, preferably, step (a) includes the prior identification of one or more elementary objects / one or more blocks composing said objects identified elementary objects, necessary for defining the transaction. Then step (a) involves obtaining the contents of all the fields necessary to construct these identified elementary objects / blocks. As explained, this identification can be done very simply if the user chooses a template. For example, if the user wants to create an "invoice," then the template defines that there will be two elementary objects: an account object and a document object (with the invoice, which is mandatory).

[0108] As explained, in a No-Code approach the elementary object(s) / component blocks of said elementary objects, necessary for the definition of the transaction are pre-selected by the receiving entity (according to the nature of the desired transaction).

[0109] In the case of semi-automatic or automatic mode, there is no problem because the contents of all the necessary fields will be imported immediately. If a field is ever missing (due to an anomaly - for example, a form is provided with an error), then the missing field(s) can be requested from the user.

[0110] Then in step (b), the structured file is generated. Note that step (b) may also include, where applicable, the generation of the formal document associated with the task and represented by the form, and its possible integration into the structured file (as explained, the document can be stored online, and only a URL is included to retrieve it). Any other supplementary document can be integrated in the same way.

[0111] Preferably, step (b) further includes the generation of a message encapsulating said structured file.

[0112] In a known manner, said message may consist of a header, said structured file as the message body, and optionally a history file or activity log, from the English “log file” or “change log”.

[0113] The header contains a description of said transaction and is preferably generated first by said server 1, 2, 3 based on general information also provided by said first client device 10 (in particular designating the second entity). Indeed, the structured file may depend on any additional predefined requirements of the second entity; i.e., in some cases, it is the header and the designation of the receiving entity that determine exactly how to adapt said structured file.

[0114] Preferably, the header is also a structured object, advantageously also defined by a predefined set of standardized object fields, and including, where appropriate, blocks. Generally, the header defines contextual information about the message, which is not necessary for the implementation of the transaction but facilitates its tracking. For example, a main block might have including fields unique identifier, creation date, transaction status (see below), issuer (i.e. identification of the first entity), conversation (this will be explained later).

[0115] The potential history file, activity log, or log is primarily for traceability and debugging purposes; it is not necessarily accessible to the first and second entities. It records a history of (1) changes to form fields and / or (2) transaction processing steps, including changes in status (see below). Again, it is typically also a structured file, advantageously defined by a predefined set of standardized object fields, and possibly including blocks.

[0116] Thus, in the same way that the structured file is universal and adapts to any transaction, the message is also universal.

[0117] Then, in a step (c), the process includes making available to the second client device 20 of the second entity a message encapsulating said structured file, by said server 1, 2, 3.

[0118] This provision is understood by analogy with emails and the SMTP protocol: one or more messages are placed in an inbox associated with its recipient (the second entity), which can be retrieved by any second client device 20 of said second entity. This allows for a complete, centralized view of the flows. Duplicates are avoided, as is any risk of missing a transaction.

[0119] In practice, steps (b) and (c) are implemented within seconds after a user of the first client device presses a "send" button once the form field contents are obtained in step (a). Retrieval of the message, however, is asynchronous and may occur long after this initial delivery.

[0120] According to a "pull" mode, the retrieval of said message by the second client device 20 from said server 1, 2, 3 is on request from said second client device 20.

[0121] According to a "push" mode, the provision results in the sending of a notification to said second client device 20, and where applicable the automatic retrieval of said message (in particular if the second client device 20 is active).

[0122] Advantageously, the second device 20 can have, in a similar manner to the first client device 10, access to said web portal displaying the message(s) made available, where applicable issued by the first entity or another entity.

[0123] Preferably, the message status field acts as a tracker, that is, it is a data field used to track the delivery of the message, shared with the sending entity by analogy with a tracking device for a package or delivery. The sending entity can thus easily verify that the message is received and processed.

[0124] Preferably, the status defines a state of said provision, in particular selected from several possible states: draft, sent, received, processed, pending, returned, etc. An update of the status is recorded in the possible activity log, for complete traceability.

[0125] Such a status can be created at the same time as the structured file (in step (b)), before the message is made available, hence the possible draft state.

[0126] Pending or returned states may occur if, for example, the structured file has a problem, or was sent to the wrong entity.

[0127] The process then includes a final step (d) of extracting and processing by said second client device 20 the data from the fields of said structured file (which, it should be recalled, correspond to the data from the fields of said form), so as to implement said transaction. This step can be triggered by retrieving the message, or manually by the user.

[0128] Like step (a), this step (d) can be carried out in many different ways, depending on the level of instrumentation of the second entity and the type of transaction, and may include partial or even total automation of the underlying task. It is still possible to extract the information manually, for example in the event of a software failure, since the formal document is always available as an attachment.

[0129] 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).

[0130] In a simple transaction such as invoicing, a corresponding payment can be prepared directly and automatically in response to the invoice. For example, after processing the transaction, the user can be asked to approve or reject the invoice. If approved, the payment is automatically processed. This saves a significant amount of administrative work while ensuring complete legal security.

[0131] If the transaction is processed correctly, the status field can be updated (and displayed in the inbox) so that the user of the second client device 20 knows they can proceed to the next message. The user of the first client device 10 (sender) can also monitor the transaction status on the receiving end. Generally, the status can change to "received" and then "processed" when step (d) has been implemented nominally, but otherwise it can change to "pending" if further checks are required (and processing cannot be done automatically or at least not immediately), and possibly the message can be "resent" (and the status changed accordingly). If, for example, it is made available to the wrong entity, the activity log is again preferably completed accordingly.

[0132] We will now present more advanced examples for which the present process becomes even more interesting.

[0133] Example 1 - Patent application filing instructions

[0134] With reference to [Fig.3a], said transaction may be an instruction to file a patent application (for example, the first and second entities are two firms, the second being a foreign correspondent).

[0135] This is a complex transaction for which the formal document is usually a letter of instruction.

[0136] We can see that we need 4 elementary objects in the structured file: • a party favor for the depositor • an asset object for the patent application • an event object for a filing deadline (future event set by the applicant or official - case of a priority filing) • one or two attachments: at least the text of the request and possibly the formal document (the letter of instructions)

[0137] The fields of the party, asset and event objects can be directly filled in the data management system of the first entity and automatically imported in step (a), the text loaded manually, and the mail generated automatically.

[0138] The processing of the transaction will obviously not result in the automatic filing of the application (this must be done by an agent), but the automatic creation of the file corresponding to this new filing in the data management system of the second entity (by importing the data from the fields of said structured file), and the entry of the deadline.

[0139] The agent will then be able, on the day of filing, to import this data into a filing software or a portal (in particular e-procedures).

[0140] Example 2 - annuity payment instruction

[0141] With reference to [Fig.3b], said transaction may be an instruction to pay an annuity (for example, the first and second entities are again two firms, the second being a foreign correspondent).

[0142] This is a simpler transaction for which the formal document is usually a simple email (there is usually no full instruction email).

[0143] We can see that we only need 2 elementary objects in the structured file: • an asset object specifying the patent for which the annuity is payable • an event object for the annuity period (future event corresponding to an official deadline and possibly an internal deadline to proceed with payment before the formal due date)

[0144] The fields of the asset and event objects can be directly filled in the data management system of the first entity and automatically imported in step (a).

[0145] The processing of the transaction may optionally result in the automatic payment of the annuity if the data management system of the second entity is configured to do so.

[0146] At a minimum, the processing of the transaction entails the entry of the instruction to pay the annuity into the data management system of the second entity (by importing the data from the fields of said structured file), and the entry of the deadline, with a view to a manual payment.

[0147] The method according to the invention limits the risks inherent in annuity payments, in particular the possible errors of manual entry of a descriptive number of the security to be maintained, or of a date to be respected, each of which can lead to a loss of rights.

[0148] Example 3 - annuity payment statement

[0149] With reference to [Fig. 3c], said transaction may be a payment record annuity (typically in response to the transaction in example 2).

[0150] This is a complex transaction combining confirmation of task completion and invoicing, for which there are usually two formal documents (report letter and invoice).

[0151] We can see that we need 4 elementary objects in the structured file: • an asset object for the patent application for which the annuities have been paid • an event object for the annuity payment date (past event) • an account object for billing • One or two attachments: at least the invoice and possibly the report letter

[0152] The fields of the asset, event and account objects can be directly filled in the data management system of the first entity and automatically imported in step (a), and the invoice (and where applicable the letter) generated automatically.

[0153] The processing of the transaction results in the validation of the annuity payment deadline in the data management system of the second entity (by importing the data from the fields of said structured file), and possibly the automatic payment of the invoice.

[0154] Transaction sequence

[0155] According to a second aspect, the present invention relates to a method for implementing a sequence of transactions between at least a first entity and a second entity, relating to a task required by one of the first and second entities from the other. It should be noted that there may be other "third" entities (third, fourth, etc.) involved in this task and therefore some of the transactions in the sequence, but the task remains legally between the first and second entities only. The first and second entities, as well as any third entities, may alternately act as sending or receiving entities.

[0156] The process thus includes the execution, for each transaction of said sequence, of the process according to the first aspect for the implementation of said transaction.

[0157] In general, there is an "alternation" of entities in transactions. In other words, if the i-th transaction is issued by the first entity, then the i+1-th transaction is issued by the second entity (which becomes the issuing entity), the i+2-th transaction is issued by the first entity or a third entity, etc., although there may be exceptions.

[0158] But, in an original way, the implementations are such that the set of messages made available at each step (c) forms, as explained, a conversation. To rephrase, the message made available for the i+l-th transaction is a response to the message made available for the i-th transaction.

[0159] This allows a simple and efficient view of the transaction sequence, and therefore of almost fully automated processes from A to Z, with a total absence of risk of input error.

[0160] We will now look at two detailed examples.

[0161] With reference to [Fig.3d], said sequence of transactions may relate to an extension abroad of a patent application.

[0162] Said sequence would comprise the following transactions in succession: • request for a quote by the first entity from a second entity which is a correspondent (3 elementary objects: party (the depositor), asset (the priority request), and event (priority delay)); • transmission of the quote (1 object account (the quote)) • instructions for submitting to the second entity (4 basic items - see example 1, attachment referring to Attachments) • Optionally, the second entity may order a translation from a translator forming a third entity, if there is a language change (2 elementary objects: event (internal translation submission deadline) and attachment (the text of the priority request)). Alternatively, the translation is ordered traditionally. • Optionally, receiving the translation from the third entity (2 basic objects: attachment (the translation) and account (the invoice)) • Optionally, filing instructions from the second entity to the office as the fourth entity, if the latter accepts this procedure (4 elementary objects - see example 1), alternatively the filing is done traditionally • optionally acknowledgment of receipt of the deposit by the fourth entity (5 elementary objects: party (the depositor), asset (the application filed), event (the accepted filing date), attachment (the receipt) and account (the tax slip)) • finally, report of the filing with the first entity (5 elementary objects: party (the applicant), asset (the application filed), event (the accepted filing date), attachment (invoice + report + documents filed) and account (invoice))

[0163] With reference to [Fig.3e], said sequence of transactions may relate to a response to an official foreign notification.

[0164] Said sequence would comprise the following transactions in succession: • optionally transmission of the notification by the office as the first entity to a second entity which is the local agent, i.e. the correspondent (2 elementary objects event (official deadline) and attachment (the notification)), alternatively the notification is served by mail / email in the ordinary way; • retransmission of the notification from the second entity to the main firm forming the third entity (the same two objects) • receiving instructions to process the notification (1 elementary event object (internal processing delay)) • transmission of an analysis and / or draft response to the notification to the third entity (2 elementary objects: event (internal processing time) and attachment (the analysis / draft)) • Optionally, the retransmission of the analysis / draft response by the third entity to its client (the applicant) as a fourth entity (the same two objects) • optionally an agreement on the project in response (at least an event object with a new internal deadline and possibly an attachment if the project has been modified / commented on); • finally instructions for the second entity to submit the response to the notification to the first entity (the office), with only one object attached: the response.

[0165] Note that this sequence only concerned the processing of the notification, but it could also have included reporting and invoicing.

[0166] Client and server devices

[0167] According to a third aspect, the invention relates to the system comprising at least the first client device 10 of the sending entity, the second client device 20 of the receiving entity and the server(s) 1, 2, 3, connected by a communication network 30, for the implementation of the method according to the first aspect (or the second aspect).

[0168] 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.

[0169] Equipment 1, 2, 3, 10, 20 are configured to implement a transaction between the sending entity and the receiving entity, relating to a task required by one entity from the other, defined by a form comprising a plurality of fields, by implementing steps consisting of: • Obtain the contents of the fields of said form at the level of the first client device 10; • generate a structured file representing the transaction containing the data from the fields of said document, said structured file being composed of one or more elementary objects of a category chosen from a finite list of categories of objects describing an aspect of the task, in particular from: • 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;

[0170] each object category being defined by a predefined set of object fields, such that each field of each object category is standardized, 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, said generation 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. • make available to the second client device 20 a message encapsulating said structured file; • Extract and process by said second client device 20 the data from the fields of said structured file, so as to implement said transaction.

[0171] Computer program product

[0172] According to a fourth and a fifth aspect, the invention relates to a computer program product comprising code instructions for the execution (on equipment 1, 2, 3, 10, 20) of a method according to the first (or second) aspect for the implementation of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other, defined by a form comprising a plurality of fields; as well as computer-readable storage means (for example, the storage means of equipment 1, 2, 3, 10, 20) on which this computer program product is found.

Claims

Demands

1. A method for implementing a transaction between an emitting entity and a receiving entity, relating to a task required by one of the entities from the other, defined by a form comprising a plurality of fields, characterized in that it includes the implementation of steps of: (a) Obtaining at the level of a first client device (10) of the emitting entity the contents of the fields of said form; (b) Generating a structured file representing the transaction containing said data of the fields of said form, 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;each object category in said finite list being defined by a predefined set of object fields, such that each field of each object category is standardized, 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; said generation 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. (c) Making available to a second client device (20) of the receiving entity a message encapsulating said structured file, by at least one server (1, 2, 3) connected to said first and second client devices (10, 20) by a communication network (30); (d) Extraction and processing by said second client device (20) of the data from the fields of said structured file, so as to implement said transaction.

2. A method according to claim 1, wherein the object categories of said finite list are: • Object describing a part involved in said task • Object describing an asset involved in said task • Object describing an event associated with the task • Object describing an accounting aspect of said task • Object describing a document associated with said task.

3. A method according to claim 2, wherein step (a) comprises the generation of a document defining said task, said structured file comprising at least one object of the category descriptive object of a document containing said document or a link to said document.

4. A method according to any one of claims 1 to 3, wherein said message comprises a header and a structured file as the message body.

5. A method according to claim 4, wherein said message consists of said header, body, and an activity log tracing a history of actions in the creation and implementation of the transaction.

6. A method according to any one of claims 4 and 5, wherein step (a) also includes the designation of the receiving entity, step (b) further includes the generation prior to said structured file of said header according to the designation of the receiving entity.

7. A method according to any one of claims 1 to 6, wherein step (d) comprises retrieving said message by the second client device (20) from said server (1,2, 3), preferably following a request issued by said second client device (20).

8. A method according to any one of claims 1 to 7, wherein a first server (1) of the issuing entity implements a data management system of the issuing entity, step (a) comprising the automatic import of contents of the fields of said form from said data management system of the issuing entity.

9. A method according to any one of claims 1 to 8, wherein a second server (2) of the receiving entity implements a data management system of the receiving entity, step (a) comprising the automatic export of data from the fields of said structured file to said data management system of the receiving entity.

10. A method according to any one of claims 1 to 8, wherein step (a) includes the prior identification of one or more elementary objects and one or more blocks composing said identified elementary objects, necessary for the definition of the transaction, in particular by choosing a form template, and obtaining the contents of all the fields necessary to construct said elementary objects and the identified blocks.

11. A method according to claim 10, wherein the elementary object(s) and the block(s) composing said elementary objects, necessary for the definition of the transaction, are pre-selected by the receiving entity.

12. A method for carrying out a sequence of transactions between at least a first entity and a second entity, relating to a task required by one of the first and second entities, from the other, comprising executing, for each transaction in said sequence, the method according to any one of claims 1 to 11 for carrying out said transaction, such that the set of messages made available at each step (c) forms a conversation.

13. A system comprising at least one first client device (10) of a sending entity, a second client device (20) of a receiving entity and at least one server (1, 2, 3), connected by a communication network (30), characterized in that they are configured to, in order to implement a transaction between the sending entity and the receiving entity, relating to a task required by one of the entities, from the other, defined by a form comprising a plurality of fields: • Obtain at the level of the first client device (10) the contents of the fields of said form; • generate a structured file representing the transaction containing said data of the fields of said form, 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;each object category of said finite list being defined by a predefined set of object fields, such that each field of each object category is standardized, each elementary object being itself composed of blocks defining subsets of said predefined set of object fields, and of links between fields of the blocks, said generation 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. • make available to the second client device (20) a message encapsulating said structured file; • Extract and process by said second client device (20) the data from the fields of said structured file, so as to implement said transaction.

14. Product computer program comprising code instructions for carrying out a method according to any one of claims 1 to 10 for implementing a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other, defined by a form comprising a plurality of fields, when said program is executed on a computer.

15. 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 implementation of a transaction between a sending entity and a receiving entity, relating to a task required by one of the entities, from the other, defined by a form comprising a plurality of fields.