以下、図面を参照しながら本発明の実施形態について詳解する。
A.システム構成
図1には、本発明の一実施形態に係るリモコン操作環境を示している。
参照番号11は、本発明が適用されたリモコンである。本実施形態では指向性通信を実現する手段としてIR(Infrared:赤外線)を利用し、その中でもAV機器のリモコンなどで広く一般に使用されている赤外線通信規格であるSIRCS(Serial Infrared Remote Control System)を適用する。参照番号111はそのSIRCS送信部である。
また、本実施形態では、透過性通信を実現する手段としてはIEEE 802.11gに基づく電波通信を適用する。参照番号112はその通信インターフェースである。但し、本実施形態では、IP(Internet Protocol)ネットワークの利用を前提とするものであり、IEEE802.11gに限定されるものではない。例えば、IEEE 802.11a、IEEE 802.11bなどの他のIEEE 802.11系の技術や、Bluetooth通信や、あるいは超広帯域を利用して極めて微弱なインパルス列に情報を載せて無線通信を行なうUWB(Ultra Wide Band)をベースとした通信方法などでIPネットワークを利用できる通信インターフェースであるならば何でもよい。また、IEEE 802.11gの通信においても、AP(アクセス・ポイント)の介在により同期的な通信動作を行なうインフラストラクチャ・モード、あるいはAPを配置せず各通信局が自律分散的に通信動作を行なうアドホック・モードによって、IPネットワークが構築されていることを前提としもよい。また、IP層よりも上位のプロトコルとして、TCP(Transmission Control Protocol)又はUDP(User Datagram Protocol)を使用する。
セレクト・ボタン113は、指向性通信においてもデバイスを特定できず、複数のデバイスが制御対象となる場合にデバイスを選択するために使用されるボタンである。セレクト・ボタン113を押す度に、デバイスの選択先を遷移させるために使われる。以下、本明細書では、制御対象となるデバイスを選択することを「セレクト」と呼ぶことにする。
ロックオン・ボタン114は、指向性通信を行なわずに透過性通信のみのモードへの切り替えをトグル式に行なうためのボタンである。
画像出力装置115は、ユーザに対して選択中のデバイスの表示や、エラーメッセージの表示を行なうために使用する。リモコン用として10数文字程度の文字列が表示可能なLEDによる簡易なものから、LCDを用いた比較的高品位な装置などが画像出力装置115として一般的に使われる。
音声出力装置116は、画像出力装置115と同様に、ユーザへ何らかのメッセージを送る用途に使われる。これには単純なBeep音のみの音源からFM音源、PCM音源とスピーカなどの装置で構成される。
コマンド・ボタン群117は、デバイスを制御するための操作/コマンド・ボタンの集合である。例えば、テレビの電源ON/OFFボタンや、チャンネル切り替え(選局)ボタン、音量調整ボタンなどがこれに含まれる。任意の機能を持ったボタンに対して本発明は適用できる。
参照番号12〜14は、本発明が適用された、リモコンによる操作対象となるデバイスであり、例えばテレビ受像機や、DVDレコーダ、オーディオ・プレーヤなどがこれに含まれる。本発明により、複数のデバイスが存在する状況でも、リモコン11を適用することができる。以下では、これらの代表としてテレビ12について説明する。
デバイス12は、Pingランプ121と、SIRCS受信部122と、通信インターフェース123を備えている。
Pingランプ121は、ユーザがそのデバイスを選択していることを示すために使用される。但し、デバイスの選択通知を行なうために使用される。但し、ランプでなくとも、音声によるインターフェースを適用してもよい。
SIRCS受信部122は、リモコン11のSIRCS送信部111からの信号すなわちSIRCSコマンドを受けることで、赤外線を利用した片方向の指向性通信を行なう。
通信インターフェース123は、リモコン11側の通信インターフェースとの間で、IEEE802.11gに従い、電波を利用した透過性通信を行なう(同上)。
図2には、リモコン11の内部システム構成を模式的に示している。
参照番号21は、本発明に係るデータ処理の実行を司る制御装置である。一般に、制御装置21は、演算ユニットとしてのCPU(Central Processing Unit)、プログラム・コードやその他のデータを恒久的に格納するROM(Read Only Memory)、CPUが実行するプログラム・コードや作業データをロードするRAM(Random Access Memory)や、システムに必須のデータを不揮発的に記録するEEPROM(electrically Eraseable ROM)など(いずれも図示しない)で構成される。
参照番号22はタイマーであり、時間を計測する。但し、タイマー22は、絶対時刻でなく、リモコンが起動してからの相対的な時間経過だけを計測できるものでよい。
参照番号23はリモコンのIDであり、リモコン毎に固有で不変な値である。形式としてはEUI−64や、MAC−48、OSF(Open Software Foundation)のDCE(Distributed Computing Environment)のUUID(Universally Unique IDentifier)などが適当である。
参照番号24はリモコン名であり、固有の値ではあるもののユーザにとっては識別が困難なリモコンID23に代わってリモコンを識別するための分かり易い名称が格納されている。ユーザによって変更可能であってもよい。また国際化の観点からはMIME(Multipurpose Internet Mail Extensions)とそれに付随するcharsetパラメータによってリモコン名24の文字コード指定の情報が付加されていてもよいし、また複数の言語に対応するように言語毎に名前を持っていてもよい。
参照番号25はデバイス・リストであり、アクセス対象となりうるデバイスの情報のリストが格納されている。詳細は後述する。
参照番号26はロックオン状態かどうかを管理するためのフラグである。ここで言うロックオン状態とは、リモコンによる制御対象となるデバイスを固定してしまう動作状態のことである。このとき、指向性通信を使わずに常に透過性通信が行なわれるため、ユーザがリモコンを制御したいデバイスに向けて操作しなくてもデバイスを制御することができる。
参照番号27は現在照合トークンであり、後述するサーチ・リクエスト送信時にそのデータを構成するために使われる。
参照番号28は受信リストであり、セレクト・ボタン113によってセレクトを行なう際に一時的に使用される記録領域である。詳細は後述に譲る。
参照番号29は直前にセレクト・ボタン113によってセレクトを行なった時間が記録されている記憶領域であり、タイマー22から値を取得する。
デバイス・リスト25やロックオン状態フラグ26は不揮発性メモリに格納し、リモコンの電源が入っていない状態でも情報を保持できることが望ましい。
参照番号210は、セレクト・ボタン113、ロックオン・ボタン114、コマンド・ボタン117などのボタン入力を扱うための装置である。
参照番号211は通信バスであり、リモコン内部の各装置間の相互通信に使用される。
図3には、リモコン11による被制御対象デバイスであるテレビ12の内部システム構成を模式的に示している。
参照番号31は、本発明に係るデータ処理の実行を司る制御装置である。一般に、制御装置31は、演算ユニットとしてのCPU、プログラム・コードやその他のデータを恒久的に格納するROM、CPUが実行するプログラム・コードや作業データをロードするRAMや、システムに必須のデータを不揮発的に記録するEEPROMなどで構成される。
参照番号32はデバイスを識別するためのIDであり、デバイスリモコン毎に固有で不変な値である。形式としてはEUI−64や、MAC−48、OSFのDCEのUUIDなどが適当である。
参照番号33はユーザがデバイスを識別するための名称であり、固有の値ではあるもののユーザにとっては識別が困難なリモコンID23に代わってリモコンを識別するための分かり易い名称が格納されている。
参照番号34はアクセス許可リストである。これは特定のリモコンからのみ制御を行なわれることを許可することを実現するために使われる。本実施形態では、このアクセス許可リスト34は何らかの手段によって事前に登録されているものとする。考えられる方法として、固定的にデータを格納する方法や、リモコンID23を動的に登録する方法などが適用できる。例えば、本出願人に既に譲渡されている特開2004−152249号公報には、ユーザ操作によってオーソライズされたクライアントのMACアドレスだけがサーバ側に認証登録され、サーバは認証登録されたMACアドレスを有するクライアントとのアクセスだけを許容する機器認証方法について開示されているが、ここではより一般的にリモコンを識別するリモコンID23が登録されるとよい。
参照番号36は通信バスであり、デバイス内部の各装置間の相互通信に使用される。
なお、放送波を受信するアンテナや選局動作するチューナ、受信信号を復調・復号して元の映像及び音響信号を取り出すデータ処理部、映像信号を表示出力するディスプレイや音響信号を音声出力するスピーカなど、テレビとしての本来の機能部分も備えている。また、デバイスがDVDプレーヤであれば、DVDプレーヤ固有の機能を実現する機能部分を備えている。但し、これらは本発明に係る機能に直接依存しないので、本明細書では説明を省略する。
図4には、リモコン11側において、アクセス対象となりうるデバイスの情報のリストが格納されたデバイス・リスト25の構成例を示している。
参照番号41は、デバイス・エントリであり、デバイスID411、デバイス・タイプ412、デバイス名413、プロトコル414、存在フラグ415、選択候補フラグ416など、デバイス毎のエントリ・データを記載するフィールドを備えている。
デバイスID414は、デバイスを一意に識別するために使用され、該当するデバイスの制御装置31内で管理されるデバイスID32の値に対応する。
デバイス・タイプ412は、「テレビ」、「DVDプレーヤ」など、該当するデバイス(若しくはデバイスが提供するサービスや機能)の種類が記載される。この値によって、リモコン11は制御対象デバイスがどのような機能を持っているかを判断することができる。また、1つのデバイスが複数のデバイス・タイプを有していてもよい。つまり、1つのデバイスで「テレビ」且つ「DVDプレーヤ」であることが可能である。
デバイス名413は、ユーザがデバイスを識別するためのデバイスの名称であり、該当するデバイスの制御装置31内で管理されるデバイス名33の値に対応する。
プロトコル情報414には、デバイスを制御するためにどのようなプロトコルを使ってアクセスすればよいかが記載される。本実施形態では、TCPあるいはUDPのどちらであるのかと、IPアドレスとポート番号の値が記載される。より汎用的なプロトコル情報の示し方として、UPnP AVアーキテクチャで考案されているres@protocolInfoプロパティのような記述でもよい。また逆に、この値はデバイスに依らず固定なプロトコルと決めてしまい、エントリ情報としては記録しない実装でもよい。
存在フラグ415は、直前にデバイスが指向性通信によって応答したことを示す。
選択候補フラグ416は、指向性通信によって複数のデバイスが候補となった場合に、ユーザの明示的な選択により制御対象となったデバイスであることを示す。再び複数のデバイスが制御対象となった場合には、このフラグがonのデバイスが優先的に自動選択される。
これらのデバイス・エントリが複数個リストで管理されるが、本明細書では、説明の便宜上、デバイス・リストの数を最大4個とする。
これらのエントリに順番を規定する。本明細書では、エントリの順番を上位、下位という言葉で表現し、デバイス選択時における優先順位として意味付ける。2つのエントリがあった場合に、図4に示したデバイス・リスト25上で上に位置するエントリを上位のエントリ、下に位置するエントリを下位のエントリと呼ぶ。また、複数のエントリの場合に、最も上に位置するものを最上位のエントリ、最も下に位置するエントリを最下位のエントリと呼ぶ。特に断りがなく最上位、最下位と呼ぶ場合は、リスト内の全エントリ中で最も上位や下位のこととする。
また、ここでターゲットという言葉の定義を行なう。ターゲットとは、最上位のエントリで、直前にデバイスが指向性通信によって応答したことを示す存在フラグ415がonで、且つ、ユーザの明示的な選択により制御対象となったデバイスであることを示す選択候補フラグ416がonのものであるデバイス・エントリ、あるいはそのデバイス・エントリが表すデバイスのこととする。
図5には、リモコン11内の制御装置21で管理される受信リスト28の構成例を示している。受信リスト28の構成は、基本的にはデバイス・リスト25とほぼ同一である。デバイス・リスト25と異なる点は、存在フラグ415に相当する前回指向性通信に応答をしたデバイスであることを示す前回存在フラグ515の他に、今回応答をしたデバイスであることを示す現在存在フラグ517を備えている点である。また、受信リスト28のエントリの総数は、デバイス・リスト25にエントリされているすべてのデバイスから応答があったことを想定し、デバイス・リスト25のエントリ総数の2倍以上必要となる。本実施形態では最大8個である。
図6には、デバイス12内の制御装置31で管理されるアクセス許可リスト34の構成例を示している。
アクセス許可リスト34には、アクセスが許可され、コマンドを受け付けてよいリモコンについて記録されている。アクセスが許可されたリモコン毎にエントリ・データが設けられ、リモコンID611とリモコン名612が記載される。ここで、リモコンID611及びリモコン名612は、該当するリモコン11の制御装置21内で管理されるリモコンID23及びリモコン名24に対応する。
デバイス12側でアクセスを許可するリモコンを固定的に決めてしまう場合には、リモコン名612は必ずしも必要でない。しかし、アクセスを許可するリモコンが動的に登録できる場合で、ユーザにアクセス許可リスト34を画像出力装置115などで提示する場合や、ユーザがこのリストを編集する場合、あるいはデバイス12自身でアクセス・ログを残す場合などには、リモコン名があった方がユーザにとって分かり易い。
B.システム動作
図7には、本実施形態に係るリモコン11が実行する動作手順をフローチャートの形式で示している。この動作手順は、制御装置21において所定のプログラム・コードを実行するという形態で実現される。
まず、動作に必要な初期化処理を行なう(ステップS71)。デバイス・リスト25やロックオン状態フラグ26が揮発性メモリ上にある場合や、不揮発性メモリにある場合でも初期起動時には適切な初期化を行なう。デバイス・リスト25はすべて空のエントリでリストの長さを0に、ロックオン状態フラグ26はoffに初期化する。現在照合トークン27においては、何かしらの値で初期化されていればよい。
そして、初期化がなされた状態で、ユーザの入力を待つ(ステップS72)。ここで言うユーザの入力とは、図1に示したリモコン11上の各ボタンの押下操作である。より高機能なリモコンにおいては、タッチパネル、マウス、ジョグ、音声入力などの様々なユーザ・インターフェースを利用した入力方法も考えられる。
以後の処理手順は大きく3つに分かれる。1つはセレクト・ボタン113を押した場合であり(ステップS73)、制御対象のデバイスの選択を行なう(ステップS8)。詳細は後述する。
2つ目はロックオン・ボタン114を押した場合である(ステップS74)。これによって、デバイス・リスト25の最上位のエントリが候補になっている場合、すなわち当該エントリの選択候補フラグ416がonである場合には(ステップS75)、ロックオン・フラグをonであるならばoff、offであるならばonというトグル処理を行う(ステップS77)。また、ロックオン中は、画像出力装置115上でその状態であることをユーザに知らせる表示を行なう。一方、最上位のエントリが候補でない、すなわち当該エントリの選択候補フラグがoffである場合は、ロックオンに失敗とみなし、画像出力装置115上でメッセージを表示する、あるいは音声出力装置116上で音声を鳴らすなどの手段でユーザに知らせる(ステップS76)。
最後の3つ目がその他コマンド・ボタンが押された場合である(ステップS78)。この場合、デバイス毎に異なるさまざまな機能を呼び出す処理が行なわれる(ステップS9)。例えば、デバイスがテレビ12であるなら電源On/Offや、チャンネルの切り替え、音量の調節などが考えられる。コマンド・ボタンが押された場合の動作の詳細については後述する。
図8には、リモコン11上でセレクト・ボタン113が押された場合に実行される、ステップS8における詳細な処理手順をフローチャートの形式で示している。
この場合、ターゲット・デバイスの有無と前回のセレクト・ボタンが押されたときからの経過時間によって処理が分岐する(ステップS81)。
もしターゲット・デバイスが存在し、且つ前回のセレクト・ボタン113の押下からN秒未満であれば、ローテート・フラグをonにし、さらにターゲットのデバイスIDをターゲットIDとして記憶し(ステップS83)、それ以外の場合はローテート・フラグをoffにする(ステップS82)。
ここで、N秒とは任意の秒数の意味であるが、3〜5秒程度を想定している。時間経過についてはタイマー22から取得する現在時間と前回セレクト時間29の差分より計算する。またローテート・フラグとターゲットIDは、セレクトの処理を行なう当該処理ルーチン(S8)の中でのみ必要なローカルな情報であり、後述するステップS86で再度参照されるのみである。
ここで、前回のセレクト・ボタン113操作からの経過時間によって処理が分岐することの意味について説明する。前回のデバイス選択より経過時間がN秒未満(すなわち、セレクト・ボタン113の連打)であるならば、ユーザがデバイス選択操作を繰り返し行なっている途中であると判断し、次のデバイスを選択する。また、前回のデバイス選択からの経過時間がN秒以上であるならば、デバイス選択操作を開始した、あるいは現在選択中のデバイスを確認したいと判断し、現在のデバイスを選択する。これによって、1つのセレクト・ボタン113で2つの機能を使い分けることができる。勿論、他の実施形態としてセレクト・ボタン113の代わりにこの2つの機能をそれぞれ割り当てた2つのボタンを用意することも考えられるが、実際の使用例を考えた場合ユーザがわざわざ2つの機能を明示的に切り替える必要性は考えられない。
続いて、リモコン操作の対象となるデバイスのサーチを行なう(ステップS10)。サーチの動作手順の詳細については後述する。サーチの結果、アクセス対象となりえるデバイスの情報を管理するデバイス・リスト25が更新されている。
次いで、デバイス・リスト25中で存在フラグ415がonとなっているエントリを探索する(ステップS84)。存在フラグ415がonとなっているエントリが存在しないならば、セレクトの処理ルーチン(S8)は失敗する。この場合、画像出力装置115や音声出力装置116を使ってその旨のユーザに知らせ、本処理ルーチン全体を終了する。
一方、デバイス・リスト25中に存在フラグ415がonとなっているエントリが存在する場合には、続いて、ローテートを行なうかどうかを判別する(ステップS86)。ローテート・フラグがonで、且つ、現在ターゲット・デバイスが存在し、そのデバイスID411がステップS83で記録したターゲットIDと一致するならば、ローテート処理を行なう。まず最上位のエントリの選択候補フラグ416をoffにする(ステップS87)。さらにそのエントリを、存在フラグ415がonであるエントリのうち最下位のエントリの下に移動させる。そして、代わって最上位になったエントリの選択候補フラグ416をonにする。これでターゲット・デバイスが移ったことになる。
図12(2)及び図12(3)には、デバイス・リスト25でローテート処理を行なった様子を示している。図示のように、最上位であるデバイスAのエントリの選択候補フラグ416をoffにし、さらにそのエントリを存在フラグ415がonであるエントリのうち最下位のエントリの下に移動する。そして、代わって最上位になったデバイスCのエントリの選択候補フラグ416をonにする。これでターゲット・デバイスがデバイスAからデバイスCに移ったことになる。勿論このローテート処理を行なっても、存在フラグがonのデバイスが1つの場合には、同じデバイスになるため遷移はしない。
分岐S86でローテート処理をしない場合には、デバイス・リスト25中に存在フラグ415がonで且つ選択候補フラグ416がonであるエントリがあるか否かを判別する(ステップS810)。このようなエントリがない場合には、デバイス・リスト25中で、存在フラグ415がonのエントリのうち最上位となるエントリの選択候補フラグ416をonにする(ステップS89)。このエントリは、結果的には全エントリの中で最上位のものになっている。また、存在フラグonで且つ選択候補フラグonのエントリがある場合には、そのエントリを最上位に移動させる(ステップS811)。
以上の処理で、デバイス・リスト25の最上位のエントリは必ずターゲットになっている。そこで、そのターゲット・エントリに記載されているプロトコル414の情報を使ってターゲット・デバイスにPingコマンドを送信する(ステップS812)。Pingコマンドの送信は透過性通信を使って行ない、プロトコル414に記載されている送信プロトコルが使われる。Pingコマンドを受けたターゲット・デバイスはPingランプ121を点滅させ、現在ユーザによって選択されていることをユーザに知らせる。なお、Pingコマンドにより選択通知情報を送信し、日選択機器側で被選択表示を行なう点については、例えば本出願人に既に譲渡されている特開2001−236772号公報に記載されている。
最後に、タイマー22から現在時間を取得し、前回セレクト時間29として記録し(ステップS813)、当該セレクト処理(S8)全体を終える。
図8に示したセレクト処理を実行することにより、リモコン11は、デバイス・リスト25中で存在が確認されているデバイスの中から、なるべくユーザが意図するように、1台のデバイスがアクセス対象として選択されることになる。そして選択されたデバイスは、デバイス・リスト25の最上位エントリに位置付けられ、その選択候補フラグがonになる。
図9には、リモコン11上で、セレクト・ボタン113やロックオン・ボタン114以外の、通常のコマンド・ボタン117が押された場合に実行される詳細な処理手順をフローチャートの形式で示している。
まずロックオン・フラグ26を参照し、現在ロックオン状態であるかどうかで処理が分岐する(ステップS91)。
ロックオン状態であるならば、ターゲット・デバイスに対してコマンドを送信する(ステップS910)。ロックオン状態は、ロックオン・ボタン114のトグル操作により設定される。ロックオン状態では、指向性通信を行なわずに透過性通信によりコマンド送信が行なわれる。
リモコン11からのコマンドを受けたデバイス側では、コマンドの種類によって何かしらの動作を行なう。例えばテレビであるならば、電源のon/offやチャンネルの選択、音量調節などを実行する。これらの個々のコマンドの内容については、本発明は直接関連しないので、ここではこれ以上説明しない。
一方、ロックオン状態でない場合には(ステップS91)、アクセス対象となるデバイスを探索し特定するためのサーチを行なう(ステップS10)。サーチ処理の詳細については後述に譲る。
サーチ処理の結果、デバイス・リスト25が更新される。ここで、デバイス・リスト中に存在フラグ415がonのエントリがない場合には(ステップS92)、アクセス対象となるデバイスが存在しないので、その旨をユーザに知らせ(ステップS93)、当該サーチの処理(S9)全体を終了する。ここで、ユーザに知らせる手段としては、画像出力装置115や音声出力装置116を利用することができる(同上)。
一方、デバイス・リスト25を更新した結果、存在フラグがonとなるエントリがある場合には(ステップS92)、続いて、存在フラグがonのエントリが1つかどうかを調べる(ステップS94)。存在フラグがonのエントリが1つの場合には、そのエントリの選択候補フラグ416をonにし(ステップS99)、そのデバイスにコマンドを送信する(ステップS910)。コマンドを送信する際、該当デバイス・エントリのプロトコル414に記載されている送信プロトコルを使用する。
また、デバイス・リスト25を更新した結果、存在フラグがonとなるエントリが複数あった場合には(ステップS94)、その中で選択候補フラグがonのものがあるかどうかを調べる(ステップS95)。選択候補フラグがonのものがあったならば、そのうちの最上位のものをデバイス・リストの最上位に移動させ、そのデバイスにコマンドを送信する(ステップS910)。コマンドを送信する際、該当デバイス・エントリのプロトコル414に記載されている送信プロトコルを使用する。
また、デバイス・リスト25を更新した結果、存在フラグがonとなるエントリが複数あるが、選択候補フラグがonであるエントリがない場合には(ステップS95)、当該コマンドの処理(S9)は失敗する。これをユーザに知らせるため、まず、存在フラグがonであるすべてのデバイスに対し、それぞれのデバイス・エントリのプロトコル414に記載されている送信プロトコルを基にPingコマンドを送信し、その旨をユーザに知らせ(ステップS97)、当該サーチの処理(S9)全体を終了する。ここで、ユーザに知らせる手段としては、画像出力装置115や音声出力装置116を利用することができる(同上)。これによって複数のデバイスのPingランプが点滅しリモコンからも音声やメッセージによってユーザは制御対象のデバイスを1つに特定できなかったためコマンド送信に失敗したことを知ることができる。この後、ユーザはセレクト・ボタン113で制御対象の機器を選択した後、改めてコマンド・ボタン117を押すことでコマンド送信を成功させることができる。
図10には、アクセス対象となるデバイスを探索するためのサーチ処理(S10)の動作手順をフローチャートの形式で示している。
まず、デバイス・リスト25のエントリ情報を受信リスト28にコピーする(ステップS101)。その際に、存在フラグ415は前回存在フラグ515にコピーを行ない、他は同じ名前のものをコピーする。また、受信エントリの有効なものだけをコピーし、空のエントリはコピーする必要はない。受信エントリではコピーされなかった受信エントリは無効なエントリとして区別される。
図12(1)及び図12(4)には、デバイス・リスト25のエントリ情報を受信リスト28にコピーする様子を示している。存在フラグ415を前回存在フラグ515にコピーを行ない、他は同じ名前のものをコピーする
次に、現在照合トークンを更新する(ステップS102)。この更新の仕方としては、数字をインクリメントしたり乱数列を用いたりするなどをして、同じ値が再度現れるまで十分に長い周期性を持った手段を使う。
続いて、サーチ・リクエスト15をSIRCS送信部111らかIR上で送信する(ステップS103)。図15には、サーチ・リクエスト15のフォーマットを示している(後述)。照合トークン152には更新した現在照合トークン27の値を使う。それからタイマー22から現在の時間を取得し、受信開始時間として記録する(ステップS104)。
続いて、ステップS105〜S109で構成される一連の受信ループ処理に入る。まず受信開始時間とタイマー22の値の差分をとり特定の時間が経過しているかを調べる(ステップS105)。これによって受信タイムアウトを実現する。タイムアウトの時間は、通信環境にも依るが、ユーザ・インターフェースの観点からはなるべく短いほうが好ましく、数百ミリ秒から1秒辺りまでが適当であると思われる。タイムアウトした場合は受信ループを抜け、タイムアウトしていない場合はデバイスからサーチ・リクエスト15に対するサーチ・レスポンス16を受信したかを調べる(ステップS106)。
サーチ・レスポンス16を受信した場合には、まずそのサーチ・レスポンス16中の照合トークン162がリモコン11の制御装置21において管理されている照合トークン27の値と同じかを調べる(ステップS107)。
互いの照合トークンが異なるならばその受信したサーチ・レスポンス16を破棄する。また、互いの照合トークンが同じであるならばまずデバイスが既に受信リスト中の受信エントリに存在するかを調べる。
そして、存在する場合は、その受信エントリ51の現在存在フラグ517をonにする。また、存在しない場合には、その情報から受信エントリ51を作成し、受信リスト28の最下位に追加する(ステップS107)。作成の仕方は、サーチ・リクエスト15(図15を参照のこと)から該当データを受信エントリ51にコピーし、前回存在フラグ515をoffに、選択候補フラグ516をoffに、現在存在フラグ517をonに設定する。
図12(4)及び図12(5)には、サーチ・レスポンスを受信した場合に受信リスト28を更新する様子を示している。受信リスト28には、デバイス・リスト1からデバイスA、B、C、Dのデバイス・エントリがコピーされている。そして、サーチ・リクエストに対し、デバイスA、C、Eからサーチ・レスポンスを受信し、これらのデバイス・エントリについて現在存在フラグをoffからonに書き換える。
その後、受信リストが満杯になったかどうかを調べる(ステップS109)。本実施形態では、受信リストの大きさは最大8であるので、受信エントリが8個であるならば受信ループを抜ける。また同様に、前述のステップS105において受信タイムアウトした場合も、受信ループを抜ける。
受信ループを抜けた後は、受信エントリの並べ替え処理を行なう(ステップS1010)。まずは受信エントリの中で現在存在フラグ517がonのエントリを受信リストの最上位から連続するように移動させる。このとき、元のエントリの順番は変更しないようにする。つまり、現在存在フラグがonのエントリの中で最上位のものをまず受信リストの最上位に移動させ、在存在フラグがonのエントリの中で2番目に上位だったものを受信リストの最上位の次に移動という具合である。
次に、それら現在存在フラグがonのエントリのうち、選択候補フラグがonのエントリで最上位のものを受信リストの最上位に移動させる(ステップS1011)。そして、現在存在フラグがonで且つ選択候補フラグがonのエントリのうち最上位以外のエントリについて、選択候補フラグをoffに設定する(ステップS1012)。
図12(5)及び図12(6)には、受信リスト28の受信エントリの並べ替えを行なう様子を示している。現在存在フラグ517がonとなっているデバイスA、C、Eの各エントリを、元のエントリの順番を変更しないように、受信リストの最上位から順に並べる。そして、デバイスC、Eは最上位でないのでこれらのデバイス・エントリの選択候補フラグがonであればoffに書き換える。
最後に、受信リスト28からデバイス・リスト25へとコピーを行なう(ステップS1013)。この際、受信リストの最上位をデバイス・リストの最上位になるように順番にコピーを行なう。デバイス・リストの方がエントリ数が少ないので、コピーできない受信エントリが存在する場合は、それらのエントリは破棄してよい。本実施形態では、デバイス・リストの最大エントリ数が4、受信リストの最大エントリ数が8であるので、最大で受信リストの上位4つのエントリをデバイス・リストのデバイス・エントリにコピーすればよい。
図12(6)及び図12(2)には、受信リスト28からデバイス・リスト25へデバイス・エントリをコピーする様子を示している。本実施形態では、デバイス・リストの最大エントリ数が4、受信リストの最大エントリ数が8であるので、最大で受信リストの上位4つのデバイスA、C、E、Bに関するエントリのみがデバイス・リスト28にコピーされる。
図11には、サーバのレスポンスの処理シーケンスをフローチャートの形式で示している。
デバイスは、ステップS111からS119までの一連のループ処理を行なっている。リモコン11からのリクエスト受信待ちを行なう(ステップS111)。リクエストを受信した場合、そのリクエストに示されたリモコンIDによってそのリクエストを受け付けるか破棄するかを判断する(ステップS112)。図14には、リクエスト・データの一般的な構造を示しているが、詳細は後述に譲る。このリクエスト・データから送信元のリモコンを示すリモコンID141を取得する。これをアクセス許可リスト34の全許可エントリ61のリモコンIDと順次照らし合わせて行く。もし一致するものがなければ、受信したリクエストは破棄される。一致した場合はそのリクエストを受け入れる。受け入れる場合にリクエストによって大きく3つに分岐する。
まず1つは、サーチ・リクエスト15を受信した場合である(ステップS113)。サーチ・リクエスト15は、SIRCS受信部122によりIRとして受信する。サーチ・リクエスト15の詳細については後述に譲る。
サーチ・リクエスト15を受信した場合、そのサーチ・デバイス・タイプ153が“Any”であるか若しくはデバイスのデバイス・タイプに一致するならば、直ちにサーチ・レスポンス16をリモコン11側の受信プロトコル154に従って送信する(ステップS115)。サーチ・レスポンス16の詳細については後述に譲る。
もう1つはPingリクエストを受信した場合である(ステップS116)。Pingリクエストの詳細については後述に譲る。Pingリクエストを受信した場合、デバイス12はPingランプ121を一定時間だけ点滅させる(ステップS117)。
最後の1つはコマンド・リクエスト18を受信した場合である(ステップS118)。コマンド・リクエスト18の詳細については後述に譲る。この場合、デバイス・タイプ毎に定義されている各コマンドに応じた処理が、コマンド・リクエスト18を受信したデバイス12により行なわれる。例えば、デバイス12がテレビであるならば、電源のon/offやチャンネルの切り替え、音量調節などである。
本実施形態では、IR通信としてSIRCSが利用されている。図13には、SIRCSの概要を示している。図示のように、SIRCSは、論理的に信号の開始を意味するリーダ・コードと、メーカや機器を区別するカスタム・コードと、カスタム・コード毎に定義されたさまざまな機能に対応するデータ・コードから成り立っている。本実施形態のようにIR上でサーチ・リクエスト15を送信する場合には、本実施形態に固有のカスタム・コードを定義する。これにより従来使われているSIRCS機器とのIR信号の混線を防ぐことができる。ちなみに本実施形態では、デバイスの種類毎にカスタム・コードを割り当てる必要はない。
図14には、本実施形態に係る通信システムにおいて使用される、基本となるデータ・フォーマットの構成例を示している。これは、リモコン11からデバイス12へ、並びにデバイス12からリモコン11へ、双方向で共通であり、また、SIRCS上でもIPネットワーク上でも共通の通信データ・フォーマットである。
参照番号141は送信元となるリモコンIDあるいはデバイスIDであり、リモコン11内の制御装置21で管理されるリモコンID23や、デバイス12内の制御装置31で管理されるデバイスID32に対応する。
参照番号142は、リクエスト、レスポンスなどの各データ・フレームのメッセージ・タイプを示すもので、それぞれのメッセージ毎に一意の値を持っている。本実施形態では、“サーチ・リクエスト”、“サーチ・レスポンス”、“Pingリクエスト”、“コマンド”の4種類を識別する。そして、参照番号143がメッセージ・タイプ毎にフォーマットが定義される領域である。
図15には、サーチ・リクエストの通信フォーマット例を示している。サーチ・リクエスト15は、これはリモコン11がSIRCS送信部111すなわち伝送媒体としてIRを使ってデバイスをサーチする場合に使用される。
参照番号142で示されるメッセージ・タイプ・フィールドには“サーチ・リクエスト”という値が入る。また、送信元リモコン名151には、送信元となるリモコンのリモコン名24が記載される。この値は本実施形態では利用されない値であるため、必須ではなく省略してもよい。
参照番号152は照合トークンであり、サーチ・リクエストを受信したデバイスはこの値をサーチ・レスポンスでそのまま返してくる。これによってリモコンがサーチ・リクエストを連発して送信した場合でもどのサーチ・リクエストに対するサーチ・レスポンスかを判断することができる。
参照番号153はサーチ・デバイス・タイプであり、リモコン11はどのようなデバイスを探しているかをこのフィールドで示すことができる。本実施形態では、リモコン11は固定値“Any”を送信することにしているため、有効には使われていない。ここで、“Any”とはすべてのデバイス・タイプを表す値である。
参照番号154は、リモコン11がIPネットワーク上でメッセージを受信するためのプロトコル情報が記される。本実施形態ではUDPかTCPを採用しているため、UDPかTCPの区別とIPアドレス、ポート番号が示される。
図16には、サーチ・レスポンスの通信フォーマット例を示している。サーチ・レスポンス16は、サーチ・リクエストを受信したデバイス12がリモコン11に対して返答するために使用される。図示の通信フォーマット構成は、上述したサーチ・リクエスト通信フォーマット15に類似している。
メッセージ・タイプ142には“サーチ・レスポンス”という値が使われる。送信元デバイス名161には送信元となるデバイスのデバイス名33が記載される。
照合トークン162には、送られてきたサーチ・リクエストに記載されている照合トークン152の値がそのまま入る。デバイス・タイプ163には、デバイスに定義されているデバイス・タイプが入る。
デバイスのリクエスト受信プロトコル164には、当該デバイスがリモコン11からのリクエストを受信する際に使用されるプロトコル情報が記される。本実施形態ではUDPかTCPを採用しているため、UDPかTCPの区別とIPアドレス、ポート番号が示される。
図17には、Pingリクエストの通信フォーマットを示している。Pingリクエストは、リモコン11がデバイス12のPingランプ121を一定時間点滅させる制御を行なう場合に使用される。
送信元リモコン名171は、送信元となるリモコン11のリモコン名24が記載される。この値は、本実施形態では利用されない値であるため、必須ではなく、省略してもよい。
図18には、コマンドの通信フォーマットを示している。コマンド18は、デバイス毎に固有の機能を制御したい場合に使われる。
メッセージ・タイプ142には“コマンド”という値が使われる。参照番号181には各デバイス・タイプで定義されたコマンド・タイプが入る。例えばテレビであるならば、“電源on/off”や“チャンネル切り替え”などのコマンドが考えられる。本発明の要旨はデバイス固有の機能には依存しないため、コンマ度・タイプに関しこれ以上の説明は行なわない。図18ではテレビのチャンネル切り替えを想定して書かれている。
以上、本実施形態に係る通信システムにおいて使用される各種通信フォーマットの構成について説明を行なったが、ここでは論理的な構造のみが示されている。実際にSIRCSや、IPネットワーク上でデータを送る場合はビット列に変換し送る必要がある。そのエンコーディングについては対応するデコーディングにより元と全く同じ情報を復元できる方式であるなら任意の方式でよい。例えば、ASN.1 BER/CER/DER形式やXML形式、あるいは全く独自のものであってもよい。
但し、サーチ・リクエスト15はSIRCS上で送信されるが、SIRCSで現実的にはせいぜい数倍と程度のデータしか安定して送ることができない。このため、ビット単位のエンコーディング方式を採用し、送信元リモコン名151を省略し、リモコンのレスポンス受信プロトコル154についてもUDPに固定し、ポート番号も特定の値に固定し、IPアドレスだけを送信するなどの手法にとることが現実的である。
以上本発明の実施形態について詳解してきた。ここで、具体的なシナリオを基に、一連の処理動作例について説明する。
図19には、リモコンと複数のデバイスからなる通信システムにおける具体的なシナリオの一例を動作シーケンスの形式で示している。ここでは、本発明が適用されたデバイスであるテレビが4台設置された環境において、ユーザがリモコンを使ってそれらテレビを操作しようとしている。
リモコンは初めて電源が投入され初期化が行なわれている。このときのデバイス・リスト25はすべて空である。この状態を図23(1)に示している。また、各テレビにおいて、アクセス許可リスト34にはリモコンのIDが事前に登録されているものとする。
まず、ユーザはテレビ2を操作したいと考え、テレビ2にリモコンを向けてあるコマンド・ボタンを押す。この様子を図24に示している。図示の操作により、図9にフローチャートの形式で示したコマンドの処理が行なわれる。さらにその処理中で、図10にフローチャートの形式で示したデバイスのサーチの処理が行なわれる。
リモコンよりSIRCS送信部111からサーチ・リクエスト15が投げられる。ここで、テレビ1とテレビ2はリモコンに近接しており(若しくはSIRCSの視野内に位置する)、サーチ・リクエスト15をともに受信できたことから、両方のテレビ1及び2からサーチ・レスポンス16が返される。
サーチ処理(S10)を終了したときには、リモコン11内のデバイス・リスト25は、図23(2)に示す状態になっている。この状態では、存在フラグがonで且つ選択候補フラグonとなっているデバイスがまだ存在しない。このため、存在が検出されたすべてのデバイスにPingリクエストを送信するという処理(ステップS96)が行なわれ、リモコンからテレビ1、テレビ2に対してPingリクエストが投げられる。この結果、テレビ1、テレビ2のPingランプがともに点滅する。同時に、リモコン上では、画像出力装置115又は音声出力装置116からコマンド送信が失敗したことがユーザに示される。
コマンド送信が失敗したことを受けて、ユーザはセレクト・ボタン113を押す。これにより、図8にフローチャートの形式で示されるセレクト処理が行なわれる。ターゲットが存在しないし、また初めてのセレクトでもあるので、ローテート・フラグはoffである(ステップS82)。
そして、セレクト処理により、存在が検出されたデバイスの中からアクセス対象とするデバイスが特定された後、再びサーチ処理(S10)が行なわれる。サーチ処理が終了した後のデバイス・リストは、前述と同じく、図23(2)の状態である。しかし、セレクト処理(S8)においては、ステップS810、並びにS89の処理が行なわれることで、デバイス・リストは図23(3)に示す状態になっている。したがって、ステップS812では、テレビ1に対してPingリクエスト17が送信され、テレビ1のPingランプ121が点滅し選択されたことになる。
しかし、テレビ1はユーザが狙ったデバイスでないため、ユーザはもう一度セレクト・ボタンを押す。これによって、セレクトの処理(S8)が再度起動されるが、前回のセレクトから間もないため、今回はステップS83にてローテート・フラグがonになる。サーチ処理(S10)の結果は上述と同様に図23(2)であるが、ローテート・フラグがonであるため、セレクト処理においてステップS87、S88、S89の処理が行なわれる。このとき、デバイス・リスト25は図23(4)の状態になっており、今度はテレビ2にPingリクエスト17が送信され、テレビ2が選択される。
テレビ2が選択されたのを受けて、ユーザは再度テレビ2に向けてコマンド・ボタンを押す。ここで、コマンドの処理(S9)がまた行なわれるが、サーチ処理(S10)の結果は図23(4)であるため、今度はステップS92、S94、S95、S98の処理が行なわれ、ステップS910にてテレビ2にコマンド18が送られ、テレビ2ではそのコマンドが実行される。
また、図20には、リモコンと複数のデバイスからなる通信システムにおける具体的なシナリオの他の例について、動作シーケンスの形式で示している。ここでは、ユーザはテレビ3を操作しようとしている。
ユーザは、リモコンをテレビ3に向けてコマンド・ボタンを押す。この様子を図25に示している。このコマンド・ボタンの操作に応答してコマンド処理(S9)が行なわれる。このコマンド処理中で行なわれるサーチ処理(S10)の結果は図23(5)のようになる。
コマンド処理において、ステップS92、S94、S99により、デバイス・リスト25は図23(6)に示す状態になり、ステップS910で今度はセレクトすることなくテレビ3にコマンドが送信されテレビ3にてコマンドが実行されることになる。
また、図21には、リモコンと複数のデバイスからなる通信システムにおける具体的なシナリオについてさらに他の例を動作シーケンスの形式で示している。今度はユーザはテレビ4を操作しようとしている。
ユーザは、テレビ4にリモコンを向けてコマンド・ボタンを押す。この様子を図26に示している。このコマンド・ボタンの操作により、コマンドの処理(S9)が行なわれる。このコマンド処理中でサーチ処理(S10)が行なわれ、リモコン11のSIRCS送信部111からサーチ・リクエスト15が投げられる。
ここで、テレビ1とテレビ4は近接しており(若しくはSIRCSの視野内に位置する)、サーチ・リクエスト15をともに受信できたことから、両方のテレビ1及び4からサーチ・レスポンス16が返される。
サーチ処理(S10)を終了した時には、リモコン11内のデバイス・リスト25は図23(7)に示す状態になっている。この状態では、存在フラグがonで且つ選択候補フラグonのデバイスが存在しない。このため、存在が検出されたすべてのデバイスにPingリクエストを送信するという処理(ステップS96)が行なわれ、リモコンからテレビ1、テレビ4に対してPingリクエストが投げられる。この結果、テレビ1、テレビ4のPingランプが点滅する。同時にリモコン上でコマンド送信が失敗したことがユーザに示される。
コマンド送信が失敗したことを受けて、ユーザはセレクト・ボタン113を押す。これによりセレクト処理(S8)が行なわれる。前回のセレクトから十分時間が経過しているため、ステップS82ではローテート・フラグはoffである。そして再びサーチ処理(S10)が行なわれる。
サーチ処理が終了した後のデバイス・リストの状態は、前述と同じく、図23(7)の状態である。しかし、セレクト処理(S8)においてはステップS810、S89の処理が行なわれることで、デバイス・リスト25は図23(8)に示す状態になっている。ステップS812でテレビ1に対してPingリクエストが送信され、テレビ1のPingランプが点滅し選択されたことになる。しかしテレビ1はユーザが狙ったデバイスでないため、ユーザはもう一度セレクト・ボタン113を押す。
これに応答してセレクトの処理(S8)が再度起動されるが、前回のセレクトから間もないため、今回はステップS83にてローテート・フラグがonになる。サーチ処理(S10)の結果は、同様に図23(8)であるが、ローテート・フラグがonであるため、ステップS87、S88、S89の処理が行なわれる。このとき、デバイス・リスト25は図23(9)の状態になっており、今度はテレビ4にPingパケットが送信されテレビ4が選択される。
テレビ4が選択されたのを受けて、ユーザは再度テレビ4に向けてコマンド・ボタンを押す。コマンドの処理(S9)がまた行なわれるが、サーチ処理(S10)の結果は図23(9)であるため、今度はステップS92、S94、S95、S98の処理が行なわれる。そして、ステップS910にてテレビ4にコマンド18が送られ、テレビ4ではそのコマンドが実行される。
また、図22には、リモコンと複数のデバイスからなる通信システムにおける具体的なシナリオについてさらに他の例を動作シーケンスの形式で示している。ここでは、再度ユーザはテレビ2を操作したいと考え、テレビ2に向けてリモコンのコマンド・ボタンを押す。この様子を図27に示している。
コマンドの処理(S9)が行なわれ、そこで、サーチの処理(S10)が行なわれる。テレビ1、テレビ2は近接しているため、テレビ1、テレビ2からともにサーチ・レスポンスが返ってくるが、ステップS1011、S1012により、選択候補フラグがonとなる最上位のテレビ2がターゲットとなる。これを表すデバイス・リスト25を図23(10)に示している。
以後、ステップS92、S94、S95、S98、S910により、テレビ4にコマンドが送信されコマンドが実行される。