JP2011129962A - サービストリガ制御システム、サーバ、方法およびプログラム - Google Patents

Abstract

【課題】特定の宛先を知らなくても所定のサービスを受けられるようにする。
【解決手段】サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御システムであって、接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定部と、判定部が接続応答装置が存在しないと判定した場合に、接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知部とを備える。
【選択図】図１

Description

本発明は、サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御システム、サービストリガ制御サーバ、サービストリガ制御方法およびサービストリガ制御プログラムに関する。

電話網をはじめとするネットワークを介して音声通話その他のサービスを利用する際のセッションの開始時において、例えばＳＩＰ（Session Initiation Protocol ）等の、セッションを確立するためのプロトコルを利用することが主流になりつつある。セッション確立用のプロトコルによれば、接続先の情報と送信元の情報がヘッダに記され、一般にＳＩＰサーバと呼ばれるプロキシサーバがセッションを管理することが可能となっている。

また、世界的には、一般にスマートフォンと呼ばれる携帯電話端末が多く利用され、端末によって通信事業者が限定されるということは少ない。一方、２００７年現在、日本では、一般に通信事業者ごとに利用できる端末が限定されている。通信事業者が提供するサービスを利用するためには、サービスにアクセスするためのＵＲＩを事前に入手し、利用可能な端末に直接ＵＲＩを入力する。または、サービスにアクセスするための専用のボタンが用意され、ボタン押下時にあらかじめ端末に記憶させておいたＵＲＩに自動的にアクセスするような仕組みを搭載している端末を利用する。

しかし、日本においてもスマートフォンタイプの端末が増加傾向にあり、さらに、通信事業者による利用端末の限定が解除される流れが出てきている。また、従来の固定電話回線網がＩＰ化されて音声通話以外の多様なサービスが展開されるようになるとともに、これまでの固定電話機も多機能になり、機能的にはスマートフォンに似た端末が登場すると予想される。

このような状況の中で、通信事業者が限定されないタイプの端末を用いてサービスを受ける場合、利用する端末によっては、通信事業者のインフラストラクチャを介して提供されるサービスにアクセスするために、特定の番号やＵＲＩを入力する必要があるという問題がある。

例えば、携帯電話通信網のような、通信事業者が回線で加入者を管理するようなネットワークにおいては、あるサービスのポータルページや、加入者ごとにカスタマイズされたサービスが提供されている。一般的なネットワーク上で行われている方法により、上記のようなサービスを実現する場合、例えば、非特許文献１，２に記載されている手段が取られている。

例えば、非特許文献１には、ある通信事業者が提供しているサービスサイトにアクセスする方法として、当該通信事業者網でしか利用できない専用端末に予め当該サイトのＵＲＬを記録しておき、専用ボタン等を押下することによりアクセスすることが記載されている。

また、非特許文献２には、一般的にあらかじめ利用者毎に用意されているカスタマイズされたサイトを、利用者がＷｅｂブラウザ等で表示させるための方法が記載されている。非特許文献２によれば、サービスプロバイダまたは通信事業者から事前に電子メール、郵送等で通知された特定のＵＲＬを入力したりリンクをクリックするか、あらかじめ指定されたポータルサイトにアクセスし、そこで利用者識別用のID、パスワード等を入力することにより、カスタマイズされたサイトにアクセスすることができる。

しかし、非特許文献１，２に記載されている方法には、以下のような問題がある。まず、利用者は、アクセスするサービスサイトの番号やＵＲＬ等のアドレスをあらかじめ知っているか入手している必要がある。また、アクセス先が利用者専用サービスである場合は、ポータルサイトのアドレスを知っていてかつパスワード等を事前に取得している必要がある。つまり、受けたいサービスのアクセス先の番号やＵＲＬ等の情報を知らなければ、サービスを受けることができない。

上記の問題点について、例えば自身の端末に付与されている番号をダイヤルし、ダイヤルされた番号とダイヤル操作した端末機が同一の場合は、メモリに記憶されているサービスの処理を行う技術が開示されている（例えば、特許文献１，２参照。）。

特開昭６３−１８７７５６号公報 特開平０８−２１４０６５号公報 "Ｙａｈｏｏ！ケータイ"、［online］、ソフトバンクモバイル株式会社、［平成２０年２月１４日検索］、インターネット＜ＵＲＬ：http://mb.softbank.jp/mb/service/3G/yahoo_keitai/index.html＞ "ＭｙＳｏｆｔＢａｎｋとは？"、［online］、ソフトバンクモバイル株式会社、［平成２０年２月１４日検索］、インターネット＜ＵＲＬ：http://mb.softbank.jp/mb/support/3G/mysoftbank/＞

特許文献１，２に記載されている技術の利用方法として、操作者が自身の端末に電話番号を入力する、または自身の端末にダイヤルする専用ボタンを押すといった利用の方法が考えられる。しかし、これらの方法には以下の課題が残る。

まず、操作者が電話番号を入力する場合、例えば電話番号なら少なくとも１０桁の番号を入力する必要がある。また、電話番号ではなく、他のＵＲＩ形式でアクセスする場合も、決まった文字列を入力する必要がある。さらに、万が一自分の電話番号やＵＲＩを忘れてしまった場合、特許文献１，２に記載されている技術を利用することができない。また、端末の機能に依存する問題として、専用ボタン押下時に、自身の端末の番号宛にダイヤルする、またはアクセスするという機能を持ったインタフェースが備えられている保証はない。

そこで、本発明は、特定の宛先を知らなくても所定のサービスを受けられるようにするサービストリガ制御システム、サービストリガ制御サーバ、サービストリガ制御方法およびサービストリガ制御プログラムを提供することを目的とする。

本発明によるサービストリガ制御システムは、サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御システムであって、接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定部と、判定部が接続応答装置が存在しないと判定した場合に、接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知部とを備えたことを特徴とする。

本発明によるサービストリガ制御サーバは、サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御サーバであって、接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定部と、判定部が接続応答装置が存在しないと判定した場合に、接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知部とを備えたことを特徴とする。

本発明によるサービストリガ制御方法は、サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御方法であって、接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定ステップと、判定ステップで接続応答装置が存在しないと判定した場合に、接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知ステップとを含むことを特徴とする。

本発明によるサービストリガ制御プログラムは、サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御プログラムであって、コンピュータに、接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定処理と、判定処理で接続応答装置が存在しないと判定した場合に、接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知処理とを実行させることを特徴とする。

本発明によれば、特定の宛先を知らなくても所定のサービスを受けられるようにすることができるという効果がある。

まず、本発明の概要について図面を参照して説明する。図１は、本発明によるサービストリガ制御システムの最小の構成例を示すブロック図である。図１に例示するサービストリガ制御システムは、判定部２０１と、通知部２１１とを備える。

サービストリガ制御システムは、サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させる。

判定部２０１は、接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する。

通知部２１１は、判定部２０１が接続応答装置が存在しないと判定した場合に、接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する。

図１に示すように構成すれば、特定の宛先を知らなくても所定のサービスを受けられるようにすることができる。

実施形態１．
以下、本発明の第１の実施形態を図面を参照して説明する。図２は、第１の実施形態のサービストリガ制御システムの構成例を示すブロック図である。図２に示すサービストリガ制御システムは、ユーザ端末１００と、プログラム制御により動作する接続先制御サーバ２００と、サービス提供サーバ３００とを備える。ユーザ端末１００、接続先制御サーバ２００およびサービス提供サーバ３００は、通信ネットワーク４００を介して相互に接続されている。なお、ユーザ端末１００は、接続要求装置として動作し、サービス提供サーバ３００は接続応答装置として動作する。接続先制御サーバ２００は、サービストリガ制御サーバとして動作する。

ユーザ端末１００は、携帯電話機、固定電話機、パーソナルコンピュータ（ＰＣ）、携帯端末（ＰＤＡ）等で種類を問わずに実現される。ユーザ端末１００は、通信ネットワーク４００に対し、サービス提供サーバ３００へのアクセスを要求するアクセス要求を送信する処理を実行する機能を有する。

アクセス要求は、アクセス要求の送信元を示す「送信元情報」と、アクセス先（接続先）を示す「接続先情報」とを含む情報である。また、アクセス要求は、アクセス要求自体の送信先（転送先）を示す「送信先情報」を含む。「送信先情報」は、例えば、ＩＰヘッダにおける宛先ＩＰアドレスで実現される。

サービス提供サーバ３００は、ユーザ端末１００が送信したアクセス要求に応じてサービスを提供する。サービス提供サーバ３００は、例えば、Ｗｅｂサーバで実現され、ポータルサイト等を表示するためのファイルを格納し、アクセス要求に応じてユーザ端末１００に送信する。

接続先制御サーバ２００は、ユーザ端末１００によるサービストリガに応じて、ユーザ端末１００とサービス提供サーバ３００とのセッションを確立させる処理を実行する機能を有する。サービストリガとは、サービス提供サーバ３００が提供するサービスを受けるためのきっかけとして、ユーザが存在しないサーバのＵＲＬを入力し、ユーザ端末１００が存在しないサーバのＵＲＬを含むアクセス要求を送信することを意味する。

具体的には、接続先制御サーバ２００は、第１の実施形態において、ユーザ端末１００からアクセス要求を受信し、アクセス要求に含まれる「接続先情報」に基づいて「送信先情報」を設定し、アクセス要求を転送する処理を実行する機能を有する。図３は、第１の実施形態の接続先制御サーバ２００の構成例を示すブロック図である。図３を参照すると、接続先制御サーバ２００は、判定部２０１と、転送機能部２０２と、送受信部２０３とを含む。

判定部２０１は、受信したアクセス要求の送信元と接続先が存在するかどうかを確認する。例えば、判定部２０１は、受信したアクセス要求に含まれる「接続先情報」が示す接続先が存在するか否かを判定する。

転送機能部２０２は、受信したアクセス要求の接続先（アクセス先）が存在しない場合、受信したアクセス要求を、あらかじめ決められたサービスの接続先に転送する。例えば、転送機能部２０２は、受信したアクセス要求に含まれる「接続先情報」が示す接続先が存在しない場合、アクセス要求の「送信先情報」に所定の接続先を示す情報を設定する。また、「接続先情報」に所定の接続先を示す情報を設定してもよい。

送受信部２０３は、ユーザ端末１００からのアクセス要求の送受信やサービス提供サーバとのアクセス要求の送受信を行う。

次に、図面を参照して第１の実施形態の動作について説明する。図４は、第１の実施形態におけるサービストリガ制御システムの処理の例を示すフローチャートである。

はじめに、ユーザ端末１００は、存在しない接続先を設定したアクセス要求を送信する（ステップＳ１１０）。例えば、ユーザ端末１００は、存在しない接続先を示す情報を「接続先情報」に設定したアクセス要求を送信する。

アクセス要求に含まれる送信元情報は、電話番号やＳＩＰ等のＵＲＩ、ＩＰアドレスなど、自端末を識別可能な情報であれば、形式を問わない。また、接続先情報は、任意の番号、文字列、あるいは空欄（設定しない）でもよい。

また、ユーザ端末１００は、アクセス要求自体の送信先（ＩＰヘッダの宛先等）として、交換機に相当するプロキシサーバ等を設定し、アクセス要求を送信する。具体的には、プロキシサーバとして、ＳＩＰサーバと呼ばれるプロキシサーバなどが考えられる。

接続先制御サーバ２００は、このプロキシサーバ等と同一機器内に置かれてもよく、プロキシサーバ等から転送される別の機器として実現されてもよい。いずれにしても、アクセス要求が接続先制御サーバ２００に到達するものとする。

次に、接続先制御サーバ２００は、受信したアクセス要求の処理を行う（ステップＳ１２０）。接続先制御サーバ２００が実行する処理（ステップＳ１２０）について、図５を参照して説明する。図５は、第１の実施形態の接続先制御サーバ２００が実行する処理の例を示すフローチャートである。

まず、接続先制御サーバ２００は、送受信部２０３を介してユーザ端末１００からのアクセス要求を受信する（ステップＳ２１０）。

次に、判定部２０１は、アクセス要求内に設定された接続先が存在するかどうかを確認する（ステップＳ２２０）。例えば、判定部２０１は、アクセス要求に含まれる接続先情報が示す接続先が、実在するか否かの判断を行う。

判定部２０１が接続先の有無を確認する方法は、接続先が存在するかしないかを確認できれば、どんな方法でもよい。例えば、存在する全接続先を示す情報と比較して一致するかを確認しても良いし、接続先として設定された番号やＵＲＩが、決められたフォーマットと一致するかしないかを確認してもよい。また、接続先情報が、空欄、ｎｕｌｌ等の場合は、当然のことながらその時点で存在しないと判断してもよい。

確認の結果、接続先が存在すると判断した場合、通常の処理として、接続先に対してアクセス要求を転送して終了する（ステップＳ２３５）。

確認の結果、接続先が存在しないと判断した場合、転送機能部２０２は、例えば、受信したアクセス要求自体の送信先（ＩＰヘッダの宛先等）を、あらかじめ通信事業者が決めておいたサービス提供サーバ３００の接続先に設定する（ステップＳ２３０）。例えば、転送機能部２０２は、アクセス要求の「送信先情報」にサービス提供サーバ３００を示す情報を設定する。このとき、アクセス要求内の接続先情報をサービス提供サーバ３００の情報に書き換えてもよいし、書き換えずに元の情報のままでもよい。

次に、送受信部２０３は、ステップＳ２３０で転送機能部２０２が設定した接続先（サービス提供サーバ３００）に対して、アクセス要求を転送し（ステップＳ２４０）、ステップＳ１２０の処理を終了する。

次に、図４を参照してステップＳ１３０の処理について説明する。サービス提供サーバ３００がアクセス要求を受信し、ユーザ端末１００とサービス提供サーバ３００との間でセッションが確立されると、アクセス要求を受信したサービス提供サーバ３００は、アクセス要求の送信元であるユーザ端末１００に対してサービスを提供し、一連の処理を終了する（ステップＳ１３０）。

以上に説明したように、第１の実施形態によれば、特殊な番号、ＵＲＬ等や自身の電話番号やＵＲＩを知らなくても、事前に決められたサービスを受けることができる。また、利用端末を取り換えても、同じサービスを受けることができる。その理由は、設定された接続先情報が無い場合も含め、接続先として存在しない番号や文字列等を設定してアクセス要求を送信すればよいからである。

また、極端に長い番号やＵＲＩを入力することなくサービスを受けることができる。その理由は、空欄を含め、任意の存在しない番号や文字列を接続先として設定することができるからである。つまり、番号の場合は電話番号よりも短い番号を設定すればよく、文字列からなるＵＲＩの場合も決められた形式以外で短い文字列を設定すればよいからである。

例えば、ユーザのＩＰ電話機から、アクセス先が不定となる任意の番号に対して電話をかけると、通信事業者の接続先制御サーバ２００が、アクセス先が存在しないことを確認した後、あらかじめ決めておいたサービス提供サーバ３００に対してユーザからアクセス要求がきた旨を通知する。存在する電話番号にかけた場合は、通常のセッション確立が行われ、通話等のサービスを受けることができる。

実施形態２．
次に、本発明の第２の実施形態を図面を参照して説明する。第１の実施形態では、あらかじめ通信事業者が決めておいたサービス提供サーバ３００にのみアクセス要求を転送していたが、第２の実施形態では、ユーザ毎に転送先サービスを設定できる点で第１の実施形態と異なる。

図６は、第２の実施形態の接続先制御サーバ２００の構成例を示すブロック図である。図６を参照すると、第２の実施形態では、図３に示す第１の実施形態に対し、データベース（ＤＢ）管理部２０４と、サービスデータベース（ＤＢ）２０５とが追加されている。なお、接続先制御サーバ２００のその他の構成は、第１の実施形態における構成（図３参照。）と同様であるため、説明を省略する。

データベース管理部２０４は、サービスデータベース２０５に対する検索や更新を管理する。

サービスデータベース２０５は、アクセス要求の送信元に対応するサービスのＵＲＬや番号等サービスの接続先を記憶するハードウェア資源である。例えば、サービスデータベース２０５は、アクセス要求の送信元を示す「送信元情報」と、アクセス要求の接続先を示す「接続先情報」とを対応付けて記憶する。

次に、図面を参照して第２の実施形態の動作について説明する。第２の実施形態では、サービストリガ制御システムの全体の動作は第１の実施形態の動作（図４参照。）と同様であるが、ステップＳ１２０の接続先制御サーバ２００の処理の内容が異なる。以下、ステップＳ１２０の接続先制御サーバ２００の処理について説明する。

図７は、第２の実施形態の接続先制御サーバ２００が実行する処理の例を示すフローチャートである。

図７におけるステップＳ２２０までの処理は、第１の実施形態における処理（図５参照。）と同様であるため、説明を省略する。

ステップＳ２２０での確認の結果、接続先が存在すると判断した場合、通常の処理として、接続先に対してアクセス要求を転送して終了する（ステップＳ２３５）。

確認の結果、接続先が存在しないと判断した場合、データベース管理部２０４は、サービスデータベース２０５を検索し、あらかじめ送信元に対応付けておいたサービス提供サーバ３００の接続先を取得する（ステップＳ２２５）。例えば、データベース管理部２０４は、ユーザ端末１００から受信したアクセス要求に含まれる送信元情報に基づいてサービスデータベース２０５を検索し、対応する接続先情報として、サービス提供サーバ３００の接続先を示す情報を抽出する。

次に、転送機能部２０２は、受信したアクセス要求自体の送信先（ＩＰヘッダの宛先等）を、ステップＳ２２５で取得した送信元に対応付けられたサービス提供サーバ３００の接続先に設定する（ステップＳ２３１）。例えば、転送機能部２０２は、アクセス要求の「送信先情報」にサービス提供サーバ３００の接続先を示す情報を設定し、ステップＳ２４０に移行する。以降の処理は、第１の実施形態における処理（図４，図５参照。）と同様であるため、説明を省略する。

以上に説明したように、第２の実施形態によれば、送信元ごとに異なるサービス提供先を設定することができるという効果がある。

実施形態３．
次に、本発明の第３の実施形態を図面を参照して説明する。第１の実施形態では、接続先制御サーバ２００は、受信したアクセス要求をサービス提供サーバ３００に転送していたが、第３の実施形態では、ユーザが送信したアクセス要求とは別セッションとなるアクセス要求を生成し、サービス提供サーバ３００に送信する点が異なる。

図８は、第３の実施形態の接続先制御サーバ２００の構成例を示すブロック図である。図８を参照すると、第３の実施形態では、図３に示す第１の実施形態における転送機能部２０２に代えて、アクセス要求生成管理部２０６が設けられている。

アクセス要求生成管理部２０６は、ユーザ端末１００が送信したアクセス要求とは別セッションとなるアクセス要求であって、あらかじめ通信事業者が決めておいたサービス提供サーバ３００宛てのアクセス要求を生成する。また、アクセス要求生成管理部２０６は、元の（すなわち、ユーザ端末１００が送信した）アクセス要求と別セッションのアクセス要求とを関連づけて管理する処理を行う。

次に、図面を参照して第３の実施形態の動作について説明する。第３の実施形態では、サービストリガ制御システムの全体の動作は第１の実施形態の動作（図４参照。）と同様であるが、ステップＳ１２０の接続先制御サーバ２００の処理の内容が異なる。以下、ステップＳ１２０の接続先制御サーバ２００の処理について説明する。

図９は、第３の実施形態の接続先制御サーバ２００が実行する処理の例を示すフローチャートである。

図９におけるステップＳ２２０までの処理は、第１の実施形態における処理（図５参照。）と同様であるため、説明を省略する。

ステップＳ２２０での確認の結果、接続先が存在すると判断した場合、通常の処理として、接続先に対してアクセス要求を転送して終了する（ステップＳ２３５）。

ステップＳ２２０において、判定部２０１が接続先が存在しないと判断した場合、ステップＳ２２６に移行する。ステップＳ２２６において、アクセス要求生成管理部２０６は、受信したアクセス要求とは別セッションとなるアクセス要求を生成し、受信した元のアクセス要求と関連付けて管理する。この際、アクセス要求生成管理部２０６は、アクセス要求内の送信元の情報を、ユーザ端末１００にしても、接続先制御サーバ２００にしてもよい。

次に、アクセス要求生成管理部２０６は、ステップＳ２２６で生成したアクセス要求自体の送信先（ＩＰヘッダの宛先等）を、あらかじめ通信事業者が決めておいたサービス提供サーバ３００の接続先に設定する（ステップＳ２３２）。

次に、ステップＳ２４１で、送受信部２０３は、ステップＳ２２６で生成したアクセス要求自体を、ステップＳ２３２で設定した接続先に送信し、ステップＳ１２０の処理を終了する。以降の処理は、第１の実施形態における処理（図４参照。）と同様であるため、説明を省略する。

第３の実施形態は、例えば、アクセス要求内のヘッダその他の情報を、途中で書き換えてはいけないような場合に、別のアクセス要求を生成し必要な情報を置き換えて別セッションとして管理することで実現する方法として適している。第３の実施形態は、例えばＳＩＰ（Session Initiation Protocol ）の場合、内部的に２つのＳＩＰ端末（User Agent）を背中合わせに実装したＢ２ＢＵＡ（Back to Back User Agent ）と呼ばれるものと同様である。

実施形態４．
次に、本発明の第４の実施形態を図面を参照して説明する。第４の実施形態は、第２の実施形態の特徴であるユーザ毎に転送先サービスを設定できる点と、第３の実施形態の特徴であるアクセス要求を別セッションとなるように生成し、サービス提供サーバ３００に送信する点を併せ持った方式である。

図１０は、第４の実施形態の接続先制御サーバ２００の構成例を示すブロック図である。図１０を参照すると、第４の実施形態では、図６に示す第２の実施形態における転送機能部２０２に代えて、図８に示す第３の実施形態におけるアクセス要求生成管理部２０６が設けられている。

次に、図面を参照して第４の実施形態の動作について説明する。第４の実施形態では、サービストリガ制御システムの全体の動作は第１〜第３の実施形態の動作（図４参照。）と同様であるが、ステップＳ１２０の接続先制御サーバ２００の処理の内容が異なる。以下、ステップＳ１２０の接続先制御サーバ２００の処理について説明する。

図１１は、第４の実施形態の接続先制御サーバ２００が実行する処理の例を示すフローチャートである。

図１１におけるステップＳ２２５までの処理およびステップＳ２３５の処理は、第２の実施形態における処理（図７参照。）と同様であるため、説明を省略する。

第４の実施形態では、ステップＳ２２５の処理の後、ステップＳ２２６の処理を実行する。ステップＳ２２６の処理は、第３の実施形態における処理（図９参照。）と同様であるため、説明を省略する。

次に、アクセス要求生成管理部２０６は、ステップＳ２２６で生成したアクセス要求自体の送信先（ＩＰヘッダの宛先等）を、ステップＳ２２５で取得したサービス提供サーバ３００の接続先に設定する（ステップＳ２３３）。例えば、アクセス要求生成管理部２０６は、ステップＳ２２６においてアクセス要求生成管理部２０６が生成した別セッションとなるアクセス要求の「送信先情報」に、ステップＳ２２５でデータベース管理部２０４がサービスデータベース２０５から抽出したサービス提供サーバ３００の接続先を示す情報を設定する。

次に、ステップＳ２４２で、送受信部２０３は、ステップＳ２２６で生成したアクセス要求自体を、ステップＳ２３３で設定した接続先に送信し、ステップＳ１２０の処理を終了する。以降の処理は、第１〜第３の実施形態における処理（図４参照。）と同様であるため、説明を省略する。

第４の実施形態によれば、送信元ごとに異なるサービス提供先を設定することができ、かつ、プロトコルの仕様上書き換えてはいけない部分を変更したい場合でも対応することができる。その理由は、元のアクセス要求情報で書き換えてはいけない部分には手を加えず、元のアクセス要求とは異なるセッションのアクセス要求を生成し、その別セッションとなるアクセス要求にあらかじめ定められた情報を設定しているからである。

なお、上記に示した実施形態では、以下の（１）〜（５）に示すような特徴的構成を備えたサービストリガ制御システムが示されている。

（１）サービス提供のトリガとなる接続要求に応じて、接続要求（例えば、アクセス要求で実現される）を送信した接続要求装置（例えば、ユーザ端末１００で実現される）と接続要求に応答する接続応答装置（例えば、サービス提供サーバ３００で実現される）との接続を確立させるサービストリガ制御システムであって、接続応答装置を示す接続応答装置情報（例えば、接続先情報で実現される）を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定部（例えば、判定部２０１で実現される）と、判定部が接続応答装置が存在しないと判定した場合に、接続要求装置が接続要求を送信した旨を所定の接続応答装置（例えば、サービス提供サーバ３００で実現される）に通知する通知部（例えば、通知部２１１、転送機能部２０２および送受信部２０３で実現される）とを備えたサービストリガ制御システム。

（２）通知部は、判定部が接続応答装置が存在しないと判定した場合に、接続要求に含まれる情報であって接続要求の送信先を示す送信先情報に、所定の接続応答装置を示す情報を設定して、当該接続要求を転送するサービストリガ制御システム。そのように構成されたサービストリガ制御システムは、送信先情報を用いて接続要求を転送することができる。

（３）判定部が接続応答装置が存在しないと判定した場合に、接続要求装置が送信した接続要求とは異なる接続要求を生成する接続要求生成部（例えば、アクセス要求生成管理部２０６で実現される）を備え、通知部は、接続要求生成部が生成した接続要求を、所定の接続応答装置に送信するサービストリガ制御システム。そのように構成されたサービストリガ制御システムは、接続要求を書き換えてはいけない場合に、特定の宛先を知らなくても、所定のサービスを受けることができる。

（４）接続要求の送信元を示す送信元情報と、接続応答装置情報とを対応付けて記憶するデータベース（例えば、サービスデータベース２０５で実現される）を備え、通知部は、判定部が接続応答装置が存在しないと判定した場合に、接続要求に含まれる送信元情報に対応する接続応答装置情報を前記データベースから抽出し、抽出した接続応答装置情報が示す接続応答装置に接続要求装置が接続要求を送信した旨を通知するサービストリガ制御システム。そのように構成されたサービストリガ制御システムは、接続要求の送信元ごとに異なる接続応答装置に通知を行うことができる。

（５）判定部は、接続応答装置情報が設定されていない場合に、当該接続応答装置情報が示している接続応答装置が存在しないと判定するサービストリガ制御システム。そのように構成されたサービストリガ制御システムは、接続応答装置情報が設定されていない場合に接続応答装置が存在しないと判定することができる。

本発明は、特定の宛先を設定することなく、所定のサービスを受けたい場合に効果的に適用できる。

本発明によるサービストリガ制御システムの最小の構成例を示すブロック図である。 第１の実施形態のサービストリガ制御システムの構成例を示すブロック図である。 第１の実施形態の接続先制御サーバの構成例を示すブロック図である。 第１の実施形態におけるサービストリガ制御システムの処理の例を示すフローチャートである。 第１の実施形態の接続先制御サーバが実行する処理の例を示すフローチャートである。 第２の実施形態の接続先制御サーバの構成例を示すブロック図である。 第２の実施形態の接続先制御サーバが実行する処理の例を示すフローチャートである。 第３の実施形態の接続先制御サーバの構成例を示すブロック図である。 第３の実施形態の接続先制御サーバが実行する処理の例を示すフローチャートである。 第４の実施形態の接続先制御サーバの構成例を示すブロック図である。 第４の実施形態の接続先制御サーバが実行する処理の例を示すフローチャートである。

符号の説明

２０１ 判定部
２１１ 通知部

Claims (11)

1. サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御システムであって、
   接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定部と、
   前記判定部が接続応答装置が存在しないと判定した場合に、前記接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知部と
   を備えたことを特徴とするサービストリガ制御システム。
2. 通知部は、判定部が接続応答装置が存在しないと判定した場合に、接続要求に含まれる情報であって接続要求の送信先を示す送信先情報に、所定の接続応答装置を示す情報を設定して、当該接続要求を転送する
   請求項１記載のサービストリガ制御システム。
3. 判定部が接続応答装置が存在しないと判定した場合に、接続要求装置が送信した接続要求とは異なる接続要求を生成する接続要求生成部を備え、
   通知部は、前記接続要求生成部が生成した接続要求を、所定の接続応答装置に送信する
   請求項１または請求項２記載のサービストリガ制御システム。
4. 接続要求の送信元を示す送信元情報と、接続応答装置情報とを対応付けて記憶するデータベースを備え、
   通知部は、判定部が接続応答装置が存在しないと判定した場合に、接続要求に含まれる送信元情報に対応する接続応答装置情報を前記データベースから抽出し、抽出した接続応答装置情報が示す接続応答装置に接続要求装置が接続要求を送信した旨を通知する
   請求項１から請求項３のうちのいずれか１項に記載のサービストリガ制御システム。
5. 判定部は、接続応答装置情報が設定されていない場合に、当該接続応答装置情報が示している接続応答装置が存在しないと判定する
   請求項１から請求項４のうちのいずれか１項に記載のサービストリガ制御システム。
6. サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御サーバであって、
   接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定部と、
   前記判定部が接続応答装置が存在しないと判定した場合に、前記接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知部と
   を備えたことを特徴とするサービストリガ制御サーバ。
7. 通知部は、判定部が接続応答装置が存在しないと判定した場合に、接続要求に含まれる情報であって接続要求の送信先を示す送信先情報に、所定の接続応答装置を示す情報を設定して、当該接続要求を転送する
   請求項６記載のサービストリガ制御サーバ。
8. サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるサービストリガ制御方法であって、
   接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定ステップと、
   前記判定ステップで接続応答装置が存在しないと判定した場合に、前記接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知ステップと
   を含むことを特徴とするサービストリガ制御方法。
9. 通知ステップで、判定ステップで接続応答装置が存在しないと判定した場合に、接続要求に含まれる情報であって接続要求の送信先を示す送信先情報に、所定の接続応答装置を示す情報を設定して、当該接続要求を転送する
   請求項８記載のサービストリガ制御方法。
10. サービス提供のトリガとなる接続要求に応じて、接続要求を送信した接続要求装置と接続要求に応答する接続応答装置との接続を確立させるためのサービストリガ制御プログラムであって、
    コンピュータに、
    接続応答装置を示す接続応答装置情報を含む接続要求について、当該接続応答装置情報が示している接続応答装置が存在するか否かを判定する判定処理と、
    前記判定処理で接続応答装置が存在しないと判定した場合に、前記接続要求装置が接続要求を送信した旨を所定の接続応答装置に通知する通知処理と
    を実行させるためのサービストリガ制御プログラム。
11. コンピュータに、
    通知処理で、判定処理で接続応答装置が存在しないと判定した場合に、接続要求に含まれる情報であって接続要求の送信先を示す送信先情報に、所定の接続応答装置を示す情報を設定して、当該接続要求を転送する処理を実行させるための
    請求項１０記載のサービストリガ制御プログラム。

Images