(57)【特許請求の範囲】
【請求項１】
クライアントサーバ環境下にある自装置の通信先となる他方の装置との間で双方向通信を行うために動作される複数のスレッドのうち、前記他方の装置へ送信するデータを保持する送信キューにデータが格納されるのを待機しているスレッドの数が所定の閾値以上であるか否かを判定する判定部と、
前記判定部によって前記スレッドの数が所定の閾値以上であると判定された場合には、空のリクエストもしくは空のレスポンスを送信するようにスレッドを機能させ、前記スレッドの数が所定の閾値未満であると判定された場合には、前記送信キューにデータが格納されるまで待機した後に当該送信キューに格納されたデータを通信データの本体として埋め込んでリクエストまたはレスポンスを送信するようにスレッドを機能させるスレッド制御部と
を有することを特徴とする情報処理装置。
【請求項２】
前記送信キューにデータを格納するアプリケーションによって生成されるデータの生成状態もしくは前記送信キューに格納されているデータの格納量に応じて、前記判定部によって用いられる前記閾値を変更する閾値変更部をさらに有することを特徴とする請求項１に記載の情報処理装置。
【請求項３】
クライアントとして機能する第１の装置と、サーバとして機能する第２の装置とに用いられる通信制御方法であって、
前記第１の装置が、
前記第２の装置との間で双方向通信を行うために動作される複数のスレッドのうち、前記第２の装置へ送信するデータを保持する送信キューにデータが格納されるのを待機しているスレッドの数が所定の閾値以上であるか否かを判定する判定ステップと、
前記判定ステップによって前記スレッドの数が所定の閾値以上であると判定された場合には、空のリクエストを送信するようにスレッドを機能させ、前記スレッドの数が所定の閾値未満であると判定された場合には、前記送信キューにデータが格納されるまで待機した後に当該送信キューに格納されたデータを通信データの本体として埋め込んでリクエストを送信するようにスレッドを機能させるスレッド制御ステップとを実行し、
前記第２の装置が、
前記第１の装置との間で双方向通信を行うために動作される複数のスレッドのうち、前記第１の装置へ送信するデータを保持する送信キューにデータが格納されるのを待機しているスレッドの数が所定の閾値以上であるか否かを判定する判定ステップと、
前記判定ステップによって前記スレッドの数が所定の閾値以上であると判定された場合には、空のレスポンスを送信するようにスレッドを機能させ、前記スレッドの数が所定の閾値未満であると判定された場合には、前記送信キューにデータが格納されるまで待機した後に当該送信キューに格納されたデータを通信データの本体として埋め込んでレスポンスを送信するようにスレッドを機能させるスレッド制御ステップと
を実行することを特徴とする通信制御方法。
【請求項４】
コンピュータに、
クライアントサーバ環境下にある自装置の通信先となる他方の装置との間で双方向通信を行うために動作される複数のスレッドのうち、前記他方の装置へ送信するデータを保持する送信キューにデータが格納されるのを待機しているスレッドの数が所定の閾値以上であるか否かを判定する判定手順と、
前記判定手順によって前記スレッドの数が所定の閾値以上であると判定された場合には、空のリクエストもしくは空のレスポンスを送信するようにスレッドを機能させ、前記スレッドの数が所定の閾値未満であると判定された場合には、前記送信キューにデータが格納されるまで待機した後に当該送信キューに格納されたデータを通信データの本体として埋め込んでリクエストまたはレスポンスを送信するようにスレッドを機能させるスレッド制御手順と
を実行させることを特徴とする通信制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置、通信制御方法及び通信制御プログラムに関する。
【背景技術】
【０００２】
ネットワーク（network）を介して各種のサービス（service）を提供する仕組みが知られている。一例としては、家庭や公共の空間でロボット（robot）によるインタネット（internet）を介したサービスを提供するロボットサービスが提案されている。
【０００３】
かかるロボットサービスを提供する場合には、ロボットが収容されるファイアウォール（firewall）を通過して所定のサーバ（server）へアクセス（access）できることが求められる。さらには、ロボットがローカルアドレス（local  address）しか有していない場合でも、ロボット及びサーバ間で双方向通信が実行できることも求められる。
【０００４】
これらの要求を満たすために、ロボットを起点としてＨＴＴＰ（HyperText  Transfer  Protocol）による通信を実現する通信方式がＲＳｉ（Robot  Service  initiative）により策定されている。
【０００５】
この通信方式では、ロボットからサーバへデータ転送を行うための上り用の通信路と、サーバからロボットへデータ転送を行うための下り用の通信路との２つの通信路がそれぞれ使用される。なお、ロボット及びサーバは、相手先へ送信するデータを保持する送信キュー（queue）及び相手先から受信したデータを保持する受信キューをそれぞれ有するものとする。
【０００６】
一例として、ロボットからサーバへの上り通信を行う場合を想定する。この場合には、ロボット側で上り用のＨＴＴＰ通信のセッション（session）を実現するロボット側の上りＨＴＴＰスレッド（thread）は、ロボットの送信キューにデータが保持されているか否かを監視する。このとき、ロボットの送信キューにデータが保持されると、ロボット側の上りＨＴＴＰスレッドは、送信キューに保持されたデータをＨＴＴＰリクエストのペイロード（payload）へ埋め込んでサーバへ送信する。一方、サーバ側で上り用のＨＴＴＰ通信のセッションを実現するサーバ側の上りＨＴＴＰスレッドは、ＨＴＴＰリクエストのペイロードに埋め込まれていたデータをサーバの受信キューに保持させるとともに、空のＨＴＴＰレスポンスをロボットへ応答する。このようにして、ロボットからサーバへのデータ転送が上り用の通信路のＨＴＴＰリクエストにより実現される。
【０００７】
他の一例として、サーバからロボットへ下り通信を行う場合を想定する。この場合には、ロボット側で下り用のＨＴＴＰ通信のセッションを実現するロボット側の下りＨＴＴＰスレッドは、予め空のＨＴＴＰリクエストをサーバへ送信する。一方、サーバ側で下り用のＨＴＴＰ通信のセッションを実現するサーバ側の下りＨＴＴＰスレッドは、サーバの送信キューにデータが保持されるまでロボットから受信したＨＴＴＰリクエストに対するレスポンスを保留状態とする。そして、サーバの送信キューにデータが保持されると、サーバ側の下りＨＴＴＰスレッドは、ＨＴＴＰリクエストの保留状態を解除し、送信キューに保持されたデータをＨＴＴＰレスポンスのペイロードへ埋め込んでロボットへ送信する。また、ロボット側の下りＨＴＴＰスレッドは、ＨＴＴＰレスポンスのペイロードに埋め込まれていたデータをロボットの受信キューに保持させるとともに、空のＨＴＴＰリクエストをロボットへ再び送信する。このようにして、サーバからロボットへのデータ転送が下り用の通信路のＨＴＴＰレスポンスにより実現される。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特表２００２−５１７８５７号公報
【特許文献２】特開２００３−５８４３９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
しかしながら、上記の従来技術では、上り用の通信路と下り用の通信路とを固定して使用するので、上り通信のＨＴＴＰレスポンスおよび下り通信のＨＴＴＰリクエストが実態的なデータ転送に利用されず、通信路を有効活用することができないという問題がある。
【００１０】
例えば、上り通信を行う場合には、ロボットがサーバへ送信するＨＴＴＰリクエストはロボットの送信キューにあるデータをサーバへ転送するのに利用できる。ところが、サーバがロボットへ送るＨＴＴＰレスポンスは、ＨＴＴＰリクエストに対する形式的な応答が空のレスポンスとしてなされるに過ぎず、サーバからロボットへのデータ転送は実態的になされない。また、下り通信を行う場合には、サーバがロボットへ送信するＨＴＴＰレスポンスはサーバの送信キューにあるデータをロボットへ転送するのに利用できる。ところが、ロボットがサーバへ送るＨＴＴＰリクエストは、サーバの送信キューにデータが保持される時のために空のリクエストとしてなされるに過ぎず、ロボットからサーバへのデータ転送は実態的になされない。
【００１１】
開示の技術は、上記に鑑みてなされたものであって、通信路を有効活用することができる情報処理装置、通信制御方法及び通信制御プログラムを提供することを目的とする。
【課題を解決するための手段】
【００１２】
本願の開示する情報処理装置は、判定部と、スレッド制御部とを有する。前記判定部は、クライアントサーバ環境下にある自装置の通信先となる他方の装置との間で双方向通信を行うために動作される複数のスレッドのうち、送信キューにデータが格納されるのを待機しているスレッドの数が所定の閾値以上であるか否かを判定する。前記送信キューは、前記他方の装置へ送信するデータを保持する。前記スレッド制御部は、自装置で動作するスレッドの動作を制御する。前記スレッド制御部は、前記判定部によって前記スレッドの数が所定の閾値以上であると判定された場合には、空のリクエストもしくは空のレスポンスを送信するようにスレッドを機能させる。前記スレッド制御部は、前記スレッドの数が所定の閾値未満であると判定された場合には、それ以降に前記送信キューに格納されるデータを通信データの本体として埋め込んでリクエストまたはレスポンスを送信するようにスレッドを機能させる。
【発明の効果】
【００１３】
本願の開示する情報処理装置の一つの態様によれば、通信路を有効活用することができるという効果を奏する。
【図面の簡単な説明】
【００１４】
【図１】図１は、実施例１に係る情報処理装置の構成を示すブロック図である。
【図２】図２は、実施例２に係るクライアントサーバシステムのシステム構成を示す図である。
【図３】図３は、実施例２に係るロボットの構成を示すブロック図である。
【図４】図４は、共有データの一例を示す図である。
【図５】図５は、実施例２に係るサーバの構成を示すブロック図である。
【図６】図６は、共有データの一例を示す図である。
【図７】図７は、実施例２に係るＨＴＴＰロボットスレッドに実行される処理の手順を示すフローチャートである。
【図８】図８は、実施例２に係るＨＴＴＰサーバスレッドに実行される処理の手順を示すフローチャートである。
【図９】図９は、実施例３に係る通信制御プログラムを実行するコンピュータの一例について説明するための図である。
【発明を実施するための形態】
【００１５】
以下に、本願の開示する情報処理装置、通信制御方法及び通信制御プログラムの実施例を図面に基づいて詳細に説明する。なお、この実施例は開示の技術を限定するものではない。
【実施例１】
【００１６】
図１は、実施例１に係る情報処理装置の構成を示すブロック図である。図１に示すように、情報処理装置１は、判定部１ａと、スレッド制御部１ｂとを有する。
【００１７】
判定部１ａは、クライアントサーバ環境下にある自装置の通信先となる他方の装置との間で双方向通信を行うために動作される複数のスレッドのうち、送信キューにデータが格納されるのを待機しているスレッドの数が所定の閾値以上であるか否かを判定する。この送信キューとは、他方の装置へ送信するデータを保持するキューを指す。
【００１８】
スレッド制御部１ｂは、情報処理装置１で動作するスレッドの動作を制御する。例えば、スレッド制御部１ｂは、判定部１ａによってスレッドの数が所定の閾値以上であると判定された場合に、空のリクエストもしくは空のレスポンスを送信するようにスレッドを機能させる。一例として、情報処理装置１がクライアントとして機能する場合には、クライアントからサーバへデータ転送を行う上り用の通信路として機能するスレッドが十分に存在する場合にその逆の下り用の通信路としてスレッドを機能させることができる。他の一例として、情報処理装置１がサーバとして機能する場合には、下り用の通信路として機能するスレッドが十分に存在する場合に上り用の通信路としてスレッドを機能させることができる。
【００１９】
また、スレッド制御部１ｂは、スレッドの数が所定の閾値未満であると判定された場合に、送信キューにデータが格納されるまで待機した後にそのデータを通信データの本体として埋め込んでリクエストまたはレスポンスを送信するようにスレッドを機能させる。一例として、情報処理装置１がクライアントとして機能する場合には、上り用の通信路として機能するスレッドが十分に存在しない場合に上り用の通信路としてスレッドを機能させることができる。他の一例として、情報処理装置１がサーバとして機能する場合には、下り用の通信路として機能するスレッドが十分に存在しない場合に下り用の通信路としてスレッドを機能させることができる。
【００２０】
このように、本実施例に係る情報処理装置１は、上り用の通信路として機能させるスレッド及び下り用の通信路として機能させるスレッドを機動的に変更できる。このため、本実施例に係る情報処理装置１では、上り用の通信路と下り用の通信路とを固定する場合に比べて、上り通信で発生する空のレスポンスの送信回数及び下り通信で発生する空のリクエストの送信回数を低減できる。また、本実施例に係る情報処理装置１では、スレッドを機動的に変更しても、各通信路として機能させるスレッドを適切な数に保つことができる。それゆえ、本実施例に係る情報処理装置１によれば、通信路を有効活用することが可能になる。さらに、本実施例に係る情報処理装置１では、通信路の数を増減させる場合に上り専用の通信路及び下り専用の通信路の２つを１組として拡張または縮退せずとも、通信路の数をよりきめ細やかに増減させることができる。
【実施例２】
【００２１】
［システム構成］
続いて、実施例２に係るクライアントサーバシステムについて説明する。図２は、実施例２に係るクライアントサーバシステムのシステム構成を示す図である。図２の例では、サーバ３０がネットワーク２０を介して気象情報や防災情報などの各種の情報をロボット１０へ通知したり、また、ロボット１０がロボット１０の異常可否やセンサ出力をサーバ３０へ通知したりする場合を想定する。
【００２２】
図２に示すように、クライアントサーバシステム（client  server  system）は、ロボット１０と、サーバ３０とを有する。これらロボット１０及びサーバ３０は、ネットワーク２０を介して、相互に通信可能に接続される。なお、ネットワーク２０には、インターネット（Internet）、ＬＡＮ（Local  Area  Network）やＶＰＮ（Virtual  Private  Network）などの任意の種類の通信網を採用できる。
【００２３】
ロボット１０は、情報サービスや物理サービスなどの各種のサービスを提供するサービスロボットである。情報サービスの一例としては、サーバ３０からネットワーク２０を介して受信した気象情報や防災情報などを表示デバイスや音声出力デバイスを介して出力するサービスが挙げられる。また、物理サービスの一例としては、サーバ３０からネットワーク２０を介して受信した遠隔操作情報にしたがって荷物を搬送する搬送サービスや施設内の警備を行う警備サービスなどが実行される。
【００２４】
なお、ロボット１０は、サーバ３０からデータを受信するだけではなく、サーバ３０へデータの送信も行う。一例としては、ロボット１０は、ロボット１０に設けられた各種のセンサ（sensor）、例えば音声、画像、温度や湿度などを検出するセンサの出力をサーバ３０へ送信することにより、ロボット１０のセンサ情報をサーバ３０へアップロード（upload）する。他の一例としては、ロボット１０は、自装置が正常または異常であるのかをサーバ３０へ定期的に送信することもできる。
【００２５】
サーバ３０は、クライアント端末であるロボット１０にデータ配信を行うコンピュータ（Computer）である。一例としては、外部装置からネットワーク２０を介して収集した気象情報や防災情報などをロボット１０へ送信する。なお、サーバ３０は、ロボット１０へデータを送信するだけではなく、ロボット１０からもデータを受信する。一例としては、サーバ３０は、ロボット１０からネットワーク２０を介してセンサ情報を受信することにより、ロボット１０の管制を行う。
【００２６】
ここで、図２に示すロボット１０及びサーバ３０の間では、ロボットを起点としてＨＴＴＰ（HyperText  Transfer  Protocol）による通信を実現する通信方式が採用されるものとする。かかる通信方式を採用するのは、ロボット１０及びサーバ３０の間におけるファイアウォールの有無に関係なく、また、ロボットがローカルアドレスしか保有していない場合でも、ロボット１０及びサーバ３０の間の双方向通信を行うためである。
【００２７】
これを説明すると、ロボット１０及びサーバ３０には、ＨＴＴＰ通信のセッションを確立することによりロボット１０及びサーバ３０間の通信路を生成する通信制御プログラムがそれぞれインストール（install）される。ここでは、ロボット１０にインストールされる通信制御プログラムをロボット向けの通信制御プログラムと呼び、サーバ３０にインストールされる通信制御プログラムをサーバ向けの通信制御プログラムと呼ぶ。
【００２８】
このうち、ロボット向けの通信制御プログラムが動作するロボット１０では、サーバ３０との間でＨＴＴＰセッションを確立するスレッドがＨＴＴＰロボットスレッド１８Ａ及びＨＴＴＰロボットスレッド１８Ｂとして動作する。また、サーバ向けの通信制御プログラムが動作するサーバ３０では、ロボット１０との間でＨＴＴＰセッションを確立するスレッドがＨＴＴＰサーバスレッド３８Ａ及びＨＴＴＰサーバスレッド３８Ｂとして動作する。図２に示す例では、同一のセッションを確立するスレッドの符号にはその末尾に同一の大文字アルファベットを付している。なお、以下では、ＨＴＴＰロボットスレッド１８Ａ及び１８Ｂを区別なく総称する場合にはＨＴＴＰロボットスレッド１８と表記し、また、ＨＴＴＰサーバスレッド３８Ａ及び３８Ｂを区別なく総称する場合にはＨＴＴＰサーバスレッド３８と表記する。
【００２９】
このように、ロボット１０及びサーバ３０では、両者の間で確立されたＨＴＴＰ通信のセッションの数と同数の組のＨＴＴＰロボットスレッド１８及びＨＴＴＰサーバスレッド３８が動作する。
【００３０】
これらＨＴＴＰロボットスレッド１８Ａ及びＨＴＴＰサーバスレッド３８Ａと、ＨＴＴＰロボットスレッド１８Ｂ及びＨＴＴＰサーバスレッド３８Ｂとは、いずれも上り用の通信路または下り用の通信路として固定使用されない。すなわち、ロボット１０及びサーバ３０は、上り用の通信路として機能させるスレッド及び下り用の通信路として機能させるスレッドを機動的に変更する。
【００３１】
一例として、図２に示す２組のＨＴＴＰロボットスレッド１８及びＨＴＴＰサーバスレッド３８が動作している場合、すなわち２つの通信路を用いる場合を想定してロボット１０及びサーバ３０間のデータ転送を説明する。
【００３２】
図２に示す符号１６ａは、サーバ３０へ送信するデータを保持する送信キューである。この送信キュー１６ａには、ロボット１０が特定のサービスを提供するためにインストールされたロボット用のアプリケーション、以下「ロボット用サービスアプリ」と記載によって生成されたデータがサーバ３０へ通知される場合に格納される。図２に示す符号１６ｂは、サーバ３０から受信したデータを保持する受信キューである。この受信キュー１６ｂに格納されたデータは、ロボット用サービスアプリにより使用される。図２に示す符号３６ｂは、ロボット１０へ送信するデータを保持する送信キューである。この送信キュー３６ｂには、ロボット１０が特定のサービスを提供するためにインストールされたサーバ用のアプリケーション、以下「サーバ用サービスアプリ」と記載によって生成されたデータがロボット１０へ通知される場合に格納される。図２に示す符号３６ａは、ロボット１０から受信したデータを保持する受信キューである。この受信キュー３６ａに格納されたデータは、サーバ用サービスアプリにより使用される。
【００３３】
図２に示すように、ロボット１０側のＨＴＴＰロボットスレッド１８は、サーバ３０からＨＴＴＰレスポンスを受信すると、ＨＴＴＰレスポンスのペイロードに埋め込まれているデータを受信キュー１６ｂへ格納する。そして、ＨＴＴＰロボットスレッド１８は、送信キュー１６ａのデータの有無を確認する。このとき、送信キュー１６ａにデータが存在する場合には、ＨＴＴＰロボットスレッド１８は、送信キュー１６ａに保持されているデータをＨＴＴＰリクエストのペイロードへ埋め込んでＨＴＴＰリクエストをサーバ３０へ送信する。また、既に送信キュー１６ａにデータが格納されるのを待機しているスレッドがある場合には、ＨＴＴＰロボットスレッド１８は、自スレッドを下り用の通信路として機能させるために、空のＨＴＴＰリクエストをサーバ３０へ送信する。
【００３４】
一方、サーバ側のＨＴＴＰサーバスレッド３８は、ロボット１０からＨＴＴＰリクエストを受信すると、ＨＴＴＰリクエストのペイロードに埋め込まれているデータを受信キュー３６ａへ格納する。そして、ＨＴＴＰサーバスレッド３８は、送信キュー３６ｂのデータの有無を確認する。このとき、送信キュー３６ｂにデータが存在する場合には、ＨＴＴＰサーバスレッド３８は、送信キュー３６ｂに保持されているデータをＨＴＴＰレスポンスのペイロードへ埋め込んでＨＴＴＰレスポンスをロボット１０へ送信する。また、既に送信キュー３６ｂにデータが格納されるのを待機しているスレッドがある場合には、ＨＴＴＰサーバスレッド３８は、自スレッドを上り用の通信路として機能させるために、空のＨＴＴＰレスポンスをロボット１０へ送信する。
【００３５】
一例として、防災情報を提供するサービス提供アプリがロボット１０及びサーバ３０で実行される場合を想定する。この場合には、ロボット１０からサーバ３０へ防災情報の配信要求を上り通信路を利用してリクエストし、サーバ３０により気象警報、例えば大雨警報や波浪警報の発令情報が収集されると、サーバ３０からロボット１０へ下り通信路でその情報を通知できる。
【００３６】
なお、図２の例では、ロボット１０及びサーバ３０の間で２つの通信路が生成される場合を例示したが、ロボット１０及びサーバ３０の間で生成される通信路は３つ以上であってもかまわない。一例としては、通信制御プログラムの開発者の設定により任意の通信路の数を生成することができる。他の一例としては、ロボット１０またはサーバ３０で動作するサービス提供用アプリが生成するデータ量に応じて任意の通信路の数を生成することもできる。
【００３７】
［ロボット１０の構成］
次に、本実施例に係るロボットの構成について説明する。図３は、実施例２に係るロボットの構成を示すブロック図である。図３に示すように、ロボット１０は、センサ類１１と、表示部１２と、通信インタフェース部１３と、制御部１４とを有する。なお、ロボット１０は、図３に示した機能部以外にも既知のサービスロボットが有する各種の機能部、例えば各種の入力デバイスや記憶デバイスの他、ロボット１０が自走を行うための駆動部等を有するものとする。
【００３８】
センサ類１１は、音声、画像、温度や湿度などを検出する各種のセンサである。例えば、音声を検出するセンサの一例としては、マイク（microphone）を適用できる。また、画像を検出するセンサの一例としては、ＣＣＤ（Charge  Coupled  Device）やＣＭＯＳ（Complementary  Metal  Oxide  Semiconductor）などの撮像デバイスを適用できる。これらの他にも、温度センサ、湿度センサや生体センサなどを適用することもできる。なお、センサ類１１の出力は、後述のロボット用サービス提供アプリ１５により収集される。
【００３９】
表示部１２は、モニタ、ディスプレイやタッチパネルなどの表示デバイスである。一例としては、表示部１２は、サーバ３０からネットワーク２０を介して受信した防災情報や気象情報などを表示することにより、情報サービスのインタフェースとして機能する。
【００４０】
通信インタフェース部１３は、ネットワーク２０を介して接続される他装置、例えばサーバ３０との間で通信を行うためのインタフェース（interface）である。
【００４１】
制御部１４は、例えば、ＡＳＩＣ（Application  Specific  Integrated  Circuit）やＦＰＧＡ（Field  Programmable  Gate  Array）などの集積回路またはＣＰＵ（Central  Processing  Unit）やＭＰＵ（Micro  Processing  Unit）などの電子回路である。
【００４２】
制御部１４は、各種の処理手順を規定したプログラム、例えばＯＳ（Operating  System）、ロボット向けの通信制御プログラムやロボット用サービス提供アプリなどのプログラムや制御データを格納するための内部メモリを有する。制御部１４は、内部メモリを用いて種々の処理を実行する。制御部１４は、図３に示すように、ロボット用サービス提供アプリ１５と、送信キュー１６ａと、受信キュー１６ｂと、共有メモリ１７と、ＨＴＴＰロボットスレッド１８とを有する。
【００４３】
ロボット用サービス提供アプリ１５は、ロボット１０が特定のサービスを提供するためにインストールされたロボット用のアプリケーションである。一例としては、ロボット用サービス提供アプリ１５が情報サービスを提供するアプリである場合を想定する。この場合には、ロボット用サービス提供アプリ１５は、定期時刻または指定時刻に防災情報及び／又は気象情報をサーバ３０へ要求する電文を送信キュー１６ａへ格納する。その後、サーバ３０から防災情報及び／又は気象情報を表示用データとして受信すると、後述のレスポンス受信制御部１８Ａｃにより表示用データの受信イベントが通知される。この受信イベントの通知を受け付けたことを契機に、ロボット用サービス提供アプリ１５は、受信キュー１６ｂから表示用データを取り出して防災情報及び／又は気象情報を表示部１２へ表示させる。
【００４４】
送信キュー１６ａは、サーバ３０へ送信するデータを保持するキューである。この送信キュー１６ａには、ロボット用サービス提供アプリ１５により生成されたデータがサーバ３０へ通知される場合に格納される。また、受信キュー１６ｂは、サーバ３０から受信したデータを保持するキューである。この受信キュー１６ｂに格納されたデータは、ロボット用サービス提供アプリ１５により使用される。これら送信キュー１６ａ及び受信キュー１６ｂは、ＦＩＦＯ（First-In  First-Out）などの方式でデータが入出力される。
【００４５】
共有メモリ１７は、各ＨＴＴＰロボットスレッド１８により共有されるメモリである。この共有メモリ１７には、ＨＴＴＰロボットスレッドごとにそのスレッドが上り用の通信路として機能しているか、あるいは下り用の通信路として機能しているかを示す通信方向を対応付けた共有データを記憶する。なお、共有メモリ１７には、ＲＡＭ（Random  Access  Memory)を始め、フラッシュメモリ（flash  memory）などの半導体メモリ素子を含む記憶デバイス全般を適用できる。
【００４６】
図４は、共有データの一例を示す図である。図４に示す共有データは、ＨＴＴＰロボットスレッド１８Ａが上り用の通信路として機能しており、ＨＴＴＰロボットスレッド１８Ｂが下り用の通信路として機能しており、また、ＨＴＴＰロボットスレッド１８Ｃが上り用の通信路として機能している場合を示す。なお、共有データは、制御部１４で動作する各ＨＴＴＰロボットスレッド１８により、通信路の上りまたは下りが切り替えられる場合に更新される。
【００４７】
ＨＴＴＰロボットスレッド１８は、サーバ３０との間でＨＴＴＰセッションを確立することによりロボット１０及びサーバ３０間の通信路を生成するスレッドである。このＨＴＴＰロボットスレッド１８は、通信制御プログラムの開発者により設定された通信路の数のスレッドがロボット向けの通信制御プログラムにより生成される。なお、ここでは、ＨＴＴＰロボットスレッド１８の数が変化しないものとして説明を行うが、ロボット向けの通信制御プログラムにより動的に変更されることとしてもかまわない。
【００４８】
ここで、図３の例では、ＨＴＴＰロボットスレッド１８を２つ図示しているが、３つ以上のＨＴＴＰロボットスレッド１８が動作している場合を想定しつつ、ＨＴＴＰロボットスレッド１８Ａを例にとってＨＴＴＰロボットスレッド１８の機能を説明する。なお、ＨＴＴＰロボットスレッド１８Ａ以外のＨＴＴＰロボットスレッド１８、例えばＨＴＴＰロボットスレッド１８Ｂが果たす機能も同様である。
【００４９】
ＨＴＴＰロボットスレッド１８Ａは、図３に示すように、上り用スレッド判定部１８Ａａと、リクエスト送信制御部１８Ａｂと、レスポンス受信制御部１８Ａｃとを有する。
【００５０】
上り用スレッド判定部１８Ａａは、共有メモリ１７に記憶された共有データを用いて、上り用の通信路として機能する上り用スレッドの数が所定の閾値以上であるか否かを判定する処理部である。ここで言う「上り用スレッド」とは、送信キュー１６ａにデータが格納されるのを待機しているＨＴＴＰロボットスレッド１８のことを指す。
【００５１】
これを説明すると、上り用スレッド判定部１８Ａａは、ロボット１０の電源が起動された直後の初期状態または後述のレスポンス受信制御部１８ＡｃによりＨＴＴＰレスポンスの受信制御が行われた後に処理を起動する。上り用スレッド判定部１８Ａａは、共有メモリ１７に記憶された共有データのうち通信方向が「上り」と書き込まれているスレッド数の集計値を上り用スレッド数として導出する。このとき、上り用スレッド判定部１８Ａａは、上り用スレッド数に自スレッドを含めて集計することとしてもよいし、また、含めずに集計することとしてもかまわない。そして、上り用スレッド判定部１８Ａａは、上り用スレッド数が閾値以上であるか否かを判定する。
【００５２】
このとき、上り用スレッド数が閾値以上である場合には、上り用スレッド判定部１８Ａａは、共有メモリ１７に記憶された自スレッドに対応する通信方向のエントリを「下り」へ更新する。これにより、ＨＴＴＰロボットスレッド１８Ａは、送信キュー１６ａにデータが格納されるのを待機する上り用スレッドとして機能するようになる。また、上り用スレッド数が閾値未満である場合には、上り用スレッド判定部１８Ａａは、共有メモリ１７に記憶された自スレッドに対応する通信方向のエントリを「上り」へ更新する。これにより、ＨＴＴＰロボットスレッド１８Ａは、ＨＴＴＰサーバスレッド３８Ａへ空のＨＴＴＰリクエストを送信する下り用スレッドとして機能するようになる。
【００５３】
ここで、３つ以上の通信路を生成している場合、すなわち３組以上のＨＴＴＰロボットスレッド１８が動作している場合には、一例として、（動作中のスレッドの数／２＋１）＝ｎを上り用スレッドの数と比較する閾値として用いる。このように、全ＨＴＴＰロボットスレッド１８の過半数を閾値とすれば、ＨＴＴＰロボットスレッド１８の上り用スレッドと下り用スレッドとの割合をバランスよく維持させることができる。
【００５４】
リクエスト送信制御部１８Ａｂは、ＨＴＴＰリクエストの送信制御を行う処理部である。このリクエスト送信制御部１８Ａｂは、上り用スレッド判定部１８Ａａによる判定結果に応じて自スレッドが上り用または下り用のいずれの通信路として機能するかを切り替える。
【００５５】
これを説明すると、上り用スレッド判定部１８Ａａにより上り用スレッド数が閾値未満であると判定された場合には、上り用スレッドが不足していると推定できる。このため、リクエスト送信制御部１８Ａｂは、自スレッドを上り用スレッドとして機能させる。すなわち、リクエスト送信制御部１８Ａｂは、送信キュー１６ａにデータが入るまで待機してから送信キュー１６ａに格納されたデータをペイロードに埋め込んでＨＴＴＰリクエストをサーバ３０のＨＴＴＰサーバスレッド３８Ａへ送信する。
【００５６】
また、上り用スレッド判定部１８Ａａにより上り用スレッド数が閾値以上であると判定された場合には、上り用スレッドが十分に存在していると推定できる。このため、リクエスト送信制御部１８Ａｂは、自スレッドを下り用スレッドとして機能させる。すなわち、リクエスト送信制御部１８Ａｂは、ＨＴＴＰサーバスレッド３８でＨＴＴＰリクエストを保留状態とするために、ペイロードにデータがない空のＨＴＴＰリクエストをサーバ３０のＨＴＴＰサーバスレッド３８Ａへ送信する。
【００５７】
レスポンス受信制御部１８Ａｃは、ＨＴＴＰレスポンスの受信制御を行う処理部である。これを説明すると、レスポンス受信制御部１８Ａｃは、サーバ３０のＨＴＴＰサーバスレッド３８ＡからＨＴＴＰレスポンスを受信すると、ＨＴＴＰレスポンスのペイロードにデータがあるか否かを判定する。このとき、ペイロードにデータがあった場合には、レスポンス受信制御部１８Ａｃは、ペイロードに埋め込まれているデータを受信キュー１６ｂへ格納する。そして、レスポンス受信制御部１８Ａｃは、ペイロードに埋め込まれているデータの受信イベントをロボット用サービス提供アプリ１５のハンドラに通知する。また、ペイロードにデータがなかった場合には、受信キュー１６ｂへのデータの格納やハンドラへの通知を行わずにＨＴＴＰレスポンスの受信制御を終了する。
【００５８】
［サーバ３０の構成］
次に、本実施例に係るサーバの構成について説明する。図５は、実施例２に係るサーバの構成を示すブロック図である。図５に示すように、サーバ３０は、表示部３１と、コンテンツ記憶部３２と、通信インタフェース部３３と、制御部３４とを有する。なお、サーバ３０は、図５に示した機能部以外にも既知のサーバ装置が有する各種の機能部、例えば各種の入力デバイスや記憶デバイス等を有するものとする。
【００５９】
表示部３１は、モニタ、ディスプレイやタッチパネルなどの表示デバイスである。一例としては、表示部３１は、ロボット１０からネットワーク２０を介して受信したロボット１０のセンサ情報を表示することにより、ロボット１０の周辺環境をモニタリングするモニタサービスのインタフェースとして機能する。他の一例としては、表示部３１は、ロボット１０からネットワーク２０を介して受信した異常可否情報を表示することにより、ロボット１０本体の状態を管理するメンテナンスサービスのインタフェースとして機能する。
【００６０】
コンテンツ記憶部３２は、各種のコンテンツを記憶する記憶デバイスである。このコンテンツ記憶部３２に記憶されるコンテンツは、予め登録されたコンテンツであってもよいし、後述のサーバ用サービス提供アプリ３５により収集されたコンテンツ、例えば防災情報や気象情報であってもよい。なお、コンテンツ記憶部３２には、ハードディスク、光ディスクなどの記憶装置をはじめ、フラッシュメモリなどの半導体メモリ素子を含む記憶デバイス全般を適用できる。
【００６１】
通信インタフェース部３３は、ネットワーク２０を介して接続される他装置、例えばロボット１０との間で通信を行うためのインタフェースである。
【００６２】
制御部３４は、各種の処理手順を規定したプログラム、例えばＯＳ（Operating  System）、サーバ向けの通信制御プログラムやサーバ用サービス提供アプリなどのプログラムや制御データを格納するための内部メモリを有する。制御部３４は、内部メモリを用いて種々の処理を実行する。制御部３４は、図５に示すように、サーバ用サービス提供アプリ３５と、受信キュー３６ａと、送信キュー３６ｂと、共有メモリ３７と、ＨＴＴＰサーバスレッド３８とを有する。
【００６３】
サーバ用サービス提供アプリ３５は、ロボット１０が特定のサービスを提供するためにインストールされたサーバ用のアプリケーションである。一例としては、サーバ用サービス提供アプリ３５が情報サービスを提供するアプリである場合を想定する。この場合には、サーバ用サービス提供アプリ３５は、ロボット１０からの防災情報及び／又は気象情報の要求電文の受信イベントが後述のリクエスト受信制御部３８Ａａにより通知されるので、その要求電文を受信キュー３６ａから取り出す。これを契機に、サーバ用サービス提供アプリ３５は、コンテンツ記憶部３２から読み出したり、また、外部装置からネットワーク２０を介して収集したりすることにより、防災情報及び／又は気象情報を取得する。その後、サーバ用サービス提供アプリ３５は、先に取得した防災情報及び／又は気象情報をロボット１０で表示させるために加工処理を行って表示データを生成する。そして、サーバ用サービス提供アプリ３５は、先に生成した表示データを送信キュー３６ｂへ格納する。
【００６４】
受信キュー３６ａは、ロボット１０から受信したデータを保持するキューである。この受信キュー３６ａに格納されたデータは、サーバ用サービス提供アプリ３５により使用される。また、送信キュー３６ｂは、ロボット１０へ送信するデータを保持するキューである。この送信キュー３６ｂには、サーバ用サービス提供アプリ３５により生成されたデータがロボット１０へ通知される場合に格納される。これら受信キュー３６ａ及び送信キュー３６ｂは、ＦＩＦＯ（First-In  First-Out）などの方式でデータが入出力される。
【００６５】
共有メモリ３７は、各ＨＴＴＰサーバスレッド３８により共有されるメモリである。この共有メモリ３７には、ＨＴＴＰサーバスレッドごとにそのスレッドが上り用の通信路として機能しているか、あるいは下り用の通信路として機能しているかを示す通信方向を対応付けた共有データを記憶する。なお、共有メモリ３７には、ＲＡＭを始め、フラッシュメモリなどの半導体メモリ素子を含む記憶デバイス全般を適用できる。
【００６６】
図６は、共有データの一例を示す図である。図６に示す共有データは、ＨＴＴＰサーバスレッド３８Ａが上り用の通信路として機能しており、ＨＴＴＰサーバスレッド３８Ｂが下り用の通信路として機能しており、また、ＨＴＴＰサーバスレッド３８Ｃが上り用の通信路として機能している場合を示す。なお、共有データは、制御部３４で動作する各ＨＴＴＰサーバスレッド３８により、通信路の上りまたは下りが切り替えられる場合に更新される。
【００６７】
ＨＴＴＰサーバスレッド３８は、ロボット１０との間でＨＴＴＰセッションを確立することによりロボット１０及びサーバ３０間の通信路を生成するスレッドである。このＨＴＴＰサーバスレッド３８は、通信制御プログラムの開発者により設定された通信路の数のスレッドがサーバ向けの通信制御プログラムにより生成される。なお、ここでは、ＨＴＴＰサーバスレッド３８の数が変化しないものとして説明を行うが、サーバ向けの通信制御プログラムにより動的に変更されることとしてもかまわない。
【００６８】
ここで、図５の例では、ＨＴＴＰサーバスレッド３８を２つ図示しているが、３つ以上のＨＴＴＰサーバスレッド３８が動作している場合を想定しつつ、ＨＴＴＰサーバスレッド３８Ａを例にとってＨＴＴＰサーバスレッド３８の機能を説明する。なお、ＨＴＴＰサーバスレッド３８Ａ以外のＨＴＴＰサーバスレッド３８、例えばＨＴＴＰサーバスレッド３８Ｂが果たす機能も同様である。
【００６９】
ＨＴＴＰサーバスレッド３８Ａは、図５に示すように、リクエスト受信制御部３８Ａａと、下り用スレッド判定部３８Ａｂと、レスポンス送信制御部３８Ａｃとを有する。
【００７０】
リクエスト受信制御部３８Ａａは、ＨＴＴＰリクエストの受信制御を行う処理部である。これを説明すると、リクエスト受信制御部３８Ａａは、ロボット１０のＨＴＴＰロボットスレッド１８ＡからＨＴＴＰリクエストを受信すると、ＨＴＴＰリクエストのペイロードにデータがあるか否かを判定する。このとき、ペイロードにデータがあった場合には、リクエスト受信制御部３８Ａａは、ペイロードに埋め込まれているデータを受信キュー３６ａへ格納する。そして、リクエスト受信制御部３８Ａａは、ペイロードに埋め込まれているデータの受信イベントをサーバ用サービス提供アプリ３５のハンドラに通知する。また、ペイロードにデータがなかった場合には、受信キュー３６ａへのデータの格納やハンドラへの通知を行わずにＨＴＴＰリクエストの受信制御を終了する。
【００７１】
下り用スレッド判定部３８Ａｂは、共有メモリ３７に記憶された共有データを用いて、下り用の通信路として機能する下り用スレッドの数が所定の閾値以上であるか否かを判定する処理部である。ここで言う「下り用スレッド」とは、送信キュー３６ｂにデータが格納されるのを待機しているＨＴＴＰサーバスレッド３８のことを指す。
【００７２】
これを説明すると、下り用スレッド判定部３８Ａｂは、リクエスト受信制御部３８ＡａによりＨＴＴＰリクエストの受信制御が行われた後に処理を起動する。下り用スレッド判定部３８Ａｂは、共有メモリ３７に記憶された共有データのうち通信方向が「下り」と書き込まれているスレッド数の集計値を下り用スレッド数として導出する。このとき、下り用スレッド判定部３８Ａｂは、下り用スレッド数に自スレッドを含めて集計することとしてもよいし、また、含めずに集計することとしてもかまわない。そして、下り用スレッド判定部３８Ａｂは、下り用スレッド数が閾値以上であるか否かを判定する。
【００７３】
このとき、下り用スレッド数が閾値以上である場合には、下り用スレッド判定部３８Ａｂは、共有メモリ３７に記憶された自スレッドに対応する通信方向のエントリを「上り」へ更新する。これにより、ＨＴＴＰサーバスレッド３８Ａは、ＨＴＴＰロボットスレッド１８Ａへ空のＨＴＴＰレスポンスを送信する上り用スレッドとして機能するようになる。また、下り用スレッド数が閾値未満である場合には、下り用スレッド判定部３８Ａｂは、共有メモリ３７に記憶された自スレッドに対応する通信方向のエントリを「下り」へ更新する。これにより、ＨＴＴＰサーバスレッド３８Ａは、送信キュー３６ｂにデータが格納されるのを待機する下り用スレッドとして機能するようになる。
【００７４】
ここで、３つ以上の通信路を生成している場合、すなわち３組以上のＨＴＴＰサーバスレッド３８が動作している場合には、一例として、（動作中のスレッドの数／２＋１）＝ｎを下り用スレッドの数と比較する閾値として用いる。このように、全ＨＴＴＰサーバスレッド３８の過半数を閾値とすれば、ＨＴＴＰサーバスレッド３８における上り用スレッドと下り用スレッドとの割合をバランスよく維持させることができる。
【００７５】
レスポンス送信制御部３８Ａｃは、ＨＴＴＰレスポンスの送信制御を行う処理部である。このレスポンス送信制御部３８Ａｃは、下り用スレッド判定部３８Ａｂによる判定結果に応じて自スレッドが上り用または下り用のいずれの通信路として機能するかを切り替える。
【００７６】
これを説明すると、下り用スレッド判定部３８Ａｂにより下り用スレッド数が閾値未満であると判定された場合には、下り用スレッドが不足していると推定できる。このため、レスポンス送信制御部３８Ａｃは、自スレッドを下り用スレッドとして機能させる。すなわち、レスポンス送信制御部３８Ａｃは、送信キュー３６ｂにデータが入るまで待機してから送信キュー３６ｂに格納されたデータをペイロードに埋め込んでＨＴＴＰレスポンスをロボット１０のＨＴＴＰロボットスレッド１８Ａへ送信する。
【００７７】
また、下り用スレッド判定部３８Ａｂにより下り用スレッド数が閾値以上であると判定された場合には、下り用スレッドが十分に存在していると推定できる。このため、レスポンス送信制御部３８Ａｃは、自スレッドを上り用スレッドとして機能させる。すなわち、レスポンス送信制御部３８Ａｃは、ＨＴＴＰロボットスレッド１８からのＨＴＴＰリクエストを待機するために、ペイロードにデータがない空のＨＴＴＰレスポンスをロボット１０のＨＴＴＰロボットスレッド１８Ａへ送信する。
【００７８】
［処理の流れ］
次に、本実施例に係るクライアントサーバシステムの処理の流れを説明する。なお、ここでは、（１）ＨＴＴＰロボットスレッド１８に実行される処理フローを説明してから、（２）ＨＴＴＰサーバスレッド３８に実行される処理フローを説明する。
【００７９】
（１）ＨＴＴＰロボットスレッドに実行される処理フロー
図７は、実施例２に係るＨＴＴＰロボットスレッドに実行される処理の手順を示すフローチャートである。この処理は、ロボット１０の電源が起動された直後の初期状態または後述のレスポンス受信制御部１８ＡｃによりＨＴＴＰレスポンスの受信制御が行われた後に起動される。
【００８０】
図７に示すように、上り用スレッド判定部１８Ａａは、送信キュー１６ａにデータが格納されるのを待機している上り用スレッド数が閾値以上であるか否かを判定する（ステップＳ１０１）。
【００８１】
ここで、上り用スレッド数が閾値未満である場合（ステップＳ１０１否定）には、上り用スレッド判定部１８Ａａは、共有メモリ１７に記憶された自スレッドに対応する通信方向のエントリを「上り」へ更新する（ステップＳ１０２）。
【００８２】
その後、リクエスト送信制御部１８Ａｂは、送信キュー１６ａにデータが入るまで待機する（ステップＳ１０３）。そして、リクエスト送信制御部１８Ａｂは、送信キュー１６ａに格納されたデータをペイロードに埋め込んでＨＴＴＰリクエストをサーバ３０のＨＴＴＰサーバスレッド３８Ａへ送信する（ステップＳ１０４）。
【００８３】
一方、上り用スレッド数が閾値以上である場合（ステップＳ１０１肯定）には、上り用スレッド判定部１８Ａａは、共有メモリ１７に記憶された自スレッドに対応する通信方向のエントリを「下り」へ更新する（ステップＳ１０５）。
【００８４】
そして、リクエスト送信制御部１８Ａｂは、ＨＴＴＰサーバスレッド３８でＨＴＴＰリクエストを保留状態とするために、ペイロードにデータがない空のＨＴＴＰリクエストをサーバ３０のＨＴＴＰサーバスレッド３８Ａへ送信する（ステップＳ１０６）。
【００８５】
その後、サーバ３０のＨＴＴＰサーバスレッド３８ＡからＨＴＴＰレスポンスを受信すると（ステップＳ１０７）、レスポンス受信制御部１８Ａｃは、ＨＴＴＰレスポンスのペイロードにデータがあるか否かを判定する（ステップＳ１０８）。
【００８６】
このとき、ペイロードにデータがあった場合（ステップＳ１０８肯定）には、レスポンス受信制御部１８Ａｃは、ペイロードに埋め込まれているデータを受信キュー１６ｂへ格納する（ステップＳ１０９）。そして、レスポンス受信制御部１８Ａｃは、ペイロードに埋め込まれているデータの受信イベントをロボット用サービス提供アプリ１５のハンドラに通知する（ステップＳ１１０）。その後、上記のステップＳ１０１に戻り、上記のステップ１０１〜ステップＳ１１０までの処理を繰り返し行う。
【００８７】
また、ペイロードにデータがなかった場合（ステップＳ１０８否定）には、受信キュー１６ｂへのデータの格納やハンドラへの通知を行わずに上記のステップＳ１０１に戻る。そして、上記のステップ１０１〜ステップＳ１１０までの処理を繰り返し行う。
【００８８】
なお、上記のステップＳ１０２及びステップＳ１０５の処理は、ステップＳ１０７の処理が実行されるまでであればステップの順番を入れ替えたり、並列処理するなど任意のタイミングで実行できる。また、上記のステップＳ１０９及びステップＳ１１０の処理は、互いに順番を入れ替えたり、並列処理したりすることができる。
【００８９】
（２）ＨＴＴＰサーバスレッドに実行される処理フロー
図８は、実施例２に係るＨＴＴＰロボットスレッドに実行される処理の手順を示すフローチャートである。この処理は、サーバ３０の電源がオン状態になり、かつロボット１０のＨＴＴＰロボットスレッド１８ＡからＨＴＴＰリクエストを受信した場合に起動される。
【００９０】
図８に示すように、ロボット１０のＨＴＴＰロボットスレッド１８ＡからＨＴＴＰリクエストを受信すると（ステップＳ３０１）、リクエスト受信制御部３８Ａａは、ＨＴＴＰリクエストのペイロードにデータがあるか否かを判定する（ステップＳ３０２）。
【００９１】
このとき、ペイロードにデータがあった場合（ステップＳ３０２肯定）には、リクエスト受信制御部３８Ａａは、ペイロードに埋め込まれているデータを受信キュー３６ａへ格納する（ステップＳ３０３）。そして、リクエスト受信制御部３８Ａａは、ペイロードに埋め込まれているデータの受信イベントをサーバ用サービス提供アプリ３５のハンドラに通知する（ステップＳ３０４）。
【００９２】
一方、ペイロードにデータがなかった場合（ステップＳ３０２否定）には、受信キュー３６ａへのデータの格納やハンドラへの通知を行わずにそのままステップＳ３０５に移行する。
【００９３】
ここで、下り用スレッド判定部３８Ａｂは、送信キュー３６ｂにデータが格納されるのを待機している下り用スレッド数が閾値以上であるか否かを判定する（ステップＳ３０５）。
【００９４】
このとき、下り用スレッド数が閾値以上である場合（ステップＳ３０５肯定）には、下り用スレッド判定部３８Ａｂは、共有メモリ３７に記憶された自スレッドに対応する通信方向のエントリを「上り」へ更新する（ステップＳ３０６）。
【００９５】
そして、レスポンス送信制御部３８Ａｃは、ＨＴＴＰロボットスレッド１８からのＨＴＴＰリクエストを待機するために、ペイロードにデータがない空のＨＴＴＰレスポンスをロボット１０のＨＴＴＰロボットスレッド１８Ａへ送信する（ステップＳ３０７）。その後、上記のステップＳ３０１に戻り、上記のステップ３０１〜ステップＳ３０６までの処理を繰り返し行う。
【００９６】
一方、下り用スレッド数が閾値未満である場合（ステップＳ３０５否定）には、下り用スレッド判定部３８Ａｂは、共有メモリ３７に記憶された自スレッドに対応する通信方向のエントリを「下り」へ更新する（ステップＳ３０８）。
【００９７】
レスポンス送信制御部３８Ａｃは、送信キュー３６ｂにデータが入るまで待機する（ステップＳ３０９）。そして、レスポンス送信制御部３８Ａｃは、送信キュー３６ｂに格納されたデータをペイロードに埋め込んでＨＴＴＰレスポンスをロボット１０のＨＴＴＰロボットスレッド１８Ａへ送信する（ステップＳ３１０）。その後、上記のステップＳ３０１に戻り、上記のステップ３０１〜ステップＳ３１０までの処理を繰り返し行う。
【００９８】
なお、上記のステップＳ３０６の処理は、ステップＳ３０７の処理と順番を入れ替えたり、並列処理したりすることができる。さらに、ステップＳ３０８の処理は、ステップＳ３０９またはステップＳ３１０の処理と順番を入れ替えたり、並列処理したりすることができる。また、上記のステップＳ３０３及びステップＳ３０４の処理は、互いに順番を入れ替えたり、並列処理したりすることができる。
【００９９】
［実施例２の効果］
上述してきたように、本実施例に係るロボット１０及びサーバ３０は、上り用の通信路として機能させるスレッド及び下り用の通信路として機能させるスレッドを機動的に変更できる。このため、本実施例に係るロボット１０及びサーバ３０では、上り用の通信路と下り用の通信路とを固定する場合に比べて、上り通信で発生する空のレスポンスの送信回数及び下り通信で発生する空のリクエストの送信回数を低減できる。また、本実施例に係るロボット１０及びサーバ３０では、スレッドを機動的に変更しても、各通信路として機能させるスレッドを適切な数に保つことができる。それゆえ、本実施例に係るロボット１０及びサーバ３０によれば、通信路を有効活用することが可能になる。さらに、本実施例に係るロボット１０及びサーバ３０では、通信路の数を増減させる場合に上り専用の通信路及び下り専用の通信路の２つを１組として拡張または縮退せずとも、通信路の数をよりきめ細やかに増減させることができる。
【実施例３】
【０１００】
さて、これまで開示の装置に関する実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明に含まれる他の実施例を説明する。
【０１０１】
［応用例］
上記の実施例２では、上り用スレッド判定部１８Ａａ及び下り用スレッド判定部３８Ａｂが用いる閾値を過半数とする場合を説明したが、開示の装置はこれに限定されるものではない。例えば、ロボット用サービス提供アプリ１５またはサーバ用サービス提供アプリ３５によって生成されるデータの生成状態もしくは送信キュー１６ａまたは送信キュー３６ｂに格納されているデータの格納量に応じて、閾値を変更してもよい。
【０１０２】
一例としては、ロボット用サービス提供アプリ１５またはサーバ用サービス提供アプリ３５によって生成されるデータが多くなるほど閾値が高くなるように変更できる。他の一例としては、送信キュー１６ａまたは送信キュー３６ｂに格納されているデータの格納量、例えばデータサイズやメッセージ数が多くなるほど閾値が高くなるように変更できる。これによって、上り通信または下り通信の需要に応じてスレッドが上りスレッドとして機能するか、あるいは下りスレッドとして機能するのかを機動的に変更できる。
【０１０３】
［適用例］
また、上記の実施例２では、サーバ３０との間でＨＴＴＰセッションを確立することによりロボット１０及びサーバ３０間の通信路を生成する処理単位をスレッドとしたが、必ずしもスレッドである必要はなく、プロセスであってもかまわない。この場合には、プロセス間で通信を行うことにより共有情報に相当する情報を各プロセスが収集することが好ましい。
【０１０４】
また、上記の実施例２では、ロボット１０及びサーバ３０を有するクライアントサーバシステムにおいてロボットサービスを提供する場合を例示したが、開示の装置がこれに限定されるものではなく、一般のクライアントサーバシステムに適用できる。一例としては、クライアント端末は、パーソナルコンピュータ、携帯電話、ＰＨＳやＰＤＡなどの携帯情報端末であっても開示の装置を同様に適用できる。
【０１０５】
また、図示した各装置の各構成要素は、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。例えば、ロボット向けの通信制御プログラム及びロボット用サービス提供アプリの機能を統合して１つのソフトウェアとしてもかまわない。また、サーバ向けの通信制御プログラム及びサーバ用サービス提供アプリの機能を統合して１つのソフトウェアとしてもかまわない。
【０１０６】
［通信制御プログラム］
また、上記の実施例で説明した各種の処理は、予め用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。そこで、以下では、図９を用いて、上記の実施例と同様の機能を有する通信制御プログラムを実行するコンピュータの一例について説明する。なお、図９は、実施例３に係る通信制御プログラムを実行するコンピュータの一例について説明するための図である。
【０１０７】
図９に示すように、実施例Ｘにおけるコンピュータ１００は、操作部１１０ａと、マイク１１０ｂと、スピーカ１１０ｃと、ディスプレイ１２０と、通信部１３０とを有する。さらに、このコンピュータ１００は、ＣＰＵ１５０と、ＲＯＭ１６０と、ＨＤＤ（Hard  Disk  Drive）１７０と、ＲＡＭ（Random  Access  Memory）１８０と有する。これら１１０〜１８０の各部はバス１４０を介して接続される。
【０１０８】
ＲＯＭ１６０には、上記の実施例２で示したＨＴＴＰロボットスレッド１８Ａと、ＨＴＴＰロボットスレッド１８Ｂと同様の機能を発揮する通信制御プログラムが予め記憶される。つまり、ＲＯＭ１６０には、図９に示すように、通信制御プログラム１６１が記憶される。この通信制御プログラム１６１については、図３に示したロボットの各構成要素と同様、適宜統合又は分離しても良い。なお、ここでは、ロボット向けの通信制御プログラムを動作させる場合を例示するが、サーバ向けの通信制御プログラムを動作させることもできる。また、ＲＡＭ１６０に格納される各データは、常に全てのデータがＲＡＭ１６０に格納される必要はなく、処理に必要なデータのみがＲＡＭ１６０に格納されれば良い。
【０１０９】
そして、ＣＰＵ１５０が、この通信制御プログラム１６１をＲＯＭ１６０から読み出して実行する。これによって、ＣＰＵ１５０は、図９に示すように、通信制御プログラム１６１については、通信制御プロセス１５１として機能するようになる。この通信制御プロセス１５１は、予め設定された数または動作中に動的に決定される数のＨＴＴＰロボットプロセスを起動させつつ動作できる。図９に示す例では、ＨＴＴＰロボットプロセス１５１ａ及びＨＴＴＰロボットプロセス１５１ｂの２つのプロセスが動作する場合を例示している。各プロセス１５１ａ〜１５１ｂは、図３に示した、ＨＴＴＰロボットスレッド１８Ａと、ＨＴＴＰロボットスレッド１８Ｂとにそれぞれ対応する。なお、ＣＰＵ１５０上で仮想的に実現される各処理部は、常に全ての処理部がＣＰＵ１５０上で動作する必要はなく、処理に必要な処理部のみが仮想的に実現されれば良い。
【０１１０】
そして、ＨＤＤ１７０には、共有データ１７０ａが設けられる。なお、この共有データ１７０ａは、図３に示した共有メモリ１７に記憶されるデータに対応する。
【０１１１】
そして、ＣＰＵ１５０は、共有データ１７０ａを読み出してＲＡＭ１８０に格納する。さらに、ＣＰＵ１５０は、ＲＡＭ１８０に格納された共有データ１８０ａを更新しながら、通信制御プログラムを実行する。
【０１１２】
なお、上記の通信制御プログラムについては、必ずしも最初からＨＤＤ１７０やＲＯＭ１６０に記憶させておく必要はない。例えば、コンピュータ１００に挿入されるフレキシブルディスク、いわゆるＦＤ、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」に各プログラムを記憶させる。そして、コンピュータ１００がこれらの可搬用の物理媒体から各プログラムを取得して実行するようにしてもよい。また、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ１００に接続される他のコンピュータまたはサーバ装置などに各プログラムを記憶させておき、コンピュータ１００がこれらから各プログラムを取得して実行するようにしてもよい。
【符号の説明】
【０１１３】
１    情報処理装置
１ａ  判定部
１ｂ  スレッド制御部
１０    ロボット
１１    センサ類
１２    表示部
１３    通信インタフェース部
１４    制御部
１５    ロボット用サービス提供アプリ
１６ａ  送信キュー
１６ｂ  受信キュー
１７    共有メモリ
１８Ａ，１８Ｂ    ＨＴＴＰロボットスレッド
１８Ａａ，１８Ｂａ    上り用スレッド判定部
１８Ａｂ，１８Ｂｂ    リクエスト送信制御部
１８Ａｃ，１８Ｂｃ    レスポンス受信制御部
２０    ネットワーク
３０    サーバ
３１    表示部
３２    コンテンツ記憶部
３３    通信インタフェース部
３４    制御部
３５    サーバ用サービス提供アプリ
３６ａ  受信キュー
３６ｂ  送信キュー
３７    共有メモリ
３８Ａ，３８Ｂ    ＨＴＴＰサーバスレッド
３８Ａａ，３８Ｂａ    リクエスト受信制御部
３８Ａｂ，３８Ｂｂ    下り用スレッド判定部
３８Ａｃ，３８Ｂｃ    レスポンス送信制御部
【図１】
0005429003.tif 000002
【図２】
0005429003.tif 000003
【図３】
0005429003.tif 000004
【図４】
0005429003.tif 000005
【図５】
0005429003.tif 000006
【図６】
0005429003.tif 000007
【図７】
0005429003.tif 000008
【図８】
0005429003.tif 000009
【図９】
0005429003.tif 000010