EP3913911A1 - Simple video telephony system - Google Patents

Abstract

The present invention relates to a videophone device and method, and is characterized by the absence of software to install or of an account to be created by either of the two participants, instantaneous connection, and simplicity for the invitee and for The device comprises an infrastructure (1) to which is connected a terminal of the guest (6) which provides an identifier (2) of the guest. The identifier can in particular be the mobile telephone number of the guest. A unique link (3) is transmitted to the guest by any standard digital means (4) such as SMS, email, MMS, standardized WebPush, requiring no software installation on the guest's phone. click on this link, the guest's internet browser connects to the unique URL (3), activates the phone's camera and / or microphone, and establishes a video stream (5) with the guest. , the infrastructure (1) available to the caller is a web interface with a field for entering the identifier (2): the guest's telephone number. In a second embodiment, the infrastructure (1) could be an Interactive Voice Server. In a third embodiment, the identifier (2) could be the email address and the standard digital means (4) of sending the link could be an email. incoming call, that the view of the caller's environment is useful, urgent, and that one cannot presuppose any applications available on the caller's telephone. The invention can be used alone or in addition to a telephone conversation (0), can be enhanced with payment solutions, data collection, and secure transmission of documents, and simultaneous transcription or translation.

Description

The present invention relates to a device for establishing a videotelephony communication, real-time conversation between two parties by means of sound and image.
The present invention also relates to a videophone communication method.

We will call inviting (9) the person who wishes to bring the other to join them in a videotelephony communication, and invited (10) the person who is thus requested.

The traditional way to establish such communication usually depends on specific software. These applications include Skype, Whatsapp, Facetime, Zoom. It is usually from the application that the inviter triggers an invitation. This manifests itself in two ways: either it wakes up the guest's application, which triggers a ringing tone and displays an incoming call; or it is in the form of a textual URL and is sent by any means to the guest, including email. When this URL is clicked by the guest, the application launches.
What is remarkable is that the guest and the invitee must have the same application, and it is therefore required that the invitee first inquire about the availability of the application at the guest's premises. , either that the communication is delayed for as long as it takes for the guest to first install the application, assuming this is possible (the application must be available for the device, the guest has sufficient installation rights).

The device of the invention aims at instantaneous communication without prior knowledge of the applications in place at the guest's premises. By instant, we mean without requiring the installation of an application, and without registering the guest in a system (account creation).

Extremely simple principle of establishing communication.

The guest has a telephone or a portable device (8) equipped with a camera, capable of digital communication, and provided with an internet browser. For the sake of simplicity but without any limitation, we will call this device the telephone. The device also comprises an infrastructure (1) composed of a web server ensuring the accessibility of a website to which a guest terminal (6) (PC, tablet or possibly mobile terminal) is connected. This infrastructure (1) is available to the invitee who provides the infrastructure (1) with an identifier (2) of the guest. The identifier can in particular be the mobile phone number of the guest. When this infrastructure (1) is activated using the identifier, a unique link (3) is prepared in order to welcome the guest. This link is transmitted to the guest anywhere standard digital medium (4) such as SMS, email, MMS, standardized WebPush (www.w3.org/TR/push-api/ and https://tools.ietf.org/html/ rfc8030 and their future evolutions) or by websocket (https://tools.ietf.org/html/rfc6455 and future evolutions), processes not requiring installation of software on the telephone of the guest.
The unique link (3) is such that it is not sequential and that it includes an electronic signature preventing unauthorized access attempts.

When the guest clicks on this link, the guest's internet browser establishes the connection with the unique URL (3). In this URL is encoded a direct or indirect reference to the invitee. An indirect reference can be a virtual meeting room reference in which the invitee is waiting. The browser then accesses the camera and / or microphone of the telephone and establishes a video stream (5) with the invitee. This step does not require from the guest either any action other than the click, or beyond the click a single action authorizing access to the audio and / or video sensors.

• L'invitant n'a pas besoin de s'identifier sur l'infrastructure (1) pour les besoins de la communication visio
• L'invitant n'a pas besoin d'installer un logiciel, un navigateur internet suffit
• L'invitant n'a qu'une action très simple à faire sur l'infrastructure (1) : un seul champ à saisir et à valider - ou un correspondant à cliquer si l'implémentation fournit déjà une liste de correspondants.
• Dans une implémentation mono-directionnelle, l'invitant n'a pas besoin de matériel (microphone/caméra/carte son) ni d'autoriser l'accès à de tels périphériques.
• L'invitant n'a rien d'autre à faire après avoir activé l'infrastructure (1) : il patiente jusqu'à ce que la vidéo, et optionnellement le son, provenant du téléphone de l'invité lui soit (soient) restituée (restitués).

An essential characteristic of the invention is the simplicity of activation and interaction for the invitee:

• The invitee does not need to identify himself on the infrastructure (1) for the purposes of video communication
• The invitee does not need to install any software, a web browser is sufficient
• The inviter has only one very simple action to do on the infrastructure (1): a single field to enter and validate - or a correspondent to click if the implementation already provides a list of correspondents.
• In a one-way implementation, the guest does not need any hardware (microphone / camera / sound card) or allow access to such devices.
• The invitee has nothing else to do after activating the infrastructure (1): he waits until the video, and optionally the sound, coming from the guest's phone is returned to him. (returned).

• L'invité n'a pas à s'identifier
• L'invité n'a pas de logiciel à installer, un navigateur internet suffit
• L'invité n'a rien d'autre à faire que de cliquer sur le lien et d'éventuellement accepter le partage de ses capteurs, le cas échéant.

An essential characteristic of the invention is the simplicity of activation and interaction for the guest:

• The guest does not have to identify himself
• The guest does not have any software to install, a web browser is sufficient
• The guest has nothing else to do but click on the link and optionally accept the sharing of their sensors, if applicable.

Examples of practical realizations

• l'infrastructure (1) à disposition de l'appelant est une interface web avec un champ pour la saisie de l'identifiant (2)
• L'identifiant (2) est le numéro de téléphone de l'invité
• Le moyen numérique standard (4) d'envoyer le lien est un SMS ou un Webpush
• Le protocole utilisé pour l'établissement des flux de visiophonie (5) est le WebRTC, pilotés par des échanges Websocket.

In a practical realization,

• the infrastructure (1) available to the caller is a web interface with a field for entering the identifier (2)
• The ID (2) is the guest's phone number
• The standard digital way (4) to send the link is an SMS or a Webpush
• The protocol used for establishing videotelephony flows (5) is WebRTC, driven by Websocket exchanges.

In a second embodiment, the infrastructure (1) could be an Interactive Voice Server.
In a third embodiment, the identifier (2) could be the email address and the standard digital means (4) to send the link could be an email.

• Lorsqu'un opérateur reçoit un appel entrant d'une personne, et que l'assistance de l'opérateur ou le service fourni(e) par l'opérateur est grandement facilité(e) par la vue de l'appelant ou de l'environnement de l'appelant,
• et que l'établissement de la visiophonie est urgente
• et que l'opérateur ne peut disposer de l'information des éventuelles applications disponibles sur le téléphone de l'appelant

Dans ces cas de figure, l'opérateur est l'invitant et l'appelant est l'invité.
Il s'agit typiquement d'un appel vers un centre de traitement d'appels d'urgence médicale, sécurité ou incendie (112), violences conjugales, centre anti-poison, etc. L'implémentation peut dans ce cas rester mono-directionnelle avec tous les avantages de simplicité afférents.

• L'invitant et l'invité ont un rendez-vous et l'invitant ne connaît qu'un simple identifiant de l'invité (par exemple son numéro de téléphone).
  Il s'agit typiquement d'une consultation d'expert, consultation médicale, personnel soignant, psychologie, conseil, coaching, soutien, écoute.
• L'invitant souhaite éviter un déplacement pour observer une situation

Il s'agit notamment des constats d'experts, dans le cadre des litiges d'assurance, experts automobiles, des expertises et commissaires priseurs, des constats d'huissier.The invention is capable of application in particular in the following circumstances.

• When an operator receives an incoming call from a person, and operator assistance or the service provided by the operator is greatly facilitated by the sight of the caller or the operator. caller environment,
• and that the establishment of videophone is urgent
• and that the operator cannot have information on any applications available on the caller's phone

In these cases, the operator is the invitee and the caller is the invitee.
This is typically a call to a medical emergency call center, safety or fire (112), domestic violence, poison control center, etc. The implementation can in this case remain mono-directional with all the attendant advantages of simplicity.

• The invitee and guest have a date and the invitee only knows a simple guest ID (eg phone number).
  This is typically an expert consultation, medical consultation, nursing staff, psychology, advice, coaching, support, listening.
• The inviting party wishes to avoid a trip to observe a situation

These include in particular the findings of experts, in the context of insurance disputes, automotive experts, appraisals and auctioneers, bailiff's findings.

In all these cases, the videophone consultation can be used alone, or in addition to a parallel and independent telephone conversation (0), in particular if the implementation is mono-directional, a choice which may be justified by a need for simplicity and absence of material requirements on the guest's terminal (microphone, sound, speakers). The invitee may have a control enabling the "hands-free" mode or the volume of the telephone conversation and / or video communication to be activated on the portable device, and possibly to adjust the volume of the microphone. the portable device.
The infrastructure (1) can optionally be connected to PSTN / PSTN (Public Switched Telephone Network) or VOIP (Voice over IP) telephony equipment (13) in order to initiate two calls before or during video communication. telephone calls to the guest and the inviting (who will have previously had to provide his number in this implementation to the infrastructure (1)) in order to put them together or to call one and transfer it to the other, or to receive a call and transfer it to the other, or to receive two calls from guests and invitees to bring them together in communication, and thus allow the infrastructure (1) to automatically establish the telephone conversation, object of the previous paragraph .

Technical implementation, role of infrastructure (1)

• Lorsque l'invitant se connecte au site web, l'infrastructure (1) retourne une page HTML simple au navigateur internet du terminal qui affiche un formulaire simple de saisie de l'identifiant unique. L'invitant saisit l'identifiant et valide, ce qui retourne l'identifiant à l'infrastructure (1). Celle-ci alloue un numéro de communication visio, et renvoie un code Javascript assurant l'établissement d'une connexion websocket depuis le terminal vers l'infrastructure (1). Cette connexion permet à l'infrastructure d'initier une communication vers le navigateur internet du terminal (et non se contenter de son rôle de serveur).
• L'infrastructure (1) prépare une URL qui correspondra au numéro de communication visio ci-dessus, et l'envoie par le moyen standard. Par exemple si l'identifiant est une adresse email, le lien partira dans un email transmis à une passerelle SMTP, et si l'identifiant est un numéro de téléphone le lien sera dans le corps d'un message SMS remis à un fournisseur par le biais d'une API ad-hoc.
• Lorsque l'invité clique sur le lien, le navigateur internet de l'appareil portable se connecte au serveur web de l'infrastructure (1) qui lui retourne de façon similaire à l'invitant un code JavaScript assurant l'établissement d'une connexion websocket entre l'appareil portable et l'infrastructure (1).

• Ce même code JavaScript enchaîne avec la demande d'accès à la (les) caméra(s). En cas de succès, il active l'API de connexion Peer-to-Peer du navigateur internet qui génère une offre de connexion, un paquet SDP, qui est renvoyé via le websocket à l'infrastructure (1) qui le relaie au terminal.
• Le terminal fournit ce paquet SDP à l'API de Peer-to-Peer du navigateur internet. Ce paquet SDP contient les caractéristiques techniques des flux, des résolutions et encodages disponibles sur l'appareil portable. L'API compare les capacités de l'appareil portable et ses propres capacités, et constitue ainsi des propositions de paramétrages. La réponse SDP est relayées via Websocket à l'infrastructure (1) qui transmet à l'appareil portable.
• L'appareil portable choisit l'une des propositions de paramétrages et se met en attente de connexion des flux selon ce paramétrage, et renvoie son choix au terminal (toujours via websocket).
• Le terminal initie les flux. La connexion s'établit.
• Une fois la connexion peer to peer établie, elle sert pour acheminer les flux provenant des capteurs.
• Durant la communication visio, la connexion websocket reste active. Elle permet notamment de relayer les actions d'un côté qui affectent l'autre côté (contrôle des caméras).
• Lorsque l'une des partie termine l'appel ou ferme sa fenêtre de navigateur, l'autre partie détecte la perte du flux. Le Javascript est notifié et passe à l'étape suivante qui est l'affichage d'une page web avec un message adéquat par exemple.

La plupart des équipements sont placés derrière des pare-feux. Ceux-ci laissent passer les établissements de connexion TCP vers ure destination IP (adresse et port) dans un sens uniquement (sortant), sauf exceptions autorisées dans le sens entrant. Si les deux parties sont protégées par un pare-feux, et se retrouvent donc chacun à l'extérieur du pare-feux de l'autre, ni l'un ni l'autre ne peut établir de connexion TCP. Ce problème est résolu par l'intervention d'un serveur STUN (12) inclut dans l'infrastructure (1). L'adresse du serveur STUN est incluse dans le Javascript des deux côtés. Chaque partie s'adresse à ce serveur pour négocier des paramétrages convenables contournant les pare-feux pour une connexion en direct. Ces paramètres sont inclus dans les propositions et réponses SDP.

• When the invitee connects to the website, the infrastructure (1) returns a simple HTML page to the internet browser of the terminal which displays a simple form for entering the unique identifier. The inviter enters the identifier and validates, which returns the identifier to the infrastructure (1). This allocates a video communication number, and sends back a JavaScript code ensuring the establishment of a websocket connection from the terminal to the infrastructure (1). This connection allows the infrastructure to initiate a communication to the internet browser of the terminal (and not to be satisfied with its role of server).
• The infrastructure (1) prepares a URL which will correspond to the video communication number above, and sends it by standard means. For example if the identifier is an email address, the link will go in an email sent to an SMTP gateway, and if the identifier is a telephone number the link will be in the body of an SMS message delivered to a provider by the through an ad-hoc API.
• When the guest clicks on the link, the web browser of the portable device connects to the web server of the infrastructure (1) which returns to him in a similar to prompting a JavaScript code ensuring the establishment of a websocket connection between the portable device and the infrastructure (1).

• This same JavaScript code follows with the request for access to the camera (s). If successful, it activates the Peer-to-Peer connection API of the internet browser which generates a connection offer, an SDP packet, which is sent via the websocket to the infrastructure (1) which relays it to the terminal.
• The terminal provides this SDP package to the Internet browser's Peer-to-Peer API. This SDP package contains the technical specifications of the streams, resolutions and encodings available on the portable device. The API compares the capacities of the portable device and its own capacities, and thus constitutes setting proposals. The SDP response is relayed via Websocket to the infrastructure (1) which transmits to the portable device.
• The portable device chooses one of the configuration proposals and waits for connection of the flows according to this configuration, and returns its choice to the terminal (always via websocket).
• The terminal initiates the flows. The connection is established.
• Once the peer to peer connection is established, it is used to route the flows coming from the sensors.
• During video communication, the websocket connection remains active. In particular, it makes it possible to relay actions on one side which affect the other side (camera control).
• When either party ends the call or closes their browser window, the other party detects the loss of the stream. The Javascript is notified and goes to the next step which is the display of a web page with an appropriate message for example.

Most of the equipment is placed behind firewalls. These allow TCP connection establishments to pass to an IP destination (address and port) in one direction only (outgoing), with exceptions allowed in the incoming direction. If both parties are protected by a firewall, and therefore each end up outside the other's firewall, neither can establish a TCP connection. This problem is solved by the intervention of a STUN server (12) included in the infrastructure (1). The address of the STUN server is included in the JavaScript on both sides. Each party addresses this server to negotiate suitable settings bypassing firewalls for a live connection. These parameters are included in the SDP proposals and responses.

Functions related to video communication

In the case where the guest's telephone has several cameras, the invention optionally makes it possible to activate one or the other, or both cameras simultaneously, and to modify this configuration as desired during the video communication. The chosen implementation can delegate this control to the guest and / or the inviting party, in particular by means of clickable pictograms.
The invention also provides for providing a switch on or off the LED which serves as a lamp to illuminate the dark scene. This control can be provided to the guest but also to the invitee, which allows the guest not to depend on the invitee for this setting which can prove to be complex for some people (especially destabilized in a situation of emergency).

The invention optionally allows the invitee and / or the guest to enter photos during the video communication, in particular by means of clickable pictograms or automatically according to a criterion relating to the video or sound flow, in particular: strong change brightness, contrast, change in sound level, exceeding a sound level, presence or absence of a sound signal. Automatic photo taking may also depend on a signal generated by an accelerometer on board the phone.
The invention also provides for proposing a control of the activation of the flash during the taking of photos, parameterization by hand of the guest, but also and above all of the guest in order to preserve simplicity on the guest side.

The invention optionally allows the invitee and / or the guest to record the video stream (s), in whole, in part or in multiple parts, in particular by means of clickable pictograms or criteria similar to those of the previous paragraph. .

The invention optionally makes it possible to make these recordings available to the guest and / or the invitee, depending on the choice of implementation, and optionally to affix a cryptographic digital signature sealing the observation with possibly a time stamp. The result can be available locally or deposited in online storage.

The invention also provides for controlling the switching of the audio output peripherals (ear speaker or hands-free speaker) and possibly the volume adjustment of the portable device.

Webpush authorization

In accordance with the provisions of the standardized Webpush, the consent of the guest is essential to register the possibility of addressing the portable device. The invention provides that the Javascript on both sides collect the authorization, before or after the video communication depending on the implementation. This authorization is requested from the internet browser, which presents the question to the user in a form that is specific to him. If this authorization is granted, the infrastructure (1) stores the correspondence between the identifier (2) and the Webpush addressing means or identifier. From this moment, when the infrastructure (1) will have to make choices on the standard means of transport to be used, the infrastructure will be able to try the Webpush, and we agree to call this a situation where "the Webpush is available ”, it being specified that the functionality of Webpush may also be unavailable for any other reason unrelated to the storage of this correspondence of identifiers by the infrastructure (1), in particular for technical reasons such as a rejection of a server third party to whom the Webpush request has been sent, unreachability of this Webpush server, etc. in which case we are talking about "Webpush failure".

• Toute autre invitation initiale à la visio communication telle que décrite depuis le début du document, émanant éventuellement d'invitants totalement disjoints (autre service, autre application, autre pays)
• Les informations de mise à disposition des documents post-communication visio (descriptions plus bas), leur mot de passe de déchiffrement, leur URL d'accès, ou bien même la data numérique les constituants si leur composition est implémentée dans le navigateur de l'invité.

This allows the following messages to be sent to the portable device by Webpush when available to replace an SMS which incurs a cost:

• Any other initial invitation to video communication as described from the beginning of the document, possibly coming from totally separate invitees (other service, other application, other country)
• Information on the provision of post-communication visio documents (descriptions below), their decryption password, their access URL, or even the digital data of the constituents if their composition is implemented in the browser of the guest.

In general, any mention of sending an SMS or other standard notification (email) from the infrastructure (1) and the portable device can be replaced by a Webpush, if previously authorized.

This results in an advantageous cost saving, in particular in the case of several separate uses of the invention involving the same infrastructure (1). However, the diversity of Webpush implementations in portable devices does not systematically ensure that the infrastructure (1) is informed of the correct delivery of the Webpush message. To overcome this problem, a timeout mechanism is provided. In the event that the infrastructure (1) has the means to communicate by Webpush, the message (such as the single link (3) to initiate a video) is sent by Webpush and a timer is triggered. If the expected action, such as the guest clicks on the single link (3), is obtained before the timer expires, the timer is stopped and destroyed. If the timer expires, the message is sent again by SMS.

The value of the waiting time before fallback on sending by SMS is a parameter adjusted according to the urgency or the importance of the video communication. For an implementation in an emergency call processing center (medical, fire), the timer can be lowered to zero or close to zero, resulting in more frequent use of the SMS. In less sensitive cases, the wait time can be extended to maximize the chances of avoiding an SMS.

Both websockets and webpushes allow the infrastructure (1) to send messages to both internet browsers, but websockets do not stay connected until the internet browser window has been closed. Webpushes can be used several weeks later, but the amount of information conveyed is limited.

Payment features

The invention optionally allows the inviting party or the guest to request payment from the other participant.

• soit à l'invité d'établir une condition de paiement, notamment la saisie du montant demandé, amenant l'infrastructure de l'invitant (1) à proposer un parcours de paiement par le biais d'un moyen de paiement déjà renseigné ou d'un compte de pré-paiement préalablement alimenté, ou d'un moyen de paiement numérique selon éventuellement plusieurs choix proposés, et selon les pratiques de paiement en ligne régionales
• soit à l'invité d'autoriser un débit d'un moyen de paiement déjà renseigné ou d'un compte de pré-paiement préalablement alimenté, pour un montant indiqué par l'invitant sur l'infrastructure (1)
• soit à l'invité de procéder à un moyen de paiement numérique selon éventuellement plusieurs choix proposés, et selon les pratiques de paiement en ligne régionales, pour un montant indiqué par l'invitant sur l'infrastructure (1)

This payment can be requested before the establishment of the video streams, ie when the guest's internet browser processes the single link (3), such as an interstitial (6) before the streams are triggered. This interstitial would allow

• either to the guest to establish a payment condition, in particular the entry of the requested amount, leading the guest's infrastructure (1) to propose a payment process by means of a payment method already entered or '' a pre-payment account previously funded, or a digital payment method according to possibly several choices offered, and according to regional online payment practices
• either to the guest to authorize a debit from a means of payment already filled in or from a pre-payment account previously funded, for an amount indicated by the guest on the infrastructure (1)
• either to the guest to proceed to a digital means of payment according to possibly several choices offered, and according to regional online payment practices, for an amount indicated by the guest on the infrastructure (1)

It is understood that this interstitial before the establishment of flows is at the expense of simplicity, the heart of the invention, and is therefore a subordinate implementation. The amount can be a maximum estimate of the price that will be defined at the end of the communication, in which case the pre-video stage is a debit authorization, and the post-video stage is the use of this authorization to carry out the actual payment.

• soit dans la même fenêtre du navigateur internet de l'invité,
• soit par l'envoi d'un nouveau lien unique (3) par un moyen numérique standard (4), le même moyen ou éventuellement un moyen différent pour cet usage (il peut s'agir par exemple d'un email, si le premier lien unique (3) déclenchant la visio fut envoyé par SMS).
• soit par ré-utilisation du même lien unique (3). Dans ce dernier cas, l'invité peut simplement cliquer à nouveau sur le lien qu'il a reçu avant la communication visio, ou rafraîchir sa page. Le même lien activé avant la communication visio amène à établir la communication visio, mais activé après la communication il amène aux propositions de paiement et à un éventuel récapitulatif de la communication.

Le paiement à l'issue de la communication visio maintient la simplicité d'établissement des flux, propriété clé de l'invention.Payment can also be requested at the end of the video communication,

• either in the same window of the guest's internet browser,
• either by sending a new unique link (3) by a standard digital means (4), the same means or possibly a different means for this use (it can be for example an email, if the first single link (3) triggering the video was sent by SMS).
• or by re-use of the same unique link (3). In the latter case, the guest can simply click again on the link he received before the video communication, or refresh his page. The same link activated before the video communication leads to the establishment of the video communication, but activated after the communication it leads to the payment proposals and a possible summary of the communication.

Payment at the end of the video communication maintains the simplicity of establishing flows, a key property of the invention.

Payment can be requested during the video communication, in which case the payment interface is presented on the portable device without interrupting the video communication. This allows a first oral exchange between the speakers which allows the applicant to present his tariff, the service being able to resume after payment.

The invention provides that either party may be offered the possibility of requesting payment from the other party. Thus, although the following examples put the payment at the expense of the guest, in other configurations where the invitee is the customer of a service provided by the guest the guest specifies his request for payment according to one of the above options (before, after or during).

The payment can provide for different price components which can be distributed for the benefit of different stakeholders, in particular the guest or the inviting, the operator of the infrastructure (1), and the possible interpreter (see below).

Guest or inviting data collection

• pour un médecin : nom prénom, numéro de sécurité sociale national, date de naissance, numéro de dossier d'assureur privé, nom du médecin traitant habituel
• pour un expert automobile : numéro d'immatriculation du véhicule...
• pour un service d'urgence : nom, prénom de l'invité et sa qualité de majeur, numéro de rappel

S'agissant de certains services où l'invité requiert des informations de l'invitant, il peut s'agir par exemple de services réservés aux majeurs : affirmation de sa qualité de majeur, date de naissance...In the same implementation, the invitee may need to collect information from the guest, or vice versa, which depends on the use case of the implementation. For example, if the same implementation is used by physicians, automotive experts, and emergency service regulators, the invention allows the requester to provide different data collection forms depending on a setting. The form proposed for data collection can result from a characteristic of the invitee (in particular his profession), or the implementation can leave the inviter free to define the data to be collected, in the form of a free form.

• for a doctor: surname first name, national social security number, date of birth, private insurer file number, name of the usual attending physician
• for an automotive expert: vehicle registration number ...
• for an emergency service: last name, first name of the guest and his capacity as an adult, callback number

Regarding certain services where the guest requires information from the inviting party, it may be, for example, services reserved for adults: affirmation of their status as an adult, date of birth, etc.

This collection can, in a manner similar to what is explained above, appear in pre-communication or post-communication, independently of the choice of implementation of payment requests in pre-communication or post-communication. In the situation where the request for data and payment are offered jointly (before or after the communication), the implementation can choose the order or possibly combine the whole into a single page.

Encryption of collected data

In order to alleviate the responsibility of hosting guest or inviting data, or in order to ensure end-to-end protection of data from the view of others, such data, whether stored on the 'infrastructure (1) of the implementation or just relayed, the invention provides for the local generation of a pair of asymmetric keys on both sides (by use of the cryptography APIs of internet browsers), sending to the opposite part via the websocket of the so-called "public" key, the use by the opposite part of this key to encrypt the data sent to the initial part which will make use the key that it will have kept secret to decrypt the digital data before it is made available to the guest or made available to the invitee (depending on the meaning).

The invention provides for the sending of a key in each direction, but the implementation can relate to a single sending according to the confidentiality of the data to be received in return (which will be the case of the example of application described. further away).

If this key exchange is carried out sufficiently upstream, the invention can provide for the storage of the elements intended for the other party in encrypted form (and therefore with an almost zero risk of compromising private data) without having to resort to sophisticated security systems. storage, possibly even by using storage solutions in the general public "cloud" (Amazon Web Services, Google Drive, etc.).

The storage facility allows disengagement of data transmission, making the guest and inviter steps decorrelated. This can be particularly useful to allow time for one of the parties to make the payment before transmission of the documents, which documents may already be prepared and available in their encrypted form on network storage.

An example of a practical embodiment is the use of the invention in the context of a medical consultation or with a banking advisor. In a context deprived of this encryption, the implementation should obtain approval to host the transmitted data - even for temporary storage - which data is to be given to the other party after payment for the consultation. It is impractical to keep both parties online during the payment period, and the storage of data to be returned against payment is necessary, as it is not possible to force its writer to wait for the payment to be made.

Transcription intermediary

In certain circumstances, notably the sensory handicap of the guest or the invitee, the implementation may offer the inviter and / or the guest the intervention of a transcriptionist (11). This request can occur when the video communication is initialized, or at any time if necessary during this communication. In this case, the flows take the form of two-way triangle connections, each part receiving the streams of the two other participants and the internet browser broadcasting the streams from its sensors to the two other participants.
The interpreter involved can either be an interpreter kept available on demand by the inviting service, or be chosen by the guest on the spot (interstitial of choice) or by prior configuration of the client on the transcription service. It may be expected that the interpreter will be paid in addition to the price offered for payment (see above).
By extension, it can be any external advisor or translator, effectively leading to a three-way video consultation.

Consultation staggered in time

The invention provides for the optional possibility of giving the invitee the initiative to shift in time the sending of the standard digital means (4) containing the invitation link (3), in particular so that it is triggered at a predefined time or after a certain period of time has elapsed. This can be the case when the invitee chooses the guest from a list, such as clicking on the guest in an online directory and it is preferable to make an appointment. This can also be the case for an automobile expert's report where the guest must be allowed time to get close to the vehicle, object of the report. When establishing the video communication, the infrastructure (1) determines whether a websocket link is still active with the guest terminal. Failing this, a standard digital means will also be used at the said moment to invite the inviting again to the video communication as is done for the guest: Webpush, Websocket, or SMS. Naturally, if it is possible that the websocket connection is no longer active when establishing the video communication and that SMS use cases arise, the infrastructure (1) will have previously collected the telephone number. mobile phone of the invitee, for example at the same time as the latter will have specified the time of the meeting or the delay to wait.

Exchange of confidential documents : preparation of a key or pair of keys

At the end of or during the video communication, the invention makes it possible to send confidential documents to the guest without unencrypted online storage.
In a first implementation, the asymmetric key pair mentioned above will be used for encryption and decryption by the browser (using the Internet browser's encryption APIs) before and after the transmission, which may involve temporary online storage.

• L'infrastructure (1) génère une chaîne aléatoire avant, pendant, ou à l'issue de la communication visio et est transmise par websocket ou dans le Javascript initial, lequel aux deux extrémités en assure l'affichage pendant toute la durée de communication visio sur l'écran, ou sur l'écran qui succède au raccroché : « Notez bien votre clé de suivi pour les échanges de documents ultérieurs : [chaîne aléatoire]. Elle vous sera demandée pour déchiffrer les documents. »
• En supplément ou alternativement à la précédente, la chaîne aléatoire peut être envoyée à l'invité par SMS, ce qui lui en donne une trace rémanente sans avoir à noter. Elle peut même être incluse dans le SMS d'invitation (4) contenant le lien à cliquer avant la communication visio, ceci présentant l'avantage d'économiser un SMS ultérieur. « Cliquez sur le lien .... Par ailleurs, votre mot de passe pour l'échange ultérieur des documents est ... ».
• L'implémentation peut prévoir que la partie variable du lien unique 3 soit la clé du chiffrage réversible

La valeur de cette clé peut être stockée localement par le navigateur internet de l'appareil portable, ce qui permet de l'afficher à nouveau à l'invité. Pour ce faire, il suffit que l'invité accède à une URL de l'infrastructure (1) qui retourne un code Javascript qui sait retrouver la clé dans le stockage local et l'afficher. La clé n'a pas à quitter l'appareil portable.
Cette implémentation ne couvre pas la transmission des documents chiffrés eux-même, lesdits documents peuvent être transmis par email ou par service web de transfert de document, puisqu'ils ne sont pas utilisables sous leur forme chiffrée. Néanmoins l'invention prévoit de mettre à profit les différents éléments exposés pour proposer une solution.In a second implementation, the encryption is provided according to a reversible encryption algorithm by a single shared key. The solution ensures that this key is shared in one of three ways:

• The infrastructure (1) generates a random chain before, during, or at the end of the video communication and is transmitted by websocket or in the initial JavaScript, which at both ends ensures the display for the entire duration of the video communication on the screen, or on the screen after hanging up: “Make a note of your follow-up key for subsequent document exchanges: [random string]. You will be required to decipher the documents. "
• In addition or alternatively to the previous one, the random string can be sent to the guest by SMS, which gives him a persistent trace without having to write down. It can even be included in the invitation SMS (4) containing the link to click before the video communication, this having the advantage of saving a subsequent SMS. "Click on the link .... In addition, your password for the subsequent exchange of documents is ...".
• The implementation can provide that the variable part of the unique link 3 is the key to the reversible encryption

The value of this key can be stored locally by the web browser of the portable device, allowing it to be displayed again to the guest. To do this, the guest just needs to access a URL of the infrastructure (1) which returns a JavaScript code that can find the key in the local storage and display it. The key does not have to leave the portable device.
This implementation does not cover the transmission of the encrypted documents themselves, said documents can be transmitted by email or by document transfer web service, since they cannot be used in their encrypted form. However, the invention provides for taking advantage of the various elements exposed to propose a solution.

Exchange of confidential documents: transmission of documents

As indicated, encrypted documents are suitable for being sent by email or deposited on online storage. The infrastructure (1) can provide this encrypted data hosting service or use third-party web hosting (Amazon Web Services, Google Drive). In this case, the infrastructure (1) uploads the encrypted data, determines the download URL of the encrypted packet, and transmits it to the guest by one of the standard transmission means mentioned, in particular Webpush, emails or SMS to fault. The internet browser will load the encrypted data and two cases arise.

In the second implementation (the shared key one), the document can typically be used as is, such as an encrypted PDF. The document opening tool (Acrobat Reader) takes care of the ergonomics of entering a password.
In the first implementation (with asymmetric keys), or if a proprietary encryption is applied in the second implementation (as opposed to the mechanism provided for by the PDF standard), it is a local script (web application, JavaScript, etc.) which can take care of the decryption from the key (private or shared) without the user's knowledge, and drop the decrypted file in the browser's usual drop-off location.
In a particular case, the variable data of the document are the only data transferred, separated from the rest of the document such as a dismemberment. The variable data of the document will be called “dismembered data”, and the complementary document “generic document”, the union of the two making it possible to reconstitute the final document, equal to the starting document. The dismembered data can be the data provided for filling in the fields of a PDF form, or the text of a letter without the standard letter consisting of its header, its footer and its possible graphic background. The standard letter or the PDF form are generic documents and they can be uploaded under a URL because they are devoid of sensitive data. The sensitive data and the URL of the generic document are encrypted by one of the two means above, and the encrypted packet transmitted to the infrastructure (1) so far as above. The advantage of this method is to lighten the data part as much as possible. The infrastructure (1) which receives the encrypted dismembered data can then use the Webpush to bring the data to the internet browser of the portable device. A second Webpush notifies the user of the receipt of his documents. When the guest clicks on this notification, the internet browser has the URL of the generic document and the encrypted dismembered data. The JavaScript code downloads the generic document, decrypts the data packet, combines the two, and reconstructs (regrouping) the document, then drops it in the usual place of the downloaded documents.

Exchange of documents requiring protection against forgery

The invention provides two mechanisms for protecting documents against falsification: a control document, and the addition of a verification hash.

• le remplacement d'un certain nombre de caractères ou de certains caractères par un symbole (à la manière dont les mots de passe informatiques sont occultés), par exemple tout caractère sauf les premiers de chaque mot et les chiffres.
• un floutage suffisant pour laisser apparaître la longueur des mots sans qu'ils ne soient lisibles.

The first mechanism requires online storage of a sufficiently trivialized version of the document so that it loses its confidentiality feature. We call this version the “control document”. It does not contain data sensitive and can therefore, after creation by the JavaScript of the terminal, transmission to the infrastructure, be hosted online by the infrastructure (1).
The unencrypted original, transmitted to the guest and typically printed by the latter, comprises a URL for accessing the control document, in text format and in optical coding such as QR-code. The control consists of entering or scanning the URL and thus displaying the control document, and visually comparing the original with the control document.
To constitute the control document, the commonality mechanisms executed by the JavaScript of the terminal which then posts its result to the infrastructure (1), can be for example and without limitation:

• the replacement of a certain number of characters or certain characters by a symbol (in the way in which computer passwords are concealed), for example any character except the first of each word and the numbers.
• sufficient blurring to reveal the length of the words without them being legible.

The second mechanism does not require any online storage. This involves performing a control signature - hash - on the characters of the page (or as many parts of pages as desired), signing these hashes (with a private key) and making them appear on the document. The check consists of scanning the document, using a character recognition conversion to isolate the signed hashes from the rest of the document, verifying the authenticity of the signed hashes (by a public key), then recalculating the hashes from the rest of the text of the document and compare them to the versions appearing on the document.

Exchange of documents for counted purposes

A unique identifier, such as a UUID, can be affixed to the documents. Therefore, an online service, possibly accessible from a URL printed on the document in textual form and optical coding (QR), makes it possible to ensure that the document has only been presented once or a number of times. of times suitable at a checkpoint. Since the first tamper resistance mechanism above is already a URL, it can serve both purposes simultaneously.

Concrete example of implementation. extended version

This example takes the situation of a medical consultation. This example is not restrictive to this field but illustrative. The medical consultation can be replaced by financial advice or any other area also involving confidential data and the exchange of sensitive documents at the end of the video communication.

Prerequisites

• Due to the doctor's activity, a configuration of the solution indicates that the data to be collected are the patient's last name, first name, date of birth and social security number.
• The doctor has registered with a payment processing organization on a cantonment account, a third-party organization called PSP (7) which has been approved by a prudential authority for this.

The infrastructure (1) is a website to which the doctor connects (in https). In the case of a free service (emergency doctor), identification and registration with the approved third party organization are not necessary.

Technical infrastructure (1)

• un serveur web communiquant en protocole HTTP/HTTPS (par exemple Apache + Nginx) et disposant de certificats SSL émanants d'un CA notoire,
• un serveur établissant des connexions websocket entre un serveur (possiblement le même serveur que le serveur web) et les navigateurs web des invitants et invités,
• une signalétique transitant par websocket
• des flux conformes à la norme WebRTC
• un serveur STUN/TURN permettant l'établissement de ces flux au travers de pare-feux réseaux par l'échange de paquets SDP

Les navigateurs internets se connectent au serveur websocket au chargement des pages HTML requérant la visio communication.
Quand il s'agit d'initier un flux vidéo, les navigateurs internet exécutent du code JavaScript et envoient des données par websocket au serveur qui transmet ces données et permet aux navigateurs internet de s'accorder sur les paramètres de la connexion de flux au standard WebRTC.
Les connexions websockets restent actives tant qu'il y a des besoins de signalétique et au-delà pour les besoins de signalétiques à l'initiative du serveur web, tant que la fenêtre du navigateur internet reste ouverte sur l'application (URL du site).The technical infrastructure is based on

• a web server communicating in HTTP / HTTPS protocol (for example Apache + Nginx) and having SSL certificates from a well-known CA,
• a server establishing websocket connections between a server (possibly the same server as the web server) and the web browsers of the invitees and guests,
• signage passing through websocket
• streams compliant with the WebRTC standard
• a STUN / TURN server allowing the establishment of these flows through network firewalls by the exchange of SDP packets

Internet browsers connect to the websocket server when loading HTML pages requiring video communication.
When it comes to initiating a video stream, internet browsers execute JavaScript code and send data via websocket to the server which transmits this data and allows internet browsers to agree on the parameters of the feed connection to the standard. WebRTC.
Websockets connections remain active as long as there are signage needs and beyond for signage needs at the initiative of the web server, as long as the web browser window remains open on the application (site URL) .

Identification

As soon as a payment is foreseen, the doctor begins by identifying himself. In this example, this is done using his email address. The infrastructure probes the PSP for the existence of a payment account. If such an account is found, the infrastructure (1) sends the email address a link containing a signature. The doctor clicks on this link, and returns to the site with the signature which certifies that he is the legitimate holder of the email account and therefore of the payment account with the PSP. The infrastructure (1) stores this email address or an account identifier in a browser cookie, and a time-stamped signature allowing the infrastructure (1) to subsequently ensure that the identification has been made and that it is recent within an acceptable threshold.

Consultation

The doctor is possibly already in telephone consultation (0) with the patient, especially if it is an emergency doctor. He knows, or copies from his business software, or asks the patient with whom he is talking on the phone, the patient's mobile number.
The doctor has an extremely simple web interface, showing only one input field in this example. He sticks or types the patient's mobile number and validates it. No other interaction on his part is required, he will see the video stream appear.

The infrastructure determines a consultation number, puts the doctor's browser on hold for this communication to be established, prepares a unique signed link attached bijectively to the consultation, and sends this link by SMS to the patient.
If and only if the doctor is identified and the PSP is responsible for the legitimate activity of a doctor (registration with the national order of doctors), the text of the SMS includes an advertisement with the name of the doctor ("Dr X invites you click on this link ”) to reassure the patient. The infrastructure prepares a password, adds it to this SMS ("Your password for documents after the consultation is: ...") and will display this password to the doctor if he wishes to encrypt his documents. not this simple way (in addition to the asymmetric key system described below).

The patient clicks on the SMS without interrupting the possible call in progress. This launches the internet browser on his portable device which may ask for permission to access his camera and microphone, which the patient accepts. Apart from this possible authorization, the patient has absolutely no other action to take. During future use, the browser will have memorized its authorization and the only action required will be the click on the link received by SMS. Videophone communication is established.

The patient and the doctor have, in this example, pictograms to activate one, the other, or both cameras of the telephone. In the case of two active cameras, the doctor can choose to have the two streams side by side or the one displayed on the phone larger. The doctor has a button for photographing and recording various sequences which will then be available in the directory in which the browser usually deposits the downloaded documents. Other implementations and storage locations would be possible, especially in a network, but not in this implementation. The doctor has a button to turn on the flashlight of the portable device. The doctor has control over the passage of the hands-free speaker and possibly the volume of the portable device.

Any pre-existing phone call can remain active throughout the video consultation, at the doctor's request.

The patient and the doctor have a button to bring in a Sign Language interpreter or a written transcriptionist if the patient is deaf, in which case the screen of the portable device will dedicate the main space to the Language interpreter. Signs, or to the transcribed text. The doctor interface will present the two speakers side by side.

Payment

• dans le cas d'un médecin non identifié, d'un urgentiste, ou d'une consultation gratuite, le retour simple à l'écran permettant d'initier la communication visio avec un autre patient. Le process reste extrêmement simple et s'arrête là.
• dans un cas d'un médecin identifié chez un PSP (selon cet exemple), l'implémentation de cet exemple prévoit que le médecin saisisse un prix de consultation, une codification de son acte, un texte d'ordonnance médicale ou de certificat médical, des données d'arrêt maladie. Il peut commencer à saisir ces éléments sans attendre la fin de la communication visio.

Sur validation par le médecin au moins du prix de paiement, l'infrastructure (1) détermine si le navigateur du patient est toujours disponible et connecté par websocket à l'infrastructure (1), auquel cas, ou par l'intermédiaire d'un WebPush normalisé (www.w3.org/TR/push-api/), le navigateur du patient charge une page contenant un formulaire

• requérant les données souhaitées et dépendant de la profession (voir section « préalables » : nom, prénom, date de naissance et numéro de sécurité sociale du patient)
• affiche le prix demandé par le médecin
• propose via un curseur de laisser un pourboire supplémentaire pour l'opérateur de l'infrastructure (1)
• un bouton d'envoi

Si le navigateur de patient n'est plus connecté par websocket à l'infrastructure (1) ou joignable par WebPush, l'infrastructure envoie un nouveau SMS au patient avec un lien (identique ou différent) et un nouveau message l'invitant à cliquer sur le lien, ce qui amènera au formulaire ci-dessus.
Pendant ce temps, le médecin peut continuer ou modifier les autres saisies (codification de son acte, texte d'ordonnance médicale ou de certificat médical, données d'arrêt maladie). Ces données sont stockées localement via l'API de stockage local du navigateur internet, dans cette implémentation.When one or the other presses the end of communication button, the implementation of this example foresees

• in the case of an unidentified doctor, an emergency physician, or a free consultation, the simple return to the screen allowing the initiation of video communication with another patient. The process remains extremely simple and stops there.
• in a case of a doctor identified with a PSP (according to this example), the implementation of this example provides for the doctor to enter a consultation price, a codification of his act, a text of a medical prescription or a medical certificate, sick leave data. He can start entering these elements without waiting for the end of the video communication.

Upon validation by the doctor at least of the payment price, the infrastructure (1) determines whether the patient's browser is still available and connected by websocket to the infrastructure (1), in which case, or through a Standardized WebPush (www.w3.org/TR/push-api/), the patient's browser loads a page containing a form

• requesting the desired data and depending on the profession (see “prerequisites” section: patient's last name, first name, date of birth and social security number)
• displays the price requested by the doctor
• proposes via a slider to leave an additional tip for the operator of the infrastructure (1)
• a send button

If the patient's browser is no longer connected by websocket to the infrastructure (1) or reachable by WebPush, the infrastructure sends a new SMS to the patient with a link (identical or different) and a new message inviting him to click on the link, which will lead to the above form.
During this time, the doctor can continue or modify the other entries (codification of his act, text of medical prescription or medical certificate, sick leave data). This data is stored locally through the web browser's local storage API, in this implementation.

Payment processing

• le navigateur génère une paire de clés asymétriques, conserve celle dite privée dans son stockage local (API de stockage du navigateur internet), adjoint celle dite publique au formulaire
• transfère les données à l'infrastructure (1) qui prépare une URL de paiement chez le PSP, prenant soin de rattacher toutes les données reçues à ce paiement
• redirige le navigateur internet du patient vers les interfaces de paiement du PSP
• lors du traitement par le PSP, les différents constituants du montant du paiement sont répartis au profit des différents intervenants dans des comptes de cantonnement dédiés.

Sur paiement validé, le PSP notifie l'infrastructure (1) qui, si elle détecte une connexion ouverte en websocket avec le navigateur internet du médecin, notifie le navigateur internet du médecin de cela, résultant dans une information au médecin, ou utilise un mécanisme de webpush normalisé (www.w3.org/TR/push-api/) pour informer le médecin. Mais cette information reste optionnelle. Elle invite le médecin à aller sur une page d'historique de consultations.When the patient validates his form with the price and his data

• the browser generates an asymmetric key pair, keeps the so-called private key in its local storage (internet browser's storage API), adds the so-called public key to the form
• transfers the data to the infrastructure (1) which prepares a payment URL at the PSP, taking care to link all the data received to this payment
• redirects the patient's internet browser to the PSP payment interfaces
• during processing by the PSP, the various constituents of the payment amount are distributed for the benefit of the various participants in dedicated block accounts.

On validated payment, the PSP notifies the infrastructure (1) which, if it detects an open connection in websocket with the doctor's internet browser, notifies the doctor's internet browser of this, resulting in information to the doctor, or uses a mechanism standardized webpush (www.w3.org/TR/push-api/) to inform the physician. But this information remains optional. She invites the doctor to go to a consultation history page.

Consultation history

This page of the site is only available if the doctor is authenticated (in our example, authenticated at the PSP). When the doctor accesses it, the infrastructure (1) receives as a cookie the email or account identifier with the PSP, as well as his signature integrity that it verifies. When this data is unaltered and corresponds to the values that the infrastructure had set during identification, then the list of payment transactions is retrieved from the PSP, using the email address or the account identifier.
The internet browser displays a list of consultations, and their payment status, as well as a way to display or use the user data entered by the patient and associated with the payment request.

Use of customer data by the doctor

This user data can simply be viewed so that the clinician can copy paste it into other tools. Alternatively and in a more elaborate way, a JavaScript library makes it possible to combine customer data and local data entered by the doctor to fill out standardized PDF forms and present (or not) to the doctor one or more final / final PDFs.
The doctor can use the PDF signature mechanisms thanks to a commercial digital certificate whose validation chain certifies his identity. He can also use the password that the infrastructure (1) has displayed to him to lock the opening of the PDF. In this simple case, it only exploits protection mechanisms provided by PDF editors.

Provision of documents to the patient

Upon validation by the doctor, the PDF (s) are encrypted using the public key generated on the patient's internet browser. They are then transmitted to the infrastructure (1) which possibly ensures their storage through the use of third-party storage such as Amazon Web Services.
If the websocket connection with the patient's browser is still open, or if the use of standardized Webpush is possible, the infrastructure (1) notifies the patient of the availability of his documents. Failing this, a link is sent (same URL or different URL) by SMS or by email if the address is available (especially if it is collected by the PSP), in all cases leading the patient's internet browser to access the encrypted data, to decrypt it using its private key retrieved from the browser's local storage, and to make the document (s) available as a standard download in the usual directory for storing downloaded documents. As mentioned above, another implementation will only transfer (ideally by Webpush or by default by uploading under a URL accessed by the portable device) only sensitive data and a blank document reference (template, PDF form, background page) and the reconstruction will be done through the guest's internet browser.

In this implementation, the infrastructure (1) does not store any medical data. If patient data (the patient's last name, first name, date of birth and social security number) were to be considered medical data, the implementation would include a key pair generation in the doctor's internet browser, one keys accompanying the payment request to be used to encrypt the data entered by the patient. It seemed to us wise in this example to show the encryption only in one direction, to show the optional side.

In this implementation, the infrastructure (1) does not even store doctor account data (login, password), delegating the validation of a health professional to the PSP. This is a choice in this example to show that it is possible to operate without any data storage in the infrastructure (1) or even a customer account for the guest. The list of consultations and the associated data are hosted by the PSP, as metadata of a payment. This data in our example is not of a medical nature, but if it were considered sensitive it would still be stored at the PSP in an encrypted form. Sensitive medical data (prescription, etc.) are only stored locally by the doctor's internet browser (via its local storage API).

Use of Printed Documents - Orders

In the continuation of this example, the patient prints their prescription and takes it to the pharmacy. In the absence of a digital document (digital signature of the doctor and possibility of verifying the authenticity of the prescription, correspondence to the original), it is important to provide the pharmacist on the one hand with a means of ensuring that the The prescription has not been changed, and secondly that it has not already been processed by another pharmacist.
The current principles are based on verifying the doctor's signature on an original document, then affixing a pharmacist's stamp on the original, which can therefore no longer give rise to the dispensing of drugs in another pharmacy.

To overcome this, the invention provides two separate but cumulative mechanisms: a control document or verification hashes. These mechanisms are described here for prescriptions, but can be generalized to other documents in the example (work stoppage, medical certificate, treatment sheet, declaration of an accident at work, etc.), or to any other document in this example. other uses of the invention.

Control document

In addition, documents uploaded by the doctor's internet browser to the infrastructure (1) (PDF signed and encrypted by the doctor, or by the application running in the terminal's internet browser, or just the encrypted data packet if consolidation takes place on the portable device), the terminal's internet browser prepares a copy of the order in a control PDF document (or image) in which all characters from A to Z, both upper and lower case, are replaced by an opaque character (a solid circle for example like obfuscation of password entries) except for the first character of each word. The figures are not replaced. Optionally, all upper case letters are replaced by lower case letters.
This document is transmitted to the infrastructure (1) unencrypted because it no longer contains any medical data, the first letters not being sufficient to identify the drugs in a sentence which cannot be assumed to begin with the name. of the drug. The patient's social security number and initials are in the clear. The number of boxes or tablets are clear, without knowing whether it is boxes, tablets, or frequency of intake. The document does not disclose any actual medical data, but nevertheless enough data that a malicious user would wish to modify. This document can therefore be made accessible on the Internet via a URL (possibly including a signature), a document hosted by the infrastructure (1) or in a third-party storage service.
The URL is such that brute force does not allow documents to be obtained by unauthorized persons.
This URL is written on the medical prescription (the prescription encrypted and sent to the patient, printed, brought to the pharmacy), in text as well as in QR-code or any other optical coding. The pharmacist can thus display the control document in his internet browser, and visually verify that the prescription has not been altered in order to change the dosages or modify the planned drugs.
On access to this online version of the control document, the pharmacist can then irreversibly pass the prescription in a delivered status. This allows any other pharmacist to be alerted if the patient uses another printout of their prescription.
The signature of the URL mentioned above is not essential. It just prevents the system from being queried maliciously with random parameters. Preferably, an asymmetric key signature would be used, the private key residing only at the heart of the service responding to the access URL.

Verification hash

The patient's browser calculates a signature (hash) of the document and inscribes it on the document, framed by signage allowing it to be isolated in the optical recognition.
On presentation of the prescription to a pharmacist, the latter scans it and uses a character recognition mechanism (OCR) which feeds the same hash algorithm (excluding the hash itself, of which a graphic marker indicates the location) . The key must match, or the pharmacist proceeds to additional manual checks (doctor's call, as in the case of doubts about the authenticity of a handwritten prescription).
A refinement of this mechanism consists in putting several hashes, for example one per quadrant, in order to identify the intact parts and those whose verification fails. A second pass may prove to be more fruitful.
This mechanism does not require any storage of medical data in the network. The OCR and hash recalculation tool can be either local or remote on a web service.

Unique identifier referenced on a centralized service

To overcome the other problem, the multiple use of this prescription printed several times which the verification hash does not remedy, the document can be the subject of an attribution of a unique number (or with a very high probability of 'be unique) of type UUID (RFC 4122). This identifier is encapsulated in a URL which is entered in clear (appended with a possible signature) and in QR-code or any other optical coding on the document. When this URL is accessed for the first time, the status of this document irreversibly changes to a “processed” state or increases a counter and possibly saves other data (IP address, pharmacist identifier).
Any subsequent access to this URL generates an alert display, or the display of the number of flashes and accesses of this URL or any other relevant data (identifier of the pharmacist who previously processed the prescription).
The signature of the URL mentioned above is not essential. It just makes it possible to prevent the system from being maliciously fed by a large random number of identifiers. Preferably, an asymmetric key signature would be used, the private key residing only at the heart of the centralized service.

The previous protections are cumulative. They can be generalized to any document whose online storage is not desired but whose integrity must be verifiable in a very high proportion of cases, and the number of uses or details of use (who, when, where ) must be collected.

Claims (15)

Video telephony communication method by communicating an inviting (9) with a guest (10), the guest having a portable device (8) equipped with a camera, a microphone, an internet browser, and capable of digital communication, the guest having a terminal (6) equipped with an internet browser (for example a desktop computer, laptop, tablet or possibly mobile phone), an internet connection, allowing connection to a composite infrastructure (1) at least one web server ensuring the accessibility of a website, the method comprising the following steps, in chronological order: - the inviting party connects to the website, - the invitee provides the infrastructure with an identifier (2) of the guest, - the infrastructure generates a first link (3), such as a URL, and transmits this link by standard digital means (4) to the guest's device, - the guest clicks on this link (3), - the guest's browser accesses the camera and / or microphone of the portable device (8), - the guest's browser establishes a videophone flow (5) with the guest's browser, the process being characteristic in that • the method does not require the installation of specific software, neither on the portable device (8), nor on the terminal (6), and in that • the process does not require identification from the guest (10) • the standard means of communication (4) is an SMS or an MMS or a Webpush Method according to Claim 1, in which the standard means of communication is primarily the Webpush if such a means is available, with recourse to SMS only if the Webpush is not available, if the Webpush request fails, or if there is no SMS. a not within a predefined time either acknowledgment of the webpush or triggering of the desired action; which delay can be configurable. Method according to one of the preceding claims, in which the first step of claim 1 is preceded by the establishment of a communication telephone (0) between the guest and the invitee, this one being optionally maintained during the whole process. Method according to one of the preceding claims, in which the establishment of the videophone call does not require the invitee to identify and / or only requires the following actions: entering the identifier (2) or choosing the guest from a list; optionally, if and only if the implementation provides for bidirectional communication, authorization of access to the audio and / or video sensors of its terminal. Method according to one of the preceding claims, in which the establishment of the videophone call does not require from the guest, apart from clicking on the link, any other action, except possibly an authorization of access to the audio sensors and / or video from their portable device. Method according to one of the preceding claims, in which the identifier of the guest is a telephone number or an email address. Method according to one of the preceding claims, in which the videophone communication is mono-directional. Method according to one of the preceding claims, in which the inviter and / or the guest has a means of activating or modifying on the portable device - the "hands-free" mode of the telephone conversation and / or - the "hands-free" mode of video communication and / or - adjusting the volume of the sound reproduction (loudspeaker) and / or - adjusting the volume of the sound capture (microphone level) and / or - the choice of a camera among a plurality of cameras of the portable device and / or - control of the "torch" lighting light - taking photos or various video recordings which can optionally be digitally signed and / or time-stamped. Method according to one of the preceding claims, in which documents are exchanged during the communication or subsequently, in which optionally the documents are encrypted or access protected by a shared password, which password will have been shared during the video communication. , or will be shared at the end of the video communication, by display and / or sending of SMS and / or Webpush, and possibly stored locally by the internet browser for re-display or its software use to decrypt documents. Method according to the preceding claim in which the encryption password is announced by the standard communication means (4), possibly in advance together with the link (3), or in which the encryption password is one of the constituents of the link (3). Method according to one of the preceding claims, in which a generation of asymmetric encryption keys takes place in one or the other or each of the internet browsers and where the video communication or the end of connection screens is / are the moment sharing of public keys, the other key remaining secretly stored locally, in order to encrypt / decrypt exchanges of documents or dismembered data (parts) of a final document, these exchanges of documents or dismembered data being parallel or subsequent to video communication. Method according to one of the preceding claims, in which the documents, or the variable data dismembered from each document, are encrypted, and are transported to the other party; and in which the browser of the other party locally decrypts the encrypted documents, or the dismembered variable data that it reassembles with a generic document part to locally constitute the final document; the transmission of documents or variable data taking place in its encrypted form by Webpush, websocket and / or HTTP (s) with possibly deposit on online storage. Method according to one of the preceding claims further allowing one of the parties to involve an interpreter or an adviser or a translator (11) or any other third party before the establishment or during the video communication, resulting in the establishment of flow in triangle each transmitting its outgoing flow to the two recipients. Software which, when it is embedded on a web server, makes it possible to carry out the method according to one of the preceding claims. Web server provided with software making it possible to carry out the method according to one of the preceding claims.

Images