FR 3042297 A1 20170414 FR 1559705 A 20151013 1 PRODUCTION DE RENDEMENTS EN UTILISANT LES DONNÉES RELATIVES À L'INVENTAIRE DE PRODUITS NON UTILISÉS CONTEXTE [0001] L'invention de façon générale concerne des ordinateurs et des logiciels, notamment des systèmes, des méthodes et des programmes informatiques qui déterminent un rendement pour des unités d'inventaire ayant une date d'expiration. [0002] Les produits de services, tels que des places sur un vol, les chambres d'hôtel ou les voitures de location, ont plusieurs caractéristiques qui présentent des défis lorsqu'il s'agit de déterminer leur prix de vente. L'une des caractéristiques est que les produits de services ont un inventaire dont la durée de vie est limitée. C'est-à-dire, si le produit n'est pas vendu avant une date et/ou heure limite de disponibilité pour son utilisation, la « date d'expiration », le produit est perdu. Par exemple, une fois qu'un avion a décollé, la recette qui aurait pu être obtenue pour un siège resté invendu n'a pu être réalisée et ne peut plus être remplacée. De même, toute recette perdue pour une chambre d'hôtel inoccupée ou une voiture non louée est définitivement perdue. Les produits de services ont tendance à avoir un inventaire dont la capacité est relativement fixe. C'est-à-dire qu'il est généralement difficile et coûteux pour un fournisseur de services d'en ajuster la capacité afin de répondre aux fluctuations de la demande. Les produits de services sont aussi typiquement achetés bien avant leur utilisation voulue, parfois des semaines ou des mois à l'avance, avant que la demande pour le produit de service à la date en question soit entièrement connue. [0003] Lorsqu'il fait face à une offre pour acheter un produit, le fournisseur de services doit faire un choix : accepter l'offre, ou espérer une meilleure offre avant la date d'expiration. S'il reçoit une meilleure offre, le fournisseur peut réaliser une plus grande marge bénéficiaire sur la vente du produit. Cependant, si une meilleure offre ne se matérialise pas, et qu'une portion del'inventaire n'est pas vendue, le fournisseur perdra le chiffre d'affaires qu'il aurait pu obtenir en acceptant l'offre antérieure. Ainsi, lorsqu'ils fixent les prix, les fournisseurs de services doivent peser la probabilité de recevoir une meilleure offre après que leur inventaire a été entièrement vendu contre la probabilité que l'inventaire invendu sera perdu. 3042297 [0004] Le processus qui comprend fixer les prix dans l'industrie de services est souvent désigné comme la gestion du chiffre d'affaires. L'objectif de la gestion du chiffre d'affaires est d'optimiser le chiffre d'affaires par la tarification et le contrôle-d'inventaire. Le contrôle des prix comprend généralement la segmentation de l'inventaire en établissant une pluralité de classes au sein de l'inventaire, avec un prix différent offert pour chaque classe. Le contrôle d'inventaire détermine ensuite la quantité de l'inventaire disponible à affecter à chaque classe, dans le but de vendre l'inventaire autant que possible sans avoir à refuser des offres pour acheter de l'inventaire affecté à des classes de prix supérieures. [0005] La tarification et le contrôle d'inventaire sont généralement basés sur des projections de prix, qui réfèrent au rendement du produit, afin de déterminer à la fois la répartition de l'inventaire entre les classes, et un inventaire de prix à l'intérieur de chaque classe. Si les projections de rendement sont erronées, une trop grande quantité de l'inventaire peut être affectée à une classe inappropriée, et donner lieu à un inventaire insuffisant pour répondre à la demande des classes tarifées à un prix plus élevé. Quel que soit le cas, une partie du chiffre d'affaires peut être perdu. [0006] Donc, des systèmes, méthodes et programmes informatiques améliorés, qui déterminent le rendement des produits dont la durée de vie est limitée, sont nécessaires. RÉSUMÉ [0007] Dans l'un des modes de réalisation de l'invention, un système qui détermine un rendement pour l'inventaire restant d'un premier produit dont la première date d'expiration est fournie, le système comprend un ou deux processeurs en communication avec une mémoire. La mémoire stocke les données d'un programme codé qui, lorsqu'il est exécuté par un ou plusieurs processeurs enclenche le système qui va déterminer, avant la date d'expiration, un premier prix pour la première unité du premier produit qui est réservé, un second prix pour une seconde unité du premier produit qui est disponible, et un troisième prix payé pour une troisième unité d'un second produit dont la date/heure limite de validité est passée. Le programme codé enclenche par ailleurs le système qui détermine le rendement pour le reste de l'inventaire sur la base d'une somme pondérée du premier prix, du second prix et du troisième prix. Le programme codé par ailleurs enclenche le système à déterminer le second prix pour la seconde unité du premier 3042297 3 produit en déterminant une demande attendue pour le premier produit ; sur la base de la demande prévue, à générer une demande de réservation simulée pour la seconde unité du premier produit ; en déterminant la disponibilité du premier produit sur la base de l'inventaire restant ; générer un dossier de réservation simulée pour la seconde unité, en réponse à une disponibilité suffisante pour satisfaire la demande de réservation simulée ; en générant un billet proxy pour le dossier de réservation simulée dans lequel le billet proxy simulé a une même structure que des billets confirmés normaux ; en déterminant un contexte tarifaire pour le billet proxy ; et en tarifiant le billet proxy en utilisant le contexte tarifaire pour produire le second prix. [0008] Selon un aspect supplémentaire, le programme codé enclenche le système qui détermine le premier prix en transmettant une requête à une première base de données de dossiers de réservation, cette requête demandant à la première base de données le renvoi de dossiers de réservation pour des unités du premier produit qui ont été réservées ; en recevant un dossier de réservation pour un itinéraire incluant la première unité de la première base de données ; en générant un billet proxy pour la première unité basée sur le dossier de réservation ; en déterminant un contexte tarifaire pour le billet proxy ; et en attribuant un prix au billet proxy en utilisant le contexte tarifaire pour déterminer le premier prix. [0009] Selon un autre aspect supplémentaire, le programme codé enclenche le système qui détermine le premier prix en transmettant une requête à une base de données de billets, cette requête demandant à la base de données le renvoi de billets pour des unités achetées du premier produit ; et en recevant un premier billet de la base de données, le premier billet incluant un premier prix. BRÈVE DESCRIPTION DES DESSINS [0010] Les dessins qui sont intégrés et accompagnent les présentes constituent une partie de cette spécification ; ils illustrent une variété de modes de réalisation de l'invention et, avec la description générale de l'invention ci-dessus et la description détaillée des modes de réalisation ci-dessous, servent à expliquer les modes de réalisation de l'invention. [0011] FIG. 1 représente une vue schématique d'un environnement d'exploitation exemplaire comprenant, un système de réservation, un système billettique, un système tarifaire, un système de gestion des chiffre d'affaires et un générateur de rendement en communication via un réseau. 3042297 4 [0012] FIG. 2 est une vue schématique d'un ordinateur exemplaire abritant le système de réservation, le système billettique, le système tarifaire, le système de gestion des chiffre d'affaires, et le générateur de rendement de la FIG. 1. [0013] FIG. 3 est une vue schématique apportant des détails supplémentaires relatifs au système de réservation, au système billettique, au système tarifaire, et au générateur de rendement de la FIG. 1. [0014] FIG. 4 est une vue graphique illustrant une distribution entre des billets utilisés, des billets réservés, des billets proxy, et des billets simulés proxy qui peuvent être utilisés par le générateur de rendement de la FIG. 3 afin de déterminer le rendement. [0015] FIG. 5 est une vue schématique illustrant la relation entre le temps et un dossier de réservation utilisée, un fichier d'une réservation partiellement utilisée, et un fichier d'une réservation non utilisée. DESCRIPTION DÉTAILLÉE [0016] Les modes de réalisation de l'invention peuvent être implémentés par un système de traitement et de base de données. Le système de traitement et de base de données peut comprendre un ou plusieurs sous-systèmes informatiques, tels qu'un système de réservation, un système billettique, un système tarifaire, un système de gestion du chiffre d'affaires, et un générateur de rendement. Chacun de ces systèmes, peut faire partie, ou être fourni, par un système de distribution global (Gin, un système géré par un transporteur, ou autre fournisseur de produits de voyage, ou tout autre système approprié de traitement et de base de données. [0017] Le générateur de rendement peut fonctionner en coopération avec les autres systèmes pour déterminer le rendement d'unités invendues d'un inventaire de produits de voyage. Les produits de voyage peuvent comprendre des sièges sur un transporteur (par exemple un avion ou un train), des voitures de location, des chambres d'hôtel, ou des accès à des activités et des divertissements. Pour déterminer le rendement, le générateur de rendement peut obtenir des données relatives à l'historique des prix appliqués aux produits réservés qui n'ont pas été utilisés, aux prix des billets proxy pour des produits réservés qui n'ont pas été confirmés, aux prix des billets proxy pour des réservations simulées de produits d'inventaire qui n'ont pas été réservés. Le générateur de rendement peut produire le 3042297 rendement sous forme de somme pondérée de ces prix, et fournir le rendement à un système de gestion du chiffre d'affaires. Le système de gestion du chiffre d'affaires peut ensuite déterminer la tarification et l'affectation de l'inventaire en se basant, au moins en partie, sur le rendement. [0018] Référence est maintenant faite à la FIG. 1; un système d'exploitation 10 conformément à un mode de réalisation de l'invention peut comprendre un système de réservation 12, un système billettique 14, un système tarifaire 16, un système de gestion des chiffre d'affaires 18, et un générateur de rendement 20. Chacun des systèmes : le système de réservations 12, le système billettique 14, le système tarifaire 16, le système de gestion des chiffre d'affaires 18 et le générateur de rendement 20, peut communiquer grâce à un réseau 22. Le réseau 22 peut inclure un ou plusieurs réseaux publics ou privés (par exemple Internet) qui permettent l'échange de données. [0019] Le système de réservation 12 peut gérer l'information et faire des transactions relatives à la gestion de l'inventaire, il peut fixer les prix, réserver, et confirmer les réservations de produits de voyage tels que des vols. Dans ce but, le système de réservation 12 peut comporter un système de gestion d'inventaire qui maintient une base de données des sièges disponibles, ou unités de l'inventaire, pour chaque vol exploité par un transporteur. Le système de gestion d'inventaire peut déterminer la disponibilité et le prix des unités de l'inventaire et peut être intégré avec le système de réservation 12, ou fourni séparément. Le système de gestion d'inventaire peut définir combien de sièges sont disponibles sur un vol particulier ou sur un marché particulier en ouvrant et en fermant des classes individuelles de réservations conformément aux règles définies par le transporteur ou par le système de gestion des chiffre d'affaires. Dans le contexte des transports aériens, une unité d'inventaire disponible dans le système de gestion d'inventaire peut ne pas correspondre à un siège physique spécifique dans un avion. Par exemple un inventaire disponible peut excéder le nombre de places physiquement disponibles sur un marché qui permet la surréservation. [0020] Le système de réservations 12 peut être géré par le fournisseur (par exemple un transporteur), ou par un tiers autorisé par le fournisseur pour gérer le système de réservations 12. Le système de réservations 12 peut abriter une ou plusieurs bases de données 3042297 6 qui maintiennent les données permettant de suivre la vente et la disponibilité de l'inventaire. Le système de réservation 12 peut être lié à, ou abriter par, un système de distribution global (GDS) (qui n'est pas illustré) pouvant fournir un accès aux systèmes de réservation de multiples fournisseurs. Le système de réservations 12 peut permettre à des utilisateurs habilités de réserver, confirmer des réservations et payer des unités d'inventaire telles que des billets d'avion. Le système de réservation 12 peut aussi interagir avec d'autres systèmes de réservation et le système de vendeurs tiers {non illustré), soit directement ou par le GDS, afin de permettre à un transporteur émetteur ou à un vendeur tiers de vendre des billets pour des sièges fournis par un transporteur de fait. Le transporteur de fait peut ensuite facturer le transporteur émetteur pour les services fournis. Le système de réservation 12 peut aussi répondre à des requêtes en provenance d'autres systèmes concernant les données de l'itinéraire, comme les données relatives au vol ou au passager. [0021] Le système billettique 14 peut comporter un système informatique configuré pour entretenir les dossiers de réservation confirmée et l'utilisation des billets. Ces fichiers peuvent comporter des billets électroniques enregistrés dans une ou plusieurs bases de données. Le système billettique 14 peut surveiller le statut de billets délivrés pour des produits de voyage tels que les vols en stockant et en extrayant les données dans les bases de données. L'achat d'un billet peut impliquer la tarification, la confirmation et l'émission de billets du produit de voyage sous-jacent. Le billet électronique peut comporter un ou plusieurs coupons électroniques. Chaque coupon peut correspondre à un ou plusieurs segments ou produits de l'itinéraire de voyage défini par un dossier de réservation correspondant dans une base de données de dossiers de réservation. Les coupons de billets électroniques peuvent identifier les segments pour lesquels le billet peut être utilisé pour obtenir une carte d'embarquement, ou autre produit qui compose l'itinéraire de voyage. En plus de l'émission de billets pour des produits dont la réservation pour un voyage futur a été confirmée, le système billettique 14 peut maintenir des bases de données qui stockent les documents électroniques relatifs aux billets émis pour des produits utilisés, des billets proxy pour des produits qui ont été réservés, mais pas confirmés, et des billets proxy pour des produits qui n'ont été ni réservés ni confirmés. 3042297 7 [0022] Le système tarifaire 16 peut déterminer les prix pour des unités sur la base d'un contexte tarifaire. Le contexte tarifaire peut comporter des paramètres qui définissent un ensemble de conditions gouvernant la tarification des unités d'inventaire. Des exemples de contexte tarifaire pour les transports aériens peuvent inclure, de façon non exhaustive, une date tarifaire, un code de guichet qui identifie le guichet émetteur du billet, un code identifiant le type de passager (par exemple, enfant, adulte, adulte en liste d'attente, militaire, etc.. ), un code de société qui identifie un tarif négocié ou une remise à laquelle le passager a droit, et un code de classe de réservation qui identifie une classe de service (par exemple première classe, classe business, classe économique, etc.) [0023] Dans le contexte des transports aériens, chaque unité d'inventaire peut comporter une ou plusieurs « unités monnayables ». Une unité monnayable est une combinaison d'un ou plusieurs segments qui entrent dans la composition d'un vol, entre un point de départ et un point de destination qui est desservi par le transporteur. L'unité monnayable peut par conséquent être la plus simple combinaison de segments qui peut être réservée, confirmée et dont le billet peut être émis. L'unité la plus simple à tarifer est l'unité représentant un aller simple qui peut comporter un seul segment. D'autres unités monnayables peuvent inclure des allers-retours et des vols comprenant de multiples segments pour compléter une boucle aller-retour. Un vol confirmé peut inclure une ou plusieurs unités monnayables, chaque unité comportant un ou plusieurs segments. [0024] Le système tarifaire 16 peut maintenir une base de données de tarifs 24 (FIG. 3), dont chaque tarif est enregistré dans un fichier de la base de données. Chaque fichier de la base de données peut être associé avec un ou plusieurs paramètres correspondants compris dans le contexte tarifaire et dans les segments compris dans l'unité d'inventaire pour laquelle le prix est déterminé. Le système tarifaire 16 peut donc déterminer un prix pour une unité particulière de l'inventaire en exploitant la base de données à la recherche de prix correspondant au contexte tarifaire du vol ou d'autre produit de voyage, en question. La base de données tarifaire 24 peut être actualisée régulièrement, par exemple une fois par jour, par des données fournies par le transporteur. 3042297 s [0025] Le système de gestion des chiffre d'affaires 18 peut être configuré pour déterminer l'impact d'un revenu futur escompté résultant de la mise à disponibilité pour la vente d'unités d'inventaire dans chacune de plusieurs classes de réservations afin de fournir une tarificatkin segmentée. Le système de gestion des chiffre d'affaires peut déterminer des niveaux de disponibilité et les prix afin d'optimiser les chiffre ereffeires générées par la vente de l'inventaire. Dans certains cas, cela peut impliquer de réduire autant que se peut l'inventaire qui reste invendu, tel que les sièges vides dans un avion, les chambres inoccupées dans un hôtel, les voitures non louées pour une entreprise de location de véhicules, ou tout autre inventaire dont la durée de vie est limitée. Le produit de voyage qui peut avoir un inventaire limité et une durée de vie limitée doit être vendu avant la date d'expiration pour éviter les pertes résultant d'unités d'inventaire invendues. [0026] Par exemple, un transporteur peut avoir un nombre maximum de sièges disponibles dans une cabine, ou dans chacune de plusieurs cabines, sur un marché ou un vol spécifique. Une fois que l'avion a quitté la porte d'embarquement, la possibilité de générer des chiffre d'affaires pour des sièges invendus est perdue à jamais, et le produit est considéré comme perdu ou gâché. Dans ce cas exemplaire, la péremption actuelle peut survenir avant le départ si on prend en compte le temps nécessaire pour traiter le billet, l'enregistrement, le filtrage de sécurité, l'embarquement, et ainsi de suite. Les services de voyages autres que les sièges d'avion peuvent aussi avoir un inventaire limité et une date d'expiration. Par exemple, un hôtel peut avoir un nombre fixe de chambres disponibles, ou une attraction peut avoir un nombre limité de billets qui peuvent être vendus pour un spectacle donné. Quel que soit le cas, les chambres d'hôtel, les voitures de location, ou les billets invendus d'une attraction peuvent également être périmés, car les revenus ne peuvent être restitués pendant la période de non-occupation des chambres, les voitures ne peuvent plus être louées, et les attractions n'ont pas été remplies. [0027] Le système de gestion des chiffre d'affaires 18 peut séparer le processus d'optimisation des chiffre d'affaires en fonctions distinctes comprenant la tarification et le contrôle d'inventaire. Comme expliqué ci-dessus, la tarification peut être segmentée en établissant des classes de réservations, et peut impliquer des prix à l'intérieur des classes pour 3042297 9 chaque marché spécifique. Le contrôle d'un inventaire de produit peut être implémenté en ajustant périodiquement les délais de confirmation des réservations intégrées dans les diverses classes de service afin d'optimiser la diversité des passagers, permettant ainsi de maximiser les chiffre d'affaires générées. En particulier, l'objectif peut être de remplir chaque avion autant que possible sans permettre que les passagers qui réservent tôt en bénéficiant d'un tarif réduit prennent la place de passagers qui réservent tardivement en payant un plein tarif. [0028] Le coût imputé à une unité d'inventaire invendue peut être la valeur actuelle prévue pour la vente de l'unité à un moment donné dans le futur, ou « le coût d'opportunité » de l'unité. Le coût d'opportunité, ou « prix de l'offre » peut varier selon le volume d'inventaire restant et la durée restante jusqu'à la date d'expiration. Le prix de l'offre peut représenter un revenu escompté probabiliste pour le prochain siège mis en vente d'un inventaire restant donné et le temps restant jusqu'à la fin de vie du service. Afin de maximiser les chiffre d'affaires pour cet inventaire limité, le système de gestion des chiffre d'affaires 18 peut ouvrir et fermer certaines classes de services selon le prix d'offre. Cette stratégie de portail peut être basée sur les prix d'offre calculés périodiquement (quotidiennement, par exemple), qui peuvent en retour être utilisés pour déterminer la disponibilité de chaque classe de réservation. En traçant le prix d'offre par opposition aux unités d'inventaire restantes n dans le temps t on peut produire un vecteur offre prix PO(n, t). Le vecteur offre prix PO(n, t) peut fournir un prix minimum que le transporteur doit accepter pour confirmer le prochain siège disponible d'un inventaire restant donné n et un temps t. [0029] Le système de gestion 18 peut déterminer combien d'unités de l'inventaire restant doivent être mises à disposition dans chaque classe de réservations, sur la base du prix d'offre et du rendement. Le rendement peut refléter les revenus escomptés par unité vendue et peut varier par classe de réservation, marché et date d'expiration des unités d'inventaire. Si le prix d'offre est inférieur au rendement, les unités d'inventaire doivent typiquement être mises à disposition dans les classes de réservations. Par contraste, si le prix d'offre est supérieur au rendement, la classe de réservation doit être fermée puisque le coût d'opportunité de la prochaine unité d'inventaire dépasse le prix de vente attendu du billet. Puisque le rendement affecte directement le nombre d'unités d'inventaire qui doivent être mises à disposition pour 3042297 chaque classe de réservation afin d'optimiser les chiffre d'affaires, l'exactitude du rendement attendu peut contribuer à la performance du système de gestion des chiffre d'affaires 18. Ainsi une augmentation de la qualité de la prédiction de rendement peut améliorer la façon dont le système de gestion des chiffre d'affaires 18 fixe les prix et répartit l'inventaire entre les classes de réservations. Les améliorations visant l'exactitude de la prédiction du rendement peuvent donc augmenter à la fois les chiffre d'affaires du fournisseur, mais aussi la satisfaction du client grâce à des remises dans le cas d'embarquements refusés et/ou du manque d'unités disponibles pour les passagers qui paient plein tarif qui réservent plus tard. [0030] Dans ce but, le générateur de rendement 20 peut déterminer les rendements pour les unités d'inventaire, et fournir ces rendements au système de gestion des chiffre d'affaires 18. Le générateur de rendement 20 peut produire le rendement sur la base des prix historiques des unités vendues, des prix des unités dont la réservation est actuellement confirmée, mais qui sont toujours inutilisées, et des prix des unités non réservées. En utilisant les données disponibles relatives aux utilisations futures attendues des unités réservées/confirmées, des unités réservées et des unités non réservées avec les données historiques, le générateur de rendement 20 peut déterminer le rendement de façon plus juste que les systèmes conventionnels qui s'appuient uniquement sur les données historiques. [0031] Référence est maintenant faite à la FIG. 2, le système de réservations 12, le système billettique 14, le système tarifaire 16, le système de gestion des chiffre d'affaires 18, et le générateur de rendement 20 de l'environnement d'exploitation 10, peuvent être implémentés sur un ou plusieurs matériels informatiques ou systèmes, tels que l'ordinateur exemplaire 30. L'ordinateur 30 peut inclure un processeur 32, une mémoire 34, un dispositif de mémoire de masse 36, une interface entrée/sortie (I/O) 38, et une interface homme-machine (HM1) 40. L'ordinateur 30 peut également être couplé avec une ou plusieurs ressources extérieures 42 par l'intermédiaire du réseau 42 ou de l'interface I/O 38. Les ressources extérieures peuvent inclure, 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 toute autre ressource informatique appropriée qui peut être utilisée avec l'ordinateur 30. 3042297 11 [0032] Le processeur 32 peut inclure un ou plusieurs dispositifs sélectionnés : microprocesseurs, microcontrôleurs, processeurs de signal numérique, micro-ordinateurs, unités centrales de traitement, réseaux de portes programmables, réseaux logiques programmables, machines à état défini, circuits logiques, circuits analogues, circuits numériques, ou tout autre dispositif servant à manipuler des signaux (analogues ou numériques) sur la base d'instructions de fonctionnement stockées dans la mémoire 34. La mémoire 34 peut inclure un seul dispositif ou une pluralité de dispositifs de mémoire, notamment, mais-de façon non exhaustive, la mémoire à lecture seule (ROM), la mémoire à accès aléatoire (RAM), la mémoire volatile, la mémoire non volatile, la mémoire vive statique (SRAM), la mémoire dynamique à accès aléatoire (DRAM), la mémoire flash, la mémoire cache, ou tout autre dispositif capable de stocker l'information. Le dispositif de mémoire de masse 36 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 l'information. [0033] Le processeur 32 peut fonctionner sous le contrôle d'un système d'exploitation 44 qui réside dans la mémoire 34. Le système d'exploitation 44 peut gérer les ressources informatiques afin que le programme codé de l'ordinateur, intégré sous forme d'un ou plusieurs logiciels d'application telle l'application 46 qui réside dans la mémoire 34, puisse recevoir les instructions exécutées par le processeur 32. Le processeur 32 peut aussi exécuter l'application 46 directement, et dans ce cas le système d'exploitation 44 peut être omis. Le ou les logiciels d'application peuvent inclure un exemple de fonctionnement comportant un serveur capable d'accepter des demandes de la part des applications clientes et de leur fournir des réponses. Une ou plusieurs structures de données 48 peuvent aussi résider dans la mémoire 34 et peuvent être utilisées par le processeur 32, le système d'exploitation 44, ou l'application 46 pour stocker ou manipuler des données. [0034] L'interface I/O 38 peut fournir une interface machine qui lors du fonctionnement couple le processeur 32 à d'autres dispositifs et systèmes, tels que le réseau 22 ou la ressource externe 42. L'applicatton 46 peut donc coopérer avec le réseau 22 ou la ressource externe 42 en communiquant par l'interface I/O 38 pour fournir les divers éléments, fonctions, 3042297 12 applications, processus, ou modules composant les modes de réalisation de l'invention. L'application 46 peut aussi disposer d'un programme codé qui est exécuté par une ou plusieurs ressources externes 42, ou autrement repose sur les fonctions ou signaux fournis par le système ou les composants réseau externes à l'ordinateur 30. En effet, au vu des configurations presque infinies de matériel informatique et logiciels possible, les professionnels disposant .de compétences ordinaires comprendront que les modes de réalisation de l'invention peuvent inclure des applications localisées extérieures à l'ordinateur 30, distribuées à des ordinateurs multiples ou à d'autres ressources externes 42, ou fournis par des ressources informatiques (matériel et logiciel) qui sont fournies par un service tel un service informatique cloud, par l'intermédiaire du réseau 22. [0035] Le HMI 40 peut être couplé dans son fonctionnement avec le processeur 32 de l'ordinateur 30 pour permettre à l'utilisateur d'interagir directement avec l'ordinateur 30. Le HMI 40 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 40 peut aussi inclure des dispositifs et 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 entrées de l'utilisateur et de les transmettre dans le processeur 32. [0036] Une base de données 50 peut résider dans le dispositif de mémoire de masse 36 et peut être utilisée pour collecter et organiser les données utilisées par divers systèmes et modules décrits dans la demande présente. La base de données 50 peut inclure et supporter des structures de données qui stockent et qui organisent les données. En particulier, la base de données 50 peut être aménagée avec toute organisation ou structure de base de données, notamment, 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, une base de données orientée objet, ou des combinaisons de celles-là. [0037] Un système de gestion de bases de données sous forme de logiciel d'application qui s'exécute sous la forme d'instructions sur le processeur 32 peut être utilisé pour accéder à l'information ou aux données stockées dans des fichiers de la base de données 50 en réponse à 3042297 13 une requête, lorsqu'une requête peut être déterminée de façon dynamique et exécutée par le système d'exploitation 44, les autres applications 46, ou un ou plusieurs modules. Bien que des modes de réalisation de l'invention puissent être décrits dans les présentes en utilisant une terminologie propre aux diverses bases de données relationnelles, hiérarchiques, en réseau, orientées objet ou autre, les hommes de métier disposant de compétences ordinaires comprendront que les modes de réalisation de l'invention peuvent utiliser tout modèle approprié de gestion de base de données et qu'ils ne sont pas (imités à un type de base de données particulier. [0038] FIG. 3 illustre le système de réservation 12, le système billettique 14, le système tarifaire 16 et le générateur de rendement 20 de façon plus détaillée. Le système de réservation 12 peut inclure une base de données des réservations utilisées 52, une base de données des réservations non utilisées 54, une base de données des réservations confirmées 56 et une base de données de réservations simulées 58. La base de données des réservations utilisées 52 peut contenir des dossiers de réservation correspondants aux réservations composées d'unités qui ont été réservées et utilisées, par exemple des unités de réservations confirmées dont la date d'expiration est passée. La base de données des réservations inutilisées 54, peut contenir des dossiers de réservation correspondant aux réservations dont des unités ont été réservées, mais n'ont pas été confirmées et dont la date d'expiration est passée. [0039] La base de données des réservations confirmées 56 peut contenir des dossiers de réservation correspondant aux réservations composées d'unités qui ont été réservées et confirmées, mais n'ont pas été utilisées (par exemple, des réservations confirmées pour des unités, dont la date d'expiration est dans le futur). La base de données des réservations simulées 58 peut contenir des dossiers de réservation simulée pour des unités qui n'ont pas été réservées. Un dossier de réservation simulée peut être généré lorsqu'une simulation de réservation est fournie au système de réservation 12. Le nombre et le type de réservation simulée peuvent être déterminés sur la base de la demande attendue pour des unités. Le système de réservations 12 peut être configuré pour reconnaître les dossiers de réservation 3042297 14 simulée afin qu'ils ne bloquent pas des unités de l'inventaire, permettant ainsi aux unités d'être réservées par les voyageurs. [0040] Dans un mode de réalisation de l'invention, un ou plusieurs des dossiers de réservation peuvent comporter un fichier de nom de passager (FNP). Chaque dossier de réservation peut être généré, au moins en partie, par le système de réservation 12 et peut comporter un ou plusieurs fichiers de base de données qui contiennent l'information du passager et l'itinéraire associés avec un ou plusieurs sièges réservés sur un vol. La base de données des réservations utilisées 52, la base de données des réservations inutilisées, la base de données des réservations confirmées 56 et la base de données des réservations simulées 58 peuvent être indépendantes ou organisées en partitions dans une seule base de données. Une ou plusieurs de ces bases de données peuvent être accessibles à d'autres systèmes tels un système de gestion des clients (non illustré) et peuvent inclure des fichiers qui contiennent des données définissant un itinéraire pour un voyage particulier, un passager, ou un groupe de passagers. L'itinéraire défini peut comprendre les produits de voyage d'un ou de plusieurs fournisseurs de produits de voyage. Quel que soit le cas, pour faciliter la recherche de fichiers dans chaque base de données, un système de repérage de fichier ou tout autre identifiant approprié de fichier peut être associé à chaque dossier de réservation. [0041] Le système billettique 14 peut inclure une base de données des billets utilisés 60, une base de données des billets proxy 62, une base de données des billets confirmés 64 et une base de données des billets simulés proxy. Les bases de données billettiques 60, 62, 64, 66 peuvent comporter des bases de données indépendantes, ou des partitions à l'intérieur d'une seule base de données billettique. La base de données des billets utilisés 60 peut comporter des fichiers correspondants à des billets électroniques pour des unités d'inventaire qui ont été confirmées et utilisées, par exemple les billets de vols utilisés. La base de données des billets réservés proxy 62 peut contenir des fichiers correspondant à des billets proxy pour des unités d'inventaire réservées, mais pas encore confirmées et dont la date d'expiration n'est pas encore passée. La base de données des billets confirmés 64 peut contenir des fichiers correspondant à des billets pour des unités qui ont été confirmées, mais qui n'ont pas encore été utilisées, par exemple, des réservations confirmées pour des unités dont la date 3042297 15 d'expiration est dans le futur. La base de données des billets simulés proxy 66 peut contenir des fichiers correspondant à des billets proxy pour des unités d'inventaire qui n'ont pas encore été réservées, par exemple, des unités d'inventaire correspondant à des dossiers de réservation simulée provenant de la base de données de réservations simulées 58. [0042] Le générateur de rendement 20 peut inclure un moteur de rendement 68 et une base de données de billets composites 70. Le moteur de rendement 68 peut être configuré pour générer un rendement pour une ou plusieurs unités d'inventaire dans chaque classe de réservation sur la base des prix des billets dans la base de données des billets composites 70. La base de données des billets composites 70 peut contenir des fichiers correspondants à des billets provenant de la base de données des billets utilisés 60, de la base de données des billets réservés proxy 62, de la base de données des billets confirmés 64, et de la base de données des billets simulés proxy 66. La base de données des billets composites 70 peut ainsi maintenir des fichiers qui fournissent les prix de produits de voyage utilisés (par exemple, les billets de vols utilisés), des produits de voyage réservés qui ne sont pas encore utilisés (par exemple, les billets émis pour des vols qui ne sont pas encore partis) et pour des produits de voyage toujours non réservés (par exemple, les sièges disponibles sur un vol). Comme nous le verrons plus en détail ci-dessous, le moteur de rendement 68 peut déterminer le rendement en calculant une moyenne pondérée des prix pour chacune de ces quatre catégories de données tarifaires. [0043] Référence est maintenant faite à la FIG. 4, un schéma graphique montre un graphique en barres 72 qui illustre une distribution exemplaire des types de données fournies et maintenues par la base de données de billets composites 70. Le graphique en barres 72 comprend un axe vertical 74 qui correspond à un facteur de pondération (par exemple, le ratio entre le nombre d'unités d'inventaire utilisées et le nombre d'unités d'inventaire disponibles) et un axe horizontal 76 qui correspond au facteur temps. Une ligne brisée horizontale 78 peut représenter un facteur pondéral de 100 %, et une ligne verticale 80 peut indiquer le temps présent, ou t = 0. Les barres à gauche de la ligne verticale 80 peuvent représenter des données historiques de vente et les barres à droite de la ligne verticale 80 peuvent représenter de futures données de ventes anticipées. L'axe vertical 74 peut intersecter avec l'axe horizontal 76 à un point dans le temps N unités de temps (par exemple, 365 jours) dans le passé ou t = - N. La 3042297 ligne 82 peut intersecter avec l'axe horizontal 76 à un point dans le temps qui est N unités de temps dans le futur, ou t = + N. La période entre t = 0 et t= + N peut définir une fenêtre de réservation pendant laquelle des unités d'inventaire peuvent être réservées, par exemple, t + 365 jours ou une année dans le futur. [0044] Le graphique en barres 72 comprend une pluralité de barres 84a - 84d, chacune représentant un nombre d'unités d'inventaire. Les hommes de métier disposant de compétences ordinaires comprendront que le nombre réel d'unités de temps pour lesquelles des unités d'inventaires sont affectées peut être différent du nombre de barres 84a - 84d qui est montré à seul titre d'illustration. Les barres 84a à gauche de t = 0 peuvent représenter des nombres d'unités d'inventaire vendues et utilisées dans le passé, par exemple, des billets pour des vols utilisés. Les barres à la droite de t = 0 comprennent les barres 84 b qui peuvent représenter les billets pour des unités d'inventaire réservées et confirmées, 84c qui peuvent représenter des billets réservés proxy pour des unités d'inventaire réservées, mais non confirmées et 84d qui peuvent représenter les billets simulés proxy correspondant à des dossiers de réservation simulée, pour des unités non réservées. [0045] Les dossiers de réservation stockés dans la base de données des réservations confirmées 56 du système de réservation 12 et les billets confirmés qui y sont associés, stockés dans la base de données des billets confirmés 64, peuvent correspondre à des vols qui ne sont pas encore partis, par exemple des vols pour lesquels la fenêtre de réservation est toujours ouverte. Ces billets confirmés peuvent être représentés par les barres 84 b et peuvent fournir des indications sur les nouvelles tendances de réservation pour des parcours et des marchés associés. Cependant, parce que les billets représentés par les barres 84 b ne représentent qu'une portion des réservations finalisées attendues, leur utilisation sans traitement supplémentaire pourrait conduire à des erreurs de prévision de rendement. Par exemple les vols dont la date de départ approche peuvent être presque entièrement pleins [réservations confirmées]. Par contraste, les vols dont la date de départ est plus éloignée dans le futur peuvent être presque vides [peu de réservations confirmées]. Cette relation entre temps et billets confirmés est visible en comparant les dimensions verticales relatives des barres 84b alors que le temps se déplace vers la droite le long de l'axe horizontal 76. De plus, la 3042297 17 distribution du trafic entre les classes de service constatées à un moment t= 0 avec une date de départ t = +m peut s'avérer très différente de la distribution finale du trafic à la date de départ. [0046] Un mécanisme qui peut contribuer aux variations dans la distribution du trafic, alors que la date de départ approche, est ancré dans les différences de comportement entre les personnes qui voyagent pour leurs loisirs et les personnes qui voyagent à titre professionnel. Les personnes voyageant pour les loisirs peuvent être moins enclines à dépenser, ce qui les incite à réserver des classes de service économiques bien avant la date de départ. En comparaison, les personnes qui voyagent pour des raisons professionnelles peuvent être à la fois plus enclines à dépenser en ayant moins de temps pour déterminer leurs besoins de déplacement. Il peut en résulter une tendance des personnes voyageant pour des raisons professionnelles à confirmer des réservations dans des classes de service à un prix plus élevé et à une date plus proche de la date de départ et une tendance inverse pour les personnes qui voyagent pour leurs loisirs. En conséquence, le trafic de distribution déterminé uniquement sur la base des billets existants peut être erroné. [0047] Afin de déterminer les distributions attendues de trafic sur des vols futurs au moment du départ, les modes de réalisation de l'invention peuvent prendre en compte les réservations pour lesquelles un billet n'est pas encore émis et les unités d'inventaire non réservées. Pour prendre en compte les réservations non confirmées, le système billettique 14 peut générer un billet proxy dans la base de données de billets proxy 62 pour chaque siège réservé qui n'a pas encore été confirmé. Chacun de ces billets réservés proxy peut correspondre à une réservation enregistrée dans la base de données des réservations inutilisées 54 du système de réservation 12. Les billets réservés proxy peuvent aussi être transmis et stockés dans la base de données des billets composites 70 pour utilisation par le moteur de rendement 68. Comme l'illustrent les barres 84b et 84c du graphique en barres 72, les billets proxy peuvent être combinés avec des dossiers de réservation dont les tickets ont été émis, pour fournir des données additionnelles utilisées pour le moteur de rendement 68. [0048] Afin de prendre en compte les unités d'inventaire non réservées, le système de réservation 12 peut générer des dossiers de réservation simulée sur la base d'une demande anticipée de sièges pour chaque période entre t = 0 et t = N. Ces dossiers de réservation 3042297 18 simulée peuvent être stockés dans la base de données de réservations simulées 58 pour utilisation par le système billettique 14. Le système billettiquel4 peut générer des billets proxy en utilisant les dossiers de réservation simulée et stocker ces billets de réservations proxy dans la base de données des billets simulés proxy 66. Les billets simulés proxy peuvent aussi être transmis et stockés dans la base de données des billets composites 70 pour utilisation par le moteur de rendement 68. Comme l'illustrent les barres 84d du graphique en barres72, les billets simulés proxy peuvent être combinés avec des billets confirmés (barres 84 b) et les billets réservés proxy (barres 84c) pour fournir un ensemble complet de ventes prévues pour utilisation par le moteur de rendement 68. [0049] Référence est maintenant faite à la FIG. 5 ; nous avons une représentation schématique d'une pluralité de dossiers de réservation 90, 92, 94. Les dossiers de réservation 90, 92, 94, sont représentés par des segments programmés pour un départ à des heures différentes, comme l'indiquent les lignes pointillées 96 - 102. Le dossier de réservation 90 comprend un segment aller 102 et un segment retour 104, chacun ayant une heure de départ correspondante qui est déjà passée, c'est à dire qui est à gauche de la ligne 106 indiquant t = 0, ou temps présent. Ainsi, le dossier de réservation 90 peut représenter une réservation utilisée qui est stockée dans la base de données des réservations utilisées 52. Par contraste, le dossier de réservation 94 comprend un segment aller 108, un segment retour 110, et un segment retour 112, chacun avec une heure de départ correspondant 100-102 dans le futur. Ainsi, le dossier de réservation 90 peut représenter une réservation non utilisée qui est stockée dans la base de données des réservations inutilisées 54. [0050] Par contraste, le dossier de réservation 92 comprend un segment aller 114 avec une heure de départ 9g qui est déjà passée, et un segment de retour 116 avec une heure de départ 99 qui est dans le futur. Parce que le dossier de réservation 92 comprend à la fois un segment utilisé et un segment non utilisé, il est « partiellement utilisé ». Les définitions d'un fichier utilisé, d'un fichier partiellement utilisé, ou d'un fichier inutilisé, lorsqu'elles sont appliquées à des dossiers de réservation peuvent aussi être étendues aux billets comportant des segments multiples. Les segments de vols utilisés et de vols non utilisés des billets 3042297 19 partiellement utilisés peuvent être traités conformément et servir au générateur de rendement 20 pour produire le rendement escompté. [0051] Comme nous l'avons décrit ci-dessus, une unité d'inventaire pour un procluit de voyage peut passer par des états différents dans le temps. L'unité d'inventaire peut initialement naître sous la forme d'un siège disponible sur un vol. En réponse à la demande de réservation d'un voyageur, l'unité d'inventaire peut être associée avec un fichier dans une base de données de réservations, telle que le FNP. Un billet correspondant peut ne pas exister jusqu'à ce que la réservation soit confirmée. La confirmation peut survenir en réponse au règlement par le voyageur des produits de voyage définis dans le dossier de réservation. La confirmation peut être déclenchée, par exemple, par une commande d'impression du billet (par exemple, TTP) dans le système billettique 14. Pour un dossier de réservation comprenant plusieurs passagers, la confirmation de la réservation peut aboutir à la génération de multiples billets par le système billettique, par exemple, un billet pour chaque passager associé au vol confirmé dans le dossier de réservation. Chacun de ces billets nouvellement produits peut être intégré ou être associé à un fichier dans une base de données de billets. Selon un mode de réalisation de l'invention, des entrées peuvent être créées dans une base de données centrale (BDC) du système de billetterie électronique du transporteur ou du GDS. Dans tous les cas, avant l'heure de départ de tout billet, le segment correspondant défini dans le dossier de réservation n'est pas encore utilisé. En d'autres mots, le billet correspondant est pour un vol non utilisé. [0052] Le rendement peut être fourni au système de gestion du chiffre d'affaires comme une valeur monétique, par exemple, le montant du paiement à verser pour confirmer l'achat de l'unité d'inventaire. C'est à dire, que le rendement peut être fourni par le générateur de rendement à partir du dossier passager. Pour faciliter la détermination du rendement, les entrées faites dans le générateur de rendement peuvent aussi être fournies à partir du dossier passager, par exemple, sous forme de billets utilisés, confirmés, ou proxy, plutôt que sous la forme de dossiers de réservation non traités qui pourraient inclurent des passagers multiples. En créant des billets pour chaque dossier de réservation, et en alimentant le moteur de rendement 68 avec ces billets, les modes de réalisation de l'invention peuvent faciliter la 3042297 20 distribution de revenus au niveau des dossiers de réservation entre chaque passager défini dans les dossiers de réservation. Selon un mode de réalisation alternatif de l'invention, les données des dossiers de réservation pourraient être traitées sous un type de document électronique ou dossier, autre qu'un billet, tant que le document qui en résulte a été défini un prix pour le produit de concerné au niveau du dossier passager. [0053] Dans le contexte des transports aériens, des configurations possibles pour fournir le générateur de rendement avec les données des billets 20 peuvent inclure, de façon non exhaustive : une alimentation interactive, le vidage de fichier et l'interrogation de base de données. L'alimentation interactive peut comporter la transmission d'une notification au générateur de rendement 20 en utilisant, par exemple, un EDIFACT (message d'échange de données informatiques pour l'administration, le commerce et les transports). Un exemple d'EDIFACT qui pourrait être utilisé pour transmettre cette notification peut être TKTREQ (demande de billet). Un message peut être transmis pour chaque ticket actualisé, c'est-à-dire chaque fois qu'une entrée est créée, mise à jour, ou supprimée dans la base de données billettique. Les messages peuvent être envoyés chaque fois qu'une modification de la base de données billettique est détectée, ou par lot, à intervalles prédéterminés. Les professionnels disposant de compétences ordinaires en la matière comprendront par ailleurs que des protocoles autres qu'EDIFACT pourraient aussi être utilisés pour transmettre le message susmentionné, tel que XML, binaire, JSON, ou tout autre protocole approprié. [0054] Le vidage de fichiers peut inclure la configuration d'un enclenchement du système billettique 14 qui va déverser les billets de vols utilisés et non entamés dans un fichier d'exportation billettique qui peut ensuite être transmis à la base de données des billets composites 70. L'interrogation de la base de données peut inclure une connexion du générateur de rendement 20, ou l'intégration du générateur de rendement 20 avec le système billettique 14. Dans ce mode de réalisation, le moteur de rendement 68 pourrait interroger les bases de données billettiques 60, 62, 64, 66 directement, et dans ce cas la base de données des billets composite 70 pourrait être omise. [0055] Le rendement de billets de produits de voyage utilisés (les vols utilisés, par exemple) est généralement immuable. Cependant, les rendements déterminés à partir de produits de 3042297 21 voyage inutilisés (par exemple, les billets de vols confirmés et inutilisés, les billets réservés proxy, les billets simulés proxy) peuvent changer si les produits de voyage inutilisés sont échangés, remboursés, ou au final restent non confirmés. Par exemple, le rendement déterminé à partir de billets non utilisés peut changer en réponse à une modification de la réservation, une annulation, un échange des billets non utilisés, ou tout autre événement qui altère le contexte de réservation du billet non utilisé. Afin de prendre en compte les changements affectant les billets non utilisés, des modes de réalisation de l'invention peuvent avertir le générateur de rendement 20 de tout évènement susceptible d'altérer le rendement calculé sur la base de billets non utilisés. Cette notification peut être accomplie en envoyant des messages TKTREQ supplémentaires, en ajoutant un onglet dans des fichiers d'exportation billet-tique, ou toute autre méthode appropriée. [0056] Les modifications apportées à la base de données des billets utilisés 60 sont relativement prévisibles, avec l'ajout de nouveaux fichiers pour les billets utilisés, et la suppression des vieux fichiers au fil du temps. Par contraste, les modifications apportées à la base de données des billets proxy 62, à la base de données des billets confirmés 64, et à la base de données des billets simulés proxy 66 peuvent être relativement fréquentes et aléatoires au fur et à mesure que les réservations et les billets proxy sont mis à jour ou supprimés. Par conséquent, la base de données des billets composites 70 peut être actualisée à partir des bases de données des billets inutilisés ou proxy 62, 64, 66, plus fréquemment qu'à partir de la base de données des billets utilisés 60. [0057] Les données des billets ajoutés à la base de données des billets composites 70 du générateur de rendement 20 peuvent rester inaltérées pendant la durée de conservation des données dans la base de données des billets composites 70. Après chaque période de temps (par exemple, toutes les 24 heures), la base de données des billets composites peut-être enrichie avec les données supplémentaires de billets utilisés pendant une période. Par contraste, des clichés existants de billets inutilisés dans la base de données des billets composites 70 peuvent changer chaque fois que la base de données des billets composites 70 est actualisée en raison de modifications des dossiers de réservation correspondants. L'actualisation des bases de données du système de réservation 12 peut inclure, par exemple, 3042297 22 la création d'une nouvelle réservation, l'annulation d'une réservation existante, ou la modification d'une réservation existante. Ces actualisations peuvent à leur tour enclencher la création de nouveaux billets, ou la mise à jour de tous les billets proxy ou confirmés existants. Les actualisations de la base de données du système billettique 14 peuvent à leur tour enclencher des actualisatkins de la base de données des billets composites 70, comme nous l'avons décrit ci-dessus. [0058] Parce que les billets ne sont pas générés par les systèmes billettiques conventionnels jusqu'à ce que la réservation sous-jacente soit confirmée, les dossiers de réservation non confirmés peuvent ne pas être référencés par les bases de données billettiques conventionnelles. Ainsi, pour utiliser ces fichiers avec un système de billettique conventionnel, le générateur de rendement 20 serait obligé d'extraire les dossiers de réservation non confirmée de la base de données des réservations. Comme nous l'avons décrit ci-dessus, les dossiers de réservation contenant plus d'un passager peuvent être incapables de fournir des données au niveau du dossier passager. Les modes de réalisation de l'invention présente peuvent résoudre ce problème en générant des billets proxy qui utilisent les données extraites des dossiers de réservation non confirmée. [0059] Les billets proxy peuvent être produits de façon régulière en effectuant une numérisation complète de la base de données des réservations dans le système de réservation 12 et en transmettant tout dossier de réservation non confirmée à un module billettique dédié qui génère des billets proxy. Le processus de billetterie proxy peut être mené en parallèle à des processus de billetterie standards appliqués à des dossiers de réservation confirmée. En actionnant la billetterie proxy en parallèle, le système billettique 14 évite que le processus standard d'émission d'un billet ou la base de données des billets confirmés 64 soient affectés par des billets proxy. Le processus d'émission de billets proxy peut dupliquer le processus standard d'émission de billets générant ainsi des billets proxy approprié au calcul des rendements. Les billets proxy peuvent ensuite être stockés dans une base de données dédiée, par exemple, la base de données des billets proxy 62. Dans la mesure où le contenu et la structure des billets proxy et des billets utilisés sont essentiellement les mêmes, les processus décrits ci-dessus tels que l'alimentation interactive, le vidage de fichiers et l'interrogation de 3042297 23 base de données, peuvent également être utilisés par le système billettique 14 afin de les fournir au générateur de rendement 20. [0060] Dans certains cas, un dossier de réservation peut être généré alors qu'il n'est jamais confirmé par le voyageur. C'est-à-dire que le voyageur ne valide pas ou n'effectue p-as de paiement pour le produit de voyage avant sa date d'expiration. Pour empêcher ce type de réservation de bloquer l'inventaire qui pourrait être vendu à un autre voyageur, le système de réservation 12 peut inclure une spécification d'heure/date limite. La spécification heure/date limite peut définir une durée maximum permettant aux dossiers de réservation non confirmée de rester dans le système de réservation 12. Dans ce but, l'élément de limite dans le temps permet de supprimer les dossiers de réservation qui n'ont pas été confirmés avant l'heure/date limite spécifiée. La durée peut être définie sur la base d'un ou de plusieurs critères tels que la date/heure de création de la réservation, une paire comprenant le point de départ et la destination d'un vol réservé, une classe de réservation, ou tout autre critère approprié. [0061] Si le dossier de réservation est supprimé par l'élément heure/date limite, le générateur de rendement 20 peut être notifié afin que les billets correspondants dans la base de données des billets composites 70 soient supprimés pour maintenir la synchronisation avec le système de réservation 12. De façon plus générale, toute actualisation d'un dossier de réservation non confirmée dans le système de réservation 12 peut enclencher une actualisation correspondante du billet proxy associé dans le système billettique 14, ce qui à son tour peut enclencher une actualisation de la base de données de billets composite 70. [0062] Un autre problème qui peut survenir lorsque l'on utilise des dossiers de réservation non confirmée pour générer des données est que les produits de voyage dans les dossiers de réservation non confirmée peuvent ne pas comporter de prix. Pour remédier à ce problème, le générateur de rendement 20 peut interroger le système tarifaire 16 pour attribuer un prix au billet proxy dans la base de données des billets composites. De nouvelles requêtes pour des billets existants proxy peuvent être lancées péritadiquement (par exemple, une fois par jour) pour que les actualisations tarifaires soient capturées dans la base de données de billets composites 70. La tarification peut se faire de façon dynamique en utilisant une requête dynamique, par exemple, en transmettant un message FITQPQ au système tarifaire 16, ou en 3042297 24 mode lot, par exemple en transmettant les billets proxy sous forme d'un fichier. Dans d'autres cas, le système billettique 14 peut effectuer la tarification de billets proxy au fur et à mesure qu'ils sont générés et transmettre les données tarifaires à la base de données de billets composites 70 avec le billet proxy. Une fois tarifés, les billets réservés proxy peuvent être utilisés pour fournir une tarification au moteur de rendement 68 jusqu'à ce que la réservation sous-jacente soit supprimée du système de réservation 12, le billet réservé proxy est remplacé par une image actualisée dans le système billettique, ou le billet réservé proxy est remplacé par un billet confirmé. [0063] Comme nous pouvons le voir d'après les barres 84b et 84c du graphique en barres 72, les billets et les billets réservés proxy ne peuvent fournir qu'une portion de la demande attendue, et ont tendance à fournir moins d'information plus l'horizon de temps est éloigné dans le futur. Pour remédier à ce problème, les dossiers de réservation simulée peuvent être générés dans la base de données des réservations simulées 58 du système de réservation 12. À cette fin, une demande de voyage simulée peut être générée pour le produit de voyages sur une fenêtre de réservation s'étendant de t = 0 jusqu'à = + N (par exemple, à partir d'aujourd'hui jusqu'à 365 jours dans le futur). Cette demande peut être déterminée sur la base de demandes historiques pour des billets et peut inclure des ajustements pour prendre en compte des événements susceptibles d'affecter la demande, par exemple, de nouveaux concurrents entrants sur le marché, un trafic touristique plus élevé que ce qui avait été prévu dû à une demande touristique en hausse, ou tout autre événement susceptible d'affecter la demande. [0064] La demande attendue des voyageurs peut être traitée pour des réservations confirmées en émulant le système de réservation 12, le système d'inventaire du fournisseur, et le comportement du voyageur pour chaque période de la fenêtre de réservation. Le résultat de ce processus peut produire des dossiers de réservation simulée qui peuvent être stockés dans la base de données des réservations simulées 58. Les dossiers de réservation simulée peuvent être générés sur la base des ventes historiques de billets en prenant en compte les billets confirmés existants et les billets réservés proxy pour chaque période. 3042297 25 [0065] Une fois que les dossiers de réservation simulée ont été générés, la base de données des réservations simulées 58 peut-être scannée et des dossiers de réservation simulée sans émission de billet peuvent être transmis au système billettique 14. Le système billettique 14 peut traiter les dossiers de réservation simulée reçus en utilisant un processus dédié parallèle de billetterie qui est séparé du processus de billetterie utilisé pour les réservations confirmées. Le résultat du processus de billetterie parallèle peut produire des tickets simulés proxy, qui peuvent être stockés dans la base de données des tickets simulés proxy 66. Les billets simulés proxy peuvent avoir la même structure que les billets confirmés normaux ce qui leur permet d'être traités par le moteur de rendement 68 en utilisant les mêmes processus que ceux qui sont utilisés avec des billets confirmés, par exemple, une alimentation interactive, un vidage de fichiers, et l'interrogation de base de données. [0066] La base de données de billets composites 70 peut inclure des billets issus de quatre sources notamment des billets utilisés (c'est-à-dire, des données historiques), des billets confirmés inutilisés, des billets réservés proxy qui sont générés à partir de réservations existantes qui n'ont pas encore été confirmées et des billets simulés proxy qui sont générés à partir de dossiers de réservation simulée. Chacune de ces quatre sources de données peut être utilisée par le moteur de rendement 68 afin de produire des rendements pour des unités de temps situées entre t = 0 et t = + N. Les billets dans la base de données de billets composites 70 peuvent avoir la même origine, la même destination, le même point de vente, la même date, la même classe de réservation, etc. que les billets pour lesquels le rendement est déterminé ce qui peut faciliter le processus de génération du rendement. [0067] Le moteur de rendement 68 peut générer un rendement pour un ensemble spécifique de critères en calculant un prix moyen payé par tous les passagers qui ont acheté une unité d'inventaire réunissant l'ensemble des critères. Dans un mode de réalisation de l'invention, le rendement peut être calculé en utilisant une combinaison linéaire de ces quatre sources de données comme suit : 1/1/1 X E Pu + W2 X E PR + W3 x E PRp + W4 x E Psp Rendement = rA, vv1 X Nu + W2 X NB + W3 X Nt& ± W4 X NBp Où les coefficients de pondération W1-W4 représentent chacun un poids correspondant affecté aux données d'origine, c'est à dire, un facteur de confiance attribué à chaque source de 3042297 26 données, IPu représente la somme des prix des billets utilisés, IPB représente la somme des prix des billets confirmés non utilisés, >PRP représente la somme des prix de billets réservés proxy, IPsp représente la somme des prix de billets simulés proxy, Nu représente le nombre de billets utilisés, Ne représente le nombre de billets confirmés inutilisés NRp représente le nombre de billets réservés proxy, et Nsp représente le nombre de billets simulés proxy. [0068] Les coefficients de pondération peuvent être dynamiques, et peuvent évoluer en dépendance pour certains critères, tels que la qualité de la source de données, la route, le marché, heure/date, ou tout autre critère approprié. Les coefficients de pondération peuvent être vus comme des facteurs de confiance, de sorte que les données les plus correctes sont censées être la valeur la plus élevée du coefficient de pondération correspondant. Par exemple, sur une route affectée par de récents événements géopolitiques, les coefficients de pondération peuvent être ajustés pour donner moins de poids aux données de billets utilisés qui sont peut-être des sources de prédiction moindre en raison des changements de l'environnement tarifaire, et plus de poids aux données des billets simulés non utilisés puisque les données futures peuvent être plus représentatives des tendances du nouveau marché. [0069] Par exemple, une valeur de rendement est calculée ci-dessous selon un ensemble de critères suivants : aéroport de départ = CDG (Paris Charles de Gaulle), destination = LHR (London Heathrow), point de vente= FR (France), date de voyage = 10 mai 2014, et classe de réservation = Y. En supposant par ailleurs que nous avons les données de billet suivantes dans la base de données des billets composites : Billets utilisés CDG, LHR, FR, 10 MAI 2013, Y, 180 $ CDG, LHR, FR, 10 MAI 2013, Y, $160 CDG, LHR, FR, 10 MAI 2013, Y, 172 $ Billets confirmés/inutilisés CDG, LHR, FR, 10 MAI 2014, Y, 156 $ CDG, LHR, FR, 10 MAI 2014, Y, 190 $ Billets réservés proxy CDG, LHR, FR, 10 MAI 2014, Y, 162 $ 3042297 27 Billets simulés proxy CDG, LHR, FR, 10 MAI 2014, Y, 151 $ CDG, LHR, FR, 10 MAI 2014, Y, $184 CDG, LHR, FR, 10 MAI 2014, Y, 169 $ et les coefficients de pondération suivants : W1= 180, W2 = 130, W3 = 60, W3 = 80, la résolution des équations exemplaires de rendement ci-dessus en utilisant les valeurs de rendement ci-dessus donne : Rendement = (180 x (180 + 160 + 172) + 130 x (156 + 190) + 60 x (162) + 80 x (151 + 184 + 169) 180x 3 + 130 x 2 + 60 x 1 + 80 x 3 Le résultat simplifié est : Rendement = 170.16 $ Les calculs ci-dessus peuvent être répétés pour déterminer un rendement pour chaque ensemble de critères. [0070] Les coefficients de pondération peuvent être définis par le fournisseur de produits de voyage qui s'appuie sur une connaissance empirique du marché pour lequel le rendement est déterminé. Les coefficients de pondération peuvent aussi être définis en utilisant une méthode itérative. Par exemple, les coefficients de pondération peuvent initialement être fixés à une valeur 1, et les rendements peuvent être calculés en utilisant toutes les sources de données disponibles. L'exactitude du rendement qui en résulte peut être suivie et les coefficients de pondération peuvent être ajustés en fonction des résultats en utilisant une méthode d'ajustement comme la méthode des moindres carrés. Ce processus peut ensuite être répété jusqu'à ce que le rendement soit jugé suffisamment exact. lsorsque les données historiques suffisantes sont disponibles, les coefficients de pondération peuvent aussi être déterminés en utilisant des contrôles à postériori. [0071] En général, les routines exécutées pour mettre en oeuvre 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 3042297 28 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 des présents, peuvent être désignées dans les présentes comme « programme codé informatique » ou simplement « programme codé. » Un programme codé comporte typiquement des instructions déchiffrables par ordinateur qui résident à 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 de programmes, informatiques déchiffrables 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 dans toute combinaison d'un ou de plusieurs langages de programmation. [0072] Divers programmes codés 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 de l'invention spécifiques. Cependant, il faut savoir que toute nomenclature d'un programme particulier qui suit est utilisée par pure 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 de moyens généralement sans fin par lesquels les programmes informatiques peuvent être organisés selon des routines, procédures, méthodes, modules, objets, et ainsi de suite, ainsi que les façons variées d'affecter les fonctionnalités d'un programme au parmi les diverses couches de logiciels qui résident dans un ordinateur typique (par exemple, les systèmes d'exploitation, les bibliothèques, les APIS, les applications, les applets, etc.), il faut savoir que les modes de réalisation de l'invention ne sont pas limités à l'organisation spécifique et à l'affectation spécifique de fonctionnalités de programme décrites dans les présentes. [0073] Le programme codé intégré dans tout module/application décrit dans les présentes peut-être distribué individuellement ou collectivement comme un produit sous une variété de formes. Notamment, le programme codé peut être distribué en utilisant un médium de stockage déchiffrable par ordinateur disposant d'instructions de programme déchiffrables par 3042297 29 ordinateur déclenchant un processeur qui effectue des aspects des modes de réalisation de l'invention. [0074] Les supports de stockage déchiffrables par ordinateur, qui sont intrinsèquement non transitoire, 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 d'information, par exemple, des instructions de programme déchiffrables par ordinateur, des structures de données, des modules de programme, ou autres données. Les supports de stockage déchiffrables par ordinateur peuvent aussi comprendre des mémoires RAM, ROM, EPROM (mémoire à lecture exclusivement, programmable et effaçable), une mémoire flash, ou toute technologie de support solide de mémoire, CDROM (disque compact portable doté d'une mémoire à lecture seule), ou tout autre stockage optique, bancleed'enregistrement magnétique, mémoire à disque magnétique, ou tout autre médium apte à être déchiffré par ordinateur et pouvant être utilisé pour stocker l'information désirée. Un support de stockage déchiffrable par ordinateur ne doit pas être interprété comme des signaux transitoires proprement dits (c'est-à-dire des ondes de radio ou autres ondes électromagnétiques pouvant être propagées par un médium de transmission tel qu'un guide d'ondes, ou des signaux électriques transmis par fils). Les instructions de programme déchiffrables par ordinateur peuvent être téléchargées sur un ordinateur, un autre type d'appareil programmable de traitement de données ou sur tout autre dispositif de support de stockage déchiffrable par machine, ou vers un ordinateur externe ou par réseau vers un dispositif de stockage externe. [0075] Les instructions de programme déchiffrables par ordinateur qui sont stockées sur un support déchiffrable par ordinateur peuvent être utilisées pour commander un ordinateur, tout type d'appareil programmable de traitement des données, ou tout dispositif, pour fonctionner d'une façon particulière, de sorte que les instructions stockées sur le support déchiffrable par ordinateur produisent un article manufacturé comprenant les instructions qui implémentent les fonctions, les actions et/ou les opérations spécifiées dans les organigrammes, les diagrammes de séquences et/ou les diagrammes en blocs. Les instructions de programme informatique peuvent être fournies à un ou plusieurs processeurs d'un ordinateur à usage général, à un ordinateur dédié, ou autre appareil programmable de traitement de données pour produire 3042297 30 une machine, de sorte que les instructions, lorsqu'elles sont exécutées à l'aide du ou des processeurs, accomplissent une série de calculs pour implémenter les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels et/ou diagrammes en blocs. [0076] Dans certains modes de de réalisation alternatifs, les fonctions, actions, et/ou les opérations spécifiées dans les organigrammes, diagrammes séquentiels, et/ou diagrammes en blocs peuvent être commandées à nouveau, traitées en série, et/ou traitées concurremment de façon cohérente avec les modes de réalisation de l'invention. De plus, tout organigramme, diagramme séquentiel, et/ou diagramme en blocs peut comprendre plus ou moins de blocs que ceux illustrés, selon les modes de réalisation de l'invention. [0077] 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. Le singulier des articles définis et indéfinis « un », « une », « le » et « la » sous-entend également les formes plurielles, sauf s'il en est indiqué autrement et clairement par le contexte. Par ailleurs, les termes « comprend» et « comprenant » lorsqu'ils sont utilisés 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 termes « inclurent », « incluant », « ayant », ou des variantes, sont utilisés dans la description détaillée des revendications, ces termes sont censés être inclusifs. [0078] Bien que l'invention ait été 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 méthodes, aux appareils représentatifs et aux exemples illustratifs montrés et décrits. Par conséquent, il est possible de 3042297 31 s'éloigner de ces détails sans s'éloigner de l'esprit et de la portée du concept inventif général du demandeur. REVENDICATIONS1. Un système configuré pour déterminer un rendement pour un inventaire restant d'un premier produit ayant une première date d'expiration, comprenant : un ou plusieurs processeurs, et une mémoire couplée avec un ou plusieurs processeurs, la mémoire stockant les données comprend un programme codé qui, lorsqu'il est exécuté par un plusieurs processeurs enclenche le système qui: détermine, avant la première date d'expiration, un premier prix pour une première unité du premier produit qui est réservé ; détermine, avant la première date d'expiration, un second prix pour une seconde unité du premier produit qui est disponible ; détermine, avant la première date d'expiration, un troisième prix payé pour une troisième unité d'un second produit dont la seconde date d'expiration est passée, et détermine le rendement pour l'inventaire restant sur la base d'une somme pondérée comportant le premier prix, le second prix, et le troisième prix ; dans laquelle le programme codé enclenche le système qui détermine le second prix pour la seconde unité du premier produit en : déterminant une demande attendue pour le premier produit ; générant une demande de réservation simulée pour la seconde unité du premier produit, sur la base de la demande attendue ; déterminant une disponibilité du premier produit basé sur l'inventaire restant ; générant un dossier de réservation simulée pour la seconde unité, en réponse à la disponibilité étant suffisante pour satisfaire la demande de réservation simulée ; générant un billet proxy pour le dossier de réservation simulée, dans lequel le billet proxy simulé a une même structure que des billets confirmés normaux ; déterminant un contexte tarifaire pour le billet proxy ; et 3042297 33 attribuant un prix au billet proxy en utilisant le contexte tarifaire pour produire le second prix. 2. Le système, selon la revendication 1, dans lequel le programme codé enclenche le système qui détermine le premier prix en transmettant une requête à une première base de données de dossiers de réservation, cette requête demandant à la première base de données le renvoi de dossiers de réservation pour des unités du premier produit qui ont été réservées ; recevant un dossier de réservation pour un itinéraire incluant la première unité de la première base de données ; génère un billet proxy pour la première unité basée sur le dossier de réservation, détermine un contexte tarifaire pour le billet proxy, et attribue un prix au billet proxy en utilisant le contexte tarifaire pour déterminer le premier prix. 3. Le système selon la revendication 2 dans lequel le programme codé enclenche le système afin de : détecter un changement du contexte de réservation pour le dossier de réservation ; effectuer une nouvelle tarification du billet proxy, en réponse à la détection du changement, en utilisant le contexte modifié de la réservation pour actualiser le premier prix, et actualiser le rendement basé sur le premier prix actualisé. 4. Le système selon les revendications 2 ou 3 dont le billet proxy est stocké dans une seconde base de données de billets proxy, dans lequel le programme codé enclenche le système afin de: détecter une modification du dossier de réservation dans la première base de données; et 3042297 34 actualiser le billet proxy dans la seconde base de données, en réponse à la détection d'une modification. 5. Le système, selon la revendication 4 dans laquelle la modification du dossier de réservation comprend la suppression du dossier de réservation ou la génération d'un billet confirmé pour la première unité. 6. Le système, selon la revendication 1, dans lequel le programme codé enclenche le système qui détermine le premier prix en transmettant une requête à une base de données de billets, cette requête demandant à la base de données le renvoi de billets pour des unités achetées du premier produit, et recevant un premier billet de la base de données, le premier billet incluant un premier prix. 7. Le système selon la revendication 6 dans lequel le programme codé enclenche le système afin de: détecter un changement de statut du premier billet, et actualiser le premier prix, en réponse à la détection du changement.