(58)【調査した分野】(Int.Cl.,DB名)
前記処理結果記憶手段に記憶された複数の処理結果ファイルを、あらかじめ定めた条件に従って、1つの処理結果ファイルに集約する集約手段をさらに備えることを特徴とする請求項1または請求項2に記載の情報処理装置。
前記処理結果記憶手段に記憶された処理結果ファイルのファイル名に基づいて、前記処理手段が行った処理の結果を外部へ出力する出力手段をさらに備えることを特徴とする請求項1から3のいずれか一項に記載の情報処理装置。
【発明の概要】
【発明が解決しようとする課題】
【0004】
近年、クラウドサーバを利用して、複数の通信端末において同一のメールアカウントを有し、それぞれの端末において同じ電子メールの送受信を行うシステムが考えられている。このシステムにおいては、クラウドサーバ上に電子メールデータ(ヘッダ情報や書誌事項のほか、メール本文や添付ファイルを含む)が保存されており、通信端末は、基本的には各電子メールのヘッダ情報(各種ステータス等)および書誌情報(件名、宛先など)のみを保持している。そして、ユーザが個々の電子メールデータを閲覧する際に、通信端末はクラウドサーバからメール本文および添付ファイルを取得することで、メール本文や添付ファイルを表示することができる。
【0005】
しかしながら、操作履歴等をストレージに逐一、ファイルにして記憶すると、そのキューの数(操作履歴等の数)だけ、ファイルが生じてしまい、ストレージのメモリブロックを大量に消費してしまう、という問題がある。また、キューの内容をファイルデータに保持させると、そのファイルを開く必要が有り、タイムロスが生じる。
【0006】
そこで、本発明においては、メッセージキューイングを利用するに際して、キューの読み出しを迅速に行うことができる情報処理装置およびキュー記憶方法を提供することを目的とする。
【課題を解決するための手段】
【0007】
上述の課題を解決するために本発明の情報処理装置は、入力を受け付ける入力手段と、前記入力手段が受け付けた入力に応じた処理を行う処理手段と、前記処理手段が行った処理の結果に基づき、当該処理の内容
に応じた入力情報を示す文字列を生成する文字列生成手段と、前記文字列生成手段により生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成手段と、前記ファイル生成手段により生成された処理結果ファイルを記憶する処理結果記憶手段と、を備える。
【0008】
また、本発明のキュー記憶方法は、入力を受け付ける入力ステップと、前記入力ステップが受け付けた入力に応じた処理を行う処理ステップと、前記処理ステップが行った処理の結果に基づき、当該処理の内容
に応じた入力情報を示す文字列を生成する文字列生成ステップと、前記文字列生成ステップにより生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成ステップと、前記ファイル生成ステップにより生成された処理結果ファイルを処理結果記憶手段に記憶する記憶ステップと、を備える。
また、本発明の情報処理システムは、第1の情報処理装置及び第2の情報処理装置を含む情報処理システムであって、前記第1の情報処理装置は、入力を受け付ける入力手段と、前記入力手段が受け付けた入力に応じた処理を行う処理手段と、前記処理手段が行った処理の結果に基づき、当該処理の内容
に応じた入力情報を示す文字列を生成する文字列生成手段と、前記文字列生成手段により生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成手段と、前記ファイル生成手段により生成された処理結果ファイルを記憶する処理結果記憶手段と、前記処理結果ファイルのファイル名に基づいて、前記処理手段が行った処理の結果を前記第2の情報処理装置に送信する送信手段と、を備え、前記第2の情報処理装置は、前記送信手段により送信された処理の結果に応じた処理を実行する処理手段とを備える。
【0009】
本発明によれば、受け付けられた処理の結果に基づ
き、処理の内容に応じた入力情報を示す文字列を生成し、生成された文字列をファイル名とした処理結果ファイルを生成する。そして、生成された処理結果ファイルを記憶する。これにより、操作履歴や処理
内容等を記憶するに際して、メモリ消費量を少なくするとともに、その読み出し処理を迅速に行うことができる。その際、ファイル生成手段は、実体データを有さない処理結果ファイルを生成する。
【0010】
また、本発明の情報処理装置は、前記処理結果記憶手段に記憶された複数の処理結果ファイルを、あらかじめ定めた条件に従って、1つの処理結果ファイルに集約する集約手段をさらに備える。
【0011】
この発明によれば、あらかじめ定めた条件に従って、複数の処理結果ファイルを1つの処理結果ファイルに集約することで、メモリ消費量および読み出し処理を効率的に行うことができる。さらに、サーバ等に処理結果等を通知する際において、複数の状態を通知する必要がなく、効率的な処理を実現できる。
【0012】
また、本発明の情報処理装置は、前記処理結果記憶手段に記憶された処理結果ファイルのファイル名に基づいて、前記処理手段が行った処理の結果を外部へ出力する出力手段をさらに備える。
【0013】
この発明によれば、処理結果ファイルのファイル名に基づいた処理を外部に出力することで、外部端末は処理結果を把握することができる。
【0014】
また、本発明の情報処理装置において、前記処理結果記憶手段は、処理結果ファイルの数をファイル名に含む管理ファイルをさらに記憶し、前記ファイル生成手段が処理結果ファイルを生成するごとに、前記管理ファイルのファイル名に含まれるファイル数の情報をインクリメントするとともに、当該ファイル数の情報が所定数に達すると前記出力手段に前記処理手段が行った処理の結果を外部へ出力させるファイル数管理手段を備える。
【0015】
この発明によれば、処理結果ファイルの数をファイル名に含めた管理ファイルを作成しておき、そのファイル名に基づいてファイル数を判断することができ、ファイル数管理を迅速かつ簡易にすることができる。
【発明の効果】
【0016】
本発明によれば、操作履歴や処理
内容等を記憶するに際して、メモリ消費量を少なくするとともに、その読み出し処理を迅速に行うことができる。
【発明を実施するための形態】
【0018】
添付図面を参照しながら本発明の実施形態を説明する。可能な場合には、同一の部分には同一の符号を付して、重複する説明を省略する。
【0019】
[第1の実施形態]
図1は、本実施形態の情報処理装置100を利用した通信システムを示すシステム構成図である。
図1に示す通り、情報処理装置100は、ネットワークを介してサーバ200と通信接続することができる。本実施形態においては、情報処理装置100は、当該装置に対して受け付けられた操作履歴情報や、当該装置にインストールされているアプリケーションに対して受け付けられた操作履歴情報およびそのアプリケーションの処理結果情報をメッセージキューとして生成して、記憶することができる。そして、情報処理装置100は、生成されたメッセージキューに基づいて、操作履歴情報や処理結果情報を所定のタイミングでサーバ200に送信し、サーバ200は、受信した操作履歴情報や処理結果情報を記憶する。
【0020】
ここで情報処理装置100は、メッセージキューとして、操作履歴情報および処理結果情報を示す文字列を生成し、その文字列をファイル名としたメッセージキューファイルを生成する。そして、情報処理装置100は、所定のタイミングで、この生成したメッセージキューファイルのファイル名から操作履歴情報や処理結果情報を抽出して、サーバ200に出力し、また同期処理を行うことができる。
【0021】
図2は、本実施形態の情報処理装置100の機能構成を示すブロック図である。
図2に示されるように、情報処理装置100は、通信部101(出力手段)、ユーザインタフェース102(入力手段)、データ処理部103(処理手段)、メッセージキュー管理部104(文字列生成手段、ファイル生成手段)、メッセージキュー記憶部105(処理結果記憶手段)、データ管理部106、ライブラリ情報記憶部107およびデータ記憶部108を含んで構成されている。
【0022】
図3は、情報処理装置100のハードウェア構成図である。
図1に示される情報処理装置100は、物理的には、
図3に示すように、CPU11、主記憶装置であるRAM12及びROM13、入力デバイスであるキーボード及びマウス等の入力装置14、ディスプレイ等の出力装置15、ネットワークカード等のデータ送受信デバイスである通信モジュール16、半導体メモリ等の補助記憶装置17などを含むコンピュータシステムとして構成されている。
図2における各機能は、
図3に示すCPU11、RAM12等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、CPU11の制御のもとで入力装置14、出力装置15、通信モジュール16を動作させるとともに、RAM12や補助記憶装置17におけるデータの読み出し及び書き込みを行うことで実現される。以下、
図2に示す機能ブロックに基づいて、各機能ブロックを説明する。
【0023】
通信部101は、サーバ200と通信接続する部分であり、メッセージキューファイルに記述されている処理結果をサーバ200に通知することができる。
【0024】
ユーザインタフェース102は、ユーザによる操作を受け付け、またはユーザに提供される情報を表示する部分であり、例えば、キーボード、ディスプレイや、タッチパネルディスプレイである。情報処理装置100が携帯電話であった場合には、当該ユーザインタフェース102は、各種アイコンや、メッセージなどを表示し、またユーザからアイコンなどに対する操作を受け付けることができる。
【0025】
データ処理部103は、ユーザインタフェース102により受け付けられた操作に基づいた処理を実行する部分である。例えば、所定のアプリケーションが起動されているのであれば、そのアプリケーションに従った操作を受け付けて実行するものである。アプリケーションが、ゲームであれば、ゲームに対する操作であったり、ブラウザであれば、閲覧のための操作である。本実施形態においては、アプリケーションや、その具体的な操作については何ら限定するものではない。
【0026】
メッセージキュー管理部104は、データ処理部103において処理された結果に基づいた文字列を生成し、その文字列をファイル名としたメッセージキューファイルを生成する部分である。そして、生成したメッセージキューファイルをメッセージキュー記憶部105に記憶する。
【0027】
ここで、
図4を用いて、生成する文字列およびその文字列からなるファイル名の記述について説明する。
図4は、ディレクトリエントリと、iノードデータ構造とからなるファイル構造を示す説明図である。この説明図は、一般的に、UNIX(登録商標)などにおけるファイル構造を示したものである。
【0028】
図4(a)に示される通り、ディレクトリエントリは、iノード番号とファイル名とからなるデータ構造をとる。また、iノードデータ構造は、ファイル区分(ディレクトリか、ファイルの区分)、iノード番号、ユーザID、およびファイルサイズ等を含んだものである。メッセージキュー管理部104は、そのディレクトリエントリにおけるファイル名の領域に、処理結果を示す文字列を記述することができる。なお、iノードデータ構造には、実体データを含めないことでデータサイズを極力小さくすることができる。
【0029】
図4(a)を用いてさらに、ファイル名の構造について説明する。上述した通り、ファイル名は、少なくとも、CUE番号および操作履歴情報や処理結果情報を示す文字列からなる。CUE番号は、入力の時系列的な順番を示すIDであり、操作履歴情報や処理結果情報は、どのキーが押下(またはタッチ)されたかを示す情報である。なお、この情報に限るものではなく、例えば
図4(b)に示されるように、UUID、CUE番号、タイプ、および処理結果内容を示す文字列を生成するようにしてもよい。なお、ここでUUID(Universally Unique Identifier)は、標準化された一意に識別するための識別子であり、タイプは、アプリケーションなどの操作対象を示し、処理結果内容は、操作に対するアプリケーションにより処理された結果を示す情報である。また、
図4(c)に示される文字列としてもよい。
図4(c)においては、UUID、CUE番号、タイプ、処理結果前ステータス、および処理結果後ステータスを示す文字列を生成することが示されている。
【0030】
さらに、メッセージキュー管理部104は、生成したメッセージキューファイルが所定数に達すると、通信部101を介して、メッセージキューファイルそれ自身をサーバ200に送信するか、またはメッセージキューファイルのファイル名に記述されている文字列に基づいた操作履歴情報や処理結果情報等を抽出してサーバ200に送信する。
【0031】
メッセージキュー管理部104は、サーバ200から正常終了の旨を、通信部101を介して受信すると、当該正常終了したメッセージキューファイルをメッセージキュー記憶部105から削除する。また、サーバ200からエラーの旨を受信すると、その対応するメッセージキューファイルに基づいて、ライブラリ情報記憶部107に記憶されているアプリケーションなどの処理結果情報などを元に戻す処理を行う。
【0032】
メッセージキュー記憶部105は、メッセージキュー管理部104により生成された複数のメッセージキューファイルを記憶する部分である。
【0033】
データ管理部106は、ユーザ操作に応じてアプリケーションのライブラリ情報のステータスを変更する部分である。本実施形態では、ライブラリ情報とは、アプリケーションの処理結果情報などのステータス情報を含んだものであるが、これに限定するものではなく、アプリケーションのほか、情報処理装置100の処理結果情報であってもよい。
【0034】
ライブラリ情報記憶部107は、アプリケーションの処理結果情報や、ステータス情報などのメタデータを記憶する部分である。また、データ記憶部108は、アプリケーションなどのデータを含む各種データを記憶する部分である。
【0035】
つぎに、この情報処理装置100と通信接続するサーバ200について説明する。
図5は、サーバ200の機能構成を示すブロック図である。
図5に示されるように、サーバ200は、通信部201、メッセージキュー処理部202、データ管理部203、ライブラリ情報記憶部204およびデータ記憶部205を含んで構成されている。このサーバ200も、情報処理装置100と同様にCPU、RAM、ROM等を備えたコンピュータシステムから構成されている。以下、各機能について説明する。
【0036】
通信部201は、情報処理装置100と通信する部分であり、本実施形態においては、メッセージキューファイルまたはメッセージキューファイルに基づいた処理結果内容を情報処理装置100から受信する部分である。
【0037】
メッセージキュー処理部202は、情報処理装置100から受信したメッセージキューファイルまたは受信された処理結果内容に基づいた処理をデータ管理部203に指示する部分である。
【0038】
データ管理部203は、メッセージキュー処理部202からの指示に応じてライブラリ情報記憶部204に記憶されているライブラリ情報を更新する部分である。そして、更新の成功または失敗をメッセージキュー処理部202に通知する。メッセージキュー処理部202においては、その成否の情報を、通信部201を介して情報処理装置100に通知する。情報処理装置100では、その結果に基づいた処理(リトライまたは強制同期処理)を行う。
【0039】
ライブラリ情報記憶部204は、情報処理装置100における操作履歴情報や、アプリケーションの処理結果情報などのライブラリ情報を記憶する部分である。また、データ記憶部205は、各種データを記憶する部分である。
【0040】
このように構成された情報処理装置100において、その処理動作について説明する。
図6は、情報処理装置100の処理を示すフローチャートである。まず、情報処理装置100において、ユーザインタフェース102を介したユーザ操作によりアプリケーションが起動される(S101)。そして、アプリケーションに対するユーザ入力操作がユーザインタフェース102により受け付けられ(S102)、データ処理部103において、その入力操作に対する処理を行うとともに、データ管理部106において、その入力操作に対するライブラリ情報が更新される(S103)。なお、単なる入力操作履歴を保持するだけである場合には、ライブラリ情報の更新処理はされなくてもよい。
【0041】
そして、メッセージキュー管理部104において入力操作による処理結果に基づいた文字列が生成され、当該文字列をファイル名としたメッセージキューを示すメッセージキューファイルが生成される。生成されたメッセージキューファイルは、メッセージキュー記憶部105に記憶される(S104)。
【0042】
ここで、情報処理装置100において、所定条件を満たしたか否かが、メッセージキュー管理部104において判断される(S105)。ここでは、例えば、メッセージキューファイルが所定数を超えたか否か、明示的な操作が行われたな否か、ユーザ操作などによりサーバ200に接続されたか否か、サーバ200に対して前回接続してから一定時間経過したか否か、が判断される。ここで、所定条件を満たしたと判断されると、最もCUE番号の若いメッセージキューファイルのファイル名に応じた処理を通信部101からサーバ200に対して要求を行う(S106)。
【0043】
ここで、サーバ200において、要求に対する処理が成功したか否かが判断され(S107)、成功したと判断された場合には、メッセージキュー管理部104は、サーバ200に反映された処理を示すメッセージキューファイルを削除する(S108)。そして、メッセージキューファイルが残っているか否かが判断され(S110)、残っている場合には、S106に戻り、次のメッセージキューファイルに対する処理が行われる(S106)。
【0044】
また、サーバ200が処理に成功しなかった場合には、メッセージキュー管理部104によりエラー処理が行われる(S109)。ここでのエラー処理は、例えば、リトライ処理や、強制同期処理(情報処理装置100におけるライブラリ情報を元に戻すなど)である。そして、これら処理が繰り返し行われる。
【0045】
このようにして、本実施形態においては、情報処理装置100において生成したメッセージキューファイルのファイル名に、操作履歴情報やアプリケーションの処理結果情報などの各種ステータス情報を記述することで、その読み出し等の処理を迅速に行うことができる。なお、本実施形態においては、その利用方法や、使用状況を特に限定するものではなく、汎用的な情報処理装置100において、ユーザにより入力された操作履歴や装置やアプリケーションに対する処理結果情報などのステータス情報をメッセージキューファイルのファイル名に記述するとしたものであり、その応用範囲は多岐に渡るものである。例えば、本実施形態における情報処理装置100は、メディアプレイヤー、電子書籍リーダ、非同期通信を行うネットワークゲームなどに応用することができる。
【0046】
[第2の実施形態]
つぎに、第2の実施形態について説明する。第1の実施形態は、汎用的な情報処理装置100において、操作履歴や処理結果などのステータス情報をメッセージキューファイルのファイル名に記述することを特徴としたものである。本実施形態においては、情報処理装置100を、楽曲データを再生したり、ダウンロードするメディアプレイヤーに応用した情報処理装置100xを説明する。
【0047】
図7は、本実施形態の情報処理装置100xを利用した通信システムを示すシステム構成図である。この通信システムは、スマートフォン等の情報処理装置100xとメディアサーバ200xとを含んでいる音楽配信システムである。ここで、情報処理装置100xは、メディアプレイヤアプリケーションを備えており、ユーザは、この情報処理装置100xを操作することにより、メディアサーバ200xから楽曲データをダウンロードし、情報処理装置100xにおいて保持し、またその楽曲データを再生することができる。また、メディアサーバ200xは、インターネット上に構築されているものであり、情報処理装置100xからの要求に応じて楽曲データの配信処理や、情報処理装置100xにおける楽曲データのステータスの管理を行う。
【0048】
なお、この情報処理装置100xは、メッセージキューイングシステムを備えており、情報処理装置100xにおいてユーザにより操作された操作履歴や、当該操作により処理された処理結果を示す文字列を生成し、生成した文字列をファイル名としたメッセージキューファイルを生成し、キューとして記憶する。
【0049】
図8は、本実施形態の情報処理装置100xの機能構成を示すブロック図である。
図8に示されるように、情報処理装置100xは、通信部101x(出力手段)、ユーザインタフェース102x(入力手段)、再生部103x(処理手段)、メッセージキュー生成部104x(文字列生成手段、ファイル生成手段)、メッセージキュー管理部104y(集約手段、ファイル数管理手段)、メッセージキュー記憶部105x(処理結果記憶手段)、データ管理部106x、ライブラリ情報記憶部107xおよび楽曲データ記憶部108xを含んで構成されている。この情報処理装置100xは、第1の実施形態における情報処理装置100と同様のハードウェア構成をとるものである。
【0050】
通信部101xは、メディアサーバ200xと通信を行う部分であり、メディアサーバ200xから楽曲データをダウンロードし、またメッセージキューファイルのファイル名に記述されているメッセージキューをメディアサーバ200xに送信し、または同期処理する部分である。
【0051】
ユーザインタフェース102xは、ユーザからの操作を受け付ける部分であり、例えば、楽曲データのダウンロード指示や、楽曲データの再生指示などの操作を受け付けることができる。
【0052】
再生部103xは、ユーザからの指示に応じて、楽曲データ記憶部108xに記憶されている楽曲データの再生処理を行う部分である。
【0053】
メッセージキュー生成部104xは、データ管理部106xにより実行された処理結果に基づいた文字列を生成し、当該文字列をファイル名とするメッセージキューファイルを生成する部分である。生成したメッセージキューファイルは、メッセージキュー記憶部105xに記憶される。
【0054】
図9に、メッセージキューファイルのファイル名の具体例を示す。第1の実施形態と異なり、本実施形態においては、楽曲データのステータスを変更するものであることから、楽曲データ特有の項目がそのファイル名(文字列)に必要となる。
図9(a)は、楽曲データの管理情報を変更する場合における文字列を示している。すなわち、メッセージキューとして、メッセージキューID、楽曲データID、処理内容として“status”、変更前ステータス、および変更後ステータスとから構成されている。ここで変更前ステータス、変更後ステータスは、楽曲のジャンル、再生回数、およびレーティングが挙げられるが、これに限るものではなく、楽曲に関するステータスであればよい。
【0055】
また、
図9(b)においては、リネーム(名称変更)の場合のメッセージキューを示している。ここでは、メッセージキューとして、メッセージキューID、楽曲データID、処理内容として“rename”、変更前ステータス、および変更後ステータスとから構成されている。ここで変更前ステータス、変更後ステータスは、曲名、アーティスト名、およびアルバム名が挙げられる。そのほか、名称変更の対象となる項目であればこれらに限るものではない。
【0056】
図9(a)および(b)に示されるように、変更前と変更後とにおける各ステータス(管理情報または名前)が文字列として生成され、これがメッセージキューファイルのファイル名として記述される。
【0057】
メッセージキュー管理部104yは、生成したメッセージキューファイルをメッセージキュー記憶部105xに記憶する。
【0058】
さらに、メッセージキュー管理部104yは、メッセージキュー管理ファイルを生成する。このメッセージキュー管理ファイルは、管理ファイルを示す識別子である識別ラベルと、メッセージキューファイルのファイル数を示す数値情報とからなるファイル名が付与されており、メッセージキューファイルが生成される毎に、この管理ファイルにおけるファイル名におけるファイル数を示す数値情報が更新される。
【0059】
図10は、管理ファイルのファイル名の構成を示す説明図である。
図10に示される通り、管理ファイルのファイル名は、管理ファイルであることを示す識別ラベルと、ファイル数とから構成されている。この管理ファイルも、メッセージキューファイルと同様に、iノードの構成におけるディレクトリエントリのファイル名領域に記述される(
図4参照)。
【0060】
メッセージキュー管理部104yは、この管理ファイルのファイル名に記述されているファイル数が所定数に達すると、通信部101xを介してメディアサーバ200xに対してメッセージキューファイルのファイル名として記述されている処理をメディアサーバ200xに対して要求する。メディアサーバ200xにおいては、当該要求に基づいた処理に成功すると、メッセージキュー管理部104yは、メッセージキュー記憶部105xから、処理が成功したメッセージキューファイルを削除する。メディアサーバ200xにおいて、処理成功の旨の通知がない場合には、所定時間後にリトライ処理を行う。なお、強制的に同期をとるなどして、メディアサーバ200xにおけるライブラリ情報を書き換えるか、または情報処理装置100xにおけるライブラリ情報を元に戻す処理を行ってもよい。
【0061】
なお、メッセージキュー管理部104yは、上記のほかに、ユーザによる明示的な同期操作がなされた場合、メディアサーバ200xと通信接続した場合、または、同期してから所定時間経過した場合、を判断しており、それら条件のうち少なくとも一つを満たした場合に、同期処理を行うよう通信部101xに指示を出力する。
【0062】
また、メッセージキュー管理部104yは、メッセージキューファイルまたはそのファイル名に記述されている処理結果をメディアサーバ200xに送信する際、その内容を集約して送ることもできる。
図11に、メッセージキューの集約例を示す。
【0063】
図11(a)および(b)は、集約前メッセージキューを示し、
図11(c)は、集約後メッセージキューを示す。ここでは、各ステータスは、楽曲ジャンル+再生回数+レーティングを意味しており、
図11(a)においては、変更前ステータスとして“pops+00+00”、変更後ステータスとして“pops+01+00”が記述されている。すなわち、変更後ステータスとしては、再生回数が、1つインクリメントされていることを示す。
【0064】
同様に
図11(b)においては、変更前ステータスとして、“pops+01+00”、変更後ステータスとして“pops+01+03”が記述されている。すなわち、変更後ステータスとして、レーティングが03に変更されたことを示す。
【0065】
本実施形態においては、同じ楽曲IDに対して、メッセージキューファイルを2回送ることになり、処理に時間がかかる。このためこれを集約すると、その処理時間を軽減することができる。すなわち、
図11(c)に記載されているように、集約後メッセージキューは、変更前ステータスとして“pops+00+00”、変更後ステータスとして“pops+01+03”を記述するように集約処理を行い、これらステータスに変更されたファイル名が付されたメッセージキューを作成することができる。
【0066】
より具体的には、メッセージキュー管理部104yは、メッセージキューファイルのファイル名に記述されている、楽曲データIDおよび処理内容が一致するメッセージキューを抽出し、その抽出したメッセージキューのうち、メッセージキューIDが小さい変更前ステータス(すなわち時系列的に一番古い)と、メッセージキューIDが大きい変更後ステータス(すなわち時系列的に一番新しい)と、を抽出する。そして、これら抽出したステータスをそれぞれ変更前、変更後のステータスとした文字列からなるファイル名を生成して、新たなメッセージキューファイルとすることで、メッセージキューの集約処理を行うことができる。なお、新たな集約後メッセージキューファイルのIDは、集約対象となったファイルのうち、一番古いものにしている。
【0067】
メッセージキュー記憶部105xは、メッセージキューファイルを記憶する部分である。
【0068】
ライブラリ情報記憶部107xは、ライブラリ情報を記憶する部分である。ライブラリ情報とは、楽曲データのメタデータである。
図12に、その具体的構成を示す。
図12に示される通り、ライブラリ情報は、楽曲のID、曲名、アーティスト名、アルバム名、トラック番号、演奏時間、ジャンル、再生回数、およびレーティングからなるものである。これらライブラリ情報は、ユーザインタフェース102xを介したユーザ操作により、または装置における処理(例えば再生)に従って、変更される。このライブラリ情報は一例であり、そのほか、楽曲に関する管理情報であればこれらに限るものではない。
【0069】
楽曲データ記憶部108は、楽曲データを記憶する部分である。この楽曲データは、一般的は圧縮ファイル(MP3等)で構成されており、楽曲IDと対応付けられている。
【0070】
つぎに、メディアサーバ200xについて説明する。
図13は、メディアサーバ200xの機能構成を示すブロック図である。このメディアサーバ200xも、
図3に示されるようなハードウェア構成からなるものであり、RAM、ROM、および補助記憶装置に記憶されたプログラムに基づいて処理を実行するものである。
【0071】
通信部201xは、情報処理装置100xと通信する部分であり、本実施形態においては、メッセージキューファイルまたはメッセージキューファイルに基づいた処理結果内容を情報処理装置100xから受信する部分である。
【0072】
メッセージキュー処理部202xは、情報処理装置100xから受信したメッセージキューファイルまたは受信された処理結果内容に基づいた処理をデータ管理部203xに指示する部分である。
【0073】
データ管理部203xは、メッセージキュー処理部202xからの指示に応じてライブラリ情報記憶部204xに記憶されているライブラリ情報を更新する部分である。そして、更新の成功または失敗をメッセージキュー処理部202xに通知する。メッセージキュー処理部202xにおいては、その成否の情報を、通信部201xを介して情報処理装置100xに通知する。情報処理装置100では、その結果に基づいた処理(リトライまたは強制同期処理)を行う。
【0074】
ライブラリ情報記憶部204xは、情報処理装置100xに記憶されている楽曲データのライブラリ情報を記憶する部分である。また、楽曲データ記憶部205xは、楽曲データを記憶する分であり、情報処理装置100xからの要求により、通信部201xを介してダウンロードされる。
【0075】
このように構成された情報処理装置100xにおいて、その処理動作について説明する。
図14は、情報処理装置100xの処理を示すフローチャートである。まず、情報処理装置100xにおいて、ユーザインタフェース102xを介したユーザ操作によりメディアプレイヤーが起動される(S101)。そして、メディアプレイヤーに対するユーザ入力操作がユーザインタフェース102xにより受け付けられ(S102)、再生部103xにおいて、再生処理が行われるとともに、データ管理部106xにおいて、その再生処理に対するライブラリ情報(再生回数)が更新される(S103)。なお、そのほかメディアプレイヤーにおける編集機能を用いてアーティスト名等を変更したり、そのほかのステータスを変更することもでき、そのような変更が行われた場合もライブラリ情報が更新される。
【0076】
そして、メッセージキュー生成部104xにおいて再生処理や入力操作に基づいた文字列が生成され、当該文字列をファイル名としたメッセージキューを示すメッセージキューファイルが生成される。生成されたメッセージキューファイルは、メッセージキュー記憶部105xに記憶される(S104)。そして、メッセージキューファイルが生成されると、新たな管理ファイルが生成される(S104a)。すなわち、管理ファイルのファイル名に記述されているファイル数部分が一つインクリメントされた管理ファイルが生成される。なお、新たな管理ファイルが作成された場合、古い管理ファイルは削除されることが好ましい。
【0077】
そして、情報処理装置100xにおいて、所定条件が満たしたか否かが、メッセージキュー管理部104yにおいて判断される(S105)。ここでは、例えば、メッセージキューファイルが所定数を超えたか否か(つまり管理ファイルのファイル数が所定数を超えたか)、明示的な操作が行われたな否か、ユーザ操作などによりメディアサーバ200xに接続されたか否か、前回メディアサーバ200xに対して接続してから一定時間経過したか否か、が判断される。ここで、所定条件を満たしたと判断されると、メッセージキュー管理部104yにより、楽曲データIDおよび処理内容をキーとして、メッセージキューの集約処理が行われる(S105a)。そして、最もCUE番号の若いメッセージキューファイルのファイル名に応じた処理を通信部101からメディアサーバ200xに対して要求を行う(S106)。
【0078】
ここで、メディアサーバ200xにおいて、要求に対する処理が成功したか否かが判断され(S107)、成功したと判断された場合には、メッセージキュー管理部104yは、メディアサーバ200xに反映された処理を示すメッセージキューファイルを削除する(S108)。そして、メッセージキューファイルが残っているか否かが判断され(S110)、残っている場合には、S106に戻り、次のメッセージキューファイルに対する処理が行われる(S106)。
【0079】
また、メディアサーバ200xが処理に成功しなかった場合には、メッセージキュー管理部104yによりエラー処理が行われる(S109)。ここでのエラー処理は、例えば、リトライ処理や、強制同期処理(情報処理装置100xにおけるライブラリ情報を元に戻すなど)である。そして、これら処理が繰り返し行われる。
【0080】
つぎに、本実施形態における情報処理装置100xにおける作用効果について説明する。本実施形態の情報処理装置100xにおいて、メッセージキュー生成部104xは、ユーザインタフェース102xにより受け付けられた処理の結果に基づいた文字列を生成し、生成された文字列をファイル名とした処理結果ファイルであるメッセージキューファイルを生成する。そして、メッセージキュー管理部104yは、生成されたメッセージキューファイルを、メッセージキュー記憶部105xに記憶する。これにより、操作履歴や処理結果等のステータスを記憶するに際して、メモリ消費量を少なくするとともに、その読み出し処理を迅速に行うことができる。ここで、メッセージキューファイルは、実体データを有さない場合、メモリの利用効率をさらに向上させることができる。
【0081】
また、メッセージキュー管理部104yが、あらかじめ定めた条件に従って、複数のメッセージキューファイルを1つのメッセージキューファイルに集約することで、メモリ消費量および読み出し処理を効率的に行うことができる。さらに、メディアサーバ200x等に処理結果等を通知する際において、複数の状態を通知する必要がなく、効率的な処理を実現できる。
【0082】
さらに、本実施形態においては、通信部101xは、メッセージキューファイルのファイル名に基づいた処理を外部にあるメディアサーバ200xに出力することで、メディアサーバ200xは処理結果を把握することができる。本実施形態においては、情報処理装置100xとメディアサーバ200xにおけるライブラリ情報の整合性をとることができる。
【0083】
また、本実施形態においては、メッセージキュー管理部104yがメッセージキューファイルの数をファイル名に含めた管理ファイルを作成しておき、メッセージキューファイルが生成されるごとに、そのファイルの数を更新した管理ファイルを作成する。そして、メッセージキュー管理部104yは、そのファイル名に基づいてメッセージキューファイル数を判断することができ、ファイル数管理を迅速かつ簡易にすることができる。
【0084】
なお、上述のメディアプレイヤーに対する応用は一例であり、これに限るものではない。また、ファイル数をファイル名に含んだ管理ファイルを作成することや、複数のメッセージキューファイルを集約することについても、第1の実施形態に適用することもできる。