FR3050843A1 - METHOD AND PLATFORM FOR HOMOGENEOUS COMMUNICATION BETWEEN HUMANS AND CONNECTED OBJECTS - Google Patents

Abstract

The invention relates to a communication platform between a plurality of sources and a plurality of recipients capable of exchanging information in either a constructed language or a natural language, comprising a plurality of distributed data processing units in which the information exchanged between the sources and the recipients are systematically converted into natural language by said distributed data processing units.

Description

METHOD AND PLATFORM FOR HOMOGENEOUS COMMUNICATION BETWEEN HUMANS AND

CONNECTED OBJECTS

TECHNICAL FIELD The invention lies in the field of bidirectional communications between a plurality of sources and a plurality of recipients, and more specifically concerns a method and an intelligent platform for communication between a plurality of sources and a plurality of recipients who are likely to exchange messages and / or data via said intelligent platform, each source and each recipient being able to use either specific built languages or one or more natural languages. The invention also relates to a computer program stored on a recording medium and comprising instructions for implementing the method according to the invention when it is executed by computer.

STATE OF THE PRIOR ART

Increasingly, communicating objects, or connected objects, and digital services are used as a support for many services in most areas of personal activity, professional life and also the public environment, for example, in the areas of healthcare, human assistance, connected home, smart city, security, agriculture, autonomous vehicles, energy management, industrial robots and services, etc ... These connected objects exchange information via digital interfaces from the world of telecommunications and the world of the Internet (web). To this end, several recommendations and several standards exist, developed totally or partially, by various organizations such as the European Telecommunications Standards Institute (ETSI), the World Wide Web Consortium (W3C), the Open Interconnect Consortium (OIC), the Allseen Alliance, TeleManagement Forum (TMF), OASIS, etc. These various recommendations and standards are intended in particular: to allow a certain level of interoperability between the infrastructures, the connected objects and the services that implement them; limit the efforts and costs of developing, deploying and maintaining these objects and services; to simplify the implementation for users, especially when they use the objects and services in large numbers, for example by limiting the amount of applications needed to manage these objects and services.

However, the abundance and diversity of connected objects, digital services, communication standards and protocols, cause a multiplicity of types of commands, parameters, units, conventions, presentations, etc. so that practically every object has its own language of communication with the outside world. Dealing with this abundance by developing as much ad-hoc adaptation as there are objects or families of objects, as is done in the "digital hubs", is a complex, expensive and unsuitable solution. to the present and future explosion of the number of connected objects and digital services. In addition, the solutions recommended for this purpose do not take into account the communication problems between the different "digital hubs". In addition, the multiplicity of needs, uses, software editors, connected object manufacturers, online digital service providers, and standardization organizations leads to a multitude of options that are not conducive to simple exchanges between the different components of these services (objects, local services, web services, etc.), between the objects themselves and the users of these services (humans, animals, robots, other services, etc.).

Finally, traditional communication architectures operate in silos so that the applications and mechanisms involved in exchanges between humans are different from those used in human exchanges on the one hand and connected objects and digital services on the other hand. as well as between connected objects. In the case of exchanges between humans, the communication system of traditional communication architectures focuses on transmitting information in natural language (voice, video, text) without distorting it. In addition, the exchanges between humans and connected objects or digital services are essentially made from graphical user interfaces (GUIs) or online (CLIs for command-line interfaces) which guide the exchanges and restrict them to the possibilities of the users. objects and services involved. For their part, the exchanges between connected objects involving or not digital services are made from specialized interfaces designed specifically for computer languages (API), specific to each object and service, and interconnected by means of platforms sometimes called "hubs" digital "

Moreover, in addition to the obstacles due to the proliferation of modes and formats of communication of connected objects and digital services, traditional communication architectures encounter a problem of convergence that comes from the shift in modes of exchange between humans, connected objects and services. digital. Indeed, although the user interfaces implemented in modern terminals like "smartphones" and tablets facilitate exchanges between the world of humans and the digital world by means of graphics relatively easy to use, these interfaces are designed only to channel the expression of users to the limited capabilities of their digital interlocutors (connected objects and services), asking them to learn a 'language' for each of the connected objects or digital services they wish to use. in human expression constitute a significant obstacle to human / machine convergence: in current technologies, the control modes of connected objects are precise and closed and use a list of commands with a fixed lexicon, syntax and parameters specific to each object or family of objects, which is why human users of these objects and communicating services must go through CLI (Command Line Interface) or graphical user interfaces (GUI -Graphical User Interface) which restrict their choice and guide them to a limited number of options.

The known Natural Language Processing (NLP) technologies already allow some equipment or services to be used from natural language, most often oral. For example Siri © of Apple © or Cortana © of Microsoft © offer a virtual assistant service to perform operations such as searching for information on the Internet or booking transportation tickets using voice commands; Nuance Communication © also markets customer support products and services from virtual agents simulating human operators; Alexa © of Amazon © offers a voice interface service for third-party services. However, these technologies are an addition of a complementary interface to the services that can be called NLI (Natural Language Interface) by analogy to graphical interfaces (GUI) and command line (CLI). In addition, although they make it possible to simplify access to the various services that use them, these technologies require specific developments for each service and function supported and introduce new rigidities in uses, such as the use of key phrases by users. examples. In addition, they do not solve the problem of the proliferation of connected objects and digital services using different languages and communication protocols.

STATEMENT OF THE INVENTION

An object of the invention is to overcome the disadvantages of the prior art described above.

Another object of the invention is to unify the exchanges that humans, connected objects and digital services can have with each other (for example between connected objects, between humans and objects, etc.) around a common natural language. . Other users may also be concerned, especially animals and robots.

In the remainder of the description, the term natural target language (CNL-Core Natural Language) is used to denote the common natural language used, and by constructed language, a numerical language consisting of commands, parameters, encodings of information, implicit or explicit conventions, etc. coupled to one or more communication protocols for communicating with one or more connected objects. These built languages may vary depending on the objects and applications.

The target natural language may for example be a widely spoken language such as English, but other natural languages are also possible. It is chosen either by configuration or any other mode (voting, negotiation ...).

These goals are achieved by means of a communication method between a plurality of sources and a plurality of recipients capable of exchanging information, either in constructed languages or in natural language, via an intelligent platform comprising a plurality of distributed units. information processing system comprising at least one bidirectional NLXS natural language exchange unit, at least one first language conversion unit, at least one first media and protocol adaptation unit associated with the source, and least one second language conversion unit and at least one second media adaptation and protocol adaptation module associated with the recipient.

Note that the sources and recipients can be either humans or connected objects or digital services and can be either transmitters or receivers of messages.

The method according to the invention comprises the following steps: • on the sending side, - intercepting by the first media and protocol adaptation unit the information sent by at least one source to at least one recipient, - determining the type of language describing the intercepted information, and, if the language describing the intercepted information is a constructed language, - automatically converting said constructed language to natural language using the first language conversion unit, - transmitting said natural language information to the recipient via the module bidirectional NLXS natural language exchange, and, • on the receiving end, if the recipient's language is a constructed language, automatically convert the message in natural language of the message sent into a message in the language constructed using the second conversion unit of language, then, - provide the information in constructed language to the recipient via the second media and protocol adaptation module, if the recipient language is a natural language, providing the natural language information to the recipient.

The method according to the invention further comprises a step of analyzing information exchanged in natural language between humans, objects and services connected via said intelligent platform, and a step of solving ambiguities and inconsistencies identified by said analysis step.

Optionally, the method according to the invention comprises a procedure for learning by the intelligent platform of the modes of use by the sources and by the recipients of the target natural languages and the languages constructed so as to improve the conversion performance and the resolution of ambiguity and coherence of a human natural language and a constructed language.

Preferably, said learning procedure is executed automatically, in the background, without directly interfering with the conversion steps and ambiguity resolutions.

Said learning procedure comprises the following steps: - classifying the information exchanged according to the different sources, - analyzing the contents of said exchanged information, - progressively enriching at least one information base used by all the sources of the same type or of the same family.

In addition, for the exchanged information that required an ambiguity or coherence resolution procedure, the learning procedure also comprises the following steps: analyzing the contents of said information, progressively enriching at least one information base used by all sources of the same type or family.

The method according to the invention is implemented via an intelligent communication platform between a plurality of sources and a plurality of recipients able to exchange information in either constructed languages or in natural language, comprising a plurality of distributed units of information processing comprising at least one bi-directional NLXS natural language exchange unit, at least one first language conversion unit and at least one first media and protocol adaptation unit associated with the source, at least one second language conversion unit and at least one second media adaptation unit and protocol associated with the recipient.

The platform according to the invention is characterized in that: the first media and protocol adaptation unit is configured to intercept the information sent by at least one source to at least one recipient and to determine the type of language describing the intercepted information, and - the first language conversion unit is configured to automatically convert the message into a constructed language describing intercepted information into a natural language message, - the bi-directional NLXS natural language exchange unit is configured to transmit said messages. natural language information to the recipient; the second language conversion unit is configured to automatically convert natural language messages to built-language messages if the recipient language is a constructed language.

In a preferred embodiment, the platform according to the invention comprises: a unit for selecting a common target natural language, a bidirectional unit intended to align the messages and units in natural language to the selected target natural language (LUTA for Language, Units and Time Alignment), - a bidirectional unit for controlling and resolving the grammar, ambiguity and relevance of the information exchanged in the Target Language Language (LARC), - a bidirectional unit of conversion of messages between the target natural language and the built languages (NLAC for Natural Language to API Converter).

Said platform also includes a unit for learning modes of use by the sources and by the recipients of the target natural languages and languages constructed in such a way as to improve the conversion performance and ambiguity resolution of a human natural language. and / or a constructed language.

BRIEF DESCRIPTION OF THE DRAWINGS Other features and advantages of the invention will emerge from the description which follows, taken by way of nonlimiting example, with reference to the appended figures in which: FIG. 1 is a general diagram illustrating a platform 2 schematically represents an architecture of the platform of Figure 1 showing the different processing layers of information exchanged between a source and a recipient via the platform of Figure 1, - Figure 3 illustrates schematically a technical environment of the elements making up the platform of FIG. 1, - FIG. 4 schematically and partially represents the units of platform 1 making it possible to exchange information between a human and a connected object, - FIG. and partially the units of platform 1 allowing for exchanges of information between two connected objects, - Figures 6 and 7 respectively show functional diagrams illustrating in detail the steps of processing the information exchanged between a human and an object connected via the platform according to the invention, - Figures 8 and 9 show functional diagrams illustrating in detail the steps of processing the information exchanged between two objects connected via the platform according to the invention; FIGS. 10A and 10B respectively illustrate the essential steps of the processing applied to a message transmitted by a remote source; to a recipient, and the essential processing steps applied to a target natural language message sent by the recipient in response to the message received from said remote source; - Figure 11 is a detailed flowchart illustrating the natural language alignment of the source remote on a selected target natural language Fig. 12 is a detailed flowchart of the step of aligning the units used by the remote source with those used by the recipient; Fig. 13 is a detailed flowchart of the step of aligning the date references; of time and duration used by the remote source over those used by a connected object or a digital service, - Figure 14 is a detailed flowchart of the step of aligning the date, time and duration references used. by a recipient, transmitting a target natural language message, over those used by the remote source of FIG. 10, - FIG. 15 is a detailed flowchart of the alignment step of the units used by the recipient, transmitter of a target natural language message, over those used by the remote source of FIG. 10; FIG. 16 is a detailed flowchart of the recipient's target natural language alignment step, transmitting to the natural language of the remote source of FIG. 10; FIG. 17 represents a detailed view of an ambiguity and relevance resolution unit of the platform according to the invention; FIG. 18 represents a flow chart of the control steps; of ambiguity and relevance of a target natural language message of a remote user by means of the unit of FIG. 17, - FIG. 19 represents a flowchart of the steps of transforming the target natural language information into a language. construct used by a connected object or a digital service, - figure 20 represents a flowchart of the steps of transformation of the information in constructed language (digital format for controlling connected objects or digital format for piloting digital services) in target natural language, Figure 21 schematically illustrates the steps of an exchange relating to a request for assistance between two communicating objects.

DETAILED PRESENTATION OF PARTICULAR EMBODIMENTS

FIG. 1 represents a general view showing sources and recipients of different natures capable of communicating via a platform 1 according to the invention. These sources and recipients can be either humans 2 provided with a communication device such as for example a computer, a tablet 4, or a smartphone, or connected robots 6, or animals 7 equipped with electronic boxes with means of connection to the platform 1 and for transmitting to animals information representing instructions, or to receive information from these animals about their behavior for example. Humans can express themselves in natural language by speaking into a microphone with automatic transcription in text 8, or by text entered by means of a conventional keyboard 10 or a Braille keyboard 12 connected to a communication device. They can also express themselves by means of a sign language transcriber 14 or by detection of brain activity 16.

The connected objects can be of different natures, such as for example industrial robots, service robots, miniaturized sensors associated with clothes 17 such as for example combinations for professional use, sensors and actuators located in local offices. dwelling 34, vehicles 36, factories and offices 31, in the public domain 32, etc. Sources and recipients may further be digital services provided by remote servers.

In the rest of the description, the term "natural language" will designate a language naturally used by human beings such as English, French, Mandarin Chinese, etc., and "target natural language" will designate a natural language selected from among several natural languages depending on its area of use, its range of use or the ease of its automatic learning. It can be modified by configuration, election or any other means to take into account the specificities of the sources and recipients and the intended application.

By language, we will designate a formal language comprising a set of symbols used to construct the different structures. It is defined by a formal grammar, such as algebraic grammars and computer languages, and is likely to be parsed by automata. A typical example of a built-in language is application programming interfaces (APIs) consisting of a set of classes, functions, parameters, coding conventions, and so on. whereby connected objects and digital services provide services to other software applications.

FIG. 2 represents a layered architecture of the platform 1 according to the invention. This architecture comprises a first control layer 40 which groups together units that provide the conventional access control functions to platform 1, in particular the centralized authentication and access authorization functions for users of all kinds. , metering for statistical, billing, directory, and security reasons, and a second layer grouping management units 42 which provide the centralized functions of communication supervision, selection of a target natural language, updates of data processing software exchanged via platform 1, statistical calculations, availability management and improvements. The control units 40 and management 42 are for example software applications downloaded from local or remote servers controlled by the manager of the platform 1.

The functions described above may reside within the control layer 40 or outside this layer and be interfaced with it. The control layer 40 also performs the function of handling exceptions in case of failure of an ambiguity resolution procedure found during the exchange of information via the platform 1 or in case of failure of a transaction, for example, in the event of repeated refusals by a connected object to provide information or to execute an order. The architecture of FIG. 2 comprises a bidirectional natural language exchange unit 50 connected to the communication devices associated with each source and to each recipient registered on the platform 1, and a set of processing units comprising a software unit and and / or media adaptation hardware and protocol 52, a software and / or hardware language conversion unit 54, a software and / or hardware control and ambiguity resolution and relevance 56, a software unit and and / or bidirectional hardware 58 for converting a natural language used by a source or a recipient into a selected target natural language, and for aligning the units of physical values and time units contained in the exchanged information, and an interface bidirectional 60 which realizes the adaptation between the bidirectional unit of exchange in natural language 50 and each bidirectional unit the 58 of conversion of a natural language.

The software and / or hardware media adaptation and protocol 52-60 units can be implemented in a distributed way on the communication and data processing terminals (servers, computers, tablets, smartphones, boxes, ...) used by each source and each recipient connected to the platform 1, or implemented in one or more local or centralized platforms, or partially implemented on the terminals, local platforms and centralized platforms.

For the sake of clarity, in the following description, identical references will designate the elements that provide identical functions in the various implementations and applications of the invention.

The different units of the architecture of Figure 2 will be designated by the following acronyms: • CTRL (Control layer, in English), for the control layer 40, • MNGT (Management module, in English) for the layer grouping units 42 which provide the centralized functions of communication supervision, selection of a target natural language common to humans, connected objects and digital services, updates of data processing software exchanged via platform 1, statistical calculations, availability management and improvements ...), • NLXS 50 (Natural Language eXchange Services, in English) for two-way natural language exchange units, • MPA-x 52 (Media and Protocol Adapter, in English) for media and protocol adaptation units, x indicating the source or recipient type with which the MPA unit is associated, x = H for humans, x = O for nnected, and x = S for digital services), • NLAC 54 (Natural Language to API Converter) for language conversion units, • LARC 56 (Language Ambiguity and Relevance Controller) for software units and / or hardware for control and resolution of ambiguity and relevance of information exchanged, • LUTA 58 (Language, Units and Time Alignment, in English) for units, software and / or hardware, bidirectional conversion of a natural language used by a source or a recipient in the selected target native language • IF_NLX 60 (Interface with the Natural Language eXchange Services, in English), for bidirectional interfaces.

As illustrated in FIG. 3, the different units of the platform of FIG. 1 can access resources provided by remote servers such as, for example, a linguistic base 70, a translation service 72 or a directory service. The different units automatically connect, if necessary, to these remote servers 70, 72 74 via a description unit 76 of the connected object or the digital service to obtain: elements of description of the connected object or the service they are responsible for: identity, description, capabilities, parameters, units, syntax, API, etc. • "language base" external resources such as translation services, ontology databases and lists of synonyms, hyponyms, hyperonyms, natural language corpora and various databases to accomplish or perfect their respective functions, • others services, for example directory services, online translation and miscellaneous databases may also be used.

FIG. 4 schematically represents the distribution of the units making up the platform 1 architecture on the side of a source 2, a human being, equipped with a first communication and data processing terminal assembly 82 (a computer, a tablet or a Smartphone for example) and on the side of a recipient 6, a weather station for example, equipped with communication and data processing functions and supplemented by functions hosted by a central platform 85. The terminal set of communication and data processing for the human user 2 comprises an interface of the keyboard, screen, microphone, earphone, camera, etc. type. to the user, an MPA unit 52 for media adaptation and protocol, an interface IF_NLX 60 for communicating in natural language via the NLXS module 50 and a transceiver to the transit network 84. The set of communication and data processing method for the connected object comprises the devices necessary for exchanging and processing the messages in language constructed on the home network.

The central platform 85 includes a transmitter / receiver 83 to the connected object's home network, a media adaptation and protocol MPA 52, a NLAC 54 language conversion unit, a LARC 56 control and resolution of ambiguity and relevance of the information exchanged, a LUTA unit 58 for converting a natural language used by the target natural language source, an interface IF_NLX 60 for communicating in natural language via the NLXS module 50 and a transmitter / receiver to the transit network 84.

FIG. 5 diagrammatically represents the distribution of the units composing the architecture of the platform 1 on the side of a source 2, a connected boiler equipped with communication and data processing functions and supplemented by functions hosted by a central platform 85, and on the side of a recipient 6, a weather station for example, equipped with communication and data processing functions and completed by functions hosted by a central platform 85.

The communication and data processing functions include the necessary devices for exchanging and processing messages in language built on the home network.

In operation, the bi-directional NLXS 50 natural language exchange units ensure the exchange of information in natural language between different human interlocutors, robots, objects or digital service platforms.

These units include known means of communication, such as SMS (Short Message Service) or MMS (Multimedia Message Service) services, email services, instant messaging services, or any other suitable application for exchanging information in natural language. .

Media adaptation and MPA-x 52 protocol units such as, for example, a low power wide area network (LPWAN) radio adapter with its transport protocols (COAP, MQTT ...), a wifi interface or an interface Ethernet with its software drivers and its transport protocols (HTTP, TLS, ...) make the link between the users (humans, objects or services) connected to the platform 1 and the NLAC 54 units. In the case of human users these units MPA-H 52 support written exchanges (texts), voice or any other type depending on the nature of the interaction (eg sign language). In the case of communicating objects and digital services, the MPA-0 52 units implement the object programming protocol (API) and the possible adaptation to the media with which the objects are connected. These MPA-0 52 are for example software functions that generally implement the 'client' side of the interface with the connected object, the latter being considered as a (data) server in a client / server architecture for example Representative State Transfer (REST) type.

The NLAC language conversion units 54 provide the transformation between, on the one hand, the information in the target natural language, and on the other side, the information in the digital format for controlling the connected objects or the format of the data exchanged with the data. digital services. Additional information such as images, sounds, files, indicators of emotions or prosody for example, can optionally be added to the information in natural language.

The units for controlling and resolving the ambiguity and relevance of the information exchanged LARC 56 are installed in the receivers of the sources 2 and the recipients 6 and are configured to analyze the information received from the bidirectional units LUTA 58 on the one hand and from NLAC language conversion units 54 to determine the level of ambiguity of the messages exchanged in the target natural language and to ensure that the NLAC units 54 will be able to correctly perform the desired language conversion. In the case where the LARC units 56 judge that the level of ambiguity or inconsistency is too high, they perform an ambiguity resolution procedure, for example by asking the source of the message to repeat the request or by itself. asking to reformulate it differently. In the event of repeated failures of this procedure, the LARC units 56 signal the abandonment of the exchange at the source of the information as well as the control units 40 and the management units 42.

The bidirectional units LUTA 58 for conversion of a natural language used by a source or a recipient 6 into a selected target natural language are configured to convert, where necessary, the message language so as to use the natural language of the message. human user or target natural language selected to communicate with digital objects and services. These LUTA 58 bidirectional units also perform conversion of units (eg, Celsius / Fahrenheit or centimeters / inches, etc.), dates, and time (especially time zones and day change).

The bidirectional interfaces IF_NLX 60 perform the adaptation between the NLXS units 50 and the LUTA units 58. In particular, they choose the most suitable medium among the NLXS units 50 when there are several (for example an SMS service rather than an e-mail service) and ensure the transmission and reception of digital messages to and from these different media. For example, the IF_NLX 60 interfaces are standard functions such as e-mail client (google ©, outlook ©, yahoo © ...), microsoft skype © chat client, google hangout ©, sms / mms client, etc.

The NLAC 54, LARC 56 and LUTA 58 units may optionally automatically connect to the remote 70-74 servers to obtain, in real time or deferred, external resources such as translation services, ontology databases and mailing lists. synonyms, hyponyms, hyperonyms, corpus of natural language and various databases.

FIG. 6 describes in detail the successive processing of the request of FIG. 5 by the different units of the architecture of platform 1. At step 200, the request formulated by source 2 is intercepted by the unit MPA. H of media adaptation and protocol 52 assigned to source 2.

In the example of Figure 6, the language of the intercepted query is a human natural language. In this case, in step 200, the MPA-H unit 52 transmits the intercepted query "What temperature is it now?" To the bidirectional interfaces IF-NLX 60 without modifications. In step 202, the bidirectional interface IF-NLX 60 transmits the request to the bidirectional unit of exchange in NLXS natural language 50. The transmission is carried out for example by means of an email service to the email address my_weatherstation@messagerie.com, where "mail" is the name of the email service used by the weather station.

It should be noted that the NLXS unit 50 can also use an SMS service, an instant messaging service or any other application that makes it possible to exchange digital information in natural language and in real time or in a very short time. In the example of FIG. 6, the unit NLXS 50 is a public e-mail service with which the weather station 6 is previously registered with the e-mail address my_weatherstation@messagerie.com. The NLXS unit 50 receives the request from the bidirectional interface IF-NLX 60 on the email client my_weatherstation@messagerie.com and transmits said request to the bidirectional interface IF-NLX 60 implemented on the side of the weather station 6 to the step 204. In step 206, the bidirectional interface IF-NLX 60 implemented on the side of the weather station 6 receives the request on the email client my_weatherstation@messagerie.com and transmits said request to the bidirectional unit LUTA 58 implemented from 6. At step 208, bidirectional unit LUTA 58 receives the query "What temperature is it today? And performs the conversion of the natural language used, French in this case, to the selected target natural language, which is for example English in this case, and then transmits the converted request in English (eg "how warm is it today?" ) At the LARC control unit 56 implemented on the side of the weather station 6. At the step 210, said LARC control unit 56 receives the request, the analysis and, in case of ambiguity, performs a procedure of resolution of ambiguity and relevance of the information exchanged. In case of unambiguity, the LARC control unit 56 transmits the target natural language request, English, to the NLAC language conversion unit 54 installed on the weather station side 6. At step 212, NLAC 54 converts the request to the target natural language "How warm is it today?" In language built using «'s" getmeasure "command associated with weather station 6: http://my_weatherstation.com/api/getmeasure,access_token-[TOKEN]&device_id-[DEVICEID]&type-Temperature. ". The NLAC unit 54 then transmits the temperature measurement command to the MPA-0 media adaptation and protocol unit 52 implemented on the weather station side 6. At the step 214, said adaptation unit MPA-0 52 of media and protocol transmits the request to the weather station 6 on the media and the protocol used to reach the weather station 6.

FIG. 7 illustrates the response of the weather station 6 to the request of the source 2. Upon receipt of the temperature measurement command, the weather station 6 performs the measurement requested and generates the message "status": "ok" , "body": [{"beg_time": 123456500, "value": [69.8]}]}, then transmits this message, in step 300, to the MPA-0 unit 50. In step 302, the unit MPA-0 50 receives the message from the weather station 6 adapts to the media (radio, Ethernet, etc.) and transport protocols (http, tls, mqtt, coap ...) and transmits it to the NLAC unit 54 installed on the side of the weather station 6. In step 304, said NLAC unit 54 receives the message in constructed language transmitted by the unit MPA-0 50, automatically converts it into target natural language, English in this example, "the current temperature is 69.8 ° F", and transmits the target natural language message to the LARC control unit 56 installed on the weather station side. At step 306, the LARC control unit 56 receives the target natural language message "the current temperature is 69.8 ° F", and transmits it without processing to the bidirectional unit LUTA 58 installed on the weather station side 6. At step 308 the bidirectional unit LUTA 58 receives the target natural language message "the current temperature is 69.8 ° F" and performs the conversion of the target natural language into natural language of the source 2, the French in this case, then performs a converting the unit of measurement from degrees Fahrenheit to degrees Celsius to obtain the user-defined natural language message "temperature is 21 degrees Celsius", and then transmits this message to the bidirectional interface IF-NLX 60 cooperating with the weather station 6 At step 310, the bidirectional interface IF-NLX 60 sends the user-natural language message to the client whose email address is alice@aliceaddress.com. In step 312, the NLXS unit 50 receives the message from the bidirectional interface IF-NLX 60 and retransmits it to the email client at the address source@sourceaddress.com. In step 314, the bidirectional interface IF-NLX 60 in charge of the source 2 transmits the content of the message in natural language user "the temperature is 21 degrees Celsius" to the unit MPA-FI of media adaptation and protocol 52 installed in the terminal of the source 2. In step 316, the unit MPA-H 52 delivers the message in natural language user "the temperature is 21 degrees Celsius" at the source 2, or by a voice message either by a display on the terminal screen of source 2.

FIG. 8 represents the processing steps applied to a request sent by a boiler connected to the weather station. The boiler can for example be programmed to request information from the weather station 6 at regular intervals in order to perform an automatic adjustment of its operating parameters by adapting its power to the measured temperature.

The boiler and the weather station exchange the messages by means of their respective communication and data processing assemblies 85 shown in FIG. 5. In step 402, the boiler 400 transmits to the media adaptation unit and protocol MPA-0 52 a query in the built language and using the media and the protocols it implements: "GET: http: // xxxx / api / gettemperature? ". In step 404, the unit MPA-0 52 transmits the request in the boiler built-up language to the NLAC language conversion unit 54 in charge of the boiler and automatically converts it to step 406, in a previously selected target natural language message, for example English: "what is the temperature now? And then transmits the target natural language query to the LARC 56 ambiguity and relevance control and resolution unit. In step 408, the LARC unit 56 transmits the target natural language message "what is the temperature now? Without modification to the natural language conversion LUTA unit 58 in charge of the boiler 400. In step 410, the LUTA unit 58 transmits the target natural language message "what is the temperature now? Without modification to the bidirectional interface IF-NLX 60 in charge of the boiler 400. In step 412, the bidirectional interface IF-NLX 60 transmits the target natural language message to the NLXS unit 50 to be delivered to the email client my_weatherstation@messagerie.com, where "mail" is the name of the mail service used by the weather station. In step 414, the natural language exchange unit NLXS 50 receives the target natural language message and transmits it to the bidirectional interface IF-NLX 60 in charge of the weather station 6. The bidirectional interface IF- NLX 60 receives the message on the client e-mail my_weatherstation@messagerie.com and forwards it, in step 416, to the LUTA unit 58 installed on the weather station side 60. At the step 418, the LUTA unit 58 transmits the message in natural language target "what is the temperature now? Without modification to the LARC unit 56 in charge of the weather station 6. At step 420, said LARC unit 56 performs an ambiguity analysis of the received message in the target natural language.

If the LARC unit 56 judges that the received message is not ambiguous and is consistent with the role and the capabilities of the object it is responsible for, it transmits it without modification to the NLAC unit 54 of the weather station. At step 422, the NLAC unit 54 of the weather station 6 converts the received message to the target natural language "what is the temperature now? To the constructed language of the weather station, in this case a "getmeasure" command: GET: http://my_weatherstation.com/api/getmeasure,access_token-[TOKEN]&device_id-[DEVICEID]&type- Temperature "and transmits the message obtained to the media adaptation unit and protocol MPA-0 52 in charge of the weather station 6. At step 424, the unit MPA-0 52 transfers the command in constructed language at the weather station 6 using the protocols and the media used by the weather station 6. Upon receipt of this command, the weather station 6 generates a response to the request.

FIG. 9 represents the processing steps applied to the response to be sent by the weather station 6 to the boiler. In step 500, the weather station sends the temperature measured by the response to the "getmeasure" command, expressed in the associated API language, to its MPA-0 unit 52, using the protocols and the 6. In step 502, the unit MPA-0 52 transmits the message received in the built-up language of the weather station to the NLAC language conversion unit 54 in charge of the weather station 6. In step 504, the NLAC unit 54 automatically converts the message into a constructed language into English text which is the previously selected target natural language: "the current temperature is 69.8 ° F", and transmits the response, in English, to the LARC unit 56 in charge of the weather station 6. At step 506, the LARC unit 56 in charge of the weather station 6 transmits the target language message "the current temperature is 69.8 ° F" without modification at unit LUTA 58. At step 508, the bidire unit LUTA 58 receives the target language message "the current temperature is 69.8 ° F", preserves the message in English since it is the natural language used by the boiler, then performs, if necessary, a conversion of the degree of degrees Fahrenheit in degrees Celsius to obtain the target natural language message "the current temperature is 21 ° C", and then transmits this message to the bidirectional interface IF-NLX 60 in charge of the weather station 6. A step 510, the bi-directional interface IF-NLX 60 of the weather station 6 transmits this target natural language message to the natural language exchange unit NLXS 50 for delivery to the email address heather@heatheraddress.com ( e-mail address assigned to the boiler) In step 512, the NLXS unit 50 receives the target natural language message and forwards it to the bidirectional interface IF-NLX 60 in charge of the boiler. It transmits it, in step 514, LUTA unit 58 in charge of the boiler. In step 516, the LUTA unit 58 transmits the target natural language message "the current temperature is 21 ° C" without modification to the LARC unit 56. In step 518, said LARC unit 56 performs an analysis. ambiguity of the received message.

If the LARC unit 56 judges that the message received in the target natural language is unambiguous and consistent, it transmits it without modification to the NLAC unit 54 in charge of the boiler. In step 520, the NLAC unit 54 in charge of the boiler 400 converts the target natural language response "the current temperature is 21 ° C" to the boiler's built-in language, in this case the response to the command. 'gettemperature': {"status": "ok", "body": [{"beg_time": 123456500, "value": [21.0]}]}, and transmits the converted response to the media adaptation unit and protocol MPA-0 52 in charge of the boiler. In step 522, the MPA-0 unit 52 transmits this message to the boiler using the protocols and media used by the boiler 400.

FIG. 10A illustrates the essential steps of the processes applied by the LUTA unit 58 to a message transmitted in natural language by a remote source to a recipient via the IF-NLX unit 60 in charge of the source. In step 598, the message from the remote source is transmitted in natural language to the LUTA unit 58 via the IF-NLX unit 60. At the step 600 the LUTA unit 58 converts the natural language of the remote source to the selected target natural language. In step 602 the LUTA unit 58 aligns the units used by the remote source with those used by the recipient. In step 604 the LUTA unit 58 aligns the date, time and duration references used by the remote source with those used by the recipient. In step 606, the LUTA 58 transmits the message processed by steps 598-604 to the recipient's LARC 56.

FIG. 10B illustrates the essential steps of the processes applied by the LUTA unit 58 to the target natural language message transmitted from a local source to a recipient. In step 610 the target natural language message is transmitted to the LUTA unit 58 via the LARC unit 56 in charge of the local connected object. In step 612, LUTA 58 aligns the date, time, and duration references used in the message with those used by the remote party. In step 614, the LUTA unit 58 aligns the units used in the message with those used by the remote party. In step 616, the LUTA unit 58 converts the target natural language message to the natural language used by the remote party. In step 620 the LUTA unit 58 transmits the natural language message used by the remote party to the IF-NLX unit 60.

Fig. 11 is a detailed flowchart of step 600 of converting natural language from the remote source to the selected target natural language. Upon receiving the natural language message transmitted by the remote source, in step 700, the recipient's LUTA unit 58 examines the message text to determine the natural language of the remote source.

If the natural language of the remote source is recognized, in step 702, the recipient's LUTA unit 58 checks whether the recognized language is the same as the previously selected target natural language.

If the natural language of the remote source is the same as the selected target natural language, the processing of Fig. 10A continues from step 602.

Otherwise, in step 704, the LUTA unit 58 in charge of the recipient 6 checks whether it is possible to locally, automatically, convert the natural language message from the remote source to the target natural language.

If such an automatic conversion is possible locally, in step 706, the LUTA unit 58 in charge of the recipient performs the conversion. The processing of FIG. 10A then continues from step 602.

Otherwise, in step 708, the recipient's LUTA unit 58 checks whether the conversion can be delegated to a remote translation server.

If an automatic natural language conversion from the remote source to the target natural language can be delegated to a remote translation server, in step 710, the remote translation server performs the conversion. The processing of FIG. 10A then continues from step 602

Otherwise, in step 712, the LUTA 58 in charge of the recipient 6 generates a failure message and transmits this message to the remote source, to the control unit 40, and to the management unit 42.

If at the end of the test of step 700 the natural language of the remote source is not recognized by the LUTA unit 58 in charge of the recipient, in step 714, the LUTA unit 58 checks whether the language the remote source is indicated in its registration file on platform 1.

If so, the natural language alignment procedure of the remote source on the selected target natural language continues from step 702.

Otherwise, in step 716, the LUTA 58 in charge of the recipient 6 checks whether the natural language of the remote source is indicated in an external directory.

If so, the natural language alignment procedure of the remote source on the selected target natural language continues from step 702.

Otherwise, in step 718, the LUTA unit 58 in charge of the recipient 6 checks whether the natural language of the remote source 2 could be learned by examining the previous messages.

If so, the natural language alignment procedure of the remote source on the selected target natural language continues from step 702.

Otherwise, in step 712, the LUTA 58 in charge of the recipient generates a failure message and transmits this message to the remote source, to the control unit 40, and to the management unit 42.

Figure 12 is a detailed flowchart of step 602 of Figure 10 for aligning units used by the remote source with those used by the recipient. In step 720, the recipient's LUTA unit 58 checks whether the length, area, and volume units present in the message received from the remote user are identical to the units used by the local user receiving the message. .

Otherwise, in step 722, the recipient's LUTA unit 58 converts the length, area, and volume units of the received message into units of length used by the recipient's local user of the message.

If yes, In step 724, the recipient LUTA 58 unit checks whether the mass and weight units are identical to the units used by the local user receiving the message.

If the mass and weight units are not aligned, in step 726, the recipient's LUTA 58 unit converts the mass and weight units of the received message into units used by the local user receiving the message. .

If the mass and weight units are aligned, in step 728, the recipient LUTA unit 58 checks whether the temperature units are identical to the units used by the local user receiving the message.

If the temperature units are not aligned with those of the message receiving local user, in step 730, the recipient's LUTA 58 unit converts the temperature units of the received message into temperature units used by the receiver. local user receiving the message.

If the temperature units are aligned, in step 732, the recipient LUTA 58 unit checks whether the date, time, and duration units are the same as the units used by the local user receiving the message.

If the date, time, and duration units are not aligned, in step 734, the recipient LUTA 58 transforms the date, time, and duration units into units used by the recipient. local user receiving the message.

If the date, time, and duration units are aligned, in step 736, the procedure for aligning the natural language of the remote source to the selected target natural language continues from step 604 of the Figure 10A.

Fig. 13 is a detailed flowchart of step 604 for aligning the date, time, and duration references used by the remote source with those used by a connected object or a digital service. In step 740, the LUTA 58 in charge of the recipient 6 checks whether the date references used by the connected object or the digital service providing the message are identical to the references used by the local user receiving the message.

Otherwise, in step 742, the recipient's LUTA 58 in charge of the recipient transforms the received date references into date references used by the local user receiving the message. In step 744, the recipient's LUTA unit 58 checks whether the time references used by the connected object or the digital service are aligned with that of the local user receiving the message.

Otherwise, in step 746, the recipient's LUTA unit 58 transforms the received time references into time references used by the receiving local user of the message.

If so, in step 748, the recipient LUTA 58 unit checks whether the duration references are identical to the references used by the local user receiving the message.

Otherwise, in step 750, the recipient's LUTA unit 58 transforms the duration references of the received message into time references used by the local user receiving the message. In step 752, the recipient's LUTA unit 58 transmits the message to the LARC unit 56 installed in the receiver of the message receiver to analyze the ambiguity of the received information.

Fig. 14 is a detailed flowchart of step 612 for aligning the date, time, and duration references used by a local source sending a target natural language message with those used by the recipient. In step 760, the source LUTA unit 58 checks whether the date references used by the recipient user of the received message are identical to the references used by the local source.

Otherwise, in step 762, the source LUTA 58 in charge of the source transforms the date references of the message into date references used by the recipient.

If yes, in step 764, the source LUTA 58 in charge of the source checks whether the time references are identical to the time references used by the remote source.

Otherwise, in step 766, the source LUTA 58 in charge of the source transforms the message's clock references into time references used by the recipient.

If yes, in step 768, the source LUTA 58 in charge of the source checks whether the message duration references are identical to the duration references used by the recipient.

Otherwise, in step 770, the LUTA 58 in charge of the source transforms the message duration references into time references used by the recipient.

If so, in step 772, the source-supporting LUTA 58 transmits the target NAT message from the recipient to the function for performing alignment to the recipient's preferred units.

Fig. 15 is a detailed flowchart of step 614 of aligning the units used by a local source, transmitting a target natural language message, with those used by the recipient. In step 780, the LUTA unit 58 in charge of the local source checks whether the units of length, area and volume are identical to the units used by the recipient of the message.

Otherwise, in step 782, the local source LUTA 58 transforms the length, area, and volume units of the message into a length unit used by the destination user.

If yes, in step 784, the LUTA unit 58 in charge of the local source checks whether the mass and weight units are identical to the units used by the user receiving the message.

Otherwise, in step 786, the LUTA unit 58 in charge of the local source transforms the mass and weight units of the message into units used by the recipient user of the message.

If yes, in step 788, the LUTA unit 58 in charge of the local source checks whether the temperature units are identical to those used by the user receiving the message.

Otherwise, in step 790, the LUTA unit 58 in charge of the local source transforms the temperature units of the message into units used by the recipient 6.

If so, in step 792, the local source LUTA 58 checks whether the date, time, and duration units are the same as those used by the recipient user of the message.

Otherwise, in step 794, the local source LUTA 58 converts the date, time, and duration units of the message into units used by the message recipient user.

If so, at step 796, the local source LUTA unit 58 transmits the received target natural language message to the function for performing alignment to the remote user's natural language.

Fig. 16 is a detailed flowchart of step 616 of source alignment of the target natural language to the natural language of the remote user. In step 800, the LUTA unit 58 in charge of the local source checks whether the natural language of the remote user is indicated in his registration file on the platform 1.

If so, in step 802, the local source LUTA 58 checks whether the natural language of the indicated remote user is identical to the target natural language.

Otherwise, in step 804, the LUTA unit 58 in charge of the local source checks whether a local automatic conversion to the remote user's language is possible.

If so, in step 806, the local source LUTA unit 58 performs the local automatic translation of the target natural language to the remote user's language and transmits, in step 808, the natural language message. the remote user to the IF-NLX module 60 of this remote user.

If the natural language of the remote user is not indicated in his registration folder on platform 1, in step 814, the LUTA unit 58 in charge of the local source checks whether the natural language of this user remote is indicated in an external directory.

If so, the target natural language alignment procedure to the remote user's natural language continues from step 802.

Otherwise, the LUTA unit 58 in charge of the local source transmits, in step 816, the target natural language message to the IF-NLX module 60 in charge of the local source for transmission to the remote user.

The messages in a target natural language exchanged between the bidirectional interfaces IF-NLX 60 implemented respectively on the side of a source and the side of a recipient may include grammatical or syntactic ambiguities. These messages are transmitted to the LARC ambiguity and relevance control and resolution units 56 respectively from the LUTA bidirectional units 58 and from the NLAC language conversion units 54 respectively installed on the source side and the recipient side to determine the level of ambiguity of the messages exchanged and to ensure that the NLAC 54 units will be able to correctly perform the desired language conversion.

FIG. 17 represents a detailed view of an LARC 56 ambiguity and relevance resolution unit. It comprises a transmission block 820, a resolution block 822 and a reception block 824.

The transmission block 820 comprises a first multiplexer 826 intended to keep a copy of the messages sent by the local user and a second multiplexer 828 intended to transmit messages to the remote user through the LUTA module 58.

The resolution block 822 includes a grammatical ambiguity resolution module 830, an inconsistency resolution module 832, a resolution message response module 834, and a user assistance module 836.

The reception block 824 comprises a message parsing module 840, an ambiguities resolution message intercepting module, confirmations and inconsistencies 842, a user assistance request message interception module 844. , and a message coherence analysis module 846.

Fig. 18 is a flowchart of the steps of control, by the LARC unit 56, of ambiguity and relevance of a target natural language message from a remote user, and received from a bidirectional LUTA unit 58 in charge of the recipient. In step 850, the message grammar parsing module 840 of the LARC unit 56 in charge of the recipient checks whether the received message is sufficiently compliant with the grammar (lexicon, syntax, etc.) of the target natural language.

If the received message is not sufficiently compliant, in step 852, the module 840 transmits the message to the grammatical ambiguity resolution module 830 which generates a grammar ambiguity request message in the target natural language and transmits it. to the remote user through the bidirectional unit LUTA 58 in charge of the recipient.

If the received message is sufficiently compliant, in step 854, the module for intercepting the messages for resolving ambiguities, confirmations and inconsistencies 842 checks whether the message received is a request message for resolving grammatical ambiguities, confirmations or inconsistencies.

If so, in step 856, the module 842 transmits the message to the resolution message response module 834 which generates a response message to the target language grammar ambiguity resolution request and transmits it to the user. remote through the LUTA 58 unit.

Otherwise, in step 858, a user assistance request message interception module 844 checks whether the message is a support request from the remote user.

If the message is a request for assistance from the remote user, in step 860, the module 844 transmits the message to the user assistance module 836 which generates a response message to the assistance request. in the target natural language and transmits it to the remote user through the LUTA unit 58.

Otherwise, in step 862, the message coherence analysis module 846 checks whether the received message is consistent with the nature and capabilities of the connected local user, object, or service.

If the message is sufficiently coherent, it is transmitted to the NLAC 54 language conversion unit.

Otherwise, in step 864, the module 846 transmits the message to the inconsistency resolution module 832 which generates a request message for resolving confirmations and inconsistencies and transmits the message to the remote user through the LUTA module 58.

The natural language messages exchanged between a source 2 and a recipient 6 transit via the NLAC language conversion units 54 which are responsible for performing the transformation between on one side the target natural language information to a constructed language used by a user. connected object or a digital service and on the other the messages in constructed language (digital format for managing connected objects or digital format for piloting digital services) in target natural language.

Figures 19 and 20 illustrate the steps to perform these transformations respectively in the first case and in the second case.

Referring to Fig. 19, upon receipt of a target natural language message transmitted to a connected object or digital service by a remote user, the NLAC unit 54 in charge of the connected object or digital service stores the message received at step 870 to improve the elaboration of the possible target natural language response. In step 872, the natural language used in the stored message is converted to the constructed language of the connected object or service. A check of this conversion is performed at step 874.

If the conversion is judged successful, in step 876, the NLAC unit 54 transmits the constructed language message of the connected object or service to the supported media adaptation and protocol adaptation module MPA-0. connected object or digital service.

Otherwise, in step 878, the NLAC unit 54 transmits a circumstantial error message to the target natural language remote user through the LARC module 56, and to the CTRL 40 and management control units 42.

Referring to Fig. 20, upon receipt of a constructed language message transmitted by a connected object or digital service, at step 880, the NLAC 54 in charge of the remote user checks whether the received message is an error message or not.

If so, at step 882, said NLAC unit 54 issues a circumstantial error message to the target natural language remote user through the LARC unit 56, and to the CTRL 40 and management 42 control units.

Otherwise, in step 884, the NLAC unit 54 converts the received message into the constructed language into the target natural language. A check of this conversion is performed at step 886.

If the conversion is judged successful, in step 888 the NLAC module 54 transmits the target natural language message to the recipient user through the LARC module 56.

Otherwise, in step 882, the NLAC unit 54 transmits a target natural language error message to the remote user through the LARC module 56 as well as to the CTRL 40 and management control units 42.

Note that the resolution of ambiguities is done according to a strategy of which depends on the level of problem. Thus, it may consist in asking the remote user to: • Repeat the message; • Reformulate the message; • Confirm the message by indicating what has been understood; • Reformulate the message by indicating which word (s) are (are) not understood; • Reformulate the message by recommending that it be simplified; • Reformulate the message by indicating that there is a risk of multiple interpretation; • Reformulate the message by indicating which word (s) or concept (s) do not apply to the communicating object or the digital service; • Etc.

For each of the above strategies, the units for controlling and resolving the ambiguity and relevance of the exchanged information are configured to use sufficiently diverse natural language expressions to not tire a human user. These expressions will also be simple enough to be understood by both a remote user of human type as well as the interception modules of ambiguities resolution messages, confirmations and inconsistencies 842 equipping LARC units connected objects and services.

The strategy for resolving ambiguities can evolve either if the previous strategy did not provide a satisfactory solution or to avoid tiring a human distant user

After a given number (possibly variable) of unsuccessful attempts, the ambiguity resolution function may declare the abandonment of the transaction by signaling it to the remote user as well as the CTRL 40 and management control units 42.

All or part of the data (steps, messages, strategies, etc.) used and generated by the ambiguity resolution function are stored for later use, in particular by the management unit of the management unit improvements 42.

It should be noted that the response to ambiguity resolution messages, confirmations and inconsistencies is activated by the interception function of the ambiguity resolution messages, the confirmations and the inconsistencies of the reception block, for example when receiving the reception block. a request for repetition, confirmation, etc. It also has a copy of the original message that has been emitted from the block and is intended to eliminate ambiguities or inconsistencies. Depending on the resolution strategy chosen by the functions to resolve inconsistencies, confirmations or remote ambiguities, the answer function will consist, for example, in: • Repeating the message; • Reformulate the message; • Specify the message according to the indications given by the distance resolution function; • Simply confirm the message; • Confirm understanding only at the remote function of the message; • Abandon the transaction; • Etc.

The response function to the resolution messages may change if it finds that the previous attitude has not brought a satisfactory solution or to avoid boring a human remote user.

After a given number (possibly variable) of unsuccessful attempts, the resolution message response function may declare the abandonment of the transaction by signaling it to the remote user as well as the CTRL 40 and management control units 42.

All or some of the data (steps, messages, attitudes, etc.) used and generated by the resolution message response function are stored for later use, in particular by the management unit of the management unit improvements. .

User assistance.

The user assistance function is activated by the interception function of the assistance request messages from the reception block. These requests for assistance can be of various kinds, for example: • Information on the nature, identity and capacity of the communicating object or the digital service; • Information on the operational status (ON / OFF) or the administrative status (enabled / disabled) of the object or service; • The list of actions that the object or service can undertake or information that it can provide; • Examples of natural language sentences to communicate with this object or service; • Tips for solving the most common problems; • What to do in an emergency situation; • Etc. The user assistance interface 836 receives and processes support requests according to their nature. It responds in natural language, possibly adding additional data (detailed documentation files, web links to tutorials, etc.).

Figure 21 schematically illustrates an exchange related to a request for assistance between two communicating objects, a boiler and a weather station. In this example, the target natural language selected is English.

As illustrated by this figure, the exchanges are between the receiving blocks 824 equipping the respective LARC units 56 of each connected object. For example, the boiler sends the target language message to the weather station "Can you tell me what are your capacities? ". On receipt of this message via its LARC unit 56, the weather station automatically generates, for example, the target natural language message "the mable to measure the current temperature and humidity" and sends it back to the boiler via the unit. LARC 56 of the latter.

Note that all or part of the data received and generated by the user assistance interfaces 836 are stored for later use, in particular by the management unit 42. The invention thus takes into account the constraints related to the environment. of each type of communication and exploits the fact that the natural language is the most adapted to convey rich information (pure data, contextual data, emotions, etc.) at the price of a certain ambiguity. Connected objects and digital services are configured to accept lexical and syntactic variations of messages, and to exchange between support for ambiguity tolerance in order to simplify and expand their communication capability. The invention thus takes advantage of the relative simplicity of communicating objects and digital services to move the constraint from humans to objects and services by means of natural language processing (NLP) insofar as these objects and communicating services most often perform a limited number of simple tasks (or at least specialized enough to be expressed simply). This is exploited by the invention to perform natural language comprehension functions restricted to the missions assigned to these objects and services. We thus realize the displacement of the constraint from the human persons (who must adapt to the artificial languages of the objects and services) towards the objects and services (which must adapt to the natural language of the humans).

It is possible to implement the invention from a different number of modules, some of which may be optional; Moreover, different groups can be made for practical or technological reasons, without changing the nature of the invention. It may also be envisaged to modify the order of some of the modules without significantly modifying the scope of the invention.

Claims (13)

A method of communication between a plurality of sources (2,6) and a plurality of recipients (2,6) capable of exchanging information, either in a constructed language or in a natural language, via an intelligent platform (1). ) having a plurality of distributed data processing units comprising at least one natural language exchange bidirectional unit (50), at least one first language conversion unit (54) and at least one first media and protocol adaptation (52) associated with each source, at least one second language conversion unit (54) and at least one second media adaptation and protocol unit (52) associated with each recipient, characterized by the following steps: • on the sending side, - intercepting by the first media adaptation unit and protocol (52) the information sent by at least one source to at least one recipient, - determining the type of language describing the intercepted information, and, if the language describing the intercepted information is a constructed language, - automatically converting said received information into a constructed language to the natural language using the first language conversion unit (54), transmitting said information in natural language to the recipient via the natural language NLX (50) bidirectional exchange module, and, on the receiving side, if the recipient's language is a built-in language, automatically converting the received information into natural language to the language constructed using the second language conversion unit (54), and then supplying the constructed language information to the recipient via the second media adaptation and protocol unit (52), if the recipient language is a natural language, provide the natural language information to the recipient. 2. Method according to claim 1 wherein said sources and said recipients are either humans (2) or connected objects (6) or digital services (30). 3. Method according to claim 2 further comprising a step of analyzing information exchanged in natural language between humans (2), connected objects (6) and digital services (30) connected via said intelligent platform (1), and a step of resolving ambiguities and inconsistencies identified by said analyzing step. 4. The method of claim 3 comprising a prior step of choosing a target natural language. 5. Method according to one of the preceding claims comprising a procedure for learning by the intelligent platform (1) modes of use by the sources (2, 6) and by the recipients (2,6) of the target natural languages and / or languages constructed in such a way as to improve the conversion performance and ambiguity resolution of a human natural language and a constructed language. The method of claim 5 wherein the learning procedure is performed automatically, in the background, without directly interfering with the conversion steps and ambiguity resolutions. 7. The method as claimed in claim 6, in which the learning procedure comprises the following steps: classifying the information exchanged as a function of the different sources (2,6); analyzing the contents of said exchanged information; progressively enriching at least one base; information used by all sources (2,6) and the set of recipients (2,6) of the same type or family. 8. The method as claimed in claim 7, in which, for the information exchanged which has required an ambiguity or coherence resolution procedure, the learning procedure further comprises the following steps: analyzing the contents of said information, progressively enriching at least one information base used by all the sources (2,6) and the set of recipients (2,6) of the same type or of the same family. 9. Intelligent platform (1) for communication between a plurality of sources (2,6) and a plurality of recipients (2,6) capable of exchanging information, either a constructed language or a natural language, comprising a plurality of distributed data processing units comprising at least one bi-directional natural language exchange unit (50), at least one first language conversion unit (54) and at least one first media and protocol adaptation unit (52) associated with the source, at least one second language conversion unit (54) and at least one second media adaptation and protocol adaptation unit (52) associated with the recipient, characterized in that: - the first media and protocol adaptation unit (52) is configured to intercept the information sent by at least one source to at least one recipient and to determine the type of language used for the information int ercepted, and - the first language conversion unit (54) is configured to automatically convert a message into a constructed language describing intercepted information to a natural language, - the bidirectional natural language exchange unit (50) is configured to transmit said information in natural language to the recipient; the second language conversion unit (54) is configured to automatically convert a natural language message to a constructed language if the recipient language is a constructed language. 10. Intelligent platform according to claim 9 wherein said sources (2,6) and said recipients (2,6) are either humans (2) or connected objects (6) or digital services (30). The intelligent platform of claim 10 further comprising - at least one selection unit of a target natural language, at least one bidirectional unit (58) for converting a message into a constructed language to a selected target natural language and vice versa - a control unit (56) and resolution of ambiguity and relevance of information exchanged. 12. intelligent platform according to one of claims 9 to 11 further comprising a learning unit of the modes of use by the sources (2,6) and by the recipients (2,6) of the target natural languages and languages constructed to improve the conversion performance and ambiguity resolution of a human natural language and / or constructed language. A computer program stored on a recording medium and having instructions for carrying out the method of claims 1 to 8 when executed by computer.