JP6127552B2 - 情報処理装置 - Google Patents

Description

本発明は、外部との通信手段を備えた第１の情報処理ユニットと、第１の情報処理ユニットとデータ通信線を介して接続された第２の情報処理ユニットと、を有する情報処理装置に関する。

情報処理装置は、消費電力の低減要請に応えるため、内部が複数の電源ドメインに分割されている。電源制御回路は、消費電力が低減される省エネモード時、予め定められた必要な機能を含む電源ドメイン以外の電源を落とすことで、消費電力を低減する。

例えば、設計者は通信機能を１つの電源ドメインとしてサブシステム化し、省エネモード時はサブシステムにのみ電源が供給されるように設計する。他方の電源ドメインであるＣＰＵなどを搭載したメインシステムは、省エネモード時には電源が供給されない。したがって、情報処理装置としては省エネモード時も通信を行いながら、消費電力を低減することができる。

サブシステムはメインシステムに電源供給されている場合も、メインシステムで動作するアプリケーションが使用するデータの通信を受け持つが、サブシステムはメインシステムに比べ、メモリ量などに制限がある。つまり、通信用のリソース（例えば、バッファ）が例えばメインシステムや通信相手のサーバなどと比べて少ない。このため、一回の送受信で交換できるデータ量が少なく、結果としてメインシステムのアプリケーションへのデータ供給が遅れる場合がある。このように、サブシステムとメインシステムが分割され、サブシステムが通信する構成の場合、サブシステムがボトルネックになるおそれがあった。

このような不都合に対して通信プロセスに割り当てるバッファを可変とする技術が考えられる（例えば、特許文献１参照。）。特許文献１には、未実行中の処理プロセスからバッファの割り当て要求があった場合、優先順位に基づいて実行中の処理プロセスに割り当てられているバッファブロック数を減少させることによって、未実行中の処理プロセスに割り当てるバッファブロックを確保して、未実行中の処理プロセスに割り当てるバッファバッファの動的管理方法が開示されている。

しかしながら、特許文献１に記載されたバッファの割り当て方法では、実行中の処理プロセスの優先順位に基づいて減少されるバッファブロック数を決定するので、優先される処理プロセスが多く動作していれば割り当てが不十分になるという問題がある。すなわち、処理プロセスのそれぞれは最低限必要なバッファブロックが確保されるため、未実行中の処理プロセスに割り当てるバッファブロック数が少ない状態になる場合があり、バッファブロックが少ないことがボトルネックになるおそれがあることに変わりがない。

本発明は、サブシステムが通信のボトルネックになることを抑制可能な機器を提供することを目的とする。

本発明は、外部との通信手段を備えた第１の情報処理ユニットと、前記第１の情報処理ユニットとデータ通信線を介して接続された第２の情報処理ユニットと、を有する情報処理装置であって、前記第２の情報処理ユニットは、複数の情報処理手段と、前記第２の情報処理ユニットの動作モードに前記第１の情報処理ユニットの動作モードを紐づけた複数の第２のテーブルと、前記第２のテーブルの第２の選択ポリシーが記憶された第２の選択ポリシー記憶手段と、前記第２の選択ポリシー記憶手段に記憶された前記第２の選択ポリシーに基づき前記第２のテーブルを選択する第２のテーブル選択手段と、前記第２のテーブル選択手段が選択した前記第２のテーブルから、前記第２の情報処理ユニットの動作モードに紐づけられた前記第１の情報処理ユニットの動作モードを読み出し前記第１の情報処理ユニットに送信する動作モード送信手段と、を有し、
前記第１の情報処理ユニットは、前記通信手段が外部から受信したデータを記憶させるデータ記憶手段と、前記第２の情報処理ユニットの動作モードにより定まる前記第１の情報処理ユニットの動作モードごとに、各情報処理手段が使用するデータのために確保される領域サイズが紐づけられた第１のテーブルと、前記データ記憶手段の容量のうち、前記第１のテーブルにて現在の前記第１の情報処理ユニットの動作モードに紐づけられた前記領域サイズの領域を、前記情報処理手段に割り当てる領域割り当て手段と、を有し、
前記第１の情報処理ユニットの前記領域割り当て手段は、前記第１のテーブルにおいて、前記第２の情報処理ユニットから受信した前記第１の情報処理ユニットの動作モードに紐づけられた前記領域サイズの領域を、前記情報処理手段に割り当てる、ことを特徴とする。

サブシステムが通信のボトルネックになることを抑制可能な機器を提供することができる。

本実施形態の機器によるサブシステムの特徴を概略的に説明する図の一例である。 本実施形態の機器を含むネットワークシステムの概略構成図の一例である。 プロジェクタのブロック図、通信相手装置のハードウェア構成図の一例である。 メインシステムとサブシステムの機器構成を示す図の一例である。 メインシステムとサブシステムの機能ブロック図の一例である。 機器モードテーブル、割り当てテーブルの一例を示す図である。 機器がバッファ領域の割り当てを変更してファームウェアを更新する手順を示すフローチャート図の一例である。 サブシステムがバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。 割り当てテーブルを示す図の一例である（実施例２）。 バッファ領域（通信部）とバッファ領域（内部通信）の模式的な構成図の一例である。 メインシステムとサブシステムの機能ブロック図の一例である（実施例３）。 機器サブセット、機器サブセット毎の機器モードテーブルの一例を示す図である。 サブシステムがバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。 メインシステムとサブシステムの機能ブロック図の一例である（実施例４）。 サブバッファセット、サブバッファセット毎の割り当てテーブルの一例を示す図である。 サブシステムがバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。 メインシステムとサブシステムの機能ブロック図の一例である（実施例５）。 アカウントテーブルの一例を示す図である。 メインシステムとサブシステムの機器構成を示す図の一例である（実施例６）。 サブシステムがバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。 メインシステムとサブシステムの機器構成を示す図の一例である（実施例７）。 メインシステムとサブシステムの機能ブロック図の一例である（実施例７）。 機器モードテーブルの一例を示す図である。 サブシステムがバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。 メインシステムとサブシステムの機能ブロック図の一例である（実施例８）。 表示パターンテーブルの一例を示す図である。 メインシステムとサブシステムの機器構成を示す図の一例である（実施例９）。 メインシステムとサブシステムの機能ブロック図を示す図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。しかしながら、本発明の技術的範囲が、本実施の形態に限定されるものではない。

図１は、本実施形態の機器によるサブシステムの特徴を概略的に説明する図の一例である。機器１００はメインシステム５０とサブシステム２０を有し、メインシステム５０で動作するアプリ１〜ｎに対し、サブシステム２０がメモリにアプリ１〜ｎ用のバッファを確保する。

本実施形態では機器１００の機能を考慮していくつかの機器モードが定義されている。機器モードは、例えば大量のデータを扱うアプリが動作しているかどうかにより分類されている。
通常モード：アプリ１〜ｎはそれぞれ任意のデータを扱う
動画投影モード：動画データを受信するため大量のデータを扱う
ファームウェア更新モード：ファームウェアを受信するため大量のデータを扱う
サブシステムは、機器モードに対応するサブシステムモードで動作し、サブシステムモードに応じてアプリ１〜ｎに割り当てるバッファ領域のサイズを決定し、割り当てる。

図１（ａ）は機器モードが通常モードの場合のバッファ割り当ての一例を説明する図の一例である。通常モードでは、サブシステムモードは定常設計割り当てとなる。このため、アプリ１〜ｎが扱うデータのデータサイズに応じて、アプリ１〜ｎ用の予め定められたバッファ領域が割り当てられている。例えばアプリ２は、アプリ１，３よりも大きなバッファ領域が割り当てられている。

図１（ｂ）は機器モードがファームウェア更新の場合のバッファ割り当ての一例を説明する図の一例である。ファームウェア更新モードでは、サブシステムモードは単一アプリ占有割り当てとなる。このため、ファームウェアの更新対象となるアプリＸ用のバッファ領域として、バッファ領域をアプリＸが占有している。すなわち、サブシステムが大量のデータを受信するので、バッファ領域を可能な限り大きくすることで、通信相手装置は一度に多くのデータを送信できるため高速な通信が可能になる。

このように、本実施例では機器がどのようなデータを扱うかによって、同じアプリ（例えばアプリＸ）が動作する場合でも、サブシステムのバッファ領域の割り当てを変更できる。例えば、アプリＸのファームウェアが更新される場合、アプリＸ用のバッファ領域が充分に大きいのでボトルネックとなるおそれを低減できる。

〔構成例〕
図２は、本実施形態の機器１００を含むネットワークシステム５００の概略構成図の一例を示す。ネットワークを介して機器１００と通信相手装置２００が接続されている。ネットワーク３００は、ＬＡＮ、又は、複数のＬＡＮがルータなどを介して接続されたＷＡＮである。ＷＡＮにはインターネットが含まれる。ネットワーク３００は有線で構築されていてもよいし、一部又は全てが無線ＬＡＮ（IEEE802.11b/a/g/n等）で構築されていてもよい。さらに、ネットワーク３００は携帯電話網、WiMAX網、ＰＨＳ網などの移動体向けに構築された通信網を含む。なお、機器１００と通信相手装置２００が無線ＬＡＮのアドホックモードなどで１対１で通信しても、ネットワーク３００により接続されているとして説明する。

機器１００は、通信相手装置２００と通信して動作するアプリに応じた処理を行う。機器１００は、どのようなものでもよいが、例えば、プロジェクタ、画像形成装置、テレビ会議端末、携帯端末、クライアント端末などである。プロジェクタは動画データ、画像データを受信してスクリーンなどに投影する。画像形成装置は、コピー機、スキャナー、プリンタ、ファックス装置など画像を形成する機能を備えた装置である。画像形成装置はこのうち１つ以上の機能を有していればよい。携帯端末は、例えば、携帯電話、スマートフォン、タブレット端末、ＰＤＡ（Personal Digital Assistant）、デジタルカメラなど、ユーザが携帯又は所持する端末である。クライアント端末はノートＰＣ、デスクトップＰＣ、ワークステーションなどユーザが使用する情報処理装置である。

通信相手装置２００は、機器１００として説明した具体的な装置でもよいし、サーバ装置やシンクライアント等の情報処理装置でもよい。通信相手装置２００は、機器１００と該通信相手装置２００の具体的な組み合わせに応じたデータを機器１００に送信する。通信相手装置２００は、例えばプロジェクタ（機器１００）に対し動画データを送信するクライアント端末であり、画像形成装置（機器１００）に印刷データを送信するクライアント端末であり、テレビ会議端末（機器１００）にカメラが撮影した動画データを送信するテレビ会議端末であり、携帯端末（機器１００）にＷｅｂデータや音声データを送信するサーバや携帯端末である。また、各種の機器１００に対し更新用のファームウェアを送信するサーバでもありうる。

図３（ａ）は、プロジェクタのブロック図の一例を示す。プロジェクタ１１０は、上述したサブシステム２０とメインシステム５０を有している。メインシステム５０はコントローラ１０２により制御され、コントローラ１０２にフラッシュメモリ１０１、ＲＡＭ１０３、画像投影部１０４、画像処理部１０５、及び、操作入力部１０６が接続されている。

サブシステム２０は通信相手装置２００と通信して動画データを受信する。サブシステム２０については後述する。入力される画像データは、ネットワーク経由で送信されるデジタルデータ（ＭＰＥＧ２、ＷＭＶ、ＭＰ４、Ｈ．２６４、ＪＰＥＧ、ＢＭＰ、ＧＩＦ、ＰＮＧなど）である。但し、プロジェクタ１１０としては、Ｄ−Ｓｕｂ、ＢＣＮ、ＨＤＭＩなどのインタフェースで送信される映像信号（NTSC、PAL、SECAM）を投影する機能を有している。

動画データは、コントローラ１０２を介して画像処理部１０５へ入力される。画像処理部１０５は、画像投影用に動画データに処理を施す。例えば、動画データを圧縮形式に応じてデコードし、動画データの解像度をプロジェクタ１１０が対応する解像度に変換したり、ＲＧＢの各色の画像への分解、所定の色信号を強調・減衰したり、画像の周辺の先鋭度を高くするなどの処理を行う。

画像投影部１０４は、ＬＣＤ（Liquid Crystal Display）、ＤＬＰ（Digital Light Processing）、ＬＣＯＳ（Liquid crystal on silicon）などの光学デバイス及び光学系である。コントローラ１０２は画像処理部１０５がＲＡＭ１０３に記憶した投影データを読み出して画像投影部１０４を制御することで投影データを投影する。

フラッシュメモリ１０１には、プログラム１０９を含む色の調整値などのパラメータなどのファームウェアが記憶されている。プログラム１０９は、インストール可能な形式又は実行可能な形式のファイルで、コンピュータで読み取り可能な記録メディアに記録して配布される。また、プログラム（又はファームウェア）は、不図示のサーバからインストール可能な形式又は実行可能な形式のファイルで配布される。

操作入力部１０６は、ユーザの操作を受け付けるハードキー、タッチパネル式の液晶などに表示されたソフトキー、又は、音声入力装置などである。

図３（ｂ）は、通信相手装置２００のハードウェア構成図の一例を示す。通信相手装置２００は、バスに接続された、ＣＰＵ２０１、ＲＯＭ２０２、ＲＡＭ２０３、ＨＤＤ２０４、ディスプレイ２２０が接続されたグラフィックボード２０５、キーボード・マウス２０６、メディアドライブ２０７、及び、ネットワーク通信部２０８を有する。

ＣＰＵ２０１はＨＤＤ２０４に記憶されたプログラム２１０をＲＡＭ２０３に展開して実行し、各部品を制御して入出力を行ったり、データの加工を行ったりする。ＲＯＭ２０３にはＢＩＯＳや、ブートストラップローダをＨＤＤ２０４からＲＡＭ２０３に読み出す小さなプログラムが記憶されている。ブートストラップローダは、ＯＳをＨＤＤ２０４からＲＡＭ２０３に読み出す。

ＨＤＤ２０４は、不揮発性のメモリであればよくＳＳＤ（Solid State Drive）などでもよい。ＨＤＤ２０４はＯＳ、デバイスドライバ、及び、通信相手装置２００に必要な機能を提供するプログラム２１０を記憶している。ディスプレイ２２０にはプログラム２１０が指示し、グラフィックボード２０５が作成したＧＵＩ画面が表示される。

キーボード・マウス２０６はユーザの操作を受け付ける入力装置である。メディアドライブ２０７はコンパクトディスク、ＤＶＤ及びブルーレイディスクなどの光学メディアにデータを読み書きする。また、フラッシュメモリなどのメモリカードにデータを読み書きしてもよい。ネットワーク通信部２０８は、例えばＬＡＮに接続するためのイーサネット（登録商標）カードである。ＴＣＰ／ＩＰ（ＵＤＰ／ＩＰ）やアプリケーション層のプロトコルの処理はＯＳやプログラム２１０が行う。アプリケーション層のプロトコルは各種あるが、例えばＳＮＭＰ（Simple Network Management Protocol）、ＨＴＴＰ、ＦＴＰ、ＳＭＢ（Server Message Block）等がある。

プログラム２１０は、インストール可能な形式又は実行可能な形式のファイルで、コンピュータで読み取り可能な記録メディアに記録して配布される。また、プログラム２１０は、不図示のサーバからインストール可能な形式又は実行可能な形式のファイルで配布される。

〔機能的な構成例〕
図４は、メインシステム５０とサブシステム２０の機器構成を示す図の一例である。メインシステム５０とサブシステム２０はそれぞれ別の基板、ＡＳＩＣ、ＦＰＧＡ、又は、ＳｏＣ（System On Chip）などで構成されている。メインシステム５０とサブシステム２０はデータやコマンドを送受信する線７０で接続されている。

メインシステム５０はバスに接続されたＣＰＵ４１、ＲＡＭ４２、フラッシュメモリ４３、及び、外部接続端子４４を有している。ＣＰＵ４１と外部接続端子４４は図３（ａ）の例ではコントローラ１０２に含まれている。

機器１００は不図示のメイン電源を有しているが、メイン電源がＯＮの状態でも動画データを受信しない時間や操作入力部１０６がユーザの操作を受け付けない時間が所定時間を超えると、省エネモードに移行する。省エネモードではＲＡＭ４２にプログラムやデータを記憶したまま、ＣＰＵ４１の動作クロックが低減されたり、最小限の回路を除いて電源がＯＦＦにされる。省エネモードのメインシステム５０は、動画データを受信したり、操作入力部１０６がユーザの操作を受け付けることでウェイクアップして、通常動作モードに復帰する。

サブシステム２０は、メインシステム５０が省エネモードに移行しても、省エネモードには移行しない。メインシステム５０が省エネモードとなることで消費電力を抑制し、かつ、サブシステム２０が比較的負荷の軽い処理（例えば通信）を実行できる。

サブシステム２０はＣＰＵ１１、ＲＡＭ１２、外部接続端子１４、及び、外部通信装置１３を有する。サブシステム２０及びメインシステム５０の外部接続端子１４，４４は、例えばＵＳＢ（Universal Serial Bus）、IEEE1394、ＳＡＴＡ（Serial ATA）など通信端子である。サブシステム２０とメインシステム５０が高速に通信可能であればよい。有線でなく無線で通信可能に接続されていてもよい。外部通信装置１３は、通信相手装置２００のネットワーク通信部と同等の通信装置である。

例えばメイン電源のＯＮによりプロジェクタ１１０が起動した時に、メインシステム５０からサブシステム２０にプログラム１０９の一部が送信される。サブシステム２０は、不図示のＲＯＭに、外部接続端子１４が受信したプログラム１０９をＲＡＭ１２にコピーするプログラムを記憶しており、コピー後はＲＡＭに記憶されたプログラム１０９を実行する。このプログラム１０９は、通信相手装置２００と通信する機能、メインシステム５０にデータを転送する機能、及び、ＲＡＭ１２に配置される各アプリ１〜ｎのバッファ領域のサイズを変更する機能などを有している。なお、メインシステム５０からサブシステム２０にプログラム１０９を送信するのでなく、サブシステム２０がプログラムをフラッシュメモリなどに記憶していてもよい。

図５はメインシステム５０とサブシステム２０の機能ブロック図の一例を示す。

・メインシステム
メインシステム５０は、アプリ５５（以下、区別するためアプリ１〜ｎという）、機器モード設定部５２、機器モードテーブル５１、送受信部５４、及び、機器モード記録領域５３を有している。アプリ１〜ｎは、機器１００に特有の機能を提供するアプリであり、プロジェクタ１１０では例えば画像を投影するためのアプリ、投影輝度や倍率の設定を受け付けるアプリなどがある。画像形成装置では、例えばコピーアプリ、プリンタアプリ、スキャナアプリなどがある。アプリ１〜ｎはＲＡＭ４２を使用するが、メインシステム５０のＲＡＭ４２はサブシステム２０のＲＡＭ１２と比較して大きな容量を有している。

機器モード設定部５２は、ユーザの操作、通信相手装置２００からの制御、などに起因するイベントに応じて、機器モードを決定し機器モード記録領域５３に記憶する。機器モード記録領域５３には現在の機器モードが記憶される。機器モードについては図６（ａ）にて説明する。また、機器モード設定部５２は、機器モードテーブル５１を参照し現在の機器モードに対応づけられたサブシステムモードを決定する。

送受信部５４はサブシステム２０との間でデータを受信したりコマンドを送信したりする。受信するデータとしては、動画データ、印刷データなど、機器１００の種類に応じて種々のものがあり、また、更新用のファームウェアの場合がある。また、送信するコマンドは、例えば上記のサブシステムモード、省エネモードに移行したことの通知、などがある。

・サブシステム
サブシステム２０は、サブシステムモード設定部２３、サブシステムモード記録領域２２、バッファ領域割り当て部２４、通信部２５、送受信部２６、及び、割り当てテーブル２１を有する。サブシステムモード記録領域２２には、最後にメインシステム５０から取得したサブシステムモードが記憶されている。

サブシステムモード設定部２３は、メインシステム５０からサブシステムモードを取得した場合に、サブシステムモード記録領域２２のサブシステムモードと比較して、サブシステムモードが変更されたか否かを判定する。

バッファ領域割り当て部２４は、サブシステムモードに応じて各アプリ１〜ｎへのバッファ領域の割り当てを変更する。割り当てテーブル２１には、サブシステムモードに対応づけてバッファ領域の割り当て方法が登録されている。割り当てテーブル２１については図６（ｂ）にて説明する。

送受信部２６はメインシステム５０にデータを送信し、コマンドを受信する（データを受信しコマンドを送信してもよい）。通信部２５はネットワーク３００に接続して、通信プロトコルに応じた処理を行い、データをＲＡＭ１２に記憶する。例えば、ＴＣＰ／ＩＰでは、ポート番号で、通信相手装置２００から受信したデータの宛先のアプリが判別されるので、通信部２５はポート番号に基づきアプリを判断し、アプリに割り当てられたバッファ領域にデータを記憶する。送受信部２６は、通信部２５からデータが受信されたことを検出してＲＡＭ１２のデータをメインシステム５０に送信する。

図６（ａ）は機器モードテーブル５１の一例を示す図である。機器モードには、例えば、「通常モード」、「動画投影モード」、及び、「ファームウェア更新モード」がある。各機器モードにはサブシステムモードが設定されている。サブシステムモードはバッファ領域の割り当て方法を指定する割り当て方法の名称である。設計者などは各機器モードにおいて送受信されるデータのサイズを考慮して「サブシステムモード」を決定している。通常モードでは「定常設計割り当て」というサブシステムモードが、動画投影モードには「単一アプリ占有割り当て」というサブシステムモードが、ファームウェア更新モードには「単一アプリ占有割り当て」というサブシステムモードが、それぞれ対応づけられている。

図６（ｂ）は割り当てテーブル２１の一例を示す図である。サブシステムモードが定常設計割り当ての場合、及び、単一アプリ占有割り当ての場合のそれぞれに、具体的なバッファ割り当て方法が規定されている。例えば、送信用と受信用それぞれのバッファ領域のサイズが規定されている。

定常設計割り当ては通常モードに対応した割り当て方法なので、各アプリ１〜ｎがそれぞれ動作している状況に適切なバッファ領域がアプリ１〜ｎに対し確保される。すなわち、アプリ１〜ｎが使用するデータのサイズを想定して各アプリのバッファ領域のサイズが規定されている。単一アプリ占有割り当ては大容量のデータが受信される機器モード（動画投影モード、ファームウェア更新モード）に対応した割り当て方法なので、データを使用する１つのアプリＸ（Ｘは１〜ｎ）にＲＡＭ１２のバッファ領域の大部分が確保される。

〔動作手順〕
図７は、機器１００がバッファ領域の割り当てを変更してファームウェアを更新する手順を示すフローチャート図の一例である。ここでは、ファームウェアの更新を例に説明するが、ファームウェアの更新を行うアプリを更新実行アプリと記載した。更新実行アプリはアプリ１〜ｎの１つである。
S1：ユーザが機器１００のアプリケーションＸのファームウェアを更新するため、更新実行アプリ（アプリ３）に対しファームウェアの更新操作を行う。更新実行アプリはファームウェアを受信する通信利用アプリケーションである。
S2：更新実行アプリは機器モード設定部５２に、ファームウェア更新のための機器モードに変更するよう依頼する。更新実行アプリは機器モード設定部５２から依頼の受け付けの成否を取得する。
S3：機器モード設定部５２は機器モード記録領域５３に機器モード（ファームウェア更新モード）を設定し、更新実行アプリに機器モードの変更を通知する。更新実行アプリは機器モード設定部５２に通知の受け付けＯＫを送信する。
S4：機器モード設定部５２は、更新対象のアプリケーションＸに機器モードの変更を通知する。アプリケーションＸは機器モード設定部５２に通知の受け付けＯＫを送信する。
S5：機器モード設定部５２は、S3、S4の応答がすべてＯＫの場合に、サブシステム２０にサブシステムモード(単一アプリ占有モード)を通知してサブシステムモードの変更を依頼する。
S5.1：サブシステムモード設定部２３は、サブシステムモードを取得してサブシステムモード記録領域２２に通知されたサブシステムモードを記録する。サブシステムモード設定部２３はバッファ領域割り当て部２４にサブシステムモードの変更を通知する。
S5.1.1：バッファ領域割り当て部２４は割り当てテーブル２１を参照して、ＲＡＭ１２におけるバッファ領域の割り当てを変更する。バッファ領域割り当て部２４はサブシステムモード設定部２３に変更ＯＫを送信する。
S5.2：サブシステムモード設定部２３は通信部２５にサブシステムモードの変更を通知する。通信部２５は、サブシステムモード設定部２３に通知の受け付けＯＫを送信する。
S6：サブシステムモード設定部２３は、バッファ領域割り当て部２４及び通信部２５からの応答がすべてＯＫの場合に、メインシステム５０の機器モード設定部５２にOKを返す。
S7：機器モード設定部５２は、更新実行アプリに更新を許可するOKを通知する。
S8：更新実行アプリは、ユーザによるファームウェア更新の依頼内容に応じて、サブシステム２０の通信部２５にファームウェアのダウンロードの開始を依頼する。これにより、通信部２５はファームウェアを通信相手装置２００から受信して確保されたバッファ領域に記憶する。送受信部２６は、例えばバッファ領域がいっぱいになると、メインシステム５０にファームウェアを送信する。更新実行アプリはフラッシュメモリ４３のアプリケーションＸのファームウェアを更新する。

図８は、サブシステム２０がバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。図８は図７の主にステップＳ5.1.1の処理について説明している。

上述したようにメインシステム５０の機器モード設定部５２が機器モードを決定する（Ｓ１１０）。

機器モード設定部５２は機器モードテーブル５１を参照してサブシステムモードを決定し、サブシステムに通知する（Ｓ１２０）。

サブシステムの送受信部２６はサブシステムモードを受信する（Ｓ２１０）。

サブシステムモード設定部２３はサブシステムモードが変更されたか否かを判定する（Ｓ２２０）。通知されたサブシステムモードが、サブシステムモード記録領域のサブシステムモードと同じ場合はバッファ領域の割り当てを変更する必要がないためである。

サブシステムモードが変更された場合（Ｓ２２０のＹｅｓ）、バッファ領域割り当て部２４はバッファ領域の割り当てを変更する（Ｓ２３０）。

その後、通信部２５は通信を開始する（Ｓ２４０）。

以上説明したように、本実施例のネットワークシステム５００は、機器モードに応じてサブシステム２０のバッファ領域の割り当てを変更するのでバッファ領域を機器モードに最適化できる。ＲＡＭ１２の容量が小さくても、大きなデータを受信する場合はバッファ領域を最大限に広げるので、ボトルネックとなることを抑制できる。

なお、実施例１の各機能の配置は一例にすぎない。例えば、機器モードテーブル５１はサブシステムに配置されてもよく、割り当てテーブル２１がメインシステムに配置されてもよい。また、機器モード設定部５２がサブシステムに配置されてもよく、サブシステムモード設定部２３がメインシステムに配置されてもよい。また、アプリの一部をサブシステムが有していてもよい。

実施例１では、機器１００が通信相手装置２００と通信する際のバッファ領域の割り当てを変更したが、本実施例ではメインシステム５０とサブシステム２０が通信する際のバッファ領域の割り当てを変更する機器１００について説明する。

機能ブロック図は実施例１と変更はないが、割り当てテーブル２１の構成が変更される。図９は本実施例の割り当てテーブル２１を示す図の一例である。本実施例の割り当てテーブル２１は、サブシステムモードに応じて内部通信用のバッファ領域のサイズを規定している。つまり、サブシステム２０がメインシステム５０に送信するデータが記憶されるバッファ領域のサイズが規定されている。

本実施例においても、通信部２５が通信先相手から受信したデータがバッファ領域に確保されるので、データはバッファ領域（通信部）からバッファ領域（内部通信）に転送される。

図１０は、バッファ領域（通信部）とバッファ領域（内部通信）の模式的な構成図の一例を示す。通信部２５が通信したデータはバッファ領域（通信部）Ｂ１に一時的に記憶され、所定量のデータが記憶されると例えばＤＭＡＣ（Direct Memory Access Controller）などによりバッファ領域（通信部）からバッファ領域（内部通信）に転送される。なお、バッファ領域（通信部）Ｂ１も、実施例１と同様にアプリ毎にバッファ領域が割り当てられていてもよい。

図9に示すように、定常設計モードではアプリ１〜ｎに適切なバッファ領域が割り当てられ、単一アプリ占有モードではアプリＸにバッファ領域（内部通信）の大部分が割り当てられる。単一アプリ占有モードでは通信部２５が大量のデータをバッファ領域（通信部）に記憶するが、バッファ領域（内部通信）も大きな容量が確保されているので、ボトルネックとならずにサブシステム２０がメインシステム５０にデータを送信できる。

なお、本実施例及び実施例１は、以下の実施例に共通に適用可能であり、以下では、特に区別しないで説明する。

実施例１では、大きなバッファ領域が割り当てられたアプリ以外のアプリは、バッファ領域の割り当てが減少し通信が遅くなる場合がある。このため、大きなデータを受信しない機器であれば極端なバッファ領域の割り当てが好ましくない場合もある。そこで、本実施例では、機器モードに応じてバッファ領域の割り当てを行うか否かを、機器ごとに設定可能な機器１００について説明する。

これにより、ネットワーク動画再生を主に行う機器１００は、動画再生するアプリのバッファ領域を増やす設定にすることにより快適な再生を可能とし、それ以外の機器１００ではアプリ間でバランスのとれた複数機能の同時利用が可能となる。

図１１は、メインシステム５０とサブシステム２０の機能ブロック図の一例である。本実施例において、図５において同一の符号を付した構成要素は同様の機能を果たすので、主に本実施例の主要な構成要素についてのみ説明する場合がある。本実施例のメインシステム５０は、複数の機器モードテーブル５１とテーブル切替部５６を有する。

テーブル切替部５６は、機器サブセットに応じて機器モードテーブル５１を切り替える。機器サブセットとは、機器モードテーブル５１を選択するためのポリシーである。

図１２（ａ）は機器サブセットの一例を示す図である。図１２（ａ）では２つの機器サブセットが図示されており、Ｎｏ１が「アプリによって高速化する」、Ｎｏ２が「オススメ（出荷時設定）」である。「アプリによって高速化する」とは、実施例１，２のように機器モードに応じてバッファ領域の割り当てを任意に制御するポリシーであり、「オススメ（出荷時設定）」とは、機器モードに関わらずバッファ領域の割り当てに変更がないポリシー（従来と同じ）である。

図１２（ｂ）は機器サブセット毎の機器モードテーブル５１の一例を示す図である。Ｎｏ１「アプリによって高速化する」の機器モードテーブル５１は、実施例１と同様である。Ｎｏ２「オススメ（出荷時設定）」の機器モードテーブル５１は、機器モードに関係なく定常設計割り当てが対応づけられている。

したがって、現在の機器サブセットに応じて機器モードテーブル５１が切り替えられることで、機器モードに応じてバッファ領域の割り当てを変更するか否かを制御可能になる。

なお、機器サブセットは、予め機器１００に設定されているか、ユーザや管理者が操作により変更したり、通信相手装置２００が変更することができる。機器１００が機器サブセットの設定を受け付けると、機器モード記録領域５３に登録し、テーブル切替部５６が機器モードテーブル５１を切り替える。

図１３は、サブシステム２０がバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。

例えばユーザにより機器サブセットが変更される（Ｓ１０２）。

テーブル切替部５６は変更後の機器サブセットに応じて機器モードテーブル５１を切り替える（Ｓ１０４）。

メインシステム５０が機器モードを決定する（Ｓ１１０）。

機器モード設定部５２は機器モードテーブル５１を参照してサブシステムモードを決定し、サブシステムに通知する（Ｓ１２０）。

以降の処理は、実施例１と同様である。これにより、サブシステム２０は機器サブセットに応じてバッファ領域の割り当てを変更できる。

以上説明したように、本実施例の機器１００は、機器サブセットに応じて機器モードテーブル５１を切り替えるので、機器によってバッファ領域の割り当てを変更するか否かを設定することができる。例えば、通信負荷の高いアプリ（例えばファームウェアダウンロードやネットワーク動画再生）を特に高速化したい機器だけ、バッファ領域の割当て変更を適用できるようになる。

実施例３では機器モードテーブル５１が切り替えられたが、本実施例では、サブシステム２０が複数の割り当てテーブル２１を有し、サブシステム２０の現在のサブバッファセットに応じて割り当てテーブル２１を切り替える機器１００について説明する。これにより、実施例３と同様の効果を奏することができる。

図１４は、メインシステム５０とサブシステム２０の機能ブロック図の一例である。本実施例のサブシステム２０は、複数の割り当てテーブル２１と割り当てテーブル切替部２７を有している。割り当てテーブル切替部２７は、サブバッファセットに応じて割り当てテーブル２１を切り替える。サブバッファセットとは、割り当てテーブル２１を選択するためのポリシーである。

図１５（ａ）はサブバッファセットの一例を示す図である。図１５（ａ）では２つのサブバッファセットが図示されており、Ｎｏ１が「バランス優先」、Ｎｏ２が「速度最優先」である。「バランス優先」とは、機器モード毎にアプリ1〜ｎにバランスよく（特定のアプリにバッファ領域の割り当てを偏らせるのでなく）バッファ領域を割り当てるポリシーであり、「速度最優先」とは、機器モード毎に任意のアプリの通信速度が最も速くなるようにバッファ領域を割り当てるポリシーである。

図１５（ｂ）はサブバッファセット毎の割り当てテーブル２１の一例を示す図である。Ｎｏ１「バランス優先」の割り当てテーブル２１は、定常設計割り当てではアプリ１〜ｎに均等にバッファ領域が割り当てられ、単一アプリ占有割り当てではアプリＸに全バッファ領域の半分程度のバッファ領域が割り当てられている。

Ｎｏ２「速度最優先」の割り当てテーブル２１は、定常設計割り当てではアプリ１〜ｎ毎に異なる（使用するデータ量が考慮された）バッファ領域が割り当てられ、単一アプリ占有割り当てではアプリＸに全バッファ領域のバッファ領域が割り当てられている。

したがって、現在のサブバッファセットに応じて割り当てテーブル２１が切り替えられることで、サブシステムモードに応じてバッファ領域の割り当て方法を変更できる。

サブバッファセットは、予め機器１００に設定されているか、ユーザが操作により変更したり、通信相手装置２００が変更することができる。機器１００がサブバッファセットの設定を受け付けると、送受信部５４が送受信部２６にサブバッファセットを送受信して、サブシステムモード記録領域２２に記憶する。割り当てテーブル切替部２７はサブバッファセットに応じて割り当てテーブル２１を切り替える。

なお、図１４は実施例３の構成（図１１）を受け継いで説明したが、本実施例ではサブシステムがバッファ領域の極端な割り当てを行うかどうかを決定できるので、メインシステム５０は機器モードテーブル５１の切り替えを行わなくてもよい。しかし、メインシステム５０が機器サブセットに応じて機器モードテーブル５１を切り替えれば同じ機器モードでも異なるサブシステムモードが選択される。そして、サブシステムがサブバッファセットに応じて割り当てテーブル２１を切り替えるので、バッファ領域の割り当てをより細かく制御できるようになる。すなわち、機器サブセットとサブバッファセットの組み合わせに応じて、バッファ領域の割り当てをさらに最適化できる。

図１６は、サブシステム２０がバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。実施例３の図１３に対し、ステップＳ１１０の機器モードの決定に続いて、サブバッファセットが変更される（Ｓ１１２）。

メインシステムは、サブシステム２０に変更後のサブシステムモードとサブバッファセットを通知する（Ｓ１２０）。

サブシステムはサブシステムモードとサブバッファセットを受信する（Ｓ２１２）。

割り当てテーブル切替部２７は、サブバッファセットに応じて割り当てテーブル２１を切り替える（Ｓ２１４）。

サブシステムモード設定部２３は機器モード又はサブバッファセットが変更されたか否かを判定する（Ｓ２２２）。

機器モード又はサブバッファセットのどちらか一方でも変更された場合（Ｓ２２２のＹｅｓ）、バッファ領域割り当て部２４はバッファ領域の割り当てを変更する（Ｓ２３０）。

その後、通信部２５は通信を開始する（Ｓ２４０）。

以上説明したように、本実施例の機器１００は、サブバッファセットに応じて割り当てテーブル２１を切り替えるので、機器によって同じサブシステムモードが指示されても、バッファ領域の割り当てを機器１００に最適化することができる。

本実施例では、ログインしたユーザに応じて機器サブセットを選択するネットワークシステム５００について説明する。

実施例３では、ユーザが機器サブセットを設定する場合があると説明したが、ユーザが設定した場合、同じユーザであれば同じ機器サブセットを好む場合がある。この場合、ユーザが再度、設定することなく自動的に機器サブセットが設定されれば機器１００の操作性を向上できる。例えば、通信負荷の高いアプリを高速化したいユーザだけ、バッファ領域の割り当てを変更することができる。

図１７は、メインシステム５０とサブシステム２０の機能ブロック図の一例である。本実施例のメインシステム５０は、アカウント管理部５８とアカウントテーブル５７を有する。アカウントテーブル５７には、アカウント（ユーザ）に応じて機器サブセットが登録されている。

図１８はアカウントテーブル５７の一例を示す図である。アカウント（ユーザ）に応じて機器サブセットが登録されている。

機器１００は、ログイン時のユーザ名からアカウントを特定するので、アカウント管理部５８はユーザ名をアカウントとして、アカウントテーブル５７から機器サブセットを特定する。アカウント管理部５８は、機器サブセットを機器モード記録領域５３に記憶する。テーブル切替部５６は、記憶された機器サブセットに応じて機器モードテーブル５１を切り替える。

本実施例によれば、実施例１〜４の効果に加え、ログインしたユーザに応じて機器サブセットを自動的に選択でき、ユーザが操作しなくても、通信負荷の高いアプリを高速化したいユーザだけ、バッファ領域の割り当てを変更することができる。

本実施例では、近距離無線通信部を有する機器１００について説明する。
図１９は、メインシステム５０とサブシステム２０の機器構成を示す図の一例である。本実施例のメインシステム５０は、近距離無線通信部５９と、アプリ４（近距離通信アプリ６０）を有する。近距離無線通信部５９はＮＦＣ（登録商標：Near Field Communication）、Bluetooth（登録商標）、無線ＬＡＮ、ＺｉｇＢｅｅ（登録商標）など、比較的、近距離（数十メートル）で通信可能な通信装置である。近距離という言葉は携帯電話網などの長距離無線通信に対比して用いられることが多い。

また、近距離通信アプリ６０は近距離無線通信部５９に対応したアプリで、近距離無線通信部５９が通信する場合に通信処理を行う。また、本実施例の近距離通信アプリ６０は、近距離無線通信部５９が通信することに適した機器サブセットに変更し、機器モード記録領域に設定する。テーブル切替部５６はこの現在の機器サブセットに応じて機器モードテーブル５１を切り替える。

近距離無線通信部５９は、近距離無線通信可能な端末を接近させるだけで通信を始めることができるので、ユーザが端末（例えば、ＮＦＣが搭載されたドングル）を機器１００に近づけたり、機器１００を端末に近づけるだけで、近距離通信アプリ６０が機器サブセットを変更できる。

したがって、ユーザは簡単な操作で、機器１００に最適な機器サブセットを設定して、機器モードに応じたバッファ領域の割り当てが可能になる。

図２０は、サブシステム２０がバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。

機器１００が近距離無線通信を開始する（Ｓ１０１）。

これにより、近距離通信アプリ６０が機器サブセットを変更する（Ｓ１０２）。

テーブル切替部５６は変更後の機器サブセットに応じて機器モードテーブル５１を切り替える（Ｓ１０４）。

メインシステム５０が機器モードを決定する（Ｓ１１０）。

必要に応じてサブバッファセットが変更される（Ｓ１１２）。

メインシステムは、サブシステム２０に変更後のサブシステムモードとサブバッファセットを通知する（Ｓ１２２）。以降の処理は実施例４と同様になる。

なお、本実施例では、近距離通信アプリ６０が機器サブセットを変更したが、サブバッファセットを変更してもよい。

図２０（ｂ）は、サブバッファセットが変更される場合のメインシステムの動作手順を示すフローチャート図の一例である。図２０（ａ）では、ステップＳ１０２−２で、近距離通信アプリ６０がサブバッファセットを決定している（Ｓ１０２−２）。

ユーザなどが機器モード記録領域５３の機器サブセットを変更する（Ｓ１０２）。

テーブル切替部５６は変更後の機器サブセットに応じて機器モードテーブル５１を切り替える（Ｓ１０４）。

メインシステムは機器モードを決定する（Ｓ１１０）。

メインシステムは、サブシステム２０に変更後のサブシステムモードとサブバッファセットを通知する（Ｓ１２２）。

これにより、サブシステム２０のサブシステムモード記録領域２２にはサブバッファセットが記憶されるので、割り当てテーブル切替部２７は割り当てテーブル２１を切り替えることができる。

本実施例によれば、機器１００が近距離無線通信部５９を有することで、ユーザは簡単な操作で、機器サブセットやサブバッファセットを切り替え、バッファ領域の割り当てを行うことができる。

本実施例では現在の通信状態を視覚的に通知するモード表示部を備えた機器１００について説明する。

図２１は、メインシステム５０とサブシステム２０の機器構成を示す図の一例である。本実施例において、図５において同一の符号を付した構成要素は同様の機能を果たすので、主に本実施例の主要な構成要素についてのみ説明する場合がある。本実施例のメインシステム５０は、モード表示部４５を有する。モード表示部４５は、例えばＬＥＤ発光素子、有機ＥＬ発光素子、ランプなど光源を備え、点灯又は点滅することができる。モード表示部４５は、点灯状態でサブシステムモードを通知する。例えば、点灯していれば「サブシステムモード＝単一アプリ占有割り当て」であり、消灯していれば「サブシステムモード＝定常設定割り当て」であることが分かる。

図２２は、メインシステム５０とサブシステム２０の機能ブロック図の一例である。なお、本実施例の機器１００は、実施例２〜６で説明した機能を含みうるが、説明を容易にするため実施例１の機器構成に対する差異を説明する。本実施例のメインシステム５０は、モード表示制御アプリ６１を有する。モード表示制御アプリ６１は、モード表示部４５の点灯状態を制御するアプリである。

具体的には、モード表示制御アプリ６１は、サブシステムモードが定常設定割り当ての場合はモード表示部４５を消灯（ＯＦＦ）し、機器モードが単一アプリ占有割り当ての場合はモード表示部４５を点灯（ＯＮ）する。このため、本実施例の機器モードテーブル５１には、サブシステムモードに対応づけてモード表示部４５の点灯状態が設定されている。

図２３は、機器モードテーブル５１の一例を示す図である。各サブシステムモードに点灯状態（ＯＮ／ＯＦＦ）が設定されている。なお、ＯＮとＯＦＦ以外にも点滅や点滅周期を設定してもよい。また、カラー表示が可能なモード表示では、発光色が設定されていてもよい。

図２４は、サブシステム２０がバッファ領域の割り当てを変更する手順を示すフローチャート図の一例である。

メインシステム５０が機器モードを決定する（Ｓ１１０）。

機器モード設定部５２は機器モードテーブル５１を参照してサブシステムモードを決定し、サブシステムに通知する（Ｓ１２０）。

サブシステム側の処理は実施例１と同様になる。
サブシステムの送受信部２６はサブシステムモードを受信する（Ｓ２１０）。

サブシステムモード設定部２３はサブシステムモードが変更されたか否かを判定する（Ｓ２２０）。

サブシステムモードが変更された場合（Ｓ２２０のＹｅｓ）、バッファ領域割り当て部２４はバッファ領域の割り当てを変更する（Ｓ２３０）。通信部２５は通信を開始する（Ｓ２４０）。

そして、メインシステム５０のモード表示制御アプリ６１はサブシステムモードに対応づけられた機器モードテーブル５１の点灯状態を読み出し、モード表示部４５を点灯する（Ｓ１３０）。

本実施例のネットワークシステム５００は、バッファ領域の割り当て状態をリアルタイムにユーザが確認できる。例えば、高速に通信しているか否かを容易に把握できる。

本実施例では、実施例７の機器において、ユーザが表示パターンを選択可能な機器１００について説明する。

実施例７ではサブシステムモードに点灯状態が固定的に対応づけられていた。例えば、サブシステムモードが定常設定割り当ての場合はＯＦＦ（消灯）、サブシステムモードが単一アプリ占有割り当ての場合はＯＮ（点灯）のように決まってしまっている。

しかし、ユーザによっては、サブシステムモードが定常設定割り当ての場合に点灯させたい場合もある。そこで、本実施例ではユーザによりサブシステムモードの点灯状態の設定を受け付ける機器１００について説明する。

図２５は、メインシステム５０とサブシステム２０の機能ブロック図の一例である。本実施例のメインシステム５０は、図２２のメインシステム５０に対しモード表示設定アプリ６２及び表示パターンテーブル６３を有する。

モード表示設定アプリ６２は、「点灯状態＝ＯＮ」が消灯なのか点灯なのか、「点灯状態＝ＯＦＦ」が消灯なのか点灯なのか、の設定を受け付け、表示パターンテーブル６３に設定する。例えば、ＬＣＤに所定のメニューを表示させこれらの選択を受け付けてもよいし、所定のボタンの長押しで設定が交互に切り替わるようしてもよい。

図２６（ａ）（ｂ）は表示パターンテーブル６３の一例を示す図である。図２６（ａ）は初期設定の表示パターンテーブル６３であり、実施例７と同様に点灯状態「ＯＦＦ」に「消灯」が、点灯状態「ＯＮ」に「点灯」が、対応づけて設定されている。この表示パターンを切り替えたいユーザは、不図示のボタンや液晶に表示されたメニューにしたがって機器１００を操作する。これにより、モード表示設定アプリ６２は図２６（ｂ）の表示パターンテーブル６３を作成する。図２６（ｂ）では点灯状態「ＯＦＦ」に「点灯」が、点灯状態「ＯＮ」に「消灯」が、対応づけて設定されているので、モード表示部４５は、サブシステムモードが定常設定割り当ての場合は点灯し、機器モードが単一アプリ占有割り当ての場合は消灯する。

本実施例の機器１００によれば、ユーザはサブシステムモードに応じて所望の表示パターンを設定できる。

本実施例では、データ通信用の発光素子を実施例７、８のモード表示部４５として使用する機器１００について説明する。

例えば、外部通信装置１３がイーサネット（登録商標）カードの場合、固定された一対のＬＥＤを有している。１つはＬＡＮアクティブＬＥＤと呼ばれデータを送受信している場合に橙色に点灯する。もう１つはリンクＬＥＤと呼ばれ、ネットワーク３００に正常に接続している場合（通信可能な場合）に緑色に点灯する。

本実施例では、点灯状態がＯＮ（又はＯＦＦでもよい）の場合に、ＬＥＤの少なくとも一方を特殊パターン（例えば、０．５秒間隔）で点滅する。これにより、新たにモード表示部４５を付加することなく、既存のＬＥＤを使用して機器モードを表示することができる。

図２７は、メインシステム５０とサブシステム２０の機器構成を示す図の一例である。図２１と比較するとモード表示部４５がなく、外部通信装置１３がＬＥＤ１５を有している。

図２８（ａ）は、メインシステム５０とサブシステム２０の機能ブロック図を示す図の一例である。メインシステム５０がモード表示制御アプリ６１を有さず、サブシステム２０がサブ表示制御アプリ２８と点灯制御テーブル２９を有している。図２８（ｂ）に示すように、点灯制御テーブル２９にはサブシステムモードに点灯制御内容が設定されている。

サブ表示制御アプリ２８は、サブシステムモードに応じて点灯制御テーブル２９を参照し、ＬＥＤ１５を点灯制御する。例えば、サブシステムモードが単一アプリ占有割り当ての場合に、リンクＬＥＤを周期的にＯＮ／ＯＦＦする。これにより、サブシステムモードに応じてリンクＬＥＤを点滅させることができる。

したがって、本実施例によれば、コスト増を抑制して、サブシステムモード（バッファ領域の割り当て状態）をリアルタイムにユーザが確認できる。

２０ サブシステム
２１ 割り当てテーブル
２２ サブシステムモード記録領域
２５ 通信部
２７ 割り当てテーブル切替部
５０ メインシステム
５１ 機器モードテーブル
５３ 機器モード記録領域
５５ アプリ
５６ テーブル切替部
１００ 機器
２００ 通信相手装置

特許第３７６１３１７号公報

Claims (8)

1. 外部との通信手段を備えた第１の情報処理ユニットと、前記第１の情報処理ユニットとデータ通信線を介して接続された第２の情報処理ユニットと、を有する情報処理装置であって、
   前記第２の情報処理ユニットは、
   複数の情報処理手段と、
   前記第２の情報処理ユニットの動作モードに前記第１の情報処理ユニットの動作モードを紐づけた複数の第２のテーブルと、
   前記第２のテーブルの第２の選択ポリシーが記憶された第２の選択ポリシー記憶手段と、
   前記第２の選択ポリシー記憶手段に記憶された前記第２の選択ポリシーに基づき前記第２のテーブルを選択する第２のテーブル選択手段と、
   前記第２のテーブル選択手段が選択した前記第２のテーブルから、前記第２の情報処理ユニットの動作モードに紐づけられた前記第１の情報処理ユニットの動作モードを読み出し前記第１の情報処理ユニットに送信する動作モード送信手段と、を有し、
   前記第１の情報処理ユニットは、
   前記通信手段が外部から受信したデータを記憶させるデータ記憶手段と、
   前記第２の情報処理ユニットの動作モードにより定まる前記第１の情報処理ユニットの動作モードごとに、各情報処理手段が使用するデータのために確保される領域サイズが紐づけられた第１のテーブルと、
   前記データ記憶手段の容量のうち、前記第１のテーブルにて現在の前記第１の情報処理ユニットの動作モードに紐づけられた前記領域サイズの領域を、前記情報処理手段に割り当てる領域割り当て手段と、を有し、
   前記第１の情報処理ユニットの前記領域割り当て手段は、前記第１のテーブルにおいて、前記第２の情報処理ユニットから受信した前記第１の情報処理ユニットの動作モードに紐づけられた前記領域サイズの領域を、前記情報処理手段に割り当てる、ことを特徴とする情報処理装置。
2. 前記第１の情報処理ユニットは、
   複数の前記第１のテーブルと、
   前記第１のテーブルの第１の選択ポリシーが記憶された第１の選択ポリシー記憶手段と、
   前記第１の選択ポリシー記憶手段に記憶された前記第１の選択ポリシーに基づき前記第１のテーブルを選択する第１のテーブル選択手段と、を有し、
   前記領域割り当て手段は、前記第１のテーブル選択手段が選択した前記第１のテーブルにおいて、前記第２の情報処理ユニットから受信した前記第１の情報処理ユニットの動作モードに紐づけられた前記領域サイズの領域を、前記情報処理手段に割り当てる、
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記第２の情報処理ユニットは、
   アカウント情報に前記第２の選択ポリシーが紐づけられたアカウント情報記憶手段と、
   当該情報処理装置にログインしたユーザのアカウント情報に対応づけられている前記第２の選択ポリシーを前記アカウント情報記憶手段から読み出し、前記第２の選択ポリシー記憶手段に設定する第２の選択ポリシー設定手段を有し、
   前記第２のテーブル選択手段は、前記第２の選択ポリシー記憶手段に記憶された前記第２の選択ポリシーに基づき前記第２のテーブルを選択する、
   ことを特徴とする請求項１又は２に記載の情報処理装置。
4. 外部と無線通信する無線通信手段を有し、
   前記第２の情報処理ユニットは、前記無線通信手段を制御する無線通信制御手段を有し、
   前記無線通信制御手段は、前記無線通信手段が外部と通信する際、予め定められた前記第２の選択ポリシーを前記第２の選択ポリシー記憶手段に設定し、
   前記第２のテーブル選択手段は、前記第２の選択ポリシー記憶手段に記憶された前記第２の選択ポリシーに基づき前記第２のテーブルを選択する、
   ことを特徴とする請求項１又は２に記載の情報処理装置。
5. 外部から目視可能な表示装置を有し、
   前記第２の情報処理ユニットの前記第２のテーブルには、前記第１の情報処理ユニットの動作モードに前記表示装置の点灯指示情報が紐づけられており、
   前記第２の情報処理ユニットは、
   前記第２の情報処理ユニットの動作モードに応じて前記第２のテーブルから読み出した前記点灯指示情報にしたがって前記表示装置を制御する表示装置制御手段、
   を有することを特徴とする請求項１〜４のいずれか１項に記載の情報処理装置。
6. 前記第２の情報処理ユニットは、
   前記点灯指示情報に点灯状態が紐づけられた点灯状態テーブルと、
   前記点灯指示情報に紐づける前記点灯状態の設定を受け付ける点灯状態設定受付手段と、を有することを特徴とする請求項５に記載の情報処理装置。
7. 前記表示装置は前記通信手段に固定されている発光素子であり、
   前記第１の情報処理ユニットは、
   前記第１の情報処理ユニットの動作モードに点灯状態が紐づけられた第２の点灯状態テーブルと、
   前記第１の情報処理ユニットの動作モードに応じて前記第２の点灯状態テーブルから読み出した前記点灯状態にしたがって前記発光素子を制御する表示装置制御手段と、
   を有することを特徴とする請求項５に記載の情報処理装置。
8. 前記第１のテーブルには、
   前記第１の情報処理ユニットの動作モードに、前記データ通信線を介して前記第１の情報処理ユニットと前記第２の情報処理ユニットが通信する際に前記情報処理手段ごとに確保される前記領域サイズが紐づけられており、
   前記領域割り当て手段は、前記データ記憶手段の容量のうち、前記第１のテーブルにて現在の前記第１の情報処理ユニットの動作モードに紐づけられた前記領域サイズの領域を、前記第１の情報処理ユニットが前記第２の情報処理ユニットに送信するデータの記憶領域として前記情報処理手段に割り当てる、
   ことを特徴とする請求項１〜７のいずれか１項に記載の情報処理装置。
   

Images