JP5218393B2 - リーチャビリティ実現システムおよびリーチャビリティ実現方法 - Google Patents

Description

本発明は、リーチャビリティを実現するリーチャビリティ実現システムおよびリーチャビリティ実現方法に関する。

リーチャビリティとは、ある人や物への到達性のことをいう。以下、あるリーチャビリティ利用者から、あるサービス顧客へのリーチャビリティ（情報などの到達性）を扱うシステムを考える。特開２００３−１０９１６０号公報（特許文献１）および”マイブーメラン”、[online]、ブーメランイット・ジャパン、［平成１９年２月２２日検索］、インターネット＜ＵＲＬ：http://www.bij.jp/＞（非特許文献１）は、リーチャビリティを扱うシステムを記載している。特許文献１には、利用者、つまりリーチャビリティ利用者の身体に異常が発生したことを検知すると、あらかじめ契約した救助者、つまりサービス顧客に、緊急連絡を行う緊急救助支援システムが記載されている。特許文献１には、利用者と救助者とが直接無線を介して契約を行い、利用者が救助者のプロファイル（リーチャビリティ）をあらかじめ登録することが記載されている。なお、サービス顧客は、リーチャビリティを提示する側、例えばアドレスや電話番号を教える側である。

非特許文献１は、あらかじめ紛失物回収代理サービス会社の連絡先と識別子が記載されたラベルを貴重品に貼り付けておくことを記載している。非特許文献１に記載されたサービスでは、貴重品を紛失しても、発見者がラベルに記載された連絡先に連絡してくれた場合には、紛失物回収代理サービス会社は、発見者から貴重品を回収し、ラベルに記載された貴重品の識別子に基づいて所有者を検索して所有者に届けることができる。また、非特許文献１は、発見者が紛失物回収代理サービス会社に自分の連絡先を伝えることにより、紛失物回収代理サービス会社が貴重品の所有者に代わって謝礼をすることを記載している。

しかし、特許文献１や非特許文献１に記載された方式では、緊急救助支援システム利用者、貴重品所有者等のリーチャビリティ利用者や、緊急救助支援システム、紛失物回収代理サービス会社等のサービス提供者が、救助者や貴重品発見者等のサービス顧客へのリーチャビリティを不正に利用することが可能であるという問題がある。

例えば、特許文献１に記載された方式では、契約を行うことにより、利用者が救助者のプロファイルを取得することができる。そのため、救助者がプロファイルを変更しない限り、利用者によって救助者のプロファイルが不正に利用されたり、つきまとわれたりする可能性がある。

非特許文献１に記載された方式では、紛失物回収代理サービス会社が発見者の連絡先を取得するため、発見者が連絡先を変更しない限り、連絡先を謝礼以外の用途に使用されたり、紛失物回収代理サービス会社から不要な連絡を受けたりする可能性がある。また、非特許文献１に記載された方式では、発見者、紛失物回収代理サービス会社以外の第三者（貴重品所有者）がリーチャビリティを利用することはできない。例えば、リーチャビリティ利用者がサービス顧客に連絡することはできない。

発明の概要

そこで、本発明は、サービス顧客へのリーチャビリティが不正に利用されることがなく、リーチャビリティ利用者がサービス顧客に連絡可能なリーチャビリティ実現システムおよびリーチャビリティ実現方法を提供することを目的とする。

本発明は、第１の視点において、サービスを提供する第１の利用者が保有するサービス提供サーバから第２の利用者が使用する利用者端末へのリーチャビリティを実現するリーチャビリティ実現システムであって、
前記第２の利用者に対して連絡可能な現実の宛先を表す実宛先情報と、前記第１の利用者が前記実宛先情報を特定不能なように変換された実宛先情報である変換後宛先情報と、前記変換後宛先情報が有効であるか無効であるかを表す効力フラグと、を、対応付けて宛先情報記憶部に保存する宛先情報保存部と、
前記サービスを提供する業務において、ビジネスフローに沿って実行される処理の実行状態を表す状態情報と、当該状態情報に応じて、前記第２の利用者が利用する利用者端末にアクセスを求めるアクセス要求を送信する送信処理と、前記効力フラグを、当該状態情報に応じて、前記変換後宛先情報が有効であることを表す有効フラグ若しくは前記変換後宛先情報が無効であることを表す無効フラグのいずれかに更新する更新処理と、当該送信処理及び当該更新処理が実行される実行条件を表す条件情報と、を対応付けて記憶する処理情報記憶部と、
前記第２の利用者の変換後宛先情報を含み、前記サービスの提供において前記第２の利用者に生じたイベントを示すイベント情報を受信する受信部と、
前記受信されたイベント情報で表されるイベントの発生により成立した実行条件を表す条件情報と、前記処理の現在の実行状態を示す状態情報と、に対応付けて前記処理情報記憶部に記憶された更新処理及び送信処理を抽出する処理情報抽出部と、
前記抽出された更新処理を実行することで、前記受信された変換後宛先情報に対応付けられた効力フラグを更新する更新部と、
前記効力フラグが更新された後に、前記効力フラグが有効フラグであると、前記抽出された送信処理に従って、前記受信された変換後宛先情報と当該有効フラグとに対応付けられた実宛先情報に基づき、前記アクセス要求を前記第２の利用者が利用する利用者端末に送信する送信部と、を備える、
ことを特徴とするリーチャビリティ実現システムを提供する。

本発明は、第２の視点において、サービスを提供する第１の利用者が保有するサービス提供サーバから第２の利用者が使用する利用者端末へのリーチャビリティをリーチャビリティ実現システムが実現するリーチャビリティ実現方法であって、
前記リーチャビリティ実現システムが、前記第２の利用者に対して連絡可能な現実の宛先を表す実宛先情報と、前記第１の利用者が前記実宛先情報を特定不能なように変換された実宛先情報である変換後宛先情報と、前記変換後宛先情報が有効であるか無効であるかを表す効力フラグと、を、対応付けて宛先情報記憶部に保存する宛先情報保存ステップと、
前記リーチャビリティ実現システムが、前記第２の利用者の変換後宛先情報を含み、前記サービスの提供において前記第２の利用者に生じたイベントを示すイベント情報を受信する受信ステップと、
前記リーチャビリティ実現システムが、前記サービスを提供する業務において、ビジネスフローに沿って実行される処理の実行状態を表す状態情報と、当該状態情報に応じて、前記第２の利用者が利用する利用者端末にアクセスを求めるアクセス要求を送信する送信処理と、前記効力フラグを、当該状態情報に応じて、前記変換後宛先情報が有効であることを表す有効フラグ若しくは前記変換後宛先情報が無効であることを表す無効フラグのいずれかに更新する更新処理と、当該送信処理及び当該更新処理が実行される実行条件を表す条件情報と、を対応付けて記憶する処理情報記憶部から、前記受信されたイベント情報で表されるイベントの発生により成立した実行条件を表す条件情報と、前記処理の現在の実行状態を示す状態情報と、に対応付けて前記処理情報記憶部に記憶された更新処理及び送信処理を抽出する処理情報抽出ステップと、
前記リーチャビリティ実現システムが、前記抽出された更新処理を実行することで、前記受信された変換後宛先情報に対応付けられた効力フラグを更新する更新ステップと、
前記リーチャビリティ実現システムが、前記効力フラグが更新された後に、前記効力フラグが有効フラグであると、前記抽出された送信処理に従って、前記受信された変換後宛先情報と当該有効フラグとに対応付けられた実宛先情報に基づき、前記アクセス要求を前記第２の利用者が利用する利用者端末に送信する送信ステップと、を有する、
ことを特徴とするリーチャビリティ実現方法を提供する。

本発明の上記、及び、他の目的、特徴及び利益は、図面を参照する以下の説明により明らかになる。

第１の実施形態のリーチャビリティ管理システムを例示するブロック図である。 第１の実施形態におけるリーチャビリティ管理システムの動作を例示するシーケンス図である。 リーチャビリティ端末を例示するブロック図である。 リーチャビリティ管理システムを例示するブロック図である。 リーチャビリティＩＤ保持部が、本ＩＤ、リーチャビリティＩＤおよび有効期限を記憶する場合を例示する説明図である。 第２の実施形態のリーチャビリティ管理システムを例示するブロック図である。 リーチャビリティＩＤ保持部が、本ＩＤ、リーチャビリティＩＤおよびサービスＩＤを記憶する場合を例示する説明図である。 リーチャビリティＩＤ保持部が、１つの本ＩＤおよび１つのサービスＩＤに対して、複数のリーチャビリティＩＤを記憶する場合を例示する説明図である。 第３の実施形態におけるリーチャビリティＩＤ管理サーバを例示するブロック図である。 第４の実施形態のリーチャビリティ管理システムを例示するブロック図である。 第５の実施形態のリーチャビリティ管理システムを例示するブロック図である。 リーチャビリティＩＤ管理サーバを例示するブロック図である。 リーチャビリティＩＤ管理サーバの動作を例示するシーケンス図である。 履歴データを例示する説明図である。 第６の実施形態のリーチャビリティ管理システムを例示するブロック図である。 第６の実施形態における現在状態管理テーブルの登録例を示す説明図である。 第６の実施形態におけるフローテンプレートテーブルの登録例を示す説明図である。 第６の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。 第６の実施形態におけるリーチャビリティＩＤ有効性管理テーブルの登録例を示す説明図である。 サービス管理テーブルの登録例を示す説明図である。 加入者がサービスの提供依頼を行う場合のリーチャビリティ管理システムの動作を示すフローチャートである。 リーチャビリティ活用者が加入者に連絡を取る場合のリーチャビリティ管理システムの動作を示すフローチャートである。 イベントが発生した場合のリーチャビリティ管理システムの動作を示すフローチャートである。 第７の実施形態のリーチャビリティ管理システムを例示するブロック図である。 第７の実施形態における現在状態管理テーブルの登録例を示す説明図である。 第７の実施形態におけるフローテンプレートテーブルの登録例を示す説明図である。 第７の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。 第７の実施形態におけるリーチャビリティＩＤ有効性管理テーブルの登録例を示す説明図である。 第８の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。 第９の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。 第１０の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。 第１１の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。 第１２の実施形態のリーチャビリティ管理システムを例示するブロック図である。 第１２の実施形態におけるフローテンプレートテーブルの登録例を示す説明図である。 第１４の実施形態における現在状態管理テーブルの登録例を示す説明図である。 第１４の実施形態におけるフローテンプレートテーブルの登録例を示す説明図である。 第１４の実施形態におけるリーチャビリティＩＤ有効性管理テーブルの登録例を示す説明図である。 第１６の実施形態のリーチャビリティ管理システムを例示するブロック図である。

発明の詳細な説明

以下、図面を参照し、本発明の例示的な実施形態について詳細に説明する。全ての図面では、同様な要素には同様な符号を付してある。
実施形態１
図１は、本発明の第１の実施形態のリーチャビリティ管理システムのブロック図である。リーチャビリティ管理システムは、リーチャビリティ端末１０，２０と、端末３０と、リーチャビリティ適用サーバ１００と、リーチャビリティＩＤ管理サーバ２００と、サービス提供サーバ３００と、外部サービスシステム４００とを備える。

リーチャビリティ端末１０，２０は、例えば、インターネット等の通信ネットワークを介して、リーチャビリティ適用サーバ１００およびサービス提供サーバ３００と通信可能である。リーチャビリティ端末１０，２０は、例えば、パーソナルコンピュータ、ＰＤＡ、モバイル端末等で実現される。リーチャビリティ端末１０は、サービス顧客によって使用される。また、リーチャビリティ端末２０は、リーチャビリティ利用者によって使用される。

リーチャビリティ端末１０は、サービス顧客の本ＩＤとリーチャビリティ利用者の識別子とを含むサービス利用依頼をリーチャビリティ適用サーバ１００に送信する。リーチャビリティ端末２０は、サービス顧客のリーチャビリティＩＤを含む連絡依頼をリーチャビリティ適用サーバ１００に送信する。リーチャビリティ端末１０，２０がパーソナルコンピュータで実現される場合、上記の機能は、パーソナルコンピュータに搭載されるＣＰＵが、それらの機能を実現するためのプログラムを実行することによって実現される。

端末３０は、例えば、インターネット等の通信ネットワークを介して、リーチャビリティ適用サーバ１００からの連絡を受信する。端末３０は、例えば、パーソナルコンピュータ、ＰＤＡ、モバイル端末等で実現される。端末３０は、サービス顧客によって使用される。図１に示す例では、リーチャビリティ端末１０と端末３０とを異なる装置として記載しているが、同じ装置であってもよい。

リーチャビリティ適用サーバ１００は、リーチャビリティＩＤ適用部１１０と、情報配信部１２０とを含む。リーチャビリティＩＤ適用部１１０は、例えば、通信ネットワークを介して、リーチャビリティＩＤ管理サーバ２００およびサービス提供サーバ３００にアクセス可能に接続される。

リーチャビリティＩＤ適用部１１０は、リーチャビリティ端末１０が送信するサービス利用依頼に基づいて、サービス顧客の本ＩＤとリーチャビリティ利用者の識別子とを含むリーチャビリティＩＤ取得依頼をリーチャビリティＩＤ管理サーバ２００に送信し、リーチャビリティＩＤを受信する。リーチャビリティＩＤ適用部１１０は、リーチャビリティＩＤとリーチャビリティ利用者の識別子とを含むサービス提供依頼をサービス提供サーバ３００に送信する。

本ＩＤは、例えば、サービス顧客の電話番号、ｅ−ｍａｉｌアドレス、住所等のサービス顧客にとって変更が容易ではない情報であって、サービス顧客に連絡を取るための宛先情報である。リーチャビリティＩＤは、ある人や物へのリーチャビリティの安全性を保証するために払い出される識別子である。リーチャビリティＩＤは、例えば、電話、ｅ−ｍａｉｌアドレス、住所等の本ＩＤに対応付けて発行される。１つの本ＩＤに対し、複数のリーチャビリティＩＤが発行されてもよく、また、一時的に発行されてもよい。

本実施形態では、本ＩＤに基づいてリーチャビリティＩＤを生成可能とする。リーチャビリティＩＤを生成する演算として、様々なものが知られているが、例えば、ハッシュ値を利用する演算でもよい。例えば、ハッシュ値を利用する演算では、本ＩＤ「0312345678」に基づいて、リーチャビリティＩＤ「3e977b1c3611a85fece041c55ac01ae3」が生成される。

さらに、リーチャビリティＩＤ適用部１１０は、リーチャビリティ端末２０から、リーチャビリティＩＤを含むサービス顧客への連絡依頼を受信する。また、リーチャビリティＩＤ適用部１１０は、リーチャビリティ端末２０からの連絡依頼に基づいて、リーチャビリティＩＤを含む本ＩＤ取得依頼をリーチャビリティＩＤ管理サーバ２００に送信し、本ＩＤを受信する。情報配信部１２は、リーチャビリティＩＤ適用部１１０が受信した本ＩＤに基づいて、サービス顧客によって使用される端末３０に連絡を行う。

リーチャビリティＩＤ管理サーバ２００は、リーチャビリティＩＤ管理部２１０と、リーチャビリティＩＤ保持部２２０とを含む。リーチャビリティＩＤ管理サーバ２００は、例えば、通信ネットワークを介して、リーチャビリティ適用サーバ１００にアクセス可能に接続される。

リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ適用部１１０からのリーチャビリティＩＤ取得依頼に基づいてリーチャビリティＩＤを生成する。リーチャビリティＩＤ管理部２１０は、サービス顧客の本ＩＤと生成したリーチャビリティＩＤとを対応付けてリーチャビリティＩＤ保持部２２０に記憶させるとともに、リーチャビリティＩＤ適用部１１０に送信する。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ適用部１１０からの本ＩＤ取得依頼に基づいて、本ＩＤをリーチャビリティＩＤ適用部１１０に送信する。リーチャビリティＩＤ保持部２２０は、サービス顧客の本ＩＤとリーチャビリティＩＤとを対応付けて記憶する記憶装置である。

サービス提供サーバ３００は、サービス提供フロントエンド３１０と、連絡先管理部３２０とを含む。サービス提供サーバ３００は、例えば、通信ネットワークを介して、リーチャビリティ適用サーバ１００および外部サービスシステム４００にアクセス可能に接続される。なお、サービス提供サーバ３００は、例えば、電話会社、自治体、介護会社等のサービス提供者によって運用されてもよい。

サービス提供フロントエンド３１０は、リーチャビリティＩＤ適用部１１０が送信するサービス提供依頼に基づいて、サービス提供依頼に含まれるリーチャビリティＩＤおよびリーチャビリティ利用者の識別子を連絡先管理部３２０に記憶させる。また、サービス提供フロントエンド３１０は、外部サービスシステム４００にリーチャビリティ利用者の識別子を含むサービス実行依頼を送信する。連絡先管理部３２０は、リーチャビリティＩＤおよびリーチャビリティ利用者の識別子を記憶する記憶装置である。

外部サービスシステム４００は、例えば、サービス提供者が各種外部サービスを提供するために運営するサーバである。外部サービスシステム４００は、例えば、サービス提供サーバ３００が送信するサービス実行依頼を受信し、受信したリーチャビリティ利用者の識別子に基づいて実際のサービスを提供したり、サービス提供のための受付等を行う。

次に、第１の実施形態の動作について説明する。サービス顧客は、リーチャビリティ端末１０を利用して、リーチャビリティ適用サーバ１００を介して、外部サービスシステム４００が提供するサービスを利用する。そして、リーチャビリティ利用者は、リーチャビリティ適用サーバ１００を介してサービス顧客へ連絡をとることができる。

具体的な例では、通報者（サービス顧客）が、リーチャビリティ適用サーバ１００を介してレスキューサービスへ緊急救助が必要な患者がいることを通報すると、レスキューサービスが実行され患者が救助される。患者（リーチャビリティ利用者）は、レスキュー通報のお礼をするために、リーチャビリティ適用サーバ１００に対し通報者への連絡依頼を行う。リーチャビリティ適用サーバ１００は、お礼の連絡を通報者に行う。

ここで、サービス顧客は、患者の識別子を知ることができると仮定する。例えば、患者が常時携帯している名札に識別子が記載されており、或いは、患者が自身の識別子のデータが記録された電子タグを所持しておれば、サービス顧客は、患者の識別子を知ることができる。以下、外部サービスシステム４００が提供するサービスがレスキューサービスである場合を例にして説明する。

図２は、第１の実施形態におけるリーチャビリティ管理システムの動作を例示するシーケンス図である。サービス顧客（通報者）が、自身のリーチャビリティ端末１０を操作することにより（ステップＳ１）、リーチャビリティ端末１０は、サービス顧客の本ＩＤ（例えば、電話番号）とリーチャビリティ利用者（患者）の識別子とを含むサービス利用依頼をリーチャビリティ適用サーバ１００に送信する（ステップＳ２）。なお、ステップＳ１，Ｓ２の処理は、レスキューサービスへの通報にあたる。

リーチャビリティＩＤ適用部１１０は、受信したサービス利用依頼に基づいて、サービス顧客の本ＩＤを含むリーチャビリティＩＤ取得依頼をリーチャビリティＩＤ管理サーバ２００に送信する（ステップＳ３）。リーチャビリティＩＤ管理部２１０は、受信したサービス顧客の本ＩＤに対応付けてリーチャビリティＩＤを生成する。リーチャビリティＩＤ管理部２１０は、サービス顧客の本ＩＤと生成したリーチャビリティＩＤとの対をリーチャビリティＩＤ保持部２２０に記憶させる（ステップＳ４）。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ適用部１１０に、生成したリーチャビリティＩＤを送信する（ステップＳ５）。

リーチャビリティＩＤ適用部１１０は、サービス顧客のリーチャビリティＩＤとリーチャビリティ利用者の識別子とを含むサービス提供依頼をサービス提供サーバ３００に送信する（ステップＳ６）。サービス提供フロントエンド３１０は、受信したサービス提供依頼に基づいて、サービス顧客のリーチャビリティＩＤと患者の識別子とを連絡先管理部３２０に記憶させる（ステップＳ７）。サービス提供フロントエンド３１０は、外部サービスシステム４００にサービス実行依頼を送信する（ステップＳ８）。本実施例では、患者の救助が行われる。

リーチャビリティ利用者が、自身のリーチャビリティ端末２０を操作することにより（ステップＳ１１）、リーチャビリティ端末２０は、連絡先管理部３２０に患者の識別子を含む連絡先取得依頼を送信し（ステップＳ１２）、連絡先管理部３２０に記憶された通報者のリーチャビリティＩＤを受信する（ステップＳ１３）。リーチャビリティ端末２０は、サービス顧客への連絡依頼をリーチャビリティＩＤ適用部１１０に送信する（ステップＳ１４）。連絡依頼は、サービス顧客のリーチャビリティＩＤを含む情報である。

リーチャビリティＩＤ適用部１１０は、リーチャビリティＩＤ管理部２１０に、リーチャビリティＩＤを含む本ＩＤ取得依頼を送信する（ステップＳ１５）。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ保持部２２０に、サービス顧客のリーチャビリティＩＤを含む本ＩＤ取得依頼を出力する（ステップＳ１６）。リーチャビリティＩＤ保持部２２０は、リーチャビリティＩＤに基づいて、記憶している本ＩＤとリーチャビリティＩＤの対から該当するサービス顧客の本ＩＤを抽出し、リーチャビリティＩＤ管理部２１０に出力する（ステップＳ１７）。リーチャビリティＩＤ管理部２１０は、サービス顧客の本ＩＤを入力し、リーチャビリティＩＤ適用部１１０に送信する（ステップＳ１８）。

リーチャビリティＩＤ適用部１１０は、情報配信部１２０に、サービス顧客の本ＩＤを含む連絡依頼を出力する（ステップＳ１９）。情報配信部１２０は、サービス顧客の本ＩＤに基づいて、端末３０に連絡を行い（ステップＳ２０）、サービス顧客は、端末３０を用いて連絡を受ける（ステップＳ２１）。本実施例において、本ＩＤが電話番号である場合には、情報配信部１２０は、サービス顧客に電話をかけてもよい。この場合、端末３０は、固定電話機や携帯電話機等であってもよい。

以上に説明したように、第１の実施形態によれば、本ＩＤをサービス提供者（外部サービスシステム４００）やリーチャビリティ利用者（患者）が知ることができないので、サービス顧客にとっては、サービスを利用しても本ＩＤを不正に利用されることがないという効果がある。

また、サービス顧客が本ＩＤをトレースされる脅威にさらされることなくサービスを利用することができるので、気軽に本実施形態における通報を行うことができる。さらに、患者が通報者に救助に対するお礼をすることができる。

また、リーチャビリティＩＤをサービス顧客のサービス利用ごとに生成することにより、単一サービス内においてリーチャビリティＩＤのトレースが行われることを防ぐことができる。

リーチャビリティ端末１０は、本ＩＤ解析部１１と、サービス利用依頼送信部１２とを備えてもよい。図３は、リーチャビリティ端末を例示するブロック図である。本ＩＤ解析部１１は、サービス顧客の本ＩＤを解析する。本ＩＤ解析部１１は、例えば、対話形式で画面表示等を行うことにより、サービス顧客に本ＩＤの入力を促す。また、本ＩＤ解析部１１は、例えば、指紋認証を行うことにより、本ＩＤを検索する。

サービス利用依頼送信部１２は、リーチャビリティ適用サーバ１００のリーチャビリティＩＤ適用部１１０に、サービス顧客の本ＩＤを含むサービス利用依頼を送信する。なお、図３には、リーチャビリティ管理システムにおけるリーチャビリティ端末１０およびリーチャビリティ適用サーバ１００のリーチャビリティＩＤ適用部１１０のみが示されている。

リーチャビリティＩＤは再利用してもよい。リーチャビリティＩＤ管理部２１０は、ステップＳ４においてリーチャビリティＩＤを生成する前に、リーチャビリティＩＤ保持部２２０に対し、本ＩＤに対応するリーチャビリティＩＤを既に記憶しているか否かを問い合わせる。既にリーチャビリティＩＤが生成され、リーチャビリティＩＤ保持部２２０に記憶されていた場合、リーチャビリティＩＤ管理部２１０は、生成済みのリーチャビリティＩＤをリーチャビリティＩＤ適用部に送信する。リーチャビリティＩＤをサービス毎に生成することにより、複数サービス間でリーチャビリティＩＤのトレースが行われることを防ぐことができる。

リーチャビリティ管理システムは、リーチャビリティＩＤ管理端末４０を備えてもよい。図４は、リーチャビリティ管理システムを例示するブロック図である。なお、図４には、リーチャビリティ管理システムにおけるリーチャビリティＩＤ管理端末４０およびリーチャビリティＩＤ管理サーバ２００のみが示されている。

リーチャビリティＩＤ管理端末４０は、例えば、通信ネットワークを介して、リーチャビリティＩＤ管理サーバ２００にアクセス可能に接続される。任意のユーザが、リーチャビリティＩＤ管理端末４０を利用して、リーチャビリティＩＤを更新してもよい。

また、リーチャビリティＩＤ管理部２１０は、ステップＳ１８の処理の後に、リーチャビリティＩＤ保持部２２０のリーチャビリティＩＤを更新してもよい。

また、リーチャビリティＩＤに有効期限を設けてもよい。図５は、リーチャビリティＩＤ保持部２２０が、本ＩＤ、リーチャビリティＩＤおよび有効期限を記憶する場合を例示する説明図である。リーチャビリティＩＤ適用部１１０は、リーチャビリティＩＤ保持部２２０が記憶するリーチャビリティＩＤのうち、リーチャビリティＩＤ有効期限を過ぎたものを更新してもよい。

実施形態２
次に、本発明の第２の実施形態を説明する。図６は、本実施形態のリーチャビリティ管理システムを例示するブロック図である。第２の実施形態のリーチャビリティ管理システムは、第１の実施形態におけるサービス提供サーバ３００に代えてサービス提供サーバ３００−１，３００−２，・・・，３００−Ｎを備える。また、リーチャビリティ適用サーバ１００は、リーチャビリティＩＤ適用部１１０と、情報配信部１２０と、サービス提供者解決部１３０とを含む。サービス提供サーバ３００−１，３００−２，・・・，３００−Ｎは、それぞれサービス提供フロントエンド３１０−１，３１０−２，・・・，３１０−Ｎを含む。

第２の実施形態において、リーチャビリティＩＤ適用部１１０は、複数のサービス提供サーバ３００−１，３００−２，・・・，３００−Ｎにアクセスしてもよい。さらに、リーチャビリティＩＤ適用部１１０は、サービス提供者解決部１３０にアクセスしてもよい。なお、図６には、リーチャビリティ管理システムにおけるリーチャビリティ適用サーバ１００およびサービス提供サーバ３００−１，２，Ｎのみが示されている。

サービス提供者解決部１３０は、例えば、サービスを識別可能なサービスＩＤに対応させて、サービス提供サーバを識別可能なサービス提供サーバＩＤをあらかじめ記憶する。リーチャビリティ適用サーバ１００は、例えば、リーチャビリティ端末１０から、サービスＩＤを含むサービス利用依頼を受信する。

サービス提供者解決部１３０は、受信したサービスＩＤに基づいて、記憶するサービス提供サーバＩＤを選択することにより、リーチャビリティＩＤ適用部１１０がどのサービス提供サーバへアクセスするべきかを判断し、アクセスすべきサービスのアドレスをリーチャビリティＩＤ適用部１１０に出力する。

例えば、サービスＩＤ“rescue123456”を入力した場合、サービス提供者解決部１３０は、サービスＩＤ“rescue123456”に対応するサービス提供サーバＩＤ”http://www.example.com/ ”を選択する。そして、サービス提供者解決部１３０は、アクセスすべきサービスのアドレスとして”http://www.example.com/~rescue123456”をリーチャビリティＩＤ適用部１１０に出力する。

リーチャビリティＩＤ保持部２２０は、本ＩＤ、リーチャビリティＩＤ、サービスＩＤのセットを記憶してもよい。図７は、リーチャビリティＩＤ保持部２２０が、本ＩＤ、リーチャビリティＩＤおよびサービスＩＤを記憶する場合を例示する説明図である。例えば、第１の実施形態における例では、サービスＩＤとしてレスキューサービスを示す識別子が記憶される。

リーチャビリティＩＤ管理部２１０は、１つの本ＩＤに対して複数のリーチャビリティＩＤを生成してもよい。リーチャビリティＩＤ管理部２１０は、１つの本ＩＤおよび１つのサービスＩＤに対して、複数のリーチャビリティＩＤを生成し、リーチャビリティＩＤ保持部２２０に記憶させてもよい。図８は、リーチャビリティＩＤ保持部２２０が、１つの本ＩＤおよび１つのサービスＩＤに対して、複数のリーチャビリティＩＤを記憶する場合を例示する説明図である。

また、リーチャビリティＩＤ管理部２１０は、１つの本ＩＤに対して、サービス毎にリーチャビリティＩＤを生成してもよい。

実施形態３
次に、本発明の第３の実施形態を説明する。図９は、本実施形態におけるリーチャビリティＩＤ管理サーバ２００を例示するブロック図である。第３の実施形態において、リーチャビリティＩＤ管理サーバ２００は、リーチャビリティＩＤ管理部２１０と、リーチャビリティＩＤ保持部２２０と、リーチャビリティＩＤ利用履歴管理部２３０とを含む。

リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ利用履歴管理部２３０にアクセス可能に接続される。リーチャビリティＩＤ利用履歴管理部２３０は、リーチャビリティＩＤ適用部１１０からリーチャビリティＩＤ管理サーバ２００へのリーチャビリティＩＤ生成依頼（取得依頼）や本ＩＤ取得要求を、履歴データとして、例えば、記憶装置（図示せず。）に記憶させる。

実施形態４
次に、本発明の第４の実施形態を説明する。図１０は、本実施形態のリーチャビリティ管理システムを例示するブロック図である。第４の実施形態において、サービス提供サーバ３００は、サービス提供フロントエンド３１０と、連絡先管理部３２０と、連絡先閲覧履歴３３０とを含む。なお、図１０には、リーチャビリティ管理システムにおけるサービス提供サーバ３００、外部サービスシステム４００およびリーチャビリティ端末２０のみが示されている。

連絡先管理部３２０は、連絡先閲覧履歴３３０にアクセス可能に接続される。連絡先管理部３２０は、リーチャビリティ利用者によって使用されるリーチャビリティ端末２０が連絡先管理部３２０からリーチャビリティＩＤを取得する処理等の一連の利用履歴を連絡先閲覧履歴３３０に記憶させてもよい。連絡先閲覧履歴３３０は、利用履歴を記憶する記憶装置である。なお、連絡先閲覧履歴３３０は、外部からアクセス可能であってもよい。すなわち、連絡先閲覧履歴３３０は、記憶する利用履歴の閲覧要求を受信する部を有してもよい。例えば、連絡先閲覧履歴３３０が記憶する利用履歴に基づいて、課金を行うことができる。

実施形態５
次に、本発明の第５の実施形態を図面を参照して説明する。図１１は、第５の実施形態のリーチャビリティ管理システムを例示するブロック図である。第５の実施形態において、リーチャビリティＩＤ管理サーバ２００は、リーチャビリティＩＤ管理部２１０と、リーチャビリティＩＤ保持部２２０と、リーチャビリティＩＤ有効条件評価部２４０と、リーチャビリティＩＤ有効条件保持部２５０とを含む。なお、図１１には、リーチャビリティ管理システムにおけるリーチャビリティＩＤ管理サーバ２００およびリーチャビリティＩＤ管理端末４０のみが示されている。

第５の実施形態では、リーチャビリティＩＤを利用可能な条件を示すリーチャビリティＩＤ有効条件に基づいて、リーチャビリティＩＤが利用される。リーチャビリティＩＤ有効条件は、例えば、［ＩＦ Ｃ：リーチャビリティ利用者 ＴＨＥＮ 本ＩＤ変換許可］等のＩＦ ＴＨＥＮルールである。すなわち、リーチャビリティＩＤ有効条件は、例えば、リーチャビリティ利用者からサービス顧客への連絡が可能となるための条件である。例えば、リーチャビリティＩＤ適用部１１０は、リーチャビリティＩＤを含むサービス顧客への連絡依頼を受信した場合に、リーチャビリティＩＤ有効条件に基づいて、以降の処理を行うか否かを判断する。

リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効条件評価部２４０にアクセス可能に接続される。リーチャビリティＩＤ有効条件評価部２４０は、リーチャビリティＩＤ有効条件保持部２５０にアクセス可能に接続される。サービス提供者は、リーチャビリティＩＤ管理端末４０を利用して、リーチャビリティＩＤ有効条件保持部２５０が記憶するリーチャビリティＩＤ有効条件を更新することができる。また、サービス提供者以外のユーザが、端末を利用してリーチャビリティＩＤ有効条件の更新を行ってもよい。

第５の実施形態によれば、リーチャビリティＩＤ有効条件を設定することにより、サービス顧客とサービス提供側双方の合意の下でリーチャビリティの安全性を確保して利用することができる。なお、リーチャビリティ有効条件をサービス毎に設けてもよい。また、サービス顧客がサービスを利用する際に、利用するサービスに設定されたリーチャビリティ有効条件を確認してもよい。また、サービス顧客がサービスを利用する際に、利用するサービスに設定されたリーチャビリティ有効条件を更新してもよい。

リーチャビリティＩＤ有効条件に状態記述を行うことが可能であってもよい。図１２は、リーチャビリティＩＤ管理サーバ２００を例示するブロック図である。リーチャビリティＩＤ管理サーバ２００は、リーチャビリティＩＤ管理部２１０と、リーチャビリティＩＤ保持部２２０と、リーチャビリティＩＤ利用履歴管理部２３０と、リーチャビリティＩＤ有効条件評価部２４０と、リーチャビリティＩＤ保持部２５０とを含む。

リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ利用履歴管理部２３０およびリーチャビリティＩＤ有効条件評価部２４０にアクセス可能に接続される。リーチャビリティＩＤ有効条件評価部２４０は、リーチャビリティＩＤ有効条件保持部２５０にアクセス可能に接続される。

次に、図１２に例示するリーチャビリティＩＤ管理サーバ２００の動作について説明する。図１３は、図１２のリーチャビリティＩＤ管理サーバ２００の動作を例示するシーケンス図である。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ適用部１１０からの本ＩＤ取得依頼を受けると（ステップＳ３１）、リーチャビリティＩＤ有効条件評価部２４０に対して、リーチャビリティＩＤと共にリーチャビリティＩＤの有効条件評価を依頼する（ステップＳ３２）。

リーチャビリティＩＤ有効条件評価部２４０は、リーチャビリティＩＤ有効条件保持部２５０から、リーチャビリティＩＤに紐づくリーチャビリティＩＤ有効条件を取得する（ステップＳ３３）。リーチャビリティＩＤ有効条件評価部２４０は、リーチャビリティＩＤ利用履歴管理部２３０から履歴データを取得する（ステップＳ３４）。

リーチャビリティＩＤ有効条件評価部２４０は、リーチャビリティＩＤ有効条件と履歴データとに基づいてリーチャビリティ有効条件を評価する（ステップＳ３５）。リーチャビリティＩＤ有効条件は、例えば、リーチャビリティＩＤの利用制限数であってもよい。図１４は、履歴データを例示する説明図である。例えば、リーチャビリティＩＤ有効条件が、［ＩＦ リーチャビリティＩＤ（3e977b1c3611a85fece041c55ac01ae3）利用回数が３回を越えている ＴＨＥＮ 本ＩＤ変換拒否］であって、履歴データが図１４に示すデータである場合、評価結果は偽となる。リーチャビリティＩＤ有効条件評価部２４０は、リーチャビリティＩＤ管理部２１０に評価結果を出力する（ステップＳ３６）。

リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効条件評価部２４０が出力した評価結果を、リーチャビリティＩＤ適用部１１０に送信する（ステップＳ３７）。上記の例では、リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ適用部１１０に本ＩＤ取得不可を示す情報を送信する。

上記実施形態によれば、リーチャビリティ利用者は、サービス提供者へのリーチャビリティの安全性を確保してサービス顧客へ連絡をとることができる。また、リーチャビリティＩＤを任意のタイミングで更新することができる。また、サービス顧客は、リーチャビリティＩＤを制御することにより、任意のタイミングで、サービス提供者やリーチャビリティ利用者からの連絡を遮断することができる。また、リーチャビリティ利用者は、サービス提供者によって提供されるサービスを利用したサービス顧客に対し、リーチャビリティ管理システムを介して連絡をとることができる。

リーチャビリティ管理システムの運営者は、リーチャビリティ利用履歴をとることにより、例えば、リーチャビリティ利用料をサービス提供者やリーチャビリティ利用者から徴収することができる。例えば、サービス提供者からはリーチャビリティ提供料を、リーチャビリティ利用者からはサービス提供者への連絡送信料を徴収してもよい。

サービス提供者は、リーチャビリティ利用履歴をとることにより、サービス顧客のリーチャビリティ取得料を、リーチャビリティ利用者から徴収することが出来る。また、例えば、モバイル端末を利用したレストラン予約サービスにおいて、レストランの客は、本ＩＤを明かさずにレストランの待ち行列に並ぶことができる。また、レストランの店員は、リーチャビリティＩＤを利用してレストランの予約に関するお知らせを送ることができる。

例えば、ローンの相談サービスにおいて、ローンの相談者は、本ＩＤを明かさずにローンの相談をすることができ、ローン会社側から連絡を取られることがない。また、ローンの相談者は、一時的に自分のリーチャビリティをローン窓口に渡すことができる。

また、例えば、紛失物回収サービスにおいて、落とし物を拾った人は、本ＩＤを明かさずに紛失物を届けることができるとともに、謝礼を受け取ることができる。また、落とし物をした人は、身元を明かさずに謝礼を行うことができる。

実施形態６
本発明の第６の実施形態を説明する。なお、以下に示す第６の実施形態以降の実施形態では、第１の実施形態〜第５の実施形態と同様に、リーチャビリティとは、ある人や物などサービス顧客への到達性のことをいう。ｅ−ｍａｉｌや電話などのコミュニケーション部は、人へのリーチャビリティを利用したサービスである。また、物へのリーチャビリティを利用したサービスには、カラオケ装置やビデオ装置などへのプログラムやデータなどの配付などがある。

以下に示す第６の実施形態以降の実施形態において、リーチャビリティＩＤとは、サービス顧客へのリーチャビリティを保証するために、サービス提供者に払い出される「識別子」のことである。リーチャビリティＩＤの払い出し方法はいくつかある。例えば、サービス顧客がサービス利用依頼を行う度に払い出す方法や、サービス提供者とサービス顧客との組み合わせ毎に払い出す方法等が挙げられる。後者の場合、同じサービス提供者へのサービス利用依頼を複数行っても、リーチャビリティＩＤは一つだけ払いだされる。前者、後者共にサービス提供者間で共通のリーチャビリティＩＤが払い出されることはない。

また、以下に示す第６の実施形態以降の実施形態において、用語は以下のように定める。本ＩＤは、リーチャビリティを具体化するシステム（メールシステム、電話サービスなど）の中でサービス顧客毎に払い出される「識別子」である。例えば、本ＩＤは、電話番号や、電子メールアドレス、住所等である。ビジネスフローとは、ある業務におけるビジネスプロセスのことである。例えば、レストラン予約処理業務では、ビジネスフローは、顧客からの予約を受理してから顧客用の席を用意する等の業務における始点から終点までの処理の流れを指す。ビジネスフローテンプレートとは、ビジネスフローを状態遷移モデルに従って実現したものである。なお、以下、ビジネスフローテンプレートを、フローテンプレートと省略して記載することがある。

第６の実施形態以降の実施形態に関連するリーチャビリティを扱うシステムが以下に示す各文献に記載されている。例えば、特許文献１は、救助される側（リーチャビリティ活用者）と、救助を行う側（サービス顧客）とが、直接無線を介して契約のやりとりを行うことを記載している。

特許文献１に記載されたシステムでは、契約を行うことにより、リーチャビリティ活用者にサービス顧客の本ＩＤが知られてしまう。そのため、サービス顧客が本ＩＤを変更しない限り、リーチャビリティ活用者からの迷惑メールなどを受け取ってしまう虞がある。さらに、本ＩＤを無効化することが容易でないため、救助サービスを解約しても、リーチャビリティを無効化することができない。

第１の実施形態〜第５の実施形態には、本ＩＤの代わりに、本ＩＤと関連付けたリーチャビリティＩＤをサービス提供者に提供するシステムが記載されている。サービス提供者は、そのリーチャビリティＩＤを利用して、リーチャビリティを制御するシステムにサービス顧客へのリーチャビリティを要求することで、サービス顧客の匿名性を保持する。さらに、リーチャビリティＩＤの有効性の評価条件として、例えば、「利用回数３回未満」や、「利用期限（2010/01/01）以内」といった値を設定し評価することにより、サービス提供者に対してリーチャビリの利用制限をおこなっている。

非特許文献１に記載された関連サービスでは、サービス提供サーバ（マイブーメラン）側にサービス顧客の本ＩＤが保存されてしまう。そのため、サービス顧客は、本ＩＤを変更しない限り、サービス提供側（レスキューサービス）につきまとわれてしまう可能性がある。さらに、本ＩＤを無効化することが容易でないため、マイブーメランを解約しても、リーチャビリティを無効化することができない。

上記の各文献に記載されている関連するリーチャビリティ制御システムでは、サービスのビジネスフローに応じてリーチャビリティＩＤの有効性を評価することまではしていない。また、通信事業者（以下、キャリアと呼ぶ）の情報資産（例えば、本ＩＤ）を利用したサービスのフローに密接に関わるような細かなリーチャビリティＩＤの制御を行うキャリアの共通基盤がなかった。

そのため、上記の各文献に記載されている関連するリーチャビリティ制御システムでは、サービスに特化した条件を設定、評価し、条件を満たす場合にリーチャビリティを有効にするような詳細な制御はできない。例えば、リーチャビリティＩＤ”Ａ”のサービス顧客がサービス提供者のサービスに入会中でかつ来店しているときのみリーチャビリティを与え、サービス顧客がリーチャビリティを必要とするとき、または迷惑と感じないときに、サービス提供者へリーチャビリティを有効にするような詳細な制御はできない。

さらに、サービス顧客が必要とするときだけ又は迷惑と感じないときだけ、サービス提供者に対してサービス顧客へのリーチャビリティを有効にする制御を行い、或いは、サービス顧客の匿名性を保持したままリーチャビリティを提供するかどうか保証できるようにすることが好ましい。そのためには、サービス提供者毎に、ビジネスフローを取得し検証する。

第６の実施形態では、加入者のリーチャビリティＩＤとビジネスフローの現在状態を関連付け、ビジネスフローにリーチャビリティの有効性を制御するアクションやそのパラメータを設定することにより、ビジネスフローに応じたリーチャビリティの制御を自動的に行うことが可能となる。

以下、第６の実施形態について説明する。本実施形態では、サービス提供者をレストラン事業者、サービス顧客をキャリアの加入者とし、レストラン事業者から加入者へのリーチャビリティを制御する事業者をキャリアパートナーまたはキャリアとする。

図１５は、第６の実施形態のリーチャビリティ管理システムを例示するブロック図である。リーチャビリティ管理システムは、レストラン事業者が操作する「サービス運用端末１０２０」と、加入者が所有する「連絡受信端末１０３０」および「サービス利用端末１０１０」と、キャリアパートナーまたはキャリアが運営する「リーチャビリティ適用サーバ１００」、「リーチャビリティＩＤ管理サーバ２００」および「リーチャビリティ利用フロー管理サーバ１３００」とを備える。

サービス利用端末１０１０、サービス運用端末１０２０、連絡受信端末１０３０、リーチャビリティ適用サーバ１００、リーチャビリティＩＤ管理サーバ２００およびリーチャビリティ利用フロー管理サーバ１３００は、それぞれプログラムに従って動作するパーソナルコンピュータ等の情報処理装置によって実現される。また、サービス利用端末１０１０、サービス運用端末１０２０、連絡受信端末１０３０、リーチャビリティ適用サーバ１００、リーチャビリティＩＤ管理サーバ２００およびリーチャビリティ利用フロー管理サーバ１３００は、それぞれキャリアのネットワークに接続可能である。

サービス利用端末１０１０および連絡受信端末１０３０は、加入者１１０４によって利用される。サービス利用端末１０１０は、サービス利用依頼部１１０５を備えている。サービス利用依頼部１１０５は、リーチャビリティ適用サーバ１００に対してサービス利用依頼を送信する機能を備える。サービス利用端末１０１０は、例えば、非接触ＩＣカードリーダー等で実現される。

連絡受信端末１０３０は、連絡受信部１１０６を備えている。連絡受信部１１０６は、リーチャビリティ適用サーバ１００からの連絡を受ける部である。連絡受信部１１０６は、例えば、ｅ−ｍａｉｌ受信機能やＩＭ（インスタントメッセージ）クライアント機能等で実現され、連絡受信端末１０３０は、これらの機能を備えた携帯端末等で実現される。

リーチャビリティ適用サーバ１００は、情報配信部１１０８と、リーチャビリティＩＤ適用部１１０７とを備えている。情報配信部１１０８は、本ＩＤを基に連絡受信部１１０６へ連絡を送信する機能を備えている。リーチャビリティＩＤ適用部１１０７は、リーチャビリティＩＤ管理部２１０を利用して本ＩＤとリーチャビリティＩＤとを相互に変換したり、サービス提供フロントエンド１１０９にサービス依頼を転送したりする機能を備えている。

リーチャビリティＩＤ管理サーバ２００は、リーチャビリティＩＤ管理部２１０を備える。

リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを保持するとともに、本ＩＤをキーとしたリーチャビリティＩＤ取得要求に対して、リーチャビリティＩＤを返したり、リーチャビリティＩＤの有効性を変更したりする機能を持つ。リーチャビリティＩＤ有効性管理テーブルについては後述する。

リーチャビリティ利用フロー管理サーバ１３００は、サービス提供フロントエンド１１０９と、フローデータ保持部１１０１と、フローテンプレート保持部１１０２と、イベント評価部１１１０と、アクション実行部１１１１と、サービスＩＤ管理部１１１２とを備える。サービス提供フロントエンド１１０９は、サービス提供依頼を受けると、サービスＩＤに対応するイベント評価部１１１０に、サービス提供依頼を転送する機能を備えている。

サービスＩＤは、後述するリーチャビリティＩＤ活用アプリケーション１１１３の識別子である。例えば、リーチャビリティＩＤ管理サーバ２００がサービスＩＤを発行、管理してもよい。サービス提供者が複数のリーチャビリティＩＤ活用サービスを提供する場合、サービスＩＤも複数となる。

フローデータ保持部１１０１、イベント評価部１１１０およびアクション実行部１１１１は、自身と対応するサービスＩＤを保持している。保持するサービスＩＤは複数であってもよい。フローデータ保持部１１０１、イベント評価部１１１０およびアクション実行部１１１１は、ビジネスフローテンプレート毎に生成される。例えば、レストラン席予約用フローテンプレートを利用するレストランＡ席予約サービスとレストランＢ席予約サービスとがある場合、席予約サービス毎にこれら３つの部が生成される。なお、ビジネスフローテンプレートは、ビジネスフローを状態遷移モデルに従って実現したものであって、「フローテンプレート」と省略して記載する場合もある。フローテンプレートについては後述する。

フローデータ保持部１１０１は、現在状態管理テーブルを保持、管理している。現在状態管理テーブルには、リーチャビリティＩＤに対応付けて、フローの現在状態が登録されている。以下、現在状態管理テーブルに登録されている情報をフローデータと表記する場合がある。

イベント評価部１１１０は、リーチャビリティＩＤ活用アプリケーション１１１３からイベントを受信すると、受信したイベント内の情報と、フローテンプレート保持部１１０２が記憶するフローテンプレートと、フローデータ保持部１１０１が記憶するフローデータとに基づいて、実行すべきアクションを決定する。すなわち、イベント評価部１１１０は、イベント内の情報、フローテンプレートおよびフローデータに基づいて、実行すべきアクションを決定する。なお、イベントとは、例えば、ビジネスフローにおける出来事を意味する。また、ビジネスフローにおける出来事を示す情報を、単にイベントと表記する場合がある。また、イベントは、状態を示す情報として、例えば“来場者が１００人になった”ことを示し、或いは、その他の場合として、例えば”１人来場した”情報などを示してもよい。

アクション実行部１１１１は、イベント評価部１１１０の決定に基づいて、フローテンプレートに設定されたアクションを実行する。アクションの例として、リーチャビリティＩＤ管理部２１０が記憶するリーチャビリティＩＤ有効性管理テーブルに対してリーチャビリティＩＤを有効に設定する、無効に設定する等の処理が挙げられる。フローテンプレート保持部１１０２は、ビジネスフローが記述されたフローテンプレートテーブルを保持、管理している。フローテンプレートテーブルについては後述する。

サービスＩＤ管理部１１１２は、サービスＩＤと、サービス毎の連絡先とが記述されたサービスＩＤ管理テーブルを保持、管理している。サービスＩＤ管理テーブルについては後述する。サービス運用端末１０２０は、リーチャビリティＩＤ活用アプリケーション１１１３を備える。リーチャビリティＩＤ活用アプリケーション１１１３は、リーチャビリティ利用フロー管理サーバ１３００からイベントを受信する機能、リーチャビリティ利用フロー管理サーバ１３００に対してイベントを送信する機能、およびリーチャビリティ適用サーバ１００にリーチャビリティＩＤを利用してサービス顧客（本実施例における加入者）に対する連絡依頼を行う機能を備える。

リーチャビリティＩＤ活用アプリケーション１１１３は、リーチャビリティ利用フロー管理サーバ１３００から受けたイベント通知をトリガとして駆動し、アクションを行うようなフローを運用してもよい。アクションの例として、リーチャビリティ適用サーバ１００に対するリーチャビリティＩＤを利用した加入者への連絡依頼が挙げられる。サービス運用端末１０２０のリーチャビリティＩＤ活用アプリケーション１１１３は、リーチャビリティ活用者１１１４によって利用される。

図１６は、第６の実施形態におけるフローデータ保持部１１０１が保持管理している現在状態管理テーブルの登録例を示す説明図である。現在状態管理テーブルは、リーチャビリティＩＤとフローの現在状態とを少なくとも項目に持つ。現在状態管理テーブルは、具体的には、リーチャビリティ利用フロー管理サーバ１３００のハードディスク装置やメモリ等の記憶装置に記憶される。

図１７は、第６の実施形態におけるフローテンプレート保持部１１０２が保持管理しているフローテンプレートテーブルの登録例を示す説明図である。図１７には、レストラン席予約用フローテンプレートテーブルを例示する。フローテンプレートテーブルは、現在状態、コンディション、アクションおよび遷移先を項目に持つ。アクションの値として、後述するリーチャビリティＩＤアクションテーブルに登録されている変数を記載してもよい。コンディションは、例えば、イベントに対応する情報である。フローテンプレートテーブルは、具体的には、リーチャビリティ利用フロー管理サーバ１３００のハードディスク装置やメモリ等の記憶装置に記憶される。

図１８は、第６の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。リーチャビリティＩＤアクションテーブルは、変数およびアクションを項目に持つ。リーチャビリティＩＤアクションテーブルには、リーチャビリティＩＤを制御するアクション（有効、無効等）やパラメータ（回数等）が、読みやすさの為に変数に対応付けて登録されていることが好ましい。なお、図１８には、アクションのみが登録されている場合を例示する。リーチャビリティＩＤアクションテーブルに登録されている値は、フローテンプレートテーブルの変数に代入されていてもよい。

図１９は、第６の実施形態におけるリーチャビリティＩＤ管理部２１０が保持管理しているリーチャビリティＩＤ有効性管理テーブルの登録例を示す説明図である。リーチャビリティＩＤ有効性管理テーブルは、本ＩＤ、リーチャビリティＩＤおよび有効フラグを少なくとも項目に持つ。リーチャビリティＩＤ有効性管理テーブルは、具体的には、リーチャビリティＩＤ管理サーバ２００のハードディスク装置やメモリ等の記憶装置に記憶される。

図２０は、サービスＩＤ管理部が保持管理しているサービス管理テーブルの登録例を示す説明図である。サービス管理テーブルは、サービスＩＤと、リーチャビリティＩＤ活用アプリケーションの連絡先とを項目に持つ。アクション実行部１１１１がリーチャビリティＩＤ活用アプリケーション１１１３に対してイベント通知を行う場合などに利用する。サービス管理テーブルは、具体的には、リーチャビリティ利用フロー管理サーバ１３００のハードディスク装置やメモリ等の記憶装置に記憶される。

次に、第６の実施形態の動作について説明する。リーチャビリティ利用フロー管理サーバ１３００には、レストラン用のビジネスフロー（図１７参照。）が設定されているものとする。図１７に例示するビジネスフローは、レストランの席予約サービスを実現するものである。例えば、アクションとして登録されているdoReachability（）関数は、リーチャビリティＩＤ管理部１１０３に、リーチャビリティＩＤ有効性管理テーブルを更新する処理を実行させるためのプログラムを示す。doReachability（）関数は、第１引数にリーチャビリティＩＤを持ち、第２引数にリーチャビリティＩＤアクションテーブル（図１８参照）の変数カラムの値を持つ。doReachability（）関数が実行されると、リーチャビリティＩＤ有効性管理テーブルにおいて、第１引数として指定されたリーチャビリティＩＤに対応付けられた有効フラグに対し、第２引数として指定された変数に対応するアクションが実行される。

また、notify（）関数は、第１引数にリーチャビリティＩＤを持ち、第２引数に通知先の連絡先を持ち、第３引数にメッセージ内容を持つ。notify（）関数が実行されると、第１引数に指定したリーチャビリティＩＤを含む第３引数のメッセージを、第２引数の連絡先に通知するアクションが実行される。以下の説明では、レストランの席予約のサービスＩＤは”restaurant1234”とする。

以下、加入者が席予約サービスを利用して、レストラン事業者に席の予約依頼を行う動作について説明する。図２１は、加入者がサービスの提供依頼を行う場合のリーチャビリティ管理システムの動作を示すフローチャートである。加入者１１０４は、例えば、サービス利用端末１０１０（この場合非接触ＩＣカードリーダーを備えている）を利用して、レストランの広告に添付された非接触ＩＣカードに書き込まれたサービスＩＤを読み取るなどして、席の予約サービスを依頼する操作を行う。次に、サービス利用端末１０１０のサービス利用依頼部１１０５は、例えば近距離無線等を利用して、リーチャビリティＩＤ適用部１１０７に対して、サービス顧客の本ＩＤ”tsuta@tsuta.com ”とサービス顧客の希望するサービスＩＤ”restaurant1234”と共に「サービス利用依頼」を送信する（ステップＳ１０１）。

リーチャビリティＩＤ適用部１１０７は、「サービス利用依頼」を受信すると、リーチャビリティＩＤ管理部２１０に対して、加入者１１０４の本ＩＤと共に「リーチャビリティＩＤ取得依頼」を送信する。リーチャビリティＩＤ管理部２１０は、受け取ったサービス顧客の本ＩＤに対応するリーチャビリティＩＤを生成して保存し、リーチャビリティＩＤ適用部１１０７にリーチャビリティＩＤを送信する（ステップＳ１０２）。ここでは、リーチャビリティＩＤは、”4d40a4adb5ada496d96610b0dd9f8042”とする。

リーチャビリティＩＤ適用部１１０７は、サービス提供フロントエンド１１０９に対して、加入者１１０４のリーチャビリティＩＤとサービスＩＤと共に「サービス利用依頼」を送信する。サービス提供フロントエンド１１０９は、「サービス利用依頼」を受信すると、サービスＩＤに対応するサービスのイベント評価部１１１０に「サービス利用依頼」を転送する（ステップＳ１０３）。

イベント評価部１１１０は、まず、「サービス利用依頼」から加入者１１０４のリーチャビリティＩＤを抽出し、現在状態管理テーブルにリーチャビリティＩＤ、初期状態の遷移先の行を追加する（図１６（ａ）参照。）。そして、イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図１６（ａ）参照。）とフローテンプレート保持部１１０２のレストランフローテンプレート（図１７参照。）とに基づいて、状態遷移先とアクションとを決定する（ステップＳ１０４）。ここでは、現在状態が「予約受付中」であり、コンディションが「サービス利用依頼」なので、遷移先として「予約完了」が選択され、アクションとして「doReachability（reachabilityId,A）」「notify（reachabilityId, to, reachabilityId +”から予約を承っております。”）；」が選択される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「予約完了」に更新する（図１６（ｂ）参照。）。イベント評価部１１１０は、アクション実行部１１１１に対し、ステップＳ１０４で決定したアクションを示す情報と、リーチャビリティＩＤと共にアクション実行依頼を出力する（ステップＳ１０５）。今回の場合、アクション実行依頼には、「doReachability（reachabilityId, A）」「notify（reachabilityId, to, reachabilityId+ ”から予約を承っております。”）；」とリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”とが含まれる。

アクション実行部１１１１は、「doReachability（reachabilityId,A）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”と共にリーチャビリティＩＤ有効性管理テーブル更新依頼を出力する。この場合、更新とは、リーチャビリティＩＤ管理部２１０が管理しているリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を有効にすることを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ１０６）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図１９（ａ）に示すようになる。

アクション実行部１１１１は、続いて「notify（reachabilityId, to, reachabilityId+”から予約を承っております。”）；」を実行する。アクション実行部１１１１は、サービスＩＤ管理部１１１２からサービスＩＤ”restaurant1234”に対応するリーチャビリティＩＤ活用アプリケーション１１１３の連絡先を抽出し、抽出した連絡先にリーチャビリティＩＤを含むイベントを通知する（ステップＳ１０７）。今回の場合、リーチャビリティＩＤは、”4d40a4adb5ada496d96610b0dd9f8042”、連絡先は”restaurant1234＠example.com”、メッセージは”4d40a4adb5ada496d96610b0dd9f8042から予約を承っております”、となる。リーチャビリティＩＤ活用アプリケーション１１１３は、受け取ったリーチャビリティＩＤを保存する。

次に、レストランにおいて、加入者の席の準備が整ったときに、レストラン事業者が加入者に連絡を取る場合の動作について説明する。図２２は、リーチャビリティ活用者が加入者に連絡を取る場合のリーチャビリティ管理システムの動作を示すフローチャートである。

レストランＡのリーチャビリティ活用者１１１４は、サービス運用端末１０１０のリーチャビリティＩＤ活用アプリケーション１１１３を利用して、リーチャビリティＩＤ適用部１１０７に対して、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を含む加入者１１０４への連絡依頼を送信する（ステップＳ２０１）。この場合、連絡依頼に含まれるリーチャビリティＩＤは、リーチャビリティ連絡の送信先のサービス顧客（加入者１１０４）を指定する為と、サービス顧客がレストランに来店する際にレストラン側で本人確認を行う為とに利用される。

リーチャビリティＩＤ適用部１１０７は、リーチャビリティＩＤ管理部２１０を利用して、リーチャビリティＩＤから本ＩＤへの変換を試みる（ステップＳ２０２）。今回の場合、”4d40a4adb5ada496d96610b0dd9f8042”は有効となっているので（図１９（ａ）参照。）、本ＩＤへの変換は有効となる。また、上記のリーチャビリティＩＤは、本ＩＤ”tsuta@tsuta.com ”に対応している（図１９（ａ）参照。）。リーチャビリティＩＤ適用部１１０７は、情報配信部１１０８に対して、本ＩＤ”tsuta@tsuta.com ”と共に加入者１１０４への連絡依頼を送信する。

情報配信部１１０８は、連絡受信端末１０３０の連絡受信部１１０６に対して連絡を行う（ステップＳ２０３）。加入者１１０４は、情報配信部１１０８を介して、レストランＡから本人確認用番号としてリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を含む予約完了の連絡を受け取る。連絡は、例えばｅ−ｍａｉｌによるものでもよい。

次に、席予約完了の連絡を受けた加入者１１０４が、レストランに来店した場合の処理について説明する。図２３は、イベントが発生した場合のリーチャビリティ管理システムの動作を示すフローチャートである。以下、加入者がレストランに来店したというイベントが発生した場合を例にして説明する。

レストランAのリーチャビリティ活用者１１１４は、来店した加入者が予約した加入者１１０４であることを確認するために、加入者１１０４が提示するリーチャビリティＩＤを確認する。確認方法として、加入者１１０４が提示するリーチャビリティＩＤ、
”4d40a4adb5ada496d96610b0dd9f8042”
が記載されたメールを、リーチャビリティ活用者１１１４が、リーチャビリティＩＤ活用アプリケーション１１１３に保存されているリーチャビリティＩＤと合致しているかどうか目で照合するなどの方法が考えられる。レストランＡのリーチャビリティ活用者１１１４は、リーチャビリティＩＤ活用アプリケーション１１１３を利用して、イベント評価部１１１０に対して「reachabilityIdが来店」イベントをリーチャビリティＩＤと共に送信する（ステップＳ３０１）。

イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図１６（ｂ）参照。）とフローテンプレート保持部１１０２のレストランフローテンプレート（図１７参照。）とに基づいて、状態遷移先とアクションとを決定する（ステップＳ３０２）。ここでは、現在状態が「予約完了」なので、「reachabilityIdが来店」イベントを受けた場合、遷移先として「来店完了」が選択され、アクションとして「doReachability（reachabilityId,B）」が選択される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「来店完了」に更新する（図１６（ｃ）参照。）。今回の場合、リーチャビリティＩＤアクションテーブルの変数Ｂに対し、アクション「無効」が登録されているため（図１８参照。）、doReachability（）が選択されるとリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を無効にするアクションが実行される。

イベント評価部１１１０は、アクション実行部１１１１に対し、アクション実行依頼を出力する（ステップＳ３０３）。今回の場合、アクション実行依頼には「doReachability（reachabilityId,B）」とリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”とが含まれる。アクション実行部１１１１は、「doReachability（reachabilityId,B）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リーチャビリティＩＤと共にリーチャビリティＩＤ有効性管理テーブル更新依頼を送信する。この場合、更新とは、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を無効にすることを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ３０４）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図１９（ｂ）に示すようになる。

この時点で、リーチャビリティＩＤ活用アプリケーション１１１３から加入者１１０４に対して、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を利用して連絡を取ろうとしても、リーチャビリティＩＤは無効となっているので、リーチャビリティＩＤ管理部２１０はリーチャビリティＩＤから本ＩＤへの変更を適用しない。つまり、リーチャビリティＩＤ活用アプリケーション１１１３から加入者への連絡は成功しない。

次に、加入者がレストランに忘れ物をし、レストラン側から加入者に忘れ物の連絡をする場合の動作について説明する。まず、図２３を参照して、加入者が忘れ物をしたというイベントが発生した場合を例にして説明する。レストランＡのリーチャビリティ活用者１１１４は、加入者１１０４の忘れ物を発見する。忘れ物が加入者１１０４のものであるかどうかは、例えば、忘れ物が置いてある席番号から割り出すものとする。リーチャビリティ活用者１１１４は、リーチャビリティＩＤ活用アプリケーション１１１３を利用して、イベント評価部１１１０に対して「リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”が忘れ物」イベントを送信する（ステップＳ３０１）。

イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図１６（ｃ）参照。）とフローテンプレート保持部１１０２のレストランフローテンプレート（図１７参照。）とに基づいて、状態遷移先とアクションとを決定する（ステップＳ３０２）。ここでは、現在状態が「来店完了」なので、「reachabilityIdが忘れ物」イベントを受けた場合、遷移先として「終了」が選択され、アクションとして「doReachability（reachabilityId,A）」が選択される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「終了」に更新する（図１６（ｄ）参照。）。今回の場合、リーチャビリティＩＤアクションテーブルの変数Ａに対し、アクション「有効」が登録されているため（図１８参照。）、doReachability（）が選択されるとリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を有効にするアクションが実行される。イベント評価部１１１０は、アクション実行部１１１１に対し、アクション実行依頼を出力する（ステップＳ３０３）。今回の場合、アクション実行依頼には「doReachability（reachabilityId,A）」とリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”とが含まれる。

アクション実行部１１１１は、「doReachability（reachabilityId,A）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リーチャビリティＩＤと共にリーチャビリティＩＤ有効性管理テーブル更新依頼を送信する。この場合、更新とは、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を有効にすることを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ３０４）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図１９（ａ）に示すようになる。

続いて、リーチャビリティ活用者が加入者に連絡を取る場合のリーチャビリティ管理システムの動作について説明する。以下、図２２を参照して、リーチャビリティ活用者が加入者に忘れ物があった旨の連絡をする場合を例にして説明する。

レストランAのリーチャビリティ活用者１１１４は、サービス運用端末１０１０のリーチャビリティＩＤ活用アプリケーション１１１３を利用して、リーチャビリティＩＤ適用部１１０７に対して、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を含む加入者１１０４への連絡依頼を送信する（ステップＳ２０１）。

リーチャビリティＩＤ適用部１１０７は、リーチャビリティＩＤ管理部２１０を利用して、リーチャビリティＩＤから本ＩＤへの変換を試みる（ステップＳ２０２）。今回の場合、”4d40a4adb5ada496d96610b0dd9f8042”は有効となっているので（図１９（ａ）参照。）、本ＩＤへの変換は有効となる。リーチャビリティＩＤ適用部１１０７は、情報配信部１１０８に対して、本ＩＤと共に加入者１１０４への連絡依頼を送信する。情報配信部１１０８は、連絡受信端末１０３０の連絡受信部１１０６に対して連絡を行う。すなわち、加入者１１０４は、情報配信部１１０８を介して、忘れ物の連絡を受け取る（ステップＳ２０３）。連絡は、例えばｅ−ｍａｉｌによるものでもよい。

一般的に優れたリーチャビリティとは、データの到達確率の高さや到達時間の速さなどを指標とする。第６の実施形態は、サービス顧客が必要とするときだけ、または迷惑と感じないときだけ、サービス提供者に対してサービス顧客へのリーチャビリティを有効にする制御や、サービス顧客の匿名性を保持したままリーチャビリティを提供することも、優れたリーチャビリティの指標としている。

第６の実施形態によれば、サービスのフローに応じたリーチャビリティＩＤの有効性評価を行うことにより、キャリアやサービス顧客の意図しない用途でのリーチャビリティＩＤ利用を防ぐことが出来る。さらに、リーチャビリティ利用フロー管理サーバ１３００は、投入されるビジネスフローを検証するため、キャリアやサービス顧客の意図しない用途でのリーチャビリティＩＤ利用がないことを保証することができる。これにより、リーチャビリティＩＤをリーチャビリティＩＤ活用者へ提供し、利用してもらうことができる。

また、第６の実施形態によれば、ビジネスフローテンプレートに従ってリーチャビリティが設定される。ビジネステンプレートを活用することにより、ユーザがリーチャビリティＩＤ活用アプリケーション１１１３毎にリーチャビリティを設定したり、条件を確認することができる。サービス提供側がユーザに迷惑メッセージ（スパム）を送信することを、ユーザに代わって、キャリアまたはＩＳＰが行うことができる。また、ビジネステンプレートが、「通知」を含むリーチャビリティＩＤ、有効、無効等のアクション駆動条件を広いバリエーションで管理することができる。

実施形態７
次に、本発明の第７の実施形態を説明する。本実施形態では、リーチャビリティをビジネスフローに応じて生成、削除することにより、複数のサービス提供者が協調してビジネスフローを運用する。以下の例では、サービス提供者を、ローン会社および第三者審査会社の２つとする。また、ローン会社のサービスＩＤを”loan1234”、第三者審査会社のサービスＩＤを”audit1234 ”とする。

図２４は、第７の実施形態のリーチャビリティ管理システムを例示するブロック図である。図２４は、図１５を拡張したものである。なお、第６の実施形態と同様の構成については、図１５と同一の符号を付し、説明を省略する。図２４において、「：」より前には、「：」より後の記載の具体例が示されている。例えば、リーチャビリティ活用者としてのローン会社は「ローン会社：リーチャビリティ活用者」という表記になっている。

第７の実施形態では、第６の実施形態の構成に加えて、サービス運用端末１０２１が設けられている。サービス運用端末１０２１は、「第三者審査会社：リーチャビリティＩＤ活用アプリケーション１２０２」を有する。「第三者審査会社：リーチャビリティ活用者１２０１」は、「第三者審査会社：リーチャビリティＩＤ活用アプリケーション１２０２」を利用している。リーチャビリティＩＤ活用アプリケーション１２０２は、審査依頼が来ると、リーチャビリティＩＤを利用して加入者に連絡をとり本人確認を行う。

「第三者審査会社：リーチャビリティＩＤ活用アプリケーション１２０２」は、リーチャビリティ利用フロー管理サーバ１３００からリーチャビリティＩＤに対応する加入者の審査依頼を受けたり、審査結果をリーチャビリティ利用フロー管理サーバ１３００に返したり、リーチャビリティ適用サーバ１００を介して加入者に連絡する機能を備える。

図２５は、第７の実施形態における現在状態管理テーブルの登録例を示す説明図である。現在状態管理テーブルは、リーチャビリティＩＤとフローの現在状態とを少なくとも項目に持つ。図２６は、第７の実施形態におけるフローテンプレートテーブルの登録例を示す説明図である。図２６には、ローン契約ビジネスフローテンプレートテーブルを例示する。リーチャビリティ利用フロー管理サーバ１３００には、ローン契約ビジネスフローが設定されているものとする。

図２７は、第７の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。図２７に示すリーチャビリティＩＤアクションテーブルには、第６の実施形態におけるリーチャビリティＩＤアクションテーブル（図１８参照。）のアクションに加えて、それぞれ変数Ｃ，Ｄに対応付けて、生成、削除のアクションが追加されている。

図２８は、第７の実施形態におけるリーチャビリティＩＤ有効性管理テーブルの登録例を示す説明図である。図２８（ａ），（ｂ）に示すリーチャビリティＩＤ有効性管理テーブルは、第６の実施形態におけるリーチャビリティＩＤ有効性管理テーブル（図１９（ａ），（ｂ）参照。）を拡張したものである。項目「リーチャビリティＩＤ２」には、項目「リーチャビリティＩＤ」と同じ本ＩＤに対応付けられたリーチャビリティＩＤが設定される。

次に、第７の実施形態のついて、図２１を参照して、加入者がローン会社に貸付依頼を行うまでの動作について説明する。加入者１１０４は、例えば、サービス利用端末１０１０（この場合非接触ＩＣカードリーダーを備えている）を利用して、ローン会社の広告添付の非接触ＩＣカードに書き込まれたサービスＩＤを読み取るなどして、ローンを依頼する操作を行う。次に、サービス利用端末１０１０のサービス利用依頼部１１０５は、リーチャビリティＩＤ適用部１１０７に対して、自身の本ＩＤとサービスＩＤ（loan1234）と共に「サービス利用依頼」を送信する（ステップＳ１０１）。

リーチャビリティＩＤ適用部１１０７は、「サービス利用依頼」を受信すると、リーチャビリティＩＤ管理部２１０に対して、加入者１１０４の本ＩＤと共に「リーチャビリティＩＤ取得依頼」を送信する。リーチャビリティＩＤ管理部２１０は、受け取ったサービス顧客の本ＩＤに対応するリーチャビリティＩＤを生成して保存し、リーチャビリティＩＤ適用部１１０７にリーチャビリティＩＤを送信する（ステップＳ１０２）。ここでは、リーチャビリティＩＤは”4d40a4adb5ada496d96610b0dd9f8042”とする。

リーチャビリティＩＤ適用部１１０７は、サービス提供フロントエンド１１０９に対して、加入者１１０４のリーチャビリティＩＤとサービスＩＤと共に「サービス利用依頼」を送信する。サービス提供フロントエンド１１０９は、「サービス利用依頼」を受信すると、サービスＩＤに対応するイベント評価部１１１０に「サービス利用依頼」を転送する（ステップＳ１０３）。

イベント評価部１１１０は、まず、「サービス利用依頼」から加入者１１０４のリーチャビリティＩＤを抽出し、現在状態管理テーブルにリーチャビリティＩＤ、初期状態の遷移先の行を追加する（図２５（ａ）参照。）。そして、イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図２５（ａ）参照。）とフローテンプレート保持部１１０２のローンフローテンプレート（図２６参照。）とに基づいて、状態遷移先とアクションを決定する（ステップＳ１０４）。ここでは、現在状態が「貸付依頼受付中」であり、コンディションが「貸付依頼」なので、遷移先として「貸付準備中」が選択され、アクションとして「doReachability（reachabilityId1, A）」「notify（reachabilityId1, to1, reachabilityId1+ ”からローン依頼を承っております。”）；」が選択される。

doReachability（）関数は、第１引数にリーチャビリティＩＤを持ち、第２引数にリーチャビリティＩＤアクションテーブルの変数カラムの値を持つ。今回の場合、第１引数には”4d40a4adb5ada496d96610b0dd9f8042”が代入され、第２引数にはＡが代入される。doReachability（）関数が選択されると、リーチャビリティＩＤ有効性管理テーブルにおいて、第１引数として指定されたリーチャビリティＩＤに対応付けられた有効フラグに対し、第２引数として指定された変数に対応するアクションが実行される。つまり、今回の場合、”4d40a4adb5ada496d96610b0dd9f8042”を有効にするというアクションが実行される。

また、notify（）関数は、第１引数にリーチャビリティＩＤを持ち、第２引数に通知先の連絡先を持ち、第３引数にメッセージ内容を持つ。今回の場合、第１引数には”4d40a4adb5ada496d96610b0dd9f8042”が代入され、第２引数には”sip:loan1234@aaa.com”が代入される。notify（）関数が選択されると、第１引数に指定したリーチャビリティＩＤを含む第３引数のメッセージを、第２引数の連絡先に通知するアクションが実行される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「貸付準備中」に更新する（図２５（ｂ）参照。）。イベント評価部１１１０は、アクション実行部１１１１に対し、アクション実行依頼を出力する（ステップＳ１０５）。今回の場合、アクション実行依頼には、「doReachability（reachabilityId1, A）」「notify（reachabilityId1, to1, reachabilityId1+ ”からローン依頼を承っております。”）；」とリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”と通知先”sip:loan1234@aaa.com”とが含まれる。

アクション実行部１１１１は、「doReachability（reachabilityId1, A）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”と共にリーチャビリティＩＤ有効性管理テーブル更新依頼を出す。この場合、更新とは、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を有効にすることを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ１０６）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図２８（ａ）に示すようになる。

アクション実行部１１１１は、続いて「notify（reachabilityId1, to1, reachabilityId1 + ”からローン依頼を承っております。”）；」を実行する。アクション実行部１１１１は、サービスＩＤ管理部１１１２からリーチャビリティＩＤ活用アプリケーション１１１３の連絡先を抽出し、抽出した連絡先にリーチャビリティＩＤを含むイベントを通知する（ステップＳ１０７）。今回の場合、リーチャビリティＩＤは”4d40a4adb5ada496d96610b0dd9f8042”、連絡先は”sip:loan1234@aaa.com”、メッセージは”4d40a4adb5ada496d96610b0dd9f8042からローン依頼を承っております”、となる。リーチャビリティＩＤ活用アプリケーション１１１３は受け取ったリーチャビリティＩＤを保存する。

次に、ローン会社において、加入者がローン返済可能か第三者審査会社に審査を委託する場合の動作について説明する。図２３を参照して、第三者審査会社への審査依頼を行うというイベントが発生した場合を例にして説明する。「ローン会社：リーチャビリティＩＤ活用アプリケーション１１１３」は、イベント評価部１１１０に対して「審査依頼」イベントをリーチャビリティＩＤ、
”4d40a4adb5ada496d96610b0dd9f8042”
と共に送信する（ステップＳ３０１）。

イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図２５（ｂ）参照。）とフローテンプレート保持部１１０２のローンフローテンプレート（図２６参照。）とに基づいて、状態遷移先とアクションを決定する（ステップＳ３０２）。ここでは、現在状態が「貸付準備中」なので、「審査依頼」イベントを受けた場合、遷移先として「審査中」が選択され、アクションとして「doReachability（reachabilityId1, C）」が選択される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「審査中」に更新する（図２５（ｃ）参照。）。今回の場合、リーチャビリティＩＤアクションテーブルの変数Ｃに対し、アクション「生成」が登録されている（図２７参照。）。よって、doReachability（）が選択されると、第２引数がＣなので新たな第三者審査会社にリリースする為のリーチャビリティＩＤを生成するアクションが実行される。イベント評価部１１１０は、アクション実行部１１１１に対し、アクション実行依頼を出力する（ステップＳ３０３）。今回の場合、アクション実行依頼には「doReachability（reachabilityId1, C）」とリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”とが含まれる。

アクション実行部１１１１は、「doReachability（reachabilityId1, C）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リーチャビリティＩＤと共にリーチャビリティＩＤ有効性管理テーブル更新依頼を送信する。この場合、更新とは、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”に対応する本ＩＤに対応付けられたリーチャビリティＩＤを新規に生成することを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ３０４）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図２８（ｂ）に示すようになる。

さらに、アクション実行部１１１１は、「notify（reachabilityId2, to2, reachabilityId2+”への貸付審査依頼です。”）」を実行する。今回の場合、reachabilityId2は、新規生成された”5d40a6adb6ada596d96610b1de9f9053”（図２８（ｂ）参照。）、to2は、「第三者審査会者：リーチャビリティＩＤ活用アプリケーション１２０２」への連絡先”audit1234@bbbb.com”（図２０参照。）となる。「第三者審査会社：リーチャビリティＩＤ活用アプリケーション１２０２」は、受け取ったリーチャビリティＩＤ”5d40a6adb6ada596d96610b1de9f9053”を保存する。

次に、第三者審査会社が新規に発行されたリーチャビリティＩＤを利用して加入者へ連絡をとり、本人確認を行う。以下、図２２を参照して、第三者審査会社が加入者の本人確認の連絡をする場合を例にして説明する。「第三者審査会者：リーチャビリティ活用者１２０１」は、「第三者審査会者：リーチャビリティＩＤ活用アプリケーション１２０２」を利用して、リーチャビリティＩＤ適用部１１０７に対して、リーチャビリティＩＤ”5d40a6adb6ada596d96610b1de9f9053”を含む加入者１１０４への連絡依頼を送信する（ステップＳ２０１）。

リーチャビリティＩＤ適用部１１０７は、リーチャビリティＩＤ管理部２１０を利用して、リーチャビリティＩＤの本ＩＤへの変換を試みる（ステップＳ２０２）。今回の場合、”5d40a6adb6ada596d96610b1de9f9053”は有効となっているので（図２８（ｂ）参照。）、本ＩＤへの変換は有効となる。また、上記のリーチャビリティＩＤは、本ＩＤ”tsuta@tsuta.com ”に対応している（図２８（ｂ）参照。）。リーチャビリティＩＤ適用部１１０７は、情報配信部１１０８に対して、本ＩＤと共に加入者１１０４への連絡依頼を送信する。

情報配信部１１０８は、連絡受信端末１０３０の連絡受信部１１０６に対して連絡を行う（ステップＳ２０３）。連絡は、例えば、情報配信部１１０８の電話取次ぎによる第三者審査会社と加入者の通話によるものでもよい。

次に、第三者審査会社が審査結果を報告する場合の動作について説明する。図２３を参照して、審査が通らなかったというイベントが発生した場合を例にして説明する。「第三者審査会者：リーチャビリティ活用者１２０１」は、「第三者審査会者：リーチャビリティＩＤ活用アプリケーション１２０２」を利用して、イベント評価部１１１０に対して「審査が通らなかった」イベントをリーチャビリティＩＤ”5d40a6adb6ada596d96610b1de9f9053”と共に送信する（ステップＳ３０１）。

イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図２５（ｃ）参照。）とフローテンプレート保持部１１０２のローンフローテンプレート（図２６参照。）とに基づいて、状態遷移先とアクションを決定する（ステップＳ３０２）。ここでは、現在状態が「審査中」なので、「審査が通らなかった」イベントを受けた場合、遷移先として「終了」が選択され、アクションとして「doReachability（reachabilityId2, D）」が選択される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「終了」に更新する（図２５（ｄ）参照。）。今回の場合、リーチャビリティＩＤアクションテーブルの変数Ｄに対し、アクション「削除」が登録されている（図２７参照。）。よって、doReachability（）が選択されると、リーチャビリティＩＤ”5d40a6adb6ada596d96610b1de9f9053”を削除するアクションが実行される。イベント評価部１１１０は、アクション実行部１１１１に対し、アクション実行依頼を出力する（ステップＳ３０３）。今回の場合、アクション実行依頼には「doReachability（reachabilityId2, D）」とリーチャビリティＩＤ”5d40a6adb6ada596d96610b1de9f9053”とが含まれる。

アクション実行部１１１１は、「doReachability（reachabilityId２, D）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リーチャビリティＩＤと共にリーチャビリティＩＤ有効性管理テーブル更新依頼を送信する。この場合、更新とは、リーチャビリティＩＤ”5d40a6adb6ada596d96610b1de9f9053”を削除することを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ３０４）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図２８（ａ）に示すようになる。

この時点で、「第三者審査会社：リーチャビリティＩＤ活用アプリケーション１２０２」から加入者１１０４に、リーチャビリティＩＤ”5d40a6adb6ada596d96610b1de9f9053”を利用して連絡を試みても、リーチャビリティＩＤは削除されているので、リーチャビリティＩＤ管理部２１０は本ＩＤの変換を行わず、連絡を取ることは出来ない。

以上に説明したように、上記の第７の実施形態によれば、リーチャビリティＩＤをビジネスフローに応じて生成、削除することから、複数のサービス提供者が強調してビジネスフローを運用することができる。

実施形態８
次に、本発明の第８の実施形態を説明する。本実施形態では、第６の実施形態に対し、リーチャビリティＩＤを有効にする際に有効期限として回数を設けてもよい。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤから本ＩＤへの変換をリーチャビリティＩＤ毎にカウントし、カウントが有効回数以下の場合に、リーチャビリティＩＤから本ＩＤへの変換を行う。

図２９は、第８の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。第８の実施形態では、リーチャビリティＩＤアクションテーブルには、変数に対応付けて、アクションおよび回数が設定されている。リーチャビリティＩＤアクションテーブルに設定される「回数」は、例えば、「有効」と設定されるアクションに対するパラメータである。例えば、リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルの有効フラグを「有効」に更新する際に、パラメータとして回数「３」を登録する。また、リーチャビリティＩＤ管理部２１０は、例えば、リーチャビリティ活用者１１４からの連絡依頼に基づいてリーチャビリティＩＤを本ＩＤに変換する際に、登録された回数「３」を参照し、変換を行うか否かを判断する。

図２９を例にする場合、リーチャビリティＩＤ管理部２１０によるリーチャビリティＩＤから本ＩＤへの変換は３回までとなり、４回目の変換は行われない。つまり、リーチャビリティＩＤ活用アプリケーション１１１３が、上記の期限付きのリーチャビリティＩＤを利用して、加入者への４回目の連絡を行おうとしても成功しない。

実施形態９
次に、本発明の第９の実施形態を図面を参照して説明する。第９の実施形態では、第６の実施形態に対し、リーチャビリティＩＤを有効にする際に有効期限として期間を設けてもよい。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤが有効となった時刻をリーチャビリティＩＤ毎に保持し、リーチャビリティＩＤから本ＩＤへの変換時刻との差分が、予め設定した期間を越えない場合に、リーチャビリティＩＤから本ＩＤへの変換を行う。

図３０は、第９の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。第９の実施形態では、リーチャビリティＩＤアクションテーブルには、変数に対応付けて、アクションおよび期間が設定されている。なお、図３０に示す例では、期間の単位は分とする。図３０に示す例では、リーチャビリティＩＤ管理部２１０によるリーチャビリティＩＤから本ＩＤへの変換は、リーチャビリティＩＤを有効にしてから６０分までとなり、６０分以降は変換が行われない。つまり、リーチャビリティＩＤ活用アプリケーション１１１３が、上記の期限付きのリーチャビリティＩＤを利用して、加入者への６０分以降の連絡を行おうとしても成功しない。

実施形態１０
次に、本発明の第１０の実施形態を図面を参照して説明する。第１０の実施形態では、第６の実施形態に対し、リーチャビリティＩＤを有効にする際に有効期限として時刻を設けてもよい。例えば、リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤから本ＩＤへの変換時刻が、予め設定した時刻を越えない場合に、リーチャビリティＩＤから本ＩＤへの変換を行う。

図３１は、第１０の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。第１０の実施形態では、リーチャビリティＩＤアクションテーブルには、変数に対応付けて、アクションおよび時刻が設定されている。なお、図３１に示す例では、時刻として日付が設定されている。図３１に示す例では、例えば、リーチャビリティＩＤ管理部２１０によるリーチャビリティＩＤから本ＩＤへの変換は、２０１０年１月１日２３時５９分までとなり、それ以降の変換は行われない。例えば、３０１１年１月１日０時１０分に、リーチャビリティＩＤ活用アプリケーション１１１３が、上記の期限付きのリーチャビリティＩＤを利用して、加入者への連絡を行おうとしても成功しない。

また、例えば、リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤから本ＩＤへの変換時刻が、予め設定した時刻を越えた場合に、リーチャビリティＩＤから本ＩＤへの変換を行う。図３１に示す例では、例えば、リーチャビリティＩＤ管理部２１０によるリーチャビリティＩＤから本ＩＤへの変換は、２０１０年１月１日２３時５９分からとなり、それ以前の変換は行われない。例えば、２００７年１月１日０時１０分に、リーチャビリティＩＤ活用アプリケーション１１１３が、上記の期限付きのリーチャビリティＩＤを利用して、加入者への連絡を行おうとしても成功しない。

実施形態１１
次に、本発明の第１１の実施形態を説明する。第１１の実施形態では、第６の実施形態に対し、リーチャビリティＩＤを有効にする際に有効期限として回数、期間、時刻を設けてもよい。図３２は、第１１の実施形態におけるリーチャビリティＩＤアクションテーブルの登録例を示す説明図である。第１１の実施形態では、リーチャビリティＩＤアクションテーブルには、変数に対応付けて、アクション、回数、期間および時刻が設定されている。

さらに、リーチャビリティＩＤ管理部１１０３がリーチャビリティＩＤから本ＩＤへの変換を行うか否かを決定するために、例えば、以下の演算『「回数が期限以内」Ｘ「期間が期限以内」Ｘ「時刻が期限以内」（ＸにはＡＮＤ、または、ＯＲが入る。）』を行ってもよい。演算結果が真の場合変換を行い、偽の場合変換を行わない。

実施形態１２
次に、本発明の第１２の実施形態を説明する。本実施形態では、サービス顧客が必要とするときだけ、または迷惑と感じないときだけ、サービス提供者に対してサービス顧客へのリーチャビリティを有効にするように制御したり、サービス顧客の匿名性を保持したままリーチャビリティを提供するかどうか保証したりするために、サービス提供者毎にビジネスフローを取得、検証する。

第１２の実施形態では、フローテンプレート検証ポリシに従ったフローテンプレートがリーチャビリティ利用フロー管理サーバ１３００に登録される。フローテンプレート検証ポリシとは、フローテンプレートが優れたリーチャビリティを提供するフローになっているか否かを検証するためのポリシである。例えば、フローテンプレート検証ポリシは、フローテンプレートに、無限に本ＩＤを抽出できるような内容が記載されていないことを検証する。

図３３は、第１２の実施形態のリーチャビリティ管理システムを例示するブロック図である。図３３は、図１５に対する拡張部分を示している。フローテンプレート検証部１１２１は、フローテンプレート送信部１１１６から受けたフローテンプレートと、これに対するフローテンプレート検証ポリシとに基づいて、フローテンプレート保持部１１０２にフローテンプレートを登録するかどうかを判定したり、フローテンプレート保持部１１０２に送信されたフローテンプレートを登録したりする。

検証ポリシ管理部１１２２は、フローテンプレート検証ポリシを保持、管理する機能を備える。フローチャート管理者１１１５は、フローテンプレート送信端末１０４０内のフローテンプレート送信部１１１６を利用している。フローテンプレート送信部１１１６は、フローテンプレートをフローテンプレート検証部１１２１に送信する。検証ポリシ作成者１１２５は、ポリシ設定端末１０５０内のポリシ送信部１１２３およびフローテンプレート閲覧部１１２４を利用している。

ポリシ送信部１１２３は、検証ポリシ管理部１１２２にフローテンプレート検証ポリシを送信する。フローテンプレート閲覧部１１２４は、例えば、フローテンプレート保持部１１０２が記憶するフローテンプレートを受信して、ポリシ設定端末１０５０に表示させる。

図３４は、第１２の実施形態におけるフローテンプレートテーブルの登録例を示す説明図である。図３４には、フローチャート管理者１１１５がリーチャビリティ利用フロー管理サーバ１３００に登録するフローテンプレートを示している。なお、図３４に示すフローテンプレートには、図３に示すフローテンプレートとは違い、リーチャビリティＩＤを制御するアクション（有効・無効）やパラメータ（回数、期間、時刻）が記述されている。

まず、検証ポリシ作成者１１２５は、ポリシ設定端末１０５０内のポリシ送信部１１２３を利用して、フローテンプレート検証ポリシを検証ポリシ管理部１１２２に送信する。今回の場合、フローテンプレート検証ポリシには、例えば、「ＩＦ doReachability（reachabilityId, 無効）が一つ以上含まれている ＴＨＥＮ 真」のようなリーチャビリティを制御するアクションが記載されているものとする。

次に、フローチャート管理者１１１５は、フローテンプレート送信端末１０４０のフローテンプレート送信部１１１６を利用して、フローテンプレートをフローテンプレート検証部１１２１に送信する。今回の場合、図３４に示すフローテンプレートを例にして説明する。フローテンプレート検証部１１２１は、検証ポリシ管理部１１２２からフローテンプレート検証ポリシを入力し、フローテンプレート送信部１１１６によって送信されたフローテンプレートを、入力したポリシに従い評価する。図３４に例示するフローテンプレートには、doReachability（reachabilityId, 無効）が１つ以上含まれているので、結果は「真」となる。よって、フローテンプレート検証部１１２１は、図３４に示すフローテンプレートをフローテンプレート保持部１１０２に登録する。

以上に説明したように、第１２の実施形態によれば、サービス提供者１１１４の利用するビジネスフローテンプレートが、サービス顧客１１０４が必要とするときだけ、または迷惑と感じないときだけ、サービス提供者１１１４に対してサービス顧客１１０４へのリーチャビリティを有効にするように制御したり、サービス顧客１１０４の匿名性を保持したままリーチャビリティを提供したりするかどうかを、フローテンプレート検証部１１２１がリーチャビリティＩＤの主体に代わって一括して検証することにより、リーチャビリティＩＤの主体が個別にサービス提供者のリーチャビリティ制御方法を検証する手間を省くことが出来る。

実施形態１３
次に、本発明の第１３の実施形態を説明する。第１３の実施形態では、第１２の実施形態に対し、フローテンプレートの検証ポリシにリーチャビリティを制御するアクションとパラメータとを記載してもよい。例えば、フローテンプレート検証ポリシとして、「ＩＦ （doReachability（reachabilityId, 無効）が１つ以上含まれている） ＡＮＤ （リーチャビリティＩＤ有効期限は１回かつ６００秒以内かつ２００７年６月２６日１５時までとする） ＴＨＥＮ 真」と設定してもよい。

この場合、図３４に示すフローテンプレートテーブルへの評価は偽となり、フローテンプレート検証部１１２１は、フローテンプレート保持部１１０２にフローテンプレートを登録しない。

実施形態１４
次に、本発明の第１４の実施形態を説明する。第６の実施形態では、リーチャビリティＩＤはサービス利用依頼毎に払いだされる。この場合、リーチャビリティＩＤ活用アプリケーション１１１３側では、受信するリーチャビリティＩＤ間の関連性がわからない。例えば、リーチャビリティＩＤ１とリーチャビリティＩＤ２とが同一の加入者であることがわからない。第１４の実施形態では、リーチャビリティＩＤをサービスＩＤ毎に再利用し、さらにサービス利用依頼毎に払い出すＩＤをリーチャビリティＩＤ以外に設けることにより、リーチャビリティＩＤ間の関連性を持たせる。

図１５に示す構成図を参照して、本発明の第１４の実施形態の動作について説明する。リーチャビリティＩＤ管理部２１０が、本ＩＤとサービスＩＤの組み合わせ毎にリーチャビリティＩＤを割り当てるとする。例えば、本ＩＤ”a@b.com ”、サービスＩＤ”restaurant1234”と共にサービス提供依頼が送信されると、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”が割り当てられる。再度同様の本ＩＤ、サービスＩＤと共にサービス提供依頼が送信されても、リーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”が割り当てられる。

図３５は、第１４の実施形態における現在状態管理テーブルの登録例を示す説明図である。第１４の実施形態において、現在状態管理テーブルには、リクエスト識別情報（リクエストＩＤ）とフローの現在状態とを含む情報が設定されている。図３６は、第１４の実施形態におけるフローテンプレートテーブルの登録例を示す説明図である。以下、リーチャビリティ利用フロー管理サーバ１３００には、図３６に示すレストラン用のビジネスフローが設定されているものとする。図３６に示すビジネスフローは、レストランの席予約サービスを実現するものである。

doReachability（）関数は、第１引数にリクエストＩＤを持ち、第２引数にリーチャビリティＩＤアクションテーブル（図１８参照。）の変数カラムの値を持つ。doReachability（）関数を実行すると、リーチャビリティＩＤ有効性管理テーブルにおいて、第１引数として指定されたリクエストＩＤに対応付けられた有効フラグに対し、第２引数として指定された変数に対応するアクションが実行される。

また、notify（）関数は、第１引数にリーチャビリティＩＤを持ち、第２引数にリクエストＩＤを持ち、第３引数に通知先の連絡先を持ち、第４引数にメッセージ内容を持つ。notify（）関数が実行されると、リーチャビリティＩＤとリクエストＩＤとを第３引数の連絡先に通知するアクションが実行される。以下の説明では、レストラン席予約のサービスＩＤは”restaurant1234”とする。

さらに、加入者は、サービスＩＤ”restaurant1234”に対してサービス利用依頼を行ったことがあるとする。また、リーチャビリティＩＤ管理部２１０の保持するリーチャビリティＩＤ有効性管理テーブルには、図３７（ａ）に例示するようなデータが保存されているとする。

図３７は、第１４の実施形態におけるリーチャビリティＩＤ有効性管理テーブルの登録例を示す説明図である。図３７に示すリーチャビリティＩＤ有効性管理テーブルには、本ＩＤ、サービスＩＤ、リーチャビリティＩＤ、リクエストＩＤおよび有効フラグを含む情報が設定されている。図３７に示すリーチャビリティＩＤ有効性管理テーブルの項目”リクエストＩＤ”の値は一意であり、サービス利用依頼毎に割り当てられる。すなわち、リーチャビリティＩＤ管理部２１０は、サービス利用依頼を受信すると、受信した本ＩＤおよびサービスＩＤに対応するリーチャビリティＩＤを登録するとともに、サービス利用依頼に応じたリクエストＩＤを登録する。

次に、図面を参照して第１４の実施形態の動作について説明する。以下、図２１を参照して、加入者が席予約サービスを利用してレストラン事業者に席の予約依頼を行う動作について説明する。加入者１１０４は、例えば、サービス利用端末１０１０（この場合非接触ＩＣカードリーダーを備えている）を利用して、レストランの広告に添付された非接触ＩＣカードに書き込まれたサービスＩＤを読み取るなどして、席の予約サービスを依頼する操作を行う。次に、サービス利用端末１０１０のサービス利用依頼部１１０５は、リーチャビリティＩＤ適用部１１０７に対して、自身の本ＩＤとサービスＩＤ”restaurant1234”と共に「サービス利用依頼」を送信する（ステップＳ１０１）。

リーチャビリティＩＤ適用部１１０７は、「サービス利用依頼」を受信すると、リーチャビリティＩＤ管理部２１０に対して、加入者１１０４の本ＩＤとサービスＩＤと共に「リーチャビリティＩＤ取得依頼」を送信する。リーチャビリティＩＤ管理部２１０は、受信したサービス顧客のリーチャビリティＩＤに対応するリクエストＩＤを生成して保存し（図３７（ｂ）参照。）、リーチャビリティＩＤ適用部１１０７にリーチャビリティＩＤ、リクエストＩＤを送信する（ステップＳ１０２）。ここでは、リーチャビリティＩＤは、”4d40a4adb5ada496d96610b0dd9f8042”とし、リクエストＩＤは”2”とする。

リーチャビリティＩＤ適用部１１０７は、サービス提供フロントエンド１１０９に対して、加入者１１０４のリーチャビリティＩＤとリクエストＩＤとサービスＩＤと共に「サービス利用依頼」を送信する。サービス提供フロントエンド１１０９は、「サービス利用依頼」を受信すると、サービスＩＤに対応するサービスのイベント評価部１１１０に「サービス利用依頼」を転送する（ステップＳ１０３）。

イベント評価部１１１０は、まず、「サービス利用依頼」から加入者１１０４のリーチャビリティＩＤとリクエストＩＤとを抽出し、現在状態管理テーブルにリクエストＩＤ、初期状態の遷移先の行を追加する（図３５（ａ）参照。）。そして、イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図３５（ａ）参照。）とフローテンプレート保持部１１０２のレストランフローテンプレート（図３６参照。）とに基づいて、状態遷移先とアクションとを決定する（ステップＳ１０４）。ここでは、現在状態が「予約受付中」であり、コンディションが「サービス利用依頼」なので、遷移先として「予約完了」が選択され、アクションとして「doReachability（reachabilityId, requestId, A）；notify（reachabilityId,requestId, to, reachabilityId+”から予約を承っております。”）；」が選択される。

イベント評価部１１１０は、リクエストＩＤ”２”の現在状態管理テーブルの現在状態を「予約完了」に更新する（図３５（ｂ）参照。）。イベント評価部１１１０は、アクション実行部１１１１に対し、ステップＳ１０４で決定した２つのアクションを示す情報と、リーチャビリティＩＤとリクエストＩＤと共にアクション実行依頼を出力する（ステップＳ１０５）。今回の場合、アクション実行依頼には、「doReachability（requestId, A）」「notify（reachabilityId, requestId, to, reachabilityId+ ”から予約を承っております。”)；」とリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”とリクエストＩＤ”２”が含まれる。

アクション実行部１１１１は、「doReachability（requestId, A）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リクエストＩＤ”２”と共にリーチャビリティＩＤ有効性管理テーブル更新依頼を出力する。この場合、更新とは、リーチャビリティＩＤ管理部２１０が管理しているリクエストＩＤ”2”に対応するリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を有効にすることを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ１０６）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図３７（ｃ）に示すようになる。

アクション実行部１１１１は、続いて「notify（reachabilityId, requestId, to, reachabilityId+”から予約を承っております。”）；」を実行する。アクション実行部１１１１は、サービスＩＤ管理部１１１２からサービスＩＤ”restaurant1234”に対応するリーチャビリティＩＤ活用アプリケーション１１１３の連絡先”restaurant1234＠example.com”を抽出し、抽出した連絡先にリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”とリクエストＩＤ”２”とを含むイベントを通知する（ステップＳ１０７）。リーチャビリティＩＤ活用アプリケーション１１１３は、受け取ったリーチャビリティＩＤとリクエストＩＤとを保存する。

次に、図２２を参照して、レストランにおいて、加入者の席の準備が整ったときに、レストラン事業者が加入者に連絡を取る場合の動作について説明する。レストランＡのリーチャビリティ活用者１１１４は、サービス運用端末１０１０のリーチャビリティＩＤ活用アプリケーション１１１３を利用して、リーチャビリティＩＤ適用部１１０７に対して、リクエストＩＤ”２”と共に加入者１１０４への連絡依頼を送信する（ステップＳ２０１）。

リーチャビリティＩＤ適用部１１０７は、リーチャビリティＩＤ管理部２１０を利用して、リクエストＩＤから本ＩＤへの変換を試みる（ステップＳ２０２）。今回の場合、リクエストＩＤ”２”は有効となっているので（図３７（ｃ）参照。）、本ＩＤへの変換は有効となる。また、上記のリクエストＩＤ”２”は、本ＩＤ”tsuta@tsuta.com ”に対応している（図３７（ｃ）参照。）。リーチャビリティＩＤ適用部１１０７は、情報配信部１１０８に対して、本ＩＤ”tsuta@tsuta.com ”と共に加入者１１０４への連絡依頼を送信する。

情報配信部１１０８は、連絡受信端末１０３０の連絡受信部１１０６に対して連絡を行う（ステップＳ２０３）。加入者１１０４は、情報配信部１１０８を介して、レストランＡから本人確認用番号としてリクエストＩＤ”２”入りの予約完了の連絡を受け取る。連絡は、例えばｅ−ｍａｉｌによるものでもよい。

次に、席予約完了の連絡を受けた加入者１１０４が、レストランに来店した場合の処理について説明する。以下、図２３を参照して、加入者がレストランに来店したというイベントが発生した場合を例にして説明する。

レストランAのリーチャビリティ活用者１１１４は、来店した加入者が予約した加入者１１０４であることを確認するために、加入者１１０４が提示するリクエストＩＤを確認する。確認方法として、加入者１１０４が提示するリクエストＩＤ”２”が記載されたメールを、リーチャビリティ活用者１１１４が、リーチャビリティＩＤ活用アプリケーション１１１３に保存されているリクエストＩＤと合致しているかどうか目で照合するなどの方法が考えられる。レストランＡのリーチャビリティ活用者１１１４は、リーチャビリティＩＤ活用アプリケーション１１１３を利用して、イベント評価部１１１０に対して「requestId が来店」イベントをリクエストＩＤと共に送信する（ステップＳ３０１）。

イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図３５（ｂ）参照。）とフローテンプレート保持部１１０２のレストランフローテンプレート（図３６参照。）とに基づいて、状態遷移先とアクションを決定する（ステップＳ３０２）。ここでは、現在状態が「予約完了」なので、「requestId が来店」イベントを受けた場合、遷移先として「来店完了」が選択され、アクションとして「doReachability（requestId, B）」が選択される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「来店完了」に更新する（図３５（ｃ）参照。）。今回の場合、リーチャビリティＩＤアクションテーブルの変数Ｂに対し、アクション「無効」が登録されているため（図１８参照。）、doReachability（）が選択されるとリクエストＩＤ”２”を無効に設定するアクションが実行される。イベント評価部１１１０は、アクション実行部１１１１に対し、アクション実行依頼を出力する（ステップＳ３０３）。今回の場合、アクション実行依頼には「doReachability（requestId, B）」とリクエストＩＤ”２”とが含まれる。

アクション実行部１１１１は、「doReachability（requestId, B）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リクエストＩＤと共にリーチャビリティＩＤ有効性管理テーブル更新設定依頼を送信する。この場合、更新設定とは、リクエストＩＤ”２”に対応するリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を無効にすることを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ３０４）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図３７（ｄ）に示すようになる。

この時点で、リーチャビリティＩＤ活用アプリケーション１１１３から加入者１１０４に対して、リクエストＩＤ”２”を利用して連絡を取ろうとしても、リクエストＩＤ”２”に対応するリーチャビリティＩＤは無効となっているので、リーチャビリティＩＤ管理部２１０はリーチャビリティＩＤから本ＩＤへの変更を適用しない。つまり、リーチャビリティＩＤ活用アプリケーション１１１３から加入者への連絡は成功しない。

次に、加入者がレストランに忘れ物をし、レストラン側から加入者に忘れ物の連絡をする場合の動作について説明する。まず、図２３を参照して、加入者が忘れ物をしたというイベントが発生した場合を例にして説明する。レストランＡのリーチャビリティ活用者１１１４は、加入者１１０４の忘れ物を発見する。忘れ物が加入者１１０４のものであるかどうかは、例えば、忘れ物が置いてある席番号から割り出すものとする。リーチャビリティ活用者１１１４は、リーチャビリティＩＤ活用アプリケーション１１１３を利用して、イベント評価部１１１０に対して「リクエストＩＤ”２”が忘れ物」イベントを送信する（ステップＳ３０１）。

イベント評価部１１１０は、フローデータ保持部１１０１の現在状態管理テーブル（図３５（ｃ）参照。）とフローテンプレート保持部１１０２のレストランフローテンプレート（図３６参照。）とに基づいて、状態遷移先とアクションとを決定する（ステップＳ３０２）。ここでは、現在状態が「来店完了」なので、「reachabilityIdが忘れ物」イベントを受けた場合、遷移先として「終了」が選択され、アクションとして「doReachability（reachabilityId,A）」が選択される。

イベント評価部１１１０は、現在状態管理テーブルの現在状態を「終了」に更新する（図３５（ｄ）参照。）。今回の場合、リーチャビリティＩＤアクションテーブルの変数Ａに対し、アクション「有効」が登録されているため（図１８参照。）、doReachability（）が選択されるとリクエストＩＤ”２”に対応するリーチャビリティＩＤ”4d40a4adb5ada496d96610b0dd9f8042”を有効にするアクションが実行される。イベント評価部１１１０は、アクション実行部１１１１に対し、アクション実行依頼を出力する（ステップＳ３０３）。今回の場合、アクション実行依頼には「doReachability（requestId, A）」とリクエストＩＤ”２”とが含まれる。

アクション実行部１１１１は、「doReachability（requestId, A）」を実行する。すなわち、アクション実行部１１１１は、リーチャビリティＩＤ管理部２１０に対し、リクエストＩＤと共にリーチャビリティＩＤ有効性管理テーブル更新依頼を送信する。この場合、更新とは、リクエストＩＤ”２”を有効にすることを指す。リーチャビリティＩＤ管理部２１０は、リーチャビリティＩＤ有効性管理テーブルを更新する（ステップＳ３０４）。今回の場合、更新された結果、リーチャビリティＩＤ有効性管理テーブルは、図３７（ｃ）に示すようになる。

続いて、図２２を参照して、リーチャビリティ活用者が加入者に連絡を取る場合のリーチャビリティ管理システムの動作について説明する。以下、リーチャビリティ活用者が加入者に忘れ物があった旨の連絡をする場合を例にして説明する。レストランAのリーチャビリティ活用者１１１４は、サービス運用端末１０１０のリーチャビリティＩＤ活用アプリケーション１１１３を利用して、リーチャビリティＩＤ適用部１１０７に対して、リクエストＩＤ”２”と共に加入者１１０４への連絡依頼を送信する（ステップＳ２０１）。

リーチャビリティＩＤ適用部１１０７は、リーチャビリティＩＤ管理部２１０を利用して、リーチャビリティＩＤから本ＩＤへの変換を試みる（ステップＳ２０２）。今回の場合、リクエストＩＤ”２”は有効となっているので（図３７（ｃ）参照。）本ＩＤへの変換は有効となる。リーチャビリティＩＤ適用部１１０７は、情報配信部１１０８に対して、本ＩＤと共に加入者１１０４への連絡依頼を送信する。

情報配信部１１０８は、連絡受信端末１０３０の連絡受信部１１０６に対して連絡を行う（ステップＳ２０３）。加入者１１０４は、情報配信部１１０８を介して、忘れ物の連絡を受け取る。連絡は、例えばｅ−ｍａｉｌによるものでもよい。

実施形態１５
次に、本発明の第１５の実施形態を説明する。イベント評価部１１１０に送信されるイベントは、リーチャビリティ利用フロー管理サーバ１３００内から送信されてもよい。さらに、イベント評価部１１１０に送信されるイベントは、キャリアの情報資産を含んでいてもよい。

実施形態１６
次に、本発明の第１６の実施形態を説明する。図３８は、第１６の実施形態のリーチャビリティ管理システムを例示するブロック図である。なお、第６の実施形態と同様の構成部については、図１５と同一の符号を付し、説明を省略する。本実施形態では、図３８に示すように、加入者１１０４がサービス利用依頼部１１０５を利用して、イベント評価部１１１０に対してイベントを送信してもよい。例えば、イベントには、リーチャビリティＩＤ無効（もしくは有効）依頼と加入者のリーチャビリティＩＤが含まれていてもよい。

第１６の実施形態によれば、リーチャビリティＩＤ活用アプリケーション１１１３から加入者１１０４への連絡が、加入者１１０４にとって必要ないものであった場合、加入者１１０４が自発的にリーチャビリティＩＤを無効化することが出来る。さらに、ビジネスフローにより無効にされてしまった加入者１１０４に対応するリーチャビリティＩＤを、加入者１１０４が自発的に有効化することにより、リーチャビリティＩＤ活用アプリケーション１１１３から加入者１１０４への連絡を行うことが出来る。

なお、上記の各実施形態において、連絡受信部１１０６とサービス利用依頼部１１０５とは、１つの端末に配置されてもよい。

以上、説明したように、本発明によれば、サービス提供者やリーチャビリティ利用者が本ＩＤを利用することができないため、本ＩＤを不正に利用されることがないという効果がある。また、リーチャビリティ利用者は、本ＩＤのかわりにリーチャビリティＩＤを利用して、リーチャビリティ提示者に連絡することができるという効果がある。

以上説明したように、本発明は、上記に示した例示的な実施形態において、例えば下記のように実現されている。リーチャビリティ実現サーバは、リーチャビリティＩＤ管理サーバ２００及びリーチャビリティ適用サーバ１００によって実現される。第２利用者端末は、リーチャビリティ端末１０によって実現される。実宛先情報受信部は、リーチャビリティＩＤ適用部１１０によって実現される。変換後宛先情報生成部は、リーチャビリティＩＤ管理部２１０によって実現される。リーチャビリティＩＤ管理部２１０は、変換後宛先情報生成部、リクエスト識別情報生成部、宛先情報更新部、及び、実宛先情報抽出部を含む。アクセス要求転送部は情報配信部１２０によって実現され、また、サービス提供サーバはサービス提供サーバ３００によって、サービス提供者記憶部はサービス提供者解決部１３０によって、リーチャビリティ実現サーバはリーチャビリティ適用サーバ１００およびリーチャビリティＩＤ管理サーバ２００によって実現される。リクエストＩＤ生成部はリーチャビリティＩＤ管理部２１０によって、宛先情報記憶部はリーチャビリティＩＤ保持部２２０及びリーチャビリティＩＤ有効条件保持部２５０によって、宛先情報更新部はリーチャビリティＩＤ管理部１１０３によって、更新処理情報記憶部はフローテンプレート保持部１１０２によって、更新処理情報抽出部はイベント評価部１１１０によって、実宛先情報受信部はリーチャビリティＩＤ適用部１１０によって、実宛先情報抽出部はリーチャビリティＩＤ管理部２１０によって、第１利用者端末はリーチャビリティ端末２０によって、それぞれ実現される。変換後宛先情報生成部はリーチャビリティＩＤ管理部２１０によって、変換後宛先情報送信部はリーチャビリティＩＤ適用部１１０によって、履歴記憶部はリーチャビリティＩＤ利用履歴管理部２３０によって、それぞれ実現される。

上記に示した実施形態において、下記態様のリーチャビリティ実現サーバが例示されている。
（１）相互に面識のない第１の利用者（例えば、リーチャビリティ利用者）から第２の利用者（例えば、サービス顧客）へのリーチャビリティを実現するリーチャビリティ実現サーバ（例えば、リーチャビリティ適用サーバ１００およびリーチャビリティＩＤ管理サーバ２００）であって、第２の利用者が使用する第２利用者端末（例えば、リーチャビリティ端末１０）から、第２の利用者に対して連絡可能な現実の宛先情報を受信する実宛先情報受信部（例えば、リーチャビリティＩＤ適用部１１０）と、実宛先情報受信部が受信した実宛先情報に基づいて、第１の利用者が実宛先情報を特定不能な変換後宛先情報を生成する変換後宛先情報生成部（例えば、リーチャビリティＩＤ管理部２１０）とを備えたリーチャビリティ実現サーバ。

（２）変換後宛先情報生成部が生成した変換後宛先情報を、実宛先情報に対応付けて記憶する宛先情報記憶部（例えば、リーチャビリティＩＤ保持部２２０）と、第１の利用者が使用する第１利用者端末（例えば、リーチャビリティ端末２０）から、変換後宛先情報を含むアクセス要求を受信すると、受信したアクセス要求に含まれる変換後宛先情報に対応する実宛先情報を宛先情報記憶部から抽出する実宛先情報抽出部（例えば、リーチャビリティＩＤ管理部２１０）と、実宛先情報抽出部が抽出した実宛先情報に基づいて、第１利用者端末からのアクセス要求を第２利用者端末に転送するアクセス要求転送部（例えば、情報配信部１２０）とを含むリーチャビリティ実現サーバ。そのような構成によれば、第１利用者端末が第２利用者端末に直接アクセスすることなく連絡を取ることができる。

（３）変換後宛先情報生成部が生成した変換後宛先情報を、第２の利用者からの依頼によりサービスを提供するサービス提供サーバ（例えば、サービス提供サーバ３００）に送信する変換後宛先情報送信部（例えば、リーチャビリティＩＤ適用部１１０）を含むリーチャビリティ実現サーバ。そのような構成によれば、サービス提供サーバに実宛先情報を送信しなくてよい。

（４）サービスを識別可能な情報に対応付けて、サービス提供サーバを識別可能な情報をあらかじめ記憶するサービス提供者記憶部（例えば、サービス提供者解決部１３０）を含み、実宛先情報受信部は、サービスを識別可能な情報を実宛先情報とともに受信し、変換後宛先情報送信部は、受信したサービスを識別可能な情報に基づいて、サービス提供者記憶部からサービス提供サーバを識別可能な情報を抽出し、抽出した情報が示すサービス提供サーバに変換後宛先情報を送信するリーチャビリティ実現サーバ。そのような構成によれば、サービス提供サーバが複数の場合にも適切に変換後宛先情報を送信することができる。

（５）宛先情報記憶部は、任意のタイミングで更新可能な変換後宛先情報を記憶するリーチャビリティ実現サーバ。そのような構成によれば、変換後宛先情報を任意のタイミングで更新することができる。

（６）宛先情報記憶部は、変換後宛先情報の有効期限を示す情報を変換後宛先情報に対応付けて記憶するリーチャビリティ実現サーバ。そのような構成によれば、変換後宛先情報の有効期限に基づいて変換後宛先情報を更新することができる。

（７）宛先情報記憶部（例えば、リーチャビリティＩＤ有効条件保持部２５０）は、変換後宛先情報を利用可能な条件を変換後宛先情報に対応付けて記憶し、実宛先情報抽出部は、アクセス要求を受信した場合に、条件に基づいて実宛先情報を抽出するリーチャビリティ実現サーバ。そのような構成によれば、リーチャビリティの適切な利用を図ることができる。

（８）変換後宛先情報の生成および実宛先情報の抽出の履歴を記憶する履歴記憶部（例えば、リーチャビリティＩＤ利用履歴管理部２３０）を含み、実宛先情報抽出部は、アクセス要求を受信した場合に、履歴記憶部が記憶する履歴および宛先情報記憶部が記憶する条件に基づいて実宛先情報を抽出するリーチャビリティ実現サーバ。そのような構成によれば、リーチャビリティのより適切な利用を図ることができる。

（９）宛先情報記憶部は、更新可能な条件を変換後宛先情報に対応付けて記憶するリーチャビリティ実現サーバ。そのような構成によれば、リーチャビリティのより適切な利用を図ることができる。

（１０）宛先情報記憶部は、変換後宛先情報を利用可能な条件として、変換後宛先情報を利用した回数の範囲を変換後宛先情報に対応付けて記憶するリーチャビリティ実現サーバ。そのような構成によれば、変換後宛先情報の利用制限数を条件として設定することができる。

（１１）ビジネスフローにおける所定の状態に対応付けて、宛先情報記憶部が記憶する情報を更新する処理を示す更新処理情報（例えば、フローテンプレートテーブルのアクションで実現される）を記憶する更新処理情報記憶部（例えば、フローテンプレート保持部１１０２によって実現される）と、第１利用者端末から、変換後宛先情報および現在の状態を示す情報を含むイベント情報を受信すると、受信したイベント情報に含まれる現在の状態を示す情報に基づいて更新処理情報記憶部から更新処理情報を抽出する更新処理情報抽出部（例えば、イベント評価部１１１０によって実現される）と、更新処理情報抽出部が抽出した更新処理情報および受信したイベント情報に含まれる変換後宛先情報に基づいて、宛先情報記憶部が記憶する情報を更新する宛先情報更新部（例えば、リーチャビリティＩＤ管理部１１０３によって実現される）とを備えたリーチャビリティ実現サーバ。そのように構成されたリーチャビリティ実現サーバは、ビジネスフローにおける状態に応じて宛先情報記憶部が記憶する情報を更新することができる。

（１２）宛先情報記憶部は、変換後宛先情報に対応する実宛先情報を抽出可能か否かを示す抽出可否フラグ（例えば、有効フラグで実現される）を、変換後宛先情報に対応付けて記憶し、更新処理情報記憶部は、宛先情報記憶部が記憶する抽出可否フラグを更新する処理を示す更新処理情報を記憶し、実宛先情報抽出部は、宛先情報記憶部が記憶する抽出可否フラグに基づいて変換後宛先情報に対応する実宛先情報を抽出するリーチャビリティ実現サーバ。そのように構成されたリーチャビリティ実現サーバは、ビジネスフローにおける状態に応じて変換後宛先情報に対応する実宛先情報を抽出可能にすることができる。

（１３）更新処理情報記憶部は、更新処理情報抽出部が受信したイベント情報に含まれる変換後宛先情報に対応する実宛先情報に対応付けて、宛先情報記憶部が記憶する変換後宛先情報を更新する処理を示す更新処理情報を記憶し、次いで、前記宛先情報記憶部が記憶する変換後宛先情報を生成または削除するリーチャビリティ実現サーバ。

（１４）更新処理情報記憶部は、変換後宛先情報に対応する実宛先情報を抽出可能な回数を示す情報を含む更新処理情報を記憶するリーチャビリティ実現サーバ。

（１５）更新処理情報記憶部は、変換後宛先情報に対応する実宛先情報を抽出可能な期間を示す情報を含む更新処理情報を記憶するリーチャビリティ実現サーバ。

（１６）更新処理情報記憶部は、変換後宛先情報に対応する実宛先情報を抽出可能な時刻を示す情報を含む更新処理情報を記憶するリーチャビリティ実現サーバ。

（１７）更新処理情報記憶部は、変換後宛先情報に対応する実宛先情報を抽出可能な回数、期間および時刻を示す情報の任意の組み合わせを含む更新処理情報を記憶するリーチャビリティ実現サーバ。

（１８）更新処理情報記憶部が記憶する更新処理情報が、リーチャビリティの制御を行う内容（例えば、フローテンプレート検証ポリシで実現される）か否かを検証する検証部（例えば、フローテンプレート検証部１１２１で実現される）を備えたリーチャビリティ実現サーバ。

（１９）検証部は、宛先情報記憶部が記憶する抽出可否フラグを更新する処理を示す更新処理情報が、所定の条件を満たしているか否かを検証するリーチャビリティ実現サーバ。

（２０）検証部は、変換後宛先情報に対応する実宛先情報を抽出可能な条件を含む所定の条件を、更新処理情報が満たしているか否かを検証するリーチャビリティ実現サーバ。

（２１）検証部は、変換後宛先情報に対応する実宛先情報を抽出可能な回数を示す情報を含む所定の条件を、更新処理情報が満たしているか否かを検証するリーチャビリティ実現サーバ。

（２２）検証部は、変換後宛先情報に対応する実宛先情報を抽出可能な期間を示す情報を含む所定の条件を、更新処理情報が満たしているか否かを検証するリーチャビリティ実現サーバ。

（２３）検証部は、変換後宛先情報に対応する実宛先情報を抽出可能な時刻を示す情報を含む所定の条件を、更新処理情報が満たしているか否かを検証するリーチャビリティ実現サーバ。

（２４）検証部は、変換後宛先情報に対応する実宛先情報を抽出可能な回数、期間および時刻を示す情報の任意の組み合わせを含む所定の条件を、更新処理情報が満たしているか否かを検証するリーチャビリティ実現サーバ。

（２５）検証部は、変換後宛先情報に対応する実宛先情報を抽出可能な回数、期間または時刻を示す情報を含む条件のうち、すべてまたはいずれかを満たす旨の所定の条件を、更新処理情報が満たしているか否かを検証するリーチャビリティ実現サーバ。

（２６）実宛先情報受信部が実宛先情報を受信する毎に、リクエストＩＤを生成するリクエストＩＤ生成部（例えば、リーチャビリティＩＤ管理部２１０によって実現される）を備え、宛先情報記憶部は、リクエストＩＤ生成部が生成したリクエストＩＤを、変換後宛先情報に対応付けて記憶し、更新処理情報抽出部は、第１利用者端末から、リクエストＩＤおよび現在の状態を示す情報を含むイベント情報を受信すると、受信したイベント情報に含まれる現在の状態を示す情報に基づいて更新処理情報記憶部から更新処理情報を抽出し、宛先情報更新部は、更新処理情報抽出部が抽出した更新処理情報および受信したイベント情報に含まれるリクエストＩＤに基づいて、宛先情報記憶部が記憶する情報を更新するリーチャビリティ実現サーバ。

（２７）更新処理情報抽出部は、第２利用者端末から変換後宛先情報および更新処理情報を受信し、宛先情報更新部は、更新処理情報抽出部が受信した変換後宛先情報および更新処理情報に基づいて、宛先情報記憶部が記憶する情報を更新するリーチャビリティ実現サーバ。

本出願は、２００７年３月７日及び９月１４日出願に係る日本特許出願２００７−０５７５９７号及び２００７‐２３９３２１を基礎とし且つその優先権を主張するものであり、引用によってその開示の内容の全てを本出願の明細書中に加入する。

本発明は、サービス顧客の連絡先の不正利用を防止するために適用することができ、特に、サービス顧客の連絡先を扱うサービスの普及を支援するために効果的に適用できる。また、本発明は、サービス提供者が通信事業者（キャリア）によって管理されるサービス顧客の情報資産を活用してサービス提供を行う場合に適用できる。また、本発明は、通信事業者（キャリア）によって管理されるサービス顧客に対して短期間のサービスを提供する場合に適用できる。

Claims (2)

1. サービスを提供する第１の利用者が保有するサービス提供サーバから第２の利用者が使用する利用者端末へのリーチャビリティを実現するリーチャビリティ実現システムであって、
   前記第２の利用者に対して連絡可能な現実の宛先を表す実宛先情報と、前記第１の利用者が前記実宛先情報を特定不能なように変換された実宛先情報である変換後宛先情報と、前記変換後宛先情報が有効であるか無効であるかを表す効力フラグと、を、対応付けて宛先情報記憶部に保存する宛先情報保存部と、
   前記サービスを提供する業務において、ビジネスフローに沿って実行される処理の実行状態を表す状態情報と、当該状態情報に応じて、前記第２の利用者が利用する利用者端末にアクセスを求めるアクセス要求を送信する送信処理と、前記効力フラグを、当該状態情報に応じて、前記変換後宛先情報が有効であることを表す有効フラグ若しくは前記変換後宛先情報が無効であることを表す無効フラグのいずれかに更新する更新処理と、当該送信処理及び当該更新処理が実行される実行条件を表す条件情報と、を対応付けて記憶する処理情報記憶部と、
   前記第２の利用者の変換後宛先情報を含み、前記サービスの提供において前記第２の利用者に生じたイベントを示すイベント情報を受信する受信部と、
   前記受信されたイベント情報で表されるイベントの発生により成立した実行条件を表す条件情報と、前記処理の現在の実行状態を示す状態情報と、に対応付けて前記処理情報記憶部に記憶された更新処理及び送信処理を抽出する処理情報抽出部と、
   前記抽出された更新処理を実行することで、前記受信された変換後宛先情報に対応付けられた効力フラグを更新する更新部と、
   前記効力フラグが更新された後に、前記効力フラグが有効フラグであると、前記抽出された送信処理に従って、前記受信された変換後宛先情報と当該有効フラグとに対応付けられた実宛先情報に基づき、前記アクセス要求を前記第２の利用者が利用する利用者端末に送信する送信部と、を備える、
   ことを特徴とするリーチャビリティ実現システム。
2. サービスを提供する第１の利用者が保有するサービス提供サーバから第２の利用者が使用する利用者端末へのリーチャビリティをリーチャビリティ実現システムが実現するリーチャビリティ実現方法であって、
   前記リーチャビリティ実現システムが、前記第２の利用者に対して連絡可能な現実の宛先を表す実宛先情報と、前記第１の利用者が前記実宛先情報を特定不能なように変換された実宛先情報である変換後宛先情報と、前記変換後宛先情報が有効であるか無効であるかを表す効力フラグと、を、対応付けて宛先情報記憶部に保存する宛先情報保存ステップと、
   前記リーチャビリティ実現システムが、前記第２の利用者の変換後宛先情報を含み、前記サービスの提供において前記第２の利用者に生じたイベントを示すイベント情報を受信する受信ステップと、
   前記リーチャビリティ実現システムが、前記サービスを提供する業務において、ビジネスフローに沿って実行される処理の実行状態を表す状態情報と、当該状態情報に応じて、前記第２の利用者が利用する利用者端末にアクセスを求めるアクセス要求を送信する送信処理と、前記効力フラグを、当該状態情報に応じて、前記変換後宛先情報が有効であることを表す有効フラグ若しくは前記変換後宛先情報が無効であることを表す無効フラグのいずれかに更新する更新処理と、当該送信処理及び当該更新処理が実行される実行条件を表す条件情報と、を対応付けて記憶する処理情報記憶部から、前記受信されたイベント情報で表されるイベントの発生により成立した実行条件を表す条件情報と、前記処理の現在の実行状態を示す状態情報と、に対応付けて前記処理情報記憶部に記憶された更新処理及び送信処理を抽出する処理情報抽出ステップと、
   前記リーチャビリティ実現システムが、前記抽出された更新処理を実行することで、前記受信された変換後宛先情報に対応付けられた効力フラグを更新する更新ステップと、
   前記リーチャビリティ実現システムが、前記効力フラグが更新された後に、前記効力フラグが有効フラグであると、前記抽出された送信処理に従って、前記受信された変換後宛先情報と当該有効フラグとに対応付けられた実宛先情報に基づき、前記アクセス要求を前記第２の利用者が利用する利用者端末に送信する送信ステップと、を有する、
   ことを特徴とするリーチャビリティ実現方法。

Images