JP5718953B2 - 情報処理装置およびキュー記憶方法 - Google Patents

Description

本発明は、メッセージキューイングを行う情報処理装置およびキュー記憶方法に関する。

従来の携帯電話などの携帯端末におけるメールシステムは、メールサーバにおいて新しい電子メールが受信されると、携帯端末にその旨を通知し、または電子メールを配信している。例えば、以下の特許文献１には、メールサーバと携帯コンピューティングデバイスとの間でデータベースの同期をとることの記載がある。より具体的には、特許文献１に記載のデータベースの同期方法においては、メールサーバにおいてメールを受信すると、その旨を携帯コンピューティングデバイスに通知し、携帯コンピューティングデバイスは、メールサーバからメールを取得することができる。

特開２００１−２７４８４１号公報

近年、クラウドサーバを利用して、複数の通信端末において同一のメールアカウントを有し、それぞれの端末において同じ電子メールの送受信を行うシステムが考えられている。このシステムにおいては、クラウドサーバ上に電子メールデータ（ヘッダ情報や書誌事項のほか、メール本文や添付ファイルを含む）が保存されており、通信端末は、基本的には各電子メールのヘッダ情報（各種ステータス等）および書誌情報（件名、宛先など）のみを保持している。そして、ユーザが個々の電子メールデータを閲覧する際に、通信端末はクラウドサーバからメール本文および添付ファイルを取得することで、メール本文や添付ファイルを表示することができる。

しかしながら、操作履歴等をストレージに逐一、ファイルにして記憶すると、そのキューの数（操作履歴等の数）だけ、ファイルが生じてしまい、ストレージのメモリブロックを大量に消費してしまう、という問題がある。また、キューの内容をファイルデータに保持させると、そのファイルを開く必要が有り、タイムロスが生じる。

そこで、本発明においては、メッセージキューイングを利用するに際して、キューの読み出しを迅速に行うことができる情報処理装置およびキュー記憶方法を提供することを目的とする。

上述の課題を解決するために本発明の情報処理装置は、入力を受け付ける入力手段と、前記入力手段が受け付けた入力に応じた処理を行う処理手段と、前記処理手段が行った処理の結果に基づき、当該処理の内容に応じた入力情報を示す文字列を生成する文字列生成手段と、前記文字列生成手段により生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成手段と、前記ファイル生成手段により生成された処理結果ファイルを記憶する処理結果記憶手段と、を備える。

また、本発明のキュー記憶方法は、入力を受け付ける入力ステップと、前記入力ステップが受け付けた入力に応じた処理を行う処理ステップと、前記処理ステップが行った処理の結果に基づき、当該処理の内容に応じた入力情報を示す文字列を生成する文字列生成ステップと、前記文字列生成ステップにより生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成ステップと、前記ファイル生成ステップにより生成された処理結果ファイルを処理結果記憶手段に記憶する記憶ステップと、を備える。
また、本発明の情報処理システムは、第１の情報処理装置及び第２の情報処理装置を含む情報処理システムであって、前記第１の情報処理装置は、入力を受け付ける入力手段と、前記入力手段が受け付けた入力に応じた処理を行う処理手段と、前記処理手段が行った処理の結果に基づき、当該処理の内容に応じた入力情報を示す文字列を生成する文字列生成手段と、前記文字列生成手段により生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成手段と、前記ファイル生成手段により生成された処理結果ファイルを記憶する処理結果記憶手段と、前記処理結果ファイルのファイル名に基づいて、前記処理手段が行った処理の結果を前記第２の情報処理装置に送信する送信手段と、を備え、前記第２の情報処理装置は、前記送信手段により送信された処理の結果に応じた処理を実行する処理手段とを備える。

本発明によれば、受け付けられた処理の結果に基づき、処理の内容に応じた入力情報を示す文字列を生成し、生成された文字列をファイル名とした処理結果ファイルを生成する。そして、生成された処理結果ファイルを記憶する。これにより、操作履歴や処理内容等を記憶するに際して、メモリ消費量を少なくするとともに、その読み出し処理を迅速に行うことができる。その際、ファイル生成手段は、実体データを有さない処理結果ファイルを生成する。

また、本発明の情報処理装置は、前記処理結果記憶手段に記憶された複数の処理結果ファイルを、あらかじめ定めた条件に従って、１つの処理結果ファイルに集約する集約手段をさらに備える。

この発明によれば、あらかじめ定めた条件に従って、複数の処理結果ファイルを１つの処理結果ファイルに集約することで、メモリ消費量および読み出し処理を効率的に行うことができる。さらに、サーバ等に処理結果等を通知する際において、複数の状態を通知する必要がなく、効率的な処理を実現できる。

また、本発明の情報処理装置は、前記処理結果記憶手段に記憶された処理結果ファイルのファイル名に基づいて、前記処理手段が行った処理の結果を外部へ出力する出力手段をさらに備える。

この発明によれば、処理結果ファイルのファイル名に基づいた処理を外部に出力することで、外部端末は処理結果を把握することができる。

また、本発明の情報処理装置において、前記処理結果記憶手段は、処理結果ファイルの数をファイル名に含む管理ファイルをさらに記憶し、前記ファイル生成手段が処理結果ファイルを生成するごとに、前記管理ファイルのファイル名に含まれるファイル数の情報をインクリメントするとともに、当該ファイル数の情報が所定数に達すると前記出力手段に前記処理手段が行った処理の結果を外部へ出力させるファイル数管理手段を備える。

この発明によれば、処理結果ファイルの数をファイル名に含めた管理ファイルを作成しておき、そのファイル名に基づいてファイル数を判断することができ、ファイル数管理を迅速かつ簡易にすることができる。

本発明によれば、操作履歴や処理内容等を記憶するに際して、メモリ消費量を少なくするとともに、その読み出し処理を迅速に行うことができる。

第１の実施形態の情報処理装置１００を利用した通信システムを示すシステム構成図である。 第１の実施形態の情報処理装置１００の機能構成を示すブロック図である。 情報処理装置１００のハードウェア構成図である。 ディレクトリエントリと、ｉノードデータ構造とからなるファイル構造を示す説明図である。 サーバ２００の機能構成を示すブロック図である。 情報処理装置１００の処理を示すフローチャートである。 第２の実施形態の情報処理装置１００ｘを利用した通信システムを示すシステム構成図である。 第２の実施形態の情報処理装置１００ｘの機能構成を示すブロック図である。 第２の実施形態におけるメッセージキューの具体例を示す説明図である。 管理ファイルのファイル名の構成を示す説明図である。 メッセージキューの集約例を示す説明図である。 ライブラリ情報の具体例を示す説明図である。 メディアサーバ２００ｘの機能構成を示すブロック図である。 情報処理装置１００ｘの処理を示すフローチャートである。

添付図面を参照しながら本発明の実施形態を説明する。可能な場合には、同一の部分には同一の符号を付して、重複する説明を省略する。

［第１の実施形態］
図１は、本実施形態の情報処理装置１００を利用した通信システムを示すシステム構成図である。図1に示す通り、情報処理装置１００は、ネットワークを介してサーバ２００と通信接続することができる。本実施形態においては、情報処理装置１００は、当該装置に対して受け付けられた操作履歴情報や、当該装置にインストールされているアプリケーションに対して受け付けられた操作履歴情報およびそのアプリケーションの処理結果情報をメッセージキューとして生成して、記憶することができる。そして、情報処理装置１００は、生成されたメッセージキューに基づいて、操作履歴情報や処理結果情報を所定のタイミングでサーバ２００に送信し、サーバ２００は、受信した操作履歴情報や処理結果情報を記憶する。

ここで情報処理装置１００は、メッセージキューとして、操作履歴情報および処理結果情報を示す文字列を生成し、その文字列をファイル名としたメッセージキューファイルを生成する。そして、情報処理装置１００は、所定のタイミングで、この生成したメッセージキューファイルのファイル名から操作履歴情報や処理結果情報を抽出して、サーバ２００に出力し、また同期処理を行うことができる。

図２は、本実施形態の情報処理装置１００の機能構成を示すブロック図である。図２に示されるように、情報処理装置１００は、通信部１０１（出力手段）、ユーザインタフェース１０２（入力手段）、データ処理部１０３（処理手段）、メッセージキュー管理部１０４（文字列生成手段、ファイル生成手段）、メッセージキュー記憶部１０５（処理結果記憶手段）、データ管理部１０６、ライブラリ情報記憶部１０７およびデータ記憶部１０８を含んで構成されている。

図３は、情報処理装置１００のハードウェア構成図である。図１に示される情報処理装置１００は、物理的には、図３に示すように、ＣＰＵ１１、主記憶装置であるＲＡＭ１２及びＲＯＭ１３、入力デバイスであるキーボード及びマウス等の入力装置１４、ディスプレイ等の出力装置１５、ネットワークカード等のデータ送受信デバイスである通信モジュール１６、半導体メモリ等の補助記憶装置１７などを含むコンピュータシステムとして構成されている。図２における各機能は、図３に示すＣＰＵ１１、ＲＡＭ１２等のハードウェア上に所定のコンピュータソフトウェアを読み込ませることにより、ＣＰＵ１１の制御のもとで入力装置１４、出力装置１５、通信モジュール１６を動作させるとともに、ＲＡＭ１２や補助記憶装置１７におけるデータの読み出し及び書き込みを行うことで実現される。以下、図２に示す機能ブロックに基づいて、各機能ブロックを説明する。

通信部１０１は、サーバ２００と通信接続する部分であり、メッセージキューファイルに記述されている処理結果をサーバ２００に通知することができる。

ユーザインタフェース１０２は、ユーザによる操作を受け付け、またはユーザに提供される情報を表示する部分であり、例えば、キーボード、ディスプレイや、タッチパネルディスプレイである。情報処理装置１００が携帯電話であった場合には、当該ユーザインタフェース１０２は、各種アイコンや、メッセージなどを表示し、またユーザからアイコンなどに対する操作を受け付けることができる。

データ処理部１０３は、ユーザインタフェース１０２により受け付けられた操作に基づいた処理を実行する部分である。例えば、所定のアプリケーションが起動されているのであれば、そのアプリケーションに従った操作を受け付けて実行するものである。アプリケーションが、ゲームであれば、ゲームに対する操作であったり、ブラウザであれば、閲覧のための操作である。本実施形態においては、アプリケーションや、その具体的な操作については何ら限定するものではない。

メッセージキュー管理部１０４は、データ処理部１０３において処理された結果に基づいた文字列を生成し、その文字列をファイル名としたメッセージキューファイルを生成する部分である。そして、生成したメッセージキューファイルをメッセージキュー記憶部１０５に記憶する。

ここで、図４を用いて、生成する文字列およびその文字列からなるファイル名の記述について説明する。図４は、ディレクトリエントリと、ｉノードデータ構造とからなるファイル構造を示す説明図である。この説明図は、一般的に、ＵＮＩＸ（登録商標）などにおけるファイル構造を示したものである。

図４（ａ）に示される通り、ディレクトリエントリは、ｉノード番号とファイル名とからなるデータ構造をとる。また、ｉノードデータ構造は、ファイル区分（ディレクトリか、ファイルの区分）、ｉノード番号、ユーザＩＤ、およびファイルサイズ等を含んだものである。メッセージキュー管理部１０４は、そのディレクトリエントリにおけるファイル名の領域に、処理結果を示す文字列を記述することができる。なお、ｉノードデータ構造には、実体データを含めないことでデータサイズを極力小さくすることができる。

図４（ａ）を用いてさらに、ファイル名の構造について説明する。上述した通り、ファイル名は、少なくとも、ＣＵＥ番号および操作履歴情報や処理結果情報を示す文字列からなる。ＣＵＥ番号は、入力の時系列的な順番を示すＩＤであり、操作履歴情報や処理結果情報は、どのキーが押下（またはタッチ）されたかを示す情報である。なお、この情報に限るものではなく、例えば図４（ｂ）に示されるように、ＵＵＩＤ、ＣＵＥ番号、タイプ、および処理結果内容を示す文字列を生成するようにしてもよい。なお、ここでＵＵＩＤ（Universally Unique Identifier）は、標準化された一意に識別するための識別子であり、タイプは、アプリケーションなどの操作対象を示し、処理結果内容は、操作に対するアプリケーションにより処理された結果を示す情報である。また、図４（ｃ）に示される文字列としてもよい。図４（ｃ）においては、ＵＵＩＤ、ＣＵＥ番号、タイプ、処理結果前ステータス、および処理結果後ステータスを示す文字列を生成することが示されている。

さらに、メッセージキュー管理部１０４は、生成したメッセージキューファイルが所定数に達すると、通信部１０１を介して、メッセージキューファイルそれ自身をサーバ２００に送信するか、またはメッセージキューファイルのファイル名に記述されている文字列に基づいた操作履歴情報や処理結果情報等を抽出してサーバ２００に送信する。

メッセージキュー管理部１０４は、サーバ２００から正常終了の旨を、通信部１０１を介して受信すると、当該正常終了したメッセージキューファイルをメッセージキュー記憶部１０５から削除する。また、サーバ２００からエラーの旨を受信すると、その対応するメッセージキューファイルに基づいて、ライブラリ情報記憶部１０７に記憶されているアプリケーションなどの処理結果情報などを元に戻す処理を行う。

メッセージキュー記憶部１０５は、メッセージキュー管理部１０４により生成された複数のメッセージキューファイルを記憶する部分である。

データ管理部１０６は、ユーザ操作に応じてアプリケーションのライブラリ情報のステータスを変更する部分である。本実施形態では、ライブラリ情報とは、アプリケーションの処理結果情報などのステータス情報を含んだものであるが、これに限定するものではなく、アプリケーションのほか、情報処理装置１００の処理結果情報であってもよい。

ライブラリ情報記憶部１０７は、アプリケーションの処理結果情報や、ステータス情報などのメタデータを記憶する部分である。また、データ記憶部１０８は、アプリケーションなどのデータを含む各種データを記憶する部分である。

つぎに、この情報処理装置１００と通信接続するサーバ２００について説明する。図５は、サーバ２００の機能構成を示すブロック図である。図５に示されるように、サーバ２００は、通信部２０１、メッセージキュー処理部２０２、データ管理部２０３、ライブラリ情報記憶部２０４およびデータ記憶部２０５を含んで構成されている。このサーバ２００も、情報処理装置１００と同様にＣＰＵ、ＲＡＭ、ＲＯＭ等を備えたコンピュータシステムから構成されている。以下、各機能について説明する。

通信部２０１は、情報処理装置１００と通信する部分であり、本実施形態においては、メッセージキューファイルまたはメッセージキューファイルに基づいた処理結果内容を情報処理装置１００から受信する部分である。

メッセージキュー処理部２０２は、情報処理装置１００から受信したメッセージキューファイルまたは受信された処理結果内容に基づいた処理をデータ管理部２０３に指示する部分である。

データ管理部２０３は、メッセージキュー処理部２０２からの指示に応じてライブラリ情報記憶部２０４に記憶されているライブラリ情報を更新する部分である。そして、更新の成功または失敗をメッセージキュー処理部２０２に通知する。メッセージキュー処理部２０２においては、その成否の情報を、通信部２０１を介して情報処理装置１００に通知する。情報処理装置１００では、その結果に基づいた処理（リトライまたは強制同期処理）を行う。

ライブラリ情報記憶部２０４は、情報処理装置１００における操作履歴情報や、アプリケーションの処理結果情報などのライブラリ情報を記憶する部分である。また、データ記憶部２０５は、各種データを記憶する部分である。

このように構成された情報処理装置１００において、その処理動作について説明する。図６は、情報処理装置１００の処理を示すフローチャートである。まず、情報処理装置１００において、ユーザインタフェース１０２を介したユーザ操作によりアプリケーションが起動される（Ｓ１０１）。そして、アプリケーションに対するユーザ入力操作がユーザインタフェース１０２により受け付けられ（Ｓ１０２）、データ処理部１０３において、その入力操作に対する処理を行うとともに、データ管理部１０６において、その入力操作に対するライブラリ情報が更新される（Ｓ１０３）。なお、単なる入力操作履歴を保持するだけである場合には、ライブラリ情報の更新処理はされなくてもよい。

そして、メッセージキュー管理部１０４において入力操作による処理結果に基づいた文字列が生成され、当該文字列をファイル名としたメッセージキューを示すメッセージキューファイルが生成される。生成されたメッセージキューファイルは、メッセージキュー記憶部１０５に記憶される（Ｓ１０４）。

ここで、情報処理装置１００において、所定条件を満たしたか否かが、メッセージキュー管理部１０４において判断される（Ｓ１０５）。ここでは、例えば、メッセージキューファイルが所定数を超えたか否か、明示的な操作が行われたな否か、ユーザ操作などによりサーバ２００に接続されたか否か、サーバ２００に対して前回接続してから一定時間経過したか否か、が判断される。ここで、所定条件を満たしたと判断されると、最もＣＵＥ番号の若いメッセージキューファイルのファイル名に応じた処理を通信部１０１からサーバ２００に対して要求を行う（Ｓ１０６）。

ここで、サーバ２００において、要求に対する処理が成功したか否かが判断され（Ｓ１０７）、成功したと判断された場合には、メッセージキュー管理部１０４は、サーバ２００に反映された処理を示すメッセージキューファイルを削除する（Ｓ１０８）。そして、メッセージキューファイルが残っているか否かが判断され（Ｓ１１０）、残っている場合には、Ｓ１０６に戻り、次のメッセージキューファイルに対する処理が行われる（Ｓ１０６）。

また、サーバ２００が処理に成功しなかった場合には、メッセージキュー管理部１０４によりエラー処理が行われる（Ｓ１０９）。ここでのエラー処理は、例えば、リトライ処理や、強制同期処理（情報処理装置１００におけるライブラリ情報を元に戻すなど）である。そして、これら処理が繰り返し行われる。

このようにして、本実施形態においては、情報処理装置１００において生成したメッセージキューファイルのファイル名に、操作履歴情報やアプリケーションの処理結果情報などの各種ステータス情報を記述することで、その読み出し等の処理を迅速に行うことができる。なお、本実施形態においては、その利用方法や、使用状況を特に限定するものではなく、汎用的な情報処理装置１００において、ユーザにより入力された操作履歴や装置やアプリケーションに対する処理結果情報などのステータス情報をメッセージキューファイルのファイル名に記述するとしたものであり、その応用範囲は多岐に渡るものである。例えば、本実施形態における情報処理装置１００は、メディアプレイヤー、電子書籍リーダ、非同期通信を行うネットワークゲームなどに応用することができる。

［第２の実施形態］
つぎに、第２の実施形態について説明する。第１の実施形態は、汎用的な情報処理装置１００において、操作履歴や処理結果などのステータス情報をメッセージキューファイルのファイル名に記述することを特徴としたものである。本実施形態においては、情報処理装置１００を、楽曲データを再生したり、ダウンロードするメディアプレイヤーに応用した情報処理装置１００ｘを説明する。

図７は、本実施形態の情報処理装置１００ｘを利用した通信システムを示すシステム構成図である。この通信システムは、スマートフォン等の情報処理装置１００ｘとメディアサーバ２００ｘとを含んでいる音楽配信システムである。ここで、情報処理装置１００ｘは、メディアプレイヤアプリケーションを備えており、ユーザは、この情報処理装置１００ｘを操作することにより、メディアサーバ２００ｘから楽曲データをダウンロードし、情報処理装置１００ｘにおいて保持し、またその楽曲データを再生することができる。また、メディアサーバ２００ｘは、インターネット上に構築されているものであり、情報処理装置１００ｘからの要求に応じて楽曲データの配信処理や、情報処理装置１００ｘにおける楽曲データのステータスの管理を行う。

なお、この情報処理装置１００ｘは、メッセージキューイングシステムを備えており、情報処理装置１００ｘにおいてユーザにより操作された操作履歴や、当該操作により処理された処理結果を示す文字列を生成し、生成した文字列をファイル名としたメッセージキューファイルを生成し、キューとして記憶する。

図８は、本実施形態の情報処理装置１００ｘの機能構成を示すブロック図である。図８に示されるように、情報処理装置１００ｘは、通信部１０１ｘ（出力手段）、ユーザインタフェース１０２ｘ（入力手段）、再生部１０３ｘ（処理手段）、メッセージキュー生成部１０４ｘ（文字列生成手段、ファイル生成手段）、メッセージキュー管理部１０４ｙ（集約手段、ファイル数管理手段）、メッセージキュー記憶部１０５ｘ（処理結果記憶手段）、データ管理部１０６ｘ、ライブラリ情報記憶部１０７ｘおよび楽曲データ記憶部１０８ｘを含んで構成されている。この情報処理装置１００ｘは、第１の実施形態における情報処理装置１００と同様のハードウェア構成をとるものである。

通信部１０１ｘは、メディアサーバ２００ｘと通信を行う部分であり、メディアサーバ２００ｘから楽曲データをダウンロードし、またメッセージキューファイルのファイル名に記述されているメッセージキューをメディアサーバ２００ｘに送信し、または同期処理する部分である。

ユーザインタフェース１０２ｘは、ユーザからの操作を受け付ける部分であり、例えば、楽曲データのダウンロード指示や、楽曲データの再生指示などの操作を受け付けることができる。

再生部１０３ｘは、ユーザからの指示に応じて、楽曲データ記憶部１０８ｘに記憶されている楽曲データの再生処理を行う部分である。

メッセージキュー生成部１０４ｘは、データ管理部１０６ｘにより実行された処理結果に基づいた文字列を生成し、当該文字列をファイル名とするメッセージキューファイルを生成する部分である。生成したメッセージキューファイルは、メッセージキュー記憶部１０５ｘに記憶される。

図９に、メッセージキューファイルのファイル名の具体例を示す。第１の実施形態と異なり、本実施形態においては、楽曲データのステータスを変更するものであることから、楽曲データ特有の項目がそのファイル名（文字列）に必要となる。図９（ａ）は、楽曲データの管理情報を変更する場合における文字列を示している。すなわち、メッセージキューとして、メッセージキューＩＤ、楽曲データＩＤ、処理内容として“status”、変更前ステータス、および変更後ステータスとから構成されている。ここで変更前ステータス、変更後ステータスは、楽曲のジャンル、再生回数、およびレーティングが挙げられるが、これに限るものではなく、楽曲に関するステータスであればよい。

また、図９（ｂ）においては、リネーム（名称変更）の場合のメッセージキューを示している。ここでは、メッセージキューとして、メッセージキューＩＤ、楽曲データＩＤ、処理内容として“rename”、変更前ステータス、および変更後ステータスとから構成されている。ここで変更前ステータス、変更後ステータスは、曲名、アーティスト名、およびアルバム名が挙げられる。そのほか、名称変更の対象となる項目であればこれらに限るものではない。

図９（ａ）および（ｂ）に示されるように、変更前と変更後とにおける各ステータス（管理情報または名前）が文字列として生成され、これがメッセージキューファイルのファイル名として記述される。

メッセージキュー管理部１０４ｙは、生成したメッセージキューファイルをメッセージキュー記憶部１０５ｘに記憶する。

さらに、メッセージキュー管理部１０４ｙは、メッセージキュー管理ファイルを生成する。このメッセージキュー管理ファイルは、管理ファイルを示す識別子である識別ラベルと、メッセージキューファイルのファイル数を示す数値情報とからなるファイル名が付与されており、メッセージキューファイルが生成される毎に、この管理ファイルにおけるファイル名におけるファイル数を示す数値情報が更新される。

図１０は、管理ファイルのファイル名の構成を示す説明図である。図１０に示される通り、管理ファイルのファイル名は、管理ファイルであることを示す識別ラベルと、ファイル数とから構成されている。この管理ファイルも、メッセージキューファイルと同様に、ｉノードの構成におけるディレクトリエントリのファイル名領域に記述される（図４参照）。

メッセージキュー管理部１０４ｙは、この管理ファイルのファイル名に記述されているファイル数が所定数に達すると、通信部１０１ｘを介してメディアサーバ２００ｘに対してメッセージキューファイルのファイル名として記述されている処理をメディアサーバ２００ｘに対して要求する。メディアサーバ２００ｘにおいては、当該要求に基づいた処理に成功すると、メッセージキュー管理部１０４ｙは、メッセージキュー記憶部１０５ｘから、処理が成功したメッセージキューファイルを削除する。メディアサーバ２００ｘにおいて、処理成功の旨の通知がない場合には、所定時間後にリトライ処理を行う。なお、強制的に同期をとるなどして、メディアサーバ２００ｘにおけるライブラリ情報を書き換えるか、または情報処理装置１００ｘにおけるライブラリ情報を元に戻す処理を行ってもよい。

なお、メッセージキュー管理部１０４ｙは、上記のほかに、ユーザによる明示的な同期操作がなされた場合、メディアサーバ２００ｘと通信接続した場合、または、同期してから所定時間経過した場合、を判断しており、それら条件のうち少なくとも一つを満たした場合に、同期処理を行うよう通信部１０１ｘに指示を出力する。

また、メッセージキュー管理部１０４ｙは、メッセージキューファイルまたはそのファイル名に記述されている処理結果をメディアサーバ２００ｘに送信する際、その内容を集約して送ることもできる。図１１に、メッセージキューの集約例を示す。

図１１（ａ）および（ｂ）は、集約前メッセージキューを示し、図１１（ｃ）は、集約後メッセージキューを示す。ここでは、各ステータスは、楽曲ジャンル＋再生回数＋レーティングを意味しており、図１１（ａ）においては、変更前ステータスとして“pops＋００+００”、変更後ステータスとして“pops＋０１＋００”が記述されている。すなわち、変更後ステータスとしては、再生回数が、１つインクリメントされていることを示す。

同様に図１１（ｂ）においては、変更前ステータスとして、“pops＋０１+００”、変更後ステータスとして“pops＋０１＋０３”が記述されている。すなわち、変更後ステータスとして、レーティングが０３に変更されたことを示す。

本実施形態においては、同じ楽曲ＩＤに対して、メッセージキューファイルを２回送ることになり、処理に時間がかかる。このためこれを集約すると、その処理時間を軽減することができる。すなわち、図１１（ｃ）に記載されているように、集約後メッセージキューは、変更前ステータスとして“pops＋００+００”、変更後ステータスとして“pops＋０１＋０３”を記述するように集約処理を行い、これらステータスに変更されたファイル名が付されたメッセージキューを作成することができる。

より具体的には、メッセージキュー管理部１０４ｙは、メッセージキューファイルのファイル名に記述されている、楽曲データＩＤおよび処理内容が一致するメッセージキューを抽出し、その抽出したメッセージキューのうち、メッセージキューＩＤが小さい変更前ステータス（すなわち時系列的に一番古い）と、メッセージキューＩＤが大きい変更後ステータス（すなわち時系列的に一番新しい）と、を抽出する。そして、これら抽出したステータスをそれぞれ変更前、変更後のステータスとした文字列からなるファイル名を生成して、新たなメッセージキューファイルとすることで、メッセージキューの集約処理を行うことができる。なお、新たな集約後メッセージキューファイルのＩＤは、集約対象となったファイルのうち、一番古いものにしている。

メッセージキュー記憶部１０５ｘは、メッセージキューファイルを記憶する部分である。

ライブラリ情報記憶部１０７ｘは、ライブラリ情報を記憶する部分である。ライブラリ情報とは、楽曲データのメタデータである。図１２に、その具体的構成を示す。図１２に示される通り、ライブラリ情報は、楽曲のＩＤ、曲名、アーティスト名、アルバム名、トラック番号、演奏時間、ジャンル、再生回数、およびレーティングからなるものである。これらライブラリ情報は、ユーザインタフェース１０２ｘを介したユーザ操作により、または装置における処理（例えば再生）に従って、変更される。このライブラリ情報は一例であり、そのほか、楽曲に関する管理情報であればこれらに限るものではない。

楽曲データ記憶部１０８は、楽曲データを記憶する部分である。この楽曲データは、一般的は圧縮ファイル（ＭＰ３等）で構成されており、楽曲ＩＤと対応付けられている。

つぎに、メディアサーバ２００ｘについて説明する。図１３は、メディアサーバ２００ｘの機能構成を示すブロック図である。このメディアサーバ２００ｘも、図３に示されるようなハードウェア構成からなるものであり、ＲＡＭ、ＲＯＭ、および補助記憶装置に記憶されたプログラムに基づいて処理を実行するものである。

通信部２０１ｘは、情報処理装置１００ｘと通信する部分であり、本実施形態においては、メッセージキューファイルまたはメッセージキューファイルに基づいた処理結果内容を情報処理装置１００ｘから受信する部分である。

メッセージキュー処理部２０２ｘは、情報処理装置１００ｘから受信したメッセージキューファイルまたは受信された処理結果内容に基づいた処理をデータ管理部２０３ｘに指示する部分である。

データ管理部２０３ｘは、メッセージキュー処理部２０２ｘからの指示に応じてライブラリ情報記憶部２０４ｘに記憶されているライブラリ情報を更新する部分である。そして、更新の成功または失敗をメッセージキュー処理部２０２ｘに通知する。メッセージキュー処理部２０２ｘにおいては、その成否の情報を、通信部２０１ｘを介して情報処理装置１００ｘに通知する。情報処理装置１００では、その結果に基づいた処理（リトライまたは強制同期処理）を行う。

ライブラリ情報記憶部２０４ｘは、情報処理装置１００ｘに記憶されている楽曲データのライブラリ情報を記憶する部分である。また、楽曲データ記憶部２０５ｘは、楽曲データを記憶する分であり、情報処理装置１００ｘからの要求により、通信部２０１ｘを介してダウンロードされる。

このように構成された情報処理装置１００ｘにおいて、その処理動作について説明する。図１４は、情報処理装置１００ｘの処理を示すフローチャートである。まず、情報処理装置１００ｘにおいて、ユーザインタフェース１０２ｘを介したユーザ操作によりメディアプレイヤーが起動される（Ｓ１０１）。そして、メディアプレイヤーに対するユーザ入力操作がユーザインタフェース１０２ｘにより受け付けられ（Ｓ１０２）、再生部１０３ｘにおいて、再生処理が行われるとともに、データ管理部１０６ｘにおいて、その再生処理に対するライブラリ情報（再生回数）が更新される（Ｓ１０３）。なお、そのほかメディアプレイヤーにおける編集機能を用いてアーティスト名等を変更したり、そのほかのステータスを変更することもでき、そのような変更が行われた場合もライブラリ情報が更新される。

そして、メッセージキュー生成部１０４ｘにおいて再生処理や入力操作に基づいた文字列が生成され、当該文字列をファイル名としたメッセージキューを示すメッセージキューファイルが生成される。生成されたメッセージキューファイルは、メッセージキュー記憶部１０５ｘに記憶される（Ｓ１０４）。そして、メッセージキューファイルが生成されると、新たな管理ファイルが生成される（Ｓ１０４ａ）。すなわち、管理ファイルのファイル名に記述されているファイル数部分が一つインクリメントされた管理ファイルが生成される。なお、新たな管理ファイルが作成された場合、古い管理ファイルは削除されることが好ましい。

そして、情報処理装置１００ｘにおいて、所定条件が満たしたか否かが、メッセージキュー管理部１０４ｙにおいて判断される（Ｓ１０５）。ここでは、例えば、メッセージキューファイルが所定数を超えたか否か（つまり管理ファイルのファイル数が所定数を超えたか）、明示的な操作が行われたな否か、ユーザ操作などによりメディアサーバ２００ｘに接続されたか否か、前回メディアサーバ２００ｘに対して接続してから一定時間経過したか否か、が判断される。ここで、所定条件を満たしたと判断されると、メッセージキュー管理部１０４ｙにより、楽曲データＩＤおよび処理内容をキーとして、メッセージキューの集約処理が行われる（Ｓ１０５ａ）。そして、最もＣＵＥ番号の若いメッセージキューファイルのファイル名に応じた処理を通信部１０１からメディアサーバ２００ｘに対して要求を行う（Ｓ１０６）。

ここで、メディアサーバ２００ｘにおいて、要求に対する処理が成功したか否かが判断され（Ｓ１０７）、成功したと判断された場合には、メッセージキュー管理部１０４ｙは、メディアサーバ２００ｘに反映された処理を示すメッセージキューファイルを削除する（Ｓ１０８）。そして、メッセージキューファイルが残っているか否かが判断され（Ｓ１１０）、残っている場合には、Ｓ１０６に戻り、次のメッセージキューファイルに対する処理が行われる（Ｓ１０６）。

また、メディアサーバ２００ｘが処理に成功しなかった場合には、メッセージキュー管理部１０４ｙによりエラー処理が行われる（Ｓ１０９）。ここでのエラー処理は、例えば、リトライ処理や、強制同期処理（情報処理装置１００ｘにおけるライブラリ情報を元に戻すなど）である。そして、これら処理が繰り返し行われる。

つぎに、本実施形態における情報処理装置１００ｘにおける作用効果について説明する。本実施形態の情報処理装置１００ｘにおいて、メッセージキュー生成部１０４ｘは、ユーザインタフェース１０２ｘにより受け付けられた処理の結果に基づいた文字列を生成し、生成された文字列をファイル名とした処理結果ファイルであるメッセージキューファイルを生成する。そして、メッセージキュー管理部１０４ｙは、生成されたメッセージキューファイルを、メッセージキュー記憶部１０５ｘに記憶する。これにより、操作履歴や処理結果等のステータスを記憶するに際して、メモリ消費量を少なくするとともに、その読み出し処理を迅速に行うことができる。ここで、メッセージキューファイルは、実体データを有さない場合、メモリの利用効率をさらに向上させることができる。

また、メッセージキュー管理部１０４ｙが、あらかじめ定めた条件に従って、複数のメッセージキューファイルを１つのメッセージキューファイルに集約することで、メモリ消費量および読み出し処理を効率的に行うことができる。さらに、メディアサーバ２００ｘ等に処理結果等を通知する際において、複数の状態を通知する必要がなく、効率的な処理を実現できる。

さらに、本実施形態においては、通信部１０１ｘは、メッセージキューファイルのファイル名に基づいた処理を外部にあるメディアサーバ２００ｘに出力することで、メディアサーバ２００ｘは処理結果を把握することができる。本実施形態においては、情報処理装置１００ｘとメディアサーバ２００ｘにおけるライブラリ情報の整合性をとることができる。

また、本実施形態においては、メッセージキュー管理部１０４ｙがメッセージキューファイルの数をファイル名に含めた管理ファイルを作成しておき、メッセージキューファイルが生成されるごとに、そのファイルの数を更新した管理ファイルを作成する。そして、メッセージキュー管理部１０４ｙは、そのファイル名に基づいてメッセージキューファイル数を判断することができ、ファイル数管理を迅速かつ簡易にすることができる。

なお、上述のメディアプレイヤーに対する応用は一例であり、これに限るものではない。また、ファイル数をファイル名に含んだ管理ファイルを作成することや、複数のメッセージキューファイルを集約することについても、第１の実施形態に適用することもできる。

１００、１００ｘ…情報処理装置、１０１、１０１ｘ…通信部、１０２、１０２ｘ…ユーザインタフェース、１０３…データ処理部、１０３ｘ…再生部、１０４…メッセージキュー管理部、１０４ｘ…メッセージキュー生成部、１０４ｙ…メッセージキュー管理部、１０５、１０５ｘ…メッセージキュー記憶部、１０６、１０６ｘ…データ管理部、１０７、１０７ｘ…ライブラリ情報記憶部、１０８…データ記憶部、１０８、１０８ｘ…楽曲データ記憶部、２００…サーバ、２００ｘ…メディアサーバ、２０１、２０１ｘ…通信部、２０２、２０２ｘ…メッセージキュー処理部、２０３、２０３ｘ…データ管理部、２０４、２０４ｘ…ライブラリ情報記憶部、２０５…データ記憶部、２０５ｘ…楽曲データ記憶部。

Claims (7)

1. 入力を受け付ける入力手段と、
   前記入力手段が受け付けた入力に応じた処理を行う処理手段と、
   前記処理手段が行った処理の結果に基づき、当該処理の内容に応じた入力情報を示す文字列を生成する文字列生成手段と、
   前記文字列生成手段により生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成手段と、
   前記ファイル生成手段により生成された処理結果ファイルを記憶する処理結果記憶手段と、を備える情報処理装置。
2. 前記ファイル生成手段は、実体データを有さない処理結果ファイルを生成することを特徴とする請求項１に記載の情報処理装置。
3. 前記処理結果記憶手段に記憶された複数の処理結果ファイルを、あらかじめ定めた条件に従って、１つの処理結果ファイルに集約する集約手段をさらに備えることを特徴とする請求項１または請求項２に記載の情報処理装置。
4. 前記処理結果記憶手段に記憶された処理結果ファイルのファイル名に基づいて、前記処理手段が行った処理の結果を外部へ出力する出力手段をさらに備えることを特徴とする請求項１から３のいずれか一項に記載の情報処理装置。
5. 前記処理結果記憶手段は、処理結果ファイルの数をファイル名に含む管理ファイルをさらに記憶し、
   前記ファイル生成手段が処理結果ファイルを生成するごとに、前記管理ファイルのファイル名に含まれるファイル数の情報をインクリメントするとともに、当該ファイル数の情報が所定数に達すると前記出力手段に前記処理手段が行った処理の結果を外部へ出力させるファイル数管理手段を備えることを特徴とする請求項４に記載の情報処理装置。
6. 入力を受け付ける入力ステップと、
   前記入力ステップが受け付けた入力に応じた処理を行う処理ステップと、
   前記処理ステップが行った処理の結果に基づき、当該処理の内容に応じた入力情報を示す文字列を生成する文字列生成ステップと、
   前記文字列生成ステップにより生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成ステップと、
   前記ファイル生成ステップにより生成された処理結果ファイルを処理結果記憶手段に記憶する記憶ステップと、を備えるキュー記憶方法。
7. 第１の情報処理装置及び第２の情報処理装置を含む情報処理システムであって、
   前記第１の情報処理装置は、
   入力を受け付ける入力手段と、
   前記入力手段が受け付けた入力に応じた処理を行う処理手段と、
   前記処理手段が行った処理の結果に基づき、当該処理の内容に応じた入力情報を示す文字列を生成する文字列生成手段と、
   前記文字列生成手段により生成された文字列をファイル名とした処理結果ファイルを生成するファイル生成手段と、
   前記ファイル生成手段により生成された処理結果ファイルを記憶する処理結果記憶手段と、
   前記処理結果ファイルのファイル名に基づいて、前記処理手段が行った処理の結果を前記第２の情報処理装置に送信する送信手段と、
   を備え、
   前記第２の情報処理装置は、
   前記送信手段により送信された処理の結果に応じた処理を実行する処理手段と
   を備える情報処理システム。

Images