JP4013740B2

JP4013740B2 - 情報処理装置、情報処理支援装置および情報処理支援システム

Info

Publication number: JP4013740B2
Application number: JP2002329465A
Authority: JP
Inventors: 一郎吉田
Original assignee: Denso Corp
Current assignee: Denso Corp
Priority date: 2002-11-13
Filing date: 2002-11-13
Publication date: 2007-11-28
Anticipated expiration: 2022-11-13
Also published as: JP2004164288A

Description

【０００１】
【発明の属する技術分野】
本発明は、外部から受ける情報処理依頼に対して、自己のリソースでは達成できない場合でも、これを他の機器と連携して処理を行えるようにした情報処理装置、情報処理支援装置、ユーザ情報管理装置および情報処理支援システムに関する。
【０００２】
【発明が解決しようとする課題】
従来、１つの機器で処理機能を満足できないときに、外部の機器と連携して処理を行うことが検討されつつある。例えば、１台のＰＣで処理できない数値計算問題を解決するのに、複数のＰＣを用いて並列処理が行われることがある。この場合、複数のＰＣにはほぼ同じ構成（ＣＰＵ、メモリ、処理速度）で、リソース自体も固定されたもののため、別の処理を行う場合、複数のＰＣのリソースを別の処理に適合するように再構成する必要がある。
【０００３】
一方、機器を使用するユーザが人の場合、単純な数値計算とは異なり、一般的な人の要求、命令は特定の分野に限定されていないため、人からＰＣに命令が出されたとき、それをそのＰＣが持つリソースだけで処理することは難しいことになる。これは、例えば、音声認識、画像認識（読唇術）、文字認識等によるＨＭＩ（Human-Machine Interface）などを想定している。
【０００４】
そのため、このような要求に対応するためには、従来の並列処理とは異なる外部機器との連携機能が必要になる（連携分散処理）。この場合、外部機器の連携により生ずる処理の遅れに関するユーザのイライラを解消するために、処理中において処理完了予測時刻等をユーザに知らせる手段が必要になる。
【０００５】
また、上記の要求を実現するために、具体的には、ユーザが話した言葉を機器が認識した場合に、その単語が、名詞，動詞，形容詞，助詞等のいずれであるかを判別して分類し、ユーザの目的に合致した制御を行う機能が必要である。各品詞を分類してその活用形まで対応付けを行うことで、ユーザの意図を把握する必要がある。つまり、依頼内容を把握すること、すなわち音声認識を行った結果からテキスト解析を行うことでユーザの意図を把握するようにするのである。
【０００６】
本発明は上記事情に鑑みてなされたものであり、その目的は、人、または他の機器からの情報処理依頼を受けた時、その処理を情報処理機器本体だけで実行できない場合でもこれを他の機器に依頼して実行できるようにした情報処理装置、情報処理支援装置、ユーザ情報管理装置および情報処理支援システムを提供することにある。
【０００７】
【課題を解決するための手段】
請求項１の情報処理装置によれば、受付手段により外部からの依頼情報処理を受け付けると、その依頼情報処理が自己のリソースを用いて実行可能か否かを判定手段により判定し、実行不能な場合には、その実行に不足するリソースが収集可能か否かを探索手段により探索して収集可能であるときには、その不足リソースをダウンロードするかまたは外部リソースを用いて協調動作で処理するかをユーザに問い合わせ、探索手段により不足リソースがハードウェアであると判定されると共に問い合わせ手段により問い合わせした結果外部リソースを用いて協調動作で処理するとユーザにより選択入力された場合、その不足リソースのハードウェアを利用可能な情報処理装置を探索してそのハードウェアで行うべき情報処理を依頼し、問い合わせ手段により問い合わせした結果不足リソースをダウンロードして処理するとユーザにより選択入力された場合、不足リソースをダウンロードし、ダウンロードして処理する場合または外部リソースを用いた協調動作を行うときには、ユーザの依頼に対応するためのユーザのメッセージタイプを認識し当該メッセージタイプに応じた動作をなすアプリを構築する処理を実行する。
【０００８】
これにより、自己が備えているリソースだけでは達成することが出来ない場合でも、依頼情報処理について不足するリソースが外部から収集可能である場合にはこれを収集してユーザの依頼に対応するためのユーザのメッセージタイプに応じた動作をなすアプリを構築することができ、これによって外部と連携して広い範囲の情報処理を達成することができ、依頼情報処理の内容の範囲についての制限を少なくして汎用的な利用をすることができるようになる。
【０００９】
しかも、探索手段が不足リソースをハードウェアであると判定したときには、処理依頼手段により、不足リソースのハードウェアを利用可能な情報処理支援装置を探索して実行すべき情報処理を依頼し、そのハードウェアにより実行された結果を受領手段により受け取ることができるので、自己の内部ではハードウェアリソースが不足していて処理プログラムを構築することが出来ない場合でも、外部の情報処理支援装置が備えるハードウェアを利用して達成することができるようになる。
【００１２】
請求項２の情報処理装置によれば、上記各発明において、受付手段として、人が音声により入力する情報処理の依頼を受け付ける入力手段と、この入力手段により入力された音声情報を、呼びかけ、説明、依頼、質問、確認などの各メッセージタイプに分類し、当該分類されたメッセージタイプから前記実行手段が実行可能な情報として解釈する依頼解釈手段とを備えた構成としているので、情報処理の依頼をするのが人である場合に、直接音声により入力して依頼を行わせることができるようになり、使い勝手の向上を図ることができるようになる。
【００１３】
請求項３に記載の情報処理支援装置によれば、ネットワークを介して情報処理装置からアクセスされ、その情報処理装置が有する前記請求項１または２記載の情報処理装置により不足リソースの収集依頼を受けると、リソース提供手段は、これに応じてその不足リソースを提供するので、情報処理装置と連携して依頼情報処理の実行を達成することができるようになる。
【００１４】
請求項４に記載の情報処理支援装置によれば、上記請求項３の発明において、処理依頼手段は、リソース提供手段により不足リソースがハードウェアであると判定されたときに、その不足リソースのハードウエアを利用可能な他の情報処理支援装置を探索してそのハードウェアで行うべき情報処理を依頼するので、依頼を受けた情報処理について自己が有するハードウェアでは処理不能でも、外部の他の情報処理支援装置と連携して情報処理を実行可能である場合には依頼して実行することができるので、自己が備えるリソースに加えて他の情報処理支援装置のハードウェアリソースも利用して処理を実現することができるようになる。
【００１５】
請求項５に記載の情報処理支援装置によれば、請求項１に記載の情報処理装置もしくは請求項４に記載の情報処理支援装置の処理依頼手段により前記不足リソースのハードウェアの利用依頼を受けたときに、対象となったハードウェアで行うべき情報処理を受け付けてこれを処理する処理手段と、この処理手段による処理結果を前記情報処理装置の受領手段に渡す送信手段とを設けているので、情報処理装置に対して、利用依頼を受けた不足リソースであるハードウェアを提供して情報処理を行ってその結果を送信手段により送信することができる。これにより、情報処理装置が単独ではハードウェアリソースが不足していて処理できない情報処理についても、これを支援して達成させることができるようになる。
【００１６】
請求項６に記載の情報処理支援装置によれば、上記請求項３ないし５の何れかに発明において、自己が備えるリソースが情報処理装置の処理方法選択手段により選択された外部リソースに該当する場合に、その要求に応じて協同して前記依頼情報処理を実行するので、単独では処理能力に劣る場合や、処理不能なリソースがある場合に、効率よく依頼された情報処理を達成することができるようになる。
【００２２】
請求項７に記載の情報処理支援システムによれば、請求項１または２記載の情報処理装置を備え、ユーザから命令を受けたときに、本体のハードウェアだけでその命令を処理できるか否かを判定する判定手段と、この判定手段により本体のみでその命令が処理できないと判定されたときに、外部の情報処理支援装置に一時的に移動して当該外部の情報処理支援装置内のリソースを利用してアクセス許可範囲内で必要な処理を完了させるＡＩエージェントを生成するＡＩエージェント生成手段とを備え、ＡＩエージェントを、前記情報処理支援装置内で内部に保有するリソースを利用して必要な処理を完了させて、その完了結果を移動前の場所に転送させた後、必要な処理が完了すると自己消滅するように構成したので、ＡＩエージェントという概念のもとで、情報処理装置の内部のリソースが不足する場合でも効率的に情報処理を達成することができるようになる。
【００２３】
【発明の実施の形態】
以下、本発明を携帯情報処理機を用いたシステムに適用した場合の一実施形態について図面を参照して説明する。
【００２４】
（基本構成の説明）
図１はこのシステムの全体構成を概略的に示すもので、情報処理装置としての携帯情報処理機１は、ユーザＡが主たる使用者で、いわゆるモバイル機器と呼ばれるものである。この携帯情報処理機１は、携帯電話としての機能およびパケット通信機としての機能を兼ね備えている。
【００２５】
この携帯情報処理機１は、操作入力をするためのキーボード２、表示装置３を備えると共に、マイクロホン４、スピーカ５、ＣＣＤカメラ６やタッチパネル７（図２参照）を備えており、ユーザの音声入力や操作入力あるいは画像入力を受け付けるように構成されている。外部との通信にはアンテナ８を通じて送受信を行うように構成されている。表示装置３は、例えばＬＣＤ，ＥＬ，有機ＥＬ等のものが用いられており、これはＣＣＤカメラ６の画像表示やＴＶモニタとしても使用できる。
【００２６】
携帯情報処理機１は、無線電話機能を使用すると、中継局９を介してネットワーク１０にアクセスすることができる。ユーザＡが自己のテリトリーとして使用可能な外部機器（情報処理支援装置）として、例えば家用ＰＣ（パソコン）１１ａ、会社用ＰＣ１１ｂ車両用ＰＣ１１ｃ、その他のＰＣ１１ｄなどがあるが、これらはインターネットなどに代表されるネットワーク１０を通じて携帯情報処理機１がアクセス可能となっている。
【００２７】
また、ネットワーク１０には、多数のユーザが共通に利用することができる情報処理支援装置としての外部機器１２が接続されており、携帯情報処理機１によりアクセス可能となっている。さらに、後述する個人認識モジュールを多数のユーザ毎に管理しているユーザ情報管理装置としてのリソース管理会社１３の端末装置（サーバ）もネットワーク１０に接続されていて、携帯情報処理機１や外部機器１１、１２などによりアクセス可能となっている。
【００２８】
図２は携帯情報処理機１の電気的構成を示している。全体の制御をつかさどる制御回路１４は、ＣＰＵ、ＲＯＭ、ＲＡＭなどを主体として構成されるもので、電話機能の制御や通信機能に加えて、種々の情報処理機能を達成するようにソフトウェアおよびハードウェアが組み込まれている。この制御回路１４には、前述した各構成に加えて、通信回路１５、ＧＰＳ受信機１６、メモリ１７や、ＩＣカードの情報を読み書きするＩＣカードリーダ１８などが接続されている。
【００２９】
通信回路１５により外部へ送信されたデータは、中継局９などを経由して、家や会社、車両その他に置かれたＰＣ１１ａ〜１１ｄなどで受信させたり、後述する外部機器１２に受信させることができる。送信データのあて先を決めるために、機器に設定されたインターネットのＩＰアドレスやユーザが独自に設定したユーザアドレス等が用いられる。
【００３０】
携帯情報処理機１の制御回路１４は、ユーザの音声認識により得た結果を分析して、ユーザの発生音（発音の特徴、イントネーション、母音、子音の周波数帯域など）や使用する語彙からユーザの特徴を割り出して記憶するようになっている。
【００３１】
前記のように、携帯情報処理機１は、そのユーザＡの音声を認識してユーザＡの特徴を記憶することができるように構成されている。ユーザＡは、ほぼ常時使用する携帯情報処理機１の解析、学習結果をＡの管理するサーバやＰＣ１１ａ〜１１ｄなどに蓄積する。あるいは、リソース管理会社１３のサーバにユーザＡの解析、学習結果の蓄積、管理を記憶して管理するようにしてもよい。
【００３２】
外部機器１２は、ユーザＡの持つ携帯情報処理機１にユーザＡを認識するためのデータの使用依頼を行い、必要な認証が完了すると、携帯情報処理機１からユーザ認証に必要な音声認識データを受領することができる。また、外部機器１２からユーザＡのデータ使用依頼がリソース管理会社１３のサーバにあった場合も同様に、サーバは通信によって外部機器１２へ必要なデータを送るように構成されている。
【００３３】
このようにして、携帯情報処理機１を用いて入力を行うユーザＡについて、その携帯情報処理機１あるいはリソース管理会社１３から音声認識についてのデータを受け取ることができるので、外部機器１２がユーザＡであることとその言語を確実に認識できるようになる。
【００３４】
なお、外部機器１２が携帯情報処理機１もしくはリソース管理会社１３から受領した音声認識に関するデータには有効期限がつけられており、その有効期限として設定されている時間が経過すると自動的にそのデータは消去されるように決められている。なお、外部機器１２の種類によっては、例えば家電製品のように、ある程度長時間使用される機器では、設定時間が日単位で設定され、自動販売機のような機器では分単位で消去されるように設定される。また、セキュリティ確保の目的でデータが使用される場合は、月や年単位でデータ更新を行うようにしても良い。
【００３５】
（概略的な動作説明）
次に、認識結果をもとに事前動作確認を行う例について図３ないし５を用いて説明する。まず、図３においては、携帯情報処理機１の概略的な動作について順を追って示している。図４および図５では、それらを詳細にした流れが示されている。
【００３６】
図３の携帯情報処理機１の動作フローにおいて、まず、ユーザによる入力が行われると、その情報収集を行い（ステップＡ１）、収集した情報についてそれらの情報が何を意味しているのかの認識処理を行う(ステップＡ２)。ここで、ステップＡ１の情報収集は、外部つまりユーザＡあるいは他のユーザなどから入力があるかをチェックするステップで、続くステップＡ２の情報認識は、入力があるとその情報を別の形に変え、機器が理解しやすい形に変更する（音声認識では声をテキストに変更する操作を示す）処理を行う。
【００３７】
次に、携帯情報処理機１は、依頼されている処理内容が認識できると、その認識結果について得られた情報の範囲で実行可能か否かを判定する（ステップＡ３）。これは、テキストデータを解析して、テキストデータからユーザの意向を判定する（命令、依頼、質問、その他から機器がすべき動作を決定する）処理である。
【００３８】
次に、認識結果に基づいて、その依頼内容について事前動作確認を行い、実行に必要な情報で認識できない部分をユーザＡに問い合わせて認識語彙を増加させる（ステップＡ４）。ここで、事前動作確認とは、ユーザＡが発した言葉が理解できない場合、ユーザＡはどのような目的を持っていて、それは具体的にどのような処理を期待しているかをユーザＡに確認するために行われるものである。
【００３９】
ここでは、ユーザＡの意向に沿えるソフト、ハードの条件を検証する（ユーザの意向確認と、動作シミュレートを行う。ここで語彙増加、認識条件向上用の設定値の調整、マッチングデータを収集、蓄積する）。
【００４０】
続いて、ユーザＡの要求に内部リソースでは対応できないと判定された場合、不足リソースを探索し、不足リソースが見つかった場合、ユーザＡに外部との協調による動作をすること（ここでは、不足リソースをダウンロードして携帯情報処理機１内でアプリを構築するか、それともタスクを外部に依頼するかの選択を行うこと）の情報提供、確認の処理と、ユーザＡが不足リソースダウンロードまたは、協調動作を受け入れた場合に、対応するリソースを収集するか、または外部機器１２へタスクを依頼する処理（ステップＡ５）が実施される。このようにして対応モジュールが収集されると、次に、動作確定処理（ステップＡ６）として、動作可能と判定された処理について実際に動作することを確定し、その動作を実行する（ステップＡ７）。
【００４１】
これにより、ユーザＡの意図に反した動作を行わないようにして、携帯情報処理機１の動作効率を改善させると共に、ユーザＡの特徴を記録して認識率の改善を図るようにしている。また、ユーザＡの言い間違いや勘違いによる携帯情報処理機１の動作ミスを未然に防止することができるようになる。
【００４２】
（詳細な動作説明）
次に、図４および図５を参照して携帯情報処理機１の動作の詳細について説明する。この動作の主体となる制御回路１４は、まず、マイクロホン４を通じて入力された音声データから、ユーザＡが機器に対して入力（会話）を行おうとしているか否かについて処理を行う（ステップＳ１）。そして、ユーザの音声の有無の検知、背景雑音の低減などの処理結果を常時出力すると共に、ユーザＡの入力（会話）があれば確実にそれを認識処理に移行できるように判定を行っている（ステップＳ２）。
【００４３】
制御回路１４は、上記出力結果から、会話があったか否かを判定し、会話が無いと判定された場合にはステップＳ１に戻り、会話が有りと判定された場合には、続いて会話データ部の切り出しを行う（ステップＳ３）。続いて、適宜切り出したデータをデジタルデータに変換し（ステップＳ４）、さらにそのデータが認識できるように変換処理を行う（ステップＳ５）。
【００４４】
次に、制御回路１４は、変換されたデータについて音声認識処理（音声マッチング）を行い（ステップＳ６）、これをテキストデータに変換する（ステップＳ７）。このとき、音の大きさ、抑揚データなども合わせて解析する。
【００４５】
この後、制御回路１４は、得られたテキストデータについて、単語の並びをもとに文の構造を、文法的に分類する（ステップＳ８）。続いて、テキストデータから単語を抽出し、それらを品詞（名詞、動詞、助詞、形容詞等）に分け（ステップＳ９）、抽出された単語については、それぞれ品詞を類別するＩＤ（データタイプタグ）を付けて記憶する（ステップＳ１０，Ｓ１１）。
【００４６】
ここで、制御回路１４は、各単語につけた品詞の矛盾をチェックしたり、あるいは、テキストとして認識することはできたがその意味が通らない単語（認識データ辞書にはないもの）があるかどうかについてチェックを行い（ステップＳ１２）、問題がなければ（ステップＳ１２で「ＹＥＳ」と判断）、次のステップＳ２０へ進む。
【００４７】
一方、単語に矛盾がある場合、制御回路１４は、ステップＳ１３に進み、矛盾が生じている単語を表示装置に表示して、ユーザに再入力をしてもらうように促す。制御回路１４は、ユーザが再入力するのを待ち（ステップＳ１４，Ｓ１５）、入力されたデータは認識処理が行われる（ステップＳ１６）。ユーザによる再入力が無い場合にはステップＳ１５で「ＹＥＳ」と判断して、開始画面に移動する（ステップＳ１に戻る）。
【００４８】
ここで、制御回路１４は、入力されたデータの解析を行い、使用されている単語がデータ辞書にあるか否かを判定して単語に矛盾が生じていないか否かを判定する。もし、入力データが理解できない（認識辞書に無い）場合には、ユーザへ理解できない単語を復唱あるいは表示にて知らせる。ユーザはそれにより理解されなかった単語を入力する。入力結果は解析され、理解できるか否かが判定される。この部分で、制御回路１４は、入力された単語を認識するための必要データを記憶し、同じユーザＡの入力に対し、認識候補を増やして認識率を向上させることができるようになる。必要なデータとは、基本音素データ、音素変動パラメータ、抑揚、速度、選択語彙の変化などである。
【００４９】
次に、制御回路１４は、認識されたデータに矛盾がないかを再度チェックし（ステップＳ１７）、まだ矛盾があれば、ユーザにそのデータを登録するか否かを判断し（ステップＳ１８）、「ＹＥＳ」ならば正しい語を入力するよう表示させてユーザに依頼する（ステップＳ１９）。ユーザにより代替語が入力されると、制御回路１４は、音データと代替語を関連付けて保存する。また、ユーザが設定時間が経過する間、何もしない場合には、データに矛盾があるためそれ以上の処理ができないので、開始画面へ移動する（ステップＳ１８で「ＮＯ」と判断してステップＳ１に戻る）。
【００５０】
制御回路１４は、ステップＳ１９で代替入力を得て単語レベルで矛盾がなくなると、次に、認識されたテキストのメッセージタイプを分類する（図５のステップＳ２０）。ここでいうメッセージタイプとは、例えば、呼びかけ、説明、依頼、質問、確認、応答などの各タイプを想定している。この分類に際しては、制御回路１４は、分類されたテキストから動詞を探し、動詞の前後関係からメッセージタイプを分析して決定する（ステップＳ２１）。
【００５１】
この後、制御回路１４は、そのメッセージタイプの内容に対応できるかを判定し（ステップＳ２２）、対応できないと判定するとユーザにメッセージタイプの再確認を行う（ステップＳ２３）。再確認の処理では、ユーザにメッセージタイプの入力を促すための画面表示を行う。そして、ユーザにより再確認の入力がなされると、制御回路１４は、その結果が前と同じメッセージタイプかを確認してその結果がどのメッセージタイプかをチェックする（ステップＳ２４）。
【００５２】
制御回路１４は、メッセージタイプの再チェックを行ってもそれがわからないと判定すると（ステップＳ２４で「ＮＯ」と判断）、対応できない旨の表示と、対応できない理由や、入力に関する推奨項目を表示する（ステップＳ２５）。この場合には、メッセージタイプを明確にするための入力の仕方の案内を行うと良い。例えば、
「質問なら、『・・・か？ですか？』、依頼なら『・・・してほしい』の語尾を使ってください。」
等の表示、又は音声伝達を行うことで案内を行うと良い。
【００５３】
次に、ステップＳ２２で、テキストのメッセージタイプに対応できると判定されると、制御回路１４は、そのメッセージタイプに入れられた単語を解析し、そのメッセージの処理を行うためのリソースの有無をチェックするようになる（ステップＳ２６）。
【００５４】
次に、制御回路１４は、リソース不足と判定した場合には（ステップＳ２７で「ＹＥＳ」と判断）、外部機器１２との通信を開始し、不足リソースを探索するようになる（ステップＳ２８）。外部機器１２としてはユーザのコンタクトできる事務所や家庭のＰＣ１１ａ〜１１ｄなどを経由してインターネット１０で探索したり、あるいはリソースを管理するリソース管理会社１３に接続して、リソースの有無を問い合わせる。
【００５５】
制御回路１４は、探索処理を行うことより、不足するリソースが見つかれば（ステップＳ２９で「ＹＥＳ」と判断）、リソースの属性を読み出し（ステップＳ３０）、ユーザに不足するリソースをどのように取り扱うかを問い合わせを行う(ステップＳ３１)。
【００５６】
ここでは、制御回路１４は、ユーザに対して、リソースをダウンロードする（ステップＳ３３）か、不足リソースのサイズが大きい場合やダウンロード時間がかかりすぎる場合や内部処理能力不足が予想される等の場合で、外部機器との協調動作（ステップＳ３４）を選ぶか、処理を取りやめる（ステップＳ３５）かを選択する問い合わせを行う。
【００５７】
ユーザが実行を示す決定をした場合（ステップＳ３２にて、ステップＳ３３，Ｓ３４のいずれかを選択した場合）には、制御回路１４は、不足リソースのダウンロード（ステップＳ３３）または外部機器１２との協調動作（ステップＳ３４）のセットアップをして、アプリを構築する処理を実行し（ステップＳ３６〜Ｓ３９）、ユーザのメッセージに応じた動作をする（この部分の機能は、リアルタイムインタラクティブアプリ構築環境とも言える）。
【００５８】
なお、上記の処理を経ることで得られたアプリについては、制御回路１４は、メッセージタイプ毎に分類して記憶するようになっている。この場合、リソース自体が大きいため、記憶エリアを確保できない場合は、リソース名とそのリソースを得た場所（アドレス）情報を記憶する。これにより、将来、同じメッセージタイプにおいて、類似するユーザ依頼があった場合には、記憶したリソースの情報を読み出すことで迅速にアプリ構築が行えるようになる。
【００５９】
（リソース管理会社の管理システムの説明）
次に、上記のシステムを用いた場合のリソース管理会社１３における管理システムについて図６を参照して説明する。図６において、リソース管理会社１３は、主にユーザの音声認識関連データをリソースとして管理するように構成されている。
【００６０】
前述した携帯情報処理機１は、電話機能を有しており、図示しない電話会社と使用契約が行われる。また、電話使用と同時にリソース管理会社１３との間で音声認識機能拡張への登録を行う。ここで、音声認識処理については、ユーザ本人を確認するための補助手段としても使用可能としている。
【００６１】
まず、ユーザが携帯情報処理機１を用いて電話機能を使うと、ユーザの通常使用する音声認識関連データが改良され認識率が向上していく。それらの音声認識関連データは定期的にリソース管理会社１３において記録される。これによって、ユーザの所有する携帯情報処理機１が壊れても音声認識関連データを失うおそれがないので、新たな携帯情報処理機１を使用する際に、その機器内で音声認識関連データを新たに作成する必要がなくなる。
【００６２】
次に、ユーザが携帯情報処理機１に指示を出すと、携帯情報処理機１は、前述したように、その指示に応じてメッセージタイプを調べ、それにあったリソースをリソース管理会社１３から無償で取得する。リソースのダウンロードに応じてリソース管理会社はユーザから料金を徴収するようなシステムとすることもできる。
【００６３】
さらに、携帯情報処理機１を上述したようにして使用することで、ユーザが構築したアプリは、リソース管理会社１３側で管理することができる。これによって、他のユーザが管理されているリソースのアプリを使いたい場合、有償あるいは無償で配布することで共有することができるようになる。その際、アプリを構築したユーザに使用料を支払うことができるようにすれば、アプリを構築するユーザ側も積極的に提供するアプリを構築することができ、また、利用するユーザ側も既に出来上がっているアプリの中から適切なものを選ぶことで迅速且つ実績のあるリソースとして活用することができるようになる。
【００６４】
そして、リソース管理会社１３は、サーバで管理しているユーザの音声認識関連データが外部機器１２（料金をとるサービス機器）で使用することを積極的に行うことで、その使用料金を徴収するメリットを享受することができる。ユーザ認識用の音声認識関連データの使用は、外部機器１２へ購入を依頼する手順のどこかでリソース管理会社１３に使用を連絡する手順を設け、リソース管理会社１３が使用状況を把握できるようにする。たとえば、ユーザ認識用の音声認識関連データを外部機器１２に転送したタイミングでリソース管理会社１３は、外部機器１２の管理会社へ課金処理を行うようになっている。
【００６５】
上記のようにシステムを構築することで、ユーザ認識率が高い機器は、従来の認識機能よりも優れた認識機能を提供することができるようになるため、サービスが向上しユーザにとって受け入れられやすくなる。また、本人認証を厳密に行えるようになるため、セキュリティの確保にも効果がある。また、ユーザ認識用の音声認識関連データはリソース管理会社１３が管理するため、自分のデータを失うおそれがない。
【００６６】
図６の例では、携帯情報処理機１にリソースを集め、携帯情報処理機１内でアプリを構築する例を示している。すなわち、ユーザの依頼に対応するためにユーザのメッセージタイプを見つけ、そのメッセージタイプに応じた動作を行えるかどうかを検証し、その結果、携帯情報処理機１内部のリソースだけでは動作が行えない場合、外部機器１２などからリソースを獲得してアプリを構築する例を示している。
【００６７】
携帯情報処理機１が、十分高速な演算装置やメモリ等のハードを持ち、大きなアプリも構築できるハードリソースを持っている場合は問題なく実行をすることができるが、携帯情報処理機１側のハードウェアリソースが不足し、内部では十分なアプリが構築できない場合、外部のハードウェアリソースと共同してユーザの依頼を処理するアプリを構築する必要がでてくる。
【００６８】
携帯情報処理機１の制御回路１４は、どのような構成でユーザの依頼に対応できるかを、言語認識結果から得られたメッセージタイプの内容を解析して、アプリ構築をシミュレートする。内部のリソースで対処できる場合は、アプリを構築してユーザの依頼を実行する。
【００６９】
一方、携帯情報処理機１の内部のリソースでは対応できない場合、あるいはアプリは構築できるが処理に時間がかかる場合や、アプリを構築するハードウェアリソースがないためアプリを構築できない場合等では、次のような対応をする。制御回路１４は、外部リソースを探す。対応できる外部リソースを持つリソース管理会社１３、あるいはユーザが別の場所に保有する外部機器１１ａ〜１１ｄや外部機器１２等で不足リソース（ハード）を補うことが出来れば、それらに協調動作依頼とその依頼内容を含めたデータを送信する。
【００７０】
依頼内容を受信した外部のリソースを管理する機器１１ａ〜１１ｄ，１２からは、依頼内容に対する対応可否の回答と、対応可とすると、いつまでに依頼内容に対応できるかを携帯情報処理機１の制御回路１４に送る。また、利用が有料であるリソース管理会社１３を利用した場合には、その料金情報等も合わせて受け取る。
【００７１】
携帯情報処理機１は、これらをユーザに提示して、ユーザに依頼を実行してよいかの判断を委ねる。ユーザ依頼において、ユーザが既に同じ依頼を何度も行い、ユーザがその依頼に関する判断条件を判定して、ユーザに判断を委ねることを省いて協調動作を管理することも可能である。
【００７２】
（リソース管理会社から外部機器へのデータ転送の説明）
図７と図８は、リソース管理会社１３から外部機器１２へのデータ転送の様子を模式的に示したものである。図７に示すように、ユーザの携帯情報処理機１から外部機器１２へ情報を伝達し、外部機器１２はホストであるリソース管理会社１３のサーバへ認識モジュールすなわちユーザ認識用の音声認識関連データの送信を依頼し、そのデータを受領する。外部機器１２は、携帯情報処理機１のユーザの言語を認識してユーザの要求を処理することができるようになる。以下に図８のフローの説明をする。
【００７３】
図８において、外部機器１２はリソース管理会社１２のサーバ（以下、リソース管理会社と略称する）にあらかじめ利用登録を行う（ステップＰ１）。携帯情報処理機１もリソース管理会社１２に利用登録を行う（ステップＰ２）。リソース管理会社１３は、これらの利用登録を受け付ける（ステップＰ３）。
【００７４】
携帯情報処理機１からは、ユーザが使用をするたびにその音声認識関連データを記憶して蓄積しており、その蓄積している音声認識関連データについて、適宜の時間間隔でリソース管理会社１２に送り（ステップＰ４）、リソース管理会社１２はそのデータを定期的にアップデートする（ステップＰ５）。
【００７５】
携帯情報処理機１のユーザＡが外部機器１２の利用をしたい場合、携帯情報処理機１から外部機器１２に対して利用依頼を出す（ステップＰ６）。これに対して、外部機器１２は外部機器利用依頼を受け付け、その利用依頼に含まれたユーザＩＤを読む（ステップＰ７）。次に、外部機器１２は、リソース管理会社１３に利用者確認依頼とデータ利用依頼を行う（ステップＰ８）。
【００７６】
これを受けて、リソース管理会社１２は、利用者確認処理をした後（ステップＰ９）、要求を受けた外部機器１２に対して必要なデータを送る（ステップＰ１０）。外部機器１２は、ユーザの依頼を処理できるように必要なデータ（リソース）を集め（ステップＰ１１）、アプリをセットアップするようになる（ステップＰ１２）。
【００７７】
それが完了すると、外部機器１２は、ユーザに入力を促すように表示を携帯情報処理機１又は外部機器１２に行う（ステップＰ１３）。これに対して、ユーザは携帯情報処理機１を用いて入力処理を行う（ステップＰ１４）。外部機器１２はデータ認識と応答の処理を行う（ステップＰ１５）。
【００７８】
ユーザは利用が完了すると、携帯情報処理機１により利用完了入力を行う（ステップＰ１６）。外部機器１２は、携帯情報処理機１から送信された利用完了を受信すると、リソース管理会社１３から受領したデータを設定時間後に消去するように処理する（ステップＰ１７）。
【００７９】
（携帯情報処理機がアプリを構築する場合の説明）
次に、図９を参照して、携帯情報処理機１がユーザからの依頼を受け、アプリ構築を検討した結果、外部機器１２にてアプリ全体を構築する例を説明する。なお、この説明においては、携帯情報処理機１において、制御回路１４が実施していた処理について、ソフトウェアである音声モジュールが主体的に動作する形式で説明する。
【００８０】
すなわち、携帯情報処理機１の音声モジュールは、ユーザが入力する音声から言語を認識し、その認識結果からユーザの依頼をメッセージタイプに分類する。次に、リソースマネージャがメッセージタイプとその詳細を解析し、どのようなリソースを用いてアプリを構築するかを検討し、アプリ仕様設計書を作成する。アプリ仕様設計書には、アプリ構築に必要なリソースのタイプとその構成（アプリモジュールの連結）が記載されている。
【００８１】
このアプリ仕様設計書に基づき、リソースマネージャは、携帯情報処理機１内部のリソースを調査する。この場合には、携帯情報処理機１内で処理することは難しいと判断している例を示している。たとえば非常に演算量が多いため、携帯情報処理機１内でアプリを構築すると時間がかかりすぎるような場合がこの例に対応する。
【００８２】
携帯情報処理機１は、外部機器１２へアプリ仕様設計書と携帯情報処理機１が持つリソースを外部機器１２へ送る。外部機器１２はアプリ使用設計書に基づき、必要なリソースを機器の内部や外部のリソース管理会社１３から集め、アプリを構築する。外部機器１２内で構築されたアプリは、ユーザの依頼に対する結果を出す。出された結果は通信用インターフェース回路を用いて携帯情報処理機１に送られ、ユーザに提示される。
【００８３】
上記のようなアプリの構築を行う場合のリソースマネージャとユーザとの関係は、図１０に示すようになっている。すなわち、リソースマネージャは、ユーザの言語やジェスチャをテキストに変換して、メッセージタイプ、メッセージタイプ対応情報（必要な機能モジュール、リソース）を決定して、ユーザの目的を確認する。
【００８４】
リソースマネージャは、ユーザの目的がわかると、自己の機器の内部にあるリソースを確認して、仮のアプリを作成し、それがユーザの目的を満たすか否かを判定する。もし、ユーザの目的を満たせない時は外部からリソースを集めて再度仮のアプリを作成しユーザに提示する。ユーザが気に入ったところでアプリを完全に機能するようにリソースを配置して、アプリ動作を開始する。
【００８５】
また、ユーザが気に入ったアプリの構成（リソースリスト、リソース配置等）を記録し、後でユーザが再度そのアプリの動作を希望したとき、迅速にそのアプリを構築できるようにする。
【００８６】
（携帯情報処理機が外部機器と協働して処理を実行する場合の説明）
上述の例では、携帯情報処理機１が、アプリを外部機器１２にて構築して、結果のみを携帯情報処理機１へ返すようにしているが、これに代えて、図１１に示すように、携帯情報処理機１でアプリの一部を構築し、外部機器１２で残りのアプリを構築し、それらが協調して動作し、外部機器１２の結果を携帯情報処理機１が利用して最終的な結果を出すようにしてもよい。
【００８７】
このような場合の一例として、ＪＡＶＡＶＭの上で作動するリソースを大量に必要とするアプリケーションをリソースを持たない携帯情報処理機１で動作させる場合、携帯情報処理機１だけでは動作できないアプリを外部機器１２と連携して動作させてユーザには見かけ上、携帯情報処理機１だけで動くように見せる手段として有効である。
【００８８】
どんなアプリでも作動できるように、ネットワーク上にある使用可能なリソースのデータベースを持ち、それらを適宜利用してユーザの依頼を処理することを考えると、図１１に示した構成が効率的である。
【００８９】
（具体的な応用例の説明）
また、別の例として、コンピュータグラフィックスのアニメーション作成のように、大量の画像を作成する場合、１台のコンピュータでそれらの処理を行うと、莫大な演算能力が必要になる。従来は、複数のＣＰＵを搭載できる高速なコンピュータを複数台使って、画像作成および動画作成を行っていた。
【００９０】
このような場合に、本発明の構成を採用することで、画像作成の中心にある制御アプリがネットワーク上にある負荷の少ない複数のＰＣそれぞれに、描画に必要なアプリ機能を構築し、ＣＰＵの能力に応じて描画画面、描画枚数等を割り当てることが可能になる。また、描画された結果を、動画化するためには、制御アプリが動画化する機能を持つＰＣ等を探して、そこへ複数のＰＣが描画したデータを送信するように命令を出す。これにより、従来のように高価な機器を使用しなくても、大規模な画像（動画）を作成することが可能になる。
【００９１】
ただし、この前提は、制御アプリが負荷の少ないＰＣを選択する場合に、セキュリティ機能（相互認証）を受け、この認証が確認された場合に、選択されたＰＣは命令を受けるようにする。このとき、制御アプリが業務を依頼する外部ＰＣは、それぞれ使用可能のリソースリストを持ち、制御アプリは、そのリソースリストを参照して、外部ＰＣへの業務を割り当てるようにする。また、制御アプリは、そのリソースリストを超えるＰＣのリソース領域にはアクセスできないようになっている。
【００９２】
（ビジネスモデルとして成立するシステムの説明）
次に、上記システムを利用して成立するビジネスモデルについて説明する。制御アプリが業務を依頼するＰＣのユーザには、通信料金の割引や、使用時間に応じたポイント、あるいは作成された画像を安価で利用出来る等のサービスが付加される。このようにして、業務にＰＣを貸すことでＰＣの購入を安価にすることができる。
【００９３】
例えば、ＰＣ自体を主に個人リースし、ユーザの使っていない空き時間で、そのＰＣを使いたいユーザに共同利用させることができるようにする。ここで、空き時間に使いたいユーザは、負荷の大きなアプリを動かしたいヘビーユーザであり、通常のアプリを動作させるユーザをライトユーザとすると、ライトユーザ、ヘビーユーザ両者に時間に応じた料金を支払うようにし、ＰＣの維持費（電気代、通信費）はヘビーユーザが使用時間、量に応じて支払うようにする。ライトユーザは、従来よりも安価にＰＣを使うことができる。また、ヘビーユーザは、ＰＣを設置するために空間が不要になるという効果がある。
【００９４】
（車載サーバのＯＳ補助アプリに適用した例の説明）
次に、上記のシステムを車載サーバのＯＳ補助アプリに適用した場合の例を示す。すなわち、車載サーバの補助アプリは、外部から依頼を受け取る（同時に複数の処理を行う）。補助アプリ（ＯＳＧｉ）は、依頼内容が、車載サーバに搭載されたアプリモジュール（アプレット、サーブレット、あるいはその部品ソフト）で実行できるか判定する。
【００９５】
補助アプリは、車載サーバ本体で処理できないと判定すると、どのようなアプリモジュールが不足するかをチェックする。補助アプリは、不足するモジュールをネットワークにアクセスして獲得できないかをチェックする。補助アプリは、不足するアプリモジュールをネットワークを介して獲得できることがわかると、そのアプリモジュールを獲得しても良いかをユーザに問い合わせる。あるいは予めユーザが自動的にアプリモジュールを獲得する条件を設定しておく、それから外れた場合は、ユーザに問い合わせる。
【００９６】
補助アプリは、不足リソースをネットワークを介して獲得する。補助アプリは、不足リソースを獲得すると、実行できるアプリケーションの形に構築して、ＯＳに処理を渡す。ＯＳは、依頼された処理を行う。アプリの動作が感旅してＯＳに完了を通知し、ＯＳがその処理完了を確認すると、結果を補助アプリに渡す。補助アプリはアプリ不要なリソースを削除、あるいは退避する。
【００９７】
続いて、上記システムにおける携帯情報処理機１の機能を、情報処理装置としてのＰＣ１１ａ〜１１ｄ（以下ＰＣ１１と称する）が実行する場合について、ＰＣ１１内に上記システムを実行するように構成されたソフトウェアであるリソース収集型ＡＩモジュール（以下、単にＡＩモジュールと称する）を設定して行う場合について説明する。
【００９８】
図１２はその基本的な動作をチャートに示したものである。ユーザの手元（ホーム）にあるＰＣ１１のＡＩモジュールがユーザから処理の命令（ステップＲ１）を受けたとき（ステップＲ２）に、ＡＩモジュール（ソフト）は、自己が常駐する本体（ハード）だけでその命令を処理できるか否かを判定する（ステップＲ３，Ｒ４）。
【００９９】
本体内でその命令の処理が可能である場合には（ステップＲ４で「ＹＥＳ」と判断）、内部処理を実行してその結果を出力する（ステップＲ５，Ｒ６）。また、本体のみでその命令が処理できないと判定されると、ＡＩモジュールは、他のＰＣに一時的に移動可能なＡＩエージェント（ソフトモジュール）を生成し、他のＰＣ１２（その他情報処理機器あるいは外部機器）にＡＩエージェント（ソフトモジュール）を送る（ステップＲ７）。
【０１００】
他のＰＣ１２では、ＡＩエージェントを受信すると（ステップＲ８）、内部でＡＩエージェントが起動するようになる。ＡＩエージェントは、ＰＣ１２内のリソース（ハードとソフト）の使用依頼をして（ステップＲ９）、ＯＫであれば（ステップＲ１０で「ＹＥＳ」と判断）、リソースを利用して必要な処理を完了させて（ステップＲ１１）、その完了結果をＡＩモジュールのある場所（ホーム）へ転送する（ステップＲ１２）。この後、ＰＣ１２内のＡＩエージェントは必要な処理が完了したことをもって自己消滅するか、あるいはＡＩエージェントはＯＳにＡＩエージェントを消す命令を残して停止する（ステップＲ１３）。
【０１０１】
また、ＡＩエージェントが内部リソースの使用依頼を出したときに、ＯＫが得られない場合には（ステップＲ１０で「ＮＯ」と判断）、ＡＩエージェントの依頼が実行できないことから、キャンセル処理を行ってその旨をＡＩエージェントの送信元であるＡＩモジュールが常駐しているＰＣ１１側に通知する（ステップＲ１４，Ｒ１５）。
【０１０２】
ＰＣ１１側では、ＡＩモジュールが、ＡＩエージェントを送った先のＰＣ１２から処理結果を受け取ると（ステップＲ１６）、その結果をユーザに出力するようになる（ステップＲ６）。なお、ＰＣ１２に送ったＡＩエージェントから内部リソースの使用依頼がＯＫされなかった場合には、この通知を受けた後（ステップＲ１５）、他のＰＣ１２を探索して上記のステップを繰り返し実行するか、あるは利用が出来ない場合の処置をとることになる。
【０１０３】
上記のようにすると、ネットワーク１０を用いた遠隔処理のように、通信のために回線内に常にデータを流す必要がないため、ネットワーク回線の混雑を緩和することができる。ただし、これを安易に実行するとＰＣユーザのプライバシーに触れることの可能性が出てくるので、各ＰＣ１１，１２においては、他のＰＣからのＡＩエージェントに割り当てられるリソースを制限する機能を持たせることが必要となる。
【０１０４】
また、ＡＩエージェントに公開されるネットワークエリアをパブリックエリア、公開されないエリアをプロテクトエリアと呼ぶことにする。ＡＩエージェントは基本的にパブリックエリア情報を検索、移動することができるように設定される。さらに、ＡＩエージェント発行者がネットワーク使用について対価を支払うことが前提であれば、対価支払に応じてＡＩエージェントを受け入れたＰＣ１１，１２は、使用可能エリアの使用制限を緩めるようなネットワーク構成にしても良い。また、各ＰＣユーザは他のＰＣユーザから利用に応じた対価を得るようにすると良い。
【０１０５】
次に、上記したリソース収集型ＡＩモジュールを適用した場合の具体的事例について説明する。
【０１０６】
（具体的事例その１）
まず、具体的事例その１として、リアルイメージナビゲーションについて説明する。これは、ドライバが走行中に自分の目的場所の景色、道路機能（自動運転エリアか）、混雑状況、駐車場の入口の渋滞状況、駐車場が自動料金収受システムか、駐車場の駐車アシストの有無等のリアルイメージの情報を得ることができるようにしたもので、ドライバに動画で表示できるようにするナビゲーションシステムである。
【０１０７】
ここでは、情報処理装置として車両に搭載しているＰＣ１１ｃが車載サーバとして機能するように構成されている。車載サーバ１１ｃは、カーナビゲーション装置と協働してナビゲーション機能の向上を図るものである。そして、後述する種々の情報をカーナビゲーション装置の表示装置を利用して表示させるようになっている。
【０１０８】
ユーザ（車両のドライバ、同乗者の使用も可能）は、車上で自分の行きたい場所（例えば、ショッピングセンタ）の名前を、通信メディアなどで知った（あるいは別のメディアで情報を入手した）とする。そのとき、ユーザがその場所の景色、渋滞状況（空から見た）、駐車場の空き状況、駐車場の入口の渋滞状況、駐車場が自動料金収受システム対応か、駐車場の自動駐車アシストの有無等を知りたくなり、車載サーバ１１ｃに調査を依頼するシチュエーションを考える。
【０１０９】
車載サーバ１１ｃは、自分自身のリソース（メモリ、ＤＶＤ、ＣＤ、接続中のネットワーク等）を調査する。例えば、依頼者の欲する場所の情報（現在の航空写真、紹介文）が無い、駐車場付近の画像等を保有していない、自動走行のための基本データ（デジタル道路情報）が無い等、車載サーバ１１ｃ単独でユーザの要求を処理できない依頼であると判定すると、そのときに、ユーザ要求に答えるための不足するデータと機能を分類して、処理すべきタスクを構成し、そのタスクを処理するＡＩモジュールを作成する。
【０１１０】
ここでいうＡＩモジュールとは、テキストで構成されたプログラムスクリプトや、相手先ＰＣが理解できるプログラム言語、相手ＰＣが音声認識が可能ならユーザの音声の指示、またはそのテキスト変換されたデータ等であり、種々の形態がある。
【０１１１】
次にＡＩモジュールがどのように作動するかを詳細に説明する。車載サーバ１１ｃは、種々の通信メディア情報をユーザに届け、必要ならその情報を記録するメディア車載機（あるいは車載サーバの追加機能モジュール）から、ユーザが調査依頼を出したキーワードを、メディア車載機が記録したデジタルデータから検索する（ここで車載サーバ１１ｃにメディア車載機の機能を持たせるようにしてもよい）。
【０１１２】
その情報として、例えば
[情報１]−「○○ショッピングセンタは、会員の皆さんにＸＸ時より３０分のタイムサービスを行います。これから送りますキーワード情報をお持ちの方に限り、下記の製品を４０％引きにします」
という情報をユーザが得たとする。
【０１１３】
ユーザは、紹介された製品を欲しいと思うと、車載サーバ１１ｃに対して音声にて、現在位置から○○ショッピングセンタに移動して、目的の商品の購入が可能かを問い合わせることができる。
【０１１４】
ここで、ユーザは、単純に「上記情報の製品を購入できるか？」と車載サーバ１１ｃに問い合わせる場合を想定する。車載サーバ１１ｃは、ユーザのリクエストに対し、いくつかの質問をすることで、ユーザの要求が、
「ＸＸ時３０分までに（ＭＭ分以内に）この車両は目的地に到着できるか」
という具体的な内容であることを判別する。そこで、車載サーバ１１ｃは、車両の目的地到着時刻推定のタスクを実行する。
【０１１５】
車載サーバ１１ｃは、目的地までのルートを複数検索し、法定速度で走行したときの平均走行時間からユーザの欲しい商品を購入できる可能性を判定する。ここで、全く可能性が無い場合は、車載サーバ１１ｃは、ユーザに不可能という応答を返す。
【０１１６】
一方、車載サーバ１１ｃが、商品を購入できる可能性があると判定した場合には、現在地から目的地までの正確な渋滞情報、渋滞を回避したときの走行時間、目的地付近の渋滞状況（駐車場付近の渋滞台数）、駐車場付近の移動速度等を考慮し、購入可能性を推定する処理を行う。しかし、上記の情報がローカルな情報で車載サーバ１１ｃの位置からでは詳細な情報が得られない場合が考えられる。その際、車載サーバ１１ｃは、目的地付近の種々の情報発信機器へアクセスして必要な情報を集める必要がある。
【０１１７】
例えば、対象となっているショッピングセンタまで行く経路１として、県道のＡ，Ｂ，Ｃ，Ｄを通過して行くとすると、その間のリアルタイム情報を集める必要がある。これ以外に経路がある場合には、それらについても同様にリアルタイム情報を集めて到達時間を求める。
【０１１８】
車載サーバ１１ｃは、図１３に概念的に示すように、ユーザの依頼を県道の通過エリア毎に分類し、その分類単位のタスク１，２，３などに分けて、そのタスクを行うＡＩモジュール１，２，３などを作成し、通過時間を調査する。それぞれの通過時間を受け取ると、目的地までの走行時間が精度良く推定できる。
【０１１９】
図１４は、ＡＩモジュールが生成するＡＩエージェントの設定事項を示しており、ＡＩモジュールＩＤ、ターゲットネットワークＩＤ、スクリプトテキスト、検索エリア、回答データ（単位）、回答期限、ＡＩモジュール寿命、オプション等を含むものである。
【０１２０】
次に、図１５を参照して、ＡＩエージェントの具体的な構成の一例を示す。ＡＩモジュールＩＤは、例えばＩＰｖ６形式の値を設定している。この中にＡＩモジュールを作成した車載サーバ１１ｃのＩＰが含まれている。そして回答データが自動的に車載サーバ１１ｃへ戻るようになっている。これにはタスクＩＤまで含ませてもよい。設定例としては、例えば、
「１２ＤＥ：０９ａ１：３３３Ｆ：ＦＦＦＦ：１２ＤＥ：０９ａ１：３３３Ｆ：ＦＦＦＦ」
である。
【０１２１】
ターゲットネットワークＩＤは、例えば、設定エリアにあるサーバ（ネットワーク）のＩＰを設定し（複数ある場合には複数を設定）、その設定には関連情報のデータベースに事前にアクセスして絞り込むようにしておく。ＡＩエージェントのアクセスレベルは、パブリック、プライベート１、プライベート２、アドミニストレータ等アクセス権限を分けるようにする。なお、通常はパブリックに設定される。
【０１２２】
スクリプトテキストは、例えば、
「県道○○線Ａ−Ｂ地点の通行車両の通過時間を複数の通過車両の通過時間から算定する。」
などであり、これはコマンドとデータを順に並べて記載するようにしてもよい。
【０１２３】
検索エリアは、緯度範囲、経度範囲内のサーバ、あるいは関連エリアの情報データベースを持つリソース管理会社１３のサーバなどを対象とする。回答データは、例えば、
「県道○○線Ａ−Ｂ地点の車両通過時間（単位分）」
などとして設定する。データ形式は、テキスト、バイナリ、ＸＭＬなど設定することができるが、汎用性の高いＸＭＬ形式で設定することが望ましい場合が多くなっている。
【０１２４】
回答期限は、例えば３０秒といった時間に設定される。また、ＡＩエージェント寿命は、例えば３５秒といった時間に設定される。オプション１として、ＡＩエージェントを受入れたサーバが、そのＡＩエージェントも寿命が終わったこと（消去した）を送信元に連絡するように受入先サーバに依頼しておく条件や、オプション２として、回答期限延長条件などを設定する。この回答期限延長条件は、処理が指定時間内で完了しなかった場合、時間延長するか、それとも時間が来たら処理を止めるかなどを設定するものである。
【０１２５】
ここで、検索されるサーバには位置座標が設定される。対象となる車両にサーバが搭載されている場合、車両の移動によって検索エリアから外れる場合がある。その場合、指定した検索エリアから外れた車両については検索対象から外すことが可能になる。
【０１２６】
車載サーバ１１ｃは、目的地周辺のネットワークを検索するために、キーワードを用いて、どのネットワークのどのサーバにどのような情報があるかの概略情報を得る。その結果をもとに、車載サーバ１１ｃは、複数のＡＩモジュールを作る。
【０１２７】
ＡＩモジュールは、最初に返信するＡＩエージェントが活動する概略検査ネットワークエリアと検索キーを決定し、ＡＩエージェントをその検査ネットワークエリアのサーバに送る。複数のＡＩエージェントのうち、最初に車載サーバ１１ｃから送られたＡＩエージェントは、受入れられたネットワークのリソースに応じて、作業する範囲と作業内容を決定し車載サーバ１１ｃへ連絡する。作業する範囲と作業内容は、ＡＩエージェントを受入れたサーバが適宜決定する。
【０１２８】
図１６に示すように、最初のＡＩエージェントが、ＡＩモジュールに返す情報は下記のようになる。ＡＩモジュールＩＤは、上述と同様にＩＰｖ６形式の値をつける。送信先のターゲットネットワークＩＤは車載サーバのＩＤを設定する。調査範囲サーバＩＰは調査を行うことが認証されたサーバのＩＰ（ＡＩエージェント受入サーバで決定）に設定する。
【０１２９】
認証番号は、ＡＩエージェントが受け入れられた結果を示す認証番号であり、これは、受入先サーバが発行するものである。この認証番号の値からＡＩエージェントと受入先サーバがいつ処理を開始したかを後で見なおすことができるようになっている。調査分類範囲は、ＡＩエージェントが調査するカテゴリ（あるいはキーワード）である。
【０１３０】
ＡＩモジュールは、次のＡＩエージェントの作業内容を第１のＡＩエージェントと重複しないように設定し、目的のサーバ（ネットワーク）へ送信する。以後、車載サーバから送信されるＡＩエージェントに同様な設定がなされるようになっている。
【０１３１】
ＡＩエージェントが受け入れられると、受入先のサーバは、ＡＩエージェントに含まれるスクリプトまたはコマンドを読み出してＡＩエージェントの目的を実行する。この時、受入先サーバは、ＡＩエージェントの要求内容を分析し、パブリックエリアの情報で回答可能、すなわち目的のデータが得られれば（例えば、受入先サーバが、パブリックエリアに車両通行時間のデータベースを持っていれば）、それをＡＩエージェントの応答データに入れて、車載サーバ１１ｃへ返すようになる。
【０１３２】
（具体的事例その２）
ＡＩエージェントの別の形として、ＡＩエージェントが一つのアプリケーションとして受入サーバでオープンされ、ＡＩエージェントに含まれるスクリプトを順次実行して結果を求め、結果を車載サーバへ戻すようにすることもできる。
【０１３３】
スクリプトの具体例としては、例えば、
「県道○○線Ａ−Ｂ地点の通行車両の通過時間を複数の通行車両の通過時間から算定する」
というものである。
【０１３４】
このために、ＡＩエージェントが、車載サーバ１１ｃから情報処理支援装置である交通管理用サーバ１２に送られる場合を記述する。
【０１３５】
（１）車載サーバ１１ｃは、ＡＩエージェントを交通管理サーバに送信する。
（２）交通管理サーバ１２はＡＩエージェントを認証する。
（３）交通管理サーバ１２はＡＩエージェント認証結果を車載サーバに送信する。
（４）交通管理サーバ１２は、ＡＩエージェントの動作部（スクリプト）を翻訳し、ＡＩエージェントの目的が達成できるようにソフトウェアを構成する。また交通管理サーバ１２がもつデータベースを検索し、目的のデータ（ＸＸ時のＡ地点とＢ地点の走行時間のデータ）を探す。
【０１３６】
（５）交通管理サーバ１２は、目的のデータ（複数の車両のＡ−Ｂ間の走行時間、または走行速度が見つかるとそれを処理し、Ａ−Ｂ間の走行時間の回答を出す。
（６）交通管理サーバ１２は、設定されたデータ構成を形成して、車載サーバ１１ｃに回答を返す。オプション関連データ送付が必要であれば、それらも同時に車載サーバ１１ｃへ送る。
（７）回答を受けた車載サーバ１１ｃは、回答が十分なものであれば受信完了を返す。
（８）一方、回答が不十分であれば（たとえばサンプル数が少なくて精度が悪い場合）、車載サーバ１１ｃは、新規スクリプト（同様な交通状況の日の平均走行速度）を構成して交通管理サーバ１２へ送る。
（９）交通管理サーバ１２は、受信したデータが受信済みのＡＩエージェントであれば、そこへスクリプトを送り、再度データ検索を行う。
（１０）結果が得られれば、交通管理サーバ１２は再度車載サーバ１１ｃへ回答を返す。
（１１）交通管理サーバ１２は、ＡＩエージェントの寿命がくると、ＡＩエージェントを消去する。
【０１３７】
ＡＩエージェントは、送信先サーバに到着して受付がされた時に応答を返し、以後は結果がでるまで、あるいはタイムオーバになったときだけ応答を返すようにする。そのため、通常のネットワークの処理のように随時サーバ間の通信をしなくても良いため、ネットワークのトラフィックを抑えることができる。
【０１３８】
（具体的事例その３）
別の例として、地点Ａ‐Ｂを走行する車載サーバ１１ｃをリアルタイムでモニタし、実際の車両速度を得る例を示す。
（１）自車の車載サーバ１１ｃは、地点Ａ‐Ｂ間を走行する車両のサーバ１２（情報処理支援装置）を検索する。
（２）検索した結果、地点Ａ−Ｂ間を走行する車両があれば、そのＩＰを調べ、その車両のサーバ１２にＡＩエージェントを送る。
（３）ＡＩエージェントが送られた車両のサーバ１２が、ＡＩエージェントのアクセスを許せば、ＡＩエージェントは車両速度、走行時間、車両の周囲の状況の情報等を車速センサ（あるいは測定結果メモリエリア）や車載カメラ等を利用して十分な情報を収集する。あるいは、ＡＩエージェントに添付されたスクリプトを他車の車載サーバ１２で実行する。
【０１３９】
（４）必要な情報が集まると、ＡＩエージェント（あるいは他車のサーバ１２）は自車の車載サーバ１１ｃへ結果を返す。
（５）車載サーバ１１ｃは，複数の車両から同様な情報を集め、正確な通行時間情報を得る。
（６）他車のサーバ１２にアクセスする場合、アクセスしている時間に応じて利用料金を計算する（アクセスが有料設定なら）。
【０１４０】
（具体的事例その４）
次に、車上での画像編集を行う場合のＡＩエージェントの動作の例について説明する。ここでは、自車には望遠カメラがなく撮りたい景色を撮影できない場合、他車の望遠カメラを利用して景色を撮影し、それを車内で加工する例を示す。この時、車内には加工ソフトがなく、外部から加工ソフトのリソースを持ってい来る例を示す。
【０１４１】
（１）車載サーバ１１ｃは、ユーザから、撮影位置を指定した写真を撮影し、それらをまとめて１つの画面を作成するように依頼される。これは、例えば、ドライブ記録アルバムの作成をする場合などである。しかし、車載サーバ１１ｃは指定されたアングル（例えば望遠）が自車のカメラでは不可能と判定したとする。また、写真をまとめる機能を保持していないと判定したとする。
【０１４２】
（２）車載サーバ１１ｃは周辺の車両のサーバ１２にアクセスし、指定されたアングルで撮影できる車両があるかをＡＩエージェントを送って調査する。
（３）ＡＩエージェントのスクリプトには、ユーザの希望するアングルが指定されており、他車のカメラの画像が指定条件を満たした時、その画像をキャプチャする。
（４）他車でキャプチャされた画像リソースは、ＡＩエージェントにより自車の車載サーバ１１ｃに送られる。
【０１４３】
（５）並行して、車載サーバ１１ｃは写真をまとめる画像ソフトモジュール（リソース）を検索するために、ネットワークを検索し、関連リソースを持つリソースサーバへＡＩエージェントを送る。そのＡＩモジュールのスクリプトには検索条件（写真画像編集機能、拡大縮小、コンポジット、重ね合わせ、レイヤ構成等）が含まれる。
【０１４４】
（６）リソースサーバ１２は車載サーバ１１ｃへ必要なリソースを送る。ここで、対価が必要ならこの時点で支払処理を行うことになる。
（７）車載サーバ１１ｃは、他車から受信したデータを画像編集リソースを用いてユーザの好みに合うように編集する。編集の途中段階でユーザに結果を見せ、その結果がユーザの満足が得られるまで、編集ソフト（受信リソース）を用いる。
【０１４５】
（具体的事例その５）
次に、通信販売品の購入をする場合の具体例について説明する。例えば、ユーザがデジタル放送で知った商品を直ぐに購入するために、それが販売される目的の場所に行く例を示す。
【０１４６】
ユーザは車両で、自分が購入したい物品の情報をデジタル放送から入手（見たり聞いたりして）する。この時、ユーザには品名が聞こえたが、それがいつどこで販売されるかが聞き取れなかったとする。
【０１４７】
ユーザは車載サーバ１１ｃに、完全に聞き取れなかった情報の一部を検索キーワードにして、デジタル放送を検索するようにサーバに依頼する。車載サーバ１１ｃは、メディア車載機１２に、過去のユーザが聴取した放送プログラムを呼び出させて、その中から検索キーワードに適合する部分を複数選択させる。
【０１４８】
車載サーバ１１ｃは、メディア車載機１２が選択したいくつかの候補を選び、ユーザに提供する。ユーザは、適合するものがあれば、それを車載サーバ１１ｃに示すことで、車載サーバ１１ｃはユーザが情報を得た放送プログラムの必要な部分を確定する。
【０１４９】
車載サーバは１１ｃ、ここで、ユーザに対して、ユーザが希望する内容を問い合わせる。例えば、ユーザが品物をすぐに購入するために、販売場所まで今すぐに短時間で行きたいと応答した場合、車載サーバ１１ｃは販売場所までのルート情報を確定したデジタル放送プログラムをもとに検索する。この場合、例えば、今日の走行スケジュールが設定されている場合に、その合間に行くためにはどのように車両走行移動を行うかということも考慮することができる。
【０１５０】
ユーザが購入したい製品を販売する販売会社名がデジタル放送のデータに含まれていれば、そのデータを検索キーに使って、販売場所を検索することができる。これは、販売場所の中に販売会社へのリンクデータが埋め込まれていたり、逆に、販売会社データに販売情報のリンクデータが埋め込まれているように放送プログラムが作成されているということが前提条件となる。
【０１５１】
この場合、メディア車載機１２は、車両に送られたさまざまなデジタル情報をユーザの要求に応じて切替え、ユーザがいつ、何を聴取していたかの履歴を記録する。メディア車載機１２が記録したデジタル情報データには、複数の関連情報と連携できるリンクデータ（例えばＵＲＬアドレス）が含まれている。メディア車載機１２は、ユーザが設定した番組を別途記録することが可能なように構成されている。
【０１５２】
ユーザは通信メディアから得た情報を確認するために、自分が聞いた情報をプレイバックし、キーワードを探して情報検索を行うことができる。ここで、通信メディア情報はデジタル信号化されて車両に送られてくるため、車両に通信メディア記録手段が搭載されている。ユーザは自分が聞いた情報（音声）を再確認できる。
【０１５３】
また、音声情報は情報検索等でテキスト情報が必要になった場合、テキスト情報に変換される。あるいは、あらかじめテキスト情報が音声と同時に送信されている場合、そのテキスト情報を検索キーにして情報検索を用いるようにしてもよい。また、デジタル放送の信号にＵＲＬのような必要な情報に接続（リンク）するための情報を含むようにすれば、ドライバはその情報を利用して即座に関連情報サイトにアクセスすることが可能になる。
【０１５４】
各サイトへアクセスする際、ユーザがいわゆるブラウザを使って検索する場合、一度に多くのサーバにアクセスして情報を得ることは難しい。そのため、車載サーバはＡＩモジュールを多くの関連リンクのサーバに送付して、同時に多くの情報を集めるようにする。
【０１５５】
上記のようにＡＩエージェントは、スクリプトを含み、そこにユーザの嗜好、価格範囲等を入れておく。このようにして、一度に多くのＷＥＢサイトを検索し、短時間で多くの情報を集めることができる。集めた情報は車載サーバ１１ｃに集めることで、以後の加工が容易に行える。
【０１５６】
（具体的事例その６）
次に、データ収集および加工の例について述べる。ユーザが走行中に、オフィスのユーザ用ＰＣ１１ｂのデータファイルを検索して、必要なファイルが見つかれば走行中の車両に見つかったファイルを転送し表示する。もし、必要なデータがユーザ用ＰＣ１１ｂに見つからなかった場合、ＡＩエージェントがオフィスネットワークに送られ、ドライバの希望するファイルに類似のファイルをネットワークから選択して、データを再構成し車両（ドライバ）に転送する。
【０１５７】
もし、ドライバの希望する情報データがそのネットワークになければ、ＡＩエージェントは、オフィスのネットワークのアクセス可能エリアからそれらを検索し、ドライバの希望するデータを探索し、必要なら探索データを加工して、ドライバへ送る。
【図面の簡単な説明】
【図１】本発明の一実施形態を示すシステムの概略的構成図
【図２】携帯情報処理機の電気的なブロック構成図
【図３】携帯情報処理機の概略的な処理の流れ図
【図４】携帯情報処理機の処理プログラムのフローチャート（その１）
【図５】携帯情報処理機の処理プログラムのフローチャート（その２）
【図６】リソース管理システムの作用説明図
【図７】リソース管理会社から外部機器へのデータ転送の概念図
【図８】携帯情報処理機、リソース管理会社および外部機器の動作を相互関係を持って示す流れ図
【図９】外部機器との協調動作を示す作用説明図（その１）
【図１０】リソースマネージャのアプリ構築の流れを説明する図
【図１１】外部機器との協調動作を示す作用説明図（その２）
【図１２】ＡＩモジュールと他のＰＣとの間の動作を示す流れ図
【図１３】ユーザ依頼に基づいたタスクの構成説明図
【図１４】ＡＩモジュールの設定事項の説明図
【図１５】ＡＩエージェントの構成例を示す図
【図１６】ＡＩエージェントがＡＩモジュールに返す情報の説明図
【符号の説明】
１は携帯情報処理機（情報処理装置）、４はマイクロホン、５はスピーカ、６はＣＣＤカメラ、１０はネットワーク、１１ａ〜１１ｄはＰＣ（外部機器、情報処理装置）、１２は外部機器（情報処理支援装置）、１３はリソース管理会社のサーバ、１４は制御回路である。

Claims

外部から情報処理の依頼を受ける受付手段と、
この受付手段により受け付けた依頼情報処理を自己のリソースを用いて実行可能か否かを判定する判定手段と、
この判定手段により実行不可能と判定されたときに不足リソースを探索して外部から収集可能か否かを判定する探索手段と、
この探索手段により収集可能と判定されたときにその不足リソースをダウンロードするかまたは外部リソースを用いて協調動作で処理するかをユーザに問い合わせる手段と、
前記探索手段により不足リソースがハードウェアであると判定されると共に前記問い合わせ手段により問い合わせした結果前記外部リソースを用いて協調動作で処理するとユーザにより選択入力された場合、その不足リソースのハードウエアを利用可能な情報処理支援装置を探索してそのハードウェアで行うべき情報処理を依頼する処理依頼手段と、
前記問い合わせ手段により問い合わせした結果、不足リソースをダウンロードして処理するとユーザにより選択入力された場合、不足リソースをダウンロードする手段と、
前記ダウンロードして処理する場合または前記外部リソースを用いた協調動作を行うときには、ユーザの依頼に対応するための当該ユーザのメッセージタイプを認識し当該メッセージタイプに応じた動作をなすアプリを構築する処理を実行する実行手段と、
前記外部リソースを用いた協調動作を行った場合には前記処理依頼手段が情報処理を依頼した情報処理支援装置から前記情報処理結果を受け取る受領手段とを備えたことを特徴とする情報処理装置。
請求項１記載の情報処理装置において、
前記受付手段は、
人が音声により入力する情報処理の依頼を受け付ける入力手段と、
この入力手段により入力された音声情報を、呼びかけ、説明、依頼、質問、確認、応答などの各メッセージタイプに分類し、当該分類されたメッセージタイプから前記実行手段が実行可能な情報として解釈する依頼解釈手段とを備えていることを特徴とする情報処理装置。
ネットワークを介して情報処理装置からアクセス可能に設けられ、請求項１または２記載の情報処理装置により前記不足リソースの収集依頼を受けるとこれに応じてその不足リソースを提供するリソース提供手段を備えたことを特徴とする情報処理支援装置。
請求項３に記載の情報処理支援装置において、
前記リソース提供手段により前記不足リソースがハードウェアであると判定されたときに、その不足リソースのハードウエアを利用可能な他の情報処理支援装置を探索してそのハードウェアで行うべき情報処理を依頼する処理依頼手段を備えたことを特徴とする情報処理支援装置。
請求項１に記載の情報処理装置もしくは請求項４に記載の情報処理支援装置の処理依頼手段により前記不足リソースのハードウェアの利用依頼を受けたときに、対象となったハードウェアで行うべき情報処理を受け付けてこれを処理する処理手段と、この処理手段による処理結果を前記情報処理装置の受領手段に渡す送信手段とを備えたことを特徴とする情報処理支援装置。
請求項３ないし５のいずれかに記載の情報処理支援装置において、
自己が備えるリソースが、前記情報処理装置の外部リソースとして用いられる場合に、前記情報処理装置の不足リソースの収集要求に応じて協同して前記依頼情報処理を実行することを特徴とする情報処理支援装置。
請求項１または２記載の情報処理装置と、
ユーザから命令を受けたときに、本体のハードウェアだけでその命令を処理できるか否かを判定する判定手段と、
この判定手段により本体のみでその命令が処理できないと判定されたときに、外部の情報処理支援装置に一時的に移動して当該外部の情報処理支援装置内のリソースを利用してアクセス許可範囲内で必要な処理を完了させるＡＩエージェントを生成するＡＩエージェント生成手段とを備え、
前記ＡＩエージェントを、前記情報処理支援装置内で内部に保有するリソースを利用して必要な処理を完了させて、その完了結果を移動前の場所に転送させた後、必要な処理が完了すると自己消滅するように構成したことを特徴とする情報処理支援システム。