JP2011525006A - ユーザが、少なくとも１人の他のユーザによって提供される少なくとも１つのサービスにアクセスするための方法およびシステム - Google Patents

Abstract

本発明は、第1のユーザによって提供される少なくとも1つのサービスに少なくとも1人の第2のユーザがアクセスするための方法に関する。本発明によれば、当該方法は、少なくとも1人の第2のユーザが少なくとも1つのサービスにアクセスできるよう上記第1のユーザが定義したアクセスレベルを含む少なくとも1つの招待を上記第1のユーザが上記第2のユーザに送信するステップと、上記少なくとも1つの招待の内容を検証し、上記アクセスレベルに応じて上記少なくとも1つのサービスにアクセスする許可を上記第2のユーザに出力するステップと、上記アクセス許可から上記第2のユーザによって上記少なくとも1つのサービスへのアクセスを要求するステップとを含む。

Description

本発明は、排他的ではないが特に、通信ネットワークを介してアクセス可能なサービス(それらのサービスの一部は、例えばCommunity Webの原則に依存する可能性がある)というコンテキストにおいて、またはインターパーソナルコミュニケーションというコンテキストに関連して、複数ユーザ間でサービスを共有する分野に関する。

より詳細には、本発明は、ウェブタイプのユーザインターフェースによってリンクされる、ユーザBが構成するパーソナルサービス(例えば、電話、プレゼンス)に対するユーザAのアクセス権の管理を導入することを目的とする。

実際、電気通信サービスは、コミュニティの共有とインターパーソナルコミュニケーションにおける個人情報の使用を目的として、より一般的には、1ユーザと複数の第三者間における仲介を目的として設計されることが多くなってきている。

説明のための一例として、写真サービスは、今ではユーザの写真を記憶することのみを目的とするのではなく、ユーザがそれらの写真を他の人々と共有できるようにすることも目的としている。

同様に、位置情報サービスは、今ではユーザに対してそのユーザ自身の位置を示すことのみを目的とするのではなく、その情報を複数の第三者に提供することも目的としている。

同じことがプレゼンスマネージメントサービスについても言える。

電話などの従来型サービスも、電話サービスがユーザへの連絡を第三者に許可するなど、この枠組みに参入してきている。

上記サービスの全てにおいて、自分が予め構成し、かつ/または個人化したサービスを複数の他のユーザに対してアクセス可能とするユーザは、そのサービスを管理する必要がある。

STNテレフォニーの分野では、電話サービスへのアクセスは、原則として公開である。すなわち、電話帳に記載されている電話番号には誰でもアクセスすることができる。

携帯電話の分野では、携帯電話番号の配布方法でアクセスが制限される。すなわち、誰でもかけられるように携帯電話番号を電話帳に掲載するか、携帯電話で連絡をとる許可を与えた人物にだけ携帯電話番号を携帯電話で送信するかを選択できる。

プレゼンスサービスまたは位置情報サービスの場合、サービスのユーザのプレゼンスまたはサービスのユーザの位置情報にアクセスできる人物の記名式による許可が使用されるが、これらの人物は、このプレゼンス/位置情報サービスの個人識別子のうちの1つによって特徴付けられる。

例えば「ソーシャルネットワーキング」タイプなど、他のサービスは、友達を作ることのできる電話帳、つまり、まず友達となるべき人物の公開プロフィールにアクセスし、次いでそのプライベートプロフィールにアクセスするための記名式による許可を要求することのできる電話帳(例えば、識別子(姓または名である場合が多い)のうちの1つに応じて、またはネットワークのメンバーシップを介して、または関心の中心を介して)を兼ね備えている。

しかし上記のサービスはどれも、サービス自体がそれに対するアクセス許可を管理している。

さらに、通信サービス(テレフォニー、プレゼンスなど)の場合、サービスに対するアクセスを管理するための既存のソリューションは、そのサービスの関係者の集中化した知識に基づいている。

ユーザは自分のデータに対するアクセス権を表し、自分の通信相手に関して自分が有する知識または取得可能な知識、例えば連絡可能識別子、例えば電話番号などに基づいて自分のサービスを構成する。

ユーザ間の対話履歴もまた、この知識ベースに含まれる。友人リストに含めることに関してユーザ間で合意がなされる場合がある。対話の一部は過去に行われている場合がある。

これらのデータは、アクセス権を決定するためにも現行で使用されている。

個人データ(例えば写真)を共有するサービスの場合、周知の従来技術によるソリューションはアクセスリンクを含めた招待を送信するが、それらソリューションはそれぞれのサービスに固有である。したがって、アクセス権をN個のサービスに割り当てることは、N個の異なるインターフェースを介してN個の招待を送信することを必要とし、それらの招待はレシーバでN個の異なる方法により受信され管理されることになる。

従来技術は、原則として、以下に示す制限全てを提示する。
ユーザは、自分のアクセス権を設定するために使用できる様々なシステムを理解しておく必要がある。
ユーザはまた、自分の通信相手の連絡可能識別子に自分のシステムを適合させるために、それらの連絡可能識別子を知っておく必要がある。
ユーザの通信相手の連絡可能識別子が事前に周知でない場合は、アクセス制御を設定することが不可能である。

本発明は、従来技術の上記欠点のどれも示さない新しいソリューションを、第1のユーザが提供する少なくとも1つのサービスに対して少なくとも1人の第2のユーザがアクセスする方法という形式で提案する。

本発明によれば、そのような方法は、
少なくとも1つのサービスへのアクセスを第2のユーザに許可するために第1のユーザによって定義されたアクセスレベルを含む少なくとも1つの招待を第1のユーザが第2のユーザに送信するステップと、
上記少なくとも1つの招待の内容を検証し、アクセスレベルに応じて少なくとも1つのサービスに対するアクセス許可を第2のユーザに配信するステップと、
アクセス許可に基づいて第2のユーザが少なくとも1つのサービスへのアクセスを要求するステップと
を含む。

したがって、本発明は、第1のユーザにより少なくとも1人の第2のユーザが自由に使用できるように配置されたサービスに対してその第2のユーザがアクセスする相互的な方法を提供するが、この方法は、第2のユーザに送信され、上記サービスにアクセスするよう招く招待中の第2のユーザのために第1のユーザが事前に定義したアクセス権を考慮している。

本発明は、サービスの環境および通信相手に関して予め知られることを防ぐことができる利点があり、本発明の原理は、ユーザが制作し、(周知および/または周知でない)自分の様々な通信相手がデータまたはユーザ自身が幾分限定的な方法で共有することを望んでいるサービスにアクセスすることを許可するためにユーザが様々な通信相手に送信した招待クーポンの使用に依存する。

少なくとも1つのサービスに対するアクセスとは、第1のユーザが管理するアプリケーションサービスに対するアクセス、またはこの第1のユーザによって他のユーザに招待により自由に使用できるように配置された、またはアクセスだけはできるようにされた個人データに対するアクセスと同等の意味に理解される。

本発明は、さらに、第2のユーザが、第1のユーザから以前に受信した別の招待に基づいて1つの招待を送信することを可能にする。以下に示すシナリオは、簡単な説明と、限定的でない典型的な場合の一例として示すものである。
ユーザAが公開招待を発行する。
ユーザBはユーザAに出会う。
Bは、Aの公開招待を使用してAを自分のアドレス帳、より一般的には自分の連絡先に追加する。
Bは、Aの公開招待に含まれるデータを使用してAに特定の招待を(Bに連絡するAの権利と共に)送信する。
Aは、ユーザB固有の招待を受け取り、Bを自分の連絡先に追加する。
Aは、Bから受け取った招待に含まれるデータおよびアクセス権に基づいてユーザBに対して新しい特定の招待を(Aに連絡するBの権利と共に)送信する。

当然ながら、このような典型的な場合は、招待には、その送信者を表す情報の少なくとも1項目、例えば電子メールアドレス、または送信者に連絡できるいずれか他の種類の通信識別子などが含まれるものとする。

さらに、1つの招待に含まれる情報に、「一昨日お目にかかりました・・・」の類の、受信側ユーザの注意を引くための送信側ユーザの個人的メッセージを追加するために確保された少なくとも1つの情報フィールドを追加することができる。

さらに、ユーザが招待にアクセスしている間、実行可能な本発明による方法の変形形態において、招待のユーザはロボットでないことを検証する認証ステップに提供が行われる場合がある。このような認証ステップ中に、別のユーザの招待にアクセスし、かつ/または使用することを希望するユーザは、無作為に生成されたテキストを予め入力しておく必要がある場合がある。

好適には、この方法は、送信するステップの前に、少なくとも1人の第2のユーザを対象とする上記少なくとも1つのサービスにアクセスするための少なくとも1つの招待を、招待を管理する装置によって生成するステップを含む。

自分のいくらかの通信相手または連絡先に自分自身の共有データまたはサービスに対する特定のアクセス権を配布することを希望するユーザは、自分の通信相手または連絡先の全てまたは一部に宛てて、または自分がその人物の通信識別子または識別データ(電子メールアドレス、SMSを送信するための携帯電話番号、電子名刺上またはウェブサイト上で使用可能なバーコード、その他)しか有しない人物にさえも宛てて複数の招待を生成し、自分の様々な通信相手または連絡先に自分の招待を送信することによりそれを行うことができる利点がある。

したがって、第1のユーザによって共有されるサービスに対する少なくとも1人の第2のユーザのアクセス権の定義は第1のユーザによって行われるものであり、従来技術のシステムにおけるようにサービス自体が行うものではない。

本発明の有利な実施形態では、この方法は、少なくとも1人の第2のユーザに関して生成された上記少なくとも1つの招待を、招待を管理する装置によって保存するステップも含む。

このように保存することにより、第1のユーザは、自分が生成した招待内に定義されたアクセス権を所与の通信相手または連絡先のために拡張または制限することを意図した、またはそれを取り消すことさえ意図した、当該招待に後からなされる変更の目的をもって、当該招待のそれぞれに戻ることができる。さらに、招待の寿命は、例えば2週間などに限定されており、それ以降は無効となる。

有利には、上記生成するステップが、生成された招待ごとに、
上記少なくとも1つのサービスへのアクセスを第2のユーザに許可するために招待で定義されたアクセスレベルを、上記招待管理装置に接続された証明エンティティによって検証するサブステップと、
第2のユーザを表す情報の少なくとも1項目であって、上記サービスにアクセスすることを第2のユーザに許可するために検証されたアクセスレベルを表す情報の少なくとも1項目に関連付けられた情報の少なくとも1項目を、証明エンティティによって記憶するサブステップと
を含む。

説明のための限定的でない例として、このような証明エンティティは、一組のアクセス権および/またはアプリケーションサービスの使用を管理することのできる特権サーバの形式をとることができるようになる。

したがって、そのような証明エンティティによってアクセスの許可のために後からなされる要求に鑑みて、本発明のこのような方法は、別のユーザにサービスを提供するユーザによって配布されたアクセス権の拡張を保証し、第2のユーザのために第1のユーザによって定義されたアクセス権を記憶することを可能にする。

本発明の特定の実施形態において、上記生成するステップの間、第2のユーザ固有の個人識別子が生成された招待に関連付けられている。

このような方法により、第1のユーザによって提供されるサービスへのアクセスを要求する第2のユーザが、招待に含まれる個人識別子に対応する1ユーザであることを上記アクセス権に対して補足的に後から確かめることさえ可能になる。従って、ID詐欺、およびその結果として招待の内容の不正な割り当てのいかなる試みをも避けることができる。

招待は、招待(例えば、送信者と受信者を識別する招待マネージャにより)により招待に応答することを可能にする(符号化された)識別子を含むこともできる。

招待には、第2のユーザに宛てた第1のユーザのテキストまたはマルチメディアメッセージを含めることもできる。

本発明の有利な実施形態において、第2のユーザ固有の少なくとも1つの通信識別子を考慮しながら、上記送信するステップが招待を管理する装置によって実行される。

招待管理装置は、自分のサービスの少なくとも1つを共有することを希望するユーザによって事前に指定される通信相手/連絡先のそれぞれに、電子メール、SMS、MMSタイプなどのメッセージの送信により招待を送信する役割を担うことさえできる。

招待が生成されるとすぐに上記通信相手/連絡先の個人および/または通信識別子を特定し、電話帳に含まれる各連絡先に招待を自動的に送信するために、招待管理装置を連絡先電話帳、または自分の1つまたは複数のサービスを使用可能にする第1のユーザ固有のアドレス帳に直接接続すると認識することも可能である。

本発明の好適な実施形態において、このような招待が、所定のデータ構造に含まれて第2のユーザに送信される。

例えば招待は、第2のユーザの注意を引くために、第1のユーザに固有の名刺に直接的に統合され、第1のユーザが送信する電子メールに添付されてもよい。

このような招待は、特に、また限定的でない方法で、「電子的な」形式(例えば、SMS、MMSメッセージ、電子メール、ウェブサイトまたはページを指示するURL、vcard、その他)をとるか、または電子的もしくは具体的な視覚形態(例えば、紙の名刺または2次元(2D)バーコード入り電子名刺)をとる。

招待を送信するための媒体として、いかなる他の種類の標準化されたデータ構造でも使用することができる。

本発明の改良された実施形態において、検証するステップは第2のユーザを認証する先行サブステップを含む。

本発明のこのような方法により、第1のユーザのサービスにアクセスしようとしている第2のユーザが確かに第1のユーザが招待を送信した人物であることを、より高度な制御レベルで確かめることが可能になる。
したがって、サービスに対するアクセスを検証することは、特定ユーザ宛ての招待の生成に参加する特権サーバの形式をとることができる証明エンティティに掛っている。次いで、この検証は、上記サービスアクセスの許可に含まれているアクセス権を表すデータを、上記証明エンティティによって生成する上記ステップに対応する記憶されたデータと比較することにより実行されることになる。

好適には、本発明による方法は特定の実施形態において、上記証明エンティティにより上記少なくとも1つのサービスによってアクセスの許可の妥当性を確認するステップを含む。

本発明の有利な実施形態において、上記送信するステップで、招待が第1のユーザ固有の第1の招待管理装置によって第2のユーザ固有の第2の招待管理装置に送信される。

したがって、各ユーザは、サービスに対する招待の受信と他のユーザに対するそのような招待の生成および送信を管理できる自分の管理装置を有する。

拡張により、本発明による方法によれば、招待を生成したユーザが後でそれを変更するか、または招待の1人または複数のユーザに対してそれを取り消すことさえもさらに可能になる。

このような技術的方法は、例えば招待のそれぞれが直接記憶されるような連絡先の電話帳または独自のアドレス帳と関連させてサービスへの招待の受信および送信をユーザがより容易に管理できるようにするため、より有益になることが分かる。

有利には、事前に送信された招待に対する変更要求を受けた際に、第2のユーザのために第1のユーザによってこの招待で事前に定義されたアクセス権を変更するために、事前に送信された招待に関する更新メッセージを、招待を管理する第1の装置によって招待を管理する第2の装置に送信するステップ。

これは、第2のユーザのために第1のユーザによって当初定義されたサービスに対するアクセス権を高めるか、制限するか、または完全に取り消すか、第1のユーザが自動的かつ第2のユーザに対して完全に透過的に変更することを可能にするさらなる利点を提供する。

したがって、第1のユーザが、第2のユーザに固有の招待管理装置に事前に送信された招待の更新を第1のユーザの招待管理装置から要求し、その結果、当該招待に当初含まれていたアクセス権を更新するために更新メッセージが第1のユーザの招待管理装置によって第2のユーザの招待管理装置に自動的に送信されれば十分である。

本発明は、また、第1のユーザによって提供される少なくとも1つのサービスに少なくとも1人の第2のユーザがアクセスするためのシステムに関する。

本発明によれば、このようなシステムは、
上記少なくとも1つのサービスへのアクセスの少なくとも1つの招待を第1のユーザが第2のユーザに送信する手段であって、上記招待は、上記少なくとも1つのサービスに固有のアクセスレベルであって、第2のユーザのために第1のユーザによって定義されたアクセスレベルを含む手段と、
上記少なくとも1つの招待の内容を検証し、アクセスレベルを考慮して上記少なくとも1つのサービスに対するアクセスの許可を第2のユーザに配信することのできる手段と、
上記第2のユーザが上記少なくとも1つのサービスにアクセスすることを要求する手段であって、アクセス許可を考慮する手段と
を含む。

好適には、このようなシステムは、招待を生成するための少なくとも1つの装置であって、少なくとも1人の第2のユーザを対象とする上記少なくとも1つのサービスにアクセスするための少なくとも1つの招待を生成するために、アクセス権を証明するための少なくとも1つのエンティティ(例えば特権サーバ)と共同で機能できる装置を含む。

本発明はさらに、通信ネットワークからダウンロード可能であり、かつ/またはコンピュータ可読情報媒体に記憶されており、かつ/またはマイクロプロセッサによって実行可能なコンピュータプログラム製品において、上記方法に従い第1のユーザによって提供される少なくとも1つのサービスに少なくとも1人の第2のユーザがアクセスする方法を実行するための符号命令を含むコンピュータプログラム製品にも関する。

本発明の技術的特徴および利点は、添付の図面に関して限定的でない表示によりなされる以下の説明からより明らかになろう。

本発明によるシステムのアーキテクチャと、そのようなシステムで交換される情報の力学とを、本発明による方法に従い提示する図である。 本発明による方法の主要ステップを要約するフローチャートである。

図1に示すように、本発明の原理は以下に示す順番に基づいている。
最初に、ユーザ100は、招待を管理するための装置101に基づいて招待クーポンを制作する。この招待クーポンは、ユーザ100のデータまたはサービスにアクセスすることを可能にする。
その後、ユーザ100は、このクーポンを自分の通信相手102のうちの少なくとも1人に送信する(10)。この送信(10)は、例えば電子メール(Eメール)を送信することにより、またはインスタントメッセージの類かSMSメッセージ(「ショートメッセージサービス」)形式でマルチメディアメッセージの形式で行うことができる。招待クーポンの送信10は、招待を管理する装置101により動的かつ/または自動的な方法で確実に実行することができる。このような招待は、例えば携帯電話番号もしくは「OpenID」アカウント番号、またはアドレス帳にあるアカウント番号など、各受信側の通信相手に固有の識別子を含み、それにより、この識別子を所有する受信者だけがその招待を使用できるようにすることが好ましい。

招待クーポンの送信は、本発明の有利な変形形態において、第1のユーザ100固有の第1の招待管理装置101と第2のユーザ102固有の第2の招待管理装置105の間で行うこともできる。このような変形形態により、ユーザ間における招待の処理を簡素化することができる。さらにこのような変形形態は、単に招待管理装置101と105の間でアクセス権を更新する旨のメッセージを送信することにより、事前に送信された招待に含まれているアクセス権の更新を容易にすることもできる。
次に、通信相手102は、事前に受信した招待クーポンを提示することによりユーザ100のデータまたはサービスに対するアクセスを呼び出す(11)ことができる。これは、例えば招待を管理する装置101に接続された、招待クーポンの生成に貢献することのできる特権サーバ103などによって、招待に含まれる識別子を保証するものが認証するステップの後に、任意の方法で実行することができる。
特権サーバ103は、招待クーポンに応じてアクセス制御ポリシーを決定し、そのアクセス許可クーポンによってサービス104にアクセスする(13)ことのできる通信相手にアクセス許可クーポンを返信する(12)。
次いで、通信相手102によりアクセスされるサービス104は、通信相手102により送信された許可クーポンに基づいて、通信相手102に許可されるサービス104へのアクセス権を特権サーバ103から取り戻す(14)。

より一般的には、特権サーバ(証明エンティティ)とサービス104は、第2のユーザのアクセス権を特定するために対話する(14)。この対話は、(特権サーバ103に対するサービス104の)アクセス中、または特権サーバ103によるサービス104の構成によって事前に、または共有された秘密(暗号化の場合)により間接的にでさえ行うことができる。
通信相手102は、ユーザ100が送信した招待により通信相手102が自由に使用できるよう配置されたサービス104を、上記招待内で上記ユーザ100が通信相手102に事前に割り当てたアクセス権に従って使用する(15)。

本発明によるアクセス方法の枠組み内における交換の力学を確実にするために、第1のユーザが提供する少なくとも1つのサービスに対する少なくとも1人の第2のユーザによるアクセスのために分散化されたシステムが実施される。これは、以下に示す様々なエンティティの実施に依存する。
招待クーポン管理装置101:このようなサーバ装置は、招待を生成し、変更し、取り消すことをユーザ100に許可するよう構成された招待クーポン生成モジュールと共同して機能することのできるグラフィカルインターフェース(MMI)と、その招待の中に含まれているアクセス権、すなわち少なくとも1人の通信相手102がアクセスできるユーザ100のサービス104のうちの少なくとも1つをその通信相手102に与えるためにユーザ100が定義したアクセス権を含む。有利には、ユーザ100のアドレス帳などを参照した様々な通信相手102に対する招待クーポンの配布を自動化するため、または最低でも容易にするために、また、通信相手102によって受信された招待の記憶を容易にするために、このような招待クーポンを管理する装置101は、ユーザ100のアドレス帳にリンクされていてもよい。

本発明の実行可能な変形形態において、実施態様よりも困難を増すことなく、招待をユーザのアドレス帳に直接記憶できると考えられる。

本発明の改良された実施形態において、そのような招待クーポンを管理する装置101は、ユーザ100が目標とする通信相手102に宛てた様々な招待クーポンの送信10を動的に保証する。クーポン管理装置101が招待クーポン(すなわち、招待クーポン自体、通信相手のグループおよび関連付けられた権利)を生成するステップ中に制作することになる様々な情報は、装置101が接続されている特権サーバ103に記憶される。本発明によるアクセスシステムの想定される実施形態によれば、特権サーバ103は招待クーポンを管理する装置101に統合してもよいし、例えば通信ネットワークにより当該装置101に接続しても装置101とは別個に遠隔に配置してもよい。
招待クーポンを管理する装置101と共同で機能できる特権サーバ103。このようなサーバ103は、ユーザ100が自分のサービス104のうちの少なくとも1つにアクセスするための招待クーポンを送信したいと思う通信相手102それぞれに対して定義したアクセス権を管理するポリシーに関連付けられた特権独自の識別子を生成する。

特権サーバ103は、本発明によるシステムの重要な構成要素である。特権サーバ103は、サービス104に関する招待クーポンと、ユーザ100が所与の通信相手102のために定義し、当該招待クーポンに関連付けられた権利の間のリンクを記憶する。本発明の改良された実施形態において、特権サーバ103は、招待クーポンと、当該クーポンの受信者である通信相手102の1つまたは複数の識別子の間のリンクも記憶する。特権サーバ103は、例えばクーポンの送信者100のアドレス帳にある受信者に関する連絡先記録を更新する際に、または別のサービス提供者の特権サーバからの要求に応じて、上述した識別子を更新することができる。招待クーポンに基づく要求が行われた場合、特権サーバ103は、許可されたサービスにアクセスするための1つまたは複数のアクセス許可トークンを通信相手102に返信する(12)ことにより、当該クーポンに関連付けられた権利に応じてその要求に応答する。

本発明の実行可能な変形形態において、本発明によるシステムは、第2のユーザ102に特定の招待管理装置105を実施する。すなわち、このようなサーバ装置は、第2のユーザが様々なユーザから受信する可能性のある様々な招待を、適切ならばそのアドレス帳で、管理できるように構成されたグラフィカルインターフェース(MMI)も含む。

最終的に、サービス104は、サービス104のユーザ‐提供者100が通信相手102に限定して定義したアクセス権に応じて通信相手102によりアクセスされ、そのアクセス権は特権サーバ103により検証され、証明される。次いで通信相手102は、適用されるべきアクセス制御ポリシーをサービスが確認できるようにする、その確認の基礎となるトークンをアクセス要求の中に含めてサービス104に送信(13)することによりサービス104にアクセスする。したがって、通信相手102がサービス104にアクセスするために呼び出したアクセス権の検証を得るために、サービス104自体が特権サーバ103に呼び掛ける(14)。

第1のユーザが提供する少なくとも1つのサービスに少なくとも1人の第2のユーザがアクセスする方法は、以下に示す順番を実施する。
ユーザ100は、招待管理装置101のMMI(マン‐マシンインターフェース)を使用して、招待クーポンを生成し、または既存の招待クーポンを変更/削除する。ユーザ100は、自分の通信相手または連絡先102の少なくとも1人をアクセス可能としたいと思うサービス104に対し事前に連絡し、その招待に割り当てられた権利(家族、職業、その他)のグループを任意で作っておく。このために、ユーザ100のアドレス帳に既に作成されたカテゴリまたは特定の連絡先に権利を割り当てることができるように、招待管理装置101をユーザ100のアドレス帳にリンクすることができる。

一例として、ユーザ(100)は以下に示すグループを作ることができる。
ユーザ(100)に関する個人データ(姓、名、郵便番号、写真など)、ユーザのプレゼンスを参照することができ、ユーザの固定電話または携帯電話に連絡することができ、ユーザの個人アドレスまたは仕事のアドレスに電子メールを送信することができる「ファミリー」グループ。
午後7時以降および週末はこのユーザに関するプレゼンスを参照することができ、ユーザの固定電話に連絡することができ、ユーザの個人アドレスに電子メールを送信することができる「フットボールクラブ」グループ。
月曜日から金曜日の午前9時から午後7時の間はユーザのプレゼンスを参照することができ、月曜日から金曜日の午前9時から午後7時の間はユーザの携帯電話に連絡することができ、ユーザの仕事のアドレスに電子メールを送信することができる「仕事」グループ。
ユーザがたまに確認するだけの第3の電子メールアドレスに電子メールを送信することができる「匿名」グループ(デフォルトグループ)。

特権サーバ103は、生成された招待のログをメモリに保存し、それによって、ユーザ100が、ユーザ100のサービス104の1つに対する通信相手102のアクセス権を拡張/制限するため、または既に割り当て済みの権利を取り消すために、後で権利に戻ることを可能にする。

ユーザ100は、受信者102を特徴付ける個人識別子を所有する人物だけが招待クーポンで許可されたサービス104にアクセスできるようにするために、招待クーポンをその個人識別子に任意で関連付けることができる。この個人識別子は、(例えば、識別子が電話番号の場合はSMSを送信するために)招待クーポンを送信するための通信識別子として任意で使用することができる。
招待管理装置101は、ユーザが定義した通信相手102に対する招待クーポンを送信(10)する。この送信は、系統的な方法により、または要求(例えば、通信相手がシステムにその旨を要求した場合)に応じて行うことができる。公開招待クーポンは、任意で使用可能とすることができる(例えば、個人のウェブページまたはブログ上で)。

装置101は、特権サーバ103の支援により招待クーポンを生成する。装置101は、生成したデータの入力および適切なフォーマッティングだけを担当する。

招待クーポンは、個人または組織体エンティティの連絡可能識別子(例えば、電子メールアドレス、電話番号、ファックス番号、インスタントメッセージ識別子、ネットワーク接続されたゲーム識別子、個人のウェブサイトのアドレス、その他)を記憶し、伝達することを可能にする、(例えば「vcard」または「hcard」フォーマットの)標準化されたデータ構造または所有権を主張できるデータ構造など、例えば名刺のような様々な種類であってよい。次いで、以下で定義されるトークンは、この名刺に含まれて直接的に伝達することができる。このクーポンは、名刺の特定分野の形式をとることもできる。

受信した招待クーポン(および関連付けられたトークン)は、アドレス帳(名刺の形式をとる場合は特に)または他の情報記憶手段により保存することができる。
ユーザ100から招待クーポンを受信した通信相手102は、ユーザによって提案されるサービス104にアクセスすることができる。例えば、電話でユーザ100に連絡をとるか、またはインスタントメッセージを送信するか、またはユーザ100の個人データにアクセスする(例えば、郵便の住所)。

特別な実施形態において、ユーザの個人データにアクセスするために、通信相手102は、受信した招待クーポンを特権サーバ103に提供し(11)、このクーポンのためにユーザ100が発行したデータを回復する(12)。

一般的な方法では、サービス104にアクセスするために(例えば、ユーザに接触するために)、通信相手102は、サービスにアクセスするよう特権サーバ103に要求する(11)。この要求をしている間、通信相手102は受信した招待クーポンを提供する。特権サーバ103は、アクセス制御ポリシーにリンクされたトークンを戻す(12)。

このトークンは、以下に例示するように様々な形式で提供することができる。
通信サービスが特権サーバ103(付録Aに記載のケース)から対応する連絡可能識別子(例えば、電子メールアドレスまたはSIP URI)を回復できるようにする「トークン」
特権サーバ103とユーザ100のサービス104の両方に周知の暗号キーで、または直接的にサービス104の公開キーで、特権サーバ103により暗号化された連絡可能識別子
特権サーバ103により事前にサービス104に蓄積された一時連絡可能識別子(「ワンショット」)
識別子をアクセス可能とせずにサービス104(例えばテレフォニーの場合の「クリックしてダイヤル」)を実行できるようにするウェブページのURI(例えば特権サーバによりホストされた)

ユーザ100により通信相手102の認証を要求する目的でクーポンが定義されている場合、任意で当該認証を要求できる。
通信相手102は、通信サービスに対するアクセスを要求する(13)。通信相手102は、特権サーバ103によりユーザ100指定のものと証明されたアクセス制御ポリシートークンを提供する。これは、上記トークンの形式に従い、様々な手段で実行することができる。例を以下に示す。
「トークン」の場合、暗号化された、またはワンショット(使い捨て)の連絡可能識別子により、通信相手102の端末は、ユーザ100により共有されるサービス104を直接的に呼び出す。
「クリックしてダイヤル」タイプの呼の場合、送信されたURIにより指定されるウェブサーバがサービス104、例えば通信サービスを呼び出す。特定の実施形態において、ウェブサーバは特権サーバ103と一致する場合がある。
通信サービス104は、アクセス制御ポリシーを提供したトークンにリンクされたアクセス制御ポリシーの定義を特権サーバ103に要求する(14)。このステップは、トークンの形式により任意である。例えば使い捨ての連絡可能識別子(「ワンショット」タイプの)の場合は、特権サーバ103により権利が予めサービス104に蓄積されているので、このステップは省略される。
サービス104は、通信相手102に対するサービスを実行する(例えば、携帯電話番号を伝達せずに通信相手102を携帯電話でユーザと接触させるか、またはサービス104に対する個人化されたアクセスを、ユーザ100が通信相手102のために事前に定義したアクセス権に基づいて提供することにより)。

本発明の実行可能な実施形態の詳細な説明を、ウェブページからアクセス可能なテレフォニーサービスを基にして以下に示す。

以下に示す順番で、招待クーポンをウェブインターフェースで配信するテレフォニーサービスに適用された本方法の例示的な一実施形態を説明する。このシナリオでは、自分の電話に対する着信呼び出しをフィルタリングしようとしているユーザUAと、ユーザUAと通話しようとする通信相手UBが実施される。
1)ユーザUAは、自分と通話を始めることをUBに好意のある方法で許可することを意図して、メッセージを介してURLをUBに送信する。このURLは、HTTP URLの形式であり、招待クーポンを構成する。このURLは、特権識別子を構成する暗号化されたデータである。この暗号化されたデータは、特権サーバにより生成される。このURLは、実際には、電話サービスではなく、ユーザUAの特権サーバを示している。
この招待クーポンは、http://ua.invitation-orange.com/87GHT54PO0007FTY32;という形式である。
2)UBはUAと通話を始めたいと望んでいる。UBは上述したURLを使用する。UBからの呼び出しは、ユーザUAの特権サーバによって受信される。
3)UAの特権サーバは、その特権識別子が失効していないことを検証し、ユーザ(UA)に関するデータと、ユーザのデータまたはサービスにアクセスするためのURLと、連絡可能識別子とを含むXHTMLドキュメント(ウェブページ)を「hCard」形式で取得する。
4)ユーザUAの特権サーバは、このUAに関する接続要求(例えばユーザUAのSIP電話に対する)の処理を担当するネットワークのエージェントに向けて「SIP URI」を「xhtml」ドキュメントに含めて提供する。URIは不透明であり、アクセスポリシー「direct access」を特定するトークンとユーザUAとを含んでいる。本例のURIは「sip:58346981247@sip.orange.com」である。
5)UBは、このSIP URIを使用してUAを呼び出す。
6)この要求を受信するネットワークのエージェントは、受信したURI(「58346981247」)のアクセスポリシーと受信者はどれかを確認するために特権サーバを呼び出す。
7)特権サーバは、この呼を管理するための必須情報であるauthorized ring tone and return to authorized mobileと、宛先SIP URI(「sdupond1@sip.orange.com」)とを提供する。
8)呼の処理を担当するネットワークのエージェントは、権利に応じてサービスを実行する。

対応する符号化の一例を付録Aに示す。
招待クーポンの形式については、招待クーポンは例えば次に示す種類である。
「Privilege://provider/token_sender/token_coupon」、または
「http://privilege.provider/sender/token」

受信者が特権サーバによる認証を受ける必要がある場合、トークンを省略することができる。

少なくとも1人の通信相手のために、ユーザが共有するサービスに対するアクセスを許可するトークンの形式を、数例、以下で説明する。

説明と限定的でない例として、通信相手ボブはユーザアリスから招待クーポンを既に受信しており、ユーザアリスは、例えばコミュニティウェブサービスのコンテキストにおいて自分のサービスの1つに固有のアクセスをボブに提供したいと思っているとする。

ボブは、ライトクライアント用PCウェブアクセスまたは携帯電話でのクライアント用ウェブアクセスを有する。

携帯アクセスの場合のトークンを以下に例示する。
テレフォニーサービスの場合、「<sip:abcd@orange.fr>を呼び出す」

このトークンを駆動することにより、携帯電話からabcd@orange.frへの呼び出しが開始される。このURI(「Uniform Resource Identifier」)は、アリスの本当の電話番号に経路指定された電話サーバと共に、また任意で特別のタイムテーブル規則(例えば、午後2時から午後6時だけ、それ以外はメッセージ)と共に、特権サーバにより予め構成される。
プレゼンスサービスの場合、「プレゼンス<pres:xyz@orange.fr>」

このトークンを駆動することにより、プレゼンスクライアントからxyz@orange.frへの要求が開始される。このアドレスは、アリスのプレゼンスに対応するプレゼンスサーバ、個人的な生活に準拠した特定規則(または「プライバシー」)と共に、特権サーバにより予め構成される。
写真サービスの場合、「写真アルバム<http:gugus.photo.orange.fr>」

このトークンを駆動することにより、携帯ウェブクライアントからhttp:gugus.photo.orange.frへの要求が開始される。

ウェブアクセスの場合のトークンを以下に例示する。
テレフォニーサービスの場合、「http://abcd.phone.orange.frを呼び出す」

このトークンを駆動することにより、abcd@orange.frに対するクリックしてダイヤル呼び出しが開始される。次いで、ボブは自分に最も近い電話の番号を入力する必要がある。abcd@orange.frのURIは事前に構成される。
プレゼンスサービスの場合、「プレゼンスhttp://xyz.presence.orange.fr」

このトークンを駆動することにより、プレゼンスクライアント(フロントエンドウェブ)からxyz@orange.frへの要求が開始される。このアドレスは、以前と同様、特権サーバにより予め構成される。
写真サービスの場合、「写真アルバム<http:gugus.photo.orange.fr>」

このトークンを駆動することにより、ウェブクライアントからhttp:gugus.photo.orange.frへの要求が開始される。

本発明による、第1のユーザ100が提供する少なくとも1つのサービスに対する少なくとも1人の第2のユーザ102によるアクセス方法の主要ステップを、図2に関連して以下に要約する。
少なくとも1つのサービスにアクセスするための少なくとも1つの招待を、第1のユーザ100により第2のユーザ102に送信するステップ210であって、この招待は、第2のユーザのために第1のユーザによって定義され、上記少なくとも1つのサービスに特有のアクセスレベルを含むステップと、
アクセス権管理エンティティにより上記少なくとも1つの招待の内容を検証するステップ220であって、アクセスレベルを考慮しながら、上記少なくとも1つのサービス104にアクセスする許可を第2のユーザ102に配信するステップと、
アクセス許可に基づいて第2のユーザが上記少なくとも1つのサービスへのアクセスを要求するステップ230。

送信するステップ210の前に、本発明による方法は、少なくとも1人の第2のユーザを対象とする上記少なくとも1つのサービスにアクセスするための少なくとも1つの招待を、招待を管理する装置101によって生成するステップ200を含む。

上記方法は、少なくとも1人の第2のユーザ102に関して生成された少なくとも1つの招待を、招待を管理する装置101によって保存するステップ240も含む。

生成するステップ200が、生成された招待ごとに
上記少なくとも1つのサービス104にアクセスするために第2のユーザ102に固有の、招待で定義されたアクセスレベルを、招待管理装置101に接続されたアクセス特権サーバ103によって検証するサブステップ201と、
上記少なくとも1人の第2のユーザ102を表す情報の少なくとも1項目であって、第2のユーザ102のために上記少なくとも1つのサービス104に対するアクセスの証明されたレベルを表す情報の少なくとも1項目に関連付けられた情報の少なくとも1項目を、アクセス特権サーバ103によって記憶するサブステップ202とを含む。

上記生成するステップ200において、上記第2のユーザ102の識別子は上記生成された招待に関連付けられている203。

第2のユーザ102固有の少なくとも1つの通信識別子に基づいて、送信するステップ210は招待を管理する装置101によって実行される。

上記少なくとも1つの招待が、標準化されたデータ構造内で第2のユーザ102に送信される(ステップ210)。

上記少なくとも1つの招待は、受信した招待を管理する装置105に記憶される。

検証するステップ220は、上記第2のユーザ102を認証する先行サブステップ221を含む。

本発明による方法は、特権サーバ103により、上記少なくとも1つのサービス104によってアクセスの許可の妥当性を確認するステップ250も含む。

付録A
<div class="vcard">
<span class="fn n">
<a class="url" href="http://dupond.orange.com">
<span class="given-name">Serge</span>
<span class="family-name">Dupond</span>
</a>
</span>
<span class="nickname">S.Dupond</span>
<a class="url" href="xmpp:58346981247@jabberorange.com">priviledge IM access to S Dupond</a>
<a class="url" href="msnim:chat?contact=sdupond@hotmail.com">IM with s dupond@hotmail.com</a>
<a class="url" href="sip:58346981247@sip.orange.com">Priviledge calling line</a>
<a class="email" href="mailto:58346981247@orange.com">
<span class="type">preferred email</span>
</a>
<span class="org">Orange</span>
<span class="geo">
<abbr class="latitude" title="48.816667">N 48° 81.6667</abbr>
<abbr class="longitude" title="2.366667">E 2° 36.6667</abbr>
</span>
</div>

100 ユーザ(第1のユーザ)
101 招待管理装置
102 通信相手(第2のユーザ)
103 特権サーバ
104 サービス
105 招待管理装置
UA ユーザA
UB ユーザB

Claims (14)

1. 第1のユーザによって提供される少なくとも1つのサービスに少なくとも1人の第2のユーザがアクセスする方法において、
   前記少なくとも1つのサービスへのアクセスを前記少なくとも1人の第2のユーザに許可するために前記第1のユーザによって定義されたアクセスレベルを含む少なくとも1つの招待を前記第1のユーザが前記第2のユーザに送信するステップと、
   前記少なくとも1つの招待の内容を検証し、前記アクセスレベルに応じて前記少なくとも1つのサービスに対するアクセス許可を前記第2のユーザに配信するステップと、
   前記アクセス許可に基づいて前記第2のユーザが前記少なくとも1つのサービスへのアクセスを要求するステップと
   を含むことを特徴とする方法。
2. 前記送信するステップの前に、少なくとも1人の第2のユーザを対象とする前記少なくとも1つのサービスにアクセスするための少なくとも1つの招待を、招待を管理する装置によって生成するステップを含むことを特徴とする請求項1に記載の方法。
3. 少なくとも1人の第2のユーザに関して生成された前記少なくとも1つの招待を、前記招待を管理する装置によって保存するステップを含むことを特徴とする請求項2に記載の方法。
4. 前記生成するステップが、前記生成するステップで生成された招待ごとに
   前記少なくとも1つのサービスへのアクセスを前記第2のユーザに許可するために前記招待で定義されたアクセスレベルを、前記招待管理装置に接続された証明エンティティによって検証するサブステップと、
   前記少なくとも1人の第2のユーザを表す情報の少なくとも1項目であって、前記サービスにアクセスすることを前記第2のユーザに許可するために検証されたアクセスレベルを表す情報の少なくとも1項目に関連付けられた情報の少なくとも1項目を、前記証明エンティティによって記憶するサブステップと
   を含むことを特徴とする請求項2または3に記載の方法。
5. 前記生成するステップで、前記第2のユーザ固有の個人識別子が前記生成された招待に関連付けられていることを特徴とする請求項2から4のいずれか一項に記載の方法。
6. 前記第2のユーザ固有の少なくとも1つの通信識別子を考慮しながら、前記送信するステップが前記招待を管理する装置によって実行されることを特徴とする請求項2から5のいずれか一項に記載の方法。
7. 前記少なくとも1つの招待が所定のデータ構造内で前記第2のユーザに送信されることを特徴とする請求項1から6のいずれか一項に記載の方法。
8. 前記検証するステップが前記第2のユーザを認証する先行サブステップを含むことを特徴とする請求項1から7のいずれか一項に記載の方法。
9. 前記証明エンティティの支援により前記少なくとも1つのサービスによってアクセスの前記許可の妥当性を確認するステップを含むことを特徴とする請求項4から8のいずれか一項に記載の方法。
10. 前記送信するステップで、前記招待が前記第1のユーザ固有の第1の招待管理装置によって前記第2のユーザ固有の第2の招待管理装置に送信されることを特徴とする請求項1から9のいずれか一項に記載の方法。
11. 事前に送信された招待に対する変更要求を受けた際に、前記第2のユーザのために前記第1のユーザによってこの招待で事前に定義されたアクセス権を変更するために、前記事前に送信された招待に関する更新メッセージを、前記招待を管理する第1の装置によって前記招待を管理する第2の装置に送信するステップを含むことを特徴とする請求項10に記載の方法。
12. 第1のユーザが提供する少なくとも1つのサービスに少なくとも1人の第2のユーザがアクセスするためのシステムにおいて、
    前記少なくとも1つのサービスへのアクセスを可能にする少なくとも1つの招待を前記第1のユーザが前記第2のユーザに送信する手段であって、前記招待は、前記少なくとも1つのサービスに固有のアクセスレベルであって、前記第2のユーザのために前記第1のユーザによって定義されたアクセスレベルを含む手段と、
    前記少なくとも1つの招待の内容を検証し、前記アクセスレベルを考慮して前記少なくとも1つのサービスに対するアクセス許可を前記第2のユーザに配信することのできる手段と、
    前記第2のユーザが前記少なくとも1つのサービスにアクセスすることを要求する手段であって、前記アクセス許可を考慮する手段と
    を含むことを特徴とするシステム。
13. 招待を生成するための少なくとも1つの装置であって、少なくとも1人の第2のユーザを対象とする前記少なくとも1つのサービスにアクセスするための少なくとも1つの招待を生成するために少なくとも1つの証明エンティティと共同で機能できる装置を含むことを特徴とする請求項12に記載のシステム。
14. 通信ネットワークからダウンロード可能であり、かつ/またはコンピュータ可読情報媒体に記憶されており、かつ/またはマイクロプロセッサによって実行可能なコンピュータプログラム製品において、請求項1から11のいずれか一項に記載の、第1のユーザによって提供される少なくとも1つのサービスに少なくとも1人の第2のユーザがアクセスする方法を実行するための符号命令を含むことを特徴とするコンピュータプログラム製品。

Images