FR3063824A1

FR3063824A1 - Gestion coordonnee des perturbations

Info

Publication number: FR3063824A1
Application number: FR1751883A
Authority: FR
Inventors: Yann Lamoureux; Emilie Glerant; Emilie Marie Muguerza Sarah; Antoine Lefebvre; Beatrix Stephanie Gualmini Alexandra
Original assignee: Amadeus SAS
Current assignee: Amadeus SAS
Priority date: 2017-03-08
Filing date: 2017-03-08
Publication date: 2018-09-14

Abstract

Des systèmes, des procédés, et des produits-programmes d'ordinateur pour coordonner les opérations des systèmes pertinents après une perturbation d'un itinéraire de passager. En réponse à la réception d'une demande de transfert incluant au moins une portion d'un nouvel itinéraire de voyage pour remplacer un itinéraire de voyage perturbé pour chacun de multiples passagers, un système d'inventaire actualise automatiquement des compteurs sur la base de l'itinéraire de voyage perturbé de chaque passager et du nouvel itinéraire de voyage, et un système de réservation actualise automatiquement un ou plusieurs enregistrements de réservation pour refléter une association entre chaque passager et le nouvel itinéraire de voyage. Par la suite, un système billettique effectue automatiquement un processus de billetterie relatif au nouvel itinéraire de voyage pour chaque passager et un système de contrôle des départs transfère automatiquement la donnée de passager, stockée pour chaque passager en relation à l'itinéraire de voyage perturbé du passager, vers un enregistrement associé au nouvel itinéraire.

Description

Titulaire(s) : Amadeus S.A.S..

Demande(s) d’extension

Mandataire(s) : SAMSON & PARTNER PATENTANWALTE MBB.

FR 3 063 824 - A1

GESTION COORDONNEE DES PERTURBATIONS.

©) Des systèmes, des procédés, et des produits-programmes d'ordinateur pour coordonner les opérations des systèmes pertinents après une perturbation d'un itinéraire de passager. En réponse à la réception d'une demande de transfert incluant au moins une portion d'un nouvel itinéraire de voyage pour remplacer un itinéraire de voyage perturbé pour chacun de multiples passagers, un système d'inventaire actualise automatiquement des compteurs sur la base de l'itinéraire de voyage perturbé de chaque passager et du nouvel itinéraire de voyage, et un système de réservation actualise automatiquement un ou plusieurs enregistrements de réservation pour refléter une association entre chaque passager et le nouvel itinéraire de voyage. Par la suite, un système billettique effectue automatiquement un processus de billetterie relatif au nouvel itinéraire de voyage pour chaque passager et un système de contrôle des départs transfère automatiquement la donnée de passager, stockée pour chaque passager en relation à l'itinéraire de voyage perturbé du passager, vers un enregistrement associé au nouvel itinéraire.

¢-10

I

GESTION COORDONNÉE DES PERTURBATIONS

DOMAINE TECHNIQUE [0001 ] L’invention présente concerne de façon générale la gestion des perturbations d’itinéraire et plus particulièrement, des systèmes, des procédés et des produits-programmes d’ordinateur pour coordonner des systèmes qui répondent à de telles perturbations.

CONTEXTE [0002] L’approvisionnement d’un client en produits et services implique souvent plusieurs systèmes, chacun remplissant une fonction différente. Dans le cas des segments de vols, par exemple, l’approvisionnement en produits et services peut impliquer un système pour suivre le nombre de sièges disponibles sur chaque vol planifié, un système pour gérer les réservations, un système pour effectuer des opérations de billetterie et un système pour gérer les opérations à l’aéroport. Occasionnellement, l’itinéraire de voyage réservé d’un passager peut subir une perturbation, par exemple, lorsqu’un des vols dans l’îtinéraire de voyage est retardé ou annulé. En réponse à une telle perturbation, il est souhaitable que la compagnie aérienne propose rapidement une solution de remplacement au passager. Cependant, trouver et mettre en œuvre de telles solutions de remplacement implique de nombreux systèmes de la compagnie aérienne, tels que ceux qui ont été mentionnés ci-dessus. Par conséquent, si elles ne sont pas gérées correctement, la recherche et la mise en œuvre de solutions de remplacement pour un passager affecté par une perturbation peuvent donner lieu à des inefficacités et dès incohérences entre chacun des systèmes impliqués ce qui peut produire d’autres effets néfastes, tels que des temps de réponse lents et des surréservations.

[0003] il existe donc un besoin de systèmes, de procédés et de produits-programmes d’ordinateur qui traitent les perturbations d’itinéraire d’une manière entièrement intégrée, coordonnée et efficace.

RÉSUMÉ [0004] Dans un mode de réalisation exemplaire, un système de gestion des perturbations qui coordonne, après une perturbation, les opérations d’une pluralité de systèmes Inclus dans le système de gestion des perturbations inclut un système d’inventaire, un système de réservation, un système billettique, et un système de contrôle des départs (DCS). Le système d’inventaire inclut une première base de données incluant des compteurs, chacun des compteurs suivant une valeur de disponibilité pour un produit de voyage. Le système de réservation inclut une seconde base de données incluant un ou plusieurs enregistrements de réservation pour des passagers, chacun des passagers étant inclus dans un d’un ou de plusieurs enregistrements de réservation et étant associé dans ledit enregistrement de réservation à un premier itinéraire de voyage sur lequel le passager est réservé. Le DCS inclut une troisième base de données incluant une donnée de passager stockée pour chaque passager qui est associée au premier itinéraire de voyage du passager. Le système billettique inclut une quatrième base de données incluant un e-billet pour chaque passager. Le système d’inventaire, le système de réservation, le système billettique et le DCS sont connectés via un réseau informatique, (0005] Ire système de gestion des perturbations inclut aussi des processeurs et des 10 dispositifs de mémoire. Le système d’inventaire, le système de réservation, le système billettique et le DCS incluent chacun au moins un des processeurs. Les dispositifs de mémoire incluent des instructions qui, lorsqu’elles sont exécutées par les processeurs du système de gestion des perturbations après une perturbation du premier itinéraire de voyage de chaque passager et en réponse à la réception par le système de gestion des perturbations d’une demande de transfert incluant les passagers et au moins une portion d’un second itinéraire de voyage pour remplacer le premier itinéraire de voyage de chaque passager, amènent le système de gestion des perturbations à mettre en œuvre automatiquement les opérations suivantes : Le système d’inventaire actualise automatiquement les compteurs de la première base de données sur la base du premier itinéraire de voyage pour chaque passager et du second itinéraire de voyage, et le système de réservation actualise automatiquement ledit ou plusieurs enregistrements de réservation de la seconde base de données pour refléter une association entre chaque passager et le second itinéraire de voyage. Après que la première et la seconde base de données ont été actualisées, le système billettique effectue automatiquement un processus automatisé de billetterie pour chaque passager pour le second itinéraire de voyage et le DCS transfert automatiquement, pour chaque passager, la donnée de passager relative au premier itinéraire de voyage vers un enregistrement inclus dans la troisième base de données qui est associée au second itinéraire de voyage, (0006) Lois de l’exécution, les instructions peuvent amener le système de gestion des perturbations à actualiser les compteurs de la première base de données pour chaque passager, via le système d’inventaire, sur la base du premier itinéraire de voyage et du second itinéraire de voyage, et à actualiser ledit ou plusieurs enregistrements de réservation de la seconde base de données, via le système de réservation, pour refléter une association entre chaque passager et le second itinéraire de voyage en amenant, via le système d’inventaire, le système de gestion des perturbations à déterminer si les passagers peuvent obtenir une nouvelle réservation pour le second itinéraire de voyage sur la base des compteurs de la première base de données. En réponse à la détermination que les passagers peuvent être réservés à nouveau sur le second itinéraire de voyage, les opérations suivantes peuvent être effectuées pour chaque passager : le système de réservation réserve à

S nouveau le passager sur le second itinéraire de voyage dans la seconde base de données et en réponse à la nouvelle réservation du passager, le système d’inventaire actualise les compteurs de la première base de données sur la base de la nouvelle réservation, [0007] Par ailleurs lors de l’exécution, les instructions peuvent amener le système de gestion des perturbations à actualiser les compteurs de la première base de données, via le système d’inventaire, sur la base du premier itinéraire de voyage de chaque passager et du second itinéraire de voyage en amenant le système de gestion des perturbations à transmettre une requête unique au système d’inventaire, la requête unique incluant au moins une portion du premier itinéraire de voyage de chaque passager et au moins une portion du second itinéraire de voyage. Par la suite, le système d’inventaire peut mettre à jour les compteurs de la première base de données sur la base de la requête unique, [0008] De plus lors de l’exécution, les instructions peuvent par ailleurs amener le système de gestion des perturbations à effectuer ce qui suit : Avant la réception de la demande de transfert et en réponse à un changement d’horaire exécuté par le système d’inventaire qui affecte le premier itinéraire de voyage de chaque passager, le DCS, peut automatiquement générer un enregistrement de sauvegarde pour chaque passager incluant la donnée du passager relative au premier itinéraire de voyage du passager. Dans cette situation, la donnée de passager transférée pour le passager vers l’enregistrement associé au second itinéraire de voyage peut provenir de l'enregistrement de sauvegarde pour le passager. Dans certains cas, le premier itinéraire de voyage de chaque passager peut inclure un segment de vol commun, le changement d’horaire peut être relatif au segment de vol commun et le changement d’horaire peut être exécuté dans une fourchette opérationnelle du segment de vol commun. De surcroît ou autrement, la requête de transfert peut être générée via le DCS.

[0009] De plus, la donnée de passager stockée dans la troisième base de données pour chacun des passagers et qui est relative au premier itinéraire de voyage dudit passager peut inclure une première information de bagage pour ledit passager, la première information de bagage incluant un premier itinéraire de bagage et un identifiant unique. Dans ce cas lors de l’exécution, les instructions peuvent amener le système de gestion des perturbations à transférer la donnée de passager stockée pour ledit passager relative au premier itinéraire de voyage dudit passager vers l’enregistrement inclus dans la troisième base de données qui est associé au second itinéraire de voyage, en amenant le système de gestion des perturbations à modifier la première information de bagage pour inclure un second itinéraire de bagage basé sur le second itinéraire de bagage.

L’information de bagage modifiée peut être ajoutéeà l’enregistrement associé au second itinéraire de voyage et peut inclure l’identifiant unique de la première information de bagage.

[0010] De plus, le premier itinéraire de voyage de chaque passager peut inclure un vol remplacé et lé second itinéraire de voyage peut inclure un nouveau vol qui remplace le vol remplacé du premier itinéraire de voyage de chaque passager. De façon connexe, les instructions lors de l’exécution peuvent par ailleurs amener le système de gestion des perturbations, en réponse à la réception de la demande de transfert et avant que la première et la seconde base de données ne soient actualisées, à verrouiller le vol remplacé du premier itinéraire de voyage de chaque passager et le nouveau vol.

[0011] En outre lors de l’exécution, les instructions peuvent amener le système de gestion des perturbations à actualiser ledit ou plusieurs enregistrements de réservation de la seconde base de données, via le système de réservation, pour refléter une association entre chaque passager et le second itinéraire de voyage, en amenant le système de gestion des perturbations à générer un nouvel enregistrement de réservation dans la seconde base de données. Le nouvel enregistrement de réservation peut inclure au moins un des passagers et le second itinéraire de voyage.

[0012] Par ailleurs lors de l’exécution, les instructions peuvent amener le système de gestion des perturbations à mettre en œuvre le processus de billetterie pour chaque passager pour le second itinéraire de voyage, via le système billettique, en amenant le système de gestion des perturbations à sélectionner pour chaque passager une transaction e-billet sélectionnée à partir d’un groupe comprenant une transaction de revalidation e-billet et une transaction d’échange e-billet. Une requête unique, incluant la transaction e-billet sélectionnée pour chaque passager, peut ensuite être transmise au système billettique. De plus lors de l’exécution, les instructions peuvent amener le système de gestion des perturbations à mettre en œuvre le processus de billetterie pour chaque passager pour le second itinéraire de voyage, via le système billettique, en amenant par ailleurs le système de gestion des perturbations, en réponse à la réception d’un rejet de la requête unique par le système billettique, à générer une demande de billetterie séparée pour chaque passager. La demande de billetterie séparée, générée pour chaque passager, peut être transmise au système billettique, et le système billettique peut traiter chaque demande de billetterie séparée, l’une après l’autre.

[0013] De plus lors de l’exécution, les instructions peuvent amener le système de gestion des perturbations à mettre en œuvre le processus de billetterie pour chaque passager pour le second itinéraire de voyage, via le système billettique, en amenant par ailleurs le système de gestion des perturbations à effectuer la transaction e-billet sélectionnée pour chaque passager, via le système billettique. En réponse à la mise en œuvre de la transaction e-billet sélectionnée pour chaque passager par le système billettique, des documents de coupons électroniques variés (EMD) associés aux passagers peuvent être déterminés, dans lesquels chacun des coupons EMD est pour le premier itinéraire de voyage de l’un des passagers. Pour chaque coupon EMD, une transaction EMD pour le coupon EMD sélectionné à partir d’un groupe comprenant une transaction de dissociation EMD, une transaction d’association EMD et une transaction d’échange EMD, peut être sélectionnée et effectuée.

[0014] Dans un autre mode de réalisation exemplaire, un procédé pour coordonner, après une perturbation, les opérations de systèmes connectés via un réseau de communication inclus dans un système de gestion des perturbations, les systèmes incluant le système d’inventaire, le système de réservation, le système billettique et le DCS décrits ci-dessus. inclut la réception par le système de gestion des perturbations et après la perturbation du premier itinéraire de voyage de chaque passager, d’une demande de transfert incluant les passagers et au moins une portion du second itinéraire de voyage pour remplacer le premier itinéraire de voyage de chaque passager. En réponse à la réception de la demande de transfert reçue par le système de gestion des perturbations, le procédé inclut l’actualisation automatique des compteurs de la première base de données, via le système d’inventaire, sur la base du premier itinéraire de voyage pour chaque passager et du second itinéraire de voyage, et l’actualisation automatique d’un ou de plusieurs enregistrements de réservation de la seconde base de données, via le système de réservation, pour refléter une association entre chaque passager et le second itinéraire de voyage. Après que la première et la seconde base de données ont été actualisées, le procédé inclut par ailleurs la mise en œuvre automatique d’un processus automatisé de billetterie pour chaque passager pour le second itinéraire de voyage, via le système billettique et, pour chaque passager, le transfert automatique de la donnée de passager relative au premier itinéraire de voyage, via Je DCS, vers un enregistrement inclus dans la troisième base de données qui est associé au second itinéraire de voyage.

[0015] Le procédé peut aussi inclure l’une quelconque ou plusieurs des caractéristiques et/ou la mise en œuvre de l’une quelconque ou de plusieurs des opérations décrites en relation avec le système de gestion des perturbations exemplaire décrit ci-dessus.

[0016] Dans un autre mode de réalisation exemplaire, un produit-programme d’ordinateur pour coordonner, après une perturbation, les opérations de systèmes connectés via un réseau de communication inclus dans un système de gestion des perturbations, les systèmes incluant le système d’inventaire, le système de réservation, le système billettique et le DCS décrits ci-dessus en relation avec le Système de gestion des perturbations exemplaire, inclut un support de stockage non transitoire lisible par ordinateur. Lors de l’exécution par un ou plusieurs processeurs du système de gestion des perturbations après la perturbation du premier itinéraire de voyage de chaque passager et en réponse à la réception par le système de gestion des perturbations d’une demande de transfert incluant les passagers et au moins une portion d’un second itinéraire de voyage pour remplacer le premier itinéraire de voyage de chaque passager, les instructions stockées sur le dispositif non transitoire lisible par ordinateur, amènent le système de gestion des perturbations à mettre en œuvre automatiquement les opérations suivantes. Le système d’inventaire actualise automatiquement les compteurs de la première base de données sur la base du premier itinéraire de voyage pour chaque passager et du second itinéraire de voyage et le système de réservation actualise automatiquement ledit ou plusieurs enregistrements de réservation de la seconde base de données pour refléter une association entre chaque passager et le second itinéraire de voyage. Après que la première et la seconde base de données ont été actualisées, le système billettique met en œuvre automatiquement un processus de billetterie automatisé pour chaque passager pour le second itinéraire de voyage et, pour chaque passager, le DCS transfère automatiquement la donnée de passager relative au premier itinéraire de voyage vers un enregistrement inclus dans fa troisième base de données qui est associé au second itinéraire de voyage.

[0017] Lots de l’exécution, les instructions sur le support non transitoire lisible par ordinateur peuvent aussi amener le système à implémenter l'une quelconque ou plusieurs des caractéristiques et/ou à mettre en œuvre l’une quelconque ou plusieurs des opérations décrites ci25 dessus en relation avec le système de gestion des perturbations exemplaire décrit ci-dessus, [0018] Le résumé ci-dessus peut apporter une vue d'ensemble simplifiée de certains des modes de réalisation de l'invention afin de fournir une compréhension basique de certains aspects de l’invention discutés dans les présentes. Le résumé ne prétend pas apporter une vue d’ensemble exhaustive de {'invention et n'est pas destiné à identifier des éléments clés ou critiques quelconques ou à limiter la portée de l'invention. Le seul but du résumé est de présenter simplement quelques concepts sous une forme simplifiée comme préambule à la description détaillée présentée cidessous.

BRÈVE DESCRIPTION DES DESSINS [0019] Les modes de réalisation de la présente invention seront mieux compris et seront appréciés plus pleinement grâce à la lecture de la description détaillée ci-après qui complète les dessins, [0020] FIG. 1 est une vue schématique d'un environnement d’exploitation exemplaire qui inclut une pluralité de systèmes informatiques pour gérer les perturbations d’itinéraire.

[0021] FIG. 2 est une vue schématique d’un système informatique exemplaire de la FIG. I.

[0022] FIG. 3 est une vue schématique d'une architecture de traitement exemplaire pouvant être mise en œuvre par le système informatique de la FIG. 1.

[0023] FIG.4 est un diagramme séquentiel d’un processus exemplaire pour la gestion de perturbations d’itinéraire qui peut être facilité par l’architecture de traitement de la FIG. 3.

[0024] FIG.5 est un diagramme séquentiel d’un processus exemplaire qui peut être inclus dans le processus de la FIG, 4 pour effectuer les opérations de billeterie.

[0025] FIG. 6 est un diagramme d’une machine étatique exemplaire qui peut être implémentée par un ou plusieurs des systèmes informatiques de la FIG.l et/ou par l’architecture de traitement de la FIG. 3.

DESCRIPTION DÉTAILLÉE [0026] Plusieurs des modes de réalisation, décrits dans les présentes, traitent de la coordination d’un réseau de systèmes pour gérer une perturbation d’itinéraire d’un passager. En particulier, lorsqu’un passager réservé sur un itinéraire de voyage subit une perturbation, par exemple en raison de l’annulation ou du retard d’un vol, il peut être nécessaire de transférer le passager sur un nouvel itinéraire de voyage et de le faire rapidement. Un tel transfert peut, cependant, impliquer plusieurs systèmes informatiques qui remplissent chacun un rôle respectif dans l’approvisionnement en produits et en services de voyage pour les passagers. L’arrivée des systèmes informatiques et de l’Internet pour fournir des produits et des services de voyage aux passagers a augmenté la complexité et la nature sensible du transfert d’un passager sur un nouvel itinéraire de voyage, car chacun de ces systèmes peut héberger des données relatives au transfert qui peuvent être affectées par un nombre quelconque de processus contradictoires provenant d’un nombre quelconque d’autres systèmes informatiques. Des modes de réalisation pour coordonner les opérations des systèmes informatiques qui sont impliqués dans le transfert d’un passager en maintenant l'intégrité des systèmes informatiques dans leurs rôles respectifs sont donc décrits dans les présentes. De surcroît, un ou plusieurs de ces modes de réalisation coordonnent les systèmes informatiques impliqués d’une façon qui améliore le temps de réponse global tout en maintenant l’intégrité du système, [0027] La FIG. 1 illustre un environnement d’exploitation 10 qui peut inclure un ou plusieurs systèmes de réservation 12, systèmes d’inventaire 14, systèmes billettiques 16, systèmes de contrôle des départs (DCS) 18 et un système de transfert 20. Chacun de ces systèmes peut communiquer via un réseau 24, tel qu'Intemet. Par ailleurs, deux ou plusieurs de ces systèmes peuvent être intégrés les uns aux autres. Par exemple, le système de transfert 20 peut être hébergé par le système d’inventaire 14 et/ou par un ou plusieurs des autres systèmes de l’environnement d’exploitation 10.

[0028] Le système de réservation 12 peut être configuré pour traiter les demandes de recherche et de réservation pour des produits et des services de voyage offerts par un ou plusieurs fournisseurs de services, tels qu’une ou plusieurs compagnies aériennes. Par exemple, le système de réservation 12 peut recevoir une demande de recherche ou de réservation d’un agent de voyage ou d’un client via un dispositif informatique tel qu’un ordinateur de bureau, un ordinateur portable, un dispositif mobile, une tablette, etc. pour un ou plusieurs produits de voyage. En réponse à la réception d’une demande de recherche pour un ou plusieurs produits de voyage, le système de réservation 12 peut interroger une base de données hébergée par le système d’inventaire 14 pour trouver des produits de voyages disponibles qui correspondent à un ou plusieurs critères de recherche de la demande de recherche. À la réception des produits de voyage disponibles de la base de données, ou après, le système de réservation 12 peut transmettre un ou plusieurs des produits de voyage disponibles au dispositif informatique demandeur pour évaluation.

[0029] En réponse à la réception d’une demande de réservation qui inclut une information de paiement et une sélection d’un ou de plusieurs produits de voyage, le système de réservation 12 peut créer une réservation pour ledit ou plusieurs produits de voyage, au moins en partie, en générant et en stockant un enregistrement de réservation. Chaque enregistrement de réservation généré et stocké par le système de réservation 12 peut inclure une identification d’un ou de plusieurs clients et un ou plusieurs produits de voyage réservés par ledit ou plusieurs clients. Dans certains modes de réalisation, le système de réservation 12 peut être associé à une compagnie aérienne particulière et chaque enregistrement de réservation stocké peut être un enregistrement de nom de passager (PNR) incluant une identification d’un ou de plusieurs passagers et un itinéraire de voyage réservé par ledit ou plusieurs passagers de sorte que ledit ou plusieurs passagers et l’itinéraire de voyage dudit ou de plusieurs passagers sont associés les uns aux autres dans l’enregistrement de réservation. L’itinéraire de voyage peut inclure un ou plusieurs des vols die la compagnie aérienne et/ou des vols de partenaires de la compagnie aérienne (c,-à-d, des vols exploités par une autre compagnie aérienne ayant un accord avec la compagnie aérienne associée au système de réservation 12).

[0030] Dans d’autres modes de réalisation, le système de réservation 12 peut être un système de distribution globale (GDS) qui facilite la recherche et la réservation de produits de transport aérien et/ou de produits de voyage autres de plusieurs fournisseurs de services différents, que les fournisseurs de services différents aient, ou non, des accords de partenariat. Le cas échéant, chaque enregistrement de réservation généré et stocké par le système de réservation 12 peut être un enregistrement de voyage total (TTR) qui est capable d’inclure à la fois des produits de transport aérien et des produits de voyage autres offerts par de multiples fournisseurs de services. Des exemples non limitatifs de produits de voyage autres que des produits de transport aérien incluent des chambres d’hôtel, des locations de voiture, des admissions à des événements et des attractions et tout autre produit de voyage, autre que le transport aérien, souvent associé au voyage.

[0031] Un enregistrement de réservation généré et stocké par le système de réservation 12 peut aussi inclure les préférences des clients et/ou les services auxiliaires réservés par les clients en relation avec les produits de voyage identifiés dans l’enregistrement de réservation. En particulier, chaque préférence et service auxiliaire réservé par le client peut être représenté par un élément de demande spéciale de service (SSR) inclus dans l’enregistrement de réservation. Par exemple, dans le cas d’un enregistrement de réservation qui inclut un siège sur un vol, l’enregistrement de réservation peut aussi inclure la préférence de siège et la préférence de repas d’un client en relation avec le vol. Dans un autre exemple, l’enregistrement de réservation peut inclure une indication d’un aménagement spécial demandé par un client, par exemple une indication que le client demande une assistance ou que le client est accompagné d’un nourrisson ou d’un animal de service. Certains des services auxiliaires réservés inclus dans l’enregistrement de réservation peuvent être des services auxiliaires payants achetés par un client. Des exemples non limitatifs de services auxiliaires payants incluent un siège amélioré, la prise en charge de bagage, une demande de repas, etc.

[0032] Le système d’inventaire 14 peut être configuré pour suivre une valeur de disponibilité pour chaque produit de voyage et service auxiliaire offert par ledit ou plusieurs fournisseurs de services. Spécifiquement, le système d’inventaire 14 peut inclure une base de données qui stocke un nombre total d’unités disponibles offertes par les fournisseurs de services pour chaque produit de voyage (p. ex., le nombre total de sièges offerts par une compagnie aérienne pour chaque classe de réservation sur chaque vol planifié) et des compteurs qui suivent une valeur de disponibilité pour chaque produit de voyage offert en comptant le nombre d’unités qui ont été réservées pour chaque produit de voyage offert. De façon similaire, le système d’inventaire 14 peut inclure une base de données qui stocke un nombre total d’unités disponibles pour chaque service auxiliaire offert en relation avec chaque produit de voyage offert et des compteurs qui suivent une valeur de disponibilité pour chaque service auxiliaire offert en relation avec un produit de voyage offert, en comptant le nombre d’unîtés qui ont été achetées et/ou réservées pour chaque produit auxiliaire offert en relation avec chaque produit de voyage offert.

[0033] Ainsi, en réponse à la réception d’une requête de recherche pour des produits de voyage de la part d’un agent de voyage ou d’un client, le système de réservation 12 peut interroger te système d’inventaire 14 pour obtenir des produits de voyage disponibles qui correspondent à un ou plusieurs critères de recherche de la demande de recherche. En outre, en réponse à la réception d’une demande de réservation pour des produits de voyage, le système de réservation 12 peut interroger le système d’inventaire 14 afin de déterminer si les produits de voyage sont disponibles et, si tel est le cas, notifier aussi le système d’inventaire 14 lorsque la réservation est complète de sorte que le système d’inventaire 14 peut ajuster les compteurs associés aux produits de voyage réservés. De façon similaire, en réponse à la réception d’une requête de recherche ou de réservation pour un service auxiliaire de la part d’un agent de voyage ou d ’un client en relation avec un vol donné, le système de réservation 12 peut interroger le système d’inventaire 14 pour déterminer si le service auxiliaire est disponible et, dans ce cas, notifier le système d’inventaire 14 de l’achat ou de la réservation du service auxiliaire de sorte que le système d’inventaire 14 peut ajuster les compteurs pertinents.

[0034] Dans certains modes de réalisation, de multiples produits de voyage suivis par le système d’inventaire 14 peuvent être liés à un même événement. Par exemple, dans le cas d’un vol, une compagnie aérienne peut offrir de multiples produits de voyage pour le vol, chacun d’eux étant associé à une classe de réservation différente dont le tarif diffère. En général, la disponibilité et/ou le prix associé à chaque produit de voyage offert par un fournisseur de services peut dépendre du niveau de service associé au produit de voyage (p. ex., première classe, économie) et/ou du critère de recette associé au produit de voyage (p, ex., combien d’unités du produit de voyage ont été ou devraient être réservées avant l’utilisation prevue du produit de voyage, combien d’unités d’autres produits de voyage relatifs au même événement ont été ou devraient être réservées avant l’utiiisation prévue du produit de voyage, et combien de temps à l’avance a été faite la réservation).

II [0035] Le système bi 1 lettique 16 peut être configuré pour générer et stocker des e-bîllets, ainsi que d’autres documents électroniques associés aux produits de voyage et aux services auxiliaires réservés. Plus particulièrement, lorsque des produits de voyage sont réservés, le système de réservation 12 peut automatiquement notifier la réservation au système billettique 16. Le système billettique 16 peut en réponse générer un e-billet pour chaque client inclus dans la réservation. Chaque e-bîllet peut être généré par le système billettique 16 et peut inclure un ou plusieurs coupons pour un ou plusieurs produits de voyage réservés, tels qu’un ou plusieurs segments de vol réservés qui font partie du même itinéraire de voyage. En particulier chaque ebillet peut inclure une identification du client, un ou plusieurs coupons pour un ou plusieurs produits de voyage réservés relatifs à un même itinéraire de voyage réservé et/ou des tarifs et des taxes payés pour ledit ou plusieurs produits de voyage réservés. En général, un e-billet peut symboliser la preuve de paiement et le droit du client, dont le nom est indiqué, aux produits de voyage réservés. Ainsi, lorsqu’un client procède par la suite à l’utilisation des produits de voyage réservés, l’e-billet peut représenter la preuve que le client a droit aux produits de voyage. Chaque e1$ billet peut aussi inclure un identifiant unique, tel qu’un numéro de référence spécifique à l’e-bîilet. L’identifiant unique d’un e-billet donné peut être stocké dans l’enregistrement de réservation de la réservation pour laquelleTe-blIIet a été généré de sorte que l’identifiant unique est associé aux produits de voyage réservés, associés à l’e-billet dans l’enregistrement de réservation.

[0036] Comme décrit précédemment, certains des services auxiliaires peuvent être payants et sont donc associés à un prix. En réponse à la réservation d’un service auxiliaire payant et au paiement du prix associé, le système billettique 16 peut générer un coupon de document divers électronique (EMD) pour le service auxiliaire acheté. Un coupon EMD, tout comme un e-billet, peut inclure une indication concernant un client, un service auxiliaire acheté et/ou des taxes et des frais payés pour le service auxiliaire. Comme pour l’e-billet, un coupon EMD fournit une preuve de paiement et un droit au service auxiliaire acheté. Lors de la création d’un coupon EMD relatif à un produit de voyage réservé, le coupon EMD et l’e-billet générés pour le produit de voyage réservé peuvent être associés l’un à l’autre par le système billettique 16. Plus particulièrement, chaque ebillet et coupon EMD peuvent être modifiés pour inclure une référence â l’autre, par exemple l’identifiant unique de l’autre. Ainsi, tout comme un e-billet, un coupon EMD peut inclure un identifiant unique qui lui est spécifique pouvant aussi être inclus dans l’enregistrement de réservation créé pour le produit de voyage réservé associé au coupon EMD et/ou pouvant être inclus dans l'enregistrement de réservation associé au service pour lequel le coupon EMD est généré.

[0037] Le système de contrôle des départs (DCS) 18 peut être configuré pour effectuer des opérations pour le compte des fournisseurs de services, par exemple les fournisseurs de services qui utilisent le système de réservation 12 et le système d’inventaire 14 à un terminal de voyage, tel qu’un aéroport. Plus spécifiquement, le DCS 18 peut faciliter l’approvisionnement de produits de voyage aux passagers le jour du voyage. Des exemples non limitatifs d’opérations effectuées par le DCS 18 peuvent inclure l’enregistrement et l’embarquement des passagers sur un vol, la gestion des informations de bagage et l’impression des cartes d’embarquement. Un DCS 18 unique à un terminai de voyage peut servir de multiples fournisseurs de services pour effectuer les opérations aéroportuaires respectives des fournisseurs de services. Cependant, chaque point d’accès pour le

DCS 18 dans un terminal de voyage (p. ex., chaque terminal d’ordinateur dans un aéroport ayant une connexion au DCS 18) peut être configuré pour servir et/ou être dédié à une compagnie aérienne à la fois. Par exemple, un groupe de terminaux d’ordinateur dans un aéroport peut être configuré pour servir et/ou être dédié à la compagnie aérienne A et un autre groupe de terminaux d’ordinateur dans l’aéroport peut être configuré pour servir et/être dédié à la compagnie aérienne B.

[0038] Le DCS 18 peut commencer à effectuer des opérations aéroportuaires pour un vol donné dès l’ouverture d’une fenêtre opérationnelle pour le vol qui peut être un ou plusieurs jours (p. ex. 3 jours) avant le départ prévu du vol. À ce moment, le DCS 18 peut ouvrir le vol aux opérations DCS, par exemple en créant un enregistrement pour le vol et en recevant une liste de noms de passager (PNL) pour le vol provenant du système de réservation 12. Le PNL peut inclure l’information des enregistrements de réservation incluant le vol donné. Des exemples non limitatifs de T information qui peut être incluse dans le PNL incluent des données d’identification pour chaque passager réservé sur le vol (p. ex., le nom, l'âge, la nationalité, le pays, le lieu de naissance, la date de naissance et le sexe), l’itinéraire de voyage complet de chaque passager, les préférences de chaque passager, les services auxiliaires réservés par chaque passager et les identifiants uniques associés aux e-billets et aux coupons EMD de chaque passager pour le vol. Après l’ouverture du vol, le DCS 18 peut, pour chaque passager dans le PNL, stocker la donnée du passager, pat exemple dans un enregistrement DCS associé au vol et/ou spécifique au passager qui inclut l’information du passager incluse dans le PNL. De cette façon, pour les passagers réservés sur un itinéraire de voyage incluant un ou plusieurs vols ouverts, le DCS 18 peut stocker la donnée du passager relative à l’itinéraire de voyage du passager, pour chaque passager. En particulier, le DCS 18 peut, pour chaque passager, stocker une donnée de passager dans un ou plusieurs enregistrements DCS, chacun d’un ou de plusieurs enregistrements DCS étant associé à un des vols ouverts de l’itinéraire de voyage réservé pour Je passager. Chaque vol ouvert dans le DCS 18 peut être associé à un ou plusieurs enregistrements DCS, chacun incluant une donnée de passager pour un ou plusieurs des passagers réservés sur le vol.

[0039J Le DCS 18 peut permettre l’enregistrement (autrement dit « l’acceptation ») des passagers sur le vol dans la fenêtre opérationnelle du vol, et/ou dans un temps déterminé avant l’heure de départ prévue du vol, par exemple 24 heures avant. Lorsqu’un passager est accepté sur le vol, le DGS 18 peut modifier l'enregistrement DCS du passager pour le vol afin de confirmer que le statut du passager est « enregistré », ce qui peut être considéré comme faisant partie de la donnée de passager pour le passager dans renregistrement DCS. Cette modification peut verrouiller l’e-billet et/ou les coupons EMD du passager relatifs aux vols, empêchant ainsi qu’ils soient modifiés et/ou utilisés en relation avec un produit de voyage autre que le vol. Le DCS 18 peut aussi modifier renregistrement DCS du passager pour le vol afin d’inclure une donnée additionnelle de passager pour le vol telle que l’heure d’acceptation, le siège attribué au passager et/ou une donnée réglementaire (p. ex. une donnée relative à des contrôles imposés par le gouvernement). Plus tard au cours de cette période, un passager peut choisir d’enregistrer son bagage ; dans ce cas le DCS 18 peut générer une information électronique de bagage pour le passager. L’information électronique de bagage peut inclure un itinéraire de bagage, un identifiant unique associé physiquement au bagage, par exempte par une étiquette placée sur le bagage et, le cas échéant, une exemption de frais de bagage. Le DCS 18 peut ensuite insérer l’information de bagage du passager dans l’enregistrement DCS de passager pour le vol comme faisant partie intégrante de la donnée de passager.

[0040] Le DCS 18 peut héberger (c.-à-d. effectuer des opérations aéroportuaires) des types de vols variés. Par exemple, le DCS 18 peut héberger des vols internes, en d’autres ternies, les vols gérés par le système de réservation 12 et le système d’inventaire 14 de l’environnement d’exploitation 10. Le DCS 18 peut aussi héberger des vols gérés au sol. Les vols gérés au sol sont des vols gérés par des systèmes de réservation et d’inventaire externes à l’environnement d’exploitation 10, mais qui sont délégués par le DCS 18 pour des opérations â un aéroport particulier. Par exemple, une compagnie aérienne qui utilise un système de réservation et d’inventaire externe à l’environnement d’exploitation 10 peut aussi normalement utiliser Un autre

DCS qui diffère du DCS 18 pour ses opérations aéroportuaires. Cependant, dans certains aéroports où la compagnie aérienne à des vols, l'autre DCS peut être indisponible. Si le DCS 18 est disponible à l’un de ces aéroports, la compagnie aérienne peut alors déléguer des opérations pour cet aéroport au DCS 18. D’autres vols qui ne sont pas hébergés par le DCS 18 peuvent être désignés dans les présentes comme « vols externes », [0041] En général, lorsqu’un passager procède à son enregistrement pour un vol donné via le DCS 18, le DCS 18 peut aussi enregistrer le passager sur d’autres vols ouverts dans Γ itinéraire de voyage du passager. En particulier, le DCS 18 peut utiliser Γitinéraire de voyage du passager qui peut être inclus dans l’enregistrement DCS de passager ou associé à celui-ci pour le vol donné, pour enregistrer le passager sur un ou plusieurs des vols ouverts de l’itinéraire. Dans certaines situations, l’itinéraire de voyage du passager peut inclure des vols réservés par de multiples compagnies aériennes et/ou des vols externes au DCS 18. En enregistrant le passager, le DCS 18 qui peut être exploité pour le compte d’une compagnie aérienne particulière peut aussi amener le passager à être enregistré sur les vols associés à d’autres compagnies aériennes et/ou sur les vols externes au DCS 18, en supposant que les vols sont également ouverts à l’enregistrement et/ou que les aménagements appropriés sont en place. Dans le cas d’un vol externe inclus dans l’itinéraire de voyage d’un passager, le DCS peut, par exemple, être configuré pour envoyer un message à la compagnie aérienne associée au vol externe qui à son tour peut enregistrer le passager sur le vol externe en utilisant son DCS. Le processus d’enregistrement des passagers sur un vol associé à une compagnie aérienne différente de la compagnie aérienne qui a déclenché l’enregistrement via le DCS 18 peut être désigné dans les présentes comme un « enregistrement à destination finale » (through check-în).

[0042] Occasionnellement, que ce soit avant ou après l’enregistrement d’un passager sur un vol, l’itinéraire de voyage du passager peut subir une perturbation. Par exemple, en raison de circonstances imprévues, telles que des problèmes mécaniques ou des complications météorologiques, un des vols de l’itinéraire de voyage du passager peut être annulé ou retardé de façon inacceptable (p. ex. en raison du retard, le passager rate un vol de correspondance ou arrive à la destination finale du passager au-delà d’un délai acceptable). Lorsqu’un des vols de l’itinéraire du passager est annulé ou retardé de façon inacceptable, le passager a souvent besoin d’être transféré sur un autre itinéraire de voyage qui permet au passager d’atteindre sa destination prévue dans son délai désiré ou dans un délai aussi proche que possible du délai désiré.

[0043] Le transfert des passagers d’un itinéraire de voyage perturbé vers un autre itinéraire de voyage implique certains défis techniques. Par exemple, les systèmes impliqués dans ce processus doivent être capables d’effectuer ces transferts rapidement. Spécifiquement, les perturbations d’un vol planifié ne surviennent pas souvent avant la date de départ et, plus de temps s’écoule après la perturbation, moins U est probable que le passager pourra arriver à sa destination prévue dans le délai désiré (p. ex., il n’y a plus de sièges disponibles sur des vols de remplacement et des vols de remplacement peuvent être partis). Par conséquent il est aussi souhaitable pour les systèmes impliqués d’offrir un grand choix de vols pour le nouvel itinéraire en incluant ceux qui ne sont pas encore ouverts dans le DGS 18. De surcroît, après le transfert d’un passager d’un itinéraire de voyage perturbé à un nouvel itinéraire de voyage il est souhaitable que tous les systèmes de l’environnement d’exploitation 10 soient dans un état synchronisé de sorte que chaque système reflète correctement les réservations actuelles et l’inventaire disponible pour chaque vol.

[0044] Les systèmes et procédés conventionnels pour transférer les passagers d’un itinéraire de voyage perturbé à un nouvel itinéraire de voyage font peu pour relever ces défis et sont donc loin d’être satisfaisants. Par exemple, lorsqu’un itinéraire de voyage est perturbé dans sa fenêtre opérationnelle, les passagers affectés par la perturbation peuvent déjà être à l’aéroport et être enregistrés sur un ou plusieurs vols. Par conséquent, le transfert des passagers vers un nouvel itinéraire de voyage peut être géré par un agent DGS qui interagit avec un DGS. Cependant, dans des environnements conventionnels, les DGS fonctionnent plutôt indépendamment des systèmes de réservation et des systèmes d’inventaire qu’ils accommodent par rapport aux transferts de passagers. Plus particulièrement, lorsqu’un DCS conventionnel effectue une opération de transfert qui implique un vol donné, le système de réservation et le système d’inventaire qui gèrent le vol ne sont avertis de l’opération qu’après le départ du vol, par exemple au cours d’une période de rapprochement comptable ultérieure. Par conséquent, lorsqu’un passager est transféré d’un vol à un autre par un DCS conventionnel, les systèmes de réservation et les systèmes d’inventaire impliqués ne sont pas avertis en temps réel du transfert et ces systèmes n’ont typiquement pas connaissance du transfert avant le départ des vols. Il en résulte qu’avant le départ des vols les systèmes de réservation et les systèmes d’inventaire impliqués peuvent ne pas refléter correctement les réservations et la disponibilité pour chaque vol. Ce manque de précision peut donner lieu à des surréservations ou à des sous-réservations inattendues des vols et peut générer une charge de travail additionnelle pour la compagnie aérienne lors d’un rapprochement comptable ultérieur.

[0045] Un autre revers est qu’un DCS conventionnel permet généralement à un agent DCS de transférer des passagers sur des vols déjà ouverts dans le DCS, mais pas sur d’autres vols, tels que ceux qui ne sont pas encore ouverts ou des vols externes qui ne sont pas hébergés par un DCS particulier. Par conséquent, le nombre d’options possibles pour un passager en cours de transfert est réduit, réduisant ainsi les chances que le passager pourra atteindre sa destination pendant le délai désiré.

[0046] En outre, le transfert d’un passager via un DCS conventionnel peut être une procédure complexe sujette à des erreurs, surtout lorsque le passager a déjà été enregistré sur le vol depuis lequel il est transféré. Comme décrit ci-dessus, lorsqu’un passager s’enregistre sur un vol, certaines informations, telles que des informations de bagage et de réglementation, peuvent être ajoutées à l’enregistrement DCS du passager pour le vol comme partie intégrante des données de passagers enregistrées pour le passager pour le vol. Par conséquent lorsque l’agent transfère un passager déjà enregistré sur un vol vers un nouveau vol, via un DCS conventionnel, il a généralement besoin d’accepter manuellement le passager sur le nouveau vol ; au moins en partie en rentrant manuellement les informations d’enregistrement antérieures du passager dans le DCS,

Cette procédure de réacceptation manuelle rallonge le temps nécessaire pour effectuer un transfert et peut engendrer un retour en arrière (entraînant plus de retard) si des données sont ressaisies de façon incorrecte. En outre, i’agent DCS doit typiquement effectuer cet enregistrement manuel pour chaque passager en cours de transfert. Lorsqu’un avion entier de passagers est perturbé et que chaque passager a besoin d’être transféré, par exemple lorsqu’un vol est annulé, le temps de traitement pour le transfert dé tous les passagers affectés par la perturbation vers un nouvel itinéraire de voyage peut donc s’avérer accablant.

[0047] Dans certaines situations, l’itinéraire de voyage d’un ou de plusieurs passagers peut être perturbé en raison d’un changement de programmation (p. ex., une annulation ou un changement d’horaire) effectué par une compagnie aérienne via un système d’inventaire.

Cependant, en raison de la configuration des systèmes conventionnels impliqués dans un transfert de passager, une compagnie aérienne est généralement incapable de réaliser des changements d’horaires pour un vol dans la fenêtre opérationnelle du vol et/ou après l’enregistrement d’un ou de plusieurs passagers sur le vol. Spécifiquement, en réponse à l’implémentation d’un changement d’horaire d’une compagnie aérienne pour un vol, par exemple dans un système d’inventaire conventionnel, un système de réservation conventionnel correspondant est configuré pour annuler la réservation des passagers sur le vol modifié, ce qui amène le système de réservation à notifier l’annulation des réservations au DCS, par exemple via une liste de noms modifiée (ADL) qui supplémente le PNL reçu pour le vol, avec les ajouts de nouveaux passagers ou les suppressions d’anciens passagers pour le vol. Lors de la réception de cette notification, le DCS est typiquement configuré pour effectuer un autonettoyage des données de passager et/ou des enregistrements DCS pour le vol qui est associé aux passagers dont la réservation a été annulée, ce qui entraîne une perte d’information incluse dans ces enregistrements. Par conséquent si un passager a déjà été enregistré sur le vol modifié, l’information, telle que l’information de bagage ou l’information réglementaire, ajoutée à l’enregistrement DOS du passager pour le vol lors de l’enregistrement, est perdue. Cette information ayant généralement besoin d’être conservée pour des raisons à la fois commerciales et réglementaires, les compagnies aériennes sont incapables, dans un environnement de voyage conventionnel, d’implémenter des changements d’horaire via un système d’inventaire conventionnel dans la fenêtre opérationnelle d’un vol et/ou après l’enregistrement d’un ou de plusieurs passagers sur le vol.

[0048] Le système de transfert 20 apporte une solution à ces problèmes et à d’autres.

Spécifiquement, le système de transfert 20 peut recevoir une demande de transfert de passager via le système de réservation 12, le système d’inventaire 14 ou le DCS 18. Par exemple, un agent DCS peut accéder au système de transfert 20 via un terminal d’ordinateur du DCS 18, sélectionner un ou plusieurs vols de remplacement pour un nouvel itinéraire de voyage via une interface graphique d’utilisateur (GUI) générée par le système de transfert.20 et, par la suite, soumettre une demande de transfert au système de transfert 20 incluant au moins une portion du nouvel itinéraire de voyage, par exemple au moins les vols de remplacement. Autrement, lorsqu’un agent d’inventaire d’une compagnie aérienne, exécute un changement d’horaire pour un vol soit avant, soit ou cours de la fenêtre opérationnelle du vol, via le système d’inventaire 14, le système d’inventaire 14 peut afficher la GUI du système de transfert 20. En utilisant la GUI, l’agent de la compagnie aérienne peut sélectionner un ou plusieurs vols de remplacement pour un nouvel itinéraire de voyage et par la suite émettre une demande de transfert au système de transfert 20 incluant au moins une portion du nouvel itinéraire de voyage, par exemple au moins les vols de remplacement. Comme autre exemple, après un changement d’horaire exécuté dans le système d’inventaire 14, le système de transfert 20 peut automatiquement générer une ou plusieurs demandes de transfert pour les passagers affectés, chacune des demandes de transfert incluant au moins une portion du nouvel itinéraire automatiquement sélectionné par le système de transfert 20. En d’autres termes, le système de transfert 20 peut « recevoir » la demande de transfert via le système d’ inventaire 14 du fait de la génération automatique d’une demande de transfert en réponse à un changement d’horaire en cours d’exécution dans le système d’inventaire 14.

[0049] Quel que soit le cas, en réponse à la réception d’une demande de transfert, le système de transfert 20 peut être configuré pour automatiser une séquence spécifique d’interactions complexes entre les systèmes de l’environnement d’exploitation 10 qui transfère intégralement un ou plusieurs passagers d’un itinéraire de voyage perturbé sur un autre itinéraire de voyage avec peu ou aucune interaction de la part d’un agent. En d’autres termes, après que le système de transfert 20 a fini de traiter la demande de transfert, les passagers transférés peuvent être en mesure de continuer

S avec leur nouvel itinéraire sans aucune action supplémentaire de la part d’un agent. Par exemple, en supposant qu’aucune erreur ne survienne, l’agent peut ne pas avoir à réaccepter manuellement chaque passager transféré sur le nouvel itinéraire de voyage ou manuellement recopier les informations d’enregistrement des enregistrements DCS antérieurs du passager. De surcroît, une fois que le système de transfert 20 a fini de traiter la demande de transfert, les autres systèmes de l’environnement d’exploitation 10 peuvent être en état synchronisé assurant ainsi que les systèmes reflètent correctement les réservations et la disponibilité pour chaque vol affecté par le transfert. (0050] De plus, parce qu’un temps de réponse rapide est désiré et parfois nécessaire lors du transfert de passagers d’un itinéraire de vol perturbé à un nouvel itinéraire de vol, le système de transfert 20 peut être configuré pour faciliter la séquence d’interactions de manière à réduire et minimiser te temps d’achèvement du traitement pour une demande de transfert reçue. En particulier, le système de transfert 20 peut être configuré pour poursuivre le traitement de la demande de transfert en dépit de l’occurrence de certaines erreurs. Par la suite, si des erreurs sont survenues pendant le traitement, un rapport unique complet de toutes les erreurs peut être affiché pour l’agent qui peut alors prendre action pour y remédier. De surcroît, dans des situations impliquant de multiples passagers ayant besoin d’être transférés, par exemple en raison d’un changement d’horaire exécuté dans le système d’inventaire 14 qui affecte un vol entier, le système de transfert 20 peut être configuré pour faciliter le traitement de chaque passager parallèlement, pour une ou plusieurs parties du processus de transfert, ce qui réduit encore le temps de réponse du système. Ces caractéristiques du système de transfert 20 et d'autres sont décrites de façon plus détaillée par la suite, [0051] Faisant maintenant référence à la FIG. 2, les systèmes de l'environnement d'exploitation 10 peuvent être implémentés sur un ou plusieurs dispositifs informatiques, tels que le dispositif informatique exemplaire 26. Le système informatique 26 peut inclure un processeur 28, une mémoire 30, un dispositif de stockage de mémoire de masse 32, une interface entrée/sortie (I/O) 34, et une interface homme-machine (HMI) 36. Le système informatique 26 peut aussi être couplé de façon fonctionnelle avec une ou plusieurs ressources externes 38 via le réseau 24 ou l'interface I/O 34. Les ressources externes peuvent inclure, mais de façon non exhaustive, des serveurs, des bases de données, des dispositifs de mémoire de masse, des dispositifs périphériques, des services de réseau cloud, ou autres ressources informatiques appropriées pouvant être utilisée avec l'ordinateur 26.

[0052] Le processeur 28 peut inclure un ou plusieurs dispositifs sélectionnés :

microprocesseurs, mîcrocontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, des réseaux de portes programmables, des dispositifs logiques programmables, des machines à état défini, des circuits logiques, des circuits analogiques, des circuits numériques, ou tout autre dispositif servant â manipuler des signaux (analogues ou numériques) basés sur des instructions de fonctionnement enregistrées dans la mémoire 30. La mémoire 30 peut inclure un seul dispositif de mémoire ou une pluralité de dispositifs de mémoire comprenant, de façon non exhaustive, la mémoire morte (ROM), la mémoire vive (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire vive dynamique (DRAM), la mémoire flash, l'antémémoire (cache memory), ou tout autre dispositif capable de stocker des informations. Le dispositif de mémoire de masse 32 peut inclure des dispositifs de stockage de données tels qu’un disque dur, un disque optique, un dérouleur de bande magnétique, un circuit à l'état solide volatile ou non volatile, ou tout autre dispositif capable de stocker des informations.

[0053] Le processeur 28 peut fonctionner sous Je contrôle d'un système d'exploitation 40 qui réside dans la mémoire 30. Le système d'exploitation 40 peut gérer les ressources de l'ordinateur de telle façon que le code de programme de l'ordinateur, intégré sous forme d'un ou de plusieurs logiciels d'application, tels que l'application 42, résidant dans la mémoire 30, puisse disposer d’instructions exécutées par le processeur 28. Dans un autre mode de réalisation alternatif, le processeur 28 peut exécuter l'application 42 directement et dans ce cas, le système d'exploitation 40 peut être omis. Une ou plusieurs structures de données 44 peuvent aussi résider dans la mémoire 30, et peuvent être utilisées par le processeur 28, le système d’exploitation 40 ou l'application 42 pour stocker ou manipuler des données.

[0054] L'interface 34 peut fournir une interface machine qui couple de façon fonctionnelle le processeur 28 à d'autres dispositifs et systèmes, tels que le réseau 24 ou une ou plusieurs ressources externes 38. L'application 42 peut ainsi collaborer avec le réseau 24 et/ou les ressources externes 38 en communiquant par l'intermédiaire de l'interface I/O 34 pour fournir les divers éléments, fonctions, applications, processus, ou modules composant les modes de réalisation de l’invention. Le serveur d'application 42 peut aussi avoir un code de programme qui est exécuté par une ou plusieurs ressources externes 38 ou sinon repose sur les fonctions ou signaux fournis par d'autres systèmes ou composants de réseau externe à l'ordinateur 26. En effet, au vu des configurations presque infinies de matériel informatique et de logiciel possibles, les hommes de métier comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieurement à l'ordinateur 26, distribuées à des ordinateurs multiples et à d'autres ressources externes 38, ou apportées par des ressources informatiques (matériel et logiciel) qui sont fournies comme services sur le réseau 24, par exemple un service d’informatique en nuage (cloud computing).

[0055] Le HMI peut 36 peut être couplé de façon fonctionnelle avec le processeur 28 du système informatique 26 d'une manière connue pour permettre à un utilisateur d'interagir directement avec système informatique 26. Le HMI 36 peut inclure un affichage vidéo ou une unité d'affichage à caractères, un écran tactile, un haut-parleur et tout autre indicateur visuel et audio capable de communiquer des données à l'utilisateur. Le HMI 36 peut aussi inclure des dispositifs de saisie et des contrôles tels qu’un clavier alphanumérique, un périphérique de pointage, des claviers, des boutons poussoir, des boutons de commande, des microphones, etc. capables d’accepter des „ commandes ou des saisies de l'utilisateur, et de les transmettre au processeur 28.

[0056] La base de données 46 peut résider sur le dispositif de stockage de mémoire de masse 32 et peut être utilisée pour collecter et organiser les données utilisées par les divers systèmes et modules décrits dans les présentes. La base de données 46 peut inclure des données et la structure de données qui les supporte pour stocker et organiser les données. En particulier, la base de données 46 peut-être arrangée selon toute organisation ou structure de base de données incluant, mais de façon non exhaustive, une base de données relationnelle, une base de données de type hiérarchique, une base de données en réseau, ou des combinaisons de celles-là. Un système de gestion de base de données, sous forme d'une application logicielle qui s'exécute sous forme d'instructions sur le processeur 28, peut être utilisé pour accéder à l'information ou aux données stockées dans les enregistrements de la base de données 46 en réponse à une interrogation, dans lequel l'interrogation peut être déterminée de façon dynamique et peut être exécutée par le système d'exploitation 40, d'autres applications 42 ou un ou plusieurs modules.

[0057] La FIG.3 Illustre une architecture de traitement 50 qui peut inclure un modulé de transfert 52 et une pluralité de bases de données. Le module de transfert 52 peut être hébergé par un ou plusieurs des systèmes de l’environnement d’exploitation 10, tels que le système d’inventaire 14 et/ou le système de transfert 20. En d’autres termes, le module de transfert 52 peut être implémenté via des instructions exécutables par ordinateur, stockées sur un ou plusieurs dés systèmes de l'environnement d’exploitation 10, de sorte que chacun d’un ou de plusieurs systèmes comprend une portion du module de transfert 52.

[0058] En réponse à la réception d’une demande de transfert 54, le module de transfert 52 peut être configuré pour faciliter automatiquement une séquence d’interactions avec les bases de données afin de transférer intégralement un ou plusieurs passagers d’un itinéraire de voyage perturbé à un nouvel itinéraire de voyage. Plus particulièrement, le module de transfert 52 peut amener un ou plusieurs processeurs qui peuvent être inclus dans un ou plusieurs des systèmes de l’environnement d’exploitation 10, à interagir avec les bases de données de l’architecture de traitement 50 et à effectuer des opérations variées afin de transférer un passager d’un itinéraire de voyage perturbé à un nouvel itinéraire de voyage d’une manière entièrement intégrée et automatisée. Pendant ce processus, le module de transfert 52 peut veiller au statut du processus de transfert du passager et continuellement actualiser un rapport de transfert affiché 56 sur cette base. Après l’achèvement du processus de transfert facilité par le module de transfert 52, le module de transfert 52 peut stocker la version finale du rapport de transfert 56, par exemple dans une base de données de rapport de transfert 70. Tout cela, ainsi que d’autres éléments concernant le processus de transfert facilité par le module de transfert 52, est décrit de façon plus détaillée en référence aux FIGS. 4-6.

[0059] Les bases de données de l’architecture de traitement 50 peuvent inclure une base de données d’enregistrement de réservation 58, une base de données d’inventaire 60, une base de données d’e-bület 62, une base de données de coupon EMD 64, une base de données DCS 66, une base de données de demande dé transfert 68 et une base de données de rapport de transfert 70, Chacune des bases de données mentionnées ci-dessus peut être hébergée par un ou plusieurs des systèmes de l’environnement d’exploitation 10. Chacune de ces bases de données peut comprendre de multiples bases de données et peut faire partie d’une base de données plus large qui inclut une ou plusieurs des autres bases de données.

[0060] La base de données d’enregistrement de réservation 58 peut être hébergée par le système de réservation 12 de {'environnement d'exploitation 10, La base de données d’enregistrement de réservation 58 peut stocker un enregistrement de réservation, tel qu’un PNR, pour chaque réservation faîte par le système de réservation 12. Plus particulièrement, la base de données d’enregistrement de réservation 58 peut stocker les enregistrements de réservation générés par le système de réservation 12 comme décrit ci-dessus en référence à la FIG. 1.

[0061] La base de données d’inventaire 60 peut être hébergée par le système d’inventaire 14 de l’environnement d’exploitation 10. La base de données d’inventaire 60 peut suivre une valeur de disponibilité pour chaque produit et/ou service auxiliaire de voyage offert par un ou plusieurs fournisseurs de services. Plus particulièrement, la base de données d’inventaire 60 peut stocker le nombre total d’unités disponibles proposées par les fournisseurs de services pour chaque produit de voyage et service auxiliaire, ainsi que les compteurs qui suivent, pour chaque produit de voyage et service auxiliaire, le nombre d’unités qui ont été réservées de chaque produit de voyage et service auxiliaire, comme décrit ci-dessus en référence à la FIG. 1.

[0062] La base de données e-btllet 62 et la base de données de coupon EMD 64 peuvent être hébergées par le système bi 1 lettique 16 de l’environnement d’exploitation 10. La base de données ebillet 62 peut stocker chaque e-billet généré par le système billettîque 16 et la base de données de coupon EMD 64 peut stocker chaque coupon EMD généré par le système billettîque 16. Comme décrit précédemment, dans certains modes de réalisation, la base de données e-biliet 62 et la base de données de coupon EMD 64 peuvent être incluses dans une seule base de données billettiques. De cette façon, chaque coupon EMD stocké dans la base de données billettîque peut être associé ou lié dans la base de données billettiques à l’e-billet associé au coupon EMD.

[0063] La base de données DCS 66 peut être hébergée par le DCS 18 de l’environnement d’exploitation 10. La base de données DCS 66 peut stocker un enregistrement de vol pour chaque vol ouvert dans le DCS 18. De plus, la base de données DCS 66 peut stocker les enregistrements

DCS générés par le DGS 18 incluant les données de passager pour les passagers des vols ouverts. Chaque enregistrement DGS stocké dans la base de données DCS 66 pour un passager donné peut être associé ou lié dans la base de données DCS 66 à un des vols ouverts de l’itinéraire de voyage du passager, par exemple, par association à l’enregistrement du vol ouvert inclus dans la base de données DCS 66. Par exemple, si un itinéraire de voyage pour un passager inclut un vol A et un vol

B, un enregistrement DCS pour le passager peut alors être associé, ou lié, dans la base de données DCS 66 au vol A et un autre enregistrement DCS pour le passager peut être associé ou lié dans la base de données DCS 66 au vol B. De plus, chacun de ces enregistrements DCS peut être associé ou lié avec un autre dans la base de données DGS 66 et/ou avec l’itinéraire de voyage complet du passager.

[0064] La base de données de demande de transfert 68 et la base de données de rapport de transfert 70 peuvent être hébergées par le système de transfert 20. La base de données de demande de transfert 68 peut stocker chaque demande de transfert 54 reçue par le module de transfert 52 et la base de données de rapport de transfert 70 peut stocker chaque rapport de transfert final 56 généré par le module de transfert 52, Chaque rapport de transfert 56 stocké dans la base de données de rapport de transfert 70 peut inclure un résumé consolidé du traitement d’une demande de transfert 54, y compris si chaque passager de la demande de transfert 54 a été transféré avec succès et quelles actions, le cas échéant, doivent être initiées ou accomplies par un agent pour compléter la demande de transfert 54. Comme il a été mentionné précédemment, la base de données de demande de transfert 68 et la base de données de rapport de transfert 70 peuvent faire partie d’une base de données un ique de transfert et chaque demande de transfert 54 incluse dans la base de données de transfert peut être associée ou liée dans la base de données de transfert au rapport de transfert correspondant 56.

[0065] La FIG. 4 illustre un processus 100 pour transférer des passagers d’un itinéraire de voyage perturbé à un nouvel itinéraire de voyage. Le processus 100 peut être implémenté ou facilité par le module de transfert 52 de l’architecture de traitement 50. En général le processus 100 peut se dérouler comme suit. Un agent habilité peut accéder à une GUI générée par le module de transfert 52, sélectionner des passagers affectés par une perturbation et consulter des produits de voyage de remplacement qui correspondent le mieux à l’itinéraire de voyage perturbé du passager sélectionné. L’agent, utilisant la GUI, peut alors sélectionner un ou plusieurs des produits de voyage de remplacement pour les inclure dans un nouvel itinéraire de voyage pour les passagers et peut, par la suite, déclencher le processus 100, entièrement intégré et automatisé, de transfert du passager. En réponse au déclenchement du processus de transfert 100, une demande de transfert 54 basée sur les sélections de l'agent peut être générée par le module de transfert 52 et/ou reçue par celui-ci. En réponse à la demande de transfert 54 qui est générée et/ou reçue, le module de transfert 52 peut être configuré pour appeler et/ou amener les divers systèmes, tels qu’un ou plusieurs des systèmes de l’environnement d’exploitation 10 à effectuer une série de sous-processus. L’ordre selon lequel ces sous-processus sont effectués peut être spécifique, car la mise en œuvre des sous-processus dans un autre ordre peut causer un retour en arrière inutile qui réduira la vitesse et l’efficacité des systèmes impliqués pour compléter le transfert, [0066] La série de sous-processus ordonnés peut inclure un processus de validation, un processus d’actualisation d’un inventaire, un processus de nouvelle réservation, un processus de débarquement, un processus de billetterie, un processus d’actualisation d’un DCS et un processus de rapport. Le processus de validation peut inclure la mise en œuvre de contrôles de la demande de transfert 54 pour assurer que la demande de transfert 54 est légitime et correcte. Le processus d’actualisation de l'inventaire peut inclure l’actualisation des compteurs stockés dans la base de données d’inventaire 60 sur ta base des vois de i’itinéraire de voyage perturbé qui ne sont pas partis et qui ne sont pas inclus dans le nouvel itinéraire de voyage (c.-à-d. les vols remplacés) et les vols du nouvel itinéraire de voyage qui ne sont pas inclus dans l’itinéraire de voyage perturbé (c.-à-d. les nouveaux vols). Le processus de nouvelle réservation peut inclure de réserver à nouveau les passagers sélectionnés et de transférer leurs préférences et leurs services auxiliaires sur les nouveaux vols d’un nouvel itinéraire de voyage dans la base de données d’enregistrement de réservation 58. Le processus de débarquement peut inclure l’annulation de l’acceptation des passagers identifiés, ayant déjà été enregistrés sur le vol remplacé de l’itinéraire de voyage perturbé dans la demande de transfert 54, ce qui libère les e-billets des passagers par rapport aux coupons qu’ils contiennent pour les vols remplacés ainsi que les coupons EMD associés aux vols remplacés et permet ainsi que le processus de billetterie se déroule avec succès. Le processus de billetterie inclut la génération d’un e-billet valide pour le nouvel itinéraire de voyage dans la base de données d’e-billet 62 pour chaque passager et le traitement des coupons EMD de chaque passager associés aux vols remplacés dans la base de données de coupon EMD 64 pour le nouvel itinéraire de voyage. Le processus d’actualisation DCS peut inclure le transfert d’information, telle que les détails d’enregistrement, dans la base de données DCS 66, de sorte que chaque information de passager stockée en relation avec les vols remplacés est transférée vers l’information de passager stockée en relation avec ies nouveaux vols. Par ailleurs, le processus d’actualisation du DCS peut inclure l’acceptation de chaque passager sur les nouveaux vols qui sont ouverts dans le DCS 18 et/ou qui sont disponibles vîa l’enregistrement à destination finale (through check-in). Au cours de tous les sous-processus mentionnés ci-dessus, le processus de rapport peut générer et fournir un rapport complet et détaillé à l’agent. Le rapport complet et détaillé peut fournir des données visuelles et actualisées concernant le statut du processus de transfert 100, par exemple un statut global du processus 100 et/ou des parties du processus 100 qui ont abouti ou qui ont échoué, pour chaque passager.

[0067J Après que chacun de ces processus a été effectué pour les passagers sélectionnés, les divers systèmes et/ou bases de données impliqués dans le transfert du passager peuvent être dans un état synchronisé. Spécifiquement, les enregistrements de réservation stockés pour chaque passager sélectionné, dans la base de données d’enregistrements de réservation 58 peuvent inclure les détails du nouvel itinéraire de voyage incluant les services auxiliaires réservés en relation avec celui-ci, les compteurs dans la base de données d’inventaire 60 peuvent refléter la disponibilité des produits de voyage et des services auxiliaires impliqués à la fois dans l’itinéraire de voyage perturbé et dans le nouvel itinéraire de voyage (les compteurs pour les produits de voyage remplacés peuvent être décrémentés et les compteurs pour les nouveaux produits de voyage peuvent être augmentés, etc.) et le DCS 18 peut inclure un ou plusieurs enregistrements DCS pour les nouveaux vols qui incluent les passagers transférés, le nouvel itinéraire de voyage et/ou toute information pertinente précédemment stockée pour les passagers en relation avec l’itinéraire de voyage perturbé (p. ex. l’information de bagage). De cette façon, après l’achèvement du processus de transfert et avec peu ou aucune interaction de la part d’un agent, le DCS 18 peut être en mesure d’effectuer ses opérations régulières pour les passagers transférés comme si les passagers avaient été initialement réservés et enregistrés sur les vols du nouvel itinéraire de voyage. De plus, les passagers peuvent continuer à être réservés à la fois sur les vols remplacés (s’ils ne sont pas annulés) et sur les nouveaux vols avec un risque réduit de surréservation ou de sous-réservation pour les produits de voyage dus à un manque de connaissance des passagers transférés via le DCS 18.

[0068] Le processus 100 peut maintenant être décrit de façon plus détaillée. Dans le bloc 102, une demande de transfert peut être reçue, par exemple par le module de transfert 52. Plus particulièrement, la demande de transfert 54 peut être reçue par le module de transfert 52 via le système de réservation 12, le système d’inventaire 14 ou le DCS 18. Par exemple, à partir d’un terminal d’ordinateur connecté au DCS 18, un agent DCS peut accéder à l’écran d’enregistrement d’un client, ou à l’écran d’une liste de clients, qui peut être affiché comme une partie d’une GUI présentée â l’agent et générée par le module de transfert 52 et/ou par le DCS 18. De l’écran d’enregistrement du client ou de l’écran de la liste de clients, l’agent DCS peut ensuite sélectionner un ou plusieurs passagers affectés par une perturbation pour un transfert.

[0069] En général, le DCS 18 et/ou le module de transfert 52 peuvent permettre à l’agent

DCS de transférer un passager sur tout type de vol hébergé, incluant les vols gérés par le système de réservation 12 et le système d’inventaire 14 de l’environnement d’exploitation 10 et sur les vols gérés au sol par des systèmes de réservation et des systèmes d’inventaire externes à i’enyironnement d’exploitation 10. Certains sous-processus inclus dans le processus 100, par exemple le processus de nouvelle réservation qui est décrit ci-dessus, peuvent être affectés selon que le passager est transféré d’un vol géré au sol ou d’un autre vol hébergé. De telles variations sont décrites de façon plus détaillée ci-dessous.

[0070] En réponse à la réception de la sélection de l’agent, d’un ou de plusieurs passagers pour un transfert, la GUI peut afficher un écran de sélection de vols qui inclut une liste de vols de remplacement pour les passagers sélectionnés, La liste des vols de remplacement peut inclure à la fois des vols hébergés par le DCS 18, qu’ils soient ouverts ou qu’ils ne le soient pas encore sur le DCS 18, et/ou des vols externes au DCS 18 (p. ex. des vols hébergés sur d’autres DCS). Ces derniers peuvent être clairement identifiés comme des vols externes. De cette façon, contrairement aux systèmes conventionnels, le DCS 18 et/ou le module de transfert 52 peuvent permettre à l’agent DCS de transférer un passager d’un itinéraire de voyage perturbé à un nouvel itinéraire de voyage qui inclut des vois hébergés par le DCS 18, des vols externes au DCS 18, ou une combinaison de ceux-là. En d’autres termes, le DCS 18 fournit plus d’options pour un transfert que les systèmes conventionnels. Pour d’autres vols de remplacement qui sont hébergés par le DCS 18, l’écran d’affichage de la sélection de vols peut afficher une disponibilité brute pour chaque vol de remplacement, dont une partie peut être basée sur des accords de partenariat entre des compagnies aériennes qui exploitent certains des vols de remplacement et la compagnie aérienne pour lequel le terminal d’ordinateur connecté via le DCS 18 effectue actuellement des opérations.

[0071] Pour les vols de remplacement qui sont externes ou DCS 18, l’écran de sélection de vols peut afficher une disponibilité générale de réservation pour chaque vol. Si l’agent DCS sélectionne un ou plusieurs vols externes pour le nouvel itinéraire de voyage, la GUI peut alors, en réponse à la sélection de l’agent, afficher un écran de sélection de classe. L’écran de sélection de classe peut permettre à l’agent DCS de choisir, en fonction de la disponibilité, la classe de réservation sur laquelle les passagers doivent être réservés sur les vols externes sélectionnés.

[0072] Après que l’agent DCS a sélectionné les passagers pour le transfert et les nouveaux vols pour le nouvel itinéraire de voyage, l’agent DCS peut utiliser la GUI pour soumettre une demande de transfert 54 au module de transfert 52. La demande de transfert $4peut inclure une identification de chaque passager affecté par la perturbation, pour lequel un transfert a été demandé, les détails d’au moins une portion de l’itinéraire de voyage perturbé de chaque passager (p, ex. au moins les vols remplacés) et/ou des détails d’au moins une portion du nouvel itinéraire (p. ex. au moins les nouveaux vols) qui remplace l’itinéraire de voyage perturbé pour chaque passager. En réponse à l’émission de la demande de transfert 54 au module de transfert 52, la GUI peut afficher un rapport de transfert 56 qui est actualisé périodiquement sur la base du statut actuel du processus de transfert 100. En particulier, le rapport de transfert 56 peut inclure un statut global du processus 100 et un statut du processus 100 pour chaque passager pour lequel un transfert a été demandé.

[0073] Comme mentionné précédemment, une demande de transfert 54 peut aussi être reçue par le module de transfert 52 via te système d’inventaire 14. En particulier, de façon similaire au cas de DCS 18 décrit ci-dessus, un agent d’inventaire peut accéder à la GUI générée par le système d’inventaire 14 et/ou le module de transfert 52, par exemple via un terminal d’ordinateur connecté au système d’inventaire 14. En utilisant la GUI, l’agent d’inventaire peut sélectionner un ou plusieurs passagers à transférer, sélectionner une ou plusieurs options de vol de remplacement pour un nouvel itinéraire de voyage pour les passagers et par la suite soumettre une demande de transfert 54 incluant un ou plusieurs des éléments cités ci-dessus au module de transfert 52, [0074] Contrairement aux systèmes conventionnels qui limitent généralement l’exécution des changements d’horaires dans le système d’inventaire 14 pour un vol donné à un moment avant la fenêtre opérationnelle du vol, le système de réservation 12, le système d’inventaire 14, le DCS 18 et le module de transfert 52 peuvent permettre à une compagnie aérienne d’exécuter un changement d’horaire pour un vol dans le système d’inventaire 14 à un moment dans la fenêtre opérationnelle du vol. En particulier, le DCS 18 et/ou le module de transfert 52 peuvent être configurés pour conserver un ou plusieurs enregistrements de sauvegarde par exemple, dans la base de données

DCS 66, incluant des données de passager telles que l’information de passager, les détails d’enregistrement, l’information de bagage, l’information réglementaire et l’information d’itinéraire de voyage des enregistrements DCS stockés dans la base de données DCS 66. Le DCS 18 et/ou le module de transfert 52 peuvent aussi être configurés de sorte que ces enregistrements de sauvegarde ne soient pas effacés en réponse à un changement d’horaire. Les données stockées dans les enregistrements de sauvegarde peuvent être désignées dans les présentes comme « données non opérationnelles ».

[0075] Ainsi, bien qu’un changement d’horaire pour un vol donné exécuté dans le système d’inventaire 14 dans la fenêtre opérationnelle du vol puisse déclencher la suppression d’information importante stockée en relation avec les passagers réservés sur le vol, telle que l’information stockée dans la base de données d’enregistrement de réservation 58 et dans la base de données DCS 66, les passagers peuvent toujours être transférés automatiquement via le processus 100, En particulier, en utilisant les données non opérationnelles conservées par le DCS 18 et/ou par le module de transfert 52, le processus 100 peut effectivement transférer les passagers affectés en dépit du nettoyage de données causé par le changement d’horaire.

[0076] Dans certains modes de réalisation, le DCS 18 et/ou le module de transfert 52 peuvent être configurés pour générer et stocker les enregistrements en réponse à la réception d’une notification, par exemple via un ADL, d’un changement exécuté pour un vol dans le système d’inventaire 14 affectant l’itinéraire de voyage d’un ou de plusieurs passagers. De cette façon, les enregistrements de sauvegarde générés par le DCS 18 et/ou le module de transfert 52 ne peuvent être en rapport qu’avee les vols et/ou passagers affectés par le changement, ce qui permet au

DCS 18 et/au module de transfert 52 de réaliser des économies de ressources en ne stockant pas les enregistrements de sauvegarde pour chacun et tous les vols et/passagers gérés par le DCS 18. En d’autres termes, en réponse à un changement d’horaire exécuté dans le système d’inventaire 14 qui affecte l’itinéraire de voyage d’un ou de plusieurs passagers, le DCS 18 peut générer un enregistrement de sauvegarde pour chaque passager, incluant la donnée de passager pour le passager, stockée en relation avec Γitinéraire de voyage du passager, ou plus particulièrement en association avec le vol affecté de l’itinéraire de voyage. Plus tard, lorsqu’un transfert vers un nouvel itinéraire de voyage est initié pour ces passagers, pour chaque passager, la donnée de passager qui est transférée vers un ou plusieurs enregistrements DCS, pour un ou plusieurs nouveaux vols remplaçant le vol affecté, peut provenir de l’enregistrement de sauvegarde du passager.

[0077] Le système de réservation 12 et/ou le module de transfert 52 peuvent aussi stocker l’histoire de chaque enregistrement de réservation, stocké dans la base de données 58, faisant l’objet d’un changement, par exemple, en raison d’un changement d’horaire. Cette histoire peut être désignée dans les présentes comme « histoire du PNR » et peut être incluse dans l’enregistrement de réservation correspondant. Spécifiquement, l’histoire du PNR peut inclure des détails sur un itinéraire de voyage précédent sur lequel un passager était réservé. Avec les enregistrements de sauvegarde, le processus 100 peut aussi utiliser l’histoire du PNR si nécessaire, par exemple pour déterminer l’itinéraire de voyage perturbé d’un passager afin de remplacer des vols avec de nouveaux vols correspondants, ce qui est décrit de façon plus détaillée ci-dessous.

[0078] Dans certains modes de réalisation, en réponse à un changement d’horaire exécuté dans le système d’inventaire 14, le système d’inventaire 14 et/ou le module de transfert 52 peuvent être configurés pour déclencher automatiquement le processus de transfert 100. En particulier, le système d’inventaire 14 et/ou le module de transfert 52 peuvent être configurés pour sélectionner automatiquement un ou plusieurs produits de voyage de remplacement pour un nouvel itinéraire de voyage pour les passagers affectés négativement par le changement d’horaire. Par exemple,

Γitinéraire de voyage de plusieurs passagers peut inclure un segment de vol commun, le changement d’horaire peut être relatif au segment de vol commun et peut être dans la fenêtre opérationnelle du segment de vol commun. Par conséquent, chacun des multiples passagers peut être affecte négativement par Je changement d’horaire. Quel que soit fe cas, le système d’inventaire 14 et/ou le module de transfert 52 peuvent sélectionner les produits de voyage de remplacement pour le nouvel itinéraire de voyage sur la base de règles et/ou de paramètres définis par la compagnie aérienne associée au changement d’horaire, et/ou sur la base des produits de voyage de remplacement correspondant le mieux au vol ou vols affectés par le changement d’horaire.

[0079] Accompagnant le processus de voyage 100 déclenché en réponse à un changement d’horaire, le système d’inventaire 14 et/ou le module de transfert 52 peuvent être configurés pour fonctionner en mode automatique ou en mode guidé. Lorsqu’ils fonctionnent en mode automatique, une fois que ledit ou plusieurs produits de voyage de remplacement ont été sélectionnés, le système d’inventaire 14 et/ou le module de transfert 52 peuvent être configurés pour effectuer automatiquement les étapes restantes du processus de transfert 100. Cependant, lorsqu’ils fonctionnent en mode guidé, le système d’inventaire 14 et/ou le module de transfert 52 peuvent d’abord, par exemple via une GUI générée par le système d’inventaire 14 et/ou le module de transfert 52, donner à i’agent d’inventaire la possibilité d’accepter ou de changer les produits de voyage de remplacement sélectionnés avant de continuer.

[0080] Dans d’autres modes de réalisation, en réponse à un changement d’horaire, le système d’inventaire 14 et/ou le module de transfert 52 peuvent être configurés pour inciter automatiquement un agent d’inventaire, par exemple via une GUI générée par le système d’inventaire 14 et/ou le module de transfert 52, à sélectionner manuellement un ou plusieurs produits de voyage de remplacement pour inclusion dans un nouvel itinéraire de voyage pour les passagers affectés négativement par le changement d’horaire, par exemple en utilisant les écrans de la GUI décrits ci-dessus en relation avec le DCS 18. Autrement, le module de transfert 52 et/ou le système d’inventaire 14 peuvent ne pas être configurés pour prendre une quelconque action relative au transfert des passagers en réponse à un changement d’horaire exécuté dans te système d’inventaire 14. Dans ce cas, l’agent d’inventaire peut, soit accéder manuellement à une GUI générée par le système d’inventaire 14 et/ou le module de transfert 52 pour faire des sélections et déclencher le processus de transfert 100 qui est décrit ci-dessus en relation avec le DCS 18, soit ne rien faire et laisser les agents DCS gérer tous les passagers affectés par la perturbation via le

DCS 18, [0081] Comme l’illustre la FIG. 4, après la réception de la demande de transfert 54, il est possible de déterminer si la demande de transfert 54 est valide (block 104). En particulier, le module de transfert 52 peut être configuré pour vérifier que Γagent demandeur est habilité à déclencher le transfert, par exemple en récupérant la donnée d’autorisation stockée et associée à l’information de connexion de l’agent. Autrement, l’habilitation de l’agent pour le déclenchement peut être supposée du fait que l’agent est capable de se connecter et d’accéder au module de transfert 52, par exemple via un terminal d’ordinateur connecté au DCS 18 ou au système d’inventaire 14. En d’autres termes, seules certaines connexions d’utilisateurs peuvent avoir accès à la GUI permettant à un agent de déclencher une demande de transfert.

[0082] Le bloc 104 peut aussi inclure la possibilité de déterminer si la donnée incluse dans la demande de transfert 54 satisfait une pluralité de contrôles. Par exemple, le module de transfert 52 peut effectuer un contrôle de route, un contrôle d’ordre de vols, un contrôle de correspondance négative, un contrôle de statut d’un vol, un contrôle transversal des transporteurs pour le transfert, un contrôle de statut d’un transfert, un contrôle de statut d’une réservation et du type de passager et/ou un contrôle d’horaire. Chacun de ces contrôles est décrit de façon plus détaillée dans les paragraphes suivants, [0083] Le contrôle de route peut inclure la vérification que le nouvel itinéraire de voyage et l’itinéraire de voyage perturbé dans la demande de transfert 54 ont une route similaire. Spécifiquement, le module de transfert 52 peut assurer que le nouvel itinéraire de voyage inclut la même origine, les mêmes points de correspondance et la même destination (p. ex. les mêmes aéroports, les mêmes villes) que l’itinéraire de voyage perturbé. Sinon, le module de transfert 52 peut alors déterminer que la demande de transfert 54 est invalide. Le contrôle de route peut inclure une ou plusieurs exceptions qui permettent à une demande de transfert 54 ne satisfaisant pas le test ci-dessus de passer ou de contourner ce contrôle. Par exemple, si une demande de transfert 54 est soumise par un agent ayant une habilitation de superviseur, la demande de transfert 54 peut alors contourner le contrôle de route, soit automatiquement soit en réponse à une indication expresse de l’agent.

[0084] Le contrôle d’ordre de vols peut inclure la vérification que la séquence des vols dans le nouvel itinéraire est logique. En particulier, le module de transfert 52 peut vérifier que la séquence des vols dans le nouvel itinéraire est correcte. Par exemple, si le nouvel itinéraire de voyage inclut un vol de A à B et un vol de B à C, et que le vol de A à B décolle après le vol de B à

C, le module de transfert 52 peut alors déterminer que la demande de transfert 54 est invalide.

[0085] Le contrôle de correspondance négative peut inclure la vérification que la séquence de vols dans le nouvel itinéraire de voyage ne forme pas une correspondance négative. En particulier, pour chaque vol dans le nouvel itinéraire de voyage le module de transfert 52 peut vérifier que le vol arrive soit à la destination finale du passager soit à une destination d’où part un vol suivant. Donc, même si le nouvel itinéraire conserve des vols de l’itinéraire de voyage perturbé, les nouveaux vols inclus dans le nouvel Itinéraire de voyage peuvent avoir besoin d’une correspondance avec les vols retenus pour que le nouvel itinéraire de voyage satisfasse ce contrôle. Tout comme pour lé contrôle de route, le contrôle de correspondance négative peut inclure une ou plusieurs exceptions qui permettent à une demande de transfert 54 ne satisfaisant pas le test cidessus de passer ou de contourner le contrôle de correspondance négative. Par exemple, si une demande de transfert 54 est soumise par un agent ayant une habilitation de superviseur, la demande de transfert 54 peut alors contourner le contrôle de correspondance négative, soit automatiquement soit en réponse à une indication expresse de l’agent.

[0086] Le contrôle de statut de vol peut inclure de vérifier que le passager peut effectivement être débarqué d’un ou de plusieurs vols, tels que les vols remplacés sur lesquels au moins un des passagers dans la demande de transfert 54 a déjà été enregistré, dansTitinéraire de voyage perturbé. De plus, le contrôle de statut de vols peut inclure de vérifier que les passagers peuvent ou pourront être acceptés et embarqués sur un ou plusieurs vols, tels que les vols ouverts du nouvel itinéraire de voyage sur lesquels les passagers n’ont pas encore été enregistrés et/ou les nouveaux vols du nouvel itinéraire de voyage. En particulier, le module de transfert 52 peut interroger et/ou amener le DCS 18 à vérifier que le statut de chacun d’un ou de plusieurs vols dans l’itinéraire perturbé permet à un quelconque passager enregistré d’être débarqué. Par exemple, si un ou plusieurs des passagers de la demande de transfert 54 ont déjà été enregistrés sur un des vols remplacés de l’itinéraire de voyage perturbé, le module de transfert 52 et/ou le DCS 18 peuvent vérifier que le statut de ce vol n’indique pas que le l’enregistrement pour le vol est finalisé. De façon similaire, le module de transfert 52 peut interroger et/ou amener le DCS 18 à vérifier que le statut de chacun d’un ou de plusieurs vols dans le nouvel itinéraire de voyage indique que le vol est ouvert à l’enregistrement et/ou n’est pas encore parti. Si le module de transfert 52 et/ou le DCS 18 sont incapables d’effectuer ces contrôles, te module de transfert 52 peut alors déterminer que la demande de transfert 54 est Invalide.

[0087] Le contrôle transversal des transporteurs pour le transfert peut inclure de vérifier que tout transfert entre transporteurs résultant du nouvel itinéraire de voyage est conforme à un accord de partenariat entre les transporteurs et/ou à des règles commerciales définies. En particulier, le module de transfert 52 peut interroger une base de données stockant les détails des accords de partenariat et/ou des règles commerciales pour vérifier que le transfert entre transporteurs est permis. Sinon, le module de transfert 52 peut alors déterminer que la demande de transfert 54 est invalide.

[0088] La contrôle de statut d’un transfert peut inclure de vérifier qu’il n’y a pas d’offre de transfert en cours pour un quelconque des passagers sélectionnés. Si le module de transfert 52 détermine qu’un autre transfert est en cours pour un ou plusieurs des passagers sélectionnés, il peut déterminer que l’intégralité de la demande de transfert 54 est invalide. Autrement, le module de transfert 52 peut déterminer que la demande de transfert 54 est invalide pour les passagers pour lesquels un transfert est déjà en cours, mais pas pour les autres passagers sélectionnés.

[0089] La contrôle de type de passager et de statut de réservation peut inclure de vérifier que chaque passager est éligible à un transfert sur la base du statut de réservation et de type de passager. Par exemple, des règles commerciales et des réglementations peuvent empêcher le transfert d’un nourrisson non accompagné. Ainsi, si la demande de transfert 54 implique le transfert d’un nourrisson voyageant seul, le module de transfert 52 peut alors déterminer que la demande de transfert 54 est invalide. Comme autre exemple, des règles commerciales et des réglementations peuvent indiquer que lorsque la réservation d’un passager est annulée par un agent de voyage, le passager ne peut pas être transféré sur un itinéraire de voyage par un agent DCS via le DCS 18. Ainsi si la demande de transfert 54 implique une telle situation, le module de transfert 52 peut déterminer que la demande de transfert 54 est invalide.

[0090] La contrôle d’horaire peut inclure de vérifier la validité d’un ou de plusieurs vols indiqués dans la demande de transfert 54, tels que les nouveaux vols du nouvel itinéraire de voyage. En particulier, le module de transfert 52 et/ou le système d’inventaire 14 peuvent être configurés pour vérifier ledit ou plusieurs vols identifiés dans la demande de transfert 54 par comparaison avec les données d’horaires dans la base de données d’inventaire 60. S’il existe une incohérence, le module de transfert 52 et/ou le système d’inventaire 14 peuvent déterminer que la demande de transfert 54 est invalide.

[0091 ] En réponse à Indétermination que toute ou une partie d’une demande de transfert 54 est déterminée être invalide (branche «Non » du bloc 104), par exemple en raison d’un échec relatif à l’un des contrôles décrits ci-dessus, une notification d’erreur peut alors être générée au bloc 106 et présentée à l’agent demandeur dans le rapport de transfert 56. La notification d’erreur peut inclure une raison pour l’invalidité, telle qu'une indication de l'échec du contrôle de la demande de transfert 54 ou d’un passager de la demande de transfert 54, Dans certains modes de réalisation, si la demande de transfert 54 est jugée invalide par rapport à un quelconque des passagers, le processus 100 peut être entièrement interrompu. Dans d’autres modes de réalisation, le processus 100 peut continuer uniquement pour le compte des passagers pour lesquels la demande de transfert 54 est valide, peimettant ainsi au processus 100 de continuer en dépit de l’occurrence d’une erreur d’invalidité, [0092] En réponse à la détermination que toute ou une partie de la demande de transfert 54 est déterminée être valide (branche « Oui » du bloc 108), un ou plusieurs des vols de la demande de transfert 54, tels que les vols remplacés et/ou les nouveaux vols, peuvent être verrouillés par rapport à d’autres processus. En particulier, le module de transfert 52 peut appeler et/ou amener le système d’inventaire 14, et/ou un ou plusieurs autres systèmes de l’environnement d’exploitation 10 à empêcher qu’un ou plusieurs des vols impliqués soient affectés par un processus conflictuel externe au processus 100, De cette façon, les conflits entre le processus 100 et d’autres processus tels qu’un changement d’horaire ou un déclenchement automatique de liste d’attente impliquant un ou plusieurs des vols indiqués puissent être évités. Ces verrouillages peuvent être enlevés après l’achèvement du processus 100 ou après qu’au moins certains des sous-processus suivants du processus 100 aient été achevés (p. ex. après la fin de l’actualisation des bases de données de réservation et d’inventaire).

[0093] Plus particulièrement, en raison de la nature intégrée et des rôles divers des systèmes de l’environnement d’exploitation 10, plusieurs processus différents pouvant être initiés par des systèmes différents de l’environnement d’exploitation 10 peuvent affecter un ou plusieurs des vols impliqués par la demande de transfert 54, Ainsi, l’exécution de ces processus parallèlement au processus 100 peut nuire à l’intégrité des données stockées sur un ou plusieurs des systèmes de l’environnement d’exploitation 10 et/ou dans les bases de données de l’architecture de traitement 50, ce qui peut en retour amener un ou plusieurs des systèmes et/ou des bases de données à cesser de fonctionner, ou dans le pire des cas à un effondrement total (crash). Le verrouillage, tôt dans le processus 100, d’un ou plusieurs des vols impliqués par la demande de transfert 54 contre des processus conflictuels, par exemple avant que le processus 10 ne soit configuré pour effectuer des changements aux données relatives aux vols Indiqués dans un ou plusieurs des systèmes de l’environnement d’exploitation 10 et/ou dans les bases de données de l’architecture de traitement 50, réduit ainsi la probabilité que ces problèmes surviennent. Par conséquent, ces verrouillages améliorent l’intégrité et la stabilité des systèmes dans l’environnement d’exploitation 10 et pour les bases de données de l’architecture de traitement 50.

[0094] Après le verrouillage d’un ou de plusieurs des vols indiqués, au bloc î 10, les données dans la demande de transfert 54 peuvent faire l’objet d’un traitement préliminaire. Le module de transfert 52 peut, en particulier, analyser les vols de chaque itinéraire de voyage perturbé et le nouvel itinéraire de voyage pour déterminer les relations entre les vols de chaque itinéraire de voyage et/ou effectuer des changements à un ou à plusieurs des vols du nouvel itinéraire de voyage selon les préférences de la compagnie aérienne qui effectue le transfert. Bien que le bloc 110 illustre un mode de réalisation survenant après la détermination de la validation au bloc 104 et te verrouillage du vol au bloc 108, dans d’autres modes de réalisation, le bloc 110 peut se dérouler avant et/ou, au moins en partie, parallèlement au bloc 104 et/ou au bloc 108.

[0095] Dans certain mode de réalisation, le bloc 110 peut inclure de faire un appariement,

DE — À, entre les vols remplacés dans un itinéraire de voyage perturbé et les nouveaux vols dans le nouvel itinéraire de voyage. En particulier, le module de transfert 52 peut apparier chaque nouveau vol dans le nouvel itinéraire de voyage à un vol dans l’itinéraire de voyage perturbé qui est remplacé par le nouveau vol. Si un vol de l’itinéraire de voyage perturbé est remplacé par de multiples vols dans un nouvel itinéraire de voyage, chacun des multiples vols peut alors être apparié au même vol dans l’itinéraire de voyage perturbé.

[0096] Lors d’une réservation et/ou d’un transfert d’un passager sur un nouveau vol, l’appariement DE — À peut permettre au module de transfert 52 d’utiliser les données stockées pour le passager en relation avec le vol de l’itinéraire de voyage perturbé qui est apparié au nouveau vol. Ainsi, au lieu qu’il soit nécessaire pour un agent de ressaisir manuellement certains éléments de données pour chaque passager transféré, ce qui est courant avec les systèmes conventionnels, peut retarder le processus de transfert et augmenter l’occurrence d’erreurs, le module de transfert 52 peut être configuré pour copier et utiliser automatiquement les données déjà stockées pour chaque passager. Par conséquent, ledit ou plusieurs des systèmes informatiques qui effectuent le transfert sont capables de réaliser des temps de réponse plus rapides entre le moment auquel un agent déclenché un transfert de passagers et le moment ou le transfert est achevé. En outre, ledit ou plusieurs des systèmes informatiques sont capables d’obtenir des résultats améliorés, car la probabilité d’erreurs pendant le transfert des passagers est réduite. Des exemples non limitatifs de données stockées antérieurement pour un passager qui peuvent être utilisées par le module de transfert 52 dans le processus de transfert 100 incluent tout statut spécial appliqué aux passagers, la classe de réservation précédente du passager, la date de création de la réservation d’origine du passager. le point de vente de la réservation d’origine, les demandes de services dans la réservation d’origine et la préférence de siège du passager, chacune de ces préférences pouvant faire partie de l’enregistrement de réservation pour le passager qui stocké dans la base de données d’enregistrements de réservation 58. Le module de transfert 52 peut aussi utiliser l’information dans les enregistrements DCS du passager (enregistrements de sauvegarde) relatifs à l’itinéraire de voyage perturbé qui sont stockés dans la base de données DCS 66, telle que les détails d’enregistrement précédent du passager, et peut utiliser les e-bîllets et les coupons EMD stockés pour le passager dans la base de données e-billet 62 et la base de données de coupon 64, respectivement.

[0097] Le module de transfert 52 peut être configuré pour construire l’appariement DE — À de la façon suivante. Si un seul vol de l’itméraîre de voyage perturbé est remplacé, le module de transfert 52 peut alors apparier chaque nouveau vol dans le nouvel itinéraire de voyage au vol remplacé dans l’itinéraire de voyage perturbé. Si plus d’un vol dans l’itinéraire de voyage perturbé est remplacé, le modulé de transfert 52 peut alors rechercher et apparier des sous-routes similaires entre les vols remplacés et les nouveaux vols. Cette recherche peut être basée sur une ou plusieurs règles commerciales qui peuvent être définies par la compagnie aérienne qui effectue le transfert. Par exemple, une règle commerciale peut dicter que la recherche soit effectuée au niveau d’un aéroport. Dans ce cas, le module de transfert 52 peut rechercher et apparier un vol remplacé ou une séquence de vols remplacés et un nouveau vol ou une séquence de nouveaux vols qui partent du même aéroport et arrivent au même aéroport. Autrement, la règle commerciale peut dicter que la recherche soit effectuée au niveau de la ville ou au niveau du pays. Dans ces cas, le module de transfert 52 peut rechercher et apparier un vol remplacé ou une séquence de vols remplacés et un nouveau vol ou une séquence de nouveaux vols qui partent de la même ville ou du même pays, respectivement, et araive à la même ville ou au même pays respectivement.

[0098J Une fois que les sous-routes sont appariées, le module de transfert 52 peut identifier un vol principal pour chaque sous-route dans une paire. Dans certains modes de réalisation, le vol principal pour une séquence de vols donnée peut être le vol international ou le vol le plus long en temps de vol écoulé. Par la suite, pour chaque paire de sous-routes, le module de transfert 52 peut apparier le vol principal de la sous-route du nouveau vol au vol principal de la sous-route du vol remplacé. Une fois que les vols principaux sont appariés pour une paire de sous-routes, les vols récepteurs et fournisseurs de la nouvelle sous-route de vol dans la paire peuvent être appariés respectivement aux vols fournisseurs et récepteurs dans la sous-route du vol remplacé dans la paire. Pour une sous-route donnée, les vols fournisseurs peuvent être des vols avant le vol principal et les vols récepteurs peuvent être des vois après le vol principal. Si une nouvelle sous-route de vol d’une paire donnée inclut des vols fournisseurs et que la sous-route du vol remplacé de la paire n’en inclut pas, les vols fournisseurs de la nouvelle sous-route de vol peuvent alors vraisemblablement être appariés avec le vol principal de la sous-route du vol remplacé. La même règle peut aussi être appliquée pour l’appariement de vols récepteurs d’une nouvelle sous-route de vol aux vols d’une sous-route de vols remplacés.

[0099] En plus de la construction d’un appariement DE— À, le bloc 110 peut inclure la transformation d’un ou de plusieurs des nouveaux vols indiqués dans la demande de transfert 54» En particulier, certains vols peuvent être exploités par une compagnie aérienne, mats être vendus avec de multiples numéros de vols, chacun d’eux étant associé à une compagnie aérienne différente.

Cette situation peut survenir lorsqu’un accord de partenariat permet à une compagnie aérienne de vendre des sièges sur un vol exploité par une autre compagnie aérienne. Ainsi, pour chaque nouveau vol d’un nouvel itinéraire de voyage, le module de transfert 52 peut déterminer si le numéro de vol soumis dans la demande de transfert 54 pour le nouveau vol est associé avec la même compagnie aérienne que le numéro de vol du vol remplacé apparié au nouveau vol. Sinon, le module de transfert 52 peut alors déterminer s’il existe un numéro de vol disponible, associé à la même compagnie aérienne du vol remplacé, pour le nouveau vol. Si tel est le cas, le module de transfert 52 peut convertir le numéro de vol du nouveau vol au numéro de vol associé à la même compagnie aérienne du vol remplacé et utiliser le numéro de vol converti pour la réservation du passager sur le nouveau vol. De cette façon et dans la mesure du possible, les passagers sont transférés à partir des vols et sur des vols de la même compagnie aérienne ce qui permet à la compagnie aérienne de retenir les passagers transférés comme clients ainsi que les recettes afférentes.

[0100] Par exemple, un vol de Nice à Paris peut être associé un numéro de vol XI de la compagnie aérienne exploitante et un numéro de vol Y1 de la compagnie aérienne vendeuse. Un passager peut être réservé sur ce vol sous le numéro de vol XI et un autre passager peut être réservé sur ce vol sous le numéro de vol YL Si ce vol subît une perturbation et que ces passagers sont transférés, un agent peut sélectionner les passagers des deux vols pour les transférer sur un autre vol associé un numéro de vol X2 de la compagnie aérienne exploitante. Ce vol peut aussi être associé à un numéro de vol Y2 pour la compagnie aérienne vendeuse. Ainsi, en réponse à la réception d’une demande de transfert 54, le module de transfert 52 peut convertir le numéro de vol X2 au numéro de vol Y2 pour le passager réservé à l’origine sous le numéro de vol Y1. Cependant, pour l’autre passager le module de transfert 52 peut procéder avec le numéro de vol X2 puisqu’il a été réservé à l’origine sous XI.

[0101] Après le traitement préliminaire du bloc 110, la base de données d’inventaire 60 peut être actualisée au bloc 112 sur la base de la demande de transfert 54, ou plus spécifiquement du nouvel itinéraire de voyage et/ou de Γ itinéraire de voyage perturbé de chaque passager. En particulier, le module de transfert 52 peut appeler et/ou amener le système d’inventaire 14 à actualiser un compteur de disponibilité pour chaque nouveau vol dans le nouvel itinéraire de voyage et pour chaque vol remplacé dans Γ itinéraire de voyage perturbé. Le module de transfert 52 et/ou le système d’inventaire 14 peuvent incrémenter un compteur de disponibilité d’un produit de voyage, dans la base de données d’inventaire 60, associé à chaque nouveau vol et/ou peuvent diminuer un compteur de disponibilité d’un produit de voyage, stocké dans la base de données d’inventaire 60, pour chaque vol remplacé. Par exemple, lorsque la demande de transfert 54 consiste à ajouter un ou plusieurs nouveaux vols à l’itinéraire de voyage d’un passager sans annuler ou modifier un quelconque vol existant, le module de transfert 52 peut appeler et/ou amener le système d’inventaire 14 à incrémenter un compteur de disponibilité de produit de voyage uniquement pour chaque nouveau vol. Comme autre exemple, lorsque la demande de transfert 54 consiste à remplacer des vols et à ajouter des nouveaux vols, le module de transfert 52 peut appeler et/ou amener le système d’inventaire 14 à décrémenter un compteur de disponibilité de produit de voyage associé à chaque vol remplacé et à incrémenter un compteur de disponibilité de produit de voyage associé à chaque nouveau vol. Le compteur de disponibilité de produit de voyage qui est incrémenté ou décrémenté pour un vol donné peut dépendre de la classe de réservation pour laquelle le vol a été réservé. En particulier et comme décrit ci-dessus, un vol donné peut être associé à plusieurs compteurs de disponibilité de produit de voyage, chacun étant pour une classe de réservation différente pour le vol.

[0102] Lons de la mise à jour de la disponibilité sur la base de la demande de transfert 54, le module de transfert 52 et/ou le système d’inventaire 14 peuvent aussi mettre à jour les compteurs des services auxiliaires associés à chaque vol remplacé et chaque nouveau vol. En particulier, pour chaque passager et pour chaque nouveau vol dans la demande de transfert 54. le module de transfert 52 et/ou le système d’inventaire 14 peuvent déterminer si l’enregistrement de réservation du passager stocké dans la base de données d’enregistrement de réservation 58 inclut un service auxiliaire, par exemple dans un élément de données SSR» associé au vol remplacé et apparié au nouveau vol. Dans ce cas, le module de transfert 52 et/ou le système d’inventaire 14 peuvent vérifier si îe service auxiliaire est disponible sur le nouveau vol, par exemple sur la base du nombre total d’unités disponibles pour le service auxiliaire qui sont stockées pour le nouveau vol dans la base de données d’inventaire 60 et sur la base du compteur stocké dans la base de données d’inventaire 60 qui suit le nombre d’unités du service auxiliaire qui ont été réservées pour le nouveau vol Si une comparaison entre les deux indique que le compteur est au moins égal au nombre total d’unités disponibles, le service auxiliaire ne peut alors pas être réservé pour le nouveau vol et îe rapport de transfert 56 peut être actualisé pour indiquer que le service auxiliaire ne sera pas réservé à nouveau sur le nouveau vol. Autrement si la comparaison indique que le compteur est en dessous du nombre total d’unités réservées, le compteur associé au service auxiliaire peut alors être incrémenté.

[0103] Pour des raisons de performance, toutes les mises à jour dans le système d’inventaire 14 peuvent être effectuées en une seule transaction. En d’autres termes, le module de transfert 52 peut placer un seul appel ou fournir une seule demande au système d’inventaire 14 pour tous les passagers et/ou les produits de voyage impliqués dans le transfert, et en réponse, le système d’inventaire 14 peut actualiser les compteurs d’inventaire sur la base de l’appel ou de la demande. Par exemple, la requête unique peut inclure au moins une portion de l’itinéraire de voyage perturbé de chaque passager (p. ex. au moins les vols remplacés) et au moins une portion du nouvel itinéraire de voyage (p. ex. au moins les nouveaux vois) et le système d’inventaire peut actualiser les compteurs sur cette base. De cette façon, tes systèmes qui implémentent le processus 100 sont capables de réaliser des temps de réponse plus rapides que par le biais d’appels ou de demandes émis séparément au système d’inventaire 14 pour chaque produit de voyage et/ou passager impliqué par la demande de transfert 54 qui réduisent la vitesse à laquelle le bloc 112. est complété. De plus, le recours à un appel ou une demande unique pour tous les passagers et/ou les produits de voyage impliqués par la demande de transfert 54 permet aussi d’actualiser en parallèle les compteurs dans la base de données d’inventaire 60, ce qui améliore encore la vitesse à laquelle les systèmes sont capables de réaliser le processus 100. De surcroît, parce que chaque demande ou appel provenant du module de transfert 52 nécessite généralement l’utilisation de ressources informatiques additionnelles par un ou plusieurs des systèmes de l’environnement d’exploitation 10, le fait de recourir à un seul appel ou demande pour tous les produits de voyage et/ou passagers impliqués permet au processus 100 de réaliser des économies de ressources informatiques.

[0104] Parce que le processus de transfert 100 ne peut pas empêcher les transactions de vente normales, il est généralement souhaitable d’actualiser la base de données d’inventaire 60 dès que possible pour refléter correctement la disponibilité de chaque produit de voyage et service auxiliaire affecté par le transfert. Par conséquent, dans le mode de réalisation illustré, la mise à jour de la base de données d’inventaire 60 survient immédiatement après ie traitement préliminaire du bloc 110 qui peut être un précurseur nécessaire à l’actualisation de la base de données d’inventaire 60 (p. ex. l’appariement DE — Λ peut être utilisé pour mettre à jour la base de données d’inventaire 60). De cette façon, en supposant qu’il n’y ait pas d’erreur causée par une interruption ou un échec complet du processus de transfert 100, la base de données d’inventaire 60 peut être actualisée dès que possible afin d’empêcher une surréservation et une sous-réservation des produits de voyage et des services auxiliaires affectés par le transfert.

[0105] L’actualisation de la base de données d’inventaire 60 peut aussi inclure la nouvelle attribution de sièges aux passagers sur les nouveaux vols. En particulier, un nouveau siège peut être attribué à chaque passager pour chaque nouveau vol. En général, le processus d’attribution de nouveaux sièges peut prendre en compte la valeur ou le statut du passager, donnant priorité aux préférences des passagers de la demande de transfert 54 ayant une valeur ou un statut plus élevé.

Dans le cas de l’attribution de siège à un passager qui avait précédemment réservé un siège amélioré payant, le processus d’attribution de siège peut tenter de trouver un siège équivalent au siège précédemment réservé sur le nouveau vol en fonction des caractéristiques du siège acheté (p. ex. l’emplacement et les aménagements) et des paramètres définis par la compagnie aérienne (l’emplacement prévaut sur les aménagements, ou vice versa).

[0106] Le bloc 112 peut être contourné dans certaines situations. Par exemple, lorsque la demande de transfert 54 inclut simplement des changements d’horaire d’un ou de plusieurs vols dans l’itinéraire de voyage perturbé, la base d’inventaire 60 n’apas besoin d’une mise à jour. Comme autre exemple, lorsque la demande de transfert pertinente 54 inclut des vols, qu'ils soient nouveaux ou remplacés, qui ne sont pas gérés par le système d’inventaire 14 et/ou le système de réservation 12 (p. ex. les vols gérés au sol, les vols externes) les compteurs d’inventaire, ne sont généralement pas accessibles au module de transfert 52 et/ou au système d’inventaire 14 pouf une manipulation et l’opération de mise à jour peut donc être contournée pour ces vols.

[0107] Dans le bloc 114, la base de données d’enregistrement de réservation 58 peut être actualisée sur la base de la demande de transfert 54 ou plus spécifiquement sur au moins une portion du nouvel itinéraire de voyage de la demande de transfert 54, telle que les nouveaux vols.

En particulier, le module de transfert 52 peut appeler et/ou amener le système de réservation 12 à actualiser ledit ou plusieurs enregistrements de réservation stockés dans la base de données d’enregistrement de réservation 58 pour indiquer une association entre chaque passager sélectionné et le nouvel itinéraire de voyage. Cette actualisation peut entraîner la génération d’un ou de plusieurs nouveaux enregistrements de réservation dans la base de données d’enregistrement de réservation 58 incluant une identification et une association entre au moins un des passagers et le nouvel itinéraire de voyage et/ou la modification d'un ou de plusieurs enregistrements existants de réservation affectés par la demande de transfert 54 dans la base de données d’enregistrement de réservation 58. Par exemple, la modification d’un ou de plusieurs enregistrements de réservation existants peut inclure l’annulation de l’itinéraire de voyage perturbé dans chacun des enregistrements de réservation existants en retirant l’itinéraire de voyage perturbé ou en indiquant une annulation de l’itinéraire de voyage perturbé dans l’enregistrement de réservation. En outre, la modification peut inclure l’insertion d’une indication et l’association entre chacun des passagers sélectionnés des enregistrements de réservation existants et le nouvel Itinéraire de voyage dans les enregistrements de réservation existants. Après la mise à jour, la base de données d’enregistrement de réservation 58 peut inclure un enregistrement de réservation pour chaque passager transféré qui inclut le nouvel itinéraire de voyage. Les enregistrements de réservation existants qui ont été actualisés pour inclure le nouvel itinéraire de voyage peuvent aussi inclure une histoire, telle que l’histoire du PNR décrite ci-dessus qui contient des détails relatifs à l’itinéraire de voyage perturbé. [Q108J Dans le mode de réalisation illustré, l’actualisation de la base de données d’enregistrement de réservation 58 survient après que la base de données d’inventaire 60 a été mise à jour sur la base de la demande de transfert 54. Pendant que les enregistrements de réservation sont actualisés, le module de transfert 52 et/ou le système de réservation 12 peuvent surveiller les enregistrements de réservation pour détecter des incohérences dans la base de données d’inventaire 60 par rapport à la base de données d’enregistrement de réservation 58. Par exemple, lorsque le module de transfert 52 et/ou le système de réservation 12 sont incapables de réserver un passager sur un vol du nouvel itinéraire de voyage ou sont incapables d’appliquer à nouveau les services auxiliaires au nouvel itinéraire de voyage, en dépit de leur disponibilité, il est alors possible que les compteurs dans la base de données d’inventaire 60 reflètent un nombre incorrect de produits de voyage ou de services auxiliaires relatifs à un vol donné. Par conséquent lorsqu’une incohérence est déterminée, le module de transfert 52 peut initier un processus de rétrogression pour signaler l’incohérence au système d’inventaire 14 qui peut alors annuler les changements relatifs à l’incohérence qui ont eu lieu précédemment dans la base de données d’inventaire 60. De cette façon, après l'achèvement du bloc 114, la base de données d’inventaire 60 et la base de données d’enregistrement de réservation 58 peuvent être dans un état synchronisé.

[0109] Pendant le processus d’actualisation d’enregistrement de réservation au bloc 114, le module de transfert 52 peut fournir l’appariement DE —· À déterminé au bloc 110 afin de l’inclure dans les enregistrements de réservation actualisés ou nouveaux, par exemple dans un élément dédié étiqueté « PIM » (PNR Itinerary Matching). Le système de réservation et/ou le module de transfert 52 peuvent utiliser l’appariement DE — À pour réappliquer les détails d’un passager sur les nouveaux vols, y compris ses services auxiliaires et ses préférences. Par exemple, un passager peut être réservé initialement sur un itinéraire de voyage comprenant deux vols incluant XI Nice à

Paris et Y2 Paris à New York. Si i’itinéraire de voyage subit une perturbation, un agent peut alors émettre une demande de transfert 54 qui inclut deux nouveaux vols pour remplacer les anciens vols, notamment X3 Nice à Londres et Y4 Londres à New York. Si l’appariement DE — À apparie X3 à XI et Y4 à Y2, alors au cours de la création ou de la mise à jour d’un enregistrement de réservation pour le passager et en supposant qu’il y ait une disponibilité pour les services auxiliaires réservés précédemment pour îepassager sur les nouveaux vols, le système de réservation 12 et/ou lemodule de transfert 52 peuvent réappliquer les services réservés et les préférences pour le passager de XI à X3 et peuvent réappliquer les services réservés et les préférences pour le passager de Y2 â Y4. De cette façon et dans la mesure du possible, les préférences des passagers et les services auxiliaires réservés sont maintenus sur le nouvel itinéraire de voyage.

[0110] L’actualisation des enregistrements de réservation impliqués par la demande de transfert 54 peut procéder de la façon suivante. Pour chaque passager, le module de transfert 52 et/ou le système de réservation 12 peuvent rechercher les enregistrements de réservation stockés dans la base de données d’enregistrement de réservation 58 pour déterminer si un enregistrement de réservation (parfois désigné spécifiquement comme « PNR de distribution ») pour le passager transféré est disponible par rapport à l’itinéraire de voyage perturbé. Un tel enregistrement de réservation peut ne pas être disponible, par exemple si l’itinéraire de voyage perturbé a été réservé pour le passager par un système de réservation externe à P environnement d’exploitation 10, ce qui peut être le cas lorsque P itinéraire de voyage perturbé inclut des vols gérés au sol ou des vols à codes multiples (p. ex. des vols exploités par une compagnie aérienne utilisant le système de réservation 12, mais qui sont réservés par une compagnie aérienne vendeuse n’utilisant pas le système de réservation 12). Si l’enregistrement de réservation est disponible pour un passager donné, le module de transfert 52 peut alors appeler et/ou amener le système de réservation 12 à actualiser l’enregistrement de réservation sur la base du nouvel itinéraire de voyage. Sinon, le module de transfert 52 peut appeler et/ou amener le système de réservation 12 à créer une nouvelle réservation pour le passager incluant te nouvel itinéraire de voyage. Dans un cas comme dans l’autre, le module de transfert 52 et/ou le système de réservation 12 peuvent entrer un élément SSR5 CK1N associé au nouvel itinéraire de voyage dans le nouvel enregistrement de réservation ou dans renregistrement de réservation trouvé et actualisé avec le nouvel itinéraire de voyage incluant l’appariement DE — À déterminé ci-dessus.

[OUI] Dans certaines situations, seuls certains des passagers d’un enregistrement de réservation donné, stocké dans la base de données d’enregistrement de réservation 58, peuvent être impliqués par la demande de transfert 54, signifiant que seul un sous-ensemble des passagers inclus dans un enregistrement de réservation doit être réservé à nouveau sur le nouvel itinéraire de voyage. Dans ce cas, le module de transfert 52 et/ou le système de réservation 12 peuvent scinder l’enregistrement de réservation en deux ou plusieurs enregistrements de réservation enfants spécifiques aux passagers affectés. Par la suite, le module de transfert 52 et/ou le système de réservation 12 peuvent actualiser les enregistrements de réservation enfants, incluant les passagers affectés, avec le nouvel itinéraire de voyage. L’élément PIM de chaque enregistrement de réservation enfant peut être modifié pour stocker l’information relative à la scission, telle qu’une identification de l’enregistrement de réservation parent et/ou de chaque enregistrement de réservation enfant provenant de la scission de l’enregistrement de réservation parent.

[0112] Dans certains modes de réalisation, plutôt que d’actualiser la base de données d’inventaire 60 pour chaque passager avant que la base de données d’enregistrement de réservation 58 ne soit mise à jour, ces processus peuvent être effectués en parallèle pour chaque passager afin d’améliorer le temps de réponse du système. Par exemple, il est possible de déterminer si un ou plusieurs des passagers et/ou des services auxiliaires réservés des passagers peuvent être transférés ou réservés à nouveau sur les nouveaux vols du nouvel itinéraire de voyage, par exemple en interrogeant la base de données d’inventaire 60 pour obtenir les valeurs actuelles des compteurs pertinents. Si tel est le cas, le module de transfert 52 peut alors appeler et/ou amener le système de réservation 12 à réserver à nouveau en parallèle chacun des passagers et/ou leurs services auxiliaires sur les nouveaux vols. Ainsi, en réponse à la nouvelle réservation d’un passager et/ou d’un service auxiliaire sur un ou plusieurs des nouveaux vols, le module de transfert 52 peut appeler et/ou amener le système d’inventaire 14 à actualiser les compteurs dans la base de données d’inventaire 60 pour refléter les nouvelles réservations. En d’autres termes, les compteurs associés aux vols remplacés du passager qui est à nouveau réservé peuvent être décrémentés et les compteurs associés aux nouveaux vols du passager réservé peuvent être Incrémentês, De cette façon, les compteurs des nouveaux vols et des services auxiliaires dans la base de données d’inventaire 60 ne sont actualisés que lorsqu’un passager et/ou un service auxiliaire sont actuellement réservés sur le nouveau vol dans la base de données d’enregistrement de réservation 58, ce qui peut augmenter la précision et l’intégrité de la base de données d’inventaire 60 pendant le processus de transfert 100. De surcroît, en effectuant les opérations ci-dessus en parallèle pour chaque passager, le système n’est pas tenu d’attendre que chaque passager soit réservé à nouveau pour mettre en œuvre le processus d’actualisation de l’inventaire, ou vice versa, ce qui peut améliorer le temps de réponse du système.

[0113] Dans certains modes de réalisation, dès qu’un passager ou un service auxiliaire est réservé à nouveau sur un ou plusieurs des nouveaux vols, te module de transfert 52 et/ou le système de réservation 12 peuvent commencer à effectuer une nouvelle réservation pour un passager ou un service auxiliaire suivant, et le module de transfert 52 et/ou le système d’inventaire 14 peuvent commencer à actualiser les compteurs pour le passager ou le service auxiliaire précédent. De cette façon, la base de données d’inventaire 60 est actualisée en parallèle avec la base de données d⁵enregistrement de réservation 58, ce qui génère des temps de réponse améliorés pour les systèmes qui implémentent le processus 100, comparé à la mise à jour d’une des bases de données pour tous les passagers puis, une fois que cette actualisation est complète, la mise à jour des autres bases de données pour tous les passagers. Dans un autre mode de réalisation, chacun des passagers ou sousgroupes de passagers faisant l’objet d’une demande de transfert peut être traité parallèlement par le système d’inventaire 14 et le système de réservation 12 (c.-à-d. qu’une nouvelle réservation et actualisation de l’inventaire peuvent être effectués pour chaque passager ou sous-groupe de passagers de façon concomitante sans attendre la fin d’une mise à jour pour un passager ou sous25 groupe de passagers donné), ce qui peut améliorer encore plus les temps de réponse des systèmes qui implémentent le processus 100.

[0114] Dans certaines situations, les compteurs dans la base de données d’inventaire 60 peuvent indiquer qu’un ou plusieurs des passagers faisant f objet d’un transfert ne peuvent pas être transférés sur le nouvel itinéraire de voyage, ou qu’un ou plusieurs des services auxiliaires réservés ne peuvent pas être réappliqués sur le nouvel itinéraire de voyage. En réponse, le module de transfert 52, le système d’inventaire 14 et/ou le système de réservation 12 peuvent être configurés pour placer tous les passagers sur une liste d’attente pour le nouvel itinéraire de voyage et/ou ledit ou plusieurs des services auxiliaires. Autrement, le module de transfert 52, le système d’inventaire 14 et/ou le système de réservation 12 peuvent être configurés pour implémenter un processus permettant à autant de passagers et de services auxiliaires que possible d’être réservés à nouveau jusqu’à ce qu’il n’y est plus de disponibilité. Les passagers qui ne sont pas réservés à nouveau sur le nouvel itinéraire de voyage ne peuvent alors plus être gérés par le reste du processus 100. Dans le premier cas, en réponse au placement de passagers en liste d’attente, le module de transfert 52 peut actualiser le rapport de transfert 56 pour indiquer le statut des passagers en liste d’attente. Dans le deuxième cas, le module de transfert 52 peut actualiser le rapport de transfert 56 pour indiquer les passagers qui ne peuvent pas être réservés à nouveau et ne pourront donc pas être transférés, [0115] Après l’actualisation de la base de données d’enregistrement de réservation 58 et de la base de données d’inventaire 60, dans le bloc 116, les passagers inclus dans la demande de transfert 54 qui ont été réservés à nouveau avec succès et qui ont déjà été enregistrés sur les vols remplacés de Γitinéraire de voyage perturbé peuvent être débarqués des vols remplacés.

Spécifiquement, le module de transfert 52 peut appeler et/ou amener le DCS 18 à débarquer chaque passager enregistré. Autrement, le système de réservation 12 peut automatiquement générer et transmettre un ou plusieurs messages correspondants aux DCS 18 lorsque les passagers ont une nouvelle réservation, informant le DCS 18 des nouvelles réservations ou, plus particulièrement, que les passagers réservés à nouveau ne sont plus réservés sur les vols remplacés, lequel peut en réponse être configuré pour débarquer automatiquement les passagers réservés à nouveau des vols remplacés. Spécifiquement, les messages correspondants peuvent indiquer T itinéraire de voyage précédent ou les vols remplacés de chaque passager, le nouvel itinéraire ou les nouveaux vols de chaque passager et/ou l’appariement DE — À décrit précédemment qui peut être stocké et utilisé plus tard par le DCS 18 pour le processus de transfert de données DCS. Le débarquement d’un passager d’un vol donné amène à un changement du statut de l’e-billet et des coupons EMD du passager qui devient « ouvert » pour ce vol. Par exemple, lorsqu’un passager est débarqué d’un vol, le coupon inclus dans 1 ’e-bîllet du passager pour ce vol peut passer à un statut « ouvert ». En général, chaque e-billet et coupons EMD d’un passager transféré, associé aux vols remplacés, nécessite un statut ouvert par rapport aux vols remplacés pour permettre l’aboutissement de la portion billetterie du processus 100, décrite de façon plus détaillée ci-dessous, [0116] Dans certains modes de réalisation, le module de transfert 52 et/ou le DCS 18 peuvent être configurés pour débarquer des passagers enregistrés du premier vol remplacé dans l’itinéraire de voyage perturbé qui est hébergé par le DCS 18, puis de tous les vols remplaces suivants, incluant des vols externes (p. ex. via des messages envoyés aux systèmes externes pertinents). Par exemple, un passager qui a besoin d’être transféré peut initialement être réservé sur un itinéraire de voyage perturbé incluant les vols XI et Y1, dans lequel XI est hébergé par le DCS

18 et Y1 est externe au DCS 18, mais disponible pour enregistrement sur le DCS 18 en utilisant l’enregistrement à destination finale (through check-in), Si XI est planifié avant Y1 et que XI et Y1 sont tous deux remplacés dans un nouvel itinéraire de voyage, le module de transfert 52 et/ou le DCS 18 peuvent alors débarquer les passagers des deux vols XI et Y1. Autrement, si YI est planifié avant XI, et que les deux vols XI et Y1 sont remplacés, le module de transfert 52 et/ou le

DCS 18 peuvent alors débarquer le passager uniquement du vol XI. Comme autre possibilité, si XI est programmé avant Y1 et que seul Y1 est remplacé, le module de transfert 52 et/ou le DCS 18 ne peuvent alors effectuer aucune opération de débarquement.

[0117] Dans le bloc 118, une ou plusieurs des opérations automatisées de billetterie peuvent être effectuées pour les passagers débarqués et/ou réservés à nouveau. Spécifiquement, le module de transfert 52 peut appeler le système billettîque 16 pour traiter automatiquement les e-billeîs et les coupons EMD des passagers pour le nouvel itinéraire. Le module de transfert 52 et/ou le système billettîque 16 peuvent échanger et revalider chaque e-billet. Par la suite, le module de transfert 52 et/ou le système billettîque 16 peuvent dissocier, réassoeler ou échanger les coupons EMD. Les opérations particulières du bloc 116 sont discutées de façon plus détaillée en référence à la FIG 5.

[0118] Dans le bloc 120, un transfert de données DCS peut être initié pour que la base de données DCS 66 soit actualisée pour refléter le nouvel itinéraire de voyage de chaque passager détenant une nouvelle réservation. En particulier, après l’achèvement du processus de nouvelle réservation et du processus de billetterie, le module de transfert 52 et/ou le système de réservation 12 peuvent envoyer des données relatives aux processus de nouvelle réservation et de billetterie au DCS 18 afin de déclencher le processus de transfert de données du DCS. Les données de déclenchement peuvent indiquer les passagers transférés, l ’ itinéraire de voyage perturbé et/ou les vols remplacés pour chaque passager, le nouvel itinéraire de voyage et/ou un quelconque service auxiliaire réservé à nouveau. De plus, les données de déclenchement peuvent inclure un ID de transaction de transfert, un identifiant unique pour chaque passager, le cas échéant, les échecs de réservation, les identifiants d’e-billet et/ou les identifiants de coupon EMD, et/ou les erreurs de billetterie le cas échéant. Pendant que le DCS 18 traite les données de déclenchement, le module de transfert 52 peut mettre à jour le rapport de transfert 56 pour afficher un nouveau statut de transfert pour chaque passager (p. ex. transfert de données DCS en cours de traitement).

[0119] En réponse à la réception des données de déclenchement ci-dessus, le module de transfert 52 et/ou le DCS 18 peuvent déterminer si le nouvel itinéraire de voyage inclut un ou plusieurs nouveaux vols, et dans ce cas si ces vois sont hébergés par le DCS 18 ou sont externes. Si le premier nouveau vol dans le nouvel itinéraire de voyage est externe au DCS 18. on peut considérer que le transfert est achevé, car le DCS 18 ne peut pas être responsable de la gestion des opérations aéroportuaires pour ce vol. Sinon, le module de transfert 52 et/ou le DCS 18 peuvent alors, pour chaque nouveau vol hébergé par le DCS 18, initier un transfert de données DCS.

[0120] Comme décrit précédemment, lorsqu’un ou plusieurs passagers sont réservés à nouveau à partir de, ou vers des vols qui sont ouverts dans le DCS 18, le système de réservation 12 peut être configuré pour envoyer un PNL ou ADL au DCS 18, ce qui peut déclencher une mise à jour par le DCS 18 des enregistrements DCS dans la base de données DCS 66 sur la base de l’information incluse dans le PNL ou l’ADL. Par exemple, à la réception d’un PNL ou d’un ADL après la nouvelle réservation, le DCS 18 peut être configuré pour générer un ou plusieurs enregistrements DCS associés à un ou plusieurs vols dans le nouvel itinéraire qui incluent les passagers détenant une nouvelle réservation. Occasionnellement, les données de déclenchement décrites ci-dessus peuvent être reçues avant le PNL ou l’ADL, et dans ce cas, la base de données DCS 66 peut ne pas encore inclure les enregistrements DCS, du nouvel itinéraire de voyage incluant les passagers vers lesquels les données doivent être transférées. Dans ce cas, le module de transfert 52 et/ou le DCS 18 peuvent être configurés pour réessayer automatiquement d’initier le transfert de données DCS après un délai prédéterminé et/ou après la réception d’un PNL et/ou d’un ADL.

[0121] Dans certains modes de réalisation, les données de déclenchement peuvent être reçues avant l’ouverture dans le DCS 18 de tous les vols hébergés du nouvel itinéraire de voyage. Dans cette situation, le module de transfert 52 et/ou le DCS 18 peuvent attendre que chaque vol du nouvel itinéraire de voyage, exploité par une compagnie aérienne particulière parmi les autres (désignée dans les présentes comme la « compagnie aérienne premium »), soit ouvert dans le DCS 18. Par exemple, la compagnie aérienne premium peut être la compagnie aérienne associée au premier nouveau vol du nouvel itinéraire de voyage et le module de transfert 52 et/ou le DCS 18 peuvent attendre jusqu’à ce que chaque nouveau vol associé à la compagnie aérienne premium soit ouvert dans le DCS 18 avant que le transfert de données soit initié. Pour les nouveaux vols qui ne sont pas associés à la compagnie aérienne premium et qui n’ont pas encore été ouverts dans le DCS 18 quand le transfert de données est actuellement initié, on peut généralement supposer que les données de passager, telles que l’information de bagage et le statut d’acceptation, seront ajoutées à l’enregistrement DCS pour ces vols au cours d’un enregistrement déclenché manuellement par un agent, [0122] Quel que soit le cas, en réponse à l’initiation d’un processus de transfert de données

DCS pour un ou plusieurs passagers, le module de transfert 52 et/ou le DCS 18 peuvent, pour chaque passager, copier ou transférer la donnée de passager, relative à l’itinéraire de voyage perturbé, stockée pour le passager par exemple dans des enregistrements de sauvegarde ou dans des enregistrements DCS associés à l’itinéraire de voyage perturbé dans la base de données DCS 66.

vers des enregistrements DCS pour le passager inclus dans la base de données DCS 66 qui sont associés dans la base de données DCS 66 au nouvel itinéraire de voyage, ou plus particulièrement aux nouveaux vois du nouvel itinéraire de voyage. Certaines sinon toutes ces données transférées peuvent être absentes des enregistrements de réservation pour les passagers, et par conséquent, peuvent être absentes d’un PNL ou d’un ADL fourni par te DCS 18 après la nou velle réservation des passagers. Par exemple, alors que des changements pour des demandes de services spéciaux (SSR) relatives à des services achetés ou demandés par un passager peuvent être stockés dans les enregistrements de réservation et être reçus par le DGS 18 via un PNL ou ADL, certaines données réglementaires (p. ex. les numéros de passeport, les données APIS) peuvent être absentes. Par conséquent le processus de transfert de données DCS aide à atténuer la perte de ces données.

[0123] La source spécifique de données à partir de laquelle une donnée de passager est copiée ou transférée vers chaque enregistrement DCS associé au nouvel itinéraire de voyage, peut être affinée par les diverses compagnies aériennes, ou peut être basée sur l’appariement DE — À déterminé ci-dessus. Plus particulièrement, pour un enregistrement DCS associé à un nouveau vol d’un nouvel itinéraire de voyage, pour un passager donné, certaines données de passager peuvent être copiées ou transférées à partir de l’enregistrement de sauvegarde ou de l’enregistrement DCS du passager associé au vol remplacé qui est apparié au nouveau vol, alors que d’autres données peuvent être copiées ou transférées d’une autre source, La source de données peut dépendre largement du type de donnée qui est copiée ou transférée. Le tableau I illustre un mappage exemplaire de types de donnée et des sources de données pour le transfert de données DCS relatif à chaque nouveau vol pour chaque passager. Le module de transfert 52 et/ou le DCS 18 peuvent utiliser le tableau I par défaut en l’absence de règles particulières d’une compagnie aérienne.

TABLEAU 1
Type de donnée	Source
Nationalité	Vol mappé de l’appariement DE — À
Pays	Vol mappé de l’appariement DE — À
Indicateur de doc. valide	Vol mappé de l’appariement DE — À
Dérogation de bagage	Vol mappé de l’appariement DE — À
Indicateur de visa de transit	Vol mappé de l’appariement DE — À
Donnée manuelle du sélectionné	Vol mappé de l’appariement DE — À
Lieu de naissance	Vol mappé de l’appariement DE — À
Nombre de transferts (pour processus d’autotransfert)	Vol mappé de l’appariement DE — À
Heure d’acceptation	Vol mappé de l’appariement DE — À
Données règlementaires (p. ex., numéro de passeport)	Vol mappé de l’appariement DE — À
Système d’avance d’information de passager (ÂPIS)/Traitement avancé de passager (APP)/lnterrogatton rapide des données de ΙΆΡ1S (ÀQQ)	Transfert d’un même vol uniquement (p. ex. le transfert est le résultat d’un changement d’horaire)
Commentaires à haute priorité	Vol mappé de l’appariement DE — À
Préférence de siège	Premier vol remplacé
Siège bloqué	Premier vol remplacé

[0124] Pendant le processus de transfert de données DCS. si une information de bagage est générée et stockée pour un passager transféré donné, relative à un itinéraire de voyage perturbé, le module de transfert 52 et/ou le DCS 18 peuvent modifier l’information de bagage pour inclure un itinéraire de bagage basé sur le nouvel itinéraire de voyage et ajouter l’informarion de bagage modifiée aux enregistrements DCS du passager donné qui sont associés au nouvel itinéraire de voyage. En particulier, le module de transfert 52 et/ou le DCS 18 peuvent retirer les vols remplacés de ritincraire de bagage et peuvent ajouter les nouveaux vols du nouvel itinéraire de voyage à l’itinéraire de bagage. Les numéros d’étiquette de bagage inclus dans l’information de bagage qui peut être physiquement attachée au bagage du passager ne peuvent pas être altérés et peuvent aussi être inclus dans l’information de bagage modifiée. Si l’information de bagage pour un passager donné indique que le bagage a été étiqueté pour une destination intermédiaire, « short check-in » (c.-à-d. que l’itinéraire du bagage se termine à une destination qui est un point de correspondance avant la destination finale du passager), le module de transfert 52 et/ou le DCS 18 peuvent alors déterminer si la destination de correspondance dans l’Itinéraire de bagage d’origine est incluse dans le nouvel itinéraire de voyage. Dans ce cas, le module 52 et/ou le DCS 18 peuvent à nouveau accepter le bagage du passager pour cette destination. Autrement si le bagage est étiqueté pour la correspondance et que le nouvel itinéraire de voyage n’inclut pas la destination d’origine du bagage, le module de transfert 52 et/ou le DCS 18 peuvent accepter le bagage sur le nouvel itinéraire de voyage et pour l’itinéraire complet de sorte que le bagage sera géré jusqu’à la destination finale du passager. Après que l’information de bagage a été modifiée, le module de transfert 52 et/ou le

DCS 18 peuvent envoyer l’information de bagage actualisée aux systèmes pertinents de gestion de bagage.

[0125] Dans le bloc 122 après que le transfert de données DCS a été achevé, les passagers transférés peuvent être enregistrés (ou acceptés) sur un ou plusieurs des vols du nouvel itinéraire de voyage. En particulier, pour chaque passager, si le passager a été accepté ou est en stand-by sur un ou plusieurs vols de ritinéraire de voyage perturbé, par exemple pour le premier vol remplacé, le module de transfert 52 et/ou le DCS 18 peuvent alors essayer de réaccepter le passager sur un ou plusieurs vols du nouvel itinéraire de voyage. Autrement si l’agent a sélectionné l’option pertinente lors de la création de la demande de transfert 54, le module de transfert 52 et/ou le DCS 18 peuvent accepter chaque client comme passager en stand-by plutôt que comme passager complètement accepté sur ledit ou plusieurs vols d’un nouvel itinéraire de voyage. Les passagers peuvent alors être complètement acceptés sur les vols via des protocoles normaux de stand-by (p. ex. â un moment avant le vol, un ou plusieurs des passagers stand-by peuvent être complètement acceptés sur une base prioritaire).

[0126] Dans le cadre du processus de transfert de données DCS ou du processus d’acceptation, le module de transfert 52 et/ou le DCS 18 peuvent aussi contrôler qu’un temps de correspondance minimum est respecté pour le nouvel itinéraire de voyage, par exemple entre le dernier nouveau vol dans le nouvel itinéraire de voyage et le vol suivant dans le nouvel itinéraire de voyage. Par exemple, un itinéraire de voyage perturbé peut inclure trois vols, notamment X1, X2 et X3 en séquence, et un nouvel itinéraire de voyage peut inclure Y1, ¥2 et X3 en séquence. Dans ce cas le module de transfert 52 et/ou le DCS 18 peuvent vérifier que le temps de correspondance minimum est respecté entre Y2 et X3. Dans ce cas, le module de transfert 52 et/ou le DCS 18 peuvent procéder au transfert de données DCS et/ou à l’acceptation des passagers transférés sur le nouvel itinéraire de voyage de la façon décrite ci-dessus. Sinon, le rapport de transfert 56 et/ou le DCS 18 peuvent amener le rapport de transfert 56 à inclure une erreur et une justification (p. ex. transfert de données DCS ou acceptation du passager n’ont pu être complétés en raison d’un échec relatif au temps de correspondance minimum exigé). Autrement, si le temps de correspondance minimum n’est pas respecté, le module de transfert 52 et/ou leDGS 18 peuvent alors continuer pour mettre en œuvre le transfert de données DCS et/ou accepter les passagers sur le nouvel itinéraire de voyage, mais générer un avertissement dans le rapport de transfert 56 concernant le manquement au temps minimum exigé pour la correspondance. De plus et/ou autrement, cette vérification peut être effectuée dans le processus de validation du bloc 104.

[0127] Dans le bloc 124, le rapport de transfert 56 peut être finalisé et présenté à l’agent. En particulier, le module de transfert 52 peut générer des données représentatives du rapport de transfert 56 qui peut être un affichage unique consolidé résumant les résultats du processus de transfert 100. Le module de transfert 52 peut ensuite présenter les données représentatives du rapport de transfert 56 à l’agent, par exemple via un terminal d’ordinateur connecté au DCS 18 ou au système d’inventaire 14.

[0128] Le rapport de transfert 56 peut inclure plusieurs éléments qui résument le résultat du processus de transfert 100. Par exemple, je rapport de transfert 56 peut inclure un résultat de transaction global, tel qu’« achevé », « achevé avec erreurs », « achevé avec avertissements », « incomplet » ou « en cours » pour tous les passagers faisant l’objet d’une demande. Le rapport de transfert 56 peut aussi inclure et/ou identifier le nombre de passagers réservés à nouveau avec succès sur le nouvel itinéraire de voyage, le nombre de passagers pour lesquels des services (p. ex. SSR) ont été réappiiqués avec succès au nouvel itinéraire de voyage, le nombre de passagers pour lesquels des e-billets et des coupons EMD ont été traités avec succès par rapport au nouvel itinéraire de voyage, le nombre de passagers pour lesquels des données ont été transférées avec succès dans la base de données DCS 66 et/ou le nombre des passagers qui ont été acceptés avec succès sur un ou plusieurs vols du nouvel itinéraire de voyage. De façon similaire, le rapport de transfert 56 peut inclure le nombre de passagers pour lesquels les processus ci-dessus ont échoué.

[0129] Le rapport de transfert 56 peut aussi inclure des détails concernant le résultat de chaque sous-processus dans le processus 100 pour chaque passager de la demande de transfert 54. Spécifiquement, pour chaque passager, le rapport de transfert 56 peut inclure un résultat des nouvelles réservations, des résultats pour le retraitement des services, quelle opération e-billet a été effectuée pour le passager (p, ex., revalidation ou échange), quelles opérations de coupons EMD ont été effectuées pour le passager (p. ex., dissociation, réassociation ou échange), si des données ont été transférées avec succès pour le passager dans la base de données DGS 66 ou non, et/ou si le passager a été accepté avec succès sur un ou plusieurs vols du nouvel itinéraire de voyage. En outre, si un quelconque des processus se solde par un échec ou un avertissement, une erreur ou un avertissement correspondant peut être fourni pour le passager dans le rapport de transfert 56.

[0130] En d’autres termes, le rapport de transfert 56 peut fournir un affichage complet et unique pour l’agent, résumant le processus de transfert 100 relatif à chaque passager. L’agent peut donc utiliser le rapport de transfert 56 pour identifier rapidement les problèmes pour chaque passager et corriger manuellement ces problèmes pour les passagers de façon appropriée (par ex.» en échangeant manuellement un e-billet, en saisissant manuellement des données dans la base de données DCS 66). En outre, si un passager a perdu un service réservé pendant le processus de voyage 100» tel qu’un siège amélioré, le rapport de transfert 56 peut permettre à un agent d’identifier rapidement le service perdu, par exemple via une icône spécifique associée aux passagers dans le rapport de transfert 56.

[0131] Dans certains modes de réalisation, une compagnie aérienne peut définir, pour le module de iransfert 52, un ensemble d’instructions spécifiques à mettre en œuvre en réponse à un échec ou une erreur, par exemple un service ou un service payant qui n’a pu être réservé à nouveau sur le nouvel itinéraire de voyage, comme indiqué par le rapport de transfert 56. En réponse à la perte d’un service payant au cours du processus de transfert 100, une compagnie aérienne peut, par exemple, définir des instructions pour le module de transfert 52 pour placer automatiquement l’enregistrement de réservation pertinent en file d’attente à un bureau particulier d’une compagnie aérienne, par exemple pour traiter un remboursement et/ou pour ajouter une indication telle qu’un élément « SSR OTHS » dans l’enregistrement de réservation pertinent indiquant que le service payant a été perdu au cours du transfert.

[0132] La FIG. 5 illustre un processus 200 pour mettre en œuvre les opérations automatisées de billetterie du bloc 118 dans le processus de transfert 100. Le processus 200 peut être mis en œuvre par le module de transfert 52 et/ou le système billettique 16. En particulier, et comme décrit précédemment, pendant le processus de transfert 100, le module de transfert 52 peut appeler et/ou amener le système bîllettique 16 à gérer automatiquement le traitement des e-bîllets et des coupons EMD pour les passagers transférés. Par la suite, le système bîllettique 16 et/ou le module de transfert 52 peuvent mettre en œuvre le processus 200.

[0133] Dans le bloc 202, un bureau de billetterie dans lequel sont effectuées des transactions de billetterie peut être sélectionné. Le choix du bureau de billetterie détermine quelle compagnie aérienne est le transporteur émetteur qui désigne généralement le transporteur qui valide et/et émet les billets aux passagers, collecte/reçoit le paiement des passagers pour le nouvel itinéraire de voyage, distribue le paiement aux compagnies aériennes exploitantes impliquées dans le nouvel itinéraire de voyage et/ou émet des remboursements ou des crédits.

[0134] Le module de transfert 52 et/ou le système bîllettique 16 peuvent sélectionner un bureau hillettîqueen utilisant la logique suivante. Si la compagnie aérienne qui déclenche le transfert dispose d’un bureau bîllettique dans lequel les transactions de billetterie peuvent être effectuées, le module de transfert 52 et/ou le système bîllettique 16 peuvent alors sélectionner le bureau de billetterie de la compagnie aérienne responsable du déclenchement. Sinon, le module de transfert 52 et/ou le système bîllettique 16 peuvent sélectionner le bureau de billetterie de la compagnie aérienne exploitante du vol affecté (p. ex. la compagnie aérienne qui exploité le vol à l’origine de l’itinéraire de voyage perturbé).

[0135] La logique ci-dessus permet au processus 200 de travailler avec des vols gérés au sol ainsi qu'avec d’autres vols hébergés par le DCS 18. Spécifiquement, pour un vol géré au sol, le gestionnaire ou la compagnie aérienne au sol qui demande le transfert peut ne pas avoir un bureau bîllettique pouvant effectuer les transactions de billetterie du processus 200 pour le compte de la compagnie aérienne exploitante du vol géré au sol, car le vol géré au sol peut être externe aux systèmes du gestionnaire au soi ou aux systèmes de la compagnie aérienne, Cependant, la compagnie aérienne exploitante du vol géré au sol doit avoir un bureau de billetterie capable d’effectuer les opérations de billetterie pour le vol géré au sol et ce bureau de billetterie peut être sélectionné en utilisant la logique ci-dessus.

[0136] Si en utilisant la logique ci-dessus, le module de transfert 52 et/ou le système bîllettique 16 sont incapables de déterminer un bureau de billetterie, le module de transfert 52 et/ou le système bîllettique 16 peuvent alors interrompre le processus 200. Dans ce cas, le reste du processus de transfert 100 peut procéder et le module de transfert 52 peut actualiser le rapport de transfert 56 pour inclure une indication l’échec du le processus de billetterie. Le rapport de transfert 56 peut aussi inclure la raison de l’échec (p. ex., bureau billettique indisponible).

[0137] Dans le bloc 204, en réponse à la sélection d’un bureau billettique, il est possible de déterminer si chaque passager dans la demande de transfert 54 est éligible à une transaction e-billet automatisée. Par exemple, le module de transfert 52 et/ou le système billettique 16 peuvent vérifier si un ou plusieurs des nouveaux vols dans le nouvel itinéraire de voyage sont exploités par des compagnies aériennes qui fonctionnent sans billet. Dans ce cas, aucun des passagers n’est éligible à des transactions e-billet automatisées, tout au moins lorsqu’elles ne sont pas relatives à ces vols. Un autre contrôle peut inclure de vérifier si la demande de transfert 54 inclut un nourrisson. Dans ce cas, le nourrisson peut avoir besoin de son propre e-billet. Si le nourrisson n’a pas son propre ebillet, le module de transfert 52 et/ou le système billettique 16 peuvent alors déterminer que le passager nourrisson et/ou tous les passagers voyageant avec le nourrisson sont inéligibles à une transaction e-billet automatisée. Un autre contrôle peut inclure de vérifier si le nom du passager sur chaque e-billet (et coupon EMD) impliqué dans la demande de transfert 54 et devant être traité dans le processus 200 correspond à un des noms de passager inclus dans la demande de transfert 54 pouvant être transférés à partir des enregistrements de réservation pertinents stockés dans la base de données d’enregistrement de réservation 58 (p. ex., les noms présentés à l’agent pour la sélection peuvent être générés à partir des enregistrements dé réservation dans la base de données d’enregistrement de réservation 58). En général, ce contrôle peut assurer une cohérence du procédé et éviter une fraude potentielle, augmentant ainsi la sécurité du système dans son ensemble. Si un nom de passager inclus dans la demande de transfert 54 diffère du nom de passager sur un e-billet ou coupon EMD devant être traité pour le passager, le module de transfert 52 et/ou le système billettique 16 peuvent alors déterminer que ce passager dans la demande de transfert 54 est inéligible à une transaction e-billet automatisée, [0138] Le module de transfert 52 et/ou le système billettique 16 peuvent aussi vérifier que chacun des e-billets (et coupons EMD) impliqués par la demande de transfert 54 et devant être traité dans le processus 200 dispose d’un statut « ouvert », au moins par rapport aux vois remplacés. Si un des e-billets a toujours un statut « enregistré » par rapport aux vols remplacés, le module de transfert 52 et/ou le système billettique 16 peuvent alors implémenter un mécanisme de nouvelle tentative qui effectue ce contrôle à nouveau après un court délai afin d’accorder plus de temps au ebillet pour qu’il passe au statut « ouvert » par rapport aux vols remplacés. Cette nouvelle tentative peut être effectuée plusieurs fois et si l’e-billet continue à indiquer un statut « enregistré » par rapport aux vols remplacés, le module de transfert 52 et/ou le système billettique 16 peuvent déterminer que le passager associé à î’e-bïllet est inéligible à une transaction automatisée d’e-billet. [0139] Plus loin dans le bloc 204, le module de transfert 52 et/ou le système biIlettique 16 peuvent déterminer pour quels e-billets ils doivent effectuer les contrôles ci-dessus et/ou procéder avec les parties restantes du processus 200. Une logique intelligente peut être utilisée pour identifier les e-billets pertinents, c’est-à-dire le ou les e-billets pour chaque passager correspondant à l’itinéraire de voyage perturbé et plus particulièrement qui incluent des coupons pour les vols remplacés. En particulier, pour chaque passager transféré et pour chaque vol remplacé, le module de transfert 52 et/ou le système billettique 16 peuvent utiliser une liste prioritaire de sources de données pour identifier un e-billet pour le passager pour le vol. Par exemple, le module de transfert 52 et/ou le système billettique 16 peuvent vérifier si le vol a été associé à un identifiant d’e-billet dans le DCS 18 pour le passager. Si tel n’est pas le cas, le module de transfert 52 et/ou le système billettique 16 peuvent alors vérifier si l’enregistrement de nom de passagers pour le passager incluant le vol dispose d’un identifiant d’e-billet qui a été ajouté automatiquement à l’enregistrement de nom de passager par le système de réservation 12 lors de la réservation du passager et de l’émission de billet pour le vol. S’il n’y a toujours pas de numéro e-billet trouvé, le module de transfert 52 et/ou le système billettique 16 peuvent alors vérifier si l’enregistrement de nom de passager pour le passager incluant le vol, inclut un numéro d’e-billet dans un élément FHE pour le vol, ce qui correspond à un identifiant d’e-billet saisi manuellement par un agent lorsque la réservation a été créée. Une fois que l’identifiant e-billet est sélectionné pour chaque vol remplacé pour un passager, il est possible de déterminer si les e-billets associés aux identifiants sélectionnés correspondent aux vols remplacés, par exemple en affichant chacun des e-billets et en déterminant si les e-billets incluent des coupons pour les vols remplacés. Si une correspondance complète est trouvée, un ou plusieurs des e-billets correspondants aux identifiants sont sélectionnés pour les contrôles cî-dessus et/ou pour les parties restantes du processus 200 pour le passager. Sinon, il est possible de déterminer que le passager est inéligible à une transaction e-billet automatisée [0140] S’il est déterminé qu’un ou plusieurs des passagers sont inéligibles à une transaction e-billet automatisée (branche «Non » du bloc 204) le contrôle est alors transféré au bloc 218, le rapport de transfert 56 peut être actualisé pour indiquer une erreur d’inéligibilité d’e-bîllet et/ou la raison de cette erreur, et le processus 200 peut être interrompu. Autrement, le rapport de transfert 56 peut être actualisé pour indiquer une erreur uniquement pour les passagers dont il a été déterminé qu’ils sont inéligibles à une transaction e-billet automatisée relative à un ou à plusieurs des nouveaux vols. Dans ee cas, le processus 200 peut procéder à effectuer des transactions de billetterie pour les passagers dont l'éligibilité, par rapport à un ou à plusieurs des nouveaux vols, a été déterminée. Dans certains scénarios, un passager donné peut être inéligible par rapport à un nouveau vol dans le nouvel itinéraire de voyage et éligible par rapport un autre nouveau vol dans le nouvel itinéraire de voyage. Dans ce cas, le passager peut être signalé comme étant inéligible dans le rapport de transfert 56 pour ledit nouveau vol et le processus 200 peut continuer pour le passager avec l’autre nouveau vol.

[0141] En réponse à la détermination qu’un ou plusieurs des passagers sont éligibles à une transaction e-biliet automatisée par rapport à un ou à plusieurs de nouveaux vols (branche « Oui » du bloc 204), un type de transaction e-bîîlet peut alors être déterminé au bloc 208 pour chaque passager éligible, par exemple à partir du groupe qui consiste en une transaction de revalidation d’un e-billet et une transaction d’échange d’un e-biliet. Spécifiquement, le module de transfert 52 et/ou le système billettique 16 peuvent sélectionner une transaction de validation ou une transaction d’échange pour chaque passager éligible. En général, une transaction de revalidation peut inclure la mise à jour d’un e-billet existant avec les nouveaux détails de vol et ne peut être possible que si le nouvel itinéraire de voyage inclut le même trajet, date et classe que l’itinéraire de voyage perturbé. De plus, une compagnie aérienne peut définir certaines conditions de base qui nécessitent aussi d’être remplies pour qu’une transaction de revalidation d’un e-billet soit sélectionnée afin d’augmenter le taux de réussite de revalidation.

[0142] Si la revalidation n’est pas disponible pour un passager donné, le module de transfert 52 et/ou le système billettique 16 peuvent sélectionner une transaction d’échange d’un ebillet pour le passager donné. Une transaction d’échange e-billet peut inclure l’émission d’un nouvel e-billet pour le nouvel itinéraire de voyage avec un nouvel identifiant ou identifiant de billet. Dans certains modes de réalisation, avant le traitement de la transaction d’échange (ou de la transaction de revalidation), le module de transfert 52 et/ou le système billettique 16 peuvent effectuer une vérification additionnelle pour confirmer que la durée avant le départ du nouveau vol et/ou vol qui n’est pas encore parti dans le nouvel itinéraire de voyage est supérieur à une durée prédéterminée. Dans ce cas, le processus 200 peut alors être interrompu de façon à laisser l’échange (ou la revalidatîon) aux mains du transporteur émetteur associé à un ou à plusieurs des e-billets précédents du passager. De cette façon, le transporteur émetteur évite de perdre le contrôle des ebiilets qui ont été émis. Cette durée prédéterminée peut être configurée séparément pour chaque compagnie aérienne.

[0143) Dans certains modes de réalisation, une seule transaction e-billet peut être effectuée pour chaque passager éligible. De cette façon, le module de transfert 52 et/ou le système billettique 16 sont capables d’éviter des échecs partiels pour un passager donné (c.-à-d. l’aboutissement de certaines transactions e-billetet l’échec de certaines transactions e-billet pour un passager donné).

Par ailleurs, le fait de limiter chaque passager à une seule transaction e-bîllet par personne peut réduire le temps de réponse du système et, le cas échéant, peut faciliter les traitements manuels effectués par l’agent. Ainsi, lorsque, pour un passager donné, deux ou plusieurs e-billets sont déterminés incluant les vols remplacés de l’itinéraire de voyage perturbé, le passager peut alors être limité à une transaction d’échange afin de se conformer à la règle d’une transaction e-billet par personne.

[0144] Au bloc 210, îe type de transaction e-billet déterminé pour chaque passager éligible peut être traité sur un ou plusieurs des e-billets des passagers, tels que l’e-billet ou les e-billets identifiés au bloc 204. Dans certains modes de réalisation, toutes les transactions e-billets pour la demande de transfert 54 peuvent être déclenchées via une requête envoyée au système billettique 16 par le bureau billettique déterminé et/ou le module de transfert 52 qui inclut le type de transaction ebilîet déterminé pour chaque passager, ce qui permet au système de réaliser un temps de réponse amélioré (p, ex., des requêtes multiples nécessitent l’usage de ressources informatiques additionnelles et un temps de réponse plus élevé comparé à une requête unique). Cependant, en réponse au rejet de la requête unique par le système billettique 16, chaque transaction e-billet peut, sur une base individuelle, faire l’objet d’une nouvelle tentative. Plus particulièrement, le module de transfert 52 et/ou le bureau de billetterie déterminé peuvent générer une demande distincte de billetterie pour chaque passager de façon à déclencher le système billettique 16 pour traiter chaque transaction e-billet déterminée, une par une.

[0145] Pendant que les transactions e-billets sont en cours de traitement, les accords interlignes habituels entre les compagnies aériennes affectées peuvent être également vérifiés. Si une erreur survient dans ce processus pour un passager ou un e-bîllet donné, une remarque peut être ajoutée à l’enregistrement de réservation pertinent dans la base de données d’enregistrement de réservation 58 qui inclut Γidentifiant ou le numéro de l’e-billet ayant échoué, ce qui peut aider l’agent à identifier un e-billet qui nécessite un traitement manuel. Sinon, une référence à un identifiant ou à un numéro d’e-billet peut autrement être absente de l’enregistrement de réservation pertinent, par exemple lorsque l’e-billet a été manuellement associé dans le DCS 18 et non dans l‘enregistrement de réservation, ou dans le cas d’un nouvel enregistrement de réservation créé pour le passager au cours du processus de transfert 100, ce qui peut gêner les tentatives de l’agent pour corriger l’erreur d’émission d’è-bilîet [0146] En réponse à la mise en œuvre des transactions e-billet pour chaque passager, des coupons EMD peuvent commencer à être traités pour chaque passager. Afin de traiter les coupons

EMD pour un passager donné, la transaction e-billet pour le passager peut devoir être réussie, car un e-billet valide peut être nécessaire afin qu’un coupon EMD soit traité et lui soit associé. En d’autres termes, le traitement de coupons EMD ne peut commencer avant que le traitement des ebillets pour les passagers transférés ne soit terminé.

[0147] Dans le bloc 212, un ou plusieurs coupons EMD associés aux passagers peuvent être identifiés, chacun des coupons EMD étant relatif à l’itinéraire de voyage perturbé d’un des passagers, et il est possible de déterminer si chacun des coupons EMD associés aux passagers est éligible au traitement automatisé. En particulier, le module de transfert 52 et/ou le système bilîettique 16 peuvent identifier les coupons EMD des passagers relatifs aux vols remplacés, par exemple en effectuant le même processus détaillé ci-dessus, basé sur la priorité, pour déterminer les e-billets devant être vérifiés et/ou traités. La détermination de l’éligibilité d’un coupon EMD au traitement automatisé peut être basée sur le fait que le passager associé au coupon EMD a été confirmé sur le nouveau vol pendant le processus de nouvelle réservation (bloc 114 du processus 100) détaillé ci-dessus, et/ou si la transaction e-billet pour le passager associé au coupon EMD a été effectuée avec succès par rapport au nouveau vol. Spécifiquement, si un passager n’a pas été confirmé sur un nouveau vol ou s’il n’existe pas d’e-billet valide pour un passager par rapport au nouveau vol, un coupon EMD peut ne pas pouvoir être traité automatiquement pour le nouveau vol du passager.

[0148] Si un ou plusieurs (ou tous) coupons EMD sont déterminés comme étant éligibles au traitement automatisé (branche « Oui » du bloc 212) alors le bloc 214 peut être mis en œuvre pour les coupons EMD éligibles. Au bloc 214, pour chaque coupon EMD déterminé comme étant éligible à un traitement automatisé, un type de transaction EMD peut être sélectionné, par exemple à partir du groupe consistant en une transaction de dissociation EMD, une transaction de réassociation EMD et un échange de transaction EMD. Le module de transfert 52 et/ou le système bilîettique 16 peuvent, par exemple, sélectionner une transaction EMD de dissociation si le service associé au coupon EMD ne pouvait pas être réappliqué au nouveau vol, par exemple pendant le processus de nouvelle réservation (bloc 114 du processus 100) décrit ci-dessus. En général, la mise en œuvre d’une transaction de dissociation EMD pour un coupon EMD donné peut inclure le changement du statut d’un lien « en rapport avec » sur le coupon EMD (et tout e-billet associé) à « dissocié » et/ou en enlevant 1⁵identifiant unique de l’e-biilet associé du coupon EMD, et/ou vice versa.

[0149] Autrement, le module de transfert 52 et/ou le système billettique 16 peuvent sélectionner une transaction de réassociation EMD si le service associé au coupon EMD a été réappliqué sur le nouveau vol pendant le processus de nouvelle réservation et que le nouveau vol inclut seulement des changements minimes relatifs au vol remplacé apparié au nouveau vol. En général, la mise en œuvre d’une transaction de réassociation EMD pour un coupon EMD donné peut inclure le changement du statut « en rapport avec » du lien pour le coupon EMD (et de l’e10 billet associé) à « associé » et/ou en ajoutant l’identifiant unique de l’e-billet associé au coupon

EMD et/ou vice versa. Comme exemple non limitatif, un changement d’aéroport, un changement de nombre de vols (p. ex., un vol remplacé est apparié à de multiples nouveaux vols) et/ou un changement de transporteur exploitant du vol peuvent être considérés en dehors du champ d’application des « changements minimes ».

[0150] Comme autre possibilité, le module de transfert 52 et/ou le système billettique 16 peuvent sélectionner une transaction d’échange EMD pour le coupon EMD. Cela peut survenir, par exemple, si un coupon EMD est inéligible, soit à une transaction de dissociation EMD, soit à une transaction de réassociation EMD. Comme autre exemple, lorsqu’une transaction d’échange e-billet est déterminée et traitée pour un passager aux blocs 208 et 210 du processus 200, le module de transfert 52 et/ou le système billettique 16 peuvent alors sélectionner une transaction d’échange

EMD pour tous les EMD du passager associés au e-billet échangé, car la sélection d’une transaction d’échange e-billet pour l’e-billet implique des changements en dehors du champ d’application de ceux qui sont minimes. Afin d’effectuer une transaction d’échange EMD, l’enregistrement de réservation pertinent peut être actualisé avec l’information de base, telle qu’un élément TSM-P, une ligne FO, la forme de paiement, etc. pouvant être nécessaire pour effectuer l’échange EM.

[0151] Dans le bloc 216, les coupons EMD éligibles peuvent être traités selon les transactions déterminées. De façon similaire au processus e-billet décrit ci-dessus, une remarque incluant les numéros d’un ancien coupon EMD peut être ajoutée à chaque enregistrement de réservation pertinent si des erreurs surviennent Dans certains modes de réalisation, chaque transaction EMD peut être traitée immédiatement après la détermination de la transaction EMD et/ou une ou plusieurs transactions EMD peuvent être traitées en parallèle. De cette façon, le temps de réponse du système peut être réduit.

[0152] Dans le bloc 218, après Γachèvement du processus e-billet et du processus EMD pour les passagers, les résultats du processus peuvent être résumés dans le rapport de transfert 56. Spécifiquement, une fois que les transactions EMD sont effectuées et/ou après la détermination qu’un ou plusieurs des coupons EMD sont inéligibles au traitement automatisé (branche «Non » du bloc 212), le rapport de transfert 56 peut alors être actualisé au bloc 218 pour inclure un résultat global pour tous les passagers (p. ex., « abouti », « achevé », « achevé avec erreur »). De plus ou autrement, le rapport de transfert 56 peut être actualisé pour indiquer, pour chaque passager, quels e-billets ont abouti ou ont échoué au cours du traitement et/ou quels coupons EMD ont abouti ou ont échoué au cours du traitement. Dans l’éventualité d’un quelconque échec, le rapport de transfert 56 peut aussi être actualisé pour inclure les détails de cet échec pour chaque passager. Par exemple, tout coupon EMD qui est déterminé comme étant inéligible à une transaction automatisée, peut être inclus dans le rapport de transfert 56 de façon à être lié au passager associé au coupon EMD dans le rapport de transfert 56.

[0153] La FIG.6 illustre une machine étatique finie 300 qui peut veiller au statut du processus 100 pour un ou plusieurs passagers inclus dans le processus. Comme indiqué dans le schéma, des états qui ne sont pas finaux survenant pendant le processus de transfert 100 sont représentés par des cercles entourés d’une ligne fine solide, des états finaux survenant pendant le processus de transfert 100 qui se sont achevés sans erreurs/avertissements sont représentés par des cercles entourés d’une ligne épaisse pointillée et des états finaux survenant lorsque le processus 100 est achevé avec des erreurs/avertissements sont représentés par des cercles entourés de lignes épaisses solides. La machine étatique 300 peut être utilisée par le module de transfert 52 pour actualiser le rapport de transfert 56 aux diverses étapes du processus de transfert 100, Chaque état peut représenter un état global pour l’intégralité du processus 100 et/ou un état du processus 100 pour un ou plusieurs des passagers faisant l’objet d’une demande. En d’autres termes, chaque passager de la demande peut être dans un état différent dans la machine étatique 300 à un moment donné et chaque passager peut être représenté ou associé à un état différent de la machine étatique 300 implémentée par l’environnement d’exploitation 10 et/ou l’architecture de traitement 50.

[0154] Lorsque le processus de transfert 100 est déclenché, la machine étatique 300 peut entrer dans un état 302, « sous réserve de validation ». À l’état 302 « sous réserve de validation », la validation du bloc 104 du processus 100 peut être en cours. Une fois que le processus de validation est achevé, la machine étatique 300 peut recevoir une entrée représentative indiquant si la demande de transfert 54 a été validée ou invalidée, par exemple par le module de transfert 52. En réponse à la réception d’une entrée représentant que la demande de transfert 54 est invalide, la machine étatique 300 peut passer à un état 304, « échec du transfert -— invalide ». Autrement, en réponse à une entrée représentant la demande de transfert comme étant valide, la machine étatique 300 peut passer à un état 306 « nouvelle réservation en cours ».

(0155) Au cours de l’état 306, « nouvelle réservation en cours, un ou plusieurs des blocs 108-118 du processus 100 peuvent être en cours de réalisation. Une fois achevée, la machine étatique 300 peut recevoir une de plusieurs entrées, chacune amenant la machine étatique 300 à passer à un état différent. Par exemple, si la machine étatique 300 reçoit une entrée représentant que la nouvelle réservation pour un ou plusieurs passagers a échoué, la machine étatique 300 peut alors, pour chacun de ces passagers, passer à l’état 308, « échec du transfert — erreur de réservation ». Comme décrit précédemment, la machine étatique 300 peut représenter chaque passager séparément ou représenter un résultat global du processus 100. Par conséquent, lorsque la nouvelle réservation d’un ou de plusieurs passagers échoue, la machine étatique 300 peut passer à l’état 308, « échec du transferterreur de réservation », uniquement pour chaque passager dont la réservation a échoué, ou pour l’intégralité du processus 100.

[0156] Autrement, si l’entrée reçue représente que la nouvelle réservation a été réservée avec succès et que le premier nouveau vol et/ou un vol du nouvel itinéraire de voyage qui n’est pas encore parti est externe au DCS 18, la machine étatique 300 peut alors passer à un état [308], « transfert achevé — externe «Autrement si l'entrée reçue représente que la nouvelle réservation a été réservée avec succès et qu’un PNL ou ADL n*a pas encore été reçu pour les vols impliques dans la nouvelle réservation, la machine étatique 300 peut alors passer à l’état 310, « en attente du PNL/ADL ». Autrement, si l’entrée reçue représente que la nouvelle réservation a été réservée avec succès et qu’un ou plusieurs des nouveaux vols dans le nouvel itinéraire de voyage ne sont pas encore ouverts dans te DCS 18, la machine étatique 300 peut alors passer à l’état 312, « en attente d’ouverture du vol ». Autrement, si Centrée reçue représente que la nouvelle réservation a été réservée avec succès et qu’un PNL ou un ADL a été reçu pour les nouveaux vols impliqués par la nouvelle réservation, la machine étatique 300 peut alors passer à l’état 314, « transfert de données DCS en cours », pendant lequel un ou plusieurs des blocs 120 -124 du processus 100 peuvent être effectués.

[0157] À l’état 310 «en attente PNL/ADL, ou à l’état 312 « en attente d’ouverture du vol », la machine étatique 300 peut recevoir une entrée représentative de la réception d’un PNL ou ADL relatif à la nouvelle réservation ou de l’ouverture d’un ou de plusieurs vols relatifs à la nouvelle réservation, respectivement. En réponse à la réception de Pune ou de l’autre entrée, la machine étatique 300 peut passer à P état 314 « transfert de données DCS en cours ».

(0158] Encore une fois, lorsque la machine étatique 300 est à l’état 314 « transfert de données DCS en cours », la machine étatique 300 peut recevoir une ou plusieurs entrées qui affectent différemment la transition suivante de la machine étatique 300. Par exemple, la machine étatique 300 peut recevoir une entrée représentant que le processus de transfert de données DCS a été achevé et/ou a été manuellement ignoré/contourné par l’agent, ce qui peut donner lieu à une transition de la machine étatique 300 à l’état 316 « transfert achevé ». Autrement, si l’entrée reçue représente que le processus de transfert de données DCS a été achevé pour un ou plusieurs passagers et qu’un ou plusieurs des passagers n’ont pas pu être acceptés sur le nouveau vol, la machine étatique 300 peut alors passer à un état 318 « achevé avec erreur—non accept. ». Autrement, si l’entrée reçue représente que le processus de transfert de données DCS a été achevé pour un ou plusieurs des passagers, mais que des erreurs sont survenues pendant le processus de billetterie, la machine étatique 300 peut alors passer à l’état 320, « achevé avec erreur - échec billet ». Autrement, si l'entrée reçue représente que des erreurs sont survenues pendant le processus de transfert de données DCS, la machine étatique 300 peut alors passer à l’état 322, « achevé avec erreur — échec du transfert DCS ». Sur la base de l’état achevé, indiqué dans le rapport de transfert 56, l’agent peut alors corriger toute erreur et peut redéclencher tout sous-processus du processus 100, si nécessaire.

[0159] En général, les processus de bi 1 letterie et de débarquement mentionnés ci-dessus peuvent survenir entre l’état de sortie 306 et l’état de sortie 314. Par exemple, après l’achèvement de la nouvelle réservation et l’actualisation de la base de données d’enregistrement de réservation 58, le système de réservation 12 peut automatiquement déclencher l’envoi d’un ou de plusieurs PNL ou ADL au DCS 18 qui reflètent les nouvelles réservations (p. ex., il reflète la suppression des passagers d’un vol remplacé ou l’ajout de passagers à un nouveau vol), c’est à ce stade que les passagers transférés peuvent être débarqués de tous les vols remplacés dans lesquels ils ont déjà été acceptés. Comme décrit précédemment, c’est également après l’achèvement de la nouvelle réservation qu’un appel peut aussi être placé au système billettique 16 pour effectuer les opérations de billetterie pour les passagers transférés. Le processus d’acceptation mentionné cidessus impliquant l’enregistrement des passagers sur les nouveaux vols du nouvel itinéraire de voyage peut survenir pendant l’état 314.

[0160] Un ou plusieurs des systèmes de l’environnement d’exploitation 10 et/ou le module de transfert 52 peuvent inclure un code exécutable qui suit de façon générale les états de la machine étatique 300. Dans un mode de réalisation particulier, les systèmes et/ou le module de transfert 52 peuvent être programmés spécifiquement de façon à implémenter littéralement la machine étatique finie 300. En particulier, les systèmes et/ou le module de transfert 52 peuvent stocker un code exécutable qui représente un ensemble ou une structure de donnée stockant les étapes possibles de la machine étatique finie 300. De plus, le code peut inclure un pointeur configuré pour pointer vers un état actuel pendant le processus de transfert 100. Chaque état peut être associé, dans le code, à une table de référence qui montre un état suivant pour une certaine entrée donnée. Ainsi, durant le processus de transfert 100, lorsque le code programmable pour la machine étatique 300 reçoit une entrée, le code peut utiliser la table de référence pour déterminer l’état de transition suivant. Comme décrit précédemment, l’état actuel de la machine étatique 300 peut être affiché dans le rapport de transfert 56 par rapport à un niveau global et/ou par rapport à un passager particulier. Ainsi, en étant programmés pour implémenter littéralement la machine étatique 300, les systèmes et/ou le module de transfert 52 peuvent être en mesure de rapporter l’état actuel du processus de transfert 100 en interrogeant simplement l’état de la machine étatique 300, ce qui permet au système et/ou au module de transfert 52 de réaliser des économies de ressources et d’améliorer les temps de réponse en comparaison à l’interrogation continuelle de divers systèmes pour calculer les processus enclenchés et leurs résultats à un quelconque moment donné pendant le processus 100.

[0161] En général, les routines exécutées pour mettre en œuvre les modes de réalisation de l'invention» qu'elles soient implémentées dans le cadre d'un système d'exploitation ou d'une application spécifique, d'un composant, d’un programme, d'un objet, d'un module ou d'une séquence d’instructions, ou même un sous-ensemble de ceux-là, peuvent être désignées dans les présentes comme « code de programme informatique » ou simplement « code de programme ». Le code de programme comprend typiquement des instructions lisibles par ordinateur résidant à divers moments dans divers dispositifs de mémoire et de stockage dans un ordinateur, et qui lorsqu'il est lu et exécuté par un ou plusieurs processeurs dans un ordinateur, provoque l'exécution par l’ordinateur d’opérations et/ou d’éléments propres aux aspects variés des modes de réalisation de l'invention. Les instructions d'un programme informatique lisibles par ordinateur pour effectuer les opérations des modes de réalisation de l'invention peuvent être, par exemple ; le langage d'assemblage ou un code source ou un code objet, écrit en combinaison avec un ou plusieurs langages de programmation.

[0162] Divers codes de programme décrits dans les présentes peuvent être identifiés, selon l'application dans laquelle ils sont implémentés, dans des modes de réalisation spécifiques de l'invention. Cependant, on remarquera que toute nomenclature d’un programme particulier qui suit est utilisée uniquement par commodité ; ainsi l'invention ne peut être limitée à un seul usage dans toute application spécifique identifiée et/ou sous-entendue par ladite nomenclature. Par ailleurs, au vu du nombre généralement infini de moyens par lesquels les programmes informatiques peuvent être organisés selon des sous-programmes, procédures, procédés, modules, objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme parmi diverses couches de logiciels qui sont résidents dans un ordinateur typique [p, ex., les systèmes d'exploitation, les bibliothèques, les interfaces d'application de programme (API), les applications, les petites applications (applets)], etc. ; on remarquera que les modes de réalisation de l'invention ne sont pas limités à l'organisation spécifique et à l'affectation spécifique des fonctionnalités de programme telles qu’elles sont décrites dans les présentes.

[0163] Le code de programme mis en œuvre dans une quelconque application ou module décrits dans les présentes peut être distribué individuellement ou collectivement comme un produitprogramme d'ordinateur, sous une variété de formes. En particulier, le code de programme peut-être distribué en utilisant un support de stockage lisible par ordinateur ayant des instructions de programme lisibles par ordinateur en amenant un processeur à exécuter des aspects des modes de réalisation de l'invention.

[0164] Les supports de stockage de données lisibles par ordinateur et qui sont intrinsèquement durables, peuvent inclure des médias tangibles, volatiles et non volatiles, amovibles et non amovibles, implémentés dans toute méthode ou technologie de stockage de données, telles que des instructions de programme lisibles par ordinateur, des structures de données, des modules de programme, ou autres données. Les supports de stockage lisibles par ordinateur peuvent aussi comprendre des mémoires, une mémoire vive (RAM), une mémoire morte (ROM), une mémoire à lecture exclusive programmable et effaçable (EPROM), une mémoire à lecture exclusive, programmable et effaçable électriquement (EEPROM), une mémoire flash, ou toute technologie de support solide de mémoire, un disque compact portable doté d'une mémoire à lecture seule (CD-ROM), ou tout autre stockage optique, des bandes d’enregistrement magnétique, une mémoire à disque magnétique, ou tout autre médium pouvant être utilisé pour stocker l'information désirée et apte à être lu par un ordinateur. Un support de stockage lisible par ordinateur ne peut être interprété comme des signaux transitoires en soi (p, ex., des ondes radio ou toutes autres ondes électromagnétiques se propageant à travers un support de transmission telle qu'un guide d'ondes, ou des signaux électriques transmis par câble). Les instructions de programme lisibles par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil de traitement de données programmable ou sur tout autre dispositif de support de stockage lisible par machine, ou vers un ordinateur externe ou vers un dispositif de stockage externe par un réseau.

[0165] Les instructions de programme lisibles par ordinateur, stockées dans un support lisible par ordinateur, peuvent être utilisées pour instruire un ordinateur, d'autres types d'appareils programmables de traitement ou d'autres dispositifs pour fonctionner d'une façon particulière, de sorte que les instructions stockées sur un support lisible par ordinateur produisent un article de fabrication comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagrammes de séquence, et/ou diagrammes blocs. Les instructions de programme informatique peuvent être fournies par un ou plusieurs processeurs sur un ordinateur à usage générai, un ordinateur à usage spécial, ou tout autre appareil programmable de traitement de données pour produire une machine telle que les instructions qui s'exécutent par l'intermédiaire d'un ou de plusieurs processeurs provoquent une série de calculs devant être effectués pour implémenter les fonctions, actions et/opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes blocs.

[0166] Dans certains modes de réalisation alternatifs, les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, diagramme séquentiel et/ou diagrammes blocs peuvent inclure plus ou moins de blocs que ceux qui sont illustrés tout en restant conformes avec les modes de réalisation de l’invention. De plus, tout organigramme, diagramme séquentiel, et/ou diagramme bloc peut inclure plus ou moins de blocs que ceux qui sont illustrés conformément à des modes de réalisation de l'invention.

[0167] La terminologie utilisée dans les présentes a pour but de décrire uniquement des modes de réalisation particuliers et n’est pas destinée à limiter les modes de réalisation de l’invention. On comprendra par ailleurs que les formes verbales du verbe « comprendre », « comprend » et/ou « comprenant », lorsqu’elles sont utilisées dans cette spécification, précisent la présence de caractéristiques, de nombres entiers, d’étapes, d’opérations, d’éléments, et/ou de composants, mais n’excluent pas la présence ou l’ajout d’un ou de plusieurs caractéristiques.

nombres entiers, étapes, éléments, composants et/ou groupes, en cela. De plus, dans la mesure où les verbes « inclure », « ayant », « a », « avec », « composé de » ou des variantes de ceux-là, sont utilisés dans la description détaillée et les revendications, ces termes sont censés être inclusifs de façon similaire à la forme verbale « comprenant ».

[0168} Bien que l'invention soit illustrée par une description de divers modes de réalisation et bien que ces modes de réalisation soient décrits de façon très détaillée, il n'est pas de l’intention du demandeur de restreindre ou de limiter, de quelque façon que ce soit, l'étendue des revendications des présentes à ces détails. Des avantages supplémentaires et des modifications possibles apparaîtront aisément aux hommes de métier. L’invention sous un angle plus large n'est donc pas limitée aux détails spécifiques, aux procédés et aux appareils représentatifs, et aux illustrations montrées et décrites à titre d’exemple. Par conséquent, il est possible de s'éloigner de ces détails sans s'éloigner de l'esprit et de la portée du concept inventif général de l'appliquant.

Claims

REVENDICATIONS

I. Un système de gestion des perturbations qui coordonne, après une perturbation, les opérations d’une pluralité de systèmes qui sont inclus dans le système de gestion des perturbations,

5 le système de gestion des perturbations comprenant :

un système d’inventaire comprenant une première base de données qui inclut une pluralité de compteurs, chacun des compteurs suivant une valeur de disponibilité pour un produit de voyage ; un système de réservation comprenant une seconde base de données qui inclut un ou plusieurs enregistrements de réservation pour une pluralité de passagers, chacun des passagers étant 10 inclus dans l’un d’un ou de plusieurs enregistrements de réservation et étant associé dans ledit enregistrement de réservation à un premier itinéraire de voyage sur lequel le passager est réservé ; un système de contrôle des départs, DCS, comprenant une troisième base de données incluant une donnée de passager stockée pour chaque passager qui est associée au premier itinéraire de voyage du passager ;

15 un système bîllettique comprenant une quatrième base dé données incluant un e-billet pour chaque passager, dans lequel le système d’inventaire, le système de réservation, le système billettîque et le DCS sont connectés via un réseau informatique ;

une pluralité de processeurs, le système d’inventaire, le système de réservation, le système billettîque et le DCS incluant chacun au moins un des processeurs ; et

20 une pluralité de dispositifs de mémoire incluant des instructions qui, lorsqu’elles sont exécutées par les processeurs, amènent le système à :

en réponse à la réception, par le système de gestion des perturbations et après la perturbation du premier itinéraire de voyage de chaque passager, d’une demande de transfert incluant les passagers et au moins une portion d’un second itinéraire de voyage pour

25 remplacer le premier itinéraire de voyage de chaque passager :

actualiser automatiquement les compteurs de la première base de données, via le système d’inventaire, sur la base du premier itinéraire de voyage de chaque passager et du second itinéraire de voyage ;

actualiser automatiquement ledit ou plusieurs enregistrements de réservation 30 de la seconde base de données, via le système de réservation, pour refléter une association entre chaque passager et le second itinéraire de voyage ; et après que la première et ta seconde base de données ont été actualisées :

effectuer un processus automatisé de billetterie, via le système de billetterie, pour chaque passager pour le second itinéraire de voyage ; et pour chaque passager, transférer automatiquement les données de passager relatives au premier itinéraire de voyage, via le DCS, vers un

5 enregistrement associé au second itinéraire de voyage qui est inclus dans la troisième base de données.
2. Le système de gestion des perturbations selon la revendication 1 dans lequel, lors de l’exécution, les instructions amènent le système de gestion des perturbations à actualiser les

10 compteurs de la première base de données pour chaque passager, via le système d’inventaire, sur la base du premier itinéraire de voyage et du second itinéraire de voyage, et à actualiser ledit ou plusieurs enregistrements de réservation de la seconde base de données, via le système de réservation, pour refléter une association entre chaque passager et le second itinéraire de voyage en amenant le système de gestion dés perturbations à :

15 déterminer, via le système d’inventaire, si les passagers peuvent être réservés à nouveau sur le second itinéraire de voyage sur la base des compteurs de la première base de données ; et en réponse à la détermination que les passagers peuvent être réservés à nouveau sur le second itinéraire de voyage, effectuer ce qui suit pour chaque passager :

réserver le passager à nouveau, via le système de réservation, sur le second itinéraire

20 de voyage dans la seconde base de données ; et actualiser les compteurs de la première base de données, via le système d’inventaire, sur la base de la nouvelle réservation.
3. Le système de gestion des perturbations selon la revendication 1 ou la revendication 2 dans

25 lequel, lors de l’exécution, les instructions amènent le système de gestion des perturbations à actualiser les compteurs de la première base de données, via le système d’inventaire, sur la base du premier itinéraire de voyage de chaque passager et du second itinéraire de voyage en amenant le système de gestion des perturbations à :

transmettre une requête unique au système d’inventaire, la requête unique incluant le

30 premier itinéraire de voyage de chaque passager et le second itinéraire de voyage ; et actualiser les compteurs de la première base de données, via le système d’inventaire, sur la base de la requête unique.
4. Le système de gestion des perturbations selon l’une quelconque des revendications 1 à 3, dans lequel, lors de l’exécution, les instructions amènent par ailleurs le système de gestion des perturbations à :
5 avant la réception de la demande de transfert et en réponse à un changement d’horaire exécuté par le système d’inventaire et affectant le premier itinéraire de voyage de chaque passager, générer un enregistrement de sauvegarde pour chaque passager, via le DCS, incluant la donnée du passager relative au premier itinéraire de voyage du passager.

dans lequel la donnée du passager qui est transférée pour chaque passager vers

10 l’enregistrement associé au second itinéraire de voyage provient de l’enregistrement de sauvegarde.

5. Le système de gestion des perturbations selon la revendication 4 dans lequel le premier itinéraire de voyage de chaque passager comprend un segment de vol commun, le changement d’horaire est lié au segment de vol commun et le changement d’horaire est exécuté dans une fenêtre

15 opérationnelle du segment de vol commun.
6. Le système de gestion des perturbations selon l’une quelconque des revendications 1 à 5 dans lequel la demande de transfert est générée via le DCS.

20
7. Le système de gestion des perturbations selon l’une quelconque des revendications 1 à 6 dans lequel la donnée de l’un des passagers qui est stockée dans la troisième base de données et qui est relative au premier itinéraire de voyage dudit passager inclut une première information de bagage pour ledit passager, la première information de bagage incluant un premier itinéraire de bagage et un identifiant unique, et les instructions lors de l’exécution amènent le système de gestion

25 des perturbations à transférer la donnée de passager stockée pour ledit passager qui est relative au premier itinéraire de voyage dudit passager vers l’enregistrement associé au second itinéraire de voyage inclus dans la troisième base de données, en amenant le système de gestion des perturbations à :

modifier la première information de bagage pour inclure un second itinéraire de bagage basé

30 sur le second itinéraire de voyage ; et ajouter l’information de bagage modifiée à l’enregistrement qui est associé au second itinéraire de voyage, dans lequel l’information de bagage modifiée inclut l’identifiant unique de la première information de bagage.
8. Le système de gestion des perturbations selon i’une quelconque des revendications 1 à 7 5 dans lequel le premier itinéraire de voyage de chaque passager inclut un vol remplacé, le second itinéraire de voyage inclut un nouveau vol qui remplace le vol remplacé du premier itinéraire de voyage de chaque passager et, lors de l’exécution, les instructions amènent par ailleurs le système de gestion des perturbations à :

en réponse à la réception de la demande de transfert et avant l’actualisation de la première et 10 de la seconde base de données, verrouiller le vol remplacé du premier itinéraire de voyage de chaque passager et le nouveau vol.
9. Le système de -gestion des perturbations selon l’une quelconque des revendications 1 à 8 dans lequel, lors de l’exécution, les instructions amènent le système de gestion des perturbations à

15 effectuer, pour chaque passager, le processus de billetterie automatisé pour le second itinéraire de voyage, via le système billettique, en amenant le système de gestion des perturbations à :

pour chaque passager, sélectionner une transaction e-billet qui est sélectionnée dans un groupe comprenant une transaction de revalidation e-billet et une transaction d’échange e-billet ; et transmettre une requête unique au système billettique qui inclut la transaction e-biliet 20 sélectionnée pour chaque passager.
10. Le système de gestion des perturbations selon la revendication 9 dans lequel, lors de l’exécution, les instructions amènent le système de gestion des perturbations à effectuer, pour chaque passager, le processus de billetterie automatisé pour le second itinéraire de voyage, via le

25 système billettique., en amenant par ailleurs le système de gestion des perturbations à :

en réponse à la réception d’un rejet de la requête unique par le système billettique, générer une seconde demande de billetterie séparée pour chaque passager ; et transmettre la demande de billetterie séparée pour chaque passager au système billettique, dans lequel le système billettique traite chaque demande de billetterie séparée, l’une après l’autre.

IL Le système de gestion des perturbations selon ia revendication 9 ou la revendication 10 dans lequel, lors de l’exécution, les instructions amènent le système de gestion des perturbations à effectuer le processus de billetterie automatisé pour chaque passager pour le second itinéraire de voyage, via le système billettique, en amenant par ailleurs le système de gestion des perturbations

5 à:

effectuer la transaction e-billet sélectionnée pour chaque passager, via le système billettique ; et en réponse à la réalisation, par le système billettique, de la transaction e-billet sélectionnée pour chaque passager :

10 déterminer une pluralité de documents, EMD, de coupons électroniques variés, associés aux passagers ; et pour chaque coupon EMD ; sélectionner et effectuer une transaction EMD pour le coupon EMD qui est sélectionnée dans un groupe comprenant une transaction de dissociation EMD ; une transaction d’association EMD ; et une transaction d’échange ÊMD.
12. Un procédé pour coordonner, après une perturbation, les opérations d’une pluralité de systèmes connectés via un réseau informatique, inclus dans un système de gestion des perturbations, les systèmes comprenant :

un système d’inventaire comprenant une première base de données incluant une pluralité de 20 compteurs, chacun des compteurs suivant une valeur de disponibilité pour un produit de voyage ;

un système de réservation comprenant une seconde base de données incluant un ou plusieurs enregistrements de réservation pour une pluralité de passagers, chacun des passagers étant inclus dans l’un d’un ou de plusieurs enregistrements de réservation et étant associé, dans ledit enregistrement de réservation, à un premier itinéraire de voyage sur lequel le passager est réservé.

25 un système de contrôle des départs» comprenant une troisième base de données incluant une donnée de passager stockée pour chaque passager qui est associée au premier itinéraire de voyage du passager ; et un système billettique comprenant une quatrième base de données qui inclut un e-billet pour chaque passager,

30 le procédé comprenant ;

la réception par le système de gestion des perturbations, après la perturbation du premier itinéraire de voyage» d’une demande de transfert incluant les passagers et au moins une portion d’un second itinéraire de voyage pour remplacer le premier itinéraire de voyage de chaque passager ; et en réponse à la réception de la demande de transfert par le système de gestion des perturbations :

5 l’actualisation automatique des compteurs de la première base de données sur la base du premier itinéraire de voyage de chaque passager et du second itinéraire de voyage, via le système d'inventaire ;

l'actualisation automatique dudit ou de plusieurs enregistrements de réservation de la seconde base de données, via le système de réservation, pour

10 refléter une association entre chaque passager et le second itinéraire de voyage ; et après que la première et la seconde base de données ont été actualisées :

la mise en œuvre automatique d’un processus de billetterie automatisé pour chaque passager, via le système billettique, pour le second itinéraire de voyage ; et
15 pour chaque passager, le transfert automatique de la donnée du passager relative au premier itinéraire de voyage, via le DCS, vers un enregistrement inclus dans la troisième base de données qui est associé au second itinéraire de voyage.
20 13. Un produit-programme d’ordinateur pour coordonner, après une perturbation, les opérations d’une pluralité de systèmes connectés via un réseau informatique inclus dans un système de gestion des perturbations, les systèmes comprenant :

un système d’inventaire comprenant une première base de données qui inclut une pluralité de compteurs, chacun des compteurs suivant une valeur de disponibilité pour un produit de voyage ;
25 un système de réservation comprenant une seconde base de données incluant un ou plusieurs enregistrements de réservation pour une pluralité de passagers, chacun des passagers étant inclus dans un d’un ou de plusieurs enregistrements de réservation et étant associé dans ledit enregistrement de réservation à un premier itinéraire de voyage sur lequel le passager est réservé.

un système de contrôle des départs comprenant une troisième base de données incluant la
30 donnée de passager stockée pour chaque passager qui est relative au premier itinéraire de voyage du passager; et un système bîllettique comprenant une quatrième base de données incluant un e-billet pour chaque passager, le produit-programme d'ordinateur comprenant ;

un code de programme enregistré sur un support lisible par ordinateur pour mettre en œuvre 5 les étapes du procédé selon la revendication 12 lorsque ledit programme fonctionne sur un ordinateur.

1/5