(57)【要約】本発明は、イベントオリジネータ（ｅｖｅｎｔ  ｏｒｉｇｉｎａｔｏｒ）であるサービスプロバイダが加入者リストを別途に管理する必要なく、中継プラットホームでイベントを１つの経路で集積してプッシュできるようにし、サービスプロバイダからプッシュされるイベントなどを中継プラットホームで管理される加入者に３Ａ（Ａｎｙｔｉｍｅ、Ａｎｙｗｈｅｒｅ、Ａｎｙｄｅｖｉｃｅ）基盤で提供できるように統合管理することにより、加入者は自身のイベントプロフィールを一括して管理することができ、サービスプロバイダはイベントプッシュサービスの加入権限を一貫したインターフェースで提供することができるユビキタス（ｕｂｉｑｕｉｔｏｕｓ）通知（ｎｏｔｉｆｉｃａｔｉｏｎ）方法およびシステムに関する。本発明に係るユビキタス通知方法は、サービスに連係したイベントがプッシュされるステップと、プッシュされたイベントに応答してイベントメッセージを送信するステップとを含む。
2010527480.tif 000002
【特許請求の範囲】
【請求項１】
サービスに連係したイベントがプッシュされるステップと、
前記プッシュされたイベントに応答してイベントメッセージを送信するステップと、
を含むことを特徴とするユビキタス通知方法。
【請求項２】
前記イベントメッセージを送信するステップは、
各ユビキタス加入者端末の多様な形態を識別し、該当端末がサポートする通信方式で前記イベントメッセージを送信することを特徴とする請求項１に記載のユビキタス通知方法。
【請求項３】
前記通信方式は、ＴＣＰ／ＩＰ、ＳＭＳ、ＵＤＰ、Ｐ２Ｐのうちの１つ以上の方式を含むことを特徴とする請求項２に記載のユビキタス通知方法。
【請求項４】
前記イベントがプッシュされるステップの前に、サービスプロバイダから提供されたサービスに連係した少なくとも１つのチャネルとＵＥＤファイルを提供者情報として登録するステップをさらに含み、
前記イベントがプッシュされるステップにおいて、前記ＵＥＤファイルで指定されたデータフォーマットで前記イベントがプッシュされることを特徴とする請求項１に記載のユビキタス通知方法。
【請求項５】
前記ＵＥＤファイルは、ＸＭＬを用いて構成されたことを特徴とする請求項４に記載のユビキタス通知方法。
【請求項６】
前記イベントメッセージを送信するステップは、
各加入者端末の多様な形態を識別して、該当端末がサポートするデータタイプのバイナリプロトコルによるデータに前記イベントメッセージを含ませて送信することを特徴とする請求項１に記載のユビキタス通知方法。
【請求項７】
前記イベントメッセージを送信するステップは、
各加入者端末の多様な形態を識別せずに、ＸＭＬ形態のデータに前記イベントメッセージを含ませて送信することを特徴とする請求項１に記載のユビキタス通知方法。
【請求項８】
前記イベントがプッシュされるステップの前または後に、
ユーザ端末からの要請に応じて前記サービスに連係した少なくとも１つのチャネルリストを前記ユーザ端末に送信するステップと、
前記チャネルリストのうちからユーザによって選択された少なくとも１つのチャネルに対する選択情報とユーザ端末に対応するユーザ情報を加入者情報として登録するステップと、
をさらに含み、
前記イベントメッセージを送信するステップにおいて、前記加入者情報による該当チャネルに対する前記イベントメッセージを送信することを特徴とする請求項１に記載のユビキタス通知方法。
【請求項９】
前記加入者情報を登録するステップの後に、
前記ユーザ端末の要請に応じてユーザとのインターフェースのためのＵＥＤファイルを前記ユーザ端末に送信するステップをさらに含むことを特徴とする請求項８に記載のユビキタス通知方法。
【請求項１０】
前記ＵＥＤファイルを送信するステップにおいて、
前記ＵＥＤファイルで指定されたデータタイプのバイナリプロトコルによるデータに前記イベントメッセージを含ませて送信することを特徴とする請求項９に記載のユビキタス通知方法。
【請求項１１】
前記ＵＥＤファイルにはメッセージ表示形式を指定するテンプレートが含まれ、
前記該当チャネルに対するイベントメッセージは、前記ユーザ端末上で前記ＵＥＤファイルの解析することにより前記テンプレートに基づいた形態に変換されることを特徴とする請求項９に記載のユビキタス通知方法。
【請求項１２】
前記イベントがプッシュされるステップの後に、各サービスに対してイベントが属するドメインを示すチャネル単位で前記プッシュされたイベントを管理するステップをさらに含み、
前記イベントメッセージを送信するステップにおいて、前記チャネル単位で前記イベントメッセージを送信することを特徴とする請求項１に記載のユビキタス通知方法。
【請求項１３】
前記チャネルに少なくとも１つのサブチャネルが含まれた場合に、前記イベントメッセージを前記少なくとも１つのサブチャネルに加入した端末に送信するステップをさらに含むことを特徴とする請求項１２に記載のユビキタス通知方法。
【請求項１４】
前記プッシュされたイベントを管理するステップにおいて、
前記チャネルに予め定められた識別子が含まれたユーザＩＤが含まれている場合に、前記ユーザＩＤに対応するユーザ端末のみに前記イベントメッセージが送信されるように前記プッシュされたイベントを管理し、前記ユーザＩＤに対応するユーザ端末のみに前記イベントメッセージが送信されないように前記プッシュされたイベントを管理することを特徴とする請求項１２に記載のユビキタス通知方法。
【請求項１５】
端末でイベントを提供する方法において、
プッシュサービスの加入要請を送信するステップと、
前記加入要請に応じてサービスに連係した少なくとも１つのチャネルリストを受信するステップと、
端末に対応するユーザ情報と前記チャネルリストのうちからユーザによって選択された少なくとも１つのチャネルに対する選択情報を含む加入者情報を送信するステップと、
前記加入者情報に対応する該当チャネルに対するイベントメッセージを受信するステップと、
を含むことを特徴とするイベント提供方法。
【請求項１６】
前記加入者情報を送信するステップの後に、
ユーザとのインターフェースのためのＵＥＤファイル要請を送信するステップと、
前記ＵＥＤファイル要請に応じてＵＥＤファイルを受信するステップと、
を含むことを特徴とする請求項１５に記載のイベント提供方法。
【請求項１７】
前記イベントメッセージを受信するステップにおいて、
前記イベントメッセージを前記ＵＥＤファイルで指定されたデータタイプのバイナリプロトコルによるデータ形態で受信することを特徴とする請求項１６に記載のイベント提供方法。
【請求項１８】
前記ＵＥＤファイルを受信するステップの後に、
前記ＵＥＤファイルにメッセージ表示形式を指定するテンプレートが含まれている場合、前記ＵＥＤファイルを解析して前記チャネルに対するイベントメッセージを前記テンプレートに基づいて変換するステップをさらに含むことを特徴とする請求項１６に記載のイベント提供方法。
【請求項１９】
請求項１乃至１８のうちのいずれか一項の方法を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項２０】
イベントを提供する端末において、
イベントプッシュサービス加入要請によってサービスに連係した少なくとも１つのチャネルリストを受信し、前記チャネルリストのうちからユーザによって選択された少なくとも１つのチャネルに対する選択情報とユーザ端末に対応するユーザ情報を含む加入者情報を生成して送信し、前記選択情報に対応する該当チャネルに対するイベントメッセージを受信する通知クライアントと、
前記通知クライアントにより受信された前記イベントメッセージを表示するユーザインターフェースと、
を含むことを特徴とする端末。
【請求項２１】
前記端末は、ユーザとのインターフェースのためのＵＥＤファイルが格納されるメモリをさらに含み、
前記通知クライアントは、前記ＵＥＤファイルの要請によって前記ＵＥＤファイルを受信することを特徴とする請求項２０に記載の端末。
【請求項２２】
前記通知クライアントは、前記イベントメッセージを前記ＵＥＤファイルで指定されたデータタイプのバイナリプロトコルによるデータ形態で受信することを特徴とする請求項２１に記載の端末。
【請求項２３】
前記ＵＥＤファイルを解析してメッセージ表示形式を指定するテンプレートを抽出して解釈するテンプレートパーサをさらに含み、
前記ユーザインターフェースは、前記イベントメッセージを前記テンプレートに基づいた形態で表示することを特徴とする請求項２１に記載の端末。
【請求項２４】
サービスに連係したイベントがプッシュされるイベントゲートウェイと、
前記プッシュされたイベントに応答してイベントメッセージを送信する少なくとも１つのブローカと、
を含むことを特徴とするユビキタス通知システム。
【請求項２５】
前記少なくとも１つのブローカは、
各加入者端末の多様な形態を識別し、該当端末がサポートする通信方式で前記イベントメッセージを送信することを特徴とする請求項２４に記載のユビキタス通知システム。
【請求項２６】
前記少なくとも１つのブローカは、
各加入者端末の多様な形態を識別し、該当端末がサポートするデータタイプのバイナリプロトコルによるデータに前記イベントメッセージを含ませて送信することを特徴とする請求項２４に記載のユビキタス通知システム。
【請求項２７】
前記サービスに連係した少なくとも１つのチャネルとサービスプロバイダにより提供されたＵＥＤファイルを提供者情報としてデータベースに登録するディレクトリ管理部をさらに含み、
前記イベントゲートウェイは、前記データベースを参照して前記ＵＥＤファイルで指定されたデータフォーマットで前記イベントがプッシュされることを特徴とする請求項２４に記載のユビキタス通知システム。
【請求項２８】
前記ディレクトリ管理部は、
前記ユーザ端末の要請に応じてユーザとのインターフェースのためのＵＥＤファイルを前記ユーザ端末に送信することを特徴とする請求項２７に記載のユビキタス通知システム。
【請求項２９】
前記少なくとも１つのブローカは、
前記ＵＥＤファイルで指定されたデータタイプのバイナリプロトコルによるデータに前記イベントメッセージを含ませて送信することを特徴とする請求項２８に記載のユビキタス通知システム。
【請求項３０】
前記ディレクトリ管理部は、前記プッシュされたイベントを各サービスに対してイベントが属するドメインを示すチャネル単位で管理し、
前記少なくとも１つのブローカは、前記チャネル単位で前記イベントメッセージを送信することを特徴とする請求項２７に記載のユビキタス通知システム。
【請求項３１】
前記少なくとも１つのブローカは、
前記チャネルに少なくとも１つのサブチャネルが含まれた場合に、前記イベントメッセージを前記少なくとも１つのサブチャネルに加入した端末に送信することを特徴とする請求項３０に記載のユビキタス通知システム。
【請求項３２】
前記少なくとも１つのブローカは、
前記チャネルに予め定められた識別子が含まれたユーザＩＤが含まれている場合に、前記ユーザＩＤに対応するユーザ端末のみに前記イベントメッセージを送信し、前記ユーザＩＤに対応するユーザ端末のみに前記イベントメッセージを送信しないことを特徴とする請求項３０に記載のユビキタス通知システム。
【請求項３３】
前記少なくとも１つのブローカは、
各加入者端末の多様な形態を識別せずに、ＸＭＬ形態のデータに前記イベントメッセージを含ませて送信することを特徴とする請求項２４に記載のユビキタス通知システム。
【請求項３４】
ユーザ端末からの要請に応じて前記サービスに連係した少なくとも１つのチャネルリストを前記ユーザ端末に送信し、前記ユーザ端末に対するユーザ情報と前記チャネルリストのうちからユーザによって選択された少なくとも１つのチャネルに対する選択情報を加入者情報としてデータベースに登録する加入ゲートウェイをさらに含み、
前記少なくとも１つのブローカは、前記データベースを参照して前記加入者情報による該当チャネルに対するイベントメッセージを送信することを特徴とする請求項２４に記載のユビキタス通知システム。
【請求項３５】
サービスプロバイダと多様な形態のユビキタス端末との間でユビキタス通知を提供するシステムにおいて、
前記サービスプロバイダからプッシュされるイベントを収集するコネクション手段と、
前記コネクション手段により収集される複数のイベントを集積して統合管理し、前記イベントのうちからプッシュされようとする少なくとも１つのイベント受信に対する加入を登録した少なくとも１つの端末に、該当端末でサポートされるデータタイプのイベントメッセージを前記該当端末で支援される通信方式で送信するプッシュエンジンと、
を含むことを特徴とするユビキタス通知システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、プッシュ型（ｐｕｓｈ  ｔｙｐｅ）イベントを提供する通知方法およびシステムに関し、より詳細には、３Ａ（Ａｎｙｔｉｍｅ、Ａｎｙｗｈｅｒｅ、Ａｎｙｄｅｖｉｃｅ）基盤のプッシュ型イベントを提供することができるユビキタス通知方法およびシステムに関する。
【背景技術】
【０００２】
図１は、従来のイベント通知方法を説明するための図である。図１を参照すれば、デスクトップコンピュータ、ノート型コンピュータ、携帯電話機、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）などのユーザ端末は、インターネットや公衆網などのネットワークを介して、サービスプロバイダ（ｐｒｏｖｉｄｅｒ）であるアプリケーションサーバから提供される多様な情報にアクセスすることができる。このとき、ユーザは、自身の端末を介してアプリケーションサーバが運営するホームページ（ｗｅｂｓｉｔｅ）、ブログなどに加入し、アプリケーションサーバによって随時アップデートされる多量の新たな情報のうちから必要なイベント情報の通知を受けられるようにアプリケーションサーバに登録することができる。
【０００３】
しかしながら、上述したようなイベント通知を受けるために、ユーザは、各サービスプロバイダのホームページ、ブログなどのアプリケーションに接続し、それぞれ個別にイベント通知の受信を登録しなければならないため、登録の変更、追加、削除など、イベントに関するプロフィールを一括して管理することが難しいという問題点がある。
【０００４】
また、サービスプロバイダは、イベント通知に関する各ユーザの登録の変更、追加、削除などをそれぞれ個別に処理して１つ１つ加入関連権限を付与しなければならないため、イベント通知関連加入権限を一貫したインターフェースで提供できないという問題点がある。
【０００５】
上述のように、既存のイベントプッシュサービスの大部分は、固定したコンピュータを用いて高速のインターネットラインを介して提供される形態のイベントプッシュサービスであったが、最近ではユビキタス（Ｕｂｉｑｕｉｔｏｕｓ）時代の到来により、このようなサービスは多様なユビキタスデバイスで提供されるように発展している。ユビキタス化したサービスは、パーソナルコンピュータ、携帯電話機、ＰＤＡだけではなく、無線インターネットや携帯インターネットが支援される端末や、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）に接続した冷蔵庫、電子レンジ、電子炊飯器、自動販売機、メモリスティック（登録商標）などのより多様なデバイスにより、いつどこででもアクセスが可能なサービスである。ユビキタスサービスは、顧客がサービスにアクセスする形態というよりは、次第にサービスが顧客にアクセスするプロアクティブ（ｐｒｏａｃｔｉｖｅ）形態のサービスであるといえる。
【０００６】
したがって、ユビキタス時代に合わせ、インターネットなどの各アプリケーションサービスで生じるイベントを統合集積し、顧客個々人に容易かつ効率的に伝達することができるプッシュ型インフラが必要となり、アプリケーションサーバで各サービスに多様な形態のユビキタスデバイスを支援することは現実的に難しいため、プッシュ型イベントをデバイスに適合するように適切に処理することができる中継プラットホームが求められている。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
本発明は、上述した問題点を解決するためのものであって、プッシュ型イベントの提供を受ける加入者は自身のイベントプロフィールを一括して管理することができ、サービスプロバイダはイベントプッシュサービスの加入権限を一貫したインターフェースで提供できるようにするために、加入者リストを中継プラットホームで管理し、サービスプロバイダから提供される各サービスのイベントを１つの経路を介して集積して統合管理し、加入者に３Ａ基盤でいつどこででもデバイスに関係なく提供することができる、ユビキタス通知方法およびシステムを提供することにある。
【０００８】
本発明の他の目的は、ユビキタスユーザ端末に対応してイベントを通知することができるように適切なブローカコネクション（ｂｒｏｋｅｒ  ｃｏｎｎｅｃｔｉｏｎ）を運営し、サービスプロバイダがサービス種類、イベント種類、およびイベントのフォーマットと意味などを登録するディレクトリを介してどのような形態のユーザ端末であってもこれを参照し、該当端末に適合した方式でイベントプッシュサービスを提供することができる、ユビキタス通知方法およびシステムを提供することにある。
【０００９】
本発明のさらに他の目的は、サービスプロバイダが提供しようとするすべての形態のイベントをその量に関係なくユーザに提供することができるように、中継プラットホームに集積されて統合管理されるイベントをサービス別またはイベント別に分散処理して並列処理することによってサーバの超大容量トランザクションを処理する、ユビキタス通知方法およびシステムを提供することにある。
【００１０】
本発明のさらに他の目的は、上述のような技術を既に提供されているレガシー（ｌｅｇａｃｙ）サービスの小さい変更によって実現できるようにすることで、ユビキタスデバイスに適合した統合型プッシュサービスが提供されるようにし、ユーザがサービスにより密着することができるユビキタス連結環（ｕｂｉｑｕｉｔｏｕｓ  ｃｏｎｎｅｃｔｉｏｎ  ｒｉｎｇ）をユーザに提供することによってサービスの発展にも寄与することができる、ユビキタス通知方法およびシステムを提供することにある。
【課題を解決するための手段】
【００１１】
まず、上述のような本発明の目的を達成するために、本発明の一態様に係るユビキタス通知方法は、サービスに連係したイベントがプッシュされるステップと、前記プッシュされたイベントに応答してイベントメッセージを送信するステップとを含む。前記イベントメッセージを送信するステップは、各ユビキタス加入者端末の多様な形態を識別して、該当端末がサポートする通信方式で前記イベントメッセージを送信する。
【００１２】
なお、前記通信方式には、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＳＭＳ(Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ)、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）及びＰ２Ｐ（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）等が含まれる。
【００１３】
前記イベントがプッシュされるステップの前に、サービスに連係した少なくとも１つのチャネルとＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ  Ｍａｒｋｕｐ  Ｌａｎｇｕａｇｅ）を用いて形成されたＵＥＤ（Ｕｎｏｔｓ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルをサービスプロバイダから提供し、そのチャネル及びＵＥＤファイルを提供者情報として登録するステップを含み、前記サービスプロバイダから前記ＵＥＤファイルで指定するデータフォーマットで前記イベントがプッシュされることを特徴とする。
【００１４】
前記イベントメッセージを送信するステップでは、各加入者端末の多様な形態を識別して該当端末がサポートするデータタイプのバイナリプロトコルによるデータに前記イベントメッセージを含ませて送信し、また、各加入者端末の多様な形態を識別せずにＸＭＬ形態のデータに前記イベントメッセージを含ませて送信する。
【００１５】
上述したような本発明の目的を達成するための本発明の他の一態様に係るユビキタス通知方法は、サービスプロバイダと多様な形態のユビキタス端末との間でプッシュエンジンを用いて前記サービスプロバイダからプッシュされる複数のイベントを集積して統合管理し、前記イベントのうちでプッシュされようとする少なくとも１つのイベントに対する加入を登録した少なくとも１つの端末に、該当端末でサポートされるデータタイプのイベントメッセージを前記該当端末でサポートされる通信方式で送信することを特徴とする。
【００１６】
上述したような本発明の目的を達成するために、本発明のさらに他の一態様に係るユビキタス端末でイベントを提供する方法は、プッシュサービスの加入要請を送信するステップと、前記加入要請に応じてサービスに連係した少なくとも１つのチャネルリストを受信するステップと、端末に対応するユーザ情報と前記チャネルリストのうちからユーザによって選択された少なくとも１つのチャネルに対する選択情報とを含む加入者情報を送信するステップと、前記加入者情報による該当チャネルに対するイベントメッセージを受信するステップとを含む。
【００１７】
前記加入者情報を送信するステップの後に、ユーザとのインターフェースのためのＵＥＤファイル要請を送信するステップと、前記ＵＥＤファイル要請に応じてユーザとのインターフェースのためのＵＥＤファイルを受信するステップとを更に含む。ここで、前記加入者情報を受信するステップでは、前記イベントメッセージを前記ＵＥＤファイルで指定するデータタイプのバイナリプロトコルによるデータで受信する。
【００１８】
前記ＵＥＤファイルを受信するステップの後に、前記ＵＥＤファイルにメッセージ表示形式を指定するテンプレートが含まれている場合、前記ＵＥＤファイルを解析し、前記該当チャネルに対するイベントメッセージを前記テンプレートに基づく形態に変換するステップをさらに含む。
【００１９】
上述のような本発明の目的を達成すために、本発明のさらに他の一態様に係るイベントを提供する端末は、イベントプッシュサービスの加入要請に応じてサービスに連係した少なくとも１つのチャネルリストを受信し、前記チャネルリストのうちからユーザによって選択された少なくとも１つのチャネルに対する選択情報とユーザ端末に対応するユーザ情報とを含む加入者情報を生成して送信し、前記選択情報による該当チャネルに対するイベントメッセージを受信する通知クライアントと、前記通知クライアントを介して受信された前記イベントメッセージを表示するユーザインターフェースとを含むことを特徴とする。
【００２０】
前記端末は、ユーザとのインターフェースのためのＵＥＤファイルが格納されるメモリをさらに含み、前記通知クライアントは、前記ＵＥＤファイルの要請に応じて前記ＵＥＤファイルを受信する。ここで、前記通知クライアントは、前記イベントメッセージを前記ＵＥＤファイルで指定されたデータタイプのバイナリプロトコルによるデータで受信する。
【００２１】
前記端末は、前記ＵＥＤファイルを解析し、メッセージ表示形式を指定するテンプレートを抽出して解釈するテンプレートパーサをさらに含み、前記ユーザインターフェースは、前記イベントメッセージを前記テンプレートに基づいた形態で表示する。
【００２２】
上述のような本発明の目的を達成するために、本発明のさらに他の一態様に係るユビキタス通知システムは、サービスに連係したイベントがプッシュされるイベントゲートウェイと、前記プッシュされたイベントに応答してイベントメッセージを送信する少なくとも１つのブローカとを含む。ここで、前記少なくとも１つのブローカは、各加入者端末の多様な形態を識別して該当端末がサポートする通信方式で前記イベントメッセージを送信し、各加入者端末の多様な形態を識別して該当端末がサポートするデータタイプのバイナリプロトコルによるデータに前記イベントメッセージを含ませて送信する。
【００２３】
前記ユビキタス通知システムは、前記サービスに連係した少なくとも１つのチャネルとサービスプロバイダから提供されるＵＥＤファイルを受信するディレクトリ管理部と、前記提供者情報として前記少なくとも１つのチャネルと前記ＵＥＤファイルをデータベースに登録するレジスタとをさらに含み、前記イベントゲートウェイは、前記データベースを参照して、前記ＵＥＤファイルで指定されたデータフォーマットで前記イベントがプッシュされることを特徴とする。ここで、前記ディレクトリ管理部は、ユーザ端末の要請に応じてユーザとのインターフェースのためのＵＥＤファイルを前記ユーザ端末に送信する。これにより、前記少なくとも１つのブローカは、前記ＵＥＤファイルで指定されたデータタイプのバイナリプロトコルによるデータに前記イベントメッセージを含ませて送信する。さらに、前記ディレクトリ管理部は、各サービスに対してイベントが属するドメインを示すチャネル単位で前記プッシュされたイベントを管理し、前記少なくとも１つのブローカは、前記チャネル単位で前記イベントメッセージを送信する。これにより、前記少なくとも１つのブローカは、前記チャネルに少なくとも１つのサブチャネルが含まれた場合に、前記イベントメッセージを承認された少なくとも１つのサブチャネルに送信することができる。
【００２４】
さらに、前記少なくとも１つのブローカは、前記チャネルに予め定められた識別者が含まれたユーザＩＤが含まれている場合に、前記ユーザＩＤに対応するユーザ端末のみに前記イベントメッセージを送信、又は、前記ユーザＩＤに対応するユーザ端末のみに前記イベントメッセージを送信しない。さらに、前記少なくとも１つのブローカは、各加入者端末の多様な形態を識別せずに、ＸＭＬ形態のデータに前記イベントメッセージを含ませて送信する。
【００２５】
前記ユビキタス通知システムは、ユーザ端末からの要請に応じて前記サービスに連係した少なくとも１つのチャネルリストを前記ユーザ端末に送信し、前記ユーザ端末に対するユーザ情報と前記チャネルリストのうちからユーザによって選択された少なくとも１つのチャネルに対する選択情報とを加入者情報としてデータベースに登録する加入ゲートウェイをさらに含み、前記少なくとも１つのブローカは、前記データベースを参照して、前記加入者情報による該当チャネルに対するイベントメッセージを送信する。
【００２６】
上述のような本発明の目的を達成するために、本発明のさらに他の一態様に係るサービスプロバイダと多様な形態のユビキタス端末との間でユビキタス通知を提供するシステムは、前記サービスプロバイダからプッシュされるイベントを収集するコネクション手段と、前記コネクション手段によって収集される複数のイベントを集積して統合管理し、前記イベントのうちでプッシュされようとする少なくとも１つのイベントに対する加入を登録した少なくとも１つの端末に、該当端末でサポートされるデータタイプで生成したイベントメッセージを前記該当端末でサポートされる通信方式で送信するプッシュエンジンとを含む。
【図面の簡単な説明】
【００２７】
【図１】従来のイベント通知方法を説明するための図である。
【図２】本発明の一実施形態に係るユビキタス通知システムのイベントプッシュ方法の概念を説明するための図である。
【図３】本発明の一実施形態に係るユビキタス通知システムを説明するための図である。
【図４】図３のユビキタス通知サーバの具体的なブロック図である。
【図５】ユビキタス環境でイベント発生が予想されるサービスを説明するための図である。
【図６】本発明の一実施形態に係るイベント別のチャネルリストを説明するための図である。
【図７】本発明の一実施形態に係るイベントメッセージの生成を説明するための図である。
【図８】図３のユーザ端末の具体的なブロック図である。
【図９】本発明の一実施形態に係るＵＥＤに定義されるデータタイプを説明するための図である。
【図１０】本発明の一実施形態に係るユビキタス通知方法を説明するためのフローチャートである。
【発明を実施するための形態】
【００２８】
以下、添付の図面に基づき、本発明の好適な実施の形態を詳細に説明するが、本発明がこれらの実施形態によって制限または限定されることはない。図中、同じ参照符号は同じ部材を示す。
【００２９】
図２は、本発明の一実施形態に係るイベントプッシュ方法の概念を説明するためのユビキタス通知システム（ＵｎｏｔＳ：Ｕｂｉｑｕｉｔｏｕｓ  Ｎｏｔｉｆｉｃａｔｉｏｎ  Ｓｙｓｔｅｍ）２００を示している。
【００３０】
図２を参照すれば、本発明の一実施形態に係るユビキタス通知システム２００は、サービスプロバイダでプッシュされる各サービスのイベントを収集するためのコネクタ（ｃｏｎｎｅｃｔｏｒ）２１０と、サービスプロバイダからプッシュされるイベントなどを集積して統合管理し、多様な形態のユビキタスデバイス（端末）に送信するプッシュエンジン（ｐｕｓｈ  ｅｎｇｉｎｅ）２２０とを含む。
【００３１】
プッシュエンジン２２０は、１つ以上のサービスプロバイダからプッシュされる各サービスと関連した多様なイベントを、コネクタ２１０の１つの経路を介して集積して統合管理する。ここで、各サービスプロバイダは、地域情報のようなコミュニティ（ｃｏｍｍｕｎｉｔｙ）サービス、電子メール及びＳＭＳ（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）のようなメッセージングサービス、競売落札などの通知サービス、緊急遭難サービス、証券／金融情報、オンラインコミュニティ情報、ブログ情報、ゲーム情報などの多様なサービスと関連したイベントを提供することができる。
【００３２】
また、プッシュエンジン２２０は、多様なユビキタス端末のうちでプッシュされようとする少なくとも１つのイベントに対して加入した少なくとも１つの端末に、該当端末でサポートされるデータタイプのイベントメッセージを該当端末でサポートされる通信方式で送信することができる。プッシュエンジン２２０を介してサービスプロバイダと連係したサービスに対する加入権限が付与され、コンピュータ、移動端末、ＴＶ、ＰＤＡ、ゲーム機などの多様な形態のユビキタスデバイス（端末）のユーザは、いつどこででもプッシュエンジン２２０を介してイベントプッシュサービスを受けるための加入手続きに参加することができ、該当サービスの提供が可能となる。
【００３３】
したがって、必要なイベントをプッシュしようとする加入者に対するリストをサービスプロバイダが直接に管理するのではなく、中継プラットホームであるプッシュエンジン２２０でリストを管理することにより、サービスプロバイダは、イベントプッシュサービスの加入権限をプッシュエンジン２２０の一貫したインターフェースで提供できるようになる。また、サービスプロバイダから提供される各サービスのイベントは、１つの経路を介してプッシュエンジン２２０に集積されて統合管理されるため、プッシュ型イベントが提供される加入者は、プッシュエンジン２２０によって自身のイベントプロフィールを一括して管理できるようになり、プッシュエンジン２２０は、加入者に３Ａ基盤でいつどこででもデバイスに適合した方式でイベントを提供できるようになる。これにより、ユーザがサービスにより密着することができるユビキタス連結環をユーザに提供する。
【００３４】
このようなプッシュエンジン２２０は、サービスプロバイダによって提供されていたプッシュ型イベントなどのようなレガシーサービスの小さい変更のみで実現することができ、ユビキタスデバイスに適合するようにプッシュ型イベントの集積と統合管理および加入権限付与と多様な形態のユビキタスデバイスに適応して大容量のトランザクション（ｔｒａｎｓａｃｔｉｏｎ）処理が可能な中継機能などの役割を実行することができる。
【００３５】
図３は、本発明の一実施形態に係るユビキタス通知システム３００を説明するための図である。本発明の一実施形態に係るユビキタス通知システム３００は、インターネット、無線インターネット網、携帯インターネット網、公衆網、コア網などのネットワーク３１０に連結した少なくとも１つ以上のサービスプロバイダ３２０と、多様な形態のユビキタスデバイスであるユーザ端末３４０とを含み、サービスプロバイダ３２０からユーザ端末３４０へのプッシュ型イベントの伝達を中継するプラットホームの役割をするユビキタス通知サーバ３３０を含む。
【００３６】
サービスプロバイダ３２０は、多様なアプリケーションを運営し、地域情報などのコミュニティサービス、電子メールサービス及びＳＭＳなどのメッセージングサービス、競売落札などの通知サービス、緊急遭難サービス、証券／金融情報、オンラインコミュニティ情報、ブログ情報、ゲーム情報など多様なサービスに関するイベントを提供することができる。
【００３７】
ユーザ端末３４０は、多様な形態のユビキタスデバイスであり、デスクトップコンピュータやノート型コンピュータなどのコンピュータ、ＣＤＭＡ／ＷＣＤＭＡ網や無線インターネットまたは携帯インターネットを介して通信する携帯電話機（Ｃｅｌｌｕｌａｒ  ｐｈｏｎｅ）、ＰＣＳフォン（ＰＣＳ  ｐｈｏｎｅ：Ｐｅｒｓｏｎａｌ  Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｅｒｖｉｃｅｓ  ｐｈｏｎｅ）、同期式／非同期式ＩＭＴ−２０００（Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎ−２０００）などの移動端末を含み、この他にもパームパーソナルコンピュータ（Ｐａｌｍ（登録商標）  Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）、ＰＤＡ（Ｐｅｒｓｏｎａｌ  Ｄｉｇｉｔａｌ  Ａｓｓｉｓｔａｎｔ）、スマートフォン（Ｓｍａｒｔ  ｐｈｏｎｅ）、ＷＡＰフォン（ＷＡＰ  ｐｈｏｎｅ：Ｗｉｒｅｌｅｓｓ  ａｐｐｌｉｃａｔｉｏｎ  ｐｒｏｔｏｃｏｌ  ｐｈｏｎｅ）、モバイルゲーム機（ｍｏｂｉｌｅ  ｐｌａｙ−ｓｔａｔｉｏｎ（登録商標））、公衆網またはＩＰ網などに接続されたＬＡＮ通信が可能なＴＶ、ＩＰＴＶ、冷蔵庫、電子レンジなど、すべての有線・無線線家電／通信装置が含まれる。
【００３８】
ユビキタス通知サーバ３３０は、サービスプロバイダ３２０と多様な形態のユビキタスユーザ端末３４０との間で、サービスプロバイダ３２０からプッシュされる多様なイベントを集積して統合管理し、イベントのうちでプッシュされようとする少なくとも１つのイベントに対して加入した少なくとも１つの端末に、該当端末でサポートされるデータタイプのイベントメッセージを該当端末でサポートされる通信方式で送信することができる。
【００３９】
図３のユビキタス通知サーバ３３０の具体的なブロック図が図４に示されている。図４を参照すれば、ユビキタス通知サーバ３３０は、イベントゲートウェイ（ｇａｔｅｗａｙ）３３１、１つ以上のブローカ（ｂｒｏｋｅｒ）３３２、ディレクトリ（ｄｉｒｅｃｔｏｒｙ）管理部３３３、提供者データベース（ｄａｔａｂａｓｅ）３３４、加入（ｓｕｂｓｃｒｉｐｔｉｏｎ）ゲートウェイ３３５、および加入者データベース３３６を含む。
【００４０】
イベントゲートウェイ３３１は、サービスプロバイダ３２０から各サービスに連係したイベントがプッシュされる。イベントがプッシュされる方法は、既存のテキスト方式よりはバイナリプロトコルによる方式で処理されるようになっており、該当バイナリプロトコルをサポートするために、ＨＴＴＰ（ｈｙｐｅｒｔｅｘｔ  ｔｒａｎｓｆｅｒ  ｐｒｏｔｏｃｏｌ）、Ｊａｖａ  Ｃｌａｓｓなどの適応型レイヤ（Ａｄａｐｔａｔｉｏｎ  Ｌａｙｅｒ）が用いられる。下記でも説明するが、イベントゲートウェイ３３１に接続するサービスプロバイダ３２０は、ディレクトリ管理部３３３によって提供者データベース３３４に登録されたサーバではなければならず、接続を試みる時に該当サービスＩＤ又は認証キーなどに基づいて接続することができる。この後、サービスプロバイダ３２０から送信される全てのイベントは、イベントゲートウェイ３３１に定められた規則により、ユーザ端末３４０を管理する該当ブローカ３３２に送信される。
【００４１】
これにより、ブローカ３３２は、プッシュされたイベントに対応するイベントメッセージを加入者端末に送信する。ブローカ３３２は、ユーザ端末３４０の認証、接続管理、プレゼンス（ｐｒｅｓｅｎｃｅ）管理などに基づいて、ユーザ端末３４０へのイベントメッセージ送信を実行する。このとき、ブローカ３３２は、各加入者端末の多様な形態を区分して、該当端末がサポートする通信方式でイベントメッセージを送信する。
【００４２】
ブローカ３３２は、イベントメッセージを端末の通信方式別に区分して送信するために、複数のブローかで構成することができる。例えば、ブローカ３３２は、ＴＣＰ／ＩＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）、ＳＭＳ（Ｓｈｏｒｔ  Ｍｅｓｓａｇｅ  Ｓｅｒｖｉｃｅ）、ＵＤＰ（Ｕｓｅｒ  Ｄａｔａｇｒａｍ  Ｐｒｏｔｏｃｏｌ）、Ｐ２Ｐ（Ｐｅｅｒ  ｔｏ  Ｐｅｅｒ）基盤の通信プロトコルなどの端末に適した多様な通信方式でイベントメッセージを送信することにより、多様なユビキタス端末に対するイベントプッシュをサポートすることができる。該当イベントとユーザ端末３４０の間のコネクションは、所定のメモリ上でポインタに参照することで、端末へのイベントプッシュと関連して最高の性能を保障することができる。同じイベントが１つのブローカ３３２によって多数の加入者端末に配布される場合には、イベントゲートウェイ３３１はブローカ３３２に該当イベントと受信ユーザ端末リストを送信することができ、ブローカ３３２は該当イベントをリストに記録された各加入者端末に配布することもできる。
【００４３】
また、ユーザ端末３４０の種類による多様な形態の通信をサポートするブローカ３３２は、接続基盤ブローかと非接続基盤ブローカに分類することができる。接続基盤ブローカは、接続して認証したユーザ端末３４０を有効クライアントとして認識し、イベントゲートウェイ３３１に接続したというプレゼンス信号をアクティブにさせることにより、以後にイベントゲートウェイ３３１から伝達されたイベントを該当加入者端末に送信する。非接続基板ブローカは、ＳＭＳ基盤の移動端末あるいはポップアップサービスのための周期的ポーリング（ｐｏｌｌｉｎｇ）方式のインターネットサービス端末などで用いられる。ここで、ブローカ３３２は、セッション（ｓｅｓｓｉｏｎ）情報を個別に管理する。例えば、携帯電話機は、Ａｌｗａｙｓ−Ｏｎ  Ｄｅｖｉｃｅ（常にオン状態で待機する端末）として認識することができるため、サービス加入及び取り消しがインターネットホームページなどのログインまたはログアウトの役割を実行することと同じものとして判断することができる。
【００４４】
ただし、加入ゲートウェイ３３５を介して、ユーザ端末３４０のうちでイベントプッシュサービスを受けようとするユーザ端末に対する情報である加入者情報を加入者データベース３３６に格納することができるが、この他にも、ブローカ３３２で該当加入者端末のプレゼンスを一括して管理するための個別のデータベースを運営することもできる。ブローカ３３２は、追加するデバイスの形態に応じて該当端末のサービスサポート方式に適合するように開発されて追加されることができる。
【００４５】
一方、ブローカ３３２は、必要によっては、各加入者端末の多様な形態を区分せずに、ＸＭＬ形態のデータにイベントメッセージを含ませて送信することもできるが、各加入者端末の多様な形態を考慮して、該当端末がサポートするデータタイプのバイナリ（ｂｉｎａｒｙ）プロトコルによるペイロード（ｐａｙｌｏａｄ：データ）にイベントメッセージを含ませて送信することが好ましい。
【００４６】
本発明に係るユビキタス通知サーバ３３０は、パソコンのようにデータ送信が自由であって広帯域のデータを無理なく送信することができる環境よりは、データ送信が制約的であってプロセッシングパワーが制限的な携帯型端末に積極的に活用できるように提案された。例えば、ＳＭＳ基盤のメッセージ送信は、送信が可能なデータの大きさが８０バイト程度に過ぎないため、ＳＭＳを用いたイベント送信はその内容と長さに極めて制約を有するようになる。したがって、様々な制約がある携帯型端末に容易に適用するために、イベントの固有の意味のみをバイナリプロトコルによるデータ形態で送信できるようにした。
【００４７】
イベント自体はサービスＩＤとイベントＩＤを有しており、サービスプロバイダ３２０は、該当イベントに対する定義をディレクトリ管理部３３３を介して提供者データベース３３４にまず登録した後、該当イベントに対するバイナリプロトコルを定義したＵＥＤ（ＵｎｏｔＳ  Ｅｖｅｎｔ  Ｄｅｓｃｒｉｐｔｉｏｎ）ファイルも共に登録した後、該当バイナリプロトコルに対するイベントを発生させれば良い。このとき、バイナリプロトコルを記述するために提供されるデータタイプは、図９に対する説明で記述するように、８、１６、３２ビットなどの定数や文字列関数で定義されて送受信することができる。
【００４８】
イメージや動画などのマルチメディアデータを上述のデータタイプで送信する場合には、上述以外にもＳｔｒｉｎｇ２またはＳｔｒｉｎｇ４などの関数を活用して符号化されたデータを送信することも可能であるが、このような形態のマルチメディアデータは、自体のＵＲＬ（ｕｎｉｆｏｒｍ  ｒｅｓｏｕｒｃｅ  ｌｏｃａｔｏｒ）のみをメッセージに符号化して送信することが好ましい。このとき、加入者端末は該当イベントメッセージを解釈し、マルチメディアの内容はＵＲＬを介したサーバ接続を用いて提供される。
【００４９】
下記でも説明するが、加入者端末は、加入時にディレクトリ管理部３３３に接続し、提供者データベース３３４に管理されるＵＥＤファイルの受信することができる。これにより、加入者端末は、ブローカ３３２から送信されるイベントメッセージの解釈において、ＵＥＤファイルの定義によってイベントメッセージを解釈して表示できるようになる。
【００５０】
一方、上述したように、プッシュ型イベントを発生させるサービスプロバイダ３２０は、各イベントに対するプッシュサービスを提供するために、サービスＩＤ、イベントＩＤおよびＵＥＤなどをディレクトリ管理部３３３に送信して、サービスＩＤを登録することができる。すなわち、ディレクトリ管理部３３３は、サービスＩＤとイベントＩＤが含まれるサービス連係チャネルがサービスプロバイダ３２０から提供されてディレクトリ形態で提供者データベース３３４内の該当チャネルに格納する。このとき、該当チャネルにおけるイベントに対するデータタイプなどを含んだユーザインターフェースを定義した下記の［ＵＥＤフォーマットの例示］のようなＵＥＤファイルも提供者データベース３３４に共に格納することにより、該当サービスのイベント関連情報を具体的に登録する。
【００５１】
このように、提供者データベース３３４に登録される各サービスに連係したチャネルとＵＥＤファイルを含む提供者情報を参照することにより、イベントゲートウェイ３３１は、サービスプロバイダ３２０からＵＥＤファイルで指定するデータタイプで該当イベントがプッシュされるようになる。もし、提供者データベース３３４に登録されないイベントフォーマットがサービスプロバイダ３２０から送信される場合、イベントゲートウェイ３３１は、該当イベントプッシュを拒絶する。
【００５２】
［ＵＥＤフォーマットの例示］
＜？ｘｍｌ  ｖｅｒｓｉｏｎ＝“１．０”ｅｎｃｏｄｉｎｇ＝“ｅｕｃ−ｋｒ”？＞
＜ｕｅｄ  ｅｖｅｎｔ−ｐｒｏｖｉｄｅｒ−ｉｄ＝“［ｅｖｅｎｔＰｒｏｖｉｄｅｒＩＤ］”ｅｖｅｎｔ−ｉｄ＝“［ｅｖｅｎｔＩＤ］”＞
＜ｄｅｓｃｒｉｐｔｉｏｎ＞［ｂｒｉｅｆ  ｄｅｓｃｒｉｐｔｉｏｎ］＜／ｄｅｓｃｒｉｐｔｉｏｎ＞
＜ｒｅｃｏｒｄ＞
＜ｆｉｅｌｄ  ｎａｍｅ＝“［ｎａｍｅ］”ｔｙｐｅ＝“［ｄａｔａ  ｔｙｐｅ］”／＞
［ｒｅｐｅａｔ  ｆｉｅｌｄ  ｅｌｅｍｅｎｔ］
＜／ｒｅｃｏｒｄ＞
＜ｕｒｌ＞［ａｄｉｔｉｏｎａｌ  ｉｎｆｏｒｍａｔｉｏｎ  ＵＲＬ］＜／ｕｒｌ＞
＜ｔｅｍｐｌａｔｅ＞［ｔｅｍｐｌａｔｅ  ｔｏ  ｂｅ  ｄｉｓｐｌａｙｅｄ  ｏｎ  ｔｈｅ  ｓｃｒｅｅｎ］＜／ｔｅｍｐｌａｔｅ＞
＜／ｕｅｄ＞
【００５３】
ディレクトリ管理部３３３は、イベントの手軽な追加や拡張を支援するだけでなく、イベント別のバージョン管理によるサービスのアップグレードも支援することができる。もし、サービスプロバイダ３２０によってイベントフォーマットが変わる場合に、サービスプロバイダ３２０は、提供者データベース３３４に新たなイベントを登録して用いなければならず、過去のイベントを用いない場合には、ディレクトリ管理部３３３は、該当イベントを無効（ｄｉｓａｂｌｅ）にしなければならない。加入者端末は、使用しないＵＥＤに対して処理方針を決定することができ、このためにＵＥＤが削除されれば、該当ＵＥＤの有効性（ｖａｌｉｄ）をディレクトリ管理部３３３に問い合わせることができる。加入者端末の要請により、ディレクトリ管理部３３３は、加入者端末のユーザインターフェースに適用する新たなＵＥＤを加入者端末に送信することができ、ブローカ３３２は、ＵＥＤファイルで指定するデータタイプのバイナリプロトコルによるデータにイベントメッセージに追加して加入者端末に送信することができる。ディレクトリ管理部３３３は、該当端末に適合するデータタイプが定義されたＵＥＤを予め認識しており、加入者端末のＵＥＤ要請時に端末機種などの仕様を参照して加入者が指定するデータタイプに適するようにそれに適合したＵＥＤを加入者端末に送信することができる。
【００５４】
サービスプロバイダ３２０が提供するサービスには、図５に示すように、オンラインコミュニティサービス、ブログサービス、電子メールサービス、ニュース、金融／電子商取引に関する競売、株価情報、口座情報、放送に関するプログラム情報、スポーツ中継、ホームショッピング情報、地域情報に関するプロフィール、天気予報、クーポン、不動産情報、コミュニケーションに関する不在情報、ＶｏＩＰメッセージ、通話料情報、または個人スケジュール情報、関心のあるお友達情報、プライバシー情報などが含まれる。
【００５５】
各サービスでイベント発生が連係したチャネルを、図６に示すように定義することができる。ディレクトリ管理部３３３は、各サービスに対してイベントが属するドメインを示すチャネル単位でサービスプロバイダ３２０からプッシュされるイベントを管理し、ブローカ３３２は、チャネル単位で加入者端末にイベントメッセージを送信することができる。
【００５６】
イベントメッセージは、あらゆるグループまたは個人に伝達することができる。しかしながら、実際のサービスプロバイダ３２０の立場では、特定のイベント伝達グループを加入者の意思とは関係なくプッシュできないだけでなく、このようなリストを管理することも困難である。したがって、本発明では、上述のようなチャネル概念を導入し、提供者データベース３３４にディレクトリ形態で管理されるイベントチャネルは、ウェプページにおけるサブディレクトリの表現と類似し、サービスプロバイダ３２０のデータ構造をそのまま活用することができる。チャネルは、自由にサブチャネルを有することができ、上位チャネル名でイベントを送信した場合は、下位チャネルの論理和に該当するチャネルに加入した端末にイベントメッセージを送信するようになる。
【００５７】
すなわち、ブローカ３３２は、該当チャネルの下位に少なくとも１つのサブチャネルが含まれた場合に、サービスプロバイダ３２０から提供されたプッシュメッセージに対応するイベントメッセージをその下位のサブチャネルに加入したすべての端末に送信することができる。チャネルのディプス（ｄｅｐｔｈ）は制約がないが、ユーザ端末側でチャネルを選択してそれぞれ加入しなければならないという問題点を考慮するとき、チャネルのディプスは最大２段階まで有することが好ましい。
【００５８】
個人の場合は、チャネルを示す表記法と類似するように個人を表示することもでき、個人を表示する場合には、＠ｕｓｅｒ１または＠ｊｈｍｏｏｎのように＠とユーザＩＤを用いて示すことができる。このように、チャネルに識別子が含まれたユーザＩＤが含まれれば、ブローカ３３２は、該当ユーザＩＤに対応するユーザ端末のみにサービスプロバイダ３２０から提供されたプッシュメッセージに対応するイベントメッセージを送信することができる。また、チャネルに「ｂｌｏｇ／ｉｎｄｉｇｏ」「ＥＸ：ｉｎｄ／ｉｎｄｉｇｏ」のように、識別子ＥＸなどを用いてＩＤがｉｎｄｉｇｏであるユーザを除外することも可能である。
【００５９】
一方、図３において、加入ゲートウェイ３３５は、ユーザ端末３４０からの要請により、サービスプロバイダ３２０によって登録された各サービスに連係した少なくとも１つのチャネルリストをユーザ端末３４０に送信する。このとき、加入ゲートウェイ３３５は、サービスプロバイダ３２０に該当ユーザＩＤを伝達することにより、サービスプロバイダ３２０が該当ユーザの権限をチェックしてチャネル登録手続きを有するようにする。
【００６０】
権限が認証されたユーザ端末は、加入ゲートウェイ３３５で提供されるチャネルリストのうちからユーザが選択する少なくとも１つのチャネルに対する選択情報と、ユーザＩＤ、パスワード、端末固有番号、端末機種などのユーザ情報とを加入ゲートウェイ３３５に送信する。これにより、加入ゲートウェイ３３５は、加入者別に選択情報とユーザ情報を含んだ加入者情報を加入者データベース３３６に登録する。
【００６１】
これにより、ブローカ３３２は、加入者データベース３３６を参照して、加入者情報による該当チャネルに対するイベントメッセージを加入者データベース３３６に送信ことができる。このとき、特定チャネルに対するサービス加入者の権限が変更されたり消滅した場合、このような事実をサービスプロバイダ３２０が該当加入者の該当チャネルに対する登録解除（ｄｅｒｅｇｉｓｔｒａｔｉｏｎ）命令として加入ゲートウェイ３３５に知らせなければならない。これにより、加入ゲートウェイ３３５は、その加入者端末にはイベントメッセージが送信されないように、加入者データベース３３６から該当加入者の権限を解除する。
【００６２】
図７は、本発明の一実施形態に係るイベントメッセージの生成を説明するための図である。例えば、オンラインコミュニティでは、「○○コミュニティの○○掲示板に○○が○○文章を掲載しました」などのようなイベントをプッシュすることができ、該当コミュニティの会員は、該当イベントに対する関連メッセージを、自身の端末形態に関係なくいつどこででもプッシュされることができる。
【００６３】
同じように、インターネットブログでは、「○○のブログに新しい書き込み○○が登録されました」などのようなイベントをプッシュすることができ、該当ブログ会員は、ブログイベントに対する関連メッセージを、自身の端末形態に関係なくいつどこででもプッシュされることができる。
【００６４】
このように、本発明では、ユビキタスユーザ端末３４０に対応する適切なブローカコネクションと、サービスプロバイダ３２０がサービス種類、イベント種類、およびイベントフォーマットと意味などを登録するディレクトリを運営し、どのような形態のユーザ端末３４０であってもディレクトリを参照してイベントプッシュサービスを受けることができるようになる。これは、サービスプロバイダ３２０のサービス企画によって多様なイベントを創出して提供できるようにし、ユーザは、サービスが異なるＵＥＤフォーマットに変更されても、ＵＥＤ関連クライアントをアップグレードすることなく、自動でイベントを解釈して提供されることができる。
【００６５】
図８は、図３のユーザ端末３４０の具体的なブロック図である。図３を参照すれば、本発明の一実施形態に係るユーザ端末３４０は、ユーザインターフェース３４１、通知クライアント３４２、メモリ３４３、およびテンプレートパーサ（ｔｅｍｐｌａｔｅ  ｐａｒｓｅｒ）３４４を含む。
【００６６】
上述したように、ユーザ端末３４０は、ＴＣＰ／ＩＰ基盤のインターネット端末やＳＭＳ基盤の移動端末のみをではなく、ユーザが携帯したり宅内に設置して有線／無線方式で通信することができるすべてのユビキタス端末を包括する。
【００６７】
例えば、ユーザ端末３４０がＳＭＳを受信することができる携帯電話機である場合に、このような端末は一般的に常にオン（Ｏｎ）になっていると仮定することができ、ユビキタス通知サーバ３３０のＳＭＳを担当するブローカを介して、イベントメッセージを受信する。
【００６８】
一方、ユーザ端末３４０が一般的なＴＣＰ／ＩＰ基盤のメッセージを受信することができる端末である場合には、初期認証手続き（ＳＭＳデバイスの場合は、初めてサービス加入が認証される手続き）を経てユビキタス通知サーバ３３０のＴＣＰ／ＩＰを担当するブローカに接続されてメッセージを受けるようになる。
【００６９】
この他にも、ＵＤＰ（ｕｓｅｒ  ｄａｔａｇｒａｍ  ｐｒｏｔｏｃｏｌ）あるいはＰ２Ｐ（ｐｅｅｒ  ｔｏ  ｐｅｅｒ）方式で通信するネットワーク上でも、イベントメッセージをプッシュをされることができる端末インターフェースがあれば、このインターフェースに適合するようにイベントメッセージの提供を受けることが可能であろう。このときには、これに適合するブローカがユビキタス通知サーバ３３０にやはり備えられなければならない。
【００７０】
ユーザインターフェース３４１は、ＬＣＤ（Ｌｉｑｕｉｄ  Ｃｒｙｓｔａｌ  Ｄｉｓｐｌａｙ）などのようなディスプレイ手段、スピーカなどのような音声出力手段、またはキーパッドやタッチスクリーンなどのようなデータ入力手段などを含み、この他にも、これらを駆動するアプリケーションまでもすべて含むものであって、ユーザが各種情報の入出力時にユーザ環境に適合するように処理するのに必要なすべての手段を含む。
【００７１】
通知クライアント３４２は、ユビキタス通知サーバ３３０で運営されるプッシュ中継サービスに加入するために加入要請を送信することができ、ＵＥＤファイルをダウンロードするためのＵＥＤ要請を送信することができる。
【００７２】
通知クライアント３４２は、前記加入要請によって、ユビキタス通知サーバ３３０のディレクトリ管理部３３３からサービスプロバイダ３２０によって提供される各サービスに連係する少なくとも１つのチャネルリストを受信し、ユーザがチャネルリストのうちから少なくとも１つのチャネルを選択できるようにし、選択されたチャネルに対する選択情報と使用端末に対するユーザ情報（ユーザＩＤ、パスワード、端末固有番号、端末機種など）などを含む加入者情報を生成してユビキタス通知サーバ３３０の加入ゲートウェイ３３５に送信することができる。
【００７３】
これにより、加入ゲートウェイ３３５が加入者情報を加入者データベース３３６に登録すれば、その後、通知クライアント３４２が選択情報による該当チャネルに対するイベントメッセージを受信することができる。このように受信されたイベントメッセージは、ユーザインターフェース３４１を介して表示される。
【００７４】
また、通知クライアント３４２は、ＵＥＤファイルをダウンロードするためのＵＥＤ要請によって、ユビキタス通知サーバ３３０のディレクトリ管理部３３３からユーザが選択したサービスまたはチャネル関連ＵＥＤファイルを受信し、このファイルをメモリ３４３に格納することができる。ディレクトリ管理部３３３は、該当端末の仕様別に適合したデータタイプが定義されたＵＥＤを予め認知している。
【００７５】
また、通知クライアント３４２は、ＵＥＤ要請時に端末機種などの仕様に適合したＵＥＤを加入者端末に送信したり、また、通知クライアント３４２を介して加入者が指定するデータタイプに適合したＵＥＤを加入者端末に送信することができる。
【００７６】
上述したように、ＵＥＤに定義されるデータタイプは、図９のように、多様な加入者端末に適応することができるよう８、１６、３２ビットなどの定数や文字列関数で定義することができ、これにより、通知クライアント３４２は、ＵＥＤファイルで指定するデータタイプのバイナリプロトコルによる形態のイベントメッセージをユビキタス通知サーバ３３０のブローカ３３２から受信することができる。
【００７７】
通知クライアント３４２は、受信されたＸＭＬ形態のイベントメッセージを直接に上位アプリケーションにアップデートして表示させることができるが、ＵＥＤに含まれているテンプレートに受信されたイベントメッセージを適用して表示することもできる。このため、端末にはテンプレートパーサ３４４が含まれ、テンプレートパーサ３４４は、ＵＥＤファイルを解析してメッセージ表示形式を指定するテンプレートを抽出して解釈する。これにより、ユーザインターフェース３４１は、バイナリプロトコルによるイベントメッセージをテンプレートに適用された形態で表示することができる。これは、簡単なアラーティング（ａｌｅｒｔｉｎｇ）機能を提供するサービスの場合に有効に用いることができる。
【００７８】
一方、テンプレートの豊富さ（ｒｉｃｈｎｅｓｓ）を増加させるために、テンプレートにはフォントに関する事項（色、太さ、サイズなど）が含めることができ、イメージなどのリソースを活用する形態を含めることができる。または、テンプレートがＦｕｌｌ  ＨＴＭＬ（ｈｙｐｅｒｔｅｘｔ  ｍａｒｋｕｐ  ｌａｎｇｕａｇｅ）文書の一部分で生成されるように、通知クライアント３４２のプログラムを作成することもできる。例えば、ユーザＩＤがパラメータ（ｐａｒａｍｅｔｅｒ）として受信されるときは、プロフィールページにリンクさせることが可能である。
【００７９】
以下、図１０のフローチャートを参照しながら、本発明の一実施形態に係るユビキタス通知サーバ３３０の動作についてより詳しく説明する。
【００８０】
まず、サービスプロバイダ３２０は、ユビキタス通知サーバ３３０の中継プラットホームによるイベントプッシュサービスを提供するためにサービスＩＤやイベントＩＤなどを含み、図６に示したように、サービスに連係した少なくとも１つのチャネルとＸＭＬ形態のＵＥＤファイルを提供者情報として登録する（Ｓ１１）。ユビキタス通知サーバ３３０のディレクトリ管理部３３３は、提供者データベース３３４に提供者情報を格納して管理する。このとき、ＵＥＤファイルをチャネル別で管理したり、サービス別に管理することができる。
【００８１】
この後、ユーザ端末３４０は、サービスプロバイダ３２０が提供するイベントプッシュサービスの提供を受けるために、プッシュサービスの加入要請をユビキタス通知サーバ３３０の加入ゲートウェイ３３５に送信する（Ｓ１２）。これにより、加入ゲートウェイ３３５が各サービスに連係した少なくとも１つのチャネルリストを送信すれば（Ｓ１３）、ユーザ端末３４０はチャネルリストのうちからイベントメッセージがプッシュされようとするチャネルを選択し、選択したチャネルに対する選択情報と、端末に対するユーザ情報（ユーザＩＤ、パスワード、端末固有番号、端末機種など）などの加入者情報を加入ゲートウェイ３３５にフィードバックする（Ｓ１４）。
【００８２】
これにより、加入ゲートウェイ３３５は、ユーザ端末３４０に提供された加入者情報を加入者データベース３３６に格納して管理する（Ｓ１５）。
【００８３】
ユーザ端末３４０は、選択したチャネルと関連したＵＥＤファイルを有しているか否かを判断し（Ｓ１６）、無ければディレクトリ管理部３３３に自身の端末仕様に適合したＵＥＤファイル要請を送信する（Ｓ１７）。これにより、ディレクトリ管理部３３３からＵＥＤファイルをダウンロードし（Ｓ１８）、ＵＥＤファイルを所定のメモリ３４３に格納して管理することができる（Ｓ１９）。ユビキタス通知サーバ３３０のディレクトリ管理部３３３は、通知クライアント３４２のＵＥＤファイル要請時に端末機種などを参照し、これに適合したＵＥＤファイルを加入者端末に送信することができ、または、通知クライアント３４２を介して加入者端末の加入者が指定するデータタイプに適するように、適合したＵＥＤファイルを加入者端末に送信することができる。
【００８４】
この後、サービスプロバイダ３２０によって提供されるサービスにイベントが発生すれば（Ｓ２０）、サービスプロバイダ３２０は、該当イベントをユビキタス通知サーバ３３０のイベントゲートウェイ３３１にプッシュする（Ｓ２１）。このとき、上述したように、ＵＥＤファイルに定義されたデータタイプのバイナリプロトコルによる形態でイベントをプッシュすることができ、また、ＸＭＬ形態でイベントをプッシュすることも可能である。
【００８５】
本発明の一実施形態において、イベントがプッシュされる場合に、プッシュされるイベントと共に加入者端末リストを受信することができる。これにより、ユビキタス通知サーバ３３０は、ブローカ３３２を介して、ユーザ端末３４０のうちで加入者端末リストに記載されている加入者端末にリアルタイムで該当イベントに対するメッセージを送信する（Ｓ２２）。
【００８６】
このとき、ブローカ３３２は、各ユビキタス加入者端末の多様な形態を区分して、ＴＣＰ／ＩＰまたはＳＭＳ基盤の方式など該当端末がサポートする通信方式でイベントメッセージを送信することができる。ブローカ３３２は、このようなイベントメッセージの送信において、各加入者端末の多様な形態を区分せずにＸＭＬ形態のデータ（ペイロード）にイベントメッセージを含ませて送信することもできるが、加入者端末の小規模な資源を考慮するとき、各加入者端末の多様な形態を区分して、該当端末がサポートするＵＥＤファイルのデータタイプ（図９参照）に定義されたバイナリプロトコルによってデータにイベントメッセージを含ませて送信することが好ましい。
【００８７】
ブローカ３３２は、各サービスに対してイベントが属するドメインを示すチャネル単位でイベントを管理することにより、チャネル単位で加入者端末にイベントメッセージを送信することができる。ブローカ３３２は、チャネルの下位に少なくとも１つのサブチャネルが含まれた場合には、イベントメッセージをサブチャネルに加入したすべての端末に送信することができる。また、ブローカ３３２は、個人などを示す予め定められた区分者が含まれたユーザＩＤがチャネルに含まれている場合、該当ユーザＩＤに対応するユーザ端末にのみイベントメッセージが送信されるようにイベントを管理し、該当ユーザＩＤに対応するユーザ端末にのみイベントメッセージが送信されないようにイベントを管理する。
【００８８】
上述の加入者情報により該当チャネルに対するイベントメッセージを受信する加入者端末は、ＸＭＬ形態でイベントメッセージを受信することもできるが、特に、ＵＥＤファイルで指定するデータタイプのバイナリプロトコルによるデータで該当イベントメッセージを受信することができる。
【００８９】
加入者端末は、通知クライアント３４２を介してブローカ３３２から受信するイベントメッセージの信号を解釈することにより、ユーザインターフェース３４１に該当メッセージを表示することができる。通知クライアント３４２は、ＸＭＬ形態のイベントメッセージがユーザインターフェース３４１を介して表示すように処理することもできるが、特に、テンプレートパーサ３４４を用いて、ＵＥＤファイルに含まれているテンプレートによってメッセージ表示形式を変換することができる（Ｓ２３）。テンプレートパーサ３４４は、サービスまたはチャネル別に所定のメモリ３４３にデータベース化されたＵＥＤファイルのうちから受信されたイベントメッセージに対応するＵＥＤファイルを抽出し、ＵＥＤファイルに含まれているテンプレートを解析することにより、ＵＥＤファイルのテンプレートに基づいた形態でメッセージ形式を変換することができる。これにより、多様なイメージやフォントなどを含むメッセージを表示することができる。
【００９０】
以上で詳述した本発明により、ユーザ端末３４０は、予め定められた規格によってイベントメッセージを出力できるだけでなく、ＵＥＤファイルによってプロトコルを分析し、自身の端末に適合したイベントを要請してサービスを受けることができる。これにより、多様なユビキタス端末で電子メール、最新書き込み、メッセージ、コメント通知などの単純なアラート（ａｌｅｒｔ）機能を提供するだけでなく、金融、電子商取引、ショッピング、及びイベントをモニタリングするための地域情報などの適時イベント、統計、詳細情報への連結、または再連動イベントの企画などに関連することにより、ユビキタス端末の製造会社や第３者などが異なるレベルの差別化されたサービスを提供できる。
【００９１】
なお、本発明で開示された方法およびシステムで用いられる機能は、コンピュータにより実現される多様な動作を実行するためのプログラム命令を含むコンピュータ読取可能な記録媒体を含む。当該コンピュータ読取可能な記録媒体は、コンピュータシステムにより読み取り可能なデータを格納する全ての種類の記録媒体が含まれる。コンピュータ読取可能な記録媒体の例としては、フロッピー（登録商標）ディスク及び磁気テープのような磁気媒体、ＣＤ−ＲＯＭのような光記録媒体、およびＲＯＭ、ＲＡＭなどのようなプログラム命令を保存して実行するように特別に構成されたハードウェア装置が含まれる。また、記録媒体は、搬送波（例えば、インターネットを介した送信）の形態で実装してもよい。さらに、記録媒体は、配布された方法でプログラム命令が格納されて実行されるように、ネットワークを介して接続されたコンピュータシステムに配布される。
【産業上の利用可能性】
【００９２】
上述したように、本発明に係るユビキタス通知方法およびシステムでは、加入者リストを中継プラットホームで管理し、サービスプロバイダからの各サービスのイベントなどを１つの経路を介して集積して統合管理し、３Ａ基盤でいつどこででもデバイスに関係なく提供することにより、プッシュ型イベントが提供される加入者は自身のイベントプロフィールを一括して管理することができ、サービスプロバイダはイベントプッシュサービスの加入権限を一貫したインターフェースで提供することができる。
【００９３】
また、本発明に係るユビキタス通知方法およびシステムでは、ユビキタスユーザ端末に対応する適切なブローカコネクションとサービスプロバイダがサービス種類、イベント種類、およびイベントのフォーマットと意味などを登録するディレクトリを運営し、どのような形態のユーザ端末であっても、ディレクトリを参照してイベントプッシュサービスを受けることができる。これにより、サービス提供者の立場では、サービス企画によって多様なイベントを創出して提供することが可能となり、ユーザは、サービスの変更時にクライアントをアップグレードする処理することなく、自動でイベントメッセージの提供を受けることができるという便利さを有する。
【００９４】
また、本発明に係るユビキタス通知方法およびシステムでは、サービスプロバイダでピークタイムに多量のイベントが発生したとしても、中継プラットホームに集積されて統合管理されるイベントをサービス別またはイベント別に分散処理又は並列処理し、サーバの超大容量のトランザクションの処理性能に制約がないようにすることにより、サービスプロバイダは、提供しようとするすべての形態のイベントを、その量に関係なくユーザに提供することができる。
【００９５】
また、本発明に係るユビキタス通知方法およびシステムでは、上述したような技術が既存に提供されたレガシーサービスの小さな変更のみによって実現されるようにすることにより、ユビキタスデバイスに適合した統合型プッシュサービスを提供することができ、ユーザがサービスにより密着することができるユビキタス連結環をユーザに提供し、サービス自体の発展にも大きく寄与することができる。
【００９６】
さらに、本発明に係るユビキタス通知方法およびシステムでは、ユーザ端末が予め定められた規格によってイベントメッセージを出力できるだけではなく、ＵＥＤファイルによってプロトコル自体を分析でき、自身の端末に適合した必要なイベントを用いることができるため、多様なユビキタス端末で電子メール、新しい書き込み、メッセージ、コメント通知などの単純なアラート機能を用いることができるだけでなく、金融、電子商取引、ショッピング、及びイベントをモニタリングするための地域情報などの適時イベント、統計、詳細情報への連結、再連動イベントの企画などに関連することにより、ユビキタス端末の製造会社や第３者などが異なるレベルの差別化されたサービスを提供することができる。
【００９７】
上述したように、本発明の好ましい実施形態を参照して説明したが、該当する技術分野において熟練した当業者は、特許請求の範囲に記載された本発明の思想および領域から逸脱しない範囲内で、本発明を多様に修正および変更させることができることを理解することができるであろう。すなわち、本発明の技術的範囲は、特許請求の範囲に基づいて定められ、発明を実施するための最良の形態により制限されるものではない。
【図１】
2010527480.tif 000003
【図２】
2010527480.tif 000004
【図３】
2010527480.tif 000005
【図４】
2010527480.tif 000006
【図５】
2010527480.tif 000007
【図６】
2010527480.tif 000008
【図７】
2010527480.tif 000009
【図８】
2010527480.tif 000010
【図９】
2010527480.tif 000011
【図１０】
2010527480.tif 000012
【国際調査報告】
2010527480.tif 000013
2010527480.tif 000014