DOMAINE TECHNIQUE AUQUEL SE RAPPORTE L'INVENTION La présente invention concerne de manière générale le domaine de l'USB, c'est-à-dire de la connexion de périphériques informatiques à un hôte conformément à la norme USB (de l'anglais « Universal Sériai Bus » ou, en français, « Bus Universel en Série »).

Elle concerne plus particulièrement un procédé de reconnaissance d'un périphérique par un hôte, ce qu'on peut également appeler « procédé d'appareillage ».

Elle concerne également un hôte et un périphérique permettant de mettre en œuvre ce procédé.

ARRIERE-PLAN TECHNOLOGIQUE

Le protocole USB est un protocole très utilisé dans le domaine de l'informatique pour permettre à deux appareils de communiquer, notamment parce qu'il est universellement utilisé par tous les fabricants d'appareils informatiques. Il est également utilisé dans le domaine de l'automobile.

Dans ce domaine, les véhicules embarquent un système d'exploitation qui est propre au fabricant du véhicule et qui permet d'offrir aux conducteurs des fonctions très variées, notamment de navigation, de radio, de climatisation...

Actuellement, les usagers des véhicules souhaitent pouvoir appareiller leurs propres téléphones mobiles (ou autres appareils mobiles intelligents) avec leurs véhicules, de façon à pouvoir profiter de fonctions propres à leurs téléphones. Ils souhaitent notamment pouvoir utiliser une application stockée dans leurs téléphones et dédiée à l'automobile (ci-après nommée « application téléphone-véhicule »). Une telle application téléphone-véhicule est par exemple déjà connue sous le nom de « Android Auto ^® » ou « Apple CarPlay ^® ».

C'est la raison pour laquelle les constructeurs souhaitent commercialiser des véhicules dont les systèmes d'exploitation comportent un logiciel (ci-après nommé « logiciel tiers » ou « logiciel d'exécution tiers ») spécialement conçu pour communiquer avec les téléphones mobiles utilisant l'application téléphone-véhicule. La demanderesse a toutefois constaté que, depuis que les systèmes d'exploitation des véhicules embarquent ces logiciels tiers, certains périphériques USB qui étaient jusqu'alors supportés ne peuvent plus l'être. Autrement formulé, certains périphériques USB qui parvenaient à s'appareiller n'y parviennent plus.

OBJET DE L'INVENTION

Afin de remédier à l'inconvénient précité de l'état de la technique, la présente invention propose un procédé d'appareillage d'un périphérique avec un hôte, comprenant :

- une étape de détection du branchement d'une fiche USB du périphérique dans un port USB de l'hôte,

- une étape de réception par l'hôte d'un set principal de paramètres de réglage et d'un set alternatif de paramètres de réglage émis par le périphérique,

- une étape de vérification par l'hôte de sa capacité à communiquer avec le périphérique compte-tenu des paramètres de réglage du set principal,

- si le périphérique est capable de communiquer avec l'hôte avec les paramètres de réglage du set principal, une étape de chargement d'un logiciel d'exécution conventionnel permettant à l'hôte de communiquer avec le périphérique sur la base des paramètres de réglage du set principal, ou

- sinon :

- une étape de vérification par l'hôte de sa capacité à communiquer avec le périphérique compte-tenu des paramètres de réglage du set alternatif, puis,

- si le périphérique est capable de communiquer avec l'hôte avec les paramètres de réglage du set alternatif, une étape de chargement d'un logiciel d'exécution conventionnel permettant à l'hôte de communiquer avec le périphérique sur la base des paramètres de réglage du set alternatif.

Selon l'invention, au moins un premier des paramètres de réglage du set principal est irréalisable quel que soit l'hôte, de façon à ce que l'hôte considère qu'il n'est pas capable de communiquer avec le périphérique sur la base des paramètres de réglage du set principal. Pour parvenir à cette invention, la demanderesse a recherché l'origine du problème d'appareillage expliqué supra. Elle a constaté que les systèmes d'exploitation embaqués dans les véhicules, depuis qu'ils comprennent les logiciels tiers (dont on rappelle qu'il s'agit des logiciels embarqués dans les véhicules afin de permettre aux usagers d'utiliser une application téléphone- véhicule stockée dans leur téléphone mobile), ne suivent plus le protocole édictée par la norme USB.

Elle s'est notamment aperçue que l'un de ces logiciels tiers force le processus d'appareillage à suivre une certification reposant sur la connexion USB mais différente du protocole USB classique, ce qui aboutit au rejet de certains périphériques non supportés par le logiciel tiers.

Pour bien illustrer le problème qui se pose, on a représenté sur la figure 1 le protocole de communication qui s'établit dans ce cas entre un périphérique 20 (typiquement un téléphone mobile) et un hôte 10 (typiquement le calculateur du véhicule automobile).

Au cours d'une première étape T1 , le périphérique 20 est connecté à l'hôte 10 via son port USB.

Au cours d'une étape T2, le périphérique 20 envoie à l'hôte 10 un set principal de paramètres de réglage (identifiant du fabricant, identifiant du périphérique 20, intensité du courant nécessaire pour fonctionner, bande- passante nécessaire, ...).

Au cours d'une étape T3, l'hôte 10 vérifie si le périphérique 20 est du type auto-alimenté ou non.

Si le périphérique n'est pas du type auto-alimenté (clé USB, ...), l'hôte 10 peut en déduire que le périphérique 20 ne peut pas être un téléphone mobile embarquant l'application téléphone-véhicule. Alors, au cours d'une étape T4, l'hôte 10 charge un logiciel d'exécution conventionnel adapté au périphérique 20.

En revanche, si le périphérique est du type auto-alimenté (téléphone mobile, tablette, ...), l'hôte 10 en déduit qu'il se peut que le périphérique 20 soit un téléphone mobile embarquant l'application téléphone-véhicule. Alors, au cours de l'étape T5, l'hôte 10 recherche si le périphérique est de la marque du fabricant de l'application téléphone-véhicule (et éventuellement s'il embarque les informations relatives au support de l'application téléphone-véhicule).

Si tel est le cas, ce qui signifie que le périphérique 20 embarque l'application téléphone-véhicule, au cours de l'étape T6, l'hôte 10 charge alors le logiciel d'exécution tiers.

Si ce n'est pas le cas, l'hôte 10 cherche à savoir si le périphérique 20 embarque malgré cela l'application téléphone-véhicule (typiquement, certains téléphones non commercialisés par Google ^® peuvent embarquer Android Auto ^® si cette application a été au préalable téléchargée dans le téléphone concerné).

Pour lever ce doute, au cours de l'étape T7, l'hôte 10 envoie alors une requête au périphérique 20.

Au cours de l'étape T8, l'hôte 10 peut ainsi vérifier si le périphérique 20 embarque l'application téléphone-véhicule.

Si tel est le cas, au cours de l'étape T9, l'hôte 10 charge alors le logiciel d'exécution tiers, en substituant aux paramètres de réglage du périphérique 20 des paramètres de réglage compatibles avec le logiciel d'exécution tiers.

Dans le cas contraire, le processus s'interrompt à l'étape T10. La demanderesse a constaté que c'est à cause de cette étape que certains périphériques sont rejetés par l'hôte 10 alors qu'ils étaient jusqu'alors supportés.

En pratique, la demanderesse a ainsi pu constater qu'à partir de l'étape T7, le processus ne respecte plus rigoureusement le protocole édicté par la norme USB.

La demanderesse propose alors une solution qui suit le protocole édicté par la norme USB et qui offre aux fabricants de téléphones mobiles une solution pour leur permettre d'identifier très facilement les périphériques utilisant leur système d'exploitation, afin que l'hôte puisse alors charger le logiciel d'exécution tiers quand un tel périphérique y est branché.

Cette solution consiste à utiliser de manière détournée une fonction offerte par la norme USB et qui n'est presque jamais utilisée, à savoir l'utilisation de sets alternatifs de paramètres de réglage (en anglais, « alternate settings »).

Avant de décrire en quoi cette fonction est détournée, on peut tout d'abord décrire comment cette fonction est utilisée de façon classique.

Lorsqu'un hôte comporte plusieurs ports USB et qu'il est donc possible d'y connecter simultanément plusieurs périphériques, il convient que l'hôte vérifie à chaque branchement de périphérique s'il est en mesure de supporter tous ces périphériques (par exemple s'il est en mesure de tous les alimenter en courant).

S'il n'est pas en mesure de les supporter tous, le dernier périphérique branché n'est généralement pas accepté. C'est pour éviter un tel rejet que les sets alternatifs de paramètres de réglage ont été conçus.

Ainsi, lorsque l'un des périphériques comporte deux sets de réglage (le set principal et le set alternatif), la norme USB permet d'utiliser ce périphérique en mode dégradé (c'est-à-dire en utilisant le set alternatif de paramètres de réglage).

A titre d'exemple, pour bien comprendre cette fonction offerte par la norme USB, on peut considérer un périphérique particulier, à savoir une caméra USB (ou « webcam ») comportant un set de réglage principal permettant d'utiliser de manière poussée les capacités de la caméra (en haute définition) et un set de réglage alternatif permettant d'utiliser cette même caméra en mode dégradé (en basse définition, voire sans certaines fonctionnalités, telle que la fonctionnalité appareil photo). De cette façon, si l'hôte n'est pas en mesure d'utiliser de façon poussée la caméra, au lieu de la rejeter, il pourra l'utiliser de façon dégradée. De manière générale, le set de réglage alternatif permet tout de même d'utiliser le dispositif, mais de manière basique.

Ici, l'invention consiste à utiliser le set alternatif de paramètres de réglage afin d'y stocker les données nécessaires au bon fonctionnement du logiciel d'exécution tiers.

Le set principal de paramètres de réglage est quant à lui au contraire utilisé de façon à ce que l'hôte rejette systématiquement ce set de paramètres de réglage et qu'il en déduise automatiquement que le périphérique est compatible avec le logiciel d'exécution tiers.

Le set principal de paramètres de réglage est en effet conçu de façon à être impossible à satisfaire au sens du protocole USB et à servir d'identifiant pour permettre à l'hôte de détecter facilement que le périphérique est compatible avec le logiciel d'exécution tiers.

Cette solution présente de nombreux avantages.

Elle permet de suivre le protocole USB, si bien que les périphériques USB n'embarquant pas l'application téléphone-véhicule ne seront pas rejetés par l'hôte.

Cette solution est facilement déployable puisqu'elle nécessite seulement de modifier les réglages enregistrés dans les périphériques embarquant l'application téléphone-véhicule, par une simple mise à jour.

Elle est enfin utilisable même lorsque le système d'exploitation embarqué dans le véhicule stocke différents logiciels d'exécution tiers (adaptés à fonctionner avec des téléphones mobiles embarquant des systèmes d'exploitation différents) : il suffit pour cela d'utiliser des paramètres de réglages dont les valeurs sont non conformes au protocole USB et différentes selon que l'un ou l'autre des logiciels d'exécution tiers doit être chargé.

D'autres caractéristiques avantageuses et non limitatives du procédé de reconnaissance conforme à l'invention sont les suivantes :

- ledit premier paramètre de réglage du set principal présente une valeur non conforme à la norme USB ;

- ledit premier paramètre de réglage du set principal présente une valeur prédéterminée, qui est associée audit logiciel d'exécution tiers à charger

- ledit premier paramètre de réglage du set principal est relatif à une intensité électrique d'alimentation, dont la valeur est strictement supérieure à 500 milliampères, voire strictement supérieure à 900 milliampères (cette valeur pouvant être prise en pratique supérieure à 1 A, voire à 10 A, comme proposé plus loin) ; - ledit premier paramètre de réglage du set principal est relatif à un nombre de canaux de communication (ou « IN/OUT Endpoints » selon l'appellation d'origine anglo-saxonne parfois utilisée), dont la valeur est strictement supérieure à 16 ;

- le périphérique est un téléphone ;

- l'hôte est embarqué dans un véhicule.

L'invention concerne aussi un hôte comprenant :

- un port USB adapté à recevoir une fiche USB d'un périphérique, et

- un calculateur qui est adapté à communiquer avec un contrôleur du périphérique au travers du port USB, et qui est adapté à mettre en œuvre un procédé de reconnaissance tel que précité.

Préférentiellement, le calculateur comporte une mémoire qui stocke un logiciel d'exécution tiers et une valeur prédéterminée pour un premier paramètre de réglage, ladite valeur étant irréalisable et étant associée audit logiciel d'exécution tiers de telle façon que lorsqu'un périphérique envoie à l'hôte un set principal de paramètres de réglage dans lequel le premier paramètre de réglage comporte cette valeur prédéterminée, l'hôte charge automatiquement ledit logiciel d'exécution tiers afin de communiquer avec ce périphérique.

L'invention concerne également un périphérique comprenant :

- une fiche USB adaptée à être engagée dans un port USB d'un hôte, et

- un contrôleur qui est adapté à communiquer avec un calculateur de l'hôte au travers de la fiche USB et qui comporte une mémoire stockant un set principal et un set alternatif de paramètres de réglage, au moins un premier des paramètres de réglage du set principal étant irréalisable quel que soit l'hôte, de façon à ce que l'hôte considère qu'il n'est pas capable de communiquer avec le périphérique sur la base des paramètres de réglage du set principal.

DESCRIPTION DÉTAILLÉE D'UN EXEMPLE DE RÉALISATION La description qui va suivre en regard des dessins annexés, donnés à titre d'exemples non limitatifs, fera bien comprendre en quoi consiste l'invention et comment elle peut être réalisée. Sur les dessins annexés :

- la figure 1 présente les étapes principales d'un procédé conforme à l'état de l'art, permettant d'appareiller un périphérique USB avec un hôte ;

- la figure 2 présente les variations de grandeurs électriques pouvant être observées aux bornes d'un port USB lors de l'appareillage d'un périphérique USB avec un hôte, en particulier pendant les phases dites d'énumération ;

- la figure 3 présente les étapes principales d'un procédé conforme à l'invention, permettant d'appareiller un périphérique USB avec un hôte ; et

- la figure 4 est un exemple de contexte dans lequel peut être mise en œuvre l'invention.

L'invention porte de manière générale sur l'appareillage d'un quelconque périphérique USB avec un quelconque hôte.

A titre préliminaire, pour bien comprendre l'invention, on peut décrire en référence à la figure 2 la manière selon laquelle un périphérique s'appareille généralement à un hôte conformément au protocole USB.

On rappellera avant cela que le périphérique comporte dans sa mémoire au moins un set de paramètres de réglage permettant de la caractériser.

On rappellera aussi qu'une connectique USB comporte au moins quatre bornes électriques, dont deux bornes d'alimentation notées Vbus et GND, et deux bornes de communication notées D+ et D-.

On a représenté sur la figure 2 les variations des tensions qui peuvent être mesurées sur ces quatre bornes électriques lorsqu'on branche un périphérique sur un hôte.

Dans un premier laps de temps At1 , la tension à la borne d'alimentation Vbus augmente, ce qui permet d'alimenter en courant le périphérique.

Dans un second laps de temps At2 ne devant pas dépasser 100ms, le périphérique se signale à l'hôte en envoyant un signal sur la borne D+ (ou D-).

Dans un troisième laps de temps At3 ne devant pas dépasser 100ms, le périphérique fait varier la tension sur la borne D+ (ou D-) afin que l'hôte puisse vérifier que la connexion est stable, le périphérique ayant transmis ses paramètres à l'hôte (l'hôte pouvant ainsi réinitialiser le périphérique avec les paramètres de réglage lors de la phase de réinitialisation ou « reset » selon l'appellation anglo-saxonne couramment utilisée).

Dans un quatrième laps de temps At4, l'hôte connaissant les capacités du périphérique, l'hôte monte la classe logicielle (ou « driver » selon l'appellation anglo-saxonne couramment utilisée) associée au périphérique et configure son fonctionnement (numéro de canal, puissance autorisée) pour que le système soit fonctionnel. Jusqu'à la réinitialisation, il s'agit de la phase dite d'énumération.

Maintenant que le processus classique d'appareillage d'un périphérique avec un hôte a été décrit, on peut exposer plus en détail un mode particulier de réalisation de l'invention.

L'invention pourra être mise en œuvre sur tout type d'hôte. Dans le mode de réalisation ici décrit, l'hôte sera embarqué dans un véhicule automobile.

Sur la figure 4, on a représenté une partie d'un habitacle d'un tel véhicule automobile, sur laquelle apparaît la console centrale 10 du véhicule automobile et un téléphone mobile 20 tenu en main par le conducteur du véhicule automobile.

Dans la suite de la description, on considérera que la console centrale 10 a une fonction d'hôte et que le téléphone mobile 20 a une fonction de « périphérique USB ». En variante, le périphérique USB pourrait être formé par tout autre type d'appareil électronique, par exemple par une tablette informatique.

Le téléphone mobile 20 est un téléphone intelligent (ou « smartphone ») qui comporte classiquement un châssis qui loge un contrôleur et dans lequel sont enchâssés un écran tactile 23 et un connecteur externe.

Ce téléphone mobile 20 est ici équipé d'un fil électrique 30 qui comporte, d'un côté, une fiche 31 branchée dans le port externe du téléphone mobile 20, et, de l'autre, une fiche USB 22. Le contrôleur 21 comporte un processeur (CPU), une mémoire vive (RAM), une mémoire morte (ROM), et différentes interfaces.

Grâce à ses interfaces, le contrôleur 21 est notamment adapté à communiquer avec un quelconque hôte via la fiche USB 22.

La mémoire morte du contrôleur 21 mémorise des données utilisées dans le cadre du procédé décrit ci-dessous.

Elle mémorise notamment un système d'exploitation (typiquement Androïd ^® ou iOS ^® sans que cela soit limitatif), différentes applications, et au moins un set de paramètres de réglages spécialement conçu pour permettre son appareillage sur un quelconque hôte (ce set étant utilisé lors de la phase d'énumération).

Chaque set de paramètres de réglage comporte différentes données, dont par exemple :

- un identifiant constructeur, qui permet d'identifier le constructeur du téléphone mobile,

- un identifiant appareil, qui permet d'identifier le type du périphérique (ici un téléphone mobile),

- une intensité d'alimentation nécessaire pour permettre au périphérique de fonctionner,

- un nombre de canaux de communication (en anglais « Endpoints

IN/OUT ») nécessaires pour permettre au périphérique de communiquer avec l'hôte.

Dans la suite de la description, on considérera deux téléphones mobiles 20 différents, respectivement appelés « téléphone mobile standard » et « téléphone mobile évolué ».

Le téléphone mobile évolué se distinguera du téléphone mobile standard en ce que sa mémoire morte stockera :

- un set alternatif 012 de paramètres de réglage (en sus du set principal ai ), et

- une « application automobile », c'est-à-dire une application qui est conçue pour permettre d'utiliser avantageusement le téléphone mobile dans un véhicule automobile (une telle application automobile est par exemple déjà connue sous le nom de « Android Auto ^® » ou « Apple CarPlay ^® »).

Selon une caractéristique particulièrement avantageuse de l'invention et pour une raison qui apparaîtra clairement dans la suite de cet exposé, le set principal ai enregistré dans le téléphone mobile évolué comporte au moins un paramètre de réglage qui est irréalisable quel que soit l'hôte, puisque sa valeur est non conforme à la norme USB.

Typiquement, ce paramètre de réglage irréalisable pourra correspondre à une requête d'alimentation en courant électrique d'intensité strictement supérieure à 500 mA (la norme USB 2.0 prévoit qu'un port USB ne saurait délivrer un courant d'intensité supérieure à 500 mA), par exemple égale à 20 A ou à 50 A (valeur irréalisable).

Selon un autre exemple, ce paramètre de réglage irréalisable pourra correspondre à une requête de canaux de communication pour communiquer avec l'hôte qui est strictement supérieure à 16 (la norme USB prévoit qu'un hôte dispose au plus de 16 canaux de communication).

De cette façon, le set principal ai sera toujours rejeté par l'hôte et ce sera le set alternatif 012 qui sera considéré.

Dans le téléphone mobile évolué, le set principal ai est alors simplement utilisé en tant qu'identifiant, pour signifier à l'hôte qu'il embraque une application automobile.

La valeur du paramètre de réglage irréalisable pourra alors être choisie de façon à ce que l'hôte puisse en déduire quelle application automobile le téléphone mobile évolué embarque.

Typiquement, le paramètre de réglage irréalisable pourra prendre une première valeur prédéterminée lorsque l'application automobile sera « Android Auto ^® », et une seconde valeur prédéterminée différente de la première lorsque l'application automobile sera « Apple CarPlay ^® ».

Comme le montre la figure 4, la console centrale 10 comporte ici un écran tactile 13, un jeu de boutons de commande 14, au moins un port USB 12, et un calculateur 1 1 . La console centrale 10 est conçue pour offrir différentes fonctions d'agrément et d'aide à la conduite au conducteur du véhicule automobile. Pour offrir ces fonctions et pour piloter l'écran tactile 13, le calculateur 1 1 comportant un processeur (CPU), une mémoire vive (RAM), une mémoire morte (ROM), et différentes interfaces.

Grâce à ses interfaces, le calculateur 1 1 est notamment adapté à communiquer avec un quelconque périphérique via le port USB 12. Il est notamment adapté à communiquer avec le téléphone mobile 20 lorsque sa fiche USB 22 est branchée dans le port USB 12.

La mémoire morte mémorise des données utilisées dans le cadre du procédé décrit ci-dessous.

Elle mémorise notamment un système d'exploitation et des logiciels d'exécution (ou « drivers ») permettant l'appareillage de différents types de périphériques.

Parmi ces logiciels d'exécution, on distinguera ici :

- les « logiciels d'exécution conventionnels » permettant au calculateur 1 1 du véhicule de communiquer avec des périphériques dépourvus d'application automobile (clé USB, téléphone mobile standard, ....), et

- les « logiciels d'exécution tiers », qui sont des logiciels spécialement conçus pour permettre au calculateur 1 1 du véhicule de communiquer avec une application automobile particulière embarquée dans un téléphone mobile évolué.

On pourra ici considérer que le calculateur 1 1 embarque un logiciel d'exécution tiers associé à l'application automobile « Android Auto® », et un logiciel d'exécution tiers associé à l'application automobile « Apple CarPlay® ».

La mémoire du calculateur 1 1 mémorise aussi une application informatique, constituée de programmes d'ordinateur comprenant des instructions dont l'exécution par le processeur permet la mise en œuvre par le calculateur du procédé décrit ci-après, en référence à la figure 3.

Ce procédé d'appareillage est mis en œuvre en plusieurs étapes successives, notées E1 à El. Sur la figure 3, les étapes notées entre parenthèses sont les étapes qui ne sont pas nécessairement mises en œuvre. La première étape E1 de ce procédé intervient dès qu'un quelconque périphérique est connecté sur le port USB 12 de la console centrale 10 du véhicule. Dans l'exemple illustré, il s'agit d'un téléphone mobile 20 standard ou évolué.

Cette première étape E1 correspondant aux étapes qui se succèdent durant les laps de temps At1 à At3 décrits précédemment en référence à la figure 2.

Une fois cette étape E1 accomplie, il est prévu une phase d'énumération comprenant une étape E2 ou deux étapes E2 et E3.

Au cours de l'étape E2, le périphérique 20 transmet à l'hôte 10 son set principal ai de paramètres de réglage.

S'il comporte un set alternatif 012 de paramètres de réglage, au cours de l'étape E3, le périphérique transmet ensuite à l'hôte 10 ce set alternatif 012 de paramètres de réglage.

On comprend, dans l'exemple qui nous intéresse, que dans le cas d'un téléphone mobile standard, seule l'étape E2 est mise en œuvre. Au contraire, dans le cas d'un téléphone mobile évolué, les étapes E2 et E3 sont toutes deux mises en œuvre.

Quoiqu'il en soit, le procédé se poursuit en une étape E4, au cours de laquelle l'hôte 10 lit les paramètres de réglage du set principal ai .

Dans le cas d'un téléphone mobile standard, ces paramètres de réglage sont généralement considérés par l'hôte 10 comme utilisables, si bien que le procédé se poursuit en une étape E7 (décrite ci-après).

Au contraire, dans le cas d'un téléphone mobile évolué, ces paramètres de réglage sont considérés par l'hôte 10 comme inutilisables. L'hôte 10 en déduit alors que le périphérique 20 est un téléphone mobile évolué.

L'hôte 10 lit alors la valeur du paramètre de réglage irréalisable, dont on rappelle qu'il sert d'identifiant, et il en déduit quel est le logiciel d'exécution tiers qu'il devra charger.

Puis, le procédé se poursuit en une étape E5 au cours de laquelle l'hôte 10 lit les paramètres de réglage du set alternatif 012. Au cours de l'étape E6, l'hôte 10 informe le périphérique 20 qu'il devra considérer les paramètres de réglage du set alternatif 012.

Enfin, au cours de l'étape E7, l'hôte réinitialise le processus (on parle de « reset ») afin d'affecter une adresse au périphérique 20 et de charger un logiciel d'exécution permettant à l'hôte 10 de fonctionner de paire avec le périphérique 20.

On comprend, dans l'exemple qui nous intéresse, que dans le cas d'un téléphone mobile 20 standard, il s'agira d'un logiciel d'exécution conventionnel, tandis que dans le cas d'un téléphone mobile 20 évolué, il s'agira d'un logiciel d'exécution tiers correspondant à l'application automobile utilisée dans le téléphone mobile 20 évolué.

La présente invention n'est nullement limitée au mode de réalisation décrit et représenté, mais l'homme du métier saura y apporter toute variante conforme à l'invention.

Ainsi, le paramètre de réglage du set principal ai qui présente une valeur irréalisable (non conforme à la norme USB) pourra être un paramètre autre que l'intensité du courant d'alimentation ou le nombre de canaux de communication.

Par ailleurs, le port USB pourra être conforme à n'importe quelle norme USB (1 .1 , 2.0, 3.0, 3.1 , . . . ), sans que cela n'affecte sensiblement le processus d'appareillage décrit ci-dessus.