IP Force 特許公報掲載プロジェクト 2022.1.31 β版

知財求人 - 知財ポータルサイト「IP Force」

▶ 富士通株式会社の特許一覧

特許7225554情報処理装置、情報処理システムおよび情報処理プログラム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-02-13
(45)【発行日】2023-02-21
(54)【発明の名称】情報処理装置、情報処理システムおよび情報処理プログラム
(51)【国際特許分類】
   H04L 67/02 20220101AFI20230214BHJP
【FI】
H04L67/02
【請求項の数】 7
(21)【出願番号】P 2018071064
(22)【出願日】2018-04-02
(65)【公開番号】P2019185129
(43)【公開日】2019-10-24
【審査請求日】2021-01-13
(73)【特許権者】
【識別番号】000005223
【氏名又は名称】富士通株式会社
(74)【代理人】
【識別番号】100104190
【弁理士】
【氏名又は名称】酒井 昭徳
(72)【発明者】
【氏名】西口 直樹
(72)【発明者】
【氏名】岡林 美和
(72)【発明者】
【氏名】松井 一樹
【審査官】白井 亮
(56)【参考文献】
【文献】特開2003-150465(JP,A)
【文献】特表2013-520738(JP,A)
【文献】特表2009-529183(JP,A)
【文献】特表2004-527812(JP,A)
(58)【調査した分野】(Int.Cl.,DB名)
H04L 67/02
(57)【特許請求の範囲】
【請求項1】
イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
複数のユーザから構成され、所定の条件に基づいて当該ユーザが登録しているグループ内において、当該ユーザごとに、当該所定の条件に関連する、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行する、
制御部を有することを特徴とする情報処理装置。
【請求項2】
前記制御部は、前記複数の同じ処理のうちの実行される処理以外の処理について、処理の実行を無効化することを特徴とする請求項1に記載の情報処理装置。
【請求項3】
前記制御部は、前記複数の同じ処理のうちの一つのみを実行する有効処理の実行結果を、前記無効化された無効処理の実行結果とすることを特徴とする請求項2に記載の情報処理装置。
【請求項4】
前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果を記憶することを特徴とする請求項3に記載の情報処理装置。
【請求項5】
前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果の出力先に関する情報を記憶することを特徴とする請求項3に記載の情報処理装置。
【請求項6】
情報処理装置と端末装置とを有する情報処理システムであって、
前記情報処理装置は、
イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を前記端末装置へ提供するにあたり、
複数のユーザから構成され、所定の条件に基づいて当該ユーザが登録しているグループ内において、当該ユーザごとに、前記端末装置からの、当該所定の条件に関連する、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行する、
ことを特徴とする情報処理システム。
【請求項7】
イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
複数のユーザから構成され、所定の条件に基づいて当該ユーザが登録しているグループ内において、当該ユーザごとに、当該所定の条件に関連する、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、情報処理装置、情報処理システムおよび情報処理プログラムに関する。
【背景技術】
【0002】
従来、イベント駆動により、関数(処理)を実行するサービスが、一般的に広く提供されている。
【0003】
関連する先行技術としては、複数ユーザがマクロを共有したり、データ処理と中間結果とを管理する技術がある(たとえば、下記特許文献1、2を参照。)。
【先行技術文献】
【特許文献】
【0004】
【文献】特開2015-158923号公報
【文献】特開平5-189490号公報
【発明の概要】
【発明が解決しようとする課題】
【0005】
しかしながら、従来技術では、サービスを受ける人が多くなると、同じ処理が大量に実行されることになり、リソースの無駄遣いが大きくなるという問題点がある。
【0006】
一つの側面では、本発明は、処理を削減することを目的とする。
【課題を解決するための手段】
【0007】
一つの実施態様では、イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、情報処理装置、情報処理システムおよび情報処理プログラムが提供される。
【発明の効果】
【0008】
本発明の一側面によれば、処理を削減することができる。
【図面の簡単な説明】
【0009】
図1図1は、実施の形態にかかる情報処理装置、情報処理システムおよび情報処理プログラムの概要の一例を示す説明図である。
図2図2は、情報処理システム200のシステム構成の一例を示すブロック図である。
図3図3は、情報処理装置201のハードウェア構成の一例を示すブロック図である。
図4図4は、ルールDB211のデータ構成の一例を示す説明図である。
図5図5は、処理情報DB212のデータ構成の一例を示す説明図である。
図6図6は、グループ情報DB213のデータ構成の一例を示す説明図である。
図7図7は、処理依存関係DB214のデータ構成の一例を示す説明図である。
図8図8は、データ間関係DB215のデータ構成の一例を示す説明図である。
図9図9は、情報処理システム200の機能的構成の一例を示すブロック図である。
図10図10は、処理管理部221の処理の手順の一例を示すフローチャートである。
図11図11は、グループ管理部222の処理の手順の一例を示すフローチャートである。
図12図12は、ルール登録部223の処理の手順の一例を示すフローチャートである。
図13図13は、イベント判定部224の処理の手順の一例を示すフローチャートである。
図14図14は、処理実行部225の処理の手順の一例を示すフローチャートである。
図15図15は、実施例1(電車内のサービスを実行する例)のシステム構成図である。
図16図16は、実施例1の内容(電車に乗っていない状況)を示す説明図である。
図17図17は、実施例1の内容(電車内のサービスの状況)を示す説明図である。
図18図18は、実施例1の内容(電車に第1端末のユーザが乗った状況(その1))を示す説明図である。
図19図19は、実施例1の内容(電車に第1端末のユーザが乗った状況(その2)状況)を示す説明図である。
図20図20は、実施例1の内容(電車に第2端末のユーザが乗った状況)を示す説明図である。
図21図21は、実施例2(バスツアーに参加する例)のシステム構成図である。
図22図22は、実施例2の内容(ツアー参加というイベントの内容)を示す説明図である。
図23図23は、実施例2の内容(ツアーの各参加者がバスで移動している状況)を示す説明図である。
図24図24は、実施例2の内容(ツアーの各参加者がガイドとともに観光をしている状況)を示す説明図である。
図25図25は、実施例におけるサーバと端末の構成例を示す説明図である。
図26図26は、「入力」に関する別の一例(その1)を示す説明図である。
図27図27は、「入力」に関する別の一例(その2)を示す説明図である。
図28図28は、ルール登録に関する別の一例を示す説明図である。
【発明を実施するための形態】
【0010】
以下に図面を参照して、本発明にかかる情報処理装置、情報処理システムおよび情報処理プログラムの実施の形態を詳細に説明する。
【0011】
(実施の形態)
(情報処理システム200の概要)
図1は、実施の形態にかかる情報処理装置、情報処理システムおよび情報処理プログラムの概要の一例を示す説明図である。
【0012】
図1の左側の図において、ユーザ「甲」は、GPS情報101から処理Aを実行することによって天気・気温情報102を出力する。ここで、出力するとは、処理の実行結果(天気・気温情報102)を取得して記録することである。また、ユーザ「甲」は、GPS情報101から処理Bを実行することによって、駅情報103を出力する。また、ユーザ「乙」は、GPS情報111から処理Aを実行することによって天気・気温情報112を出力する。また、ユーザ「丙」は、GPS情報121から処理Bを実行することによって、駅情報123を出力する。
【0013】
ユーザ「甲」のGPS情報101と、ユーザ「乙」のGPS情報111と、ユーザ「丙」のGPS情報121の内容が、それぞれ同じであっても、それぞれ、別々に処理を実行する。入力である、GPS情報101とGPS情報111とGPS情報121が同じ内容であり、処理の内容も同じであることから、出力、すなわち、天気・気温情報102と天気・気温情報112とは同じ内容になり、また、駅情報103と駅情報123も同じ内容となる。
【0014】
このことから、ユーザ「甲」、「乙」、「丙」の3人の中において、同じ処理Aが2回、同じ処理Bが2回、それぞれ実行されていることがわかる。したがって、処理Aが1回分と、処理Bが1回分だけ必要なかったともいえる。その分、リソースを無駄にしたということがいえる。
【0015】
そこで、図1の右側の図に示すように、ユーザ「甲」により実行された処理Aの出力である天気・気温情報102を、ユーザ「乙」の出力(天気・気温情報「102’」)とすることで、本来、ユーザ「乙」が実行すべき処理Aの実行をおこなわないようにすることができる。ユーザ「甲」の出力をユーザ「乙」の出力とするために、たとえば、ユーザ「乙」の出力先に、ユーザ「甲」の出力に関する情報をコピーするようにするとよい。また、ユーザ「乙」の出力先をユーザ「甲」の出力先とするようにしてもよい。何れの場合であっても、ユーザ「乙」は処理Aを実行しなくても、実行結果を得ることができるようになる。
【0016】
同様に、ユーザ「甲」により実行された処理Bの出力である駅情報103を、ユーザ「丙」の出力(駅情報「103’」)とすることで、本来ユーザ「丙」が実行すべき処理Bの実行をおこなわないようにすることができる。
【0017】
このように、同じ場所にいることがわかっている場合、別々のGPS情報であっても、同じ処理結果を得ることになるため、まとめることが可能となる。すなわち、これから同じ状況となることがわかっていて、その状況での処理を登録するときに、どの入力が同じとなるかが特定でき、処理をまとめる契機となる。
【0018】
たとえば、同じ電車に乗るという状況においては、電車の移動は乗っている人に共通となり、場所も共通である(詳細な内容は、後述する実施例1において説明する)。また、バスツアーに参加するという状況においても、移動は同じになる(詳細な内容は、後述する実施例2において説明する)。
【0019】
したがって、人の単位で、イベントと関数(処理)を管理する。そして、複数の人に対して、新たな処理を登録するときに、その処理の想定しているイベントや入力が、同じとなることを利用し、重複して実行される処理の削減をすることができる。
【0020】
(情報処理システム200のシステム構成)
図2は、情報処理システム200のシステム構成の一例を示すブロック図である。図2において、情報処理システム200は、情報処理装置201を備える。情報処理装置201は、処理を実行する際に参照および書き込みをおこなうデータ210を有する。また、情報処理装置201は、データ210と、ネットワークを介して接続されるように構成されてもよい。
【0021】
また、情報処理装置201は、各種データベース(ルールデータベース(DB)211、処理情報データベース(DB)212、グループ情報データベース(DB)213、処理依存関係データベース(DB)214、データ間関係データベース(DB)215)を有する。また、情報処理装置201は、各種データベース211~215の少なくとも一つを、有しているのではなく、その代わりに、図2における図示を省略するネットワークなどを介して接続されるように構成されていてもよい。
【0022】
また、情報処理装置201は、処理管理部221と、グループ管理部222と、ルール登録部223と、イベント判定部224と、処理実行部225の各構成部などを有する構成となっている。これらの各構成部221~225によって、情報処理装置201の制御部を構成することができる。各構成部221~225の詳細な内容については、後述する。
【0023】
また、情報処理装置201は、図2における図示を省略するネットワークを介して、ユーザ端末装置251と接続されている。ここで、ユーザ端末装置251は、たとえば、パーソナルコンピュータ251a、タブレット端末装置251b、スマートフォン251cなどの情報処理装置によって実現することができる。
【0024】
ここで、ユーザ端末装置251(251a~251c)は、図示は省略するが、CPU、メモリ、ディスプレイ、入力装置、通信装置などを有する。このユーザ端末装置251によって、情報の入力、出力、通信などの各種機能を実現することができる。
【0025】
(情報処理装置のハードウェア構成例)
図3は、情報処理装置201のハードウェア構成の一例を示すブロック図である。情報処理装置201の一例であるサーバ(具体的には、たとえば、後述する図15に示すサーバ1500や、図21に示すサーバ2100など)は、CPU(Central Processing Unit)301と、メモリ302と、ネットワークI/F(Interface)303と、記録媒体I/F304と、記録媒体305と、を有する。また、各構成部301~304は、バス300によってそれぞれ接続されている。
【0026】
ここで、CPU301は、情報処理装置201の全体の制御を司る。メモリ302は、たとえば、ROM(Read Only Memory)、RAM(Random Access Memory)およびフラッシュROMなどを有する。具体的には、たとえば、フラッシュROMやROMが各種プログラムを記憶し、RAMがCPU301のワークエリアとして使用される。メモリ302に記憶されるプログラムは、CPU301にロードされることで、コーディングされている処理をCPU301に実行させる。
【0027】
ネットワークI/F303は、通信回線を通じてネットワーク306に接続され、ネットワーク306を介して他の装置(たとえば、他のサーバ、ユーザ端末装置、データベース、あるいは、他のシステム)に接続される。そして、ネットワークI/F303は、ネットワーク306と自装置内部とのインターフェースを司り、他の装置からのデータの入出力を制御する。ネットワークI/F303には、たとえば、モデムやLANアダプタなどを採用することができる。
【0028】
記録媒体I/F304は、CPU301の制御にしたがって記録媒体305に対するデータのリード/ライトを制御する。記録媒体305は、記録媒体I/F304の制御で書き込まれたデータを記憶する。記録媒体305としては、たとえば、磁気ディスク、光ディスクなどが挙げられる。
【0029】
なお、情報処理装置201は、上述した構成部301~305のほかに、たとえば、図示を省略する、SSD(Solid State Drive)、キーボード、ポインティングデバイス、ディスプレイなどを有することにしてもよい。
【0030】
(ルールDB211の内容)
図4は、ルールDB211のデータ構成の一例を示す説明図である。図4において、ルールDB211は、ルール登録部223によって登録がおこなわれ、イベント判定部224が、イベントを判定する際に用いるデータベース(テーブル)である。ルールDBは、ユーザ毎に管理される。後述する実施例においては、端末毎にルールが登録される。
【0031】
図4に示すように、ルールDB211は、たとえば、「ユーザid」欄401と、「グループid」欄402と、「ルールid」欄403と、「トリガーとなるイベント」欄404と、「入力として扱うデータ」欄405と、「データ出力先」欄406と、「実行する処理id」欄407と、「共通ルールフラグ」欄408と、「無効フラグ」欄409と、を有する。各項目欄(カラム)401~409によって形成されるフィールドに情報を記憶することで、ルールがレコードとして登録される。
【0032】
ルールDB211は、具体的には、たとえば、図3に示した記録媒体305などによってその機能を実現することができる。また、図3に示したネットワークI/F303が、ネットワーク306を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、ルールDB211の機能を実現するようにしてもよい。
【0033】
「ユーザid」欄401には、ユーザごとに一意に設られたidを記憶する。「グループid」欄402には、グループごとに一意に設られたidを記憶する。「ルールid」欄403には、ルールごとに一意に設けられたidを記憶する。「トリガーとなるイベント」欄404には、処理のきっかけ(トリガー)となるイベントに関する情報を記憶する。トリガーとなるイベントとは、具体的には、たとえば、『GPSの情報が変化した』、『歩数が増えた』などである。また、ユーザ端末装置251の所定の操作などもトリガーとなるイベントになり得る。
【0034】
「入力として扱うデータ」欄405には、入力として扱うデータを記憶する。具体的には、たとえば、GPS情報などである。「データ出力先」欄406には、処理が実行された実行結果に関するデータを出力する出力先に関する情報(ファイルパスなど)を記憶する。「実行する処理id」欄407には、このルールにかかる処理の処理idに関する情報を入力する。処理idについては、図5の処理情報DB212「処理id」欄501および図7の処理依存関係DB214の「処理id」欄701に記憶されたものと同じidを用いる。
【0035】
「共通ルールフラグ」欄408には、当該ルールが他のルールと共通化しているか否かを示すフラグを記憶する。具体的には、当該ルールが共通化されているルールである場合は、『True』を記憶し、共通化されていないルールである場合は、『False』を記憶する。
【0036】
「無効フラグ」欄409には、当該ルールが、そのルールにおいて実行される処理が無効化されるルールであるか否かを示すフラグを記憶する。共通化されたルールにおいて、処理を行うルールであれば無効化はされず、他のユーザのルールによって処理された結果を利用する場合には無効化される。具体的には、無効化される処理にかかるルールである場合は、『True』を記憶し、無効化されない処理にかかるルールである場合は、『False』を記憶する。したがって、「無効フラグ」欄409に『False』が記憶されたルールにおいては、実行する処理idにかかる処理は実行される。一方、「無効フラグ」欄409に『True』が記憶されたルールにおいては、実行する処理idにかかる処理は実行されない。
【0037】
このように、ルールDB211には、ルールごとに、トリガーとなるイベント、入力として扱うデータ、データ出力先、実行する処理id、共通ルールフラグ、無効フラグを登録する。そして、「ルールid」を用いて、それらの各情報にアクセスすることができる。
【0038】
(処理情報DB212の内容)
図5は、処理情報DB212のデータ構成の一例を示す説明図である。図5において、処理情報DB212は、「処理」に関する具体的な内容に関する情報について記憶するデータベースである。
【0039】
図5に示すように、処理情報DB212は、たとえば、「処理id」欄501と、「ファイルパス」欄502と、を有する。各項目欄(カラム)501、502によって形成されるフィールドに情報を記憶することで、処理の内容がレコードとして登録される。処理情報DB212は、具体的には、たとえば、図3に示した記録媒体305などによってその機能を実現することができる。また、図3に示したネットワークI/F303が、ネットワーク306を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、処理情報DB212の機能を実現するようにしてもよい。
【0040】
「処理id」欄501には、処理ごとに一意に設けられたidを記憶する。「ファイルパス」欄502には、処理idごとに、対象となる処理のデータファイルがあるパスに関する情報を記憶する。
【0041】
このように、処理情報DB212には、処理ごとに、ファイルパスを登録する。こうすることによって、「処理id」を用いて、その対象となる処理のデータファイルにアクセスすることができる。
【0042】
(グループ情報DB213の内容)
図6は、グループ情報DB213のデータ構成の一例を示す説明図である。図6において、グループ情報DB213は、グループ管理部222によって管理され、ルール登録部223が、ルールを登録する際に用いるデータベース(テーブル)である。グループ情報DB213には、具体的には、ユーザによって構成されるグループ情報について記憶している。
【0043】
図6に示すように、グループ情報DB213は、たとえば、「グループid」欄601と、「ルールid」欄602と、「共通化フラグ」欄603と、を有する。各項目欄(カラム)601~603によって形成されるフィールドに情報を記憶することで、グループの内容がレコードとして登録される。
【0044】
グループ情報DB213は、具体的には、たとえば、図3に示した記録媒体305などによってその機能を実現することができる。また、図3に示したネットワークI/F303が、ネットワーク306を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、グループ情報DB213の機能を実現するようにしてもよい。
【0045】
「グループid」欄601には、グループごとに一意に設けられたidを記憶する。「ルールid」欄602には、ルールごとに一意に設けられたidであって、「ルールid」欄403に記憶されたものと同じものを所定のフィールドに記憶する。「共通化フラグ」欄603には、グループidにかかるグループに対して、各ルールidにかかるルールが、共通化できるか否かを示すフラグを記憶する。当該グループに対して、各ルールが共通化できる場合は、『True』を、ルールが共通化できない場合は、『False』を、それぞれ「共通化フラグ」欄603に記憶する。
【0046】
このように、グループ情報DB213には、グループごとに、ルールidおよび共通化フラグを登録する。そして、「グループid」をキーとして、当該グループにおけるルールのうち、共通化することが可能なルールのみを抽出することができる。
【0047】
(処理依存関係DB214の内容)
図7は、処理依存関係DB214のデータ構成の一例を示す説明図である。図7において、処理依存関係DB214は、処理管理部221によって管理され、ルール登録部223が、ルールを登録する際に用いるデータベース(テーブル)である。処理依存関係DB214には、具体的には、「処理」の入力・出力・外部リソース・共通化可能フラグなどの「処理」の依存関係に関する情報について記憶している。
【0048】
図7に示すように、処理依存関係DB214は、たとえば、「処理id」欄701と、「入力」欄702と、「出力」欄703と、「外部リソース」欄704と、「共通化可能フラグ」欄705と、を有する。各項目欄(カラム)701~705によって形成されるフィールドに情報を記憶することで、処理依存関係がレコードとして登録される。
【0049】
処理依存関係DB214は、具体的には、たとえば、図3に示した記録媒体305などによってその機能を実現することができる。また、図3に示したネットワークI/F303が、ネットワーク306を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、処理依存関係DB214の機能を実現するようにしてもよい。
【0050】
「処理id」欄701には、処理ごとに一意に設けられたidであって、「処理id」欄501に記憶されたものと同じものを記憶する。「入力」欄702には、「処理id」に対する入力に関する情報を記憶する。「出力」欄703には、「処理id」に対する出力に関する情報を記憶する。「外部リソース」欄704には、「処理id」に対する外部リソース210との関係を示す情報を記憶する。「共通化可能フラグ」欄705には、「処理id」にかかる処理が共通化可能か否かの情報を記憶する。処理が共通化可能な場合は、『True』を、処理が共通化可能でない場合は、『False』を、それぞれ「共通化可能フラグ」欄705に記憶する。
【0051】
このように、処理依存関係DB214には、「処理」ごとに、入力、出力、外部リソース、共通化可能フラグを登録する。こうすることによって、「処理id」を用いて、その対象となる処理の処理依存関係に関する情報にアクセスすることができる。
【0052】
(データ間関係DB215の内容)
図8は、データ間関係DB215のデータ構成の一例を示す説明図である。図8において、データ間関係DB215は、各「処理」の実行結果の出力先と、その実行結果のコピー先とが登録されるデータベース(テーブル)である。
【0053】
図8に示すように、データ間関係DB215は、たとえば、「データ出力先」欄801と、「コピー先」欄802と、を有する。各項目欄(カラム)801、802によって形成されるフィールドに情報を記憶することで、データ間関係がレコードとして登録される。データ間関係DB215は、具体的には、たとえば、図3に示した記録媒体305などによってその機能を実現することができる。また、図3に示したネットワークI/F303が、ネットワーク306を介して接続された所定のデータベースに対するデータの入出力をおこなうことによって、データ間関係DB215の機能を実現するようにしてもよい。
【0054】
「データ出力先」欄801には、データを出力するパスに関する情報を記憶する。また、「コピー先」欄802には、「データ出力先」欄801のデータをコピーするコピー先に関する情報を記憶する。したがって、「コピー先」欄802に記憶されたデータ出力先を持つ無効化された処理は、処理を実行することができないので、「コピー先」欄802に記憶されたデータを、処理の実行結果とすることができる。
【0055】
このように、データ間関係DB215は、共通化され、無効化された処理の実行結果を担保するために、そのデータ出力先をコピー先としている。また、反対に、無効化された処理のデータ出力先を、処理を実行して実行結果を出力している出力先にリンクし、当該出力先に記憶されているデータを、自身の出力先のデータとするようにしてもよい。
【0056】
(情報処理システム200の機能的構成例)
図9は、情報処理システム200の機能的構成の一例を示すブロック図である。図9において、情報処理装置201の処理管理部221は、処理ファイルと処理の依存関係を渡され、処理情報DB212と処理依存関係DB214に処理の登録をおこなう。処理管理部221は、具体的には、たとえば、図3に示した、メモリ302などに記憶されたプログラムをCPU301に実行させることによって、また、ネットワークI/F303などによって、その機能を実現することができる。
【0057】
情報処理装置201のグループ管理部222は、人単位でルールをまとめて管理するためのグループを作成し、グループ情報DB213へ登録する。グループ管理部222は、具体的には、たとえば、図3に示した、メモリ302などに記憶されたプログラムをCPU301に実行させることによって、また、ネットワークI/F303などによって、その機能を実現することができる。
【0058】
情報処理装置201のルール登録部223は、ルール登録の処理をおこなう。指定されたグループの情報をグループ情報DB213から取得し、登録するルールが共通化可能か否かを処理依存関係DB214を参照して判断し、共通化した内容をルールDB211やデータ間関係DB215に登録する。ルール登録部223は、具体的には、たとえば、図3に示した、メモリ302などに記憶されたプログラムをCPU301に実行させることによって、また、ネットワークI/F303などによって、その機能を実現することができる。
【0059】
イベント判定部224は、ルールDB211のイベントのトリガーに基づき、イベント判定の処理をおこなう。イベント判定部224は、具体的には、たとえば、図3に示した、メモリ302などに記憶されたプログラムをCPU301に実行させることによって、また、ネットワークI/F303などによって、その機能を実現することができる。
【0060】
処理実行部225は、イベント判定部224によりトリガーされたルールを引数として処理をおこなう。処理実行部225は、具体的には、たとえば、図3に示した、メモリ302などに記憶されたプログラムをCPU301に実行させることによって、また、ネットワークI/F303などによって、その機能を実現することができる。
【0061】
(処理管理部221の処理の内容)
図10は、処理管理部221の処理の手順の一例を示すフローチャートである。図10のフローチャートにおいて、処理管理部221は、まず、各「処理」に処理idを割り振る(ステップS1001)。そして、処理idが割り振れられた処理ファイルを処理情報DB212に保存する(ステップS1002)。具体的には、図5に示したように、処理idに対して、処理ファイルを保存している場所を示すファイルパスを登録する。
【0062】
処理管理部221は、つぎに、各「処理」の依存関係に関する情報(「入力」、「出力」、「外部リソース」、「共通化可能フラグ」)を処理idと紐付けする(ステップS1003)。そして、処理idごとに、各「処理」の依存関係に関する情報を処理依存関係DB214に保存する(ステップS1004)。
【0063】
その後、処理idを返して(ステップS1005)、一連の処理を終了する。処理管理部221は、これらの一連の処理を、新たな「処理」が発生するたびにおこなう。処理情報DB212および処理依存関係DB214は、このようにして作成され、また、更新される。
【0064】
(グループ管理部222の処理の内容)
図11は、グループ管理部222の処理の手順の一例を示すフローチャートである。図11のフローチャートにおいて、グループ管理部222は、まず、各「グループ情報」にグループidを割り振る(ステップS1101)。そして、グループidが割り振れられたグループ情報をグループ情報DB213に保存する(ステップS1102)。
【0065】
その後、グループidを返して(ステップS1103)、一連の処理を終了する。グループ管理部222は、これらの一連の処理を、新たな「グループ情報」が発生するたびにおこなう。グループ情報DB213は、このようにして作成され、また、更新される。
【0066】
(ルール登録部223の処理の内容)
図12は、ルール登録部223の処理の手順の一例を示すフローチャートである。図12のフローチャートにおいて、ルール登録部223は、指定されたユーザに対して指定されたグループのルールの登録をするために、まず、グループ情報DB213に登録されている指定されたグループにおけるルールidと共通化フラグを取得する(ステップS1201)。グループに対するルールを順番に処理する。具体的には、たとえば、図6のグループ情報DB213において、「グループid」=『G3』に着目し、『G3』のグループから「ルールid」=『R3』、『R4』、『R5』の3つのルールを順に処理する。
【0067】
ルール登録部223は、グループ情報のルールがすべて処理された場合(ステップS1202:Yes)は終了する。ルール登録部223は、処理対象のルールidと共通化フラグがある場合(ステップS1202:No)は、ステップS1203へ処理を移行する。
【0068】
ルール登録部223は、処理対象の共通化フラグが『True』かチェックする(ステップS1203)。ここで、Trueである場合(ステップS1203:Yes)は、S1204へ処理を移行する。一方、Falseである場合(ステップS1203:No)は、S1209へ処理を移行する。
【0069】
ルール登録部223は、ルールDB211から、指定されたグループidと同じグループidの処理対象であるルールidの他ユーザのルールを取得する(ステップS1204)。
【0070】
ルール登録部223は、ルールが存在しているか、すなわち、ルールが取得できたか否かを判断する(ステップS1205)。ここで、ルールが取得できた場合(ステップS1205:Yes)は、ステップS1206へ処理を移行する。一方、ルールが取得できなかった場合(ステップS1205:No)は、ステップS1208へ処理を移行する。
【0071】
ルール登録部223は、処理対象のルールid403のルールを取得する。ルールは、グループ情報DB213に保存されていてもいいし、別DBで管理されていてもよい。ルールのデータ構成は、ルールDB211の、グループid402、共通ルールフラグ408、無効フラグ409を含まない構成である。すなわち、ユーザid401、ルールid403、トリガーとなるイベント404、入力として扱うデータ405、データ出力先406、実行する処理id407を構成とする。
【0072】
そして、ルール登録部223は、取得したルールの共通ルールフラグをTrueにし、無効フラグをTrueにして、指定されたユーザとグループと紐付けて、そのルールをルールDB211に登録する(ステップS1206)。そして、ルール登録部223は、ステップ1204で取得したルールのうち、共通ルールフラグがTrueかつ無効フラグがFalseのルールのデータ出力先と、S1206で登録したルールのデータ出力先を関連付けて、データ間関係DB215に保存する(ステップS1207)。その後、ルール登録部223は、処理対象のグループの次のルールの登録をおこなうために、ステップS1201へ処理を移行する。
【0073】
一方、ルール登録部223は、ステップS1205:Noの場合、処理対象のルールidのルールを取得する。そして、取得したルールの共通ルールフラグをTrueにし、無効フラグをFalseにして、指定されたユーザとグループと紐付けて、そのルールをルールDB211に登録する(ステップS1208)。その後、ステップS1201へ処理を移行する。
【0074】
ステップS1203において、ルール登録部223は、グループ情報の処理対象のルールの共通化フラグがFalseの場合(ステップS1203:No)、ルールDB211から、指定されたユーザのルールを取得する(ステップS1209)。
【0075】
つぎに、ルール登録部223は、取得したルールのうち、入力として扱うデータが同じで共通ルールフラグがTrueのルールがあるかチェックする(ステップS1210)。ここで、ルールが存在しない場合(ステップS1210:No)は、ステップS1201へ処理を移行する。一方、ルールが存在する場合(ステップS1210:Yes)は、ステップS1211へ処理を移行する。
【0076】
ルール登録部223は、グループ情報DB213から、ルールのグループidとルールidから、共通化フラグを取得する(ステップS1211)。
【0077】
ルール登録部223は、取得した共通化フラグをチェックし、共通化フラグがTrueか否かを判断する(ステップS1212)。ここで、共通化フラグがTrueである場合(ステップS1212:Yes)は、ステップS1213へ処理を移行する。一方、共通化フラグがFalseである場合(ステップS1212:No)は、ステップS1201へ処理を移行する。
【0078】
ルール登録部223は、処理対象のルールidのルールを取得する。そして、取得したルールの共通ルールフラグをTrue、無効フラグをFalseにして、指定されたユーザとグループと紐付けてルールDB211に登録する(ステップS1213)。
【0079】
また、ルール登録部223は、同じグループの他ユーザのルールidのルールに対して、共通ルールフラグをTrue、無効フラグをTrueにし、それぞれ、処理対象のルールの出力先と、それら他ユーザのルールの出力先を関連付けして、データ間関係DB215に保存する(ステップS1214)。
【0080】
以上、ルールを登録するときの処理について述べたが、詳細は省略するが、ルールを解除するときに、共通化したルールの解除をおこなうことも、上述した処理を逆におこなうことで可能となる。たとえば、共通ルールフラグがTrueかつ無効フラグがFalseのルールが解除されるときは、同じグループの他ユーザのルールを検索し、いずれかのルールの無効フラグをTrueに変更する。グループ情報の共通化フラグがFalseのルールについては、他ユーザのルールの共通ルールフラグをFalseにする。これは、共通化を解除することを意味する。ここで、さらに、他ユーザのルールについて共通化可能かどうかのチェックするような構成も可能である。
【0081】
(イベント判定部224の処理の内容)
図13は、イベント判定部224の処理の手順の一例を示すフローチャートである。図13のフローチャートにおいて、イベント判定部224は、トリガーとなるイベントがあったか否かを判断する(ステップS1301)。トリガーとなるイベントとしてはいろいろな内容があるが、具体的には、たとえば、入力データが更新されたことをイベントの例とした場合に、入力データの更新を受けて、入力データ更新をイベントとすることができる。
【0082】
ステップS1301において、トリガーとなるイベントがあるのを待って(ステップS1301:No)、トリガーとなるイベントがあった場合(ステップS1301:Yes)は、当該イベントにかかるルールを取得する(ステップS1302)。具体的には、たとえば、ルールDB211の「トリガーとなるイベント」欄404に該当するイベントにかかるルールを抽出することによって取得することができる。
【0083】
つぎに、取得したルールに無効フラグがセットされているか否かを判断する(ステップS1303)。具体的には、たとえば、ルールDB211の「無効フラグ」欄409=『True』となっているか否かによって判断することができる。ここで、無効フラグがセットされている場合(ステップS1303:Yes)は、何もせずに一連の処理を終了する。したがって、当該ルールにかかる「処理」は無効化されているため、実行されない(後述するが、出力先にはすでに実行結果がコピーされているため、実行する必要がない)。
【0084】
一方、ステップS1303において、取得したルールに無効フラグがセットされていない場合(ステップS1303:No)は、当該取得したルールを処理実行部225へ渡す。
【0085】
(処理実行部225の処理の内容)
図14は、処理実行部225の処理の手順の一例を示すフローチャートである。図14のフローチャートにおいて、処理実行部225は、イベント判定部224から受け取ったルールから「(実行する)処理id」を抽出する(ステップS1401)。具体的には、たとえば、ルールDB211の「実行する処理id」407から当該取得したルールに関連付けられた処理idを抽出することができる。
【0086】
ステップS1401において、「処理id」に基づいて、処理情報DB212から実行する処理のファイルを取得する(ステップS1402)。
【0087】
つぎに、「入力」をデータ210から取得する(ステップS1403)。つぎに、取得した「入力」に基づいて、処理を実行する(ステップS1404)。具体的には、たとえば、処理idが「P1」である場合に、入力である「GPS(緯度経度情報)」をデータ210から取得する。そして、「GPS(緯度経度情報)」から、当該緯度経度情報が示す位置における「天気」に関する情報を導き出す。これが、処理id=「P1」の処理を実行することである。「GPS」から「天気」へと導き出すのにWebサービスなどの外部リソースを参照しておこなうことが可能である。
【0088】
そして、実行結果をデータの出力先に保存する(ステップS1405)。具体的には、たとえば、「天気」に関する情報(晴れ、雨、曇など)を実行結果として、データの出力先である「/グループ1/A1/result」に記憶する。この例では、グループ1の
A1ユーザの処理結果を意味している。出力先の表し方は、この例に限定されるものではない。
【0089】
つぎに、データ間関係DB215を参照する(ステップS1406)。そして、データ間関係DB215に、ステップS1405において、実行結果を保存したデータの出力先が登録されているか否かを判断する(ステップS1407)。ここで、データ間関係DB215に、実行結果を保存したデータの出力先が登録されていない場合(ステップS1407:No)は、何もせずに、一連の処理を終了する。
【0090】
一方、データ間関係DB215に、実行結果を保存したデータの出力先が登録されている場合(ステップS1407:Yes)は、コピー先の出力先に実行結果をコピーする(ステップS1408)。具体的には、たとえば、図8に示したように、データの出力先「/グループ1/A1/result」が登録されているので、そのコピー先である「/グループ2/A1/result」および「/グループ2/B1/result」にそれぞれ、「天気」に関する情報の実行結果をコピーする。
【0091】
あるいは、ステップS1408において、コピー先の出力先に実行結果をコピーする代わりに、コピー先の出力先に、実行結果の出力先のパスを記憶して、リンクを張り、リンクの形で参照させるようにしてもよい。このようにすることによって、無効処理においても実行結果を取得することができる。処理結果に対してその都度リンクを張る以外に、ルール登録部223において、データ間関係DB215に出力先を関連付けして保存する際にリンクを張ってもよい。
【0092】
これにより、一連の処理を終了する。このようにすることによって、図13のフローチャートにおいて、無効フラグがセットされている場合(ステップS1303:Yes)であっても、「処理」を実行しなくても、実行結果を取得することができる。
【0093】
以上説明したように、本実施の形態によれば、イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、同じ入力に関する情報を使用する複数の同じ処理(共通ルールフラグ:『True』)がある場合に、当該複数の同じ処理のうちの一つ(無効フラグ:『False』)のみを実行するので、無駄となる処理を削減することができる。
【0094】
また、本実施の形態によれば、複数の同じ処理のうちの実行される処理以外の処理(無効フラグ:『True』)について、当該処理の実行を無効化するので、無駄となる処理を実行しなくて済む。
【0095】
また、本実施の形態によれば、複数の処理のうちの一つのみを実行する有効処理(無効フラグ:『False』)の実行結果を、無効化された無効処理(無効フラグ:『True』)の実行結果とするので、無効化された無効化処理であっても、実行結果を出力(提供)することができる。
【0096】
また、本実施の形態によれば、無効処理(無効フラグ:『True』)の実行結果の出力先に、有効処理(無効フラグ:『False』)の実行結果を記憶する。あたかも、無効処理にかかる処理を実行して、実行結果が得られたのと同じ効果が得られる。
【0097】
また、本実施の形態によれば、無効処理(無効フラグ:『True』)の実行結果の出力先に、有効処理(無効フラグ:『False』)の実行結果の出力先に関する情報を記憶するので、同様に、あたかも、無効処理にかかる処理を実行して、実行結果が得られたのと同じ効果が得られる。
【0098】
また、本実施の形態によれば、グループ内において、同じ入力に関する情報を使用する複数の同じ処理(共通ルールフラグ:『True』)がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つ(無効フラグ:『False』)のみを実行するので、グループ内において、無駄となる処理を削減することができる。
【0099】
また、本実施の形態によれば、グループ内における、前記複数の同じ処理のうちの実行される処理以外の処理(無効フラグ:『True』)について、当該処理の実行を無効化するので、グループ内において、無駄となる処理を実行しなくて済む。
【0100】
このように、本実施の形態によれば、重複する処理の削減を図り、リソースの節約を図ることができる。
【0101】
(実施例1)
つぎに、実施例(実施例1)について説明する。図15図20は、電車内のサービスを実行する例である。図15は、実施例1のシステム構成図である。図15において、電車内のサービスを実現するシステムは、情報処理装置201の一例であるサーバ1500と、端末装置(第1端末1501、第2端末1502、・・・)と、電車1503とから構成され、それぞれがネットワーク1550によって接続されている。第1端末1501と、第2端末1502は、GPS情報を取得する機能と、ビーコンを受信する機能とを、有している。また、電車1503は、GPS情報を取得する機能と、ビーコンを発信する機能と、を有している。
【0102】
図16は、第1端末1501および第2端末1502の各ユーザがいずれも電車1503に乗っていない状況を示している。図16において、第1端末1501のユーザは状況に関係なく、天気サービスを利用している。サーバ1500は、1601に示すように、第1端末1501のGPS情報を受けて、処理Aを実行して、その場の天気を通知(出力)する。同様に、1602に示すように、第2端末1502のGPS情報を受けて、処理Aを実行して、その場の天気を通知(出力)する。
【0103】
このような状況では、第1端末1501の処理Aと、第2端末1502の処理Aはまとめることができない。したがって、第1端末1501の処理Aと、第2端末1502の処理Aとは、同じ処理であっても、それぞれ、別個に実行されることになる。
【0104】
図17は、電車1503内におけるサービスの状況を示している。図17において、サーバ1500は、1701に示すように、電車1503のGPS情報を受けて、処理Bを実行して、駅情報を通知(出力)する。
【0105】
図18および図19は、第1端末1501のユーザが、電車1503に乗り込んだ状況を示している。図18において、第1端末1501において、第1端末1501のビーコンを受信する機能が、電車1503のビーコンを発信する機能によって発信されたビーコンを検知して、電車1503内のサービスが追加される。図18は、本案を実施しない場合のサービス追加を示している。1801が電車内サービスとして第1端末に追加されている。図19に、本案を実施した場合のサービス追加を示している。
【0106】
具体的には、たとえば、第1端末1501が電車1503のビーコンを検知したことを、ネットワーク1550を介して、サーバ1500へ伝える。これにより、サーバ1500は、電車内サービスに対して登録されているグループ情報をグループ情報DB213から取得し、第1端末用に取得したグループを指定してルール登録部223にルール登録を依頼する。電車内ではGPS情報は同じになることから、1701はまとめることが可能なルールであり、1901に示すように、第1端末1501に電車内サービスを追加することができる。
【0107】
そして、図19において、電車1503内(すなわち、ビーコンを検知している間)は、第1端末1501のGPS情報は電車1503のGPS情報と同じになるため、処理Bを統合することができる。具体的には、たとえば、サーバ1500は、1901に示すように、入力であるGPS情報を、1701のGPS情報からコピーしてくる。GPS情報の変更により、1901のルールはトリガーされるが、1701と共通化されているため処理はされない。出力である駅情報は1701の処理実行により出力がコピーされる。したがって、1901において、処理Bがおこなわれず、結果(駅情報)のみが共有されることになる。これにより、処理Bを実行するために必要なリソースを削減することができるようになる。
【0108】
図20は、さらに、第1端末1501のユーザのみならず、第2端末1502のユーザが、電車1503に乗り込んだ状況を示している。図20において、電車1503内(ビーコン検知している間)では、第1端末1501のGPS情報も、第2端末1502のGPS情報も、電車1503のGPS情報と同じになるため、1901および2001に示すように、第1端末1501および第2端末1502の処理Bを電車1503の処理Bに統合することができる。
【0109】
さらに、1601および2002に示すように、第1端末1501のGPS情報と、第2端末1502のGPS情報とが同じなため、第1端末1501の処理Aと第2端末1502の処理Aも統合することができる。このように、図20に示すように、処理3つ分のリソースを削減することができるようになる。
【0110】
(実施例2)
つぎに、別の実施例(実施例2)について説明する。図21図24は、バスツアーに参加しているという状況における処理をまとめる例である。図21は、実施例2のシステム構成図である。
【0111】
図21において、バスツアーのサービスを実現するシステムは、情報処理装置201の一例であるサーバ2100と、端末装置(第1端末2101、第2端末2102、・・・)と、ツアーのガイドが使用するガイド端末2103と、バス2104とから構成され、それぞれがネットワーク2150によって接続されている。第1端末2101と、第2端末2102は、実施例1と同様に、GPS情報を取得する機能と、ビーコンを受信する機能とを、有している。また、ガイド端末2103およびバス2104は、GPS情報を取得する機能と、ビーコンを発信する機能と、を有している。
【0112】
図22は、ツアー参加というイベントの内容を示す説明図である。図22において、ツアーAに参加するのは、第1端末2101~第8端末2108の各ユーザで、全8名である。また、ツアーBに参加するのは、第10端末2110~第12端末2112の各ユーザで、全3名である。
【0113】
ツアーAに参加する第1端末2101~第8端末2108には、ツアーA用サービスが登録される。また、同様に、ツアーBに参加する第10端末2110~第12端末2112には、ツアーB用サービスが登録される。
【0114】
図23は、ツアーの各参加者がバスで移動している状況を示している。図23において、第1端末2101~第8端末2108の各ユーザはバスA2121に乗車している。第1端末2101~第8端末2108の各ユーザがバスA2121に乗車していることは、バスA2121のビーコンを発信する機能によって発信されたビーコンを、第1端末2101~第8端末2108のビーコンを受信する機能が検知することによってわかる。
【0115】
ここで、ツアーAの代表として第1端末2101を設定した場合に、第1端末2101にのみツアーA用のサービスにかかる処理をおこなわせる。そして、他の端末(第2端末2102~第8端末2108)については、当該サービスにかかる処理を無効化する。そして、第1端末2101の出力を他の端末(第2端末2102~第8端末2108)にそれぞれコピーすることで、当該サービスの提供を受けることができる。
【0116】
また、第10端末2110~第12端末2112の各ユーザはバスB2122に乗車している。第10端末2110~第12端末2112の各ユーザがバスB2122に乗車していることは、バスB2122のビーコンを発信する機能によって発信されたビーコンを、第10端末2110~第12端末2112のビーコンを受信する機能が検知することによってわかる。
【0117】
ここで、ツアーBの代表として第10端末2110を設定した場合に、第10端末2110にのみツアーB用のサービスにかかる処理をおこなわせる。そして、他の端末(第11端末2111および第12端末2112)については、当該サービスにかかる処理を無効化する。そして、第10端末2110の出力を他の端末(第11端末2111および第12端末2112)にそれぞれコピーすることで、当該サービスの提供を受けることができる。
【0118】
このように、ツアーAの代表として第1端末2101を設定して、第1端末2101にのみツアーA用のサービスにかかる処理をおこなわせることによって、第1端末2101以外の他の端末装置(第2端末2102~第8端末2108)が、ツアーA用のサービスにかかる処理をおこなわなくてもよく、その分、処理を削減することができる。また、ツアーBの代表として第10端末2110を設定して、第10端末2110にのみツアーB用のサービスにかかる処理をおこなわせることによって、第10端末2110以外の他の端末装置(第11端末2111および第12端末2112)が、ツアーB用のサービスにかかる処理をおこなわなくてもよく、その分、処理を削減することができる。
【0119】
図24は、ツアーの各参加者がそれぞれガイドとともに観光をしている状況を示している。図24に示すように、ツアーAに参加しているユーザのうち、第1端末2101~第5端末2105の各ユーザは、第1ガイド端末2411のガイドとともに観光をしていることがわかる。一方、ツアーAに参加しているユーザのうち、第6端末2106~第8端末2108の各ユーザと、ツアーBに参加している第10端末2110~第12端末2112の各ユーザは、第2ガイド端末2412のガイドとともに観光をしていることがわかる。
【0120】
この状況において、第1ガイド端末2421のガイドとともに観光をしているユーザに対しては、ツアーAの代表として第1端末2101を設定して、第1端末2101にのみツアーA用のサービスにかかる処理をおこなわせる。そして、他の端末(第2端末2102~第5端末2105)については、当該サービスにかかる処理を無効化する。そして、第1端末2101の出力を他の端末(第2端末2102~第5端末2105)にそれぞれコピーすることで、当該サービスを享受することができる。
【0121】
また、第2ガイド端末2422のガイドとともに観光をしているユーザに対しては、ツアーAの代表として第6端末2106を設定して、第6端末2106にのみツアーA用のサービスにかかる処理をおこなわせる。そして、他の端末(第7端末2107および第8端末2108)については、当該サービスにかかる処理を無効化する。そして、第6端末2106の出力を他の端末(第7端末2107および第8端末2108)にそれぞれコピーすることで、当該サービスを享受することができる。
【0122】
ツアーBの代表として第10端末2110を設定して、第10端末にのみツアーB用のサービスにかかる処理を行わせる。そして、他の端末(第11端末2111および第12端末2112)については、当該サービスにかかる処理を無効化する。そして、第10端末2110の出力を他の端末(第11端末2111および第12端末2112)にそれぞれコピーすることで、当該サービスを享受することができる。
【0123】
このように、各ユーザは、異なるグループに参加することによって、それぞれ、各処理の共通化の態様が変化することがわかる。
【0124】
図25は、実施例におけるサーバと端末の構成例を示す説明図である。図25において、サーバ2500は、センサー情報受信部2501と、サービス登録情報記憶部2502と、サービス情報記憶部2503と、サービス提供部2504と、を備える。また、端末2510は、監視センサー情報記憶部2511と、センサー通知部2512と、通知受信部2513と、を備える。
【0125】
端末2510は、監視センサー情報記憶部2511において、監視するセンサー情報を記憶し、センサー通知部2512が、センサー変化時にサーバ2500へ、センサー情報を伝える。サーバ2500は、サービス登録情報記憶部2502において、端末2510ごとにサービス登録情報を記憶する。
【0126】
そして、センサー情報受信部2501が、端末2510からのセンサー情報を受信して、受信したセンサー情報に対応するサービスに登録していれば、端末向けにサービスを開始する。サービスを開始するとは、そのサービスに対応するグループを指定して、端末2510向けのルールを登録することを示している。サービスにて提供する情報が、サービス情報記憶部2503に記憶されていれば、サービス提供部2504が、端末2510へ通知情報を送信する。端末2510の通知受信部2513は、その通知情報を受信する。サービス情報記憶部2503にはデータ210の場所が登録されており、その場所に変化があったときに、サービス提供部2504が端末2510へデータを送信してもよい。また、変化があったときに通知し、データは端末2510から、サーバ2500のデータ210を参照してもよい。
【0127】
具体的には、たとえば、ツアーAを申し込むと、以下のような情報が登録される。(1)『ツアーサービス』、(2)『バス内サービス』、(3)『ガイド観光サービス』である。そして、サービス登録情報記憶部2502に記憶されるサービス登録情報は、それぞれ、(1)『ツアーサービス:なし』、(2)『バス内サービス:バスA』、(3)『ガイド観光サービス:第1ガイド』である。このように、サービス登録情報記憶部2502に記憶されるサービス登録情報は、各センサー情報に対して、サービスが利用可能かについての情報を記憶する。
【0128】
また、監視センサー情報としては、監視するセンサーを指定することもできる。たとえば、GPS、ビーコンのようにデバイスを指定するようにしてもよい。この場合は、センサーからのデータはすべて、サーバ2500に送信し、サーバ2500側で取捨選択するようにしてもよい。また、範囲を限定する情報とすることも可能である。GPSの範囲や、ビーコンのUUID(Universally Unique Identifier)など、端末側で判断をおこない、合致する場合のみサーバ2500へ送信するようにしてもよい。
【0129】
そして、各センサー情報を受信した場合に、サービスが利用可能な場合には、端末2510に対して、そのセンサー情報に対応するサービスを開始することができる。このように、センサー情報をきっかけとして、サービスの提供を可能とする。
【0130】
(「入力」に関する別の例)
図26および図27は、「入力」に関する別の一例を示す説明図である。図26において、上側の図の上段は、GPS2601から住所2602へ変換し、そこから、天気・気温2603を出力している。一方、上側の図の下段は、GPS2601の代わりにiBeacon2611から住所2612へ変換し、そこから、駅情報2613を出力している。
【0131】
ここで、住所2602と住所2612とは、同じ情報であることに着目し、下側の図に示すように、GPS2601から住所2602への変換の代わりに、iBeacon2611から住所2612への変換を利用し、その住所2612から天気・気温2603を出力することができる。このように、「入力」の意味を定義しておくことで、サービスごとの入力手段の違いを吸収することができる。このような入力の代替をサービス追加時におこなうことで、より共通化を図ることができる。
【0132】
また、図27の上側の図において、「入力」が、たとえば時刻のように周期的な場合を示している。具体的には、左側は、「入力」が『30分毎』2702であるのに対して、右側は、「入力」が『15分毎』2712である。その他の「入力」2701、2711については同じである。この場合に、下側の図に示すように、『30分毎』2702と『15分毎』2712を別々の「入力」とせずに、一番短い周期(「15分」)で共通化する。これにより、処理を共通化することで、入力2701および2702とし出力2703とする処理をおこなわなくて済み、その分、処理を削減することができる。
【0133】
図28は、ルール登録に関する別の一例を示す説明図である。図28において、上述したルールに基づいて共通化を図ると、グループ2801とグループ2802の二つのグループで第1の共通化を図る。また、それとは別に、グループ2802とグループ2803とグループ2804の三つのグループで第2共通化を図ることができたとする。その場合、それぞれ共通化したグループの中に、共通するグループ2802が含まれていることがわかる。その場合に、第1の共通化と第2の共通化をさらに共通化し、四つで共通化することもできる。
【0134】
これにより、第1の共通化における処理と、第2の共通化における処理を一つの処理でおこなうことができる。このように、すでにルール登録されている場合に、入力が同じとなるルールが登録されたときは、ルール登録時の影響範囲を広げて共通化することができるため、その分の処理をさらに削減することができる。
【0135】
なお、本実施の形態で説明した情報処理方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することにより実現することができる。情報処理プログラムは、ハードディスク、フレキシブルディスク、CD(Compact Disc)-ROM、MO(Magneto-Optical Disk)、DVD(Digital Versatile Disk)、フラッシュメモリ、USB(Universal Serial Bus)メモリなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。また、情報処理プログラムは、インターネットなどのネットワークを介して配布してもよい。
【0136】
上述した実施の形態に関し、さらに以下の付記を開示する。
【0137】
(付記1)イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、
制御部を有することを特徴とする情報処理装置。
【0138】
(付記2)前記制御部は、前記複数の同じ処理のうちの実行される処理以外の処理について、当該処理の実行を無効化することを特徴とする付記1に記載の情報処理装置。
【0139】
(付記3)前記制御部は、前記複数の同じ処理のうちの一つのみを実行する有効処理の実行結果を、前記無効化された無効処理の実行結果とすることを特徴とする付記2に記載の情報処理装置。
【0140】
(付記4)前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果を記憶することを特徴とする付記3に記載の情報処理装置。
【0141】
(付記5)前記制御部は、前記無効処理の実行結果の出力先に、前記有効処理の実行結果の出力先に関する情報を記憶することを特徴とする付記3に記載の情報処理装置。
【0142】
(付記6)前記制御部は、グループ内において、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該グループ内において、当該複数の同じ処理のうちの一つのみを実行することを特徴とする付記1~5のいずれか一つに記載の情報処理装置。
【0143】
(付記7)前記制御部は、前記グループ内における、前記複数の同じ処理のうちの実行される処理以外の処理について、当該処理の実行を無効化することを特徴とする付記6に記載の情報処理装置。
【0144】
(付記8)情報処理装置と端末装置とを有する情報処理システムであって、
前記情報処理装置は、
イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を前記端末装置へ提供するにあたり、
前記端末装置からの、同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、
ことを特徴とする情報処理システム。
【0145】
(付記9)イベントの発生により、入力に関する情報を使用して処理を実行し、当該処理の実行結果を出力するにあたり、
同じ入力に関する情報を使用する複数の同じ処理がある場合に、当該複数の同じ処理のうちの一つのみを実行する、
処理をコンピュータに実行させることを特徴とする情報処理プログラム。
【符号の説明】
【0146】
200 情報処理システム
201 情報処理装置
210 データ(外部リソース)
211 ルールDB
212 処理情報DB
213 グループ情報DB
214 処理依存関係DB
215 データ間関係DB
221 処理管理部
222 グループ管理部
223 ルール登録部
224 イベント判定部
225 処理実行部
251(251a~251c) ユーザ端末装置
図1
図2
図3
図4
図5
図6
図7
図8
図9
図10
図11
図12
図13
図14
図15
図16
図17
図18
図19
図20
図21
図22
図23
図24
図25
図26
図27
図28