JP4085920B2

JP4085920B2 - 情報サービスシステム、車載端末、情報センタ

Info

Publication number: JP4085920B2
Application number: JP2003281089A
Authority: JP
Inventors: 匡英小笠原
Original assignee: Toyota Motor Corp
Current assignee: Toyota Motor Corp
Priority date: 2003-07-28
Filing date: 2003-07-28
Publication date: 2008-05-14
Anticipated expiration: 2023-07-28
Also published as: JP2005051490A

Description

本発明は、車載端末からのリクエストに応じて情報センタから情報を提供する情報サービスシステム、車載端末、情報センタに関する。

一般的な情報サービスシステムでは、必要な情報をユーザーが能動的に取得するプル型情報サービスが多く利用されている。これは、ユーザーが端末装置を操作することにより端末装置から情報センタに情報のリクエストを発信させ、このリクエストに応じた情報が情報センタから端末に提供されるものである。このようなプル型の情報サービスシステムが多く利用されるのは、汎用的なプル型情報サービス、例えば、ＷＷＷ（ＷｏｒｌｄＷｉｄｅＷｅｂ）などがすでに整備されていることなどの理由による。

通常、プル型情報サービスで、ユーザーは、情報が必要な場合、端末装置を所定の手順に従って操作して、端末装置から情報センタへのリクエストを発信させる。そして、情報センタはそのリクエストに応じた情報を提供する。したがって、ユーザーは、情報が必要なときは端末装置を操作すれば、情報を得ることができる。

しかし、車両に搭載された車載端末の場合、運転操作を行っていることが多いため、端末装置での操作は、極力少なくしたいという要望がある。また、ユーザーが端末装置の操作に不慣れな場合などは、情報センタの方で情報の配信を制御できることが望ましい。さらに、ユーザーの端末操作のタイミングと実際に情報提供できるタイミングとはずれる場合があり、端末操作時に発せられるリクエストだけでは対応できない場合がある。

そこで、情報センタでプル型の情報通信を制御できる情報サービスシステム、車載端末、情報センタを提供することを目的とする。

本発明の情報サービスシステムは、車両に搭載された端末であって、情報センタに情報のリクエストを行う車載端末と、車載端末からのリクエストに応じて車載端末に情報を提供する情報センタと、を有し、車載端末からみてプル型となる情報通信を行う情報サービスシステムにおいて、前記情報センタは、前記情報のリクエスト送信のスケジュールを記録した設定ファイルを、前記車載端末からのリクエストに応じて前記車載端末に提供する提供手段と、前記設定ファイルの提供が正常に行われなかった場合に、前記車載端末に前記設定ファイルのリクエストをさせるためのコマンドをプッシュ型で車載端末へ送信する送信手段と、を備え、前記車載端末は、ユーザから前記情報の要求操作があった場合に、前記情報端末に対して前記設定ファイルのリクエストを送信するとともに当該リクエストに応じて送信されてきた設定ファイルを受信する設定ファイル取得手段と、前記情報センタからプッシュ型で送信されてきた前記コマンドを受信するコマンド受信手段と、前記コマンドを受信した場合に、当該コマンドに従って、前記設定ファイル取得手段に設定ファイルのリクエスト送信を行わせることによりプル型の通信を開始させるコマンド実行手段と、を備えることを特徴とする。

好適な態様では、情報センタは、コマンドを送信後に車載端末によるコマンド実行が成功したか否かを判定する手段を有し、コマンド実行が失敗したと判定した場合には、再度、コマンドを送信する。情報センタから送信されるコマンドは、車載端末に定期的にリクエストをさせるコマンドであることが望ましい。

前記ユーザからの前記情報の要求操作は、前記情報センタにいるサポーターが前記車載端末で行われるべき操作を代行操作しその結果得られる前記情報を前記車載端末に提供するサポートサービスの開始を要求するための操作であることが望ましい。また、コマンドの受信及び送信は、ショートメッセージサービスを用いて行われることが望ましい。

ここで、プル型の情報通信とは、車載端末からのリクエストに応じて、情報センタが情報を提供するタイプの情報通信を指す。例えば、ＷＷＷ（ＷｏｒｌｄＷｉｄｅＷｅｂ）のようなものである。一方、プッシュ型の情報通信とは、車載端末からのリクエストがなくても、情報センタから車載端末へ情報配信できるタイプの情報通信をプッシュ型とする。したがって、ショートメッセージや電子メールのような双方向通信可能なタイプの情報通信であっても、車載端末からのリクエストがなくても、情報センタから車載端末へ情報配信できるのでプッシュ型の情報通信とする。

本発明によれば、情報センタでプル型の情報通信を制御できる。

以下、本発明の実施の形態について図面を参照しながら説明する。

図１に本発明の実施の形態である情報サービスシステム１０の構成図を示す。この情報サービスシステム１０は、情報を要求する車載端末１２および外部端末１６と情報を提供する情報センタ１４とを有している。

車載端末１２は、その本体部２０と、情報センタ１４への通信を可能にするためにデータ通信モジュール２４、車両位置の検出を行うためのＧＰＳ２６（ＧｌｏｂａｌＰｏｓｉｔｉｏｎｉｎｇＳｙｓｔｅｍ）とを備えている。また、後述するオペレーターとの通話手段である携帯電話２２が装着可能となっている。

本体部２０は、車載端末１２の本体であり、車室内の運転席近傍に設けられる。これは、車載端末１２全体の制御を行う制御部、情報の表示を行う表示部、車載端末の操作を行うための操作部などを有している。また、ＲＡＭやＳＤメモリカードなどの記憶部も備えている。この記憶部には、種々のプログラムやデータが記憶されている。記憶されているプログラムとしては、情報センタとの通信を行うためのブラウザソフト、車両の経路案内を行うナビゲーションソフト、電子メールの送受信を管理するメールソフトなどがある。また、記憶されているデータとしては、端末を識別するために付与されているＩＤ番号やナビゲーションソフトで使用される地図データなどがある。

データ通信モジュール２４は、情報センタ１４との通信を実現するための通信モジュールである。このデータ通信モジュール２４は、基地局１８を介して情報センタ１４が保有するデータのＵＲＬアドレスにアクセスできる。これにより車載端末１２は、情報センタ１４からＷＷＷのサービスを受けることができる。また、データ通信モジュール２４は、ショートメッセージサービスの機能も有しており、車載端末１２が保有する電話番号に基づいて送信されたショートメッセージを受け取ることができるＳＭ受信部２５（図示せず）を備えている。ショートメッセージは、データ通信モジュール２４の電話番号に基づいて、後述するＳＭ送信部３５から基地局１８を介してデータ通信モジュール２４に送られる。この通信は、電話回線の音声領域以外の空き領域である制御チャンネルを利用して行われる。

ところで、このデータ通信モジュール２４は、固定でない複数のＩＰアドレスが（ＤＨＣＰにより）適宜割り当てられるため、情報センタ１４側で車載端末１２毎のデータ通信モジュール２４のＩＰアドレスを把握するのは困難となっている。一方で、情報センタ１４には、本情報サービスの契約時に契約者とデータ通信モジュール２４の電話番号とが関連付けて登録されている。したがって、情報センタ１４側で各車載端末１２のデータ通信モジュール２４の電話番号を把握するのは容易となっている。そのため、電話番号に基づいてショートメッセージをセンタ側から送信することにより、情報センタ１４から車載端末１２へのプッシュ型サービスが可能になる。なお、本実施の形態では、車載端末専用の通信モジュールを用いているが、情報センタ１４との通信を実現するものであれば、携帯電話などの汎用の通信媒体を利用してもよい。

ＧＰＳ２６は、車両の位置検出を行うもので、ＧＰＳ衛星から配信される電波を利用して車両の位置を検出する。検出された位置情報は、ナビゲーションソフトに利用されるほか、データ通信モジュール２４と連動して情報センタ１４に送られる。情報センタ１４では、送られた位置情報に応じた情報サービスを提供する。

携帯電話２２は、情報センタ１４に存在するオペレーターとの通話手段であり、車載端末１２に対して着脱自在となっている。携帯電話２２を本体部２０に装着する場合は、本体部２０に設けられた専用の接続ポートに接続する。接続された携帯電話２２は、その操作を本体部２０で制御できるようになる。そのため、データ通信モジュール２４や種々のアプリケーションと連動して通話を行うことが可能となる。なお、本実施の形態では、着脱自在の携帯電話を用いているが、オペレーターとの通話ができれば、車載端末１２に固定された電話や他の通信手段であってもよい。また、サポートセンタにユーザーの要望を容易に伝達できれば、必ずしも通話手段でなくてもよい。

本システム１０は、車載端末１２での利用を基本としているが、他の外部端末１６で利用してもよい。外部端末１６としては、ＰＤＡ５４や携帯電話５２のような移動通信媒体、ネットワークに接続されたＰＣ５０（パーソナルコンピュータ）などがある。

情報センタ１４は、種々の情報を管理するサーバー部３４と、車載端末１２からのリクエストに応じて情報を処理する情報処理部３２、および、車載端末１２との通信を実現するための情報通信部３０とを備えている。また、ユーザーの操作をサポートするためのサポートセンタ３６を有している。

サーバー部３４は、個人用サーバー３８と共有サーバー４０とを有している。個人用サーバー３８は、各ユーザー専用に設けられたサーバーである。この個人用サーバー３８には、各ユーザーの嗜好に合わせたメニュー設定、メンテナンス情報、履歴情報などが記録されている。この個人用サーバー３８は、所定のＩＤとパスワードが一致すれば、車載端末１２、外部端末１６のいずれからでもアクセスできる。したがって、ユーザーは、端末種類にかかわらず、同じ情報を共有することができる。

共有サーバー４０は、全ユーザーで共有のサーバーであり、本システム１０で提供される各種コンテンツなどが記録されている。この共有サーバー４０は、個人用サーバー３８のあるセンタと同じセンタ内に設けられていてもよいし、他のセンタから通信を介して提供されてもよい。

サポートセンタ３６は、ユーザーの操作を補助するためのものである。サポートセンタ３６内にはオペレーターが存在し、ユーザーから要望があった場合には、車載端末１２で行われるべき操作をオペレーターが代行操作する。ユーザーの要望は、携帯電話２２とオペレーター用電話４２とを介してオペレーターに伝達される。また、サポートセンタ３６には、ショートメッセージ送信のためのＳＭ送信部３５を有しており、電話基地局１８を介して車載端末１２に所定の内容のショートメッセージを所定の電話番号に対して送信可能となっている。なお、本実施の形態で、オペレーターは人間であるが、ユーザーの要望に応じて代行操作できるものであれば、自動的に応答可能な電気的な装置であってもよい。

情報通信部３０は、車載端末１２との通信を可能とするもので、車載端末１２からのリクエストに応じて情報を提供する。車載端末１２からの情報のリクエストは、データ通信モジュール２４および情報通信部３０を介して情報処理部３２に伝達される。

情報処理部３２は、ＣＰＵ，ＲＯＭ，ＲＡＭなどから構成されており、プログラムの実行により、車載端末１２からのリクエストに応じてサーバー部３４および情報通信部３０の作動を制御する。各種端末１２、１６から情報のリクエストがあった場合、情報処理部３２は、その端末のＩＤおよびパスワードを確認し、どのユーザーからのリクエストであるかを判別する。そして、判別したユーザー用の個人用サーバー３８を利用して、情報処理を行う。

次に、本システム１０における情報サービスの流れについて説明する。ここでは、ナビゲーションソフトを使用した際の情報サービスの流れを例としてあげる。

ナビゲーションソフトにより経路案内などの情報サービスを受けたい場合、ユーザーは、車両の運転開始前に、車載端末１２を操作してナビゲーションソフトを起動させる。

このとき、車載端末１２からは、情報センタ１４に対して種々の情報のリクエストが送信される。車載端末１２からデータ通信モジュール２４、情報通信部３０とを介してリクエストが送信されると、情報処理部３２においてユーザーの特定が行われる。これは、各車載端末１２に付与されたＩＤから特定される。そして、共有サーバー４０およびユーザーの個人用サーバー３８から選択、処理された情報がリクエストに応じて提供される。

個人用サーバー３８から提供される情報としては、以前にユーザーが設定したスポット情報、例えば、お気に入りの店舗情報や自宅の位置情報などがある。共有サーバー４０から提供される情報としては、一般的なスポット情報、例えば、ガソリンスタンドやレストランの位置情報、店舗情報などである。

車載端末１２の表示画面には、情報センタから提供されたスポット情報などが反映された地図が表示される。そして、例えば、現在地から所定の目的地までの経路案内が必要なときは、さらに、車載端末１２を操作して目的地を設定する。設定された目的地は情報センタ１４に送られ、情報センタ１４は距離や混雑状況などを考慮して算出した経路情報を提供する。提供された経路に満足な場合は、その経路を設定し、実際の走行を開始する。

通常、走行中の車載端末１２の表示画面には、車両位置周辺の地図（ナビ画面）が表示される。これは、安全な走行を実現するためである。しかし、走行中、すなわち、ナビ画面表示中であっても、他のアプリケーションで収集された情報を知りたい場合がある。例えば、走行中であっても電子メールの受信の有無やその内容などが知りたい場合がある。

このような場合、メールソフトは、内部的に起動はしているが、画面上には表示されないようになっている。そして、メールが受信された場合は、走行の邪魔にならないように、電子メールの内容を車載端末１２に設けられたスピーカーで読み上げたり、補助画面に表示したりする。そして、このとき表示されなかった、または、補助画面に表示されたメールソフトの画面は、車載端末１２の記憶部に一時的に記憶される。そして、停車時などに再度、情報の内容を確認する場合は、この記憶された画面を呼び出して確認することができる。

次に、本システム１０で提供されるサポートサービスについて説明する。これは、車載端末１２の操作方法がわからない場合や、走行中のためユーザーが車載端末１２を操作できない場合に、ユーザーに代わって、サポートセンタのオペレーターが車載端末１２の操作の一部を代行するものである。例えば、目的地周辺のレストランを検索したいが、その方法がわからない場合には、オペレーターはユーザーに代わってレストランの検索を行い、その結果を車載端末１２に提供するものである。

このサービスの流れのイメージを図２に示す。ユーザーは、車載端末１２に装着された携帯電話２２でセンタのオペレーターに代行してほしい操作を伝える（Ｌ６０）。例えば、「目的地周辺のレストランを知りたい」や「東京タワーを目的に設定したい」などである。これを受けたオペレーターは、ユーザーに代わって、情報処理部を操作して、所定の情報を得る（Ｌ６２）。例えば、「目的地周辺のレストラン情報（最新情報）」や「東京タワーを目的地に設定する場合の設定情報」といった情報を取得する。ここで得られる情報は、車載端末１２で得ることができない最新の情報も含まれる。取得された情報は、ユーザーの個人用サーバー３８に記憶される（Ｌ６４）。車載端末１２は、この個人用サーバー３８に記憶された情報を取得する（Ｌ６６）。本体部２０では、得られた情報に応じて設定変更や画面表示を行う。このように代行操作で得られた情報を車載端末１２に提供することにより、ユーザー自身で操作した場合と同じ結果を得ることができる。

次にこのサポートサービスの流れについて、図３を用いて、より詳細に説明する。

ユーザーは、サポートサービスの開始を要求する場合は、車載端末１２に設けられた「問い合わせ」ボタンを押下する。問い合わせボタンが押下されると、車載端末１２から情報センタ１４に対して、サポートサービスの開始の連絡が送信され（Ｓ７２）、情報センタ１４はこれを受信する（Ｓ１１０）。そして、情報センタ１４は、車載端末１２のＩＤからユーザーを特定する。

次に、車載端末１２は、スケジュールファイルのリクエストを行う（Ｓ７４）。このスケジュールファイルのリクエストは、車載端末１２に事前にプログラムされており、車載端末１２は、このプログラムに基づいてスケジュールファイルのリクエストを行う。情報センタ１４は、リクエストに応じてスケジュールファイルを提供する（Ｓ１１２）。

ここでスケジュールファイルとは、車載端末１２に情報センタ１４へ定期的に情報のリクエストをさせるための定義ファイルである。具体的には、ＣＤＦ（ＣｈａｎｎｅｌＤｅｆｉｎｉｔｉｏｎＦｏｒｍａｔ）で記載されたファイルであって、個人用サーバー３８の所定領域に１分感覚でアクセスするように車載端末１２を設定するためのファイルである。すなわち、車載端末１２に個人用サーバー３８の所定領域をポーリングさせるためのファイルである。

このようなポーリングを行う理由について説明する。サポートサービスにおいてオペレーターの代行操作により取得される情報は、個人用サーバー３８の所定の領域に保存される。しかし、「問い合わせ」ボタンを押下しただけの現段階においては、個人用サーバー３８に代行操作の結果情報はまだ存在せず、また、いつ存在するかが不明である。そのため、車載端末から定期的に情報のリクエスト（所定領域へのアクセス）がなされるようにし、情報センタでは、そのリクエストに対して提供できる情報（代行操作の結果情報）があればそれを返し、無い場合にはその旨を返す。

ここで、代行操作により得られる情報が個人用サーバー３８に記憶された時点で、車載端末１２に提供する方法も考えられるが、これには、いくつかの問題がある。まず、本実施の形態では、ＷＷＷを利用したプル型の情報サービスシステムを用いている。そのため、車載端末１２からのリクエストなしで、自動的に情報センタ１４から車載端末１２へ情報を送信することはできない。必ず、車載端末１２からのリクエストが必要となる。

また、情報が個人用サーバー３８に記憶された時点で、車載端末１２からリクエストを発信させて、情報を提供する方法もある。しかし、通常、車載端末１２にリクエストを発信させるためには、ユーザーが何らかの端末操作を行う必要がある。そのような操作は、ユーザーにとって煩雑であり、特に、運転操作を伴う車載端末１２においては、そのような操作は極力減らしたい。また、運転操作をしていない場合であっても、代行操作による結果情報が個人用サーバー３８に記憶されるタイミングが不明であるため、ユーザーの端末操作のタイミングも不明となる。したがって、ユーザーは、いつ端末操作してよいか分からないこととなる。

そのため、本実施の形態では、スケジュールファイルにより、車載端末１２に個人用サーバー３８の所定領域をポーリングさせ、情報提供を行う。ここで、情報センタ１４から（車載端末１２のリクエストに応じて）提供されるスケジュールファイルを用いずに、車載端末１２内部にポーリングを行うプログラムを記憶させておくことも考えられる。そうすれば、スケジュールファイルが提供されなくても、車載端末１２において、自動的にポーリングを開始できる。しかし、多数のユーザーが所有している車載端末１２の処理を複雑化することは、メンテナンスや管理の面で好ましくない。できる限り情報センタ１４で一括管理できることが望ましい。そのため、本実施の形態では、スケジュールファイルにより、車載端末１２の動作を設定している。

このスケジュールファイルを取得した車載端末１２は、定期的に所定領域のアクセスを開始する（Ｓ７８）。このとき、第１回目の個人用サーバーへのアクセス（リクエスト）がなされたると、情報センタ１４では、アクセスフラグがＯＮに変更される（Ｓ８０）。アクセスフラグとは、車載端末１２からのアクセスの有無を表すフラグで、車載端末１２による所定領域へのアクセスがなされる前はＯＦＦであり、アクセスがなされるとＯＮとなる。

したがって、このアクセスフラグは、スケジュールファイルによる設定が正常に行われているか否かの判断基準になる。すなわち、アクセスフラグがＯＮの場合はスケジュールファイルによる設定は正常に行われており、ＯＦＦの場合は設定が失敗したということになる。

車載端末１２は、第１回目のアクセスの後も、定期的に所定領域へのアクセスを行い（Ｓ８２）、代行操作による結果情報の情報データの有無を確認する（Ｓ８４）。

一方、第１回目のアクセスの後、ポーリング動作と並行して、オペレーター用電話４２への電話が発呼される（Ｓ８６、Ｓ１１４）。これは、車載端末１２に装着された携帯電話２２から自動的に発呼される。

また、情報センタ１４のオペレーターには、その電話をかけてきたユーザーの情報が表示される。これは、ユーザーの端末ＩＤ情報や現在の車両の位置情報などの他、アクセスフラグの状態も表示される。すなわち、車載端末１２により所定領域へのアクセスがなされたか、スケジュールファイルにより正常に設定がなされたかの情報が表示される。

アクセスフラグがＯＮの場合、すなわち、正常に設定がなされた場合、オペレーターは電話に出て、ユーザーとの会話を開始する。ユーザーは、代行してほしい操作をオペレーターに伝達する（Ｓ８８）。オペレーターは、その要望を満たすように、情報処理部３２を操作し、得られた情報を個人用サーバー３８に保存する（Ｓ１２０）。

例えば、ユーザーの要望が「現在地の周辺の喫茶店を知りたい」であれば、オペレーターは、ユーザーの車両位置周辺の喫茶店を検索する。そしてその結果得られた情報を個人用サーバー３８に保存する。また、ユーザーの要望が「東京駅を目的に設定したい」であれば、そのような設定がなされる設定ファイルを作成し、個人用サーバー３８に記憶する。

そして、オペレーターは、正常に個人用サーバーに情報が保存されたことを確認して、電話を切る（Ｓ１２２）。

このユーザーとオペレーターとが通話を行っている間も、車載端末１２は個人用サーバー３８の所定領域に定期的にアクセスを行っている（Ｓ８２）。しかし、オペレーターが情報データを保存（Ｓ１２０）するまでは、個人用サーバー３８の所定領域には、情報が存在しない。そのため、車載端末１２はアクセスを繰り返す（Ｓ８４）。

オペレーターにより情報データが保存されると、車載端末１２は、必要な情報（リクエストした情報）があるので、これを取得する。そして、ユーザーとオペレーターとの通話が終了していることを確認した上で（Ｓ９０）、その取得した情報データを画面に表示し（Ｓ９２）、処理を終了する。

ところで、車載端末１２は、車両に搭載されているため、高速で移動していることが多い。そのため、通信状況が良くない地域に車両が存在する場合もある。すでにスケジュールファイルによる定期的なリクエスト（ポーリング）が設定された後であれば、車両が通信状況の悪い地域にあったとしても、車両が通信状況の良い地域へ移動するまでリクエストの再トライがなされる。

しかし、最初のスケジュールファイルのリクエストおよび提供（Ｓ７４、Ｓ１１２）の際に、車両が通信状況の悪い地域にある場合、車載端末１２は、スケジュールファイルを取得できない。その結果、車載端末１２は、定期的なリクエスト（ポーリング）を行うことができない。

このような場合は、再度、車載端末１２からスケジュールファイル提供のリクエストを発信し、スケジュールファイルを取得する必要がある。

しかしながら、ユーザーが何らかの操作を行って、再度のリクエストを発信させることは、上述したように運転操作を伴う車載端末１２では望ましくない。また、車載端末１２にスケジュールファイルの取得の成否を判断させ、再度のリクエストを行うことも、車載端末１２の処理を複雑にすることになり、望ましくない。

そこで、スケジュールファイルの取得に失敗した場合の対応について図４を中心に説明する。スケジュールファイルの取得が失敗した場合、第１回目の個人用サーバー３８へのアクセスがないまま、オペレーターへの電話が発信される（図４のＳ８６）。したがって、アクセスフラグはＯＦＦであり、オペレーターはスケジュールファイルの提供が失敗したと判断する。

その場合、情報センタ１４のオペレーターは、ＳＭ送信部３５を利用して、車載端末１２の電話番号に基づいて、車載端末１２に対して所定の内容のショートメッセージ（ＳＭ）を送信する（Ｓ１１８）。このショートメッセージには、車載端末１２にスケジュールファイル提供のリクエストを発信させるコマンドが記載されている。すなわち、スケジュールファイル提供の再度リクエストするように、ひいては、車載端末１２が所定の領域へのアクセスを再度行うように、車載端末１２のプログラムを変更するようなコマンドが記載されている。

このショートメッセージを受信した車載端末１２では、その内容を解釈する（Ｓ９６、Ｓ９８）。そして、ショートメッセージに記載されているコマンドに基づいて、再度、スケジュールファイル提供のリクエストを発信する（Ｓ１０２）。

具体的には、ショートメッセージ内には、スケジュールファイルの存在するＵＲＬが記載されており、オペレーターは、これを暗号化して送信する。このショートメッセージを受信した車載端末１２は、記載されているＵＲＬにアクセスする。

このリクエストによってスケジュールファイルを取得できた場合は、そのファイルによって、定期的なリクエスト発信が設定される。すなわち、車載端末１２によりポーリングが実施される。車載端末１２により第１回目のアクセスがなされると、アクセスフラグがＯＮとなる（Ｓ７８、Ｓ８０）。情報センタ１４では、ショートメッセージを送信した後、再度、アクセスフラグがＯＮとなっているかを判定し、ＯＮとなっている場合は、そのまま、通常の処理を行う。

一方、この再度のスケジュールファイル提供のリクエスト（Ｓ１００）によっても、スケジュールファイルの取得ができない場合もある。その場合、車載端末１２による個人用サーバーへのアクセスがなされないため、アクセスフラグはＯＦＦのままとなっている。そのため、情報センタ１４では、再度、車載端末１２の電話番号に基づいて、ショートメッセージを送信する。このように、情報センタでは、アクセスフラグの判定（Ｓ１１６）とショートメールの送信（Ｓ１１８）とをアクセスフラグＯＮとなるまで定期的に繰り返す。そして、アクセスフラグＯＮを確認すれば、その後は通常の処理を行う。

以上、説明したように、情報センタ１４から車載端末１２へショートメッセージでコマンドを送信することにより、車載端末１２からリクエストを送信させることができる。すなわち、情報センタでプル型情報通信の開始のタイミングやリクエスト内容などを管理することができる。したがって、ユーザーに新たな操作をさせることなく、情報を提供できる。また、車載端末には、複雑な処理がないため、車載端末の管理やメンテナンスが容易となる。

なお、本実施の形態では、オペレーターが車載端末１２の情報センタ１４へのアクセスを確認してショートメッセージを送信しているが、自動的にアクセスフラグの状態を確認して、ショートメッセージを送信するようにしてもよい。

また、本実施の形態では、スケジュールファイルによる定期的リクエスト設定を基本とし、その設定が失敗したときにショートメッセージを利用している。しかし、スケジュール設定を行うことなく、代行操作の結果情報がオペレーターにより個人用サーバー３８に保存された時点でショートメッセージを送信し、代行操作の結果情報のリクエストを発信させるようにしてもよい。

また、さらに別の方法として、代行操作してほしい操作が単純なものである場合（例えば、単なる目的地設定など）である場合、端末にその操作を行わせるためのコマンドをショートメッセージとして送信するようにしてもよい。

また、本実施の形態では、サポートサービスにおけるポーリング再設定のためにコマンド（ショートメッセージ）を送信しているが、他の場面でコマンド送信してもよい。例えば、車両位置情報は、定期的に車載端末１２から情報センタ１４に送信される。これは、スケジュールファイルによる設定によりなされる。しかし、この設定が適切になされていないと判断した場合は、コマンド（ショートメッセージ）を送信し、適切な設定ができるスケジュールファイルを取得させてもよい。

また、本実施の形態では、汎用的で利用しやすいためショートメッセージを利用しているが、車載端末からのリクエストなしで情報を提供できる手段であれば、他の手段でコマンドを送信してもよい。

本発明の実施の形態である情報サービスシステムの構成図である。サポートサービスのイメージ図である。ポートサービスの流れを示すフローチャートである。サポートサービスの流れを示すフローチャートである。

符号の説明

１０情報サービスシステム、１２車載端末、１４情報センタ、２０本体部、２２携帯電話、２４データ通信モジュール、２５ＳＭ受信部、３０情報通信部、３２情報処理部、３４サーバー部、３５ＳＭ送信部、３６サポートセンタ、３８個人用サーバー、４０共有サーバー、４２オペレーター用電話。

Claims

車両に搭載された端末であって、情報センタに情報のリクエストを行う車載端末と、
車載端末からのリクエストに応じて車載端末に前記情報を提供する情報センタと、
を有し、車載端末からみてプル型となる情報通信を行う情報サービスシステムにおいて、
前記情報センタは、
前記情報のリクエスト送信のスケジュールを記録した設定ファイルを、前記車載端末からのリクエストに応じて前記車載端末に提供する提供手段と、
前記設定ファイルの提供が正常に行われなかった場合に、前記車載端末に前記設定ファイルのリクエストをさせるためのコマンドをプッシュ型で車載端末へ送信する送信手段と、
を備え、
前記車載端末は、
ユーザから前記情報の要求操作があった場合に、前記情報端末に対して前記設定ファイルのリクエストを送信するとともに当該リクエストに応じて送信されてきた設定ファイルを受信する設定ファイル取得手段と、
前記情報センタからプッシュ型で送信されてきた前記コマンドを受信するコマンド受信手段と、
前記コマンドを受信した場合に、当該コマンドに従って、前記設定ファイル取得手段に設定ファイルのリクエスト送信を行わせることによりプル型の通信を開始させるコマンド実行手段と、
を備えることを特徴とする情報サービスシステム。
請求項１に記載の情報サービスシステムであって、
前記情報センタは、前記コマンドを送信後に前記車載端末によるコマンド実行が成功したか否かを判定する手段を有し、
コマンド実行が失敗したと判定した場合には、再度、前記コマンドを送信することを特徴とする情報サービスシステム。
請求項１または２に記載の情報サービスシステムであって、
前記ユーザからの前記情報の要求操作は、前記情報センタにいるサポーターが前記車載端末で行われるべき操作を代行操作しその結果得られる前記情報を前記車載端末に提供するサポートサービスの開始を要求するための操作であることを特徴とする情報サービスシステム。
請求項１乃至３のいずれか１に記載の情報サービスシステムであって、
前記コマンドの受信および送信は、ショートメッセージサービスを用いて行われることを特徴とする情報サービスシステム。
車両に搭載されたプル型の情報サービスシステム用の端末であって、情報センタに情報のリクエストを行うことにより情報センタから情報が提供される車載端末において、
ユーザから前記情報の要求操作があった場合に、前記情報端末に対して、前記情報のリクエスト送信のスケジュールを記録した設定ファイルのリクエストを送信するとともに当該リクエストに応じて送信されてきた設定ファイルを受信する設定ファイル取得手段と、
前記設定ファイルの受信が失敗した場合に前記情報センタからプッシュ型で送信されるコマンドを受信するコマンド受信手段と、
前記コマンドを受信した場合に、当該コマンドに従って前記設定ファイル取得手段に設定ファイルのリクエスト送信を行わせることによりプル型の通信を開始させるコマンド実行手段と、
を備えることを特徴とする車載端末。
車両に搭載された車載端末からの情報のリクエストに応じて車載端末に情報を提供するプル型の情報サービスシステム用の情報センタであって、
前記情報のリクエスト送信のスケジュールを記録した設定ファイルを、前記車載端末からのリクエストに応じて前記車載端末に提供する提供手段と、
前記設定ファイルの提供が正常に行われなかった場合に、前記車載端末に前記設定ファイルのリクエストをさせるためのコマンドをプッシュ型で車載端末へ送信する送信手段と、
を備えることを特徴とする情報センタ。