JP2016001370A - 到達型連絡サービスサーバ - Google Patents

Abstract

【課題】コミュニケーションサービスが多様化した現在の状況において、トラッキングシステムのような電池消耗の激しいサービスを実行しておかなくても、ユーザに連絡を速やかに取ることができるようにする。【解決手段】端末１０からの連絡要求信号を受け付ける連絡要求受信部１０１と、複数の上記外部サービスサイト１２におけるＩＤを登録するユーザ管理ＤＢ１１１と、個々のユーザの活動記録を収集する状態収集部１０２と、収集した活動記録の情報に基づき、個々のユーザへの連絡の到達可能性が所定の条件を満たす外部サービスサイト１２を選択するＣＰ選択部１０３と、選択された外部サービスサイト１２を連絡経路として設定するＣＰ設定部１０４と、当該ユーザへの連絡経路として設定された上記外部サービスサイトを介した、当該ユーザの登録したＩＤ宛のメッセージを作成するメッセージ作成部１０６とを有する到達型連絡サービスサーバによる。【選択図】図２

Description

この発明は、個人間で必要時に連絡をつけるメッセージを送信するためのサービスに関し、そのサービスを提供するためのサーバに関する。

社会全体での高齢化の進行に伴い不測の事態が発覚したときに急ぎ連絡を取らねばならないケースや、小学生など年少者の安否を確認したりするために連絡を取らねばならないケースなどに対応可能な環境作りが求められている。常時携帯可能な様々なデバイスが、このような連絡のための手段として開発されている。

さらに、ビジネス現場でもサーバエラーの際にサービス管理者を呼び出したり、自治体などで災害時に責任者を呼び出したりするなど、連絡を採らねばならないケースが増えている。

例えば特許文献１には予め登録された複数の携帯電話についてキャリアメールアドレスに同報でＨＴＭＬメールを送信し、当該ＨＴＭＬメールから速やかにコード化された回答を送る方法が記載されている。

一つの接続ラインから、優先的に接続される宛先へ連絡を取る方式としては、例えば従来の電話システムにおける１１０番や１１９番の緊急通報システムがある。このシステムでは、これら特定番号を緊急通報番号として予め公衆網側のサーバに登録させ、通報者がその番号に発呼すると、緊急通報であるとみなして、その発信地域の緊急連絡先として登録された警察や消防の受付台に呼をルーティングして、担当オペレータに電話対応をさせるシステムとなっている。これにより、一つの番号から、最適な地域の番号へと繋げて緊急要請を行うことができている。ただしこれは宛先が固定される警察や消防などに利用が限られてしまう。

一方で近年、通信端末の小型化と、ワイヤレスネットワークの普及に伴い、常に持ち運びが可能なウェアラブル端末やスマートフォンが普及している。また、通信技術の向上により、そこでやりとりできる通信量も増加している。固定回線においては、常時接続が定着し、自宅や職場ではパソコンを通じて常時インターネットに高速回線で接続する環境が整っている。

これらの複合的な要因により、従来の携帯電話キャリアメールや携帯電話での直接通話を中心とした利用形態から、ユーザが利用できるコミュニケーション手段が多様化している。例えば、ソーシャルネットワークサービス（Social Network Service：SNS）や、ショートメッセージサービス、短文投稿サービス、ブログ、ＩＰ電話、ネットワークゲームなどが挙げられ、場合によってはこれらの複数を並行して使い分けて利用されている。これを利用するための端末は、パソコンやスマートフォン、フィーチャーフォンがそれぞれ単独で利用するだけでなく、一のサービスをパソコンとスマートフォンとの両方で利用するといったことも一般的に行われている。

この他に個人の安否を確認する方法としては、スマートフォンに搭載されているＧＰＳ機能を常時起動して、友人同士や、子供と親の端末の位置関係を地図上に表示し続けるトラッキングシステムが提案されている（例えば非特許文献１、２）。

特開２００５−７８２９３号公報

www.life360.com maps.google.com/latitude （サービス終了済）

しかしながら、現在ではスパムメールの増加に対応するためにフィルタリング機能が強化されたので、一斉送信メールが届かないケースが増えている。また、携帯のキャリアメールを優先的なコミュニケーション手段としては位置づけずに、ショートメッセージサービスなどを優先して用いるユーザが増えてきているため、特許文献１の技術のようにメールでの送信だけでは限界が生じてきている。

また、スマートフォンでは公衆電話網を用いた携帯電話への呼び出しを使うのではなく、ＳＮＳに付随するＩＰ電話サービスや、その他のＩＰ電話サービスなども利用されている。このため、ある人物に対して速やかに連絡を取りたい場合に、従来のように携帯電話への発信が特に優れている状況ではなく、確実性が高い緊急連絡手段ではなくなっている。既に現在は、ユーザごとに最適な連絡の取り方が多様化しており、同じユーザでも時間帯によって最適な連絡の取り方は異なっている。

さらに、ＧＰＳを使ったトラッキングシステムは、端末の状態を常に監視し続けなければならず、スマートフォンの電池消費量を増大させてしまうという問題があった。また、トラッキングの機能はアプリケーションに依存するため、そのアプリケーションが何らかの理由により動作していない場合、連絡を受け取るべき受信者に連絡をすることができない。

そこでこの発明は、コミュニケーションサービスが多様化した現在の状況において、トラッキングシステムのような電池消耗の激しいサービスを実行しておかなくても、ユーザに連絡を速やかに取ることができるようにすることを目的とする。

この発明は、
端末からのユーザを指定した連絡要求信号を受け付ける連絡要求受信部と、
複数の外部サービスサイトにおける上記ユーザのＩＤが登録されたユーザ管理データベースと、
各々の上記外部サービスサイトにおける個々のユーザの活動記録を収集する状態収集部と、
上記状態収集部によって収集した上記活動記録の情報であるユーザアクティビティ情報に基づき、個々のユーザへの連絡の到達可能性が所定の条件を満たす上記外部サービスサイトを選択するＣＰ選択部と、
上記ＣＰ選択部で選択された上記外部サービスサイトを、当該ユーザへの連絡経路として設定するＣＰ設定部と、
上記の指定されたユーザについて、当該ユーザへの連絡経路として設定された上記外部サービスサイトを介した、当該ユーザの登録した上記ＩＤ宛のメッセージを作成するメッセージ作成部と、
を有する到達型連絡サービスサーバにより上記の課題を解決したのである。

ここで外部サービスサイトとは、ＳＮＳサービスやショートメッセージサービス、オンラインゲームサービスなどを提供しているサイトである。基本的にはＡＰＩ（Application Programming Interface）などによりオープンになった情報を取得可能であるサービスサイトを対象とする。ユーザがそれぞれの外部サービスサイトで使用しているＩＤを登録しておき、それぞれのＩＤについて時間記録を含む活動記録を収集することで、それぞれの外部サービスサイトについて当該ユーザがどのような頻度でアクセスし、活動しているかが把握できる。この頻度が高いということはすなわち、その外部サービスサイトを使えば当該ユーザに連絡が取りやすいということである。このように当該ユーザへの連絡の到達可能性が高い外部サービスサイトを連絡経路として設定し、当該ユーザ宛のメッセージを、外部サービスサイトを利用して送信する。このメッセージも、外部サービスサイトにおいて提供されているＡＰＩを利用したりして、搭載されているメッセージ機能、チャット機能、投稿機能などを通じて行う。このために、上記状態収集部は外部サービスサイトのクライアントとして振る舞う機能を有する。

上記到達可能性についての評価方法は特に限定されず、外部サービスサイトの性質によって適宜設定するとよい。例えばＩＰ電話サービスでは通話記録を外部から参照することが困難であることが多く、当該サービスについての評価値は固定値としておいてもよい。一方で頻繁にメッセージのやり取りや投稿が行われたりする外部サービスサイトでは、直近の書き込みなどの頻度から到達可能性の高さを数値化可能である。当該外部サービスサイトがログイン型のサービスであるなら、ログイン状態ならば１でログアウト状態ならば０とする真偽値Ｌを設定し、当該サービスサイトにおける過去の投稿について、現在時刻と投稿時刻との差の逆数を、直近の所定の時間中に亘って加算した和であるアクティビティ情報Ａとの積であるコスト値Ｃ１＝Ｌ×Ａの値や、これにさらに個々のユーザが設定する当該外部サービスサイトについての利用の可否を示す真偽値Ｐを掛けた積であるコスト値Ｃ２＝Ｌ×Ａ×Ｐの値により評価が可能である。

和であるアクティビティ情報Ａとは、例えば１分前、５分前、１０分前に投稿があった場合は１／１＋１／５＋１／１０＝８／１０として求められ、３分前、１５分前、３０分前に投稿があった場合は１／３＋１／１５＋１／３０＝１３／３０となり、比べると前者の方が高い評価値となる。

なお、必須ではないものの、ＧＰＳを使った位置記録機能についても、このサービスサーバが取り込むことは特に問題なく可能である。ただし、ＧＰＳによる位置情報の送信だけでなく、メッセージの受信ができるアプリケーションと連携していることが必要となる。

こうして連絡経路として条件を満たす外部サービスサイトのＩＤが複数ある場合、上記メッセージ作成部は同報でメッセージを作成し、外部サービスサイトに対して作用するクライアント模擬部がこれを同報で送信可能であると、より連絡を取れる可能性を上げることが出来る。なお、複数あるとは、複数の外部サービスサイトである場合もあるし、一つの外部サービスサイトに複数のアカウントを持っている場合も含む。

それぞれのユーザが個々の上記外部サービスサイトにおける上記ユーザのＩＤが登録されるユーザ管理データベースへの登録を行った上で、上記連絡要求受信部が受け付けるユーザの指定は、上記外部サービスサイトのＩＤを含まない、上記到達型連絡サービスサーバ用の総合ＩＤにより可能であるようにすると、各ユーザが実際の活動を行っている個々の外部サービスサイトのアカウント自体を他人に伝えることなく、連絡を受けつけることができる。

連絡を求めるメッセージは単に送信するだけでなく、確認を受け付けるようにすることもできる。到達型連絡サービスサーバが、上記連絡要求信号ごとに、その要求が到達したか否かを管理する要求記録テーブルと、上記メッセージを受け取った上記ユーザが、上記要求記録テーブルへ記録可能なＨＴＭＬページを生成するＷＥＢサーバとを有するものとし、上記メッセージに、上記ＷＥＢサーバにより生成されるＨＴＭＬページへ到達可能なアドレスを含めると、アドレスをクリック、あるいはボタンなどで指定したり、総合ＩＤ及びパスワードを入力したりすることで、連絡を受け取った旨の確認が可能となる。

この発明により、コミュニケーション手段が多様化した現在の状況にあっても、その時点における最適な連絡経路を選択して連絡を取ることができる。

この発明にかかる到達型連絡サービスサーバを実施する際の周辺を含む概念図 この発明にかかる到達型連絡サービスサーバを含む機能ブロック図 ユーザ管理データベースの例を示すテーブル この発明にかかる到達型連絡サービスサーバのサービスを受ける前段階の手順形態を示すフロー例図 連絡要求信号を受け取ったときの到達型連絡サービスサーバの動作形態を示すフロー例図 到達型連絡サービスサーバが用いる専用アカウント管理部の例を示すテーブル （ａ）〜（ｄ）アクティビティ情報テーブルの変遷を示すテーブル 子供ユーザが親ユーザへ到達型連絡要求信号を送信する際の手順例を示すシーケンス図 （ａ）〜（ｃ）図８における要求記録テーブルの変遷を示すテーブル （ａ）〜（ｅ）図８におけるアクティビティ情報テーブルの変遷を示すテーブル 図８の続きを示すシーケンス図 友達機能を使って連絡を取る際の処理フロー例図 フレンドデータベースの例を示すテーブル

以下、この発明の実施形態について詳細に説明する。
この発明にかかる到達型連絡サービスサーバ１１は、ユーザが別のユーザに連絡を取るための仲介サービスを行うサーバである。この発明を実施する際の概念図を図１に、機能ブロックの概要を図２に示す。送信側のユーザが有する端末１０から、この発明にかかる到達型連絡サービスサーバ１１へ、他のユーザを指定した連絡要求信号が送信される。到達型連絡サービスサーバ１１は、複数の外部サービスサイト１２における、各々のユーザの活動記録をリアルタイムに、又は要求に応じて収集する。また、到達型連絡サービスサーバ１１は、この活動記録の情報であるユーザアクティビティ情報に基づき、宛先として指定される受信側のユーザのへの信号の到達可能性を評価する。この中で到達可能性の高い外部サービスサイト１２を選び、そのユーザのアカウント（ＩＤ）宛にメッセージを送信する。宛先となるユーザは、受信側となる端末１３がＰＣやタブレット、スマートフォンなどの区別なく、最適の手段で連絡を取得することができる。

送信元のユーザが用いる端末１０と、宛先、すなわち受信側のユーザが用いる端末１３は、例えば、フィーチャーフォン、スマートフォン、パソコン、タブレットなど、インターネット接続機能さえあれば特に限定されるものではない。端末１０から到達型連絡サービスサーバ１１への連絡要求信号を送信する連絡要求送信部１００は、特に限定されず、ＷＥＢブラウザや専用アプリを用いたＨＴＴＰ通信でもよいし、指定されたアドレスへのメール送信でもよいし、その他、外部サービスサイト１２を介しての送信でもよい。ただし、後述する到達型連絡サービスサーバ１１の連絡要求受信部１０１はそれに対応するソフトウェアインターフェースを有していることが必要となる。

一方、受信側のユーザが用いる端末１３は、ユーザが外部サービスサイト１２のサービスを享受できる環境であれば、本発明にかかる到達型連絡サービスサーバ１１を利用できる。

外部サービスサイト１２は、主にインターネットを介してアクセス可能なコミュニケーションサービスを提供しているサーバ、又はサーバ群である。例えばＳＮＳサービス、ミニブログサービス、ショートメッセージサービス、ソーシャルゲームサービス、ネットワークゲームサービス、チャットサービス、ＩＰ電話サービス、携帯電話サービス、固定電話サービスなど、ユーザが個々にアカウント（ＩＤ）を有し、そのＩＤ間でテキストや音声、映像などによりメッセージの送信ができるものである必要がある。また、到達型連絡サービスサーバ１１がインターネットを介してメッセージを送信出来るように、ＡＰＩが公開されているものであることが望ましい。ＡＰＩが公開されていない場合、到達型連絡サービスサーバ１１はユーザアカウントを有して１ユーザとして動作することが求められる。

なお、外部サービスサイト１２には、携帯電話網、固定電話網を提供する業者が含まれていてもよい。この場合、携帯電話や固定電話に対して発呼し、自動音声や機械合成音声によりメッセージを伝える機能を有している必要がある。電話番号をＩＤとして管理しておき、当該電話番号宛に発呼し、合成音声によるメッセージを伝達可能であると、インターネットに通じていない環境であってもこの発明が利用できる。このような音声メッセージによる連絡経路と、その他のインターネットを経由したテキストメッセージを主とする連絡経路とを併用してもよい。

また、外部サービスサイト１２は、個々のＩＤを有するユーザがログインしているか否かを管理する状態管理部２０２や、フレンド情報などの個々のＩＤ間の関係を管理するアカウントリンク情報管理部２０３などを有しており、それらの管理情報を、ＡＰＩなどを通じて到達型連絡サービスサーバ１１が取得できるようにしてあると好ましい。さらに、直接にメッセージを送ることができるメッセージ送受信部２０４を有し、ＡＰＩサーバ２０１を通じてのコマンドによりメッセージ送信できることが望ましい。

これらの端末及び外部サービスサイト１２に対して、到達型連絡サービスサーバ１１は次のような機能を実行するサーバ又はサーバ群である。

到達型連絡サービスサーバ１１は、端末１０から送信された連絡要求信号を受信する連絡要求受信部１０１を有する。これは、連絡要求信号に含まれる、宛先となるユーザのＩＤを含む。なおこのＩＤは外部サービスサイト１２におけるアカウント（ＩＤ）ではなく、到達型連絡サービスサーバ１１が個々のユーザを管理するための総合ＩＤであるとよい。個々の外部サービスサイト１２のアカウントを使わずに要求を受け付けることによって、個々のユーザが自分の普段活動しているアカウントを知られることなく、この発明にかかる到達型連絡サービスサーバ１１が管理する総合ＩＤだけを伝えておけば、その伝えた相手からの連絡要求信号を受け付けることができる。

到達型連絡サービスサーバ１１は、上記総合ＩＤを有する個々のユーザについての各々の外部サービスサイト１２におけるＩＤが登録されたユーザ管理データベース１１１を有する。ここで登録とは、ユーザ自身による場合と、サービス運営者による場合との、どちらも可能である。このユーザ管理データベース１１１の例を図３に示す。後述する状態収集部１０２が各々の外部サービスサイト１２における個々のユーザの活動を把握できるように、外部サービスサイト１２内において識別可能なＩＤをそれぞれに登録してある。このＩＤは、別途、ユーザがブラウザなどのＨＴＴＰ送信機能を有するアカウント送信部２００から、到達型連絡サービスサーバ１１が有するアカウント登録部１１２を通じて適宜登録可能にしておくと使い勝手の点から好ましい。アカウント登録部１１２はそれぞれのユーザに総合ＩＤとパスワードなどの認証手段とを払い出し、ブラウザなどを通じて認証を行える環境を提供する。認証したユーザは端末１０（１３）からアクセスし、自分が使用しておりかつ必要時の連絡先として登録しておきたいと考える外部サービスサイト１２のＩＤを登録しておく。

このユーザ管理データベース１１１の記録を参照して、到達型連絡サービスサーバ１１は、複数の外部サービスサイト１２における個々のユーザの活動記録を収集する状態収集部１０２を有する。これは、提携することになる各々の外部サービスサイト１２ごとに、それに対応したクライアントとして働くプログラムであるクライアント模擬部１０５を介して、巡回作業を行う。具体的には、ログインやログアウトの概念があるサービスではその有無を登録する。また、ＳＮＳサービスやミニブログサービスであれば、データベースに登録されたＩＤの投稿日時を収集する。ＭＭＯやソーシャルゲームなどでは具体的なアクションが確認できればその操作日時を収集する。集められた情報は、宛先であるユーザごとに後述するアクティビティ情報テーブル１２３に記録していく。なお、実際にはクライアント模擬部１０５は、上記の連絡要求受信部１０１と共通の、又は並立する物理ネットワークインターフェースを介して、ネットワーク経由で各外部サービスサイト１２と通信するが、図ではこれを略記する。

上記状態収集部１０２が活動記録を収集するタイミングは、ユーザからの要求に応じて適宜収集動作を行ってもよいし、間欠的に収集してもよいし、リアルタイムで収集していてもよい。ただし、パーティ内にメッセージ受信が限られるＭＭＯなど、リアルタイムにアクセスしていなければ追跡が困難である外部サービスサイト１２では収集作業もリアルタイムに行う必要がある。一方で、リアルタイムの収集を行うと外部サービスサイト１２に与える負荷が大きすぎるサービスである場合には、間隔を空けて定期的に収集したり、ユーザからの要求に応じて収集したりする形態であるとよい。

ＣＰ選択部１０３は、このような具体的な個々のユーザの活動記録の情報であるユーザアクティビティ情報から、それぞれのユーザがどの外部サービスサイト１２により連絡を取れば到達可能性が高いかを評価する。上記の投稿日時や操作日時が確認できる外部サービスサイト１２であれば、「現在時刻と投稿時刻（操作時刻）との差」の逆数の和であるアクティビティ情報Ａを直近の所定の一定時間に亘る過去の投稿について求めることで、大まかな評価が可能となる。一方、ＩＰ電話サービスなどの投稿日時が存在しない又は確認できないサービスであれば、上記の和Ａと比較できる程度の定数値を外部サービスサイト１２ごとに設定しておく。

なお、到達型連絡サービスサーバ１１は、それぞれの外部サービスサイト１２においてログインするための専用のアカウントをそれぞれ有しており、専用アカウント管理部１１３としてまとめて登録して参照可能にしておくと好ましい。ＡＰＩによって外部からユーザのアクティビティ情報やログイン情報を取得できない場合、一ユーザのアカウントとしてログインした上で、通常のユーザとして得られる情報を収集する。

ＣＰ設定部１０４は、ＣＰ選択部１０３が評価した値から、一定の到達可能性を確保できる外部サービスサイト１２を、当該ユーザへの連絡経路であるコミュニケーションパスを構築できるルートとして設定する。ここで、設定する外部サービスサイト１２は一つである必要はなく、複数の外部サービスサイト１２を選んでもよい。また、一つの外部サービスサイト１２について、一のユーザが複数のＩＤを登録している場合、それら複数のＩＤについてまとめて選択してもよい。

また、メッセージ作成部１０６は、上記の指定されたユーザについて、当該ユーザへの連絡経路として設定された外部サービスサイト１２を利用して、当該ユーザの登録したＩＤ宛のメッセージを作成する。作成したメッセージはクライアント模擬部１０５を介して送信さる。ここで、当該外部サービスサイト１２がＡＰＩを通じてメッセージを送信できるのであれば望ましいが、出来ない場合は上記の専用アカウント管理部１１３で登録されている到達型連絡サービスサーバ１１用のアカウントでログインし、一ユーザとしてメッセージを送信する。そのメッセージの内容としては、連絡要求を送信したユーザの総合ＩＤとともに、当該ユーザの名前を含んでいてもよいし、その他、当該ユーザが許可した情報を含んでいてもよい。また、メッセージだけでなく、そのメッセージが到達したか否かを管理する後述の要求記録テーブル１２２への記録が可能なＨＴＭＬページへ到達可能なアドレスを含めておいてもよい。

さらに、ＷＥＢサーバ１２４は、上記のＨＴＭＬページを生成し、またそれを通じた情報を受け取り、これを受けたメッセージ到達確認部１０８が上記要求記録テーブル１２２への書き込みを行う。

ユーザがこの発明を利用するまでの手順を図４のフロー図を用いて説明する。
まず（Ｓ１００）、この発明を利用する前提として、それぞれのユーザは外部サービスサイト１２でアカウントを作成する（Ｓ１０１）。その上で、平時からアカウントを作成した外部サービスサイト１２にて、メッセージや日記の投稿、ゲーム活動、会話などの活動を行う（Ｓ１０２）。またさらに前提として、この発明にかかる到達型連絡サービスサーバ１１にアカウント登録を行い（Ｓ１０３）、到達型連絡サービスサーバ１１から総合ＩＤとパスワードを発行してもらう。その上で、総合ＩＤ及びパスワードにより到達型連絡サービスサーバ１１にログインした上で、Ｓ１０２にて活動している外部サービスサイト１２のアカウント（ＩＤ）のうち選択したものを、外部サービスサイト１２の名称やアドレスなどとともに、総合ＩＤに紐づけて登録する作業を行う（Ｓ１０４）。ここで登録するＩＤは、ユーザがそれを通じて必要時に連絡を受け取りたいと考える外部サービスサイト１２を選択して選ぶことになる。一つの外部サービスサイト１２に複数のＩＤを登録している場合、そのＩＤを通じて連絡を受け取りたいと考えるＩＤを登録する。その上で、ユーザは自分に連絡をする必要が生じると思われる別のユーザに対して、自分の総合ＩＤを連絡する（Ｓ１０５）。当該別のユーザは、上記のＳ１０１〜１０５のうち、少なくともＳ１０３を行っておく必要がある。総合ＩＤによりログインできなければ到達型連絡サービスサーバ１１がサービスを提供できないからである。一方で、当該別のユーザはいずれかの外部サービスサイト１２で活動をしていてもよいが、別段の活動をしていなくても、この発明にかかる到達型連絡サービスサーバ１１を利用することが可能である。もちろん、Ｓ１０１〜Ｓ１０５の全ての行程を終えた別のユーザから、当該別のユーザの総合ＩＤを連絡されておくことで、当該別のユーザへ連絡を取れるようにしておく準備が完了する（Ｓ１０６）。

以上の手順のうち到達型連絡サービスサーバ１１の動作としては、Ｓ１０３として、アカウント登録部１１２がユーザ管理データベース１１１への新規レコード作成とともに総合ＩＤとパスワードの払い出しを行う新規総合ＩＤ発行手段を実行する。次に、Ｓ１０４として、それぞれの総合ＩＤのユーザが各々の外部サービスサイト１２におけるＩＤを登録する外部サイトＩＤ登録手段を実行する。図３に示すユーザ管理データベース１１１はこれらが実行された状態である。

なお、上記ユーザが一旦登録した後、外部サービスサイト１２の使用状況が変化したなどの理由により、連絡を受け付けたいと思う外部サービスサイト１２又はそのＩＤが変化した場合、到達型連絡サービスサーバ１１のアカウント登録部１１２は、既に登録済みの外部サービスサイト１２のＩＤについて、当該ＩＤを介しては連絡を受け取らない旨の設定が可能であるとよい利用可否設定手段が実行できるとよい。例えばここでは真偽値Ｐとして表し、１であれば受け取りを許可し、０であれば受け取りを拒否するように設定する。この真偽値Ｐは上記のユーザ管理データベース１１１に登録されている、各々の外部サービスサイト１２のＩＤと紐付けられて登録可能であるとよい。もちろん、ユーザ管理データベース１１１の中に含まれていてもよい。

以上を前提として、連絡要求信号を受け取ったときの到達型連絡サービスサーバ１１の動作を図５とともに説明する。まず（Ｓ１１１）、連絡要求受信部１０１が一のユーザ（上記別のユーザ）の端末１０から、連絡要求信号を受信する（Ｓ１１２）。連絡要求受信部１０１は、到達型連絡サービスサーバ１１のインターネットのような外部ネットワークに対して送受信可能なネットワークインターフェースである。なお、到達型連絡サービスサーバ１１が設置されるネットワークは、インターネットでもよいし、間接的にインターネットへの接続が可能な閉域網でもよい。連絡要求信号はＩＰでやり取りされる信号であり、少なくとも発信元である端末１０のユーザが有する総合ＩＤと、宛先として指定される端末１３のユーザが有する総合ＩＤとが含まれる。連絡要求受信部１０１から連絡要求信号を受け取った処理部（図示せず）は、信号から送信元と宛先の総合ＩＤを抽出して、両方の総合ＩＤがユーザ管理データベース１１１に存在しているか否かを検索する、ユーザ確認手段を実行する（Ｓ１１３）。

なお、ユーザ管理データベース１１１を検索しても当該総合ＩＤが見つからない場合は、エラーとなりそこで処理が中断される。

上記の検索により、ユーザ管理データベース１１１内に宛先となる上記総合ＩＤが見つかれば、そこに登録してある外部サービスサイト１２の名称と、それぞれの外部サービスサイト１２におけるＩＤとを取得する（Ｓ１１４）。必要な場合はパスワードも取得する。なお、図示しないが、それぞれの外部サービスサイト１２の名称から、それぞれの外部サービスサイト１２のサイトアドレスやＡＰＩの定義などを求めることができるサイトアドレスデータベースを別途用意しておくとよい。例えば、「ＳＮＳ１」という名称から、その外部サービスサイト１２のアドレスとともに、後述する活動記録の収集や、メッセージの送信などにおいて実行するＡＰＩの名称や、定義の仕方、得られるデータの解析方法などをまとめて定義しておく。

その上で、登録された外部サービスサイト１２へアクセスする（Ｓ１１５）。このとき、アクセスは外部サービスサイト１２の擬似的なクライアントソフトとして動作するクライアント模擬部１０５を介して行うが、外部サービスサイト１２にアクセスするためには、ＡＰＩを通して接続する場合と、一ユーザとしてログインしてアクセスする場合とがある。後者の場合、この発明にかかる到達型連絡サービスサーバ１１は、専用のアカウントを有している必要がある。この専用アカウントは、図６のような別途、専用アカウント管理部１１３としてサイト名、アドレス、ＩＤ，パスワードなどを纏めて保存しておく。また、ＭＭＯなどのゲームであれば、サービス内サーバ名などが含まれる場合もある。

そして、クライアント模擬部１０５を介してログインするか、或いはＡＰＩを利用するなどの方法により外部サービスサイト１２にアクセスした上で、状態収集部１０２は、宛先である総合ＩＤのユーザが、それぞれの外部サービスサイト１２におけるＩＤとして登録していたＩＤについての、当該外部サービスサイト１２における記録行動を収集する（Ｓ１１６)。ここで記録行動としては、取得できるのであればログイン状態であるか否かの真偽値Ｌを取得するとともに、直接の行動として投稿されたメッセージや記録があればその時刻を取得する。例えば、日記の投稿やつぶやきの投稿、他のユーザへのメッセージの送信、他のユーザの専用ページを閲覧した足跡、評価ボタンのクリック、購入活動など、外部サービスサイト１２の仕様により取得可能な様々な情報が挙げられる。

収集した記録行動の値は、ユーザアクティビティ情報として、図７（ａ）〜（ｄ）の例に示すようなアクティビティ情報テーブル１２３に記録していく。このアクティビティ情報テーブル１２３は連絡要求信号を受信する毎に、一時的に生成されるものである。まず、ユーザ管理データベースに当該総合ＩＤが使用する外部サービスサイト１２として登録された外部サービスサイト１２の名称と、ＵＲＬと、当該総合ＩＤに紐付けられたアカウント（ＩＤ）が初期値として登録される。また、ユーザ管理データベース１１１に受け取りを許可するか否かの真偽値Ｐが含まれている場合には、その値も引用する。さらに、アクティビティ情報Ａが後述するように固定値になっている外部サービスサイト１２についてはその値を登録する。この状態でのテーブルが図７（ａ）である。その上で、状態収集部１０２が収集したデータとしてログイン状態の真偽値Ｌが記録され、そして活動記録の時刻ｔ_ｉが記録される。この状態でのテーブルが図７（ｂ）である。

上記の状態収集部１０２が収集した活動記録の情報であるユーザアクティビティ情報に基づき、ＣＰ選択部１０３は、個々のユーザへの信号の到達可能性が所定の条件を満たす外部サービスサイト１２を選択する（Ｓ１１７）。ここで到達可能性とは、その外部サービスサイト１２の対応するＩＤを通じて連絡を試みた場合に、宛先であるユーザに到達する可能性の高さであり、直近の所定時間内におけるユーザの活動が活発である外部サービスサイト１２ほど高くなると考えられる。ただし、投稿時間や活動時間などの記録が無かったり、ＡＰＩなどを通じても投稿時間などの時間的要素が抽出できない外部サービスサイト１２においては、他の評価方法と比較可能なスケールで定数を定めて取り扱う。

この到達可能性を表すパラメータの例としては、例えば、現在時刻と投稿時刻との差の逆数を、直近の所定の時間中に亘る過去の投稿について加算した式（１）のような和Ａが挙げられる。仮に、単位「分」でカウントする場合、現在時刻ｔ_０から過去６０分間の間に、投稿時間ｔ_ｉを確認できた投稿が、２分前、４分前、８分前、１２分前、１６分前の５回にあった場合には、式（２）のように計算され、パラメータＡαは約１．０６となる。また、投稿時間ｔ_ｉを確認できた投稿が、３０分前、３５分前、４０分前、４５分前、５０分前の５回にあった場合には、式（３）のように計算され、パラメータＡβは約０．１３となる。さらに、投稿時間ｔ_ｉを確認できた投稿が、２分前、４分前の２回であった場合は、式（４）のように計算され、パラメータＡγは０．７５となる。つまり、回数の多いＡβよりも、直近の活動が多いＡγの方が、当然に到達可能性が高いアクティビティ情報Ａとして示される。これを算出した状態でのテーブルが図７（ｃ）である。

Ａ＝Σ｛１／（ｔ_０−ｔ_ｉ）｝ ……式（１）
Ａα＝1/2+1/4+1/8+1/12+1/16≒1.06……式（２）
Ａβ＝1/30+1/35+1/40+1/45+1/50≒0.13……式（３）
Ａγ＝1/2+1/4＝0.75……式（４）

このような基準で投稿日時からアクティビティ情報Ａをカウントする場合、ＩＰ電話などの投稿日時をカウントできないサービスの評価値は、固定値として０．１〜０．５程度の値を状況や外部サービスサイト１２の性質に合わせて設定するとよい。

その上で、ログイン状態であるか否かの真偽値Ｌと、上記のＡとの積であるコスト値Ｃ１＝Ｌ×Ａにより、上記の到達可能性を評価してもよい。直近にどれだけ活動していても、その後でログアウトしていた場合には連絡可能性がほぼ無くなってしまっているからである。

また、個々のユーザが設定する当該外部サービスサイトのＩＤを介した利用の可否を示す真偽値Ｐを乗算したコスト値Ｃ２＝Ｌ×Ａ×Ｐにより、上記の到達可能性を評価してもよい。直近の活動があっても、ユーザ本人がその外部サービスサイト１２経由で連絡を取られることを好まない場合、端末１３側で受信設定がされていなかったりする場合もあり、また、サービスとしても問題があるためである。

こうしてＣＰ選択部１０３が評価する際の値は、例えば図７（ｄ）に示すようなアクティビティ情報テーブル１２３のようになる。この例では、ユーザアクティビティ情報Ａの最大値は「メッセージサービス１」の１．０６であるが、ログオフしているため、Ｌが０となり、Ｃ２は０となる。「ＩＰ電話１」は投稿日時がカウントできないため定数０．２が割り当てられているが、ユーザによりＩＰ電話での連絡は拒否されているためＰが０となり、Ｃ２が０となる。「ＭＭＯ１」も同様に、ログオフしており、拒否となっているためＣ２が０となっている。値が示されている中では、「ミニブログ１」が０．７５として最も高いＣ２値を示すので、到達可能性が最も高いものとなる。

このようにして評価された到達可能性について、値が低すぎるものはそもそも試みる意義が薄いため、Ｃ１やＣ２の値が所定の値以上であるとよい。例えば時間を分でカウントして上記式（１）で評価する場合には、評価値が０．１未満である外部サービスサイト１２へのアクセスはほぼ無駄となるため無視するといった処理が可能である。また、条件を満たすものの中では、評価値が高い外部サービスサイト１２ほど到達可能性が高いことになり、ＣＰ設定部１０４は評価値が高い外部サービスサイト１２を比較的高い優先順位に選択設定する。図７の例では、「ミニブログ１」が優先順位１位、「ＳＮＳ２」が優先順位２位、「ＳＮＳ１」が優先順位３位の、ユーザへの連絡経路として選択される。

なお、評価値を求めた結果、全ての外部サービスサイト１２についての評価値（コスト値）が０になってしまった場合（Ｓ１２０−Ｙｅｓ）、到達可能性のある連絡経路が無いということになるため、処理部はネットワークインターフェースである連絡要求受信部１０１を通じて、端末１０へ連絡の到達が失敗した旨の通知を行うエラー報告手段を実行する。なお、後述する図１２のＳ３１１以降の処理を行うこともできる。

指定された総合ＩＤを有するユーザの評価結果として、上記の評価値が０ではない外部サービスサイト１２があれば（Ｓ１２０−Ｙｅｓ)、メッセージ作成部１０６は、このようにして選択された外部サービスサイト１２を当該ユーザへの連絡経路として、それぞれの外部サービスサイト１２についてユーザ管理データベース１１１に登録されたＩＤ宛のメッセージを作成する。このとき、優先順位が一番の外部サービスサイト１２宛のメッセージのみを作成してもよいし、所定の条件を満たす外部サービスサイト１２の全てに対して同報となるメッセージを作成してもよい。メッセージの内容としては、送信元である端末１０のユーザの総合ＩＤや登録したユーザ名などとともに、当該ユーザから連絡要求信号が発せられた旨を含めておくことが望ましい。作成したメッセージは、クライアント模擬部１０５を通じて外部サービスサイト１２における当該ユーザのＩＤ宛に送信される（Ｓ１２２）。ログイン状態である外部サービスサイト１２を通じて、端末１３にポップアップウインドウやテキストウインドウのメッセージなどの形で通知が到達する。受け取ったユーザは、その内容を見て、送信元のユーザが連絡を求めていることを知ることができる。

上記のメッセージ作成の際に、メッセージの受信確認、すなわち到達確認の要求を含めて確認ができると、サービスの確実性の点からより好ましい。特に、上記の優先順位を定めた外部サービスサイト１２のＩＤが複数ある場合、上位の優先順位である外部サービスサイト１２のＩＤで受信確認ができなかったとき、次の優先順位である外部サービスサイト１２のＩＤへメッセージを送信することで、速やかなフォローができ、メッセージの到達漏れを少なくすることができる。

具体的には、連絡要求信号を受けるごとに、要求記録テーブル１２２にレコードを作成し、到達型連絡サービスサーバ１１がＷＥＢサーバ１２４を通じて端末１３からの確認信号を受け取り、メッセージ到達確認部１０８を介して要求記録テーブル１２２へ確認の有無を登録する。

例として、子供である送信元ユーザが、親である宛先ユーザに連絡要求信号を送信するケースを考える。この場合の手順を図８以降に示すシーケンス図と、要求記録テーブル１２２の変遷を示す図９（ａ）〜（ｃ）ともに説明する。開始時点で、親であるユーザ（Ｐａｒｅｎｔ＿Ａ）はＳ１００〜Ｓ１０４の登録手順は既に終えており、子供であるユーザ（Ｃｈｉｌｄ＿Ａ）はＳ１０３の登録手順を既に終えている状態で、子供の端末１０のアプリケーションにユーザとして自身の総合ＩＤが登録され、かつ通知先として親の総合ＩＤが登録されていて、連絡要求信号を当該総合ＩＤ宛に送信可能な条件で設定されているものとする。

まず、端末１０から送信元として子供の総合ＩＤ（Ｃｈｉｌｄ＿Ａ）を指定し、宛先として親の総合ＩＤ（Ｐａｒｅｎｔ＿Ａ）を指定した連絡要求信号が到達型連絡サービスサーバ１１に送信される（Ｓ２０１、Ｓ１１２）。これを連絡要求受信部１０１から受信した到達型連絡サービスサーバ１１の処理部は、それぞれの総合ＩＤがユーザ管理データベース１１１に登録されているかを確認する（Ｓ２０２、Ｓ１１３）。要求記録テーブル１２２に、図９（ａ）のように、新たなレコードを追加する（Ｓ２０３）。個々のレコードには、連絡要求信号の受信時刻などから生成した、連絡要求信号ごとの固有のメッセージＩＤを付与し、送信元ユーザの総合ＩＤと、宛先ユーザの総合ＩＤとを登録する。また、ステータスとして連絡を求めている要求状態である旨の真偽値を真（１）とし、メッセージ到達確認の真偽値を偽（０）とする。

その上で、到達型連絡サービスサーバ１１の状態収集部１０２は、親であるＰａｒｅｎｔ＿Ａがユーザ管理データベース１１１にＩＤを登録してある外部サービスサイト１２ａ，１２ｂ，１２ｃを確認して（Ｓ１１４）、この親であるユーザのアクティビティ情報テーブル１２３を生成する（Ｓ２０４）。生成時のアクティビティ情報テーブルの例を図１０（ａ）に示す。次に、それぞれの外部サービスサイト１２についてアクセスしログイン状態を確認する（Ｓ１１５、Ｓ２０５）。仮にここで親であるユーザが外部サービスサイト１２ｃにのみログインしていた場合、外部サービスサイト１２ｃのみがＬ＝１となり、それ以外の外部サービスサイト１２ａ、１２ｂはＬ＝０との値が得られる（Ｓ２０６）。このときのアクティビティ情報テーブル１２３の例を図１０（ｂ）に示す。ログインしている外部サービスサイト１２ｃについて、活動記録であるアクティビティ情報を収集する（Ｓ２０７）。アクティビティ情報を記録したときのアクティビティ情報テーブル１２３の例を図１０（ｃ）に示す。

この値から、ＣＰ選択部１０３が、アクティビティ情報Ａを算出し（図１０（ｄ））、コスト値Ｃ２＝Ｌ×Ａ×Ｐを算出する（図１０（ｅ））（Ｓ２０８）。ＣＰ設定部１０４は、コスト値Ｃ２が０ではない連絡経路となる外部サービスサイト１２ｃを選択して、そのアドレスを、要求記録テーブル１２２に記録する（Ｓ２０９）。このときの要求記録テーブル１２２の例を図９（ｂ）に示す。優先順位が１番の連絡経路に、外部サービスサイト１２ｃのアドレスが登録される。また、優先順位が２番以降の連絡経路は存在しなかったため、ｎｕｌｌとなる。

また、メッセージ到達確認部１０８は、メッセージＩＤに対応したメッセージ到達確認ページを生成する（Ｓ２１０）。その上で、メッセージ作成部１０６が、Ｐａｔｅｎｔ＿Ａの外部サービスサイト１２ｃにおけるＩＤ宛のメッセージを作成する（Ｓ２１１）。このメッセージには、上記のメッセージ到達確認ページへアクセスするためのアドレスが含まれる。そのメッセージを、クライアント模擬部１０５が、選択された外部サービスサイト１２ｃへ送信する（Ｓ２１２）。このメッセージはプッシュ型でもプル型でもよく、いずれの形態にしても宛先である親の端末１３にメッセージが到達する。

ここからのシーケンス図を図１１に示す。親であるユーザは端末１３のＷＥＢブラウザや専用アプリなどのインターフェースを通じて、到達型連絡サービスサーバ１１のＷＥＢサーバ１２４にアクセスする（Ｓ２２１）。ＷＥＢサーバ１２４は、Ｓ２１０で生成されたＨＴＭＬページ（図１１に示す認証画面）を表示する（Ｓ２２２）。このページで、総合ＩＤとパスワードの入力を求めることで、第三者によるなりすましを防止できる。親であるユーザは総合ＩＤとパスワードを入力して送信する（Ｓ２２３）。この入力を受け付けたメッセージ到達確認部１０８は、総合ＩＤとパスワードが当該メッセージＩＤの宛先と一致することを確認した上で（Ｓ２２４）、ＯＫを通知する（Ｓ２２５）。さらに、メッセージ到達確認部１０８は、要求記録テーブル１２２のメッセージ到達確認を真（１）に変更するとともに、状態を真から偽（０）に変更する（Ｓ２２６）。この状態の要求記録テーブルの例を図９（ｃ）に示す。

さらに、直接メッセージが到達しない場合に、ユーザ間の関連付けを利用することも出来る。ここでユーザ間の関連付けとは、ＳＮＳにおける所謂「友達」機能などのように、メッセージの送受信やタイムラインの扱い上、メッセージの到達性が高くなる関係をいう。以下、友達関係、という。それぞれの外部サービスサイト１２において、宛先となるユーザのＩＤとの間で友達関係にあるＩＤの中に、ユーザ管理データベース１１１に登録されている、いずれかの総合ＩＤに関連付けて登録された、当該外部サービスサイト１２におけるＩＤが存在すれば、その友達関係にあるＩＤを通じての連絡が可能となる。

このような直接連絡が出来ない場合の処理フローを図１２に示す。まずＳ２０８の段階で（Ｓ３０１）、到達型連絡サービスサーバ１１の処理部は、宛先であるユーザ（上記の親であるユーザ）への連絡経路として選択可能な、コスト値が０ではない経路があるか否かを判断する連絡経路確認手段を実行する（Ｓ３０２）。連絡経路があれば（Ｓ３０２−Ｙｅｓ）、その外部サービスサイト１２のＩＤへメッセージを送信する（Ｓ３０３、Ｓ２１２）。ここまでは上記と同じである。その上で上記処理部は、メッセージの送信から一定時間内に、宛先であるユーザからの確認があるか否かを確認する到達確認待機手段を実行する（Ｓ３０４）。これで、到達が確認できれば（Ｓ３０４−Ｙｅｓ，Ｓ２２３）、そこで上記のように処理は終了する（Ｓ３０５、Ｓ２２４〜Ｓ２２６）。

しかし、Ｓ３０２の条件が成立しない場合、当該契約者が間接的に連絡を取ることを許可する別のユーザを介して、到達確認を試みる。この別のユーザとは、上記外部サービスサイトを介するか否かに関わりなく、当該契約者に対して、何らかの方法で連絡を取ることが可能であると考えられ、かつ、その人物から連絡を受けることを契約者が許容する相手である。この関係にある別のユーザを「フレンド」と呼称する。このフレンドを管理するフレンドデータベース１３１の例を図１３に示す。例では、総合ＩＤが「ＩＤ１」のユーザは、「ＩＤ２」「ＩＤ３」のユーザを介しての連絡を許容している。ＩＤ２、ＩＤ３のユーザは相互に、お互いを介しての連絡を許容している。ＩＤ５のユーザはＩＤ１のユーザを介しての連絡を許容しているが、ＩＤ１のユーザはＩＤ５のユーザを介しての連絡は許容していない。

このフレンドデータベース１３１への登録は、基本的には到達型連絡サービスサーバ１１が管理する総合ＩＤで行うことが望ましい。ｗｅｂサーバ１２４が、ネットワークを通じてフレンドデータベース１３１に、ユーザが自らへの連絡を許可する総合ＩＤの登録を行う登録用ページ作成手段を実行できるようにすると、ユーザが自発的に登録できるので好ましい。

まず、フレンドデータベース１３１を検索して、当該契約者にフレンドが登録されているか否かを判断する（Ｓ３１１）。フレンドが登録されていたら（Ｓ３１１−Ｙｅｓ）、当該フレンドのそれぞれに対して、有効な連絡経路があるか否かを判断する（Ｓ３１２）。この手順は上記Ｓ３０２と同じである。なお、登録されているフレンドが複数ある場合、優先順位ごとに連絡経路の有無を確認していってもよいし、全てのフレンドについて一斉に連絡経路の有無を確認してもよい。連絡経路を有するフレンドが存在したら（Ｓ３１２−Ｙｅｓ）、当該フレンドに対して、連絡を取ろうとする当該契約者本人へ連絡を取ることを求めるメッセージを送信する（Ｓ３１３）。このメッセージは上記と同様に到達確認を含むことが望ましい。一定時間内に、当該契約者本人、又は当該フレンドから到達確認があれば（Ｓ３１４−Ｙｅｓ）、処理は無事終了し、要求記録テーブル１２２の値を偽（０）に変更する（Ｓ３１５）。

一方、Ｓ３１１、Ｓ３１２、Ｓ３１４のいずれかの条件が成立しない場合は、当該契約者本人への連絡経路が確立できないことを意味する。この場合は、監視オペレータに緊急連絡を取り、警備会社による駆けつけ対応など、物理的な連絡手段などを駆使して何らかの手段により連絡をとることとなる（Ｓ３１６）。

１０ 端末
１１ 到達型連絡サービスサーバ
１２，１２ａ，１２ｂ，１２ｃ 外部サービスサイト
１３ 端末
１００ 連絡要求送信部
２００ アカウント送信部
１０１ 連絡要求受信部
１０２ 状態収集部
１０３ ＣＰ選択部
１０４ ＣＰ設定部
１０５ クライアント模擬部
１０６ メッセージ作成部
１０８ メッセージ到達確認部
１１１ ユーザ管理データベース
１１２ アカウント登録部
１１３ 専用アカウント管理部
１２２ 要求記録テーブル
１２３ アクティビティ情報テーブル
１２４ ＷＥＢサーバ
１３１ フレンドデータベース
２０１ ＡＰＩサーバ
２０２ 状態管理部
２０３ アカウントリンク情報管理部
２０４ メッセージ送受信部
Ａ アクティビティ情報
Ｃ１ コスト値
Ｃ２ コスト値
Ｌ 真偽値
Ｐ 真偽値
ｔ_ｉ 時刻
ｔ_０ 現在時刻

Claims (6)

1. 端末からのユーザを指定した連絡要求信号を受け付ける連絡要求受信部と、
   複数の外部サービスサイトにおける上記ユーザのＩＤが登録されたユーザ管理データベースと、
   各々の上記外部サービスサイトにおける個々のユーザの活動記録を収集する状態収集部と、
   上記状態収集部によって収集した上記活動記録の情報であるユーザアクティビティ情報に基づき、個々のユーザへの信号の到達可能性が所定の条件を満たす上記外部サービスサイトを選択するＣＰ選択部と、
   上記ＣＰ選択部で選択された上記外部サービスサイトを、当該ユーザへの連絡経路として設定するＣＰ設定部と、
   上記の指定されたユーザについて、当該ユーザへの連絡経路として設定された上記外部サービスサイトを介した、当該ユーザの登録した上記ＩＤ宛のメッセージを作成するメッセージ作成部と、
   を有する到達型連絡サービスサーバ。
2. 上記ＣＰ選択部が、
   上記外部サービスサイトのうち、メッセージを投稿可能な上記外部サービスサイトについては、
   個々のユーザの上記到達可能性の条件を、
   当該外部サービスサイトにおける過去の投稿について、現在時刻と投稿時刻との差の逆数を、直近の所定の時間中に亘って加算した和Ａと、
   ログイン状態を示す真偽値Ｌと、
   の積Ｃ１＝Ｌ×Ａを用いて評価し、このＣ１の値が所定の閾値以上である上記外部サービスサイトを、条件を満たすものとして選択する、請求項１に記載の到達型連絡サービスサーバ。
3. 上記ＣＰ選択部が、
   上記外部サービスサイトのうち、メッセージを投稿可能な上記外部サービスサイトについては、
   個々のユーザの上記到達可能性の条件を、
   当該外部サービスサイトにおける過去の投稿について、現在時刻と投稿時刻との差の逆数を、直近の所定の時間中に亘って加算した和Ａと、
   ログイン状態を示す真偽値Ｌと、
   個々のユーザが設定する当該外部サービスサイトのＩＤを介した利用の可否を示す真偽値Ｐと、
   の積Ｃ２＝Ｌ×Ａ×Ｐにより評価し、このＣ２の値が所定の閾値以上である上記外部サービスサイトを、条件を満たすものとして選択する、請求項１に記載の到達型連絡サービスサーバ。
4. 上記メッセージ作成部が、上記条件を満たす複数の上記外部サービスサイトのＩＤへ、同報でメッセージを作成可能である、請求項１乃至３のいずれかに記載の到達型連絡サービスサーバ。
5. 上記連絡要求受信部における上記ユーザの指定を、上記外部サービスサイトのＩＤを含まない、上記到達型連絡サービスサーバ用の総合ＩＤにより可能とする、請求項１乃至４のいずれかに記載の到達型連絡サービスサーバ。
6. 上記連絡要求信号ごとに、その要求が到達したか否かを管理する要求記録テーブルと、
   上記メッセージを受け取った上記ユーザが、上記要求記録テーブルへ記録可能なＨＴＭＬページを生成するＷＥＢサーバと、
   を有し、
   上記メッセージ作成部は、上記メッセージに上記ＷＥＢサーバにより生成されるＨＴＭＬページへ到達可能なアドレスを含める
   請求項１乃至５のいずれかに記載の到達型連絡サービスサーバ。

Images