JP2009532795A

JP2009532795A - Ｓｉｐマルチメディアサービスにおける削除メカニズム

Info

Publication number: JP2009532795A
Application number: JP2009503713A
Authority: JP
Inventors: アダムハルナ; アルトレピサーリ
Original assignee: Nokia Oyj
Current assignee: Nokia Oyj
Priority date: 2006-04-03
Filing date: 2007-04-03
Publication date: 2009-09-10
Anticipated expiration: 2027-04-03
Also published as: KR100977188B1; RU2404549C2; EP2008425A2; CA2661954A1; CA2661954C; CN101455050A; US20070233682A1; BRPI0710719A2; CN101455050B; US7805490B2; JP4775490B2; BRPI0710719B1; MX2008012811A; RU2008140278A; ZA200809301B; WO2007113770A2; AU2007232195B2; EP2008425B1; EP2008425A4; WO2007113770A3

Abstract

ＳＩＰマルチメディア環境においてユーザアカウントから項目を削除する方法を提供する。インスタントメッセージなどの項目が削除される場合、ユーザ装置からこの項目の一意の識別子を含むＳＩＰＲＥＦＥＲメッセージが送信されてユーザアカウントから項目を削除する。送信された要求に応答して、仮想エージェントとネットワークベースの削除項目の場所との間にＳＩＰＩＮＶＩＴＥセッションが確立される。ＳＩＰＩＮＶＩＴＥセッションの確立後、項目がユーザアカウントからネットワークベースの削除項目の場所に転送され、ユーザアカウントから削除される。
【選択図】図８

Description

本発明は、一般に、セッション開始プロトコル（ＳＩＰ）サービス及びＳＩＰｆｏｒｉｎｓｔａｎｔｍｅｓｓａｇｉｎｇａｎｄｐｒｅｓｅｎｃｅｌｅｖｅｒａｇｉｎｇｅｘｔｅｎｔｉｏｎｓ（ＳＩＭＰＬＥ）サービスに関する。特に、本発明は、インスタントメッセージング（ＩＭ）及びプッシュツートーク（ＰｏＣ）サービスなどのＳＩＰ／ＳＩＭＰＬＥベースのサービスに関する。

本節は、特許請求の範囲に記載する本発明に至るまでの背景又は状況を示すことを目的とする。本明細書における説明は、追求できる概念を含むことができるが、この概念が必ずしも以前に考案又は追求されたものであるとは限らない。従って、本節で説明する内容は、本明細書において特に示さない限り、本出願における説明及び特許請求の範囲にとっての先行技術ではなく、本節に含まれることにより先行技術であると認められるものではない。

ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅ（ＯＭＡ）とは、移動電話業界で使用されるオープンスタンダードを共同で開発する標準化団体のことである。ＯＭＡは、国家、事業者、及び移動端末を越えて機能する相互運用可能なサービスイネーブラの開発を支援し、市場の必要性により推進される。移動電話市場を拡大するために、ＯｐｅｎＭｏｂｉｌｅＡｌｌｉａｎｃｅをサポートする企業は、様々な新しい拡張された移動情報、通信及びエンターテインメントサービスの迅速で広範な開発及び展開の支援に努めている。

ＯＭＡは、ＩｎｔｅｒｎａｔｉｏｎａｌＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）のＳＩＭＰＬＥワーキンググループにより開発されたＳＩＰ、メッセージセッションリレープロトコル（ＭＳＲＰ）及び拡張可能マークアップ言語（ＸＭＬ）構成アクセスプロトコル（ＸＣＡＰ）というプロトコルに基づくＩＭサービスを現在開発中である。インスタントメッセージングサービスは、複数の専用技術及びＷｉｒｅｌｅｓｓＶｉｌｌａｇｅ仕様により既に展開されている。

ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ−０４．ｔｘｔｄｒａｆｔ−ｇａｒｃｉａ−ｓｉｐｐｉｎｇ−ｆｉｌｅ−ｔｒａｎｓｆｅｒ−ｍｅｃｈ−００．ｔｘｔ

現在、ＳＩＰマルチメディアサービス環境において削除メカニズムの必要性が存在する。ｈｔｔｐ環境では、文書を削除する必要がある場合、単に「ｈｔｔｐｄｅｌｅｔｅ」コマンドが出されるだけである。しかしながら、現在、ＳＩＰ環境用に定義された対応する削除機能又はファンクションは存在しない。実際、サービスのためのＳＩＰ拡張でさえも、このような機能を定義してこなかった。現行のマルチメディアサービス、特にＯＭＡＳＩＰ／ＳＩＭＰＬＥＩＭでは、メッセージの保存及び取得に関して複数の要件が存在する。保存済みのメッセージを削除及び選択的に削除する必要性は存在するものの、このようなメカニズムはまだ定義されていない。

本発明は、ＳＩＰマルチメディアサービスで使用するための新規の削除メカニズムを含む。本発明は、この目的のために様々なＳＩＰマルチメディアサービス環境機能の使用を含む。１つの実施形態では、ネットワーク内に「ごみ箱」が定義され、ＳＩＰの統一資源識別子と関連付けられる。ネットワーク内に保存されたメッセージに一意の識別子が割り当てられる。ユーザがメッセージを削除したいと望む場合、当事者は、メッセージと、ネットワークで定義されるゴミ箱との間にＳＩＰ／ＭＳＲＰ機能を開設するように要求する。処理されると、メッセージは、ユーザのメール保存サーバ内のユーザアカウントを離れてごみ箱に転送される。

ＳＩＰＲＥＦＥＲメソッド、仮想ユーザエージェント、及びＳＩＰＵＲＩなどの既存の定義済みツールを使用するので、本発明のシステム及び方法は単純かつ導入が簡単である。

本発明の上記の及びその他の利点及び特徴、並びにその構成及び動作方法は、以下で説明する複数の図面を通じて同じ要素が同じ番号を有する添付図面と併せて、以下の詳細な説明から明らかになるであろう。

本発明は、ＳＩＰマルチメディアサービスで使用するための新規の削除メカニズムを含む。本発明は、この目的のために様々なＳＩＰマルチメディアサービス環境機能の使用を含む。１つの実施形態では、ネットワーク内に削除項目のための「ごみ箱」又は同様の場所が定義され、ＳＩＰの統一資源識別子と関連付けられる。ネットワーク内に保存されたメッセージに一意の識別子が割り当てられる。ユーザがメッセージを削除したいと望む場合、当事者は、メッセージとネットワークで定義されるゴミ箱との間にＳＩＰ／ＭＳＲＰセッション機能を開設するように要求する。処理されると、メッセージは、ユーザのメール保存サーバ内のユーザアカウントを離れてごみ箱に転送される。

図１は、本発明の１つの実施形態によるＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。特に、図１は、本明細書で定義されるユーザ／クライアント装置１００と、メールストレージのユーザアカウント１１０と、ごみ箱１２０との間の相互関係を示している。ユーザアカウント１１０及びごみ箱１２０の双方は、ユーザ／クライアント装置から遠隔に配置される。図１に示す実施形態では、ユーザ／クライアント装置のＳＩＰＵＲＩは、「Ｕｓｅｒ＠Ｓｏｎｅｒａ．ｃｏｍ」である。ユーザアカウントのＳＩＰＵＲＩは、「Ｕｓｅｒ＠ｍａｉｌｓｅｒｖｅｒ５７．Ｓｏｎｅｒａ．ｃｏｍ」である。ごみ箱のＳＩＰＵＲＩは、「ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ」である。

上述したように、ネットワーク内に保存されたメッセージには、一意のメッセージ識別子を割り当てることができる。このような３つのメッセージを、「１３２４２＠ｍａｉｌｓｅｒｖｅｒ５７．Ｓｏｎｅｒａ．ｃｏｍ」（ＭＳＧ１）、「１３２４３＠ｍａｉｌｓｅｒｖｅｒ５７．Ｓｏｎｅｒａ．ｃｏｍ」（ＭＳＧ２）、及び「１３２４４＠ｍａｉｌｓｅｒｖｅｒ５７．Ｓｏｎｅｒａ．ｃｏｍ」（ＭＳＧ３）という識別子で図１の１３０に示す。或いは、メッセージをファイルとして保存してもよい。１つの実施形態では、各メッセージにファイル名、ファイルタイプ、及びハッシュ値を与えることができる。このような３つのメッセージを、「Ｆｉｌｅ１＝（ｆｉｌｅｎａｍｅ，ｆｉｌｅｔｙｐｅ，ｕｎｉｑｕｅｈａｓｈｖａｌｕｅ）」、「Ｆｉｌｅ２＝（ｆｉｌｅｎａｍｅ，ｆｉｌｅｔｙｐｅ，ｕｎｉｑｕｅｈａｓｈｖａｌｕｅ）」、及び「Ｆｉｌｅ３＝（ｆｉｌｅｎａｍｅ，ｆｉｌｅｔｙｐｅ，ｕｎｉｑｕｅｈａｓｈｖａｌｕｅ）」という識別子で図２に示す。

図１の１４０において、ユーザがＭＳＧ２を削除したいと決定する。この時点で、ユーザ／クライアント装置１００は、ユーザアカウント１１０におけるメッセージ識別子１３２４３＠ｍａｉｌｓｅｒｖｅｒ５７．Ｓｏｎｅｒａ．ｃｏｍ（このメッセージ識別子が仮想ユーザエージェント１５５としての役目を果たす）へＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求１５０を送信する。ＳＩＰＲＥＦＥＲ要求は、Ｒｅｆｅｒ−ｔｏヘッダ内にネットワークベースのごみ箱のアドレス（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）を有する。ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求１５０は、ネットワークベースのごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）とのＳＩＰセッションを開設するように要求する役目を果たす。仮想ユーザエージェント１５５は、１６０において、ユーザ／クライアント装置１００からのＳＩＰＲＥＦＥＲ要求を「２０２ＡＣＣＥＰＴ」メッセージで受け入れることにより、これに応答する。仮想ユーザエージェント１５５はまた、１７０において、ごみ箱１２０とのＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求を送信する。ごみ箱１２０は、１８０においてこのセッションを受け入れる。１９０において、セッション記述プロトコル（ＳＤＰ）のメディア属性がａ＝ＳｅｎｄＯｎｌｙにセットされることにより、仮想ユーザエージェント１５５とのＳＩＰセッションが、メッセージセッションリレープロトコル（ＭＳＲＰ）の形式で正式に開設される。仮想ユーザエージェント１５５は、２００において、ユーザ／クライアント１００にＳＩＰセッションを通知する段階へと進み、ユーザ／クライアント装置１００は、２１０においてこの通知の確認応答を行う。ＳＩＰ／ＭＳＲＰセッションにおいて、ＭＳＧ２がユーザアカウント１１０からネットワークベースのごみ箱１２０へ送信されることにより、ＭＳＧ２はユーザアカウント１１０から消滅する。メッセージＭＳＧ２の送信に成功した後、仮想ユーザエージェント１５５とごみ箱１２０との間のＳＩＰセッションは破棄される。２２０に示す最終結果として、ユーザのメール保存サーバ内のユーザアカウント１１０内にはＭＳＧ１及びＭＳＧ３のみが存在することになる。

本発明の代替の実施形態では、ユーザアカウント１１０の機能とごみ箱１２０の機能とがまとめられる。この状況では、ＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求の送信１７０、この要求の確認応答１８０、及びＭＳＲＰによるＳＩＰセッションの開設１９０は不要となる。

メッセージをファイルとして保存する代替の実施形態を図２に示す。この実施形態では、保存又は選択されたメッセージをごみ箱に回収するためのメカニズムは、別紙Ｂとして添付するファイル転送の草案に基づくことができ、この草案は本出願に組み入れられる。この実施形態では、ＲＥＦＥＲ要求は、削除される（単複の）ファイルについてのＳＤＰ記述を含むことができる。

図２の１４０において、ユーザがＭＳＧ２（Ｆｉｌｅ２）を削除したいと決定する。この時点で、ユーザ／クライアント装置１００は、ユーザアカウント１１０におけるメール保存サーバ（このサーバが仮想ユーザエージェント１５５としての役目を果たす）へＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求１５０を送信する。ＳＩＰＲＥＦＥＲ要求は、Ｒｅｆｅｒ−ｔｏヘッダ内にネットワークベースのごみ箱のアドレス（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）を有する。ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求１５０は、ネットワークベースのごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）とのＳＩＰセッションを開設するように要求する役目を果たす。仮想ユーザエージェント１５５は、１６０において、ユーザ／クライアント装置１００からのＳＩＰＲＥＦＥＲ要求を「２０２ＡＣＣＥＰＴ」メッセージで受け入れることにより、これに応答する。仮想ユーザエージェント１５５はまた、１７０において、ごみ箱１２０とのＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求を送信する。ごみ箱１２０は、１８０においてこのセッションを受け入れる。１９０において、セッション記述プロトコル（ＳＤＰ）のメディア属性がａ＝ＳｅｎｄＯｎｌｙにセットされることにより、仮想ユーザエージェント１５５とのＳＩＰセッションが、メッセージセッションリレープロトコル（ＭＳＲＰ）の形式で正式に開設される。仮想ユーザエージェント１５５は、２００において、ユーザ／クライアント１００にＳＩＰセッションを通知する段階へと進み、ユーザ／クライアント装置１００は、２１０においてこの通知の確認応答を行う。ＳＩＰ／ＭＳＲＰセッションにおいて、Ｆｉｌｅ２がユーザアカウント１１０からネットワークベースのごみ箱１２０へ送信されることにより、ＭＳＧ２はユーザアカウント１１０から消滅する。ファイルＦｉｌｅ２（ＭＳＧ２）の送信に成功した後、仮想ユーザエージェント１５５とごみ箱１２０との間のＳＩＰセッションは破棄される。２２０に示す最終結果として、ユーザのメール保存サーバ内のユーザアカウント１１０内にはＭＳＧ１（Ｆｉｌｅ１）及びＭＳＧ３（Ｆｉｌｅ３）のみが存在することになる。

本発明の代替の実施形態を図３に示す。この実施形態では、ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求は、仮想ユーザエージェントを飛び越えてネットワークベースのごみ箱へ直接送信される。例えば、図３の３４０において、ユーザがＭＳＧ２を削除したいと決定する。この時点で、ユーザ／クライアント装置１００は、ごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）へＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求３５０を送信する。ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求３５０は、ネットワークベースのごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）と、以下の一方が使用されている場合、ユーザアカウント１１０又は仮想ユーザエージェント１５５との間にＳＩＰセッションを開設するように要求する役目を果たす。ごみ箱１２０は、３６０において、ユーザ／クライアント装置１００からのＳＩＰＲＥＦＥＲ要求を「２０２ＡＣＣＥＰＴ」メッセージで受け入れることにより、これに応答する。ごみ箱１２０はまた、３７０において、仮想ユーザエージェント１５５とのＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求を送信する。仮想ユーザエージェント１５５は、３８０においてこのセッションを受け入れる。３９０において、セッション記述プロトコル（ＳＤＰ）のメディア属性がａ＝ＲｅｃｖＯｎｌｙにセットされることにより、仮想ユーザエージェント１５５とのＳＩＰセッションが、メッセージセッションリレープロトコル（ＭＳＲＰ）の形式で正式に開設される。ごみ箱１２０は、４００において、ユーザ／クライアント１００にＳＩＰセッションを通知する段階へと進み、ユーザ／クライアント装置１００は、４１０においてこの通知の確認応答を行う。ＳＩＰ／ＭＳＲＰセッションにおいて、ＭＳＧ２がユーザアカウント１１０からネットワークベースのごみ箱１２０へ送信されることにより、ＭＳＧ２はユーザアカウント１１０から消滅する。メッセージＭＳＧ２の送信に成功した後、仮想ユーザエージェント１５５とごみ箱１２０との間のＳＩＰセッションは破棄される。４２０に示す最終結果として、ユーザのメール保存サーバ内のユーザアカウント１１０内にはＭＳＧ１及びＭＳＧ３のみが存在することになる。

前述の実施形態と同様に、代替として、ユーザアカウント１１０の機能とごみ箱１２０の機能とがまとめられる。この状況では、ＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求の送信３７０、この要求の確認応答３８０、及びＭＳＲＰによるＳＩＰセッションの開設３９０は不要となる。

図４に示す本発明の実施形態は、図３の実施形態の代替案である。図３と同様に、この実施形態では、ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求が、仮想ユーザエージェントを飛び越えてネットワークベースのごみ箱へ直接送信される。しかしながら、図４の実施形態では、保存又は選択されたメッセージをごみ箱に回収するためのメカニズムは、別紙Ｂとして添付するファイル転送の草案に基づく。この実施形態では、ＲＥＦＥＲ要求は、削除される（単複の）ファイルについてのＳＤＰ記述を含む。

図４の３４０において、ユーザがＭＳＧ２（Ｆｉｌｅ２）を削除したいと決定する。この時点で、ユーザ／クライアント装置１００は、ごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）へＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求３５０を送信する。ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求３５０は、ネットワークベースのごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）とのＳＩＰセッションを開設するように要求する役目を果たす。ごみ箱１２０は、３６０において、ユーザ／クライアント装置１００からのＳＩＰＲＥＦＥＲ要求を「２０２ＡＣＣＥＰＴ」メッセージで受け入れることにより、これに応答する。ごみ箱１２０はまた、３７０において、仮想ユーザエージェント１５５とのＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求を送信する。仮想ユーザエージェント１５５は、３８０においてこのセッションを受け入れる。３９０において、セッション記述プロトコル（ＳＤＰ）のメディア属性がａ＝ＲｅｃＯｎｌｙにセットされることにより、仮想ユーザエージェント１５５とのＳＩＰセッションが、メッセージセッションリレープロトコル（ＭＳＲＰ）の形式で正式に開設される。ごみ箱１２０は、４００において、ユーザ／クライアント１００にＳＩＰセッションを通知する段階へと進み、ユーザ／クライアント装置１００は、４１０においてこの通知の確認応答を行う。ＳＩＰ／ＭＳＲＰセッションにおいて、Ｆｉｌｅ２（ＭＳＧ２）がユーザアカウント１１０からネットワークベースのごみ箱１２０へ送信されることにより、Ｆｉｌｅ２（ＭＳＧ２）はユーザアカウント１１０から消滅する。Ｆｉｌｅ２（ＭＳＧ２）の送信に成功した後、仮想ユーザエージェント１５５とごみ箱１２０との間のＳＩＰセッションは破棄される。４２０に示す最終結果として、ユーザのメール保存サーバ内のユーザアカウント１１０内にはＦｉｌｅ１（ＭＳＧ１）及びＦｉｌｅ３（ＭＳＧ３）のみが存在することになる。

別の実施形態では、ユーザが、複数の保存されたメッセージを選択して削除することができる。図５に示すこの実施形態では、Ｍｕｌｔｉｐｌｅ−ＲＥＦＥＲ要求をごみ箱１２０へ送信して複数の選択されたメッセージを削除することができる。本出願に組み入れられる別紙Ａは、Ｍｕｌｔｉｐｌｅ−ＲＥＦＥＲ要求の１つの実施形態又は実施構成を示すものである。図５に示す実施形態では、ＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求が、仮想ユーザエージェントを飛び越えてネットワークベースのごみ箱へ直接送信される。或いは、図１に示す実施形態に関して説明したように、ＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求を仮想ユーザエージェントへ送信してもよい。

図５の５４０において、ユーザがＭＳＧ２及びＭＳＧ３を削除したいと決定する。この時点で、ユーザ／クライアント装置１００は、削除される保存メッセージ（この場合はＭＳＧ２及びＭＳＧ３）のＵＲＩを含むＵＲＩリストを含んだＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求５５０をごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）へ送信する。ＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求５５０は、ネットワークベースのごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）とのＳＩＰセッションを開設するように要求する役目を果たす。ごみ箱１２０は、５７０及び５７１において、削除される個々のメッセージごとにそれぞれ、仮想ユーザエージェント１５５及び１５６とのＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求を送信する。この場合、ＩＮＶＩＴＥ要求５７０はＭＳＧ２に対応し、ＩＮＶＩＴＥ要求５７１はＭＳＧ３に対応する。仮想ユーザエージェント１５５及び１５６は、５８０及び５８１においてこのセッションをそれぞれ受け入れる。５９０において、セッション記述プロトコル（ＳＤＰ）のメディア属性がａ＝ＲｅｃｖＯｎｌｙにセットされることにより、仮想ユーザエージェント１５５とのＳＩＰセッションが、メッセージセッションリレープロトコル（ＭＳＲＰ）の形式で正式に開設され、５９１において、仮想ユーザエージェント１５６とのＳＩＰセッションが開設される。ＳＩＰ／ＭＳＲＰセッションにおいて、ＭＳＧ２及びＭＳＧ３がユーザアカウント１１０からネットワークベースのごみ箱１２０へ送信されることにより、ＭＳＧ２及びＭＳＧ３はユーザアカウント１１０から消滅する。ＭＳＧ２及びＭＳＧ３の送信に成功した後、仮想ユーザエージェント１５５及び１５６とごみ箱１２０との間のＳＩＰセッションは破棄される。６２０に示す最終結果として、ユーザのメール保存サーバ内のユーザアカウント１１０内にはＭＳＧ１のみが存在することになる。

前述の実施形態と同様に、ユーザアカウント１１０の機能とごみ箱１２０の機能とをまとめることもできる。この状況では、ＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求の送信５７０及び５７１、これらの要求の確認応答５８０及び５８１、及びＭＳＲＰによるＳＩＰセッションの開設５９０及び５９１は不要となる。

図６に示す実施形態は、保存又は選択されたメッセージをごみ箱に回収するためのメカニズムが、別紙Ｂとして添付するファイル転送の草案に基づく場合の複数メッセージの削除を示している。この実施形態では、ＲＥＦＥＲ要求は、この場合も削除されるファイルについてのＳＤＰ記述を含むことができる。図６の５４０において、ユーザがＭＳＧ２（Ｆｉｌｅ２）及びＭＳＧ３（Ｆｉｌｅ３）を削除したいと決定する。この時点で、ユーザ／クライアント装置１００は、削除される保存メッセージ（ファイル）（この場合はＭＳＧ２及びＭＳＧ３）に関して、別紙Ｂで説明する構文を用いてＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求５５０をごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）へ送信する。この場合、削除される予定の個々のファイル（メッセージ）のＳＤＰパラメータは、個別のメディア行「ｍ＝」で送信される必要がある。ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求５５０は、ネットワークベースのごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）と、以下の一方が使用されている場合、ユーザアカウント１１０又は仮想ユーザエージェント１５５との間にＳＩＰセッションを開設するように要求する役目を果たす。ごみ箱１２０は、５７０において、仮想ユーザエージェント１５５とのＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求を送信する。仮想ユーザエージェント１５５は、５８０及び５８１において、削除される個々のファイルのセッションをそれぞれ受け入れる。５９０において、セッション記述プロトコル（ＳＤＰ）のメディア属性がａ＝ＲｅｃｖＯｎｌｙにセットされることにより、仮想ユーザエージェント１５５とのＳＩＰセッションが、メッセージセッションリレープロトコル（ＭＳＲＰ）の形式で正式に開設され、５９１において、仮想ユーザエージェント１５６とのＳＩＰセッションが開設される。ＳＩＰ／ＭＳＲＰセッションにおいて、Ｆｉｌｅ２（ＭＳＧ２）及びＦｉｌｅ３（ＭＳＧ３）がユーザアカウント１１０からネットワークベースのごみ箱１２０に送信されることにより、ＭＳＧ２（Ｆｉｌｅ２）及びＭＳＧ３（Ｆｉｌｅ３）はユーザアカウント１１０から消滅する。Ｆｉｌｅ２（ＭＳＧ２）及びＦｉｌｅ３（ＭＳＧ３）の送信に成功した後、仮想ユーザエージェント１５５とごみ箱１２０との間のＳＩＰセッションは破棄される。６２０に示す最終結果として、ユーザのメール保存サーバ内のユーザアカウント１１０内にはＦｉｌｅ１（ＭＳＧ１）のみが存在することになる。

さらに別の実施形態では、ユーザが、保存されている全てのメッセージを選択して削除することができる。図７に示すこの実施形態では、ＲＥＦＥＲ要求をごみ箱１２０へ送信して、個別のメッセージ又はメッセージのＵＲＩリストではなくユーザのメール保存アカウントのＳＩＰＵＲＩを参照することにより、全てのメッセージを削除することができる。図７に示す実施形態の場合にも、ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求は、仮想ユーザエージェントを飛び越えてネットワークベースのごみ箱へ直接送信される。或いは、図１に示す実施形態に関して説明したように、ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求を仮想ユーザエージェントへ送信してもよい。

図７の７４０において、ユーザが、自身のメール保存アカウント内のメッセージの全てを削除したいと決定する。この時点で、ユーザ／クライアント装置１００は、ユーザのメール保存アカウントのＳＩＰＵＲＩ（この場合はＵｓｅｒ＠ｍａｉｌｓｅｒｖｅｒ５７．Ｓｏｎｅｒａ．ｃｏｍ）を含むＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求７５０をごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）へ送信する。ＳＩＰＲＥＦＥＲｗｉｔｈＩＮＶＩＴＥ要求７５０は、ネットワークベースのごみ箱１２０（ＲｅｃｙｃｌｅＢｉｎ＠ｍａｉｌｓｅｒｖｅｒ．ｓｏｎｅｒａ．ｃｏｍ）と、以下の一方が使用されている場合、ユーザアカウント１１０又は仮想ユーザエージェント１５５との間にＳＩＰセッションを開設するように要求する役目を果たす。ごみ箱１２０は、７６０において、ユーザ／クライアント装置１００からのＳＩＰＲＥＦＥＲ要求を「２０２ＡＣＣＥＰＴ」メッセージで受け入れることにより、これに応答する。ごみ箱１２０はまた、７７０において、仮想ユーザエージェント１５５とのＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求を送信する。仮想ユーザエージェント１５５は、７８０においてこのセッションを受け入れる。７９０において、セッション記述プロトコル（ＳＤＰ）のメディア属性がａ＝ＲｅｃｖＯｎｌｙにセットされることにより、仮想ユーザエージェント１５５とのＳＩＰセッションが、メッセージセッションリレープロトコル（ＭＳＲＰ）の形式で正式に開設される。ごみ箱１２０は、８００において、ユーザ／クライアント１００にＳＩＰセッションを通知する段階へと進み、ユーザ／クライアント装置１００は、８１０においてこの通知の確認応答を行う。ＳＩＰ／ＭＳＲＰセッションにおいて、ユーザのメール保存サーバ内の全てのメッセージ（この場合はＭＳＧ１、ＭＳＧ２、及びＭＳＧ３）がユーザアカウント１１０からネットワークベースのごみ箱１２０へ送信されることにより、全てのメッセージはユーザアカウント１１０から消滅する。ユーザのメール保存アカウントからの全てのメッセージの送信に成功した後、仮想ユーザエージェント１５５とごみ箱１２０との間のＳＩＰセッションは破棄される。８２０に示す最終結果として、ユーザのメール保存サーバ内のユーザアカウント１１０内にはメッセージが全く残されていないことになる。

前述の実施形態と同様に、ユーザアカウント１１０の機能とごみ箱１２０の機能とをまとめることもできる。この状況では、ＳＩＰセッションを開設するためのＩＮＶＩＴＥ要求の送信７７０、この要求の確認応答７８０、及びＭＳＲＰによるＳＩＰセッションの開設７９０は不要となる。

図８は、ネットワークを通じて通信することができる複数の通信装置を含むシステム１０を示す図であり、該システムにおいて本発明を利用することができる。システム１０は、以下に限定されるわけではないが、移動電話ネットワーク、無線ローカルエリアネットワーク（ＬＡＮ）、Ｂｌｕｅｔｏｏｔｈパーソナルエリアネットワーク、Ｅｔｈｅｒｎｅｔ（登録商標）ＬＡＮ、トークンリングＬＡＮ、広域ネットワーク、インターネット等を含む有線又は無線ネットワークの任意の組み合わせを含むことができる。システム１０は、有線及び無線の両方の通信装置を含むことができる。

例示のために、図８に示すシステム１０は、移動電話ネットワーク１１及びインターネット２８を含む。インターネット２８への接続は、以下に限定されるわけではないが、長距離無線接続、短距離無線接続、及び限定的な意味ではないが電話回線、ケーブル回線、電力線などを含む様々な有線接続を含むことができる。

システム１０の例示的な通信装置は、以下に限定されるわけではないが、移動電話１２、ＰＤＡと移動電話との組み合わせ１４、ＰＤＡ１６、統合メッセージング装置（ＩＭＤ）１８、デスクトップコンピュータ２０、及びノートブックコンピュータ２２を含むことができる。通信装置は、固定型、又は移動中の個人が携行する場合のように移動型であってもよい。通信装置を、以下に限定されるわけではないが、自動車、トラック、タクシー、バス、船、飛行機、自転車、オートバイ等を含む輸送手段に配置することもできる。通信装置の一部又は全ては、呼及びメッセージを送受信することができ、基地局２４への無線接続２５を介してサービスプロバイダと通信することができる。移動電話ネットワーク１１とインターネット２８との間の通信を可能にするネットワークサーバ２６に基地局２４を接続することができる。システム１０は、追加の通信装置及び異なるタイプの通信装置を含むことができる。

図９及び図１０は、１つの代表的な移動電話１２を示す図であり、該移動電話内で本発明を実行することができる。しかしながら、本発明は、１つの特定のタイプの移動電話１２又はその他の電子装置に限定されるものではないということを理解されたい。使用可能な他のタイプの電子装置として、以下に限定されるわけではないが、ＰＤＡ１６、ＰＤＡと移動電話との組み合わせ１４、ＩＭＤ１８、デスクトップコンピュータ２０、及びノートブックコンピュータ２２を含むことができる。通信装置は、固定型、又は移動中の個人が携行する場合のように移動型であってもよい。通信装置を、以下に限定されるわけではないが、自動車、トラック、タクシー、バス、船、飛行機、自転車、オートバイ等を含む輸送手段に配置することもできる。

図９及び図１０の移動電話１２は、ハウジング３０、液晶ディスプレイ形式のディスプレイ３２、キーパッド３４、マイク３６、受話口３８、電池４０、赤外線ポート４２、アンテナ４４、本発明の１つの実施形態によるＵＩＣＣ形式のスマートカード４６、カードリーダ４８、無線インタフェース回路５２、コーデック回路５４、コントローラ５６、及びメモリ５８を含む。個々の回路及び要素は、全て当業で周知の種類のもの、例えばＮｏｋｉａ社の移動電話の範囲内のものである。例示のために、図８に示すシステム１０は、移動電話ネットワーク１１及びインターネット２８を含む。インターネット２８への接続は、以下に限定されるわけではないが、長距離無線接続、短距離無線接続、及び限定的な意味ではないが電話回線、ケーブル回線、電力線などを含む様々な有線接続を含むことができる。

本発明は、一般的なコンテキストの方法ステップで説明されており、ネットワーク環境におけるコンピュータによって実行される、プログラムコードなどのコンピュータ実行可能命令を含むプログラム製品により、上記方法ステップを１つの実施形態において実行することができる。一般的にプログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造等が含まれ、これらは特定のタスクを実行するか、或いは特定の抽象的なデータ型を実装する。コンピュータ実行可能命令、それに関するデータ構造、及びプログラムモジュールは、本明細書に開示する方法のステップを実行するためのプログラムコードの例を表すものである。特定の順序のこのような実行可能命令又はそれに関するデータ構造は、上記ステップにおいて説明した機能を実行するための対応動作の例を表すものである。

様々なデータベース検索ステップ、相関ステップ、比較ステップ、及び決定ステップを実行するための、規則に基づく論理及びその他の論理を含む標準的なプログラミング技術によって、本発明のソフトウェア及びウェブの実装を実現することができる。本明細書及び特許請求の範囲において用いられる「コンポーネント」及び「モジュール」という用語は、１又はそれ以上の行のソフトウェアコード、及び／又はハードウェアの実装、及び／又は手動入力を受け入れるための機器を用いた実装を含むことを意図している点にも留意されたい。

例示及び説明の目的で本発明の実施形態についての前述の説明を示してきた。上記説明は、本発明を網羅したり、或いは開示された厳密な形態に限定したりすることを意図するものではなく、上記の教示に照らして修正及び変更を行うか、或いは本発明を実施することによりこれらの修正及び変更を習得することができる。上記実施形態は、本発明の原理及びその実際の適用について説明する目的で選択及び説明され、想定される特定の用途に適合する様々な実施形態において、及び様々な修正を伴って、当業者が本発明を利用できるようにするものである。
〔別紙Ａ〕
セッション開始プロトコル（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ、ＳＩＰ）における複数資源に対する参照
ｄｒａｆｔ−ｉｅｔｆ−ｓｉｐｐｉｎｇ−ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ−０４．ｔｘｔ
本メモの位置づけ
各起案者は、本インターネットドラフトを提出することにより、ＢＣＰ７９のセクション６により当事者が承知している任意の適用可能な特許又は他のＩＰＲによる特許請求の範囲が既に開示されているか、或いは開示されるであろう旨、及び当事者が承知することになるこれらのいずれかが開示されるであろう旨を示すものである。
インターネットドラフトは、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）、ＩＥＴＦの領域、及びＩＥＴＦのワーキンググループによる作業文書である。他のグループからも、作業文書がインターネットドラフトとして配布される可能性がある点に注意のこと。
インターネットドラフトは、最長６ヶ月間有効の草案文書であり、任意の時点で、他の文書により更新、差し替え、又は廃版とされる場合がある。インターネットドラフトを「作業過程の文書」以外として参考資料として使用したり、或いは引用したりすることは適当ではない。
現在公開されているインターネットドラフトの一覧は、下記でアクセスすることができる。
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｅｔｆ／ｌｉｄ−ａｂｓｔｒａｃｔｓ．ｔｘｔ
インターネットドラフトシャドウディレクトリの一覧は、下記でアクセスすることができる。
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｓｈａｄｏｗ．ｈｔｍｌ
このインターネットドラフトの有効期限は、２００６年４月２４日である。
著作権表示
Ｃｏｐｙｒｉｇｈｔ（Ｃ）ＴｈｅＩｎｔｅｒｎｅｔＳｏｃｉｅｔｙ（２００５）
概要
本書は、ＳＩＰＲＥＦＥＲメソッドへの拡張機能を定義することにより、このメソッドを用いてサーバに複数の資源を参照させることができるようにするものである。これらの拡張機能は、Ｒｅｆｅｒ−ｔｏヘッダフィールド内の統一資源識別子（ＵＲＩ）リストへのポインタ及び「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」オプションタグの使用を含む。
１．はじめに
ＳＩＰ［３］ＲＥＦＥＲメソッド［５］により、ユーザエージェントは、第３者への要求の送信をサーバに求めることができるようになる。それでもなお、多くの用途において、サーバに対して宛先の組へ向けてトランザクションを開始するように求める必要がある。１つの例では、会議の議長が、会議サーバに対して参加者グループへＢＹＥ要求を送信するように望む場合がある。別の例では、同じ議長が、会議サーバに対して新規参加者の組をＩＮＶＩＴＥ（招待）するように望む場合がある。
本書は、ＲＥＦＥＲへの拡張機能を定義することにより、ＲＥＦＥＲを用いてサーバに複数の宛先を参照させることができるようにするものである。また、ＲＥＦＥＲの暗黙的加入を抑制する［７］で定義されるＲＥＦＥＲ拡張を使用する。
２．用語
本書において、「ＭＵＳＴ（しなければならない）」、「ＭＵＳＴＮＯＴ（してはならない)」、「ＲＥＱＵＩＲＥＤ（する必要がある）」、「ＳＨＡＬＬ（すべきである）」、［ＳＨＡＬＬＮＯＴ（すべきでない）」、「ＳＨＯＵＬＤ（すべきである）」、「ＳＨＯＵＬＤＮＯＴ（すべきでない）」、「ＲＥＣＯＭＭＥＮＤＥＤ（推奨される）」、「ＮＯＴＲＥＣＯＭＭＥＮＤＥＤ（推奨されない）」、「ＭＡＹ（してもよい)」、及び「ＯＰＴＩＯＮＡＬ（任意である）」というキーワードは、ＲＦＣ２１１９［１］のＢＣＰ１４で説明されるように解釈すべきであり、柔軟な実施構成に対する要求レベルを示すものである。
ここでは、以下の３つの新しい用語を定義する。
ＲＥＦＥＲ−Ｉｓｓｕｅｒ（ＲＥＦＥＲ発行者）：ＲＥＦＥＲ要求を発行するユーザエージェント
ＲＥＦＥＲ−Ｒｅｃｉｐｉｅｎｔ（ＲＥＦＥＲ受信者）：ＲＥＦＥＲ要求を受信するユーザエージェント
ＲＥＦＥＲ−Ｔａｒｇｅｔ（ＲＥＦＥＲターゲット）：ＲＥＦＥＲ−Ｒｅｃｉｐｉｅｎｔにより作成される要求の対象となる最終受信者
３．動作の概要
本書は、ＳＩＰユーザエージェントクライアント（ＵＡＣ）がＲＥＦＥＲ要求にＲＥＦＥＲ−Ｔａｒｇｅｔリストを含め、これをサーバへ送信できるようにするＳＩＰＲＥＦＥＲメソッド［５］に対する拡張機能を定義するものである。サーバは、ＲＥＦＥＲ−ＴａｒｇｅｔＵＲＩリスト内の個々のエントリに対して新規の要求を作成することになる。
ここでは、ＵＲＩリストを使用して、ＲＥＦＥＲの複数のＲＥＦＥＲ−Ｔａｒｇｅｔを表す。サーバに宛先の組を参照させたいＵＡＣ（ユーザエージェントクライアント）が、ＳＩＰＲＥＦＥＲ要求を作成する。Ｒｅｆｅｒ−Ｔｏヘッダは、本文部分に含まれているＵＲＩリストへのポインタを含み、またＲｅｑｕｉｒｅｄヘッダフィールド内にオプションタグ「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」を含む。このオプションタグは、本仕様で説明する機能をサポートするための要件を表すものである。
サーバは、このような要求を受信すると、宛先ごとに新規の要求を作成し、これらを送信する。
本書は、ＵＡＣが、複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲの結果に関する情報を得るためのいかなるメカニズムも提供しない。さらに、ＳＩＰＲＥＦＥＲメソッドの一部である暗黙的加入メカニズムへのサポートを提供するものでもない。ＵＡＣがＲＥＦＥＲの結果について通知を受け続ける方法として、サービス明細がある。例えば、ＲＥＦＥＲを送信して参加者の組を会議にＩＮＶＩＴＥ（招待）するＵＡＣは、会議状態イベント［９］に加入することにより、どの参加者がうまく会議に参入したかを把握することができる。
４．ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒＳＩＰオプションタグ
ここでは、Ｒｅｑｕｉｒｅ及びＳｕｐｐｏｒｔｅｄヘッダフィールドのための新規のＳＩＰオプションタグ「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」を定義する。
Ｓｕｐｐｏｒｔｅｄヘッダ内に「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」オプションタグを含めるユーザエージェントは、本仕様の順守を示している。
Ｒｅｆｅｒ−Ｔｏヘッダフィールド内のＵＲＩリストへのポインタを有するＲＥＦＥＲを作成するユーザエージェントは、ＲＥＦＥＲのＲｅｑｕｉｒｅヘッダフィールド内に「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」オプションタグを含め「なければならない」。
５．ＲＥＦＥＲの暗黙的加入の抑制
単一のＲｅｆｅｒ−ｔａｒｇｅｔを有するＲＥＦＥＲ要求により、参照イベントへの加入が暗黙的に確立される。Ｒｅｆｅｒ−Ｉｓｓｕｅｒは、この暗黙的加入を通じて、ＲＥＦＥＲ−Ｔａｒｇｅｔに対するトランザクションの結果について通知を受ける。ＲＦＣ３５１５［５］で説明されるように、ＲＥＦＥＲ要求によって作成された暗黙的加入の結果として送信されるＮＯＴＩＦＹ要求は、ＲＥＦＥＲ−Ｒｅｃｉｐｉｅｎｔによって開始されたトランザクションのステータスについて記述する「ｍｅｓｓａｇｅ／ｓｉｐｆｒａｇ」［４］タイプの本文を含む。
複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲを作成するＲｅｆｅｒ−Ｉｓｓｕｅｒの場合、Ｒｅｆｅｒ−Ｉｓｓｕｅｒは、通常、ＲＥＦＥＲ−Ｔａｒｇｅｔへ向けてトランザクションの結果に関する情報を提供することができる他のイベントパッケージに既に加入している。例えば、会議サーバに対して、参加者の組にＢＹＥ要求を送信するように指示する議長は、通常、この会議の会議状態イベントパッケージに加入している。このイベントパッケージへの通知により、議長及び他の契約者に現在の会議参加者リストが通知され続けることになる。
複数のＲＥＦＥＲを使用する用途のほとんどは、自己の暗黙的加入を必要としない。結果として、複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲ要求を作成するＳＩＰＲｅｆｅｒ−Ｉｓｓｕｅｒは、Ｒｅｑｕｉｒｅヘッダフィールド内に「ｎｏｒｅｆｅｒｓｕｂ」オプションタグを含めて、要求についての通知をＲｅｆｅｒ−Ｉｓｓｕｅｒに送信すべきでない旨を示す「べきである」。「ｎｏｒｅｆｅｒｓｕｂ」ＳＩＰオプションタグについては［７］で定義されており、これはＲＥＦＥＲの暗黙的加入を抑制するものである。
執筆時点においては、ＲＥＦＥＲの暗黙的加入を通じて複数のトランザクションのステータス報告を可能にする拡張機能は存在しない。これが、本書が「ｎｏｒｅｆｅｒｓｕｂ」オプションタグの使用を推奨する目的である。将来的にこのような拡張機能が定義されれば、この拡張機能を使用するＲｅｆｅｒ−Ｉｓｓｕｅｒは、「ｎｏｒｅｆｅｒｓｕｂ」オプションタグの使用を控えて、代わりに新規の拡張機能を使用することができるようになる。
６．ＳＩＰ−ＲＥＦＥＲＩｓｓｕｅｒの振る舞い
セクション４及びセクション５で示したように、複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲ要求を作成するＳＩＰＲＥＦＥＲ−Ｉｓｓｕｅｒは、Ｒｅｑｕｉｒｅヘッダフィールド内に「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」及び「ｎｏｒｅｆｅｒｓｕｂ」オプションタグを含める。
複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲ要求のＲｅｆｅｒ−Ｔｏヘッダフィールドは、ＵＲＩリストを含む本文部分を指すポインタ（すなわち、コンテンツＩＤの統一資源位置指定子（ＵＲＬ）［２］）を含ま「なければならない」。ＲＥＦＥＲ−Ｉｓｓｕｅｒは、ＵＲＩリスト内に、いかなる特定のＵＲＩも２回以上含める「べきではない」。
７．ＲＥＦＥＲ−Ｒｅｃｉｐｉｅｎｔの振る舞い
ＲＥＦＥＲＲｅｃｉｐｉｅｎｔは、ＲＦＣ３５１５［５］のセクション２．４．２の規則に従って、ＲＥＦＥＲへの応答のステータスコードを決定する。
ＵＲＩリストがＵＲＩを２回以上含んでいる場合、ＲＥＦＥＲＲｅｃｉｐｉｅｎｔは、そのＵＲＩがＵＲＩリスト内に１回しか現れていないかのように振る舞わ「なければならない」。ＲＥＦＥＲＲｅｃｉｐｉｅｎｔは、ＵＲＩリスト内のＵＲＩの各々のＵＲＩ設計に固有の比較規則を用いて、２回以上現れるＵＲＩが存在するか否かを判断する。
ＲＥＦＥＲＲｅｃｉｐｉｅｎｔは、ＲＦＣ３５１５［５］の規則に従ってＲＥＦＥＲ−Ｔａｒｇｅｔへ向けて必要な要求を作成し、ＵＲＩリスト内の個々のＵＲＩごとに標準（ＵＲＩリストでない）ＲＥＦＥＲを受信したかのように振る舞う。
８．デフォルトＵＲＩリストフォーマット
複数のＲＥＦＥＲ要求で使用されるＵＲＩリスト本文のデフォルトフォーマットは、［６］に規定されるリソースリスト文書である。複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲを作成又は受信することができるユーザエージェントは、［６］に規定されるようにこのフォーマットをサポートし「なければならず」、及び他のフォーマットをサポートし「てもよい」。
これにもかかわらず、拡張可能マークアップ言語（ＸＭＬ）構成アクセスプロトコル（ＸＣＡＰ）リソースリスト文書は、階層型リスト及びＸＣＡＰルートＵＲＩへの相対的参照によりエントリを含める能力などの、本書で定義する複数ＲＥＦＥＲサービスには必要とされない機能を提供する。従って、デフォルトのリソースリスト文書の使用時には、複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲを作成するＳＩＰＲＥＦＥＲ−Ｉｓｓｕｅｒは、フラットリスト（すなわち、階層型リストではない）を使用す「べきであり」、＜ｅｎｔｒｙ−ｒｅｆ＞要素を使用す「べきでない」。
ここまで説明してきたよりも多くの情報を有するＵＲＩリストを受信するＲＥＦＥＲＲｅｃｉｐｉｅｎｔは、余計な情報を全て破棄「してもよい」。
図１は、リソースリスト文書に従うフラットリストの例を示す図である。

９．実施例
図２は、ＲＥＦＥＲ−Ｉｓｓｕｅｒが、ＲＥＦＥＲＲｅｃｉｐｉｅｎｔの役を努める会議の焦点へｍｕｌｔｉｐｌｅ−ＲＥＦＥＲ要求を送信する場合のフロー例を示している。ＲＥＦＥＲＲｅｃｉｐｉｅｎｔは、ＲＥＦＥＲ−ＴａｒｇｅｔごとにＢＹＥ要求を作成する。（ＲＥＦＥＲを用いて会議から参加者を除外する方法については［１０］に規定する。）

ＲＥＦＥＲ要求（１）に含まれるＲｅｆｅｒ−Ｔｏヘッダフィールドは、ＲＥＦＥＲ−ＴａｒｇｅｔのＵＲＩを有するリストを含むメッセージ本文へのポインタを含む。ＲＥＦＥＲのＲｅｑｕｉｒｅヘッダフィールドは、「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」及び「ｎｏｒｅｆｅｒｓｕｂ」の両方のオプションタグを含む。図３は、このＲＥＦＥＲ要求の実施例を示す図である。リソースリスト文書は、ＲＥＦＥＲＲｅｃｉｐｉｅｎｔが作成するＳＩＰ要求の方法と共に、ＲＥＦＥＲ−ＴａｒｇｅｔＵＲＩのリストも含む。

図４は、ＲＥＦＥＲＲｅｃｉｐｉｅｎｔが第１のＲＥＦＥＲ−Ｔａｒｇｅｔへ送信するＢＹＥ要求（３）の実施例を示す。

１０．セキュリティ考察
ＳＩＰＵＲＩリストサービスのフレームワーク及びセキュリティ考察［８］では、ＳＩＰＵＲＩリストサービスに関する問題について検討がなされる。複数のＲＥＦＥＲ−Ｔａｒｇｅｔを有するＲＥＦＥＲを受け入れるサーバがＵＲＩリストサービスとして動作する場合、この種のサーバの実装は、［８］のセキュリティ関連規則に従わ「なければならない」。これらの規則は、必須であるクライアントの認証及び許可、並びにｏｐｔ−ｉｎリストを含む。
さらに、サーバは、サーバが理解する用途（例えば会議用途）という状況でのみＲＥＦＥＲ要求を受け入れる「べきである」。これはつまり、サーバは、自身が理解しない方法に関してＲＥＦＥＲを受け入れ「てはならない」ことを示唆する。これらの２つの規則の背後にある考えとして、サーバが、自身が理解しない無作為のメッセージを送出することが唯一の機能であるデータ処理能力の無いサーバとして使用されないようにするということが挙げられる。
１１．ＩＡＮＡの考慮事項
本書は、新規のＳＩＰオプションタグ「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」を定義するものである。このオプションタグは、ＳＩＰパラメータレジストリに登録されるべきである。
「ｍｕｌｔｉｐｌｅ−ｒｅｆｅｒ」オプションタグをＳｕｐｐｏｒｔｅｄヘッダフィールド内に配置するＳＩＰユーザエージェントは、複数のＲＥＦＥＲ−Ｔａｒｇｅｔについて記述するリソースリスト文書を含むＲＥＦＥＲ要求について理解する。

〔別紙Ｂ〕
セッション開始プロトコル（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ、ＳＩＰ）によるファイル転送を可能にするためのメカニズム
ｄｒａｆｔ−ｇａｒｃｉａ−ｓｉｐｐｉｎｇ−ｆｉｌｅ−ｔｒａｎｓｆｅｒ−ｍｅｃｈ−００．ｔｘｔ
本メモの位置づけ
各起案者は、本インターネットドラフトを提出することにより、ＢＣＰ７９のセクション６により当事者が承知している任意の適用可能な特許又は他のＩＰＲによる特許請求の範囲が既に開示されているか、或いは開示されるであろう旨、及び当事者が承知することになるこれらの特許が開示されるであろう旨を示すものである。
インターネットドラフトは、ＩｎｔｅｒｎｅｔＥｎｇｉｎｅｅｒｉｎｇＴａｓｋＦｏｒｃｅ（ＩＥＴＦ）、ＩＥＴＦの領域、及びＩＥＴＦの下にあるワーキンググループの作業文書である。他のグループからも、作業文書がインターネットドラフトとして配布される可能性がある点に注意のこと。
インターネットドラフトは、最長６ヶ月間有効の草案文書であり、任意の時点で、他の文書により更新、差し替え、又は廃版とされる場合がある。インターネットドラフトを「作業過程の文書」以外として参考資料として使用したり、或いは引用したりすることは適当ではない。
現在公開されているインターネットドラフトの一覧は、下記でアクセスすることができる。
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｅｔｆ／ｌｉｄ−ａｂｓｔｒａｃｔｓ．ｔｘｔ
インターネットドラフトシャドウディレクトリ一覧は、下記でアクセスすることができる。
ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｓｈａｄｏｗ．ｈｔｍｌ
このインターネットドラフトの有効期限は、２００６年８月２７日である。
著作権表示
Ｃｏｐｙｒｉｇｈｔ（Ｃ）ＴｈｅＩｎｔｅｒｎｅｔＳｏｃｉｅｔｙ（２００６）
概要
本書は、２つのユーザエージェント（ＵｓｅｒＡｇｅｎｔｓ、ＵＡ）間で１又はそれ以上のファイルの転送を可能にするメカニズムを提供するものである。ＳＩＰ及びセッション記述プロトコル（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ、ＳＤＰ）のオファー／アンサーモデルを使用して、セッションの確立を通知する。メッセージセッションリレープロトコル（ＭｅｓｓａｇｅＳｅｓｓｉｏｎＲｅｌａｙＰｒｏｔｏｃｏｌ、ＭＳＲＰ）を使用して、実際に２つのエンドポイント間でファイルを転送する。
１．はじめに
セッション開始プロトコル（ＳｅｓｓｉｏｎＩｎｉｔｉａｔｉｏｎＰｒｏｔｏｃｏｌ、ＳＩＰ）［５］は、ユーザ間でマルチメディアセッションを開設し、管理するための一般的な機能を提供する。これらのセッションは、音声及び映像などのリアルタイムメディアストリームを含むことが多いが、これらに限定されるものではない。セッション記述プロトコル（ＳｅｓｓｉｏｎＤｅｓｃｒｉｐｔｉｏｎＰｒｏｔｏｃｏｌ、ＳＤＰ）［９］のオファー／アンサーの交換［６］内に、メディア要素タイプのネゴシエーション方法についての仕様が存在する限り、基本的にあらゆるメディア要素タイプをサポートすることができる。
メッセージセッションリレープロトコル（ＭＳＲＰ）［１０］とは、セッションとの関連においてインスタントメッセージ（ＩＭ）を送信するためのプロトコルのことである。このプロトコル仕様は、ＭＳＲＰをＳＩＰ及びＳＤＰと共に使用する方法についての記述を含む。プレーンテキストメッセージに加え、ＭＳＲＰは、画像又はビデオクリップなどの任意の（バイナリの）多目的インターネットメール拡張（ＭＩＭＥ）［２］準拠のコンテンツを搬送することもできる。
ＳＩＰベースのマルチメディアセッションに関与するユーザがそのセッションとの関連においてファイルを交換したいと思うケースは数多くある。ＭＳＲＰを使用すれば、インスタントメッセージのストリーム内部にＭＩＭＥオブジェクトとしてファイルを埋め込むことが可能となる。ＭＳＲＰはまた、ファイル転送に役立つ他の機能も有する。メッセージのチャンキングにより、ＩＭをブロックすることなく大容量ファイルの転送と双方向ＩＭの交換との間で同じトランスポート接続の共有が可能になる。ＭＳＲＰリレー［１４］は、ネットワークアドレス変換器（ＮＡＴ）トラバーサルのためのメカニズムを提供する。最後に、セキュアＭＩＭＥ（Ｓ／ＭＩＭＥ）［７］を使用して、ピア間の転送の保全性及び機密性を保証することができる。
しかしながら、基本のＭＳＲＰは、ＳＩＰベースのセッション内においてファイル転送サービスに関して［１３］に記載される全ての条件を容易に満たすわけではない。欠けている３つの主な機能は以下の通りである。
受信者は、「ファイル転送」を「ＩＭに添付されたファイル」と区別し「なければならず」、これにより受信者はこれらのケースを別様に扱うことができるようになる。
送信者がファイル転送要求を送信することが可能で「なければならない」。受信者がこれを受け入れるか又は拒否することが可能で「なければならない」。実際の転送は、受信者による受け入れ後にのみ発生し「なければならない」。
送信者が実際の転送前にファイルに関する何らかのメタ情報を渡すことが可能で「なければならない」。これには、少なくともコンテンツタイプ及びサイズ、並びに短い（人間に解読可能な）記述が含まれ「なければならない」。
これらの全ての条件は、セッションの記述及びネゴシエーションに関連するものであり、実際のファイル転送メカニズムには関連しない。従って、ＭＳＲＰ自体は拡張を必要とせずにそのまま使用できるが、上記の条件を満たすには、ＳＤＰに対する属性の拡張及び使用規則を定義すればよいというのは当然のことである。さらに、ＳＤＰ拡張はサポートせずに、基本ＭＳＲＰが要求する内容の実現だけを行うエンドポイントは、機能性はいくらか低下するものの、ファイル転送セッションにおいて被発呼側としての機能を果たすことができるような方法で全てのＳＤＰ拡張を規定することができる。
本書は、ＳＩＰセッション内で転送プロトコルとしてＭＳＲＰを使用するセッション内のファイル転送サービスに関する要件を満たすのに必要なＳＤＰ属性拡張及び使用規則を定義するものである。
原則的に、本書で定義するＳＤＰ拡張を使用して、ＭＩＭＥオブジェクトを搬送することができる他の任意の同様のプロトコルにＭＳＲＰを置き換えることも可能である。必要性が生じた場合、この種の仕様を別文書として記述することができる。
本書で説明するメカニズムにより、遠隔のユーザエージェントとのファイルの送受信いずれかが可能となる。
セクション３では、本書で使用するいくつかの用語を定義する。セクション４では、動作の概要について説明する。新規のＳＤＰ属性の詳細な構文及び意味、並びに既存の属性の使用法に関する規則についてはセクション５で定義する。セクション６では、ＳＩＰ、ＳＤＰ、及びＭＳＲＰに関するプロトコル動作について説明する。セクション７にはいくつかの実施例を示す。
２．用語
本書において、「ＭＵＳＴ（しなければならない）」、「ＭＵＳＴＮＯＴ（してはならない)」、「ＲＥＱＵＩＲＥＤ（する必要がある）」、「ＳＨＡＬＬ（すべきである）」、［ＳＨＡＬＬＮＯＴ（すべきでない）」、「ＳＨＯＵＬＤ（すべきである）」、「ＳＨＯＵＬＤＮＯＴ（すべきでない）」、「ＲＥＣＯＭＭＥＮＤＥＤ（推奨される）」、「ＮＯＴＲＥＣＯＭＭＥＮＤＥＤ（推奨されない）」、「ＭＡＹ（してもよい)」、及び「ＯＰＴＩＯＮＡＬ（任意である）」というキーワードは、ＲＦＣ２１１９［１］のＢＣＰ１４で説明されるように解釈すべきであり、柔軟な実施構成に対する要求レベルを示すものである。
３．定義
本書の目的のために、ＲＦＣ３２６４［６］で規定される以下の定義が当てはまる。
Ａｎｓｗｅｒｅｒ（応答者）
Ｏｆｆｅｒｅｒ（提供者）
さらに、以下の用語を定義する。
Ｆｉｌｅｓｅｎｄｅｒ（ファイル送信者）：ファイル受信者にファイルを送信したいエンドポイント。
Ｆｉｌｅｒｅｃｅｉｖｅｒ（ファイル受信者）：ファイル送信者からファイルを受信したいエンドポイント。
Ｆｉｌｅｓｅｌｅｃｔｏｒ（ファイルセレクタ）：結果として０又はそれ以上のファイルを選択する複数のＳＤＰ属性の共通部分。これについてはセクション６．１でさらに詳細に説明する。
４．動作の概要
本書で規定するファイル転送サービスは、ＳＤＰオファー／アンサー［６］を使用して、ファイルを転送するＭＳＲＰベースのメディアストリームを確立する。各「ｍ＝」行は、単一ファイルの転送に用いられるＭＳＲＰベースのメディアストリームを表す。すなわち、複数ファイルの転送には、複数の「ｍ＝」行が必要となる。
本書は、ユーザエージェントが遠隔のユーザエージェントと送受信するファイルについて記述できるようにするＳＤＰ属性及びいくつかの規則の組を定義する。このように、ユーザエージェントは、ファイル名、サイズ、記述、ハッシュ、アイコン（例えばファイルが写真の場合）等に基づいて所定のファイル転送を受け入れるか否かを決定することができる。
事実上、このメカニズムの目的は、ＳＩＰにおけるコンテンツ間接メカニズム［１５］の目的と類似したものである。どちらのメカニズムも、ユーザエージェントがファイルに関する情報に基づいてそのファイルをダウンロードするか否かを決定できるようにするものである。しかしながら、ＳＩＰＭＥＳＳＡＧＥ［１２］要求においてコンテンツ間接メカニズムを使用してファイルを転送する（実際のファイル転送メカニズムは、ハイパーテキスト転送プロトコル（ＨＴＴＰ）［１１］になる）ことはできるが、ファイル転送プロトコルがＭＳＲＰ［１０］である場合、オファー／アンサー交換によって確立されるセッション内でコンテンツ間接メカニズムを使用することはできない。
５．ＳＤＰへの拡張
本書では、ＭＳＲＰを用いたファイルの転送について記述するのに必要な情報を提供するＳＤＰ［９］内の多数の属性を定義する。以下は、これらの新規の属性の正式なＡＢＮＦ構文［８］である。これは、ＳＤＰ［９］文法、ＲＦＣ２０４５［２］、及びＲＦＣ２３９３［３］よりも上に構築される。

「ｆｉｌｅｎａｍｅ」属性はコンテンツのファイル名を含み、この値は（ＳＤＰ［９］に定義される）バイト文字列である。
「ｆｉｌｅｔｙｐｅ」属性はコンテンツのＭＩＭＥメディアタイプを含む。一般に、Ｃｏｎｔｅｎｔ−Ｔｙｐｅヘッダフィールド（ＲＦＣ２０４５［２１]を参照）内で表すことができるあらゆるものを、「ｆｉｌｅｔｙｐｅ」属性でも表すことができる。使用できるＭＩＭＥＭｅｄｉａＴｙｐｅ値は、ＭＩＭＥＭｅｄｉａＴｙｐｅに関してＩＡＮＡレジストリにリストされたものとなる。これに０又はそれ以上のパラメータを続けることができる。「パラメータ」の構文については、ＲＦＣ２０４５［２］に規定されている。
「ｄｉｓｐｏｓｉｔｉｏｎ」属性は、ピアに対して目的とするファイルの配置についての提案を行う。使用できる値は、ＭａｉｌＣｏｎｔｅｎｔＤｉｓｐｏｓｉｔｉｏｎＶａｌｕｅｓに関してＩＡＮＡレジストリにリストされたものであるが、ファイル転送アプリケーションに関しては、「ｉｎｌｉｎｅ（インライン）」及び「ａｔｔａｃｈｍｅｎｔ（添付）」値のみが重要である可能性が高い。
「ｆｉｌｅｓｉｚｅ」属性は、ファイルサイズをオクテット単位で示す。
「ｉｃｏｎ」属性は、画像などの特定のファイルタイプに役立つことができる。この属性により、送信者は、転送されるファイルのコンテンツを表すアイコンを含むポインタを本文に含めることができるようになる。これにより、送信者は、ＳＤＰに付随する別の本文としてアイコンを含めることができ、受信者は、潜在的に転送可能なファイルのアイコンを取得できるようになる。アイコンは、意味を成す最小数のバイトに制限することを推奨する。「ｉｃｏｎ」属性は、ＲＦＣ２３９２［３］に規定されるコンテンツ−ＩＤのＵＲＬを含む。
「ｈａｓｈ」属性は、転送されるファイルのハッシュを提供する。目的には二面性がある。１つの面は、ファイル受信者が何らかの帯域外のメカニズムによりファイルのハッシュを認識していた場合、ファイル受信者がファイル名ではなくハッシュによってファイルを識別できるようにすることである。もう１つの面は、ファイル送信者が、送信するファイルのハッシュを提供できるようにすることであり、ファイル受信者は、このハッシュを使用してコンテンツの検証を行うか、或いは既に存在するファイルの不要な送信を防ぐことができるようになる。「ｈａｓｈ」属性は、ハッシュのタイプ及びその値を含む。使用できるハッシュのタイプは、ＩＰＳｅｃレジストリのＩＡＮＡレジストリのＨａｓｈＡｌｇｏｒｉｓｍセクションに定義されたものである。本仕様に従う実施構成は、米国のＳｅｃｕｒｅＨａｓｈＡｌｇｏｒｉｔｈｍ１（ＳＨＡ１）［４］を実装し「なければならず」、また他のハッシュアルゴリズムを実装し「てもよい」。ＳＤＰの創作者はまた、同じファイルに２以上の「ｈａｓｈ」属性（恐らくは異なるタイプのハッシュ）を追加し「てもよい」。値は、ファイルのコンテンツにハッシュアルゴリズムを適用した結果得られるバイト文字列である。
以下は、本メモで定義する拡張を含むＳＤＰ本文の例である。

６．プロトコルの動作
本セクションは、セクション５で定義したパラメータをオファー／アンサー［６］交換との関連において使用する方法について論じる。さらに、本セクションはまた、ＭＳＲＰを使用するエンドポイントの動作についても論じる。
通常、ファイル転送セッションは、提供者がＳＤＰオファーを応答者へ送信するときに開始される。応答者は、ファイル転送セッションを受け入れるか又は拒否し、ＳＤＰアンサーを提供者へ送信する。
提供者がファイル送信者であるか、又はファイル受信者であるかに応じて、２つの使用ケースに区別することができる。
１．提供者がファイル送信者であり、すなわち、提供者が応答者にファイルを転送したい場合。応答者はファイル受信者である。この場合のＳＤＰオファーは「ｓｅｎｄｏｎｌｙ」属性を含み、従って、ＳＤＰアンサーは「ｒｅｃｖｏｎｌｙ」属性を含む。
２．提供者がファイル受信者であり、すなわち、提供者が応答者からファイルをフェッチしたい場合。応答者はファイル送信者である。この場合のＳＤＰオファーは「ｒｅｃｖｏｎｌｙ」属性を含み、従って、ＳＤＰアンサーは「ｓｅｎｄｏｎｌｙ」属性を含む。
６．１．ファイルセレクタ
本書で規定するプロトコルは、遠隔ホスト内のファイルを識別するためのメカニズムを必要とする。ここでは、「ｈａｓｈ」、「ｆｉｌｅｎａｍｅ」、「ｆｉｌｅｓｉｚｅ」、及び「ｆｉｌｅｔｙｐｅ」属性の共通部分であるファイルセレクタの概念を導入する。
ファイルセレクタは、ＳＤＰ内における上述した属性の有無に応じて、及びホストで利用可能なファイルに応じて、０、１、又はそれ以上のファイルを指し示すことができる。本書で規定するファイル転送メカニズムでは、ファイルセレクタが結果的に１つのファイルを選択する必要がある。通常、「ｈａｓｈ」属性が分かっている場合、０又は１つのファイルを示すファイルセレクタを作成するためには「ｈａｓｈ」属性で十分である。しかしながら、ファイルセレクタは、常に分かっているわけでも利用可能なわけでもない。「ｆｉｌｅｎａｍｅ」、「ｆｉｌｅｓｉｚｅ」、又は「ｆｉｌｅｔｙｐｅ」属性のみが分かった結果、ファイルセレクタが２以上のファイルをもたらす場合があり、これは望ましくないケースである。その逆もまた真であり、ファイルセレクタが「ｈａｓｈ」及び「ｆｉｌｅｎａｍｅ」属性を含んではいるが、遠隔ホスト側のユーザがファイル名を変更しており、指示されたハッシュを有するファイルはあるが、ファイル名が一致しないという結果、ファイルセレクタが０のファイルを選択するということになる。
６．２．提供者の振る舞い
応答者との間で１又はそれ以上のファイルを送受信したい提供者は、各々がＭＳＲＰ［１０］手順に従ってＭＳＲＰセッション（従って、１つのファイル転送動作）について記述する１又はそれ以上の「ｍ＝」行を含むセッションのＳＤＰ［９］記述を構築し「なければならない」。ＭＳＲＰ［１０］により規定され要求される全てのメディア行属性（例えば、「ａ＝ｐａｔｈ」、「ａ＝ａｃｃｅｐｔ−ｔｙｐｅ」、その他）が同様に含まれ「なければならない」。転送される各ファイルごとに、個別の「ｍ＝」行が存在し「なければならない」。
６．２．１．提供者がファイル送信者である場合
提供者がファイル送信者である場合、提供者は、セッション又はメディアの「ｓｅｎｄｏｎｌｙ」属性をＳＤＰオファーに加え「なければならない」。さらに、提供者はまた、ファイルのタイプ、サイズ、及びハッシュをそれぞれ示す「ｆｉｌｅｔｙｐｅ」、「ｆｉｌｅｓｉｚｅ」、及び「ｈａｓｈ」属性も追加す「べきである」。
提供者がＳＤＰオファーを作成するときには、例えば、ホストがまだファイルを処理中であるという理由で、これらの属性が分からない可能性がある。
「ｈａｓｈ」属性は、ファイル受信者にとって、このファイルが既に利用可能であり送信される必要がないものであるか否かを識別するための有益な情報を含む。
提供者はまた、転送されるファイルについてさらに記述する「ｆｉｌｅｎａｍｅ」、「ｉｃｏｎ」、及び「ｄｉｓｐｏｓｉｔｉｏｎ」属性を追加し「てもよい」。「ｄｉｓｐｏｓｉｔｉｏｎ」属性は、表示の提案を行う（例えば、ファイル送信者は、ファイル受信者がファイルを「インライン」で表示するか、或いは「添付」として保存することを望む）。さらに、提供者は、「ｉ＝」メディア行を用いて人間に解読可能なファイルの説明を行っ「てもよい」。
６．２．２．提供者がファイル受信者である場合
提供者がファイル受信者である場合、提供者は、セッション又はメディアの「ｒｅｃｖｏｎｌｙ」属性を含むＳＤＰオファーを作成し「なければならない」。次に、提供者は、ファイルセレクタを構築する属性（「ｈａｓｈ」、「ｆｉｌｅｎａｍｅ」、「ｆｉｌｅｓｉｚｅ」、又は「ｆｉｌｅｔｙｐｅ」）の少なくとも１つを加える「べきである」。多くの場合、ファイルのハッシュが分かれば、ファイルの識別にはハッシュで十分なため、提供者は、「ｈａｓｈ」属性のみを含めることができる。しかしながら、特にファイルのハッシュが分からない場合、ファイル名、サイズ、及びタイプによって、フェッチされるファイルについての記述を行うことができる。
６．２．３．複数ファイルのためのＳＤＰオファー
１よりも多くのファイルを送受信したい提供者は、ファイルごとに「ｍ＝」行を作成する。このように、応答者は、標準ＳＤＰ［９］手順のように、関連する「ｍ＝」行のポート番号を０にセットすることにより、個々のファイルを拒否することができる。
ファイルごとに「ｍ＝」行を使用することは、異なるファイルが異なるＭＳＲＰセッションを使用して転送されることを意味する。しかしながら、［１０］のセクション８．１で説明されるように、これらのＭＳＲＰセッション全てを、単一のＴＣＰ接続を介して実行するように開設することができる。
６．３．応答者の振る舞い
提供者が提供するファイルを応答者が拒否したい場合、標準ＳＤＰ［９］手順のように、ファイルに関連する「ｍ＝」行のポート番号を０にセットする。応答者がファイルの受け入れを決定する場合は、標準ＭＳＲＰ［１０］及びＳＤＰ［９］手順のように進む。
６．３．１．応答者がファイル受信者である場合
応答者がファイル受信者で、ファイル転送の受け入れを決定する場合、「ｒｅｃｖｏｎｌｙ」属性を含むＳＤＰアンサー（ＲＦＣ３２６４［６］による）を作成し「なければならない」。オファーが「ｆｉｌｅｔｙｐｅ」、「ｆｉｌｅｓｉｚｅ」、又は「ｆｉｌｅｎａｍｅ」属性を含む場合、応答者はこれらをアンサー内にコピーし「なければならない」。これにより、応答者が本仕様をサポートしていることが提供者に知らされる。応答者がファイル受信者である場合、応答者は、ＳＤＰアンサーに「ｉｃｏｎ」、「ｈａｓｈ」、「ｄｉｓｐｏｔｉｓｉｏｎ」属性を含め「てはならない」。
受信したオファーが「ｈａｓｈ」属性を含む場合、応答者はこの「ｈａｓｈ」属性を使用して、同じハッシュを有するローカルファイルが既に利用可能であるかを調べることができ、この場合、この行為が、複製されたファイルの受信を暗に意味することになる。複製されたファイルである場合、応答者がファイル転送を受け入れるか否かの判断は応答者次第である。
６．３．２．応答者がファイル送信者である場合
応答者がファイル送信者である場合、応答者は最初に、受信したＳＤＰオファーを調べてファイルセレクタを計算し「なければならない」。ファイルセレクタとは、（以下の４つの属性が存在すれば、）ＳＤＰオファー内の同じ「ｍ＝」行を変更する「ｆｉｌｅｔｙｐｅ」、「ｆｉｌｅｓｉｚｅ」、「ｆｉｌｅｎａｍｅ」、及び「ｈａｓｈ」属性の共通部分の結果のことである（すなわち、上述した４つの属性がＳＤＰ内の同じ「ｍ＝」行の下に配置されていることになる）。ファイルセレクタは、送信する０又はそれ以上のファイルを識別する。ファイルセレクタがファイルを全く識別できない場合、応答者は、ポート番号を０にセットすることにより、ファイル転送に関するＭＳＲＰストリームを拒否し「なければならない」（及びこれがＳＤＰオファー内の唯一のストリームである場合、応答者はＲＦＣ３２６４［６］の手順によりＳＤＰを拒否す「べきである」。）。
ファイルセレクタが単一のファイルを指しており、かつ応答者がファイル転送の受け入れを決定した場合、応答者は、「ｓｅｎｄｏｎｌｙ」属性を含むＳＤＰアンサー（ＲＦＣ３２６４［６］による）を作成し「なければならない」。応答者は、送信されるファイルのハッシュを含む「ｈａｓｈ」属性を追加す「べきであり」、ファイルについてさらに記述するために「ｆｉｌｅｎａｍｅ」、「ｆｉｌｅｔｙｐｅ」、「ｆｉｌｅｓｉｚｅ」、「ｉｃｏｎ」、又は「ｄｉｓｐｏｔｉｓｉｏｎ」属性を含め「てもよい」。
最後に、ファイルセレクタが複数のファイルを指す場合、応答者は、（ポート番号を０にセットすることにより）ファイル転送に関するＭＳＲＰメディアストリームを拒否す「べきである」。
必要性が生じた場合、将来的な仕様として、複数のファイルを選択するか、或いは例えばファイルセレクタと一致するファイルのリストを返すことにより曖昧さを解決できるようになる適当なメカニズムが提供されるようにすることができる。
６．４．ＭＳＲＰの使用法
本書で規定するファイル転送サービスは、「ｍ＝」行を使用してファイルの一方向転送について記述している。結果として、セクション６．２及びセクション６．３の手順に従って確立された個々のＭＳＲＰセッションは、単一ファイルの転送のみに使用される。従って、送信者は、ＳＤＰオファー又はアンサー内に記述されたファイルを送信するためだけに所定のＭＳＲＰセッションを使用し「なけらばならない」。すなわち、送信者は、同じＭＳＲＰセッションにおいて追加のファイルを送信し「てはならない」。
ファイル転送が完了すると、ファイル送信者は、ＭＳＲＰセッションをクローズす「べきであり」、またＭＳＲＰセッションのクローズに関してはＭＳＲＰ［１０］手順に従って振る舞わ「なければならない」。
７．実施例
７．１．ＵＡＣがＵＡＳへファイルを送信する場合
本セクションでは、ファイル転送シナリオのフロー例を示す。実施例は、ＳＩＰを用いてＳＤＰ交換を伝送することを前提とするが、説明を簡潔にするためにＳＩＰの詳細については簡単に示す。
ＳＤＰ提供者であるアリスは、画像ファイルをボブ（応答者）へ送信したい。アリスのＵＡＣは、ボブに送信したいファイルについての記述を含む一方向のＳＤＰオファーを作成する。この記述はまた、転送されるファイルのコンテンツを表すアイコンも含む。順番の流れを図３に示す。

Ｆ１：アリスは、送信されるファイルについてのＳＤＰ記述を構築し、これをボブ宛てのＳＩＰＩＮＶＩＴＥ要求に添付する。

Ｆ２：ボブは、ＩＮＶＩＴＥ要求を受信し、ＳＤＰオファーを調べ、アイコン本体を展開し、ファイルサイズをチェックして、ファイル転送の受け入れを決定する。従って、ボブは以下のＳＤＰアンサーを作成する。

Ｆ４：アリスは、ボブへのＴＣＰ接続を開き、ＭＳＲＰＳＥＮＤ要求を作成する。このＳＥＮＤ要求はファイルの第１の部分を含む。

Ｆ５：ボブは第１の部分の受信を確認応答する。

Ｆ６：アリスは第２及び最終の部分を送信する。

Ｆ５：ボブは第２部分の受信を確認応答する。

Ｆ８：アリスはＳＩＰＢＹＥ要求を送信してＳＩＰセッションを終了する。
Ｆ９：ボブはＢＥＹ要求の受信を確認し２００（ＯＫ）応答を送信する。

７．２．ＵＡＣがＵＡＳからファイルを要求する場合
この実施例では、ＳＤＰ提供者であるアリスが、ＳＤＰ応答者のボブからファイルをフェッチしたい。アリスは、彼女がダウンロードしたい特定のファイルをボブが所有していることを知っている。アリスは、何らかの帯域外のメカニズムによりファイルのハッシュを認識している。特定のファイルを示すファイルセレクタを作成するためには、ハッシュ属性があれば十分である。従って、アリスは、ファイル記述子を含むＳＤＰオファーを作成する。ボブは、送信を受け入れ、ファイルをアリスへ送信する。図１０は順番の流れを示す図である。

Ｆ１：アリスは、自身が受信したいファイルについてのＳＤＰ記述を構築し、ＳＤＰオファーをボブ宛てのＳＩＰＩＮＶＩＴＥ要求に添付する。

以降、説明を簡潔にするためにＳＩＰの詳細は省く。
Ｆ２：ボブは、ＩＮＶＩＴＥ要求を受信し、ＳＤＰオファーを調べ、ファイル記述子を計算し、ハッシュがＳＤＰ内に示されているものと一致するローカルファイルを見つける。ボブは、ファイル送信を受け入れ、以下のようなＳＤＰアンサーを作成する。

Ｆ４：アリスはボブへのＴＣＰ接続を開く。次に、ボブは、ファイルを含むＭＳＲＰＳＥＮＤ要求を作成する。

Ｆ６：アリスはＳＥＮＤ要求の受信を確認応答する。

Ｆ６：ボブは、ＳＩＰＢＹＥ要求を送信することによりＳＩＰセッションを終了する。
Ｆ７：アリスは、ＢＹＥ要求の受信を確認応答し、２００（ＯＫ）応答を送信する。
８．セキュリティについての考察
未定（ＴＢＤ）
９．ＩＡＮＡについての考察
未定（ＴＢＤ）
１０．謝辞
起案者は、本メモに記載した初期概念について検討したことに対し、ＭａｔｓＳｔｉｌｌｅ、ＮａｎｃｙＧｒｅｅｎｅ、ＡｄａｍｕＨａｒｕｎａ、及びＡｒｔｏＬｅｐｐｉｓａａｒｉに感謝を表したい。本書の初版を評価して有益なコメントをいただいたことに対して、ＰｅｋｋａＫｕｕｒｅにも感謝する。

本発明の１つの実施形態によるＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。本発明の別の実施形態による、選択されたメッセージを削除するためのＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。本発明のさらに別の実施形態による、選択されたメッセージを削除するためのＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。本発明の実施形態による、複数の選択されたメッセージを削除するためのＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。本発明の実施形態による、複数の選択されたメッセージを削除するためのＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。本発明の実施形態による、複数の選択されたメッセージを削除するためのＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。本発明の実施形態による、ユーザのメール保存アカウント内の全てのメッセージを削除するためのＳＩＰマルチメディアサービスのための削除メカニズムの動作を示すフロー図である。本発明を実施することができるシステムの概観図である。本発明の実施構成で使用することができる移動電話の斜視図である。図９の移動電話の電話回路の概略図である。

Claims

ＳＩＰマルチメディア環境においてユーザアカウントから項目を削除する方法であって、
前記項目を前記ユーザアカウントから削除するための要求をユーザ装置から受信するステップと、
ネットワークベースの削除項目の場所と前記ユーザアカウントとの間にＳＩＰセッションを確立するステップと、
前記ＳＩＰセッションの確立後、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送するステップと、
前記ユーザアカウントから前記項目を削除するステップと、
を含むことを特徴とする方法。
前記要求はＳＩＰＲＥＦＥＲ要求を含む、
ことを特徴とする請求項１に記載の方法。
前記ＳＩＰＲＥＦＥＲ要求は、そのＲｅｆｅｒ−ｔｏヘッダ内に前記ネットワークベースの削除項目の場所のアドレスを含む、
ことを特徴とする請求項２に記載の方法。
前記要求はＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲ要求を含む、
ことを特徴とする請求項１に記載の方法。
前記要求の受信に応答して前記要求の確認応答を前記ユーザ装置へ送信するステップをさらに含む、
ことを特徴とする請求項１に記載の方法。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＳｅｎｄＯｎｌｙにセットされた状態で確立される、
ことを特徴とする請求項１に記載の方法。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＲｅｃｖＯｎｌｙにセットされた状態で確立される、
ことを特徴とする請求項１に記載の方法。
前記項目は一意のメッセージ識別子を含み、該一意のメッセージ識別子が前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項１に記載の方法。
前記要求は、前記ユーザアカウントから複数の項目を削除するためのものであり、該複数の項目のＵＲＩリストが前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項１に記載の方法。
前記要求は、前記ユーザアカウントから全ての項目を削除するためのものであり、該ユーザアカウントのＳＩＰＵＲＩが前記ユーザアカウントからの前記要求に含まれる、
ことを特徴とする請求項１に記載の方法。
前記項目はＳＤＰ記述を有するファイルとして保存されており、該ファイルのＳＤＰ記述が前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項１に記載の方法。
前記要求は、前記ユーザアカウントから複数の項目を削除するためのものであり、該複数の項目の各々についてのファイルのＳＤＰ記述が前記ユーザ装置からの前記要求に含まれ、個々のファイルについての前記ファイルのＳＤＰ記述が前記要求における個別のメディア行に含まれる、
ことを特徴とする請求項１１に記載の方法。
前記ユーザ装置、前記ユーザのアカウント、及び前記ネットワークベースの削除項目の場所はそれぞれ、一意の統一資源識別子を有する、
ことを特徴とする請求項１に記載の方法。
ＭＳＲＰプロトコルを使用して、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送する、
ことを特徴とする請求項１に記載の方法。
ＳＩＰマルチメディア環境においてユーザアカウントから項目を削除するための、コンピュータ可読媒体において具体化されるコンピュータプログラム製品であって、
前記項目を前記ユーザアカウントから削除するための要求をユーザ装置から受信するためのコンピュータコードと、
ネットワークベースの削除項目の場所と前記ユーザアカウントとの間にＳＩＰセッションを確立するためのコンピュータコードと、
前記ＳＩＰセッションの確立後、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送するためのコンピュータコードと、
前記ユーザアカウントから前記項目を削除するためのコンピュータコードと、
を含むことを特徴とするコンピュータプログラム製品。
前記要求はＳＩＰＲＥＦＥＲ要求を含む、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記ＳＩＰＲＥＦＥＲ要求は、そのＲｅｆｅｒ−ｔｏヘッダ内に前記ネットワークベースの削除項目の場所のアドレスを含む、
ことを特徴とする請求項１６に記載のコンピュータプログラム製品。
前記要求はＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲ要求を含む、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＳｅｎｄＯｎｌｙにセットされた状態で確立される、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＲｅｃｖＯｎｌｙにセットされた状態で確立される、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記項目は一意のメッセージ識別子を含み、該一意のメッセージ識別子が前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記要求は、前記ユーザアカウントから複数の項目を削除するためのものであり、該複数の項目のＵＲＩリストが前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記要求は、前記ユーザアカウントから全ての項目を削除するためのものであり、該ユーザアカウントのＳＩＰＵＲＩが前記ユーザアカウントからの前記要求に含まれる、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記項目はＳＤＰ記述を有するファイルとして保存されており、該ＳＤＰ記述が前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
前記要求は、前記ユーザアカウントから複数の項目を削除するためのものであり、該複数の項目の各々についてのファイルのＳＤＰ記述が前記ユーザ装置からの前記要求に含まれ、各ファイルについての前記ファイルのＳＤＰ記述が前記要求における個別のメディア行に含まれる、
ことを特徴とする請求項２３に記載のコンピュータプログラム製品。
前記ユーザ装置、前記ユーザのアカウント、及び前記ネットワークベースの削除項目の場所はそれぞれ、一意の統一資源識別子を有する、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
ＭＳＲＰプロトコルを使用して、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送する、
ことを特徴とする請求項１５に記載のコンピュータプログラム製品。
電子装置であって、
プロセッサと、
前記プロセッサに通信可能に接続されたメモリユニットと、
を備え、前記メモリユニットは、
項目をユーザアカウントから削除するためのＳＩＰ要求をユーザ装置から受信するためのコンピュータコードと、
ネットワークベースの削除項目の場所と前記ユーザアカウントとの間にＳＩＰセッションを確立するためのコンピュータコードと、
前記ＳＩＰセッションの確立後、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送するためのコンピュータコードと、
前記ユーザアカウントから前記項目を削除するためのコンピュータコードと、
を含む、
ことを特徴とする電子装置。
前記要求はＳＩＰＲＥＦＥＲ要求を含む、
ことを特徴とする請求項２８に記載の電子装置。
前記ＳＩＰＲＥＦＥＲ要求は、そのＲｅｆｅｒ−ｔｏヘッダ内に前記ネットワークベースの削除項目の場所のアドレスを含む、
ことを特徴とする請求項２９に記載の電子装置。
前記要求はＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲ要求を含む、
ことを特徴とする請求項２８に記載の電子装置。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＳｅｎｄＯｎｌｙにセットされた状態で確立される、
ことを特徴とする請求項２８に記載の電子装置。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＲｅｃｖＯｎｌｙにセットされた状態で確立される、
ことを特徴とする請求項２８に記載の電子装置。
前記項目は一意のメッセージ識別子を含み、該一意のメッセージ識別子が前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項２８に記載の電子装置。
前記要求は、前記ユーザアカウントから複数の項目を削除するためのものであり、該複数の項目のＵＲＩリストが前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項２８に記載の電子装置。
前記要求は、前記ユーザアカウントから全ての項目を削除するためのものであり、該ユーザアカウントのＳＩＰＵＲＩが前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項２８に記載の電子装置。
前記項目はＳＤＰ記述を有するファイルとして保存されており、該ファイルのＳＤＰ記述が前記ユーザ装置からの前記要求に含まれる、
ことを特徴とする請求項２８に記載の電子装置。
前記要求は、前記ユーザアカウントから複数の項目を削除するためのものであり、該複数の項目の各々についてのファイルのＳＤＰ記述が前記ユーザ装置からの前記要求に含まれ、個々のファイルについての前記ファイルのＳＤＰ記述が前記要求における個別のメディア行に含まれる、
ことを特徴とする請求項３７に記載の電子装置。
ＭＳＲＰプロトコルを使用して、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送する、
ことを特徴とする請求項２８に記載の電子装置。
ＳＩＰマルチメディア環境においてユーザアカウントから項目を削除する方法であって、
前記項目を前記ユーザアカウントから削除するための要求をユーザ装置から送信するステップと、
前記送信された要求に応答して、仮想ユーザエージェントとネットワークベースの削除項目の場所との間にＳＩＰセッションを確立するステップと、
前記ＳＩＰセッションの確立後、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送するステップと、
前記ユーザアカウントから前記項目を削除するステップと、
を含むことを特徴とする方法。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＳｅｎｄＯｎｌｙにセットされた状態で確立される、
ことを特徴とする請求項４０に記載の方法。
前記ＳＩＰセッションは、ＳＤＰ方向属性がａ＝ＲｅｃｖＯｎｌｙにセットされ状態で確立される、
ことを特徴とする請求項４０に記載の方法。
前記要求は、削除される前記項目の一意の識別子を含むＳＩＰＲＥＦＥＲ要求を含む、
ことを特徴とする請求項４０に記載の方法。
前記要求は、複数の項目を削除するためのものであり、前記要求は、削除される前記項目のＵＲＩリストを含むＳＩＰＭｕｌｔｉｐｌｅ−ＲＥＦＥＲ要求を含む、
ことを特徴とする請求項４０に記載の方法。
前記要求は、全ての項目を削除するためのものであると共に、前記ユーザアカウントのＳＩＰＵＲＩを含むＳＩＰＲＥＦＥＲ要求を含む、
ことを特徴とする請求項４０に記載の方法。
前記項目はＳＤＰ記述を有するファイルとして保存されており、前記要求は前記ＳＤＰ記述を含むＲＥＦＥＲ要求を含む、
ことを特徴とする請求項４０に記載の方法。
前記項目はＳＤＰ記述を有するファイルとして保存されており、前記要求は複数の項目を削除するためのものであり、削除される前記項目についての前記ファイルのＳＤＰ記述が前記ユーザ装置からの前記要求に含まれ、個々のファイルについての前記ファイルのＳＤＰ記述が前記要求における個別のメディア行に含まれる、
ことを特徴とする請求項４０に記載の方法。
前記ＳＩＰＲＥＦＥＲ要求は、そのＲｅｆｅｒ−ｔｏヘッダ内に前記ネットワークベースの削除項目の場所のアドレスを含む、
ことを特徴とする請求項４０に記載の方法。
ＭＳＲＰプロトコルを使用して、前記ユーザアカウントから前記ネットワークベースの削除項目の場所に前記項目を転送する、
ことを特徴とする請求項４０に記載の方法。
ＳＩＰマルチメディア環境においてユーザアカウントから項目を削除する方法であって、
前記項目を前記ユーザアカウントから削除するための、Ｒｅｆｅｒ−ｔｏヘッダ内にネットワークベースの削除項目の場所のアドレスを含むＳＩＰＲＥＦＥＲ要求を送信するステップと、
ＳＩＰＲＥＦＥＲ要求の受信に応答して、前記要求の確認応答を前記ユーザ装置へ送信するステップと、
前記ユーザアカウントから前記項目を削除するステップと、
を含むことを特徴とする方法。