EP1759356A1 - Procede de traitement de donnees d'un titre de transport - Google Patents

Procede de traitement de donnees d'un titre de transport

Info

Publication number
EP1759356A1
EP1759356A1 EP05762952A EP05762952A EP1759356A1 EP 1759356 A1 EP1759356 A1 EP 1759356A1 EP 05762952 A EP05762952 A EP 05762952A EP 05762952 A EP05762952 A EP 05762952A EP 1759356 A1 EP1759356 A1 EP 1759356A1
Authority
EP
European Patent Office
Prior art keywords
contract
preselection
data
file
stored
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP05762952A
Other languages
German (de)
English (en)
Inventor
Daniel Fauleau
Thierry D'athis
Jean LEONETTI
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales SA
Original Assignee
Thales SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Thales SA filed Critical Thales SA
Publication of EP1759356A1 publication Critical patent/EP1759356A1/fr
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07B—TICKET-ISSUING APPARATUS; FARE-REGISTERING APPARATUS; FRANKING APPARATUS
    • G07B15/00—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points
    • G07B15/02—Arrangements or apparatus for collecting fares, tolls or entrance fees at one or more control points taking into account a variable factor such as distance or time, e.g. for passenger transport, parking systems or car rental systems
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/02—Reservations, e.g. for tickets, services or events

Definitions

  • the present invention relates to a method of processing the data of a ticket.
  • a ticket is what allows a user to use public transport services, such as the metro, train, bus ...
  • a ticket includes a physical medium, the title holder, on which are stored data. There is thus the logical support (transport ticket), ie the set formed by the physical medium and its data, of the physical medium as such.
  • the physical medium can be of different technologies: magnetic, smart card with or without contact, chip token ...
  • the data that is stored are data relating to one or more contracts for use of a transport service.
  • a contract for the use of a transport service is commonly called a product because it is what is sold by the transport operators.
  • a product can be for example a monthly subscription to a metro service in a given geographical area.
  • the data associated with a contract that is stored on physical media is called a product or contract instance.
  • Other data may be stored on the physical medium. These other data may be personal data (name, address, date of birth ...) describing the holder of the ticket. Of course, anonymous tickets (metro tickets for example) do not include personal data.
  • a product instance is stored as a file. The file has several records each with the same format. A record is composed of fields. For example, EN 1545 (1998) of the European Committee for Standardization (CEN) defines formats for recorded data fields. There are many fields in a contract instance file. In particular, there is a pricing field, an instance identification field, fields relating to the sale, fields relating to the validity of the contract, etc.
  • the pricing field may be coded by an integer identifying the rules. which apply to the determination of the price, validation and control of a contract. These rules and their application are known to the system, including front end devices.
  • Instance identification field is a unique serial number that allows to identify this contract instance.
  • the fields relating to the sale include, for example, the date and time of sale of the contract, an identification number of the front-end equipment used for the sale ...
  • the fields relating to the validity of the contract include, for example, information on the point of departure of the journey, the destination, the number of authorized zones, a date of end of validity ...
  • the equipment performing read or write operations on the tickets is called front-end equipment, c that is, belonging to the front office.
  • the validation equipment must process the securities quickly. This constraint on the processing time does not allow them to read any data of the stored contract instances.
  • the method according to the invention allows a front-end equipment such as a validation equipment, to select the most appropriate contract, and this with a reduced processing time.
  • the subject of the invention is a method for processing a transport ticket in which contract instances are stored, characterized in that: • a preselection file is read, the preselection file including a record by stored contract instance, each record having at least one selection field on the one hand and a pointer referencing a contract instance on the other hand, • a pre-selection list is prepared from the data read from the pre-selection file, the pre-selection list referencing the stored contract instances in order of preference.
  • the invention also relates to a transport ticket in which contract instances are stored, characterized in that a preselection file is also stored, the preselection file comprising a record by stored contract instance, each record comprising at least a selection field on the one hand and a pointer referencing a contract instance on the other hand, the preselection file being intended to be used by this method.
  • the invention has several advantages. On the one hand, the invention also makes it possible to implement complex selection rules to choose the most appropriate contract. On the other hand, the invention is particularly useful when a ticket is shared by several different transport operators. Indeed, in such a context, a ticket may contain a plurality of contracts from different operators, some operators can not process the data of other operators.
  • FIG. 1 an exemplary method according to the invention
  • Figure 2 an example of a file recorded on the ticket for the implementation of the method according to the invention.
  • a preselection file is recorded in the transport ticket.
  • the preselection file contains certain information relating to the contracts, and more specifically relating to the contract instances stored in the ticket.
  • the preselection file is in a way a summary of the information contained in the contract instances, this summary being used to perform a preselection.
  • Preselection 1 is a process in which a pre-selection list is prepared referencing the contract instances in order of preference of use. An example of such a treatment will be described in more detail below. Once the preselection 1 has been carried out, the data of the contract instances selected in the preselection step can be read, in the order of preference of use, until a usable contract instance is obtained. This contract instance corresponds to the chosen contract.
  • the preselection file 3 includes a record 31 per contract instance.
  • Each recording has the same format and is composed of fields 32, 33, 34, 35. Among these fields are selection fields 32, 33, 34 on the one hand, and a pointer on the other hand 35.
  • the pointer 35 allows associate a record of the preset file with a particular contract instance.
  • a user priority associated with each product instance is defined.
  • a user priority represents a preference issued by the user in the order of use of the products he holds in his ticket.
  • the user priority can be a data of a selection field.
  • a standby state is also defined.
  • a product When a product is in a standby state, it can not be used by a front-end device without having been previously activated.
  • the waking state can be a data of a selection field.
  • the user priority and the standby state are coded in the same selection field 34.
  • This field designated by "UserPreference” in the following description, may be encoded by an integer for example. A value of this integer is used to mark products in a sleep state.
  • the other values of this integer define a user priority. In this case, setting a user priority implicitly means that a product is enabled, and placing a product in a sleep state prevents a user priority from being set for that product.
  • the field "UserPreference" is coded on one byte.
  • the user priorities may take three values (1, 2 and 3 for example), the lower value corresponding to the least preferred product, the higher value corresponding to the preferred product.
  • the standby state of the product can be associated with a lower value (0) than the lowest priority (1).
  • the possible values of the field "UserPreference” are designated in ascending order by "preferred product", “normal product”, “less preferred product”, and “suspended product”, the "suspended product” value corresponding to a product in the standby state.
  • a product instance can be registered in the ticket whose user priority has a default "normal product” value. Of course, this default value can be overridden by another value specified by the user.
  • Other fields of possible selections are now described.
  • a selection field 33 may make it possible to determine whether a particular instance is already in use or not. Such a situation occurs in the case of a transfer from one mode of transport to another, for example.
  • This field allows you to resolve potential conflicts in the search for contracts, ie to use a current contract rather than using a new one.
  • This field 33 may be coded by a logical value, ie of the boolean type. This field is designated by "IsUsed” in the following description.
  • Another selection field 32 contains an identifier defining the contract family to which each contract instance belongs. A contract family corresponds to a general definition of the contract, ie to a class of contract (called “template” in the English literature). The identifier may be encoded by an integer. This field 32 is designated by "ProductTemplate” in the remainder of the description. In a multi-operator context, product families have a unique identifier that is shared by transport operators.
  • a contract family defines: • the list of transport operators who can use a contract from this family, • the list of modes of transport that can be used with the contracts of this family, • the list of geographical zones in which can travel the holder of a contract of this family, • the list of lines of transport (train, subway, bus ...) being able to be used by the holder of a contract of this family, • characteristics relating to the temporal validity limits of the contracts of this family ...
  • Other characteristics can be defined in a family of contract, these characteristics not being useful at the stage of preselection.
  • the selection process comprises two main steps, a preselection step 1 according to the invention, and a step of choosing the product to be validated 2 from the result of the preselection.
  • the preselection starts with the reading of all the records of the preselection file to form an initial preselection list. From this initial preselection list, one or more filtering steps are performed, these filtering steps being optional. They make it possible to retain among the instances stored in the ticket only those relevant.
  • a first filtering step 11 consists in retaining only the activated contracts, that is to say for which the contract is not in a state ". Eve. This filtering is done simply by eliminating from the preselection list the records for which the "UserPreference" field 34 has a "suspended product” value.
  • a second filtering step 12 consists in retaining only the contracts recognized by the transport operator whose equipment seeks to process the ticket. This filtering is done simply by eliminating from the preselection list the records for which the field : "ProductTemplate" 32 has a value not included - in a predetermined list of the equipment.
  • the filtering steps described above are illustrative.
  • Variations may be considered to eliminate records (each record corresponds to a contract instance) from the pre-selection list. If at the end of one or the other step of filtering, the list of preselection is empty, the processing of the title stops without that no contract could be selected.
  • Contract sorting can be done in practice by sorting the records in the pre-selection list. Records can be classified using several successive sorting criteria. A first sorting criterion can be based on the value of the field "Isllsed" 33. In other words, it would be preferable to use a current contract as a priority rather than using a new one.
  • a second sorting criterion can be based on the value of the user priority.
  • the value of the "UserPreference" field 34 is used for this purpose. In this advantageous embodiment, it is sufficient to classify the records with the value of this field (in decreasing values). It should be noted that the presence of the preceding filtering step 11 makes it even more practical to use standby state and user priority coding on a single field.
  • a third sorting criterion may be based on a priority given by the transport operator to which the title processing equipment belongs. This sorting criterion may be based on the value of the "ProductTemplate" field 32. A transport operator may thus choose to validate preferably a contract that he has sold rather than a contract sold by a third party.
  • a fourth sorting criterion may be to select the most recent contracts as a priority. For this purpose, we can sort the records in order of appearance in the initial preselection, insofar as the records corresponding to the new contracts are placed at the top of the preselection file. This can be done simply by numbering the records during the reading of the preselection file, which number is then used for the fourth sorting criterion. At the end of sorting, we have a pre-selection list with records sorted in order of preference. This pre-selection saves time in further processing because most unusable contracts are already deleted, their data does not have to be read, and the remaining contracts are sorted. The selection step 2 of the product to be validated is now described.
  • the data of the first contract referenced by the preselection list is read. From these data, the geographical and temporal validity of the contract is tested. If the contract is valid, it is chosen. Otherwise, the processing is continued with the reading of data of the following contract.
  • the invention is not limited to this embodiment described. It will be understood, for example, that the order in which the sorting or filtering steps are performed does not matter, the sorting step may for example precede the filtering steps, or only certain filtering steps.

Landscapes

  • Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Engineering & Computer Science (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Finance (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Devices For Checking Fares Or Tickets At Control Points (AREA)

Abstract

La présente invention concerne un procédé de traitement des données d'un titre de transport. Les données mémorisées dans le titre de transport comportent des instances de contrat, c'est à dire les données d'utilisation d'un service de transport (bus, métro, tramway...). Selon l'invention: on lit (10) un fichier de présélection (3), le fichier de présélection comprenant un enregistrement (31) par instance de contrat mémorisée, chaque enregistrement comportant au moins un champ de sélection (32, 33, 34) d'une part et un pointeur (35) référençant une instance de contrat d'autre part, on prépare une liste de présélection, à partir des données lues dans le fichier de présélection, la liste de présélection référençant les instances de contrat mémorisées par ordre de préférence. On peut ainsi lire les données des instances de contrat dans cet ordre de préférence, ce qui permet d'accélérer les traitements car on évite de lire toutes les données des instances de contrat.

Description

Procédé de traitement de données d'un titre de transport
La présente invention concerne un procédé de traitement des données d'un titre de transport. Un titre de transport est ce qui permet à un utilisateur d'utiliser des services de transport publics, tels que le métro, le train, le bus... Un titre de transport comporte un support physique, le support de titre, sur lequel sont mémorisées des données. On distingue ainsi le support logique (titre de transport), c'est à dire l'ensemble formé par le support physique et ses données, du support physique en tant que tel. Le support physique peut être de différentes technologies: magnétique, carte à puce avec ou sans contact, jeton à puce... Les données qui sont mémorisées sont des données relatives à un ou plusieurs contrats d'utilisation d'un service de transport. Un contrat d'utilisation d'un service de transport est couramment appelé un produit, car c'est ce qui est vendu par les opérateurs de transport. Un produit peut être par exemple un abonnement mensuel à un service de métro dans une zone géographique déterminée. On appelle instance de produit ou de contrat les données associées à un contrat qui sont mémorisées sur un support physique. D'autres données peuvent être mémorisées sur le support physique. Ces autres données peuvent être des données personnelles (nom, adresse, date de naissance...) décrivant le titulaire du titre de transport. Bien entendu, les titres de transports anonymes (billets de métro par exemple) ne comportent pas de données personnelles. De façon conventionnelle, une instance de produit est mémorisée sous la forme d'un fichier. Le fichier comporte plusieurs enregistrements présentant chacun le même format. Un enregistrement est composé de champs. La norme ENV 1545 (1998) du CEN (Comité Européen de Normalisation) définit par exemple des formats des champs de données enregistrés. Il existe de nombreux champs dans un fichier d'instance de contrat. On trouve notamment un champ de tarification, un champ d'identification de l'instance, des champs relatifs à la vente, des champs relatifs à la validité du contrat... Le champ de tarification peut être codé par un nombre entier identifiant lès règles qui s'appliquent à la détermination du prix, de la validation et du contrôle d'un contrat. Ces règles et leur application sont connues du système, notamment les équipements frontaux. Le champ d'identification de l'instance est un numéro de série unique qui permet d'identifier cette instance de contrat. Les champs relatifs à la vente comprennent par exemple la date et l'heure de vente du contrat, un numéro d'identification de l'équipement frontal ayant servi à la vente... Les champs relatifs à la validité du contrat comprennent par exemple des informations sur le point de départ du voyage, la destination, le nombre de zones autorisées, une date de fin de validité... Les équipements réalisant des opérations de lecture ou d'écriture sur les titres de transports sont appelés des équipements frontaux, c'est à dire appartenant au "front-office". On les désigne aussi par l'acronyme MAD issu de l'expression anglo-saxonne "Media Access De vice". On trouve parmi ces équipements les équipements de validations, qui peuvent permettre de valider un titre à l'entrée d'une zone payante ("check-in") ou à sa sortie ("check-out"). Les équipements de validations doivent traiter les titres rapidement. Cette contrainte sur le temps de traitement ne leur permet pas de lire toutes données des instances de contrat mémorisées. Le procédé selon l'invention permet à un équipement frontal tel q'un équipement de validation, de sélectionner le contrat le plus approprié, et ce avec un temps de traitement réduit. A cet effet, l'invention a pour objet un procédé de traitement d'un titre de transport dans lequel sont mémorisées des instances de contrat, caractérisé en ce que: • on lit un fichier de présélection, le fichier de présélection comprenant un enregistrement par instance de contrat mémorisée, chaque enregistrement comportant au moins un champ de sélection d'une part et un pointeur référençant une instance de contrat d'autre part, • on prépare une liste de présélection, à partir des données lues dans le fichier de présélection, la liste de présélection référençant les instances de contrat mémorisées par ordre de préférence. L'invention a aussi pour objet Titre de transport dans lequel sont mémorisées des instances de contrat, caractérisé en ce qu'est aussi mémorisé un fichier de présélection, le fichier de présélection comprenant un enregistrement par instance de contrat mémorisée, chaque enregistrement comportant au moins un champ de sélection d'une part et un pointeur référençant une instance de contrat d'autre part, le fichier de présélection étant destiné à être utilisé par ce procédé. L'invention présente plusieurs avantages. D'une part, l'invention permet en outre de mettre en œuvre des règles de sélection complexes pour choisir le contrat le plus approprié. D'autre part, l'invention est particulièrement utile lorsqu'un titre de transport est partagé par plusieurs opérateurs de transports différents. En effet, dans un tel contexte, un titre de transport peut contenir une pluralité de contrats provenant d'opérateurs différents, certains opérateurs ne pouvant pas traiter les données d'autres opérateurs. D'autres caractéristiques et avantages de l'invention apparaîtront à la lecture de la description détaillée suivante présentée à titre d'illustration non limitative et faite en référence aux figures annexées, lesquelles représentent : la figure 1 , un exemple de procédé selon l'invention, la figure 2, un exemple de fichier enregistré sur le titre de transport pour la mise en œuvre du procédé selon l'invention.
On se réfère maintenant à la figure 1. Selon l'invention, on enregistre dans le titre de transport un fichier de présélection. Le fichier de présélection contient certaines informations relatives aux contrats, et plus précisément relatives aux instances de contrats mémorisées dans le titre de transport. Le fichier de présélection est en quelque sorte un résumé des informations contenues dans les instances de contrats, ce résumé servant à effectuer une présélection. La présélection 1 est un traitement au cours duquel on prépare une liste de présélection référençant les instances de contrat par ordre de préférence d'utilisation. Un exemple d'un tel traitement sera décrit plus en détail ci-dessous. Une fois la présélection 1 réalisée, on peut lire les données des instances de contrat sélectionnées à l'étape de présélection, et ce dans l'ordre de préférence d'utilisation, jusqu'à obtenir une instance de contrat utilisable. Cette instance de contrat correspond au contrat choisi. On peut alors traiter les données de cette instance de contrat pour effectuer une validation par exemple, lors de l'entrée ("check-in") ou de la sortie ("check- out") d'une zone payante. On se réfère maintenant à la figure 2. Le fichier de présélection 3 comporte un enregistrement 31 par instance de contrat. Chaque enregistrement présente le même format et est composé de champs 32, 33, 34, 35. On trouve parmi ces champs des champs de sélection 32, 33, 34 d'une part, et un pointeur d'autre part 35. Le pointeur 35 permet d'associer un enregistrement du fichier de présélection à une instance de contrat particulière. Selon l'invention, on définit une priorité utilisateur associée à chaque instance de produit. Une priorité utilisateur représente une préférence émise par l'utilisateur dans l'ordre d'utilisation des produits qu'il détient dans son titre de transport. La priorité utilisateur peut être une donnée d'un champ de sélection. Selon l'invention, on définit aussi un état de veille. Lorsqu'un produit est dans un état de veille, il ne peut être utilisé par un équipement frontal sans avoir été préalablement activé. L'état de veille peut être une donnée d'un champ de sélection. Selon un mode de réalisation avantageux, la priorité utilisateur et l'état de veille sont codés dans un même champ de sélection 34. Ce champ, désigné par "UserPreference" dans la suite de la description, peut être codé par un entier par exemple. Une valeur de cet entier permet de marquer les produits dans un état de veille. Les autres valeurs de cet entier permettent de définir une priorité utilisateur. Dans ce cas, le fait de définir une priorité utilisateur signifie implicitement qu'un produit est activé, et le fait de placer un produit dans un état de veille empêche de définir une priorité utilisateur pour ce produit. Ceci n'est pas gênant dans la mesure où un produit placé dans un état de veille ne doit jamais être utilisé. Bien entendu, il est possible d'utiliser des champs de sélection différents pour enregistrer la priorité utilisateur d'une part, et pour marquer les produits qui sont dans un état de veille d'autre part. Selon un mode de réalisation pratique, le champ "UserPreference" est codé sur un octet. Les priorités utilisateurs peuvent prendre trois valeurs (1, 2 et 3 par exemple), la valeur plus faible correspondant au produit le moins préféré, la valeur la plus élevée correspondant au produit préféré. On peut associer l'état de veille du produit à une valeur plus faible (0) que la priorité la plus faible (1 ). Dans la suite de la description, les valeurs possibles du champ "UserPreference" sont désignées dans l'ordre croissant par "produit préféré", "produit normal", "produit moins préféré", et "produit suspendu", la valeur "produit suspendu" correspondant à un produit dans l'état de veille. Lorsqu'un produit est vendu, on peut enregistrer dans le titre de transport une instance de produit dont la priorité utilisateur a une valeur "produit normal" par défaut. Bien entendu, cette valeur par défaut peut être remplacée par une autre valeur spécifiée par l'utilisateur. On décrit maintenant d'autres champs de sélections possibles. Un champ de sélection 33 peut permettre de déterminer si une instance particulière est déjà en cours d'utilisation ou non. Une telle situation se présente dans le cas d'un transfert d'un mode de transport à un autre par exemple. Ce champ permet de résoudre des conflits potentiels dans la recherche de contrats, c'est à dire d'utiliser un contrat en cours plutôt que d'en utiliser un nouveau. Ce champ 33 peut être codé par une valeur logique, c'est à dire de type boolean. On désigne ce champ par "IsUsed" dans la suite de la description. Un autre champ de sélection 32 contenir un identificateur définissant la famille de contrat à laquelle chaque instance de contrat appartient. Une famille de contrat correspond à une définition générale du contrat, c'est à dire à une classe de contrat (appelée "template" dans la littérature anglo-saxonne). L'identificateur peut être codé par un nombre entier. On désigne ce champ 32 par "ProductTemplate" dans la suite de la description. Dans un contexte multi-opérateur, les familles de produit disposent d'un identificateur unique et partagé par les opérateurs de transport. En d'autres termes, il n'y a pas de collision entre les numéros identifiant les familles de contrats d'opérateurs de transports différents. Une famille de contrat définit par exemple: • la liste des opérateurs de transports chez qui on peut utiliser un contrat de cette famille, • la liste de modes de transports pouvant être utilisés avec les contrats de cette famille, • la liste des zones géographiques dans lesquelles peut voyager le titulaire d'un contrat de cette famille, • la liste des lignes de transports (train, métro, bus...) pouvant être utilisées par le titulaire d'un contrat de cette famille, • des caractéristiques relatives aux limites de validités temporelles des contrats de cette famille... D'autres caractéristiques peuvent être définies dans une famille de contrat, ces caractéristiques n'étant pas utiles à l'étape de présélection. On peut notamment définir le nom de la famille, la liste des détaillants autorisés à vendre les produits de cette famille, la liste des profils voyageurs autorisés (étudiant, militaire, personne âgé,...)... On se réfère à nouveau à la figure 1 pour décrire plus en détail l'exemple de mise en œuvre du procédé de sélection d'un produit à valider. Le procédé de sélection comporte deux étapes principales, une étape de présélection 1 selon l'invention, et une étape de choix du produit à valider 2 à partir du résultat de la présélection. La présélection débute par la lecture 10 de tous les enregistrements du fichier de présélection pour former une liste de présélection initiale. A partir de cette liste de présélection initiale, on réalise une ou plusieurs étapes de filtrage, ces étapes de filtrage étant optionnelles. Elles permettent de ne retenir parmi les instances mémorisées dans le titre de transport uniquement celles pertinentes. Une première étape de filtrage 11 consiste à ne retenir que les contrats activés, c'est à dire pour lesquels le contrat n'est pas dans un état ». de veille. Ce filtrage est réalisé simplement en éliminant de la liste de présélection les enregistrements pour lesquels le champ "UserPreference" 34 a une valeur "produit suspendu". Une seconde étape de filtrage 12 consiste à ne retenir que les contrats reconnus par l'opérateur de transport dont l'équipement cherche à traiter le titre de transport. Ce filtrage est réalisé simplement en éliminant de la liste de présélection les enregistrements pour lesquels le champ : "ProductTemplate" 32 a une valeur non comprise - dans une liste prédéterminée de l'équipement. Bien entendu, les étapes de filtrage décrites ci-dessus le sont à titre d'illustration. Des variantes peuvent être envisagées pour éliminer des enregistrements (chaque enregistrement correspond à une instance de contrat) de la liste de présélection. Si à l'issu de l'une ou l'autre étape de filtrage, la liste de présélection est vide, le traitement du titre s'arrête sans qu'aucun contrat n'ait pu être sélectionné. On décrit maintenant l'étape de tri 13 des contrats référencés par la liste de présélection (restant après filtrage le cas échéant) par ordre de préférence. Le tri des contrats peut être réaliser en pratique en triant les enregistrements de la liste de présélection. On peut classer les enregistrements en utilisant plusieurs critères de tri successif. Un premier critère de tri peut être basé sur la valeur du champ "Isllsed" 33. En d'autres termes, on préférera utiliser en priorité un contrat en cours plutôt que d'en utiliser un nouveau Un second critère de tri peut être basé sur la valeur de la priorité utilisateur. On utilise à cet effet la valeur du champ "UserPreference" 34. Dans ce mode de réalisation avantageux, il suffit de classer les enregistrements avec la valeur de ce champ (par valeurs décroissantes). On notera que la présence de l'étape de filtrage 11 qui précède rend encore plus pratique l'utilisation d'un codage de l'état de veille et de la priorité utilisateur sur un seul champ. Un troisième critère de tri peut être basé sur une priorité donnée par l'opérateur de transport auquel appartient l'équipement traitant de titre. Ce critère de tri peut être basé sur la valeur du champ "ProductTemplate" 32. Un opérateur de transport pourra ainsi choisir de valider de préférence un contrat qu'il a vendu plutôt qu'un contrat vendu par un tiers. Un quatrième critère de tri peut être de sélectionner en priorité les contrats les plus récents. A cet effet, on peut trier les enregistrements par ordre d'apparition dans la de présélection initiale, dans la mesure où les enregistrements correspondants aux nouveaux contrats sont placés en tête du fichier de présélection. Ceci peut être réalisé simplement en numérotant les enregistrement lors de la lecture du fichier de présélection, ce numéro étant ensuite utilisé pour le quatrième critère de tri. A la fin du tri, on dispose d'une liste de présélection avec des enregistrements triés par ordre de préférence. Cette présélection permet de gagner du temps dans la suite du traitement car la plupart des contrats inutilisables sont déjà supprimés, leurs données n'ayant pas à être lues, et car les contrats restant sont triés. On décrit maintenant l'étape de choix 2 du produit à valider. On lit 20 les données du premier contrat référencé par la liste de présélection. A partir de ces données, on teste la validité géographique et temporelle du contrat. Si le contrat est valide, on le choisit. Sinon, on poursuit le traitement avec la lecture 21 de données du contrat suivant. Bien entendu, l'invention ne se limite pas à ce mode de réalisation décrit. On comprendra par exemple que l'ordre dans lequel sont effectuées les étapes de tri ou de filtrage n'a pas d'importance, l'étape de tri pouvant par exemple précéder les étapes de filtrages, ou certaines étapes de filtrage seulement.

Claims

REVENDICATIONS
1. Procédé de traitement d'un titre de transport dans lequel sont mémorisées des instances de contrat, caractérisé en ce que: • on lit (10) un fichier de présélection (3), le fichier de présélection comprenant un enregistrement (31) par instance de contrat mémorisée, chaque enregistrement comportant au moins un champ de sélection (32, 33, 34) d'une part et un pointeur (35) référençant une instance de contrat d'autre part, • on prépare une liste de présélection, à partir des données lues dans le fichier de présélection, la liste de présélection référençant les instances de contrat mémorisées par ordre de préférence.
2. Procédé selon la revendication 1 dans lequel la liste de présélection est composée d'enregistrements lus dans le fichier de présélection.
3. Procédé selon la revendication 1 dans lequel un champ de sélection (34) comprend une donnée relative à une priorité utilisateur, la priorité utilisateur étant une préférence de l'utilisateur dans l'ordre d'utilisation des produits qu'il détient dans son titre de transport, ce champ de sélection étant utilisé lors de la préparation de la liste de présélection pour trier les instances de contrat mémorisées.
4. Procédé selon la revendication 1 dans lequel un champ de sélection (34) comprend une donnée relative à un état de veille, un contrat en état de veille étant un contrat dont l'usage par un équipement frontal est interdit sans qu'il ait été préalablement activé, ce champ de sélection étant utilisé lors de la préparation de la liste de présélection pour filtrer (11 ) les instances de contrat en état de veille.
5. Titre de transport dans lequel sont mémorisées des instances de contrat, caractérisé en ce qu'il comporte un fichier de présélection (3), le fichier de présélection comprenant un enregistrement (31) par instance de contrat mémorisée, chaque enregistrement comportant au moins un champ de sélection (32, 33, 34) d'une part et un pointeur (35) référençant une instance de contrat d'autre part, le fichier de présélection étant destiné à être utilisé par le procédé selon la revendication 1.
6. Titre de transport selon la revendication 5 dans lequel un champ de sélection (34) comprend une donnée relative à une priorité utilisateur, la priorité utilisateur étant une préférence de l'utilisateur dans l'ordre d'utilisation des produits qu'il détient dans son titre de transport.
7. Titre de transport selon la revendication 5 dans lequel un champ de sélection (34) comprend une donnée relative à un état de veille, un contrat en état de veille étant un contrat dont l'usage par un équipement frontal est interdit sans qu'il ait été préalablement activé.
8. Titre de transport selon les revendications 6 et 7 dans lequel un unique champ de sélection comprend la donnée relative à la priorité utilisateur et la donnée relative à l'état de veille.
EP05762952A 2004-06-25 2005-06-21 Procede de traitement de donnees d'un titre de transport Withdrawn EP1759356A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0407018A FR2872319B1 (fr) 2004-06-25 2004-06-25 Procede de traitement des donnees d'un titre de transport
PCT/EP2005/052895 WO2006000557A1 (fr) 2004-06-25 2005-06-21 Procede de traitement de donnees d'un titre de transport

Publications (1)

Publication Number Publication Date
EP1759356A1 true EP1759356A1 (fr) 2007-03-07

Family

ID=34949096

Family Applications (1)

Application Number Title Priority Date Filing Date
EP05762952A Withdrawn EP1759356A1 (fr) 2004-06-25 2005-06-21 Procede de traitement de donnees d'un titre de transport

Country Status (5)

Country Link
US (1) US20110093300A1 (fr)
EP (1) EP1759356A1 (fr)
AU (1) AU2005256627A1 (fr)
FR (1) FR2872319B1 (fr)
WO (1) WO2006000557A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4535152B2 (ja) * 2008-03-19 2010-09-01 ソニー株式会社 表示装置、表示方法、プログラムおよび表示システム

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2274182B (en) * 1993-01-09 1996-09-25 Digital Equipment Int Database co-processor
US5578808A (en) * 1993-12-22 1996-11-26 Datamark Services, Inc. Data card that can be used for transactions involving separate card issuers
US6999936B2 (en) * 1997-05-06 2006-02-14 Sehr Richard P Electronic ticketing system and methods utilizing multi-service visitor cards
US6101477A (en) * 1998-01-23 2000-08-08 American Express Travel Related Services Company, Inc. Methods and apparatus for a travel-related multi-function smartcard
US6736317B1 (en) * 1999-04-20 2004-05-18 Mcdonald Ian Real time internet-based transit management and control system with wireless vehicular data link
US20020010604A1 (en) * 2000-06-09 2002-01-24 David Block Automated internet based interactive travel planning and reservation system
US6609655B1 (en) * 2000-06-26 2003-08-26 Martha F. Harrell Smart card system for providing financial, travel, and entertainment-related services
GB0204309D0 (en) * 2002-02-25 2002-04-10 Ibm Usage charging
US7654452B2 (en) * 2003-07-11 2010-02-02 Tc License Ltd. Self-service electronic toll collection unit and system

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006000557A1 *

Also Published As

Publication number Publication date
US20110093300A1 (en) 2011-04-21
FR2872319B1 (fr) 2007-06-08
WO2006000557A1 (fr) 2006-01-05
AU2005256627A1 (en) 2006-01-05
FR2872319A1 (fr) 2005-12-30

Similar Documents

Publication Publication Date Title
KR100819620B1 (ko) 서버 장치, 신호분배 시스템, 신호분배 방법 및 단말 장치
CN114119137B (zh) 风险控制方法和装置
US11113315B2 (en) Search keyword generation
FR2674976A1 (fr) Procede de paiement electronique par carte a puce a l'aide de jetons numerotes permettant la detection de fraudes.
EP0786746A2 (fr) Procédé et dispositif de traitement d'informations codées avec carte à puce
FR2471632A1 (fr) Appareil et procede pour coder et decoder une carte delivree a un individu par une entite
CN108280179B (zh) 音频广告检测的方法及系统、终端以及计算机可读存储介质
EP0708949B1 (fr) Procede pour produire une cle commune dans deux dispositifs en vue de mettre en oeuvre une procedure cryptographique commune, et appareil associe
EP0298831B1 (fr) Procédé et dispositif anti-fraude pour un système à accès sélectif
CN108833488A (zh) 一种推荐信息的推送方法及服务器
EP1759356A1 (fr) Procede de traitement de donnees d'un titre de transport
JPH03100792A (ja) カード式自動販売装置
CN109636378A (zh) 账户识别方法和装置、电子设备
CN118760950A (zh) 一种网约车行业重大客诉识别方法、装置及存储介质
US20050177434A1 (en) Method for marketing and organization of creative content over an online medium
CN1263028C (zh) 数据记录装置
JP6473531B1 (ja) 顔認証技術による自動割り勘決済システム
EP3752948A1 (fr) Procédé de traitement automatique pour l'anonymisation d'un jeu de données numériques
JPH08241352A (ja) 資料購入システム
EP2784703A1 (fr) Traitement relatif à une conférence établie entre des terminaux dans un réseau de communication
FR3086430A1 (fr) Procede et dispositif de generation d'un plan d'entretien
CN110287216A (zh) 数据验证方法、装置、计算机设备以及存储介质
WO2013000966A1 (fr) Procede de transaction dematerialisee
BE1003889A6 (fr) Procede pour introduire, mettre en memoire, collationner et extraire des donnees.
EP1745393A1 (fr) Systeme automatique de traitement des informations portees par des textes courts

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20061220

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU MC NL PL PT RO SE SI SK TR

17Q First examination report despatched

Effective date: 20070405

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20090109