JP2011512748A - 通信ネットワーク・ノードにおいてサービスを可能にする方法 - Google Patents

Abstract

通信ネットワーク・ノードにおいてサービスを可能にする方法、及び当該方法を実行するネットワーク・ノードが提供され、シンボルに関連付けられる１つ以上の動作を要求する第１の要求が、第１のユーザから受信される。当該要求は、１つ以上の動作を識別する指示を含む。当該要求は、固有のシンボル識別子の生成、及び当該シンボル識別子に関連付けられたシンボル・レコードの作成を始動し、当該シンボル・レコードはシンボル識別子を１つ以上の動作に紐付けする。ノードにおいて、シンボル識別子はまた、生成されたシンボルに関連付けられ、シンボルはシンボル・サーバにより作成され、かつ、第１のユーザに転送される。一旦、シンボルが、第２の要求でノードにより受信されると、当該シンボルに対応するシンボル識別子がシンボル・サーバから読み出されるとともに、シンボル識別子により識別されるシンボル・レコードに従って１つ以上の動作を実行することによって、サービスが可能になる。

Description

本発明は、概して、サービスを定義及び始動する方法に関するものであり、より詳しくは、通信ネットワーク・ノードにおいて、固有のシンボルに関連付けられているサービスを可能にする方法に関するものである。

今日、大多数の職業に携わっているパーティにとって、情報交換は日常業務のありふれた一部となっている。そのような情報交換は、情報媒体から取り出された情報を何らかの記憶手段に物理的に打ち込むことから、情報交換プロセスに関与する１つ以上のパーティからのユーザの対話に依存して、エンティティ間で情報を交換することにまで及ぶ場合がある。

名刺の交換は、ビジネスの関係者間で個人情報を交換するための定着した慣習であるのみならず、２人の個人が何らかの種類の新たな知人関係になろうとする場合には必ず、様々な出来事の中で個人情報を交換するための定着した慣習である。

名刺情報の交換への伝統的な手法は、典型的には、従来のｖＣａｒｄ標準に従っており、ユーザが紙ベースの名刺を受け取って、例えば電話番号、電子メールアドレス及び郵送先住所といった、名刺に印刷された情報を、例えばＰＤＡ又は携帯電話といった、自らのユーザ装置に入力することである。名刺情報を交換する別の方法は、ＳＭＳ、ＭＭＳ、若しくはその場合に２組のパーティ間で送信される電子メールに名刺情報を添付すること、又は、Ｂｌｕｅｔｏｏｔｈ（登録商標）若しくは赤外線接続を使用して名刺情報を交換することである。

しかしながら、今日、既に確立された異なるフォーマットのアドレス帳を情報源とする、単調な多数のやりとりを必要とせずにアドレス帳を更新する簡易な方法はほとんど存在せず、多くの場合、互換性を得るためには適応及び修正が必要となる。

また、情報又はその後の機会に更新された情報でさえ、他のユーザが容易に取り出すことを可能にする、「この種の情報を残す」方法は存在しない。

ユーザ装置に対して名刺情報を手動で入力することは、スペルミスに関するかなりの危険性によって、多くの場合、時間のかかる処理であると考えられている。また、名刺情報を交換するのに用いられる既存の技術も、一般的なユーザが取り扱うにはかなり複雑であると考えられる。これは、広く知られている情報交換手順が、多くの場合、送信側及び受信側のパーティの双方からの情報のやり取りを必要とするためである。

ユーザ間で情報を交換する別の方法は、プレゼンス・サービスによって提供されてもよい。プレゼンス・サービスは、ユーザの必要性及び好みに従って、情報配信用のサービスをカスタマイズするための広範なメカニズムを提供する。

図１は、従来技術によるプレゼンス・システムの概略図であり、当該プレゼンス・システムは周知のＳＩＰ／ＩＭＳ標準規格に従って動作する。

ウォッチャ１００（即ち、点線の四角内に位置するエンティティによって定義される、プレゼンス・システム１０１からのプレゼンス・サービスにアクセス可能なユーザ装置を具備したユーザ）は、プレゼンティティ１０２（即ち、同様にプレゼンス・サービスを起動した別のユーザ）のプレゼンス情報を要求することができ、それにより、権限を与えられたウォッチャが、プレゼンティティ１０２に関連付られた情報にアクセスすることが可能となる。プレゼンティティ１０２のプレゼンス情報を要求しているウォッチャ１００は、アプリケーション・サーバ又はプレゼンス・サーバ１０３を介してプレゼンス・システム１０１と通信する。

ウォッチャ１００から受信した要求に応じて、プレゼンス・サーバ１０３は、ウォッチャ１００がプレゼンティティ１０２のプレゼンス情報を見る権限を与えられているか否かを判定するために、プレゼンスＸＭＬドキュメント・サーバ（プレゼンスＸＤＭＳ）１０４に問い合わせを行う。

更新されたプレゼンス情報は、ローカル・サーバ又はアドレス帳サーバといった種々のプレゼンス・ソース１０５から、プレゼンス・サーバ１０３に提供され得る。プレゼンス・サーバ１０３は、当該プレゼンス・サーバに対して発行されたプレゼンス情報を受け取るとともに、権限を与えられたウォッチャに対して、それを通知として分配し得る。

プレゼンス・システムは、典型的には、プレゼンス通知予約（subscription）をリストにまとめるリソース・リスト・サーバ（ＲＬＳ）１０６をも含む。これらのリストは、その後、ＲＬＳ ＸＤＭＳ１０７に記憶され、そこからそれらのリストがプレゼンス・サーバ１０３にアクセス可能である。

プレゼンティティが自らに関するプレゼンス情報を発行する標準的な方法は、要求（典型的にはＳＩＰ ＰＵＢＬＩＳＨ要求）をプレゼンス・サーバに送ること、又は、ＸＣＡＰ ＰＵＴ要求をプレゼンスＸＤＭＳに送ることである。通常、ネットワークは、ユーザに対してプレゼンス情報を発行することも可能であるが、そのようなプレゼンス配信メカニズムには、プレゼンティティによって始動される事象の実行が含まれない。

プレゼンス情報の発行は、例えば、タイピング及び選択肢の選択の少なくとも何れかといった作業を含む、ユーザからの多くの労力を必要し得る。ここで、当該作業の全ては、実際に発行されているプレゼンス情報の量を抑える効果を有する可能性がある。

（典型的にはウォッチャと呼ばれる）ユーザが、（典型的にはプレゼンティティと呼ばれる）バディ（buddy）を、プレゼンスを使用可能なバディのリストに加える１つの標準的な方法は、（典型的にはＸＣＡＰ ＰＵＴ要求の形式の）要求を、ＲＬＳ ＸＤＭＳ及び共有ＸＤＭＳ（図示せず）の少なくとも何れかに対して送ることである。それにより、プレゼンス・システムは、ウォッチャのためにプレゼンティティに関連する情報についての通知予約（subscribe）を行い、ウォッチャは、搬送される通知を受信する。

今日、プレゼンスを使用可能なユーザのリストに、ユーザ装置を介してバディを自動的に追加する、容易かつ簡易な方法は存在しない。そのような情報を追加するための方法は、今日、追加されるべき各バディのアドレス情報を、ユーザ装置に手動で入力しなければならないということを必要とする。アドレスは、通常、非常に長く、かつ、そのためにスペルミスの危険性が無視できない可能性があり、このことは、言い換えると、サービスの定義及び実行の少なくとも何れかを行うための、より使い勝手の良いメカニズムを伴う場合と比較して、この形式のサービスを利用する頻度を低下させる可能性がある。

本発明の目的は、上記で概略した課題の少なくとも一部に対処することである。さらに、本発明の目的は、サービスの実行をユーザが始動できるようにする方法を提供することであり、当該サービスは、サービスを可能にするノードに対してシンボルを単に登録及び転送することによって、１つ以上の動作で予め定義されている。概して、本方法は、固有のシンボルにより表されるサービスをユーザが定義できるようにするとともに、同一又は別のユーザが、当該固有のシンボルによってサービスを識別する、使い勝手の良い方法でサービスを始動できるようにするメカニズムに当てはまる。これらの目的及び他の目的は、添付の独立請求項による方法を実行するように構成された方法及び通信ネットワーク・ノードによって達成され得る。

第１の態様によれば、通信ネットワーク・ノードにおけるサービスを可能にするための方法が提供される。シンボルに関連付けられる１つ以上の動作を要求する第１の要求を第１のユーザから受信すると、固有のシンボル識別子が当該ノードで生成される。当該要求は、１つ以上の動作を識別する指示を含む。シンボル識別子に関連付けられたシンボル・レコードも作成され、ここで当該シンボル・レコードは、シンボル識別子を１つ以上の動作に紐付けしている。シンボル識別子は、その後、シンボル・サーバによって作成され、かつ、当該ノードによって第１のユーザに転送されるシンボルに関連付けられ、第１のユーザは、潜在的なユーザに対してシンボルが表示され得るように、当該シンボルを記憶すること、及び再生することの少なくとも何れかを行ってもよい。

一旦、シンボルが第２の要求でノードにより受信されると、受信したシンボルに対応するシンボル識別子がシンボル・サーバから読み出されるとともに、シンボル識別子によって識別される、シンボル・レコードに係る１つ以上の動作を実行することによって、サービスが可能になる。サービスを始動する（triggering）、第２の要求の開始者は、第１のユーザと同一であってもよいし、別のユーザであってもよい。

要求されたサービスを可能にする１つ以上の動作を識別する指示は、典型的には、ノードのアプリケーションと第１のユーザのユーザ装置との間の情報のやり取りによってもたらされる。そのような情報のやり取りは、例えば、ＷＥＢサーバを介して実現されてもよい。

定義されたサービスの始動は、第２の要求を、例えばＭＭＳやＳＭＳを介して、又はＳＩＰ／ＩＭＳベースのプロトコルを介して送信することを含んでいてもよい。

サービスは、プレゼンスに関連するサービス、及びプレゼンスに関連しないサービスの双方を含んでいてもよく、より詳細には、例えば、バディ・リストと、プレゼンスの更新、発行及び通知のうちの少なくとも１つと、電子名刺の分配とのうちの少なくとも１つを取り扱うサービスのようなサービスが、ユーザによって定義され、かつ使用されてもよく、当該ユーザは、例えばコード・リーダ、スキャナ又はカメラのような、従来のコード又はシンボルの登録手段を具備した従来の通信ユーザ装置を有する。

請求している発明はまた、上述の方法を実行するように構成された通信ネットワーク・ノードに当てはまる。

説明した方法の原理に従って動作する方法及び通信ネットワーク・ノードは、新たなサービスを導入及び使用するプロセスを簡単化することができる。

説明した方法は、新たな通信ネットワーク・ノードと組み合わされて、標準化されたユーザ装置及び送信プロトコルの使用に依存する。

本発明の特徴及び利点は、以下の詳細な説明から明らかになるであろう。

従来技術に係るプレゼンス・システムを概略的に示す図である。 一実施形態に係る、シンボルに関連付けられたサービスを定義及び始動する方法を示すフローチャートである。 一実施形態に係る、シンボルに関連付けられたサービスをユーザがどのように定義可能であるかを示すシグナリング図である。 一実施形態に係る、シンボルに関連付けられたサービスをユーザがどのように始動可能であるかを示すシグナリング図である。 一実施形態に係る、シンボルに関連付けられたサービスの定義及び始動を管理するためのアプリケーション・サーバを示すブロック図である。 一実施形態に係る、ユーザが定義したサービスを表す動作を記憶するための２つのシンボル・レコードの一例を示す図である。

以下では、典型的な実施形態を用いて、かつ添付図面を参照して、本発明についてより詳細に説明する。

簡潔に説明すると、本発明は、ユーザが、別のユーザ又は同一のユーザによってそれまでに定義されているサービスを始動できるようにする、使い勝手の良い方法に当てはまる。当該サービスは、各サービスを表すようにそれまでに定義されているシンボルを登録し、かつ、当該登録されたシンボルをアプリケーション・サーバに転送することによって、始動される。当該アプリケーション・サーバは、当該サービスに関連付けされた（複数の）動作をそれに応じて実行することによって、当該サービスを提供するように構成される。

このような方法は、アプリケーション・サーバのアプリケーションにアクセスするユーザによって開始されてもよく、アプリケーション・サーバは、サービス、即ち、１つ以上の動作についての条件付の実行又は無条件の実行を、ユーザが定義できるようにし、当該サービスは、アプリケーション・サーバによって管理されよう。その結果、定義されたサービスは、アプリケーション・サーバからの要求に応じて従来のシンボル・サーバによって作成される、固有のシンボルに関連付けされる。アプリケーション・サーバはまた、固有のシンボル識別子を作成する。当該固有のシンボル識別子は、作成された当該シンボルと、シンボル識別子及び関連する１つ以上の動作を含むシンボル・レコードとに、関連付けられるであろう。

作成されたシンボルを再生し、かつ表示することにより、上述したユーザ（即ち、開始者、又はシンボルに関連するサービスの管理者）、あるいは別のユーザは、従来の登録手段を具備する従来のユーザ装置を用いてシンボルを単に登録することにより、かつ、当該シンボルをアプリケーション・サーバに転送することにより、当該シンボルに関連付けられた１つ以上の動作の実行を始動することができる。一旦、シンボル・サーバによってシンボルが復号されていると、アプリケーション・サーバは、それに応じて所定のサービスを実行する。

以下では、シンボルに関連付けられたサービスを定義及び始動するための、一実施形態に係る方法の概要について、図２のフローチャートを参照して説明する。

第１のステップ２００では、シンボルに関連付けられることになる１つ以上の動作を要求する、第１のユーザから送信される要求が、アプリケーション・サーバによって受信される。当該要求は、シンボルに関連付けられることになる実行可能なサービスを表す１つ以上の動作を識別する指示を含む。当該要求は、典型的には、シンボル始動サービス（symbol triggered service）の管理者又は開始者として、第１のユーザを識別する識別子をも含む。以下で管理者識別子（ａｄｍ ＩＤ）と称するユーザ識別子は、例えば、ＳＩＰ ＵＲＩ、ＴＥＬ ＵＲＩ、又はＰＲＥＳ ＵＲＩの何れかであってもよい。

典型的には、当該指示は、第１のユーザのユーザ装置とアプリケーション・サーバのアプリケーションとの間で確立された情報のやり取り（interaction）によってもたらされ、第１のユーザは、任意の既知の標準的な手順に従って、例えば、Ｗｅｂサーバ及びグラフィカル・ユーザ・インタフェース（ＧＵＩ）を介して、アプリケーションにアクセスし得る。従って、この機能（functionality）については、本明細書においてこれ以上詳細に説明しないこととする。

Ｗｅｂサーバによって提供されるウェブ・サービスは、典型的には、ユーザが読み取り可能なコマンドのリストを使用して、ユーザがサービスを定義できるように構成されてもよく、当該コマンドは、ウェブ・サービスにより解釈される場合には、所要のサービスの実行をもたらす。即ち、当該ウェブ・サービスは、ユーザによって入力された、ユーザが読み取り可能な各コマンドを、アプリケーション・サーバのコマンドに解釈し直し、アプリケーション・サーバの当該コマンドは、アプリケーション・サーバによって実行可能な１つ以上の特定の動作に相当する。そのような解釈を行うツールばかりでなく、上述のようにコマンドを定義するための機能もまた、従来技術を用いて提案した概念に実装可能である。このため、これらの機能についてのさらなる説明も本明細書では割愛する。

典型的なシナリオでは、指示を受信するアプリケーション・サーバは、受信した指示のコマンドを、システムが所要の（複数の）動作を行うように設定するのに適した、対応するアプリケーション・コマンドに、符号化できるであろう。ユーザＸの意図が、自らの連絡先リストに他のユーザを使い勝手の良い方法で追加することを可能にすることである場合、ＧＵＩによって入力されたユーザ・コマンドは、例えば、「このシンボルは、ユーザＸの連絡先リストに追加するものである」との形式を有していてもよい。例えば、あるユーザが昼食のために不在であるということを、当該ユーザが他のユーザに気付かせたいといった、頻繁に起こるサービスは、「このシンボルは、自分のプレゼンスを昼食中に更新するものである」と読み取れるユーザ・コマンドを、代わりに入力してもよい。コマンドはまた、タイムアウト条件を有するように設定されてもよく、所定の時間インスタンスが経過した場合にのみ、１つ以上の動作が実行されるように設定されてもよく、例えば、プレゼンスが１時間後に「昼食中」から「在席中」に変わるように自動的に設定されてもよい。

１つ以上の動作により表されるサービスが、一旦、アプリケーション・サーバで定義されると、当該アプリケーション・サーバは、ステップ２０１で示されているように、固有のシンボル識別子（シンボルＩＤ）を生成する。シンボル識別子は、定義されたサービスに関連付けられるであろう。次のステップ２０２で、アプリケーション・サーバは、サービスの開始者／管理者を識別するａｄｍ ＩＤ（管理者ＩＤ）と、シンボルＩＤと、管理者により入力されるコマンドに対応する１つ以上の関連する動作とを含む、シンボル・レコードを作成する。

別のステップ２０３で、アプリケーション・サーバは、直近で作成されたシンボルＩＤに関連付けられているシンボル、及び関連付けられた（複数の）動作を、シンボル・サーバに要求する。シンボル・サーバは、典型的には従来のシンボル・サーバであり、当該要求に応じて、シンボルＩＤを使用して従来の符号化手順に従って固有のシンボルを作成し、かつ、作成した当該シンボルをアプリケーション・サーバに返す。当該シンボルは、例えば、バーコード、カラー・コード、又はＱＲコードのような任意の既知の形式であってもよい。

シンボル・サーバは、スタンド・アロン装置としてアプリケーション・サーバと接続されてもよいし、アプリケーション・サーバと統合された単一の装置として構成されてもよい。

次のステップ２０４で、アプリケーション・サーバは、サービスについてシンボルが定義されていることを認識すると、シンボル・サーバから受信したシンボルを第１のユーザに転送し、一方で、シンボルの転送に失敗すると、第１のユーザにはエラー・コードが送られ得る。

一旦、１つ以上の識別された動作を行うことにより実行可能なサービスが、第１のユーザにより定義され、かつ、一旦、関連するシンボル及びシンボル・レコードがそれに従って作成されると、当該シンボルは、同一のユーザ又は任意の他のユーザによって、各サービスのトリガとして使用され得る。上述した始動目的で誰もがシンボルを用いるために、シンボルは利用可能にされなければならない。これは、シンボルを再生すること、例えば、任意の形式の従来の印刷手段を用いてシンボルを印刷することにより、及び、印刷したシンボルを、袋、名刺、会合若しくは会議の案内状、オフィスの扉、又は、店舗、競技場若しくは任意の他の公共施設への入り口等のような、計画的な（strategic）場所又は位置に表示することにより、行われ得る。

あるいは、第１のユーザのユーザ装置により受信されたシンボルは、ユーザ装置の記憶装置に記憶されてもよい。一旦記憶されると、シンボルは、別のユーザがアプリケーション・サーバにシンボルを登録及び転送するために、その後にユーザ装置のディスプレイ又はモニタ上に呼び出されてもよく、それにより、各シンボルに関連付けられたサービスが始動される。ユーザ装置に記憶されたシンボルは、さらに別のユーザに送信されてもよく、それにより、当該ユーザは登録のためにシンボルを発行することを選択可能である。

作成されたシンボルを潜在的なユーザに対して利用可能とし終わった後の、任意の時点において起こり得る、後続のステップ２０５において、アプリケーション・サーバは、第２のユーザ又は第１のユーザから、これまでに作成されたシンボルであって、例えば、コード・リーダ、スキャナ又はカメラのような従来の登録手段で登録されているシンボルを受信する。

別のステップ２０６で、アプリケーション・サーバは、従来のシンボル・サーバの復号標準規格を利用して、シンボルに関連付けられたシンボルＩＤをシンボル・サーバから自動的に読み出すとともに、この情報に基づいて、アプリケーション・サーバは、各シンボル・レコードを読み出して、最後のステップ２０７で示しているように、登録されたシンボルに関連付けられた１つ以上の動作を実行する。

以下では、一実施形態に係る、上記で提案した方法の冒頭の複数のステップ、即ち、固有のシンボルに関連付けられる実行可能なサービスがどのように定義され得るかを説明しているステップについて、図３のシグナリング図を参照してさらに詳細に説明する。

最初のステップ３：１で、ユーザＡ３００は、固有のシンボルに関連付けられることになるサービスを定義する。ここで、ユーザＡは、ＰＣ、ラップトップ、又は携帯電話のような、持ち運び可能なユーザ装置又は固定のユーザ装置を具備しているユーザとして定義される。そのような手順は、典型的には、上述したように、アプリケーション・サーバ３０１と情報をやり取りすることにより実現される。

次のステップ３：２で、定義されたサービスを固有のシンボルに関連付けるための要求が、アプリケーション・サーバ３０１に送信され、ステップ３：１の情報をやり取りする手順を終わらせるステップを形成する。当該要求は、ユーザＡによって定義されたサービスをどのように実行する方法、即ち、定義されたサービスをそれに応じて行うために必要とされる１つ以上の動作を、アプリケーション・サーバに知らせる指示を含む。当該要求はまた、典型的には、ユーザＡ３００をサービスの作成者／管理者として識別する、ユーザ識別子を含む。ステップ３：１及びステップ３：２は、典型的には、アプリケーション・サーバ３０１のアプリケーションへのアクセスを適切なＧＵＩによって提供する、Ｗｅｂサーバ３０３又は別の従来のサーバを介して提供される。

アプリケーション・サーバ３０１は、ユーザＡ３００から要求を受信すると、次のステップ３：３で、固有のシンボルＩＤを生成する。後続のステップ３：４で、アプリケーション・サーバ３０１は、シンボルＩＤと、関連付けられる動作ステップと、ユーザＡを識別するａｄｍ ＩＤとを含む、シンボル・レコードを生成する。別のステップ３：５で、アプリケーション・サーバ３０１は、直近で作成されたシンボルＩＤに関連付けされることになる固有のシンボルを、従来のシンボル・サーバ３０２に要求する。シンボル・サーバ３０２では、ステップ３：６及び次のステップ３：７においてシンボルが作成され、当該シンボルは、アプリケーション・サーバ３０１に配信される。

アプリケーション・サーバ３０１は、シンボル・サーバからシンボルを受信すると、別のステップ３：８で、ユーザＡ３００にシンボルを転送する。シンボルは、一旦、ユーザＡ３００によって受信されると、その後の登録のために、上記で提案した代替案のいずれかに従って記憶されること、及び、直ちに表示されることの少なくとも何れかがなされてもよい。これは、サービス定義を定義する段階を終了させるステップ３：９に示されている。

ユーザＡ３００は、所要のサービスを表すシンボルを受信すると、当該サービスをプレーン・テキストで説明する旨の指示の有無に係わらず、シンボルを再生することを直ちに選択してもよい。説明は、シンボル始動サービスの定義のために説明した手順と類似して、ウェブ・ページを介してアプリケーション・サーバにアクセスことによって実現され得る。典型的なシナリオでは、そのような説明のテキストは、ステップ３：１及びステップ３：２の、サービスを定義する段階において既に選択されている。

代替の実施形態では、ユーザＡのユーザ装置は、例えば、ＱＲコードのようなシンボルを生成するための手段を備えていてもよい。そのような場合、シンボル・サーバの機能は、ユーザＡのユーザ装置と統合されるであろうし、それにより、ステップ３：５からステップ３：７までにおいて実行される手順が、ユーザＡ３００とアプリケーション・サーバ３０１との統合によって、代わりにもたらされるであろう。

図４は、一実施形態に係る別のシグナリング図であり、ユーザＡ又は別のユーザが、自動化され、かつ、使い勝手の良い方法で各サービスをどのように始動可能であるかを記述する、提案した方法の連続するステップを説明している。

最初のステップ４：１で、ユーザＢ４００は、上記ステップ３：１でユーザＡによってそれまでに作成されたシンボルを登録する。また、ユーザＢは、ＰＣ、携帯電話、ＰＤＡ、ラップトップのような従来のユーザ装置、又は、スキャナ、コード・リーダ若しくはカメラのような少なくとも１つの従来の登録手段を具備した、任意の他の種類の固定された若しくは持ち運び可能な装置、を具備しているユーザと見なされる。

２つの後続するステップ４：２及びステップ４：３で、ユーザＢ４００は、登録したシンボルを、ユーザＢを識別するユーザ識別子と一緒に、当該シンボルに関連付けられたサービスを始動するようにアプリケーション・サーバ３０１に要求する第２の要求で、適切なネットワークを介してアプリケーション・サーバ３０１に送る。

一実施形態によれば、ＩＭＳ機能が必要とされ、シンボルは、ＳＩＰ／ＩＭＳ標準を用いてアプリケーション・サーバ３０１に転送されてもよい。そのような場合、図４の中間ノード４０１は、ＳＩＰ／ＩＭＳネットワークの従来のアクセス・ノード（即ち、Ｉ−ＣＳＣＦ）によって表される。

ＩＭＳ機能を有しないユーザ装置を取り扱うように構成された、別の実施形態によれば、ユーザ装置は、登録されたシンボルを復号するように構成された復号手段を具備していてもよい。そのような場合、復号されたデータは、アプリケーション・サーバ３０１に、例えばＳＭＳを介して送られてもよく、従って、中間ノード４０１はショート・メッセージ・サービス・センタ（ＳＭＳ−Ｃ）である。

さらに別の実施形態によれば、シンボルは、ＭＭＳによって代わりに送信されてもよく、その場合、中間ノード４０１は、代わりに、マルチメディア・メッセージング・サービス・センタ（ＭＭＳ−Ｃ）である。上述したＳＭＳ及びＭＭＳの両方の場合において、始動（triggering）は、アプリケーション・サーバにシンボルを転送するために確立されたコネクションを用いて、説明したサービスにより提供される電話番号をダイヤルすることによって、簡単に実現可能である。

シンボルを登録し、かつ、電話呼を介してシンボルをサーバに送信することだけで特定のサービスを始動することは、多くのサービスに関する日々の使用を簡単にすることができる。当該多くのサービスは、ユーザにより行われなければならない、１つ以上の、多かれ少なかれ複雑なステップを現状では必要としており、各ステップは、所要の情報のやり取りを正しく完遂できない危険性を伴う可能性があり、それにより、各サービスを正しく完遂できない危険にさらされる。

次のステップ４：４で、送信されたシンボルに関連付けられたシンボルＩＤが、シンボル・サーバ３０２から読み出される。読み出されたシンボルＩＤに基づいて、アプリケーション・サーバ３０１は、対応するシンボル・レコードを探し出すことができるとともに、１つ以上の動作により特定されるサービスであって、各シンボル及びシンボルＩＤに関連付けられたサービスを、始動できるであろう。これは、別のステップ４：５で説明される。典型的には、アプリケーション・サーバ３０１は、所要のサービスを実行するために、例えばロケーション・サーバ又はアドレス帳サーバのような１つ以上の追加サーバ４０２と、情報をやり取りする。１つのそのような典型的な情報のやり取りが、オプションのステップ４：６ｂに示されている。

当然のことながら、図３の段階３：１で説明した、これまでに定義したサービスは、ユーザ又は種々のユーザ・グループに関して条件付きのサービスとして、定義されていてもよい。例えば、当該サービスが、何らかの情報をアプリケーション・サーバからユーザＢにＳＭＳを介して直接的に送信することを含むサービスである場合、そのような手順は、その実行前に、ユーザＡによって承認されなければならない可能性がある。そのようなオプションの手順は、同図において別のステップ４：６ａで示される。

後続のステップ４：７及びステップ４：８で、ユーザＢ４００によって開始されたサービスの結果が、当該サービスを定義した際に指定された１つ以上の宛先に配信される。この例では、当該結果は、ユーザＢに対して、例えば、ＳＭＳ、ＭＭＳ、ＨＴＴＰとして送信され、又はＳＩＰ／ＩＭＳを介して送信される。

ユーザＢのユーザ装置がコード生成機能を有する場合、シンボル・サーバ機能は、ユーザ装置と統合され、それにより、ステップ４：４は、代わりに、ユーザ装置４００とアプリケーション・サーバ３０１との間の情報のやり取りとして、典型的には、選択されたネットワークへのアクセスを提供する中間ノードを介して、実行されよう。上述した方法は、多種多様な目的のために用いられてもよく、それらの目的の全ては、種々の通信手段及び種々のサービス・プラットフォームに依存し得る。

一実施形態によれば、サービスを定義している第１のユーザは、当該サービスについてのシンボルとして、固有の２次元バーコードを読み出す。当該サービスは、例えば、関心のある、承認された関係者に公表されることになる、ユーザに関する一部の個人情報を表してもよく、それにより、この種の情報へのアクセス性を簡単化する。

そのような実装に相応しい個人情報の１つの典型的な例は、例えばｖＣａｒｄ情報のような電子名刺情報である。第１のユーザであるユーザＡは、シンボル・サーバから読み出されたシンボルを印刷していてもよく、第２のユーザであるユーザＢは、ユーザＡの名刺情報を要求する場合、例えば携帯電話のカメラを用いて、シンボルを登録し、かつ、例えばアプリケーション・サーバにより提供される各サービスの番号をダイヤルすることにより、このシンボルをアプリケーション・サーバに送信することを、選択していてもよい。

一旦、各シンボル・レコードがアプリケーション・サーバによって読み出されていると、当該アプリケーション・サーバは、ユーザＡ（即ち、管理ユーザ）によってそれまでに定義されたサービスを、典型的には、図４において追加サーバ４０２と称されるサーバのような１つ以上の付加的なサーバに関連情報を要求することによって、実行する。

この場合におけるように、要求された情報が名刺情報である場合、追加サーバ４０２は、アドレス帳サーバ（Address Book Server）であってもよく、当該アドレス帳サーバから読み出された情報は、図４のステップ４：６ａに示されているように、可能な限りユーザＡが要求を承認した後に、任意の従来の送信手段を用いてユーザＢに提供される。

名刺情報、又は任意の他の種類の印刷情報を読み出すための、提案した方法を実装することにより、情報交換のための手順は、大幅に簡単化されるだけでなく、より安全である可能性がある。これは、特に、印刷された事柄の内容を書き留めるか、又はタイプしようとする際に、当該印刷された事項の内容をスペルミスする危険性が、提案の自動化された概念を用いることによって完全に解消されるためである。

プレゼンス・サービスを代わりに扱う別の実施形態によれば、図４のユーザＡにより表され得るプレゼンティティは、例えば、ウェブ・サービスを介してアプリケーション・サーバにアクセスすることによってサービスを定義し、かつ、当該サービスに関連付けられているシンボルを印刷する。当該シンボルは、他のユーザ（即ち、ウォッチャ）が、見つけ、かつ、使用するために、関連する場所に表示される。図４においてユーザＢで表されるウォッチャが、シンボルを見つけ、かつ、ユーザＡをウォッチャのバディ・リストに加えることを決定する場合、ユーザＢは、シンボルを、例えばシンボルの写真を撮ることによって登録し、かつ、それをアプリケーション・サーバに送ってもよい。アプリケーション・サーバは、シンボル・サーバ、及びオプションとして１つ以上の追加サーバと通信し、それらは全体で、シンボル始動サービスを開始するためにプレゼンス・システムを表してもよい。

一旦、シンボルがシンボル・サーバによって復号され、かつ、アプリケーション・サーバに送信されると、アプリケーション・サーバは、ユーザＡのユーザ識別子を識別できるとともに、従来の文書管理手順に従って、ユーザＢのために、ユーザＢのバディ・リストにユーザＡを加えたり、当該バディ・リストからユーザＡを除去したりすることができる。

当然のことながら、プレゼンス・サービスに関連付けられたシンボルは、様々なアプリケーションに適用され得る。

プレゼンスに基づく第１のシナリオによれば、会議管理者は、次回の会議の参加者によって用いられる多数の属性を設定することを望む可能性がある。管理者は、この種類のイベントを管理するために様々なオプション／属性を提供するように構成されたウェブ・サービスを介して、アプリケーション・サーバにアクセスしてもよい。例えば好適なプレゼンス設定を定義する属性が、管理者により一旦設定されると、当該属性に関連付けられるバーコードが、アプリケーション・サーバにより生成され、かつ、管理者に送られる。当該管理者は、当該バーコードを、例えば印刷することにより再生できる。その結果、バーコードは、例えば、郵便物として印刷した形式で分配、若しくは電子メールやＳＭＳとして電子的に分配することによって、又は、典型的には各サービスを説明するテキストと一緒に、会議ホールの外に当該バーコードを公開することによって、会議参加者に利用可能とすることができる。その結果、バーコードを登録する出席者は、サービスを始動させることが可能となる。ここで、当該サービスは、オンライン・サービスであってもよく、当該オンライン・サービスは、例えば、管理者によって選択された属性であって、会議出席者のユーザ装置のディスプレイ又はモニタに表示する属性を含んでいてもよい。その結果、出席者は、これらの属性の一部又は全てを承認するように選ぶことを選択してもよい。

同様にプレゼンスに基づく、さらに別の典型的なシナリオによれば、列車に乗ろうとしているユーザが、例えば、客車の計画的な場所に配置されているバーコードを登録することによって、運輸会社からのプレゼンス情報に対して通知予約を開始してもよい。そのような登録は、典型的には、ユーザと運輸会社のプレゼンス・サービスを管理しているアプリケーション・サーバとの間のコネクションの自動的な設定を含んでいてもよく、それにより、ユーザが、例えば所望の目的地のような個人情報を入力できるようになる。説明したプレゼンス情報に対して通知予約を行うことによって、例えば、ユーザの所望の目的地として示された駅に列車が到着しようとしている際に示す、遅れ及び警報の少なくとも何れかについての情報のような、各列車のセットに関連付けられた最新のプレゼンス情報が、ユーザに提供されてもよい。

提案したシンボル関連メカニズムを用いて、プレゼンス・サービスがいかにして高度化されるかを示す、さらに別の実施形態によれば、広告ビラが、店舗の外側、又は任意の他の建物若しくは場所の近くに掲示されてもよい。それにより、ユーザが、当該ユーザのバディ・リストに対して、商店、建物又は場所の識別子を追加又は除外することが可能となり、その結果、例えば、広告、製品情報、ニュース又はスポーツの結果といった、ある所要の情報を受信するように準備する。管理者（例えば、店舗経営者）は、プレゼンス・サービスを選ぶことを選択し得る任意の個人に対して、同一の情報を提供する一般的なサービス、又は、ユーザが種々の選択肢から選ぶことができる可能性のあるサービスに、ユーザが接続できるようにするカスタマイズされたサービスを、定義してもよい。

上述したシナリオの何れかの一般的な原理に従ったメカニズムであって、提案したサービス定義及び始動メカニズムを実装することによって、サービスの管理者は、バディ・リストの使用を大幅に簡単化し得る。提案したメカニズムを、プレゼンスと組み合わせて用いることによっても、バディ・リストについての使用領域を拡大し得る。また、バディ・リストの管理を改善するこの方法によれば、現在のプレゼンス・サービスの顧客間で、プレゼンス・サービスのより頻繁な利用を促すだけでなく、この種類のサービスを使用することに新しい顧客を引き付けることができよう。

プレゼンス・サービスを同様に扱うさらに別の実施形態によれば、説明した概念を、様々な種類のプレゼンス・データの発行又は通知を簡単にする目的で、代わりに使用し得る。発行又は通知は、シンボルを登録することによって始動され、当該シンボルは、典型的には、当該シンボルによって意図した目的（即ち、当該シンボルを登録することによってどのような種類のサービスが始動されるか、及び、当該サービスをどのように始動するかの指示、の少なくとも何れか）を説明するテキストと一緒に、例えば会議室の外側に位置付けられる。シンボルの登録によって、ユーザのプレゼンスを更新するための手順が開始されてもよい。例えば、ユーザが会議にちょうど参加しようとしている、又は会議から離れようとしている場合、当該ユーザは、所与の指示に従って、単にシンボルを登録することによって、かつ、シンボルをアプリケーションに送ることによって、高速で、簡単で、かつ、使い勝手の良い方法で、当該ユーザの応対可能性（availability）を、応対可から取り込み中に変更し、及びその逆に変更することができる。

発行及び通知の少なくとも何れかの目的のために提案した、始動の概念を利用することによって、簡単化された方法で、プレゼンス情報にアクセスすること、及びプレゼンス情報を提供することの双方の可能性を、ユーザに与えることができる。提案した方法によれば、また、ユーザが移動中に自らのプレゼンス情報を更新し続けることが可能となり、それにより、プレゼンティティ及びウォッチャの双方からの必要な労力が最小限となる。

説明した始動の概念の実装には、精巧な始動サービスを提供するように設定された新たなアプリケーション・サーバが必要となる一方で、シンボル始動サービスを定義するのに用いられるＧＵＩ／Ｗｅｂサービスは、従来の技術を用いて提供されるであろう。

以下では、図５を参照して、上述の実施形態の何れかに係る、シンボルに関連付けられた動作を処理するように構成されたアプリケーション・サーバを構成する１つの方法について説明する。

同図は、アプリケーション・サーバ３０１について記述しており、アプリケーション・サーバ３０１は、プレゼンスに関連したサービスを取り扱うために専用化された場合、プレゼンス・サーバ機能を強化する。当然のことながら、図５では、上述した実施形態の何れかに係る、シンボル及び関連付けられた動作の処理を理解するのに必要な汎用的な機能のみを含んでおり、通信ネットワークにおいてアプリケーション・サーバを従来の方法で動作させるのに必要となり得る、任意の他の従来の及び周知の機能に関する言及を割愛している。

アプリケーション・サーバ３０１は、（ここではユーザＡ及びユーザＢによって表された）種々のユーザとの通信を処理するように構成された通信部５００を備え、ユーザは、サービス（即ち、シンボル・サーバ３０２によって作成されたシンボルに関連付けられることになる動作）を定義してもよいし、所定のサービスの実行を始動してもよいし、その両方を行ってもよい。ユーザＡ及びユーザＢは、典型的には、アプリケーション・サーバ３０１の１つ以上のアプリケーションと、典型的には中間ノード（図示せず）を介して通信するように構成され、アプリケーション・サーバへのアクセスを提供するユーザ装置を具備している。

通信部５００はまた、シンボル・サーバ３０２との通信、及びオプションとして１つ以上の追加サーバ４０２との通信を処理するように構成されており、追加サーバの各々は、要求されたサービスを実行する際にアプリケーション・サーバ３０１をサポートするように構成され得る。

上述した方法を実行するために必要な機能は、汎用部によって表されてもよく、この場合、ロジック部５０１と称されていてもよい。ロジック部５０１は、サービスが対話型サービス定義手順を通して定義される際だけでなく、ユーザが実行すべきサービスを始動している際に、ユーザ及びアプリケーション・サーバ３０１との通信を制御するように構成される。ロジック部５０１はまた、シンボル・サーバ３０２との、及び所定のサービスを実行するのに必要な任意の追加サーバ４０２との情報のやり取りを制御する。

ロジック部５０１は、ユーザがサービスをシンボルに関連付けた結果として、シンボル識別子を作成し、かつ、シンボル・レコードを作成及び記憶するだけでなく、ユーザがサービスを始動したときはいつでもシンボル・レコードを読み出すように構成される。ロジック部５０１はまた、シンボル・レコードを記憶するように構成された記憶装置５０２を制御する。

サービスを定義する場合、及びシンボル始動サービスを実行する場合に、アプリケーション・サーバと情報をやり取りするために、シンボル始動サービスを定義する管理ユーザだけでなく、始動するユーザも、サーバ（典型的にはＷｅｂサーバ５０３）を介してアプリケーション・サーバにアクセスできてもよい。各ユーザ装置もまた、特定の所定のサービスに関連付けられたシンボルを登録するための登録手段を具備していてもよいし、少なくとも管理者のユーザ装置もまた、ユーザがシンボル始動サービスを定義することを可能にするアプリケーション・サーバのアプリケーションと通信するように構成されてもよい。

シンボル・レコードは多くの種々の方法で構成され得るが、図６は、１つの代替的な構造を図示しており、２つのシンボル・レコード６００及び６０１の各々は、ａｍｄ ＩＤ６０２と、シンボルＩＤ６０３と、各シンボルＩＤに関連付けられた１つ以上の動作ステップ６０４とを含む。

本例では、ユーザ（ユーザＡ）が２つのサービスを定義しており、それらは、それぞれシンボルＩＤ ｘｘｘ０１及びシンボルＩＤ ｘｘｘ０２によって識別可能な、異なるシンボル・レコードに記憶されている。シンボルＩＤ ｘｘｘ０１によって識別される、シンボル・レコード６００のサービスは、３つの動作（即ち、Ｏｐ ００１とそれに続くＯｐ ００３及びＯｐ ００５）の集合に紐付けされている一方で、シンボルＩＤ ｘｘｘ０２によって識別されるシンボル・レコード６０１のサービスは、単一の動作ステップＯｐ ０１０に紐付けされている。

本発明について、特定の典型的な実施形態を参照して説明してきたが、本明細書は、概して本発明の概念を説明することのみを意図しており、かつ、本発明の範囲を限定するものと解釈されるべきではなく、本発明の範囲は、添付の特許請求の範囲によって確定される。

プレゼンス・システムは、典型的には、プレゼンス通知予約（subscription）をリストにまとめるリソース・リスト・サーバ（ＲＬＳ）１０６をも含む。これらのリストは、その後、ＲＬＳ ＸＤＭＳ１０７に記憶され、そこからそれらのリストをプレゼンス・サーバ１０３が入手可能である。

Claims (27)

1. 通信ネットワーク・ノードにおいてサービスを可能にする方法であって、
   シンボルに関連付けられる１つ以上の動作を要求する第１の要求であって、前記１つ以上の動作を識別する指示を含む第１の要求を、第１のユーザから受信するステップと、
   固有のシンボル識別子を生成するステップと、
   前記シンボル識別子に関連付けられたシンボル・レコードであって、前記シンボル識別子を前記１つ以上の動作に紐付けするシンボル・レコードを作成するステップと、
   前記シンボル識別子を、シンボル・サーバによって作成された前記シンボルに関連付けるステップと、
   前記シンボルを前記第１のユーザに転送するステップと、
   前記シンボルを含む第２の要求を受信するステップと、
   前記シンボルに対応する前記シンボル識別子を前記シンボル・サーバから読み出すステップと、
   前記シンボル識別子によって識別される前記シンボル・レコードに従って前記１つ以上の動作を実行することによって、前記サービスを可能にするステップと
   を含むことを特徴とする方法。
2. 前記第１の要求は、前記第１のユーザを前記サービスの管理者として識別する管理者識別子をさらに含むことを特徴とする請求項１に記載の方法。
3. 前記第２の要求は、前記サービスを始動する、前記第２の要求の開始者を識別するユーザ識別子をさらに含むことを特徴とする請求項１又は２に記載の方法。
4. 前記第１のユーザは、前記第２の要求の前記開始者と同一であることを特徴とする請求項３に記載の方法。
5. 前記指示は、前記通信ネットワーク・ノードのアプリケーションと前記第１のユーザのユーザ装置との間の情報のやり取りによってもたらされるものであることを特徴とする請求項１乃至４の何れか１項に記載の方法。
6. 前記アプリケーションには、ＷＥＢサーバを介してアクセス可能であることを特徴とする請求項５に記載の方法。
7. 前記情報のやり取りは、前記第１のユーザによって入力される１つ以上のユーザ可読コマンドを、前記通信ネットワーク・ノードが実行可能である１つ以上の動作に解釈することを含むことを特徴とする請求項５又は６に記載の方法。
8. 前記第２の要求は、ＭＭＳ又はＳＭＳを介して送信されることを特徴とする請求項１乃至７の何れか１項に記載の方法。
9. 前記第２の要求は、ＳＩＰ／ＩＭＳに基づくプロトコルを介して送信されることを特徴とする請求項１乃至７の何れか１項に記載の方法。
10. １つのサービスは、プレゼンスを使用可能なバディのリストに対して前記第１のユーザを追加すること、又は、当該リストから前記第１のユーザを削除することを含み、
    前記リストは、前記第２の要求の前記開始者のバディ・リストであること
    を特徴とする請求項１乃至９の何れか１項に記載の方法。
11. １つのサービスは、前記第２の要求の前記開始者のプレゼンスを更新することを含むことを特徴とする請求項１乃至１０の何れか１項に記載の方法。
12. １つのサービスは、発行コマンド又は通知コマンドを実行することを含み、当該コマンドは、前記第１のユーザ又は前記第２の要求の前記開始者に関するプレゼンス情報の発行及び通知の少なくとも何れかを始動又は停止することを特徴とする請求項１乃至１１の何れか１項に記載の方法。
13. １つのサービスは、
    前記第１のユーザによって指定される電子的な名刺情報を、アドレス帳サーバから読み出すステップと、
    前記１つ以上の動作のうちの少なくとも１つに従って設定される電子的な名刺を、前記第２の要求の前記開始者に対して提供するステップと
    に従って、電子的な名刺を分配することを含むことを特徴とする請求項１乃至１２の何れか１項に記載の方法。
14. サービスを可能にする通信ネットワーク・ノードであって、
    シンボルに関連付けられる１つ以上の動作を要求する第１の要求であって、前記１つ以上の動作を識別する指示を含む第１の要求を、第１のユーザから受信すると、固有のシンボル識別子を生成し、
    前記シンボル識別子に関連付けられたシンボル・レコードであって、前記シンボル識別子を前記１つ以上の動作に紐付けするシンボル・レコードを作成し、
    前記シンボル識別子を、シンボル・サーバによって作成された前記シンボルに関連付け、
    前記シンボルを前記第１のユーザに転送する
    ロジック部を備え、
    前記ロジック部は、さらに、
    前記シンボルを含む第２の要求を受信し、
    前記シンボルに対応する前記シンボル識別子を前記シンボル・サーバから読み出し、
    前記シンボル識別子によって識別される前記シンボル・レコードに従って前記１つ以上の動作を実行することによって、前記サービスを提供すること
    を特徴とする通信ネットワーク・ノード。
15. 前記ロジック部は、さらに、前記通信ネットワーク・ノードのアプリケーションと前記第１のユーザのユーザ装置との間の情報のやり取りを提供し、
    前記情報のやり取りは、前記指示をもたらすという目的を有することを特徴とする請求項１４に記載の通信ネットワーク・ノード。
16. 前記アプリケーションには、ＷＥＢサーバを介してアクセス可能であることを特徴とする請求項１５に記載の通信ネットワーク・ノード。
17. 前記アプリケーションは、前記第１のユーザによって入力される１つ以上のユーザ可読コマンドを、前記通信ネットワーク・ノードが実行可能である１つ以上の動作に解釈することを特徴とする請求項１５又は１６に記載の通信ネットワーク・ノード。
18. ＳＩＰ／ＩＭＳに基づくプロトコルを介した前記第２の要求を受信する通信部をさらに備えることを特徴とする請求項１４乃至１７の何れか１項に記載の通信ネットワーク・ノード。
19. ＭＭＳ又はＳＭＳを介した前記第２の要求を受信する通信部をさらに備えることを特徴とする請求項１４乃至１８の何れか１項に記載の通信ネットワーク・ノード。
20. 前記ロジック部は、さらに、プレゼンスを使用可能なバディのリストに対して前記第１のユーザを追加し、又は、当該リストから前記第１のユーザを削除するという目的を有するサービスを可能にし、
    前記リストは、前記第２の要求の前記開始者のバディ・リストであること
    を特徴とする請求項１４乃至１９の何れか１項に記載の通信ネットワーク・ノード。
21. 前記ロジック部は、さらに、前記第２の要求の前記開始者のプレゼンスを更新するという目的を有するサービスを可能にすることを特徴とする請求項１４乃至２０の何れか１項に記載の通信ネットワーク・ノード。
22. 前記ロジック部は、前記１つ以上の動作のうちの少なくとも１つに従って発行コマンド又は通知コマンドを起動し、当該コマンドは、前記第１のユーザ又は前記第２の要求の前記開始者に関するプレゼンス情報の発行及び通知の少なくとも何れかを始動又は停止することを特徴とする請求項１４乃至２１の何れか１項に記載の通信ネットワーク・ノード。
23. 前記ロジック部は、さらに、前記第２の要求の前記開始者に対して電子的な名刺を分配するという目的を有するサービスを可能にすることを特徴とする請求項１４乃至２２の何れか１項に記載の通信ネットワーク・ノード。
24. 前記ロジック部は、
    前記第１のユーザによって指定される電子的な名刺情報を、アドレス帳サーバから読み出し、
    前記１つ以上の動作のうちの少なくとも１つに従って設定される電子的な名刺を、前記第２の要求の前記開始者に対して提供すること
    を特徴とする請求項２３に記載の通信ネットワーク・ノード。
25. 前記通信ネットワーク・ノードは、ＳＭＳ又はＭＭＳを介して、前記第１のユーザ及び前記第２の要求の開始者の少なくとも何れかと通信することを特徴とする請求項１４乃至２４の何れか１項に記載の通信ネットワーク・ノード。
26. 前記通信ネットワーク・ノードは、アプリケーション・サーバであることを特徴とする請求項１４乃至２５の何れか１項に記載の通信ネットワーク・ノード。
27. 前記アプリケーション・サーバは、プレゼンス機能を備えることを特徴とする請求項２６に記載の通信ネットワーク・ノード。

Images