EP4028888A1 - Procédé de communication entre des entités logicielles via une api - Google Patents
Procédé de communication entre des entités logicielles via une apiInfo
- Publication number
- EP4028888A1 EP4028888A1 EP20768358.2A EP20768358A EP4028888A1 EP 4028888 A1 EP4028888 A1 EP 4028888A1 EP 20768358 A EP20768358 A EP 20768358A EP 4028888 A1 EP4028888 A1 EP 4028888A1
- Authority
- EP
- European Patent Office
- Prior art keywords
- version
- software entity
- transaction
- communication method
- signature
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000000034 method Methods 0.000 title claims abstract description 53
- 238000004891 communication Methods 0.000 claims description 49
- 230000005540 biological transmission Effects 0.000 claims description 14
- 238000004590 computer program Methods 0.000 claims description 4
- 230000004044 response Effects 0.000 description 12
- 230000006870 function Effects 0.000 description 8
- 230000000977 initiatory effect Effects 0.000 description 8
- 230000008901 benefit Effects 0.000 description 4
- 239000003999 initiator Substances 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 238000012545 processing Methods 0.000 description 3
- 230000009471 action Effects 0.000 description 2
- 238000013459 approach Methods 0.000 description 2
- 238000011161 development Methods 0.000 description 2
- 230000018109 developmental process Effects 0.000 description 2
- 230000009466 transformation Effects 0.000 description 2
- 230000003044 adaptive effect Effects 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 238000012360 testing method Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/541—Interprogram communication via adapters, e.g. between incompatible applications
Definitions
- 1 / invention relates to the field of application programming interfaces (API).
- API application programming interfaces
- API application programming interface
- Each exchanged message is structured in a manner suitable for transporting the information associated with the message (description of the fields, type of fields, etc.).
- a software entity which receives a message decodes said message through the structure description which has been defined in its own version of the API transaction.
- the type of data structure considered here is a set of fields which can each have a value. It is the value contained in a given field that allows specific processing following the use of the API.
- Each field is originally typed. This means that each field accepts a type of value, for example an integer, a character string or some other structure.
- a typed array is a sequence of fields of the given type.
- the structure is an ordered set of fields. It is also considered that the encoding and decoding of data structures is based only on their type which is described in parentheses. This consideration limits the number of possible types and removes the semantics of each field. This consideration should be taken into account insofar as the number of different possible fields is not limited.
- the message implemented can be:
- ID_request message only requires in return a value corresponding to JD.
- the second device in its software version, encodes its response in a structure made up of fields typed as follows: (integer) ID
- the first device sends the second device the data containing the value corresponding to ID.
- the second device in order to respond, builds its response with its structure, which therefore includes ID, Name, Maxbandwidth and Latency.
- the second device then sends its response.
- the first device On receipt of the response, the first device decodes the data.
- the values associated with the ID and Name fields match and are consistent.
- the decoding of the Latency field is in reality the value of the Maxbandwidth field of the known structure of the second device. Understanding of the message is therefore erroneous and can therefore lead to information mishandling.
- uBus which allows services to offer structured and strictly defined objects.
- the data can be requested or modified through a request which is a structured message to be sent.
- the structure can be requested from the communication bus. Depending on the feedback from this request, it is possible to adapt the processing to the description.
- the object of the invention is to ensure, in a simple, inexpensive and efficient manner, the compatibility of the exchanges of messages between two software entities communicating via an API.
- the communication method further comprising a transmission phase comprising the step of:
- a sending software entity to send a current message of a current version of the transaction, as well as a current signature of the current version; and a reception phase comprising the steps of:
- the receiving software entity checks on receipt of the current message that it is indeed implementing the version of the transaction used by the sending software entity, and it uses the structural description of the correct version to decode the current message.
- the communication method according to the invention therefore makes it possible to ensure that the messages transmitted are interpreted correctly.
- the communication method according to the invention is simple to implement, inexpensive, low consumption of bandwidth, and does not have the limitations of the solutions of the prior art.
- a communications method such as that which has just been described is also proposed, in which, during the configuration phase, the signature is obtained by implementing on the structural description of the version a hash function which is identical for all versions of the transaction.
- a communications method such as that which has just been described is also proposed, in which the current signature is transmitted to the receiving software entity while being included in the current message.
- a communications method such as that which has just been described is also proposed, in which, during the configuration phase, each software entity stores the objects in a version table.
- a communications method such as that which has just been described is also proposed, in which, during the configuration phase, the transmitting software entity and the receiving software entity exchange their version table, so that the the issuing software entity knows and uses the versions of the transaction implemented by the receiving software entity.
- a communications method such as that which has just been described is also proposed, in which the version table of the issuing software entity comprises at least one privilege identifier which identifies a privileged version of the transaction, associated with a first entity.
- receiving software which the sending software entity uses as a priority when the sending software entity communicates with the first receiving software entity.
- a communications method such as that which has just been described is also proposed, in which the version table of the issuing software entity comprises at least one default identifier which identifies a default version of the transaction, which the entity sender software is used as a priority when the sender software entity communicates with a second receiver software entity which is not associated with a privileged version in the version table of the sender software entity.
- a communications method such as that which has just been described is also proposed, in which each object comprises, in addition to the signature and the structural description of the version associated with said object, a preference indicator making it possible to evaluate and compare between they several versions to select an optimized version allowing to optimize the performance of the communication.
- a communications method such as that which has just been described is also proposed, in which the configuration phase comprises a step during which the hash function is negotiated between the software entities.
- a communications method such as that which has just been described is also proposed, in which the configuration phase comprises the step of defining a finite set of basic types intended to define the overall structures of the messages, and of associating a type identifier to each base type, so that the structural representation of each version includes a string of said type identifiers.
- each type identifier is a distinct character.
- a communications method such as that which has just been described is also proposed, in which the overall structure of at least one message comprises at least one structure of nested data.
- a communications method such as that which has just been described is also proposed, in which the finite set of base types comprises at least one base type intended to delimit the structure of nested data.
- an item of equipment comprising a software entity arranged to communicate via an application programming interface (API) which comprises at least one transaction, the software entity comprising a version table produced by the implementation of the steps of the phase of. configuration of the communication method according to one of the preceding claims, the software entity being furthermore arranged to implement the transmission phase and / or the reception phase of the communications method such as that which has just been described .
- API application programming interface
- a computer program is further provided comprising instructions which lead the above equipment to execute the configuration phase, as well as the transmission phase and / or the reception phase of the described communication method.
- a computer readable recording medium is also proposed, on which the computer program which has just been described is recorded.
- Figure 1 shows a table which associates basic types and characters
- FIG. 2 represents a message initiating a transaction
- Figure 3 shows a transaction response message
- FIG. 4 represents a table of versions of a software entity
- FIG. 5 shows a version table of a sending software entity which communicates with a receiving software entity
- FIG. 6 represents a version table of the receiving software entity
- FIG. 7 represents the dialogue between the sending software entity and the receiving software entity
- FIG. 8 shows the updated version table of the receiving software entity
- FIG. 9 represents a dialogue between two transmitting software entities and a receiving software entity;
- FIG. 10 represents the updated version table of one of the two sender software entities.
- the communication method according to the invention allows software entities to communicate with each other through a common medium via an API.
- Each software entity is possibly, but not necessarily, integrated in a separate piece of equipment.
- the form of the API is defined as follows.
- the API comprises a plurality of transactions each defined by a set of messages. Among the messages, a distinction is made between “initiating messages”, or “requests”, which may possibly be associated with other messages, which are then called “response messages”.
- the order and type of message is important and defines the transaction.
- Each message is itself made up of data. These data are structured, ie they form a set made up of fields.
- the use of the common medium requires a transformation of the data structure on sending, which is called “encoding”, as well as the inverse transformation, which is called “decoding”.
- Encoding a transformation of the data structure on sending
- decoding inverse transformation
- Each field of the data structure is typed so that it can be encoded and decoded during the transmission of the message from one software entity to another by means of this common medium.
- the type of a field is an element of a set which allows to define the way of encoding and decoding.
- a common medium a network socket or a pipe
- a series of bytes buffer.
- One way to encode information is to define a simple data structure, such as a TLV (for "Type, Length, Value").
- the encoding then consists in assigning a value on a predefined number of bytes (for example 1) for the Type, to consider the Length of the information on a predefined number of bytes (for example 1), and to set the Value as being a sequence of bytes.
- the encoding follows the order of the data structure to be sent.
- the decoding is based on the predefined points in order to traverse the sequence of bytes and to assign each value discovered to a field of the structure.
- the Type and the Length let you know how the Value part is to be extracted.
- Each software entity possibly implements several versions of each transaction. These versions can be different between the software entities, which can lead to an erroneous interpretation of the messages.
- the communication method according to the invention first of all comprises a configuration phase, implemented in each software entity during the instantiation of the API, and for each version of each transaction implemented by said software entity. Note that it is possible to reinstantiate an API with management of new API versions: the configuration phase is then implemented again.
- This configuration phase consists first of all in producing a structural description of each version of the transaction implemented by the software entity.
- the structural description includes an overall structure of each message that can be exchanged in the version of the transaction.
- the finite set of base types is used to fundamentally describe how data is represented atomically.
- a base type can represent a more specific object, for example a MAC address. It is possible to represent this MAC address with a succession of 6 unsigned 8-bit integers, but the order and consistency of this series of 8-bit unsigned integers is necessary for the definition of a MAC address.
- a type identifier is associated with each base type of the finite set of base types. Each type identifier here is a distinct character.
- a signed 16-bit integer, or 2 bytes is represented by the character 'b'.
- a 32-bit signed integer is represented by the character 'c'.
- An unsigned 64-bit integer, or 8 bytes is represented by the character 'h'.
- An IPv4 address is represented by the character ⁇ '.
- initiator message or “response message” allow specifying that the following message is intended to be sent at the initiation of a transaction, or to be used in response during the transaction. .
- each message includes a data structure.
- strl data structure below, coded in C language, contains 3 unsigned integers, the first two of which are 8 bits and the last 32 bits: struct strl ⁇ int8_t vall; int8_t val2; int32_t val3; ⁇ ;
- each message can also include a nested data structure.
- the str2 data structure below is a nested data structure: struct str2 ⁇ int8 vall; struct strl val2; intl6 val3;
- This str2 nested data structure contains a first 8-bit signed integer, the strl data structure presented previously, and a second 16-bit signed integer.
- str2_proto (" “a” “(” “a” “a” “c” ")” "b” ")"
- a character string is concatenated comprising, for each message of the version of the transaction, a sequence of ordered characters describing the overall structure of the message. This character string forms the structural description of the transaction version, which then completely describes the API transaction version and how a message exchange must be encoded and decoded.
- the character string is of variable size: its size will be large if the structure of the transaction is too.
- the transaction uses an initiator message which is called via the transaction_send_getInterface method comprising a parameter of type 'string', a character string with a maximum size of 16 bytes.
- the transaction is completed by a transaction_answer_getInterface response message consisting of a nested data structure named interface.
- This structure is made up of 3 fields: flags, name and stats.
- the type of the flag field is an unsigned 32-bit integer.
- the name field is of type 'string' with a size of 16 bytes.
- the stats field is a stats type structure. The latter is composed of two fields bytes_sent and bytes_received. These two fields are 32-bit unsigned integer.
- transaction_send_getInterface string name [16]
- transaction_answer_getInterface construct interface
- a signature is then produced which is representative of the structural description of the version of the transaction.
- a hash function is implemented here on the structural description of the version of the transaction.
- the hash function used is the same for all versions of all transactions, and for all software entities that communicate through the API.
- the hash function helps reduce the amount of information that needs to be sent to identify the structural description of the transaction version.
- the hash function is shared or negotiated between the software entities that communicate through the API so that the same can be identified.
- the FNV-la method can also be used, for example, which makes it possible to construct a 32-bit signature from a series of bytes or a string of characters.
- the construction of a message that can be transmitted over a medium is a series of bytes.
- the initiating message itself can be coded as follows:
- the initiator message 1 is represented in the form of a series of hexadecimal numbers corresponding to a series of bytes after an encoding used to be transmitted on the medium.
- the initiator message 1 called via the transaction_send_getInterface method, successively comprises an identifier 2 of the transaction, the signature 3 of the version of the transaction, and a piece of information to be transmitted 4 which is the “eth 0” parameter.
- the transaction identifier is encoded by a 32-bit integer, which in this example is equal to zero.
- Signature 3 of the transaction version is coded to be transmitted over an IP type network (most significant byte first).
- the parameter corresponding to the information to be transmitted 4 follows the identifier and the signature 3.
- the parameter is a string of simple characters, each character being simply added in its representation in byte. A series of zeros completes the parameter which has been described as being of size 16.
- the response message 5 successively comprises the identifier 6 of the transaction, that is to say zero, the signature 7, and information to be transmitted 8.
- the information to be transmitted 8 includes the entire nested data structure, i.e. the flags field 8a, the "eth 0" parameter 8b, the
- the software entity then saves all the objects in a version table.
- a preference indicator is added in each object which makes it possible to evaluate and compare several versions with one another in order to select an optimized version making it possible to optimize the performance of the communication.
- the preference indicator makes it possible to further specify the logic for selecting the version of the transaction to be used according to the use case.
- the preference indicator shows, for example, a greater or lesser number of transmissible parameters, or the date of implementation of the version.
- This additional preference indicator makes it possible, in the event of compatibility of multiple versions of the transaction on both sides, to select the version of the transaction most suited to the message to be transmitted.
- the preference indicator makes it possible, for example, to select the version which occupies the least space on the medium.
- the tree structure of FIG. 4 is a version table 10 of an issuing software entity.
- the API includes a first transaction A, a second transaction B and a third transaction C.
- the issuing software entity in question implements a version 1, a version 2 and a version 3 of transaction A, a version 1 and a version 2 of transaction B, and a version 4, a version 5 and a version 6 of the transaction C.
- the number of versions implemented for a given transaction is not necessarily the same for each transaction.
- transaction B contains only two versions: version 1 and version 2.
- Each object 11 associated with a version of a transaction includes the identifier 12 of the transaction, the signature 13 of the version (or hash) , and the structural description 14 of the version making it possible to encode or decode the messages.
- Each object also includes a preference flag 15.
- Each transaction is also associated with a table of privileged versions 16.
- the privileged version table 16 comprises, for transaction A, two privilege identifiers. Each privilege identifier identifies a privileged version 17 of transaction A, associated with a first receiving software entity 18, that the sending software entity uses as a priority when the sending software entity communicates with said first receiving software entity.
- the software entity receiver RI and the receiver software entity R2 are “first receiver software entities”.
- Version 2 is the privileged version for the receiving software entity RI and version 3 is the privileged version for the receiving software entity R2.
- the privileged version table 16 further comprises, for each transaction, a default identifier which identifies a default version 19 of the transaction, which the issuing software entity uses as a priority when the issuing software entity communicates with a second software entity. receiver which is not associated with a privileged version in the version table 10 of the sending software entity.
- the default version 19 is version 3 for all the receiving software entities (which are “second receiving software entities”) other than the receiving software entities RI and R2.
- This association between a receiving software entity and a privileged version can be determined after a successful transmission, in which case it is possible to confirm the version to be used, or following a prior exchange of the API versions table with the various receiving software entities.
- the privileged version of a transaction is not necessarily the last version of the list of versions of this transaction.
- transaction C contains versions 4, 5 and 6. This can show for example that versions 1 to 3 can be considered obsolete.
- the sending software entity sends a current message of a current version of a transaction.
- the current message to be transmitted on the medium can therefore be constructed as it has been shown previously, by strictly following the following elements:
- the receiving software entity receives the current message by retrieving the elements in their order of arrival to extract:
- the receiving software entity identifies in its version table the transaction as well as an object having a signature identical to the current signature.
- the recipient receiving software entity can decode the current message using the structural description of the object in question, then send the information back to the application in order to be processed.
- the application part of the program can be specific to a version of the message to be processed.
- a software entity is of course not necessarily either only sender or only receiver, but can be both sender and receiver: a transaction can be carried out in both directions.
- the same version table can be created and used to make the sending and processing choices on reception.
- FIGS. 5, 6 and 7, an exemplary implementation of the communication method according to the invention is described by a sending software entity and a receiving software entity which share the implementation of an API containing transaction A.
- the version table 20 of the sending software entity E is visible in FIG. 5.
- the version table 21 of the receiving software entity R is visible. in figure 6.
- the issuing software entity E implements versions 1, 3 and 5 of transaction A.
- the default version, for transaction A, is version 5. Version 5 will therefore be used by default on the first attempt to transmit this transaction.
- the version table 21 of the receiving software entity R is visible in FIG. 6.
- the receiving software entity R implements versions 2, 3, and 4 of transaction A.
- the default version for transaction A is version 4.
- the issuing software entity E begins the transaction with an initiating message 22 containing the signature 23 of version A5, as well as the structural description 24 of version A5.
- the receiving software entity R does not find an object having the signature of version A5 concerning transaction A in its version table.
- the receiving software entity R therefore sends an error message 25 to the sending software entity E stipulating that the receiving software entity R can understand the initiating message only with a signature corresponding to version A2, version A3 or A4.
- the issuing software entity E determines the intersection of the two sets of possible signatures between the two lists of signatures of the versions of transaction A that it has, that is i.e. the list of its version table and the list of the version table of the receiving software entity R.
- Version 3 whose signature A3 is present in both lists is found. It can therefore be used to perform transaction A with the receiving software entity R.
- the sending software entity E can save the information according to which the version of the transaction corresponding to the signature A3 is to be used to communicate with the receiving software entity R.
- the next attempt to communicate from the sending software entity E to the receiving software entity R can directly use the correct version of the transaction.
- the issuing software entity E then updates its version table 26.
- the sending software entity E can thus take into account the fact that initiating a transaction A with the receiving software entity R requires the use of version 3 of transaction A.
- the issuing software entity can choose the optimized version of the transaction most suited to the transport of the information that it wishes to transmit (size, subset of settings, etc.). This choice is made thanks to the preference indicator.
- the issuing software entity will then not be at the current that its request is not processed.
- the receiving software entity can also respond with an error message showing that the message cannot be interpreted (this is the case in FIG. 7). It is then possible to add information to the returned error signal.
- This or these signatures are those of the version table of the receiving software entity whose name of the transaction matches the name of the received transaction.
- this information will already be known to each software entity for a given transaction. This thus reduces the size of the data to be transmitted on the medium, but also simplifies the management of the decoding of the message because it becomes unnecessary to look for the correspondence of the signature: it has in fact been negotiated beforehand, so that it does not there is more ambiguity.
- the exchange of the version table with the information (signature of the structural description, preference indicator) of its use for each of their respective versions is not incompatible with the use of the signature of the description of a specific version during a transmission.
- the different mechanisms can therefore be used according to the use cases in order to benefit from their respective advantages (simplicity of implementation, coverage of use cases, speed of execution, etc.) compared to the software entity that lends it. 'uses.
- a software entity which manages a service can implement the various mechanisms in order to be able to deal with all cases.
- a one-off user of this service can only implement the transmission of a transaction in a given version by employing the signature of the version of the data structure to be exchanged.
- a service manager can take advantage of a prior negotiation of the compatibility of the transactions of the API used in order to be able to exchange messages in a more efficient way by not having to implement the error handling of no. - correspondence of the transactions and to ensure in advance that the transactions can succeed, or never succeed.
- the interoperability of the two transaction version management mechanisms is implemented at the level of the receiving software entity R.
- the sending software entity E2 exchanges with the receiving software entity R the table of transactions as well as various signatures corresponding to the implemented versions of transaction A. The result of this exchange allows the issuing software entity E2 to select version 4 corresponding to the signature A4.
- the sending software entity E2 can directly use version 4 of transaction A to initiate the message exchange, knowing that the receiving software entity R will know how to interpret it.
- the receiving software entity R can always process ad hoc requests from the sending software entity E.
- the latter does not synchronize its version table corresponding to the API, and tries to transmit transaction A with version 5. Error handling concerning the use of the wrong version of the despite everything, the transaction allows the sending software entity E to retransmit the transaction A with version 3 which is compatible with the sending software entity E and the receiving software entity R.
- the invention is not limited to embodiment described but encompasses any variant coming within the scope of the invention as defined by the claims.
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Stored Programmes (AREA)
- Information Transfer Between Computers (AREA)
- Computer And Data Communications (AREA)
Abstract
Description
Claims
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
FR1910071A FR3100908B1 (fr) | 2019-09-12 | 2019-09-12 | Procédé de communication entre des entités logicielles via une API |
PCT/EP2020/075532 WO2021048395A1 (fr) | 2019-09-12 | 2020-09-11 | Procédé de communication entre des entités logicielles via une api |
Publications (1)
Publication Number | Publication Date |
---|---|
EP4028888A1 true EP4028888A1 (fr) | 2022-07-20 |
Family
ID=68807126
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
EP20768358.2A Pending EP4028888A1 (fr) | 2019-09-12 | 2020-09-11 | Procédé de communication entre des entités logicielles via une api |
Country Status (5)
Country | Link |
---|---|
US (1) | US11907773B2 (fr) |
EP (1) | EP4028888A1 (fr) |
CA (1) | CA3153844C (fr) |
FR (1) | FR3100908B1 (fr) |
WO (1) | WO2021048395A1 (fr) |
Family Cites Families (9)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB0006575D0 (en) * | 2000-03-17 | 2000-05-10 | Sgs Thomson Microelectronics | Packet conversion |
US20050203673A1 (en) * | 2000-08-18 | 2005-09-15 | Hassanayn Machlab El-Hajj | Wireless communication framework |
EP1845446A3 (fr) * | 2004-02-02 | 2008-01-23 | Research In Motion Limited | Système et procédé pour la publication et l'accès d'application API sur un terminal générique |
US7680945B2 (en) * | 2004-03-31 | 2010-03-16 | Sap Ag | Messaging protocol in enterprise applications |
US7836439B2 (en) * | 2006-02-03 | 2010-11-16 | Research In Motion Limited | System and method for extending a component-based application platform with custom services |
US20080071887A1 (en) * | 2006-09-19 | 2008-03-20 | Microsoft Corporation | Intelligent translation of electronic data interchange documents to extensible markup language representations |
US7873745B2 (en) * | 2008-04-30 | 2011-01-18 | International Business Machines Corporation | Message receipt version management in network |
US8291230B2 (en) * | 2009-01-20 | 2012-10-16 | International Business Machines Corporation | Method and system for signing JavaScript object notation (JSON) messages |
US9516130B1 (en) | 2015-09-17 | 2016-12-06 | Cloudflare, Inc. | Canonical API parameters |
-
2019
- 2019-09-12 FR FR1910071A patent/FR3100908B1/fr active Active
-
2020
- 2020-09-11 EP EP20768358.2A patent/EP4028888A1/fr active Pending
- 2020-09-11 CA CA3153844A patent/CA3153844C/fr active Active
- 2020-09-11 US US17/641,701 patent/US11907773B2/en active Active
- 2020-09-11 WO PCT/EP2020/075532 patent/WO2021048395A1/fr unknown
Also Published As
Publication number | Publication date |
---|---|
CA3153844A1 (fr) | 2021-03-18 |
US11907773B2 (en) | 2024-02-20 |
FR3100908A1 (fr) | 2021-03-19 |
CA3153844C (fr) | 2023-02-21 |
FR3100908B1 (fr) | 2021-09-03 |
WO2021048395A1 (fr) | 2021-03-18 |
US20220413949A1 (en) | 2022-12-29 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8804504B1 (en) | System and method for reducing CPU load in processing PPP packets on a SSL-VPN tunneling device | |
CA2136921C (fr) | Procede de conversion automatique pour le portage d'applications de telecommunication du reseau pct/ip sur le reseau osi-co et module utilise dans ledit procede | |
US9246819B1 (en) | System and method for performing message-based load balancing | |
EP1605668B1 (fr) | Procédé de chargement de fichiers depuis un client vers un serveur cible et dispositif pour la mise en oeuvre du procédé | |
US8312147B2 (en) | Many-to-one mapping of host identities | |
FR2851866A1 (fr) | Procede d'allocation par un premier pair d'un service a un second pair d'un reseau de communication | |
FR2855691A1 (fr) | Securisation de la distribution de documents numeriques dans un reseau pair a pair | |
FR2886494A1 (fr) | Procede et dispositif d'echange de donnees entre des stations mobiles dans un reseau pair a pair | |
FR2824215A1 (fr) | Procede et dispositif de traitement d'un message dans un reseau de communication | |
EP3732829B1 (fr) | Procédé d'acheminement de données d'une session initialisée entre un terminal et un serveur | |
FR2868896A1 (fr) | Procede et dispositif de controle d'acces a un document numerique partage dans un reseau de communication de type poste a poste | |
CN111651476A (zh) | 一种物联网关中mqtt主题的快速匹配方法及系统 | |
EP1303812B1 (fr) | Procede de transmission d'un agent mobile dans un reseau; emetteur, recepteur, et agent mobile associes | |
JP2017034666A (ja) | コンテンツ指向型ネットワークのスタックにおける状態の転送 | |
CA3153844C (fr) | Procede de communication entre des entites logicielles via une api | |
CN113765867A (zh) | 一种数据传输方法、装置、设备及存储介质 | |
FR2994782A1 (fr) | Procede et systeme d'execution de protocoles de chargement de donnees | |
EP2446360B1 (fr) | Technique de determination d'une chaine de fonctions elementaires associee a un service | |
EP3675463B1 (fr) | Procédé d'identification d'un objet connecté dans une infrastructure réseau | |
US20220327526A1 (en) | Method for enabling efficient evaluation of transactions in a distributed ledger network | |
WO2020260825A1 (fr) | Procede de gestion d'une communication entre terminaux dans un reseau de communication, et dispositifs et systeme pour la mise en oeuvre du procede | |
EP3675435A1 (fr) | Procédé de routage dynamique dans un réseau d'objets connectés | |
EP1998514B1 (fr) | Traitement de paquets en vue de communiquer avec une machine à travers un ou plusieurs réseaux secondaires | |
WO2006072692A1 (fr) | Procede pour accomplir des fonctions cryptographiques dans une application informatique ecrite en langage a code mobile, et application informatique correspondante | |
FR3108747A1 (fr) | Procédé de gestion d’un fichier numérique de description d’un modèle de données, procédé d’utilisation d’un tel fichier par un équipement client, dispositifs, équipement serveur, équipement client, système et programmes d’ordinateur correspondants. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: UNKNOWN |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE |
|
PUAI | Public reference made under article 153(3) epc to a published international application that has entered the european phase |
Free format text: ORIGINAL CODE: 0009012 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
17P | Request for examination filed |
Effective date: 20220307 |
|
AK | Designated contracting states |
Kind code of ref document: A1 Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR |
|
DAV | Request for validation of the european patent (deleted) | ||
DAX | Request for extension of the european patent (deleted) | ||
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
RAP3 | Party data changed (applicant data changed or rights of an application transferred) |
Owner name: SAGEMCOM BROADBAND SAS |
|
INTG | Intention to grant announced |
Effective date: 20231204 |
|
GRAJ | Information related to disapproval of communication of intention to grant by the applicant or resumption of examination proceedings by the epo deleted |
Free format text: ORIGINAL CODE: EPIDOSDIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE |
|
GRAP | Despatch of communication of intention to grant a patent |
Free format text: ORIGINAL CODE: EPIDOSNIGR1 |
|
STAA | Information on the status of an ep patent application or granted ep patent |
Free format text: STATUS: GRANT OF PATENT IS INTENDED |
|
INTC | Intention to grant announced (deleted) | ||
INTG | Intention to grant announced |
Effective date: 20240423 |