Classifications

• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/30—Creation or generation of source code
  • G06F8/34—Graphical or visual programming
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q20/00—Payment architectures, schemes or protocols
  • G06Q20/08—Payment architectures
  • G06Q20/20—Point-of-sale [POS] network systems
  • G06Q20/202—Interconnection or interaction of plural electronic cash registers [ECR] or to host computer, e.g. network details, transfer of information from host to ECR or from ECR to ECR
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F8/00—Arrangements for software engineering
  • G06F8/60—Software deployment
• • G—PHYSICS
  • G06—COMPUTING; CALCULATING OR COUNTING
  • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
  • G06Q10/00—Administration; Management
  • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
  • G06Q10/063—Operations research, analysis or management
  • G06Q10/0633—Workflow analysis
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07F—COIN-FREED OR LIKE APPARATUS
  • G07F9/00—Details other than those peculiar to special kinds or types of apparatus
  • G07F9/006—Details of the software used for the vending machines
• • G—PHYSICS
  • G07—CHECKING-DEVICES
  • G07G—REGISTERING THE RECEIPT OF CASH, VALUABLES, OR TOKENS
  • G07G1/00—Cash registers
  • G07G1/0009—Details of the software in the checkout register, electronic cash register [ECR] or point of sale terminal [POS]

Definitions

• the present invention relates to the field of service applications for payment terminals.
• a payment terminal is a computer device allowing a professional to manage the electronic payment of a good or a service by a customer. Payment is typically made using a bank card, smartphone or any other medium carrying a means of payment. The card, its holder and the transaction are authenticated and validated by the payment terminal with a banking service, after presentation of the card at the terminal, or manual entry of information relating to the identification of the holder (card number, date expiration date, bearer ID, etc.).
• the payment terminal can be made up of a dedicated computing device, can be made up of a general purpose computing device, such as for example a mobile phone, a computing tablet, a personal computer equipped with a means of reading a chip card.
• a magnetic stripe card contactless and generally reading information on a medium allowing the identification of a customer to the banking service (including bar code or QR code), or an application allowing access to the payment service (example: internet browser) and connected to a computer network.
• the IT device has a service application dedicated to transaction management.
• the current context of payment is marked by the appearance of new means of payment such as, for example, payment solutions using connected objects such as smart phones (smartphones in English) with payment capabilities.
• new means of payment such as, for example, payment solutions using connected objects such as smart phones (smartphones in English) with payment capabilities.
• Apple Pay registered trademark
• Android Pay registered trademark
• electronic wallet solutions international regional or affinity
• AliPay registered trademark
• WeChat Pay registered trademark
• Paypal registered trademark
• BlueCode registered trademark
• Paylib registered trademark
• VISA registered trademark
• VISA Electron registered trademark
• MasterCard registered trademark
• Maestro registered trademark
• Union Pay registered trademark
• Discover registered trademark
• American Express registered trademark
• Bank cards registered trademark
• MultiBanco registered trademark
• Giromat registered trademark
• Giropay registered trademark
• Services around payment are also developing, such as the offer of payment in installments, payment in foreign currency (DCC), deferred payment, etc.
• Services ancillary to the transaction itself are also developing, such as the offer of insurance on the good or service purchased, warranty extensions, support for tips.
• These ancillary services may also relate to customer relations, such as loyalty programs, the offer of discount coupons, the collection of customer reviews or others.
• Still other services may relate to consumer knowledge and consumer behavior. The possibilities for payment services are constantly increasing.
• the object of the present invention is to resolve the aforementioned drawbacks by proposing a service platform that can be integrated into a payment or customer interaction solution.
• the platform also offers a tool for graphical programming of payment solutions which allows a user of the platform to define payment solutions by integrating the desired services and configuring them.
• This graphical programming tool can be used without requiring any computer knowledge.
• the graphical programming tool makes it possible to generate at least two software, for example based on scripts, one intended to be executed on the payment terminal and to collaborate with the other on a server of the services platform to provide a payment solution.
• a professional can easily and quickly define the payment solution adapted to his needs.
• This solution can be deployed quickly. It can also be modified at any time by the professional in order to follow changes in his needs.
• Figure 1 illustrates the architecture of a service system for payment terminals according to an exemplary embodiment of the invention.
• Figure 2 illustrates an example of a programming interface for payment terminal service applications.
• FIG 3 illustrates a service as it appears in the edit window according to an exemplary embodiment of the invention.
• Figure 4 illustrates the deployment of the service application according to one embodiment of the invention.
• FIG 5 illustrates the flow of a service, here the payment service, according to an exemplary embodiment of the invention.
• FIG 6 illustrates the main steps in running a service application in one embodiment of the invention.
• FIG 7 illustrates the software architecture of the payment terminal in an exemplary embodiment of the invention.
• FIG 8 illustrates the software architecture of the server platform in an exemplary embodiment of the invention.
• FIG 9 is a schematic block diagram of an information processing device for the implementation of a payment terminal or a server that can implement the service platform for payment terminals according to several embodiments of the invention.
• Figure 1 illustrates the architecture of a service system for payment terminals according to an exemplary embodiment of the invention.
• the system includes a service platform 103.
• This service platform includes a first execution module 105 which enables the operation of payment services at a payment terminal 101.
• the service platform 103 also includes a payment service programming module 104 to which a user, that is to say a person operating a payment terminal 101, can connect from an information processing device 102.
• This The device may typically consist of a personal computer, a tablet, or any terminal that can connect to an Internet type data communication network.
• the information processing device typically has an Internet client, such as a web browser, allowing the user to interact with the payment services programming module 104.
• the service platform 103 is described here in a logical manner. It may consist of one or more servers interacting to provide the service described. Likewise, only the aspects essential to the definition and then to the execution of payment service applications are described.
• the platform also includes ancillary services such as, for example, authentication and user management which are not described in detail.
• the payment services programming module 104 allows the user to program in a simple, intuitive and rapid way, a payment service based on basic services offered by the service platform 103.
• the payment services programming module offers graphic programming by arrangement of elementary services, their connection and the definition of their parameters.
• This complete application once defined, consists of two software modules one intended to be executed on the payment terminal 101 and the other on the execution module 105. The two software modules then interact to jointly execute the application.
• the application involves more than two software modules running on different computing devices and interacting with each other.
• At least some of the elementary services constituting the application for a payment terminal can call on one or more external services 106 to 109.
• These external services include, for example, payment service providers (PSP for Payment Service Provider), electronic mail services, short text message messaging services (SMS for Short Message Service), customer opinion collection and analysis services, sales promotion services (loyalty program, management of coupons %), customer identification services (eg: token management) or others.
• a user operating a payment terminal can use the platform to define a complete application for a payment terminal.
• This definition does not require any particular programming knowledge, it is quick and easy to use.
• the platform Once the application is defined, the platform generates all the software modules that must run on the payment terminal.
• the platform also generates a second software module that runs on the platform itself.
• the software modules intended for the payment terminal or, more generally, any computer device, are deployed on them.
• the software module deployed on the terminal runs, connects to the platform and cooperates with the software module running on the platform to provide the services making up the application. Some of its services may use external services that interact with the service platform.
• the user can therefore, at any time, define or modify his payment application to adapt to the evolution of his needs and to offer the desired level of service to his customers.
• New services appearing on the market can be offered quickly by integration with the service platform. From this integration done, users can integrate them into their payment terminal application.
• Figure 2 illustrates an example of a service application programming interface for payment terminals.
• the graphical programming application for programming service applications operates in a client-server mode between the client 102 used by the user and the programming module 104 on the service platform.
• the example described here is based on the use of a standard web browser on the client 102 interacting with a programming module 104 developed as a web service on the platform. Any other implementation is of course possible, such as a native client interacting with a native application on the server side for example.
• the programming interface includes a main window
• a first sub-window 202 comprises a list of the elementary services 203 available.
• this list can be ordered by type of service.
• the list can be hierarchical and make it possible to display only the services of the same category at a given time to facilitate the identification of the service sought, if the total number of services is large.
• a second sub-window 204 allows editing of the service application for payment terminals. In this edit window 204, the user can arrange 205 services selected from the list of services 202. Typically, the user can select a service from the list of services.
• the service 205 once dropped into the edit window exposes at least one entry point and at least one exit point, as well as possible end points. branching (hooks in English). The user can then connect the entry and exit points of the various services to constitute his application.
• the services 205 also expose, if necessary, a set of parameters allowing the user to customize the service according to his needs.
• the interface also includes, not shown in the figure, the controls allowing the saving of an application as well as the generation and the deployment of software modules generated on the payment terminal and on the platform.
• the deployment of the software module intended for the payment terminal can be carried out on a set of payment terminals, for example in the case of a store comprising a set of payment terminals or in the case of a chain of stores.
• Figure 3 illustrates a service 301 as it appears in the edit window 204 according to an exemplary embodiment of the invention.
• the service includes at least one entry point 304 and at least one exit point 305.
• exit point # 3 transaction canceled by client
• One or more branch points 306 may be present. These connection points allow the service to be interrupted at a given time to trigger the progress of one or more other services connected to that connection point. When these services end, the interrupted service is resumed.
• the service comprises an identification zone 302.
• This identification zone can include the name of the service, an identifier of the service as well as a long description of the service.
• a button in this area opens a help page which gives details of the operation of the service to the user.
• a service configuration area 303 is present if the service can be configured.
• This configuration area typically includes controls, such as drop-down menus, multiple or exclusive selection check boxes, numeric or text fields, etc. The user can then easily configure each service according to their needs.
• a payment service could allow the user to choose the type of card accepted from contactless smart cards, contactless, magnetic cards and manual entry, etc. It can also allow choose the solutions accepted among, for example, the solutions VISA, MasterCard, American Express, Discover, JCB ...
• the types of payment accepted can also be configured from different types (example: debit, credit, reimbursement ).
• Default parameters can also be set. Connection points can be offered to allow the insertion of other services at certain times during the execution of a service (eg payment) payment such as, for example, before insertion of the card, after insertion of the card, before selection of the application and after selection of the authorization.
• a currency conversion service can be connected to the intervening branch point. After inserting the card.
• the customer will be offered the selection of a currency, for example US dollar, instead of the merchant's default currency, for example euro.
• the customer can then read on the terminal the net amount which will be withdrawn from his bank account in his currency and including any costs such as the exchange rate and the exchange commission.
• Figure 4 illustrates the deployment of the service application according to one embodiment of the invention.
• the software module 402 is intended to be executed on the payment terminal 404 (or other computer device) under the control of a service orchestra 406.
• the software module 403 is intended to be executed on the server (or other device). IT) within the service execution module 405, corresponding to the module illustrated in Figure 1 under the reference 105.
• the software module 403 is executed under the control of a service orchestra 407.
• the software modules 402 and 403 are composed of a set of resources comprising scripts, files (eg: images, configuration file, etc.), and a workflow (workflow in English ) which defines the scheduling of services.
• Each script is configured according to the parameters defined by the user.
• Each service used therefore results in a first script running on the payment terminal (or other IT device) and a second script running on the platform (or other IT device). At least one IT device is mandatory.
• These scripts cooperate through connection 408 between computing devices.
• the script can also cooperate with external services as explained in relation to Figure 1.
• the user of the payment terminal uses an application which seems to him to be executed on said terminal but which ultimately implements software modules local to the terminal, others on the service platform and potentially external services.
• the 406 and 407 service orchestras running on the computing devices respectively, are in charge of executing the different scripts that make up the different services in accordance with the defined workflow. These service orchestras also execute the scripts with the parameters corresponding to the programming of the application made in the programming module 104.
• Scripts that run on computing devices can be programmed in the same scripting language or else in different languages depending on the embodiments of the invention. This choice depends on the software choices, in terms of operating system and software environment made for the payment terminal and for the platform. These scripting languages include, for example, Javascript, Lua, Python, Kotlin, Groovy or others. In some embodiments, actual executables can be compiled in lieu of scripts.
• Figure 5 illustrates the progress of a service, here the payment service, according to an exemplary embodiment of the invention.
• the terminal initiates the execution of the service by the processing block 501.
• the processing block 501 requests the insertion of the card from the customer.
• the card is then read and the default currency of the card is extracted. If an external service is connected to the connection point “after insertion of the card”, then this service is triggered.
• the customer's PIN code is then verified. If the customer's PIN code is verified successfully, an authorization request 502 is sent to the corresponding script which is executed on the platform.
• This script running on the platform, performs a processing block 503.
• This processing block is responsible for selecting the bank that must process the payment.
• the script running on the platform must use other services available on that platform.
• the platform includes a database containing the reference of the banks with which the merchant has signed an acquisition contract.
• This database also contains technical information for connecting to banks, such as primary and secondary IP addresses and login credentials.
• acquisition contracts can be modeled in order to be able to assess which bank is the most competitive for a given type of transaction. For example, an international "VISA" payment may be cheaper with one bank while a "MasterCard" payment will be cheaper with another bank.
• the processing module 503 chooses a bank and transmits the payment request 504 to it.
• the chosen bank then processes the request during processing 505.
• the payment is validated or refused.
• the bank transmits this result in a 506 response to the platform.
• the platform, during processing 507 retransmits the response 508 to the payment terminal.
• Figure 6 illustrates the main steps in running a service application in one embodiment of the invention.
• a transaction is initiated.
• the orchestra of services of the payment terminal launches the first script making up the application.
• the terminal services orchestra is in charge of successively launching the services as they are executed on the payment terminal or computing device.
• a strong authentication can be used to authenticate the payment terminal with the platform.
• this authentication uses a cryptographic system (eg asymmetric keys) managed within a secure hardware module.
• This secure hardware module is made up of a physical part and a software part whose role is to protect the keys and cryptographic operations. Any attempt at logical or physical intrusion of a secure hardware module can lead to the immediate erasure of the cryptographic keys it contains.
• Such a secure hardware module is functionally very close to a smart card while having a greater processing capacity.
• step 605 the application context, that is to say, typically, the list of data captured and / or generated by the application, is transferred to the server.
• the platform's service orchestra identifies the server script corresponding to the service application based on the identification of the payment terminal and launches it with the associated parameters.
• step 608 the application is executed by orchestrating the various service scripts on the payment terminal and on the platform. If necessary, scripts running on the platform call on external services as described in relation to Figure 5.
• step 609 symmetrical to step 604, a connection to the client is initiated by the server.
• step 610 symmetrical to step 605, the server application context is transferred to the client.
• Steps 602 through 610 can be performed any number of times depending on the needs of the application.
• step 606 at the end of the application, the client script initiates the end of execution.
• the platform is notified of the end of execution and can then release the resources used by the script on the platform.
• the same service orchestra is deployed on the client and the server or servers.
• the application is then seen as a set of a or several software modules running on one or more computer devices and working together according to the needs of the application.
• the passage of control from one device to another is done as illustrated in FIG. 6 between the client and the server.
• the transaction can then be initiated either by one or the other of these software modules.
• a store sign could deploy an instance of the service orchestra on each of the payment terminals, an instance of the service orchestra on a server within each store and an instance on a remote central server. .
• the application would then be made up of all the software modules executed on each of these instances of the service orchestra.
• an instance of the service orchestra would be deployed on each payment terminal, only one of these terminals would be connected to the Internet.
• the instance deployed on the payment terminal connected to the internet would then act as a proxy for the other instances.
• Several terminals then collaborate in carrying out the transaction.
• a store has a screen equipped with an NFC reading means, a payment terminal having all the means to validate a payment which communicates with a remote server.
• NFC reading means an NFC reading means
• a payment terminal having all the means to validate a payment which communicates with a remote server.
• Figure 7 illustrates the software architecture of the payment terminal in an exemplary embodiment of the invention.
• the payment terminal operates under the control of Google's Android operating system (registered trademarks).
• This operating system 700 makes it possible to operate a set of software modules necessary for the operation of service applications according to the exemplary embodiment of the invention. These modules are implemented in the form of one or more Android applications depending on the embodiments.
• the central module is the service orchestra 704. It is this module which loads the various scripts constituting the service application, which allows them to be executed. and schedule them. To do this, the service orchestra 704 includes an execution engine of the chosen scripting language:
• the terminal has to process scripts that it is the only one able to execute because they call on resources only available in the terminal (eg: communication with the smart card reader).
• scripts can only be executed by the server (eg connection to a third party service hosted outside the server environment and not accessible by the terminal.
• scripts can run on the terminal or on the server.
• a transaction therefore consists of 3 major elements:
• the scripts are available in both environments (i.e. terminal and server) before the start of a transaction in order to reduce the delay in starting the transaction. However, it is also possible that the terminal downloads the scripts and the "workflow" at the start of a transaction.
• the service orchestra is responsible for transferring the context from the terminal to the server (and vice versa) during the "handover".
• the service applications share a number of common functionalities made available either by the terminal or by the server. They must all access the payment card reader integrated into the terminal, communicate with the service platform, manage the terminal interface or even manage cryptographic operations as part of their authentication with the platform, for example.
• These common functionalities are provided by a set of software modules typically grouped together in one or more Android applications, or “server” services.
• a man-machine interface module (HMI) 702 provides the functions for managing the screen of the payment terminal as well as the keyboard. This module allows interactions with the user client of the terminal.
• a security module 705 manages the cryptographic operations linked to the operation of the services. These operations include authentication with the platform and if necessary with third-party services.
• This security module can interact with a secure microcontroller 708 present in the terminal and acting as a security element, that is to say a hardware component responsible for the actual cryptographic operations and the storage of the keys. , this component being equipped with security features designed to make it tamper-proof.
• the card reader integration module 703 offers interactions with the card reader (s) present in the payment terminal. These readers can be wired or wireless.
• the 706 Platform Interface Module provides communications with the platform. This is typically the module that will allow a client script to communicate with the corresponding server script and via this server script with any third party services.
• a 701 update module is used to update workflows, scripts and various modules when new versions are available.
• a communication module 707 manages the communications between these different modules and the exterior of the payment terminal and in particular the card reader and the service platform. It is this module that establishes secure communication tunnels, for example with the platform.
• Figure 8 illustrates the software architecture of the server platform in an exemplary embodiment of the invention. This figure does not illustrate the programming module 104 but only the architecture useful for the execution of the service applications.
• the core 800 of the platform is made up of a set of modules. These core modules include the 803 service orchestra which manages the loading, execution and scheduling of application server scripts. on duty. It is the server-side counterpart of the 704 service orchestra on the terminal.
• scripts running on the platform can use a set of services available to them in the form of accessible software modules.
• These services include an 801 authentication module that manages authentications.
• This module typically cooperates with a secure hardware module 809 (HSM for Hardware Secure Module in English).
• HSM Hardware Secure Module in English.
• This authentication module will manage cryptographic operations on behalf of all modules that require it.
• the 801 and 802 modules are the access point to the 809 module. They are responsible for preparing and optimizing the operations delegated to the 809 module (eg: converting data from XML or JSON format into a single binary format suitable for HSM).
• a monitoring module 804 allows you to monitor the execution of scripts and the use of various modules and scripts during execution to detect possible anomalies that may arise from malfunctions or possible attacks on the platform.
• modules are also present, not shown, such as for example a module for recording the technical and business operations carried out (log in English), a possible protocol translation module if necessary to interact with certain third-party services, a module for update of software components. This list is not exhaustive.
• IP address IP address
• authentication token MAC address
• a module 805 manages the platform's communications with traders. It is this module which manages the communication with the payment terminals 810 within the framework of the execution of the service applications. It is also this module which manages the administration by a merchant of his service from an administration terminal 81 1.
• a module 806 manages the platform's communications with third-party services. These services are typically requested by scripts executed by the platform's orchestration service when running service applications. Among these third-party services, mention may be made of an electronic mail management service 812, banking services 813 such as payment services, and merchant electronic services. These services also include services such as a merchant's 814 extranet. Indeed, certain service applications may require data specific to the merchant, for example to apply rules such as the attribution of a promotion according to criteria specific to the merchant, or even the proposal of a questionnaire to customers who have spent in less 100 euros in the month.
• the platform also includes a module 807 which gives access to the manager of the platform for his administration.
• these different modules are implemented in the form of services in a service oriented architecture (SOA). All of these services communicate, for example, through a message broker.
• the operating system is Linux
• the hypervisor managing server virtualization is Proxmox in development and VMWare in production
• the services are managed by Kubernetes / Docker
• the message service is ActiveMQ
• the services are developed in Java / Spring, Node.js and / or C / C ++
• the database can be Cassandra, MongoDB or ElasticSearch.
• the proposed system allows a merchant to quickly define a service application (also called a “workflow”) for his terminals. payment, to deploy it without delay. Then this app can be changed at any time. New services appearing on the market can be integrated into the platform and made available to merchants who can then integrate it into their payment application. All this can be done without having to bear the costs and delays associated with the development of proprietary service applications.
• a service application also called a “workflow”
• FIG. 9 is a schematic block diagram of an information processing device 900 for implementing one or more embodiments of the invention.
• the information processing device 900 may be a peripheral such as a microcomputer, a workstation or a mobile telecommunications terminal.
• the device 900 has a communication bus connected to:
• a central processing unit 901 such as a microprocessor, denoted CPU;
• RAM random access memory 902
• the executable code of the method for carrying out the invention as well as the registers adapted to record the variables and parameters necessary for the implementation of the method according to embodiments of invention
• the memory capacity of the device can be supplemented by an optional RAM memory connected to an expansion port, for example;
• ROM read only memory 903, denoted ROM, for storing computer programs for the implementation of the embodiments of the invention
• a network interface 904 is normally connected to a communication network on which digital data to be processed are transmitted or received.
• Network interface 904 may be a single network interface, or composed of a set of different network interfaces (eg, wired and wireless, interfaces or different types of wired or wireless interfaces). Data packets are sent over the network interface for transmission or are read from the network interface for reception under the control of the software application running in processor 901;
• a user interface 905 for receiving input from a user or for displaying information to a user
• the executable code can be stored in a read only memory 903, on the storage device 906 or on a digital removable medium such as for example a disk.
• the executable code of the programs can be received by means of a communication network, via the network interface 904, in order to be stored in one of the storage means of the communication device 900, such as the storage device 906, before being executed.
• the central processing unit 901 is adapted to control and direct the execution of instructions or portions of software code of the program or programs according to one of the embodiments of the invention, instructions which are stored in one. of the aforementioned storage means. After power-up, the CPU 901 is able to execute instructions from the main RAM 902, relating to a software application. Such software, when executed by processor 901, causes the described methods to be performed.
• the apparatus is a programmable apparatus which uses software to implement the invention.
• the present invention can be implemented in hardware (eg, in the form of a specific integrated circuit or ASIC).

Landscapes

• Engineering & Computer Science (AREA)
• Business, Economics & Management (AREA)
• Physics & Mathematics (AREA)
• General Physics & Mathematics (AREA)
• Theoretical Computer Science (AREA)
• Software Systems (AREA)
• Accounting & Taxation (AREA)
• Strategic Management (AREA)
• General Engineering & Computer Science (AREA)
• Human Resources & Organizations (AREA)
• General Business, Economics & Management (AREA)
• Finance (AREA)
• Economics (AREA)
• Entrepreneurship & Innovation (AREA)
• Development Economics (AREA)
• Educational Administration (AREA)
• Game Theory and Decision Science (AREA)
• Marketing (AREA)
• Operations Research (AREA)
• Quality & Reliability (AREA)
• Tourism & Hospitality (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=68501710

Family Applications (1)

Country Status (7)

Families Citing this family (1)

Family Cites Families (58)

• 2019
  • 2019-06-21 FR FR1906735A patent/FR3097672A1/fr active Pending
• 2020
  • 2020-06-17 US US17/621,337 patent/US20220366393A1/en active Pending
  • 2020-06-17 WO PCT/FR2020/051051 patent/WO2020254761A1/fr unknown
  • 2020-06-17 CA CA3143068A patent/CA3143068A1/fr active Pending
  • 2020-06-17 AU AU2020296966A patent/AU2020296966A1/en active Pending
  • 2020-06-17 EP EP20785770.7A patent/EP3987390A1/de active Pending
  • 2020-06-17 BR BR112021025579A patent/BR112021025579A2/pt unknown

Also Published As

Similar Documents

Legal Events