JP2017058948A - 情報処理装置、プログラム、情報処理システム、データ構造 - Google Patents

Abstract

【課題】システムや開発コストの増大を抑制して多言語に対応可能な情報処理装置を提供すること。
【解決手段】目的地までの経路を案内する音声データを端末に配信する情報処理装置３１であって、前記端末から言語の指定と共に前記音声データの要求を取得する取得手段４１ｂと、言語ごとに、案内文章の識別情報に前記案内文章に含まれる１つ以上の文の識別情報が対応づけられた第一の案内文章情報１０２を記憶し、さらに、前記文の前記識別情報に対応づけられた前記文の前記音声データを記憶する記憶手段４９０から、前記取得手段が取得した言語の前記第一の案内文章情報及び前記音声データを読み出す読出手段４９と、前記読出手段が読み出した前記第一の案内文章情報及び前記音声データを前記端末に送信する送信手段４１ａと、有する。
【選択図】図１

Description

本発明は、情報処理装置、プログラム、情報処理システム及びデータ構造に関する。

目的地までの経路を地図に重ねて表示したり、交差点などの手前の案内ポイントにユーザが到達すると案内音声により経路を案内したりするナビゲーションシステムが知られている。このような案内音声においては、ナビゲーションシステムのユーザの母国語が様々であることから、案内音声の多言語化が進められている。これにより、例えば、日本のユーザは日本語の案内音声で案内され、日本を旅行中の外国人は英語で案内されることができる。

このように案内音声の多言語化が進んでいるが、各国の言語の音声データを用意すると音声データにより記憶容量が圧迫されるおそれがある。このため、音声データを外部記憶装置に記憶させておくナビゲーションシステムが考案されている（例えば、特許文献１参照）。特許文献１には、出力単位ごとに異なる指定コードを音声データに付与しておき、外部記憶装置に対し指定コードを出力して、指定コードに対応づけられた音声データを取得するナビゲーションシステムが開示されている。

特開２００７−３２２３０８号公報

しかしながら、従来のナビゲーションシステムでは、案内音声に関するロジック（案内ポイントを判定したり適切な案内音声を組み立てる処理）を言語ごとに開発する必要があるため、言語の追加によるシステムの肥大化や開発コストの増大をもたらすという問題がある。

例えば、案内ポイントの１つに経路案内を開始する案内ポイントがある。経路案内を開始する場合、日本語のナビゲーションシステムでは、経路案内を開始する案内ポイントであることを判定して「案内を開始します。交通規則にしたがって運転してください。」という案内音声を出力するロジックを開発者等が開発する。また、英語のナビゲーションシステムでは、経路案内を開始する案内ポイントであることを判定して「Now starting navigation. Please obey all traffic regulations while driving.」という案内音声を出力するロジックを開発者等が開発する。

このように、案内ポイントが同じでも言語ごとに案内音声のフレーズを組み立てるロジックを開発する必要がある。したがって、多言語化を進めると、案内ポイントを判定して適切な案内音声を組み立てるロジックが言語の数だけ必要になることでシステムが肥大化したり、開発コストの増大をもたらすおそれがある。

本発明は、上記課題に鑑み、システムや開発コストの増大を抑制して多言語に対応可能な情報処理装置を提供することを目的とする。

上記課題に鑑み、本発明は、目的地までの経路を案内する音声データを端末に配信する情報処理装置であって、前記端末から言語の指定と共に前記音声データの要求を取得する取得手段と、言語ごとに、案内文章の識別情報に前記案内文章に含まれる１つ以上の文の識別情報が対応づけられた第一の案内文章情報を記憶し、さらに、前記文の前記識別情報に対応づけられた前記文の前記音声データを記憶する記憶手段から、前記取得手段が取得した言語の前記第一の案内文章情報及び前記音声データを読み出す読出手段と、前記読出手段が読み出した前記第一の案内文章情報及び前記音声データを前記端末に送信する送信手段と、有する。

システムや開発コストの増大を抑制して多言語に対応可能な情報処理装置を提供することができる。

ナビゲーションシステムの概略的な構成を説明する図の一例である。 ナビゲーションシステムのシステム構成図の一例である。 サーバ及び端末のハードウェア構成図の一例である。 ナビゲーションシステムの階層構造を示す図の一例である。 ナビゲーションシステムが備える各機能を図示した機能ブロック図の一例である。 案内音声定義ＤＢに含まれる各種のテーブル及びファイルを模式的に示す図の一例である。 端末が音声管理ファイル等をダウンロードする手順を示すシーケンス図の一例である。 端末の表示装置に表示された言語設定画面の一例を示す図である。 端末が音声で案内するまでの処理手順を説明する図の一例である。

以下、本発明を実施するための形態を、図面を参照しながら説明する。
図１は、本実施形態のナビゲーションシステム１００の概略的な構成を説明する図の一例である。ナビゲーションシステム１００は種々の言語に対応した音声管理ファイル１０１を有している。そして、この音声管理ファイル１０１には各言語のフレーズ組立定義テーブル１０２、語順テーブル１０４及び音声データ３０１が含まれていることが特徴の１つとなっている。
（１）まず、ユーザは案内音声に用いられる言語（日本語、英語など）を選択することができる。
（２）ナビゲーションシステム１００に対応した端末を携帯する歩行者や端末を搭載した車両が案内ポイントに到達すると、案内パターンが決定される。例えば、「ルート案内開始」「ナビ終了」「リルート」などの案内パターンが予め定められている。案内パターンが決定されると、フレーズ組立定義テーブル１０２に登録されているフレーズコードが決定される。フレーズコードはフレーズを特定する番号などである。フレーズ組立定義テーブル１０２にはフレーズコードと１つ以上の語順ＩＤが対応付けられている。したがって、フレーズコードにより、例えばフレーズが「語順１と語順２」により構成されることが特定される。
（３）語順テーブル１０４には語順ＩＤと音声ＩＤが対応付けられている。したがって、語順が決定されると、語順テーブル１０４に登録されている音声ＩＤ（図１の音声１〜４）が決定される。音声ＩＤは音声データを特定する番号などである。
（４）ナビゲーションシステム１００は、特定された音声１、２，３、４を音声データ３０１から取得して語順にしたがって読み上げる。

上記の概略について補足する。まず、言語が異なっても案内ポイントは言語に関わらず同じである。したがって、ナビゲーションシステム１００では、同じ案内ポイントに同じフレーズコードを割り当てることができる。

また、ある案内ポイントにおけるフレーズは言語が異なってもある程度のパターン化が可能である。例えば、案内パターンが「１．ルート案内開始」の場合、日本語では「２．案内を開始します。」「交通規則にしたがって運転してください。」であり、英語では「a. Now starting navigation.」「b. Please obey all traffic regulations while driving.」である。したがって、１とa、２とｂにそれぞれ同じ語順ＩＤを付与しフレーズコードと関連づけておけば、言語が異なってもフレーズコードと語順ＩＤの対応を同じにすることができる。

一方、言語が異なると文法などが異なるため、細部の案内音声が異なる場合がある。そこで、言語が異なってもフレーズコードは同じまま、語順ＩＤに対応付けられた音声ＩＤで調整する。すなわち、フレーズ組立定義テーブル１０２に音声データが直接登録されるのでなく、語順ＩＤが登録されていることで、細部の案内音声の相違を吸収できる。

この結果、言語が異なっても発話フレーズを決定する際のロジック（案内ポイントの判定とフレーズコードの対応付け）をほぼ共通にすることができシステムの肥大化を抑制できる。また、開発段階では、細部の異なる案内内容だけ調整すればよいためコスト増も抑制できる。

＜システム構成例＞
図２（ａ）は、本実施例にかかるナビゲーションシステム１００のシステム構成図の一例である。ナビゲーションシステム１００は、ネットワーク３４を介して通信可能に接続されたサーバ３１及び端末３５を有している。ネットワーク３４は、例えば、ＬＡＮ、広域範囲の複数のＬＡＮが接続されたＷＡＮ、及び、インターネットなどである。ネットワーク３４は有線のみ又は無線のみで構築されていてもよいし、有線と無線とで構築されていてもよい。また、ネットワーク３４にはアクセスポイントなどの基地局３２が接続されており、端末３５は無線で基地局３２にアクセスすることでネットワーク３４に接続する。端末３５は携帯電話網や無線ＬＡＮなどの主に無線で構築される通信網を介して基地局３２と通信する。

サーバ３１は、端末３５に対し、ナビゲーションに関するサービス・機能を提供する。例えば、端末３５から現在位置の位置情報と目的地を取得して経路を検索し、後述する経路情報と電子地図やメニューなどの各種アイコンを含むナビ画面を端末３５に送信する。

ネットワーク３４には符号３５にて示す端末１〜Ｎが接続され得る。端末１〜Ｎを区別せずに説明する場合は端末３５と称する。例えば、端末１を自分であるユーザが使用し、端末２〜Ｎを相手が使用する。

図２（ｂ）に示す用に、端末３５は、汎用的な情報処理端末３５１である場合とナビゲーション専用端末３５２の場合がある。ナビゲーション専用端末３５２はＰＮＤ（Portable Navigation Device）とも呼ばれる。なお、本実施例の端末３５は、情報処理端末３５１又はナビゲーション専用端末３５２以外でもよい。

情報処理端末３５１としての端末３５は、例えば、スマートフォン、タブレット端末、携帯電話、ＰＤＡ（Personal Digital Assistant）、ノートＰＣ、及び、ウェアラブルＰＣ（例えば、腕時計型、サングラス型など）などである。情報処理端末３５１はこれらに限定されるものではなく、ナビ画面の表示や経路案内に適切な装置であればよい。これらの装置は、普段は情報処理端末として利用されるが、ナビゲーションのためのアプリケーションソフトウェアを実行すると、ナビゲーション専用端末３５２と同様、経路検索及び経路案内等を行う。

また、端末３５は、汎用的な情報処理端末３５１とナビゲーション専用端末３５２のどちらの場合でも、車載された状態と携帯可能な状態の切り替えが可能であってもよい。

端末３５の動作態様には大きく２つある。１つは、端末３５が例えば専用のアプリケーションソフトウェアやＷｅｂブラウザを起動してサーバ３１と通信し、経路案内に関する情報を受信して表示するクライアント型の動作態様である。もう１つは、原則的に地図の描画などの処理を端末内で完結し、地図データの取得など必要な場合にのみサーバ３１と通信するアプリケーション型の動作端末である。本実施例では、クライアント型を例に説明するが、アプリケーション型に対しても本実施例のナビゲーションシステム１００を好適に適用できる。

なお、ユーザは２台の端末３５を用いて、ナビゲーションシステム１００を利用してもよい。例えば、ノートＰＣなどの端末３５でドライブポータルサイトにアクセスして、出発地から目的地までの経路を事前に検索しておく。ドライブポータルサイトは、運転者（ドライバ）のための情報サービスサイトである。検索された経路はドライブポータルサイトに登録しておき、任意のタイミングでスマートフォンなどの端末３５から登録されている経路情報をダウンロードする。このような使い方により、ユーザは予め経路を事前に検索しておくことができ、出発前の端末３５の操作を少なくできる。

＜ハードウェア構成＞
図３は、サーバ３１及び端末３５のハードウェア構成図の一例である。サーバ３１及び端末３５は情報処理装置の機能を有している。図３（ａ）に示すように、サーバ３１は、ハードウェア構成として、ＣＰＵ（Central Processing Unit）２１１、ＲＯＭ（Read Only Memory）２１５、ＲＡＭ（Random Access Memory）２１６、補助記憶装置２１７、入力装置２１２、表示装置２１３、及び、通信装置２１４を有する。

また、図３（ｂ）に示すように、端末３５は、ハードウェア構成として、ＣＰＵ２１１、ＲＯＭ２１５、ＲＡＭ２１６、補助記憶装置２１７、入力装置２１２、表示装置２１３、通信装置２１４、音声入出力装置２１８、及び、ＧＰＳ受信装置２１９を有する。

ＣＰＵ２１１は、各種プログラムの実行や演算処理を行う。ＲＯＭ２１５には、起動時に必要なプログラムなどが記憶されている。ＲＡＭ２１６は、ＣＰＵ２１１での処理を一時的に記憶したり、データを記憶したりする作業エリアである。補助記憶装置２１７は、各種データ及びプログラム２１０１、２１０２を格納する不揮発性のメモリである。入力装置２１２は、例えばキーボードやマウスである。表示装置２１３は、ディスプレイやプロジェクタ、ＨＵＤ（Ｈｅａｄ Ｕｐ Ｄｉｓｐｌａｙ）であり、例えば、ナビ画面等が表示される。通信装置２１４は、基地局３２を介してネットワーク３４に接続しサーバ３１等との通信を行う。音声入出力装置２１８は、音声の入出力を行う装置であり、例えば、経路案内の音声を読み上げる際に使用される。ＧＰＳ受信装置２１９は、ＧＰＳ衛星の電波を受信して現在位置を算出するＧＮＳＳ（Global Navigation Satellite System）の一例である。

なお、端末３５の入力装置２１２は、キーボードやマウスに代え又はこれらに加えて、画面に対する接触位置（タッチ座標）を検知可能なタッチパネルにより実現されうる。また、入力装置２１２は、音声入出力装置２１８が入力させた音声を認識する音声認識装置としての機能を有していてもよい。

サーバ３１又は端末３５の補助記憶装置２１７に記憶されているプログラム２１０１，２１０２は、ＵＳＢメモリなどの記憶媒体に記憶された状態で配布される。あるいは、プログラムを配布する配信サーバから端末３５がダウンロードすることで配布される。端末３５のプログラム２１０２は、経路案内に専用のアプリケーションソフトウェアでもよいし、ブラウザソフトウェアでもよい。また、実行形式で配布されてもインストール用の形式で配布されてもよい。

なお、サーバ３１にはクラウドコンピューティングが適用されていることが好ましい。クラウドコンピューティングの物理的な構成に厳密な定義はないが、情報処理装置を構成するＣＰＵ、ＲＡＭ、ストレージなどのリソースが負荷に応じて動的に接続・切断されることで情報処理装置の構成や設置場所が柔軟に変更されてよい。また、クラウドコンピューティングでは、サーバ３１が仮想化されることが一般的である。一台の情報処理装置が仮想化によって複数のサーバ３１としての機能を提供することや、複数の情報処理装置が仮想化によって一台のサーバ３１としての機能を提供することができる。

したがって、図示したサーバ３１のハードウェア構成は、１つの筐体に収納されていたり一まとまりの装置として備えられていたりする必要はなく、サーバ３１が備えていることが好ましいハード的な要素を示す。なお、サーバ３１がクラウドコンピューティングとしてではなく単独の情報処理装置により提供されることも可能である。

＜ナビシステムの階層＞
図４は、本実施形態のナビゲーションシステム１００の階層構造を示す図である。ナビゲーションシステム１００は、主にデータ層４０１、エンジン層４０２、ＵＩ層４０３の３つの階層を有している。データ層４０１には例えば地図データ、音声管理ファイル、検索データ等が配置される。地図データは地図を描画するためのデータであり、音声管理ファイルは図１で説明した案内音声のためのテーブルや音声データなどであり、検索データは施設、電話番号、住所などのＰＯＩ（Point Of Interest）のデータである。

エンジン層４０２には地図描画エンジン、経路・案内エンジン、検索エンジンなどが含まれる。エンジン層４０２はＵＩ層４０３から処理に必要な情報を取得し、データ層４０１のデータを使用して地図描画、経路の検索・案内、ＰＯＩの検索等を行い、ＵＩ層４０３に出力する。

ＵＩ層４０３は、ユーザインタフェースとなる層であり、表示装置２１３への地図表示、検索結果に基づく案内音声の出力、出発地や目的地など各種設定の受け付け等を行う。

このように階層が区分されていることで、ナビゲーションシステム１００のサービス提供者はナビゲーションシステム１００を柔軟に構築することが可能になる。例えば、「a. データ層４０１とエンジン層４０２をクラウド側に設置しＵＩ層４０３を端末側に搭載する」、「b.データ層４０１のみをクラウド側に設置しエンジン層４０２とＵＩ層４０３を端末側に搭載する」、「c.データ層４０１、エンジン層４０２及びＵＩ層４０３を一台の情報処理装置に搭載する」、というような構成が可能である。

本実施形態ではａの構成に基づいて説明するが、ナビゲーションシステム１００の構成はｂ、ｃを含め柔軟に構成できる。

＜経路表示システムの機能構成例＞
図５は、本実施例のナビゲーションシステム１００が備える各機能を図示した機能ブロック図の一例である。

<<サーバの機能構成>>
サーバ３１は、サーバ送受信部４１、経路検索部４２、ナビ画面作成部４３、及び、記憶・読出処理部４９を有している。これらの各機能は図３（ａ）に示したＣＰＵ２１１がプログラム２１０１を実行してサーバ３１のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

また、サーバ３１は、図３（ａ）に示した補助記憶装置２１７、ＲＯＭ２１５又はＲＡＭ２１６により構築される記憶部４９０を有している。記憶部４９０には、地図ＤＢ４９１、道路ネットワークＤＢ４９２、歩行者ネットワークＤＢ４９３、及び、案内音声定義ＤＢ４９４が構築されている。これらの各データベース（ＤＢ）は、サーバ３１が直接有していなくてもよく、サーバ３１がアクセス可能なネットワーク３４上の任意の場所にあればよい。

まず、各データベースについて説明する。
地図ＤＢ４９１は、電子地図を描画するための地図データを記憶している。電子地図に表示される情報には、都道府県などの区画、緑地や河川、道路や鉄道、記号や注記など多くの表示対象があるため、性質の似たものに分類し各分類ごとに描画できるようになっている。それぞれに分類された表示対象又は表示対象が描画された状態をレイヤーといい、電子地図はいくつかのレイヤーを重ねることで描画される。各レイヤーの地図データは、ベクトルデータ又はラスターデータのうち表示対象に適したフォーマットで記述されている。また、地図データは経度・緯度などが既知のメッシュ状に区切られており、１つ以上のメッシュを結合してナビ画面が作成される。ベクトルデータの場合は、緯度・経度でポイント、ポリライン、ポリゴンの位置が定められている。また、ラスターデータの場合は緯度・経度に対応づけて縮尺に応じたデータが用意されている。

表１は道路ネットワークＤＢの構成を模式的に示す。道路ネットワークＤＢ４９２は、車両が通行可能な道路の構造を表すデータであって、表１（ａ）のノードテーブルと表１（ｂ）のリンクテーブルとを有している。ノードテーブルには、ノードを識別するためのノードＩＤとノードの座標（緯度・経度）が登録されている。ノードとは道路網表現上の結節点である。ノードは例えば交差点、分岐点、合流点、屈曲点などである。

また、リンクテーブルにはリンクを識別するためのリンクＩＤ、リンクの始点ノード、リンクの終点ノード、道路種別などが登録されている。この他、幅員、リンク長などが登録されてよい。リンクとはノードとノードを結ぶ道路をいい、リンクはノード同士を結ぶ線分となる。道路種別は、例えば一般道、高速道路、専用道路、私道などである。ノードＩＤが分かればノードに繋がっているリンクがリンクテーブルから判明するので、ノードテーブルとリンクテーブルを相互に参照することで道路を検索できる。

歩行者ネットワークＤＢ４９３は、ノードテーブルとリンクテーブルとを有する点で道路ネットワークＤＢ４９２と同様である。ただし、歩行者ネットワークＤＢ４９３には、歩行者が通行可能な道（歩道、横断歩道、歩道橋、地下道、通り抜け可能な通路など）のリンクと、リンクの始点と終点のノード等が登録されている。

表２（ａ）は案内音声定義ＤＢ４９４に記憶されているフレーズ組立定義テーブル１０２を模式的に示す。フレーズ組立定義テーブル１０２には、フレーズコードｆｎ（ｎは自然数）に対応づけてフレーズ内容が登録されている。フレーズ内容は１つ以上の文を含む文章である。案内ポイントではこのフレーズ内容が読み上げられる。フレーズコードｆｎはフレーズ内容を識別する識別情報であり、フレーズ内容は語順ＩＤとその順番を定義する。なお、語順ＩＤは"seq"と1つ以上の数値の組み合わせで表される。語順ＩＤは、１つ以上の音声ＩＤと対応しており、音声ＩＤが示す音声データの読み上げ順を規定する。

表２（ａ）のフレーズ組立定義テーブル１０２は、英語の音声で案内される場合のものである。しかし、後述されるように日本語の場合のフレーズ組立定義テーブル１０２も同様になる。

表２（ｂ）は案内音声定義ＤＢ４９４に記憶されている案内条件テーブル１０３を模式的に示す。案内条件テーブル１０３には語順ＩＤに対応づけて案内条件と必須かどうかが登録されている。案内条件は語順ＩＤで特定される案内音声をナビゲーションシステム１００が読み上げるための条件である。必須の欄には必須の場合に"○"が、必須でない場合に"×"がそれぞれ登録されている。なお、表２（ｂ）のオフロード道とは、道路がない地域（砂漠や原野やなど）を走行することを意味している。

表２（ｃ）は案内音声定義ＤＢ４９４に記憶されている語順テーブル１０４を模式的に示す。語順テーブル１０４には語順ＩＤに対応づけて音声ＩＤが登録されている。音声ＩＤは音声データを識別するための識別情報である。語順ＩＤに音声ＩＤが対応づけられることで、ナビゲーションシステム１００は案内ポイントで読み上げる音声データを特定できる。語順ＩＤは主に１つの文を特定するための識別情報であり、音声ＩＤは文、句、又は単語を特定するための識別情報である。

フレーズ組立定義テーブル１０２と語順テーブル１０４が語順ＩＤにより関連づけられることで、フレーズ組立定義テーブル１０２は言語が異なっても同じか又はほぼ同じにすることができ、言語間の違いを語順テーブル１０４で受け持つことができる。フレーズ組立定義テーブル１０２が各言語に共通であれば、フレーズコードを決定するためのロジックも言語間で同じか又はほぼ同じにすることができる。

表２（ｄ）は案内音声定義ＤＢ４９４に記憶されている音声データテーブルを模式的に示す。音声データテーブルには音声ＩＤに対応づけて案内テキスト、意味、音声データが登録されている。案内テキストは、案内音声に用いられる最小単位の文字列（文、句、又は単語）である。

なお、表２（ｄ）の「意味」は説明の便宜のために示されたものであり、ナビゲーションシステム１００が有していなくてもよい。また、音声データはｗａｖファイルのファイル名を示している。音声データのファイルはｍｐ３などの他の音楽フォーマットでもよい。

表２（ｄ）の音声データテーブルに示すように、音声ＩＤにより音声データが特定されるため、ナビゲーションシステム１００は音声データを読み上げることができる。

（サーバ３１の機能について）
続いて、サーバ３１が有する機能について説明する。サーバ送受信部４１は送信部４１ａと受信部４１ｂを有している。サーバ送受信部４１は、図３（ａ）のＣＰＵ２１１及び通信装置２１４等により実現され、受信部４１ｂは端末３５からナビゲーションに関する種々の要求を受け付ける。この要求には、例えば、目的地までの検索要求、ナビ画面の更新要求（拡大・縮小、表示範囲の変更など）がある。これらの要求は、ナビ画面作成部４３及び経路検索部４２に振り分けられる。また、サーバ送受信部４１の送信部４１ａは経路情報やナビ画面を端末３５に送信する。

経路検索部４２は、図３（ａ）のＣＰＵ２１１等により実現され、検索要求に対し道路ネットワークＤＢ４９２又は歩行者ネットワークＤＢ４９３の少なくとも一方を用いて経路を検索し経路情報を作成する。経路検索には、リンク長や幅員、渋滞状況をコストに換算して、出発地から目的地までのコストの合計が最も少なくなる経路を選ぶダイクストラ法が知られている。なお、ダイクストラ法以外の検索方法が用いられてもよい。経路情報には案内ポイントが含まれている。

ナビ画面作成部４３は、図３（ａ）のＣＰＵ２１１等により実現され、２点を包含する領域を含み、経路及び２点（例えば出発地及び目的地）が強調表示されたナビ画面を作成する。なお、ナビ画面は経路を含めＧＩＦやＪｐｅｇなどの画像データとして作成される場合と、画像データとしての電子地図とプログラムコードとして記述された経路情報とに分けて作成される場合がある。

後者の場合、経路の描画は端末３５が行う。サーバ３１のナビ画面作成部４３は経路を描画するためのプログラムコードを生成して端末３５に送信し、端末３５がプログラムコードを実行することでナビ画面に経路を描画できる。このようなプログラムコードとしてはＨＴＭＬと共に送信されるJavascript（登録商標）が知られている。

ナビ画面はさらに、ユーザの現在位置を表示してもよい。また、ユーザが移動を開始すると、ナビ画面作成部４３は案内に適した縮尺のナビ画面を作成する。また、端末３５から更新要求を取得すると、ナビ画面作成部４３は要求された縮尺や表示範囲に応じてナビ画面を作成する。サーバ送受信部４１はこのようにして作成された経路情報とナビ画面を端末３５に送信する。

記憶・読出処理部４９は、図３（ａ）のＣＰＵ２１１、ＲＯＭ２１５、ＲＡＭ２１６及び補助記憶装置２１７等により実現され、記憶部４９０に各種データを記憶したり、記憶部４９０に記憶された各種データを読み出す処理を行う。

<<端末の機能構成>>
続いて端末３５の機能又は手段について説明する。端末３５は、端末送受信部５１、操作受付部５２、位置検出部５３、経路案内部５４、ナビ画面表示部５５、及び、記憶・読出処理部５９を有している。これらは、図３（ｂ）に示したＣＰＵ２１１がプログラム２１０２を実行して端末３５のハードウェアと協働することで実現される機能又は手段である。これらの機能の一部又は全てがＩＣなどのハードウェア回路により実現されてもよい。

また、端末３５は、図３（ｂ）に示した補助記憶装置２１７、ＲＯＭ２１５又はＲＡＭ２１６により構築される記憶部５９０を有している。記憶部５９０には、案内パターン管理ＤＢ５９１が構築されている。案内パターン管理ＤＢ５９１は、端末３５が直接有していなくてもよく、端末３５がアクセス可能なネットワーク３４上の任意の場所にあればよい。

表３は案内パターン管理ＤＢ５９１に記憶されている案内管理テーブルを模式的に示す。案内管理テーブルには、案内パターン、条件及びフレーズコードが対応づけて登録されている。案内パターンは案内音声が出力されるいくつかのパターンである。案内パターンは説明のために示されており、案内パターン管理ＤＢ５９１が実際に保持していなくてもよい。条件は、フレーズコードを特定するための状況である。例えば、ユーザがある経路におけるナビを開始する操作を行うと、端末３５の操作受付部５２が操作を受け付け、表３の「ナビ開始時」の条件が成立する。そして、この場合はフレーズコードとしてｆ１が特定される。

なお、表３の案内管理テーブルは説明のために示したものであり、案内管理テーブルはプログラム２１０２のプログラムコードに含まれている場合が多い。したがって、案内管理テーブルは表３のように独立した形式で存在しない場合がある。案内管理テーブル又はプログラムコードはサーバ３１から端末３５がダウンロードしてもよいし、予め端末３５が保持していてもよい。

（端末３５の機能について）
続いて、端末３５が有する機能について説明する。端末送受信部５１は、図３（ｂ）のＣＰＵ２１１及び通信装置２１４等により実現され、サーバ３１に検索要求及び更新要求を送信したり、サーバ３１からナビ画面や経路情報を受信したりする。

操作受付部５２は、図３（ｂ）のＣＰＵ２１１及び入力装置２１２等により実現され、ユーザから、言語の指定、経路検索のためのＰＯＩや検索方法の入力、拡大・縮尺の指示、及び、表示範囲変更などの指示を受け付ける。

位置検出部５３は、図３（ｂ）のＣＰＵ２１１及びＧＰＳ受信装置２１９等により実現され、定期的に及びユーザの操作に応じて現在位置を検出する。検出した現在位置は端末送受信部５１からサーバ３１に送信される。

経路案内部５４は、図３（ｂ）のＣＰＵ２１１等により実現され、サーバ３１から取得した経路情報と現在位置とに基づいて音声管理ファイル１０１や案内パターン管理ＤＢ５９１を参照し案内音声を出力する。次述するように音声管理ファイル１０１は端末３５にダウンロードされている。経路案内部５４は、ユーザの状況が案内管理テーブルの条件を満たすか否かを判定し、満たす場合には条件に対応するフレーズコードを特定し、さらにフレーズコードに対応した語順ＩＤ、音声ＩＤを特定する。これにより、例えば案内ポイントに到達すると、曲がり角などを指示する音声データを音声入出力装置２１８に出力させる。

ナビ画面表示部５５は、図３（ｂ）のＣＰＵ２１１等により実現され、サーバ３１から受信したナビ画面を表示装置２１３に表示する。また、位置検出部５３が検出した現在位置を経路上に補正して（ルートマッチングして）、ユーザの現在位置としてナビ画面に合成する。経路情報が検索されていない状態では、道路や道などユーザが存在するはずのリンク上に現在位置を補正するマップマッチングを行う。なお、ルートマッチング又はマップマッチングはサーバ３１が行ってもよい。

記憶・読出処理部５９は、記憶部５９０に各種データを記憶したり、記憶部５９０に記憶された各種データを読み出す処理を行う。

＜多言語に対応した音声管理ファイルと端末３５へのダウンロード＞
図６は、端末３５への音声管理ファイル１０１のダウンロードを模式的に説明する図の一例である。図６（ａ）は、案内音声定義ＤＢ４９４に含まれる各種のテーブル及びファイルを模式的に示す図の一例である。案内音声定義ＤＢ４９４は、１つの言語定義ファイル１０７、ナビゲーションシステム１００が対応している言語の数と同じ数の表示テキストファイル１０８、及び、ナビゲーションシステム１００が対応している言語の数と同じ数の音声管理ファイル１０１を有している。

言語定義ファイル１０７には、ナビゲーションシステム１００が対応している言語、及び、キャラクタボイスの一覧（リスト）が定義されている。言語定義ファイル１０７は、ナビゲーションシステム１００が新たな言語に対応するごとに更新される。端末３５はサーバ３１から言語定義ファイル１０７が更新された旨の通知を取得し表示装置２１３に表示する。この画面例については図８にて説明する。なお、キャラクタボイスとは、音声データの属性である。属性には例えば、男性の音声、女性の音声等が挙げられるがこれには限られない。

表示テキストファイル１０８は、言語ごとに、表示装置２１３の画面のタイトル、メニューなどを表示するテキスト（文字、アルファベット、記号、数字等）が記述されたファイルである。したがって、音声データだけでなく、表示装置２１３の画面の文字などもユーザが所望する言語で表示される。

音声管理ファイル１０１は、上記したフレーズ組立定義テーブル１０２、案内条件テーブル１０３、語順テーブル１０４、音声データテーブル１０５、及び、音声データ一式１０６を関連づけるファイル（したがって、音声管理ファイル１０１はテーブル等がひとつにまとめられた圧縮ファイル又は実際にはフォルダやディレクトリでもよい）である。１つの音声管理ファイル１０１が１つの言語に対応している。音声データ一式１０６は、１つの言語分の音声データの集合である（各案内ポイントで読み上げられるフレーズの集合）。音声管理ファイル１０１が複数の音声データ一式１０６を有しているのは、異なるキャラクタボイスに対応するためである。したがって、男性が話す英語の音声データ一式１０６、女性が話す英語の音声データ一式１０６などが提供され得る。音声データ一式１０６は１つでもよい。

<<ファイル名について>>
続いて、案内音声定義ＤＢ４９４のファイル又はテーブルのファイル名と、端末３５にダウンロードされるファイルについて説明する。図６（ｂ）は端末３５の補助記憶装置２１７に構築されるファイル構造を示している。

言語定義ファイル１０７は例えばLangType.jsonというファイル名で端末３５の補助記憶装置２１７に記憶される。表示テキストファイル１０８はDisplaｙというファイル名で端末３５の補助記憶装置２１７に記憶されている。フレーズ組立定義テーブル１０２、案内条件テーブル１０３、語順テーブル１０４及び音声データテーブル１０５は例えばen_f.jsonというファイル名（以下、en_f.jsonを音声管理ファイル１０１のファイル名と称す）で端末３５の補助記憶装置２１７に記憶される。そして、音声データ一式１０６はen_fというフォルダに記憶されている。

なお、音声管理ファイル１０１のファイル名は以下のような規則で付与される。
言語コード＋"−"＋エリアコード＋"_"＋キャラクタコード
言語コードは言語を指定する識別情報であり、言語コードは国際基準ＩＳＯ６３９−１（２文字コード）に準ずるものとする。例えば、英語の言語コードは「en」、日本語の言語コードは「ja」、中国語の言語コードは「zh」である。

エリアコードとは、例えば地域によって異なる表現（例えば方言）がある言語に関し、該地域を指定する識別情報である。エリアコードは国際基準ＩＳＯ３１６６−１_ａｌｐｈａ−３（３文字コード）に準ずるものとする。例えば、アメリカ英語であればエリアコードは「usa」となる。エリアコードは省略可能である。

キャラクタコードは、キャラクタボイスを指定する識別情報である。例えば、女性のキャラクタボイスのキャラクタコードは「ｆ」、男性のキャラクタボイスのキャラクタコードは「ｍ」である。キャラクタコードは省略可能である。

以上により、アメリカ英語の女性のキャラクタボイスが格納される音声管理ファイル１０１のファイル名は「en-usa_f.json」となり、英語の女性のキャラクタボイスが格納される音声管理ファイル１０１のファイル名は「en-usa_f.json」となる。このようにＩＳＯに準拠したファイル名を付与することで、統一されたファイル名を付与することができる。しかしながら、このようなファイル名は一例にすぎず、このようなファイル名に制限されるものではない。

なお、ファイルフォーマットとしてjson（JavaScript Object Notation）形式を用いたのは一例に過ぎず、ＸＭＬ（Extensible Markup Language）形式など他の形式を用いてもよい。

また、表３の案内管理テーブルは端末３５が実行するプログラムコードに含まれているものとし、図６（ｂ）のファイル構造の中に独立しては存在していない。ただし、案内管理テーブルが音声管理ファイル１０１（＊＊＊.json）に含まれていてもよい。

<<ダウンロード手順>>
図７は、端末３５が音声管理ファイル１０１等をダウンロードする手順を示すシーケンス図の一例である。なお、端末３５にプログラム２１０２（アプリケーションソフトウェア）がインストールされる際に、基本となる音声管理ファイル１０１が少なくとも１つダウンロードされている。

S1：端末３５の端末送受信部５１は、定期的にサーバ３１と通信している。サーバ３１のサーバ送受信部４１は、音声管理ファイル１０１が増えるなどにより新たな言語に対応した場合、端末３５からの通信に対し言語更新通知を端末３５に送信する。なお、新たな言語に対応した場合とは、新しい表示テキストファイル１０８と音声管理ファイル１０１が登録され、言語定義ファイル１０７が更新されることをいう。

S2：端末３５の端末送受信部５１は言語更新通知を受信すると、言語定義ファイル１０７をサーバ３１に要求する。

S3：サーバ３１のサーバ送受信部４１の受信部４１ｂはこの要求を受信し、サーバ送受信部４１の送信部４１ａは端末３５に対し言語定義ファイル１０７を送信する。

S4：端末３５の端末送受信部５１は言語定義ファイル１０７を受信して、ナビ画面表示部５５が言語設定画面を表示装置２１３に表示する。言語設定画面を図８に示す。

S5：ユーザが言語（キャラクタボイスを含む）を指定する操作を行うと、端末３５の操作受付部５２が言語指定の操作を受け付ける。

S6：端末３５の端末送受信部５１は、言語（キャラクタボイスを含む）を指定して音声データをサーバ３１に要求する。この要求には、言語コード、エリアコード、キャラクタコードが含まれる。エリアコードとキャラクタコードは必須でない。

S7：サーバ３１のサーバ送受信部４１の受信部４１ｂはこの要求を受信し、サーバ送受信部４１の送信部４１ａはユーザが指定した言語の音声管理ファイル１０１を端末３５に送信する。なお、指定された言語の音声管理ファイル１０１が複数の音声データ一式１０６を有する場合、送信するのはエリアコード及びキャラクタボイスで指定されたもののみでよい。

このような処理により、端末３５は新しい言語の音声データ一式１０６を取得できる。したがって、ユーザは所望の言語に切り替えることができる。

<<言語設定画面>>
図８は、端末３５の表示装置２１３に表示された言語設定画面５０１の一例を示す。言語設定画面５０１は、言語名５０２ごとにキャラクタボイス５０３、ダウンロードアイコン５０４、視聴ボタン５０５、詳細ボタン５０６を有している。キャラクタボイス５０３は表示されない場合がある。ダウンロードアイコン５０４は音声管理ファイル１０１をダウンロードするためのボタンである。ダウンロードされていない言語についてはアイコンが点線で表示される。視聴ボタン５０５は予め決まった音声データを視聴するためのボタンである。詳細ボタン５０６はダウンロード対象の音声管理ファイル１０１の詳細（例えば、登録年月日、言語、エリア、キャラクタボイスの説明など）を表示させるためのボタンである。

ユーザはこのような言語設定画面５０１から任意の言語（キャラクタボイスを含む）を指定し、指定した言語の音声管理ファイル１０１をダウンロードすることができる。

＜他の言語の音声管理ファイル１０１について＞
続いて、言語が異なる場合の音声管理ファイル１０１について説明する。まず、フレーズ組立定義テーブル１０２は言語が異なっても同じかほぼ同じ構造にすることができる。一例として、日本語のフレーズ組立定義テーブル１０２を示す。

表４は案内音声定義ＤＢ４９４に記憶されている日本語のフレーズ組立定義テーブル１０２を模式的に示す。表２（ａ）と比較すると明らかなように、英語と日本語でフレーズ組立定義テーブル１０２は同じである。

しかしながら、英語と日本語では文法が異なるため、seq1-1などで特定される語順までは完全に同一にならない。一例として、英語と日本語ではseq1-2が異なっている。英語のseq1-2は表２（ｃ）に示すように以下である。
英語のseq1-2 ：2111・2115・2117・2116
「This route includes off-road and a border crossing」
これに対し、日本語のseq1-2は以下である。
日本語のseq1-2：2111,2116
「この経路は国境を含んでいます」
つまり、日本語ではオフロード道に関する音声データが含まれない。このように、本実施形態のナビゲーションシステム１００は、言語が異なってもフレーズ組立定義テーブル１０２における語順ＩＤと音声ＩＤの対応関係を同じか又はほぼ同じ構成にすることができる。また、開発段階では、細部の異なる案内内容だけ語順ＩＤに対応づけられた音声ＩＤで調整すればよいためコスト増も抑制できる。

＜動作手順＞
図９は、端末３５が音声で案内するまでの処理手順を説明する図の一例である。図９の処理手順は例えばプログラム２１０２が起動されるとスタートする。

まず、ユーザは言語設定画面５０１から案内音声の言語の指定を受け付ける（Ｓ１０）。端末３５の操作受付部５２は言語の指定を受け付ける。指定された言語は、例えば言語コード、エリアコード及びキャラクタコードの組み合わせで表現されている。ユーザが指定した言語は記憶部５９０に記憶される。

端末３５の経路案内部５４は記憶部５９０に記憶されているユーザ指定の言語を読み出して、案内音声の言語を特定する（Ｓ２０）。

この後、端末３５の経路案内部５４は、ユーザが案内ポイントに到達したか否かを判定する（Ｓ３０）。

案内ポイントに到達した場合（Ｓ３０のＹｅｓ）、経路案内部５４は案内管理テーブルの条件を参照して案内ポイントにおいて読み上げるフレーズのフレーズコードを決定する（Ｓ４０）。説明の便宜上、フレーズコードｆ１が選択されたものとする。

次に、端末３５の経路案内部５４は案内条件テーブル１０３を参照して、フレーズ内容に含まれる語順ＩＤのうち案内に使用する語順ＩＤを選択する（Ｓ５０）。フレーズコードｆ１のフレーズ内容は「seq.0＋seq.1-1＋seq.1-2＋seq.1-3＋seq.1-4＋seq.1-5」である。seq.0は必須（案内通知音）なので常に出力される。seq.1-1は必須であるが、端末３５が交通情報を考慮するか否かによって案内開始１，２のどちらかが選択される。交通情報を考慮するか否かは例えばユーザが端末３５に設定している。あるいはＶＩＣＳ（登録商標）（Vehicle Information and Communication System）が接続されているか否かよって自動的に判定してもよい。説明の便宜上、経路案内１が選択されたものとする。seq.1-2、seq.1-3又はseq.1-4について現在の案内ポイントが国境付近かどうか及びオフロード道かどうかを経路案内部５４は判定し、必要であればseq.1-2、seq.1-3又はseq.1-4の１つを出力すると判定する。説明の便宜上、seq.1-2、seq.1-3又はseq.1-4はいずれも出力されないものとする。seq.1-5は必須である。

次に、端末３５の経路案内部５４は語順テーブル１０４を参照して語順ＩＤに対応づけられている音声ＩＤを取得する（Ｓ６０）。したがって、音声ＩＤとして9、1233、1234が取得される。

次に、端末３５の経路案内部５４は音声データテーブル１０５を参照して、音声データ一式１０６から音声データを取得する（Ｓ７０）。したがって、en_9.wav、en_1233.wav、en_1234.wavの３つの音声データが取得される。

次に、端末３５の経路案内部５４は語順ＩＤに基づいて音声データを並べ替える（Ｓ８０）。すなわち、フレーズコードｆ１のフレーズ内容の順番に音声データを並び替える。

次に、端末３５の経路案内部５４は音声データを再生することでフレーズを読み上げる（Ｓ９０）。例えば、「Pon. Now starting navigation. Please obey all traffic regulations while driving.」というフレーズを読み上げる。

以上説明したように、本実施形態のナビゲーションシステム１００は、言語が異なっても共通のフレーズのパターンを抽出し、案内ポイントにフレーズコードを対応づける。そしえ、フレーズコードに語順ＩＤを、語順ＩＤに音声ＩＤをそれぞれ対応づけることで、言語が異なってもフレーズコードと語順ＩＤの対応を同じか又はほぼ同じにすることができる。また、フレーズコードに語順ＩＤが対応づけられていることで、語順ＩＤに対応付けられた音声ＩＤによって異なる細部の案内音声の相違を吸収できる。したがって、言語が異なっても発話フレーズを決定する際のロジックをほぼ共通にすることができシステムの肥大化を抑制できる。また、細部の異なる案内内容だけ調整すればよいためコスト増も抑制できる。

＜その他の好適な適用例＞
以上、本発明を実施するための最良の形態について実施例を用いて説明したが、本発明はこうした実施例に何等限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々の変形及び置換を加えることができる。

例えば、サーバ３１が音声データをｗａｖファイル等の音声データで配信すると説明したが、案内テキストを端末３５に送信してもよい。端末３５はＴＴＳ(Text-To-Speech)システムにより案内テキストを音声合成して出力する。

例えば、図５などの構成例は、サーバ３１による処理の理解を容易にするために、主な機能に応じて分割したものである。処理単位の分割の仕方や名称によって本願発明が制限されることはない。サーバ３１の処理は、処理内容に応じてさらに多くの処理単位に分割することもできる。また、１つの処理単位がさらに多くの処理を含むように分割することもできる。

また、サーバ３１が有する各データベースを複数の情報処理装置が分散して有していてもよい。

また、図５では一台のサーバ３１を図示したが、サーバ３１が複数台、存在してもよい。また、一台のサーバ３１が有する機能が複数のサーバに分散して配置されてもよい。

また、受信部４１ｂは取得手段の一例であり、記憶・読出処理部４９，５９は読出手段の一例であり、送信部４１ａは送信手段の一例である。経路案内部５４は案内文章決定手段の一例であり、記憶部４９０，５９０は記憶手段の一例である。音声出力部は音声入出力装置２１８の一例である。フレーズ組立定義テーブル１０２は第一の案内文章情報の一例であり、語順テーブル１０４は第二の案内文章情報の一例である。サーバ３１の音声管理ファイル１０１の構造、又は、端末３５の補助記憶装置２１７における音声管理ファイル１０１の記憶構造はデータ構造の一例である。ナビゲーションシステム１００は情報処理システムの一例である。案内条件テーブルは案内条件情報の一例である。

３１ サーバ
３５ 端末
５２ 操作受付部
５４ 経路案内部
５５ ナビ画面表示部
１００ ナビゲーションシステム

Claims (9)

1. 目的地までの経路を案内する音声データを端末に配信する情報処理装置であって、
   前記端末から言語の指定と共に前記音声データの要求を取得する取得手段と、
   言語ごとに、案内文章の識別情報に前記案内文章に含まれる１つ以上の文の識別情報が対応づけられた第一の案内文章情報を記憶し、さらに、前記文の前記識別情報に対応づけられた前記文の前記音声データを記憶する記憶手段から、前記取得手段が取得した言語の前記第一の案内文章情報及び前記音声データを読み出す読出手段と、
   前記読出手段が読み出した前記第一の案内文章情報及び前記音声データを前記端末に送信する送信手段と、有する情報処理装置。
2. 前記第一の案内文章情報において、前記案内文章の前記識別情報には言語が異なっても同じ前記文の前記識別情報が対応づけられている請求項１に記載の情報処理装置。
3. 前記記憶手段は、前記文の識別情報に対応づけて文、句又は単語の識別情報が対応づけられた第二の案内文章情報を記憶しており、
   前記第二の案内文章情報において、前記文の前記識別情報に対応づけられる前記文、句又は単語の前記識別情報の対応関係が言語によって一部異なっている請求項２に記載の情報処理装置。
4. 目的地までの経路を音声で案内する情報処理装置を、
   前記音声を出力する案内ポイントで案内文章の識別情報を決定する案内文章決定手段と、
   前記案内文章の前記識別情報に前記案内文章に含まれる１つ以上の文の識別情報が対応づけられた第一の案内文章情報を記憶する記憶手段から、前記案内文章決定手段が決定した前記案内文章の前記識別情報に対応づけられている前記文の前記識別情報を読み出す読出手段と、として機能させるためのプログラムであって、
   前記文の前記識別情報に対応づけて前記文の音声データを記憶する記憶手段から前記読出手段が読み出した前記文の前記音声データを音声出力部から出力させるプログラム。
5. 前記文の識別情報に対応づけて前記文を音声で出力するための条件が登録された案内条件情報を記憶する記憶手段から、前記案内文章決定手段が決定した前記案内文章に含まれる前記文の前記識別情報に対応づけられた前記条件を前記読出手段が読み出し、
   前記案内文章決定手段は前記文が前記条件を満たすか否かを判定し、満たすと判定された前記文のみを前記音声出力部から出力すると決定する請求項４に記載のプログラム。
6. 前記文の識別情報に対応づけて文、句又は単語の識別情報が対応づけられた第二の案内文章情報を記憶し、さらに、前記第二の案内文章情報に登録されている前記文、句又は単語の前記識別情報に対応づけて前記音声データが登録されている記憶手段から、前記案内文章決定手段が決定した前記案内文章に含まれる前記文、句又は単語の前記音声データを前記読出手段が読み出し、
   前記案内文章決定手段は、前記第一の案内文章情報に登録されている前記文の前記識別情報の順番に、前記読出手段が読み出した前記音声データを並び替え、
   前記案内文章決定手段は並び替えた前記音声データを音声出力部から出力する請求項４又は５に記載のプログラム。
7. 目的地までの経路を案内する音声データを記憶する情報処理システムであって、
   言語ごとに、前記音声データとして出力される案内文章の識別情報に前記案内文章に含まれる１つ以上の文の識別情報が対応づけられた第一の案内文章情報、及び、
   前記文の前記識別情報に対応づけられた前記文の前記音声データを記憶する記憶手段、
   を有する情報処理システム。
8. 目的地までの経路を音声で案内する情報処理装置であって、
   前記音声を出力する案内ポイントで案内文章の識別情報を決定する案内文章決定手段と、
   前記案内文章の前記識別情報に前記案内文章に含まれる１つ以上の文の識別情報が対応づけられた第一の案内文章情報を記憶する記憶手段から、前記案内文章決定手段が決定した前記案内文章の前記識別情報に対応づけられている前記文の前記識別情報を読み出す読出手段と、とを有し、
   前記文の前記識別情報に対応づけて前記文の音声データを記憶する記憶手段から前記読出手段が読み出した前記文の前記音声データを、前記案内文章決定手段が音声出力部から出力する情報処理装置。
9. 目的地までの経路を案内する音声データの決定に用いられるデータ構造であって、
   前記データ構造では、案内文章の識別情報に前記案内文章に含まれる１つ以上の文の識別情報が対応づけられ、さらに、前記文の前記識別情報に対応づけて前記文の音声データを記憶し、
   情報処理装置が、前記データ構造にアクセスして、前記案内文章を出力する案内ポイントで決定した前記案内文章の前記識別情報に対応付けられた前記文の前記識別情報を取得し、
   前記情報処理装置が、前記文の前記識別情報に対応づけられた前記文の前記音声データを前記データ構造から読み出して音声出力部から出力するために使用されるデータ構造。

Images