JP7225554B2 - 情報処理装置、情報処理システムおよび情報処理プログラム - Google Patents

Description

本発明は、情報処理装置、情報処理システムおよび情報処理プログラムに関する。

従来、イベント駆動により、関数（処理）を実行するサービスが、一般的に広く提供されている。

関連する先行技術としては、複数ユーザがマクロを共有したり、データ処理と中間結果とを管理する技術がある（たとえば、下記特許文献１、２を参照。）。

特開２０１５－１５８９２３号公報 特開平５－１８９４９０号公報

しかしながら、従来技術では、サービスを受ける人が多くなると、同じ処理が大量に実行されることになり、リソースの無駄遣いが大きくなるという問題点がある。

一つの側面では、本発明は、処理を削減することを目的とする。

一つの実施態様では、イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、情報処理装置、情報処理システムおよび情報処理プログラムが提供される。

本発明の一側面によれば、処理を削減することができる。

図１は、実施の形態にかかる情報処理装置、情報処理システムおよび情報処理プログラムの概要の一例を示す説明図である。 図２は、情報処理システム２００のシステム構成の一例を示すブロック図である。 図３は、情報処理装置２０１のハードウェア構成の一例を示すブロック図である。 図４は、ルールＤＢ２１１のデータ構成の一例を示す説明図である。 図５は、処理情報ＤＢ２１２のデータ構成の一例を示す説明図である。 図６は、グループ情報ＤＢ２１３のデータ構成の一例を示す説明図である。 図７は、処理依存関係ＤＢ２１４のデータ構成の一例を示す説明図である。 図８は、データ間関係ＤＢ２１５のデータ構成の一例を示す説明図である。 図９は、情報処理システム２００の機能的構成の一例を示すブロック図である。 図１０は、処理管理部２２１の処理の手順の一例を示すフローチャートである。 図１１は、グループ管理部２２２の処理の手順の一例を示すフローチャートである。 図１２は、ルール登録部２２３の処理の手順の一例を示すフローチャートである。 図１３は、イベント判定部２２４の処理の手順の一例を示すフローチャートである。 図１４は、処理実行部２２５の処理の手順の一例を示すフローチャートである。 図１５は、実施例１（電車内のサービスを実行する例）のシステム構成図である。 図１６は、実施例１の内容（電車に乗っていない状況）を示す説明図である。 図１７は、実施例１の内容（電車内のサービスの状況）を示す説明図である。 図１８は、実施例１の内容（電車に第１端末のユーザが乗った状況（その１））を示す説明図である。 図１９は、実施例１の内容（電車に第１端末のユーザが乗った状況（その２）状況）を示す説明図である。 図２０は、実施例１の内容（電車に第２端末のユーザが乗った状況）を示す説明図である。 図２１は、実施例２（バスツアーに参加する例）のシステム構成図である。 図２２は、実施例２の内容（ツアー参加というイベントの内容）を示す説明図である。 図２３は、実施例２の内容（ツアーの各参加者がバスで移動している状況）を示す説明図である。 図２４は、実施例２の内容（ツアーの各参加者がガイドとともに観光をしている状況）を示す説明図である。 図２５は、実施例におけるサーバと端末の構成例を示す説明図である。 図２６は、「入力」に関する別の一例（その１）を示す説明図である。 図２７は、「入力」に関する別の一例（その２）を示す説明図である。 図２８は、ルール登録に関する別の一例を示す説明図である。

以下に図面を参照して、本発明にかかる情報処理装置、情報処理システムおよび情報処理プログラムの実施の形態を詳細に説明する。

（実施の形態）
（情報処理システム２００の概要）
図１は、実施の形態にかかる情報処理装置、情報処理システムおよび情報処理プログラムの概要の一例を示す説明図である。

図１の左側の図において、ユーザ「甲」は、ＧＰＳ情報１０１から処理Ａを実行することによって天気・気温情報１０２を出力する。ここで、出力するとは、処理の実行結果（天気・気温情報１０２）を取得して記録することである。また、ユーザ「甲」は、ＧＰＳ情報１０１から処理Ｂを実行することによって、駅情報１０３を出力する。また、ユーザ「乙」は、ＧＰＳ情報１１１から処理Ａを実行することによって天気・気温情報１１２を出力する。また、ユーザ「丙」は、ＧＰＳ情報１２１から処理Ｂを実行することによって、駅情報１２３を出力する。

ユーザ「甲」のＧＰＳ情報１０１と、ユーザ「乙」のＧＰＳ情報１１１と、ユーザ「丙」のＧＰＳ情報１２１の内容が、それぞれ同じであっても、それぞれ、別々に処理を実行する。入力である、ＧＰＳ情報１０１とＧＰＳ情報１１１とＧＰＳ情報１２１が同じ内容であり、処理の内容も同じであることから、出力、すなわち、天気・気温情報１０２と天気・気温情報１１２とは同じ内容になり、また、駅情報１０３と駅情報１２３も同じ内容となる。

このことから、ユーザ「甲」、「乙」、「丙」の３人の中において、同じ処理Ａが２回、同じ処理Ｂが２回、それぞれ実行されていることがわかる。したがって、処理Ａが１回分と、処理Ｂが１回分だけ必要なかったともいえる。その分、リソースを無駄にしたということがいえる。

そこで、図１の右側の図に示すように、ユーザ「甲」により実行された処理Ａの出力である天気・気温情報１０２を、ユーザ「乙」の出力（天気・気温情報「１０２’」）とすることで、本来、ユーザ「乙」が実行すべき処理Ａの実行をおこなわないようにすることができる。ユーザ「甲」の出力をユーザ「乙」の出力とするために、たとえば、ユーザ「乙」の出力先に、ユーザ「甲」の出力に関する情報をコピーするようにするとよい。また、ユーザ「乙」の出力先をユーザ「甲」の出力先とするようにしてもよい。何れの場合であっても、ユーザ「乙」は処理Ａを実行しなくても、実行結果を得ることができるようになる。

同様に、ユーザ「甲」により実行された処理Ｂの出力である駅情報１０３を、ユーザ「丙」の出力（駅情報「１０３’」）とすることで、本来ユーザ「丙」が実行すべき処理Ｂの実行をおこなわないようにすることができる。

このように、同じ場所にいることがわかっている場合、別々のＧＰＳ情報であっても、同じ処理結果を得ることになるため、まとめることが可能となる。すなわち、これから同じ状況となることがわかっていて、その状況での処理を登録するときに、どの入力が同じとなるかが特定でき、処理をまとめる契機となる。

たとえば、同じ電車に乗るという状況においては、電車の移動は乗っている人に共通となり、場所も共通である（詳細な内容は、後述する実施例１において説明する）。また、バスツアーに参加するという状況においても、移動は同じになる（詳細な内容は、後述する実施例２において説明する）。

したがって、人の単位で、イベントと関数（処理）を管理する。そして、複数の人に対して、新たな処理を登録するときに、その処理の想定しているイベントや入力が、同じとなることを利用し、重複して実行される処理の削減をすることができる。

（情報処理システム２００のシステム構成）
図２は、情報処理システム２００のシステム構成の一例を示すブロック図である。図２において、情報処理システム２００は、情報処理装置２０１を備える。情報処理装置２０１は、処理を実行する際に参照および書き込みをおこなうデータ２１０を有する。また、情報処理装置２０１は、データ２１０と、ネットワークを介して接続されるように構成されてもよい。

また、情報処理装置２０１は、各種データベース（ルールデータベース（ＤＢ）２１１、処理情報データベース（ＤＢ）２１２、グループ情報データベース（ＤＢ）２１３、処理依存関係データベース（ＤＢ）２１４、データ間関係データベース（ＤＢ）２１５）を有する。また、情報処理装置２０１は、各種データベース２１１～２１５の少なくとも一つを、有しているのではなく、その代わりに、図２における図示を省略するネットワークなどを介して接続されるように構成されていてもよい。

また、情報処理装置２０１は、処理管理部２２１と、グループ管理部２２２と、ルール登録部２２３と、イベント判定部２２４と、処理実行部２２５の各構成部などを有する構成となっている。これらの各構成部２２１～２２５によって、情報処理装置２０１の制御部を構成することができる。各構成部２２１～２２５の詳細な内容については、後述する。

また、情報処理装置２０１は、図２における図示を省略するネットワークを介して、ユーザ端末装置２５１と接続されている。ここで、ユーザ端末装置２５１は、たとえば、パーソナルコンピュータ２５１ａ、タブレット端末装置２５１ｂ、スマートフォン２５１ｃなどの情報処理装置によって実現することができる。

ここで、ユーザ端末装置２５１（２５１ａ～２５１ｃ）は、図示は省略するが、ＣＰＵ、メモリ、ディスプレイ、入力装置、通信装置などを有する。このユーザ端末装置２５１によって、情報の入力、出力、通信などの各種機能を実現することができる。

（情報処理装置のハードウェア構成例）
図３は、情報処理装置２０１のハードウェア構成の一例を示すブロック図である。情報処理装置２０１の一例であるサーバ（具体的には、たとえば、後述する図１５に示すサーバ１５００や、図２１に示すサーバ２１００など）は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）３０１と、メモリ３０２と、ネットワークＩ／Ｆ（Ｉｎｔｅｒｆａｃｅ）３０３と、記録媒体Ｉ／Ｆ３０４と、記録媒体３０５と、を有する。また、各構成部３０１～３０４は、バス３００によってそれぞれ接続されている。

ここで、ＣＰＵ３０１は、情報処理装置２０１の全体の制御を司る。メモリ３０２は、たとえば、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）およびフラッシュＲＯＭなどを有する。具体的には、たとえば、フラッシュＲＯＭやＲＯＭが各種プログラムを記憶し、ＲＡＭがＣＰＵ３０１のワークエリアとして使用される。メモリ３０２に記憶されるプログラムは、ＣＰＵ３０１にロードされることで、コーディングされている処理をＣＰＵ３０１に実行させる。

ネットワークＩ／Ｆ３０３は、通信回線を通じてネットワーク３０６に接続され、ネットワーク３０６を介して他の装置（たとえば、他のサーバ、ユーザ端末装置、データベース、あるいは、他のシステム）に接続される。そして、ネットワークＩ／Ｆ３０３は、ネットワーク３０６と自装置内部とのインターフェースを司り、他の装置からのデータの入出力を制御する。ネットワークＩ／Ｆ３０３には、たとえば、モデムやＬＡＮアダプタなどを採用することができる。

記録媒体Ｉ／Ｆ３０４は、ＣＰＵ３０１の制御にしたがって記録媒体３０５に対するデータのリード／ライトを制御する。記録媒体３０５は、記録媒体Ｉ／Ｆ３０４の制御で書き込まれたデータを記憶する。記録媒体３０５としては、たとえば、磁気ディスク、光ディスクなどが挙げられる。

なお、情報処理装置２０１は、上述した構成部３０１～３０５のほかに、たとえば、図示を省略する、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）、キーボード、ポインティングデバイス、ディスプレイなどを有することにしてもよい。

（ルールＤＢ２１１の内容）
図４は、ルールＤＢ２１１のデータ構成の一例を示す説明図である。図４において、ルールＤＢ２１１は、ルール登録部２２３によって登録がおこなわれ、イベント判定部２２４が、イベントを判定する際に用いるデータベース（テーブル）である。ルールＤＢは、ユーザ毎に管理される。後述する実施例においては、端末毎にルールが登録される。

図４に示すように、ルールＤＢ２１１は、たとえば、「ユーザｉｄ」欄４０１と、「グループｉｄ」欄４０２と、「ルールｉｄ」欄４０３と、「トリガーとなるイベント」欄４０４と、「入力として扱うデータ」欄４０５と、「データ出力先」欄４０６と、「実行する処理ｉｄ」欄４０７と、「共通ルールフラグ」欄４０８と、「無効フラグ」欄４０９と、を有する。各項目欄（カラム）４０１～４０９によって形成されるフィールドに情報を記憶することで、ルールがレコードとして登録される。

ルールＤＢ２１１は、具体的には、たとえば、図３に示した記録媒体３０５などによってその機能を実現することができる。また、図３に示したネットワークＩ／Ｆ３０３が、ネットワーク３０６を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、ルールＤＢ２１１の機能を実現するようにしてもよい。

「ユーザｉｄ」欄４０１には、ユーザごとに一意に設られたｉｄを記憶する。「グループｉｄ」欄４０２には、グループごとに一意に設られたｉｄを記憶する。「ルールｉｄ」欄４０３には、ルールごとに一意に設けられたｉｄを記憶する。「トリガーとなるイベント」欄４０４には、処理のきっかけ（トリガー）となるイベントに関する情報を記憶する。トリガーとなるイベントとは、具体的には、たとえば、『ＧＰＳの情報が変化した』、『歩数が増えた』などである。また、ユーザ端末装置２５１の所定の操作などもトリガーとなるイベントになり得る。

「入力として扱うデータ」欄４０５には、入力として扱うデータを記憶する。具体的には、たとえば、ＧＰＳ情報などである。「データ出力先」欄４０６には、処理が実行された実行結果に関するデータを出力する出力先に関する情報（ファイルパスなど）を記憶する。「実行する処理ｉｄ」欄４０７には、このルールにかかる処理の処理ｉｄに関する情報を入力する。処理ｉｄについては、図５の処理情報ＤＢ２１２「処理ｉｄ」欄５０１および図７の処理依存関係ＤＢ２１４の「処理ｉｄ」欄７０１に記憶されたものと同じｉｄを用いる。

「共通ルールフラグ」欄４０８には、当該ルールが他のルールと共通化しているか否かを示すフラグを記憶する。具体的には、当該ルールが共通化されているルールである場合は、『Ｔｒｕｅ』を記憶し、共通化されていないルールである場合は、『Ｆａｌｓｅ』を記憶する。

「無効フラグ」欄４０９には、当該ルールが、そのルールにおいて実行される処理が無効化されるルールであるか否かを示すフラグを記憶する。共通化されたルールにおいて、処理を行うルールであれば無効化はされず、他のユーザのルールによって処理された結果を利用する場合には無効化される。具体的には、無効化される処理にかかるルールである場合は、『Ｔｒｕｅ』を記憶し、無効化されない処理にかかるルールである場合は、『Ｆａｌｓｅ』を記憶する。したがって、「無効フラグ」欄４０９に『Ｆａｌｓｅ』が記憶されたルールにおいては、実行する処理ｉｄにかかる処理は実行される。一方、「無効フラグ」欄４０９に『Ｔｒｕｅ』が記憶されたルールにおいては、実行する処理ｉｄにかかる処理は実行されない。

このように、ルールＤＢ２１１には、ルールごとに、トリガーとなるイベント、入力として扱うデータ、データ出力先、実行する処理ｉｄ、共通ルールフラグ、無効フラグを登録する。そして、「ルールｉｄ」を用いて、それらの各情報にアクセスすることができる。

（処理情報ＤＢ２１２の内容）
図５は、処理情報ＤＢ２１２のデータ構成の一例を示す説明図である。図５において、処理情報ＤＢ２１２は、「処理」に関する具体的な内容に関する情報について記憶するデータベースである。

図５に示すように、処理情報ＤＢ２１２は、たとえば、「処理ｉｄ」欄５０１と、「ファイルパス」欄５０２と、を有する。各項目欄（カラム）５０１、５０２によって形成されるフィールドに情報を記憶することで、処理の内容がレコードとして登録される。処理情報ＤＢ２１２は、具体的には、たとえば、図３に示した記録媒体３０５などによってその機能を実現することができる。また、図３に示したネットワークＩ／Ｆ３０３が、ネットワーク３０６を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、処理情報ＤＢ２１２の機能を実現するようにしてもよい。

「処理ｉｄ」欄５０１には、処理ごとに一意に設けられたｉｄを記憶する。「ファイルパス」欄５０２には、処理ｉｄごとに、対象となる処理のデータファイルがあるパスに関する情報を記憶する。

このように、処理情報ＤＢ２１２には、処理ごとに、ファイルパスを登録する。こうすることによって、「処理ｉｄ」を用いて、その対象となる処理のデータファイルにアクセスすることができる。

（グループ情報ＤＢ２１３の内容）
図６は、グループ情報ＤＢ２１３のデータ構成の一例を示す説明図である。図６において、グループ情報ＤＢ２１３は、グループ管理部２２２によって管理され、ルール登録部２２３が、ルールを登録する際に用いるデータベース（テーブル）である。グループ情報ＤＢ２１３には、具体的には、ユーザによって構成されるグループ情報について記憶している。

図６に示すように、グループ情報ＤＢ２１３は、たとえば、「グループｉｄ」欄６０１と、「ルールｉｄ」欄６０２と、「共通化フラグ」欄６０３と、を有する。各項目欄（カラム）６０１～６０３によって形成されるフィールドに情報を記憶することで、グループの内容がレコードとして登録される。

グループ情報ＤＢ２１３は、具体的には、たとえば、図３に示した記録媒体３０５などによってその機能を実現することができる。また、図３に示したネットワークＩ／Ｆ３０３が、ネットワーク３０６を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、グループ情報ＤＢ２１３の機能を実現するようにしてもよい。

「グループｉｄ」欄６０１には、グループごとに一意に設けられたｉｄを記憶する。「ルールｉｄ」欄６０２には、ルールごとに一意に設けられたｉｄであって、「ルールｉｄ」欄４０３に記憶されたものと同じものを所定のフィールドに記憶する。「共通化フラグ」欄６０３には、グループｉｄにかかるグループに対して、各ルールｉｄにかかるルールが、共通化できるか否かを示すフラグを記憶する。当該グループに対して、各ルールが共通化できる場合は、『Ｔｒｕｅ』を、ルールが共通化できない場合は、『Ｆａｌｓｅ』を、それぞれ「共通化フラグ」欄６０３に記憶する。

このように、グループ情報ＤＢ２１３には、グループごとに、ルールｉｄおよび共通化フラグを登録する。そして、「グループｉｄ」をキーとして、当該グループにおけるルールのうち、共通化することが可能なルールのみを抽出することができる。

（処理依存関係ＤＢ２１４の内容）
図７は、処理依存関係ＤＢ２１４のデータ構成の一例を示す説明図である。図７において、処理依存関係ＤＢ２１４は、処理管理部２２１によって管理され、ルール登録部２２３が、ルールを登録する際に用いるデータベース（テーブル）である。処理依存関係ＤＢ２１４には、具体的には、「処理」の入力・出力・外部リソース・共通化可能フラグなどの「処理」の依存関係に関する情報について記憶している。

図７に示すように、処理依存関係ＤＢ２１４は、たとえば、「処理ｉｄ」欄７０１と、「入力」欄７０２と、「出力」欄７０３と、「外部リソース」欄７０４と、「共通化可能フラグ」欄７０５と、を有する。各項目欄（カラム）７０１～７０５によって形成されるフィールドに情報を記憶することで、処理依存関係がレコードとして登録される。

処理依存関係ＤＢ２１４は、具体的には、たとえば、図３に示した記録媒体３０５などによってその機能を実現することができる。また、図３に示したネットワークＩ／Ｆ３０３が、ネットワーク３０６を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、処理依存関係ＤＢ２１４の機能を実現するようにしてもよい。

「処理ｉｄ」欄７０１には、処理ごとに一意に設けられたｉｄであって、「処理ｉｄ」欄５０１に記憶されたものと同じものを記憶する。「入力」欄７０２には、「処理ｉｄ」に対する入力に関する情報を記憶する。「出力」欄７０３には、「処理ｉｄ」に対する出力に関する情報を記憶する。「外部リソース」欄７０４には、「処理ｉｄ」に対する外部リソース２１０との関係を示す情報を記憶する。「共通化可能フラグ」欄７０５には、「処理ｉｄ」にかかる処理が共通化可能か否かの情報を記憶する。処理が共通化可能な場合は、『Ｔｒｕｅ』を、処理が共通化可能でない場合は、『Ｆａｌｓｅ』を、それぞれ「共通化可能フラグ」欄７０５に記憶する。

このように、処理依存関係ＤＢ２１４には、「処理」ごとに、入力、出力、外部リソース、共通化可能フラグを登録する。こうすることによって、「処理ｉｄ」を用いて、その対象となる処理の処理依存関係に関する情報にアクセスすることができる。

（データ間関係ＤＢ２１５の内容）
図８は、データ間関係ＤＢ２１５のデータ構成の一例を示す説明図である。図８において、データ間関係ＤＢ２１５は、各「処理」の実行結果の出力先と、その実行結果のコピー先とが登録されるデータベース（テーブル）である。

図８に示すように、データ間関係ＤＢ２１５は、たとえば、「データ出力先」欄８０１と、「コピー先」欄８０２と、を有する。各項目欄（カラム）８０１、８０２によって形成されるフィールドに情報を記憶することで、データ間関係がレコードとして登録される。データ間関係ＤＢ２１５は、具体的には、たとえば、図３に示した記録媒体３０５などによってその機能を実現することができる。また、図３に示したネットワークＩ／Ｆ３０３が、ネットワーク３０６を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、データ間関係ＤＢ２１５の機能を実現するようにしてもよい。

「データ出力先」欄８０１には、データを出力するパスに関する情報を記憶する。また、「コピー先」欄８０２には、「データ出力先」欄８０１のデータをコピーするコピー先に関する情報を記憶する。したがって、「コピー先」欄８０２に記憶されたデータ出力先を持つ無効化された処理は、処理を実行することができないので、「コピー先」欄８０２に記憶されたデータを、処理の実行結果とすることができる。

このように、データ間関係ＤＢ２１５は、共通化され、無効化された処理の実行結果を担保するために、そのデータ出力先をコピー先としている。また、反対に、無効化された処理のデータ出力先を、処理を実行して実行結果を出力している出力先にリンクし、当該出力先に記憶されているデータを、自身の出力先のデータとするようにしてもよい。

（情報処理システム２００の機能的構成例）
図９は、情報処理システム２００の機能的構成の一例を示すブロック図である。図９において、情報処理装置２０１の処理管理部２２１は、処理ファイルと処理の依存関係を渡され、処理情報ＤＢ２１２と処理依存関係ＤＢ２１４に処理の登録をおこなう。処理管理部２２１は、具体的には、たとえば、図３に示した、メモリ３０２などに記憶されたプログラムをＣＰＵ３０１に実行させることによって、また、ネットワークＩ／Ｆ３０３などによって、その機能を実現することができる。

情報処理装置２０１のグループ管理部２２２は、人単位でルールをまとめて管理するためのグループを作成し、グループ情報ＤＢ２１３へ登録する。グループ管理部２２２は、具体的には、たとえば、図３に示した、メモリ３０２などに記憶されたプログラムをＣＰＵ３０１に実行させることによって、また、ネットワークＩ／Ｆ３０３などによって、その機能を実現することができる。

情報処理装置２０１のルール登録部２２３は、ルール登録の処理をおこなう。指定されたグループの情報をグループ情報ＤＢ２１３から取得し、登録するルールが共通化可能か否かを処理依存関係ＤＢ２１４を参照して判断し、共通化した内容をルールＤＢ２１１やデータ間関係ＤＢ２１５に登録する。ルール登録部２２３は、具体的には、たとえば、図３に示した、メモリ３０２などに記憶されたプログラムをＣＰＵ３０１に実行させることによって、また、ネットワークＩ／Ｆ３０３などによって、その機能を実現することができる。

イベント判定部２２４は、ルールＤＢ２１１のイベントのトリガーに基づき、イベント判定の処理をおこなう。イベント判定部２２４は、具体的には、たとえば、図３に示した、メモリ３０２などに記憶されたプログラムをＣＰＵ３０１に実行させることによって、また、ネットワークＩ／Ｆ３０３などによって、その機能を実現することができる。

処理実行部２２５は、イベント判定部２２４によりトリガーされたルールを引数として処理をおこなう。処理実行部２２５は、具体的には、たとえば、図３に示した、メモリ３０２などに記憶されたプログラムをＣＰＵ３０１に実行させることによって、また、ネットワークＩ／Ｆ３０３などによって、その機能を実現することができる。

（処理管理部２２１の処理の内容）
図１０は、処理管理部２２１の処理の手順の一例を示すフローチャートである。図１０のフローチャートにおいて、処理管理部２２１は、まず、各「処理」に処理ｉｄを割り振る（ステップＳ１００１）。そして、処理ｉｄが割り振れられた処理ファイルを処理情報ＤＢ２１２に保存する（ステップＳ１００２）。具体的には、図５に示したように、処理ｉｄに対して、処理ファイルを保存している場所を示すファイルパスを登録する。

処理管理部２２１は、つぎに、各「処理」の依存関係に関する情報（「入力」、「出力」、「外部リソース」、「共通化可能フラグ」）を処理ｉｄと紐付けする（ステップＳ１００３）。そして、処理ｉｄごとに、各「処理」の依存関係に関する情報を処理依存関係ＤＢ２１４に保存する（ステップＳ１００４）。

その後、処理ｉｄを返して（ステップＳ１００５）、一連の処理を終了する。処理管理部２２１は、これらの一連の処理を、新たな「処理」が発生するたびにおこなう。処理情報ＤＢ２１２および処理依存関係ＤＢ２１４は、このようにして作成され、また、更新される。

（グループ管理部２２２の処理の内容）
図１１は、グループ管理部２２２の処理の手順の一例を示すフローチャートである。図１１のフローチャートにおいて、グループ管理部２２２は、まず、各「グループ情報」にグループｉｄを割り振る（ステップＳ１１０１）。そして、グループｉｄが割り振れられたグループ情報をグループ情報ＤＢ２１３に保存する（ステップＳ１１０２）。

その後、グループｉｄを返して（ステップＳ１１０３）、一連の処理を終了する。グループ管理部２２２は、これらの一連の処理を、新たな「グループ情報」が発生するたびにおこなう。グループ情報ＤＢ２１３は、このようにして作成され、また、更新される。

（ルール登録部２２３の処理の内容）
図１２は、ルール登録部２２３の処理の手順の一例を示すフローチャートである。図１２のフローチャートにおいて、ルール登録部２２３は、指定されたユーザに対して指定されたグループのルールの登録をするために、まず、グループ情報ＤＢ２１３に登録されている指定されたグループにおけるルールｉｄと共通化フラグを取得する（ステップＳ１２０１）。グループに対するルールを順番に処理する。具体的には、たとえば、図６のグループ情報ＤＢ２１３において、「グループｉｄ」＝『Ｇ３』に着目し、『Ｇ３』のグループから「ルールｉｄ」＝『Ｒ３』、『Ｒ４』、『Ｒ５』の３つのルールを順に処理する。

ルール登録部２２３は、グループ情報のルールがすべて処理された場合（ステップＳ１２０２：Ｙｅｓ）は終了する。ルール登録部２２３は、処理対象のルールｉｄと共通化フラグがある場合（ステップＳ１２０２：Ｎｏ）は、ステップＳ１２０３へ処理を移行する。

ルール登録部２２３は、処理対象の共通化フラグが『Ｔｒｕｅ』かチェックする（ステップＳ１２０３）。ここで、Ｔｒｕｅである場合（ステップＳ１２０３：Ｙｅｓ）は、Ｓ１２０４へ処理を移行する。一方、Ｆａｌｓｅである場合（ステップＳ１２０３：Ｎｏ）は、Ｓ１２０９へ処理を移行する。

ルール登録部２２３は、ルールＤＢ２１１から、指定されたグループｉｄと同じグループｉｄの処理対象であるルールｉｄの他ユーザのルールを取得する（ステップＳ１２０４）。

ルール登録部２２３は、ルールが存在しているか、すなわち、ルールが取得できたか否かを判断する（ステップＳ１２０５）。ここで、ルールが取得できた場合（ステップＳ１２０５：Ｙｅｓ）は、ステップＳ１２０６へ処理を移行する。一方、ルールが取得できなかった場合（ステップＳ１２０５：Ｎｏ）は、ステップＳ１２０８へ処理を移行する。

ルール登録部２２３は、処理対象のルールｉｄ４０３のルールを取得する。ルールは、グループ情報ＤＢ２１３に保存されていてもいいし、別ＤＢで管理されていてもよい。ルールのデータ構成は、ルールＤＢ２１１の、グループｉｄ４０２、共通ルールフラグ４０８、無効フラグ４０９を含まない構成である。すなわち、ユーザｉｄ４０１、ルールｉｄ４０３、トリガーとなるイベント４０４、入力として扱うデータ４０５、データ出力先４０６、実行する処理ｉｄ４０７を構成とする。

そして、ルール登録部２２３は、取得したルールの共通ルールフラグをＴｒｕｅにし、無効フラグをＴｒｕｅにして、指定されたユーザとグループと紐付けて、そのルールをルールＤＢ２１１に登録する（ステップＳ１２０６）。そして、ルール登録部２２３は、ステップ１２０４で取得したルールのうち、共通ルールフラグがＴｒｕｅかつ無効フラグがＦａｌｓｅのルールのデータ出力先と、Ｓ１２０６で登録したルールのデータ出力先を関連付けて、データ間関係ＤＢ２１５に保存する（ステップＳ１２０７）。その後、ルール登録部２２３は、処理対象のグループの次のルールの登録をおこなうために、ステップＳ１２０１へ処理を移行する。

一方、ルール登録部２２３は、ステップＳ１２０５：Ｎｏの場合、処理対象のルールｉｄのルールを取得する。そして、取得したルールの共通ルールフラグをＴｒｕｅにし、無効フラグをＦａｌｓｅにして、指定されたユーザとグループと紐付けて、そのルールをルールＤＢ２１１に登録する（ステップＳ１２０８）。その後、ステップＳ１２０１へ処理を移行する。

ステップＳ１２０３において、ルール登録部２２３は、グループ情報の処理対象のルールの共通化フラグがＦａｌｓｅの場合（ステップＳ１２０３：Ｎｏ）、ルールＤＢ２１１から、指定されたユーザのルールを取得する（ステップＳ１２０９）。

つぎに、ルール登録部２２３は、取得したルールのうち、入力として扱うデータが同じで共通ルールフラグがＴｒｕｅのルールがあるかチェックする（ステップＳ１２１０）。ここで、ルールが存在しない場合（ステップＳ１２１０：Ｎｏ）は、ステップＳ１２０１へ処理を移行する。一方、ルールが存在する場合（ステップＳ１２１０：Ｙｅｓ）は、ステップＳ１２１１へ処理を移行する。

ルール登録部２２３は、グループ情報ＤＢ２１３から、ルールのグループｉｄとルールｉｄから、共通化フラグを取得する（ステップＳ１２１１）。

ルール登録部２２３は、取得した共通化フラグをチェックし、共通化フラグがＴｒｕｅか否かを判断する（ステップＳ１２１２）。ここで、共通化フラグがＴｒｕｅである場合（ステップＳ１２１２：Ｙｅｓ）は、ステップＳ１２１３へ処理を移行する。一方、共通化フラグがＦａｌｓｅである場合（ステップＳ１２１２：Ｎｏ）は、ステップＳ１２０１へ処理を移行する。

ルール登録部２２３は、処理対象のルールｉｄのルールを取得する。そして、取得したルールの共通ルールフラグをＴｒｕｅ、無効フラグをＦａｌｓｅにして、指定されたユーザとグループと紐付けてルールＤＢ２１１に登録する（ステップＳ１２１３）。

また、ルール登録部２２３は、同じグループの他ユーザのルールｉｄのルールに対して、共通ルールフラグをＴｒｕｅ、無効フラグをＴｒｕｅにし、それぞれ、処理対象のルールの出力先と、それら他ユーザのルールの出力先を関連付けして、データ間関係ＤＢ２１５に保存する（ステップＳ１２１４）。

以上、ルールを登録するときの処理について述べたが、詳細は省略するが、ルールを解除するときに、共通化したルールの解除をおこなうことも、上述した処理を逆におこなうことで可能となる。たとえば、共通ルールフラグがＴｒｕｅかつ無効フラグがＦａｌｓｅのルールが解除されるときは、同じグループの他ユーザのルールを検索し、いずれかのルールの無効フラグをＴｒｕｅに変更する。グループ情報の共通化フラグがＦａｌｓｅのルールについては、他ユーザのルールの共通ルールフラグをＦａｌｓｅにする。これは、共通化を解除することを意味する。ここで、さらに、他ユーザのルールについて共通化可能かどうかのチェックするような構成も可能である。

（イベント判定部２２４の処理の内容）
図１３は、イベント判定部２２４の処理の手順の一例を示すフローチャートである。図１３のフローチャートにおいて、イベント判定部２２４は、トリガーとなるイベントがあったか否かを判断する（ステップＳ１３０１）。トリガーとなるイベントとしてはいろいろな内容があるが、具体的には、たとえば、入力データが更新されたことをイベントの例とした場合に、入力データの更新を受けて、入力データ更新をイベントとすることができる。

ステップＳ１３０１において、トリガーとなるイベントがあるのを待って（ステップＳ１３０１：Ｎｏ）、トリガーとなるイベントがあった場合（ステップＳ１３０１：Ｙｅｓ）は、当該イベントにかかるルールを取得する（ステップＳ１３０２）。具体的には、たとえば、ルールＤＢ２１１の「トリガーとなるイベント」欄４０４に該当するイベントにかかるルールを抽出することによって取得することができる。

つぎに、取得したルールに無効フラグがセットされているか否かを判断する（ステップＳ１３０３）。具体的には、たとえば、ルールＤＢ２１１の「無効フラグ」欄４０９＝『Ｔｒｕｅ』となっているか否かによって判断することができる。ここで、無効フラグがセットされている場合（ステップＳ１３０３：Ｙｅｓ）は、何もせずに一連の処理を終了する。したがって、当該ルールにかかる「処理」は無効化されているため、実行されない（後述するが、出力先にはすでに実行結果がコピーされているため、実行する必要がない）。

一方、ステップＳ１３０３において、取得したルールに無効フラグがセットされていない場合（ステップＳ１３０３：Ｎｏ）は、当該取得したルールを処理実行部２２５へ渡す。

（処理実行部２２５の処理の内容）
図１４は、処理実行部２２５の処理の手順の一例を示すフローチャートである。図１４のフローチャートにおいて、処理実行部２２５は、イベント判定部２２４から受け取ったルールから「（実行する）処理ｉｄ」を抽出する（ステップＳ１４０１）。具体的には、たとえば、ルールＤＢ２１１の「実行する処理ｉｄ」４０７から当該取得したルールに関連付けられた処理ｉｄを抽出することができる。

ステップＳ１４０１において、「処理ｉｄ」に基づいて、処理情報ＤＢ２１２から実行する処理のファイルを取得する（ステップＳ１４０２）。

つぎに、「入力」をデータ２１０から取得する（ステップＳ１４０３）。つぎに、取得した「入力」に基づいて、処理を実行する（ステップＳ１４０４）。具体的には、たとえば、処理ｉｄが「Ｐ１」である場合に、入力である「ＧＰＳ（緯度経度情報）」をデータ２１０から取得する。そして、「ＧＰＳ（緯度経度情報）」から、当該緯度経度情報が示す位置における「天気」に関する情報を導き出す。これが、処理ｉｄ＝「Ｐ１」の処理を実行することである。「ＧＰＳ」から「天気」へと導き出すのにＷｅｂサービスなどの外部リソースを参照しておこなうことが可能である。

そして、実行結果をデータの出力先に保存する（ステップＳ１４０５）。具体的には、たとえば、「天気」に関する情報（晴れ、雨、曇など）を実行結果として、データの出力先である「／グループ１／Ａ１／ｒｅｓｕｌｔ」に記憶する。この例では、グループ１の
Ａ１ユーザの処理結果を意味している。出力先の表し方は、この例に限定されるものではない。

つぎに、データ間関係ＤＢ２１５を参照する（ステップＳ１４０６）。そして、データ間関係ＤＢ２１５に、ステップＳ１４０５において、実行結果を保存したデータの出力先が登録されているか否かを判断する（ステップＳ１４０７）。ここで、データ間関係ＤＢ２１５に、実行結果を保存したデータの出力先が登録されていない場合（ステップＳ１４０７：Ｎｏ）は、何もせずに、一連の処理を終了する。

一方、データ間関係ＤＢ２１５に、実行結果を保存したデータの出力先が登録されている場合（ステップＳ１４０７：Ｙｅｓ）は、コピー先の出力先に実行結果をコピーする（ステップＳ１４０８）。具体的には、たとえば、図８に示したように、データの出力先「／グループ１／Ａ１／ｒｅｓｕｌｔ」が登録されているので、そのコピー先である「／グループ２／Ａ１／ｒｅｓｕｌｔ」および「／グループ２／Ｂ１／ｒｅｓｕｌｔ」にそれぞれ、「天気」に関する情報の実行結果をコピーする。

あるいは、ステップＳ１４０８において、コピー先の出力先に実行結果をコピーする代わりに、コピー先の出力先に、実行結果の出力先のパスを記憶して、リンクを張り、リンクの形で参照させるようにしてもよい。このようにすることによって、無効処理においても実行結果を取得することができる。処理結果に対してその都度リンクを張る以外に、ルール登録部２２３において、データ間関係ＤＢ２１５に出力先を関連付けして保存する際にリンクを張ってもよい。

これにより、一連の処理を終了する。このようにすることによって、図１３のフローチャートにおいて、無効フラグがセットされている場合（ステップＳ１３０３：Ｙｅｓ）であっても、「処理」を実行しなくても、実行結果を取得することができる。

以上説明したように、本実施の形態によれば、イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、同じ入力に関する情報を使用する複数の同じ処理（共通ルールフラグ：『Ｔｒｕｅ』）がある場合に、当該複数の同じ処理のうちの一つ（無効フラグ：『Ｆａｌｓｅ』）のみを実行するので、無駄となる処理を削減することができる。

また、本実施の形態によれば、複数の同じ処理のうちの実行される処理以外の処理（無効フラグ：『Ｔｒｕｅ』）について、当該処理の実行を無効化するので、無駄となる処理を実行しなくて済む。

また、本実施の形態によれば、複数の処理のうちの一つのみを実行する有効処理（無効フラグ：『Ｆａｌｓｅ』）の実行結果を、無効化された無効処理（無効フラグ：『Ｔｒｕｅ』）の実行結果とするので、無効化された無効化処理であっても、実行結果を出力（提供）することができる。

また、本実施の形態によれば、無効処理（無効フラグ：『Ｔｒｕｅ』）の実行結果の出力先に、有効処理（無効フラグ：『Ｆａｌｓｅ』）の実行結果を記憶する。あたかも、無効処理にかかる処理を実行して、実行結果が得られたのと同じ効果が得られる。

また、本実施の形態によれば、無効処理（無効フラグ：『Ｔｒｕｅ』）の実行結果の出力先に、有効処理（無効フラグ：『Ｆａｌｓｅ』）の実行結果の出力先に関する情報を記憶するので、同様に、あたかも、無効処理にかかる処理を実行して、実行結果が得られたのと同じ効果が得られる。

また、本実施の形態によれば、グループ内において、同じ入力に関する情報を使用する複数の同じ処理（共通ルールフラグ：『Ｔｒｕｅ』）がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つ（無効フラグ：『Ｆａｌｓｅ』）のみを実行するので、グループ内において、無駄となる処理を削減することができる。

また、本実施の形態によれば、グループ内における、前記複数の同じ処理のうちの実行される処理以外の処理（無効フラグ：『Ｔｒｕｅ』）について、当該処理の実行を無効化するので、グループ内において、無駄となる処理を実行しなくて済む。

このように、本実施の形態によれば、重複する処理の削減を図り、リソースの節約を図ることができる。

（実施例１）
つぎに、実施例（実施例１）について説明する。図１５～図２０は、電車内のサービスを実行する例である。図１５は、実施例１のシステム構成図である。図１５において、電車内のサービスを実現するシステムは、情報処理装置２０１の一例であるサーバ１５００と、端末装置（第１端末１５０１、第２端末１５０２、・・・）と、電車１５０３とから構成され、それぞれがネットワーク１５５０によって接続されている。第１端末１５０１と、第２端末１５０２は、ＧＰＳ情報を取得する機能と、ビーコンを受信する機能とを、有している。また、電車１５０３は、ＧＰＳ情報を取得する機能と、ビーコンを発信する機能と、を有している。

図１６は、第１端末１５０１および第２端末１５０２の各ユーザがいずれも電車１５０３に乗っていない状況を示している。図１６において、第１端末１５０１のユーザは状況に関係なく、天気サービスを利用している。サーバ１５００は、１６０１に示すように、第１端末１５０１のＧＰＳ情報を受けて、処理Ａを実行して、その場の天気を通知（出力）する。同様に、１６０２に示すように、第２端末１５０２のＧＰＳ情報を受けて、処理Ａを実行して、その場の天気を通知（出力）する。

このような状況では、第１端末１５０１の処理Ａと、第２端末１５０２の処理Ａはまとめることができない。したがって、第１端末１５０１の処理Ａと、第２端末１５０２の処理Ａとは、同じ処理であっても、それぞれ、別個に実行されることになる。

図１７は、電車１５０３内におけるサービスの状況を示している。図１７において、サーバ１５００は、１７０１に示すように、電車１５０３のＧＰＳ情報を受けて、処理Ｂを実行して、駅情報を通知（出力）する。

図１８および図１９は、第１端末１５０１のユーザが、電車１５０３に乗り込んだ状況を示している。図１８において、第１端末１５０１において、第１端末１５０１のビーコンを受信する機能が、電車１５０３のビーコンを発信する機能によって発信されたビーコンを検知して、電車１５０３内のサービスが追加される。図１８は、本案を実施しない場合のサービス追加を示している。１８０１が電車内サービスとして第１端末に追加されている。図１９に、本案を実施した場合のサービス追加を示している。

具体的には、たとえば、第１端末１５０１が電車１５０３のビーコンを検知したことを、ネットワーク１５５０を介して、サーバ１５００へ伝える。これにより、サーバ１５００は、電車内サービスに対して登録されているグループ情報をグループ情報ＤＢ２１３から取得し、第１端末用に取得したグループを指定してルール登録部２２３にルール登録を依頼する。電車内ではＧＰＳ情報は同じになることから、１７０１はまとめることが可能なルールであり、１９０１に示すように、第１端末１５０１に電車内サービスを追加することができる。

そして、図１９において、電車１５０３内（すなわち、ビーコンを検知している間）は、第１端末１５０１のＧＰＳ情報は電車１５０３のＧＰＳ情報と同じになるため、処理Ｂを統合することができる。具体的には、たとえば、サーバ１５００は、１９０１に示すように、入力であるＧＰＳ情報を、１７０１のＧＰＳ情報からコピーしてくる。ＧＰＳ情報の変更により、１９０１のルールはトリガーされるが、１７０１と共通化されているため処理はされない。出力である駅情報は１７０１の処理実行により出力がコピーされる。したがって、１９０１において、処理Ｂがおこなわれず、結果（駅情報）のみが共有されることになる。これにより、処理Ｂを実行するために必要なリソースを削減することができるようになる。

図２０は、さらに、第１端末１５０１のユーザのみならず、第２端末１５０２のユーザが、電車１５０３に乗り込んだ状況を示している。図２０において、電車１５０３内（ビーコン検知している間）では、第１端末１５０１のＧＰＳ情報も、第２端末１５０２のＧＰＳ情報も、電車１５０３のＧＰＳ情報と同じになるため、１９０１および２００１に示すように、第１端末１５０１および第２端末１５０２の処理Ｂを電車１５０３の処理Ｂに統合することができる。

さらに、１６０１および２００２に示すように、第１端末１５０１のＧＰＳ情報と、第２端末１５０２のＧＰＳ情報とが同じなため、第１端末１５０１の処理Ａと第２端末１５０２の処理Ａも統合することができる。このように、図２０に示すように、処理３つ分のリソースを削減することができるようになる。

（実施例２）
つぎに、別の実施例（実施例２）について説明する。図２１～図２４は、バスツアーに参加しているという状況における処理をまとめる例である。図２１は、実施例２のシステム構成図である。

図２１において、バスツアーのサービスを実現するシステムは、情報処理装置２０１の一例であるサーバ２１００と、端末装置（第１端末２１０１、第２端末２１０２、・・・）と、ツアーのガイドが使用するガイド端末２１０３と、バス２１０４とから構成され、それぞれがネットワーク２１５０によって接続されている。第１端末２１０１と、第２端末２１０２は、実施例１と同様に、ＧＰＳ情報を取得する機能と、ビーコンを受信する機能とを、有している。また、ガイド端末２１０３およびバス２１０４は、ＧＰＳ情報を取得する機能と、ビーコンを発信する機能と、を有している。

図２２は、ツアー参加というイベントの内容を示す説明図である。図２２において、ツアーＡに参加するのは、第１端末２１０１～第８端末２１０８の各ユーザで、全８名である。また、ツアーＢに参加するのは、第１０端末２１１０～第１２端末２１１２の各ユーザで、全３名である。

ツアーＡに参加する第１端末２１０１～第８端末２１０８には、ツアーＡ用サービスが登録される。また、同様に、ツアーＢに参加する第１０端末２１１０～第１２端末２１１２には、ツアーＢ用サービスが登録される。

図２３は、ツアーの各参加者がバスで移動している状況を示している。図２３において、第１端末２１０１～第８端末２１０８の各ユーザはバスＡ２１２１に乗車している。第１端末２１０１～第８端末２１０８の各ユーザがバスＡ２１２１に乗車していることは、バスＡ２１２１のビーコンを発信する機能によって発信されたビーコンを、第１端末２１０１～第８端末２１０８のビーコンを受信する機能が検知することによってわかる。

ここで、ツアーＡの代表として第１端末２１０１を設定した場合に、第１端末２１０１にのみツアーＡ用のサービスにかかる処理をおこなわせる。そして、他の端末（第２端末２１０２～第８端末２１０８）については、当該サービスにかかる処理を無効化する。そして、第１端末２１０１の出力を他の端末（第２端末２１０２～第８端末２１０８）にそれぞれコピーすることで、当該サービスの提供を受けることができる。

また、第１０端末２１１０～第１２端末２１１２の各ユーザはバスＢ２１２２に乗車している。第１０端末２１１０～第１２端末２１１２の各ユーザがバスＢ２１２２に乗車していることは、バスＢ２１２２のビーコンを発信する機能によって発信されたビーコンを、第１０端末２１１０～第１２端末２１１２のビーコンを受信する機能が検知することによってわかる。

ここで、ツアーＢの代表として第１０端末２１１０を設定した場合に、第１０端末２１１０にのみツアーＢ用のサービスにかかる処理をおこなわせる。そして、他の端末（第１１端末２１１１および第１２端末２１１２）については、当該サービスにかかる処理を無効化する。そして、第１０端末２１１０の出力を他の端末（第１１端末２１１１および第１２端末２１１２）にそれぞれコピーすることで、当該サービスの提供を受けることができる。

このように、ツアーＡの代表として第１端末２１０１を設定して、第１端末２１０１にのみツアーＡ用のサービスにかかる処理をおこなわせることによって、第１端末２１０１以外の他の端末装置（第２端末２１０２～第８端末２１０８）が、ツアーＡ用のサービスにかかる処理をおこなわなくてもよく、その分、処理を削減することができる。また、ツアーＢの代表として第１０端末２１１０を設定して、第１０端末２１１０にのみツアーＢ用のサービスにかかる処理をおこなわせることによって、第１０端末２１１０以外の他の端末装置（第１１端末２１１１および第１２端末２１１２）が、ツアーＢ用のサービスにかかる処理をおこなわなくてもよく、その分、処理を削減することができる。

図２４は、ツアーの各参加者がそれぞれガイドとともに観光をしている状況を示している。図２４に示すように、ツアーＡに参加しているユーザのうち、第１端末２１０１～第５端末２１０５の各ユーザは、第１ガイド端末２４１１のガイドとともに観光をしていることがわかる。一方、ツアーＡに参加しているユーザのうち、第６端末２１０６～第８端末２１０８の各ユーザと、ツアーＢに参加している第１０端末２１１０～第１２端末２１１２の各ユーザは、第２ガイド端末２４１２のガイドとともに観光をしていることがわかる。

この状況において、第１ガイド端末２４２１のガイドとともに観光をしているユーザに対しては、ツアーＡの代表として第１端末２１０１を設定して、第１端末２１０１にのみツアーＡ用のサービスにかかる処理をおこなわせる。そして、他の端末（第２端末２１０２～第５端末２１０５）については、当該サービスにかかる処理を無効化する。そして、第１端末２１０１の出力を他の端末（第２端末２１０２～第５端末２１０５）にそれぞれコピーすることで、当該サービスを享受することができる。

また、第２ガイド端末２４２２のガイドとともに観光をしているユーザに対しては、ツアーＡの代表として第６端末２１０６を設定して、第６端末２１０６にのみツアーＡ用のサービスにかかる処理をおこなわせる。そして、他の端末（第７端末２１０７および第８端末２１０８）については、当該サービスにかかる処理を無効化する。そして、第６端末２１０６の出力を他の端末（第７端末２１０７および第８端末２１０８）にそれぞれコピーすることで、当該サービスを享受することができる。

ツアーＢの代表として第１０端末２１１０を設定して、第１０端末にのみツアーＢ用のサービスにかかる処理を行わせる。そして、他の端末（第１１端末２１１１および第１２端末２１１２）については、当該サービスにかかる処理を無効化する。そして、第１０端末２１１０の出力を他の端末（第１１端末２１１１および第１２端末２１１２）にそれぞれコピーすることで、当該サービスを享受することができる。

このように、各ユーザは、異なるグループに参加することによって、それぞれ、各処理の共通化の態様が変化することがわかる。

図２５は、実施例におけるサーバと端末の構成例を示す説明図である。図２５において、サーバ２５００は、センサー情報受信部２５０１と、サービス登録情報記憶部２５０２と、サービス情報記憶部２５０３と、サービス提供部２５０４と、を備える。また、端末２５１０は、監視センサー情報記憶部２５１１と、センサー通知部２５１２と、通知受信部２５１３と、を備える。

端末２５１０は、監視センサー情報記憶部２５１１において、監視するセンサー情報を記憶し、センサー通知部２５１２が、センサー変化時にサーバ２５００へ、センサー情報を伝える。サーバ２５００は、サービス登録情報記憶部２５０２において、端末２５１０ごとにサービス登録情報を記憶する。

そして、センサー情報受信部２５０１が、端末２５１０からのセンサー情報を受信して、受信したセンサー情報に対応するサービスに登録していれば、端末向けにサービスを開始する。サービスを開始するとは、そのサービスに対応するグループを指定して、端末２５１０向けのルールを登録することを示している。サービスにて提供する情報が、サービス情報記憶部２５０３に記憶されていれば、サービス提供部２５０４が、端末２５１０へ通知情報を送信する。端末２５１０の通知受信部２５１３は、その通知情報を受信する。サービス情報記憶部２５０３にはデータ２１０の場所が登録されており、その場所に変化があったときに、サービス提供部２５０４が端末２５１０へデータを送信してもよい。また、変化があったときに通知し、データは端末２５１０から、サーバ２５００のデータ２１０を参照してもよい。

具体的には、たとえば、ツアーＡを申し込むと、以下のような情報が登録される。（１）『ツアーサービス』、（２）『バス内サービス』、（３）『ガイド観光サービス』である。そして、サービス登録情報記憶部２５０２に記憶されるサービス登録情報は、それぞれ、（１）『ツアーサービス：なし』、（２）『バス内サービス：バスＡ』、（３）『ガイド観光サービス：第１ガイド』である。このように、サービス登録情報記憶部２５０２に記憶されるサービス登録情報は、各センサー情報に対して、サービスが利用可能かについての情報を記憶する。

また、監視センサー情報としては、監視するセンサーを指定することもできる。たとえば、ＧＰＳ、ビーコンのようにデバイスを指定するようにしてもよい。この場合は、センサーからのデータはすべて、サーバ２５００に送信し、サーバ２５００側で取捨選択するようにしてもよい。また、範囲を限定する情報とすることも可能である。ＧＰＳの範囲や、ビーコンのＵＵＩＤ（Ｕｎｉｖｅｒｓａｌｌｙ Ｕｎｉｑｕｅ Ｉｄｅｎｔｉｆｉｅｒ）など、端末側で判断をおこない、合致する場合のみサーバ２５００へ送信するようにしてもよい。

そして、各センサー情報を受信した場合に、サービスが利用可能な場合には、端末２５１０に対して、そのセンサー情報に対応するサービスを開始することができる。このように、センサー情報をきっかけとして、サービスの提供を可能とする。

（「入力」に関する別の例）
図２６および図２７は、「入力」に関する別の一例を示す説明図である。図２６において、上側の図の上段は、ＧＰＳ２６０１から住所２６０２へ変換し、そこから、天気・気温２６０３を出力している。一方、上側の図の下段は、ＧＰＳ２６０１の代わりにｉＢｅａｃｏｎ２６１１から住所２６１２へ変換し、そこから、駅情報２６１３を出力している。

ここで、住所２６０２と住所２６１２とは、同じ情報であることに着目し、下側の図に示すように、ＧＰＳ２６０１から住所２６０２への変換の代わりに、ｉＢｅａｃｏｎ２６１１から住所２６１２への変換を利用し、その住所２６１２から天気・気温２６０３を出力することができる。このように、「入力」の意味を定義しておくことで、サービスごとの入力手段の違いを吸収することができる。このような入力の代替をサービス追加時におこなうことで、より共通化を図ることができる。

また、図２７の上側の図において、「入力」が、たとえば時刻のように周期的な場合を示している。具体的には、左側は、「入力」が『３０分毎』２７０２であるのに対して、右側は、「入力」が『１５分毎』２７１２である。その他の「入力」２７０１、２７１１については同じである。この場合に、下側の図に示すように、『３０分毎』２７０２と『１５分毎』２７１２を別々の「入力」とせずに、一番短い周期（「１５分」）で共通化する。これにより、処理を共通化することで、入力２７０１および２７０２とし出力２７０３とする処理をおこなわなくて済み、その分、処理を削減することができる。

図２８は、ルール登録に関する別の一例を示す説明図である。図２８において、上述したルールに基づいて共通化を図ると、グループ２８０１とグループ２８０２の二つのグループで第１の共通化を図る。また、それとは別に、グループ２８０２とグループ２８０３とグループ２８０４の三つのグループで第２共通化を図ることができたとする。その場合、それぞれ共通化したグループの中に、共通するグループ２８０２が含まれていることがわかる。その場合に、第１の共通化と第２の共通化をさらに共通化し、四つで共通化することもできる。

これにより、第１の共通化における処理と、第２の共通化における処理を一つの処理でおこなうことができる。このように、すでにルール登録されている場合に、入力が同じとなるルールが登録されたときは、ルール登録時の影響範囲を広げて共通化することができるため、その分の処理をさらに削減することができる。

なお、本実施の形態で説明した情報処理方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。情報処理プログラムは、ハードディスク、フレキシブルディスク、ＣＤ（Ｃｏｍｐａｃｔ Ｄｉｓｃ）－ＲＯＭ、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ Ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、フラッシュメモリ、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、情報処理プログラムは、インターネットなどのネットワークを介して配布してもよい。

上述した実施の形態に関し、さらに以下の付記を開示する。

（付記１）イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、
制御部を有することを特徴とする情報処理装置。

（付記２）前記制御部は、前記複数の同じ処理のうちの実行される処理以外の処理について、当該処理の実行を無効化することを特徴とする付記１に記載の情報処理装置。

（付記３）前記制御部は、前記複数の同じ処理のうちの一つのみを実行する有効処理の実行結果を、前記無効化された無効処理の実行結果とすることを特徴とする付記２に記載の情報処理装置。

（付記４）前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果を記憶することを特徴とする付記３に記載の情報処理装置。

（付記５）前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果の出力先に関する情報を記憶することを特徴とする付記３に記載の情報処理装置。

（付記６）前記制御部は、グループ内において、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行することを特徴とする付記１～５のいずれか一つに記載の情報処理装置。

（付記７）前記制御部は、前記グループ内における、前記複数の同じ処理のうちの実行される処理以外の処理について、当該処理の実行を無効化することを特徴とする付記６に記載の情報処理装置。

（付記８）情報処理装置と端末装置とを有する情報処理システムであって、
前記情報処理装置は、
イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を前記端末装置へ提供するにあたり、
前記端末装置からの、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、
ことを特徴とする情報処理システム。

（付記９）イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。

２００ 情報処理システム
２０１ 情報処理装置
２１０ データ（外部リソース）
２１１ ルールＤＢ
２１２ 処理情報ＤＢ
２１３ グループ情報ＤＢ
２１４ 処理依存関係ＤＢ
２１５ データ間関係ＤＢ
２２１ 処理管理部
２２２ グループ管理部
２２３ ルール登録部
２２４ イベント判定部
２２５ 処理実行部
２５１（２５１ａ～２５１ｃ） ユーザ端末装置

Claims (7)

1. イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
   複数のユーザから構成され、所定の条件に基づいて当該ユーザが登録しているグループ内において、当該ユーザごとに、当該所定の条件に関連する、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行する、
   制御部を有することを特徴とする情報処理装置。
2. 前記制御部は、前記複数の同じ処理のうちの実行される処理以外の処理について、処理の実行を無効化することを特徴とする請求項１に記載の情報処理装置。
3. 前記制御部は、前記複数の同じ処理のうちの一つのみを実行する有効処理の実行結果を、前記無効化された無効処理の実行結果とすることを特徴とする請求項２に記載の情報処理装置。
4. 前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果を記憶することを特徴とする請求項３に記載の情報処理装置。
5. 前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果の出力先に関する情報を記憶することを特徴とする請求項３に記載の情報処理装置。
6. 情報処理装置と端末装置とを有する情報処理システムであって、
   前記情報処理装置は、
   イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を前記端末装置へ提供するにあたり、
   複数のユーザから構成され、所定の条件に基づいて当該ユーザが登録しているグループ内において、当該ユーザごとに、前記端末装置からの、当該所定の条件に関連する、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行する、
   ことを特徴とする情報処理システム。
7. イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
   複数のユーザから構成され、所定の条件に基づいて当該ユーザが登録しているグループ内において、当該ユーザごとに、当該所定の条件に関連する、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行する、
   処理をコンピュータに実行させることを特徴とする情報処理プログラム。

Images