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, the method comprising: (a) obtaining contents of the fields of the form; (b) generating a structured file representative of the transaction containing the data from the fields of the form, the structured file consisting of elementary objects belonging to categories each defined by a predefined set of standardized object fields, each elementary object being composed of blocks defining subsets of the predefined set of object fields, and of links between fields of the blocks; the step of generating the structured file comprising the transcription of the contents of the one or more fields of the form into the object fields of the structured file; (c) providing a message encapsulating the structured file; (d) extracting and processing the data from the fields of the structured file so as to implement the transaction.

Description

[0001] Description

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

[0003] GENERAL TECHNICAL FIELD

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

[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] While this has significantly reduced the cost and environmental impact of their emission compared to paper, it is clear that dematerialization practices are still highly heterogeneous and that their processing remains long and tedious.

[0008] For example, the standard procedure for processing an electronic invoice is as follows:

[0009] - generation of the invoice in PDF format by the service provider (using their data management system)

[0010] - sending the invoice to the customer by email

[0011] - receiving and manually entering invoice information into a customer-specific data management system for payment.

[0012] Manual data entry is tedious and sometimes outsourced.

[0013] Solutions exist to avoid this manual data entry, such as using OCR on PDFs or embedding a QR code on the invoice for scanning. However, this requires developing additional modules or versions, which must be multiplied by the number of service providers, and this solution is sometimes prone to errors due to the "optical" phase.

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

[0015] These techniques provide satisfactory results 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 be structured in a standardized way, particularly to meet regulatory requirements.

[0016] This solution is satisfactory but proves inflexible and scalable, as the data must be communicated precisely according to models or templates to be accepted. While multiple templates can be created, one for each entity involved, this is laborious.

[0017] The present invention improves the situation.

[0018] PRESENTATION OF THE INVENTION

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

[0020] (a) Obtaining, at the level of a first client device of the content-issuing entity, the fields of said form;

[0021] (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 object categories 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;

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

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

[0024] According to advantageous and non-limiting characteristics:

[0025] The object categories in the said finite list are:

[0026] - Descriptive object of a part involved in said task

[0027] - Descriptive object of an asset involved in said task

[0028] - Descriptive object of an event associated with the task

[0029] - Descriptive object of an accounting aspect of said task

[0030] - Descriptive object of a document associated with said task.

[0031] Each object in the category of 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.

[0032] Each object in the descriptive object category of an event includes a past event block or an expected event block when the task is completed.

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

[0034] The message includes a header and the structured file as the message body.

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

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

[0037] Step (b) further includes the generation, prior to said structured file, of said header according to the designation of the receiving entity.

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

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

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

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

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

[0043] 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 identified blocks.

[0044] 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. 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 from the other, comprising the execution, for each transaction of said sequence, of the method 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.

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

[0046] - Obtain the contents of the fields of said form at the level of the first client device;

[0047] - generate a structured file representing the transaction containing the data from the fields of said form, said structured file being composed of one or more elementary objects of a category chosen from a finite list of object categories 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 including the transcription of said content 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;

[0048] - Extract and process by said second client device (20) the data from the fields of said structured file, so as to implement said transaction.

[0049] According to a fourth and a fifth aspect, the invention proposes a computer program product comprising code instructions for the execution of a process according to the first 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; and a computer-readable storage means on which is recorded a computer program product comprising code instructions for the execution of a process according to the first 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.

[0050] PRESENTATION OF THE FIGURES

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

[0052] [Fig. 1] Figure 1 is a diagram of a system for implementing the process according to the invention;

[0053] [Fig. 2] Figure 2 is a flowchart illustrating the steps of an embodiment of the process according to the invention;

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

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

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

[0057] [Fig. 3e] Figure 3e illustrates a fifth example of implementation of the process according to the invention.

[0058] DETAILED DESCRIPTION

[0059] Architecture

[0060] 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 Figure 1.

[0061] 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 (see below for examples involving third and fourth entities).

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

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

[0064] Note 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 might be a first transaction in which entity A orders a service from entity B, defined by a first document (letter of instruction), and a second transaction in which B sends a report of said service to A after it has been performed (this report being the second document). It is understood that:

[0065] - in the first transaction, the first entity A has the role of sender and the second entity B has the role of receiver;

[0066] - in the second transaction, the second entity B has the role of sender and the first entity A has the role of receiver.

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

[0068] Furthermore, a sequence of transactions can involve more than two entities, these entities taking turns acting as sender / receiver. For example, after the first transaction, the second entity B can commission 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 commissioned to perform it), with B then being the new sender and C the new receiver.

[0069] For convenience, in the rest of the description, in the case of a simple transaction we will arbitrarily consider the first entity to be the sender and the second entity to be the receiver.

[0070] Furthermore, this process specifically 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, 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, 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 later in the description, we will mention other documents called "annexes," which are separate from the formal document. These annexes 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.

[0071] As such, the form is written in natural language (and not simply as a computer instruction). It should be noted that any formal document represented by the form can be digitized, meaning it exists 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 we will see, the data transmitted via this process can be equivalent to said formal document.

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

[0073] - a request for a quote (the formal document is a description of the service requested)

[0074] - the provision of the quote (the formal document is the quote)

[0075] - a request to implement a task (the formal document is a letter of order)

[0076] - the transmission of official documents (the formal document is the said official document)

[0077] - an acknowledgement of receipt (the formal document is a message acknowledging receipt of another formal document)

[0078] - a report (the formal document is the report)

[0079] - an invoice (the formal document is the invoice)

[0080] - etc.

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

[0082] We will focus, as a preferred example, on the field of intellectual property, with the following examples of transactions which will be described later:

[0083] - instructions for filing a patent application

[0084] - annuity payment instruction

[0085] - annuity payment report

[0086] - sequence of transactions in the case of a foreign extension of a patent application; sequence of transactions in the case of a response to an official notification

[0087] In addition, with reference to Figure 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.

[0088] You can have up to three servers:

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

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

[0091] - a third server 3 from a trusted third party.

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

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

[0094] Each server / device 1, 2, 3 has, where applicable, data processing means (typically a processor), noted 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), noted 12, 22, 32 respectively for the first server 1, the second server 2 and the third server 3.

[0095] 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 resources 12, 22 of server 1, 2. In the preferred embodiment in the field of intellectual property (IP), said 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, said data management system can be off-the-shelf, and the two entities can have different systems.

[0096] According to a first embodiment, the present process is implemented centrally by the third server 3, located in the wide area network 30. The 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, the client devices 10, 20 can be capable of directly receiving structured input files from the servers 1, 2 in a predefined markup language.

[0097] The 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 ​​can be used, for example, based on XML, HTML, RPA, CSV, etc.

[0098] According to a second embodiment, the present process 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 process, 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. The three servers can be combined in a hybrid mode (depending on the entities and their computing capabilities).

[0099] Principle

[0100] As is known, the present process proposes the generation of a structured file called the main file (which can be like the input structured file in a predefined markup language, such as XML or JSON, but also in a proprietary language), containing the data of said form and therefore representing said document, by means of which the transaction will be implemented.

[0101] What is unique is that this structured file does not conform to a predetermined structured file model chosen based on a specific type of formal form / document (invoice, purchase order, etc.) or even a specific type of transaction. On the contrary, this structured file is "universal," meaning it works with any type of document, including non-conventional ones. Furthermore, the process is entirely agnostic, making no distinction between types of transactions or documents.

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

[0103] To do this, the 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.

[0104] This 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:

[0105] - A 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 patent holder, an inventor, a licensee, an alleged infringer, an opponent, an agent, a patent office, etc.

[0106] - 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 declaration of invention, a patent application, a patent, a trademark, a design, etc.

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

[0108] - 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;

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

[0110] By "constituted", we mean that there are no other elementary categories than the categories in the said finite list.

[0111] To rephrase, the structured file preferably contains only elementary objects from a category chosen from:

[0112] - Descriptive object of a part involved in said task

[0113] - Descriptive object of an asset involved in said task

[0114] - Descriptive object of an event associated with the task

[0115] - Descriptive object of an accounting aspect of said task

[0116] - Descriptive object of a document associated with said task.

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

[0118] Indeed, as we will see, this structuring into a limited number of categories, as few as five, proves sufficient to represent any document defining any transaction. Furthermore, these categories are complementary and can be linked to one another.

[0119] It suffices that each object category 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.

[0120] 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., accept only a list of possible values ​​(for example, the legal form of a legal entity). Preferably, the set of predefined object field sets is defined in a common standard, for example, the AFNOR NF X50-276 standard for intellectual property transactions.

[0121] 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 always be able to understand it and implement the corresponding transaction, without needing any template, regardless of the original form or formal document.

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

[0123] The present method cleverly solves this problem by stipulating that each elementary object is itself composed of blocks called "cards," defining subsets of the object's predefined set of fields, and links between the fields of these blocks, possibly in a hierarchical manner. To rephrase, the blocks are composed either of the object's fields or of links to other blocks or even other objects, so that the blocks structure the object's predefined set of fields. It should be understood that the notion of "links between block fields" is to be interpreted broadly; these links can be direct, that is, connecting individual fields, or indirect, that is, connecting two blocks or objects that have a particular relationship. To illustrate:

[0124] - the descriptive object of a party (a natural or legal person) can be linked to the descriptive object of an asset (patent, trademark...) or of a document (an identity card or a registration form in the trade and companies register of a legal person).

[0125] - The descriptive object of an accounting aspect (an invoice) can be linked to the descriptive object of a document (a PDF document corresponding to the invoice) and to the descriptive object of one or more parties (an issuer of the invoice and a recipient). Etc.

[0126] For each category of elementary object, we can have rules defining possible combinations of blocks, mandatory fields, possible links, etc.

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

[0128] While objects constitute generic technical structures applicable to all possible cases and, in particular, all domains, blocks are preferentially business-oriented, further simplifying their selection. In other words, a global collection of possible blocks can be planned, including, within 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. Furthermore, unlike the list of objects, which is fixed, the list of blocks can always evolve to cover a new transaction.

[0129] For example, in the IP domain:

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

[0131] - An asset object can include a profile block (fields: asset type, jurisdiction, extension method, status, etc.), and where applicable, a description block (fields: title, language, etc.), and where applicable, a contribution block (fields: 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 fields: event code, title, official date / deadline, internal date / deadline).

[0132] - An account object can include at least one accounting entry block (with fields for type, order number, issue date, amounts, currency, tax, etc.) and, for example, a more detailed analytical accounting block

[0133] - An attachment object can include, in addition to the attachment itself (i.e., the document, whether it's the main 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 solely via a link.

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

[0135] Furthermore, we will not be limited to any organization of blocks / fields within said objects.

[0136] 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 will generally always have more or less the same tasks) and remain optional (we can always define any original transaction of our choice).

[0137] 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 their transaction in the interface, directly with the block / fields that the receiving entity wishes to retrieve, and server 3 offers APIs or Web forms which correspond to the expectations of the receiving entity.

[0138] This solution enables the universal implementation of transactions and presents no setup difficulties. Unlike existing solutions that require rule definition and specific configuration for each entity pair, this one requires no setup (initialization) and works directly as long as the objects, blocks, and fields are shared. This allows for the immediate creation of a community of entities capable of communicating (one-to-many approach).

[0139] Procedure for implementing a transaction

[0140] With reference to Figure 2, which represents a preferred embodiment, the present process 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).

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

[0142] In the first manual mode, the user simply enters the contents of the fields of their choice.

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

[0144] According to a third, fully automated mode, which is particularly preferred, especially if the first server 1 implements a data management system for the first entity, the first client device 10 can obtain the contents of said fields from the first entity's data management system in the form of a structured input file, or by using APIs. 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, such that not every arbitrary combination of fields is necessarily possible.

[0145] 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 is understandable 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.

[0146] Preferably, step (a) involves the prior identification of one or more elementary objects / one or more blocks comprising said identified elementary objects, necessary for defining the transaction. Then, step (a) includes retrieving the contents of all the fields necessary to construct said 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 being mandatory).

[0147] 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 (depending on the nature of the desired transaction).

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

[0149] 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 for retrieval). Any other supporting document can be integrated in the same way.

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

[0151] As is known, the said message may consist of a header, the said structured file as the body of the message, and optionally a history file or activity log, from the English "log file" or "change log".

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

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

[0154] The potential history file, activity log, or log file is primarily used 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 a structured file, also advantageously defined by a predefined set of standardized object fields, and potentially including blocks.

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

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

[0157] This provision is analogous to email 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 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.

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

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

[0160] In a "push" mode, the delivery triggers a notification to the second client device 20, and, if applicable, the automatic retrieval of the message (particularly if the second client device 20 is active). Advantageously, the second device 20 can have access, similar to the first client device 10, to the web portal displaying the message(s) delivered, if applicable, issued by the first entity or another entity.

[0161] Preferably, the message status field acts as a tracker, meaning it's a piece of data that tracks the message's delivery, shared with the sending entity similarly to a tracking number for a package or delivery. This allows the sending entity to easily verify that the message has been received and processed.

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

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

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

[0165] The process then includes a final step (d) of extraction and processing by said second client device 20 of 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 the retrieval of the message, or manually by the user.

[0166] Like step (a), this step (d) can be performed 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 remains possible to extract the information manually, for example, in the event of a software failure, as the formal document is always available as an attachment. 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., its storage in said business database stored on the storage means 22 of server 2).

[0167] In a simple transaction such as an invoice, a corresponding payment can be prepared directly and automatically in response to the invoice. For example, after the transaction has been processed, the user can be asked to approve or reject the invoice. If approved, the payment is automatically processed. This significantly reduces administrative work while ensuring complete legal security.

[0168] 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 (the 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 correctly. However, if further checks are required (and processing cannot be done automatically, or at least not immediately), the status may change to "pending." The message may also be "resent" (and the status modified accordingly) if, for example, it was made available to the wrong entity. Again, the activity log is preferably updated accordingly.

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

[0170] Example 1 - Instruction to file a patent application With reference to Figure 3a, said transaction may be an instruction to file a patent application (e.g. the first and second entities are two firms, the second being a foreign correspondent).

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

[0172] We can see that we need 4 basic objects in the structured file:

[0173] - a party favor for the depositor

[0174] - an asset object for the patent application

[0175] - an event object for a filing deadline (future event set by the applicant or official - case of a priority filing)

[0176] - one or two attachments: at least the text of the request and possibly the formal document (the letter of instructions)

[0177] The fields for 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.

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

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

[0180] Example 2 - Annuity payment instruction

[0181] Referring to Figure 3b, this transaction could be an instruction to pay an annuity (for example, the first and second entities are again two firms, the second being a foreign correspondent). This is a simpler transaction for which the formal document is usually a simple email (there is generally no full instruction letter).

[0182] We can see that we only need 2 basic objects in the structured file:

[0183] - an asset object specifying the patent for which the annuity is payable

[0184] - 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)

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

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

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

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

[0189] Example 3 - Annuity payment statement

[0190] With reference to Figure 3c, said transaction may be an annuity payment report (typically in response to the transaction in Example 2).

[0191] This is a complex transaction combining confirmation of task completion and invoicing, for which there are usually two formal documents (a report letter and an invoice). We can see that we need four basic objects in the structured file:

[0192] - an asset object for the patent application for which the annuities have been paid

[0193] - an event object for the annuity payment date (past event)

[0194] - an account object for billing

[0195] - one or two attachments: at least the invoice and possibly the report letter

[0196] 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 if applicable the letter) generated automatically.

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

[0198] Transaction sequence

[0199] According to a second aspect, the present invention relates to a method for implementing a sequence of transactions between at least one first entity and a second entity, concerning 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 in 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.

[0200] The process thus includes executing, for each transaction in said sequence, the process according to the first aspect for the implementation of said transaction. In general, there is an "alternation" of entities in the 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, and so on, although there may be exceptions.

[0201] However, 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+1th transaction is a response to the message made available for the i-th transaction.

[0202] 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 data entry errors.

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

[0204] With reference to figure 3d, the said sequence of transactions may concern an extension abroad of a patent application.

[0205] The said sequence would include the following transactions in succession:

[0206] - 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));

[0207] - transmission of the quote (1 object account (the quote))

[0208] - instructions for filing with the second entity (4 basic objects - see example 1, attachment referring to Attachments)

[0209] - Optionally, the second entity orders a translation from a translator forming a third entity, if there is a language change (2 elementary objects: event (internal translation delivery deadline) and attachment (the text of the priority request)), alternatively the translation is ordered traditionally - Optionally, the translation is received from the third entity (2 elementary objects: attachment (the translation) and account (the invoice))

[0210] - 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

[0211] - 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))

[0212] - finally, report of the deposit to the first entity (5 elementary objects: party (the depositor), asset (the application filed), event (the accepted deposit date), attachment (invoice + report + documents filed) and account (invoice))

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

[0214] The said sequence would include the following transactions in succession:

[0215] - 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;

[0216] - retransmission of the notification from the second entity to the main firm forming the third entity (the same two objects)

[0217] - receiving instructions to process the notification (1 elementary object event (internal processing delay)) - transmitting an analysis and / or draft response to the notification to the third entity (2 elementary objects event (internal processing delay) and attachment (the analysis / draft))

[0218] - 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)

[0219] - 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);

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

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

[0222] Client and server devices

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

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

[0225] Equipment 1, 2, 3, 10, and 20 are configured to implement a transaction between the sending and receiving entities, relating to a task required by one entity from the other, as defined by a form comprising multiple fields. This involves implementing steps consisting of:

[0226] - Obtain the contents of the fields of said form at the level of the first client device 10;

[0227] - generate a structured file representing the transaction containing said data from the fields of said document, 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, in particular among: o Object describing a party involved in said task o Object describing an asset involved in said task o Object describing an event associated with the task o Object describing an accounting aspect of said task o Object describing a document associated with said task;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.;

[0228] - to make available to the second client device 20 a message encapsulating said structured file;

[0229] - Extract and process by said second client device 20 the data from the fields of said structured file, so as to implement said transaction.

[0230] Computer program product 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

33 DEMANDS 1. A method for implementing a transaction between a sending entity and a receiving entity, relating to a task required by one entity from the other, defined by a form comprising a plurality of fields, characterized in that it comprises the implementation of the following steps: (a) Obtaining at the level of a first client device (10) of the content-issuing entity the fields of said form; (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 object categories 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: 34 - 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.

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. 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 before 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 import automatic content 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) comprises 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. 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. 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, comprising executing, for each transaction of said sequence, the method according to any one of claims 1 to 11 for the implementation of said transaction, such that the set of messages made available at each step (c) forms a conversation.

13. 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 network of communication (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 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; each category of object in said finite list being defined by a predefined set of object fields, such that each field of each category of object 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 including 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 the execution of a method 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, when said program is executed on a computer. 37 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.

Images