交通情報クライアントデバイス
【課題】交通情報クライアントデバイスにおいて復号化する交通メッセージの多用性および融通性を改善すること。
【解決手段】交通情報クライアントデバイスとして動作するように構成されている電子デバイスは、交通イベントの位置を識別する位置コードを備え得る交通情報メッセージを受信するように適応されているインタフェース（１１）と、メモリ（１２）と、該メモリに格納される関係型データベース（２０）であって、位置コードを位置情報と直接的または間接的に関連付ける少なくとも１つの関係（１２０、１２１）を含む少なくとも第１の組の関係（１０２）を備える関係型データベース（２０）と、処理ユニット（１３）であって、該関連付けられた位置情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信される位置コードで該関係型データベース（２０）を照会するように適応されている処理ユニット（１３）とを備える。
【解決手段】交通情報クライアントデバイスとして動作するように構成されている電子デバイスは、交通イベントの位置を識別する位置コードを備え得る交通情報メッセージを受信するように適応されているインタフェース（１１）と、メモリ（１２）と、該メモリに格納される関係型データベース（２０）であって、位置コードを位置情報と直接的または間接的に関連付ける少なくとも１つの関係（１２０、１２１）を含む少なくとも第１の組の関係（１０２）を備える関係型データベース（２０）と、処理ユニット（１３）であって、該関連付けられた位置情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信される位置コードで該関係型データベース（２０）を照会するように適応されている処理ユニット（１３）とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
（技術分野）
本発明は、ＴＭＣまたはＴＰＥＧクライアントデバイスなどの交通情報クライアントとして動作するように構成された電子デバイスに関し、さらには、本発明は、そのようなデバイスを動作させる方法に関する。
【背景技術】
【０００２】
（背景）
車両を運転する場合のナビゲーション、とりわけ、配向は、ナビゲーションデバイスの使用によって容易にされ、ナビゲーションデバイスは、一般的に、現在場所を決定するためにグローバルポジショニングシステム（ＧＰＳ）を使用する。経路選択情報と一緒に、現在場所の指示が可視的出力または音声出力によって使用者に提供される。ナビゲーションデバイスは、通常、使用者または運転者によって入力される目的地への経路が計算され得る基準となる地図データを備える。従来のナビゲーションデバイス上に格納された地図情報は静的であるのみであり、これによって、事故または道路工事に起因してなど、特定の道路が通行不能になるか、または封鎖される場合、この地図情報は、経路決定において考慮されない。
【０００３】
この欠点は、どの現在の交通および走行情報（ＴＴＩ）がナビゲーションデバイスおよび運転者に送達され得るかということによる交通メッセージチャネル（ＴＭＣ）を導入することによって克服された。ＴＭＣ上の情報は、一般的に、従来のＦＭラジオ放送によってデジタル的に符号化され、伝送される。さらに、交通メッセージを伝送する、新たな／追加の標準的方法としてのＴＰＥＧプロトコルは、道路状態についての動的な情報をクライアントデバイスに搬送するために使用され得る。ＴＭＣまたはＴＰＥＧメッセージは、イベントコード（ＥＣ）および位置記述を備え、位置記述は、ＴＭＣの場合においては位置コード（ＬＣ）である（ＴＰＥＧの場合においては位置コード（ＬＣ）であり得る）。ＴＭＣまたはＴＰＥＧメッセージは、時間制限（または効果持続期間）、メッセージが関係する国についての情報、および同様なものなど、さらなる情報を備え得る。イベントコードおよび位置コードは、クライアントデバイスにおいて、道路網上の特定の交通イベントおよび位置へなど、使用者に発せられ得る情報へ翻訳されなければならない。この目的のために、クライアントデバイスを動作させる（ＴＭＣおよび／またはＴＰＥＧプロトコルを使用する）交通情報ソフトウェアは、イベントコード表および位置コード表を備える（ＴＭＣ位置が、ＴＰＥＧの場合における選定された参照方法である場合）。
【０００４】
イベントコード表および位置コード表は、従来のデバイスにおいて、ソフトウェアの一部であるか、またはＴＭＣ／ＴＰＥＧクライアントのデータベース中に格納されるかのいずれかである。これら表は、ＴＭＣ／ＴＰＥＧクライアントデバイス上にバイナリラージオブジェクト（ＢＬＯｂ）として格納される。このような構成は、いくつかの不利点を有する。イベントコード表および位置コード表の更新は、困難であり、これら表がソフトウェア中に埋め込まれる場合には、ＴＭＣ／ＴＰＥＧクライアントソフトウェアの更新と一緒に発生しなければならず、つまり、クライアントデバイス上で動作しているソフトウェアが更新されるか、または再インストールされる必要がある。同様に、表の更新は、表がデータベース中にＢＬＯｂとして格納される場合には困難である。プレインストールされたＴＭＣ表は、概して、個々のＴＭＣ／ＴＰＥＧクライアントデバイスが販売される市場に対してのみ適切であり、そして、プレインストールされたＴＭＣ表は、その製造の時点までのみのＴＭＣイベントコードおよび位置コードを備える。更新の他に、例えば新たな使用者言語でなど、イベントコード表および位置コード表を展開することは困難である。
【０００５】
これらの制限に起因して、イベントコード表および位置コード表の機能性が制約される。さらに、これらの表に含まれる情報は、概して、交通メッセージ用の正しい話し言葉出力を再生成することに対して好適ではない。新たな類型の情報もまた、概して、既存の、そして標準化されたイベントコード表および位置コード表に追加され得ない。
【０００６】
バイナリラージオブジェクトの形態において表を格納することは、比較的大量の空間をさらに必要とする。表中の情報にアクセスする場合、オブジェクト全体がクライアントデバイスのメインメモリへロードされる必要があり、このことは、大量のメインメモリを必要とし、デバイスの性能を低減する。同様に、データを表から検索する場合に、アクセスが遅い。したがって、現存のＴＭＣ／ＴＰＥＧクライアントデバイスは、幾分非効率的に動作し、更新または新たな情報の追加に関して非常に融通性が利かない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
（概要）
したがって、上述された欠点のうちの少なくともいくつかを取り除くことと、交通情報クライアントデバイスにおいて復号化する交通メッセージの多用性および融通性を改善することの必要性がある。
【課題を解決するための手段】
【０００８】
この必要性は、独立請求項の特徴によって満たされる。従属請求項において、本発明の好ましい実施形態が記載される。
【０００９】
本発明の第１の局面に従って、交通情報クライアントとして動作するように構成された電子デバイスが提供される。このクライアントデバイスは、交通情報メッセージを受信するように適応されたインタフェースを備え、交通情報メッセージは、交通イベントの位置を識別する位置コードと、メモリと、該メモリ内に格納された関係型データベースとを備える。関係型データベースは、少なくとも１つの関係を含む、少なくとも第１の組の関係を備え、少なくとも１つの関係は、位置コードを位置情報と直接的または間接的に関連付ける。電子デバイスは、処理ユニットをさらに備え、処理ユニットは、関連付けられた位置情報を関係型データベースから検索するために、交通情報メッセージと共に受信された位置コードで関係型データベースを照会するように適応される。
【００１０】
本発明の実施形態において、交通情報メッセージは、交通イベントを識別するイベントコードをさらに備え得、関係型データベースは、少なくとも１つの関係を含む第２の組の関係をさらに備え得、少なくとも１つの関係は、イベントコードをイベント情報と直接的または間接的に関連付ける。次いで、処理ユニットは、関連付けられたイベント情報を関係型データベースから検索するために、交通情報メッセージと共に受信されたイベントコードで関係型データベースを照会するように適応され得る。
【００１１】
エベントコードおよび／または位置コードを関係型データベース中に格納することによって、対応する情報が容易に更新され得、データベースが容易に拡張され得る。さらに、イベント情報および位置情報は、例えば、情報の類型に従ってなど、関係型データベースのいくつかの関係にわたって分布され得る。必然的に、該少なくとも１つの関係はまた、イベント／位置コードをイベント／位置情報と直接的および間接的に関連付け得る。このようにして、コンパクトなデータベースが達成され得る。データベースを照会する場合、要求された情報を備える関係のみがアクセスされる必要がある。このようにして、記憶空間を節約し、必要とされる作業用メモリの量を低減することが可能であり、データベースからの情報の検索がさらに加速される。処理ユニットのサーチ照会は、イベントコード、位置コード、または両方を含み得、勿論、処理ユニットのサーチ照会は、国コード（ｃｃ）、拡張された国コード（ｅｃｃ）、位置表番号（ｌｔｎ）、または同様なものなど、さらなる情報を含み得る。
【００１２】
実施形態において、位置コードはＴＭＣ位置コードであり、電子デバイスは、ＴＭＣクライアントまたはＴＰＥＧクライアントとして動作するように構成される。したがって、交通情報メッセージは、ＴＭＣメッセージまたはＴＰＥＧメッセージであり得る。
【００１３】
好ましくは、ＴＭＣクライアントデバイスとして実装される場合には、関係型データベースは、第１の組の関係および第２の組の関係の両方を備え得る一方、ＴＰＥＧクライアントデバイスとして実装される場合には、関係型データベースは、例えば、ＴＭＣ位置参照を可能にするためになど、第１の組の関係のみを備え得る。必然的に、ＴＰＥＧクライアントデバイスにもまた、両方の組の関係を備える関係型データベースが提供され得る。
【００１４】
本発明のさらなる実施形態に従って、第１の組の関係は、複数のレコードを有する第１の関係を備え、複数のレコードは、異なる国々に対する位置コードを有し、異なる国々に対するレコードは、同一の位置コードを備え得、第１の関係は、該第１の関係の各レコードを一意の位置識別子と関連付ける属性を備える。例として、この第１の関係（以下、位置リスト関係とも呼ばれる）の特定のレコードにアクセスするために、サーチ照会は、位置コードと、ｃｃ、ｌｔｎ、および（提供される場合は）ｅｃｃのうちの１つまたは組合せとを備え得る。そうして、アクセスされたレコードと関連付けられた一意の位置識別子（ｌｏｃＩｄ）が、検索され得、３つまたは４つの前述された属性の代わりに、他の関係中のレコードにアクセスするために使用され得る。次いで、さらなる位置情報へのアクセスが容易にされ、加速される。第１の関係の各レコードは、例えば、位置コード、国コード、拡張された国コード（利用可能な場合）、および位置表番号を、一意の位置識別子と関連付け得る。
【００１５】
上述された位置コードと位置情報との間の間接的な関連付けは、以下の方法で提供され得る。第１の組の関係は、位置コードを、識別子、好ましくは一意の位置識別子および／または位置名称識別子と関連付ける、第１の関係を備え得、さらに、１つ以上の第２の関係を備え得、１つ以上の第２の関係は、それぞれ、特定の類型の位置情報に対するものであり、識別子を対応する位置情報と関連付ける。識別子はまた、「外部キー」とも称され得、別の関係中のレコードへの参照であり得る。したがって、位置情報を複数の関係に分割することが可能であり、それでも依然として、すべての情報は、位置コードによって直接的または間接的にアクセス可能である。勿論、第１の関係はまた、位置コードをさらなる位置情報と直接的に関連付け得る。第２の関係において、識別子は、主キーとして、または主キーの一部として使用され得る。識別子を第１の関係から検索した後に、識別子は、位置情報を第２の関係から検索するために、サーチ照会において使用され得る。
【００１６】
本発明の実施形態において、１つ以上の第２の関係は、エリア位置情報とのエリア位置関係、区画位置情報との区画位置関係、点位置情報との点位置関係、位置名称情報との位置名称関係、位置類型情報との位置類型関係、および座標情報との位置座標関係のうちの少なくとも１つを備える。この構成は、すべてのこれらの類型の情報が単一の関係中に提供される構成と比較して、例えば、区画位置およびエリア位置データフィールドが空であるような点位置に対応する位置コードに対してなど、関係中の空のデータフィールドが回避される利点を有する。情報を複数の関係にわたって分布させることによって、データにアクセスする際の性能がさらに改善され得、必要とされるデータベースの記憶空間が最小化される。
【００１７】
例として、第１の関係は、位置コードを位置分類識別子と関連付け得、位置分類識別子は、対応する位置がエリア位置、線状位置、または点位置であるかどうかを示す。次いで、処理ユニットは、関係型データベースを照会することによって、受信された位置コードの位置分類を識別するように適応され得、また、識別された位置分類に依存して、サーチ照会として、識別子、好ましくは一意の位置識別子を使用して、エリア位置関係、区画位置関係、または点位置関係のいずれかから、さらなる位置情報を検索するように適応され得る。位置コードを一意の位置識別子および位置分類識別子と関連付ける第１の関係によって、処理ユニットは、どの第２の関係および第２の関係のどのレコードをアクセスするかを即座に決定し得る。
【００１８】
第１の関係、区画位置関係、および／または位置類型関係は、各レコードを位置名称識別子と関連付ける属性を備え得、位置名称関係は、位置名称識別子を位置名称と関連付けるレコードを備える。位置名称識別子は、例えば、位置名称関係の主キー、または主キーの一部である。したがって、すべての位置名称を、例えば、人間が理解可能なテキスト文字列の形態においてなど、単一の関係中に格納することが可能である。すべての他の関係は、位置名称を検索するために、位置名称識別子に対する属性を備える必要があるのみである。このことは、１つのコンパクトな関係が更新される必要があるのみであるから、異なる位置に対して利用可能なテキスト表現の更新または拡張を容易にする。
【００１９】
第１の組の関係は、位置コードを、下記の属性のうちの少なくとも１つ以上の組合せと直接的または間接的に関連付ける、エリア位置関係を備え得、ここで、上記属性は、位置コードに対応するエリアがサービス放送エリアであるかどうかを示す属性、および、位置コードに対応するエリアが位置する州の略号を備える属性である。このような略号は、例えば、カリフォルニアに対する「ＣＡ」であり得る。
【００２０】
第１の組の関係は、さらに、位置コードを、下記の属性のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、区画位置関係を備え得、ここで、上記属性は、位置名称識別子、道路名称、位置コードに対応する区画の道路番号のプレフィクス文字列部を備える道路番号プレフィクス、位置コードに対応する区画の道路番号の整数部を備える道路番号属性、位置コードに対応する区画の道路番号のサフィクス文字列部を備える道路番号サフィクスである。
【００２１】
このようにして、道路番号（例えば、Ａ９、Ｂ２Ｒ、または同様なものなど）は、プレフィクス、番号、およびサフィクスの３部に分割され得、このことは、道路番号属性に従った交通メッセージの番号によるソーティング、または、該プレフィクスに対応する道路標識の図形表現上の整数の道路番号の図形的表現を可能にする。
【００２２】
第１の組の関係は、さらに、位置コードを、下記の属性のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、点コード関係を備え得、ここで、上記属性は、位置コードに対応する点位置のジャンクション名称の番号部を備えるジャンクション番号、位置コードに対応する点位置のジャンクション名称の文字列部を備えるジャンクション番号サフィクス、第１の方向（正の方向）における次の点位置までの道路距離、第２の方向（負の方向）における次の点位置までの道路距離、位置が都市部であるかどうかを示す情報、第１の方向の自動車専用道路に沿った既定の迂回路に対する迂回番号、および第２の方向の自動車専用道路に沿った既定の迂回路に対する迂回番号である。この場合もまた、ジャンクション名称を番号およびサフィクスに分割することによって、ジャンクション番号に従ったソーティングが可能になる。さらには、隣接する点位置までの距離情報を伴うことで、２つの点位置を接続する道路区間に沿った現実の距離が属性中に入力され得るので、２つの点位置間の距離が写実的にモデル化され得る。このことは、交通メッセージによって開始されるナビゲーションデバイスにおける経路コストの計算を改善し得る。
【００２３】
第１の組の関係は、さらに、位置コードを、座標、座標分類、およびシーケンス番号と直接的または間接的に関連付ける、位置座標関係を備え得る。座標は、例えば、ｘおよびｙ座標、または、ＷＧＳ ８４形式における経度および緯度座標であり得る。関係は、さらに、関係の各レコードを、主キーとして使用される一意の位置識別子およびインデックス番号と関連付ける属性を備え得る。位置の類型（エリア、線状、または点）に依存して、位置は、シーケンス番号によって指定され得る複数の点で記述され得る。位置の類型に依存して（点位置に対しては、記述されるべき具体的な座標に依存して）、いくつかの座標分類がある。すなわち、「ＡＲＥＡ」類型は、エリアの外形をポリゴンのいくつかの点で記述する、複数の座標に対して使用され得、「ＬＩＮＥ」類型は、（道路または道路の区画などの）線状位置の端点に対して使用され得、５つの類型「ＣＥＮＴＲＥ＿ＰＯＩＮＴ」、「ＰＯＳＩＴＩＶＥ＿ＳＴＡＲＴ」、「ＮＥＧＡＴＩＶＥ＿ＳＴＡＲＴ」、「ＰＯＳＩＴＩＶＥ＿ＥＮＤ」、「ＮＥＧＡＴＩＶＥ＿ＥＮＤ」は、点位置の中心を記述するために使用され得る（例えば、これは、大きな幹線道路交差点に対しては、交差点の地理的中心であり得る）。道路の一端または他端における幹線道路交差点の始まりを記述するために、開始座標が使用され得（したがって、ＴＭＣリンケージの正方向および負方向の各々に対して座標類型が提供され得る）、幹線道路交差点の終わりを記述するために、終了座標が使用され得る（この場合も、別個の座標類型を有する両方の道路方向）。
【００２４】
第１の組の関係は、さらに、道路番号プレフィクスを優先度と関連付ける道路プレフィクス関係を備え得る。このようにして、特定の類型の道路の優先度を識別することが可能になり、このことは、道路優先度に従ってメッセージリスト中のＴＭＣ／ＴＰＥＧメッセージをソートするために使用され得る。
【００２５】
第１の組の関係は、さらに、とりわけ点位置のために、位置コードを、少なくとも第１の一意の位置識別子および第２の一意の位置識別子と直接的または間接的に関連付ける、相互参照関係を備え得る。相互参照関係において、同一の物理的道路上に位置する、点位置の複数の対が格納され得る。したがって、同一の道路の一続きを指すＴＭＣ／ＴＰＥＧメッセージは、たとえ、それらメッセージが異なる点位置に対する位置コードを使用しても、識別され得、メッセージのうちの一方は、冗長な情報の表示を回避するために抑制され得る。
【００２６】
さらなる実施形態において、第２の組の関係は、イベントコードをイベントテキストと直接的または間接的に関連付ける、イベント名称関係を備え、該イベント名称関係は、２つ以上の異なる言語において、イベントテキストのためのレコードを備え、該関係は、さらに、各レコードにおいてイベントテキストが提供される言語を識別する属性を備える。好ましくは、イベント名称関係は、イベント名称をイベントテキストと直接的に関連付ける。イベント名称関係は、関係する交通イベントテキストがどの類型の数量詞と結合され得るかを示すための数量詞類型属性など、さらなる属性を備え得る。数えられる要素（例えば温度などの物理的値と対照的に）を記述する、ＴＭＣメッセージ中において伝送される数量詞は、単数（伝送される数量詞の値が１）または複数（値が１より大きい）であり得る。さらに、数量詞の値を含有せず送信されるＴＭＣメッセージがあり得る。３つの場合（単数／複数／数量詞なし）の各々に対して、イベントテキストは、クライアントデバイスのテキスト生成モジュールが、挿入された数量詞の値を有するＴＭＣメッセージの整形されたテキスト表現を生み出すことを可能にするために、異なる言い回しを必要とし得る。次いで、イベントコード、数量詞類型、および言語コードは、イベント名称関係のレコードにアクセスするための主キーとして使用され得る。
【００２７】
同様に、第１の組の関係は、位置コードを位置名称と直接的または間接的に関連付ける、位置名称関係を備え得、該位置名称関係は、２つ以上の異なる言語において、位置名称のためのレコードを備え、該関係は、さらに、言語コードを有する属性を備え、言語コードは、各レコードにおいて位置名称が提供される言語を識別する。位置コードに対して、関連付けは、好ましくは、間接的なものである。位置名称関係は、例えば、主キーとして、上述された一意の位置識別子および言語コードを使用し得る。位置名称は、テキスト文字列の形態において、位置名称関係中に格納され得る。
【００２８】
したがって、関係型データベースは、単に、言語コードを有する対応するレコードを、イベント名称関係および／または位置名称関係に追加することによって、さらなる言語で簡単に拡張され得る。さらには、残りの関係はすべて、言語独立であり得る。このようにして、新たな言語での更新は、これら２つの関係のみに制限され得、これは、時間効率的かつメモリ効率的である。
【００２９】
特定の言語においてテキストを検索するために、処理ユニットは、電子デバイスの現在の言語設定、または使用者選好の言語を決定するように適応され得、現在の言語または使用者選好の言語において、イベントテキストまたは位置名称を、それぞれ、イベント名称関係または位置名称関係から検索するために、サーチ照会において対応する言語コードを使用し得る。
【００３０】
さらなる実施形態において、イベント名称関係または位置名称関係は、それぞれ、対応するイベントテキストまたは位置名称の音素表現を検索するために、イベントテキストまたは位置名称を音素識別子と関連付け得る。これらの関係は、追加的または代替的に、対応するイベントテキストまたは位置名称の音響表現を検索するために、それぞれ、イベントテキストまたは位置名称を声音識別子と関連付け得る。このようにして、音素識別子および声音識別子は、関係型データベースにおいて提供されるさらなる関係から対応する音素表現または音響表現を検索するために、外部キーとして機能し得る。テキスト文字列に対して、音素表現、または、音声ファイルなどの音響表現までも提供することによって、対応するテキストの話し言葉出力は、有意に強化され得る。
【００３１】
第１の組の関係は、なおもさらに、イベントコードを下記の属性のうちの少なくとも１つまたは組合せと関連付けるイベント関係を備え得、ここで、上記属性は、イベントコードと関連付けられたアイコン組を識別するアイコン組識別子、イベントの性質を識別するイベント性質、対応する交通情報メッセージの持続期間の決定のための情報を備える持続期間類型、イベントが交通の一方向または両方向に関係するかどうかを示すデフォルト方向性、イベントの緊急度を示すイベント緊急度、交通イベントの深刻度を示す渋滞分類、クライアントデバイスにおける更新機構によって使用される更新等級、および、イベントと共に使用されることが許される数量詞類型についての指示である。アイコン組識別子は、アイコンについての情報を含有する別の関係への外部キーであり得、アイコンは、ＴＭＣクライアントデバイスのディスプレイ上で、交通イベントに対する指示として表示され得る。渋滞分類属性は、適用可能ならば機械可読な形態において、イベントテキストのテキスト的ステートメントを備え得、これによって、渋滞分類属性が、経路選択アプリケーションにおける走行コストの決定のために使用され得る。
【００３２】
関係型データベースは、さらに、受信されたＴＭＣメッセージに含まれる国識別子を、下記の属性のうちの少なくとも１つまたは組合せと関連付ける、局リスト関係を備え得、ここで、上記属性は、ＴＭＣメッセージを放送する送信者を示す送信者識別子、ラジオ番組を識別する番組識別子、送信者が受信可能である地理的エリアを記述するタイル識別子である。この場合もまた、国識別子は、ｃｃ、ｅｃｃ、およびｌｔｎのうちの１つまたは組合せであり得る。ＴＭＣメッセージを送信しているラジオ局が受信可能であるエリアは、異なるレベルのタイルによって識別され得る。したがって、局リスト関係によって、どのエリアがＴＭＣメッセージを放送しているどのラジオ局によって提供されているかが識別され得る。
【００３３】
本発明のさらなる局面に従って、交通情報クライアントとして動作するように構成された電子デバイスを動作させる方法が提供される。電子デバイスは、交通情報メッセージを受信するためのインタフェースと、位置コードを位置情報と直接的または間接的に関連付ける少なくとも第１の組の関係を備える関係型データベースとを備える。本方法は、交通イベントの位置を識別する位置コードを備える交通情報メッセージをインタフェース上で受信するステップと、サーチ照会として位置コードを使用して関係型データベースを照会するステップと、位置コードと関連付けられた位置情報を関係型データベースから検索するステップとを包含する。
【００３４】
本発明の方法で、交通情報クライアントデバイスに関して上記で概説された利点と同様の利点が達成され得る。
【００３５】
本発明の実施形態において、関係型データベースは、さらに、少なくとも１つの関係を含む第２の組の関係を備え、少なくとも１つの関係は、イベントコードをイベント情報と直接的または間接的に関連付け、受信された交通情報メッセージは、さらに、交通イベントを識別するイベントコードを備える。本方法は、さらに、サーチ照会としてイベントコードを使用して関係型データベースを照会するステップと、イベントコードと関連付けられたイベント情報を関係型データベースから検索するステップとを包含し得る。
【００３６】
本方法は、２つの別個のサーチ照会の使用を包含し得、１つはイベントコードに対して、１つは位置コードに対してである。必然的に、各サーチ照会は、関係型データベース中のレコードを一意に識別するために、ｃｃ、ｅｃｃ、またはｌｔｎなどのさらなる情報を備え得る。
【００３７】
本発明の方法の実施形態において、電子デバイス、とりわけ、関係型データベースは、交通情報クライアントデバイスの複数の異なる実施形態に関して上述されたように構成される。
【００３８】
本発明のさらなる局面に従って、電子的に可読なデータキャリアであって、その上に格納された関係型データベースを備えるデータキャリアが提供される。関係型データベースは、少なくとも１つの関係を含む第１の組の関係を備え、少なくとも１つの関係は、ＴＭＣ位置コードを位置情報と直接的または間接的に関連付ける。
【００３９】
実施形態において、関係型データベースは、さらに、少なくとも１つの関係を含む第２の組の関係を備え、少なくとも１つの関係は、イベントコードを、イベント情報、とりわけＴＭＣイベントコードと直接的または間接的に関連付ける。さらなる実施形態において、データキャリア上に格納された関係型データベースは、交通情報クライアントデバイスの複数の実施形態のうちのいずれかに関して上述されたように構成される。
【００４０】
上述された本発明の複数の局面および実施形態の特徴、ならびに、以下にさらに説明される同特徴は、示されるそれぞれの組合せにおいてのみならず、本発明の範囲を逸脱することなく、他の組合せにおいても、または単独でも使用され得る。
【００４１】
以上により、本発明は、例えば以下の項目を提供する。
【００４２】
（項目１）
交通情報クライアントデバイスとして動作するように構成されている電子デバイスであって、
交通情報メッセージを受信するように適応されているインタフェース（１１）であって、交通情報メッセージは、交通イベントの位置を識別する位置コードを備え得る、インタフェース（１１）と、
メモリ（１２）と、
該メモリに格納される関係型データベース（２０）であって、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、関係型データベース（２０）と、
処理ユニット（１３）であって、該関連付けられた位置情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信される位置コードで該関係型データベース（２０）を照会するように適応されている処理ユニット（１３）と
を備えている、電子デバイス。
【００４３】
（項目２）
交通情報メッセージは、交通イベントを識別するイベントコードをさらに備え得、上記関係型データベースは、少なくとも１つの関係（１１０、１１１）を含む第２の組の関係（１０１）をさらに備え、該少なくとも１つの関係（１１０、１１１）は、イベントコードをイベント情報と直接的または間接的に関連付け、
上記処理ユニットは、該関連付けられたイベント情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信されるイベントコードで該関係型データベース（２０）を照会するように適応されている、上記項目のうちのいずれかに記載の電子デバイス。
【００４４】
（項目３）
上記第１の組の関係は、複数のレコードを有する第１の関係（１２０）を備え、該複数のレコードは、異なる国々に対する位置コードを有し、異なる国々に対する該レコードは、同一の位置コードを備え得、該第１の関係は、該第１の関係の各レコードを一意の位置識別子と関連付ける属性を備える、上記項目のうちのいずれかに記載の電子デバイス。
【００４５】
（項目４）
上記第１の組の関係は、第１の関係（１２０）と、１つ以上の第２の関係（１２１、１２３、１２４、１２５）とを備え、該第１の関係（１２０）は、上記位置コードを、識別子、好ましくは、一意の位置識別子および／または位置名称識別子と関連付け、該１つ以上の第２の関係（１２１、１２３、１２４、１２５）は、それぞれ、特定の類型の位置情報に対して、該識別子を対応する該位置情報と関連付け、これによって、該第１の関係（１２０）は、該位置情報との間接的な関連付けを提供する、上記項目のうちのいずれかに記載の電子デバイス。
【００４６】
（項目５）
上記１つ以上の第２の関係（１２１、１２２、１２３、１２４、１２５、１２６）は、
エリア位置情報を有するエリア位置関係（１２３）と、
区画位置情報を有する区画位置関係（１２４）と、
点位置情報を有する点位置関係（１２５）と、
位置名称情報を有する位置名称関係（１２１）と、
位置類型情報を有する位置類型関係（１２２）と、
座標情報を有する位置座標関係（１２６）と
のうちの少なくとも１つの関係を備える、上記項目のうちのいずれかに記載の電子デバイス。
【００４７】
（項目６）
上記第１の関係（１２０）は、上記位置コードを位置分類識別子と関連付け、該位置分類識別子は、対応する位置がエリア位置、線状位置、または点位置であるかどうかを示し、
上記処理ユニット（１３）は、上記関係型データベース（２０）を照会することによって、受信された位置コードの位置分類を識別するように適応され、かつ、該識別された位置分類に依存して、サーチ照会として、該識別子、好ましくは上記一意の位置識別子を使用して、上記エリア位置関係（１２３）、上記区画位置関係（１２４）、または上記点位置関係（１２５）のいずれかから、さらなる位置情報を検索するように適応されている、上記項目のうちのいずれかに記載の電子デバイス。
【００４８】
（項目７）
上記第１の関係（１２０）、上記区画位置関係（１２４）、および／または上記位置類型関係（１２２）は、各レコードを位置名称識別子と関連付ける属性を備え、上記位置名称関係（１２１）は、該位置名称識別子を位置名称と関連付けるレコードを備える、上記項目のうちのいずれかに記載の電子デバイス。
【００４９】
（項目８）
上記第１の組の関係（１０２）は、エリア位置関係（１２３）を備え、該エリア位置関係（１２３）は、位置コードを、
該位置コードに対応するエリアがサービス放送エリアであるかどうかを示す属性と、
該位置コードに対応するエリアが位置する州の略号を備える属性と
のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５０】
（項目９）
上記第２の組の関係（１０１）は、イベントコードをイベントテキストと直接的または間接的に関連付けるイベント名称関係（１１１）を備え、該イベント名称関係（１１１）は、２つ以上の異なる言語において、該イベントテキストのためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該イベントテキストが提供される言語を識別する、上記項目のうちのいずれかに記載の電子デバイス。
【００５１】
（項目１０）
上記第１の組の関係（１０２）は、位置コードを位置名称と直接的または間接的に関連付ける位置名称関係（１２１）を備え、該位置名称関係は、２つ以上の異なる言語において、該位置名称のためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該位置名称が提供される言語を識別する、上記項目のうちのいずれかに記載の電子デバイス。
【００５２】
（項目１１）
上記イベント名称関係（１１１）または上記位置名称関係（１２１）は、それぞれ、対応する上記イベントテキストまたは上記位置名称の音素表現を検索するために、該イベントテキストまたは該位置名称を音素識別子とさらに関連付け、かつ／あるいは、それぞれ、対応する該イベントテキストまたは該位置名称の音響表現を検索するために、該イベントテキストまたは該位置名称を声音識別子とさらに関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５３】
（項目１２）
上記第２の組の関係（１０１）は、イベント関係（１１０）を備え、該イベント関係（１１０）は、上記イベントコードを、
イベントコードと関連付けられたアイコン組を識別するアイコン組識別子と、
上記イベントの性質を識別するイベント性質と、
対応するＴＭＣメッセージの持続期間の決定のための情報を備える持続期間類型と、
該イベントが交通の一方向または両方向に関係するかどうかを示すデフォルト方向性と、
該イベントの緊急度を示すイベント緊急度と、
該交通イベントの深刻度を示す渋滞分類と、
該イベントの更新等級を識別する更新等級と、
該イベントと結合されることが許される数量詞の類型を示す数量詞類型と
のうちの少なくとも１つの属性またはこれら属性の組合せと直接的または間接的に関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５４】
（項目１３）
上記関係型データベース（２０）は、局リスト関係（１０３）をさらに備え、該局リスト関係（１０３）は、受信されたＴＭＣメッセージ中に含まれる国識別子を、
ＴＭＣメッセージを放送する送信者を示す送信者識別子と、
ラジオ番組を識別する番組識別子と、
該送信者が受信可能である地理的エリアを記述するタイル識別子と
のうちの少なくとも１つの属性またはこれら属性の組合せと関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５５】
（項目１４）
上記位置コードはＴＭＣ位置コードであり、上記電子デバイスは、ＴＭＣクライアントまたはＴＰＥＧクライアントとして動作するように構成されている、上記項目のうちのいずれかに記載の電子デバイス。
【００５６】
（項目１５）
交通情報クライアントとして動作するように構成された電子デバイス（１０）を動作させる方法であって、該電子デバイス（１０）は、交通情報メッセージを受信するためのインタフェース（１１）と、少なくとも第１の組の関係（１０２）を備える関係型データベース（２０）とを備え、該第１の組の関係（１０２）は、位置コードを位置情報と直接的または間接的に関連付ける少なくとも１つの関係（１２０、１２１）を含み、該方法は、
交通イベントの位置を識別する位置コードを備える交通情報メッセージを該インタフェース（１１）上で受信するステップと、
サーチ照会として該位置コードを使用して該関係型データベース（２０）を照会するステップと、
該位置コードと関連付けられた位置情報を該関係型データベース（２０）から検索するステップと
を包含する、方法。
【００５７】
（項目１６）
上記電子デバイスは、上記項目のうちのいずれかに従って構成されている、上記項目のうちのいずれかに記載の方法。
【００５８】
（項目１７）
電子的に可読なデータキャリアであって、該データキャリアは、該データキャリア上に格納された関係型データベースを備え、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、電子的に可読なデータキャリア。
【００５９】
（項目１８）
上記関係型データベース（２０）は、上記項目のうちのいずれかに従って構成されている、上記項目のうちのいずれかに記載の電子的に可読なデータキャリア。
【００６０】
（摘要）
本発明は、交通情報クライアントとして動作するように構成された電子デバイスを提供する。交通情報クライアントデバイスは、交通情報メッセージを受信するように適応されたインタフェースを備え、交通情報メッセージは、交通イベントの位置を識別する位置コードを備え得る。交通情報クライアントデバイスは、さらに、メモリと、該メモリに格納された関係型データベースとを備え、関係型データベースは、少なくとも１つの関係を含む、少なくとも第１の組の関係を備え、少なくとも１つの関係は、位置コードを位置情報と直接的または間接的に関連付ける。
【図面の簡単な説明】
【００６１】
本発明の前記および他の特徴ならびに利点は、添付の図面と共に読まれると、以下の例示的実施形態の詳細な説明からさらに明白になろう。
【図１】図１は、本発明の実施形態に従うＴＭＣクライアントデバイスを図示する概略図である。
【図２】図２は、本発明の実施形態に従う関係型データベースの複数の関係を概略的に図示する。
【図３】図３は、図２の実施形態に従う関係型データベースのさらなる関係を概略的に図示する。
【図４】図４は、本発明の実施形態に従う方法を図示するフロー図である。
【図５】図５は、本発明の実施形態に従う方法を図示するフロー図である。
【図６】図６は、本発明の実施形態に従う関係型データベースの更新を図示するフロー図である。
【発明を実施するための形態】
【００６２】
以下において、本発明の実施形態は、添付の図面を参照して詳細に説明される。以下の実施形態の説明は、例示の目的のためにのみ供され、限定的な意味にとられるべきではないことを理解されたい。図面は、概略の表現であるようにのみ見なされるべきであり、図面中の複数の要素は、必ずしも互いにスケールを決める必要はない。図面中に示された物理的もしくは機能的なブロック、または、物理的もしくは機能的なユニットは、必ずしも物理的に別個のユニットとして実装される必要はないが、示されるか、または説明されるブロックもしくはユニットは、別個のユニット、回路、チップ、または回路要素として実装され得るか、あるいは、共通の回路、チップ、回路要素、またはユニットとしても同様に実装され得る。
【００６３】
以下において、ＴＭＣメッセージを受信するＴＭＣクライアントデバイスに対して参照がなされるが、この説明は、本発明に対して明らかに非制限的であり、ＴＰＥＧメッセージを受信するＴＰＥＧクライアントデバイスなど、任意の類型の交通情報クライアントデバイスが本発明によって網羅されることを留意されたい。とりわけ、ＴＭＣメッセージと共に受信される位置コードの処理に関して以下に供される説明は、ＴＭＣ位置参照を使用するＴＰＥＧクライアントデバイスにおいて、ＴＰＥＧメッセージと共に受信される位置コードの処理に対して同等に適用可能である。
【００６４】
図１は、本発明の実施形態に従う交通情報クライアントデバイス１０の概略ブロック図を示す。交通情報クライアントデバイス１０は、ＴＭＣまたはＴＰＥＧクライアントとして動作するように適応され得、とりわけ、交通情報クライアントデバイス１０は、ＴＭＣメッセージおよび／またはＴＰＥＧメッセージを受信もしくは解釈するように適応される。受信されたＴＭＣメッセージまたはＴＰＥＧメッセージに含まれる情報は、交通情報クライアントデバイス１０によって処理され、デバイスの使用者に提示される。以下において、ＴＭＣクライアントデバイスとしてのデバイス１０の実装が説明されるが、この説明は、ＴＰＥＧクライアントデバイスおよびＴＰＥＧメッセージに対して等しく適用可能であることが明らかであろう。
【００６５】
ＴＭＣクライアントデバイス１０は、受信ユニット１１を備え、受信ユニット１１は、ＴＭＣメッセージを受信するためのインタフェースを提供するように適応される。ＴＭＣメッセージは、概して、ＦＭ放送を使用して伝送され、該メッセージは、ＦＭラジオデータシステム（ＲＤＳ）を使用してデジタル的に符号化される。したがって、受信ユニット１１は、ＲＤＳが有効にされたＦＭ受信器を備え得る。従来のＦＭラジオ放送以外に、ＴＭＣメッセージはまた、デジタル音声放送（ＤＡＢ）上で、または衛星ラジオ上で伝送され得る。したがって、受信ユニット１１はまた、これらのチャネル上でＴＭＣメッセージを受信するように適応され得る。他の実施形態において、受信ユニット１１は、ＴＭＣメッセージを、そのようなメッセージを提供する任意のソースから受信するように適応される。ＴＰＥＧデバイスとして実装される場合、受信ユニット１１は、ＴＰＥＧメッセージを受信するように適応され得、ＴＰＥＧメッセージは、デジタル放送（例えばＤＡＢ）またはセルラー／インターネット接続などの二地点間接続を使用して伝送される。しかしながら、一般的に、ＴＰＥＧはベアラ独立であるように設計されるので、任意のデジタルベアラが使用され得、したがって、任意の類型のＴＰＥＧメッセージが受信ユニット１１によって受信され得る。
【００６６】
ＴＭＣクライアントデバイス１０は、さらに、受信されたＴＭＣメッセージを処理するように適応される処理ユニット１３を備える。処理ユニット１３は、メモリ１２に格納された制御プログラムに従って、ＴＭＣクライアントデバイス１０の動作を制御する。処理ユニット１３は、汎用または専用のマイクロプロセッサもしくは１つ以上のデジタル信号プロセッサ、あるいは特定用途向け集積回路の形態において、単一または複数のマイクロプロセッサとして実装され得る。メモリ１２は、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、またはハードドライブなど、あらゆる形態のメモリを備え得る。これらの類型のメモリのうちのいくつかは、フラッシュメモリカードまたは同等物など、デバイス１０から取り外し可能であり得る。
【００６７】
処理ユニット１３は、機能ユニット２５および２６を備え、機能ユニット２５および２６は、例えば、処理ユニット１３上で走行するソフトウェアコード部分として実装され得る。検索ユニット２５は、着信するＴＭＣメッセージを、その中に含まれる情報について解析するように適応され、このような情報は、ＴＭＣイベントコード（ＴＰＥＧメッセージの場合はＴＰＥＧコード、本特許の部分ではない）、ＴＭＣ位置コード、国コード（ｃｃ）、拡張された国コード（ｅｃｃ）（供給される場合）、位置表番号（ｌｔｎ）、イベント識別子、位置オフセット、方向、および同様なものなどである。ＴＰＥＧクライアントデバイスとして実装される場合、検索ユニット２５は、受信されたＴＰＥＧメッセージ中に含まれるＴＭＣ位置コンテナから、ｃｃ、ｅｃｃ（供給される場合）、およびｌｔｎのみならず、ＴＭＣ位置コードを抽出し得、さらに、ＴＰＥＧメッセージからＴＰＥＧイベントコードおよび同様なものを抽出し得る。
【００６８】
検索ユニット２５は、受信されたＴＭＣメッセージから抽出された情報からサーチ照会を構成し、対応するイベント情報または位置情報を検索するために、このサーチ照会を使用して、メモリ１２に格納された関係型データベース２０を照会する。データベース２０から検索された情報から、処理ユニット３０は、図形的メッセージまたはテキストメッセージを組立て、これらメッセージは、ディスプレイ１５によってＴＭＣクライアントデバイス１０の使用者に発せられ得る。他の実施形態において、拡声器（示されていない）によってＴＭＣクライアントデバイス１０の使用者に発せられる声音メッセージがコンパイルされる。
【００６９】
受信されるＴＭＣメッセージは、ＴＭＣ規格（例えば、ＡＬＥＲＴ Ｃ規格、またはＩＳＯ １４８１９）において規定されるように、任意の情報を備え得る。受信されたＴＭＣメッセージを復号化する場合、処理ユニット１３は、対応する交通イベントの類型および場所を識別する必要がある。交通イベントの類型は、イベントコードによって識別される。このような類型は、例えば、「静止した交通」、「列をなしている交通」、「ゆっくりとした交通」、または同様なものであり得る。ＴＭＣメッセージ中に含まれる位置コードは、交通イベントの位置を識別し、そして、対応する位置表を使用することによって復号化され得る。異なる国々に対する位置表は、同一の位置コードを備え得るので、国および使用されるべき位置表を一意に識別するために、追加の値ｃｃ、ｅｃｃ、およびｌｔｎが使用される。次いで、交通渋滞の開始場所および終了場所は、交通渋滞の開始している場所を識別する位置コードと、交通渋滞の延びを識別する方向およびオフセットとから識別され得る。処理ユニット１３は、対応する情報を関係型データベース２０から検索し、「ミュンヘンとミュンヘン空港との間で４ｋｍの列をなしている交通」などの対応するメッセージを発するように適応される。
【００７０】
受信されるＴＰＥＧメッセージは、ＴＰＥＧ規格（ＩＳＯ １８２３４シリーズまたはＩＳＯ ２１２１９シリーズ）において規定されるように、任意の情報を備え得る。ＴＰＥＧメッセージの位置内容は、それがＴＭＣ位置参照を使用する場合、ＴＭＣメッセージの位置部に類似する手法において処理される。
【００７１】
従来のシステムにおいて、イベント表および位置表は、ＴＭＣまたはＴＰＥＧクライアントソフトウェア内に含まれ、バイナリラージオブジェクトの形態において格納されるが、本発明は、イベント情報および位置情報を備える関係型データベース２０を提供する。関係型データベース２０の可能な実装は、図２および図３に関連して、以下に説明される。
【００７２】
関係型データベース２０は、少なくとも、位置情報を備える第１の組の関係１０２（図３）と、イベント情報を備える第２の組の関係１０１（図２）とを備える。一般的に、両方の組の関係がＴＭＣクライアントデバイスにおいて提供されるが、ＴＰＥＧクライアントデバイスは、ＴＭＣ位置参照のために、第１の組の関係のみを備え得る。さらに、ＴＰＥＧクライアントデバイスはまた、ＴＰＥＧイベントコードをイベント情報と関連付ける第２の組の関係を有するデータベースを備え得、以下に供される説明が、必要な変更を伴って適用可能である。
【００７３】
図２および図３において、関係は、矩形によって図示され、参照符号によって表記される。各関係は、第１行に関係の名称を備える。次の組の行において、主キー（ＰＫ）として使用され得る関係の属性が識別される。第３の組の行は、関係のさらなる属性を備える。本実施形態において必須である各関係のさらなる属性は、太字フォントで表される一方、随意的な属性は、通常フォントで複写されている。他の実施形態において、他の属性が必須または随意であり得ることは明確であろう。関係は、外部キーを有する属性を備え得、外部キーは、別の関係中のレコードを識別するために使用され得る。これは、関係間の線によって図示され、線が向かって接続する関係の中のレコードにアクセスするための外部キーを示す。これは、後で詳細に説明される。
【００７４】
第２の組の関係１０１は、イベントコードをイベント情報と直接的に関連付ける２つの関係１１０および１１１を備える。他の実施形態において、唯一のこのような関係が提供され得るか、または、イベントコードをイベント情報と間接的に関連付ける関係が提供され得る。
【００７５】
イベント関係１１０は、主キー（ＰＫ）として使用されるイベントコードを、以下に詳述されるイベント情報を備えるいくつかの属性と直接的に関連付ける。各関係は、表として想定され得、このような表は、表の列を形成する属性と、行を形成する関係の（タプルまたはリレーションシップとも呼ばれる）レコードとを有する。各レコードまたは各表の行は、主キーによって一意に識別され得る。したがって、主キーが供されると、関係または表の残りの属性の値は、主キーによって識別されたレコードから検索され得る。
【００７６】
ＴＭＣイベント関係１１０は、各イベントコードに対して、テキストおよび追加の情報を備え、テキストおよび追加の情報は、例えば、メッセージ管理のために使用され得る。主キーｅｖｅｎｔＣｏｄｅは、ＴＭＣメッセージ中において受信される場合のイベントコードである。属性ｉｃｏｎＳｅｔＩｄは、アイコン組識別子を備え、アイコン組識別子は、ナビゲーションデバイスのディスプレイ上に表示され得るアイコンについての情報を含有する別個の表（示されていない）へのリンクである。各交通イベントに対して、アイコンの一類型が別個の表において提供され得る（例えば、交通イベント「交通渋滞」に対する、赤い枠を有する三角形の中に表示されたいくつかの自動車）。ＴＭＣクライアントデバイスのディスプレイ上において、サイズ、色（例えば、昼間アイコンまたは夜間アイコン）などが異なり得る「交通渋滞」アイコンのいくつかの出現があり得るので、組全体のアイコンが各交通イベントに割当てられる。現在時刻またはディスプレイサイズなどのさらなる情報を使用して、適切なアイコンが検索され得る。
【００７７】
関係１１０は、属性ｊａｍＣａｔｅｇｏｒｙをさらに備え、属性ｊａｍＣａｔｅｇｏｒｙは、機械可読な形態において、「重度の交通」または「ゆっくりとした交通」など、イベントコードに対応するイベントテキストのテキスト的ステートメントを記述する。これらステートメントは、ＴＭＣクライアントデバイス１０の経路選択ユニット（示されていない）に提供され得るか、または、この経路選択ユニットによって検索され得る。このようなユニットが開始点から目的地までの経路を決定する場合、ユニットは、それぞれの道路区画に対する経路選択コストを決定するために、渋滞分類を考慮し得る。イベントコードと関連付けられたイベントテキストは、交通渋滞に関係した情報をテキスト文字列としてのみ供するが、渋滞分類属性は、この情報を直接的に数字形式において提供し得、時間を費やすイベントテキストの言語依存解析を回避する。
【００７８】
関係１１０は、イベントコードをイベント情報と関連付ける、いくつかのさらなる属性を備える。これらは、交通イベントの性質を記述するイベント性質属性、数量詞の類型を決定する許容された数量詞類型属性を含み、許容された数量詞類型属性は、ゆっくりと動く交通の平均速度など、イベントコードと共に使用され得る。ｄｕｒａｔｉｏｎＴｙｐｅ属性は、メッセージの持続期間を決定し、ＴＭＣクライアントデバイスによって、（例えば、特定の交通イベントの持続性など）メッセージ管理のために使用され得る。例として、「Ｄ」は、短い持続期間の動的イベントを指示し得、「Ｌ」は、より長く継続するイベントを指示し得る。コードが括弧内に置かれる場合、持続期間情報は、本実施形態におけるクライアントデバイスの使用者に提示されない。
【００７９】
さらなる属性が、交通イベントが一方向もしくは両方向に関連しているかどうかを示すｄｅｆａｕｌｔＤｉｒｅｃｔｉｏｎａｌｉｔｙ、イベントの緊急度、またはｕｐｄａｔｅＣｌａｓｓを備え、ｕｐｄａｔｅＣｌａｓｓは、ＴＭＣクライアントデバイスによるメッセージ管理のための更新機構によって使用される。
【００８０】
イベント名称関係１１１は、イベントコードをイベントテキストと直接的に関連付ける。同一のイベントコードに対して、対応するイベントテキストが、関係１１１中に異なる言語において提供される。したがって、属性ｌａｎｇｕａｇｅＣｏｄｅは、属性ｅｖｅｎｔＣｏｄｅと一緒に、主キーとして使用される必要がある。さらに、イベントテキストは、数量詞を有さずに、単数の数量詞に対して、または１より大きい数量詞に対して、提供され得る。したがって、「ｑｕａｎｔｉｆｉｅｒ」属性は、交通イベントテキストがどの類型の数量詞に対して検索されるべきかを示すために、主キーにおいて使用される。複数形の形態に対して、イベントテキストは、例えば、プレースホルダを備え得る。単数形／複数形の形態に対して格納されるイベントテキストは、例えば、「（１台／Ｑ台）の重量のあるトラックを巻き込む事故」などであり得る。３の数量詞に対しては、イベントテキストは「３台の重量のあるトラックを巻き込む事故」と読み得る。単数形の形態に対しては、イベントテキストは「１台の重量のあるトラックを巻き込む事故」と読み得る。
【００８１】
イベントテキスト中の固定コード化された値は、例えば、番号を「＄」文字の間に置くことによってなど、特別な手法においてマークされ得る。
【００８２】
イベントテキストが数量詞プレースホルダを含有する場合、数量詞プレースホルダもまた、特別な文字によってマークされ、特別な文字は、実際の値および数量詞の単位によって置換され得る。例として、イベントコード「１０８」は、イベントテキスト「（＄Ｑ＄の平均速度で）列をなしている交通」と関連付けられ得、＄Ｑ＄は、数量詞が提供される場合は、数量詞で置換される。提供されない場合は、括弧内のテキストは、対応するテキストメッセージを表示する際に除去される。
【００８３】
さらなる属性ｐｈｏｎｅｍｅＩｄは、音素識別子を備え、音素識別子は、関連付けられたイベントテキスト文字列の音素表現を含有する表のレコードを参照する。これは、話し言葉出力の品質を強化するために使用され得る。同様に、属性ｖｏｉｃｅＩｄは、声音識別子を備え、声音識別子は、事前録音された声音出力を備える表の中のエントリを参照する。事前録音された声音出力は、例えば、ｍｐ３ファイルであり得、ｍｐ３ファイルは、対応する交通メッセージを使用者に提供するために、ｍｐ３復号器によって再生され得る。これらの属性は、随意であり、いくつかのレコードに対しては空（ｖｏｉｄ）であり得ることが明確であろう。
【００８４】
関係１１２は、ＴＭＣ補足情報リストを備える。関係１１２は、ＴＭＣメッセージと共に受信される場合の補足情報コードを、対応する情報を有するテキスト文字列を備えるテキスト属性と関連付ける。この場合もまた、テキストは、異なる複数の言語に対して提供され得、これによって、言語コードは、補足情報コードと一緒に主キーとして使用される。関係１１１に関して上述されたように、関係１１２は、さらに、音素識別子（ｐｈｏｎｅｍｅＩｄ）および声音識別子（ｖｏｉｃｅＩｄ）のための属性を備え得る。
【００８５】
関係１１３は、ＴＭＣイベントのバージョン番号を保持する。本実施形態において、すべてのイベントコードが同一のバージョンである。一般的に、ＴＭＣイベントコードの複数のバージョンを保持することは必要とされない。
【００８６】
図３は、位置コードを位置情報と直接的または間接的に関連付ける関係を備える、第１の組の関係１０２を示す。組１０２は、位置コードを位置情報と直接的および間接的に関連付ける関係１２０を備える。位置リスト関係１２０の各レコードは、属性ｃｃ（国コード）、ｅｃｃ（拡張された国コード）、ｌｔｎ（位置表番号）、およびｌｏｃＣｏｄｅ（位置コード）によって一意に識別され得る。したがって、これらの属性は、特定のレコードを関係１２０から検索するために、サーチ照会として使用され得る。関連付けられた関係において、レコードの識別を容易にするために、かつ、レコードへのアクセスをさらに加速するために、各レコードに対する一意の位置識別子を備えるｌｏｃＩｄ属性が提供される。この一意の識別子は、サロゲート（ｓｕｒｒｏｇａｔｅ）キーに相当し、代用キーは、関係１２０において主キーとして使用される。
【００８７】
次いで、関係１２０は、たとえ、異なる国々が同一の位置コードを使用する場合でも、これら異なる国々に対する位置コードを備える。各国は、２つ以上の位置表を確保し得るので（対応するｌｔｎ値の範囲は、ＴＭＣ基準において規定される）、属性ｌｔｎは、位置を全世界ベースで一意に識別するために、ｌｏｃＣｏｄｅ、ｃｃおよびｅｃｃと一緒に使用され得る。各位置に対して、情報は、各レコードにおいて、位置分類（ｌｏｃＣａｔｅｇｏｒｙ）、位置類型（ｌｏｃＴｙｐｅ）、および位置副類型（ｌｏｃＳｕｂｔｙｐｅ）について提供される。ｌｏｃＣａｔｅｇｏｒｙ属性は、位置が、エリア、線状（区画とも呼ばれる）、または点位置であるかどうかを示す。ｌｏｃａｔｉｏｎＴｙｐｅは、例えば、ジャンクションまたは同様なものなどであり得る。副類型は、例えば自動車専用道路の出口の形態におけるジャンクションなど、位置類型をさらに指定する。これらの属性の値は、主キーｌｏｃＩｄ、または、４つの属性ｃｃ、ｅｃｃ、ｌｔｎ、およびｌｏｃＣｏｄｅのどちらかで関係１２０を照会する場合に検索され得る。データベース２０によって返される結果の一例は「Ｐ１．４］であり得、ここで、「Ｐ」は点位置を示し、「１」は類型「ジャンクション」を示し、「４」は自動車専用道路の出口を示す。
【００８８】
さらなる属性ｐｏｓＯｆｆｓｅｔＬｏｃＩｄおよびｎｅｇＯｆｆｓｅｔＬｏｃＩｄは、位置リスト関係１２０に従って、それぞれ、正方向または負方向における次の位置に対する一意の位置識別子を備える。これらの属性はまた、無（ｎｕｌｌ）または空（ｖｏｉｄ）であり得る。このようにして、先行または後続する位置が容易に識別され得る。
【００８９】
属性ｐａｒｅｎｔＡｒｅａＩｄおよびｐａｒｅｎｔＳｅｇｍｅｎｔＩｄは、階層内のより高位の位置のために、それぞれ、エリア位置および区画位置に対する一意の位置識別子を備える。このことは、自動車専用道路の出口などの点位置が位置する道路区画を識別するために有利であり得る。このことは、特に、位置の名称が位置を曖昧さ無く記述するのに十分ではない状況に対して有利であり、これによって、階層内のより高位のエリアまたは区画が必要とされる。一例は、「Ｂａｈｎｈｏｆｓｔｒａｓｓｅ」、「ｉｎ Ｎｅｕｍａｒｋｔ」、および「ｉｎ ｄｅｒ Ｏｂｅｒｐｆａｌｚ」であり、異なる階層の３つの名称のみで位置を曖昧さ無く記述する。
【００９０】
ｆｉｒｓｔＮａｍｅＩｄ属性は、位置名称識別子を備え、位置名称識別子は、ＴＭＣ名称関係１２１中のレコードを参照し、しかるに、外部キーに相当する。このことは、関係１２０と関係１２１との間の矢印によって示される。したがって、これらの関係は、位置コードと位置名称との間の間接的な関連付けを提供する。関係１２１は、すべての位置名称をテキスト文字列の形態において保持する。この場合もまた、同一の位置名称識別子（属性「ｉｄ」）に対して複数のレコードが存在するように、名称が異なる複数の言語で提供される。したがって、属性「ｉｄ」および「ｌａｎｇｕａｇｅＣｏｄｅ」は、主キーとして使用される。属性「ｎａｍｅ」は、それぞれの言語における位置名称のテキスト文字列を備える。関係１１１を参照して上述されたように、関係１２１は、音素識別子属性および声音識別子属性を備え、音素識別子属性および声音識別子属性は、それぞれ、位置名称の音素表現、または、位置名称に対する事前録音された声音データを備える、対応するレコードを参照する。いくつかの名称は、追加情報なしでは、テキストから話し言葉へのエンジンによって正しく発音されることができないので（例えば英国レスター（Ｌｅｉｃｅｓｔｅｒ））、そのような音素情報は、位置名称に対して特に有用である。
【００９１】
すべてのテキスト文字列を別個の関係１１１または１２１中に提供することによって、テキスト文字列が容易に更新され得、新たな言語が追加され得る。対応する関係は、単に、対応する言語におけるイベントテキストまたは位置名称を備える追加のレコードで展開される必要がある。次いで、処理ユニットによって識別された言語コードが、対応する言語におけるテキストを検索するために使用され得る。さらには、残りの関係は、完全に言語独立に維持され得、残りの関係の構造を単純化し、残りの構造に含まれるレコードへのアクセスを加速する。
【００９２】
エリア、区画、または点位置に特有の情報に対して、それぞれ、３つの別個の関係１２３、１２４、および１２５が提供される。この場合もまた、これらの関係に含まれる位置情報は、一意の位置識別子（ｌｏｃＩｄ）によって位置コードと関連付けられる。ｌｏｃＩｄ属性は、これら３つの関係に対する主キーとして使用される。このことは、例えば、点位置のレコードにおける区画位置に特有の属性に対してなど、空のデータフィールドが回避されるので、データベースをよりコンパクトに表し、記憶空間を節約する。
【００９３】
エリア位置関係１２３は、ｌｏｃＩｄを、エリアが放送サービスエリアであるかどうかを示す属性と関連付ける。この情報は、例えば、米国に対して利用可能であり、また、この情報は、ＴＭＣクライアントデバイス１０のチューナの局選択方略のために有用であり得る。属性略号は、例えば、カリフォルニアに対する「ＣＡ」など、エリアに対応する州の略号を識別する。これは、ＴＭＣクライアントデバイスのディスプレイ上の交通メッセージのテキスト的表現の一部であり得る。
【００９４】
区画位置関係１２４は、区画位置のｌｏｃＩｄを位置名称識別子（ｓｅｃｏｎｄＮａｍｅＩｄ）と関連付け、位置名称識別子（ｓｅｃｏｎｄＮａｍｅＩｄ）は、（言語コードと一緒に）位置名称関係１２１中のレコードを参照する。ｆｉｒｓｔＮａｍｅＩｄ（関係１２０）およびｓｅｃｏｎｄＮａｍｅＩｄは、例えば、「シュトゥットガルト」と「ミュンヘン」との間のＡ８など、道路区画の開始点および終了点を指す。属性ｒｏａｄＮａｍｅＩｄは、道路名称を検索するための識別子を備える。道路名称は、一般的に、「Ｂａｈｎｈｏｆｓｓｔｒａｓｓｅ」などのテキスト文字列として規定される。
【００９５】
本実施形態において、「Ａ８」などの道路番号は、３つの部、すなわち、プレフィクス文字列（ｒｏａｄＮｕｍｂｅｒＰｒｅｆｉｘＩｄ属性）、整数道路番号（ｒｏａｄＮｕｍｂｅｒ属性）、およびサフィクス文字列（ｒｏａｄＮｕｍｂｅｒＳｕｆｆｉｘ属性）に分割される。例として、番号「Ｂ６２Ｎ」を有する道路は、「Ｂ」＋「６２」＋「Ｎ」に分割される。このことは、特に、ナビゲーションアプリケーションと組合せて使用される場合に有利である。交通情報メッセージを表示する交通情報リストは、整数道路番号によって容易に数値的に格納され得る。さらには、道路番号の図形的表現において、ドイツの「Ｂｕｎｄｅｓｓｔｒａｓｓｅ」に対して黒い縁（ｂｏａｒｄｅｒ）を有する黄色い標識など、プレフィクスは、整数道路番号が表されるビットマップによって置き換えられ得る。このようにして、プレフィクス情報は、ビットマップの形態において提示される。属性ｒｏａｄＮｕｍｂｅｒＳｔｒｉｎｇは、道路番号が、プレフィクス＋整数道路番号＋サフィクスのパターンに当てはまらない場合に対して、フォールバックとして使用される。
【００９６】
関係１２４において、プレフィクスは、関係１２７中のレコードを参照する属性ｒｏａｄＮｕｍｂｅｒＰｒｅｆｉｘＩｄによって間接的に提供される。この関係は、各プレフィクス識別子を優先度および実際のプレフィクスと関連付ける。これは、各国に対して行われ得る。ドイツに対する例としては、道路番号プレフィクス「Ａ」（Ａｕｔｏｂａｈｎ）は、最も高い優先度と関連付けられ得、プレフィクス「Ｂ」（Ｂｕｎｄｅｓｓｔｒａｓｓｅ）は、次のより低い優先度と関連付けられ得るなどである。したがって、第１の評価基準としてのプレフィクス優先度、および第２の評価基準としての道路番号によって、クライアントデバイスのディスプレイ１５上の交通情報メッセージリストをソートすることが可能である。このようなソートされたリストの例は、Ａ１，Ａ１０，Ｂ２，Ｂ１１であり得、それぞれの交通情報が道路番号の後に表示される。
【００９７】
同様な手法において、点位置関係１２５は、一意の位置識別子をｊｕｎｃｔｉｏｎＮｕｍｂｅｒ属性およびｊｕｎｃｔｉｏｎＮｕｍｂｅｒＳｕｆｆｉｘ属性と関連付け、これら属性によって、ジャンクション名称は、整数番号と文字列とに分割される。これによって、番号によるジャンクションのソートと、より直観的な図形的表現におけるジャンクションの表示とが可能になる。点位置間の距離は、一般的に、それらの座標を使用して計算される。関係１２５は、さらに、ｄｉｓｔａｎｃｅＴｏＰｏｓＯｆｆｓｅｔＬｏｃ属性およびｄｉｓｔａｎｃｅＴｏＮｅｇＯｆｆｓｅｔＬｏｃ属性を備え、これら属性は、正方向または負方向における隣接する点位置までの道路距離を供する。この道路距離は、２点間の飛行距離よりも写実的であり、しかるに、交通メッセージによって起動され得るナビゲーションアプリケーションにおける経路コストの計算を改善する。属性「ｉｓＵｒｂａｎ」は、位置が都市部エリアの内外のいずれであるかを規定する。この情報は、位置が都市部エリアである場合、街路名称に加えてそれぞれの都市名を表示するために使用され得る。ｎｂｒＰｏｓＤｉｒ属性およびｎｂｒＮｅｇＤｉｒ属性は、それぞれ、正方向および負方向において、自動車専用道路または同様に建設された道路に沿った、事前割当てされた迂回番号を備える。一般的に、位置および方向毎に１つの迂回番号が提供され、対応する方向における自動車専用道路の次の入口まで道を案内する。
【００９８】
関係１２８は、点位置に関係している経路選択リンクを備える。関係は、点位置の一意の位置識別子およびシーケンス番号（ｓｅｑＮｕｍｂｅｒ）によって照会され得、シーケンス番号（ｓｅｑＮｕｍｂｅｒ）によって、正方向におけるリンクは、１で始まる正の番号で番号付けされ、負方向におけるリンクは、負の番号で番号付けされる。シーケンス番号−１を有する入口は、位置コードに最も近い。属性ｔｉｌｅＩｄは、対応するリンクを含有する経路選択タイルのタイル番号を備える。ｌｉｎｋＩｄ属性は、タイル内のリンクのシーケンス番号を供する。
【００９９】
関係１２９は、点位置に対する、一意の位置識別子（ｌｏｃＩｄｓ）の対を備える。関係は、ｌｏｃＩｄＲｏａｄＯｎｅおよびｌｏｃＩｄＲｏａｄＴｗｏによって識別される２つの点位置が同一の物理的道路上に位置していることを示す。これは、２つの異なる組の点位置によって表される２つの別個の自動車専用道路が、同一の物理的道路上で、ある距離の間続いている場合に生じ得る。ナビゲーションアプリケーションにおいて、この情報は、異なる位置を備える２つのＴＭＣメッセージが実際に同一の道路の一続きを指しているかどうかを見出すことを助け得る。２つのこのようなメッセージが識別される場合、ナビゲーションシステムは、冗長な情報を表示することを回避するために、それらのうちの１つを抑制し得る。この種の冗長な交通情報のフィルタリングは、特に、２つ以上の交通情報ソース（例えば２つ以上のラジオ局）が一度に受信される場合に有用である。
【０１００】
地図中の交通情報の表示を容易にするために、または、（例えば、ディスプレイ上に提供される交通情報リストにおいて、交通メッセージを距離でソートするためになど）放送位置と現在の自動車の場所との間の距離の計算を容易にするために、関係型データベースは、位置座標関係１２６を備える。すべての類型の位置に対して、関係１２６は、ｌｏｃＩｄを２つの座標（属性ｘおよびｙ）と関連付ける。従来のシステムにおいては、点位置のみに座標が提供される。関係１２６は、例えば、ＷＧＳ８４形式においてなど、他の類型の位置に対してもまた、これらの座標を提供する。属性「ｃａｔｅｇｏｒｙ」は、ａｒｅａ、ｌｉｎｅ、ｐｏｉｎｔ＿ｃｅｎｔｅｒ、ｐｏｉｎｔ＿ｐｏｓｉｔｉｖｅｓ＿ｓｔａｒｔ、…など、座標類型を識別する。エリアに対しては、外形は、エリア位置の副次的に順序付けされた（ｓｕｂｏｒｄｅｒｅｄ）点の場所から形成される。１つのエリア位置のすべての点は、同一のｌｏｃＩｄと、１つの連続するシーケンス番号（ｓｅｑＮｕｍｂｅｒ）とを有する。このようにして、属性ｓｅｑＮｕｍｂｅｒは、外形が定められた点のインデックスを識別する。これは、区画位置に対して同様である。点位置に対しては、位置の中心を近似する中心座標、または、「ｃａｔｅｇｏｒｙ」属性によって識別されるさらなる座標が供され得る。
【０１０１】
テキスト的表現を完成するために、属性として位置名称識別子（ｎａｍｅＩｄ）を備える位置類型関係１２２が提供され、位置名称識別子（ｎａｍｅＩｄ）は、ある類型の位置のテキスト表現を供する位置名称関係１２１中のレコードを参照する。この場合もまた、ｎａｍｅＩｄおよび言語コードの両方が関係１２１を照会するために主キーとして使用されるので、位置類型関係１２２は言語特化である。関係１２２において、主キーは、位置リスト関係１２０から検索されるｌｏｃＣａｔｅｇｏｒｙ属性、ｌｏｃＴｙｐｅ属性、およびｌｏｃＳｕｂｔｙｐｅ属性のみならず、国および位置表を識別する属性ｃｃ、ｅｃｃ、およびｌｔｎを含む。このようなデータベースの構造化は、位置コード毎に位置類型に対するテキスト文字列が提供される必要はないので、記憶空間を節約する。同一の類型の位置を識別する点コードに対しては、言語毎に、かつ、適用可能な場合は国毎に（特定の類型のＴＭＣ位置は、同一の言語を有する異なる国々において、異なるように呼ばれ得る）、唯一のレコードが関係１２１中に提供される必要がある。この結果として、関係１２０および１２２は、コンパクトに維持され得る。
【０１０２】
例として、ＮａｍｅＩｄによって参照される、自動車専用道路の出口に対するテキスト表現は、ドイツ語で「Ａｎｓｃｈｌｕｓｓｓｔｅｌｌｅ」であり得、または、より短いテキストが所望される場合は「ＡＳ」であり得る。いくつかの位置類型のテキスト表現は、例えば、道路分類を割当てることに対するある種の自由度のレベルに起因してなど、
国毎に異なり得るので、テキスト表現は、国毎に提供される。したがって、ｃｃ、ｅｃｃ、およびｌｔｎが関係１２２の主キーにおいて使用される。ｃｃおよびｅｃｃが国を全世界の中で識別するために十分であっても、一部の放送者は、依然として、欧州内の国を識別するために前記の組合せｃｃ＋ｌｔｎを使用し得る。
【０１０３】
さらなる関係１３０は、異なるＴＭＣ位置のバージョン番号を保持する。１つの位置表のすべての位置は、好ましくは、同一のバージョンを有する。位置表は、３つの属性ｃｃ、ｅｃｃ、およびｌｔｎによって識別される。すべての位置表のすべてのエントリが、位置リスト関係１２０中に格納される。このようにして、関係１３０は、特定の位置表のバージョンを検索するために照会され得る。
【０１０４】
第１の組の関係１０１および第２の組の関係１０２の他に、関係型データベース２０は、さらなる関係を備え得る。例として、局リスト関係１０３が提供され、局リスト関係１０３は、送信者識別子（ｓｉｄ）および番組識別子（ｐｉ）を、送信者が受信され得るタイルのタイル番号（ｔｉｌｅＩｄ）と関連付ける。この場合もまた、この情報は国特化であり、関係１０３は、さらなる属性ｃｃ、ｅｃｃ、およびｌｔｎを備える。したがって、ＴＭＣクライアントデバイス１０のチューナは、特定の地理的エリアにおける走行時にチューニングすべき局に関して、関係１０３から有用な勧告を検索し得る。ｔｉｌｅＩｄによって識別される地理的エリアは、座標を使用して記述され、データベースの別の部分に格納され得る。
【０１０５】
図２および図３は、データベース２０の１つの可能な構成を図示するのみであり、他の実施形態においては、より多くの関係もしくはより少ない関係が提供され得るか、関係が結合されて１つの関係を形成し得るか、または、ある１つの関係の属性が他の関係にスワップアウトされ得ることが明確であろう。例として、関係１２０および１２２は、関係１２０内にＮａｍｅＩｄ属性を提供するように結合され得る。
【０１０６】
ここで図１に戻ると、検索ユニット２５は、イベントコードを備えるサーチ照会と、ＴＭＣメッセージと共に受信される位置コードとｃｃ、ｅｃｃ、およびｌｔｎ属性とを備えるサーチ照会とで、関係型データベース２０を照会するように構成され、それによって、それぞれ、関係１１０および１２０から情報を検索する。ＴＰＥＧクライアントデバイスとして実装される場合、サーチ照会は、ＴＰＥＧメッセージ中のＴＭＣ位置コンテナから読まれたＴＭＣ位置コードを備え得る。ｌｏｃＩｄなどの検索された情報に基づいて、他の関係から情報を検索するために、さらなる照会が関係型データベース２０に送信され得る。このようにして、指示された主キーを使用して、図２および図３に示された関係中に含まれるすべての情報が検索され得る。
【０１０７】
次いで、検索された情報は、検索ユニット２５によってテキストメッセージまたは声音メッセージへコンパイルされ、これらメッセージは、例えば、ディスプレイ１５または拡声器によってなど、使用者に発せられる。
【０１０８】
関係型データベース２０が処理ユニット１３上で走行するＴＭＣクライアントソフトウェアから分離される場合、データベース２０は、容易に更新および展開され得る。この目的のために、更新ユニット２６が提供され、更新ユニット２６は、処理ユニット１３によって実装される機能ユニットである。更新ユニット２６は、関係型データベース２０を更新するためにどのデータが検索され得るかということによって、更新インタフェース１４とインタフェース接続する。更新インタフェース１４は、例えば、ＵＳＢインタフェース、ｆｉｒｅ−ｗｉｒｅインタフェース、イーサネット（登録商標）インタフェース、または同様なものなど、有線インタフェースとして実装され得るか、あるいは、更新インタフェース１４は、例えば、無線ローカルエリアネットワークインタフェース、Ｂｌｕｅｔｏｏｔｈ（登録商標）インタフェース、モバイル通信インタフェース、または同様なものなど、無線インタフェースとして実装され得る。
【０１０９】
インタフェース１４上で受信された更新情報で、更新ユニット２６は、関係型データベース２０のレコード、関係、または組全体の関係を追加もしくは更新し得る。勿論、更新はまた、データベース２０からのレコードまたは関係の除去を含み得る。例として、更新ユニット２６は、新たな言語に対するイベントテキストおよび位置名称を、それぞれ、関係１１１および１２１に追加するように構成され得る。
【０１１０】
交通情報クライアントデバイス１０は、例えば、車両ナビゲーションデバイスとして、パーソナルナビゲーションデバイス（ＰＮＤ）として、パーソナルデジタルアシスタント（ＰＤＡ）として、携帯電話、スマートフォン、および同等物などのモバイル通信デバイスとして、または、ＴＭＣおよび／もしくはＴＰＥＧメッセージを受信および処理することから便益を受ける任意の他のデバイスとして実装され得る。これらのデバイスは、一般的に、使用者に対して地図情報を表示することが可能であるので、車両ナビゲーションデバイスまたはＰＮＤとしての実装が特に有利であり、このような実装において、受信されたＴＭＣ／ＴＰＥＧメッセージから取得される交通イベントの位置がマークされ得、対応するテキストメッセージが使用者に発せられ得る。このように、交通情報クライアントデバイス１０は、デバイス１０の具体的な実装に対して一般的である、さらなるコンポーネントを備え得る。例として、ナビゲーション的機能性を有するデバイスとして実装される場合、デバイス１０は、ＧＰＳ受信器と、使用者に対して表示されるべき地図を組み立てるための地図ユニットと、開始点から目的地までの経路を決定するための経路選択ユニットとを備え得る。
【０１１１】
これに対応して、メモリ１２は、地図データベースおよび経路選択データベースをさらに備え得、これらデータベースは、別個に提供され得るか、またはデータベース２０の部分として提供され得る。地図ユニットは、例えば、道路区間をマークすることによってなど、受信されたＴＭＣ／ＴＰＥＧメッセージによって示される交通イベントを表示し得、交通イベントは、受信された位置コードによって識別され得る。マーク付けの類型は、さらに、交通イベントの深刻度を示し得、このために、地図ユニットは、関係１１０の「ｊａｍＣａｔｅｇｏｒｙ」属性を利用し得る。同様に、経路選択ユニットは、関係１１０の「ｊａｍＣａｔｅｇｏｒｙ」属性、または関係１２５の「正のオフセット位置までの距離」に従って決定される経路区画に対するコストを考慮し得る。このようにして、関係型データベース２０によって、経路選択の精度および性能が改善され得る。
【０１１２】
例えば、モバイル通信デバイスとしてなど、他の実施形態において、交通情報クライアントデバイス１０は、モバイル電話ネットワークの通信のために適応されたモバイル送受信機と、そのようなデバイスに共通したさらなるコンポーネントとを備え得る。モバイル通信デバイスもまた、ナビゲーション的機能性を備え得、そして、それゆえ、上述された特徴はまた、このようなデバイスにも含まれ得ることが明確であろう。
【０１１３】
図４は、ＴＭＣクライアントデバイスとして実装された場合の、交通情報クライアントデバイス１０上で実行され得る方法のフロー図を示す。最初のステップ４０１において、ＴＭＣメッセージが受信ユニット１１によって受信される。ステップ４０２において、ｅｖｅｎｔＣｏｄｅと、利用可能であるならば数量詞とが、受信されたＴＭＣメッセージから読まれる。数量詞は、例えば、交通渋滞における平均速度を示す。次のステップ４０３において、言語コードがＴＭＣクライアントデバイス１０の現在の言語設定から決定される。
【０１１４】
ステップ４０４において、関係１１０（図２）の属性に対する値を検索するためのサーチ照会として、関係型データベース２０がｅｖｅｎｔＣｏｄｅで照会される。この場合もまた、データベース２０は、ＴＭＣイベント名称関係１１１からイベントテキストとｐｈｏｎｅｍｅＩｄもしくはｖｏｉｃｅＩｄとを検索するために、サーチ照会としてイベントコード、数量詞、およびｌａｎｇｕａｇｅＣｏｄｅを使用して照会される（ステップ４０５）。
【０１１５】
ここで、クライアントデバイスは、「４キロメートルにわたる重度の交通」など、交通イベントのテキスト的表現を提供するために利用可能な情報を有する。交通イベントの位置を決定するために、位置コード、オフセット、および方向が、受信されたＴＭＣメッセージから読まれる（ステップ４０６）。由来する国を識別するために、さらに、国コード（ｃｃ）、拡張された国コード（ｅｃｃ）、および位置表番号（ｌｔｎ）がメッセージから読まれる。
【０１１６】
サーチ照会として位置コード、ｃｃ、ｅｃｃ、および／またはｌｔｎを使用して、関係１２０において提供される情報、とりわけ、一意の位置識別子（ｌｏｃＩｄ）およびｆｉｒｓｔＮａｍｅＩｄを検索するために、関係型データベース２０が照会される（ステップ４０７）。例として、位置コードは、点位置を参照する。サーチ照会としてｆｉｒｓｔＮａｍｅＩｄおよびｌａｎｇｕａｇｅＣｏｄｅを使用して、位置名称、ｐｈｏｎｅｍｅＩｄおよび／またはｖｏｉｃｅＩｄが関係１２１から検索され得る（ステップ４０８）。点位置の名称は、例えば、「Ｓｕｌｚｅｍｏｏｓ」であり得る。ここで、ＴＭＣメッセージから検索される方向におけるオフセット値は、位置１２０の「ｐｏｓＯｆｆｓｅｔＬｏｃＩｄ」属性によって、近隣の位置のｌｏｃａｔｉｏｎＩｄを検索することによって、交通イベントの終了を識別するために使用され得る（ステップ４０９）。終了位置のｌｏｃａｔｉｏｎＩｄと、この場合もまた、ｌａｎｇｕａｇｅＣｏｄｅとを使用して、例えば「Ｏｄｅｌｚｈａｕｓｅｎ」など、対応する位置名称が関係１２１から検索され得る。両方の点位置に対して関係１２０から検索されるさらなる属性によって、対応するＮａｍｅＩｄは、関係１２２から取得され得、そして、例えば、言語ＤＥに対する「Ａｕｔｏｂａｈｎａｎｂｉｎｄｕｎｇ」など、関係１２１から位置類型名称を検索するために使用され得る。ここで、ＴＭＣクライアントデバイスは、フリーウェイアクセス「Ｓｕｌｚｅｍｏｏｓ」とフリーウェイアクセス「Ｏｄｅｌｚｈａｕｓｅｎ」との間で４キロメートルの重度の交通があるとの、利用可能な情報を有する。
【０１１７】
関係１２０のｐａｒｅｎｔＳｅｇｍｅｎｔＩｄによって、点位置のｐａｒｅｎｔＳｅｇｍｅｎｔのｌｏｃＩｄがさらに知られる。これは、関係１２０からｐａｒｅｎｔＳｅｇｍｅｎｔのｆｉｒｓｔＮａｍｅＩｄを検索するために、次のステップ４１０において使用される。関係１２１は、ｓｅｃｏｎｄＮａｍｅＩｄと、さらなる属性、とりわけ、ｒｏａｄＮａｍｅまたはｒｏａｄＮｕｍｂｅｒとを検索するために、親区画のｌｏｃＩｄでさらに照会される（ステップ４１１）。この場合もまた、ｆｉｒｓｔＮａｍｅ識別子およびｓｅｃｏｎｄＮａｍｅ識別子ならびにｌａｎｇｕａｇｅＣｏｄｅは、テキスト文字列としての対応する位置名称および／またはｐｈｏｎｅｍｅＩｄもしくはｖｏｉｃｅＩｄを関係１２１から検索するために使用される（ステップ４１２）。例として、第１の位置名称が「ミュンヘン」で、第２の位置名称が「シュトゥットガルト」であり得、これらは、ｒｏａｄＮａｍｅ「Ａ８」を有する区画を終端させる。ここで、クライアントデバイスは、交通イベントがミュンヘンとシュトゥットガルトとの間のＡ８上に位置しているとの、利用可能な情報を有する。
【０１１８】
これは、処理ユニット１３がイベントおよび位置情報を関係型データベース２０からどのように検索し得るかということのただの一例であることが明確であろう。処理ユニット１３は、示された主キー、または、関係中のレコードを一意に識別する他の属性によって、図２および図３に示された関係において提供される任意の情報を関係型データベースから検索し得る。
【０１１９】
次のステップ４１３において、テキストメッセージまたは声音メッセージが、検索されたイベントおよび位置情報から組立てられる。本例において、このようなテキストメッセージは、言語設定ドイツ語（ＤＥ）に対して、「Ａ８ Ｍｕｅｎｃｈｅｎ − Ｓｔｕｔｔｇａｒｔ： ｖｏｎ ＡＳ Ｓｕｌｚｅｍｏｏｓ ｂｉｓ ＡＳ Ｏｄｅｌｚｈａｕｓｅｎ： ｄｉｃｈｔｅｒ Ｖｅｒｋｅｈｒ ａｕｆ ４ ｋｍ」であり得る。上述されたように、声音メッセージは、対応する音素表現または事前録音された声音出力を利用することによって、追加的または代替的に組立てられ得る。
【０１２０】
最後のステップ４１４において、テキストメッセージまたは声音メッセージは、ＴＭＣクライアントデバイスの使用者に発せられる。
【０１２１】
図４および図５に関して説明された方法は、ＴＰＥＧメッセージを受信し、かつＴＭＣ位置参照を使用するＴＰＥＧクライアントデバイスとして実装される場合、必要な変更を伴って、交通情報クライアントデバイス１０上で同様に実行され得る。この場合において、ステップ４０２、４０４、４０５は実行される必要がない。代わりに、ステップ４０１で受信されたＴＰＥＧメッセージから読まれたＴＰＥＧイベントコードが、その後、ＴＰＥＧクライアントソフトウェアを使用してイベントテキストへ変換され得る。ステップ４０６において、ｃｃ、ｅｃｃ（適用可能な場合）、およびｌｔｎのみならず、ＴＭＣ位置コードが、受信されたＴＰＥＧメッセージのＴＭＣ位置コンテナから読まれ得る。
【０１２２】
図６は、交通情報クライアントデバイス１０上の関係型データベース２０の更新を図示する。最初のステップ６０１において、関係型データベースの新たなレコードもしくは更新されたレコードまたは関係、あるいは、関係型データベース中に含まれるべき新たな関係を備える、更新情報は、例えば、更新インタフェース１４上で受信される。交通情報クライアントデバイス上の関係型データベースは、既存のレコード／関係を更新することによって、または、受信された更新情報に含まれる新たなレコード／関係で関係型データベースを展開することによって、ステップ６０２において更新される。関係型データベース２０は、交通情報クライアントデバイスとは別個に提供されるので、このような更新は、クライアントソフトウェアを改変することなく可能である。このことは、新たな類型の情報または新たな言語が容易に追加され得、かつ既存のレコードが容易に修正され得るので、ＴＭＣもしくはＴＰＥＧメッセージ符号化の融通性を多大に増大する。さらに、道路網建設に起因した、新たな／変更された位置は、クライアントデータベースを更新することによって交通情報クライアントデバイスに提供され得る。
【０１２３】
最後のステップ６０３において、交通情報クライアントデバイスは、更新された関係型データベースを有して動作する。
【０１２４】
上記から理解され得るように、クライアントソフトウェアとは別個に、交通情報クライアントデバイスの関係型データベース中に位置情報と、場合によってはイベント情報とを格納することによって、クライアントソフトウェアから独立して、とりわけ、クライアントソフトウェアを再インストールする必要なく、データベースの内容を修正することが可能になる。位置情報およびイベント情報を関係のある形態において格納することは、データベース内容の更新、とりわけ、さらなるレコードによる関係の展開、単体のレコードの修正、さらなる関係の追加、および同様なものを容易にする。このようにして、ＴＭＣ位置情報およびＴＭＣイベント情報は、データベース更新によって現在の状態まで引き上げられ得る。さらには、情報をいくつかの関係間に分布させることによって、必要とされる記憶空間が低減され、レコードにアクセスする際の性能が改善される。このことはまた、クライアントデバイスのメインメモリへのデータベースの部分の選択的ローディングを可能にし、それによって、必要とされるメインメモリの量（メモリフットプリント）を低減する。関係型データベースは、さらに、クライアントデバイス上の地図上での交通情報の表示と、クライアントデバイス上で表示されるべき交通イベントに対するテキストメッセージの生成と、使用者に対して再生されるべき交通イベントに対する声音出力の生成と、動的経路計算のための、交通イベントと関連付けられるコストの決定とを容易にする。
【符号の説明】
【０１２５】
１０ 交通情報クライアントデバイス
１１ 受信ユニット
１２ メモリ
１３ 処理ユニット
１４ 更新インタフェース
１５ ディスプレイ
２０ 関係型データベース
２５ 検索ユニット
２６ 更新ユニット
１０１ 第２の組の関係
１０２ 第１の組の関係
１０３ 局リスト関係
１１０ イベント関係
１１１ イベント名称関係
１２０ 位置リスト関係
１２１ 位置名称関係
１２２ 位置類型関係
１２３ エリア位置関係
１２４ 区画位置関係
１２５ 点位置関係
１２６ 位置座標関係
【技術分野】
【０００１】
（技術分野）
本発明は、ＴＭＣまたはＴＰＥＧクライアントデバイスなどの交通情報クライアントとして動作するように構成された電子デバイスに関し、さらには、本発明は、そのようなデバイスを動作させる方法に関する。
【背景技術】
【０００２】
（背景）
車両を運転する場合のナビゲーション、とりわけ、配向は、ナビゲーションデバイスの使用によって容易にされ、ナビゲーションデバイスは、一般的に、現在場所を決定するためにグローバルポジショニングシステム（ＧＰＳ）を使用する。経路選択情報と一緒に、現在場所の指示が可視的出力または音声出力によって使用者に提供される。ナビゲーションデバイスは、通常、使用者または運転者によって入力される目的地への経路が計算され得る基準となる地図データを備える。従来のナビゲーションデバイス上に格納された地図情報は静的であるのみであり、これによって、事故または道路工事に起因してなど、特定の道路が通行不能になるか、または封鎖される場合、この地図情報は、経路決定において考慮されない。
【０００３】
この欠点は、どの現在の交通および走行情報（ＴＴＩ）がナビゲーションデバイスおよび運転者に送達され得るかということによる交通メッセージチャネル（ＴＭＣ）を導入することによって克服された。ＴＭＣ上の情報は、一般的に、従来のＦＭラジオ放送によってデジタル的に符号化され、伝送される。さらに、交通メッセージを伝送する、新たな／追加の標準的方法としてのＴＰＥＧプロトコルは、道路状態についての動的な情報をクライアントデバイスに搬送するために使用され得る。ＴＭＣまたはＴＰＥＧメッセージは、イベントコード（ＥＣ）および位置記述を備え、位置記述は、ＴＭＣの場合においては位置コード（ＬＣ）である（ＴＰＥＧの場合においては位置コード（ＬＣ）であり得る）。ＴＭＣまたはＴＰＥＧメッセージは、時間制限（または効果持続期間）、メッセージが関係する国についての情報、および同様なものなど、さらなる情報を備え得る。イベントコードおよび位置コードは、クライアントデバイスにおいて、道路網上の特定の交通イベントおよび位置へなど、使用者に発せられ得る情報へ翻訳されなければならない。この目的のために、クライアントデバイスを動作させる（ＴＭＣおよび／またはＴＰＥＧプロトコルを使用する）交通情報ソフトウェアは、イベントコード表および位置コード表を備える（ＴＭＣ位置が、ＴＰＥＧの場合における選定された参照方法である場合）。
【０００４】
イベントコード表および位置コード表は、従来のデバイスにおいて、ソフトウェアの一部であるか、またはＴＭＣ／ＴＰＥＧクライアントのデータベース中に格納されるかのいずれかである。これら表は、ＴＭＣ／ＴＰＥＧクライアントデバイス上にバイナリラージオブジェクト（ＢＬＯｂ）として格納される。このような構成は、いくつかの不利点を有する。イベントコード表および位置コード表の更新は、困難であり、これら表がソフトウェア中に埋め込まれる場合には、ＴＭＣ／ＴＰＥＧクライアントソフトウェアの更新と一緒に発生しなければならず、つまり、クライアントデバイス上で動作しているソフトウェアが更新されるか、または再インストールされる必要がある。同様に、表の更新は、表がデータベース中にＢＬＯｂとして格納される場合には困難である。プレインストールされたＴＭＣ表は、概して、個々のＴＭＣ／ＴＰＥＧクライアントデバイスが販売される市場に対してのみ適切であり、そして、プレインストールされたＴＭＣ表は、その製造の時点までのみのＴＭＣイベントコードおよび位置コードを備える。更新の他に、例えば新たな使用者言語でなど、イベントコード表および位置コード表を展開することは困難である。
【０００５】
これらの制限に起因して、イベントコード表および位置コード表の機能性が制約される。さらに、これらの表に含まれる情報は、概して、交通メッセージ用の正しい話し言葉出力を再生成することに対して好適ではない。新たな類型の情報もまた、概して、既存の、そして標準化されたイベントコード表および位置コード表に追加され得ない。
【０００６】
バイナリラージオブジェクトの形態において表を格納することは、比較的大量の空間をさらに必要とする。表中の情報にアクセスする場合、オブジェクト全体がクライアントデバイスのメインメモリへロードされる必要があり、このことは、大量のメインメモリを必要とし、デバイスの性能を低減する。同様に、データを表から検索する場合に、アクセスが遅い。したがって、現存のＴＭＣ／ＴＰＥＧクライアントデバイスは、幾分非効率的に動作し、更新または新たな情報の追加に関して非常に融通性が利かない。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
（概要）
したがって、上述された欠点のうちの少なくともいくつかを取り除くことと、交通情報クライアントデバイスにおいて復号化する交通メッセージの多用性および融通性を改善することの必要性がある。
【課題を解決するための手段】
【０００８】
この必要性は、独立請求項の特徴によって満たされる。従属請求項において、本発明の好ましい実施形態が記載される。
【０００９】
本発明の第１の局面に従って、交通情報クライアントとして動作するように構成された電子デバイスが提供される。このクライアントデバイスは、交通情報メッセージを受信するように適応されたインタフェースを備え、交通情報メッセージは、交通イベントの位置を識別する位置コードと、メモリと、該メモリ内に格納された関係型データベースとを備える。関係型データベースは、少なくとも１つの関係を含む、少なくとも第１の組の関係を備え、少なくとも１つの関係は、位置コードを位置情報と直接的または間接的に関連付ける。電子デバイスは、処理ユニットをさらに備え、処理ユニットは、関連付けられた位置情報を関係型データベースから検索するために、交通情報メッセージと共に受信された位置コードで関係型データベースを照会するように適応される。
【００１０】
本発明の実施形態において、交通情報メッセージは、交通イベントを識別するイベントコードをさらに備え得、関係型データベースは、少なくとも１つの関係を含む第２の組の関係をさらに備え得、少なくとも１つの関係は、イベントコードをイベント情報と直接的または間接的に関連付ける。次いで、処理ユニットは、関連付けられたイベント情報を関係型データベースから検索するために、交通情報メッセージと共に受信されたイベントコードで関係型データベースを照会するように適応され得る。
【００１１】
エベントコードおよび／または位置コードを関係型データベース中に格納することによって、対応する情報が容易に更新され得、データベースが容易に拡張され得る。さらに、イベント情報および位置情報は、例えば、情報の類型に従ってなど、関係型データベースのいくつかの関係にわたって分布され得る。必然的に、該少なくとも１つの関係はまた、イベント／位置コードをイベント／位置情報と直接的および間接的に関連付け得る。このようにして、コンパクトなデータベースが達成され得る。データベースを照会する場合、要求された情報を備える関係のみがアクセスされる必要がある。このようにして、記憶空間を節約し、必要とされる作業用メモリの量を低減することが可能であり、データベースからの情報の検索がさらに加速される。処理ユニットのサーチ照会は、イベントコード、位置コード、または両方を含み得、勿論、処理ユニットのサーチ照会は、国コード（ｃｃ）、拡張された国コード（ｅｃｃ）、位置表番号（ｌｔｎ）、または同様なものなど、さらなる情報を含み得る。
【００１２】
実施形態において、位置コードはＴＭＣ位置コードであり、電子デバイスは、ＴＭＣクライアントまたはＴＰＥＧクライアントとして動作するように構成される。したがって、交通情報メッセージは、ＴＭＣメッセージまたはＴＰＥＧメッセージであり得る。
【００１３】
好ましくは、ＴＭＣクライアントデバイスとして実装される場合には、関係型データベースは、第１の組の関係および第２の組の関係の両方を備え得る一方、ＴＰＥＧクライアントデバイスとして実装される場合には、関係型データベースは、例えば、ＴＭＣ位置参照を可能にするためになど、第１の組の関係のみを備え得る。必然的に、ＴＰＥＧクライアントデバイスにもまた、両方の組の関係を備える関係型データベースが提供され得る。
【００１４】
本発明のさらなる実施形態に従って、第１の組の関係は、複数のレコードを有する第１の関係を備え、複数のレコードは、異なる国々に対する位置コードを有し、異なる国々に対するレコードは、同一の位置コードを備え得、第１の関係は、該第１の関係の各レコードを一意の位置識別子と関連付ける属性を備える。例として、この第１の関係（以下、位置リスト関係とも呼ばれる）の特定のレコードにアクセスするために、サーチ照会は、位置コードと、ｃｃ、ｌｔｎ、および（提供される場合は）ｅｃｃのうちの１つまたは組合せとを備え得る。そうして、アクセスされたレコードと関連付けられた一意の位置識別子（ｌｏｃＩｄ）が、検索され得、３つまたは４つの前述された属性の代わりに、他の関係中のレコードにアクセスするために使用され得る。次いで、さらなる位置情報へのアクセスが容易にされ、加速される。第１の関係の各レコードは、例えば、位置コード、国コード、拡張された国コード（利用可能な場合）、および位置表番号を、一意の位置識別子と関連付け得る。
【００１５】
上述された位置コードと位置情報との間の間接的な関連付けは、以下の方法で提供され得る。第１の組の関係は、位置コードを、識別子、好ましくは一意の位置識別子および／または位置名称識別子と関連付ける、第１の関係を備え得、さらに、１つ以上の第２の関係を備え得、１つ以上の第２の関係は、それぞれ、特定の類型の位置情報に対するものであり、識別子を対応する位置情報と関連付ける。識別子はまた、「外部キー」とも称され得、別の関係中のレコードへの参照であり得る。したがって、位置情報を複数の関係に分割することが可能であり、それでも依然として、すべての情報は、位置コードによって直接的または間接的にアクセス可能である。勿論、第１の関係はまた、位置コードをさらなる位置情報と直接的に関連付け得る。第２の関係において、識別子は、主キーとして、または主キーの一部として使用され得る。識別子を第１の関係から検索した後に、識別子は、位置情報を第２の関係から検索するために、サーチ照会において使用され得る。
【００１６】
本発明の実施形態において、１つ以上の第２の関係は、エリア位置情報とのエリア位置関係、区画位置情報との区画位置関係、点位置情報との点位置関係、位置名称情報との位置名称関係、位置類型情報との位置類型関係、および座標情報との位置座標関係のうちの少なくとも１つを備える。この構成は、すべてのこれらの類型の情報が単一の関係中に提供される構成と比較して、例えば、区画位置およびエリア位置データフィールドが空であるような点位置に対応する位置コードに対してなど、関係中の空のデータフィールドが回避される利点を有する。情報を複数の関係にわたって分布させることによって、データにアクセスする際の性能がさらに改善され得、必要とされるデータベースの記憶空間が最小化される。
【００１７】
例として、第１の関係は、位置コードを位置分類識別子と関連付け得、位置分類識別子は、対応する位置がエリア位置、線状位置、または点位置であるかどうかを示す。次いで、処理ユニットは、関係型データベースを照会することによって、受信された位置コードの位置分類を識別するように適応され得、また、識別された位置分類に依存して、サーチ照会として、識別子、好ましくは一意の位置識別子を使用して、エリア位置関係、区画位置関係、または点位置関係のいずれかから、さらなる位置情報を検索するように適応され得る。位置コードを一意の位置識別子および位置分類識別子と関連付ける第１の関係によって、処理ユニットは、どの第２の関係および第２の関係のどのレコードをアクセスするかを即座に決定し得る。
【００１８】
第１の関係、区画位置関係、および／または位置類型関係は、各レコードを位置名称識別子と関連付ける属性を備え得、位置名称関係は、位置名称識別子を位置名称と関連付けるレコードを備える。位置名称識別子は、例えば、位置名称関係の主キー、または主キーの一部である。したがって、すべての位置名称を、例えば、人間が理解可能なテキスト文字列の形態においてなど、単一の関係中に格納することが可能である。すべての他の関係は、位置名称を検索するために、位置名称識別子に対する属性を備える必要があるのみである。このことは、１つのコンパクトな関係が更新される必要があるのみであるから、異なる位置に対して利用可能なテキスト表現の更新または拡張を容易にする。
【００１９】
第１の組の関係は、位置コードを、下記の属性のうちの少なくとも１つ以上の組合せと直接的または間接的に関連付ける、エリア位置関係を備え得、ここで、上記属性は、位置コードに対応するエリアがサービス放送エリアであるかどうかを示す属性、および、位置コードに対応するエリアが位置する州の略号を備える属性である。このような略号は、例えば、カリフォルニアに対する「ＣＡ」であり得る。
【００２０】
第１の組の関係は、さらに、位置コードを、下記の属性のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、区画位置関係を備え得、ここで、上記属性は、位置名称識別子、道路名称、位置コードに対応する区画の道路番号のプレフィクス文字列部を備える道路番号プレフィクス、位置コードに対応する区画の道路番号の整数部を備える道路番号属性、位置コードに対応する区画の道路番号のサフィクス文字列部を備える道路番号サフィクスである。
【００２１】
このようにして、道路番号（例えば、Ａ９、Ｂ２Ｒ、または同様なものなど）は、プレフィクス、番号、およびサフィクスの３部に分割され得、このことは、道路番号属性に従った交通メッセージの番号によるソーティング、または、該プレフィクスに対応する道路標識の図形表現上の整数の道路番号の図形的表現を可能にする。
【００２２】
第１の組の関係は、さらに、位置コードを、下記の属性のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、点コード関係を備え得、ここで、上記属性は、位置コードに対応する点位置のジャンクション名称の番号部を備えるジャンクション番号、位置コードに対応する点位置のジャンクション名称の文字列部を備えるジャンクション番号サフィクス、第１の方向（正の方向）における次の点位置までの道路距離、第２の方向（負の方向）における次の点位置までの道路距離、位置が都市部であるかどうかを示す情報、第１の方向の自動車専用道路に沿った既定の迂回路に対する迂回番号、および第２の方向の自動車専用道路に沿った既定の迂回路に対する迂回番号である。この場合もまた、ジャンクション名称を番号およびサフィクスに分割することによって、ジャンクション番号に従ったソーティングが可能になる。さらには、隣接する点位置までの距離情報を伴うことで、２つの点位置を接続する道路区間に沿った現実の距離が属性中に入力され得るので、２つの点位置間の距離が写実的にモデル化され得る。このことは、交通メッセージによって開始されるナビゲーションデバイスにおける経路コストの計算を改善し得る。
【００２３】
第１の組の関係は、さらに、位置コードを、座標、座標分類、およびシーケンス番号と直接的または間接的に関連付ける、位置座標関係を備え得る。座標は、例えば、ｘおよびｙ座標、または、ＷＧＳ ８４形式における経度および緯度座標であり得る。関係は、さらに、関係の各レコードを、主キーとして使用される一意の位置識別子およびインデックス番号と関連付ける属性を備え得る。位置の類型（エリア、線状、または点）に依存して、位置は、シーケンス番号によって指定され得る複数の点で記述され得る。位置の類型に依存して（点位置に対しては、記述されるべき具体的な座標に依存して）、いくつかの座標分類がある。すなわち、「ＡＲＥＡ」類型は、エリアの外形をポリゴンのいくつかの点で記述する、複数の座標に対して使用され得、「ＬＩＮＥ」類型は、（道路または道路の区画などの）線状位置の端点に対して使用され得、５つの類型「ＣＥＮＴＲＥ＿ＰＯＩＮＴ」、「ＰＯＳＩＴＩＶＥ＿ＳＴＡＲＴ」、「ＮＥＧＡＴＩＶＥ＿ＳＴＡＲＴ」、「ＰＯＳＩＴＩＶＥ＿ＥＮＤ」、「ＮＥＧＡＴＩＶＥ＿ＥＮＤ」は、点位置の中心を記述するために使用され得る（例えば、これは、大きな幹線道路交差点に対しては、交差点の地理的中心であり得る）。道路の一端または他端における幹線道路交差点の始まりを記述するために、開始座標が使用され得（したがって、ＴＭＣリンケージの正方向および負方向の各々に対して座標類型が提供され得る）、幹線道路交差点の終わりを記述するために、終了座標が使用され得る（この場合も、別個の座標類型を有する両方の道路方向）。
【００２４】
第１の組の関係は、さらに、道路番号プレフィクスを優先度と関連付ける道路プレフィクス関係を備え得る。このようにして、特定の類型の道路の優先度を識別することが可能になり、このことは、道路優先度に従ってメッセージリスト中のＴＭＣ／ＴＰＥＧメッセージをソートするために使用され得る。
【００２５】
第１の組の関係は、さらに、とりわけ点位置のために、位置コードを、少なくとも第１の一意の位置識別子および第２の一意の位置識別子と直接的または間接的に関連付ける、相互参照関係を備え得る。相互参照関係において、同一の物理的道路上に位置する、点位置の複数の対が格納され得る。したがって、同一の道路の一続きを指すＴＭＣ／ＴＰＥＧメッセージは、たとえ、それらメッセージが異なる点位置に対する位置コードを使用しても、識別され得、メッセージのうちの一方は、冗長な情報の表示を回避するために抑制され得る。
【００２６】
さらなる実施形態において、第２の組の関係は、イベントコードをイベントテキストと直接的または間接的に関連付ける、イベント名称関係を備え、該イベント名称関係は、２つ以上の異なる言語において、イベントテキストのためのレコードを備え、該関係は、さらに、各レコードにおいてイベントテキストが提供される言語を識別する属性を備える。好ましくは、イベント名称関係は、イベント名称をイベントテキストと直接的に関連付ける。イベント名称関係は、関係する交通イベントテキストがどの類型の数量詞と結合され得るかを示すための数量詞類型属性など、さらなる属性を備え得る。数えられる要素（例えば温度などの物理的値と対照的に）を記述する、ＴＭＣメッセージ中において伝送される数量詞は、単数（伝送される数量詞の値が１）または複数（値が１より大きい）であり得る。さらに、数量詞の値を含有せず送信されるＴＭＣメッセージがあり得る。３つの場合（単数／複数／数量詞なし）の各々に対して、イベントテキストは、クライアントデバイスのテキスト生成モジュールが、挿入された数量詞の値を有するＴＭＣメッセージの整形されたテキスト表現を生み出すことを可能にするために、異なる言い回しを必要とし得る。次いで、イベントコード、数量詞類型、および言語コードは、イベント名称関係のレコードにアクセスするための主キーとして使用され得る。
【００２７】
同様に、第１の組の関係は、位置コードを位置名称と直接的または間接的に関連付ける、位置名称関係を備え得、該位置名称関係は、２つ以上の異なる言語において、位置名称のためのレコードを備え、該関係は、さらに、言語コードを有する属性を備え、言語コードは、各レコードにおいて位置名称が提供される言語を識別する。位置コードに対して、関連付けは、好ましくは、間接的なものである。位置名称関係は、例えば、主キーとして、上述された一意の位置識別子および言語コードを使用し得る。位置名称は、テキスト文字列の形態において、位置名称関係中に格納され得る。
【００２８】
したがって、関係型データベースは、単に、言語コードを有する対応するレコードを、イベント名称関係および／または位置名称関係に追加することによって、さらなる言語で簡単に拡張され得る。さらには、残りの関係はすべて、言語独立であり得る。このようにして、新たな言語での更新は、これら２つの関係のみに制限され得、これは、時間効率的かつメモリ効率的である。
【００２９】
特定の言語においてテキストを検索するために、処理ユニットは、電子デバイスの現在の言語設定、または使用者選好の言語を決定するように適応され得、現在の言語または使用者選好の言語において、イベントテキストまたは位置名称を、それぞれ、イベント名称関係または位置名称関係から検索するために、サーチ照会において対応する言語コードを使用し得る。
【００３０】
さらなる実施形態において、イベント名称関係または位置名称関係は、それぞれ、対応するイベントテキストまたは位置名称の音素表現を検索するために、イベントテキストまたは位置名称を音素識別子と関連付け得る。これらの関係は、追加的または代替的に、対応するイベントテキストまたは位置名称の音響表現を検索するために、それぞれ、イベントテキストまたは位置名称を声音識別子と関連付け得る。このようにして、音素識別子および声音識別子は、関係型データベースにおいて提供されるさらなる関係から対応する音素表現または音響表現を検索するために、外部キーとして機能し得る。テキスト文字列に対して、音素表現、または、音声ファイルなどの音響表現までも提供することによって、対応するテキストの話し言葉出力は、有意に強化され得る。
【００３１】
第１の組の関係は、なおもさらに、イベントコードを下記の属性のうちの少なくとも１つまたは組合せと関連付けるイベント関係を備え得、ここで、上記属性は、イベントコードと関連付けられたアイコン組を識別するアイコン組識別子、イベントの性質を識別するイベント性質、対応する交通情報メッセージの持続期間の決定のための情報を備える持続期間類型、イベントが交通の一方向または両方向に関係するかどうかを示すデフォルト方向性、イベントの緊急度を示すイベント緊急度、交通イベントの深刻度を示す渋滞分類、クライアントデバイスにおける更新機構によって使用される更新等級、および、イベントと共に使用されることが許される数量詞類型についての指示である。アイコン組識別子は、アイコンについての情報を含有する別の関係への外部キーであり得、アイコンは、ＴＭＣクライアントデバイスのディスプレイ上で、交通イベントに対する指示として表示され得る。渋滞分類属性は、適用可能ならば機械可読な形態において、イベントテキストのテキスト的ステートメントを備え得、これによって、渋滞分類属性が、経路選択アプリケーションにおける走行コストの決定のために使用され得る。
【００３２】
関係型データベースは、さらに、受信されたＴＭＣメッセージに含まれる国識別子を、下記の属性のうちの少なくとも１つまたは組合せと関連付ける、局リスト関係を備え得、ここで、上記属性は、ＴＭＣメッセージを放送する送信者を示す送信者識別子、ラジオ番組を識別する番組識別子、送信者が受信可能である地理的エリアを記述するタイル識別子である。この場合もまた、国識別子は、ｃｃ、ｅｃｃ、およびｌｔｎのうちの１つまたは組合せであり得る。ＴＭＣメッセージを送信しているラジオ局が受信可能であるエリアは、異なるレベルのタイルによって識別され得る。したがって、局リスト関係によって、どのエリアがＴＭＣメッセージを放送しているどのラジオ局によって提供されているかが識別され得る。
【００３３】
本発明のさらなる局面に従って、交通情報クライアントとして動作するように構成された電子デバイスを動作させる方法が提供される。電子デバイスは、交通情報メッセージを受信するためのインタフェースと、位置コードを位置情報と直接的または間接的に関連付ける少なくとも第１の組の関係を備える関係型データベースとを備える。本方法は、交通イベントの位置を識別する位置コードを備える交通情報メッセージをインタフェース上で受信するステップと、サーチ照会として位置コードを使用して関係型データベースを照会するステップと、位置コードと関連付けられた位置情報を関係型データベースから検索するステップとを包含する。
【００３４】
本発明の方法で、交通情報クライアントデバイスに関して上記で概説された利点と同様の利点が達成され得る。
【００３５】
本発明の実施形態において、関係型データベースは、さらに、少なくとも１つの関係を含む第２の組の関係を備え、少なくとも１つの関係は、イベントコードをイベント情報と直接的または間接的に関連付け、受信された交通情報メッセージは、さらに、交通イベントを識別するイベントコードを備える。本方法は、さらに、サーチ照会としてイベントコードを使用して関係型データベースを照会するステップと、イベントコードと関連付けられたイベント情報を関係型データベースから検索するステップとを包含し得る。
【００３６】
本方法は、２つの別個のサーチ照会の使用を包含し得、１つはイベントコードに対して、１つは位置コードに対してである。必然的に、各サーチ照会は、関係型データベース中のレコードを一意に識別するために、ｃｃ、ｅｃｃ、またはｌｔｎなどのさらなる情報を備え得る。
【００３７】
本発明の方法の実施形態において、電子デバイス、とりわけ、関係型データベースは、交通情報クライアントデバイスの複数の異なる実施形態に関して上述されたように構成される。
【００３８】
本発明のさらなる局面に従って、電子的に可読なデータキャリアであって、その上に格納された関係型データベースを備えるデータキャリアが提供される。関係型データベースは、少なくとも１つの関係を含む第１の組の関係を備え、少なくとも１つの関係は、ＴＭＣ位置コードを位置情報と直接的または間接的に関連付ける。
【００３９】
実施形態において、関係型データベースは、さらに、少なくとも１つの関係を含む第２の組の関係を備え、少なくとも１つの関係は、イベントコードを、イベント情報、とりわけＴＭＣイベントコードと直接的または間接的に関連付ける。さらなる実施形態において、データキャリア上に格納された関係型データベースは、交通情報クライアントデバイスの複数の実施形態のうちのいずれかに関して上述されたように構成される。
【００４０】
上述された本発明の複数の局面および実施形態の特徴、ならびに、以下にさらに説明される同特徴は、示されるそれぞれの組合せにおいてのみならず、本発明の範囲を逸脱することなく、他の組合せにおいても、または単独でも使用され得る。
【００４１】
以上により、本発明は、例えば以下の項目を提供する。
【００４２】
（項目１）
交通情報クライアントデバイスとして動作するように構成されている電子デバイスであって、
交通情報メッセージを受信するように適応されているインタフェース（１１）であって、交通情報メッセージは、交通イベントの位置を識別する位置コードを備え得る、インタフェース（１１）と、
メモリ（１２）と、
該メモリに格納される関係型データベース（２０）であって、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、関係型データベース（２０）と、
処理ユニット（１３）であって、該関連付けられた位置情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信される位置コードで該関係型データベース（２０）を照会するように適応されている処理ユニット（１３）と
を備えている、電子デバイス。
【００４３】
（項目２）
交通情報メッセージは、交通イベントを識別するイベントコードをさらに備え得、上記関係型データベースは、少なくとも１つの関係（１１０、１１１）を含む第２の組の関係（１０１）をさらに備え、該少なくとも１つの関係（１１０、１１１）は、イベントコードをイベント情報と直接的または間接的に関連付け、
上記処理ユニットは、該関連付けられたイベント情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信されるイベントコードで該関係型データベース（２０）を照会するように適応されている、上記項目のうちのいずれかに記載の電子デバイス。
【００４４】
（項目３）
上記第１の組の関係は、複数のレコードを有する第１の関係（１２０）を備え、該複数のレコードは、異なる国々に対する位置コードを有し、異なる国々に対する該レコードは、同一の位置コードを備え得、該第１の関係は、該第１の関係の各レコードを一意の位置識別子と関連付ける属性を備える、上記項目のうちのいずれかに記載の電子デバイス。
【００４５】
（項目４）
上記第１の組の関係は、第１の関係（１２０）と、１つ以上の第２の関係（１２１、１２３、１２４、１２５）とを備え、該第１の関係（１２０）は、上記位置コードを、識別子、好ましくは、一意の位置識別子および／または位置名称識別子と関連付け、該１つ以上の第２の関係（１２１、１２３、１２４、１２５）は、それぞれ、特定の類型の位置情報に対して、該識別子を対応する該位置情報と関連付け、これによって、該第１の関係（１２０）は、該位置情報との間接的な関連付けを提供する、上記項目のうちのいずれかに記載の電子デバイス。
【００４６】
（項目５）
上記１つ以上の第２の関係（１２１、１２２、１２３、１２４、１２５、１２６）は、
エリア位置情報を有するエリア位置関係（１２３）と、
区画位置情報を有する区画位置関係（１２４）と、
点位置情報を有する点位置関係（１２５）と、
位置名称情報を有する位置名称関係（１２１）と、
位置類型情報を有する位置類型関係（１２２）と、
座標情報を有する位置座標関係（１２６）と
のうちの少なくとも１つの関係を備える、上記項目のうちのいずれかに記載の電子デバイス。
【００４７】
（項目６）
上記第１の関係（１２０）は、上記位置コードを位置分類識別子と関連付け、該位置分類識別子は、対応する位置がエリア位置、線状位置、または点位置であるかどうかを示し、
上記処理ユニット（１３）は、上記関係型データベース（２０）を照会することによって、受信された位置コードの位置分類を識別するように適応され、かつ、該識別された位置分類に依存して、サーチ照会として、該識別子、好ましくは上記一意の位置識別子を使用して、上記エリア位置関係（１２３）、上記区画位置関係（１２４）、または上記点位置関係（１２５）のいずれかから、さらなる位置情報を検索するように適応されている、上記項目のうちのいずれかに記載の電子デバイス。
【００４８】
（項目７）
上記第１の関係（１２０）、上記区画位置関係（１２４）、および／または上記位置類型関係（１２２）は、各レコードを位置名称識別子と関連付ける属性を備え、上記位置名称関係（１２１）は、該位置名称識別子を位置名称と関連付けるレコードを備える、上記項目のうちのいずれかに記載の電子デバイス。
【００４９】
（項目８）
上記第１の組の関係（１０２）は、エリア位置関係（１２３）を備え、該エリア位置関係（１２３）は、位置コードを、
該位置コードに対応するエリアがサービス放送エリアであるかどうかを示す属性と、
該位置コードに対応するエリアが位置する州の略号を備える属性と
のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５０】
（項目９）
上記第２の組の関係（１０１）は、イベントコードをイベントテキストと直接的または間接的に関連付けるイベント名称関係（１１１）を備え、該イベント名称関係（１１１）は、２つ以上の異なる言語において、該イベントテキストのためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該イベントテキストが提供される言語を識別する、上記項目のうちのいずれかに記載の電子デバイス。
【００５１】
（項目１０）
上記第１の組の関係（１０２）は、位置コードを位置名称と直接的または間接的に関連付ける位置名称関係（１２１）を備え、該位置名称関係は、２つ以上の異なる言語において、該位置名称のためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該位置名称が提供される言語を識別する、上記項目のうちのいずれかに記載の電子デバイス。
【００５２】
（項目１１）
上記イベント名称関係（１１１）または上記位置名称関係（１２１）は、それぞれ、対応する上記イベントテキストまたは上記位置名称の音素表現を検索するために、該イベントテキストまたは該位置名称を音素識別子とさらに関連付け、かつ／あるいは、それぞれ、対応する該イベントテキストまたは該位置名称の音響表現を検索するために、該イベントテキストまたは該位置名称を声音識別子とさらに関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５３】
（項目１２）
上記第２の組の関係（１０１）は、イベント関係（１１０）を備え、該イベント関係（１１０）は、上記イベントコードを、
イベントコードと関連付けられたアイコン組を識別するアイコン組識別子と、
上記イベントの性質を識別するイベント性質と、
対応するＴＭＣメッセージの持続期間の決定のための情報を備える持続期間類型と、
該イベントが交通の一方向または両方向に関係するかどうかを示すデフォルト方向性と、
該イベントの緊急度を示すイベント緊急度と、
該交通イベントの深刻度を示す渋滞分類と、
該イベントの更新等級を識別する更新等級と、
該イベントと結合されることが許される数量詞の類型を示す数量詞類型と
のうちの少なくとも１つの属性またはこれら属性の組合せと直接的または間接的に関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５４】
（項目１３）
上記関係型データベース（２０）は、局リスト関係（１０３）をさらに備え、該局リスト関係（１０３）は、受信されたＴＭＣメッセージ中に含まれる国識別子を、
ＴＭＣメッセージを放送する送信者を示す送信者識別子と、
ラジオ番組を識別する番組識別子と、
該送信者が受信可能である地理的エリアを記述するタイル識別子と
のうちの少なくとも１つの属性またはこれら属性の組合せと関連付ける、上記項目のうちのいずれかに記載の電子デバイス。
【００５５】
（項目１４）
上記位置コードはＴＭＣ位置コードであり、上記電子デバイスは、ＴＭＣクライアントまたはＴＰＥＧクライアントとして動作するように構成されている、上記項目のうちのいずれかに記載の電子デバイス。
【００５６】
（項目１５）
交通情報クライアントとして動作するように構成された電子デバイス（１０）を動作させる方法であって、該電子デバイス（１０）は、交通情報メッセージを受信するためのインタフェース（１１）と、少なくとも第１の組の関係（１０２）を備える関係型データベース（２０）とを備え、該第１の組の関係（１０２）は、位置コードを位置情報と直接的または間接的に関連付ける少なくとも１つの関係（１２０、１２１）を含み、該方法は、
交通イベントの位置を識別する位置コードを備える交通情報メッセージを該インタフェース（１１）上で受信するステップと、
サーチ照会として該位置コードを使用して該関係型データベース（２０）を照会するステップと、
該位置コードと関連付けられた位置情報を該関係型データベース（２０）から検索するステップと
を包含する、方法。
【００５７】
（項目１６）
上記電子デバイスは、上記項目のうちのいずれかに従って構成されている、上記項目のうちのいずれかに記載の方法。
【００５８】
（項目１７）
電子的に可読なデータキャリアであって、該データキャリアは、該データキャリア上に格納された関係型データベースを備え、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、電子的に可読なデータキャリア。
【００５９】
（項目１８）
上記関係型データベース（２０）は、上記項目のうちのいずれかに従って構成されている、上記項目のうちのいずれかに記載の電子的に可読なデータキャリア。
【００６０】
（摘要）
本発明は、交通情報クライアントとして動作するように構成された電子デバイスを提供する。交通情報クライアントデバイスは、交通情報メッセージを受信するように適応されたインタフェースを備え、交通情報メッセージは、交通イベントの位置を識別する位置コードを備え得る。交通情報クライアントデバイスは、さらに、メモリと、該メモリに格納された関係型データベースとを備え、関係型データベースは、少なくとも１つの関係を含む、少なくとも第１の組の関係を備え、少なくとも１つの関係は、位置コードを位置情報と直接的または間接的に関連付ける。
【図面の簡単な説明】
【００６１】
本発明の前記および他の特徴ならびに利点は、添付の図面と共に読まれると、以下の例示的実施形態の詳細な説明からさらに明白になろう。
【図１】図１は、本発明の実施形態に従うＴＭＣクライアントデバイスを図示する概略図である。
【図２】図２は、本発明の実施形態に従う関係型データベースの複数の関係を概略的に図示する。
【図３】図３は、図２の実施形態に従う関係型データベースのさらなる関係を概略的に図示する。
【図４】図４は、本発明の実施形態に従う方法を図示するフロー図である。
【図５】図５は、本発明の実施形態に従う方法を図示するフロー図である。
【図６】図６は、本発明の実施形態に従う関係型データベースの更新を図示するフロー図である。
【発明を実施するための形態】
【００６２】
以下において、本発明の実施形態は、添付の図面を参照して詳細に説明される。以下の実施形態の説明は、例示の目的のためにのみ供され、限定的な意味にとられるべきではないことを理解されたい。図面は、概略の表現であるようにのみ見なされるべきであり、図面中の複数の要素は、必ずしも互いにスケールを決める必要はない。図面中に示された物理的もしくは機能的なブロック、または、物理的もしくは機能的なユニットは、必ずしも物理的に別個のユニットとして実装される必要はないが、示されるか、または説明されるブロックもしくはユニットは、別個のユニット、回路、チップ、または回路要素として実装され得るか、あるいは、共通の回路、チップ、回路要素、またはユニットとしても同様に実装され得る。
【００６３】
以下において、ＴＭＣメッセージを受信するＴＭＣクライアントデバイスに対して参照がなされるが、この説明は、本発明に対して明らかに非制限的であり、ＴＰＥＧメッセージを受信するＴＰＥＧクライアントデバイスなど、任意の類型の交通情報クライアントデバイスが本発明によって網羅されることを留意されたい。とりわけ、ＴＭＣメッセージと共に受信される位置コードの処理に関して以下に供される説明は、ＴＭＣ位置参照を使用するＴＰＥＧクライアントデバイスにおいて、ＴＰＥＧメッセージと共に受信される位置コードの処理に対して同等に適用可能である。
【００６４】
図１は、本発明の実施形態に従う交通情報クライアントデバイス１０の概略ブロック図を示す。交通情報クライアントデバイス１０は、ＴＭＣまたはＴＰＥＧクライアントとして動作するように適応され得、とりわけ、交通情報クライアントデバイス１０は、ＴＭＣメッセージおよび／またはＴＰＥＧメッセージを受信もしくは解釈するように適応される。受信されたＴＭＣメッセージまたはＴＰＥＧメッセージに含まれる情報は、交通情報クライアントデバイス１０によって処理され、デバイスの使用者に提示される。以下において、ＴＭＣクライアントデバイスとしてのデバイス１０の実装が説明されるが、この説明は、ＴＰＥＧクライアントデバイスおよびＴＰＥＧメッセージに対して等しく適用可能であることが明らかであろう。
【００６５】
ＴＭＣクライアントデバイス１０は、受信ユニット１１を備え、受信ユニット１１は、ＴＭＣメッセージを受信するためのインタフェースを提供するように適応される。ＴＭＣメッセージは、概して、ＦＭ放送を使用して伝送され、該メッセージは、ＦＭラジオデータシステム（ＲＤＳ）を使用してデジタル的に符号化される。したがって、受信ユニット１１は、ＲＤＳが有効にされたＦＭ受信器を備え得る。従来のＦＭラジオ放送以外に、ＴＭＣメッセージはまた、デジタル音声放送（ＤＡＢ）上で、または衛星ラジオ上で伝送され得る。したがって、受信ユニット１１はまた、これらのチャネル上でＴＭＣメッセージを受信するように適応され得る。他の実施形態において、受信ユニット１１は、ＴＭＣメッセージを、そのようなメッセージを提供する任意のソースから受信するように適応される。ＴＰＥＧデバイスとして実装される場合、受信ユニット１１は、ＴＰＥＧメッセージを受信するように適応され得、ＴＰＥＧメッセージは、デジタル放送（例えばＤＡＢ）またはセルラー／インターネット接続などの二地点間接続を使用して伝送される。しかしながら、一般的に、ＴＰＥＧはベアラ独立であるように設計されるので、任意のデジタルベアラが使用され得、したがって、任意の類型のＴＰＥＧメッセージが受信ユニット１１によって受信され得る。
【００６６】
ＴＭＣクライアントデバイス１０は、さらに、受信されたＴＭＣメッセージを処理するように適応される処理ユニット１３を備える。処理ユニット１３は、メモリ１２に格納された制御プログラムに従って、ＴＭＣクライアントデバイス１０の動作を制御する。処理ユニット１３は、汎用または専用のマイクロプロセッサもしくは１つ以上のデジタル信号プロセッサ、あるいは特定用途向け集積回路の形態において、単一または複数のマイクロプロセッサとして実装され得る。メモリ１２は、ランダムアクセスメモリ（ＲＡＭ）、フラッシュメモリ、またはハードドライブなど、あらゆる形態のメモリを備え得る。これらの類型のメモリのうちのいくつかは、フラッシュメモリカードまたは同等物など、デバイス１０から取り外し可能であり得る。
【００６７】
処理ユニット１３は、機能ユニット２５および２６を備え、機能ユニット２５および２６は、例えば、処理ユニット１３上で走行するソフトウェアコード部分として実装され得る。検索ユニット２５は、着信するＴＭＣメッセージを、その中に含まれる情報について解析するように適応され、このような情報は、ＴＭＣイベントコード（ＴＰＥＧメッセージの場合はＴＰＥＧコード、本特許の部分ではない）、ＴＭＣ位置コード、国コード（ｃｃ）、拡張された国コード（ｅｃｃ）（供給される場合）、位置表番号（ｌｔｎ）、イベント識別子、位置オフセット、方向、および同様なものなどである。ＴＰＥＧクライアントデバイスとして実装される場合、検索ユニット２５は、受信されたＴＰＥＧメッセージ中に含まれるＴＭＣ位置コンテナから、ｃｃ、ｅｃｃ（供給される場合）、およびｌｔｎのみならず、ＴＭＣ位置コードを抽出し得、さらに、ＴＰＥＧメッセージからＴＰＥＧイベントコードおよび同様なものを抽出し得る。
【００６８】
検索ユニット２５は、受信されたＴＭＣメッセージから抽出された情報からサーチ照会を構成し、対応するイベント情報または位置情報を検索するために、このサーチ照会を使用して、メモリ１２に格納された関係型データベース２０を照会する。データベース２０から検索された情報から、処理ユニット３０は、図形的メッセージまたはテキストメッセージを組立て、これらメッセージは、ディスプレイ１５によってＴＭＣクライアントデバイス１０の使用者に発せられ得る。他の実施形態において、拡声器（示されていない）によってＴＭＣクライアントデバイス１０の使用者に発せられる声音メッセージがコンパイルされる。
【００６９】
受信されるＴＭＣメッセージは、ＴＭＣ規格（例えば、ＡＬＥＲＴ Ｃ規格、またはＩＳＯ １４８１９）において規定されるように、任意の情報を備え得る。受信されたＴＭＣメッセージを復号化する場合、処理ユニット１３は、対応する交通イベントの類型および場所を識別する必要がある。交通イベントの類型は、イベントコードによって識別される。このような類型は、例えば、「静止した交通」、「列をなしている交通」、「ゆっくりとした交通」、または同様なものであり得る。ＴＭＣメッセージ中に含まれる位置コードは、交通イベントの位置を識別し、そして、対応する位置表を使用することによって復号化され得る。異なる国々に対する位置表は、同一の位置コードを備え得るので、国および使用されるべき位置表を一意に識別するために、追加の値ｃｃ、ｅｃｃ、およびｌｔｎが使用される。次いで、交通渋滞の開始場所および終了場所は、交通渋滞の開始している場所を識別する位置コードと、交通渋滞の延びを識別する方向およびオフセットとから識別され得る。処理ユニット１３は、対応する情報を関係型データベース２０から検索し、「ミュンヘンとミュンヘン空港との間で４ｋｍの列をなしている交通」などの対応するメッセージを発するように適応される。
【００７０】
受信されるＴＰＥＧメッセージは、ＴＰＥＧ規格（ＩＳＯ １８２３４シリーズまたはＩＳＯ ２１２１９シリーズ）において規定されるように、任意の情報を備え得る。ＴＰＥＧメッセージの位置内容は、それがＴＭＣ位置参照を使用する場合、ＴＭＣメッセージの位置部に類似する手法において処理される。
【００７１】
従来のシステムにおいて、イベント表および位置表は、ＴＭＣまたはＴＰＥＧクライアントソフトウェア内に含まれ、バイナリラージオブジェクトの形態において格納されるが、本発明は、イベント情報および位置情報を備える関係型データベース２０を提供する。関係型データベース２０の可能な実装は、図２および図３に関連して、以下に説明される。
【００７２】
関係型データベース２０は、少なくとも、位置情報を備える第１の組の関係１０２（図３）と、イベント情報を備える第２の組の関係１０１（図２）とを備える。一般的に、両方の組の関係がＴＭＣクライアントデバイスにおいて提供されるが、ＴＰＥＧクライアントデバイスは、ＴＭＣ位置参照のために、第１の組の関係のみを備え得る。さらに、ＴＰＥＧクライアントデバイスはまた、ＴＰＥＧイベントコードをイベント情報と関連付ける第２の組の関係を有するデータベースを備え得、以下に供される説明が、必要な変更を伴って適用可能である。
【００７３】
図２および図３において、関係は、矩形によって図示され、参照符号によって表記される。各関係は、第１行に関係の名称を備える。次の組の行において、主キー（ＰＫ）として使用され得る関係の属性が識別される。第３の組の行は、関係のさらなる属性を備える。本実施形態において必須である各関係のさらなる属性は、太字フォントで表される一方、随意的な属性は、通常フォントで複写されている。他の実施形態において、他の属性が必須または随意であり得ることは明確であろう。関係は、外部キーを有する属性を備え得、外部キーは、別の関係中のレコードを識別するために使用され得る。これは、関係間の線によって図示され、線が向かって接続する関係の中のレコードにアクセスするための外部キーを示す。これは、後で詳細に説明される。
【００７４】
第２の組の関係１０１は、イベントコードをイベント情報と直接的に関連付ける２つの関係１１０および１１１を備える。他の実施形態において、唯一のこのような関係が提供され得るか、または、イベントコードをイベント情報と間接的に関連付ける関係が提供され得る。
【００７５】
イベント関係１１０は、主キー（ＰＫ）として使用されるイベントコードを、以下に詳述されるイベント情報を備えるいくつかの属性と直接的に関連付ける。各関係は、表として想定され得、このような表は、表の列を形成する属性と、行を形成する関係の（タプルまたはリレーションシップとも呼ばれる）レコードとを有する。各レコードまたは各表の行は、主キーによって一意に識別され得る。したがって、主キーが供されると、関係または表の残りの属性の値は、主キーによって識別されたレコードから検索され得る。
【００７６】
ＴＭＣイベント関係１１０は、各イベントコードに対して、テキストおよび追加の情報を備え、テキストおよび追加の情報は、例えば、メッセージ管理のために使用され得る。主キーｅｖｅｎｔＣｏｄｅは、ＴＭＣメッセージ中において受信される場合のイベントコードである。属性ｉｃｏｎＳｅｔＩｄは、アイコン組識別子を備え、アイコン組識別子は、ナビゲーションデバイスのディスプレイ上に表示され得るアイコンについての情報を含有する別個の表（示されていない）へのリンクである。各交通イベントに対して、アイコンの一類型が別個の表において提供され得る（例えば、交通イベント「交通渋滞」に対する、赤い枠を有する三角形の中に表示されたいくつかの自動車）。ＴＭＣクライアントデバイスのディスプレイ上において、サイズ、色（例えば、昼間アイコンまたは夜間アイコン）などが異なり得る「交通渋滞」アイコンのいくつかの出現があり得るので、組全体のアイコンが各交通イベントに割当てられる。現在時刻またはディスプレイサイズなどのさらなる情報を使用して、適切なアイコンが検索され得る。
【００７７】
関係１１０は、属性ｊａｍＣａｔｅｇｏｒｙをさらに備え、属性ｊａｍＣａｔｅｇｏｒｙは、機械可読な形態において、「重度の交通」または「ゆっくりとした交通」など、イベントコードに対応するイベントテキストのテキスト的ステートメントを記述する。これらステートメントは、ＴＭＣクライアントデバイス１０の経路選択ユニット（示されていない）に提供され得るか、または、この経路選択ユニットによって検索され得る。このようなユニットが開始点から目的地までの経路を決定する場合、ユニットは、それぞれの道路区画に対する経路選択コストを決定するために、渋滞分類を考慮し得る。イベントコードと関連付けられたイベントテキストは、交通渋滞に関係した情報をテキスト文字列としてのみ供するが、渋滞分類属性は、この情報を直接的に数字形式において提供し得、時間を費やすイベントテキストの言語依存解析を回避する。
【００７８】
関係１１０は、イベントコードをイベント情報と関連付ける、いくつかのさらなる属性を備える。これらは、交通イベントの性質を記述するイベント性質属性、数量詞の類型を決定する許容された数量詞類型属性を含み、許容された数量詞類型属性は、ゆっくりと動く交通の平均速度など、イベントコードと共に使用され得る。ｄｕｒａｔｉｏｎＴｙｐｅ属性は、メッセージの持続期間を決定し、ＴＭＣクライアントデバイスによって、（例えば、特定の交通イベントの持続性など）メッセージ管理のために使用され得る。例として、「Ｄ」は、短い持続期間の動的イベントを指示し得、「Ｌ」は、より長く継続するイベントを指示し得る。コードが括弧内に置かれる場合、持続期間情報は、本実施形態におけるクライアントデバイスの使用者に提示されない。
【００７９】
さらなる属性が、交通イベントが一方向もしくは両方向に関連しているかどうかを示すｄｅｆａｕｌｔＤｉｒｅｃｔｉｏｎａｌｉｔｙ、イベントの緊急度、またはｕｐｄａｔｅＣｌａｓｓを備え、ｕｐｄａｔｅＣｌａｓｓは、ＴＭＣクライアントデバイスによるメッセージ管理のための更新機構によって使用される。
【００８０】
イベント名称関係１１１は、イベントコードをイベントテキストと直接的に関連付ける。同一のイベントコードに対して、対応するイベントテキストが、関係１１１中に異なる言語において提供される。したがって、属性ｌａｎｇｕａｇｅＣｏｄｅは、属性ｅｖｅｎｔＣｏｄｅと一緒に、主キーとして使用される必要がある。さらに、イベントテキストは、数量詞を有さずに、単数の数量詞に対して、または１より大きい数量詞に対して、提供され得る。したがって、「ｑｕａｎｔｉｆｉｅｒ」属性は、交通イベントテキストがどの類型の数量詞に対して検索されるべきかを示すために、主キーにおいて使用される。複数形の形態に対して、イベントテキストは、例えば、プレースホルダを備え得る。単数形／複数形の形態に対して格納されるイベントテキストは、例えば、「（１台／Ｑ台）の重量のあるトラックを巻き込む事故」などであり得る。３の数量詞に対しては、イベントテキストは「３台の重量のあるトラックを巻き込む事故」と読み得る。単数形の形態に対しては、イベントテキストは「１台の重量のあるトラックを巻き込む事故」と読み得る。
【００８１】
イベントテキスト中の固定コード化された値は、例えば、番号を「＄」文字の間に置くことによってなど、特別な手法においてマークされ得る。
【００８２】
イベントテキストが数量詞プレースホルダを含有する場合、数量詞プレースホルダもまた、特別な文字によってマークされ、特別な文字は、実際の値および数量詞の単位によって置換され得る。例として、イベントコード「１０８」は、イベントテキスト「（＄Ｑ＄の平均速度で）列をなしている交通」と関連付けられ得、＄Ｑ＄は、数量詞が提供される場合は、数量詞で置換される。提供されない場合は、括弧内のテキストは、対応するテキストメッセージを表示する際に除去される。
【００８３】
さらなる属性ｐｈｏｎｅｍｅＩｄは、音素識別子を備え、音素識別子は、関連付けられたイベントテキスト文字列の音素表現を含有する表のレコードを参照する。これは、話し言葉出力の品質を強化するために使用され得る。同様に、属性ｖｏｉｃｅＩｄは、声音識別子を備え、声音識別子は、事前録音された声音出力を備える表の中のエントリを参照する。事前録音された声音出力は、例えば、ｍｐ３ファイルであり得、ｍｐ３ファイルは、対応する交通メッセージを使用者に提供するために、ｍｐ３復号器によって再生され得る。これらの属性は、随意であり、いくつかのレコードに対しては空（ｖｏｉｄ）であり得ることが明確であろう。
【００８４】
関係１１２は、ＴＭＣ補足情報リストを備える。関係１１２は、ＴＭＣメッセージと共に受信される場合の補足情報コードを、対応する情報を有するテキスト文字列を備えるテキスト属性と関連付ける。この場合もまた、テキストは、異なる複数の言語に対して提供され得、これによって、言語コードは、補足情報コードと一緒に主キーとして使用される。関係１１１に関して上述されたように、関係１１２は、さらに、音素識別子（ｐｈｏｎｅｍｅＩｄ）および声音識別子（ｖｏｉｃｅＩｄ）のための属性を備え得る。
【００８５】
関係１１３は、ＴＭＣイベントのバージョン番号を保持する。本実施形態において、すべてのイベントコードが同一のバージョンである。一般的に、ＴＭＣイベントコードの複数のバージョンを保持することは必要とされない。
【００８６】
図３は、位置コードを位置情報と直接的または間接的に関連付ける関係を備える、第１の組の関係１０２を示す。組１０２は、位置コードを位置情報と直接的および間接的に関連付ける関係１２０を備える。位置リスト関係１２０の各レコードは、属性ｃｃ（国コード）、ｅｃｃ（拡張された国コード）、ｌｔｎ（位置表番号）、およびｌｏｃＣｏｄｅ（位置コード）によって一意に識別され得る。したがって、これらの属性は、特定のレコードを関係１２０から検索するために、サーチ照会として使用され得る。関連付けられた関係において、レコードの識別を容易にするために、かつ、レコードへのアクセスをさらに加速するために、各レコードに対する一意の位置識別子を備えるｌｏｃＩｄ属性が提供される。この一意の識別子は、サロゲート（ｓｕｒｒｏｇａｔｅ）キーに相当し、代用キーは、関係１２０において主キーとして使用される。
【００８７】
次いで、関係１２０は、たとえ、異なる国々が同一の位置コードを使用する場合でも、これら異なる国々に対する位置コードを備える。各国は、２つ以上の位置表を確保し得るので（対応するｌｔｎ値の範囲は、ＴＭＣ基準において規定される）、属性ｌｔｎは、位置を全世界ベースで一意に識別するために、ｌｏｃＣｏｄｅ、ｃｃおよびｅｃｃと一緒に使用され得る。各位置に対して、情報は、各レコードにおいて、位置分類（ｌｏｃＣａｔｅｇｏｒｙ）、位置類型（ｌｏｃＴｙｐｅ）、および位置副類型（ｌｏｃＳｕｂｔｙｐｅ）について提供される。ｌｏｃＣａｔｅｇｏｒｙ属性は、位置が、エリア、線状（区画とも呼ばれる）、または点位置であるかどうかを示す。ｌｏｃａｔｉｏｎＴｙｐｅは、例えば、ジャンクションまたは同様なものなどであり得る。副類型は、例えば自動車専用道路の出口の形態におけるジャンクションなど、位置類型をさらに指定する。これらの属性の値は、主キーｌｏｃＩｄ、または、４つの属性ｃｃ、ｅｃｃ、ｌｔｎ、およびｌｏｃＣｏｄｅのどちらかで関係１２０を照会する場合に検索され得る。データベース２０によって返される結果の一例は「Ｐ１．４］であり得、ここで、「Ｐ」は点位置を示し、「１」は類型「ジャンクション」を示し、「４」は自動車専用道路の出口を示す。
【００８８】
さらなる属性ｐｏｓＯｆｆｓｅｔＬｏｃＩｄおよびｎｅｇＯｆｆｓｅｔＬｏｃＩｄは、位置リスト関係１２０に従って、それぞれ、正方向または負方向における次の位置に対する一意の位置識別子を備える。これらの属性はまた、無（ｎｕｌｌ）または空（ｖｏｉｄ）であり得る。このようにして、先行または後続する位置が容易に識別され得る。
【００８９】
属性ｐａｒｅｎｔＡｒｅａＩｄおよびｐａｒｅｎｔＳｅｇｍｅｎｔＩｄは、階層内のより高位の位置のために、それぞれ、エリア位置および区画位置に対する一意の位置識別子を備える。このことは、自動車専用道路の出口などの点位置が位置する道路区画を識別するために有利であり得る。このことは、特に、位置の名称が位置を曖昧さ無く記述するのに十分ではない状況に対して有利であり、これによって、階層内のより高位のエリアまたは区画が必要とされる。一例は、「Ｂａｈｎｈｏｆｓｔｒａｓｓｅ」、「ｉｎ Ｎｅｕｍａｒｋｔ」、および「ｉｎ ｄｅｒ Ｏｂｅｒｐｆａｌｚ」であり、異なる階層の３つの名称のみで位置を曖昧さ無く記述する。
【００９０】
ｆｉｒｓｔＮａｍｅＩｄ属性は、位置名称識別子を備え、位置名称識別子は、ＴＭＣ名称関係１２１中のレコードを参照し、しかるに、外部キーに相当する。このことは、関係１２０と関係１２１との間の矢印によって示される。したがって、これらの関係は、位置コードと位置名称との間の間接的な関連付けを提供する。関係１２１は、すべての位置名称をテキスト文字列の形態において保持する。この場合もまた、同一の位置名称識別子（属性「ｉｄ」）に対して複数のレコードが存在するように、名称が異なる複数の言語で提供される。したがって、属性「ｉｄ」および「ｌａｎｇｕａｇｅＣｏｄｅ」は、主キーとして使用される。属性「ｎａｍｅ」は、それぞれの言語における位置名称のテキスト文字列を備える。関係１１１を参照して上述されたように、関係１２１は、音素識別子属性および声音識別子属性を備え、音素識別子属性および声音識別子属性は、それぞれ、位置名称の音素表現、または、位置名称に対する事前録音された声音データを備える、対応するレコードを参照する。いくつかの名称は、追加情報なしでは、テキストから話し言葉へのエンジンによって正しく発音されることができないので（例えば英国レスター（Ｌｅｉｃｅｓｔｅｒ））、そのような音素情報は、位置名称に対して特に有用である。
【００９１】
すべてのテキスト文字列を別個の関係１１１または１２１中に提供することによって、テキスト文字列が容易に更新され得、新たな言語が追加され得る。対応する関係は、単に、対応する言語におけるイベントテキストまたは位置名称を備える追加のレコードで展開される必要がある。次いで、処理ユニットによって識別された言語コードが、対応する言語におけるテキストを検索するために使用され得る。さらには、残りの関係は、完全に言語独立に維持され得、残りの関係の構造を単純化し、残りの構造に含まれるレコードへのアクセスを加速する。
【００９２】
エリア、区画、または点位置に特有の情報に対して、それぞれ、３つの別個の関係１２３、１２４、および１２５が提供される。この場合もまた、これらの関係に含まれる位置情報は、一意の位置識別子（ｌｏｃＩｄ）によって位置コードと関連付けられる。ｌｏｃＩｄ属性は、これら３つの関係に対する主キーとして使用される。このことは、例えば、点位置のレコードにおける区画位置に特有の属性に対してなど、空のデータフィールドが回避されるので、データベースをよりコンパクトに表し、記憶空間を節約する。
【００９３】
エリア位置関係１２３は、ｌｏｃＩｄを、エリアが放送サービスエリアであるかどうかを示す属性と関連付ける。この情報は、例えば、米国に対して利用可能であり、また、この情報は、ＴＭＣクライアントデバイス１０のチューナの局選択方略のために有用であり得る。属性略号は、例えば、カリフォルニアに対する「ＣＡ」など、エリアに対応する州の略号を識別する。これは、ＴＭＣクライアントデバイスのディスプレイ上の交通メッセージのテキスト的表現の一部であり得る。
【００９４】
区画位置関係１２４は、区画位置のｌｏｃＩｄを位置名称識別子（ｓｅｃｏｎｄＮａｍｅＩｄ）と関連付け、位置名称識別子（ｓｅｃｏｎｄＮａｍｅＩｄ）は、（言語コードと一緒に）位置名称関係１２１中のレコードを参照する。ｆｉｒｓｔＮａｍｅＩｄ（関係１２０）およびｓｅｃｏｎｄＮａｍｅＩｄは、例えば、「シュトゥットガルト」と「ミュンヘン」との間のＡ８など、道路区画の開始点および終了点を指す。属性ｒｏａｄＮａｍｅＩｄは、道路名称を検索するための識別子を備える。道路名称は、一般的に、「Ｂａｈｎｈｏｆｓｓｔｒａｓｓｅ」などのテキスト文字列として規定される。
【００９５】
本実施形態において、「Ａ８」などの道路番号は、３つの部、すなわち、プレフィクス文字列（ｒｏａｄＮｕｍｂｅｒＰｒｅｆｉｘＩｄ属性）、整数道路番号（ｒｏａｄＮｕｍｂｅｒ属性）、およびサフィクス文字列（ｒｏａｄＮｕｍｂｅｒＳｕｆｆｉｘ属性）に分割される。例として、番号「Ｂ６２Ｎ」を有する道路は、「Ｂ」＋「６２」＋「Ｎ」に分割される。このことは、特に、ナビゲーションアプリケーションと組合せて使用される場合に有利である。交通情報メッセージを表示する交通情報リストは、整数道路番号によって容易に数値的に格納され得る。さらには、道路番号の図形的表現において、ドイツの「Ｂｕｎｄｅｓｓｔｒａｓｓｅ」に対して黒い縁（ｂｏａｒｄｅｒ）を有する黄色い標識など、プレフィクスは、整数道路番号が表されるビットマップによって置き換えられ得る。このようにして、プレフィクス情報は、ビットマップの形態において提示される。属性ｒｏａｄＮｕｍｂｅｒＳｔｒｉｎｇは、道路番号が、プレフィクス＋整数道路番号＋サフィクスのパターンに当てはまらない場合に対して、フォールバックとして使用される。
【００９６】
関係１２４において、プレフィクスは、関係１２７中のレコードを参照する属性ｒｏａｄＮｕｍｂｅｒＰｒｅｆｉｘＩｄによって間接的に提供される。この関係は、各プレフィクス識別子を優先度および実際のプレフィクスと関連付ける。これは、各国に対して行われ得る。ドイツに対する例としては、道路番号プレフィクス「Ａ」（Ａｕｔｏｂａｈｎ）は、最も高い優先度と関連付けられ得、プレフィクス「Ｂ」（Ｂｕｎｄｅｓｓｔｒａｓｓｅ）は、次のより低い優先度と関連付けられ得るなどである。したがって、第１の評価基準としてのプレフィクス優先度、および第２の評価基準としての道路番号によって、クライアントデバイスのディスプレイ１５上の交通情報メッセージリストをソートすることが可能である。このようなソートされたリストの例は、Ａ１，Ａ１０，Ｂ２，Ｂ１１であり得、それぞれの交通情報が道路番号の後に表示される。
【００９７】
同様な手法において、点位置関係１２５は、一意の位置識別子をｊｕｎｃｔｉｏｎＮｕｍｂｅｒ属性およびｊｕｎｃｔｉｏｎＮｕｍｂｅｒＳｕｆｆｉｘ属性と関連付け、これら属性によって、ジャンクション名称は、整数番号と文字列とに分割される。これによって、番号によるジャンクションのソートと、より直観的な図形的表現におけるジャンクションの表示とが可能になる。点位置間の距離は、一般的に、それらの座標を使用して計算される。関係１２５は、さらに、ｄｉｓｔａｎｃｅＴｏＰｏｓＯｆｆｓｅｔＬｏｃ属性およびｄｉｓｔａｎｃｅＴｏＮｅｇＯｆｆｓｅｔＬｏｃ属性を備え、これら属性は、正方向または負方向における隣接する点位置までの道路距離を供する。この道路距離は、２点間の飛行距離よりも写実的であり、しかるに、交通メッセージによって起動され得るナビゲーションアプリケーションにおける経路コストの計算を改善する。属性「ｉｓＵｒｂａｎ」は、位置が都市部エリアの内外のいずれであるかを規定する。この情報は、位置が都市部エリアである場合、街路名称に加えてそれぞれの都市名を表示するために使用され得る。ｎｂｒＰｏｓＤｉｒ属性およびｎｂｒＮｅｇＤｉｒ属性は、それぞれ、正方向および負方向において、自動車専用道路または同様に建設された道路に沿った、事前割当てされた迂回番号を備える。一般的に、位置および方向毎に１つの迂回番号が提供され、対応する方向における自動車専用道路の次の入口まで道を案内する。
【００９８】
関係１２８は、点位置に関係している経路選択リンクを備える。関係は、点位置の一意の位置識別子およびシーケンス番号（ｓｅｑＮｕｍｂｅｒ）によって照会され得、シーケンス番号（ｓｅｑＮｕｍｂｅｒ）によって、正方向におけるリンクは、１で始まる正の番号で番号付けされ、負方向におけるリンクは、負の番号で番号付けされる。シーケンス番号−１を有する入口は、位置コードに最も近い。属性ｔｉｌｅＩｄは、対応するリンクを含有する経路選択タイルのタイル番号を備える。ｌｉｎｋＩｄ属性は、タイル内のリンクのシーケンス番号を供する。
【００９９】
関係１２９は、点位置に対する、一意の位置識別子（ｌｏｃＩｄｓ）の対を備える。関係は、ｌｏｃＩｄＲｏａｄＯｎｅおよびｌｏｃＩｄＲｏａｄＴｗｏによって識別される２つの点位置が同一の物理的道路上に位置していることを示す。これは、２つの異なる組の点位置によって表される２つの別個の自動車専用道路が、同一の物理的道路上で、ある距離の間続いている場合に生じ得る。ナビゲーションアプリケーションにおいて、この情報は、異なる位置を備える２つのＴＭＣメッセージが実際に同一の道路の一続きを指しているかどうかを見出すことを助け得る。２つのこのようなメッセージが識別される場合、ナビゲーションシステムは、冗長な情報を表示することを回避するために、それらのうちの１つを抑制し得る。この種の冗長な交通情報のフィルタリングは、特に、２つ以上の交通情報ソース（例えば２つ以上のラジオ局）が一度に受信される場合に有用である。
【０１００】
地図中の交通情報の表示を容易にするために、または、（例えば、ディスプレイ上に提供される交通情報リストにおいて、交通メッセージを距離でソートするためになど）放送位置と現在の自動車の場所との間の距離の計算を容易にするために、関係型データベースは、位置座標関係１２６を備える。すべての類型の位置に対して、関係１２６は、ｌｏｃＩｄを２つの座標（属性ｘおよびｙ）と関連付ける。従来のシステムにおいては、点位置のみに座標が提供される。関係１２６は、例えば、ＷＧＳ８４形式においてなど、他の類型の位置に対してもまた、これらの座標を提供する。属性「ｃａｔｅｇｏｒｙ」は、ａｒｅａ、ｌｉｎｅ、ｐｏｉｎｔ＿ｃｅｎｔｅｒ、ｐｏｉｎｔ＿ｐｏｓｉｔｉｖｅｓ＿ｓｔａｒｔ、…など、座標類型を識別する。エリアに対しては、外形は、エリア位置の副次的に順序付けされた（ｓｕｂｏｒｄｅｒｅｄ）点の場所から形成される。１つのエリア位置のすべての点は、同一のｌｏｃＩｄと、１つの連続するシーケンス番号（ｓｅｑＮｕｍｂｅｒ）とを有する。このようにして、属性ｓｅｑＮｕｍｂｅｒは、外形が定められた点のインデックスを識別する。これは、区画位置に対して同様である。点位置に対しては、位置の中心を近似する中心座標、または、「ｃａｔｅｇｏｒｙ」属性によって識別されるさらなる座標が供され得る。
【０１０１】
テキスト的表現を完成するために、属性として位置名称識別子（ｎａｍｅＩｄ）を備える位置類型関係１２２が提供され、位置名称識別子（ｎａｍｅＩｄ）は、ある類型の位置のテキスト表現を供する位置名称関係１２１中のレコードを参照する。この場合もまた、ｎａｍｅＩｄおよび言語コードの両方が関係１２１を照会するために主キーとして使用されるので、位置類型関係１２２は言語特化である。関係１２２において、主キーは、位置リスト関係１２０から検索されるｌｏｃＣａｔｅｇｏｒｙ属性、ｌｏｃＴｙｐｅ属性、およびｌｏｃＳｕｂｔｙｐｅ属性のみならず、国および位置表を識別する属性ｃｃ、ｅｃｃ、およびｌｔｎを含む。このようなデータベースの構造化は、位置コード毎に位置類型に対するテキスト文字列が提供される必要はないので、記憶空間を節約する。同一の類型の位置を識別する点コードに対しては、言語毎に、かつ、適用可能な場合は国毎に（特定の類型のＴＭＣ位置は、同一の言語を有する異なる国々において、異なるように呼ばれ得る）、唯一のレコードが関係１２１中に提供される必要がある。この結果として、関係１２０および１２２は、コンパクトに維持され得る。
【０１０２】
例として、ＮａｍｅＩｄによって参照される、自動車専用道路の出口に対するテキスト表現は、ドイツ語で「Ａｎｓｃｈｌｕｓｓｓｔｅｌｌｅ」であり得、または、より短いテキストが所望される場合は「ＡＳ」であり得る。いくつかの位置類型のテキスト表現は、例えば、道路分類を割当てることに対するある種の自由度のレベルに起因してなど、
国毎に異なり得るので、テキスト表現は、国毎に提供される。したがって、ｃｃ、ｅｃｃ、およびｌｔｎが関係１２２の主キーにおいて使用される。ｃｃおよびｅｃｃが国を全世界の中で識別するために十分であっても、一部の放送者は、依然として、欧州内の国を識別するために前記の組合せｃｃ＋ｌｔｎを使用し得る。
【０１０３】
さらなる関係１３０は、異なるＴＭＣ位置のバージョン番号を保持する。１つの位置表のすべての位置は、好ましくは、同一のバージョンを有する。位置表は、３つの属性ｃｃ、ｅｃｃ、およびｌｔｎによって識別される。すべての位置表のすべてのエントリが、位置リスト関係１２０中に格納される。このようにして、関係１３０は、特定の位置表のバージョンを検索するために照会され得る。
【０１０４】
第１の組の関係１０１および第２の組の関係１０２の他に、関係型データベース２０は、さらなる関係を備え得る。例として、局リスト関係１０３が提供され、局リスト関係１０３は、送信者識別子（ｓｉｄ）および番組識別子（ｐｉ）を、送信者が受信され得るタイルのタイル番号（ｔｉｌｅＩｄ）と関連付ける。この場合もまた、この情報は国特化であり、関係１０３は、さらなる属性ｃｃ、ｅｃｃ、およびｌｔｎを備える。したがって、ＴＭＣクライアントデバイス１０のチューナは、特定の地理的エリアにおける走行時にチューニングすべき局に関して、関係１０３から有用な勧告を検索し得る。ｔｉｌｅＩｄによって識別される地理的エリアは、座標を使用して記述され、データベースの別の部分に格納され得る。
【０１０５】
図２および図３は、データベース２０の１つの可能な構成を図示するのみであり、他の実施形態においては、より多くの関係もしくはより少ない関係が提供され得るか、関係が結合されて１つの関係を形成し得るか、または、ある１つの関係の属性が他の関係にスワップアウトされ得ることが明確であろう。例として、関係１２０および１２２は、関係１２０内にＮａｍｅＩｄ属性を提供するように結合され得る。
【０１０６】
ここで図１に戻ると、検索ユニット２５は、イベントコードを備えるサーチ照会と、ＴＭＣメッセージと共に受信される位置コードとｃｃ、ｅｃｃ、およびｌｔｎ属性とを備えるサーチ照会とで、関係型データベース２０を照会するように構成され、それによって、それぞれ、関係１１０および１２０から情報を検索する。ＴＰＥＧクライアントデバイスとして実装される場合、サーチ照会は、ＴＰＥＧメッセージ中のＴＭＣ位置コンテナから読まれたＴＭＣ位置コードを備え得る。ｌｏｃＩｄなどの検索された情報に基づいて、他の関係から情報を検索するために、さらなる照会が関係型データベース２０に送信され得る。このようにして、指示された主キーを使用して、図２および図３に示された関係中に含まれるすべての情報が検索され得る。
【０１０７】
次いで、検索された情報は、検索ユニット２５によってテキストメッセージまたは声音メッセージへコンパイルされ、これらメッセージは、例えば、ディスプレイ１５または拡声器によってなど、使用者に発せられる。
【０１０８】
関係型データベース２０が処理ユニット１３上で走行するＴＭＣクライアントソフトウェアから分離される場合、データベース２０は、容易に更新および展開され得る。この目的のために、更新ユニット２６が提供され、更新ユニット２６は、処理ユニット１３によって実装される機能ユニットである。更新ユニット２６は、関係型データベース２０を更新するためにどのデータが検索され得るかということによって、更新インタフェース１４とインタフェース接続する。更新インタフェース１４は、例えば、ＵＳＢインタフェース、ｆｉｒｅ−ｗｉｒｅインタフェース、イーサネット（登録商標）インタフェース、または同様なものなど、有線インタフェースとして実装され得るか、あるいは、更新インタフェース１４は、例えば、無線ローカルエリアネットワークインタフェース、Ｂｌｕｅｔｏｏｔｈ（登録商標）インタフェース、モバイル通信インタフェース、または同様なものなど、無線インタフェースとして実装され得る。
【０１０９】
インタフェース１４上で受信された更新情報で、更新ユニット２６は、関係型データベース２０のレコード、関係、または組全体の関係を追加もしくは更新し得る。勿論、更新はまた、データベース２０からのレコードまたは関係の除去を含み得る。例として、更新ユニット２６は、新たな言語に対するイベントテキストおよび位置名称を、それぞれ、関係１１１および１２１に追加するように構成され得る。
【０１１０】
交通情報クライアントデバイス１０は、例えば、車両ナビゲーションデバイスとして、パーソナルナビゲーションデバイス（ＰＮＤ）として、パーソナルデジタルアシスタント（ＰＤＡ）として、携帯電話、スマートフォン、および同等物などのモバイル通信デバイスとして、または、ＴＭＣおよび／もしくはＴＰＥＧメッセージを受信および処理することから便益を受ける任意の他のデバイスとして実装され得る。これらのデバイスは、一般的に、使用者に対して地図情報を表示することが可能であるので、車両ナビゲーションデバイスまたはＰＮＤとしての実装が特に有利であり、このような実装において、受信されたＴＭＣ／ＴＰＥＧメッセージから取得される交通イベントの位置がマークされ得、対応するテキストメッセージが使用者に発せられ得る。このように、交通情報クライアントデバイス１０は、デバイス１０の具体的な実装に対して一般的である、さらなるコンポーネントを備え得る。例として、ナビゲーション的機能性を有するデバイスとして実装される場合、デバイス１０は、ＧＰＳ受信器と、使用者に対して表示されるべき地図を組み立てるための地図ユニットと、開始点から目的地までの経路を決定するための経路選択ユニットとを備え得る。
【０１１１】
これに対応して、メモリ１２は、地図データベースおよび経路選択データベースをさらに備え得、これらデータベースは、別個に提供され得るか、またはデータベース２０の部分として提供され得る。地図ユニットは、例えば、道路区間をマークすることによってなど、受信されたＴＭＣ／ＴＰＥＧメッセージによって示される交通イベントを表示し得、交通イベントは、受信された位置コードによって識別され得る。マーク付けの類型は、さらに、交通イベントの深刻度を示し得、このために、地図ユニットは、関係１１０の「ｊａｍＣａｔｅｇｏｒｙ」属性を利用し得る。同様に、経路選択ユニットは、関係１１０の「ｊａｍＣａｔｅｇｏｒｙ」属性、または関係１２５の「正のオフセット位置までの距離」に従って決定される経路区画に対するコストを考慮し得る。このようにして、関係型データベース２０によって、経路選択の精度および性能が改善され得る。
【０１１２】
例えば、モバイル通信デバイスとしてなど、他の実施形態において、交通情報クライアントデバイス１０は、モバイル電話ネットワークの通信のために適応されたモバイル送受信機と、そのようなデバイスに共通したさらなるコンポーネントとを備え得る。モバイル通信デバイスもまた、ナビゲーション的機能性を備え得、そして、それゆえ、上述された特徴はまた、このようなデバイスにも含まれ得ることが明確であろう。
【０１１３】
図４は、ＴＭＣクライアントデバイスとして実装された場合の、交通情報クライアントデバイス１０上で実行され得る方法のフロー図を示す。最初のステップ４０１において、ＴＭＣメッセージが受信ユニット１１によって受信される。ステップ４０２において、ｅｖｅｎｔＣｏｄｅと、利用可能であるならば数量詞とが、受信されたＴＭＣメッセージから読まれる。数量詞は、例えば、交通渋滞における平均速度を示す。次のステップ４０３において、言語コードがＴＭＣクライアントデバイス１０の現在の言語設定から決定される。
【０１１４】
ステップ４０４において、関係１１０（図２）の属性に対する値を検索するためのサーチ照会として、関係型データベース２０がｅｖｅｎｔＣｏｄｅで照会される。この場合もまた、データベース２０は、ＴＭＣイベント名称関係１１１からイベントテキストとｐｈｏｎｅｍｅＩｄもしくはｖｏｉｃｅＩｄとを検索するために、サーチ照会としてイベントコード、数量詞、およびｌａｎｇｕａｇｅＣｏｄｅを使用して照会される（ステップ４０５）。
【０１１５】
ここで、クライアントデバイスは、「４キロメートルにわたる重度の交通」など、交通イベントのテキスト的表現を提供するために利用可能な情報を有する。交通イベントの位置を決定するために、位置コード、オフセット、および方向が、受信されたＴＭＣメッセージから読まれる（ステップ４０６）。由来する国を識別するために、さらに、国コード（ｃｃ）、拡張された国コード（ｅｃｃ）、および位置表番号（ｌｔｎ）がメッセージから読まれる。
【０１１６】
サーチ照会として位置コード、ｃｃ、ｅｃｃ、および／またはｌｔｎを使用して、関係１２０において提供される情報、とりわけ、一意の位置識別子（ｌｏｃＩｄ）およびｆｉｒｓｔＮａｍｅＩｄを検索するために、関係型データベース２０が照会される（ステップ４０７）。例として、位置コードは、点位置を参照する。サーチ照会としてｆｉｒｓｔＮａｍｅＩｄおよびｌａｎｇｕａｇｅＣｏｄｅを使用して、位置名称、ｐｈｏｎｅｍｅＩｄおよび／またはｖｏｉｃｅＩｄが関係１２１から検索され得る（ステップ４０８）。点位置の名称は、例えば、「Ｓｕｌｚｅｍｏｏｓ」であり得る。ここで、ＴＭＣメッセージから検索される方向におけるオフセット値は、位置１２０の「ｐｏｓＯｆｆｓｅｔＬｏｃＩｄ」属性によって、近隣の位置のｌｏｃａｔｉｏｎＩｄを検索することによって、交通イベントの終了を識別するために使用され得る（ステップ４０９）。終了位置のｌｏｃａｔｉｏｎＩｄと、この場合もまた、ｌａｎｇｕａｇｅＣｏｄｅとを使用して、例えば「Ｏｄｅｌｚｈａｕｓｅｎ」など、対応する位置名称が関係１２１から検索され得る。両方の点位置に対して関係１２０から検索されるさらなる属性によって、対応するＮａｍｅＩｄは、関係１２２から取得され得、そして、例えば、言語ＤＥに対する「Ａｕｔｏｂａｈｎａｎｂｉｎｄｕｎｇ」など、関係１２１から位置類型名称を検索するために使用され得る。ここで、ＴＭＣクライアントデバイスは、フリーウェイアクセス「Ｓｕｌｚｅｍｏｏｓ」とフリーウェイアクセス「Ｏｄｅｌｚｈａｕｓｅｎ」との間で４キロメートルの重度の交通があるとの、利用可能な情報を有する。
【０１１７】
関係１２０のｐａｒｅｎｔＳｅｇｍｅｎｔＩｄによって、点位置のｐａｒｅｎｔＳｅｇｍｅｎｔのｌｏｃＩｄがさらに知られる。これは、関係１２０からｐａｒｅｎｔＳｅｇｍｅｎｔのｆｉｒｓｔＮａｍｅＩｄを検索するために、次のステップ４１０において使用される。関係１２１は、ｓｅｃｏｎｄＮａｍｅＩｄと、さらなる属性、とりわけ、ｒｏａｄＮａｍｅまたはｒｏａｄＮｕｍｂｅｒとを検索するために、親区画のｌｏｃＩｄでさらに照会される（ステップ４１１）。この場合もまた、ｆｉｒｓｔＮａｍｅ識別子およびｓｅｃｏｎｄＮａｍｅ識別子ならびにｌａｎｇｕａｇｅＣｏｄｅは、テキスト文字列としての対応する位置名称および／またはｐｈｏｎｅｍｅＩｄもしくはｖｏｉｃｅＩｄを関係１２１から検索するために使用される（ステップ４１２）。例として、第１の位置名称が「ミュンヘン」で、第２の位置名称が「シュトゥットガルト」であり得、これらは、ｒｏａｄＮａｍｅ「Ａ８」を有する区画を終端させる。ここで、クライアントデバイスは、交通イベントがミュンヘンとシュトゥットガルトとの間のＡ８上に位置しているとの、利用可能な情報を有する。
【０１１８】
これは、処理ユニット１３がイベントおよび位置情報を関係型データベース２０からどのように検索し得るかということのただの一例であることが明確であろう。処理ユニット１３は、示された主キー、または、関係中のレコードを一意に識別する他の属性によって、図２および図３に示された関係において提供される任意の情報を関係型データベースから検索し得る。
【０１１９】
次のステップ４１３において、テキストメッセージまたは声音メッセージが、検索されたイベントおよび位置情報から組立てられる。本例において、このようなテキストメッセージは、言語設定ドイツ語（ＤＥ）に対して、「Ａ８ Ｍｕｅｎｃｈｅｎ − Ｓｔｕｔｔｇａｒｔ： ｖｏｎ ＡＳ Ｓｕｌｚｅｍｏｏｓ ｂｉｓ ＡＳ Ｏｄｅｌｚｈａｕｓｅｎ： ｄｉｃｈｔｅｒ Ｖｅｒｋｅｈｒ ａｕｆ ４ ｋｍ」であり得る。上述されたように、声音メッセージは、対応する音素表現または事前録音された声音出力を利用することによって、追加的または代替的に組立てられ得る。
【０１２０】
最後のステップ４１４において、テキストメッセージまたは声音メッセージは、ＴＭＣクライアントデバイスの使用者に発せられる。
【０１２１】
図４および図５に関して説明された方法は、ＴＰＥＧメッセージを受信し、かつＴＭＣ位置参照を使用するＴＰＥＧクライアントデバイスとして実装される場合、必要な変更を伴って、交通情報クライアントデバイス１０上で同様に実行され得る。この場合において、ステップ４０２、４０４、４０５は実行される必要がない。代わりに、ステップ４０１で受信されたＴＰＥＧメッセージから読まれたＴＰＥＧイベントコードが、その後、ＴＰＥＧクライアントソフトウェアを使用してイベントテキストへ変換され得る。ステップ４０６において、ｃｃ、ｅｃｃ（適用可能な場合）、およびｌｔｎのみならず、ＴＭＣ位置コードが、受信されたＴＰＥＧメッセージのＴＭＣ位置コンテナから読まれ得る。
【０１２２】
図６は、交通情報クライアントデバイス１０上の関係型データベース２０の更新を図示する。最初のステップ６０１において、関係型データベースの新たなレコードもしくは更新されたレコードまたは関係、あるいは、関係型データベース中に含まれるべき新たな関係を備える、更新情報は、例えば、更新インタフェース１４上で受信される。交通情報クライアントデバイス上の関係型データベースは、既存のレコード／関係を更新することによって、または、受信された更新情報に含まれる新たなレコード／関係で関係型データベースを展開することによって、ステップ６０２において更新される。関係型データベース２０は、交通情報クライアントデバイスとは別個に提供されるので、このような更新は、クライアントソフトウェアを改変することなく可能である。このことは、新たな類型の情報または新たな言語が容易に追加され得、かつ既存のレコードが容易に修正され得るので、ＴＭＣもしくはＴＰＥＧメッセージ符号化の融通性を多大に増大する。さらに、道路網建設に起因した、新たな／変更された位置は、クライアントデータベースを更新することによって交通情報クライアントデバイスに提供され得る。
【０１２３】
最後のステップ６０３において、交通情報クライアントデバイスは、更新された関係型データベースを有して動作する。
【０１２４】
上記から理解され得るように、クライアントソフトウェアとは別個に、交通情報クライアントデバイスの関係型データベース中に位置情報と、場合によってはイベント情報とを格納することによって、クライアントソフトウェアから独立して、とりわけ、クライアントソフトウェアを再インストールする必要なく、データベースの内容を修正することが可能になる。位置情報およびイベント情報を関係のある形態において格納することは、データベース内容の更新、とりわけ、さらなるレコードによる関係の展開、単体のレコードの修正、さらなる関係の追加、および同様なものを容易にする。このようにして、ＴＭＣ位置情報およびＴＭＣイベント情報は、データベース更新によって現在の状態まで引き上げられ得る。さらには、情報をいくつかの関係間に分布させることによって、必要とされる記憶空間が低減され、レコードにアクセスする際の性能が改善される。このことはまた、クライアントデバイスのメインメモリへのデータベースの部分の選択的ローディングを可能にし、それによって、必要とされるメインメモリの量（メモリフットプリント）を低減する。関係型データベースは、さらに、クライアントデバイス上の地図上での交通情報の表示と、クライアントデバイス上で表示されるべき交通イベントに対するテキストメッセージの生成と、使用者に対して再生されるべき交通イベントに対する声音出力の生成と、動的経路計算のための、交通イベントと関連付けられるコストの決定とを容易にする。
【符号の説明】
【０１２５】
１０ 交通情報クライアントデバイス
１１ 受信ユニット
１２ メモリ
１３ 処理ユニット
１４ 更新インタフェース
１５ ディスプレイ
２０ 関係型データベース
２５ 検索ユニット
２６ 更新ユニット
１０１ 第２の組の関係
１０２ 第１の組の関係
１０３ 局リスト関係
１１０ イベント関係
１１１ イベント名称関係
１２０ 位置リスト関係
１２１ 位置名称関係
１２２ 位置類型関係
１２３ エリア位置関係
１２４ 区画位置関係
１２５ 点位置関係
１２６ 位置座標関係
【特許請求の範囲】
【請求項１】
交通情報クライアントデバイスとして動作するように構成されている電子デバイスであって、
交通情報メッセージを受信するように適応されているインタフェース（１１）であって、交通情報メッセージは、交通イベントの位置を識別する位置コードを備え得る、インタフェース（１１）と、
メモリ（１２）と、
該メモリに格納される関係型データベース（２０）であって、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、関係型データベース（２０）と、
処理ユニット（１３）であって、該関連付けられた位置情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信される位置コードで該関係型データベース（２０）を照会するように適応されている処理ユニット（１３）と
を備えている、電子デバイス。
【請求項２】
交通情報メッセージは、交通イベントを識別するイベントコードをさらに備え得、前記関係型データベースは、少なくとも１つの関係（１１０、１１１）を含む第２の組の関係（１０１）をさらに備え、該少なくとも１つの関係（１１０、１１１）は、イベントコードをイベント情報と直接的または間接的に関連付け、
前記処理ユニットは、該関連付けられたイベント情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信されるイベントコードで該関係型データベース（２０）を照会するように適応されている、請求項１に記載の電子デバイス。
【請求項３】
前記第１の組の関係は、複数のレコードを有する第１の関係（１２０）を備え、該複数のレコードは、異なる国々に対する位置コードを有し、異なる国々に対する該レコードは、同一の位置コードを備え得、該第１の関係は、該第１の関係の各レコードを一意の位置識別子と関連付ける属性を備える、請求項１または請求項２に記載の電子デバイス。
【請求項４】
前記第１の組の関係は、第１の関係（１２０）と、１つ以上の第２の関係（１２１、１２３、１２４、１２５）とを備え、該第１の関係（１２０）は、前記位置コードを、識別子、好ましくは、一意の位置識別子および／または位置名称識別子と関連付け、該１つ以上の第２の関係（１２１、１２３、１２４、１２５）は、それぞれ、特定の類型の位置情報に対して、該識別子を対応する該位置情報と関連付け、これによって、該第１の関係（１２０）は、該位置情報との間接的な関連付けを提供する、請求項１〜請求項３のうちのいずれかに記載の電子デバイス。
【請求項５】
前記１つ以上の第２の関係（１２１、１２２、１２３、１２４、１２５、１２６）は、
エリア位置情報を有するエリア位置関係（１２３）と、
区画位置情報を有する区画位置関係（１２４）と、
点位置情報を有する点位置関係（１２５）と、
位置名称情報を有する位置名称関係（１２１）と、
位置類型情報を有する位置類型関係（１２２）と、
座標情報を有する位置座標関係（１２６）と
のうちの少なくとも１つの関係を備える、請求項４に記載の電子デバイス。
【請求項６】
前記第１の関係（１２０）は、前記位置コードを位置分類識別子と関連付け、該位置分類識別子は、対応する位置がエリア位置、線状位置、または点位置であるかどうかを示し、
前記処理ユニット（１３）は、前記関係型データベース（２０）を照会することによって、受信された位置コードの位置分類を識別するように適応され、かつ、該識別された位置分類に依存して、サーチ照会として、該識別子、好ましくは前記一意の位置識別子を使用して、前記エリア位置関係（１２３）、前記区画位置関係（１２４）、または前記点位置関係（１２５）のいずれかから、さらなる位置情報を検索するように適応されている、請求項５に記載の電子デバイス。
【請求項７】
前記第１の関係（１２０）、前記区画位置関係（１２４）、および／または前記位置類型関係（１２２）は、各レコードを位置名称識別子と関連付ける属性を備え、前記位置名称関係（１２１）は、該位置名称識別子を位置名称と関連付けるレコードを備える、請求項５または請求項６に記載の電子デバイス。
【請求項８】
前記第１の組の関係（１０２）は、エリア位置関係（１２３）を備え、該エリア位置関係（１２３）は、位置コードを、
該位置コードに対応するエリアがサービス放送エリアであるかどうかを示す属性と、
該位置コードに対応するエリアが位置する州の略号を備える属性と
のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、請求項１〜請求項７のうちのいずれかに記載の電子デバイス。
【請求項９】
前記第２の組の関係（１０１）は、イベントコードをイベントテキストと直接的または間接的に関連付けるイベント名称関係（１１１）を備え、該イベント名称関係（１１１）は、２つ以上の異なる言語において、該イベントテキストのためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該イベントテキストが提供される言語を識別する、請求項１および請求項３〜請求項８のうちのいずれかと、請求項２とに記載の電子デバイス。
【請求項１０】
前記第１の組の関係（１０２）は、位置コードを位置名称と直接的または間接的に関連付ける位置名称関係（１２１）を備え、該位置名称関係は、２つ以上の異なる言語において、該位置名称のためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該位置名称が提供される言語を識別する、請求項１〜請求項９のうちのいずれかに記載の電子デバイス。
【請求項１１】
前記イベント名称関係（１１１）または前記位置名称関係（１２１）は、それぞれ、対応する前記イベントテキストまたは前記位置名称の音素表現を検索するために、該イベントテキストまたは該位置名称を音素識別子とさらに関連付け、かつ／あるいは、それぞれ、対応する該イベントテキストまたは該位置名称の音響表現を検索するために、該イベントテキストまたは該位置名称を声音識別子とさらに関連付ける、請求項９または請求項１０に記載の電子デバイス。
【請求項１２】
前記第２の組の関係（１０１）は、イベント関係（１１０）を備え、該イベント関係（１１０）は、前記イベントコードを、
イベントコードと関連付けられたアイコン組を識別するアイコン組識別子と、
前記イベントの性質を識別するイベント性質と、
対応するＴＭＣメッセージの持続期間の決定のための情報を備える持続期間類型と、
該イベントが交通の一方向または両方向に関係するかどうかを示すデフォルト方向性と、
該イベントの緊急度を示すイベント緊急度と、
該交通イベントの深刻度を示す渋滞分類と、
該イベントの更新等級を識別する更新等級と、
該イベントと結合されることが許される数量詞の類型を示す数量詞類型と
のうちの少なくとも１つの属性またはこれら属性の組合せと直接的または間接的に関連付ける、請求項１および請求項３〜請求項１１のうちのいずれかと、請求項２とに記載の電子デバイス。
【請求項１３】
前記関係型データベース（２０）は、局リスト関係（１０３）をさらに備え、該局リスト関係（１０３）は、受信されたＴＭＣメッセージ中に含まれる国識別子を、
ＴＭＣメッセージを放送する送信者を示す送信者識別子と、
ラジオ番組を識別する番組識別子と、
該送信者が受信可能である地理的エリアを記述するタイル識別子と
のうちの少なくとも１つの属性またはこれら属性の組合せと関連付ける、請求項１〜請求項１２のうちのいずれかに記載の電子デバイス。
【請求項１４】
前記位置コードはＴＭＣ位置コードであり、前記電子デバイスは、ＴＭＣクライアントまたはＴＰＥＧクライアントとして動作するように構成されている、請求項１〜請求項１３のうちのいずれかに記載の電子デバイス。
【請求項１５】
交通情報クライアントとして動作するように構成された電子デバイス（１０）を動作させる方法であって、該電子デバイス（１０）は、交通情報メッセージを受信するためのインタフェース（１１）と、少なくとも第１の組の関係（１０２）を備える関係型データベース（２０）とを備え、該第１の組の関係（１０２）は、位置コードを位置情報と直接的または間接的に関連付ける少なくとも１つの関係（１２０、１２１）を含み、該方法は、
交通イベントの位置を識別する位置コードを備える交通情報メッセージを該インタフェース（１１）上で受信するステップと、
サーチ照会として該位置コードを使用して該関係型データベース（２０）を照会するステップと、
該位置コードと関連付けられた位置情報を該関係型データベース（２０）から検索するステップと
を包含する、方法。
【請求項１６】
前記電子デバイスは、請求項２〜請求項１４のうちのいずれかに従って構成されている、請求項１５に記載の方法。
【請求項１７】
電子的に可読なデータキャリアであって、該データキャリアは、該データキャリア上に格納された関係型データベースを備え、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、電子的に可読なデータキャリア。
【請求項１８】
前記関係型データベース（２０）は、請求項２〜請求項１４のうちのいずれかに従って構成されている、請求項１７に記載の電子的に可読なデータキャリア。
【請求項１】
交通情報クライアントデバイスとして動作するように構成されている電子デバイスであって、
交通情報メッセージを受信するように適応されているインタフェース（１１）であって、交通情報メッセージは、交通イベントの位置を識別する位置コードを備え得る、インタフェース（１１）と、
メモリ（１２）と、
該メモリに格納される関係型データベース（２０）であって、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、関係型データベース（２０）と、
処理ユニット（１３）であって、該関連付けられた位置情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信される位置コードで該関係型データベース（２０）を照会するように適応されている処理ユニット（１３）と
を備えている、電子デバイス。
【請求項２】
交通情報メッセージは、交通イベントを識別するイベントコードをさらに備え得、前記関係型データベースは、少なくとも１つの関係（１１０、１１１）を含む第２の組の関係（１０１）をさらに備え、該少なくとも１つの関係（１１０、１１１）は、イベントコードをイベント情報と直接的または間接的に関連付け、
前記処理ユニットは、該関連付けられたイベント情報を該関係型データベース（２０）から検索するために、交通情報メッセージと共に受信されるイベントコードで該関係型データベース（２０）を照会するように適応されている、請求項１に記載の電子デバイス。
【請求項３】
前記第１の組の関係は、複数のレコードを有する第１の関係（１２０）を備え、該複数のレコードは、異なる国々に対する位置コードを有し、異なる国々に対する該レコードは、同一の位置コードを備え得、該第１の関係は、該第１の関係の各レコードを一意の位置識別子と関連付ける属性を備える、請求項１または請求項２に記載の電子デバイス。
【請求項４】
前記第１の組の関係は、第１の関係（１２０）と、１つ以上の第２の関係（１２１、１２３、１２４、１２５）とを備え、該第１の関係（１２０）は、前記位置コードを、識別子、好ましくは、一意の位置識別子および／または位置名称識別子と関連付け、該１つ以上の第２の関係（１２１、１２３、１２４、１２５）は、それぞれ、特定の類型の位置情報に対して、該識別子を対応する該位置情報と関連付け、これによって、該第１の関係（１２０）は、該位置情報との間接的な関連付けを提供する、請求項１〜請求項３のうちのいずれかに記載の電子デバイス。
【請求項５】
前記１つ以上の第２の関係（１２１、１２２、１２３、１２４、１２５、１２６）は、
エリア位置情報を有するエリア位置関係（１２３）と、
区画位置情報を有する区画位置関係（１２４）と、
点位置情報を有する点位置関係（１２５）と、
位置名称情報を有する位置名称関係（１２１）と、
位置類型情報を有する位置類型関係（１２２）と、
座標情報を有する位置座標関係（１２６）と
のうちの少なくとも１つの関係を備える、請求項４に記載の電子デバイス。
【請求項６】
前記第１の関係（１２０）は、前記位置コードを位置分類識別子と関連付け、該位置分類識別子は、対応する位置がエリア位置、線状位置、または点位置であるかどうかを示し、
前記処理ユニット（１３）は、前記関係型データベース（２０）を照会することによって、受信された位置コードの位置分類を識別するように適応され、かつ、該識別された位置分類に依存して、サーチ照会として、該識別子、好ましくは前記一意の位置識別子を使用して、前記エリア位置関係（１２３）、前記区画位置関係（１２４）、または前記点位置関係（１２５）のいずれかから、さらなる位置情報を検索するように適応されている、請求項５に記載の電子デバイス。
【請求項７】
前記第１の関係（１２０）、前記区画位置関係（１２４）、および／または前記位置類型関係（１２２）は、各レコードを位置名称識別子と関連付ける属性を備え、前記位置名称関係（１２１）は、該位置名称識別子を位置名称と関連付けるレコードを備える、請求項５または請求項６に記載の電子デバイス。
【請求項８】
前記第１の組の関係（１０２）は、エリア位置関係（１２３）を備え、該エリア位置関係（１２３）は、位置コードを、
該位置コードに対応するエリアがサービス放送エリアであるかどうかを示す属性と、
該位置コードに対応するエリアが位置する州の略号を備える属性と
のうちの少なくとも１つまたは組合せと直接的または間接的に関連付ける、請求項１〜請求項７のうちのいずれかに記載の電子デバイス。
【請求項９】
前記第２の組の関係（１０１）は、イベントコードをイベントテキストと直接的または間接的に関連付けるイベント名称関係（１１１）を備え、該イベント名称関係（１１１）は、２つ以上の異なる言語において、該イベントテキストのためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該イベントテキストが提供される言語を識別する、請求項１および請求項３〜請求項８のうちのいずれかと、請求項２とに記載の電子デバイス。
【請求項１０】
前記第１の組の関係（１０２）は、位置コードを位置名称と直接的または間接的に関連付ける位置名称関係（１２１）を備え、該位置名称関係は、２つ以上の異なる言語において、該位置名称のためのレコードを備え、該関係は、言語コードを有する属性をさらに備え、該言語コードは、各レコードにおいて該位置名称が提供される言語を識別する、請求項１〜請求項９のうちのいずれかに記載の電子デバイス。
【請求項１１】
前記イベント名称関係（１１１）または前記位置名称関係（１２１）は、それぞれ、対応する前記イベントテキストまたは前記位置名称の音素表現を検索するために、該イベントテキストまたは該位置名称を音素識別子とさらに関連付け、かつ／あるいは、それぞれ、対応する該イベントテキストまたは該位置名称の音響表現を検索するために、該イベントテキストまたは該位置名称を声音識別子とさらに関連付ける、請求項９または請求項１０に記載の電子デバイス。
【請求項１２】
前記第２の組の関係（１０１）は、イベント関係（１１０）を備え、該イベント関係（１１０）は、前記イベントコードを、
イベントコードと関連付けられたアイコン組を識別するアイコン組識別子と、
前記イベントの性質を識別するイベント性質と、
対応するＴＭＣメッセージの持続期間の決定のための情報を備える持続期間類型と、
該イベントが交通の一方向または両方向に関係するかどうかを示すデフォルト方向性と、
該イベントの緊急度を示すイベント緊急度と、
該交通イベントの深刻度を示す渋滞分類と、
該イベントの更新等級を識別する更新等級と、
該イベントと結合されることが許される数量詞の類型を示す数量詞類型と
のうちの少なくとも１つの属性またはこれら属性の組合せと直接的または間接的に関連付ける、請求項１および請求項３〜請求項１１のうちのいずれかと、請求項２とに記載の電子デバイス。
【請求項１３】
前記関係型データベース（２０）は、局リスト関係（１０３）をさらに備え、該局リスト関係（１０３）は、受信されたＴＭＣメッセージ中に含まれる国識別子を、
ＴＭＣメッセージを放送する送信者を示す送信者識別子と、
ラジオ番組を識別する番組識別子と、
該送信者が受信可能である地理的エリアを記述するタイル識別子と
のうちの少なくとも１つの属性またはこれら属性の組合せと関連付ける、請求項１〜請求項１２のうちのいずれかに記載の電子デバイス。
【請求項１４】
前記位置コードはＴＭＣ位置コードであり、前記電子デバイスは、ＴＭＣクライアントまたはＴＰＥＧクライアントとして動作するように構成されている、請求項１〜請求項１３のうちのいずれかに記載の電子デバイス。
【請求項１５】
交通情報クライアントとして動作するように構成された電子デバイス（１０）を動作させる方法であって、該電子デバイス（１０）は、交通情報メッセージを受信するためのインタフェース（１１）と、少なくとも第１の組の関係（１０２）を備える関係型データベース（２０）とを備え、該第１の組の関係（１０２）は、位置コードを位置情報と直接的または間接的に関連付ける少なくとも１つの関係（１２０、１２１）を含み、該方法は、
交通イベントの位置を識別する位置コードを備える交通情報メッセージを該インタフェース（１１）上で受信するステップと、
サーチ照会として該位置コードを使用して該関係型データベース（２０）を照会するステップと、
該位置コードと関連付けられた位置情報を該関係型データベース（２０）から検索するステップと
を包含する、方法。
【請求項１６】
前記電子デバイスは、請求項２〜請求項１４のうちのいずれかに従って構成されている、請求項１５に記載の方法。
【請求項１７】
電子的に可読なデータキャリアであって、該データキャリアは、該データキャリア上に格納された関係型データベースを備え、該関係型データベース（２０）は、少なくとも１つの関係（１２０、１２１）を含む、少なくとも第１の組の関係（１０２）を備え、該少なくとも１つの関係（１２０、１２１）は、位置コードを位置情報と直接的または間接的に関連付ける、電子的に可読なデータキャリア。
【請求項１８】
前記関係型データベース（２０）は、請求項２〜請求項１４のうちのいずれかに従って構成されている、請求項１７に記載の電子的に可読なデータキャリア。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図２】
【図３】
【図４】
【図５】
【図６】
【公開番号】特開２０１１−２４８８６４（Ｐ２０１１−２４８８６４Ａ）
【公開日】平成２３年１２月８日（２０１１．１２．８）
【国際特許分類】
【出願番号】特願２０１１−８４０８９（Ｐ２０１１−８４０８９）
【出願日】平成２３年４月５日（２０１１．４．５）
【出願人】（５０４１４７９３３）ハーマン ベッカー オートモーティブ システムズ ゲーエムベーハー (165)
【Ｆターム（参考）】
【公開日】平成２３年１２月８日（２０１１．１２．８）
【国際特許分類】
【出願日】平成２３年４月５日（２０１１．４．５）
【出願人】（５０４１４７９３３）ハーマン ベッカー オートモーティブ システムズ ゲーエムベーハー (165)
【Ｆターム（参考）】
[ Back to top ]