(57)【要約】  本発明は、受信者に対して、サーバシステム内で支払いサービス及び通信サービスの少なくとも１つを実行するよう構成されるサーバシステムにおいて混合されたコンピュータ実装された支払いサービス及び通信サービス方法に関する。方法は、受信者の公の固有の識別子を受信し、受信者がサーバシステムの支払いサービス及び通信サービスの少なくとも１つを使用するか判断することが含まれる。支払いメッセージが受信され、支払いサービスは、受信者がサーバシステムの支払いサービスを使用する場合、支払いアドレス識別子として公の固有の識別子を用いて実行される。また、通信形式メッセージが受信され、通信サービスは、受信者がサーバシステムの通信サービスを使用する場合、通信アドレス識別子として公の固有の識別子を用いて実行される。
2010518506.tif 000002
【特許請求の範囲】
【請求項１】
サーバシステム内で受信者に関する支払いサービス及び通信サービスの少なくとも１つを実行するよう構成されるサーバシステムにおいて混合されたコンピュータ実装された支払いサービス及び通信サービス方法であって、
前記受信者の公の固有の識別子を受信する段階と、
前記受信者が前記サーバシステムの前記支払いサービス及び前記通信サービスの前記少なくとも１つを使用したかを判断する段階と、
支払いメッセージを受信し、前記受信者が前記サーバシステムの前記支払いサービスを使用する場合、支払いアドレス識別子として前記公の固有の識別子を用いて前記支払いサービスを実行する段階と、
通信形式メッセージを受信し、前記受信者が前記サーバシステムの前記通信サービスを使用する場合、通信アドレス識別子として前記公の固有の識別子を用いて前記通信サービスを実行する段階と
を具備することを特徴とする方法。
【請求項２】
前記通信形式メッセージは、電話通信を示し、前記公の固有の識別子を用いて前記受信者のユーザ装置への電話接続を要求する段階を具備することを特徴とする請求項１に特徴の方法。
【請求項３】
前記通信形式メッセージは、電子メッセージ通信を示し、前記公の固有の識別子を用いて前記受信者のユーザ装置に電子メッセージを送信する段階を具備することを特徴とする請求項１又は２に記載の方法。
【請求項４】
前記通信形式メッセージは、ウェブ通信を示し、前記公の固有の識別子を用いて前記受信者からウェブページ及びストリーミングメディアの少なくとも１つを要求する段階を具備することを特徴とする上記請求項に記載の方法。
【請求項５】
支払いアドレス識別子及び通信アドレス識別子の少なくとも１つに前記公の固有の識別子を変換する段階を具備することを特徴とする上記請求項に記載の方法。
【請求項６】
前記支払いアドレス識別子を用いて前記支払いサービスを実行するために外部支払いシステムに接続する段階、又は
前記通信アドレス識別子を用いて前記通信サービスを実行するために外部通信システムに接続する段階
をさらに具備することを特徴とする請求項５に記載の方法。
【請求項７】
支払い装置又は通信装置からログイン要求を受信する段階をさらに具備し、前記ログイン要求は、少なくとも１つの個人識別子を具備することを特徴とする上記請求項に記載の方法。
【請求項８】
少なくとも１つの前記ログイン要求は、安全な方法で前記サーバシステムにネットワーク上で送信されることを特徴とする請求項７に記載の方法。
【請求項９】
ユーザ装置から少なくとも第１の要求及び後続の第２の要求を受信する段階と、
前記後続の第２の要求に用いるために、前記第１の要求に用いる第１のセッションキーと、前記第１のセッションキーとは異なる第２のセッションキーとを発する段階と
をさらに具備すること特徴とする上記請求項に記載の方法。
【請求項１０】
前記サーバシステムは、前記受信者の要求リストと前記支払いサービス及び／又は前記通信サービスのユーザのプロフィールとを少なくとも具備し、前記要求リストは、前記プロフィールの項目に関する少なくとも１つの基準を具備し、
前記ユーザの装置から前記受信者の前記公の固有の識別子を受信する段階と、
前記受信者の前記受信された公の固有の識別子を用いて前記受信者の前記要求リストを追跡する段階と、
前記プロフィールの前記項目が前記要求リストの前記少なくとも１つの基準を満たすかをチェックする段階と、
前記項目が前記基準を満たさない場合、前記支払いサービス及び前記通信サービスの少なくとも１つを否定する段階と
をさらに具備することを特徴とする上記請求項に記載の方法。
【請求項１１】
前記サーバシステムは、前記サーバシステムのユーザの第１のプロフィール及び第１の要求リストと、前記受信者の第２のプロフィール及び第２の要求リストとを少なくとも具備し、前記第１のプロフィール及び第２のプロフィールは、少なくとも１つのユーザ項目及び少なくとも１つの受信者項目を各々具備し、前記第１の要求リスト及び前記第２の要求リストは、前記ユーザの少なくとも１つのユーザ基準及び前記受信者の少なくとも１つの受信者基準を各々具備し、前記方法は、
前記ユーザの装置から前記受信者の前記公の固有の識別子を受信する段階と、
前記ユーザの前記第１の要求リストを追跡する段階と、
前記受信者の前記受信された公の固有の識別子を用いて前記受信者の前記第２の要求リストを追跡する段階と、
前記第１のプロフィールの前記少なくとも１つのユーザ項目が前記第２の要求リストの前記少なくとも１つの受信者基準を満たすかチェックする段階と、
前記第２のプロフィールの前記少なくとも１つの受信者項目が前記第１の要求リストの前記少なくとも１つのユーザ基準を満たすかチェックする段階と、
前記第１のプロフィールの前記ユーザ項目の少なくとも１つが前記第２の要求リストの前記受信者基準を満たさず、前記受信者プロフィールの前記受信者項目が前記第１の要求リストの前記ユーザ基準を満たさない場合、前記支払いサービス及び前記通信サービスの少なくとも１つを否定する段階と
をさらに具備することを特徴とする請求項１〜９に記載の方法。
【請求項１２】
他のログインデータ又は前記受信者の装置から受信される前記ユーザの公の固有の識別子を用いて前記ユーザの前記第１の要求リストを追跡する段階を具備することを特徴とする請求項１１に記載の方法。
【請求項１３】
前記基準は、前記ユーザ及び／又は前記受信者の前記公の固有の識別子から独立していることを特徴とする請求項１０〜１２に記載の方法。
【請求項１４】
前記少なくとも１つの項目は、システム項目及び／又はユーザ定義項目を具備することを特徴とする請求項１０〜１３に記載の方法。
【請求項１５】
システム項目は、スパム関連項目であることを特徴とする請求項１４に記載の方法。
【請求項１６】
前記（複数の）プロフィールの前記項目は、確認済項目及び未確認項目を具備することを特徴とする請求項１０〜１５に記載の方法。
【請求項１７】
前記サーバシステムは、前記要求リストの前記少なくとも１つの基準が前記プロフィールの確認済項目に関する確認指示を前記ユーザの装置及び前記受信者の装置の少なくとも１つから受信することを特徴とする請求項１６に記載の方法。
【請求項１８】
前記項目の１つ以上は、チェックされることが防止され、随意的に、前記サーバシステムは、前記プロフィールの１つ以上の項目がチェックされることから防止されることを示すチェック防止指示を前記ユーザの装置及び前記受信者の装置の少なくとも１つから受信することを特徴とする請求項１０〜１７に記載の方法。
【請求項１９】
チェック防止指示を適用するユーザ又は受信者の装置に通知要求を送信する段階を具備し、前記通知要求は、前記チェック防止指示を無視して要求リストの対応基準に対する前記少なくとも１つの項目のチェックを許可するオプションを提供することを特徴とする請求項１０〜１８に記載の方法。
【請求項２０】
電子システム上にインストール及びそれによって実行される時、請求項１〜１９に記載の方法を実行するよう適合されるソフトウェアコード部分を具備することを特徴とするコンピュータプログラム。
【請求項２１】
請求項２０のコンピュータプログラムを含むことを特徴とするキャリア。
【請求項２２】
支払い及び通信サービスを提供し、受信者への支払いサービス及び通信サービスの少なくとも１つを前記システム内で実行するよう構成されるシステムであって、
前記受信者の公の固有の識別子を受信するよう構成される公の固有の識別子受信機と、
前記受信者が前記少なくとも１つの前記支払いサービス及び前記通信サービスを使用するかを判断するよう構成される判断モジュールと、
前記受信者が前記サーバシステムの前記支払いサービスを使用する場合、支払いアドレス識別子として前記公の固有の識別子を用いて前記受信者に支払いを実行するために支払いサービスを実行するよう構成される支払いサービスモジュールと、
前記受信者が前記サーバシステムの前記通信サービスを使用する場合、通信アドレス識別子として前記公の固有の識別子を用いて前記受信者への通信を構築するために通信サービスを実行するよう構成される通信サービスモジュールと
を具備することを特徴とするシステム。
【請求項２３】
要求された通信の形式を示す通信形式メッセージを受信するよう構成される通信形式メッセージ受信機をさらに具備し、前記通信サービスモジュールは、前記通信形式メッセージに依存した通信サービスを要求又は実行するよう構成されることを特徴とする請求項２２に記載のシステム。
【請求項２４】
前記通信形式メッセージは、電話通信を示し、前記通信サービスモジュールは、前記公の固有の識別子を用いて前記受信者のユーザ装置への電話接続を構築するよう構成されることを特徴とする請求項２３に記載のシステム。
【請求項２５】
前記通信形式メッセージは、電子メッセージ通信を示し、前記通信サービスモジュールは、前記公の固有の識別子を用いて前記受信者のユーザ装置に電子メッセージを送信するよう構成されることを特徴とする請求項２３又は２４に記載のシステム。
【請求項２６】
前記通信形式メッセージは、ウェブ通信又はストリーミングメディアの少なくとも１つを示し、前記通信サービスモジュールは、前記公の固有の識別子を用いて前記受信者からウェブページ又はストリーミングビデオを要求するよう構成されることを特徴とする請求項２３〜２５に記載のシステム。
【請求項２７】
前記システムは、支払いアドレス識別子及び通信アドレス識別子の少なくとも１つに前記公の固有の識別子を変換するよう構成される変換装置をさらに具備することを特徴とする請求項２２〜２６に記載のシステム。
【請求項２８】
前記支払いアドレス識別子を用いて前記支払いサービスを要求するために外部支払いシステムに接続するための支払い接続モジュールと、
前記通信アドレス識別子を用いて前記通信サービスを要求するために外部通信システムに接続するための通信接続モジュールと
をさらに具備することを特徴とする請求項２７に記載のシステム。
【請求項２９】
ユーザ装置からログイン要求を受信するよう構成されるログインモジュールをさらに具備し、前記ログイン要求は、少なくとも１つの個人識別子を具備することを特徴とする請求項２２〜２８に記載のシステム。
【請求項３０】
前記ログインモジュールは、安全な方法で前記ログイン要求を受信するよう構成されることを特徴とする請求項２９に記載のシステム。
【請求項３１】
可変セッションキー発行装置をさらに具備し、前記システムは、ユーザ装置から少なくとも第１の要求及び後続の第２の要求を受信するよう構成され、前記可変セッションキー発行装置は、前記第１の要求に用いる第１のセッションキーと、前記第１のセッションキーとは異なる、前記後続の第２の要求に用いる第２のセッションキーとを発するよう構成されることを特徴とする請求項２２〜３０に記載のシステム。
【請求項３２】
前記公の固有の識別子受信機は、前記ユーザの装置から前記受信者の前記公の固有の識別子を受信するよう構成され、前記システムは、
前記受信者の要求リストと前記支払いサービス及び／又は前記通信サービスのユーザのプロフィールとを格納する格納モジュールであって、前記要求リストは、前記プロフィールの項目に関する少なくとも１つの基準を具備する、格納モジュールと、
前記受信者の前記受信された公の固有の識別子を用いて前記受信者の前記要求リストを追跡するよう構成される追跡装置と、
前記プロフィールの前記項目が前記要求リストの前記少なくとも１つの基準を満たすかをチェックするよう構成される分析装置と
を具備し、前記支払いサービスモジュール及び通信サービスモジュールの少なくとも１つは、前記項目が前記基準を満たさない場合、前記支払いサービス及び前記通信サービスを各々否定するよう構成されることを特徴とする請求項２２〜３１に記載のシステム。
【請求項３３】
前記公の固有の識別子受信機は、前記ユーザの装置から前記受信者の前記公の固有の識別子を受信するよう構成され、前記システムは、
前記システムのユーザの第１のプロフィール及び第１の要求リストと、前記受信者の第２のプロフィール及び第２の要求リストとを少なくとも格納する格納モジュールであって、前記第１のプロフィール及び第２のプロフィールは、少なくとも１つのユーザ項目及び少なくとも１つの受信者項目を各々具備し、前記第１の要求リスト及び前記第２の要求リストは、前記ユーザの少なくとも１つのユーザ基準及び前記受信者の少なくとも１つの受信者基準を各々具備する、格納モジュールと、
前記第２の要求リストを追跡するための前記受信者の前記受信された公の固有の識別子を用いて、前記受信者の前記第１の要求リスト及び前記第２の要求リストを追跡するよう構成される追跡装置と、
前記第１のプロフィールの前記少なくとも１つのユーザ項目が前記第２の要求リストの前記少なくとも１つの受信者基準を満たすかをチェックし、及び前記第２のプロフィールの前記少なくとも１つの受信者項目が前記第１の要求リストの前記少なくとも１つのユーザ基準を満たすかをチェックするよう構成される分析装置と
を具備し、前記支払いサービスモジュール及び通信サービスモジュールの少なくとも１つは、前記第１のプロフィールの前記ユーザ項目の少なくとも１つが前記第２の要求リストの前記受信者基準を満たさず、前記受信者プロフィールの前記受信者項目が前記第１の要求リストの前記ユーザ基準を満たさない場合、前記支払いサービス及び前記通信サービスの少なくとも１つを否定するよう構成されることを特徴とする請求項２２〜３２に記載のシステム。
【請求項３４】
公の固有の識別子受信機は、前記受信者の装置から前記ユーザの公のユーザ識別子を受信するよう構成され、前記追跡装置は、他のログインデータ又は前記ユーザの前記公のユーザ識別子に基づき前記第１の要求リストを追跡するよう構成されることを特徴とする請求項３３に記載のシステム。
【請求項３５】
前記基準は、前記ユーザ及び／又は前記受信者の前記公の固有の識別子から独立していることを特徴とする請求項３２〜３４に記載のシステム。
【請求項３６】
前記少なくとも１つの項目は、システム項目及び／又はユーザ定義項目を具備することを特徴とする請求項３２〜３５に記載のシステム。
【請求項３７】
システム項目は、スパム関連項目であることを特徴とする請求項３６に記載のシステム。
【請求項３８】
前記プロフィールの前記項目は、確認済項目及び未確認項目を具備することを特徴とする請求項３２〜３７に記載のシステム。
【請求項３９】
前記ユーザの装置及び前記受信者の装置の少なくとも１つから確認指示を受信及び処理するよう構成される確認指示受信機をさらに具備し、前記確認指示は、前記要求リストの少なくとも１つの基準が前記プロフィールの確認済項目に関することを示すことを特徴とする請求項３８に記載のシステム。
【請求項４０】
前記システムは、チェックされることから防止される少なくとも１つの項目を格納し、随意的に、前記ユーザの装置及び前記受信者の装置の少なくとも１つからチェック防止指示を受信及び処理するよう構成されるチェック防止指示受信機をさらに具備し、前記チェック防止指示は、前記プロフィールの１つ以上の項目が前記分析装置によってチェックされることから防止されることを示すことを特徴とする請求項３２〜３９に記載のシステム。
【請求項４１】
前記システムは、チェック防止指示を適用するユーザ又は受信者の装置に通知要求を送信するよう構成される通知送信機をさらに具備し、前記通知要求は、前記チェック防止指示を無視して要求リストの対応基準に対する前記少なくとも１つの項目のチェックを許可するオプションを提供することを特徴とする請求項３２〜４０に記載のシステム。
【請求項４２】
請求項２２〜４０に記載のシステム及び請求項１〜１９に記載の方法を用いることを特徴とする装置。
【請求項４３】
前記装置は、前記公の固有の識別子を用いてアドレス可能であることを特徴とする請求項４２に記載の装置。
【請求項４４】
請求項２２〜４０に記載のシステム及び請求項１〜１９に記載の方法を用いて公の固有の識別子を示すことを特徴とする接触カード。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、電子支払い及び通信サービスの分野に関する。具体的に、本発明は、サーバシステムにおいて混合されたコンピュータ実装された支払いサービス及び通信サービス方法に関し、受信者に金銭の支払い及び／又は前記同一の受信者への通信の構築を可能にするよう構成される。
【背景技術】
【０００２】
電子サービスのための通信装置の使用は、ここ２０年の間かなり一般的になっている。携帯電話及び電子銀行は、人々の日々の生活にかなり浸透している電子サービスの例である。他の例は、情報を持つウェブページの訪問、電子友人ネットワークへの参加、及びウェブ討論への寄稿のような、電子メール及びインターネットの使用を含む。
【０００３】
電子サービスの可能性が高まると、人々がこれら電子サービスを利用するために所有する必要のある情報量をかなり伴う。典型例として、ある人が電話で他の人に連絡するための電話番号、この同じ人に電子メールを送信するための電子メールアドレス、この人のウェブサイトを訪問するためのユーアールエル（ＵＲＬ）、及びこの人の銀行口座へ金銭を送金するための銀行口座番号等を知る必要がある。
【０００４】
他方で、人々は、全てのこれら詳細な連絡先を公衆に開示したくない。電話番号及び銀行口座番号のような一部の詳細な連絡先は、ほとんどの人々に対して秘密を保つのが好ましい一方で、ウェブサイトのＵＲＬのような他の詳細な連絡先は、できるだけ多くの人々に伝えることが許可される。
【０００５】
ＥＮＵＭイニシアチブ（www.enum.nl）により例示されるように、電話機のサービス、インターネットサービス、および支払いサービスを得るために単一の電話番号を使用することは、従来から知られている。電話番号は、処理され、サービスは、処理の後に要求される。
【０００６】
しかし、改善された支払い及び通信方法及びシステムを提供することが従来から必要であった。
【発明の概要】
【課題を解決するための手段】
【０００７】
混合されたコンピュータ実装された支払いサービス及び通信サービス方法が提供される。方法は、受信者に対してサーバシステム内で支払いサービス及び通信サービスの少なくとも１つを実行するよう構成されるサーバシステムで実行される。方法は、受信者の公の固有の識別子を受信し、受信者がサーバシステムの支払いサービス及び通信サービスの少なくとも１つを使用するかを判断する段階を含む。支払いメッセージは、受信され、支払いサービスは、受信者がサーバシステムの支払いサービスを使用する場合、支払いアドレス識別子として公の固有の識別子を用いて実行される。通信形式メッセージはまた、受信されることができ、通信サービスは、受信者がサーバシステムの通信サービスを使用する場合、通信アドレス識別子として公の固有の識別子を用いて実行される。
【０００８】
また、方法及びキャリアを実行するためのコンピュータプログラムが故に提供される。
【０００９】
出願人はまた、受信者に金銭の支払いを行い、受信者への接続を構築するために、支払い及び／又は通信サービスを提供するよう構成されるシステムを提供する。システムは、受信者の公の固有の識別子を受信するよう構成される公の固有の識別子受信機と、受信者が少なくとも１つの支払いサービス及び通信サービスを使用するか判断するよう構成される判断モジュールとを具備する。また、支払いサービスモジュール及び／又は通信サービスモジュールが提供される。支払いサービスモジュールは、受信者がサーバシステムの支払いサービスを使用する場合、支払いアドレス識別子として公の固有の識別子を用いて受信者に支払いを実行するための支払いサービスを実行するよう構成される。通信サービスモジュールは、受信者がサーバシステムの通信サービスを使用する場合、通信アドレス識別子として公の固有の識別子を用いて受信者への通信を構築するための通信サービスを実行するよう構成される。
【００１０】
最後に、電子装置、そのような装置のためのコンピュータプログラム、及び接触カードは、上記定義されたＰＵＩＤを用いて提供される。
【００１１】
単一のＰＵＩＤは、支払いサービス及び少なくとも１つの通信サービス、例えば電話機（請求項２及び２４、ＩＰ電話機を含む）、電子メッセージ（請求項３及び２５）及びウェブ閲覧及びストリーミングメディア（請求項４及び２６）に使用されることができる。単一のＰＵＩＤは、簡単に覚えることができ、サービスの混合に使用されることができる。ＰＵＩＤは、公の識別子を定義することによる。ＰＵＩＤは、全サービスのために外部システムを要求する従来のＥＮＵＭイニシアチブとは反対に、システム内でサービスを提供するのに使用されることができる。支払いアドレス識別子又は通信アドレス識別子としてＰＵＩＤを使用することは、ＰＵＩＤ自体の使用と支払い又は通信識別子へのＰＵＩＤの変換との両方を含む。
【００１２】
方法及びシステムは、ＰＵＩＤの公の利用可能性が、以下により詳細に説明するように、例えば望まれない電話連絡又はある銀行口座番号の知得をもたらさないように構成されることができる。支払い及び通信サービスは、単一の装置によって享受されることができる。
【００１３】
ＰＵＩＤは、（アルファ）数字的なシンボルの任意の組合せでもよい。しかし、大量の固有のＰＵＩＤを得るためには、５又は６文字（大文字及び小文字の両方）の使用で十分にすることもできる。受信されたＰＵＩＤは、プライバシーを考慮して、基準的な通信識別子（電話アドレス又は電子メールアドレス等）又は支払いアドレス識別子（銀行口座番号等）でないのが好ましい。即ち、ＰＵＩＤは、受信者の装置に直接接続できず、及び／又は受信者の銀行口座に支払いを行えない。
【００１４】
システムによって実行される支払いサービスの場合、各参加者は、別個の銀行口座番号を有することが要求されないことが分かる。システムは、金銭の単一仮想量を含み、各参加者は、例えばその参加者に対してフラグを設定することによって、その量の部分に対して資格があるとして識別されることができる。参加者間の金銭の授受は、このようにして簡単に整えることができる。
【００１５】
本発明は、カード、ＡＴＭ、ＲＦＩＤ技術を用いた携帯電話による支払い等のような、支払いの他の形式を行う新規的で進歩的な支払いシステムの可能性を有する。本発明によりユーザは、他の通信サービスにも使用されることができる支払いサービスを用いるために携帯電話を使用することができる。ＵＲＬもまた、ウェブ閲覧にとってもはや不必要にすることができる。
【００１６】
請求項５及び２７の実施形態は、個人的連絡情報（銀行口座番号及び電話番号、電子メッセージアドレス、及びＵＲＬ等）がサーバシステム内でのみ知られ、このシステム外に知られる必要がないという利点を提供する。サービス形式に依存して単一のＰＵＩＤをそのような個人連絡情報に変換することにより、人々は、これら個人の詳細を知ることなく、支払いサービス及び／又は通信サービスを使用することができる。請求項６及び２８に従って外部支払いサービス及び／又は外部通信サービスに接続することができる。これらサービスは、サーバシステム外に提供される。実施形態により、サーバシステムの迅速な導入を可能にするだけでなく、人々は、外部通信企業及び民間銀行のサービスを用いることもできる。
【００１７】
ユーザ及び／又は受信者及び／又はプロバイダは、サーバシステムから、又は外部システムからサービスを使用することを望むかをサーバシステムで自分によって示すことができる。
【００１８】
請求項７及び２９の実施形態により、サーバシステムの使用者の識別を可能にする。識別は、ユーザ名及びパスワードの組合せを含むのが好ましい。
【００１９】
請求項８及び３０の実施形態は、システムのユーザの身元が検索(sniff)される機会を低減する。
【００２０】
請求項９及び３１の実施形態は、第３者によるユーザ及びサーバシステム間の進行中のセッションの占拠によって、システムが妨害される機会を低減する。セッションキーの変化により、ユーザ及びサーバシステム間におけるデータ通信の暗号化の変化を可能にする。
【００２１】
システムのユーザは、他人を例えば電話番号に基づきブラックリスト化又はホワイトリスト化することによって、他人が自分に通信することを、各々否定又は許可することが従来から知られている。一例として、ＵＳ２００６／０１４７０１４が提供される。また、マイクロソフトのＭＳＮウェブ変換プラットフォームにより、連絡の遮断が可能である。また、出願人の未公開国際特許出願ＰＣＴ／ＮＬ２００７／０５０５５３が出願されており、個人識別子の使用が記載されている。しかし、これら方法及びシステムについてはむしろ詳しくなく、単に人々が装置識別子又は個人識別子に基づき互いに通信するか否かを可能にしている。請求項１０〜１９及び請求項３２〜４１の実施形態は、以下の図の記載から明らかなように、他人から及び／又はそこへの支払い、及び／又は他人との通信をするために満たされるべき基準を用いて細かい調節を可能にするシステムを提供する。プロフィールの項目及び要求リストの基準は、システムによって設定されることができ、及び／又は生成されることができ、及び／又はユーザ／受信者によって記入されることができる。本発明は、サービスへの接続を構築するのに通常無関係な情報（項目及び基準）を用いてサービスを許可又は否定することに関する。異なる項目及び／又は基準は、異なるサービスに対して存在又は適用することができる。参考として、本出願と同日に出願された出願人の同時係属の国際特許出願（Method and system for permitting or denying service）があり、国際出願の内容は、その全体が参照によって本出願中に組込まれている。しかし、同時係属の特許出願は、ＰＵＩＤの使用が要求されていない。
【００２２】
以下、本発明の実施形態がさらに詳しく記載される。これら実施形態は、本発明の保護範囲を限定するとして解釈できないことが明らかである。
【図面の簡単な説明】
【００２３】
【図１】図１は、第１の実施形態による混合された支払い及び通信システム及び電子装置の概略図を示す。
【図２】図２は、図１のシステムに用いるよう構成された電子装置の概略図を示す。
【図３Ａ】図３Ａは、図１のサーバシステムの概略図を示す。
【図３Ｂ】図３Ｂは、図１のサーバシステムの概略図を示す。
【図４Ａ】図４Ａは、プロフィール及び要求リストを具備するサーバシステムに関する状況を示す。
【図４Ｂ】図４Ｂは、プロフィール及び要求リストを具備するサーバシステムに関する状況を示す。
【図５】図５は、第２の実施形態によるサーバシステムの概略図を示す。
【図６】図６は、受信者の接触カードを示す。
【図７】図７は、図１及び図５のシステムを用いて方法の実施形態の段階を示す各種時間図を示す。
【図８】図８は、図１及び図５のシステムを用いて方法の実施形態の段階を示す各種時間図を示す。
【図９】図９は、図１及び図５のシステムを用いて方法の実施形態の段階を示す各種時間図を示す。
【図１０】図１０は、図１及び図５のシステムを用いて方法の実施形態の段階を示す各種時間図を示す。
【図１１】図１１は、図１及び図５のシステムを用いて方法の実施形態の段階を示す各種時間図を示す。
【発明を実施するための形態】
【００２４】
図１は、電子装置２Ａ〜２Ｄに通信可能に接続される混合された支払い及び通信サーバシステム１を示す。携帯電話２Ａ、２Ｂは、無線アクセスネットワーク３を介してサーバシステム１に接続される。固定装置２Ｃ、２Ｄは、インターネット又はローカルエリアネットワークのようなネットワーク４を介してサーバシステム１に接続される。ネットワーク接続は、安全にされることができる。以下では、装置２Ａ、２Ｃは、サーバシステム１のユーザによって使用され、装置２Ｂ、２Ｄは、受信者の装置であると考えられる。
【００２５】
図２に概略的に示される携帯電話２Ａは、複数のキー（数字及び／又はアルファベット）を備えたキーボード１０及びディスプレイ１１を含む携帯電話にすることができる。また、携帯電話２Ａは、通信形式キー１２Ａ、１２Ｂ、１２Ｃ及び支払いキー１２Ｄを含む。通信形式キー１２Ａ〜１２Ｃにより、携帯電話２Ａのユーザは、通話したいか（電話サービス）、電子メッセージを送信したいか（電子メッセージサービス）、又はインターネット上のウェブページを閲覧したいか（ウェブ通信サービス）を選択することができる。支払いキー１２Ｄによりユーザは、支払いサービスを選択することができる。キー１２Ａ〜１２Ｄは、分離したキーの必要がなく、例えば特定の時にソフトキーの機能を示すためにディスプレイ１１を用いて一つ以上のソフトキーによって実装されてもよいことが分かる。また、サービスの選択は、ソフトウェアメニューから行うことができる。また、同一の機能は、固定装置２Ｃに対して可能なことが分かる。最後に、留意すべき点として、装置２Ａ、２Ｃのユーザによって望まれるサービスの形式はまた、サーバシステム１に送信されるメッセージから暗示的（implicit）でもよい。一例として、ユーザ装置２Ａ、２Ｃが金銭の値を送信する場合、支払いサービスを要求することが暗示されてもよい。
【００２６】
図３Ａ及び３Ｂは、サーバシステム１の概略図を示す。
【００２７】
サーバシステム１は、プロセッサ２０、メモリ２１、ネットワーク３、４を介して１つ以上の装置２Ａ〜２Ｄに通信するためのネットワークアダプタ２２、及び関連データベース２３を含む。サーバシステム１は、図１に示す４つより多い電子装置２Ａ〜２Ｄへの接続を通常可能とすることが分かる。
【００２８】
サーバシステム１の特定機能は、図３Ｂで概略的に説明され、ここでさらに詳しく記載される。機能は、プロセッサ２０上で実行される１つ以上のコンピュータプログラムのソフトウェアコード部分として広く実装されてもよいことが分かる。
【００２９】
サーバシステム１は、（複数の）ユーザ装置２Ａ、２Ｃから受信者のＰＵＩＤを受信するよう構成される公の固有の識別子（ＰＵＩＤ）受信機２４を含む。ＰＵＩＤ受信機２４は、（複数の）受信者装置２Ｂ、２ＤからユーザのＰＵＩＤを受信するよう構成されてもよい。
【００３０】
また、サーバシステム１は、ユーザ装置２Ａ、２ＣからＰＵＩＤ受信機２４によって受信される受信者のＰＵＩＤに基づき受信者への支払いを行うために支払いサービスを実行するよう構成される支払いサービスモジュール２５を含む。また、通信サービスモジュール２６が提供され、通信を構築するためにＰＵＩＤ受信機２４によって受信されるＰＵＩＤを用いて受信者への通信を構築するために、電話サービス、電子メッセージサービス、ストリーミングメディアサービス及び／又はウェブ閲覧サービスのような通信サービスを実行するよう構成される。
【００３１】
電子装置２Ａ、２Ｃのユーザによって要求されるサービスの形式を識別するために、サーバシステム１は、携帯電話２Ａ、２Ｃから通信形式メッセージを受信するよう構成される通信形式メッセージ受信機２７を有する。また、通信サービスモジュール２６は、通信形式メッセージに依存して通信サービスを開始するよう構成される。また、要求された通信の形式は、要求における他のデータから推定されることができる。
【００３２】
構成されたメッセージは、（複数の）ユーザ装置２Ａ、２Ｃから受信でき、受信者のＰＵＩＤ、要求されたサービスの形式、及び／又は支払いサービスの金銭値、添付物、及び／又は他のコンテンツのような他のデータを含むことが分かる。
【００３３】
装置２Ａ、２Ｃのユーザは、受信者の電話番号及び銀行口座番号のような特定の連絡情報に気付いていないかもしれない。他方で、受信者は、この連絡情報を秘密に保つことを望むかもしれない。そのためには、サーバシステム１は、ＰＵＩＤを支払いアドレス識別子（例えば、銀行口座番号）及び／又は通信アドレス識別子（例えば、電話番号、電子メールアドレス及び／又はウェブページのＵＲＬ）に変換するよう構成される変換装置２８を含む。支払いアドレス識別子及び通信アドレス識別子は、ＰＵＩＤが受信者への支払いを行うのに、及び／又は例えば同一の受信者に電子メッセージを送信するのに十分なので、装置２Ａ、２Ｃのユーザによって知られる必要が無い。
【００３４】
また、サーバシステム１は、支払いアドレス識別子を用いて支払いサービスを要求するために外部支払いシステムへの接続のための支払い接続モジュール２９と、通信アドレス識別子を用いて通信サービスを要求するために外部通信システムへの接続のための通信接続モジュール３０とを含む。これらモジュール２９、３０は例えば、図５に示す通り、サーバシステム１に対して外部に提供される支払い及び通信サービスを用いて受信者のために使用されることができる。
【００３５】
ＰＵＩＤを基準的な連絡識別子に変換することは、必要ではない。支払いサービスモジュール２５は、支払いアドレス識別子の代わりにＰＵＩＤ自体を用いて支払いサービスを開始するよう構成されることができ（即ち、ＰＵＩＤが銀行口座番号として機能する）、通信サービスモジュール２６は、通信アドレス識別子の代わりにＰＵＩＤ自体を用いて通信サービスを開始するよう構成されることができる（即ち、ＰＵＩＤが電話番号、電子メッセージアドレス及び／又はＵＲＬである）。
【００３６】
サーバシステム１は、受信者がサーバシステム１又は外部システムの支払いサービス及び／又は通信サービスを使用したか判断するよう構成される判断モジュール３１を含む。
【００３７】
また、サーバシステム１は、（複数の）装置２Ａ、２Ｃからログイン要求を受信するためにログインモジュール３４Ａを含む。ログイン要求は、装置２Ａ、２Ｃのユーザを識別するために、少なくとも１つの個人識別子を含む。ユーザは、ユーザ名及びパスワードの組合せによって識別されるのが好ましい。ユーザは、そのような場合にサーバシステム１に対する加入者である。
【００３８】
ユーザ装置２Ａ、２Ｃに対する通信は、例えば安全なネットワーク接続及び／又はデータ暗号化技術によって安全にされることができる。安全性をさらに高めるために、サーバシステムは、可変セッションキー発行装置３４Ｂを含む。可変セッションキー発行装置は、ユーザ装置２Ａ、２Ｃからの後続の要求に応じて異なるセッションキーを発するよう構成される。発行装置３４Ｂは、可変キーを得るために乱数だけでなく外部パラメータ（例えば、特定位置の温度センサによって測定される温度）も使用することができる。
【００３９】
サーバシステム１のデータベース２３は、１つ以上の項目（例えば、ユーザの特徴）を含むプロフィールと、ユーザ装置２Ａ、２Ｃのユーザ及び／又は装置２Ｂ、２Ｄを用いる受信者からの１つ以上の基準を含む要求リストとを格納することができる。サーバシステム１に利用可能なプロフィール及び要求リストを使用して、ユーザ及び／又は受信者は、支払いの取引に参加を希望、及び／又はお互いの間で通信の構築を希望する状況の細かい調節をすることができる。通信を有効及び無効にするこの方法は、有効化又は無効化が装置及び／又はユーザの連絡識別子（ＰＵＩＤ等）に主に基づかない点で従来技術とは異なることが分かる。
【００４０】
そのためには、サーバシステム１は、ユーザ及び／又は受信者の少なくとも１つの要求リストを追跡するよう構成される追跡装置３５を含む。受信者の要求リストは、受信者のＰＵＩＤを用いて追跡されることができる。同じことがユーザの要求リストにも言えるが、このリストはまた、ユーザ装置２Ａ、２Ｃからの要求における他のデータに基づき追跡されることができる。
【００４１】
また、サーバシステム１は、以下にさらに詳しく説明されるように、プロフィールの１つ以上の項目が要求リストの１つ以上の基準を満たすかをチェックするよう構成される分析装置３６を有する。
【００４２】
２つの場合に注目することができる。
【００４３】
第１の場合、図４Ａに示されるように、分析装置３６は、装置２Ａ、２Ｃのユーザのプロフィールの１つ以上の項目と対象となる受信者の適当な対応する基準とを比較するだけである。ユーザプロフィールの項目が受信者要求リストの対応する基準を満たす場合、支払い及び／又は通信が許可され、支払いサービスモジュール２５及び／又は通信サービスモジュール２６が起動される。他方で、項目が基準を満たさない場合、特定の受信者に関してユーザによって支払いサービス及び／又は通信サービスを使用することが否定される。分析のこの形式は、ホワイトリスト化及び／又はブラックリスト化手法に適する。
【００４４】
第２の場合、図４Ｂに示されるように、分析装置３６は、上記比較を行うだけでなく、受信者プロフィールの１つ以上の項目がユーザ要求リストの基準を満たすか否かを分析する。支払い及び／又は通信は、ユーザプロフィールのユーザ項目が受信者要求リストの受信者基準を満たさない場合、及び／又は受信者プロフィールの受信者項目がユーザ要求リストのユーザ基準を満たさない場合、ユーザ及び受信者間で否定される。項目が両方向で基準を満たす場合のみ、支払い／通信が許可される。この場合は、ハンドシェイクの場合、又は相互承認の場合として言及されることができる。
【００４５】
項目及び対応する基準は、年齢、性別、体型（例えば、髪の色、身長）、金融細目、会社細目、地理細目（例えば、住居、出身地、住所、道路、私書箱）、個人項目（例えば、ブランドの好み、社会的な好み（スポーツ、コミュニティ等）の趣向）を含む、連絡識別子ではない、各種個人の詳細に関することができる。項目は、ユーザ定義にすることができる。勿論、個人識別子（ＰＵＩＤ）はまた、ホワイトリスト化、ブラックリスト化及び／又は相互承認手法に使用されることができる。項目によって全基準を満たすことを分析するのが好ましい。
【００４６】
また、項目及び対応する基準は、例えばサーバシステム１上のユーザ及び／又は受信者の振る舞い等、システムに関することができる。一例として、サーバシステムは、このユーザ又は受信者がスパム発信者として通知されている時、ユーザ又は受信者のプロフィールに項目としてスパムフラグを設定することができる。そのような通知の例は、出願人の国際特許出願ＰＣＴ／ＮＬ２００７／０５０５５７及びＰＣＴ／ＮＬ２００７／０５０５５に提供され、それら全体は、参照によって本特許出願中に組込まれている。
【００４７】
簡単に言うと、これら出願は、電子メッセージを配信するための１つ以上のサーバを含むサーバシステムにおける電子メッセージの拡散を低減するシステム及び方法を記載している。方法は、少なくとも１つの電子メッセージ又はその１部を提供し、前記電子メッセージ又はその前記１部に関する少なくとも１つのスパム通知信号を受信することを含む。電子メッセージの１部は例えば、電子メッセージの１つ以上のフィールド又は電子メッセージのフィールド又は特徴に基づき集合された新たな１部を含むことができる。電子メッセージ（及び／又はその１部）及び／又は同一ソースの他の（先の、又は将来の）電子メッセージへのアクセスは、前記少なくとも１つのスパム通知信号の受信に応答して限定される。電子メッセージへのアクセスの制限をもたらすスパム通知信号の数を設定することができる。一例として、電子メッセージへのアクセスが制限される前に、５０、２５、１０、５又は１個のスパム通知信号の数が設定されてもよい。
【００４８】
これに関連して、出願人は、スパムフィルタ開発者によって提供される一組のルールの定期的更新をしても、電子メールスパムメッセージを認識するのに用いる従来の一組のルールは、もはや古いことを分かっている。結局、人間のみが電子メールスパムメッセージを認識することができる。また、出願人は、スパムフィルタの改善は、スパムの全量を低減するよりむしろ増やすのに貢献することを分かっている。従って、出願人は、電子スパムメッセージを検出するためにユーザからのスパム通知信号の使用を（単に）提供し、そのようなスパム通知信号の受信時、他の（ユーザの）ユーザ装置への対応する電子メッセージに対するアクセスを制限する。故に、サーバシステムにより、電子メッセージのそのアドレス自体は、どの電子メッセージがスパムメッセージであるかを判断し、そのメッセージ（同一ソースからの他の先の及び／又は将来の電子メッセージもありうる）への他のアドレスのアクセス（権限）を後続的に判断することを可能にする。即ち、スパム通知信号は、メッセージへのアクセスを制限するための、サーバシステムへの命令である。複数のスパム通知信号の場合、各信号は、部分的な命令としてみなされる。一例として、他の（ユーザの）ユーザ装置は、電子メッセージをディスプレイ又はダウンロードすることができない。一組のスパム認識ルール、スパムパラメータ、及び基準を用いるスパムフィルタは、スパム通知信号が受信された少なくともそれら電子メッセージに関して、サーバシステムにおいて不在でもよい。
【００４９】
スパム通知メッセージは、電子メール以外のサービスに関して設定又は受信されることができ、システム又は受信者／着信先は、ある者がシステムを妨害していることを発見する。
【００５０】
例えば、電話サービスに関して、システム及び方法は、電話システムにおいて第１の加入者装置（Ａ加入者装置）及び第２の加入者装置（Ｂ加入者装置）間で電話接続を構築するよう適用されることができる。電話システムは、Ａ加入者装置（起呼側）及びＢ加入者装置（被呼側）を接続するよう配置される。方法は、Ｂ加入者装置への接続を構築するためにＡ加入者装置から要求を受信し、また前記Ａ加入者装置のユーザの個人識別コードを受信することを含む。接続は、前記Ａ加入者装置の前記ユーザの前記個人識別コードを受信した後のみ、Ａ加入者装置及びＢ加入者装置間で構築されることができる。
【００５１】
ユーザの個人識別コードを受信することによって、電話システムは、使用されている装置を認識することのみに代えて、システムのサービスを要求している人を実際に認識することができる。結果として、電話システムは、受信された認証情報の結果として、装置のみに代えて、特定のユーザに方策（measure）を適用することができる。即ち、特定のユーザに適用される方策は、異なる装置を用いて回避又は迂回されることができない。そのような方策の一例は、電気通信システムのサービスへの特定ユーザのアクセスを制限することでもよい。
【００５２】
スパム通知を作成するために、システム及び方法は、１つ以上のアクセス制限信号の受信を可能にし、１つ以上のアクセス制限信号の受信に応答して、前記Ａ加入者装置の前記ユーザ及び前記Ｂ加入者装置の前記ユーザの少なくとも１つに対して前記電話システム及び前記Ａ加入者装置又は前記Ｂ加入者装置のユーザの少なくとも１つへのアクセスを制限することができる。
【００５３】
Ｂ加入者装置のユーザは、電話コールが求められていないか又は望まれていないとしてＢ加入者装置のユーザによって受信される場合、Ａ加入者装置のユーザに対して電話システムへのアクセスを制限する可能性を有する。アクセスは、Ａ加入者装置のユーザの個人識別コードに基づき制限されるので、このユーザは、異なるＡ加入者装置を用いることによってこの方策を単に迂回することができない。個人識別コードは例えば、コードを所有する人によって接続を構築しようとするさらなる試みが、接続が構築されうる前にこの格納装置に対して先ずチェックされるように、格納されることができる。
【００５４】
電話システムスパム通知方法及びシステムは、出願人の非公開特許出願ＰＣＴ／ＮＬ２００７／０５０５５３の課題であり、その全体が本出願に組込まれている。
【００５５】
スパムに関するシステム項目は、上記方法で設定されることができる。システム及び／又はユーザは、このスパム項目が単一サービス又は複数サービスに関するかを判断することができる。
【００５６】
勿論、ユーザプロフィール又は受信者プロフィールの項目が個人の詳細を適切に反映していない可能性が存在する。例えば、ユーザ又は受信者項目は、実際は４５歳の年寄りの男性であるが、ユーザ又は受信者が２０歳の女性であることを示すことがある。もう１つの例として、ユーザ又は受信者項目は、預金残高が５００００ユーロを下回ることを示すことがあるが、実際は１０００００ユーロを上回る。そのためには、サーバシステム１は、確認済項目及び未確認項目間を区別する。一例として、サーバシステム１が支払いサービス自体を提供する場合、ユーザ又は受信者の預金残高に関する項目は、預金残高がサーバシステム１に記録されるので、内部的に確認されることができる。性別又は年齢のような他の場合、外部登録装置をチェックすることによって確認を実行することができ、項目の有効性を確認するためにパスポート等のコピーを提出するようユーザ及び受信者に要求する。また、年齢又は性別の変化等、項目内の変化を確認することによって未確認項目の確認を実行することができる。年齢は、その時の年と共に上昇して常に変化する一方、性別は、一般に全く変化しない。そのような項目が、期待されない方法で変化する場合、項目は、無制限又は制限的に、未確認として設定されることができる。また、全体のプロフィールは、信用されないとしてマークされうる。
【００５７】
確実性を高めるために、サーバシステム１は、ユーザの装置２Ａ、２Ｃ及び／又は受信者の装置２Ｂ、２Ｄから確認指示を受信及び処理するよう構成される確認指示受信機３７を含む。確認指示を用いて、ユーザ及び／又は受信者は、（複数の）要求リストの１つ以上の基準が（複数の）プロフィールの（複数の）確認済項目に関するべきである、と示すことができる。
【００５８】
項目がサーバシステム１内で安全にされる一方でサーバシステム１の外から要求されることができないが、この人のＰＵＩＤを送信するサーバシステム１に各種要求を行うことによって、原則的に１つ以上の項目、例えばある預金残高の評価を得ることができ、通信／支払いサービスが要求又は実行されるか否かを見ることができる。従って、サーバシステム１は、ユーザ及び／又は受信者のプロフィールの項目が初期設定でチェックすることから防止されるように構成されることができる。また、サーバシステム１は、ユーザの装置２Ａ、２Ｃ及び／又は受信者の装置２Ｂ、２Ｄからのチェック防止指示を受信及び処理するよう構成されるチェック防止指示受信機３８を含む。チェック防止指示は、ユーザ及び／又は受信者からの要求を示し、前記プロフィールの１つ以上の項目が分析装置３６によってチェックされることから防止される。
【００５９】
上記サーバシステム１では、項目は、基準に対してチェックするために利用可能である各種状況が存在する。例として、プロフィールは、（例えば、項目が記入されないか又は存在すらしない時）要求リストの基準に対してチェックするよう要求される項目を含まない状況と、項目は、初期設定によって、又はチェック防止指示信号（先の段落を参照）によってチェックすることから防止される状況とを含む。ユーザ又は受信者が支払い及び／又は通信できるようにするために、サーバシステム１は、例えば装置上のポップアップ画面を用いて、プロフィールからチェックが行われるユーザ又は受信者の装置２Ａ〜２Ｄに通知要求を送信するよう構成される通知送信機３９を含む。通知要求は、例えばチェック防止指示を無視して、要求リストの対応する基準に対して前記少なくとも１つの項目のチェックを許容するオプションを提供することができる。ユーザ／受信者がチェックを許容する場合、防止指示は、装置２Ａ〜２Ｄからそのような命令を受信するサーバシステム１によって永久的又は一時的に解除されることができる。一例として、ユーザが電話によって受信者への通信を望み、受信者の要求リスト上の対応する基準に対してユーザプロフィールリスト上の項目として預金残高がチェックされる時のみ受信者の要求リストが、これが可能であることを示す場合、ユーザは、通信が構築される前に預金残高のチェックを先ず許容するべきである。チェック防止指示の開放は、この情報が他人に通信されることを意味しない。それは単に、要求リストの基準に対してチェックするための項目の利用性を含む。勿論、受信者はまた、例えば商業目的で必要に応じて項目を取除くことができる。
【００６０】
項目及び基準は、サービス選択装置３９Ａを用いて１つ以上のサービスに適用するよう設定されることができる。
【００６１】
図５のサーバシステム１は、複数のサーバ１Ａ〜１Ｃを含む実施形態であり、サーバ機能及び／又はデータは例えば、安全なネットワーク接続４０によって接続される複数のサーバ上で配信される。支払い及び通信サービスの少なくとも１つは、外部システム４１によって実行される。外部システム４１は、ゲートウェイ（図示せず）を介してサーバシステム１に接続されることができる。項目及び基準は、サーバ１Ａ〜１Ｃ上で配信され、サービスの要求時に各種サーバ１Ａ〜１Ｃから取り出される。そのような実施形態は例えば、プライバシー保護に役立つことができる。
【００６２】
ここで、サーバシステム１の動作は、図７〜１１を参照して複数の実際的な状況に関して説明される。
【００６３】
先ず、ビジネス取引は、Ｇｈｉｓｌａｉｎｅ（ユーザ）及びＤｉｒｋ（受信者）間で行われると仮定する。Ｇｈｉｓｌａｉｎｅは単に、図６に示すようなＤｉｒｋの名刺を有する。以下の表は、サーバシステム１のデータベース２３に格納されるＤｉｒｋ及びＧｈｉｓｌａｉｎｅの詳細を示す。
【００６４】
【表１】
2010518506.tif 000003
【００６５】
図７は、Ｇｈｉｓｌａｉｎｅが電話によってＤｉｒｋに連絡を試みる状況を示す。Ｇｈｉｓｌａｉｎｅは、ステップ５０で自分のユーザ名及びパスワードでログインモジュール３４Ａを用いてサーバシステム１にログインする。その後ステップ５１で、Ｇｈｉｓｌａｉｎｅは、ＰＵＩＤ受信機２４によって受信されるＰＵＩＤ“ＤｉＲｋ”を用いて通話を行う。データベースは、Ｄｉｒｋの装置２Ｂに対する別の電話番号を格納せず、判断モジュール３１は、Ｄｉｒｋが（例えば内部コードを用いて）サーバシステム１の電話サービスを使用すると判断する。この状況では、電話接続は、装置がそのような要求を受ける場合、装置２Ｂの電話番号として、ＤｉｒｋのＰＵＩＤ又はその派生物（derivative）を用いて電話サービスモジュール２６を介してステップ５２で行われることができる。この場合、電話装置は、従来のＳＩＭカードを要求しない。しかし、変換装置２８を用いて（システムで利用可能な、例えば表に入力される）従来の電話番号にＰＵＩＤ“ＤｉＲｋ”を変換し、装置２Ｂの従来の電話番号に接続することも可能である。ここで、Ｇｈｉｓｌａｉｎｅ及びＤｉｒｋは、ビジネス取引を議論することができる。
【００６６】
電話の会話において、Ｇｈｉｓｌａｉｎｅは、Ｄｉｒｋの銀行口座に１０００００ユーロの支払いを送金すべきことが議論される。Ｇｈｉｓｌａｉｎｅは、Ｄｉｒｋの銀行口座番号を知らない。
【００６７】
図８では、Ｇｈｉｓｌａｉｎｅは、ステップ６０で装置２Ａを用いて再びログインモジュール３４Ａを用いてサーバシステム１にログインする。勿論、ログインは、サーバシステム１への接続が維持された場合、必ずしも２度要求されない。サーバシステム１は、第１のセッションキーを用いてディスプレイ１１のインタフェースを提供する。Ｇｈｉｓｌａｉｎｅは再び、ステップ６１でＤｉｒｋに支払いを行うためにＰＵＩＤ“ＤｉＲｋ”を入力し、サーバシステム１は、第１のセッションキーとは異なる第２のセッションキーの下で支払い額を入力するためにさらに画面を提供する。１０００００ユーロの支払い額は、ステップ６２でサーバシステム１によって受信される。勿論、支払い額はまた、ステップ６１でサーバシステム１によって、即ち受信者のＰＵＩＤと共に受信されることができる。
【００６８】
判断モジュール３１は、Ｄｉｒｋがサーバシステム１の銀行サービスを使用しないと判断する。なぜなら、Ｄｉｒｋは、表の外部銀行口座番号に記入したからである。この判断に応じて、支払い接続モジュール２９は、ステップ６３で外部銀行システム４１（図５）上の口座に支払いを行うよう起動される。ここで、Ｄｉｒｋは、支払いが行われたか否かを自分の銀行４１にチェックするため、自分の装置２Ｄを使用することができる（ステップ６４）。
【００６９】
上記例において、Ｇｈｉｓｌａｉｎｅ及びＤｉｒｋは、追加の安全な方策を実装するために提供されるプロフィール及び要求リストオプションを利用しなかったと考えられる。そのような安全な方策は、ＰＵＩＤが公に利用可能であるよう意図されるので、望まれることができる。
【００７０】
Ｇｈｉｓｌａｉｎｅ及びＤｉｒｋのプロフィール及び要求リストは、以下の表に提供される。
【００７１】
【表２】
2010518506.tif 000004
【００７２】
図９は、ユーザ名及びパスワードを確認するためにログインモジュール３４Ａを用いるＧｈｉｓｌａｉｎｅのログインステップ７０を示す。ステップ７１では、ＰＵＩＤ“ＤｉＲｋ”と、電話サービスが要求される指示とを含む構成されたメッセージは、通信形式メッセージ受信機２７と共同してＰＵＩＤ受信機２４によって受信される。
【００７３】
ＰＵＩＤ“ＤｉＲｋ”は、Ｄｉｒｋの要求リストを追跡するために追跡装置３５によって使用される。要求リストは、他人が、即ち情報及び通信技術産業（ＩＣＴ）に含まれるべき産業の形式に関する第１の基準を含む。この基準は、全サービスに対して満たされるべきである。また、他人（この場合、Ｇｈｉｓｌａｉｎｅ）のプロフィールの産業項目は、確認済項目となるべきである。Ｄｉｒｋの要求リストは、他人の預金残高が５００００ユーロより高いことを記述する第２の基準を含む。しかし、この基準は、支払いサービスに関連するのみである。Ｄｉｒｋは、ログインステップ７０の前にサーバシステム１にこれら基準を入力することができる。
【００７４】
この場合、分析装置３６は、Ｇｈｉｓｌａｉｎｅのプロフィールの産業項目がＩＣＴであるが、これが確認された項目ではなく、分析装置が電話接続を開始するよう電話サービス開始装置２６に命令しないので、電話サービスが実行されない（ステップ７２で×によって示される）。
【００７５】
この状況によりＧｈｉｓｌａｉｎｅは、例えばサーバシステム１の調節装置に契約細目を提供することによって、サーバシステム１で確認された自分のプロフィールの産業項目を有しなければならない。この項目が確認される場合、装置２Ａ及び装置２Ｂ間の電話接続は、図７の場合に従って電話サービス開始装置２６を介して構築されることができる。
【００７６】
Ｇｈｉｓｌａｉｎｅがサーバシステム１上のスパム発信者として通知されるべきでない基準をＤｉｒｋの要求リストが含む場合、分析装置３６は、Ｇｈｉｓｌａｉｎｅのプロフィールリストがスパム通知を受信したことを示すシステム項目を含むので、電話サービスモジュール２６を決して開始しない点に注意すべきである。この項目は初期設定で、分析装置３６によってチェックすることから防止されることができない確認済項目である。システム項目は、単に１つのサービス又は複数のサービスに対して有効でもよい。実際の状況では、スパム基準は初期設定で、任意のユーザ及び受信者の要求リストの一部である（しかし、Ｄｉｒｋがこの例で行うと、このリストから除去されることができる）と予想される。
【００７７】
電話の会話後、Ｇｈｉｓｌａｉｎｅは再び、Ｄｉｒｋの（外部）預金口座に１０００００ユーロの額を送金することを望む。Ｇｈｉｓｌａｉｎｅは、支払いサービスが要求される指示メッセージと共にステップ７３でサーバシステム１にＰＵＩＤ“ＤｉＲｋ”を提供する。この指示は、ステップ７４で受信される額である、ディスプレイ１１上の額フィールドに１０００００ユーロの額を入力することによって暗示されることができる。ＰＵＩＤ、指示、及び額フィールドは、単一に構成されたメッセージで受信されることができる。ＰＵＩＤがサービス毎に別個に送信されることは要求されない。
【００７８】
ＤｉｒｋのＰＵＩＤに基づき追跡装置３５を用いてＤｉｒｋの要求リストを追跡した後、分析装置３６は、Ｄｉｒｋの要求リストが支払いサービスに対してチェックのみされるべき基準も有することを見つけ、ここで他人は、少なくとも５００００ユーロの預金残高を有する。Ｇｈｉｓｌａｉｎｅのプロフィールの対応する項目をチェックする時、分析装置は、この項目がチェックすることから防止されることを見つける。これは、初期設定にすることができ、又はサーバシステム１のチェック防止指示受信機３８を用いてＧｈｉｓｌａｉｎｅによって設定されてもよい（表：封鎖を参照）。全項目及び基準は、サーバシステム１のユーザに通信されないが、防止されない場合、分析装置３６によってチェックするために利用可能にできることが分かる。結果として、分析装置３６は、この場合Ｇｈｉｓｌａｉｎｅの預金残高に対するチェックを実行することができない。分析装置３６は再び、産業要求のチェックを実行することができる。また、預金残高要求が電話サービスのような他のサービスに適用可能だった場合、電話サービスは、預金残高のチェックを許容する前に開始されなかった（預金残高が不十分だった場合、電話サービスは、開始されない）点に注意すべきである。即ち、基準は、１つのサーバ又は複数のサーバに適用可能でもよい。
【００７９】
Ｇｈｉｓｌａｉｎｅは、そのような場合、サーバシステム１の通知送信機３９がステップ７５で、Ｄｉｒｋの要求リストが支払いの実行前にＧｈｉｓｌａｉｎｅの預金残高をチェックすることを要求する事実をＧｈｉｓｌａｉｎｅに通知するというオプションを選択することができる。Ｇｈｉｓｌａｉｎｅはその後、ステップ７６で自分の預金残高項目のチェックを（一時的に）許容するよう選択することができる。その後、分析装置は、Ｄｉｒｋの要求リストの預金残高基準に対するチェックを実行し、支払い取引を開始するために支払いサービスモジュール２５を開始することができる（図８のステップ６３、６４に従うステップ７７、７８）。
【００８０】
図１０は、サービスを許容又は否定するための方法及びシステムのさらにもう１つの例を提供する。
【００８１】
Ｄｅｉｒｄｒｅ及びＨｅｎｋは、通話を行うことに同意している。Ｈｅｎｋは、自分の装置２Ｂを使用する。ステップ８０でシステム１は、ＤｅｉｒｄｒｅのＰＵＩＤを受信し、追跡装置３５は、ＰＵＩＤに基づきＤｅｉｒｄｒｅの要求リストを追跡する。また、Ｈｅｎｋのプロフィールは、追跡され、分析装置３６は、Ｈｅｎｋのプロフィールの項目がＤｅｉｒｄｒｅの要求リストの適用可能な対応する基準を満たすかをチェックする。分析装置３６は、Ｈｅｎｋのプロフィールの項目がＤｅｉｒｄｒｅの要求リストの基準を満たすことを見つけると考えられる。
【００８２】
しかし、システム１は、相互承認がこのサービスを開始するために要求されることを設定しているので、電話通信は、未だに有効ではない（ステップ８１の×によって示される）。
【００８３】
後に、Ｄｅｉｒｄｒｅは、Ｈｅｎｋの電話番号を用いてシステム１に連絡する（ステップ８２）。ここで、追跡装置３５は、Ｈｅｎｋの要求リストを追跡し、分析装置３６は、Ｄｅｉｒｄｒｅの項目がＨｅｎｋの要求リストの基準に一致するかをチェックする。Ｄｅｉｒｄｒｅのプロフィールの項目がＨｅｎｋの要求リストの基準を満たすことを分析装置３６が発見する場合、チェック後直ぐに、又は時間を置いて電話通信を開始することができる（ステップ８３）。
【００８４】
図１０の実施形態は、図４Ｂを参照して記載される相互承認方法を使用する。しかし、相互承認は、システム１に連絡するために両者を要求しないことが分かる。上記例では、Ｈｅｎｋのコールにより、両方のチェックをＧｈｉｓｌａｉｎｅの電話番号とＨｅｎｋの連絡細目（例えば、Ｈｅｎｋのログインデータ、電話番号、ＩＭＥＩコード等）とに基づき行うことができる。
【００８５】
図１１は、ユーザが自分のユーザ装置２Ｃからスパム電子メールを送信する場合を示す（ステップ９０）。ステップ９１で、システム１は、任意のユーザ装置Ｘのスパム通知メッセージを受信する。スパム通知メッセージは、出願人の非公開の国際特許出願ＰＣＴ／ＮＬ２００７／０５０５５７及びＰＣＴ／ＮＬ２００７／０５０５５５に記載される方法で得ることができ、それら全体は、参照によって本出願に組込まれる。ここで、ユーザのプロフィールは、ユーザがスパム発信者として通知されたことを反映するシステム項目を有する。ステップ９２で、ユーザは、自分の携帯電話２Ａで受信装置２Ｂに通話を行う。システム１の追跡装置３５は、受信者の受信者要求リストを追跡する。分析装置３６は、スパム発信者として登録される何者かによって開始されるサービスに受信者が含まれたくない基準を受信者要求リストが含むことを発見する。結果として、電話接続は、ステップ９３で×によって示されるように、構築されない。
【００８６】
内部的に提供されるサービス、項目を備えたプロフィール、及び対応する基準を備えた要求リストと共に単一のＰＵＩＤの実際的な用途に対してより多くの例が想定される点に注意すべきである。実際的な用途は、商業用途、出会い系サイト用途等を含む。プロフィールの１つ以上の項目は、例えば自由な通信、自由な銀行取引、又は他の利点のために、永久的又は一時的に封鎖されないことができる。全てのそのような用途は、本特許出願の保護範囲内にある。
【図１】
2010518506.tif 000005
【図２】
2010518506.tif 000006
【図３Ａ】
2010518506.tif 000007
【図３Ｂ】
2010518506.tif 000008
【図４Ａ】
2010518506.tif 000009
【図４Ｂ】
2010518506.tif 000010
【図５】
2010518506.tif 000011
【図６】
2010518506.tif 000012
【図７】
2010518506.tif 000013
【図８】
2010518506.tif 000014
【図９】
2010518506.tif 000015
【図１０】
2010518506.tif 000016
【図１１】
2010518506.tif 000017
【国際調査報告】
2010518506.tif 000018
2010518506.tif 000019
2010518506.tif 000020