JP2004304366A

JP2004304366A - サービス提供システム

Info

Publication number: JP2004304366A
Application number: JP2003092864A
Authority: JP
Inventors: Kazumasa Ushiki; 一雅宇式
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2003-03-28
Filing date: 2003-03-28
Publication date: 2004-10-28
Anticipated expiration: 2023-03-28
Also published as: US20040193710A1; JP4084225B2

Abstract

【課題】大規模なサービスエリアでも、当該サービスエリアに在圏するユーザ端末に対して当該ユーザの状態に応じた適切なサービスを提供することが可能なサービス提供システムを提供する。
【解決手段】サービス提供システムは、通信ネットワークを利用し、サービスエリアに在圏するユーザ端末３０に対して該ユーザの状態に応じたサービスを提供するものであり、サービスエリアを複数に分割したエリア２０毎に設置され、管轄するエリア２０に在圏するユーザ端末３０に対応するユーザの状態情報を管理する状態管理サーバ１０と、ユーザ端末３０に対して提供されるサービスのアプリケーションを実行するアプリケーションサーバ４０とを備えて構成される。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、通信ネットワークを利用し、サービスエリアに在圏するユーザ端末に対して該ユーザの状態に応じたサービスを提供するサービス提供システムに関する。
【０００２】
【従来の技術】
近年、インターネットや移動通信ネットワークをはじめとする通信ネットワークの急速な普及に伴い、当該通信ネットワークを利用して、ユーザ端末に対し、情報配信等の様々なサービスが提供されるようになっている。
【０００３】
例えば、鉄道の定期券利用者が所有する携帯端末に対して、電子メールにより情報を配信するサービスがある。この情報配信サービスでは、定期券利用者が所有する携帯端末のメールアドレスが予め登録される。そして、定期券利用者が駅の自動改札機を通過すると、その通過が検知され、登録されたメールアドレスの携帯端末に対し、ユーザの状態に応じた情報が電子メールにより配信される（例えば、非特許文献１参照）。
【０００４】
また、加入者が自ら加入契約を行った事業者以外の事業者網へ移動した場合に、ホームロケーションレジスタが移動先の通信網内のビジターロケーションレジスタへ加入者の情報を転送することにより、継続してサービスを提供する方法がある（例えば、特許文献１参照）。
【０００５】
【非特許文献１】
［ｏｎｌｉｎｅ］、［平成１５年３月７日検索］、インターネット、＜ＵＲＬ：ｈｔｔｐ：／／ｗｗｗ．ｇｏｏｐａｓ．ｊｐ／ｎｏｆｌａｓｈ／ｖｉｒｔｕａｌ．ｈｔｍｌ＞
【０００６】
【特許文献１】
特許第２８４５３０６号公報（第３−４頁、図２）
【０００７】
【発明が解決しようとする課題】
ところで、非特許文献１における、鉄道の定期券利用者が所有する携帯端末に対して、電子メールにより情報を配信するサービスは、サービスエリアが鉄道の沿線という極めて限定されたエリアであり、サービスの提供を受けるユーザは、定期券利用者に限定される。このため、システムは小規模であり、例えばユーザの状態情報を管理するサーバ（状態管理サーバ）は１台で済む。
【０００８】
しかしながら、大規模なサービスエリアで同様のサービスを実現する場合、サービスエリアの拡大に伴って、サービスの提供を受けるユーザも多くなる。このため、小規模なシステムであって、例えば状態管理サーバが１台である場合には、その状態管理サーバの負荷が増大してしまう。特に、個々のユーザの状態に応じたきめ細かなサービスを実現する場合には、状態管理サーバは、１人のユーザについて多数の状態情報を管理する必要があり、更に負荷が増大する。また、ユーザ端末から状態管理サーバまでの距離が長くなるため、通信ネットワークに及ぼされる負荷も増大する。また、特許文献１における、加入者情報の転送により継続してサービスを提供する方法では、個々のユーザの状態に応じたきめ細かなサービスを実現する構成になっておらず、１人のユーザについて多数の状態情報を管理することが想定されていない。このため、大規模なサービスエリアでも、サーバや通信ネットワークに及ぼされる負荷が小さく、且つ、ユーザの状態に応じた適切なサービスを提供することが要求されている。
【０００９】
本願の課題は、大規模なサービスエリアでも、当該サービスエリアに在圏するユーザ端末に対して当該ユーザの状態に応じた適切なサービスを提供することが可能なサービス提供システムを提供することにある。
【００１０】
【課題を解決するための手段】
上記課題を解決するために、本発明は請求項１に記載されるように、通信ネットワークを利用し、サービスエリアに在圏するユーザ端末に対して該ユーザの状態に応じたサービスを提供するサービス提供システムにおいて、前記サービスエリアを複数に分割した分割エリア毎に設置され、管轄する前記分割エリアに在圏するユーザ端末に対応するユーザの状態情報を管理する状態管理サーバと、前記ユーザ端末に対して提供されるサービスのアプリケーションを実行するアプリケーションサーバとを備えることを特徴とする。
【００１１】
このようなサービス提供システムでは、サービスエリアを複数に分割した分割エリア毎に、管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態情報を管理する状態管理サーバが設置されている。従って、個々の状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態情報のみを管理すれば良い。このため、サービスエリアが大規模で多数のユーザが存在し、更には、１人のユーザについての多数の状態情報を管理する場合においても各状態管理サーバにおける負荷が軽減される。また、状態管理サーバが分散して設置されるため、ユーザ端末から状態管理サーバまでの距離を短くすることが可能となり、通信ネットワークに及ぼされる負荷も軽減される。
【００１２】
また、本発明は請求項２に記載されるように、請求項１に記載のサービス提供システムにおいて、前記ユーザ端末が前記分割エリアを跨って移動した場合に、移動前の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバは、移動後の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバに対して、前記分割エリアを跨って移動したユーザ端末に対応する前記ユーザの状態情報を通知することを特徴とする。
【００１３】
ユーザ端末が分割エリアを跨って移動した場合には、移動前のユーザ端末が在圏する分割エリアを管轄する状態管理サーバから移動後のユーザ端末が在圏する分割エリアを管轄する状態管理サーバへ当該ユーザ端末に対応するユーザの状態情報が通知されるため、サービス提供システムは、ユーザ端末の移動後においても、ユーザの状態に応じたサービスを継続して提供することが可能となる。
【００１４】
また、本発明は請求項３に記載されるように、請求項１又は２に記載のサービス提供システムにおいて、前記状態管理サーバは、自らが管轄する分割エリアの近傍に設置されることを特徴とする。
【００１５】
状態管理サーバが、自らが管轄する分割エリアの近傍に設置されることにより、状態管理サーバと、当該状態管理サーバが管轄する分割エリアに在圏するユーザ端末との距離を短くすることができ、通信ネットワークに及ぼされる負荷が軽減される。
【００１６】
また、本発明は請求項４に記載されるように、請求項１乃至３の何れかに記載のサービス提供システムにおいて、前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの識別情報を前記アプリケーションサーバへ通知し、前記アプリケーションサーバは、前記ユーザの識別情報に対応するユーザ端末に対して提供されるサービスのアプリケーションを実行することを特徴とする。
【００１７】
また、本発明は請求項５に記載されるように、請求項４に記載のサービス提供システムにおいて、前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態が所定のユーザ条件を満たす場合に、該ユーザの識別情報を前記アプリケーションサーバへ通知することを特徴とする。
【００１８】
この場合には、アプリケーションサーバは、ユーザの状態が所定のユーザ条件を満たす場合にのみ、サービスのアプリケーションを実行することになるため、ユーザの状態に応じた適切なサービスの提供が可能となる。
【００１９】
また、本発明は請求項６に記載されるように、請求項５に記載のサービス提供システムにおいて、前記ユーザ端末が前記分割エリアを跨って移動した場合に、移動前の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバは、移動後の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバに対して、前記分割エリアを跨って移動したユーザ端末に対応する前記所定のユーザ条件を通知することを特徴とする。
【００２０】
ユーザ端末が分割エリアを跨って移動した場合には、移動前のユーザ端末が在圏する分割エリアを管轄する状態管理サーバから移動後のユーザ端末が在圏する分割エリアを管轄する状態管理サーバへ所定のユーザ条件が通知されるため、移動後のユーザ端末が在圏する分割エリアを管轄する状態管理サーバにおいても、当該ユーザ端末に対応するユーザの状態が所定のユーザ条件を満たすか否かを判定することができる。
【００２１】
また、本発明は請求項７に記載されるように、請求項５又は６に記載のサービス提供システムにおいて、前記状態管理サーバは、前記所定のユーザ条件のうち、自らが管轄する分割エリアにおいて有効なものを特定し、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態がその特定した所定のユーザ条件を満たす場合に、該ユーザの識別情報を前記アプリケーションサーバへ通知することを特徴とする。
【００２２】
この場合には、状態管理サーバは、ユーザの状態が所定のユーザ条件を満たすか否かを判定する際に、自らが管轄する分割エリアにおいて有効なユーザ条件のみを用いるため、その判定処理を必要最小限に抑えることができ、更に負荷の軽減を図ることができる。
【００２３】
また、本発明は請求項８に記載されるように、請求項１乃至７に記載のサービス提供システムにおいて、前記アプリケーションサーバは、前記状態管理サーバから通知されるユーザの識別情報に対応するユーザ端末に対して、サービスを提案することを特徴とする。
【００２４】
この場合には、ユーザからの要求によってサービスを提供するだけでなく、サービス提供システムが能動的にサービスを提案するため、ユーザが様々なサービスの提供を受ける機会が増え、利便性を向上させることができる。
【００２５】
また、本発明は請求項９に記載されるように、請求項８に記載のサービス提供システムにおいて、前記ユーザ端末は、前記アプリケーションサーバによって提案されたサービスの何れかを該アプリケーションサーバへ要求することを特徴とする。
【００２６】
また、本発明は請求項１０に記載されるように、請求項１乃至９の何れかに記載のサービス提供システムにおいて、前記ユーザ端末に対して提供するサービスに対応する課金を行う課金サーバを備えることを特徴とする。
【００２７】
このように、課金を可能とすることにより、商用サービスに適したサービス提供システムの構築が可能となる。
【００２８】
【発明の実施の形態】
以下、図面を参照しながら本発明の実施の形態を説明する。
【００２９】
図１は、本発明の一実施形態にかかるサービス提供システムの構成例を示す図である。同図に示すサービス提供システムは、状態管理サーバ１０−１〜１０−Ｎ（以下、これら状態管理サーバ１０−１〜１０−Ｎを適宜「状態管理サーバ１０」と称する）、ユーザ端末３０、アプリケーションサーバ４０−１〜４０−Ｍ（以下、これらアプリケーションサーバ４０−１〜４０−Ｍを適宜「アプリケーションサーバ４０」と称する）、及び、ネットワーク６０により構成される。
【００３０】
このサービス提供システムでは、サービスエリアが複数のエリア２０−１〜２０−Ｎ（以下、これらエリア２０−１〜２０−Ｎを適宜「エリア２０」と称する）に分割されており、各エリア２０に在圏するユーザ端末３０に対して該ユーザの状態に応じたサービスが提供される。
【００３１】
各状態管理サーバ１０は、エリア２０毎に、当該エリア２０の近傍に設置され、管轄するエリア２０に在圏するユーザ端末３０に対応するユーザの状態情報を管理する。例えば、状態管理サーバ１０−１は、管轄するエリア２０−１に在圏するユーザ端末３０に対応するユーザの状態情報（ユーザ状態情報）を管理する。ユーザ状態情報とは、例えば、ユーザの位置、嗜好、精神状態、所持品等、様々なものが考えられる。
【００３２】
各アプリケーションサーバ４０は、ユーザ端末３０に対して提供するサービスのアプリケーションを実行する。ロケーションサーバ５０は、ユーザ端末３０の位置を管理する。なお、ロケーションサーバ５０の代わりに、例えば、ユーザの認証機能を有する認証サーバ等、位置管理以外の他の機能を有するサーバがユーザ端末３０の位置を管理するようにしても良い。ネットワーク６０には、状態管理サーバ１０、アプリケーションサーバ４０及びロケーションサーバ５０が接続される。
【００３３】
このサービス提供システムにおいて、ユーザ端末３０がエリア２０を跨って移動すると、移動元のエリア２０を管轄する状態管理サーバ１０から移動先のエリア２０を管理する状態管理サーバ１０へ、当該ユーザ端末３０に対応するユーザ状態情報が転送される。
【００３４】
図２は、ユーザ端末３０の移動時におけるサービス提供システムの処理を示す図である。同図において、ユーザ端末３０は、エリア２０−１からエリア２０−２へ移動し、更にエリア２０−２からエリア２０−３へ移動する。
【００３５】
ユーザ端末３０は、エリア２０を跨る毎に、移動先のエリア２０を管轄する状態管理サーバ１０を介して、位置登録要求を送信する。ロケーションサーバ５０は、この位置登録要求に応じて位置登録を行い、移動先のエリア２０を管轄する状態管理サーバ１０を介して、ユーザ端末３０へ位置登録応答を返す。また、ロケーションサーバ５０は、移動元のエリア２０を管轄するユーザ状態管理サーバ１０のアドレス情報を管理しており、位置登録応答にこれを設定することができる。
【００３６】
ユーザ端末３０がエリア２０−１からエリア２０−２へ移動すると、移動先のエリア２０−２を管轄する状態管理サーバ（旧在圏状態管理サーバ）１０−２は、移動元のエリア２０−１を管轄する状態管理サーバ（旧々在圏状態管理サーバ）１０−１に対して、状態転送要求を送信する。旧々在圏状態管理サーバ１０−１は、この要求に応じて、ユーザ端末３０に対応するユーザ状態情報と、ユーザ端末３０へのサービス提供に関する所定のユーザ条件（以下、「トリガ」と称する）に関する情報（トリガ情報）とを含んだ状態転送応答を、旧在圏状態管理サーバ１０−２へ送信する。
【００３７】
更に、ユーザ端末３０がエリア２０−２からエリア２０−３へ移動すると、移動先のエリア２０−３を管轄する状態管理サーバ（新在圏状態管理サーバ）１０−３は、移動元のエリア２０−２を管轄する旧在圏状態管理サーバ１０−２に対して、ユーザ端末３０に対応する状態転送要求を送信する。旧在圏状態管理サーバ１０−２は、この要求に応じて、ユーザ端末３０に対応するユーザ状態情報とトリガ情報とを含んだ状態転送応答を、新在圏状態管理サーバ１０−３へ送信する。
【００３８】
図３は、図２における新在圏状態管理サーバ１０−３の処理を示すフローチャートである。新在圏状態管理サーバ１０−３は、自らが管轄するエリア２０−３内へユーザ端末３０が移動すると、当該ユーザ端末３０から送信される位置登録要求を受信する（ステップ１０１）。次に、新在圏状態管理サーバ１０−３は、受信した位置登録要求をロケーションサーバ５０へ送信し（ステップ１０２）、当該ロケーションサーバ５０からの位置登録応答を受信する（ステップ１０３）。
【００３９】
ロケーションサーバ５０によるユーザ端末３０の位置登録が成功している場合、新在圏状態管理サーバ１０−３は、旧在圏状態管理サーバ１０−２に対して、ユーザ端末３０に対応するユーザ状態情報及びトリガ情報の転送要求（状態転送要求）を送信する（ステップ１０４）。旧在圏状態管理サーバ１０−２のアドレス情報は、ロケーションサーバ５０から送信される位置登録応答によって通知されるか、あるいは、ユーザ端末３０から送信される位置登録要求によって通知される。このため、新在圏状態管理サーバ１０−３は、このアドレス情報により、旧在圏状態管理サーバ１０−２を認識することができる。
【００４０】
更に、新在圏状態管理サーバ１０−３は、旧在圏状態管理サーバ１０−２からの状態転送応答を受信する（ステップ１０５）。この状態転送応答には、ユーザ端末３０に対応するユーザ状態情報とトリガ情報とが含まれる。新在圏状態管理サーバ１０−３は、状態転送応答に含まれるユーザ状態情報を、自らが管轄するエリア２０−３に在圏するユーザ端末３０に対応するユーザ状態情報として設定する（ステップ１０６）。
【００４１】
次に、新在圏状態管理サーバ１０−３は、状態転送応答に含まれるトリガ情報を分析の対象として設定する（ステップ１０７）。なお、新在圏状態管理サーバ１０−３は、トリガ情報に関して後述する分割アクティベーション処理を行う場合には、図５に示す処理を行う。更に、新在圏状態管理サーバ１０−３は、位置登録応答をユーザ端末３０へ送信する（ステップ１０８）。
【００４２】
図４は、図２における旧在圏状態管理サーバ１０−２の処理を示すフローチャートである。旧在圏状態管理サーバ１０−２は、新在圏状態管理サーバ１０−３からの状態転送要求を受信する（ステップ２０１）。
【００４３】
次に、旧在圏状態管理サーバ１０−２は、自身が管理する、指定されたユーザ端末３０に対応するユーザ状態情報と、トリガ情報とを取得する（ステップ２０２、２０３）。なお、旧在圏状態管理サーバ１０−２は、トリガ情報に関して後述する分割アクティベーション処理を行う場合には、図６に示す処理を行う。更に、旧在圏状態管理サーバ１０−２は、旧々在圏状態管理サーバ１０−１へ状態消去要求を送信する（ステップ２０４）。この状態消去要求を受信した旧々在圏状態管理サーバ１０−１は、指定されたユーザ端末３０に対応するユーザ状態情報及びトリガ情報を消去し、旧在圏状態管理サーバ１０−２へ状態消去応答を送信する。
【００４４】
旧在圏状態管理サーバ１０−２は、この旧々在圏状態管理サーバ１０−１からの状態消去応答を受信する（ステップ２０５）。更に、旧在圏状態管理サーバ１０−２は、ステップ２０２及びステップ２０３において取得した、ユーザ端末３０に対応するユーザ状態情報及びトリガ情報とを含んだ状態転送応答を、新在圏状態管理サーバ１０−３へ送信する（ステップ２０６）。
【００４５】
図５は、図２における新在圏状態管理サーバ１０−３が分割アクティベーション処理を行う場合のフローチャートである。ここで分割アクティベーション処理とは、状態管理サーバ１０が自らが管轄するエリア２０において有効なトリガ情報のみについて、分析の対象として設定する処理のことを言う。
【００４６】
新在圏状態管理サーバ１０−３は、旧在圏状態管理サーバ１０−２からの状態転送応答に含まれる、ユーザ端末３０に対応する全てのトリガ情報についてアクティベーション処理を行ったか否かを判定する（ステップ３０１）。全てのトリガについてアクティベーション処理を行った場合には、新在圏状態管理サーバ１０−３は、一連の処理を終了する。一方、全てのトリガ情報についてアクティベーション処理を行っていない場合には、新在圏状態管理サーバ１０−３は、その未だアクティベーション処理を行っていないトリガ情報が管轄するエリア２０−３において有効であるか否かを判定する（ステップ３０２）。
【００４７】
トリガがエリア２０−３において有効である場合には、新在圏状態管理サーバ１０−３は、そのトリガ情報を分析の対象として設定（アクティベート）する（ステップ３０３）。一方、トリガ情報がエリア２０−３において有効でない場合には、新在圏状態管理サーバ１０−３は、そのトリガ情報を分析の対象とせずに、保存（デアクティベート）する（ステップ３０４）。ステップ３０３及び３０４の処理の後、再び、全てのトリガ情報についてアクティベーション処理を行ったか否かの判定（ステップ３０１）以降の動作が繰り返される。
【００４８】
図６は、図２における旧在圏状態管理サーバ１０−２の分割アクティベーションが行われたトリガに対する処理を示すフローチャートである。旧在圏状態管理サーバ１０−２は、ユーザ端末３０の移動後に、分析の対象として設定（アクティベート）していたユーザ端末３０に対応するトリガ情報を、保存（デアクティベート）する（ステップ４０１）。更に、旧在圏状態管理サーバ１０−２は、ステップ４０１において保存したトリガ情報を含む全ての保存したユーザ端末３０に対応するトリガ情報を取得する（ステップ４０２）。旧在圏状態管理サーバ１０−２は、これらの取得したトリガ情報を状態転送応答に含ませて、新在圏状態管理サーバ１０−３へ送信することができる。なお、図６に示す処理は、旧在圏状態管理サーバ１０−２が新在圏状態管理サーバ１０−３へユーザ状態情報を送信する際に行われても良く、送信後に行われても良い。
【００４９】
図７は、仲介サーバを有する場合におけるサービス提供システムの処理を示す図である。同図において、仲介サーバ７０は、ユーザ端末３０の位置を管理するロケーションサーバとしての機能を有する。また、ユーザ端末３０は、エリア２０−１からエリア２０−２へ移動する。
【００５０】
ユーザ端末３０は、エリア２０−１からエリア２０−２へ移動すると、移動先のエリア２０−２を管轄する状態管理サーバ（新在圏状態管理サーバ）１０−２を介して、仲介サーバ７０へ位置登録要求を送信する。仲介サーバ７０は、この位置登録要求に応じて位置登録を行う。更に、仲介サーバ７０は、移動元のエリア２０−１を管轄する状態管理サーバ（旧在圏状態管理サーバ）１０−１からのユーザ端末３０に対応するユーザ状態情報及びトリガ情報を取得し、これらユーザ状態情報及びトリガ情報を含んだ位置登録応答を、新在圏状態管理サーバ１０−２へ送信する。
【００５１】
図８は、図７における新在圏状態管理サーバ１０−２の処理を示すフローチャートである。新在圏状態管理サーバ１０−２は、自らが管轄するエリア２０−２内へユーザ端末３０が移動すると、当該ユーザ端末３０から送信される位置登録要求を受信する（ステップ５０１）。次に、新在圏状態管理サーバ１０−２は、受信した位置登録要求を仲介サーバ７０へ送信し（ステップ５０２）、当該仲介サーバ７０からの位置登録応答を受信する（ステップ５０３）。
【００５２】
仲介サーバ７０によるユーザ端末３０の位置登録が成功している場合、新在圏状態管理サーバ１０−２は、受信した位置登録応答に含まれるユーザ状態情報を、自らが管轄するエリア２０−２に在圏するユーザ端末３０に対応するユーザ状態情報として設定する（ステップ５０４）。
【００５３】
次に、新在圏状態管理サーバ１０−２は、位置登録応答に含まれるトリガ情報を分析の対象として設定する（ステップ５０５）。更に、新在圏状態管理サーバ１０−２は、位置登録応答をユーザ端末３０へ送信する（ステップ５０６）。
【００５４】
図９は、図７における仲介サーバ７０の処理を示すフローチャートである。仲介サーバ７０は、新在圏状態管理サーバ１０−２からの位置登録要求を受信する（ステップ６０１）。
【００５５】
次に、仲介サーバ７０は、受信した位置登録要求に応じて、ユーザ端末３０の位置登録に関わる処理を行う（ステップ６０２）。更に、仲介サーバ７０は、旧在圏状態管理サーバ１０−１に対して、ユーザ端末３０に対応するユーザ状態情報及びトリガ情報の転送要求（状態転送要求）を送信する（ステップ６０３）。仲介サーバ７０は、ユーザ端末３０の移動を管理しているため、移動元のエリア２０−１を管轄する旧在圏状態管理サーバ１０−１のアドレス情報を取得している。このため、仲介サーバ７０は、このアドレス情報により、旧在圏状態管理サーバ１０−１を認識することができる。
【００５６】
更に、仲介サーバ７０は、旧在圏状態管理サーバ１０−２からの状態転送応答を受信する（ステップ６０４）。この状態転送応答には、ユーザ端末３０に対応するユーザ状態情報とトリガ情報とが含まれる。仲介サーバ７０は、状態転送応答に含まれるユーザ状態情報及びトリガ情報を保存するとともに（ステップ６０５）、これらユーザ状態情報及びトリガ情報を含んだ位置登録応答を新在圏状態管理サーバ１０−３へ送信する（ステップ６０６）。
【００５７】
図１０は、図７における旧在圏状態管理サーバ１０−１の処理を示すフローチャートである。旧在圏状態管理サーバ１０−１は、仲介サーバ７０からの状態転送要求を受信する（ステップ７０１）。
【００５８】
次に、旧在圏状態管理サーバ１０−１は、指定されたユーザ端末３０に対応するユーザ状態情報と、トリガ情報とを取得する（ステップ７０２、７０３）。更に、旧在圏状態管理サーバ１０−１は、取得したユーザ端末３０に対応するユーザ状態情報及びトリガ情報とを含んだ状態転送応答を、仲介サーバ７０へ送信する（ステップ７０４）。
【００５９】
図１１は、図７における仲介サーバ７０が分割アクティベーション処理を行う場合のフローチャートである。仲介サーバ７０は、ユーザ端末３０に対応する全てのトリガ情報について、アクティベーション処理を行ったか否かを判定する（ステップ８０１）。全てのトリガ情報についてアクティベーション処理を行った場合には、仲介サーバ７０は、一連の処理を終了する。一方、全てのトリガ情報についてアクティベーション処理を行っていない場合には、仲介サーバ７０は、その未だアクティベーション処理を行っていないトリガ情報が新在圏状態管理サーバ１０−２が管轄するエリア２０−２において有効であるか否かを判定する（ステップ８０２）。
【００６０】
トリガ情報がエリア２０−２において有効である場合には、仲介サーバ７０は、そのトリガ情報を分析の対象として設定（アクティベート）する（ステップ８０３）。一方、トリガ情報がエリア２０−２において有効でない場合には、仲介サーバ７０は、そのトリガ情報を分析の対象として設定しない（スキップ）（ステップ８０４）。ステップ８０３及び８０４の処理の後、再び、全てのトリガ情報についてアクティベーション処理を行ったか否かの判定（ステップ８０１）以降の動作が繰り返される。アクティベートされたトリガは、図９のステップ６０６において新在圏状態管理サーバに送信される。
【００６１】
図１２は、ユーザ状態更新時におけるサービス提供システムの処理を示す図である。同図において、アプリケーションサーバ４０−１は、提案サービスのアプリケーションを実行するものであり、アプリケーションサーバ４０−２は、加入サービスのアプリケーションを実行するものである。このサービス提供システムでは、新在圏状態管理サーバ１０は、管轄するエリア２０−１に在圏するユーザ端末３０から通知されるユーザ状態に応じて、管理しているユーザ端末３０に対応するユーザ状態情報を更新する。
【００６２】
図１３は、図１２における新在圏状態管理サーバ１０−１の処理を示すフローチャートである。新在圏状態管理サーバ１０−１は、ユーザ端末３０からの状態通知を受信する（ステップ９０１）。この状態通知には、ユーザ端末３０に対応するユーザの状態に関する情報が含まれている。次に、新在圏状態管理サーバ１０−１は、管理しているユーザ端末３０に対応するユーザ状態情報を更新する（ステップ９０２）。次に、新在圏状態管理サーバ１０−１は、ユーザ状態情報に基づいて、トリガ情報の分析を行う（ステップ９０３）。ここで、トリガ情報の分析とは、ユーザ端末３０に対応するユーザの状態が当該トリガ情報に対応する所定のユーザ条件を満たしたか否かを判定する処理を言う。更に、新在圏状態管理サーバ１０−１は、トリガ情報が検出されたか否かを判定する（ステップ９０４）。ここで、トリガ情報の検出とは、ユーザ端末３０に対応するユーザの状態が当該トリガ情報に対応する所定のユーザ条件を満たした場合に、そのトリガ情報を検出することを言う。トリガ情報が検出された場合、新在圏状態管理サーバ１０−１は、アプリケーションサーバ４０（ここでは、アプリケーションサーバ４０−２）へトリガ通知を送信する（ステップ９０５）。このトリガ通知には、ユーザ端末３０に対応するユーザの識別情報が含まれている。一方、トリガ情報が検出されなかった場合には、ステップ９０５の処理は行われない。
【００６３】
更に、新在圏状態管理サーバ１０−１は、ユーザ分析が許可されているか否かを判定する（ステップ９０６）。ユーザ分析が許可されている場合、新在圏状態管理サーバ１０−１は、ユーザ状態に基づいてユーザの分析を行う（ステップ９０７）。次に、新在圏状態管理サーバ１０−１は、ユーザ分析の結果、ユーザ通知の条件が満たされているか否かを判定する（ステップ９０８）。ユーザ通知の条件が満たされている場合、新在圏状態管理サーバ１０−１は、ユーザ端末３０に対応するユーザの識別情報を含んだユーザ通知をアプリケーションサーバ４０（ここでは、アプリケーションサーバ４０−１）へ送信する（ステップ９０９）。一方、ユーザ通知の条件が満たされていない場合には、ステップ９０９の処理は行われない。
【００６４】
ステップ９０６においてユーザ分析が許可されていないと判定された後、ステップ９０８においてユーザ通知の条件が満たされていないと判定された後、及び、ステップ９０９においてユーザの識別情報が通知された後、新在圏状態管理サーバ１０−１は、ユーザ端末３０へ状態通知応答を送信する（ステップ９１０）。なお、ステップ９１０の処理は必ずしも行われなくても良い。
【００６５】
図１４は、図１２におけるトリガ通知を受けたアプリケーションサーバ４０−２の処理を示すフローチャートである。アプリケーションサーバ４０−２は、新在圏状態管理サーバ１０−１からのトリガ通知を受信すると（ステップ１００１）、そのトリガ通知に応じたサービスのアプリケーションを実行する（ステップ１００２）。以降、アプリケーションサーバ４０−２は、個々のサービスに応じた処理を行う。
【００６６】
図１５は、図１２におけるユーザ通知を受けたアプリケーションサーバ４０−１の処理を示すフローチャートである。アプリケーションサーバ４０−１は、新在圏状態管理サーバ１０−１からのユーザ通知を受信すると（ステップ１１０１）、そのユーザ通知により特定されるユーザに対するサービス提案を作成する（ステップ１１０２）。更に、アプリケーションサーバ４０−１は、ユーザ通知により特定されるユーザのユーザ端末３０に対して、作成したサービス提案を送信する（ステップ１１０３）。
【００６７】
サービス提案を受信したユーザ端末３０は、当該サービス提案に基づいて、サービスを要求する。アプリケーションサーバ４０−１は、その要求されたサービスのアプリケーションを実行する。この際、アプリケーションサーバ４０−１は、サービス提供後に必要に応じて当該サービスの利用料金をユーザ対して課金する。
【００６８】
なお、ユーザ端末３０は、アプリケーションサーバ４０−１からのサービス提案を拒否することができる。この場合、ユーザ端末３０は、アプリケーションサーバ４０−１に対して、サーヒス提案の拒否要求を送信する。このサービス提案の拒否要求を受信したアプリケーションサーバ４０−１は、以後、ユーザ端末３０に対するサービス提案の送信を停止する。
【００６９】
図１６は、新規トリガ設定時におけるサービス提供システムの処理を示す図である。このサービス提供システムでは、アプリケーションサーバ４０−１は、ユーザ端末３０が在圏するエリア２０−１を管轄する新在圏状態管理サーバ１０−１に対し、直接に、又は、仲介サーバ７０を介して、トリガの設定要求を送信する。新在圏状態管理サーバ１０−１は、この要求に応じて、ユーザ端末３０に対応する新たなトリガ情報を設定する。更に、新在圏状態管理サーバ１０−１は、ユーザ端末３０に対応するユーザの状態が当該トリガ情報に対応する所定のユーザ条件を満たす場合に、アプリケーションサーバ４０−１に対し、トリガ通知を送信する。トリガ通知を受信したアプリケーションサーバ４０−１は、ユーザ端末３０に対して提供されるサービスのアプリケーションを実行する。なお、図１６における仲介サーバ７０は、図２における仲介サーバ７０とは異なり、ユーザ端末３０の位置を管理する機能を有していない。
【００７０】
図１７は、図１６におけるアプリケーションサーバ４０−１の処理を示すフローチャートである。アプリケーションサーバ４０−１は、ロケーションサーバ５０に対して、ユーザ端末３０が在圏するエリア２０−１を管轄する新在圏状態管理サーバ１０−１のアドレスを問い合わせる（ロケーション要求）（ステップ１２０１）。アプリケーションサーバ４０−１は、ロケーションサーバ５０から送信される、アドレスを含んだロケーション応答を受信すると（ステップ１２０２）、そのアドレスにより特定される新在圏状態管理サーバ１０−１に対して、ユーザ端末３０に対応するトリガ情報を分析の対象として設定することの要求（トリガ設定要求）を送信する（ステップ１２０３）。更に、アプリケーションサーバ４０−１は、新在圏状態管理サーバ１０−１から送信される、トリガ情報が分析の対象とされた旨の応答であるトリガ設定応答を受信する（ステップ１２０４）。
【００７１】
図１８は、図１６におけるロケーションサーバ５０の処理を示すフローチャートである。ロケーションサーバ５０は、アプリケーションサーバ４０−１からのトリガ設定要求を受信すると（ステップ１３０１）、自らが管理している、ユーザ端末３０が在圏するエリア２０−１を管轄する新在圏状態管理サーバ１０−１のアドレスを取得する（ロケーション取得）（ステップ１３０２）。
【００７２】
更に、ロケーションサーバ５０は、トリガ設定要求を生成し（ステップ１３０３）、取得したアドレスにより特定される新在圏状態管理サーバ１０−１に対して、生成したトリガ設定要求を送信する（ステップ１３０４）。更に、アプリケーションサーバ４０−１は、新在圏状態管理サーバ１０−１から送信される、トリガ設定応答を受信すると（ステップ１３０５）、当該トリガ設定応答をアプリケーションサーバ４０−１へ送信する（ステップ１３０６）。
【００７３】
なお、図１７及び図１８では、ロケーションサーバ５０がユーザ端末３０が在圏するエリア２０−１を管轄する新在圏状態管理サーバ１０−１のアドレスを保持しているが、他のサーバが保持するようにしても良い。
【００７４】
次に、シーケンス図を参照しつつ、本実施形態のサービス提供システムの動作を説明する。
【００７５】
図１９は、ユーザ状態管理処理の第１の例を示すシーケンス図である。同図において、ユーザ端末（ＵＴ）に対応するユーザ状態情報は、状態管理サーバ１〜３（ＳＭＳ１〜ＳＭＳ３）の何れかにおいてのみ管理される。
【００７６】
ＵＴは、ＳＭＳ１が管轄するエリアであるＡ駅に在圏し、更に、ＳＭＳ２が管轄するエリアであるＢ空港へ移動する。このため、ＵＴに対応するユーザ状態情報は、まずＳＭＳ１によって管理され、続いてＳＭＳ２によって管理される。また、ＵＴに対応するトリガ情報は、ユーザ状態情報とともに、まずＳＭＳ１によって管理され、続いてＳＭＳ２によって管理される。図２０は、ＳＭＳ２によって管理されるトリガ情報の一例を示す図である。図２０に示すトリガ情報は、ＵＴがＳＭＳ１が管轄するエリアであるＡ駅に在圏する場合に、ＳＭＳ１からアプリケーションサーバ１（ＡＳ１）へトリガ通知が送信されることにより、当該ＡＳ１におけるアプリケーションの実行を可能とするためのものと、ＵＴがＳＭＳ２が管轄するエリアであるＢ空港に在圏する場合に、ＳＭＳ２からアプリケーションサーバ２（ＡＳ２）へトリガ通知が送信されることにより、当該ＡＳ２におけるアプリケーションの実行を可能とするためのものである。
【００７７】
ＳＭＳ２が管轄するエリアであるＢ空港に在圏するＵＴは、ＳＭＳ２へ状態通知を送信している（ステップ２００１）。その後、ＵＴは、ＳＭＳ３が管轄するエリアであるＣ会社へ移動すると、当該Ｃ会社に対応するルータ３（ＥＲ３）からのエリア広告を受信する（ステップ２００２）。
【００７８】
ＵＴは、このエリア広告の受信により、ＳＭＳ２が管轄するエリア（Ｂ空港）からＳＭＳ３が管轄するエリア（Ｃ会社）へ移動したことを認識し、ＳＭＳ３に対して位置登録要求を送信する（ステップ２００３）。ＳＭＳ３のアドレスは、例えばＥＲ３からのエリア広告に含まれているか、ＵＴが予め保持している。あるいは、ＵＴは、ユニバーサルプラグアンドプレイ（ＵＰｎＰ）等の手続により、ＳＭＳ３のアドレスを取得する。位置登録要求は、例えばＥＲ３を介してＳＭＳ３へ転送される。
【００７９】
位置登録要求を受信したＳＭＳ３は、当該位置登録要求をロケーションサーバ（ＬＳ）へ送信する（ステップ２００４）。位置登録要求を受信したＬＳは、ＵＴの位置情報をＳＭＳ２からＳＭＳ３へ更新する。更に、ＬＳは、ＳＭＳ３へ位置登録応答を送信する（ステップ２００５）。この際、ＬＳは、ＵＴがＣ会社の前に在圏していたエリアであるＢ空港を管轄するＳＭＳ２のアドレスを位置登録要求に含ませる。
【００８０】
位置登録応答を受信したＳＭＳ３は、当該位置登録応答に含まれるアドレスにより特定されるＳＭＳ２に対して、状態転送要求を送信する（ステップ２００６）。なお、ＵＴが位置登録要求にＳＭＳ２のアドレスを含ませて送信する場合には、ＳＭＳ３は、当該位置登録要求に含まれるアドレスにより、ＳＭＳ２を特定するようにしても良い。
【００８１】
状態転送要求を受信したＳＭＳ２は、ＵＴがＢ空港の前に在圏していたエリアであるＡ駅を管轄するＳＭＳ１に対して、状態消去要求を送信する（ステップ２００７）。ＳＭＳ１は、この状態消去要求に応じてＵＴに対応するユーザ状態情報を消去し、ＳＭＳ２に対して状態消去応答を送信する（ステップ２００８）。
【００８２】
次に、ＳＭＳ２は、ＳＭＳ３に対して、状態転送応答を送信する（ステップ２００９）。この状態転送応答には、ＵＴに対応するユーザ状態情報とトリガ情報とが含まれている。
【００８３】
状態転送応答を受信したＳＭＳ３は、当該状態転送応答に含まれる、ＵＴに対応するユーザ状態情報とトリガ情報とを管理する。この際、ＳＭＳ３は、ＵＴに対応するトリガ情報のうち、自身が管轄するエリアにおいて有効なトリガ情報についてのみ、分析の対象とし、他のトリガ情報については分析の対象とせずに保存する。例えば、ＳＭＳ３は、ＳＭＳ２からの状態転送応答に、図２０に示すトリガ情報が含まれている場合には、ＳＭＳ３が管轄するエリアにおいて有効なトリガ情報が存在しないため、何れのトリガ情報も分析の対象とせずに保存する。更に、ＳＭＳ３は、ＵＴへ位置登録応答を送信する（ステップ２０１０）。位置登録応答を受信したＵＴは、その後、ＳＭＳ３へ状態通知を送信する（ステップ２０１１）。
【００８４】
また、ＵＴが新たなサービスに加入し、新規のトリガ情報が必要になった場合には、その新たなサービスのアプリケーションを実行するアプリケーションサーバ（ＡＳ）は、ＬＳに対してロケーション要求を送信する（ステップ２０１２）。ロケーション要求を受信したＬＳは、ＡＳ３に対して、ＵＴの位置情報としてのＳＭＳ３のアドレスを送信する（ステップ２０１３）。ロケーション応答を受信したＡＳは、当該ロケーション応答に含まれるアドレスにより特定されるＳＭＳに対してトリガ設定要求を送信する（ステップ２０１４）。トリガ設定要求を受信したＳＭＳ３は、ＵＴに対応する新たなトリガ情報を設定する。この場合、ＳＭＳ３が管理するＵＴに対応するトリガ情報は、図２１に示すように、ＳＭＳ２から送信されたトリガ情報と、新たに設定したトリガ情報となる。更に、ＳＭＳ３は、ＵＴに対応するトリガ情報のうち、自身が管轄するエリアにおいて有効なトリガ情報についてのみ、分析の対象とし、他のトリガ情報については分析の対象とせずに保存する。ＳＭＳ３は、新たなトリガ情報を設定した後、ＡＳに対して、トリガ設定応答を送信する（ステップ２０１５）。
【００８５】
図２２は、ユーザ状態管理処理の第２の例を示すシーケンス図である。ＳＭＳ１が管轄するエリアであるＢ空港に在圏するＵＴは、ＳＭＳ１へ状態通知を送信している（ステップ２１０１）。その後、ＵＴは、ＳＭＳ２が管轄するエリアであるＣ会社へ移動すると、当該Ｃ会社に対応するルータ２（ＥＲ２）からのエリア広告を受信する（ステップ２１０２）。
【００８６】
ＵＴは、このエリア広告の受信により、ＳＭＳ１が管轄するエリア（Ｂ空港）からＳＭＳ２が管轄するエリア（Ｃ会社）へ移動したことを認識し、ＳＭＳ２に対して位置登録要求を送信する（ステップ２１０３）。
【００８７】
位置登録要求を受信したＳＭＳ２は、当該位置登録要求をロケーションサーバ（ＬＳ）へ送信する（ステップ２１０４）。位置登録要求を受信したＬＳは、ＵＴの位置情報をＳＭＳ１からＳＭＳ２へ更新する。更に、ＬＳは、ＵＴがＣ会社の前に在圏していたエリアであるＢ空港を管轄するＳＭＳ１に対して、状態転送要求を送信する（ステップ２１０５）。
【００８８】
状態転送要求を受信したＳＭＳ１は、ＵＴに対応するユーザ状態情報を消去し、ＬＳに対して、状態転送応答を送信する（ステップ２１０６）。この状態転送応答には、ＵＴに対応するユーザ状態情報とトリガ情報とが含まれている。
【００８９】
状態転送要求を受信したＬＳは、当該状態転送応答に含まれる、ＵＴに対応するユーザ状態情報とトリガ情報とを管理する。更に、ＬＳは、ＵＴの位置情報をＳＭＳ１からＳＭＳ２へ更新し、ＳＭＳ２に対して位置登録応答を送信する（ステップ２１０７）。この位置登録応答には、ＵＴに対応するユーザ状態情報とトリガ情報とが含まれている。
【００９０】
位置登録応答を受信したＳＭＳ２は、当該ＵＴに対応するユーザ状態情報とトリガ情報とを管理する。この際、ＳＭＳ２は、ＵＴに対応するトリガ情報のうち、自身が管轄するエリアにおいて有効なトリガ情報についてのみ、分析の対象とし、他のトリガ情報については分析の対象とせずに保存する。更に、ＳＭＳ２は、位置登録応答をＵＴへ送信する（ステップ２１０８）。位置登録応答を受信したＵＴは、その後、ＳＭＳ２へ状態通知を送信する（ステップ２１０９）。
【００９１】
また、ＵＴが新たなサービスに加入し、新規のトリガ情報が必要になった場合には、その新たなサービスのアプリケーションを実行するアプリケーションサーバ（ＡＳ）は、ＬＳに対してトリガ設定要求を送信する（ステップ２１１０）。トリガ設定要求を受信したＬＳは、当該トリガ設定要求を、更に、ＵＴが在圏するエリアであるＣ会社を管轄するＳＭＳ２へ送信する（ステップ２１１１）。
【００９２】
トリガ設定要求を受信したＳＭＳ２は、ＵＴに対応する新たなトリガ情報を設定する。この場合、ＳＭＳ２が管理するＵＴに対応するトリガ情報は、ＳＭＳ１から送信されたトリガ情報と、新たに設定したトリガ情報となる。更に、ＳＭＳ２は、ＵＴに対応するトリガ情報のうち、自身が管轄するエリアにおいて有効なトリガ情報についてのみ、分析の対象とし、他のトリガ情報については分析の対象とせずに保存する。ＳＭＳ２は、新たなトリガ情報を設定した後、ＡＳに対して、トリガ設定応答を送信する（ステップ２１１２）。トリガ設定応答を受信したＬＳは、当該トリガ設定応答を、更に、ＬＳへ送信する（ステップ２１１３）。
【００９３】
図２３は、ユーザ状態管理処理の第３の例を示すシーケンス図である。同図において、状態管理サーバ１（ＳＭＳ１）は、Ａ駅のエリア、Ｂ駅のエリア及びＣ駅のエリアを管轄するものである。
【００９４】
また、アプリケーションサーバ３（ＡＳ３）は、状態通知用のトリガ情報の設定をＳＭＳ１に要求しており、ＳＭＳ１は、この要求に応じて図２４に示すような状態通知用のトリガ情報を設定している。図２４に示す状態設定用のトリガ情報において、「＊」はいわゆるワイルドカードであり、このトリガ情報は、ＵＴがＳＭＳ１が管轄するあらゆるエリアに在圏し、且つ、ＵＴの位置が更新された場合に、ＳＭＳ１からＡＳ３へその旨のトリガ通知が送信されるようにするためのものである。
【００９５】
ＳＭＳ１は、例えば図２５に示すように、状態通知用のトリガ情報と他のトリガ情報との双方を管理している。図２５において、最初のトリガ情報は、ＵＴがＳＭＳ１が管轄するエリアであるＡ駅に在圏する場合に、ＳＭＳ１からＡＳ１へトリガ通知が送信されることにより、当該ＡＳ１におけるアプリケーションの実行を可能とするためのものである。
【００９６】
また、ＳＭＳ１は、図２６に示すようなユーザ共通状態情報を管理している。ユーザ共通状態情報は、ＳＭＳが管轄するエリアに在圏する全てのユーザに共通の情報であり、図２６では、「現在時刻」及び「天気」の情報が含まれている。なお、「天気」のようにＳＭＳ１が管轄するエリアを更に細分化したエリア毎に、情報を管理することが可能な場合には、例えば、「Ａ駅周辺の天気」等の情報が含まれるようにしても良い。
【００９７】
また、ＳＭＳ１は、図２７に示すようなユーザ分析情報を管理している。このユーザ分析情報は、ＳＭＳ１によるユーザ分析に用いられるものである。図２７において、最初のユーザ分析情報は、ＵＴがＢ駅に在圏する場合に、ＳＭＳ１からＡＳ１へユーザ通知が送信されることにより、当該ＡＳ１におけるアプリケーションの実行を可能とするためのものである。また、２番目のユーザ分析情報は、天気が雨であり、且つ、ＵＴがＣ空港に在圏する場合に、ＳＭＳ１からＡＳ２へユーザ通知が送信されることにより、当該ＡＳ２におけるアプリケーションの実行を可能とするためのものである。この２番目のユーザ分析情報は、例えば雨の日にＣ空港にいるユーザに対して、優先的にタクシーを配車するサービス等に活用することができる。なお、ユーザ分析情報を満たすユーザが所定数以上存在する場合に、ＳＭＳ１からＡＳ２へユーザ通知が送信されるようにしても良い。
【００９８】
また、図２３において、課金サーバ（ＣＳ）は、ＡＳ２によるサービスのアプリケーションの実行に応じて、ＵＴのユーザに対して課金処理を行う。
【００９９】
図２３において、ユーザ端末（ＵＴ）は、ＳＭＳ１が管轄するエリアであるＡ駅に在圏しており、当該ＳＭＳ１へ状態通知を送信している（ステップ２２０１）。ＳＭＳ１は、受信した状態通知に応じた最新のＵＴに対応するユーザ状態情報に基づいて、トリガ分析を行う。なお、同時にユーザ分析が行われても良い。トリガ分析の結果、ＵＴに対応するユーザの状態が所定のユーザ条件を満たしている場合、アプリケーションサーバ１（ＡＳ１）に対して、トリガ通知を送信する（ステップ２２０２）。ＡＳ１は、このトリガ通知に応じて、ＵＴに対して、サービスのアプリケーションを実行する。
【０１００】
また、ＵＴは、Ａ駅からＢ駅へ移動すると、ＳＭＳ１に対して状態通知を送信する（ステップ２２０３）。状態通知を受信したＳＭＳ１は、受信した状態通知に応じた最新のＵＴに対応するユーザ状態情報に基づいて、ユーザ分析を行う。なお、同時にトリガ分析が行われても良い。
【０１０１】
具体的には、ＵＴは、図２８に示すようなユーザ分析可否情報に基づいて、自らが管轄するエリアにおいてユーザ分析が許可されているか否かを判定する。このユーザ分析可否情報は、ユーザ状態情報やトリガ情報とともに、ＵＴの移動に伴ってＳＭＳ間を転送される。この場合、ＳＭＳは、自らが管轄するエリアに対応するユーザ分析可否情報のみをユーザ分析が許可されているか否かを判定に用いるようにしても良い。ユーザ分析可否情報は、例えばユーザによって設定される。あるいは、ＳＭＳが他のサーバにアクセスして取得した所定の情報に基づいて設定する。
なお、図２８は、エリア毎にユーザ分析の可否が設定されているが、サービスの種別毎や、サービスのアプリケーションを実行するアプリケーションサーバ毎に、ユーザ分析の可否が設定されるようにしても良い。また、全てのエリア共通にユーザ分析の可否が設定されていても良い。
【０１０２】
ユーザ分析が許可されている場合、ＳＭＳ１は、ＵＴに対応するユーザ状態情報に基づいて、当該ＵＴのユーザが図２７に示すユーザ分析情報に示すユーザ条件を満たすか否かを判定する。ユーザ条件を満たす場合には、ＳＭＳ１は、ＡＳ（ここではＡＳ２）に対して、ＵＴのユーザの識別情報を含んだユーザ通知を送信する（ステップ２２０４）。
【０１０３】
ＡＳ２は、受信したユーザ通知に対応するＵＴに対して、自らが提供可能なサービスを提案する（ステップ２２０５）。サービス提案の送信先は、ユーザ通知に含まれるユーザの識別情報、例えば、ＵＴのメールアドレス、インスタントメッセージのアドレス、電話番号等により特定される。例えば、ＡＳ２がウェブサービスのアプリケーションを実行する場合には、当該ウェブサービスの宣伝とＵＲＬが設定されたインスタントメッセージをＵＴへ送信する。
【０１０４】
例えば、ＵＴの画面にサービス提案が表示され、ユーザが何れかのサービスを選択する操作を行った場合、ＵＴは、その選択に応じたサービス要求をＡＳ２へ送信する（ステップ２２０６）。ＡＳ２は、ＵＴから要求されたサービスのアプリケーションを実行するとともに、ＣＳに対して課金要求を送信する（ステップ２２０７）。ＣＳは、この要求に応じてＵＴのユーザに対応する課金レコードを生成、保存し、課金応答をＡＳ２へ返す（ステップ２２０８）。
【０１０５】
また、ＵＴは、Ｂ駅からＣ駅へ移動すると、ＳＭＳ１に対して状態通知を送信する（ステップ２２０９）。ＳＭＳ１は、受信した状態通知に応じた最新のＵＴに対応するユーザ状態情報に基づいて、トリガ分析を行う。ここで、ＵＴのユーザの状態が図２４に示す状態設定用のトリガ情報に対応する条件を満たしている場合、ＳＭＳ１は、ＡＳ３へその旨のトリガ通知（状態通知）を送信する（ステップ２２１０）。状態通知を受信したＡＳ３は、ＳＭＳ１へ状態要求を送信し（ステップ２２１１）、ＳＭＳ１は、ＵＴに対応するユーザ状態情報を含んだ状態応答をＡＳ３へ返す（ステップ２２１２）。
【０１０６】
このように、本実施形態のサービス提供システムでは、サービスエリアを複数に分割したエリア２０毎に、当該エリア２０に在圏するユーザ端末３０に対応するユーザの状態情報を管理する状態管理サーバ１０が設置されている。従って、個々の状態管理サーバ１０は、自らが管轄するエリア２０に在圏するユーザ端末３０に対応するユーザの状態情報のみを管理すれば良い。従って、サービスエリアが大規模で多数のユーザが存在し、更には、１人のユーザについての多数の状態情報を管理する場合においても各状態管理サーバ１０の負荷が軽減される。また、各状態管理サーバ１０は、自らが管轄するエリア２０の近傍に分散して設置されるため、ユーザ端末３０から状態管理サーバ１０までの距離を短くすることが可能となり、通信ネットワークに及ぼされる負荷も軽減される。
【０１０７】
また、ユーザ端末３０がエリア２０を跨って移動した場合には、移動前のユーザ端末３０が在圏するエリア２０を管轄する状態管理サーバ１０から移動後のユーザ端末３０が在圏するエリア２０を管轄する状態管理サーバ１０へ当該ユーザ端末３０に対応するユーザ状態情報とトリガ情報とが通知される。このため、サービス提供システムは、ユーザ端末の移動後においても、ユーザの状態に応じたサービスを継続して提供することが可能となる。
【０１０８】
また、状態管理サーバ１０は、トリガ情報について、自らが管轄するエリア２０において有効なものを特定し、ユーザの状態がその特定したトリガ情報に対応する所定のユーザ条件を満たす場合に、アプリケーションサーバ４０に対してアプリケーションの実行を要求するトリガ通知を送信している。このため、ユーザの状態に応じた適切なサービスの提供が可能となるとともに、状態管理サーバ１０における判定処理を必要最小限に抑えることができ、更なる負荷の軽減を図ることができる。
【０１０９】
また、アプリケーションサーバ４０は、ユーザ端末３０に対して、サービスを提案しており、ユーザは自ら要求したサービスだけでなく、様々なサービスの提供を受ける機会が増え、利便性を向上させることができる。
【０１１０】
また、課金サーバがユーザ端末３０に対して提供するサービスに対応する課金を行うことにより、商用サービスに適したサービス提供システムの構築が可能となる。
【０１１１】
なお、上述した実施形態では、ユーザ端末３０の位置を特定するための情報として、状態管理サーバ１０のアドレスが用いられているが、エリア２０の識別情報が用いられるようにしても良い。この場合、状態管理サーバ１０のアドレスとエリア２０の識別情報とは、対応付けられて管理される。
（付記１）
通信ネットワークを利用し、サービスエリアに在圏するユーザ端末に対して該ユーザの状態に応じたサービスを提供するサービス提供システムにおいて、
前記サービスエリアを複数に分割した分割エリア毎に設置され、管轄する前記分割エリアに在圏するユーザ端末に対応するユーザの状態情報を管理する状態管理サーバと、
前記ユーザ端末に対して提供されるサービスのアプリケーションを実行するアプリケーションサーバと、
を備えることを特徴とするサービス提供システム。
（付記２）
請求項１に記載のサービス提供システムにおいて、
前記ユーザ端末が前記分割エリアを跨って移動した場合に、
移動前の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバは、移動後の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバに対して、前記分割エリアを跨って移動したユーザ端末に対応する前記ユーザの状態情報を通知することを特徴とするサービス提供システム。
（付記３）
請求項１又は２に記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアの近傍に設置されることを特徴とするサービス提供システム。
（付記４）
請求項１乃至３の何れかに記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの識別情報を前記アプリケーションサーバへ通知し、
前記アプリケーションサーバは、前記ユーザの識別情報に対応するユーザ端末に対して提供されるサービスのアプリケーションを実行することを特徴とするサービス提供システム。
（付記５）
請求項４に記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態が所定のユーザ条件を満たす場合に、該ユーザの識別情報を前記アプリケーションサーバへ通知することを特徴とするサービス提供システム。
（付記６）
請求項５に記載のサービス提供システムにおいて、
前記ユーザ端末が前記分割エリアを跨って移動した場合に、
移動前の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバは、移動後の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバに対して、前記分割エリアを跨って移動したユーザ端末に対応する前記所定のユーザ条件を通知することを特徴とするサービス提供システム。
（付記７）
請求項５又は６に記載のサービス提供システムにおいて、
前記状態管理サーバは、前記所定のユーザ条件のうち、自らが管轄する分割エリアにおいて有効なものを特定し、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態がその特定した所定のユーザ条件を満たす場合に、該ユーザの識別情報を前記アプリケーションサーバへ通知することを特徴とするサービス提供システム。
（付記８）
請求項１乃至７に記載のサービス提供システムにおいて、
前記アプリケーションサーバは、前記状態管理サーバから通知されるユーザの識別情報に対応するユーザ端末に対して、サービスを提案することを特徴とするサービス提供システム。
（付記９）
請求項８に記載のサービス提供システムにおいて、
前記ユーザ端末は、前記アプリケーションサーバによって提案されたサービスの何れかを該アプリケーションサーバへ要求することを特徴とするサービス提供システム。
（付記１０）
請求項１乃至９の何れかに記載のサービス提供システムにおいて、
前記ユーザ端末に対して提供するサービスに対応する課金を行う課金サーバを備えることを特徴とするサービス提供システム。
（付記１１）
請求項５に記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態が所定のユーザ条件を満たすか否かの判定が許可されている場合にのみ、該判定を行うことを特徴とするサービス提供システム。
（付記１２）
請求項８又は９に記載のサービス提供システムにおいて、
前記ユーザ端末は、前記アプリケーションサーバによるサービスの提案を拒否することを特徴とするサービス提供システム。
（付記１３）
請求項１乃至１２の何れかに記載のサービス提供システムにおいて、
前記状態管理サーバ間の通信を仲介する仲介サーバを備え、
前記仲介サーバは、前記ユーザ端末に対応する前記ユーザの状態情報を管理することを特徴とするサービス提供システム。
（付記１４）
請求項１乃至１３の何れかに記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態情報を前記アプリケーションサーバへ通知することを特徴とするサービス提供システム。
（付記１５）
請求項１乃至１４の何れかに記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアに在圏する複数のユーザ端末に対応するユーザに共通の状態情報を管理することを特徴とするサービス提供システム。
【０１１２】
【発明の効果】
本発明によれば、大規模なサービスエリアでも、当該サービスエリアに在圏するユーザ端末に対して当該ユーザの状態に応じた適切なサービスを提供することが可能となる。
【図面の簡単な説明】
【図１】サービス提供システムの構成例を示す図である。
【図２】ユーザ端末移動時におけるサービス提供システムの処理を示す図である。
【図３】図２における新在圏状態管理サーバの処理を示すフローチャートである。
【図４】図２における旧在圏状態管理サーバの処理を示すフローチャートである。
【図５】図２における新在圏状態管理サーバの分割アクティベーション処理を示すフローチャートである。
【図６】図２における旧在圏状態管理サーバの分割アクティベーションが行われたトリガに対する処理を示すフローチャートである。
【図７】仲介サーバを有するサービス提供システムの処理を示す図である。
【図８】図７における新在圏状態管理サーバの処理を示すフローチャートである。
【図９】図７における仲介サーバの処理を示すフローチャートである。
【図１０】図７における旧在圏状態管理サーバの処理を示すフローチャートである。
【図１１】図７における仲介サーバの分割アクティベーション処理を示すフローチャートである。
【図１２】ユーザ状態更新時におけるサービス提供システムの処理を示す図である。
【図１３】図１２における新在圏状態管理サーバの処理を示すフローチャートである。
【図１４】図１２におけるトリガ通知を受けたアプリケーションサーバの処理を示すフローチャートである。
【図１５】図１２におけるユーザ通知を受けたアプリケーションサーバの処理を示すフローチャートである。
【図１６】新規トリガ設定時におけるサービス提供システムの処理を示す図である。
【図１７】図１６におけるアプリケーションサーバの処理を示すフローチャートである。
【図１８】図１６におけるロケーションサーバの処理を示すフローチャートである。
【図１９】ユーザ状態管理処理の第１の例を示すシーケンス図である。
【図２０】図１９に示す処理において用いられるトリガ情報の第１の例を示す図である。
【図２１】図１９に示す処理において用いられるトリガ情報の第２の例を示す図である。
【図２２】ユーザ状態管理処理の第２の例を示すシーケンス図である。
【図２３】ユーザ状態管理処理の第３の例を示すシーケンス図である。
【図２４】図２３に示す処理において用いられる状態通知トリガの一例を示す図である。
【図２５】図２３に示す処理において用いられるアクティベートされたトリガ情報の一例を示す図である。
【図２６】図２３に示す処理において用いられるユーザ共通状態情報の一例を示す図である。
【図２７】図２３に示す処理において用いられるユーザ分析情報の一例を示す図である。
【図２８】図２３に示す処理において用いられるユーザ分析可否情報の一例を示す図である。
【符号の説明】
１０状態管理サーバ
２０エリア
３０ユーザ端末
４０アプリケーションサーバ
５０ロケーションサーバ
６０ネットワーク
７０仲介サーバ

Claims

通信ネットワークを利用し、サービスエリアに在圏するユーザ端末に対して該ユーザの状態に応じたサービスを提供するサービス提供システムにおいて、
前記サービスエリアを複数に分割した分割エリア毎に設置され、管轄する前記分割エリアに在圏するユーザ端末に対応するユーザの状態情報を管理する状態管理サーバと、
前記ユーザ端末に対して提供されるサービスのアプリケーションを実行するアプリケーションサーバと、
を備えることを特徴とするサービス提供システム。
請求項１に記載のサービス提供システムにおいて、
前記ユーザ端末が前記分割エリアを跨って移動した場合に、
移動前の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバは、移動後の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバに対して、前記分割エリアを跨って移動したユーザ端末に対応する前記ユーザの状態情報を通知することを特徴とするサービス提供システム。
請求項１又は２に記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアの近傍に設置されることを特徴とするサービス提供システム。
請求項１乃至３の何れかに記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの識別情報を前記アプリケーションサーバへ通知し、
前記アプリケーションサーバは、前記ユーザの識別情報に対応するユーザ端末に対して提供されるサービスのアプリケーションを実行することを特徴とするサービス提供システム。
請求項４に記載のサービス提供システムにおいて、
前記状態管理サーバは、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態が所定のユーザ条件を満たす場合に、該ユーザの識別情報を前記アプリケーションサーバへ通知することを特徴とするサービス提供システム。
請求項５に記載のサービス提供システムにおいて、
前記ユーザ端末が前記分割エリアを跨って移動した場合に、
移動前の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバは、移動後の前記ユーザ端末が在圏する分割エリアを管轄する状態管理サーバに対して、前記分割エリアを跨って移動したユーザ端末に対応する前記所定のユーザ条件を通知することを特徴とするサービス提供システム。
請求項５又は６に記載のサービス提供システムにおいて、
前記状態管理サーバは、前記所定のユーザ条件のうち、自らが管轄する分割エリアにおいて有効なものを特定し、自らが管轄する分割エリアに在圏するユーザ端末に対応するユーザの状態がその特定した所定のユーザ条件を満たす場合に、該ユーザの識別情報を前記アプリケーションサーバへ通知することを特徴とするサービス提供システム。
請求項１乃至７に記載のサービス提供システムにおいて、
前記アプリケーションサーバは、前記状態管理サーバから通知されるユーザの識別情報に対応するユーザ端末に対して、サービスを提案することを特徴とするサービス提供システム。
請求項８に記載のサービス提供システムにおいて、
前記ユーザ端末は、前記アプリケーションサーバによって提案されたサービスの何れかを該アプリケーションサーバへ要求することを特徴とするサービス提供システム。
請求項１乃至９の何れかに記載のサービス提供システムにおいて、
前記ユーザ端末に対して提供するサービスに対応する課金を行う課金サーバを備えることを特徴とするサービス提供システム。