データ処理装置、データ処理方法及びプログラム
【課題】データの保護とデータの加工やアクセス制限の緩和を柔軟且安全に可能とするデータ処理装置を提供すること。
【解決手段】パブリッシュ・サブスクライブ・モデルを利用したＰｕｂ−Ｓｕｂブローカ１３は、入出力データに係る所有者タグの検証を行うＰｕｂ−Ｓｕｂ検証部１６に保護される。自由ＦＦ実行環境１４は、入出力データの所有者タグの設定を行う自由ＦＦ所有者タグ設定部１７に保護される。特権ＦＦ実行環境１５は、特権フロー関数に付与された署名の検証を行う特権ＦＦ署名検証部１８に保護される。ユーザは、自由フロー関数を用いることによって、チャネルを流れるデータに対して、所望の処理を施すことができる。ただし、データと所有者タグが適合する場合にのみ、そのデータを利用可能にする。また、権限を持つ者の署名を必要とする特権フロー関数によって、所有者タグを、そのユーザに適合するように書き換えることができるようにする。
【解決手段】パブリッシュ・サブスクライブ・モデルを利用したＰｕｂ−Ｓｕｂブローカ１３は、入出力データに係る所有者タグの検証を行うＰｕｂ−Ｓｕｂ検証部１６に保護される。自由ＦＦ実行環境１４は、入出力データの所有者タグの設定を行う自由ＦＦ所有者タグ設定部１７に保護される。特権ＦＦ実行環境１５は、特権フロー関数に付与された署名の検証を行う特権ＦＦ署名検証部１８に保護される。ユーザは、自由フロー関数を用いることによって、チャネルを流れるデータに対して、所望の処理を施すことができる。ただし、データと所有者タグが適合する場合にのみ、そのデータを利用可能にする。また、権限を持つ者の署名を必要とする特権フロー関数によって、所有者タグを、そのユーザに適合するように書き換えることができるようにする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データ処理装置、データ処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来のパブリッシュ・サブスクライブ・システムの動的アクセス制御については、例えば特許文献１に、コンテンツの発行者（パブリッシャ）から購読者（サブスクライバ）に至るまでのパブリッシュ・サブスクライブ・ネットワーク（Ｐｕｂ−Ｓｕｂネットワーク）における動的アクセス制御機構が開示されている。このアクセス制御では、アクセス制御ルールが、Ｐｕｂ−Ｓｕｂシステムにおける購読者プリンシパルとアクセス形態、フィルタの３つ組によって記述される。例えば、プリンシパル「Ｊｏｈｎ Ｄｏｅ」に株価情報を購読依頼することを認めるルールは、［Ｊｏｈｎ Ｄｏｅ、購読依頼、タイプ＝‘'株価’］のように記述される。
【０００３】
この技術においては、以下の２つの問題がある。
（１）コンテンツフィルタを自由に記述することができない（アクセス制限がコンテンツフィルタに強く依存しているため、規定されたコンテンツフィルタ以外のコンテンツフィルタを利用することができない）。
【０００４】
（２）データの匿名化等、加工によるアクセス権限の緩和を実現することができない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２８７１４８公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来、データの保護と、データの加工やアクセス制限の緩和を、柔軟かつ安全に可能とする方法が知られていなかった。
【０００７】
本発明は、上記事情を考慮してなされたもので、データの保護と、データの加工やアクセス制限の緩和を、柔軟かつ安全に可能とするデータ処理装置、データ処理方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、送信装置からデータを受信し、該データを処理して受信装置へ送信することの可能なデータ処理装置であって、前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証し、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証する第１の検証部と、前記送信装置に係る前記検証に成功した場合にのみ、前記送信装置から前記データを受信することが可能であり、前記受信装置に係る前記検証に成功した場合にのみ、前記受信装置へ前記データを送信することが可能である中継部と、データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、前記自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定する設定部と、データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証する第２の検証部と、前記特権フロー関数に係る前記検証に成功した場合にのみ、前記特権フロー関数を実行することが可能であるとともに、該特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定する第２の実行部とを備えたことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、データの保護と、データの加工やアクセス制限の緩和を、柔軟かつ安全に実現することが可能になる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係る情報処理システムの構成例を示す図である。
【図２】Ｐｕｂ−Ｓｕｂブローカ及びＰｕｂ−Ｓｕｂ検証部の内部構成例を示す図である。
【図３】パブリッシュ及びサブスクライブについて説明するための図である。
【図４】所有者タグセットについて説明するための図である。
【図５】所有者タグセットを所有者タグが充足するかどうかを検証するアルゴリズムの一例を示す図である。
【図６】特権フロー関数の定義テーブルの一例を示す図である。
【図７】外部からのサブスクライブ要求に対する検証のアルゴリズムの一例を示す図である。
【図８】自由ＦＦ実行環境における出力チャネルの所有者タグのセットの設定のアルゴリズムの一例を示す図である。
【図９】パブリッシュ受付時の検証のアルゴリズムの一例を示す図である。
【図１０】同実施形態の情報処理システムの要求配置の動作手順の一例を示すフローチャートである。
【図１１】同実施形態の情報処理システムのパブリッシュ受け付け、要求配置及びサブスクライブの際に検証を行う場合の動作手順の一例を示すフローチャートである。
【図１２】同実施形態の要求処理装置のパブリッシュ時の動作手順の一例を示すフローチャートである。
【図１３】用紙残量閾値判定関数の擬似コードの一例を示す図である。
【図１４】本実施形態の動作の一例について説明するための図である。
【図１５】本実施形態の動作の一例について説明するための図である。
【図１６】本実施形態の動作の一例について説明するための図である。
【図１７】本実施形態の動作の一例について説明するための図である。
【図１８】本実施形態の動作の一例について説明するための図である。
【図１９】本実施形態の動作の一例について説明するための図である。
【図２０】本実施形態の動作の一例について説明するための図である。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照しながら本発明の実施形態について説明する。
【００１２】
図１に、本発明の一実施形態に係る情報処理システムの構成例を示す。
【００１３】
本実施形態の情報処理システムは、パブリッシュ・サブスクライブ・モデル（Ｐｕｂｌｉｓｈ−Ｓｕｂｓｃｒｉｂｅモデル）を前提とする場合を例にとって説明する。
【００１４】
また、以下において具体例を用いて説明する場合には、本実施形態の情報処理システムが、テナントが入居するビル内に設けられ、ビル内の設備等の監視・制御等に利用される場合を例にとって説明する。
【００１５】
図１において、１は要求処理装置（データ処理装置）、２はユーザ装置、３は要求配置装置、４はフロー関数コードレポジトリ（ＦＦコードレポジトリ）、５はパブリッシャとなる作用装置（送信装置）、６はサブスクライバとなる作用装置（受信装置）である。
【００１６】
各装置は、例えば、図示しないネットワークを介して通信可能である。
【００１７】
図１において、各装置は１台ずつ示されているが、システム中に各装置がそれぞれ任意台数ずつ存在して構わない。
【００１８】
個々の作用装置は、バブリッシャとしてのみ動作可能であっても良いし、サブスクライバとしてのみ動作可能であっても良いし、バブリッシャとサブスクライバの両方として動作可能であっても良い。
【００１９】
各装置の概要を下記に示す。
【００２０】
作用装置５は、要求処理装置１へデータを送信する装置である。
【００２１】
作用装置６は、要求処理装置１からデータを受信する装置である。
【００２２】
個々の作用装置５，６は、一意な識別情報（ＩＤ）を持ち識別可能であるとする。
【００２３】
ユーザ装置２は、利用者により記述されたユーザ要求を、要求配置装置３に送出する装置である。
【００２４】
要求配置装置３は、ユーザ装置２から受けた要求を、要求処理装置１に配置する装置である。
【００２５】
要求処理装置１は、１又は複数の作用装置５からデータを受信し、受信したデータ又はこれを加工したものを、作用装置６へ送信する装置である。また、ユーザ装置２と作用装置５，６との間の仲立ちを行う装置である。
【００２６】
ＦＦコードレポジトリ４は、フロー関数コード（ＦＦコード）を蓄積するデータベースである。
【００２７】
図１に示されるように、要求処理装置１は、要求受付部１１、フロー関数コードロード部（ＦＦコードロード部）１２、パブリッシュ・サブスクライブ・ブローカ（以下、Ｐｕｂ−Ｓｕｂブローカ）（中継部）１３、自由フロー関数実行環境（以下、自由ＦＦ実行環境）（第１の実行部）１４、特権フロー関数実行環境（以下、特権ＦＦ実行環境）（第２の実行部）１５、Ｐｕｂ−Ｓｕｂブローカ１３に付随するパブリッシュ・サブスクライブ検証部（以下、Ｐｕｂ−Ｓｕｂ検証部）（第１の検証部）１６、自由ＦＦ実行環境１４に付随する自由フロー関数所有者タグ設定部（以下、自由ＦＦ所有者タグ設定部）（設定部）１７、特権ＦＦ実行環境１５に付随する特権フロー関数署名検証部（以下、特権ＦＦ署名検証部）（第２の検証部）１８を備えている。
【００２８】
図２に、Ｐｕｂ−Ｓｕｂブローカ１３とＰｕｂ−Ｓｕｂ検証部１６の内部構成例を示す。図２に示されるように、Ｐｕｂ−Ｓｕｂブローカ１３は、パブリッシュ・サブスクライブ処理部１３１、送受信インタフェース部１３２、チャネル情報記憶部１３３を含む。
【００２９】
本実施形態では、パブリッシャである作用装置５と、サブスクライバである作用装置６と、（本実施形態においてサブスクライバ・パブリッシャとなる）自由フロー関数を実行する自由フロー関数実行環境１４と、（本実施形態においてサブスクライバ・パブリッシャとなる）特権フロー関数を実行する特権フロー関数実行環境１５との間のデータの受け渡しは、仮想的な通信路であるチャネルを介して行われる。パブリッシュ・サブスクライブ処理部１３１は、それらの間でデータを中継するための処理を行う。チャネル情報記憶部１３３は、各チャネルに関する情報（例えば、どの送信者がそのチャネルにデータを流し、どの受信者がそのチャネルからデータを受けるか、などの情報）を記憶する。送受信インタフェース部１３２は、外部の装置と通信を行うためのものであり、外部の装置である作用装置５，６との間のデータの受け渡しには、送受信インタフェース部１３２を介した通信が必要となる。これに対して、自由フロー関数実行環境１４又は特権フロー関数実行環境１５との間のデータの受け渡しは、チャネルを介するだけで可能である。なお、送受信インタフェース部１３２は、Ｐｕｂ−Ｓｕｂ検証部１６の外部にあっても構わない。
【００３０】
また、図２に示されるように、Ｐｕｂ−Ｓｕｂ検証部１６は、パブリッシャである作用装置５の検証を行うパブリッシャ検証部１６１と、パブリッシャである作用装置６の検証を行う、サブスクライバ検証部１６２とを含む。
【００３１】
以下、本実施形態について詳しく説明する。
【００３２】
まず、チャネル、パブリッシュ、サブスクライブ、Ｐｕｂ−Ｓｕｂブローカ１３について説明する。
【００３３】
「チャネル」は、パブリッシュ・サブスクライブ・モデルに基づく仮想的な通信路に相当するものである。
【００３４】
パブリッシュ・サブスクライブ・モデルでは、通常の要求−応答モデルと異なり、所望するデータが流れる特定のチャネルに対して、データ送付先（データの受信側）となるサブスクライバの情報を事前に登録しておき、データの送信側となるパブリッシャが、それぞれのタイミングで、データを当該特定のチャネルに送出すると、当該特定のチャネルにデータが流れたタイミングで、そのデータが、当該特定のチャネルに対して事前に登録された（１又は複数の）サブスクライバに送信される。パブリッシュ・サブスクライブ・モデルにおいて、パブリッシャとサブスクライバとの通信の仲立・中継をするのがいわゆるブローカと呼ばれるサーバである。
【００３５】
本実施形態では、要求処理装置１のＰｕｂ−Ｓｕｂブローカ１３が、パブリッシュ・サブスクライブ・モデルにおけるブローカの役割に相当する役割を担う。すなわち、Ｐｕｂ−Ｓｕｂブローカ１３は、パブリッシャとなる作用装置５とサブスクライバとなる作用装置６との通信の仲立・中継をする。
【００３６】
以下、チャネルに対してデータを送出することを「パブリッシュ」、特定のチャネルからデータを受信するために、受信側の情報を当該特定のチャネルに対して登録することを「サブスクライブ」と呼ぶものとする。
【００３７】
ところで、本実施形態では、要求処理装置１において、作用装置５から受信したデータを、後述するフロー関数により処理した後に、作用装置６へ送信することができる。このために、本実施形態では、フロー関数についても、データの受け渡しを、チャネルを介して行うものとしている。すなわち、本実施形態では、データの生成者である作用装置５と、データの需要者である作用装置６と、フロー関数（自由フロー関数、特権フロー関数）とが、チャネルを経由して、データを交換する。
【００３８】
ここで、フロー関数について説明する。
【００３９】
「フロー関数」は、特定の１又は複数のチャネルをサブスクライブし、該チャネルに係るデータを入力として、所定のタイミングで（例えば、サブスクライブ先のチャネルへ、データが出力されたイベントを契機に）、所定の処理（所定の演算及び又は判断など）を行い、その結果得られるデータを、必要に応じて、特定の１又は複数のチャネルに対してパブリッシュする関数である。なお、所定の処理の結果によっては、パブリッシュを行わない場合もある。フロー関数は、基本的にはどのような処理も可能であり、例えば、チャネルの情報を加工し、センサネットワークから有益な情報を抽出し、あるいは、その情報から環境に作用するアクチュエータを制御したりすることも可能である。フロー関数の実体は、要求処理装置１上に配置される。
【００４０】
本実施形態では、フロー関数には、「自由フロー関数」と「特権フロー関数」とがある。自由フロー関数については、任意の利用者（例えば、施設管理者、施設利用者や、第三者）が、その処理内容を自由に記述することができる。これに対して特権フロー関数については、特権を有する者（例えば、施設管理者）のみが処理内容を規定することができる。言い換えると、特権を有する者により規定された処理内容だけが実行可能である（特権を有する者以外の者が所望の特権フロー関数を実行させたい場合には、例えば、特権を有する者に、その所望の特権フロー関数を用意してもらう必要がある）。なお、フロー関数の記述には、例えばＪａｖａ（登録商標）等のプログラミング言語などが利用可能である。
【００４１】
自由フロー関数は、任意のデータ入力チャネルに対して実行することができる。すなわち、作用装置５から受信されたデータと、他の自由フロー関数が出力したデータと、特権フロー関数が出力したデータとのいずれを入力とすることも可能である。また、入力するチャネルの個数、組み合わせは任意である。
【００４２】
同様に、特権フロー関数は、任意のデータ入力チャネルに対して実行することができる。すなわち、作用装置５から受信されたデータと、自由フロー関数が出力したデータと、他の特権フロー関数が出力したデータとのいずれを入力とすることも可能である。また、入力するチャネルの個数、組み合わせは任意である。
【００４３】
さて、本実施形態では、図３（ａ）に例示するように、要求処理装置１において、パブリッシャＰから受信したデータを、チャネルＸを介して、そのままサブスクライバＳに送信することも可能であるが、そのフローの途中に、１又は複数（任意数）のフロー関数（自由フロー関数及び又は特権フロー関数）を挿入して、所望の機能を実現することが可能である。なお、図３において、実線は、データの流れを、一点鎖線は、パブリッシュを、破線は、サブスクライブをそれぞれ示す。
【００４４】
例えば、（１）自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）がチャネルＸにサブスクライブし、作用装置ＳがチャネルＹにサブスクライブしておき、作用装置ＰからのデータをチャネルＸに流し、自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）が、チャネルＸからのデータを処理してその結果となるデータをチャネルＹに流し、チャネルＹのデータを作用装置Ｓに送信する処理フロー（図３（ｂ）、図１５，１６参照）、
（２）自由フロー関数Ｆ１１がチャネルＸにサブスクライブし、特権フロー関数Ｆ２１がチャネルＹにサブスクライブし、作用装置ＳがチャネルＺにサブスクライブしておき、作用装置ＰからのデータをチャネルＸに流し、自由フロー関数Ｆ１１が、チャネルＸからのデータを処理してその結果となるデータをチャネルＹに流し、特権フロー関数Ｆ２１が、チャネルＹからのデータを処理してその結果となるデータをチャネルＺに流し、チャネルＺのデータを作用装置Ｓに送信する処理フロー（図３（ｃ）、図１参照）、
（３）特権フロー関数Ｆ２１がチャネルＸにサブスクライブし、自由フロー関数Ｆ１１がチャネルＹにサブスクライブし、作用装置ＳがチャネルＺにサブスクライブしておき、作用装置ＰからのデータをチャネルＸに流し、特権フロー関数Ｆ２１が、チャネルＸからのデータを処理してその結果となるデータをチャネルＹに流し、自由フロー関数Ｆ１１が、チャネルＹからのデータを処理してその結果となるデータをチャネルＺに流し、チャネルＹのデータを作用装置Ｓに送信する処理フロー（図１９参照）、
（４）自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）がチャネルＸ１とチャネルＸ２にサブスクライブし、作用装置ＳがチャネルＹにサブスクライブしておき、作用装置Ｐ１からのデータをチャネルＸ１に流し、作用装置Ｐ２からのデータをチャネルＸ２に流し、自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）が、チャネルＸ１とチャネルＸ２からのデータを入力として処理を行ってその結果となるデータをチャネルＹに流し、チャネルＹのデータを作用装置Ｓに送信する処理フロー（図３（ｄ）参照）、
（５）自由フロー関数Ｆ１１がチャネルＸ１とチャネルＸ２にサブスクライブし、特権フロー関数Ｆ２１がチャネルＹにサブスクライブし、作用装置ＳがチャネルＺにサブスクライブしておき、作用装置Ｐ１からのデータをチャネルＸ１に流し、作用装置Ｐ２からのデータをチャネルＸ２に流し、自由フロー関数Ｆ１１が、チャネルＸ１とチャネルＸ２からのデータを入力として処理を行ってその結果となるデータをチャネルＹに流し、特権フロー関数Ｆ２１が、チャネルＹからのデータを処理してその結果となるデータをチャネルＺに流し、チャネルＺのデータを作用装置Ｓに送信する処理フロー（図３（ｅ）参照）、
などの様々な処理フローを実現することができる。
【００４５】
チャネルは、例えば、「チャネル識別子」と「データ送付先（データ受信者）のリスト（受信者リスト）」と「許可されたデータ送信者のリスト（送信者リスト）」とを組にしたチャネル情報により管理される。このような情報は、要求処理装置１のＰｕｂ−Ｓｕｂブローカ１３のチャネル情報記憶部１３３が保持する。
【００４６】
なお、チャネル情報に「所有者タグ（所有者タグセット）」の情報を含めても良い。また、これとは別に、「チャネル識別子」と「所有者タグ（所有者タグセット）」との対応を管理しても良い。
【００４７】
Ｐｕｂ−Ｓｕｂブローカ１３（パブリッシュ・サブスクライブ処理部１３１）は、例えば、あるチャネルにデータが到着すると、到着したデータを、そのチャネルのチャネル識別子に対応する受信者リストに登録された全ての受信者へ送付する。なお、例えば、あるチャネルにデータが到着した際に、そのチャネルのチャネル識別子に対応する送信者リストに基づき、到着したデータが、そのチャネルについて許可されたデータ送信者からのものかを検査する手順も可能である。この手順では、検査の結果が正しかった場合にのみ、到着したデータを、そのチャネルのチャネル識別子に対応する受信者リストに登録された全ての受信者へ送付する。
【００４８】
ただし、後述するように、本実施形態では、作用装置５，６について、所有者タグに基づく検証を行い、この検証に成功した場合にのみ、パブリッシュやサブスクライブ（あるいは、作用装置５はらのデータの受信や、作用装置６へのデータの送信）が可能になるようにしている。
【００４９】
次に、所有者タグについて説明する。
【００５０】
本実施形態のアクセス制御技術では、作用装置５，６及び要求処理装置１並びに要求処理装置１内で扱われるデータに係るチャネルについて、所有者という概念を利用する。
【００５１】
本実施形態では、所有者を示す情報として、所有者タグを用いる。
【００５２】
「所有者タグ」は、任意数の所有者を示す識別子（所有者ＩＤ）のリストにより構成される。
【００５３】
所有者タグは、機器（本実施形態では、要求処理装置１又は作用装置５，６）の所有者、作用装置５からの入力データに係るチャネルの所有者、又は特定の種類のプログラム（本実施形態では、特権フロー関数若しくは自由フロー関数）の出力データに係るチャネルの所有者を示す情報である。
【００５４】
所有者タグは、基本的には、要求処理装置１が、パブリッシャとなる作用装置５からデータの入力や、サブスクライバとなる作用装置６へのデータの送信に先立って、所有者タグの適合性の検証を行うために利用される。
【００５５】
例えば、「ビル管理者の所有者ＩＤ」と「ビル利用者１の所有者ＩＤ」と「ビル利用者２の所有者ＩＤ」との和集合からなる所有者タグに対しては、「ビル管理者の所有者ＩＤ」と「ビル利用者１の所有者ＩＤ」と「ビル利用者２の所有者ＩＤ」の全部又は一部のみからなる所有者タグが適合し、「ビル管理者の所有者ＩＤ」「ビル利用者１の所有者ＩＤ」「ビル利用者２の所有者ＩＤ」以外の所有者ＩＤを一つでも含むものは適合しないこととなる。適合性の検証に成功した場合にのみ、そのデータが利用可能（サブスクライブ可能）になり、あるいは、要求処理装置１にデータを送信可能（パブリッシュ可能）になる。
【００５６】
装置については、例えば、権限を有する管理者等が予め当該装置に対して、（１又は複数の）所有者を含む所有者タグを設定する。なお、作用装置５，６の所有者タグは、作用装置５，６に設定して、作用装置５，６から要求処理装置１のＰｕｂ−Ｓｕｂブローカ１へ伝えるようにしても良いし、例えば、要求処理装置１内（例えば、Ｐｕｂ−Ｓｕｂブローカ１３内）に、作用装置５，６の識別情報と所有者タグとを対応付けて記憶しておき、作用装置５，６から要求処理装置１へ識別情報を伝え、要求処理装置１は、伝えられた識別情報からその作用装置５，６の所有者タグを得るようにしても良い。
【００５７】
一つの作用装置５から入力したデータ（外部からのデータ）を流すチャネルには、その入力となる作用装置５の所有者タグがそのまま与えられるものとする。
【００５８】
一つのデータを入力とする（一つのチャネルにサブスクライブする）自由フロー関数が出力するデータに係るチャネルには、それが入力とするデータに係るチャネル（それがサブスクライブするチャネル）の所有者タグがそのまま与えられるものとする。
【００５９】
特権フロー関数が出力するデータに係るチャネルには、詳しくは後述するが、当該特権フロー関数内に記載された情報に基づいて、所有者タグが設定される。
【００６０】
ただし、自由フロー関数の出力データのチャネルや、外部から入力したデータのチャネルについては、実際には、入力とするデータに係る所有者タグが複数になり得る（複数のチャネルにサブスクライブする場合に、所有者タグが複数になる）。そこで、それを示すために、自由フロー関数の出力データのチャネルや、外部からデータしたデータのチャネルについて、それらに与えられる所有者を示す情報を、「所有者タグセット」と呼ぶ。
【００６１】
所有者タグセットは、所有者タグ及び又は所有者タグセットを並列で結合した形であり、本実施形態では、それぞれの所有者タグ及び又は所有者タグセットに含まれる所有者の識別子の積集合として定義するものとする。
【００６２】
例えば、管理者と利用者とが別々の環境の場合（例えば、貸しオフィスにおける、ビル管理者とテナントとの関係のような場合）において、個々の利用者が占有している設備については、当該利用者のみを含む所有者タグを設定し、管理者と個々の利用者とが共有している設備については、管理者と当該利用者とを含む所有者タグを設定する。例えば、図４に示すように、「ビル利用者１」と「ビル管理者」とからなる「所有者タグ１」のデータと、「ビル利用者２」と「ビル管理者」とからなる「所有者タグ２」のデータとの両方を用いた自由フロー関数による演算の結果であるデータを考えると、そのデータに係るチャネルに付与される所有者タグは、それらのタグを形成する集合の積集合となり、この場合、「所有者タグ１」と「所有者タグ２」に共通する「ビル管理者」となる。よって、この演算結果のデータは、「ビル管理者」を含む「所有者タグ」を持つ場合にのみ利用可能、すなわち、そのデータに係るチャネルにサブスクライブ可能となる（ビル管理者の所有者ＩＤ以外の所有者ＩＤを一つでも含む所有者タグを持つ場合は、適合しないことになる）。
【００６３】
図５に、所有者タグセットを所有者タグが充足するかどうかを検証するアルゴリズム（共通サブルーチン）の例を示す。
【００６４】
作用装置５は、通信機能を持ち、要求処理装置１へデータを送信する装置である。作用装置６は、通信機能を持つ、求処理装置１からデータを受信する装置である。本実施形態では、作用装置５は、例えばセンサなどの環境との相互作用を行う機能を持ち、作用装置６は、例えばアクチュエータなどの環境との相互作用を行う機能を持つ。
【００６５】
バブリッシャとなる作用装置５は、データ（例えばセンサの観測値）をチャネルに出力し、サブスクライバとなる作用装置６は、チャネルからテータ（例えばアクチュエータの命令）を与えられる。
【００６６】
作用装置５，６には、それぞれ、任意数の所有者の組からなる所有者タグが設定される。所有者タグは、作用装置５がパブリッシュしたデータが流れるチャネルにおいては、所有者タグセットを構成し、該所有者全てが関係者である作用装置６だけしかデータを受信（サブスクライブ）できないことを規定する（所有者タグセットは、各入力の積集合により規定されるため）。逆に、あるチャネルのデータ受信のためのサブスクライブ要求においては、該チャネルに設定された所有者タグセットが作用装置６の所有者タグを包含していればサブスクライブ可能である。
【００６７】
要求処理装置１は、ユーザ装置２と作用装置５，６との間の仲立ちを行う。要求処理装置１は、各作用装置５，６が利用するチャネルを管理し、データの送受信の宛先管理を行う。同時に、ユーザ装置２により与えられたフロー関数を実体化し、データ処理を行う。
【００６８】
要求処理装置１のＰｕｂ−Ｓｕｂブローカ１３は、前述したように、パブリッシュ・サブスクライブ・モデルにおけるブローカの役割に相当する役割を担う。すなわち、作用装置５からデータを受信し、また、作用装置６へデータを送信するユニットである。Ｐｕｂ−Ｓｕｂブローカ１３は、例えば、パブリッシュとサブスクライブの各動作に関して、Ｐｕｂ−Ｓｕｂ検証部１６により保護される。また、前述したように、各チャネルには、入力データの源（パブリッシャ）に基づく所有者タグが規定される。
【００６９】
Ｐｕｂ−Ｓｕｂ検証部１６は、作用装置５からデータを受信するのに先立って（例えば、パブリッシュ受け付け時に）、その作用装置５の所有者タグが、当該要求処理装置１の所有者タグに適合することを検証するとともに、作用装置６へデータを送信するのに先立って（例えば、サブスクライブ時に）、その作用装置６の所有者タグが、当該要求処理装置１の所有者タグに適合することを検証するユニットである。Ｐｕｂ−Ｓｕｂブローカ１３は、前者の検証に成功した場合にのみ、作用装置５からデータを受信することが可能になる（あるいは、作用装置５のパブリッシュが可能になる）。また、後者の検証に成功した場合にのみ、作用装置６へデータを送信することが可能になる（あるいは、作用装置６のサブスクライブが可能になる）。
【００７０】
自由ＦＦ実行環境１４及び特権ＦＦ実行環境１５は、それぞれ、自由フロー関数及び特権フロー関数を実行するための実行環境である。いずれも、例えばＪａｖａのサンドボックス付き仮想マシン（すなわち、実行できる操作に制約を付けたプログラム実行環境）などを用いて構築することができる。
【００７１】
自由ＦＦ実行環境１４は、自由フロー関数を実行するユニットである。自由フロー関数は、データ処理の内容を任意に設定可能である。また、特権フロー関数と異なり、自由フロー関数の正当性の検証は不要である。自由ＦＦ実行環境１４は、自由ＦＦ所有者タグ設定部１７に保護される。
【００７２】
自由フロー関数自身は、特権フロー関数と異なり、所有者タグに対する操作が許されず、全ての入力チャネルから合成された所有者タグセットを、出力のチャネルに設定しなければならない。このタグセットの設定を強制する保護機構が、自由ＦＦ所有者タグ設定部１７である。
【００７３】
自由ＦＦ所有者タグ設定部１７は、実行された自由フロー関数が出力したデータに係るチャネルの所有者タグセットを、自由フロー関数が入力するデータに係るチャネルの所有者タグに基づいて設定するユニットである。例えば、自由フロー関数が入力するチャネルが一つの場合には、該チャネルに係る所有者タグと同一のもの（１又は複数の所有者）に設定し、自由フロー関数が入力するチャネルが複数の場合には、該複数のチャネルのすべてに共通して所有者となっているもの（１又は複数の所有者）のみを設定する（すなわち、全チャネルの所有者タグについて論理積を取る）。
【００７４】
特権ＦＦ実行環境１５は、特権フロー関数を実行するユニットである。特権フロー関数は、データ処理の内容を任意に設定可能である。また、特権フロー関数は、その出力データを流すチャネルの所有者タグを操作することができる。特権ＦＦ実行環境１５は、特権ＦＦ署名検証部１８に保護される。
【００７５】
特権フロー関数は、上記のように出力チャネルの所有者タグを操作できるので、特権フロー関数に任意のものがロードされてしまうと、データ漏洩に繋がるなどの危険性があるため、コードの正当性の検証を行う必要がある。この検証を行い、検証に成功したコードのみを特権フロー関数として実行することを強制する保護機構が、特権ＦＦ署名検証部１８である。
【００７６】
特権ＦＦ署名検証部１８は、特権フロー関数の正当性を検証するユニットである。特権ＦＦ実行環境１５は、この検証に成功した場合にのみ、特権フロー関数を実行することが可能である。
【００７７】
例えば、特権フロー関数を、事前に要求処理装置１に設定された管理者等の電子鍵（電子鍵は、例えば、公開鍵でも良いし、共有鍵でも良い。）による電子署名が為されたものに限ることとする（この署名の検証に成功したコードのみが特権フロー関数として実行可能になる）。
【００７８】
例えば、（その出力チャネルの所有者タグセットを操作するための情報を含む）特権フロー関数に、施設管理者Ｘの電子鍵による電子署名を付与するものとした場合において、ある特権フロー関数が施設管理者Ｘにより定義されたものであることは、例えば、特権ＦＦ実行環境１５に設定された管理者Ｘの電子鍵と、その特権フロー関数に付随して得られた電子署名とにより検証することができる。この検証は、例えば、一般的な公開鍵暗号での検証と同様で構わない。
【００７９】
一方、特権ＦＦ実行環境１５で特権フロー関数が実行された場合に、その実行された特権フロー関数が出力するデータを流すチャネルに係る所有者タグは、（自由フロー関数の場合と異なって、）当該特権フロー関数内に記載されている情報（所有者を指定する情報）に基づいて特権ＦＦ実行環境１５により設定される。
【００８０】
出力チャネルの所有者タグを操作する方法としては、幾つかの方法が可能である。例えば、特権フロー関数が入力したデータのチャネルに係る所有者タグにかかわらずに、出力チャネルの所有者タグを、当該特権フロー関数内に記載されている情報が示す所有者のみを含む内容に強制的に設定する方法がある。また、例えば、特権フロー関数が入力したデータのチャネルに係る所有者をもとに上記の自由フロー関数と同様にして求めた所有者タグに、当該特権フロー関数内に記載されている情報が示す所有者タグを追加したものを、出力チャネルの所有者タグに設定する方法も可能である（また、追加の他に、削除、変更などの操作を加えることも可能である）。
【００８１】
図６に、特権フロー関数の内容（定義テーブル）の一例を示す。この例では、特権フロー関数の定義は、（ａ）該特権フロー関数のコード、（ｂ）入力チャネルが満たすべき所有者タグセット、（ｃ）出力チャネルに設定される所有者タグ、（ｄ）署名者ＸのＩＤ、（ｅ）署名時刻、（ｆ）有効期限の組により行う。
【００８２】
検証は、特権フロー関数の定義情報を含む情報の組を、所定の方法（例えば、各々のビット列表現を結合することによる、などの方法）によりビット列に変換し、このビット列に対して署名者Ｘの秘密鍵で署名を行い、特権ＦＦ実行環境１５には、検証のため署名者Ｘの公開鍵を設定する、などといったプロセスで行うことができる。
【００８３】
以上６項目のうち、（ｂ）の所有者タグセットについては、例えば、対象となるチャネルの所有者タグが、（ｂ）の所有者タグセットに包含される場合に、そのチャネルを受け付けることができるとする方法の他に、例えば、対象となるチャネルの所有者タグが、（ｂ）の所有者タグセットに一致する場合にのみ、そのチャネルを受け付けることができるとする方法なども可能である。なお、（ｂ）の入力チャネルが満たすべき所有者タグセットは、空でも良い。（ｂ）が空の場合は、この特権フロー関数は、どのようなチャネルをも入力とすることができる（どのようなデータも入力として受け付けることができる）ものとする。なお、（ｂ）のフィールドを空にする変わりに、予め定められた値を記載しても良い。
【００８４】
また、（ｃ）の出力チャネルに設定される所有者タグは、空でも良い。（ｃ）が空の場合は、この特権フロー関数の出力データを流すチャネルは、どのサブスクライバでもサブスクライブできる。この場合に、そのチャネルの所有者タグは、例えば、空にする方法、予め定められた値を記載する方法などが考えられる（すなわち、全ての所有者の論理和を示す状態あるいは全ての所有者の論理和を示す情報が記載された状態にすれば良い）。なお、（ｃ）のフィールドを空にする変わりに、予め定められた値を記載しても良い。
【００８５】
なお、特権フロー関数として、何も処理をせずに、出力チャネルの所有者タグを操作するだけのものも、実行可能である。この場合には、（ａ）の該特権フロー関数のコードに、何もしないコード（あるいは、入力をそのまま出力するコード）を記載すればよい。
【００８６】
なお、電子署名の生成やその認証のための構成・手順としては、どのようなものを採用しても構わない。その際、（ｄ）署名者ＸのＩＤ、（ｅ）署名時刻、（ｆ）有効期限の部分は、採用する構成・手順に応じて、適宜修正して構わない。
【００８７】
特権フロー関数の実行には、その正当性の検証に成功する必要があり、そのために例えば電子署名等の情報を特権フロー関数に付与することについては、例えばシステムの管理者による権限を有する者等のみが可能であるので、管理者等のみが、上記の（ａ）該特権フロー関数のコード、（ｂ）入力チャネルが満たすべき所有者タグセット、（ｃ）出力チャネルに設定される所有者タグを規定することが可能である。
【００８８】
さて、利用者は、１以上のフロー関数（自由フロー関数及び又は特権フロー関数）を利用することによって、所望のデータ処理機能を実現することができる。ただし、利用者が所望する作用装置６の所有者タグが、送信対象となるデータのチャネルに係る所有者タグに適合しない限り、その作用装置６は、そのデータを受信することができない。利用者は、例えば管理者等の許諾等をもって、特権フロー関数によって、そのデータのチャネルに係る所有者タグを、利用者が所望する作用装置６の所有者タグが適合するようなものに設定することができ、この結果、その作用装置６は、そのデータを受信することができるようになる。
【００８９】
ＦＦコードロード部１２は、例えばＪａｖａで言うところのクラスローダに相当するものであり、自由ＦＦ実行環境１４及び特権ＦＦ実行環境１５でそれぞれ実行する個々の自由フロー関数及び特権フロー関数の実行イメージを、適切に設定されたファイル又はネットワークに接続されたサーバ等であるＦＦコードレポジトリ４からロードする。ここでいう「適切な設定」とは、フロー関数の名前からロードすべき実行イメージの場所が分かることであり、静的に設定されていても良いし、フロー関数の識別を実行イメージの識別子で行う（すなわち、フロー関数を指定することは、実行イメージを指定することに等しい状態にする。）ことによっても良い。
【００９０】
要求受付部１１は、要求配置装置３から、フロー関数の実体化を要求するフロー関数実体化要求を受け付ける。要求配置装置３からのフロー関数実体化要求は、少なくとも｛実体化すべきフロー関数の識別子，フロー関数のサブスクライブ先｝の組を含む。なお、要求配置装置３と要求処理装置１との間には、適切なセキュリティの設定が行われていることが望ましい。これは、例えば、pre-shared keyや公開鍵認証などの良く知られた方法により相互に認証を行うことによって実装することができる。
【００９１】
ユーザ装置２は、センサネットワーク等のシステムの利用者が、これに対するユーザ要求を記述し、要求配置装置３に送出する装置である。利用者により記述されたユーザ要求は、フロー関数の選択と、その入出力に関連付けられたチャネルのリンク（グラフ）で定義する。
【００９２】
要求配置装置３は、ユーザ装置２が記述したユーザ要求を、要求処理装置１に配置する。要求配置装置３は、情報処理システムに含まれる要求処理装置１とその所有者タグとを管理し、ユーザ装置２の要求に含まれるフロー関数を、所有者タグの条件を満たす要求処理装置１に生成する。
【００９３】
なお、個々のフロー関数は、サブスクライバであるので、サブスクライブ先の所有者タグによって入力の所有者タグセットが決定される。
【００９４】
入力の所有者タグセットは、Ｐｕｂ−Ｓｕｂブローカ１３における外部からのサブスクライブ要求に対する検証のアルゴリズムによって検証可能である。図７に、そのアルゴリズム例を示す。図７の例では、サブスクライバ先のチャネルの所有者タグセットが、サブスクライバの所有者タグを包含する場合に、充足（適合）となる。
【００９５】
また、出力の所有者タグセットは、特権フロー関数の場合は、特権フロー関数の定義により決定される。自由フロー関数の場合は、自由ＦＦ実行環境１４における出力チャネルの所有者タグのセットの設定のアルゴリズムにより決定される。図８に、そのアルゴリズム例を示す。
【００９６】
出力の所有者タグセットは、Ｐｕｂ−Ｓｕｂブローカ１３のＰｕｂ−Ｓｕｂ検証部１６におけるパブリッシュ受付時の検証のアルゴリズムにより検証可能である。図９に、そのアルゴリズム例を示す。
【００９７】
要求配置装置３が受け付けた個々のフロー関数は、入出力２つの検証を満たす要求処理装置１に順次配置される。なお、入力が決定されないと出力の所有者タグセットは、決定できないため、配置は、入力寄り（センサ等の作用装置５寄り）から開始し、順次、出力寄り（アクチュエータ等の作用装置６寄り）に向かって配置を行う。
【００９８】
図１０に、本実施形態の情報処理システムの要求配置の動作手順の一例を示す。
【００９９】
ユーザ装置２から要求配置装置３へ、利用者により記述されたユーザ要求が送信される（ステップＳ１）。
【０１００】
要求配置装置３は、受信したユーザ要求を、適切な要求処理装置１へ転送する（ステップＳ２）。該要求を受信した要求処理装置１では、要求受付部１１で、該ユーザ要求を受け付ける。
【０１０１】
要求受付部１１は、受け付けたユーザ要求を、ＦＦコードロード部１２へ送る（ステップＳ３）。
【０１０２】
ＦＦコードロード部１２は、与えられたユーザ要求に基づいて、適切な実行イメージをＦＦコードレポジトリ４からロードして、自由ＦＦ実行環境１４及び又は特権ＦＦ実行環境１５へ与える（ステップＳ４）。
【０１０３】
図１１に、作用装置４のパブリッシュ受け付け時、要求処理装置１の要求配置時及び作用装置５のサブスクライブ時に検証を行う場合の動作手順の一例を示す。ここでは、自由フロー関数と特権フロー関数が実行される場合を例にとって説明する。
【０１０４】
まず、Ｐｕｂ−Ｓｕｂ検証部１６が、パブリッシャである作用装置５について、所有者タグに基づく検証を行う（ステップＳ１１）。検証に失敗した場合には（ステップＳ１２）、この時点でエラーとなる（ステップＳ１４）。
【０１０５】
検証に成功した場合に（ステップＳ１２）、Ｐｕｂ−Ｓｕｂブローカ１３は、このデータを流すチャネルに、作用装置５と同じ所有者タグを付与する（ステップＳ１３）。
【０１０６】
次に、自由ＦＦ所有者タグ設定部１７は、上記チャネルにサブスクライブする自由フロー関数の出力データを流すチャネルに、所有者タグの設定を行う（ステップＳ１５）。
【０１０７】
次に、特権ＦＦ署名検証部１８は、上記チャネルにサブスクライブする特権フロー関数について、署名の検証を行う（ステップＳ１６）。検証に失敗した場合には（ステップＳ１７）、この時点でエラーとなる（ステップＳ１９）。
【０１０８】
検証に成功した場合に（ステップＳ１７）、特権ＦＦ実行環境１５は、この特権フロー関数の出力データを流すチャネルに、所有者タグを設定する（ステップＳ１８）。
【０１０９】
次に、Ｐｕｂ−Ｓｕｂ検証部１６が、サブスクライバである作用装置６について、所有者タグに基づく検証を行う（ステップＳ２０）。検証に失敗した場合には（ステップＳ２１）、この時点でエラーとなる（ステップＳ２２）。
【０１１０】
検証に成功した場合に（ステップＳ２１）、このフローが可能となる。
【０１１１】
なお、上記手順は、自由フロー関数や特権フロー関数の有無やその数に応じて、適宜変更される。まず、個々の自由フロー関数に応じて、ステップＳ１５の部分が実行される。自由フロー関数が実行されない場合には、ステップＳ１５の部分は省かれる。また、個々の特権フロー関数に応じて、ステップＳ１６〜Ｓ１９の部分が実行される。特権フロー関数が実行されない場合には、ステップＳ１６〜Ｓ１９の部分は省かれる。また、自由フロー関数に対応するステップＳ１５の部分や、特権フロー関数に対応するステップＳ１６〜Ｓ１９の部分は、フロー関数が実行される順番に従って実行される。
【０１１２】
ところで、上記の所有者タグの設定及び検証は、上記タイミングに加えて（或いは、これに代えて）、実際に作用装置５からデータを受信し、これをフロー関数で処理して、作用装置６に送信するときに行うことも可能である。
【０１１３】
図１２に、この場合の動作手順の一例を示す。ここでは、自由フロー関数と特権フロー関数が実行される場合を例にとって説明する。
【０１１４】
まず、パブリッシャである作用装置５が、所定のタイミングでデータを要求処理装置１へ送信する。要求処理装置１において、該データを受信すると（ステップＳ３１）、Ｐｕｂ−Ｓｕｂ検証部１６がパブリッシャである作用装置５について所有者タグに基づく検証を行う（ステップＳ３２）。検証に失敗した場合には（ステップＳ３３）、この時点でエラーとなる（ステップＳ３５）。
【０１１５】
検証に成功した場合に（ステップＳ３３）、Ｐｕｂ−Ｓｕｂブローカ１３は、このデータを流すチャネルに、所有者タグを設定する（ステップＳ３４）。
【０１１６】
次に、自由ＦＦ実行環境１４は、上記チャネルから受け取ったデータを入力として、自由フロー関数を実行する（ステップＳ３６）。自由ＦＦ所有者タグ設定部１７は、自由フロー関数の出力データを流すチャネルに、所有者タグを設定する（ステップＳ３７）。
【０１１７】
次に、特権ＦＦ署名検証部１８は、上記チャネルにサブスクライブする特権フロー関数について、署名の検証を行う（ステップＳ３８）。検証に失敗した場合には（ステップＳ３９）、この時点でエラーとなる（ステップＳ４１）。
【０１１８】
検証に成功した場合に（ステップＳ３９）、特権ＦＦ実行環境１５は、上記チャネルから受け取ったデータを入力として、特権フロー関数を実行するとともに、出力データを流すチャネルに、所有者タグを設定する（ステップＳ４０）。
【０１１９】
次に、Ｐｕｂ−Ｓｕｂ検証部１６がサブスクライバである作用装置６について所有者タグに基づく検証を行う（ステップＳ４２）。検証に失敗した場合には（ステップＳ４３）、この時点でエラーとなる（ステップＳ４５）。
【０１２０】
検証に成功した場合に（ステップＳ４３）、Ｐｕｂ−Ｓｕｂブローカ１３が、このチャネルのデータを、作用装置６に送信する（ステップＳ４４）。
【０１２１】
なお、上記手順が、自由フロー関数や特権フロー関数の有無やその数に応じて、適宜変更される点は、図１１の場合と同様である。
【０１２２】
本実施形態により、例えば、管理者と複数の所有者／利用者が存在する環境で、一利用者が、複数の所有者によるデータ（コンテンツ）を混合した状態で操作するフロー関数を定義し、その結果を特権フロー関数経由で匿名化して閲覧する、といったことが可能となる。例えば、複数のテナントが入っているビルがあったときに、個々のテナントの在室人数を合成し、ある閾値を下まわったらビルを節電モードで動作させる、などといったプログラムを、外部のＥＳＣＯ事業者がビル上で実行できる。このとき、本来テナント毎の秘密情報である在室者リストを、外部事業者が操作するプログラムを書き、この秘密性を削除する特権ＦＦ（人数のみの情報に落とすなど）によりそのプログラムの結果のみを受け取ることが可能になる。
【０１２３】
以下、本実施形態の情報処理システムをビル管理システムに適用した幾つかの具体例を用いて説明する。
【０１２４】
＜第１の具体例＞
まず、図１３〜図１６を参照しながら、第１の具体例として、サービス会社との連携の例について説明する。なお、図１４は、所有者タグが適合しないチャネルへのサブスクライブが成功しない例（フロー関数を用いない場合）であり、図１５は、自由フロー関数が出力チャネルの所有者タグを変更しないため、所有者タグが適合しない例であり、図１６は、正しく署名された特権フロー関数が出力チャネルの所有者タグを変更することによって、所有者タグが適合する例である。
【０１２５】
本具体例は、本実施形態の動作を説明するために単純化した例である。
【０１２６】
あるビルＢに、企業Ｘが入居しているとする。なお、簡単のため、ここでは、ビルＢは企業Ｘの持ちビルであり、企業Ｘがビル管理者であるとする。企業Ｘには、プリンタが一つ存在し（プリンタをＰ１とする。）、プリンタＰ１のプリンタ用紙の補充のために、サービス会社Ｓが存在する。企業Ｘは、プリンタ用紙が切れないように、また、過大なストックを置かないように、サービス会社Ｓにプリンタ用紙の管理を委託する。ただし、いつ何枚のプリントアウトを行ったかという情報、あるいは、任意の時点での用紙の残量の情報などをサービス会社Ｓに通知することは、企業Ｘにとっては例えば事業活動の活発度などを知らせることと等しいため、望ましくない。
【０１２７】
そこで、本実施形態により、以下のような構成が可能になる。
【０１２８】
プリンタＰ１を、作用装置５として動作するものとし、所有者タグとして企業Ｘの所有者ＩＤをセットする。企業Ｘは、一つの要求処理装置１を持つ。要求処理装置１には、企業Ｘの所有者ＩＤとサービス会社Ｓの所有者ＩＤからなる所有者タグをセットする。これらは、企業Ｘにより管理される一つの要求配置装置３に接続され、サービス会社Ｓは、ユーザ装置２を経由して任意のプログラムを投入することができる。
【０１２９】
サービス会社Ｓは、作用装置６として、サービス会社Ｓの所有者タグがセットされた用紙切れ警報機Ａを持つ。用紙切れ警報機Ａは、例えば、回転灯のようなものでも良いし、担当者に電子メールなどで用紙切れを通知する装置でも良い。また、ロボットや宅配便・地域内物流サービスなどを用いて半自動的に企業Ｘに用紙を配送する装置でも良い。
【０１３０】
プリンタＰ１は、用紙が使用される度に用紙の残量を数値で出力する。ここでは、例えば、企業Ｘは、「用紙の残量が１００枚を下回ったときにＴｒｕｅを返す」という用紙残量閾値判定関数ｆｔｈを、特権フロー関数として登録する。この特権フロー関数の出力所有者タグは、サービス会社Ｓの所有者ＩＤとする。ただし、特権フロー関数は、登録時に、企業Ｘによる署名が必要である。なお、この特権フロー関数は、例えば擬似コードで作成される。図１３に、用紙残量閾値判定関数ｆｔｈの擬似コード（ｔｈｒｅａｓｈｏｌｄ関数）の例を示す。
【０１３１】
ここで、サービス会社Ｓが、プリンタＰ１の用紙残量の出力を取得するケースと、自由関数によりプリンタＰ１の用紙残量の出力を加工した結果を取得するケースについて考える。
【０１３２】
用紙残量をそのまま用紙切れ警報機Ａに与えるものとした場合、図１４に示すように、プリンタＰ１の用紙残量の出力には、企業Ｘの所有者タグが与えられており、よって、出力チャネルには、企業Ｘの所有者タグが与えられるが、一方、用紙切れ警報機Ａには、サービス会社Ｓの所有者タグが与えられているので、用紙切れ警報機ＡがプリンタＰ１の出力チャネルをサブスクライブしようとしても、Ｐｕｂ−Ｓｕｂ検証部１６によりブロックされる。
【０１３３】
また、図１５に示すように、サービス会社Ｓが導入した自由フロー関数を経由して用紙切れ警報機Ａにデータを与えようとしても、同様に、自由ＦＦ所有者タグ設定部１７により自由フロー関数の出力に企業Ｘの所有者タグセットが与えられ、この出力チャネルを用紙切れ警報機Ａがサブスクライブしようとするときに、Ｐｕｂ−Ｓｕｂ検証部１６によりブロックされる。
【０１３４】
そこで、サービス会社Ｓが、用紙切れ警報機Ａに、サービスのための情報を与えるためには、図１６に示すように、用紙残量閾値判定関数ｆｔｈ（特権フロー関数）を経由させれば良い。この特権フロー関数は、企業Ｘにより署名されており、サービス会社Ｓは、その内容を操作することはできない。しかし、サービス会社Ｓがユーザ装置２から要求配置装置３に与えるプログラムの途中に、特権フロー関数を導入することが可能である。特権ＦＦ実行環境１５により、その出力の所有者タグセットにはサービス会社Ｓのみが与えられるため、その結果を用紙切れ警報機Ａで受信することができる。
【０１３５】
以上から得られる、サービス会社Ｓがサービスを実行するためのプログラムの単純な例は、プリンタＰ１の出力チャネルを用紙残量閾値判定関数ｆｔｈ（特権フロー関数）の入力とし、その出力を用紙切れ警報機Ａがサブスクライブすることにより、用紙１００枚未満となったことを検出するものである。
【０１３６】
ここで、さらにサービス会社Ｓがサービス向上のために、動的にプリンタＰ１の用紙残量の減り方を予測したいとする。例えば、大きな需要があったときには、残量１００枚になってから補充を手配したのでは間に合わない場合もある。そこで、サービス会社Ｓは、数時間分の用紙残量の履歴を取り、３時間後の用紙残量を線形補完により求める関数ｆｌｉを新しい自由フロー関数として定義し、ＦＦコードレポジトリ４に登録する。そして、プリンタＰ１の出力チャネルを関数ｆｌｉの入力とし、この出力を関数ｆｔｈの入力とする。このとき、関数ｆｌｉの出力は、関数ｆｌｉが自由フロー関数であるため、所有者タグセットとして企業Ｘが設定されており、直接的には用紙切れ警報機Ａで受信することはできない。そこで、先の例と同様、関数ｆｔｈを経由することにより、企業Ｘがサービス会社Ｓに対して認めた情報出力となり、サービス会社Ｓは、新しい関数による計算結果を、閾値関数の出力として得ることができる。
【０１３７】
＜第２の具体例＞
次に、図１７，１８を参照しながら、第２の具体例として、ビル内機器のアクセス制御の例について説明する。なお、図１７は、２つのテナントにより共用される設備の例であり、図１８は、特権フロー関数をアカウンティングの窓口として利用する例である。
【０１３８】
第１の具体例に類似する例として、ビル内機器へのアクセス制御とアカウンティングとを同時に行う例について説明する。本具体例では、ビルには、「個別フロア空調設備」、「共通空調設備」、「給湯設備」、「エレベータ設備」、「照明設備」、「フロア共有のコピー機」、「フロア共有のプリンタ」などが存在するものとする。それぞれの設備・機器は、既知のプロトコルなどを用いた通信手段により設備機器ネットワーク上からアクセス可能であるものとする。また、ビルには、複数のテナントが入っており、本具体例では、１Ｆに「テナントＴ１」が、２Ｆに「テナントＴ２ａ」と「テナントＴ２ｂ」が入居しているものとする。また、ビルには管理者が存在し、これを「ビル管理者ＢＡ」とする。
【０１３９】
ここで、本具体例では、ビル管理者あるいはテナントのユーザ装置２が存在するとする。また、テナントが貸与され管理する要求処理装置１として、テナントＴ１の要求処理装置１と、テナントＴ２ａとテナントＴ２ｂに共用の要求処理装置１が存在するとする。また、テナントＴ１の要求処理装置１には、「テナントＴ１とビル管理者ＢＡの所有者タグ」が設定され、テナントＴ２ａとテナントＴ２ｂに共用の要求処理装置１には、「テナントＴ２ａとテナントＴ２ｂとビル管理者ＢＡの所有者タグ」が設定されているものとする。なお、これら要求処理装置１は、物理的に独立した個々の装置であっても良いし、共有されたハードウェアにソフトウェア的に保護された各々の領域に仮想的に構築されたものであっても良い。
【０１４０】
また、ビル内には、被制御機器が存在する。これらには、フロア共有機器（フロア空調設備・照明設備等）、設備全体での共有機器（エレベータ等）が存在する。これらの被制御機器は、ビル管理者が直接管理するものであり、テナントが自由に制御できるものではない。そのため、これらの機器には、「ビル管理者ＢＡの所有者タグ」をセットする。なお、テナント向け制御盤に相当する機器には、「テナントの所有者タグ」がセットされるものとする。
【０１４１】
本具体例では、２Ｆに設置された空調を代表例として説明する。２Ｆの空調設備を「ＡＣ」とする。２Ｆのテナントに設置された制御盤について、テナントＴ２ａにおけるものを「制御盤ＣＴ２ａ」と、テナントＴ２ｂにおけるものを「制御盤ＣＴ２ｂ」とする。空調設備ＡＣには、「ビル管理者ＢＡの所有者タグ」が設定され、制御盤ＣＴ２ａには、「テナントＴ２ａの所有者タグ」が設定され、制御盤ＣＴ２ｂには、「テナントＴ２ｂの所有者タグ」が設定されているものとする。
【０１４２】
ここで、各々のテナントは、自由に空調が設定できるものとする。ただし、テナントの従業員は、制御盤ＣＴ２ａ又は制御盤ＣＴ２ｂに規定室温と動作要求（ＯＮ／ＯＦＦ）を入力し、制御盤ＣＴ２ａ及び制御盤ＣＴ２ｂは、それぞれ、具備する室温計から空調設備ＡＣへの動作／非動作を入力するものとする。
【０１４３】
以上のプログラムを略式に記述すると図１７のように記述できる。
【０１４４】
なお、制御盤ＣＴ２ａ及び制御盤ＣＴ２ｂは、以下の原理で動作する。入力は、規定室温（度）・動作要求（ｏｎ／ｏｆｆ）・室温計（度）である。出力は、空調制御要求（ｏｎ／ｏｆｆ）である。動作要求がｏｆｆのときには、出力はｏｆｆである。動作要求がｏｎであれば、規定室温と室温計を比較し、室温計入力が規定室温よりも高ければｏｎを、そうでなければｏｆｆを出力する。
【０１４５】
さて、ここで、制御盤ＣＴ２ａ及び制御盤ＣＴ２ｂは、それぞれ、所有者タグとしてテナントＴ２ａ及びテナントＴ２ｂを持つ。これを直接的には空調設備ＡＣの入力とはできない。なぜならば、空調設備ＡＣは、ビル管理者ＢＡの所有者タグを持ち、テナントＴ２ａとテナントＴ２ｂを出力として持つチャネルを、サブスクライブすることができないからである。
【０１４６】
一方、ビル管理者は、どのテナントがどの程度空調設備を利用しているかを知りたいものとする。これは、例えば、別途従量制の課金を行っている場合もあり、また、そうでなくても、例えば、計画節電のために過度の利用に対し制約をかける必要がある場合などがあるからである。
【０１４７】
そこで、ビル管理者は、各々の制御盤からの入力を受け、出力の所有者タグをビル管理者ＢＡとするアカウンティング特権フロー関数ｆａｃを用意する。これは、対となるアカウンティングデータベースを持ち、関数ｆａｃに対してｏｎの制御命令、つまり空調を動作させる命令が通ったときに、その累計時間を計量しアカウンティングデータベースに記録するものである。また、利用量が計画量に比べて著しく高い場合は、ｏｎの制御命令を差し止める機能を持たせても良い。
【０１４８】
ここで、関数ｆａｃは、テナント毎に用意される。例えば、テナントＴ２ａに向けたｆａｃは、入力チャネルが持つべき所有者タグセットとしてテナントＴ２ａが設定され、誤って又は故意にテナントＴ２ｂが空調をテナントＴ２ａへの課金により動作させることができない。もちろん、アカウンティングデータベースもテナント毎に用意される。一方、出力となる所有者タグセットは、ビル管理者ＢＡのものとなる。この特権フロー関数を経由させることにより、前述の擬似プログラムは、図１８のようになる。ここで、テナントＴ２ａ向けｆａｃをＦＡＣ＿Ｔ２ａ、テナントＴ２ｂ向けｆａｃをＦＡＣ＿Ｔ２ｂと記述する。
【０１４９】
以上の構成により、テナントからの要求を受け付けつつ、アクセス管理によりアカウンティングを実現する実例を示した。なお、各テナントは、独自に、制御盤の出力部分に、残業申請システムや空調の時間外動作の許認可を行うワークフローシステムを組み込んでも良い。
【０１５０】
＜第３の具体例＞
次に、図１９を参照しながら、第３の具体例として、ビル内機器制御と在室管理の連動の例について説明する。なお、図１９は、空調制御の例である。
【０１５１】
第２の具体例を拡張して、ビル内機器制御と在室管理とを連動させる例について説明する。ビルの機器及びテナントは、特に述べない限り第２の具体例と同様であるとする。
【０１５２】
テナントの入居者は、ビルのセキュリティシステムに接続された入退室管理システムを持ち、テナントの従業員又は出入りのある契約業者（清掃業者等）の従業員等が、それぞれ、カードキーにより施錠されたゲート（１ＦのゲートをＧ１、２ＦのゲートをＧ２とする。）を通過するものとする。ただし、各テナントの従業員に関しては、誰がいつゲートを通過したか、については、各企業の秘密事項であることから、ビルの管理者は、直接的には得ることができないという契約であるとする。
【０１５３】
なお、ゲートから出てくる情報は秘密であるので、ビル管理者は、直接的にはデータを取得できないようになっている。従って、ゲートＧ１には「テナントＴ１の所有者タグ」のみが設定され、ゲートＧ２には「テナントＴ２ａとテナントＴ２ｂの所有者タグ」のみが設定されており、ビル管理者ＢＡが持つ出力機器（「ビル管理者ＢＡの所有者タグ」が設定されている。）においては、ゲートＧ１／Ｇ２の情報は受信できない。
【０１５４】
ここで、テナントとビル管理者との合意により、ビル管理者は、入室している人数を知ることができるものとする。この合意は、例えば、ＩＤの一覧からその長さを得て、その出力の所有者タグをビル管理者ＢＡとする特権フロー関数を、当該テナントが導入することによって、達成することができる。ビル管理者は、例えばこの在室人数をもとに、電源計画を調整することができる。この様子を図１９に示す。
【０１５５】
図２０では、特権フロー関数Ｃ１ＦがゲートＧ１の出力（入室，カードキーＩＤ）又は（退室，カードキーＩＤ）の列を読み、現在の１Ｆの在室人数に変換する。同時に、特権フロー関数Ｃ２Ｆは、ゲートＧ２の出力を読み、２Ｆの在室人数に変換する。
【０１５６】
これらは、以下のアルゴリズムで動作可能である。
１．在室者セットを空で初期化する。
２．ゲートからの入力を待ち、入力に応じて以下のどちらかを実行する。
入室イベント在室者セットにカードキーＩＤを登録する。
退室イベント在室者セットからカードキーＩＤを削除する。
３．在室者セットの数を数え、これを出力する。
４．手順２に戻る。
【０１５７】
なお、ここで言うセットとは、重複を許さない集合を実現するデータ構造である。
【０１５８】
ビル管理者ＢＡは、この出力を自分が管理する要求処理装置１で受信することができる。
【０１５９】
在室人数と、個々のテナントとの間で取り交したサービスレベル合意から、１Ｆの空調機ＡＣ１の出力と２Ｆの空調機ＡＣ２の出力を制御することができる。ここでは、１Ｆの空調機ＡＣ１の制御を行う自由フロー関数及び２Ｆの空調機ＡＣ２の制御を行う自由フロー関数を、それぞれ、ＡＣＭ１及びＡＣＭ２で表した。
【０１６０】
この例では、サービスレベル合意は、以下の２項目の組み合わせのリストで取り交されるとする。現時点での在室人数によって、空調出力が制限される仕組みである。これにより、在室人数が少なくなるにつれ省エネ運転となり、在室人数が多いときは、快適運転とすることができる。
・ｔ：最低在室人数閾値（整数）
・ｍ：最大空調出力（０−１００）
ＡＣＭ１とＡＣＭ２は、いずれも、以下のような動作を行う。
１．仮の最大出力値ｏを０で初期化する
２．入力を待ち、その人数をｐに記録する
３．サービスレベル合意のリストから順番に要素を取り出し、それぞれのｔとｐについて、
・ｐがｔと等しいかより大きい場合
ｏ＝ｍａｘ（ｏ，ｍ）
４．結果のｏを出力する
５．手順２に戻る
＜第４の具体例＞
次に、図２０を参照しながら、第４の具体例として、ＥＳＣＯ事業と在室管理の連動の例について説明する。なお、図２０は、ビル全体の電源制御と、在室管理との連動の例を示す。
【０１６１】
ＥＳＣＯ(Energy Service COmpany)と呼ばれる事業形態は、特定の事業所のエネルギー消費を最適化（節電）することを事業として請け負うものである。
【０１６２】
ここで、あるビルに対する最適なＥＳＣＯ事業に対して、本発明を実施する例を説明する。なお、特に説明のない限り、この具体例は、ここまでの具体例の環境と同様の環境にあるとする。
【０１６３】
ここで、ＥＳＣＯ事業者がビルの管理者と契約し、契約に基づきビル内の設備・機器の電源制御を行うものとする。一方、各テナントに誰がいつ入室して、いつ退室したか、という情報は、利用の仕方によっては、各テナントのビジネスの動きを推測することができる情報であり、ＥＳＣＯ事業者には、この情報を与えてはならない。一方、ＥＳＣＯ事業者は、ビル内の最適な電源制御を行い、ビルの電力効率をより高めることから利益を得る業態であるため、ビル内の人のアクティビティや機器の利用状況を知り、また、詳細に制御することは、有益なことである。
【０１６４】
そこで、本実施形態により、ＥＳＣＯ事業者とビル管理者との間の契約に基づくデータ（制御結果の指標）のみをＥＳＣＯ事業者に渡すことを保証しつつ、実際の制御及び制御結果の指標の算出のためのプログラムは、ＥＳＣＯ事業者に自由に開発させることができる。本実施形態は、外部の事業者による自由なプログラミングと、データ流通の境界制御による情報漏曳の防止とを両立させる。
【０１６５】
その結果、本具体例では、ＥＳＣＯ事業者がより高い能力を発揮し、エネルギー消費／コストの削減に貢献することが期待できる。
【０１６６】
以下、図２０を参照しながら、具体的な具体例を説明する。
【０１６７】
ビル内には、入退室リーダ、エレベータや空調・照明・給湯などの各種被制御機器が存在する。また、数台の要求処理装置１（図示せず）が存在し、それらのうち１台がＥＳＣＯ事業者を含む外部サービス向けの出入口となっている。
【０１６８】
ＥＳＣＯセンターは、別途契約によりビル管理者から入手したビル内の機器構成から、ビル制御に必要なフロープログラムを記述する。記述したプログラムは、ＥＳＣＯセンターに割り当てられたユーザ装置２より要求配置装置３に与えられる。ここで、ＥＳＣＯセンターは、必要であればビル内でデータ処理を行うための自由フロー関数を記述し、要求配置装置３へのプログラム投入に先立ってＦＦコードレポジトリ４に登録する。
【０１６９】
要求配置装置３は、必要に応じてプログラムを分解し、例えば、入退室リーダの入力を受ける部分は、入退室リーダの近傍の要求処理装置１へ、ＥＳＣＯセンターへの出力を制御する部分は、外部向けの要求処理装置１へ、といった要領で、各フロー関数を要求処理装置１に配置する。このとき、それぞれの要求処理装置１に設定された所有者タグの制約条件を満たすようにフロー関数を配置し、要求処理装置１間を接続する。
【０１７０】
具体的に、入退室ゲートＧにテナント所有者タグＴが、空調機器の入力（制御）側と空調機器の出力（監視）側にそれぞれビル管理者の所有者タグＢＡが設置されていたとする。このとき、第３の具体例で説明したのと同様の仕組みで、空調の監視や制御を行うことが出来る。前出の具体例との相違は、ＥＳＣＯセンターはビルの外にあり、また、ビル管理者は複数のＥＳＣＯ事業者を契約によって切り替えて用いることができる点である。
【０１７１】
＜第５の具体例＞
次に、第５の具体例として、電力インフラ事業の例について説明する。
【０１７２】
電力供給が需要に追い付かなくなると、需要家に対して需給調整（例えば、需給調整契約、という契約を結んだ需要家に対して、普段の電力の割引と需給逼迫時の電力カット依頼を行うこと。）を行う場合がある現在は、この需給調整を手動で行っているが、緊急時の対応を除いて自動化することを考える。
【０１７３】
このとき、単一の供給家Ｓと複数の需要家Ｄ１，Ｄ２，．．．を考える。個々の需要家は、需要家の事業所内での電力消費を把握しており、個々の負荷の設定をフロープログラムで記述可能であるとする。具体的な記述は、前出の機器制御の事例（第３の具体例など）と同等である。ここで、需給調整用フロープログラムを事業所内部で記述する。
【０１７４】
需給調整契約は、個々の契約内容に基づき、そのプログラムの入力部に特権フロー関数を用意する。この入力チャネルが満たすべき所有者タグセットにＳを、出力に該需要家Ｄｎを設定する。入力としては、需給調整依頼の程度（需要を何ワット抑えるか）と、その依頼の期限と期間（何時間後までに調整を完了させ、その状態を何時間継続するか）の組み合わせ（タプル）であり、特権フロー関数は、契約内容と需給調整依頼が合致しているかを検証し、検証結果が正しければ、需要家が設定した需給調整用フロープログラムへ需給調整依頼を転送する機能を持つ。
【０１７５】
電力需給逼迫時には、供給家Ｓは、個々の需要家Ｄｎの特権フロー関数に対して需給調整依頼を発行する。個々の需要家は、契約規模やその時点での需要が異なるため、個々の需要家にあわせた需給調整依頼を発行する。なお、需給調整依頼を個々の需要家の契約規模やその時点での需要にあわせて自動生成する機構を導入することもできる。
【０１７６】
また、自動化により、需給調整をする／しないの二段階から、消費可能電力上限を徐々に絞っていくという方式に切り替えることも考えられる。この場合は、需給調整がはじまると
１）空調が弱くなり、サーバ機器なども省エネモードで動作する
２）止めても良い負荷（複数系統のエレベータやオフィスのプリンタなど）が止められる
３）止めても良い（機器保全でない）空調が止められる
４）生産設備の停止計画が優先度順に実行される
といった順序で消費電力削減を実行することで、求められた需給調整に連続的・自動的に対応することができる。
【０１７７】
ただし、生産設備の停止計画については、当然のことながら納入の遅れなどにつながるため、工程管理システムにおける生産能力の優先順位付けや調整と、本具体例で述べた需給調整のシステムが相互に接続している必要がある。例えば、電力削減を実現するために停止させるラインを、停止による損失額から推定し、損失額の少ないものから順に停止するといったシステムを導入する。
【０１７８】
＜第６の具体例＞
次に、第６の具体例として、交通制御の例について説明する。
【０１７９】
都心部の交通状況は、時々刻々と変わり、また、様々な経済活動に影響を与える情報源となりうる。例えば、混雑状況がリアルタイムに把握できれば、流通の配車計画をそれにあわせて調整することができる。また、センシング技術の発達やネットワーク／ＩＴＳ連動ＧＰＳナビシステムなどの登場にともない、特に車両において、誰がどこをどちらに向けて走っているかを把握することすら可能になってきている。
【０１８０】
ただし、個々の車両の移動情報を把握することは、プライバシ上の懸念も生み出す。この情報は誰でも自由に利用できる、という性質のものではないことは明らかだろう。しかし、どのような形式の情報がより多くの利益を生みだすかを事前に検討することもまた困難である。
【０１８１】
そこで、例えば個々の交通システムの要素技術（例えばナンバープレート認識装置や交通状況画像処理の結果など）においては、本実施形態における要求処理装置１に相当する機能を実装し、それらの情報を加工又は集約した結果を交通システムの外側に提供する段階で、特権フロー関数によるデータの匿名化と検証を行う、ということもできる。この方式であれば、交通システムの内部で用いるためには、プライバシ情報も含む生のデータをそのまま取り扱うことができる一方、外部の利用者へもプライバシ情報の漏出の懸念が少ない状態で情報提供および有効活用が可能になる。
【０１８２】
具体的な特権フロー関数としては、安全でかつ有意義な情報をまず（時刻／時間，カウント）のタプル列に限定し、これ以外は出力しない特権フロー関数が考えられる。これで、個々の時刻又は時間に何台車が通ったのかのみを出力し、いつ／どのような、の判断に関しては、データ利用者側の自由な発想と、自由フロー関数による処理結果に任せる、ということができる。また、将来ニーズの高まりにより新しいデータ形式の出力が求められたときは、新しい特権フロー関数を導入すれば良い。もちろん、より高精細な情報を得られる特権フロー関数を利用するには、何らかの契約により対価を支払う仕組みにしても良く、その場合は、需要者個々の所有者タグを出力にセットした特権フロー関数をＦＦコードレポジトリ４に登録する。
【０１８３】
なお、特権フロー関数と自由フロー関数の実行環境を分割する理由をここで説明する。例えば、センサから得られた生の画像や、ナンバープレート情報などを、出力が許された別の形式にエンコードしなおす（例えば、前のイベントとの時刻差分が１ならビット０、２ならビット１、とすることで任意のデータを時系列データにエンコードできる、など）ことが考えられる。これを許さないために、データの内容を操作する段階（例えばナンバープレートの数値を取得し比較する、あるいは、画像を変換して顏ＤＢと照合する、など）のみにおいて専用の特権フロー関数を用意し、出力は、交通システム所有者の所有者タグとする。一方、自由フロー関数が実行される実行環境では、データへの直接アクセスを行うメソッドの呼び出しは、禁止する（例えばＪａｖａの場合は、サンドボックスの適切な設定により禁止する）。
【０１８４】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１８５】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１８６】
１…要求処理装置、２…ユーザ装置、３…要求配置装置、４…フロー関数コードレポジトリ、５…作用装置、１１…要求受付部、１２…フロー関数コードロード部、１３…パブリッシュ・サブスクライブ・ブローカ、１４…自由フロー関数実行環境、１５…特権フロー関数実行環境、１６…パブリッシュ・サブスクライブ検証部、１７…自由フロー関数所有者タグ設定部、１８…特権フロー関数署名検証部、１３１…パブリッシュ・サブスクライブ処理部、１３２…送受信インタフェース部、１３３…チャネル情報記憶部、１６１…パブリッシャ検証部、１６２…サブスクライバ検証部
【技術分野】
【０００１】
本発明は、データ処理装置、データ処理方法及びプログラムに関する。
【背景技術】
【０００２】
従来のパブリッシュ・サブスクライブ・システムの動的アクセス制御については、例えば特許文献１に、コンテンツの発行者（パブリッシャ）から購読者（サブスクライバ）に至るまでのパブリッシュ・サブスクライブ・ネットワーク（Ｐｕｂ−Ｓｕｂネットワーク）における動的アクセス制御機構が開示されている。このアクセス制御では、アクセス制御ルールが、Ｐｕｂ−Ｓｕｂシステムにおける購読者プリンシパルとアクセス形態、フィルタの３つ組によって記述される。例えば、プリンシパル「Ｊｏｈｎ Ｄｏｅ」に株価情報を購読依頼することを認めるルールは、［Ｊｏｈｎ Ｄｏｅ、購読依頼、タイプ＝‘'株価’］のように記述される。
【０００３】
この技術においては、以下の２つの問題がある。
（１）コンテンツフィルタを自由に記述することができない（アクセス制限がコンテンツフィルタに強く依存しているため、規定されたコンテンツフィルタ以外のコンテンツフィルタを利用することができない）。
【０００４】
（２）データの匿名化等、加工によるアクセス権限の緩和を実現することができない。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００７−２８７１４８公報
【発明の概要】
【発明が解決しようとする課題】
【０００６】
従来、データの保護と、データの加工やアクセス制限の緩和を、柔軟かつ安全に可能とする方法が知られていなかった。
【０００７】
本発明は、上記事情を考慮してなされたもので、データの保護と、データの加工やアクセス制限の緩和を、柔軟かつ安全に可能とするデータ処理装置、データ処理方法及びプログラムを提供することを目的とする。
【課題を解決するための手段】
【０００８】
本発明は、送信装置からデータを受信し、該データを処理して受信装置へ送信することの可能なデータ処理装置であって、前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証し、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証する第１の検証部と、前記送信装置に係る前記検証に成功した場合にのみ、前記送信装置から前記データを受信することが可能であり、前記受信装置に係る前記検証に成功した場合にのみ、前記受信装置へ前記データを送信することが可能である中継部と、データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、前記自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定する設定部と、データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証する第２の検証部と、前記特権フロー関数に係る前記検証に成功した場合にのみ、前記特権フロー関数を実行することが可能であるとともに、該特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定する第２の実行部とを備えたことを特徴とする。
【発明の効果】
【０００９】
本発明によれば、データの保護と、データの加工やアクセス制限の緩和を、柔軟かつ安全に実現することが可能になる。
【図面の簡単な説明】
【００１０】
【図１】本発明の一実施形態に係る情報処理システムの構成例を示す図である。
【図２】Ｐｕｂ−Ｓｕｂブローカ及びＰｕｂ−Ｓｕｂ検証部の内部構成例を示す図である。
【図３】パブリッシュ及びサブスクライブについて説明するための図である。
【図４】所有者タグセットについて説明するための図である。
【図５】所有者タグセットを所有者タグが充足するかどうかを検証するアルゴリズムの一例を示す図である。
【図６】特権フロー関数の定義テーブルの一例を示す図である。
【図７】外部からのサブスクライブ要求に対する検証のアルゴリズムの一例を示す図である。
【図８】自由ＦＦ実行環境における出力チャネルの所有者タグのセットの設定のアルゴリズムの一例を示す図である。
【図９】パブリッシュ受付時の検証のアルゴリズムの一例を示す図である。
【図１０】同実施形態の情報処理システムの要求配置の動作手順の一例を示すフローチャートである。
【図１１】同実施形態の情報処理システムのパブリッシュ受け付け、要求配置及びサブスクライブの際に検証を行う場合の動作手順の一例を示すフローチャートである。
【図１２】同実施形態の要求処理装置のパブリッシュ時の動作手順の一例を示すフローチャートである。
【図１３】用紙残量閾値判定関数の擬似コードの一例を示す図である。
【図１４】本実施形態の動作の一例について説明するための図である。
【図１５】本実施形態の動作の一例について説明するための図である。
【図１６】本実施形態の動作の一例について説明するための図である。
【図１７】本実施形態の動作の一例について説明するための図である。
【図１８】本実施形態の動作の一例について説明するための図である。
【図１９】本実施形態の動作の一例について説明するための図である。
【図２０】本実施形態の動作の一例について説明するための図である。
【発明を実施するための最良の形態】
【００１１】
以下、図面を参照しながら本発明の実施形態について説明する。
【００１２】
図１に、本発明の一実施形態に係る情報処理システムの構成例を示す。
【００１３】
本実施形態の情報処理システムは、パブリッシュ・サブスクライブ・モデル（Ｐｕｂｌｉｓｈ−Ｓｕｂｓｃｒｉｂｅモデル）を前提とする場合を例にとって説明する。
【００１４】
また、以下において具体例を用いて説明する場合には、本実施形態の情報処理システムが、テナントが入居するビル内に設けられ、ビル内の設備等の監視・制御等に利用される場合を例にとって説明する。
【００１５】
図１において、１は要求処理装置（データ処理装置）、２はユーザ装置、３は要求配置装置、４はフロー関数コードレポジトリ（ＦＦコードレポジトリ）、５はパブリッシャとなる作用装置（送信装置）、６はサブスクライバとなる作用装置（受信装置）である。
【００１６】
各装置は、例えば、図示しないネットワークを介して通信可能である。
【００１７】
図１において、各装置は１台ずつ示されているが、システム中に各装置がそれぞれ任意台数ずつ存在して構わない。
【００１８】
個々の作用装置は、バブリッシャとしてのみ動作可能であっても良いし、サブスクライバとしてのみ動作可能であっても良いし、バブリッシャとサブスクライバの両方として動作可能であっても良い。
【００１９】
各装置の概要を下記に示す。
【００２０】
作用装置５は、要求処理装置１へデータを送信する装置である。
【００２１】
作用装置６は、要求処理装置１からデータを受信する装置である。
【００２２】
個々の作用装置５，６は、一意な識別情報（ＩＤ）を持ち識別可能であるとする。
【００２３】
ユーザ装置２は、利用者により記述されたユーザ要求を、要求配置装置３に送出する装置である。
【００２４】
要求配置装置３は、ユーザ装置２から受けた要求を、要求処理装置１に配置する装置である。
【００２５】
要求処理装置１は、１又は複数の作用装置５からデータを受信し、受信したデータ又はこれを加工したものを、作用装置６へ送信する装置である。また、ユーザ装置２と作用装置５，６との間の仲立ちを行う装置である。
【００２６】
ＦＦコードレポジトリ４は、フロー関数コード（ＦＦコード）を蓄積するデータベースである。
【００２７】
図１に示されるように、要求処理装置１は、要求受付部１１、フロー関数コードロード部（ＦＦコードロード部）１２、パブリッシュ・サブスクライブ・ブローカ（以下、Ｐｕｂ−Ｓｕｂブローカ）（中継部）１３、自由フロー関数実行環境（以下、自由ＦＦ実行環境）（第１の実行部）１４、特権フロー関数実行環境（以下、特権ＦＦ実行環境）（第２の実行部）１５、Ｐｕｂ−Ｓｕｂブローカ１３に付随するパブリッシュ・サブスクライブ検証部（以下、Ｐｕｂ−Ｓｕｂ検証部）（第１の検証部）１６、自由ＦＦ実行環境１４に付随する自由フロー関数所有者タグ設定部（以下、自由ＦＦ所有者タグ設定部）（設定部）１７、特権ＦＦ実行環境１５に付随する特権フロー関数署名検証部（以下、特権ＦＦ署名検証部）（第２の検証部）１８を備えている。
【００２８】
図２に、Ｐｕｂ−Ｓｕｂブローカ１３とＰｕｂ−Ｓｕｂ検証部１６の内部構成例を示す。図２に示されるように、Ｐｕｂ−Ｓｕｂブローカ１３は、パブリッシュ・サブスクライブ処理部１３１、送受信インタフェース部１３２、チャネル情報記憶部１３３を含む。
【００２９】
本実施形態では、パブリッシャである作用装置５と、サブスクライバである作用装置６と、（本実施形態においてサブスクライバ・パブリッシャとなる）自由フロー関数を実行する自由フロー関数実行環境１４と、（本実施形態においてサブスクライバ・パブリッシャとなる）特権フロー関数を実行する特権フロー関数実行環境１５との間のデータの受け渡しは、仮想的な通信路であるチャネルを介して行われる。パブリッシュ・サブスクライブ処理部１３１は、それらの間でデータを中継するための処理を行う。チャネル情報記憶部１３３は、各チャネルに関する情報（例えば、どの送信者がそのチャネルにデータを流し、どの受信者がそのチャネルからデータを受けるか、などの情報）を記憶する。送受信インタフェース部１３２は、外部の装置と通信を行うためのものであり、外部の装置である作用装置５，６との間のデータの受け渡しには、送受信インタフェース部１３２を介した通信が必要となる。これに対して、自由フロー関数実行環境１４又は特権フロー関数実行環境１５との間のデータの受け渡しは、チャネルを介するだけで可能である。なお、送受信インタフェース部１３２は、Ｐｕｂ−Ｓｕｂ検証部１６の外部にあっても構わない。
【００３０】
また、図２に示されるように、Ｐｕｂ−Ｓｕｂ検証部１６は、パブリッシャである作用装置５の検証を行うパブリッシャ検証部１６１と、パブリッシャである作用装置６の検証を行う、サブスクライバ検証部１６２とを含む。
【００３１】
以下、本実施形態について詳しく説明する。
【００３２】
まず、チャネル、パブリッシュ、サブスクライブ、Ｐｕｂ−Ｓｕｂブローカ１３について説明する。
【００３３】
「チャネル」は、パブリッシュ・サブスクライブ・モデルに基づく仮想的な通信路に相当するものである。
【００３４】
パブリッシュ・サブスクライブ・モデルでは、通常の要求−応答モデルと異なり、所望するデータが流れる特定のチャネルに対して、データ送付先（データの受信側）となるサブスクライバの情報を事前に登録しておき、データの送信側となるパブリッシャが、それぞれのタイミングで、データを当該特定のチャネルに送出すると、当該特定のチャネルにデータが流れたタイミングで、そのデータが、当該特定のチャネルに対して事前に登録された（１又は複数の）サブスクライバに送信される。パブリッシュ・サブスクライブ・モデルにおいて、パブリッシャとサブスクライバとの通信の仲立・中継をするのがいわゆるブローカと呼ばれるサーバである。
【００３５】
本実施形態では、要求処理装置１のＰｕｂ−Ｓｕｂブローカ１３が、パブリッシュ・サブスクライブ・モデルにおけるブローカの役割に相当する役割を担う。すなわち、Ｐｕｂ−Ｓｕｂブローカ１３は、パブリッシャとなる作用装置５とサブスクライバとなる作用装置６との通信の仲立・中継をする。
【００３６】
以下、チャネルに対してデータを送出することを「パブリッシュ」、特定のチャネルからデータを受信するために、受信側の情報を当該特定のチャネルに対して登録することを「サブスクライブ」と呼ぶものとする。
【００３７】
ところで、本実施形態では、要求処理装置１において、作用装置５から受信したデータを、後述するフロー関数により処理した後に、作用装置６へ送信することができる。このために、本実施形態では、フロー関数についても、データの受け渡しを、チャネルを介して行うものとしている。すなわち、本実施形態では、データの生成者である作用装置５と、データの需要者である作用装置６と、フロー関数（自由フロー関数、特権フロー関数）とが、チャネルを経由して、データを交換する。
【００３８】
ここで、フロー関数について説明する。
【００３９】
「フロー関数」は、特定の１又は複数のチャネルをサブスクライブし、該チャネルに係るデータを入力として、所定のタイミングで（例えば、サブスクライブ先のチャネルへ、データが出力されたイベントを契機に）、所定の処理（所定の演算及び又は判断など）を行い、その結果得られるデータを、必要に応じて、特定の１又は複数のチャネルに対してパブリッシュする関数である。なお、所定の処理の結果によっては、パブリッシュを行わない場合もある。フロー関数は、基本的にはどのような処理も可能であり、例えば、チャネルの情報を加工し、センサネットワークから有益な情報を抽出し、あるいは、その情報から環境に作用するアクチュエータを制御したりすることも可能である。フロー関数の実体は、要求処理装置１上に配置される。
【００４０】
本実施形態では、フロー関数には、「自由フロー関数」と「特権フロー関数」とがある。自由フロー関数については、任意の利用者（例えば、施設管理者、施設利用者や、第三者）が、その処理内容を自由に記述することができる。これに対して特権フロー関数については、特権を有する者（例えば、施設管理者）のみが処理内容を規定することができる。言い換えると、特権を有する者により規定された処理内容だけが実行可能である（特権を有する者以外の者が所望の特権フロー関数を実行させたい場合には、例えば、特権を有する者に、その所望の特権フロー関数を用意してもらう必要がある）。なお、フロー関数の記述には、例えばＪａｖａ（登録商標）等のプログラミング言語などが利用可能である。
【００４１】
自由フロー関数は、任意のデータ入力チャネルに対して実行することができる。すなわち、作用装置５から受信されたデータと、他の自由フロー関数が出力したデータと、特権フロー関数が出力したデータとのいずれを入力とすることも可能である。また、入力するチャネルの個数、組み合わせは任意である。
【００４２】
同様に、特権フロー関数は、任意のデータ入力チャネルに対して実行することができる。すなわち、作用装置５から受信されたデータと、自由フロー関数が出力したデータと、他の特権フロー関数が出力したデータとのいずれを入力とすることも可能である。また、入力するチャネルの個数、組み合わせは任意である。
【００４３】
さて、本実施形態では、図３（ａ）に例示するように、要求処理装置１において、パブリッシャＰから受信したデータを、チャネルＸを介して、そのままサブスクライバＳに送信することも可能であるが、そのフローの途中に、１又は複数（任意数）のフロー関数（自由フロー関数及び又は特権フロー関数）を挿入して、所望の機能を実現することが可能である。なお、図３において、実線は、データの流れを、一点鎖線は、パブリッシュを、破線は、サブスクライブをそれぞれ示す。
【００４４】
例えば、（１）自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）がチャネルＸにサブスクライブし、作用装置ＳがチャネルＹにサブスクライブしておき、作用装置ＰからのデータをチャネルＸに流し、自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）が、チャネルＸからのデータを処理してその結果となるデータをチャネルＹに流し、チャネルＹのデータを作用装置Ｓに送信する処理フロー（図３（ｂ）、図１５，１６参照）、
（２）自由フロー関数Ｆ１１がチャネルＸにサブスクライブし、特権フロー関数Ｆ２１がチャネルＹにサブスクライブし、作用装置ＳがチャネルＺにサブスクライブしておき、作用装置ＰからのデータをチャネルＸに流し、自由フロー関数Ｆ１１が、チャネルＸからのデータを処理してその結果となるデータをチャネルＹに流し、特権フロー関数Ｆ２１が、チャネルＹからのデータを処理してその結果となるデータをチャネルＺに流し、チャネルＺのデータを作用装置Ｓに送信する処理フロー（図３（ｃ）、図１参照）、
（３）特権フロー関数Ｆ２１がチャネルＸにサブスクライブし、自由フロー関数Ｆ１１がチャネルＹにサブスクライブし、作用装置ＳがチャネルＺにサブスクライブしておき、作用装置ＰからのデータをチャネルＸに流し、特権フロー関数Ｆ２１が、チャネルＸからのデータを処理してその結果となるデータをチャネルＹに流し、自由フロー関数Ｆ１１が、チャネルＹからのデータを処理してその結果となるデータをチャネルＺに流し、チャネルＹのデータを作用装置Ｓに送信する処理フロー（図１９参照）、
（４）自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）がチャネルＸ１とチャネルＸ２にサブスクライブし、作用装置ＳがチャネルＹにサブスクライブしておき、作用装置Ｐ１からのデータをチャネルＸ１に流し、作用装置Ｐ２からのデータをチャネルＸ２に流し、自由フロー関数Ｆ１１（又は、特権フロー関数Ｆ２１）が、チャネルＸ１とチャネルＸ２からのデータを入力として処理を行ってその結果となるデータをチャネルＹに流し、チャネルＹのデータを作用装置Ｓに送信する処理フロー（図３（ｄ）参照）、
（５）自由フロー関数Ｆ１１がチャネルＸ１とチャネルＸ２にサブスクライブし、特権フロー関数Ｆ２１がチャネルＹにサブスクライブし、作用装置ＳがチャネルＺにサブスクライブしておき、作用装置Ｐ１からのデータをチャネルＸ１に流し、作用装置Ｐ２からのデータをチャネルＸ２に流し、自由フロー関数Ｆ１１が、チャネルＸ１とチャネルＸ２からのデータを入力として処理を行ってその結果となるデータをチャネルＹに流し、特権フロー関数Ｆ２１が、チャネルＹからのデータを処理してその結果となるデータをチャネルＺに流し、チャネルＺのデータを作用装置Ｓに送信する処理フロー（図３（ｅ）参照）、
などの様々な処理フローを実現することができる。
【００４５】
チャネルは、例えば、「チャネル識別子」と「データ送付先（データ受信者）のリスト（受信者リスト）」と「許可されたデータ送信者のリスト（送信者リスト）」とを組にしたチャネル情報により管理される。このような情報は、要求処理装置１のＰｕｂ−Ｓｕｂブローカ１３のチャネル情報記憶部１３３が保持する。
【００４６】
なお、チャネル情報に「所有者タグ（所有者タグセット）」の情報を含めても良い。また、これとは別に、「チャネル識別子」と「所有者タグ（所有者タグセット）」との対応を管理しても良い。
【００４７】
Ｐｕｂ−Ｓｕｂブローカ１３（パブリッシュ・サブスクライブ処理部１３１）は、例えば、あるチャネルにデータが到着すると、到着したデータを、そのチャネルのチャネル識別子に対応する受信者リストに登録された全ての受信者へ送付する。なお、例えば、あるチャネルにデータが到着した際に、そのチャネルのチャネル識別子に対応する送信者リストに基づき、到着したデータが、そのチャネルについて許可されたデータ送信者からのものかを検査する手順も可能である。この手順では、検査の結果が正しかった場合にのみ、到着したデータを、そのチャネルのチャネル識別子に対応する受信者リストに登録された全ての受信者へ送付する。
【００４８】
ただし、後述するように、本実施形態では、作用装置５，６について、所有者タグに基づく検証を行い、この検証に成功した場合にのみ、パブリッシュやサブスクライブ（あるいは、作用装置５はらのデータの受信や、作用装置６へのデータの送信）が可能になるようにしている。
【００４９】
次に、所有者タグについて説明する。
【００５０】
本実施形態のアクセス制御技術では、作用装置５，６及び要求処理装置１並びに要求処理装置１内で扱われるデータに係るチャネルについて、所有者という概念を利用する。
【００５１】
本実施形態では、所有者を示す情報として、所有者タグを用いる。
【００５２】
「所有者タグ」は、任意数の所有者を示す識別子（所有者ＩＤ）のリストにより構成される。
【００５３】
所有者タグは、機器（本実施形態では、要求処理装置１又は作用装置５，６）の所有者、作用装置５からの入力データに係るチャネルの所有者、又は特定の種類のプログラム（本実施形態では、特権フロー関数若しくは自由フロー関数）の出力データに係るチャネルの所有者を示す情報である。
【００５４】
所有者タグは、基本的には、要求処理装置１が、パブリッシャとなる作用装置５からデータの入力や、サブスクライバとなる作用装置６へのデータの送信に先立って、所有者タグの適合性の検証を行うために利用される。
【００５５】
例えば、「ビル管理者の所有者ＩＤ」と「ビル利用者１の所有者ＩＤ」と「ビル利用者２の所有者ＩＤ」との和集合からなる所有者タグに対しては、「ビル管理者の所有者ＩＤ」と「ビル利用者１の所有者ＩＤ」と「ビル利用者２の所有者ＩＤ」の全部又は一部のみからなる所有者タグが適合し、「ビル管理者の所有者ＩＤ」「ビル利用者１の所有者ＩＤ」「ビル利用者２の所有者ＩＤ」以外の所有者ＩＤを一つでも含むものは適合しないこととなる。適合性の検証に成功した場合にのみ、そのデータが利用可能（サブスクライブ可能）になり、あるいは、要求処理装置１にデータを送信可能（パブリッシュ可能）になる。
【００５６】
装置については、例えば、権限を有する管理者等が予め当該装置に対して、（１又は複数の）所有者を含む所有者タグを設定する。なお、作用装置５，６の所有者タグは、作用装置５，６に設定して、作用装置５，６から要求処理装置１のＰｕｂ−Ｓｕｂブローカ１へ伝えるようにしても良いし、例えば、要求処理装置１内（例えば、Ｐｕｂ−Ｓｕｂブローカ１３内）に、作用装置５，６の識別情報と所有者タグとを対応付けて記憶しておき、作用装置５，６から要求処理装置１へ識別情報を伝え、要求処理装置１は、伝えられた識別情報からその作用装置５，６の所有者タグを得るようにしても良い。
【００５７】
一つの作用装置５から入力したデータ（外部からのデータ）を流すチャネルには、その入力となる作用装置５の所有者タグがそのまま与えられるものとする。
【００５８】
一つのデータを入力とする（一つのチャネルにサブスクライブする）自由フロー関数が出力するデータに係るチャネルには、それが入力とするデータに係るチャネル（それがサブスクライブするチャネル）の所有者タグがそのまま与えられるものとする。
【００５９】
特権フロー関数が出力するデータに係るチャネルには、詳しくは後述するが、当該特権フロー関数内に記載された情報に基づいて、所有者タグが設定される。
【００６０】
ただし、自由フロー関数の出力データのチャネルや、外部から入力したデータのチャネルについては、実際には、入力とするデータに係る所有者タグが複数になり得る（複数のチャネルにサブスクライブする場合に、所有者タグが複数になる）。そこで、それを示すために、自由フロー関数の出力データのチャネルや、外部からデータしたデータのチャネルについて、それらに与えられる所有者を示す情報を、「所有者タグセット」と呼ぶ。
【００６１】
所有者タグセットは、所有者タグ及び又は所有者タグセットを並列で結合した形であり、本実施形態では、それぞれの所有者タグ及び又は所有者タグセットに含まれる所有者の識別子の積集合として定義するものとする。
【００６２】
例えば、管理者と利用者とが別々の環境の場合（例えば、貸しオフィスにおける、ビル管理者とテナントとの関係のような場合）において、個々の利用者が占有している設備については、当該利用者のみを含む所有者タグを設定し、管理者と個々の利用者とが共有している設備については、管理者と当該利用者とを含む所有者タグを設定する。例えば、図４に示すように、「ビル利用者１」と「ビル管理者」とからなる「所有者タグ１」のデータと、「ビル利用者２」と「ビル管理者」とからなる「所有者タグ２」のデータとの両方を用いた自由フロー関数による演算の結果であるデータを考えると、そのデータに係るチャネルに付与される所有者タグは、それらのタグを形成する集合の積集合となり、この場合、「所有者タグ１」と「所有者タグ２」に共通する「ビル管理者」となる。よって、この演算結果のデータは、「ビル管理者」を含む「所有者タグ」を持つ場合にのみ利用可能、すなわち、そのデータに係るチャネルにサブスクライブ可能となる（ビル管理者の所有者ＩＤ以外の所有者ＩＤを一つでも含む所有者タグを持つ場合は、適合しないことになる）。
【００６３】
図５に、所有者タグセットを所有者タグが充足するかどうかを検証するアルゴリズム（共通サブルーチン）の例を示す。
【００６４】
作用装置５は、通信機能を持ち、要求処理装置１へデータを送信する装置である。作用装置６は、通信機能を持つ、求処理装置１からデータを受信する装置である。本実施形態では、作用装置５は、例えばセンサなどの環境との相互作用を行う機能を持ち、作用装置６は、例えばアクチュエータなどの環境との相互作用を行う機能を持つ。
【００６５】
バブリッシャとなる作用装置５は、データ（例えばセンサの観測値）をチャネルに出力し、サブスクライバとなる作用装置６は、チャネルからテータ（例えばアクチュエータの命令）を与えられる。
【００６６】
作用装置５，６には、それぞれ、任意数の所有者の組からなる所有者タグが設定される。所有者タグは、作用装置５がパブリッシュしたデータが流れるチャネルにおいては、所有者タグセットを構成し、該所有者全てが関係者である作用装置６だけしかデータを受信（サブスクライブ）できないことを規定する（所有者タグセットは、各入力の積集合により規定されるため）。逆に、あるチャネルのデータ受信のためのサブスクライブ要求においては、該チャネルに設定された所有者タグセットが作用装置６の所有者タグを包含していればサブスクライブ可能である。
【００６７】
要求処理装置１は、ユーザ装置２と作用装置５，６との間の仲立ちを行う。要求処理装置１は、各作用装置５，６が利用するチャネルを管理し、データの送受信の宛先管理を行う。同時に、ユーザ装置２により与えられたフロー関数を実体化し、データ処理を行う。
【００６８】
要求処理装置１のＰｕｂ−Ｓｕｂブローカ１３は、前述したように、パブリッシュ・サブスクライブ・モデルにおけるブローカの役割に相当する役割を担う。すなわち、作用装置５からデータを受信し、また、作用装置６へデータを送信するユニットである。Ｐｕｂ−Ｓｕｂブローカ１３は、例えば、パブリッシュとサブスクライブの各動作に関して、Ｐｕｂ−Ｓｕｂ検証部１６により保護される。また、前述したように、各チャネルには、入力データの源（パブリッシャ）に基づく所有者タグが規定される。
【００６９】
Ｐｕｂ−Ｓｕｂ検証部１６は、作用装置５からデータを受信するのに先立って（例えば、パブリッシュ受け付け時に）、その作用装置５の所有者タグが、当該要求処理装置１の所有者タグに適合することを検証するとともに、作用装置６へデータを送信するのに先立って（例えば、サブスクライブ時に）、その作用装置６の所有者タグが、当該要求処理装置１の所有者タグに適合することを検証するユニットである。Ｐｕｂ−Ｓｕｂブローカ１３は、前者の検証に成功した場合にのみ、作用装置５からデータを受信することが可能になる（あるいは、作用装置５のパブリッシュが可能になる）。また、後者の検証に成功した場合にのみ、作用装置６へデータを送信することが可能になる（あるいは、作用装置６のサブスクライブが可能になる）。
【００７０】
自由ＦＦ実行環境１４及び特権ＦＦ実行環境１５は、それぞれ、自由フロー関数及び特権フロー関数を実行するための実行環境である。いずれも、例えばＪａｖａのサンドボックス付き仮想マシン（すなわち、実行できる操作に制約を付けたプログラム実行環境）などを用いて構築することができる。
【００７１】
自由ＦＦ実行環境１４は、自由フロー関数を実行するユニットである。自由フロー関数は、データ処理の内容を任意に設定可能である。また、特権フロー関数と異なり、自由フロー関数の正当性の検証は不要である。自由ＦＦ実行環境１４は、自由ＦＦ所有者タグ設定部１７に保護される。
【００７２】
自由フロー関数自身は、特権フロー関数と異なり、所有者タグに対する操作が許されず、全ての入力チャネルから合成された所有者タグセットを、出力のチャネルに設定しなければならない。このタグセットの設定を強制する保護機構が、自由ＦＦ所有者タグ設定部１７である。
【００７３】
自由ＦＦ所有者タグ設定部１７は、実行された自由フロー関数が出力したデータに係るチャネルの所有者タグセットを、自由フロー関数が入力するデータに係るチャネルの所有者タグに基づいて設定するユニットである。例えば、自由フロー関数が入力するチャネルが一つの場合には、該チャネルに係る所有者タグと同一のもの（１又は複数の所有者）に設定し、自由フロー関数が入力するチャネルが複数の場合には、該複数のチャネルのすべてに共通して所有者となっているもの（１又は複数の所有者）のみを設定する（すなわち、全チャネルの所有者タグについて論理積を取る）。
【００７４】
特権ＦＦ実行環境１５は、特権フロー関数を実行するユニットである。特権フロー関数は、データ処理の内容を任意に設定可能である。また、特権フロー関数は、その出力データを流すチャネルの所有者タグを操作することができる。特権ＦＦ実行環境１５は、特権ＦＦ署名検証部１８に保護される。
【００７５】
特権フロー関数は、上記のように出力チャネルの所有者タグを操作できるので、特権フロー関数に任意のものがロードされてしまうと、データ漏洩に繋がるなどの危険性があるため、コードの正当性の検証を行う必要がある。この検証を行い、検証に成功したコードのみを特権フロー関数として実行することを強制する保護機構が、特権ＦＦ署名検証部１８である。
【００７６】
特権ＦＦ署名検証部１８は、特権フロー関数の正当性を検証するユニットである。特権ＦＦ実行環境１５は、この検証に成功した場合にのみ、特権フロー関数を実行することが可能である。
【００７７】
例えば、特権フロー関数を、事前に要求処理装置１に設定された管理者等の電子鍵（電子鍵は、例えば、公開鍵でも良いし、共有鍵でも良い。）による電子署名が為されたものに限ることとする（この署名の検証に成功したコードのみが特権フロー関数として実行可能になる）。
【００７８】
例えば、（その出力チャネルの所有者タグセットを操作するための情報を含む）特権フロー関数に、施設管理者Ｘの電子鍵による電子署名を付与するものとした場合において、ある特権フロー関数が施設管理者Ｘにより定義されたものであることは、例えば、特権ＦＦ実行環境１５に設定された管理者Ｘの電子鍵と、その特権フロー関数に付随して得られた電子署名とにより検証することができる。この検証は、例えば、一般的な公開鍵暗号での検証と同様で構わない。
【００７９】
一方、特権ＦＦ実行環境１５で特権フロー関数が実行された場合に、その実行された特権フロー関数が出力するデータを流すチャネルに係る所有者タグは、（自由フロー関数の場合と異なって、）当該特権フロー関数内に記載されている情報（所有者を指定する情報）に基づいて特権ＦＦ実行環境１５により設定される。
【００８０】
出力チャネルの所有者タグを操作する方法としては、幾つかの方法が可能である。例えば、特権フロー関数が入力したデータのチャネルに係る所有者タグにかかわらずに、出力チャネルの所有者タグを、当該特権フロー関数内に記載されている情報が示す所有者のみを含む内容に強制的に設定する方法がある。また、例えば、特権フロー関数が入力したデータのチャネルに係る所有者をもとに上記の自由フロー関数と同様にして求めた所有者タグに、当該特権フロー関数内に記載されている情報が示す所有者タグを追加したものを、出力チャネルの所有者タグに設定する方法も可能である（また、追加の他に、削除、変更などの操作を加えることも可能である）。
【００８１】
図６に、特権フロー関数の内容（定義テーブル）の一例を示す。この例では、特権フロー関数の定義は、（ａ）該特権フロー関数のコード、（ｂ）入力チャネルが満たすべき所有者タグセット、（ｃ）出力チャネルに設定される所有者タグ、（ｄ）署名者ＸのＩＤ、（ｅ）署名時刻、（ｆ）有効期限の組により行う。
【００８２】
検証は、特権フロー関数の定義情報を含む情報の組を、所定の方法（例えば、各々のビット列表現を結合することによる、などの方法）によりビット列に変換し、このビット列に対して署名者Ｘの秘密鍵で署名を行い、特権ＦＦ実行環境１５には、検証のため署名者Ｘの公開鍵を設定する、などといったプロセスで行うことができる。
【００８３】
以上６項目のうち、（ｂ）の所有者タグセットについては、例えば、対象となるチャネルの所有者タグが、（ｂ）の所有者タグセットに包含される場合に、そのチャネルを受け付けることができるとする方法の他に、例えば、対象となるチャネルの所有者タグが、（ｂ）の所有者タグセットに一致する場合にのみ、そのチャネルを受け付けることができるとする方法なども可能である。なお、（ｂ）の入力チャネルが満たすべき所有者タグセットは、空でも良い。（ｂ）が空の場合は、この特権フロー関数は、どのようなチャネルをも入力とすることができる（どのようなデータも入力として受け付けることができる）ものとする。なお、（ｂ）のフィールドを空にする変わりに、予め定められた値を記載しても良い。
【００８４】
また、（ｃ）の出力チャネルに設定される所有者タグは、空でも良い。（ｃ）が空の場合は、この特権フロー関数の出力データを流すチャネルは、どのサブスクライバでもサブスクライブできる。この場合に、そのチャネルの所有者タグは、例えば、空にする方法、予め定められた値を記載する方法などが考えられる（すなわち、全ての所有者の論理和を示す状態あるいは全ての所有者の論理和を示す情報が記載された状態にすれば良い）。なお、（ｃ）のフィールドを空にする変わりに、予め定められた値を記載しても良い。
【００８５】
なお、特権フロー関数として、何も処理をせずに、出力チャネルの所有者タグを操作するだけのものも、実行可能である。この場合には、（ａ）の該特権フロー関数のコードに、何もしないコード（あるいは、入力をそのまま出力するコード）を記載すればよい。
【００８６】
なお、電子署名の生成やその認証のための構成・手順としては、どのようなものを採用しても構わない。その際、（ｄ）署名者ＸのＩＤ、（ｅ）署名時刻、（ｆ）有効期限の部分は、採用する構成・手順に応じて、適宜修正して構わない。
【００８７】
特権フロー関数の実行には、その正当性の検証に成功する必要があり、そのために例えば電子署名等の情報を特権フロー関数に付与することについては、例えばシステムの管理者による権限を有する者等のみが可能であるので、管理者等のみが、上記の（ａ）該特権フロー関数のコード、（ｂ）入力チャネルが満たすべき所有者タグセット、（ｃ）出力チャネルに設定される所有者タグを規定することが可能である。
【００８８】
さて、利用者は、１以上のフロー関数（自由フロー関数及び又は特権フロー関数）を利用することによって、所望のデータ処理機能を実現することができる。ただし、利用者が所望する作用装置６の所有者タグが、送信対象となるデータのチャネルに係る所有者タグに適合しない限り、その作用装置６は、そのデータを受信することができない。利用者は、例えば管理者等の許諾等をもって、特権フロー関数によって、そのデータのチャネルに係る所有者タグを、利用者が所望する作用装置６の所有者タグが適合するようなものに設定することができ、この結果、その作用装置６は、そのデータを受信することができるようになる。
【００８９】
ＦＦコードロード部１２は、例えばＪａｖａで言うところのクラスローダに相当するものであり、自由ＦＦ実行環境１４及び特権ＦＦ実行環境１５でそれぞれ実行する個々の自由フロー関数及び特権フロー関数の実行イメージを、適切に設定されたファイル又はネットワークに接続されたサーバ等であるＦＦコードレポジトリ４からロードする。ここでいう「適切な設定」とは、フロー関数の名前からロードすべき実行イメージの場所が分かることであり、静的に設定されていても良いし、フロー関数の識別を実行イメージの識別子で行う（すなわち、フロー関数を指定することは、実行イメージを指定することに等しい状態にする。）ことによっても良い。
【００９０】
要求受付部１１は、要求配置装置３から、フロー関数の実体化を要求するフロー関数実体化要求を受け付ける。要求配置装置３からのフロー関数実体化要求は、少なくとも｛実体化すべきフロー関数の識別子，フロー関数のサブスクライブ先｝の組を含む。なお、要求配置装置３と要求処理装置１との間には、適切なセキュリティの設定が行われていることが望ましい。これは、例えば、pre-shared keyや公開鍵認証などの良く知られた方法により相互に認証を行うことによって実装することができる。
【００９１】
ユーザ装置２は、センサネットワーク等のシステムの利用者が、これに対するユーザ要求を記述し、要求配置装置３に送出する装置である。利用者により記述されたユーザ要求は、フロー関数の選択と、その入出力に関連付けられたチャネルのリンク（グラフ）で定義する。
【００９２】
要求配置装置３は、ユーザ装置２が記述したユーザ要求を、要求処理装置１に配置する。要求配置装置３は、情報処理システムに含まれる要求処理装置１とその所有者タグとを管理し、ユーザ装置２の要求に含まれるフロー関数を、所有者タグの条件を満たす要求処理装置１に生成する。
【００９３】
なお、個々のフロー関数は、サブスクライバであるので、サブスクライブ先の所有者タグによって入力の所有者タグセットが決定される。
【００９４】
入力の所有者タグセットは、Ｐｕｂ−Ｓｕｂブローカ１３における外部からのサブスクライブ要求に対する検証のアルゴリズムによって検証可能である。図７に、そのアルゴリズム例を示す。図７の例では、サブスクライバ先のチャネルの所有者タグセットが、サブスクライバの所有者タグを包含する場合に、充足（適合）となる。
【００９５】
また、出力の所有者タグセットは、特権フロー関数の場合は、特権フロー関数の定義により決定される。自由フロー関数の場合は、自由ＦＦ実行環境１４における出力チャネルの所有者タグのセットの設定のアルゴリズムにより決定される。図８に、そのアルゴリズム例を示す。
【００９６】
出力の所有者タグセットは、Ｐｕｂ−Ｓｕｂブローカ１３のＰｕｂ−Ｓｕｂ検証部１６におけるパブリッシュ受付時の検証のアルゴリズムにより検証可能である。図９に、そのアルゴリズム例を示す。
【００９７】
要求配置装置３が受け付けた個々のフロー関数は、入出力２つの検証を満たす要求処理装置１に順次配置される。なお、入力が決定されないと出力の所有者タグセットは、決定できないため、配置は、入力寄り（センサ等の作用装置５寄り）から開始し、順次、出力寄り（アクチュエータ等の作用装置６寄り）に向かって配置を行う。
【００９８】
図１０に、本実施形態の情報処理システムの要求配置の動作手順の一例を示す。
【００９９】
ユーザ装置２から要求配置装置３へ、利用者により記述されたユーザ要求が送信される（ステップＳ１）。
【０１００】
要求配置装置３は、受信したユーザ要求を、適切な要求処理装置１へ転送する（ステップＳ２）。該要求を受信した要求処理装置１では、要求受付部１１で、該ユーザ要求を受け付ける。
【０１０１】
要求受付部１１は、受け付けたユーザ要求を、ＦＦコードロード部１２へ送る（ステップＳ３）。
【０１０２】
ＦＦコードロード部１２は、与えられたユーザ要求に基づいて、適切な実行イメージをＦＦコードレポジトリ４からロードして、自由ＦＦ実行環境１４及び又は特権ＦＦ実行環境１５へ与える（ステップＳ４）。
【０１０３】
図１１に、作用装置４のパブリッシュ受け付け時、要求処理装置１の要求配置時及び作用装置５のサブスクライブ時に検証を行う場合の動作手順の一例を示す。ここでは、自由フロー関数と特権フロー関数が実行される場合を例にとって説明する。
【０１０４】
まず、Ｐｕｂ−Ｓｕｂ検証部１６が、パブリッシャである作用装置５について、所有者タグに基づく検証を行う（ステップＳ１１）。検証に失敗した場合には（ステップＳ１２）、この時点でエラーとなる（ステップＳ１４）。
【０１０５】
検証に成功した場合に（ステップＳ１２）、Ｐｕｂ−Ｓｕｂブローカ１３は、このデータを流すチャネルに、作用装置５と同じ所有者タグを付与する（ステップＳ１３）。
【０１０６】
次に、自由ＦＦ所有者タグ設定部１７は、上記チャネルにサブスクライブする自由フロー関数の出力データを流すチャネルに、所有者タグの設定を行う（ステップＳ１５）。
【０１０７】
次に、特権ＦＦ署名検証部１８は、上記チャネルにサブスクライブする特権フロー関数について、署名の検証を行う（ステップＳ１６）。検証に失敗した場合には（ステップＳ１７）、この時点でエラーとなる（ステップＳ１９）。
【０１０８】
検証に成功した場合に（ステップＳ１７）、特権ＦＦ実行環境１５は、この特権フロー関数の出力データを流すチャネルに、所有者タグを設定する（ステップＳ１８）。
【０１０９】
次に、Ｐｕｂ−Ｓｕｂ検証部１６が、サブスクライバである作用装置６について、所有者タグに基づく検証を行う（ステップＳ２０）。検証に失敗した場合には（ステップＳ２１）、この時点でエラーとなる（ステップＳ２２）。
【０１１０】
検証に成功した場合に（ステップＳ２１）、このフローが可能となる。
【０１１１】
なお、上記手順は、自由フロー関数や特権フロー関数の有無やその数に応じて、適宜変更される。まず、個々の自由フロー関数に応じて、ステップＳ１５の部分が実行される。自由フロー関数が実行されない場合には、ステップＳ１５の部分は省かれる。また、個々の特権フロー関数に応じて、ステップＳ１６〜Ｓ１９の部分が実行される。特権フロー関数が実行されない場合には、ステップＳ１６〜Ｓ１９の部分は省かれる。また、自由フロー関数に対応するステップＳ１５の部分や、特権フロー関数に対応するステップＳ１６〜Ｓ１９の部分は、フロー関数が実行される順番に従って実行される。
【０１１２】
ところで、上記の所有者タグの設定及び検証は、上記タイミングに加えて（或いは、これに代えて）、実際に作用装置５からデータを受信し、これをフロー関数で処理して、作用装置６に送信するときに行うことも可能である。
【０１１３】
図１２に、この場合の動作手順の一例を示す。ここでは、自由フロー関数と特権フロー関数が実行される場合を例にとって説明する。
【０１１４】
まず、パブリッシャである作用装置５が、所定のタイミングでデータを要求処理装置１へ送信する。要求処理装置１において、該データを受信すると（ステップＳ３１）、Ｐｕｂ−Ｓｕｂ検証部１６がパブリッシャである作用装置５について所有者タグに基づく検証を行う（ステップＳ３２）。検証に失敗した場合には（ステップＳ３３）、この時点でエラーとなる（ステップＳ３５）。
【０１１５】
検証に成功した場合に（ステップＳ３３）、Ｐｕｂ−Ｓｕｂブローカ１３は、このデータを流すチャネルに、所有者タグを設定する（ステップＳ３４）。
【０１１６】
次に、自由ＦＦ実行環境１４は、上記チャネルから受け取ったデータを入力として、自由フロー関数を実行する（ステップＳ３６）。自由ＦＦ所有者タグ設定部１７は、自由フロー関数の出力データを流すチャネルに、所有者タグを設定する（ステップＳ３７）。
【０１１７】
次に、特権ＦＦ署名検証部１８は、上記チャネルにサブスクライブする特権フロー関数について、署名の検証を行う（ステップＳ３８）。検証に失敗した場合には（ステップＳ３９）、この時点でエラーとなる（ステップＳ４１）。
【０１１８】
検証に成功した場合に（ステップＳ３９）、特権ＦＦ実行環境１５は、上記チャネルから受け取ったデータを入力として、特権フロー関数を実行するとともに、出力データを流すチャネルに、所有者タグを設定する（ステップＳ４０）。
【０１１９】
次に、Ｐｕｂ−Ｓｕｂ検証部１６がサブスクライバである作用装置６について所有者タグに基づく検証を行う（ステップＳ４２）。検証に失敗した場合には（ステップＳ４３）、この時点でエラーとなる（ステップＳ４５）。
【０１２０】
検証に成功した場合に（ステップＳ４３）、Ｐｕｂ−Ｓｕｂブローカ１３が、このチャネルのデータを、作用装置６に送信する（ステップＳ４４）。
【０１２１】
なお、上記手順が、自由フロー関数や特権フロー関数の有無やその数に応じて、適宜変更される点は、図１１の場合と同様である。
【０１２２】
本実施形態により、例えば、管理者と複数の所有者／利用者が存在する環境で、一利用者が、複数の所有者によるデータ（コンテンツ）を混合した状態で操作するフロー関数を定義し、その結果を特権フロー関数経由で匿名化して閲覧する、といったことが可能となる。例えば、複数のテナントが入っているビルがあったときに、個々のテナントの在室人数を合成し、ある閾値を下まわったらビルを節電モードで動作させる、などといったプログラムを、外部のＥＳＣＯ事業者がビル上で実行できる。このとき、本来テナント毎の秘密情報である在室者リストを、外部事業者が操作するプログラムを書き、この秘密性を削除する特権ＦＦ（人数のみの情報に落とすなど）によりそのプログラムの結果のみを受け取ることが可能になる。
【０１２３】
以下、本実施形態の情報処理システムをビル管理システムに適用した幾つかの具体例を用いて説明する。
【０１２４】
＜第１の具体例＞
まず、図１３〜図１６を参照しながら、第１の具体例として、サービス会社との連携の例について説明する。なお、図１４は、所有者タグが適合しないチャネルへのサブスクライブが成功しない例（フロー関数を用いない場合）であり、図１５は、自由フロー関数が出力チャネルの所有者タグを変更しないため、所有者タグが適合しない例であり、図１６は、正しく署名された特権フロー関数が出力チャネルの所有者タグを変更することによって、所有者タグが適合する例である。
【０１２５】
本具体例は、本実施形態の動作を説明するために単純化した例である。
【０１２６】
あるビルＢに、企業Ｘが入居しているとする。なお、簡単のため、ここでは、ビルＢは企業Ｘの持ちビルであり、企業Ｘがビル管理者であるとする。企業Ｘには、プリンタが一つ存在し（プリンタをＰ１とする。）、プリンタＰ１のプリンタ用紙の補充のために、サービス会社Ｓが存在する。企業Ｘは、プリンタ用紙が切れないように、また、過大なストックを置かないように、サービス会社Ｓにプリンタ用紙の管理を委託する。ただし、いつ何枚のプリントアウトを行ったかという情報、あるいは、任意の時点での用紙の残量の情報などをサービス会社Ｓに通知することは、企業Ｘにとっては例えば事業活動の活発度などを知らせることと等しいため、望ましくない。
【０１２７】
そこで、本実施形態により、以下のような構成が可能になる。
【０１２８】
プリンタＰ１を、作用装置５として動作するものとし、所有者タグとして企業Ｘの所有者ＩＤをセットする。企業Ｘは、一つの要求処理装置１を持つ。要求処理装置１には、企業Ｘの所有者ＩＤとサービス会社Ｓの所有者ＩＤからなる所有者タグをセットする。これらは、企業Ｘにより管理される一つの要求配置装置３に接続され、サービス会社Ｓは、ユーザ装置２を経由して任意のプログラムを投入することができる。
【０１２９】
サービス会社Ｓは、作用装置６として、サービス会社Ｓの所有者タグがセットされた用紙切れ警報機Ａを持つ。用紙切れ警報機Ａは、例えば、回転灯のようなものでも良いし、担当者に電子メールなどで用紙切れを通知する装置でも良い。また、ロボットや宅配便・地域内物流サービスなどを用いて半自動的に企業Ｘに用紙を配送する装置でも良い。
【０１３０】
プリンタＰ１は、用紙が使用される度に用紙の残量を数値で出力する。ここでは、例えば、企業Ｘは、「用紙の残量が１００枚を下回ったときにＴｒｕｅを返す」という用紙残量閾値判定関数ｆｔｈを、特権フロー関数として登録する。この特権フロー関数の出力所有者タグは、サービス会社Ｓの所有者ＩＤとする。ただし、特権フロー関数は、登録時に、企業Ｘによる署名が必要である。なお、この特権フロー関数は、例えば擬似コードで作成される。図１３に、用紙残量閾値判定関数ｆｔｈの擬似コード（ｔｈｒｅａｓｈｏｌｄ関数）の例を示す。
【０１３１】
ここで、サービス会社Ｓが、プリンタＰ１の用紙残量の出力を取得するケースと、自由関数によりプリンタＰ１の用紙残量の出力を加工した結果を取得するケースについて考える。
【０１３２】
用紙残量をそのまま用紙切れ警報機Ａに与えるものとした場合、図１４に示すように、プリンタＰ１の用紙残量の出力には、企業Ｘの所有者タグが与えられており、よって、出力チャネルには、企業Ｘの所有者タグが与えられるが、一方、用紙切れ警報機Ａには、サービス会社Ｓの所有者タグが与えられているので、用紙切れ警報機ＡがプリンタＰ１の出力チャネルをサブスクライブしようとしても、Ｐｕｂ−Ｓｕｂ検証部１６によりブロックされる。
【０１３３】
また、図１５に示すように、サービス会社Ｓが導入した自由フロー関数を経由して用紙切れ警報機Ａにデータを与えようとしても、同様に、自由ＦＦ所有者タグ設定部１７により自由フロー関数の出力に企業Ｘの所有者タグセットが与えられ、この出力チャネルを用紙切れ警報機Ａがサブスクライブしようとするときに、Ｐｕｂ−Ｓｕｂ検証部１６によりブロックされる。
【０１３４】
そこで、サービス会社Ｓが、用紙切れ警報機Ａに、サービスのための情報を与えるためには、図１６に示すように、用紙残量閾値判定関数ｆｔｈ（特権フロー関数）を経由させれば良い。この特権フロー関数は、企業Ｘにより署名されており、サービス会社Ｓは、その内容を操作することはできない。しかし、サービス会社Ｓがユーザ装置２から要求配置装置３に与えるプログラムの途中に、特権フロー関数を導入することが可能である。特権ＦＦ実行環境１５により、その出力の所有者タグセットにはサービス会社Ｓのみが与えられるため、その結果を用紙切れ警報機Ａで受信することができる。
【０１３５】
以上から得られる、サービス会社Ｓがサービスを実行するためのプログラムの単純な例は、プリンタＰ１の出力チャネルを用紙残量閾値判定関数ｆｔｈ（特権フロー関数）の入力とし、その出力を用紙切れ警報機Ａがサブスクライブすることにより、用紙１００枚未満となったことを検出するものである。
【０１３６】
ここで、さらにサービス会社Ｓがサービス向上のために、動的にプリンタＰ１の用紙残量の減り方を予測したいとする。例えば、大きな需要があったときには、残量１００枚になってから補充を手配したのでは間に合わない場合もある。そこで、サービス会社Ｓは、数時間分の用紙残量の履歴を取り、３時間後の用紙残量を線形補完により求める関数ｆｌｉを新しい自由フロー関数として定義し、ＦＦコードレポジトリ４に登録する。そして、プリンタＰ１の出力チャネルを関数ｆｌｉの入力とし、この出力を関数ｆｔｈの入力とする。このとき、関数ｆｌｉの出力は、関数ｆｌｉが自由フロー関数であるため、所有者タグセットとして企業Ｘが設定されており、直接的には用紙切れ警報機Ａで受信することはできない。そこで、先の例と同様、関数ｆｔｈを経由することにより、企業Ｘがサービス会社Ｓに対して認めた情報出力となり、サービス会社Ｓは、新しい関数による計算結果を、閾値関数の出力として得ることができる。
【０１３７】
＜第２の具体例＞
次に、図１７，１８を参照しながら、第２の具体例として、ビル内機器のアクセス制御の例について説明する。なお、図１７は、２つのテナントにより共用される設備の例であり、図１８は、特権フロー関数をアカウンティングの窓口として利用する例である。
【０１３８】
第１の具体例に類似する例として、ビル内機器へのアクセス制御とアカウンティングとを同時に行う例について説明する。本具体例では、ビルには、「個別フロア空調設備」、「共通空調設備」、「給湯設備」、「エレベータ設備」、「照明設備」、「フロア共有のコピー機」、「フロア共有のプリンタ」などが存在するものとする。それぞれの設備・機器は、既知のプロトコルなどを用いた通信手段により設備機器ネットワーク上からアクセス可能であるものとする。また、ビルには、複数のテナントが入っており、本具体例では、１Ｆに「テナントＴ１」が、２Ｆに「テナントＴ２ａ」と「テナントＴ２ｂ」が入居しているものとする。また、ビルには管理者が存在し、これを「ビル管理者ＢＡ」とする。
【０１３９】
ここで、本具体例では、ビル管理者あるいはテナントのユーザ装置２が存在するとする。また、テナントが貸与され管理する要求処理装置１として、テナントＴ１の要求処理装置１と、テナントＴ２ａとテナントＴ２ｂに共用の要求処理装置１が存在するとする。また、テナントＴ１の要求処理装置１には、「テナントＴ１とビル管理者ＢＡの所有者タグ」が設定され、テナントＴ２ａとテナントＴ２ｂに共用の要求処理装置１には、「テナントＴ２ａとテナントＴ２ｂとビル管理者ＢＡの所有者タグ」が設定されているものとする。なお、これら要求処理装置１は、物理的に独立した個々の装置であっても良いし、共有されたハードウェアにソフトウェア的に保護された各々の領域に仮想的に構築されたものであっても良い。
【０１４０】
また、ビル内には、被制御機器が存在する。これらには、フロア共有機器（フロア空調設備・照明設備等）、設備全体での共有機器（エレベータ等）が存在する。これらの被制御機器は、ビル管理者が直接管理するものであり、テナントが自由に制御できるものではない。そのため、これらの機器には、「ビル管理者ＢＡの所有者タグ」をセットする。なお、テナント向け制御盤に相当する機器には、「テナントの所有者タグ」がセットされるものとする。
【０１４１】
本具体例では、２Ｆに設置された空調を代表例として説明する。２Ｆの空調設備を「ＡＣ」とする。２Ｆのテナントに設置された制御盤について、テナントＴ２ａにおけるものを「制御盤ＣＴ２ａ」と、テナントＴ２ｂにおけるものを「制御盤ＣＴ２ｂ」とする。空調設備ＡＣには、「ビル管理者ＢＡの所有者タグ」が設定され、制御盤ＣＴ２ａには、「テナントＴ２ａの所有者タグ」が設定され、制御盤ＣＴ２ｂには、「テナントＴ２ｂの所有者タグ」が設定されているものとする。
【０１４２】
ここで、各々のテナントは、自由に空調が設定できるものとする。ただし、テナントの従業員は、制御盤ＣＴ２ａ又は制御盤ＣＴ２ｂに規定室温と動作要求（ＯＮ／ＯＦＦ）を入力し、制御盤ＣＴ２ａ及び制御盤ＣＴ２ｂは、それぞれ、具備する室温計から空調設備ＡＣへの動作／非動作を入力するものとする。
【０１４３】
以上のプログラムを略式に記述すると図１７のように記述できる。
【０１４４】
なお、制御盤ＣＴ２ａ及び制御盤ＣＴ２ｂは、以下の原理で動作する。入力は、規定室温（度）・動作要求（ｏｎ／ｏｆｆ）・室温計（度）である。出力は、空調制御要求（ｏｎ／ｏｆｆ）である。動作要求がｏｆｆのときには、出力はｏｆｆである。動作要求がｏｎであれば、規定室温と室温計を比較し、室温計入力が規定室温よりも高ければｏｎを、そうでなければｏｆｆを出力する。
【０１４５】
さて、ここで、制御盤ＣＴ２ａ及び制御盤ＣＴ２ｂは、それぞれ、所有者タグとしてテナントＴ２ａ及びテナントＴ２ｂを持つ。これを直接的には空調設備ＡＣの入力とはできない。なぜならば、空調設備ＡＣは、ビル管理者ＢＡの所有者タグを持ち、テナントＴ２ａとテナントＴ２ｂを出力として持つチャネルを、サブスクライブすることができないからである。
【０１４６】
一方、ビル管理者は、どのテナントがどの程度空調設備を利用しているかを知りたいものとする。これは、例えば、別途従量制の課金を行っている場合もあり、また、そうでなくても、例えば、計画節電のために過度の利用に対し制約をかける必要がある場合などがあるからである。
【０１４７】
そこで、ビル管理者は、各々の制御盤からの入力を受け、出力の所有者タグをビル管理者ＢＡとするアカウンティング特権フロー関数ｆａｃを用意する。これは、対となるアカウンティングデータベースを持ち、関数ｆａｃに対してｏｎの制御命令、つまり空調を動作させる命令が通ったときに、その累計時間を計量しアカウンティングデータベースに記録するものである。また、利用量が計画量に比べて著しく高い場合は、ｏｎの制御命令を差し止める機能を持たせても良い。
【０１４８】
ここで、関数ｆａｃは、テナント毎に用意される。例えば、テナントＴ２ａに向けたｆａｃは、入力チャネルが持つべき所有者タグセットとしてテナントＴ２ａが設定され、誤って又は故意にテナントＴ２ｂが空調をテナントＴ２ａへの課金により動作させることができない。もちろん、アカウンティングデータベースもテナント毎に用意される。一方、出力となる所有者タグセットは、ビル管理者ＢＡのものとなる。この特権フロー関数を経由させることにより、前述の擬似プログラムは、図１８のようになる。ここで、テナントＴ２ａ向けｆａｃをＦＡＣ＿Ｔ２ａ、テナントＴ２ｂ向けｆａｃをＦＡＣ＿Ｔ２ｂと記述する。
【０１４９】
以上の構成により、テナントからの要求を受け付けつつ、アクセス管理によりアカウンティングを実現する実例を示した。なお、各テナントは、独自に、制御盤の出力部分に、残業申請システムや空調の時間外動作の許認可を行うワークフローシステムを組み込んでも良い。
【０１５０】
＜第３の具体例＞
次に、図１９を参照しながら、第３の具体例として、ビル内機器制御と在室管理の連動の例について説明する。なお、図１９は、空調制御の例である。
【０１５１】
第２の具体例を拡張して、ビル内機器制御と在室管理とを連動させる例について説明する。ビルの機器及びテナントは、特に述べない限り第２の具体例と同様であるとする。
【０１５２】
テナントの入居者は、ビルのセキュリティシステムに接続された入退室管理システムを持ち、テナントの従業員又は出入りのある契約業者（清掃業者等）の従業員等が、それぞれ、カードキーにより施錠されたゲート（１ＦのゲートをＧ１、２ＦのゲートをＧ２とする。）を通過するものとする。ただし、各テナントの従業員に関しては、誰がいつゲートを通過したか、については、各企業の秘密事項であることから、ビルの管理者は、直接的には得ることができないという契約であるとする。
【０１５３】
なお、ゲートから出てくる情報は秘密であるので、ビル管理者は、直接的にはデータを取得できないようになっている。従って、ゲートＧ１には「テナントＴ１の所有者タグ」のみが設定され、ゲートＧ２には「テナントＴ２ａとテナントＴ２ｂの所有者タグ」のみが設定されており、ビル管理者ＢＡが持つ出力機器（「ビル管理者ＢＡの所有者タグ」が設定されている。）においては、ゲートＧ１／Ｇ２の情報は受信できない。
【０１５４】
ここで、テナントとビル管理者との合意により、ビル管理者は、入室している人数を知ることができるものとする。この合意は、例えば、ＩＤの一覧からその長さを得て、その出力の所有者タグをビル管理者ＢＡとする特権フロー関数を、当該テナントが導入することによって、達成することができる。ビル管理者は、例えばこの在室人数をもとに、電源計画を調整することができる。この様子を図１９に示す。
【０１５５】
図２０では、特権フロー関数Ｃ１ＦがゲートＧ１の出力（入室，カードキーＩＤ）又は（退室，カードキーＩＤ）の列を読み、現在の１Ｆの在室人数に変換する。同時に、特権フロー関数Ｃ２Ｆは、ゲートＧ２の出力を読み、２Ｆの在室人数に変換する。
【０１５６】
これらは、以下のアルゴリズムで動作可能である。
１．在室者セットを空で初期化する。
２．ゲートからの入力を待ち、入力に応じて以下のどちらかを実行する。
入室イベント在室者セットにカードキーＩＤを登録する。
退室イベント在室者セットからカードキーＩＤを削除する。
３．在室者セットの数を数え、これを出力する。
４．手順２に戻る。
【０１５７】
なお、ここで言うセットとは、重複を許さない集合を実現するデータ構造である。
【０１５８】
ビル管理者ＢＡは、この出力を自分が管理する要求処理装置１で受信することができる。
【０１５９】
在室人数と、個々のテナントとの間で取り交したサービスレベル合意から、１Ｆの空調機ＡＣ１の出力と２Ｆの空調機ＡＣ２の出力を制御することができる。ここでは、１Ｆの空調機ＡＣ１の制御を行う自由フロー関数及び２Ｆの空調機ＡＣ２の制御を行う自由フロー関数を、それぞれ、ＡＣＭ１及びＡＣＭ２で表した。
【０１６０】
この例では、サービスレベル合意は、以下の２項目の組み合わせのリストで取り交されるとする。現時点での在室人数によって、空調出力が制限される仕組みである。これにより、在室人数が少なくなるにつれ省エネ運転となり、在室人数が多いときは、快適運転とすることができる。
・ｔ：最低在室人数閾値（整数）
・ｍ：最大空調出力（０−１００）
ＡＣＭ１とＡＣＭ２は、いずれも、以下のような動作を行う。
１．仮の最大出力値ｏを０で初期化する
２．入力を待ち、その人数をｐに記録する
３．サービスレベル合意のリストから順番に要素を取り出し、それぞれのｔとｐについて、
・ｐがｔと等しいかより大きい場合
ｏ＝ｍａｘ（ｏ，ｍ）
４．結果のｏを出力する
５．手順２に戻る
＜第４の具体例＞
次に、図２０を参照しながら、第４の具体例として、ＥＳＣＯ事業と在室管理の連動の例について説明する。なお、図２０は、ビル全体の電源制御と、在室管理との連動の例を示す。
【０１６１】
ＥＳＣＯ(Energy Service COmpany)と呼ばれる事業形態は、特定の事業所のエネルギー消費を最適化（節電）することを事業として請け負うものである。
【０１６２】
ここで、あるビルに対する最適なＥＳＣＯ事業に対して、本発明を実施する例を説明する。なお、特に説明のない限り、この具体例は、ここまでの具体例の環境と同様の環境にあるとする。
【０１６３】
ここで、ＥＳＣＯ事業者がビルの管理者と契約し、契約に基づきビル内の設備・機器の電源制御を行うものとする。一方、各テナントに誰がいつ入室して、いつ退室したか、という情報は、利用の仕方によっては、各テナントのビジネスの動きを推測することができる情報であり、ＥＳＣＯ事業者には、この情報を与えてはならない。一方、ＥＳＣＯ事業者は、ビル内の最適な電源制御を行い、ビルの電力効率をより高めることから利益を得る業態であるため、ビル内の人のアクティビティや機器の利用状況を知り、また、詳細に制御することは、有益なことである。
【０１６４】
そこで、本実施形態により、ＥＳＣＯ事業者とビル管理者との間の契約に基づくデータ（制御結果の指標）のみをＥＳＣＯ事業者に渡すことを保証しつつ、実際の制御及び制御結果の指標の算出のためのプログラムは、ＥＳＣＯ事業者に自由に開発させることができる。本実施形態は、外部の事業者による自由なプログラミングと、データ流通の境界制御による情報漏曳の防止とを両立させる。
【０１６５】
その結果、本具体例では、ＥＳＣＯ事業者がより高い能力を発揮し、エネルギー消費／コストの削減に貢献することが期待できる。
【０１６６】
以下、図２０を参照しながら、具体的な具体例を説明する。
【０１６７】
ビル内には、入退室リーダ、エレベータや空調・照明・給湯などの各種被制御機器が存在する。また、数台の要求処理装置１（図示せず）が存在し、それらのうち１台がＥＳＣＯ事業者を含む外部サービス向けの出入口となっている。
【０１６８】
ＥＳＣＯセンターは、別途契約によりビル管理者から入手したビル内の機器構成から、ビル制御に必要なフロープログラムを記述する。記述したプログラムは、ＥＳＣＯセンターに割り当てられたユーザ装置２より要求配置装置３に与えられる。ここで、ＥＳＣＯセンターは、必要であればビル内でデータ処理を行うための自由フロー関数を記述し、要求配置装置３へのプログラム投入に先立ってＦＦコードレポジトリ４に登録する。
【０１６９】
要求配置装置３は、必要に応じてプログラムを分解し、例えば、入退室リーダの入力を受ける部分は、入退室リーダの近傍の要求処理装置１へ、ＥＳＣＯセンターへの出力を制御する部分は、外部向けの要求処理装置１へ、といった要領で、各フロー関数を要求処理装置１に配置する。このとき、それぞれの要求処理装置１に設定された所有者タグの制約条件を満たすようにフロー関数を配置し、要求処理装置１間を接続する。
【０１７０】
具体的に、入退室ゲートＧにテナント所有者タグＴが、空調機器の入力（制御）側と空調機器の出力（監視）側にそれぞれビル管理者の所有者タグＢＡが設置されていたとする。このとき、第３の具体例で説明したのと同様の仕組みで、空調の監視や制御を行うことが出来る。前出の具体例との相違は、ＥＳＣＯセンターはビルの外にあり、また、ビル管理者は複数のＥＳＣＯ事業者を契約によって切り替えて用いることができる点である。
【０１７１】
＜第５の具体例＞
次に、第５の具体例として、電力インフラ事業の例について説明する。
【０１７２】
電力供給が需要に追い付かなくなると、需要家に対して需給調整（例えば、需給調整契約、という契約を結んだ需要家に対して、普段の電力の割引と需給逼迫時の電力カット依頼を行うこと。）を行う場合がある現在は、この需給調整を手動で行っているが、緊急時の対応を除いて自動化することを考える。
【０１７３】
このとき、単一の供給家Ｓと複数の需要家Ｄ１，Ｄ２，．．．を考える。個々の需要家は、需要家の事業所内での電力消費を把握しており、個々の負荷の設定をフロープログラムで記述可能であるとする。具体的な記述は、前出の機器制御の事例（第３の具体例など）と同等である。ここで、需給調整用フロープログラムを事業所内部で記述する。
【０１７４】
需給調整契約は、個々の契約内容に基づき、そのプログラムの入力部に特権フロー関数を用意する。この入力チャネルが満たすべき所有者タグセットにＳを、出力に該需要家Ｄｎを設定する。入力としては、需給調整依頼の程度（需要を何ワット抑えるか）と、その依頼の期限と期間（何時間後までに調整を完了させ、その状態を何時間継続するか）の組み合わせ（タプル）であり、特権フロー関数は、契約内容と需給調整依頼が合致しているかを検証し、検証結果が正しければ、需要家が設定した需給調整用フロープログラムへ需給調整依頼を転送する機能を持つ。
【０１７５】
電力需給逼迫時には、供給家Ｓは、個々の需要家Ｄｎの特権フロー関数に対して需給調整依頼を発行する。個々の需要家は、契約規模やその時点での需要が異なるため、個々の需要家にあわせた需給調整依頼を発行する。なお、需給調整依頼を個々の需要家の契約規模やその時点での需要にあわせて自動生成する機構を導入することもできる。
【０１７６】
また、自動化により、需給調整をする／しないの二段階から、消費可能電力上限を徐々に絞っていくという方式に切り替えることも考えられる。この場合は、需給調整がはじまると
１）空調が弱くなり、サーバ機器なども省エネモードで動作する
２）止めても良い負荷（複数系統のエレベータやオフィスのプリンタなど）が止められる
３）止めても良い（機器保全でない）空調が止められる
４）生産設備の停止計画が優先度順に実行される
といった順序で消費電力削減を実行することで、求められた需給調整に連続的・自動的に対応することができる。
【０１７７】
ただし、生産設備の停止計画については、当然のことながら納入の遅れなどにつながるため、工程管理システムにおける生産能力の優先順位付けや調整と、本具体例で述べた需給調整のシステムが相互に接続している必要がある。例えば、電力削減を実現するために停止させるラインを、停止による損失額から推定し、損失額の少ないものから順に停止するといったシステムを導入する。
【０１７８】
＜第６の具体例＞
次に、第６の具体例として、交通制御の例について説明する。
【０１７９】
都心部の交通状況は、時々刻々と変わり、また、様々な経済活動に影響を与える情報源となりうる。例えば、混雑状況がリアルタイムに把握できれば、流通の配車計画をそれにあわせて調整することができる。また、センシング技術の発達やネットワーク／ＩＴＳ連動ＧＰＳナビシステムなどの登場にともない、特に車両において、誰がどこをどちらに向けて走っているかを把握することすら可能になってきている。
【０１８０】
ただし、個々の車両の移動情報を把握することは、プライバシ上の懸念も生み出す。この情報は誰でも自由に利用できる、という性質のものではないことは明らかだろう。しかし、どのような形式の情報がより多くの利益を生みだすかを事前に検討することもまた困難である。
【０１８１】
そこで、例えば個々の交通システムの要素技術（例えばナンバープレート認識装置や交通状況画像処理の結果など）においては、本実施形態における要求処理装置１に相当する機能を実装し、それらの情報を加工又は集約した結果を交通システムの外側に提供する段階で、特権フロー関数によるデータの匿名化と検証を行う、ということもできる。この方式であれば、交通システムの内部で用いるためには、プライバシ情報も含む生のデータをそのまま取り扱うことができる一方、外部の利用者へもプライバシ情報の漏出の懸念が少ない状態で情報提供および有効活用が可能になる。
【０１８２】
具体的な特権フロー関数としては、安全でかつ有意義な情報をまず（時刻／時間，カウント）のタプル列に限定し、これ以外は出力しない特権フロー関数が考えられる。これで、個々の時刻又は時間に何台車が通ったのかのみを出力し、いつ／どのような、の判断に関しては、データ利用者側の自由な発想と、自由フロー関数による処理結果に任せる、ということができる。また、将来ニーズの高まりにより新しいデータ形式の出力が求められたときは、新しい特権フロー関数を導入すれば良い。もちろん、より高精細な情報を得られる特権フロー関数を利用するには、何らかの契約により対価を支払う仕組みにしても良く、その場合は、需要者個々の所有者タグを出力にセットした特権フロー関数をＦＦコードレポジトリ４に登録する。
【０１８３】
なお、特権フロー関数と自由フロー関数の実行環境を分割する理由をここで説明する。例えば、センサから得られた生の画像や、ナンバープレート情報などを、出力が許された別の形式にエンコードしなおす（例えば、前のイベントとの時刻差分が１ならビット０、２ならビット１、とすることで任意のデータを時系列データにエンコードできる、など）ことが考えられる。これを許さないために、データの内容を操作する段階（例えばナンバープレートの数値を取得し比較する、あるいは、画像を変換して顏ＤＢと照合する、など）のみにおいて専用の特権フロー関数を用意し、出力は、交通システム所有者の所有者タグとする。一方、自由フロー関数が実行される実行環境では、データへの直接アクセスを行うメソッドの呼び出しは、禁止する（例えばＪａｖａの場合は、サンドボックスの適切な設定により禁止する）。
【０１８４】
なお、以上の各機能は、ソフトウェアとして記述し適当な機構をもったコンピュータに処理させても実現可能である。
また、本実施形態は、コンピュータに所定の手順を実行させるための、あるいはコンピュータを所定の手段として機能させるための、あるいはコンピュータに所定の機能を実現させるためのプログラムとして実施することもできる。加えて該プログラムを記録したコンピュータ読取り可能な記録媒体として実施することもできる。
【０１８５】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【符号の説明】
【０１８６】
１…要求処理装置、２…ユーザ装置、３…要求配置装置、４…フロー関数コードレポジトリ、５…作用装置、１１…要求受付部、１２…フロー関数コードロード部、１３…パブリッシュ・サブスクライブ・ブローカ、１４…自由フロー関数実行環境、１５…特権フロー関数実行環境、１６…パブリッシュ・サブスクライブ検証部、１７…自由フロー関数所有者タグ設定部、１８…特権フロー関数署名検証部、１３１…パブリッシュ・サブスクライブ処理部、１３２…送受信インタフェース部、１３３…チャネル情報記憶部、１６１…パブリッシャ検証部、１６２…サブスクライバ検証部
【特許請求の範囲】
【請求項１】
送信装置からデータを受信し、該データを処理して受信装置へ送信することの可能なデータ処理装置であって、
前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証し、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証する第１の検証部と、
前記送信装置に係る前記検証に成功した場合にのみ、前記送信装置から前記データを受信することが可能であり、前記受信装置に係る前記検証に成功した場合にのみ、前記受信装置へ前記データを送信することが可能である中継部と、
データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、
前記自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定する設定部と、
データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証する第２の検証部と、
前記特権フロー関数に係る前記検証に成功した場合にのみ、前記特権フロー関数を実行することが可能であるとともに、該特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定する第２の実行部とを備えたことを特徴とするデータ処理装置。
【請求項２】
前記第１の検証部は、前記送信装置に係る所有者情報の示す所有者の集合が、前記データ処理装置に係る所有者情報の示す所有者の集合に包含される場合に、前記検証に成功したものとすることを特徴とする請求項１に記載のデータ処理装置。
【請求項３】
前記第１の検証部は、前記受信装置に係る所有者情報の示す所有者の集合が、前記受信装置に送信すべきデータに係る所有者情報が示す所有者の集合に包含される場合に、前記検証に成功したものとすることを特徴とする請求項１に記載のデータ処理装置。
【請求項４】
前記中継部は、前記送信装置から受信される前記データに係る所有者を示す所有者情報を、前記送信装置に係る所有者を示す所有者情報と同一に設定することを特徴とする請求項１ないし３のいずいれか１項に記載のデータ処理装置。
【請求項５】
前記設定部は、前記自由フロー関数が一つのデータを入力とする場合には、該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該一つのデータに係る所有者を示す所有者情報と同一に設定し、該自由フロー関数が複数のデータを入力とする場合には、該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該複数のデータの各々に係る所有者情報がそれぞれ示す所有者の集合の論理積に設定することを特徴とする請求項１ないし４のいずれか１項に記載のデータ処理装置。
【請求項６】
前記特権フロー関数内に記載されている前記第１の情報は、権限を有する者に係る電子鍵を用いて生成された電子署名に係る情報であり、
前記第２の検証部は、前記第１の情報に基づいて、前記特権フロー関数の正当性を検証することを特徴とする請求項１ないし５のいずれか１項に記載のデータ処理装置。
【請求項７】
前記特権フロー関数内に記載されている前記第２の情報は、所有者を指定する情報であり、
前記第２の実行部は、前記特権フロー関数が出力するデータに係る所有者を示す所有者情報を、前記特権フロー関数が入力するデータに係る所有者を示す所有者情報にかかわらずに、前記第２の情報が指定する所有者を示す所有者情報に設定することを特徴とする請求項１ないし６のいずれか１項に記載のデータ処理装置。
【請求項８】
前記自由フロー関数は、前記通信装置から受信される前記データと他の自由フロー関数が出力するデータと前記特権フロー関数が出力するデータとの少なくとも一つを入力とするものであることを特徴とする請求項１ないし７のいずれか１項に記載のデータ処理装置。
【請求項９】
前記特権フロー関数は、前記通信装置から受信される前記データと前記自由フロー関数が出力するデータと他の特権フロー関数が出力するデータとの少なくとも一つを入力とするものであることを特徴とする請求項１ないし８のいずれか１項に記載のデータ処理装置。
【請求項１０】
前記受信装置へ送信する前記データは、前記通信装置から受信された前記データ又は前記自由フロー関数が出力するデータ若しくは前記特権フロー関数が出力するデータであることを特徴とする請求項１ないし９のいずれか１項に記載のデータ処理装置。
【請求項１１】
外部からの要求に基づいて、前記自由フロー関数及び又は前記特権フロー関数の実行イメージを取得して、前記自由フロー関数実行部及び又は前記特権フロー関数実行部に与える手段を更に備えたことを特徴とする請求項１ないし１４のいずれか１項に記載のデータ処理装置。
【請求項１２】
前記中継部は、前記送信装置からデータを受信した場合に、該データを予め定められた第１のチャネルに与えるものであり、
前記第１の実行部は、予め定められた第２のチャネルからデータを与えられた場合に、該データを入力として前記自由フロー関数を実行し、該自由フロー関数が出力したデータを、予め定められた第３のチャネルに与えるものであり、
前記第２の実行部は、予め定められた第４のチャネルからデータを与えられ場合に、該データを入力として前記特権フロー関数を実行し、該特権フロー関数が出力したデータを、予め定められた第５のチャネルに与えるものであり、
前記中継部は、予め定められた第６のチャネルからデータを与えられた場合に、該データを予め定められた受信装置へ送信するものであることを特徴とする請求項１ないし１１のいずれか１項に記載のデータ処理装置。
【請求項１３】
送信装置からデータを受信し、該データを処理して受信装置へ送信するために、第１の検証部と、設定部と、第２の検証部と、前記送信装置から前記データを受信し、前記受信装置へ前記データを送信する中継部と、データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、データ処理の内容を任意に設定可能な特権フロー関数を実行する第２の実行部とを備えたデータ処理装置のデータ処理方法であって、
前記第１の検証部が、前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証するステップと、
前記設定部が、データ処理の内容を任意に設定可能な自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定するステップと、
前記第２の検証部が、データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証するステップと、
前記第２の実行部が、前記検証に成功した前記特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定するステップと、
前記第１の検証部が、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証するステップとを有することを特徴とするデータ処理方法。
【請求項１４】
送信装置からデータを受信し、該データを処理して受信装置へ送信するために、第１の検証部と、設定部と、第２の検証部と、前記送信装置から前記データを受信し、前記受信装置へ前記データを送信する中継部と、データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、データ処理の内容を任意に設定可能な特権フロー関数を実行する第２の実行部とを備えたデータ処理装置としてコンピュータを機能させるためのプログラムであって、
前記第１の検証部が、前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証するステップと、
前記設定部が、データ処理の内容を任意に設定可能な自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定するステップと、
前記第２の検証部が、データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証するステップと、
前記第２の実行部が、前記検証に成功した前記特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定するステップと、
前記第１の検証部が、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証するステップとをコンピュータに実行させるためのプログラム。
【請求項１】
送信装置からデータを受信し、該データを処理して受信装置へ送信することの可能なデータ処理装置であって、
前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証し、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証する第１の検証部と、
前記送信装置に係る前記検証に成功した場合にのみ、前記送信装置から前記データを受信することが可能であり、前記受信装置に係る前記検証に成功した場合にのみ、前記受信装置へ前記データを送信することが可能である中継部と、
データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、
前記自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定する設定部と、
データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証する第２の検証部と、
前記特権フロー関数に係る前記検証に成功した場合にのみ、前記特権フロー関数を実行することが可能であるとともに、該特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定する第２の実行部とを備えたことを特徴とするデータ処理装置。
【請求項２】
前記第１の検証部は、前記送信装置に係る所有者情報の示す所有者の集合が、前記データ処理装置に係る所有者情報の示す所有者の集合に包含される場合に、前記検証に成功したものとすることを特徴とする請求項１に記載のデータ処理装置。
【請求項３】
前記第１の検証部は、前記受信装置に係る所有者情報の示す所有者の集合が、前記受信装置に送信すべきデータに係る所有者情報が示す所有者の集合に包含される場合に、前記検証に成功したものとすることを特徴とする請求項１に記載のデータ処理装置。
【請求項４】
前記中継部は、前記送信装置から受信される前記データに係る所有者を示す所有者情報を、前記送信装置に係る所有者を示す所有者情報と同一に設定することを特徴とする請求項１ないし３のいずいれか１項に記載のデータ処理装置。
【請求項５】
前記設定部は、前記自由フロー関数が一つのデータを入力とする場合には、該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該一つのデータに係る所有者を示す所有者情報と同一に設定し、該自由フロー関数が複数のデータを入力とする場合には、該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該複数のデータの各々に係る所有者情報がそれぞれ示す所有者の集合の論理積に設定することを特徴とする請求項１ないし４のいずれか１項に記載のデータ処理装置。
【請求項６】
前記特権フロー関数内に記載されている前記第１の情報は、権限を有する者に係る電子鍵を用いて生成された電子署名に係る情報であり、
前記第２の検証部は、前記第１の情報に基づいて、前記特権フロー関数の正当性を検証することを特徴とする請求項１ないし５のいずれか１項に記載のデータ処理装置。
【請求項７】
前記特権フロー関数内に記載されている前記第２の情報は、所有者を指定する情報であり、
前記第２の実行部は、前記特権フロー関数が出力するデータに係る所有者を示す所有者情報を、前記特権フロー関数が入力するデータに係る所有者を示す所有者情報にかかわらずに、前記第２の情報が指定する所有者を示す所有者情報に設定することを特徴とする請求項１ないし６のいずれか１項に記載のデータ処理装置。
【請求項８】
前記自由フロー関数は、前記通信装置から受信される前記データと他の自由フロー関数が出力するデータと前記特権フロー関数が出力するデータとの少なくとも一つを入力とするものであることを特徴とする請求項１ないし７のいずれか１項に記載のデータ処理装置。
【請求項９】
前記特権フロー関数は、前記通信装置から受信される前記データと前記自由フロー関数が出力するデータと他の特権フロー関数が出力するデータとの少なくとも一つを入力とするものであることを特徴とする請求項１ないし８のいずれか１項に記載のデータ処理装置。
【請求項１０】
前記受信装置へ送信する前記データは、前記通信装置から受信された前記データ又は前記自由フロー関数が出力するデータ若しくは前記特権フロー関数が出力するデータであることを特徴とする請求項１ないし９のいずれか１項に記載のデータ処理装置。
【請求項１１】
外部からの要求に基づいて、前記自由フロー関数及び又は前記特権フロー関数の実行イメージを取得して、前記自由フロー関数実行部及び又は前記特権フロー関数実行部に与える手段を更に備えたことを特徴とする請求項１ないし１４のいずれか１項に記載のデータ処理装置。
【請求項１２】
前記中継部は、前記送信装置からデータを受信した場合に、該データを予め定められた第１のチャネルに与えるものであり、
前記第１の実行部は、予め定められた第２のチャネルからデータを与えられた場合に、該データを入力として前記自由フロー関数を実行し、該自由フロー関数が出力したデータを、予め定められた第３のチャネルに与えるものであり、
前記第２の実行部は、予め定められた第４のチャネルからデータを与えられ場合に、該データを入力として前記特権フロー関数を実行し、該特権フロー関数が出力したデータを、予め定められた第５のチャネルに与えるものであり、
前記中継部は、予め定められた第６のチャネルからデータを与えられた場合に、該データを予め定められた受信装置へ送信するものであることを特徴とする請求項１ないし１１のいずれか１項に記載のデータ処理装置。
【請求項１３】
送信装置からデータを受信し、該データを処理して受信装置へ送信するために、第１の検証部と、設定部と、第２の検証部と、前記送信装置から前記データを受信し、前記受信装置へ前記データを送信する中継部と、データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、データ処理の内容を任意に設定可能な特権フロー関数を実行する第２の実行部とを備えたデータ処理装置のデータ処理方法であって、
前記第１の検証部が、前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証するステップと、
前記設定部が、データ処理の内容を任意に設定可能な自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定するステップと、
前記第２の検証部が、データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証するステップと、
前記第２の実行部が、前記検証に成功した前記特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定するステップと、
前記第１の検証部が、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証するステップとを有することを特徴とするデータ処理方法。
【請求項１４】
送信装置からデータを受信し、該データを処理して受信装置へ送信するために、第１の検証部と、設定部と、第２の検証部と、前記送信装置から前記データを受信し、前記受信装置へ前記データを送信する中継部と、データ処理の内容を任意に設定可能な自由フロー関数を実行する第１の実行部と、データ処理の内容を任意に設定可能な特権フロー関数を実行する第２の実行部とを備えたデータ処理装置としてコンピュータを機能させるためのプログラムであって、
前記第１の検証部が、前記送信装置から前記データを受信するのに先立って、前記送信装置に係る所有者を示す所有者情報が、前記データ処理装置に係る所有者を示す所有者情報に適合することを検証するステップと、
前記設定部が、データ処理の内容を任意に設定可能な自由フロー関数が実行された場合に該自由フロー関数が出力するデータに係る所有者を示す所有者情報を、該自由フロー関数が入力するデータに係る所有者を示す所有者情報に基づいて設定するステップと、
前記第２の検証部が、データ処理の内容を任意に設定可能な特権フロー関数の正当性を、該特権フロー関数内に記載されている第１の情報に基づいて検証するステップと、
前記第２の実行部が、前記検証に成功した前記特権フロー関数が実行された場合に該特権フロー関数が出力するデータに係る所有者を示す所有者情報を、該特権フロー関数内に記載されている第２の情報に基づいて設定するステップと、
前記第１の検証部が、前記受信装置へ前記データを送信するのに先立って、前記受信装置に係る所有者を示す所有者情報が、前記データに係る所有者を示す所有者情報に適合することを検証するステップとをコンピュータに実行させるためのプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１０−１６５１７２（Ｐ２０１０−１６５１７２Ａ）
【公開日】平成２２年７月２９日（２０１０．７．２９）
【国際特許分類】
【出願番号】特願２００９−６７９５（Ｐ２００９−６７９５）
【出願日】平成２１年１月１５日（２００９．１．１５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
【公開日】平成２２年７月２９日（２０１０．７．２９）
【国際特許分類】
【出願日】平成２１年１月１５日（２００９．１．１５）
【出願人】（０００００３０７８）株式会社東芝 (54,554)
【Ｆターム（参考）】
[ Back to top ]