JP4700090B2 - プレゼンスシステム及びプレゼンス管理方法 - Google Patents

Description

本発明は、プレゼンスシステムに関する。プレゼンスシステムでは、プレゼンス所有者(以下、プレゼンティティという)のプレゼンスが更新されると、その内容がプレゼンス通知依頼者(以下、ウォッチャーという)にリアルタイムに通知される。
本発明において、プレゼンスとは、プレゼンティティが持つ任意の情報である。例えば、プレゼンティティの状態を表すテキストメッセージ、アイコンなどの画像データ、音声データ、数値、位置情報、通信アドレスがプレゼンスとして挙げられる。また、プレゼンティティとは、プレゼンスを持ち得るあらゆる対象であり、例えば人や物、企業体、組織、サービスなどが挙げられる。

プレゼンスシステムにおいては、１つのプレゼンティティは複数のプレゼンスを所有可能である。また、プレゼンティティは、ウォッチャーに対し、自分が所有するプレゼンスのうちどのプレゼンスを通知するか制御可能である。プレゼンティティが所有する各プレゼンスの用途は、プレゼンティティが任意に決定可能である。
一般にプレゼンスの更新者はそのプレゼンスの所有者である。しかし、プレゼンスの所有者が他者に更新権限を与え、所有者以外の他者が更新することも提案されている。例えばプレゼンスの所有者Ａが更新者Ｂに更新権限を与えたとする。ところが、プレゼンティティＡが複数のプレゼンスを持つ場合がある。この場合、プレゼンティティは、ユニークなIDを各プレゼンスに割り当てる。更新者Ｂは、更新権限を与えられたプレゼンスのIDを指定することにより、更新対象プレゼンスを指定してその更新を行う。

また、特許文献１には、複数のプレゼンティティのプレゼンスを関連づける技術が記載されている。具体的には、二者のプレゼンティティの一方を転送元、他方を転送先として、予め関連付けておく。転送元のプレゼンスが更新された時、その内容を転送先へ伝搬させ、転送先のプレゼンスも自動的に同じ内容に更新させる。その後、転送先では、転送先プレゼンティティへのウォッチャーに対して、更新通知が行われる。

一方、近年RFID/ICカードが注目されている。このカードがカードリーダ付のゲートを通るだけでカードに書き込まれたデータを自動的に検知可能である為、物流等様々な分野への応用が期待されている。プレゼンスシステムに、このRFID/ICカード技術を適用すると、以下のようなことが可能となる。例えば、ICカードを持ったユーザが会議室Ａに入る時に入口のカードリーダにICカードをかざすと、自動的にそのユーザの居場所を表すプレゼンスが「会議室Ａ」に変更される。具体的には、ICカードにカード所有者のユーザＩＤを記録しておき、カードリーダがその情報を読み込み、カード所有者のプレゼンス情報を更新すればよい。
特開2003-296525号公報

複数のプレゼンスを所有するプレゼンティティは、自分が所有するプレゼンス全体の構造を他人に開示したくないと思うのが一般的である。一方で、複数のプレゼンスを所有するプレゼンティティは、１つ１つのプレゼンスを自分で更新するのは煩わしいと感じている。従って、このようなプレゼンティティは、自分のプレゼンス全体の構造を開示することなく、自動的に自分のプレゼンスを更新したい。

一方、プレゼンティティのプレゼンスを更新する更新者は、プレゼンティティのプレゼンスを更新するために、そのプレゼンティティが所有するプレゼンスの構造を調べなければならない。例えば、更新者が更新することを許されているプレゼンスのＩＤと、プレゼンスとして設定できる内容の選択肢と、を更新者はプレゼンティティから教えてもらっておかなければならない。更新対象のプレゼンスが別のプレゼンティティのプレゼンスに依存する場合には、さらにそのプレゼンスを更新者は取得しておく必要もある。

更新者がRFIDカードやRFIDタグ、ＩＣカードを読みとるカードリーダの場合、プレゼンティティが所有する複数のプレゼンスのうちどれを更新するのか、カードリーダが指定することは現実的ではない。なぜなら、カードリーダが読みとるカードの所有者は不特定多数となるため、各所有者がカードリーダに対して開放しているプレゼンスをカードリーダが判断することが難しいからである。もちろん、カードリーダが更新することができるプレゼンスのＩＤを固定的に決めておくこともできる。しかし、プレゼンスの所有者のプライバシーを侵害することにつながるので、あまり好ましくない。

つまり、プレゼンティティからすれば、複数のプレゼンスを手間をかけずに簡単に更新したいというニーズがある。一方、更新者からすれば、プレゼンティティのプライバシーに配慮して更新するのは手間である。その一方で、更新者が自由にプレゼンティティのプレゼンスを更新するのは、プレゼンティティのプライバシーを侵害する問題がある。
さらに、前記特許文献１は、プレゼンティティが複数のプレゼンスを所有する場合を考慮していない。そのため、プレゼンティティが複数のプレゼンスを所有する場合、転送元から転送先にどのプレゼンスを転送するのかを決定することができない。また、転送先のどのプレゼンスを更新するのかを決定する手段もない。しかも、転送元から転送先に転送されたプレゼンスは、転送先のものとなる。そのため、転送元が意図しないウォッチャーに対し、元々転送元が所有していたプレゼンスが公開されてしまう問題がある。

また、複数のプレゼンスを有するユーザ（サブスクライビー）に対して、別のユーザ（サブスクライバー）がプレゼンスの参照を要求する（サブスクライブ）際にも、以下の問題がある。なかでも、サブスクライバーがサブスクライビーのプレゼンス構造を知らなければサブスクライブ要求できないとなると、サブスクライバーの負担が増大する。例えば、サブスクライビーに対応づけられているプレゼンスのうちどのプレゼンスがサブスクライバーにとって知りたい情報なのかを、サブスクライバーは予め調べなければならなくなる。またプレゼンスの公開条件が設定されている場合、どのプレゼンスが公開されるのかを調べ、そのうちのどれかを選択するのは、サブスクライバー側の負担となる。その一方、サブスクライビーが、自分のプレゼンスに設定される内容やその公開条件を含むプレゼンス構造を公開することは、プライバシーやセキュリティ上問題となる恐れがある。

本発明は、複数のプレゼンスを有するプレゼンティティのプレゼンスを更新するためのプレゼンティティの手間や、ウォッチャーがプレゼンティティのプレゼンスを参照する際の手間を軽減することを目的とする。
また本発明は、複数のプレゼンスを有するプレゼンティティのプレゼンスを第３者が更新するにあたり、プレゼンティティのプライバシーの保護と更新者の手間の軽減とを両立することを目的とする。

前記課題を解決するために、発明１は、ユーザを特定するユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンスシステムを提供する。このシステムは、以下の手段を有する。
・プレゼンスの所有者以外のユーザである更新者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスを所有する更新対象者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスと、を含む更新依頼を受け付ける受付手段、
・プレゼンスの内容の種別を表す種別情報であって、前記更新者に対応付けられた種別情報を取得する種別取得手段、
・前記更新対象者の各プレゼンスの識別子と種別情報との関連付けを記憶する関連付テーブル、
・前記関連付テーブルを参照し、前記更新者に対応する種別情報に関連付けられたプレゼンス識別子を特定するプレゼンス特定手段と、
・前記特定したプレゼンス識別子に対し、前記更新依頼に含まれていたプレゼンスを設定するプレゼンス設定手段。

発明２は、以下の手段を備えるプレゼンスシステムを提供する。
・各ユーザのプレゼンスのプレゼンス識別子、種別情報及びプレゼンスと対応付けて記憶する種別付プレゼンステーブル、
・各ユーザのプレゼンス識別子毎に、プレゼンスを参照するウォッチャーを記憶するウォッチャーリスト、
・サブスクライバーが購読したいプレゼンスに対応する種別情報、前記サブスクライバーのユーザ識別子、サブスクライビーのユーザ識別子を含むサブスクライブを受信する第１サブスクライブ受信手段、
・種別付プレゼンステーブルを検索して、前記サブスクライブに含まれるサブスクライビーのユーザ識別子及び種別情報に対応するプレゼンス識別子を特定し、当該プレゼンス識別子のウォッチャーリストに前記サブスライバーのユーザ識別子を登録する登録手段。

発明３は、以下の手段を備えるプレゼンスシステムを提供する。
・各ユーザのプレゼンスの公開条件を、プレゼンス識別子、種別情報及びプレゼンスと対応付けて記憶する種別付プレゼンステーブル、
・各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶するウォッチャーリスト、
・サブスクライバーが購読したいプレゼンスに対応する種別情報、前記サブスクライバーのユーザ識別子、サブスクライビーのユーザ識別子を含むサブスクライブを受信する第１サブスクライブ受信手段、
・前記サブスクライビーのプレゼンスの公開条件のうち、前記サブスクライブに含まれる種別情報に対応するプレゼンスの公開条件を前記サブスクライバーが満たしているか否かを判断し、満たしていれば前記サブスクライバーを前記サブスクライビーのウォッチャーリストに登録する公開判定手段。

発明４は、以下の手段を備えるプレゼンスシステムを提供する。
・各ユーザのプレゼンスを、プレゼンス識別子及び種別情報と対応付けて記憶する第１プレゼンステーブル、
・各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶する第１ウォッチャーリスト、
・プレゼンスの転送元のユーザ識別子と、前記プレゼンスの転送先のユーザ識別子と、前記プレゼンスの転送に対応付けられた種別情報と、を含む転送依頼を受信する第１転送依頼受信手段、
・前記転送依頼の受信に応じ、前記転送先をサブスクライバーとし、前記転送元をサブスクライビーとし、前記転送依頼中の種別情報を含むサブスクライブを生成する第１サブスクライブ生成手段、
・前記サブスクライブに基づいて、前記転送元のウォッチャーリストに、前記転送先のユーザ識別子及び前記転送依頼中の種別情報を対応付けて登録する第１ウォッチャー登録手段、
・前記転送元のプレゼンスが更新された場合、前記転送先に対し、前記転送依頼に含まれる前記種別情報と前記転送元のプレゼンスとを通知する種別情報付通知手段。

発明５は、発明４において、以下の手段をさらに備えるプレゼンスシステムを提供する。
・各ユーザのプレゼンスを、プレゼンス識別子及び前記プレゼンスの公開条件と対応付けて記憶する第２プレゼンステーブル、
・各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶する第２ウォッチャーリスト、
・プレゼンスの転送元のユーザ識別子と、前記プレゼンスの転送先のユーザ識別子と、を含む転送依頼を受信する第２転送依頼受信手段、
・前記転送依頼の受信に応じ、前記転送先をサブスクライバーとし、前記転送元をサブスクライビーとし、前記転送先のウォッチャーリストを含むサブスクライブを生成する第２サブスクライブ生成手段、
・前記サブスクライブに基づいて、前記転送元のプレゼンスのうちその公開条件を前記転送先が満たすプレゼンスを前記プレゼンステーブルから検索し、検索したプレゼンスのウォッチャーリストに、前記転送先のユーザ識別子を登録する第２ウォッチャー登録手段。

発明６は、発明４において、以下の手段をさらに備えるプレゼンスシステムを提供する。
・各ユーザのプレゼンスを、プレゼンス識別子及び前記プレゼンスの公開条件と対応付けて記憶する第３プレゼンステーブル、
・各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶する第３ウォッチャーリスト、
・プレゼンスの転送元のユーザ識別子と、前記プレゼンスの転送先のユーザ識別子と、を含む転送依頼を受信する第３転送依頼受信手段、
・前記転送依頼の受信に応じ、前記転送先をサブスクライバーとし、前記転送元をサブスクライビーとし、前記転送先の公開条件を含むサブスクライブを生成する第３サブスクライブ生成手段、
・前記サブスクライブに基づいて、前記転送元のプレゼンスのうちその公開条件を前記転送先が満たすプレゼンスを前記プレゼンステーブルから検索し、検索したプレゼンスのウォッチャーリストに前記転送先のユーザ識別子を登録する第３ウォッチャー登録手段。

発明７は、前記プレゼンスシステムが実行するプレゼンス管理方法を提供する。
発明８は、前記プレゼンス管理方法を記録したコンピュータ読み取り可能な記録媒体を提供する。
発明９は、前記プレゼンスシステムとしてコンピュータを機能させるプレゼンス管理プログラムを提供する。

発明１０は、ユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンスシステムを提供する。このシステムは下記手段を有する。
・あるプレゼンスの所有者以外のユーザである依頼者のユーザ識別子と、前記プレゼンスを所有する対象者のユーザ識別子と、任意のプレゼンスの種別を表し前記更新者または前記対象者に対応付けられた種別情報と、を取得する取得手段、
・前記対象者のプレゼンスを処理するコマンドの種類を決定する判定手段、
・前記判定手段が決定したコマンドの種類と、前記取得手段が取得した種別情報と、前記依頼者のユーザ識別子と、前記対象者のユーザ識別子とを含むコマンドを生成するコマンド生成手段、
・前記コマンド生成手段が生成したコマンドを受け付け、そのコマンドに従って前記対象者のプレゼンスの更新、サブスクライブ／サブスクライブの解除または転送／転送の解除を行うコマンド実行手段。

本発明を用いれば、複数のプレゼンスを有するプレゼンティティを更新するためのプレゼンティティの手間や、ウォッチャーがプレゼンティティのプレゼンスを参照する際の手間を軽減することができる。また本発明は、第３者のプレゼンスを更新するための手間を軽減することができる。

＜概要＞
図１は、本発明の概念を示す説明図である。プレゼンスシステムは、プレゼンスサーバと複数のプレゼンスクライアントとがネットワークを介して接続されることにより構成されている。プレゼンスサーバは、プレゼンティティのプレゼンスを管理し、プレゼンスのウォッチャーにプレゼンスの更新を通知する。プレゼンティティとはプレゼンスを所有するユーザである。ウォッチャーとは、プレゼンティティのプレゼンスを閲覧しているユーザである。プレゼンスクライアントは、プレゼンスの更新依頼をプレゼンスサーバに通知したり、プレゼンスの更新通知をプレゼンスサーバから受信したりする。プレゼンティティやウォッチャーになりうるユーザは、人、組織、物、サービスなどであって、プレゼンスシステム上でユーザＩＤにより識別される。以下、ユーザＩＤ“Ａ”のユーザを、ユーザＡ、プレゼンティティＡまたはウォッチャーＡと呼ぶ。他のユーザＩＤについても同様である。

プレゼンスサーバは、ユーザＡのプレゼンスとして、プレゼンスＩＤ“ａ１”、“ａ２”で識別されるプレゼンスを記憶している。ユーザＡは、カードを保持しており、このカードをカードリーダに任意のタイミングでかざす。カードリーダは、カードのデータを読み込み、プレゼンスサーバに更新依頼を送信する。更新依頼には、以下の情報（ａ）〜（ｄ）が含まれている。

（ａ）更新者ＩＤ：この場合はカードリーダに割り当てられたユーザＩＤ。更新依頼の送信元を識別する。
（ｂ）対象者ＩＤ：更新依頼に含まれるプレゼンスの設定対象ユーザのＩＤを特定する。
（ｃ）種別情報：プレゼンスの種別。

（ｄ）プレゼンス：対象者ＩＤで特定されるユーザのプレゼンスを特定する。
上記の情報のうち、（ａ）更新者ＩＤ及び（ｄ）プレゼンスは、カードリーダが記憶している。（ｂ）ユーザＩＤ及び（ｃ）識別情報は、ユーザＡが所持するカードに記録されている。
プレゼンスサーバは、更新依頼を受信すると、種別情報に基づいてユーザＡのプレゼンスＩＤ“ａ１”を更新対象に特定する。さらにプレゼンスサーバは、プレゼンスＩＤ“ａ１”のプレゼンスを、更新依頼に含まれているプレゼンス“会議室Ａ”に書き換える。これにより、カードリーダは、“種別情報”により指定したプレゼンスを更新することが出来る。更新されたプレゼンスは、プレゼンス“ａ１”のウォッチャーにプレゼンスサーバから通知される。

図２は、プレゼンティティＡのプレゼンスの更新依頼がユーザＹからあったことを示す画面例である。プレゼンスサーバは、例えばこの画面例をユーザＡが操作するプレゼンスクライアントに送信し、第３者からの更新依頼を通知する。この図が示すように、更新者が指定してきた種別情報に対し、プレゼンティティは自分が所有するプレゼンスを自由に関連付けることができる。

＜第１実施形態＞
［システム全体の機能構成］
図３は、本発明の第１実施形態に係るプレゼンスシステム１００ａの概略構成図である。プレゼンスシステム１００ａは、プレゼンスサーバ１０とプレゼンスクライアント２０がネットワークを介して接続されて構成されている。プレゼンスシステム１００ａは、種別情報管理サーバ３０を含んでいても良い。

プレゼンスサーバ１０は、セッション管理部１１、プレゼンステーブル１２、プレゼンス管理部１３、ウォッチャー管理部１４、通知部１５、関連付テーブル１６を有する。セッション管理部１１は、ネットワークとプレゼンスサーバ１０内の各構成要素との間でデータの受け渡しを行う。プレゼンステーブル１２は、ユーザ毎に管理され、少なくともプレゼンスＩＤ及びプレゼンスを記憶する。この例では、プレゼンステーブル１２にはプレゼンス毎のウォッチャーリストを含む。さらに、プレゼンステーブル１２は、各プレゼンスの公開条件を含んでいることとする。

プレゼンス管理部１３は、プレゼンスの更新通知を受信すると、プレゼンステーブル１２を更新する。ウォッチャー管理部１４は、サブスクライブを受信すると、プレゼンステーブル１２内のウォッチャーリストを更新する。通知部１５は、プレゼンスの更新通知を受信すると、そのプレゼンスのウォッチャーに新たなプレゼンスを通知する。関連付テーブル１６は、種別情報とプレゼンスとの関連づけを定義する。本実施形態では、種別情報を用いて第３者のプレゼンスを更新する。

［プレゼンスサーバの各部の機能］
プレゼンス管理部１３は、関連付設定部１３１を有し、好ましくは設定先判定部１３２、設定部１３３、設定内容決定部１３４、設定ルール１３５及び／または種別情報取得部１３６を有している。また、ウォッチャー管理部１４は、好ましくは公開判定部１４１を有している。以下、これらの機能について具体的に説明する。

（１）種別情報とプレゼンスの関連付け
関連付テーブル１６は、種別情報とプレゼンスとを関係づける。関連付設定部１３１は、画面をプレゼンスクライアント２０に提供して関連付テーブル１６への登録を受け付け、受け付けた内容を関連付テーブル１６に登録する。図４〜図９を参照し、種別情報とプレゼンスとの関係を詳細に説明する。

図４は、関連付テーブル１６の一例を示す説明図である。この関連付テーブル１６は、種別情報とプレゼンスＩＤとを対応付けている。また、この関連付テーブル１６は、種別情報に対応するプレゼンスの更新が、時間帯によって変化するように定義している。つまり、8:00〜18:00ではプレゼンス“ａ３”が更新依頼によって更新され、それ以外の時間帯ではプレゼンス“ａ４”が更新依頼によって更新される。図５は、前記図４の関連付テーブル１６をプレゼンスサーバ１０に登録するための画面例である。ユーザは、自分のプレゼンスと種別情報とを、この画面で関連付けることができる。この画面は、関連付設定部１３１からクライアントに提供される。

図６は、関連付テーブル１６の別の一例を示す説明図である。この関連付テーブル１６は、種別情報とプレゼンスＩＤとを対応付けている。また、この関連付テーブル１６は、種別情報に対応するプレゼンス（図中、更新先プレゼンスＩＤ）の更新が、別のプレゼンス（図中、チェックプレゼンスＩＤ）の内容によって変化するように定義している。つまり、チェックプレゼンス“ａ１”が「会社」の時は、更新先プレゼンスＩＤ“ａ３”が更新依頼によって更新される。また、チェックプレゼンス“ａ１”が「自宅」の時は、更新先プレゼンスＩＤ“ａ４”が更新依頼によって更新される。図７は、前記図６の関連付テーブル１６をプレゼンスサーバ１０に登録するための画面例である。ユーザは、自分のプレゼンスと種別情報とを、この画面で関連付けることができる。この画面は、関連付設定部１３１からクライアントに提供される。

図８は、関連付テーブル１６の別の一例を示す説明図である。この関連付テーブル１６は、プレゼンティティのウォッチャーリストに更新者が登録されているプレゼンスを、種別情報に対応させている。図９は、前記図８の関連付テーブル１６を登録するための画面例である。この画面は、関連付設定部１３１からクライアントに提供される。
以上説明したように、関連付テーブル１６は、どの種別情報によってどのプレゼンスが更新されるかまたは更新されないかを定義する。プレゼンティティは、関連付テーブル１６を自由に設定することができる。

（２）種別情報付更新依頼
再び図１を参照する。設定先判定部１３２は、下記の内容を含む更新依頼を受信すると、対象者ＩＤで特定されるユーザＡのプレゼンステーブル１２から、種別情報「位置」に対応するプレゼンスＩＤ“ａ１”を更新対象に特定する。図１では、説明を容易にするため、プレゼンステーブル１２と関連付テーブル１６とをまとめて示している。以下の図でも同様である。設定部１３３は、プレゼンスＩＤ“ａ１”の内容として、プレゼンス「会議室Ａ」を設定する。更新の対象者が種別情報と自分のプレゼンスとを対応付けていない場合、図２に例示する通知が対象者に送信される。この例では、ユーザＡが操作するプレゼンスクライアント２０にこの画面が提供される。ユーザＡは、この画面上で、種別情報「位置」に関連付ける自分のプレゼンスを設定することができる。言い換えれば、更新者Ｘが指定する種別情報に対応するプレゼンスＩＤが対象者のプレゼンステーブル１２にある限り、更新者は自由に種別情報を指定して更新依頼を送信できる。その後、通常のプレゼンスサーバ１０と同様、通知部１５は、プレゼンスＩＤ“ａ１”のウォッチャーに新たなプレゼンス「会議室Ａ」を通知する。なお、この例では、プレゼンステーブル１２がプレゼンスの公開条件を含んでいなくても良い。

（更新依頼）
更新者ＩＤ“Ｘ”
対象者ＩＤ“Ａ”
プレゼンス「会議室Ａ」
種別情報「位置」
（３）プレゼンスの変換・設定
図１０を参照し、更新依頼に含まれるプレゼンスを変換して対象者のプレゼンスに設定する場合を説明する。関連付設定部１３１が下記の内容を含む更新依頼を受信した場合を考える。

（更新依頼）
更新者ＩＤ“Ｘ”
対象者ＩＤ“荷物Ａ”
プレゼンス「集荷店舗ＩＤ」
種別情報「荷物情報」
また、ユーザである荷物Ａの設定ルール１３５として、図１０に示す内容が記憶されているとする。この設定ルール１３５は、以下のように更新依頼に含まれるプレゼンスを変換することを定義する。

（設定ルール）
更新依頼に含まれるプレゼンスが「集荷店舗ＩＤ」→「集荷済」
更新依頼に含まれるプレゼンスが「運送トラック情報」→「運送中」
更新依頼に含まれるプレゼンスが「宅配済」→「宅配済」
この場合、設定内容決定部１３４は、更新依頼と設定ルール１３５とを比較し、変換可能なプレゼンスがあるか否かを判断する。変換可能なプレゼンス、この場合は「集荷店舗ＩＤ」があれば、それを設定ルール１３５に従って変換する。設定部１３３は、設定内容決定部１３４により変換されたプレゼンスを、対象者のプレゼンスに設定する。運送業者が設定するプレゼンス「集荷店舗ＩＤ」を「集荷済」に変換することにより、荷物Ａのプレゼンスのウォッチャーは荷物Ａの状態を把握しやすくなる。前述と同様、この例では、プレゼンステーブル１２がプレゼンスの公開条件を含んでいなくても良い。

前記図１のように更新依頼に種別情報が含まれている場合、設定ルール１３５に従って変換したプレゼンスを、種別情報に対応するプレゼンスとして設定することもできる。
図１１は、設定内容決定部１３４がプレゼンスクライアント２０に提供する画面例である。この画面は、設定ルール１３５の入力を受け付ける。設定内容決定部１３４は、画面に入力された内容を、設定ルール１３５に登録する。

（４）種別情報と更新者との管理
図１２は、種別情報と更新者との対応付けに基づいて、更新者が第３者のプレゼンスを更新することを示す説明図である。
種別情報管理サーバ３０は、更新者のユーザＩＤと、その更新者が更新対象とするプレゼンスの種別情報と、を対応付けて記憶している。下記の内容を含む更新依頼をプレゼンスサーバ１０が受信すると、種別情報取得部１３６は、更新者Ｘに対応する種別情報「位置」を、種別情報管理サーバ３０から取得する。

（更新依頼）
更新者ＩＤ“Ｘ”
対象者ＩＤ“Ａ”
プレゼンス「会議室Ａ」
その後は、プレゼンスサーバ１０は、前記図１と同様の処理を行う。すなわち、設定先判定部１３２により取得した種別情報「位置」に対応するプレゼンスＩＤをユーザＡのプレゼンステーブル１２から特定する。そして、設定部１３３により、特定したプレゼンスＩＤの内容として、更新依頼に含まれているプレゼンス「会議室Ａ」を設定する。前述と同様、この例では、プレゼンステーブル１２がプレゼンスの公開条件を含んでいなくても良い。

種別情報管理サーバ３０を、プレゼンスサーバ１０内部または外部に設けることにより、更新依頼に種別情報を含めなくても更新対象のプレゼンスを特定することができる。
（５）種別情報を用いたサブスクライブ
図１３は、種別情報を用いたサブスクライブの流れを示す説明図である。ウォッチャー管理部１４が種別情報を含むサブスクライブを受信すると、ウォッチャー管理部１４の公開判定部１４１は次の処理を行う。下記は種別情報付サブスクライブの内容である。

（種別情報付サブスクライブ）
サブスクライバーＩＤ“Ｘ”
サブスクライビーＩＤ“Ａ”
種別情報「位置」
このサブスクライブに基づいて、公開判定部１４１は、サブスクライビーＡのプレゼンステーブル１２を参照し、サブスクライブに含まれる種別情報「位置」に対応するプレゼンスの公開条件を、サブスクライバーＸが満足するかどうか判断する。この例では、サブスクライバーＸは、プレゼンスＩＤ“ａ１”の公開条件を満足する。そこで、公開判定部１４１は、サブスクライバーＸを、プレゼンスＩＤ“ａ１”のウォッチャーリストに登録する。公開判定部１４１は、ウォッチャーリストへの登録を、サブスクライビーに問い合わせた後に行っても良い。

図１４（ａ）〜（ｄ）は、種別情報付サブスクライブを要求する画面例である。公開判定部１４１は、これらの画面をプレゼンスクライアント２０に提供し、画面に入力された情報を取得する。同図（ａ）は、サブスクライバーを“Ｘ”とすれば、上記の種別情報付サブスクライブをサブスクライバーが生成するための画面例である。同図（ｂ）は、種別情報付サブスクライブのために、サブスクライビーがプレゼンスＩＤ“ａ１”と種別情報「位置」とを関連付けるための画面である。同図（ｃ）は、プレゼンスサーバ１０に接続されたディスプレイなどで出力される画面であり、種別情報付サブスクライブの受信時にサブスクライブを拒否するかサブスクライビーに問い合わせるかを設定する。同図（ｄ）は、前記（ｃ）で「ユーザに問い合わせる」を選択した場合に、サブスクライブ受信時にサブスクライビーに通知される画面例である。

サブスクライブに種別情報を付加すれば、サブスクライバーは、種別情報を指定してサブスクライブを送信するので、サブスクライビーのプレゼンスの構成や各プレゼンス識別子を予め調べなくても良い。従って、サブスクライバーは、手軽にサブスクライブを行うことができる。また、サブスクライビーは、自分のプレゼンステーブル１２の構成を他人に公開しなくてすむ利点がある。

なお、サブスクライバーとは、他のユーザのプレゼンスの閲覧を要求するユーザである。またサブスクライビーとは、サブスクライバーが閲覧を要求しているプレゼンスの所有者である。
＜第２実施形態＞
［システム全体の機能構成］
図１５は、本発明の第２実施形態に係るプレゼンスシステム１００ｂの概略構成図である。プレゼンスシステム１００ｂは、プレゼンスサーバ１０とプレゼンスクライアント２０がネットワークを介して接続されて構成されている。図示していないが、第１実施形態と同様、プレゼンスシステム１００ｂは、種別情報管理サーバ３０を含んでいても良い。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。

本実施形態においては、プレゼンスサーバ１０は、セッション管理部１１、プレゼンステーブル１２、プレゼンス管理部１３、ウォッチャー管理部１４、通知部１５を有し、関連付テーブル１６を有することが好ましい。セッション管理部１１は、ネットワークとプレゼンスサーバ１０内の各構成要素との間でデータの受け渡しを行う。プレゼンステーブル１２は、ユーザ毎に管理され、少なくともプレゼンスＩＤ及びプレゼンスを記憶する。この例では、プレゼンステーブル１２にはプレゼンス毎のウォッチャーリストを含む。さらに、プレゼンステーブル１２は、各プレゼンスの公開条件及び必要に応じてプレゼンスの転送元を含んでいることとする。

プレゼンス管理部１３は、プレゼンスの更新通知を受信すると、プレゼンステーブル１２を更新する。ウォッチャー管理部１４は、サブスクライブを受信すると、プレゼンステーブル１２内のウォッチャーリストを更新する。通知部１５は、プレゼンスの更新通知を受信すると、そのプレゼンスのウォッチャーに新たなプレゼンスを通知する。関連付テーブル１６は、種別情報とプレゼンスとの関連づけを定義する。

［プレゼンスサーバの各部の機能］
プレゼンス管理部１３は、好ましくは関連付設定部１３１、置換処理部１３７及び転送元公開条件設定部１３８を有している。また、ウォッチャー管理部１４は、好ましくは転送処理部１４２及びサブスクライブ仲介部１４３を有している。以下、これらの機能について具体的に説明する。なお、関連付設定部１３１の機能は第１実施形態と同様である。

（１）種別情報を用いた転送依頼
図１６は、種別情報付転送依頼を受信したプレゼンスサーバ１０の処理の流れを示す説明図である。種別情報付転送依頼は、下記の内容を含む。
（種別情報付転送依頼）
転送依頼者ＩＤ“Ｘ”
転送先ＩＤ“Ｂ”
転送元ＩＤ“Ａ”
種別情報「位置」
転送処理部１４２は、上記転送依頼に含まれる種別情報「位置」をキーに転送先ユーザＢのプレゼンステーブル１２を参照する。さらに、転送処理部１４２は、種別情報付サブスクライブを生成する。種別情報付サブスクライブには、下記の内容が含まれる。

（種別情報付サブスクライブ）
サブスクライバーＩＤ＝転送先ＩＤ“Ｂ”
サブスクライビーＩＤ＝転送元ＩＤ“Ａ”
種別情報「位置」
さらに転送処理部１４２は、転送元ユーザＡのプレゼンスＩＤ“ａ１”のウォッチャーリストに、転送先ユーザＢ及び種別情報「位置」を登録する。また、転送処理部１４２は、転送先Ｂの種別情報「位置」に対応するプレゼンスの転送元として、ユーザＢのプレゼンステーブル１２にユーザＡを登録する。

ユーザＡのプレゼンス“ａ１”が更新されると、プレゼンス管理部１３は、ユーザＢに対し、下記の種別情報付プレゼンス通知を送信する。これにより、ユーザＢは、自分の種別情報「位置」のプレゼンスが、ユーザＡのプレゼンスから自動的に転送されていることを知る。さらに、プレゼンス管理部１３の置換処理部１３７は、転送元Ａのプレゼンスを、転送先Ｂのプレゼンスとしてプレゼンステーブル１２に設定する。

（種別情報付プレゼンス通知）
プレゼンティティＩＤ＝転送元ＩＤ“Ａ”
ウォッチャーＩＤ＝転送先ＩＤ“Ｂ”
種別情報「位置」
プレゼンス「会議室Ａ」
図１７は、転送処理部１４２がプレゼンスクライアント２０に提供する画面例である。この画面例は、転送依頼者からの転送依頼の設定を受け付け、プレゼンスサーバ１０に送信する。

この構成では、転送先に転送元のプレゼンスを通知するときに、種別情報を同時に通知することができる。従って、転送依頼者は、転送元からのプレゼンスを転送先のどのプレゼンスに反映させたいかを、種別情報により指定することができる。すなわち、転送によるプレゼンスの自動更新の仕組みを、必要に応じて自由に変えることができる。
（２）ウォッチャーリスト付転送
図１８は、ウォッチャーリスト付転送依頼に基づいてウォッチャーリスト付サブスクライブを生成する説明図である。プレゼンスサーバ１０は、下記の内容の転送依頼を受信する。

（転送依頼）
転送依頼者ＩＤ“Ｘ”
転送先ＩＤ“Ｂ”
転送元ＩＤ“Ａ”
ウォッチャー管理部１４の転送処理部１４２は、転送先Ｂのウォッチャーリストを取得し、ウォッチャーリスト付サブスクライブを生成する。

（ウォッチャーリスト付サブスクライブ）
サブスクライバーＩＤ＝転送先ＩＤ“Ｂ”
サブスクライビーＩＤ＝転送元ＩＤ“Ａ”
ウォッチャーリスト“Ｚ”
転送処理部１４２は、転送元のプレゼンステーブル１２のプレゼンスのうち、その公開条件を転送元ユーザが満足しているプレゼンスを検索する。そしてそのプレゼンスのウォッチャーとして、転送先Ｂを登録する。その後、転送処理部１４２は、転送先Ｂのプレゼンスの転送元として、ユーザＢのプレゼンステーブル１２にユーザＡを登録する。さらに、プレゼンス管理部１３の置換処理部１３７は、転送元Ａのプレゼンスを、転送先Ｂのプレゼンスとしてプレゼンステーブル１２に設定する。

この構成では、転送元Ａが自分のプレゼンスの配信を許可している範囲内で、その転送元のプレゼンスの転送を行う。従って、転送元のプライバシーを保護することができる。
なお、転送依頼者が転送するプレゼンスの種別情報を指定することも可能である。その場合には、転送依頼者が転送を希望する分類のプレゼンスが転送されると期待できるし、同時に転送元のプライバシーが保護される。

（３）公開条件付転送
図１９は、公開条件付転送の説明図である。プレゼンスサーバ１０は、下記の内容の転送依頼を受信する。
（転送依頼）
転送依頼者ＩＤ“Ｘ”
転送先ＩＤ“Ｂ”
転送元ＩＤ“Ａ”
ウォッチャー管理部１４の転送処理部１４２は、転送先Ｂの公開条件を取得し、下記の内容を含む公開条件付サブスクライブを生成する。

（公開条件付サブスクライブ）
サブスクライバーＩＤ＝転送先ＩＤ“Ｂ”
サブスクライビーＩＤ＝転送元ＩＤ“Ａ”
公開条件“Ｚに許可”
さらに転送処理部１４２は、転送元ユーザＡの公開条件と転送先ユーザＢの公開条件とを比較し、比較結果に基づいて転送元ユーザＡのウォッチャーリストに転送先ユーザＢを登録する。例えば、転送先ユーザＢの公開条件が転送元ユーザＡのある公開条件を満足していれば、その公開条件に対応するプレゼンスのウォッチャーとしてユーザＢを登録する。通常、転送元の公開条件の優先度を高くすることが好ましい。プライバシー保護のためである。その後、転送処理部１４２は、転送先Ｂのプレゼンスの転送元として、ユーザＢのプレゼンステーブル１２にユーザＡを登録する。さらに、プレゼンス管理部１３の置換処理部１３７は、転送元Ａのプレゼンスを、転送先Ｂのプレゼンスとしてプレゼンステーブル１２に設定する。

図２０（ａ）は、転送処理部１４２がプレゼンスクライアント２０に提供する画面例である。この画面例は、ウォッチャーリスト付サブスクライブの受信時に、転送先（サブスクライビー）に問い合わせるか、問い合わせせずに公開条件が合致すればプレゼンスを転送するかの設定を受け付ける。同図（ｂ）は、転送元に対し、ウォッチャーリスト付サブスクライブ（図中、転送依頼）を通知する画面例である。この画面は、どのプレゼンスを転送するかの選択を受け付ける。

この構成により、転送先と転送元との両方の公開条件が満たされる範囲での転送が可能となる。転送依頼者は、転送元や転送先のプレゼンスの構成やプライバシーへの配慮を気にせずに転送依頼を行うことができる。
なお、種別情報を用いて転送するプレゼンスを指定することももちろん可能である。
（４）転送元の公開条件を転送先に設定
図２１は、転送元の公開条件を転送先に設定する説明図である。転送処理部１４２は下記内容の種別情報付転送依頼を受信する。

（種別情報付転送依頼）
転送依頼者ＩＤ“Ｘ”
転送先ＩＤ“Ｂ”
転送元ＩＤ“Ａ”
種別情報「位置」
転送処理部１４２は、上記転送依頼に含まれる種別情報「位置」をキーに転送先ユーザＢのプレゼンステーブル１２を参照する。さらに、転送処理部１４２は、種別情報付サブスクライブを生成する。種別情報付サブスクライブには、下記の内容が含まれる。

（種別情報付サブスクライブ）
サブスクライバーＩＤ＝転送先ＩＤ“Ｂ”
サブスクライビーＩＤ＝転送元ＩＤ“Ａ”
種別情報「位置」
転送処理部１４２は、転送元ユーザＡのプレゼンスＩＤ“ａ１”のウォッチャーリストに、転送先ユーザＢ及び種別情報「位置」を登録する。また、転送処理部１４２は、転送先Ｂの種別情報「位置」に対応するプレゼンスの転送元として、ユーザＢのプレゼンステーブル１２にユーザＡを登録する。

一方、プレゼンス管理部１３の転送元公開条件設定部１３８は、転送先Ｂがウォッチャーとなったプレゼンス“ａ１”の公開条件を、ユーザＡのプレゼンステーブル１２から読み出す。そしてこれを、転送依頼に含まれる種別情報に対応するプレゼンス“ｂ１”の公開条件として、ユーザＢのプレゼンステーブル１２に登録する。
すなわち、転送依頼者が種別情報を用いて転送したいプレゼンスの種別を指定すると、その種別情報に対応する転送元のプレゼンスの公開条件が、その種別情報に対応する転送先のプレゼンスの公開条件として設定される。従って、種別情報を用いた転送依頼により、転送元のプライバシーを簡単に保護することができる。

（５）転送元公開条件の更新を転送先に反映
図２２は、転送元の公開条件の変更を、転送先の公開条件に反映させる説明図である。前記図１９において、転送元Ａと転送先Ｂとの両方の公開条件を満たすように転送元のウォッチャーリストを更新した後、転送元Ａの公開条件が変わる場合がある。また、前記図２１において、転送先Ｂのプレゼンス“ｂ１”に、転送元Ａの公開条件を設定した後、これが変更される場合がある。転送元Ａの公開条件の設定通知は、下記の内容を含む。

（公開条件の設定依頼）
設定依頼者ＩＤ“Ａ”
プレゼンティティ“Ａ”
公開条件「Ｂ、Ｙ、Ｚ」
転送元公開条件設定部１３８は、ウォッチャーリストを参照し、下記の公開条件通知を生成する。いま、ウォッチャーリストには、ユーザＩＤ“Ｂ”と「位置」とが記述されている。

（公開条件通知）
転送元ＩＤ“Ａ”
転送先ＩＤ“Ｂ”
種別情報「位置」
公開条件「Ｂ、Ｙ、Ｚ」
転送元公開条件設定部１３８は、この通知に基づいて、種別情報「位置」に関連付けられたプレゼンスＩＤ“ｂ１”を特定し、その公開条件を書き換える。

この構成により、転送元の公開条件を種別情報を用いて転送先の公開条件に設定した後、転送元の公開条件の変化を転送先にも反映させる。従って、転送元の公開条件が変化しても、転送元のプライバシーを動的に保護することができる。
（６）転送先公開条件の更新を転送元に反映
図２３は、転送先の公開条件の変更を、転送元の公開条件に反映させる説明図である。前記図１９において、転送元Ａと転送先Ｂとの両方の公開条件を満たすように転送元Ａのウォッチャーリストを更新した後、転送先Ｂの公開条件が変わる場合がある。また、図２１において、転送先Ｂのプレゼンス“ｂ１”に、転送元Ａの公開条件を設定した後、ユーザＢがこれを変更する場合がある。転送先Ｂの新たな公開条件の設定通知は、下記の内容を含む。

（ユーザＢの新たな公開条件の設定依頼）
設定依頼者ＩＤ“Ｂ”
プレゼンティティ“Ｂ”
公開条件「Ｙ、Ｚ」
ウォッチャー管理部１４の転送処理部１４２は、転送先Ｂの公開条件を取得し、下記の内容を含む公開条件付サブスクライブを生成する。

（公開条件付サブスクライブ）
サブスクライバーＩＤ＝転送先ＩＤ“Ｂ”
サブスクライビーＩＤ＝転送元ＩＤ“Ａ”
公開条件“Ｙ，Ｚに許可”
さらに転送処理部１４２は、転送元ユーザＡの公開条件と転送先ユーザＢの新たな公開条件とを比較し、比較結果に基づいて転送元ユーザＡのウォッチャーリストを更新する。例えば、転送先ユーザＢがウォッチャーに登録されているプレゼンスについて、転送先Ｂの公開条件が転送元Ａの公開条件を満足しているかどうか、転送処理部１４２は判断する。通常、転送元の公開条件の優先度を高くすることが好ましい。プライバシー保護のためである。転送先Ｂの新たな公開条件が転送元Ａの公開条件を満足していれば、そのプレゼンスのウォッチャーとしてユーザＢを登録する。満たしていなければ、ウォッチャーからユーザＢを削除する。その場合、転送処理部１４２は、転送先Ｂのプレゼンスから、通知元Ａを削除する。

この構成により、転送先の公開条件が動的に変化しても、転送先と転送元との両方の公開条件が満たされる範囲での転送が常に可能となる。転送依頼者は、転送依頼後に転送先の公開条件が変化して転送元のプライバシーが侵害されることを気にせずに転送依頼を行うことができる。
なお、種別情報を用いて転送するプレゼンスを指定することももちろん可能である。

（７）間接的なサブスクライブ
図２４は、間接的なサブスクライブの説明図である。ウォッチャー管理部１４のサブスクライブ仲介部１４３は、下記のサブスクライブを受信すると、下記のウォッチャーリスト追加依頼を転送元Ａに依頼する。ここで、サブスクライビーＢのプレゼンス“ｂ１”は、ユーザＡのプレゼンスが転送されたものである。

（サブスクライブ）
サブスクライバーＩＤ“Ｙ”
サブスクライビーＩＤ“Ｂ”
（ウォッチャーリスト追加依頼）
サブスクライビーＩＤ“Ｂ”
転送元ＩＤ“Ａ”
サブスクライバーＩＤ“Ｙ”
サブスクライブ仲介部１４３は、転送先Ａの公開条件とウォッチャーリスト追加依頼のサブスクライバーとを比較する。そしてその比較結果に基づいて、転送先Ｂのプレゼンス“ｂ１”のウォッチャーにサブスクライバーＹを追加する。例えば、サブスクライバーの全員が転送先の公開条件を満足する場合である。

図２５は、転送元公開条件設定部１３８が提供する画面例である。同図（ａ）は、ウォッチャーリスト追加依頼発生時に、プレゼンスサーバ１０の操作者に通知する画面例である。同図（ｂ）は、転送元に通知する画面例である。転送元ユーザは、公開するプレゼンスや公開条件を設定することができる。
結局、転送元のユーザＡの公開条件の範囲内でサブスクライバーＢのウォッチャーを追加すれば、転送元ユーザのプライバシーを保護することができる。

＜第３実施形態＞
第３及び第４実施形態では、種別情報を用いた更新依頼やサブスクライブ、転送依頼を行う際に、種別情報に対応するプレゼンスＩＤがないという事態を防ぐことを考える。
図２６は、第３実施形態に係るプレゼンスシステム１００ｃの概略構成図である。プレゼンスシステム１００ｃは、前記第１実施形態のプレゼンスシステム１００ａと同様、プレゼンスサーバ１０とプレゼンスクライアント２０がネットワークを介して接続されて構成されている。プレゼンスシステム１００ｃは、種別情報管理サーバ３０を含んでいても良い。プレゼンスサーバ１０は、図示しないカードリーダとネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。

本実施形態においては、プレゼンスサーバ１０は、辞書ＤＢ２００を有している。辞書ＤＢ２００は、例えば類義語辞書や同義語辞書を記憶している。類義語辞書が辞書ＤＢ２００に記憶されている場合を例にとり、説明する。説明を容易にするため、カードリーダから下記の種別情報付き更新依頼がプレゼンスサーバ１０に送信された場合を考える。
（更新依頼）
更新者ＩＤ“Ｘ”
対象者ＩＤ“Ａ”
プレゼンス“会議室Ａ”
種別情報“位置”
プレゼンスサーバ１０の設定先判定部１３２は、類義語辞書に基づいて、更新依頼中の種別情報に対応するプレゼンスＩＤを、ユーザＡのプレゼンステーブルから特定する。設定部１３３は、そのプレゼンスＩＤの内容として、更新依頼に含まれているプレゼンス「会議室Ａ」を設定する。

設定先判定部１３２の処理をさらに詳しく説明する。設定先判定部１３２は、更新依頼中の種別情報に対応する類義語、例えば「場所」、「地点」を、辞書ＤＢ２００から抽出する。設定先判定部１３２は、更新依頼中の種別情報及びその類義語のいずれかに対応するプレゼンスＩＤを、ユーザＡのプレゼンステーブルから特定する。類義語辞書や同義語辞書を用いて更新対象のプレゼンスＩＤを特定することにより、第３者が自由に指定した種別情報に対応可能なプレゼンスＩＤの幅が広がる。言い換えれば、他人のプレゼンスを更新しようとする第３者が、種別情報を指定する自由度が広がる。そして、指定された種別情報に対応するプレゼンスＩＤが存在しないと言う事態を防止しやすくなる。

類義語辞書や同義語辞書を用いることにより、更新依頼と同様に、第３者による種別情報を用いたサブスクライブや、第３者による種別情報を用いた転送依頼においても、指定された種別情報に対応するプレゼンスＩＤを特定する自由度を増すことができる。
なお、辞書ＤＢ２００に他の辞書、例えばプレゼンスシステム１００ｃ内で共通に使用する種別情報を記憶した共通辞書を蓄積しておいても良い。カードリーダや種別情報管理サーバ３０には、共通辞書で使用するいずれかの種別情報が記憶されている。このような構成により、更新依頼に含まれる種別情報に対応するプレゼンスＩＤが存在しないと言う事態を防止することができる。また、更新者であるカードリーダの種別情報に対応するプレゼンスＩＤが存在しないと言う事態を防止することができる。

＜第４実施形態＞
第４実施形態では、ユーザの行動に起因するプレゼンスの変化が予測される場合、その変化するプレゼンスと種別情報とをユーザが予め対応付けておく。これにより、第３者の更新依頼と共に通知される種別情報に対応するプレゼンスが存在しないと言う事態を防止する。ここでは一例として、ユーザＡがオンラインチケット販売システム上で飛行機のチケットを購入した場合を考える。

［システム全体の機能構成］
図２７は、第４実施形態に係るプレゼンスシステム１００ｄの概略構成図である。プレゼンスシステム１００ｄは、前記第１実施形態のプレゼンスシステム１００ａと同様、プレゼンスサーバ１０とプレゼンスクライアント２０がネットワークを介して接続されて構成されている。また、プレゼンスサーバ１０は、カードリーダ４７ａ、ｂ、ｃ、管理サーバ６０及びユーザ端末７０とネットワークを介して接続されている。３つのカードリーダ４７ａ，ｂ，ｃは、それぞれ空港入り口と、チェックイン入口と、搭乗口とに設置されている。プレゼンスシステム１００ｄは、種別情報管理サーバ３０を含んでいても良い。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。

［カードリーダ］
カードリーダ４７ａ，ｂ，ｃは、それぞれ同様の構成を示すので、カードリーダ４７ａについて説明する。カードリーダ４７ａは、種別リスト４７１ａを記憶し、読込部４７２ａ及びコマンド生成部４７３ａを有している。読込部４７２ａは、ＩＣカード（図１参照）上の情報を読み込む。読み込まれた情報及び種別リスト４７１ａに基づいて、コマンド生成部４７３ａが更新依頼を生成・送信する。

図２８（ａ）は、カードリーダ４７ａの種別リスト４７１ａの概念説明図を示す。種別リスト４７１ａには、更新者ＩＤと、プレゼンスと、種別情報とが記憶されている。更新者ＩＤは、プレゼンスシステム１００ｄ上でのカードリーダのユーザＩＤである。この情報に基づいて、カードリーダ４７ａは、下記の情報を含む更新依頼をプレゼンスサーバ１０に送信する。図２９は、この更新依頼の送信処理の流れを示す説明図である。

（更新依頼）
更新者ＩＤ“Ｘ１”
対象者ＩＤ“Ａ”
プレゼンス“空港入口”
種別情報“位置”
図２８（ｂ）は、カードリーダ４７ｂが有する種別リスト４７１ｂの概念説明図である。この種別リストに基づいて、カードリーダ４７ｂは、下記の情報を含む更新依頼をプレゼンスサーバ１０に送信する。

（更新依頼）
更新者ＩＤ“Ｘ２”
対象者ＩＤ“Ａ”
プレゼンス“チェックイン入口”
種別情報“手続き”
図２８（ｃ）は、カードリーダ４７ｃが有する種別リスト４７１ｃの概念説明図である。この種別リストに基づいて、カードリーダ４７ｃは、下記の情報を含む更新依頼をプレゼンスサーバ１０に送信する。

（更新依頼）
更新者ＩＤ“Ｘ３”
対象者ＩＤ“Ａ”
プレゼンス“搭乗口”
種別情報“手続き”
［管理サーバ］
管理サーバ６０は、チケット販売部６０１により、オンラインで飛行機のチケットを販売している。さらに管理サーバ６０のリスト送信部６０２は、購入されたチケットに応じ、そのチケットに対応する種別情報のリストを、ユーザ端末７０に送信する。リスト送信部６０２が送信する種別情報リストは、この例では各カードリーダ４７ａ，ｂ，ｃが記憶する種別情報を含む。種別情報リストは、ユーザ端末７０のディスプレイ上に表示される。

［ユーザ端末］
ユーザ端末７０は、プレゼンスクライアント２０に加え、チケット購入部７０１及び種別情報設定部７０２を有している。チケット購入部７０１は、管理サーバ６０からチケットをオンラインで購入する機能を有する。種別情報設定部７０２は、管理サーバ６０から受信した種別情報とプレゼンスＩＤとの対応付を、ユーザ端末７０の操作者に促す。また、種別情報設定部７０２は、種別情報とプレゼンスＩＤとの対応をプレゼンスサーバ１０に送信する。

図３０は、種別情報リスト通知画面の一例を示す。この画面は、種別情報設定部７０２により表示される。例えばこの画面上で管理サーバ６０から通知された種別情報リストが表示される。ユーザは、種別情報をドラッグ＆ドロップでプレゼンスＩＤに対応させる。
［システム全体の処理の流れ］
図３１は、プレゼンスシステム１００ｄ全体の処理の流れを示す説明図である。まず、ユーザ端末７０から管理サーバ６０に対し、チケットの購入依頼が送信される（＃１）。これに対し、種別情報リストが、管理サーバ６０からユーザ端末７０に返される。ついで、種別情報リスト中の種別情報とプレゼンスＩＤとの対応付が、ユーザ端末７０からプレゼンスサーバ１０に送信される（＃３）。プレゼンスサーバ１０の関連付設定部１３１は、この対応付を関連付テーブル１６に格納する。これにより、カードリーダの種別情報とユーザのプレゼンスＩＤとの対応が、プレゼンスサーバ１０内に記憶される。

この状態において、カードリーダ４７ａ，ｂ，ｃがユーザＡのＩＣカードを読み込むと（＃４）、更新依頼がプレゼンスサーバ１０に送信される。この更新依頼に基づいて、更新依頼中の種別情報に対応するプレゼンスが更新される。カードリーダの種別情報とユーザＡのプレゼンスＩＤとの対応付はプレゼンスサーバ１０に記憶されているので、更新依頼に対応するプレゼンスＩＤがないという事態を防ぎ、確実にプレゼンスを更新することができる。

＜第５実施形態＞
以下、第５〜第１１実施形態では、更新依頼やサブスクライブの設定、転送依頼など（以下、コマンドという）を、カードリーダまたはプレゼンスサーバで生成する方法について説明する。説明を容易にするために、以下の第５〜第１１実施形態では、トラックが集荷場ＣＰ１，ＣＰ２・・・を回って商品を集め、移送する場合を考える。トラックのユーザＩＤは“Ｔ”とする。また、商品のユーザＩＤは“Ｇ１”、“Ｇ２”、“Ｇ３”・・・とする。集荷場ＣＰ１，ＣＰ２には、カードリーダが設置されている。

［システム全体の機能構成］
図３２は、第５実施形態に係るプレゼンスシステム１００ｅの概略構成図である。プレゼンスシステム１００ｅは、プレゼンスサーバ１０ｅとプレゼンスクライアント２０とがネットワークを介して接続されて構成されている。プレゼンスシステム１００ｅは、種別情報管理サーバ３０を含んでいても良い。その場合、カードリーダ４０がＩＣカードから読み込む情報には種別情報は含まれていなくても良い。また、プレゼンスサーバ１０は、カードリーダ４０とネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。

［プレゼンスサーバ］
プレゼンスサーバ１０ｅは、第１実施形態におけるプレゼンスサーバ１０の構成に加え、転送処理部１４２及びサブスクライブ仲介部１４３を有していることが好ましい。転送依頼やサブスクライブ依頼のコマンドに対応することができるからである。また、転送依頼に従って転送を実行するために、プレゼンスサーバ１０ｅは置換処理部１３７を有していることが好ましい。

［カードリーダ］
カードリーダ４０は、読込部４０１と、履歴記憶部４０２と、第１判定部４０３と、コマンド生成部４０４とを有している。読込部４０１は、ＩＣカード（図１参照）上のユーザＩＤ及び種別情報を読み込む。履歴記憶部４０２は、読み込まれた情報の履歴を記憶する。第１判定部４０３は、履歴情報に基づいて、生成するコマンドの種類を決定する。また、第１判定部４０３は、転送依頼を生成する場合、転送元及び転送先を決定する。さらに第１判定部４０３は、サブスクライブ依頼を生成する場合、サブスクライビー及びサブスクライバーを決定する。コマンド生成部４０４は、第１判定部４０３の決定に基づいて、各種コマンドを生成する。

図３３は、履歴記憶部４０２が記憶する履歴情報の概念説明図である。履歴情報には以下の情報（ａ）〜（ｃ）が少なくとも含まれる。
（ａ）時刻：ＩＣカードからユーザＩＤや種別情報が読み込まれた時刻
（ｂ）ユーザＩＤ：読み込まれたＩＣカードに記録されているプレゼンスシステム１００ｅ上のユーザＩＤ
（ｃ）種別情報：読み込まれたＩＣカードに記録されている種別情報
［コマンド生成処理］
図３４は、カードリーダ４０が行うコマンド生成処理の流れの一例を示すフローチャートである。ここでは、集荷場ＣＰ１のカードリーダ“Ｘ”にまずトラック“Ｔ”のＩＣカードを通し、ついでそのトラック“Ｔ”に積み込む商品のＩＣカードを通すという前提でコマンド生成処理が行われる。

ステップＳ１〜Ｓ２：読込部４０１は、商品に付されたＩＣカードの情報を読み込むと（Ｓ１）、その情報を履歴情報として履歴記憶部４０２に格納する（Ｓ２）。例えば、時刻“15:20”、ユーザＩＤ“Ｇ２”、種別情報“位置”という履歴情報を、履歴情報部４０２に格納したとする（図３３参照）。以下では、この読み込んだ最新の履歴情報のエントリをカレントエントリと呼ぶ。

ステップＳ３：第１判定部４０３は、過去所定時間ΔＴ内の履歴情報を、履歴記憶部４０２から読み出す。例えば、図３３に示す履歴情報を読み出したとする。
ステップＳ４：第１判定部４０３は、カレントエントリ以外の他のエントリが過去ΔＴ内にあるか否かを判断する。図３３を参照すれば、例えばΔＴが３０分であれば、この場合は２つのエントリがある。

ステップＳ５：過去ΔＴ内のエントリがある場合、第１判定部はコマンドの種類を例えば“転送依頼”と決定する。また、第１判定部４０３は、ΔＴ内のエントリ中もっとも古いエントリのユーザＩＤを転送元と決定する。さらに第１判定部４０３は、最新のエントリのユーザＩＤを、転送先と決定する。この例では、転送元はトラック“Ｔ”となり、転送先は商品“Ｇ２”となる。

なお、必要に応じ、コマンド種別を“転送”ではなく“サブスクライブ”とすることもできる。その場合、履歴情報の時刻やユーザＩＤに基づいて、サブスクライバーやサブスクライビーを決定することができる。
コマンド生成部４０４は、第１判定部４０３の決定に従ってコマンドを生成し、プレゼンスサーバ１０ｅに送信する。コマンドに含める種別情報は、カードリーダが読み込んだ種別情報である。商品“Ｇ１”のＩＣカードを読み込んだときも同様の処理が行われる。図３５は、集荷場ＣＰ１のカードリーダ“Ｘ”がトラック“Ｔ”から商品“Ｇ１”への転送依頼を生成し、プレゼンスサーバ１０ｅに送信する処理の流れを示している。

ステップＳ６：過去ΔＴ内のエントリがカレントエントリ以外にない場合、第１判定部４０３はコマンドの種類を例えば“更新依頼”と決定する。また、第１判定部４０３は、更新対象のユーザＩＤ及び種別情報を、カレントエントリ内のユーザＩＤ及び種別情報と決定する。コマンド生成部４０４は、第１判定部４０３の決定に従ってコマンドを生成し、プレゼンスサーバ１０ｅに送信する。コマンドに含める種別情報は、カードリーダが読み込んだ種別情報である。図３６は、集荷場ＣＰ１のカードリーダ“Ｘ”がトラック“Ｔ”についての更新依頼を生成し、プレゼンスサーバ１０ｅに送信する処理の流れを示している。

なお、プレゼンスサーバ１０ｅが種別情報管理サーバ３０から種別情報を取得する場合、ＩＣカードから種別情報を読み出さなくても良い場合がある。
以上のようにして、カードリーダ４０が読み込んだ履歴情報に基づいて、生成しようとするコマンドの種別などを決定し、コマンドを自動的に生成することができる。
＜第６実施形態＞
第６実施形態では、更新依頼などのコマンドを、プレゼンスサーバ側で生成する方法について説明する。

［システム全体の機能構成］
図３７は、第６実施形態に係るプレゼンスシステム１００ｆの概略構成図である。このプレゼンスシステム１００ｆでは、カードリーダで読み込んだ情報に基づいて、プレゼンスサーバ１０内で更新依頼などのコマンドを生成する。
プレゼンスシステム１００ｆは、前記第５実施形態のプレゼンスシステム１００ｅと同様、プレゼンスサーバ１０ｆとプレゼンスクライアント２０とがネットワークを介して接続されて構成されている。プレゼンスシステム１００ｆは、種別情報管理サーバ３０を含んでいても良い。また、プレゼンスサーバ１０は、カードリーダ４１とネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。

［プレゼンスサーバ］
プレゼンスサーバ１０ｆは、前記第５実施形態のプレゼンスサーバ１０ｅの構成に加え、さらに以下の構成要素を含んでいる。
（ａ）readコマンド受信部１７：カードリーダ４１からのreadコマンドを受信し、後述する履歴記憶部１１０に履歴情報を格納する。履歴情報は、前記第５実施形態と同様の情報を含む。

（ｂ）第１判定部１８：前記第５実施形態のカードリーダ４０における第１判定部４０３と同様の機能を有する。すなわち、生成するコマンドの種類などを、履歴情報に基づいて決定する。
（ｃ）コマンド生成部１９：前記第５実施形態のカードリーダ４０におけるコマンド生成部４０４と同様の機能を有する。すなわち、コマンドを生成し、プレゼンス管理部１３またはウォッチャー管理部１４に通知する。

（ｄ）履歴記憶部１１０：readコマンドと共に受信した履歴情報を記憶する。
すなわち、プレゼンスサーバ１０ｆは、第５実施形態のプレゼンスサーバ１０に、カードリーダ４０の一部の構成を付加した構成を有している。このように構成されたプレゼンスサーバ１０ｆは、readコマンドに基づいて更新依頼などのコマンドを生成し、生成したコマンドに基づくプレゼンスの更新・転送・サブスクライブを行う。

［カードリーダの構成］
カードリーダ４１は、読込部４１１とreadコマンド生成部４１２とを有している。読込部４１１は、第５実施形態のカードリーダ４０の読込部４０１と同様、ＩＣカード（図１参照）上のユーザＩＤ及び種別情報を読み込む。readコマンド生成部４１２は、読み込んだ情報をプレゼンスサーバ１０ｆに送信する。

［コマンド生成処理］
図３８は、プレゼンスサーバ１０ｆが行うコマンド生成処理の流れの一例を示すフローチャートである。ここでは、第５実施形態と同様、集荷場ＣＰ１のカードリーダ“Ｘ”にまずトラック“Ｔ”のＩＣカードを通し、ついでそのトラック“Ｔ”に積み込む商品のＩＣカードを通すという前提でコマンド生成処理が行われる。

まず、カードリーダ４１の読込部４１１は、商品に付されたＩＣカードの情報を読み込むと（＃１１）、履歴情報を含むreadコマンドをプレゼンスサーバ１０ｆに送信する（＃１２）。
プレゼンスサーバ１０ｆのreadコマンド受信部１７は、readコマンドを受信すると（＃１３）、履歴情報、すなわちカレントエントリを履歴記憶部１１０に格納する（＃１４）。

さらに、第１判定部１８は、過去所定時間ΔＴ内の履歴情報を、履歴記憶部１１０から読み出す（＃１５）。
ついで、第１判定部１８は、カレントエントリ以外の他のエントリが過去ΔＴ内にあるか否かを判断する（＃１６）。
第１判定部１８は、過去ΔＴ内のエントリがカレントエントリ以外にもある場合、コマンドの種類を例えば“転送依頼”と決定する（＃１７）。また、第１判定部１８は、過去ΔＴ内のエントリ中もっとも古いエントリのユーザＩＤを転送元と決定する。さらに第１判定部１８は、最新のエントリのユーザＩＤを、転送先と決定する。なお、コマンド種別を転送ではなくサブスクライブとすることもできる。その場合、履歴情報の時刻やユーザＩＤに基づいて、サブスクライバーやサブスクライビーを決定することができる。

その後、コマンド生成部１９は、第１判定部１８の決定に従って転送依頼のコマンドを生成し、ウォッチャー管理部１４に通知する（＃１７）。コマンドに含める種別情報は、readコマンドに含まれる種別情報である。ウォッチャー管理部１４の転送処理部１４２は、この通知に基づいて転送設定を行う。図３９は、集荷場ＣＰ１のカードリーダ“Ｘ”からのreadコマンドに基づいて、プレゼンスサーバ１０ｆがトラック“Ｔ”から商品“Ｇ１”への転送依頼を生成し、転送設定する処理の流れを示している。

第１判定部１８は、過去ΔＴ内のエントリがカレントエントリ以外にない場合、コマンドの種類を例えば“更新依頼”と決定する（＃１８）。また、第１判定部１８は、更新対象のユーザＩＤ及び種別情報を、カレントエントリ内のユーザＩＤ及び種別情報と決定する。コマンド生成部１９は、第１判定部１８の決定に従って更新依頼を生成し、プレゼンス管理部１３に通知する。コマンドに含める種別情報は、readコマンドに含まれる種別情報である。プレゼンス管理部１３の設定部１３３は、受け取った更新依頼に基づいてプレゼンスの更新を行う。図４０は、集荷場ＣＰ１のカードリーダ“Ｘ”からのreadコマンドに基づいて、プレゼンスサーバ１０ｆがトラック“Ｔ”についての更新依頼を生成し、プレゼンスを設定する処理の流れを示している。

なお、コマンドの種類が“転送“ではなく“サブスクライブ”であってもよい。この場合、コマンド生成部１８はサブスクライブ依頼をウォッチャー管理部１４に通知する。ウォッチャー管理部１４のサブスクライブ仲介部１４３は、受け取ったサブスクライブ依頼に基づいて、ウォッチャーリストの更新を行う。
なお、種別情報管理サーバ３０が設けられている場合、コマンドに含める種別情報をプレゼンスサーバ１０ｆがそこから取得することもできる。

以上のようにして、カードリーダ４１が読み込んだ履歴情報に基づいて、プレゼンスサーバ１０ｆが生成しようとするコマンドの種別などを決定し、コマンドを自動的に生成することができる。
＜第７実施形態＞
図４１は、第７実施形態に係るプレゼンスシステム１００ｇの概略構成図である。プレゼンスシステム１００ｇは、プレゼンスサーバ１０ｇとプレゼンスクライアント２０とがネットワークを介して接続されて構成されている。プレゼンスシステム１００ｇは、種別情報管理サーバ３０を含んでいても良い。また、プレゼンスサーバ１０ｇは、カードリーダ４２とネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。プレゼンスサーバ１０ｇは、前記第５実施形態と同様の構成を有している。

［カードリーダ］
カードリーダ４２は、読込部４２１と、カテゴリ記憶部４２２と、第２判定部４２３と、コマンド生成部４２４とを有している。読込部４２１は、ＩＣカード（図１参照）上の情報を読み込む。カテゴリ記憶部４２２は、ユーザ−カテゴリテーブルと、カテゴリ−コマンドテーブルと、履歴テーブルとを記憶する。第２判定部４２３は、カテゴリ記憶部４２２内の情報に基づいて、生成するコマンドの種類を決定する。また、第２判定部４２３は、転送依頼を生成する場合、転送元及び転送先を決定する。さらに第２判定部４２３は、サブスクライブ依頼を生成する場合、サブスクライビー及びサブスクライバーを決定する。コマンド生成部４２４は、第２判定部４２３の決定に基づいて、各種コマンドを生成する。

図４２は、カテゴリ記憶部４２２内に記憶される情報の概念説明図である。同図（ａ）は、ユーザ−カテゴリテーブル４２２ａに蓄積される情報の概念説明図を示す。このテーブル４２２ａには、ユーザＩＤとそのユーザのカテゴリとが対応付けられている。例えば、トラックのユーザＩＤ“Ｔ”にはカテゴリ“トラック”が、商品のユーザＩＤ“Ｇ１”、“Ｇ２”にはカテゴリ“商品”が、それぞれ対応付けられている。

同図（ｂ）は、カテゴリ−コマンドテーブル４２２ｂに蓄積される情報の概念説明図を示す。このテーブル４２２ｂには、カテゴリとコマンド種類とが対応付けられている。カテゴリ“商品”には“転送依頼”が、カテゴリ“トラック”には“更新依頼”が、それぞれ対応付けられている。
ユーザ−カテゴリテーブル４２２ａとカテゴリ−コマンドテーブル４２２ｂとにより、ユーザＩＤとコマンド種類とを対応付けることができる。この２つのテーブル４２２ａ、４２２ｂは、予めカテゴリ記憶部４２２に記憶されている。

同図（ｃ）は、履歴テーブル４２２ｃに蓄積される履歴情報の概念説明図を示す。履歴情報には、時刻及びユーザＩＤが少なくとも含まれる。ここで、時刻は、ＩＣカードから情報が読み込まれた時刻である。ユーザＩＤは、読み込まれたＩＣカードに記録されているプレゼンスシステム１００ｇ上のユーザＩＤである。履歴情報は、カードリーダ４２がＩＣカードを読み込むたびに記憶される。

［コマンド生成処理］
図４３は、カードリーダ４２が実行するコマンド生成処理の流れの一例を示すフローチャートである。ここでは、集荷場ＣＰ１において複数のトラックに次々に商品が積み込まれる。１つのトラックに商品が積み込まれると１グループの積み込み処理が終了したと見なされる。１グループの積み込み処理終了後、所定時間以上あけた後で、次のグループの積み込み処理が開始される。

ステップＳ１１：カードリーダ４２の読込部４２１は、トラックまたは商品に付されたＩＣカードのユーザＩＤを読み込むと（Ｓ１１）、履歴情報をカテゴリ記憶部４２２に格納する（Ｓ１２）。例えば、時刻“15:10”、ユーザＩＤ“Ｇ３”という履歴情報を、履歴情報部４２２に格納したとする（図４２参照）。以下では、この読み込んだ最新の履歴情報のエントリをカレントエントリと呼ぶ。

ステップＳ１３：第２判定部４２３は、ユーザ−カテゴリテーブル４２２ａから、カレントエントリ内のユーザＩＤに対応するカテゴリを読み出す。
ステップＳ１４：第２判定部４２３は、カテゴリ−コマンドテーブル４２２ｂから、前記ユーザＩＤに対応するコマンド種類を読み出す。第２判定部４２３は、履歴情報中のユーザＩＤと、読み出したカテゴリと、それに対応するコマンド種別とを１レコードとして対応付け、図示しないバッファなどに一時的に記憶する。

ステップＳ１５：第２判定部４２３は、１グループの積み込み処理が終了したか否かを判断する。この判断は、例えば履歴テーブル４２２ｃを参照し、カレントエントリ内の時刻とその１つ前のエントリの時刻との間の時間が所定時間以上か否かにより行うことができる。具体的に、所定時間が５分であって、図４２（ｃ）の最後のエントリ“15:10，Ｇ３”がカレントエントリである場合を例にとる。この場合、その直前のエントリの時刻“15:02”との差が８分であるので、１グループの積み込み処理は終了したと判断される。

ステップＳ１６：１グループの積み込み処理が終了した場合、第２判定部４２３は、前記バッファに蓄積されている１グループの各レコード毎にコマンドを生成する。あるレコード中のコマンド種類が転送依頼の場合、例えば転送元を１グループ中のカテゴリ“トラック”で特定し、転送先をそのレコード中のユーザＩＤとすることができる。サブスクライブ依頼の生成についても同様に行うことができる。

ステップＳ１７：その後、生成されたコマンドは、コマンド生成部４２４によりプレゼンスサーバ１０ｇに次々に送信される。プレゼンスサーバ１０ｇは、コマンドに基づいてプレゼンスの更新や転送設定、サブスクライブ設定などを行う。
以上のように、ユーザＩＤとコマンドの種類とを間接的に対応付けておくことによりコマンドの種類を決定することができる。また、１つのグループ単位でコマンドを自動的に生成することにより、転送元やサブスクライビーを決定することができる。

なお、ユーザＩＤとコマンドの種類とを直接的に対応付け、それに基づいてコマンドの種類を決定することも可能である。
上記の処理で１グループ分の情報をバッファに記憶してからコマンドを生成するのは、１グループの中で転送元やサブスクライビーを特定するためである。こうすることで、例えばトラックのＩＣカードを、１グループの最初ではなく途中や最後に読み込むような態様にも対応することができる。ただし、前記第５実施形態のように、最初にトラックのＩＣカードを読み込むと決まっている場合などは、トラックを転送元に最初から特定可能であるので、ＩＣカードを読み込む毎にコマンドを生成・送信しても良い。

また上記の処理では、１グループの積み込み処理が終了したか否かを時間間隔で判断しているが、別の方法で判断しても良い。例えば、積み込んだ商品の個数や、明示の終了コマンドの入力の有無に基づいて判断することが考えられる。
さらに上記の処理において、ユーザＩＤから読み込んだ種別情報またはカードリーダ４２に対応する種別情報を、生成したコマンドに含めても良い。その場合には、種別情報付きの更新依頼、転送依頼、サブスクライブ依頼をプレゼンスサーバ１０ｇに送信することができる。

＜第８実施形態＞
図４４は、第８実施形態に係るプレゼンスシステム１００ｈの概略構成図である。このプレゼンスシステム１００ｈでは、カードリーダで読み込んだ情報に基づいて、プレゼンスサーバ内で更新依頼などのコマンドを生成する。
プレゼンスシステム１００ｈは、前記第７実施形態のプレゼンスシステム１００ｇと同様、プレゼンスサーバ１０ｈとプレゼンスクライアント２０とがネットワークを介して接続されて構成されている。プレゼンスシステム１００ｈは、種別情報管理サーバ３０を含んでいても良い。また、プレゼンスサーバ１０ｈは、カードリーダ４３とネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。

［プレゼンスサーバ］
プレゼンスサーバ１０ｈは、前記第７実施形態のプレゼンスサーバ１０ｇの構成に加え、さらに以下の構成要素を含んでいる。
（ａ）readコマンド受信部１１１：カードリーダ４３からのreadコマンドを受信し、後述するカテゴリ記憶部１１４に履歴情報を格納する。履歴情報は、前記第７実施形態と同様の情報を含む。

（ｂ）第２判定部１１２：前記第７実施形態のカードリーダ４２における第２判定部４２３と同様の機能を有する。すなわち、生成するコマンドの種類などを、履歴情報に基づいて決定する。
（ｃ）コマンド生成部１１３：前記第７実施形態のカードリーダ４２におけるコマンド生成部４２４と同様の機能を有する。すなわち、コマンドを生成し、プレゼンス管理部１３またはウォッチャー管理部１４に通知する。

（ｄ）カテゴリ記憶部１１４：前記第７実施形態のカテゴリ記憶部４２２と同様の情報を記憶する（前記図４２参照）。履歴情報は、カードリーダ４３からのreadコマンドと共に取得可能である。
すなわち、プレゼンスサーバ１０ｈは、第７実施形態のプレゼンスサーバ１０ｇに、カードリーダ４２の一部の構成を付加した構成を有している。このように構成されたプレゼンスサーバ１０ｈは、readコマンドに基づいて更新依頼などのコマンドを生成し、生成したコマンドに基づくプレゼンスの更新・転送・サブスクライブを行う。

［カードリーダ］
カードリーダ４３は、読込部４３１と、readコマンド生成部４３２とを有している。読込部４３１は、第７実施形態のカードリーダ４２の読込部４２１と同様、ＩＣカード（図１参照）上の情報を読み込む。readコマンド生成部４３２は、読み込んだ情報をプレゼンスサーバ１０ｈに送信する。

［コマンド生成処理］
以上のように構成されたプレゼンスシステムｈにおいては、プレゼンスサーバ１０ｈがreadコマンドに基づいてコマンドを生成し、プレゼンス管理部１３またはウォッチャー管理部１４に通知する。生成するコマンドの種類の判別、転送元や転送先の決定、サブスクライバーやサブスクライビーの決定は、前記第８実施形態の第２判定部４２３と同様にして第２判定部１１２が行う。

本実施形態では、プレゼンスサーバ１０ｈ側において、１つのグループ単位でコマンドを自動的に生成することができる。
＜第９実施形態＞
図４５は、第９実施形態に係るプレゼンスシステム１００ｉの概略構成図である。本実施形態では、カードリーダが更新依頼などのコマンドを自動的に生成し、プレゼンスサーバに送信する。

プレゼンスシステム１００ｉは、前記第５実施形態のプレゼンスシステム１００ｅと同様、プレゼンスサーバ１０ｉとプレゼンスクライアント２０とがネットワークを介して接続されて構成されている。プレゼンスシステム１００ｉは、種別情報管理サーバ３０を含んでいても良い。また、プレゼンスサーバ１０ｉは、カードリーダ４４とネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。プレゼンスサーバ１０ｉは、前記第５実施形態と同様の構成を有している。

［カードリーダ］
カードリーダ４４は、読込部４４１と、プレゼンス記憶部４４２と、第３判定部４４３と、コマンド生成部４４４とを有している。読込部４４１は、ＩＣカード（図１参照）上の情報を読み込む。プレゼンス記憶部４４２は、ユーザ−プレゼンステーブルと、プレゼンス−コマンドテーブルと、履歴テーブルとを記憶する。第３判定部４４３は、プレゼンス記憶部４４２内の情報に基づいて、生成するコマンドの種類を決定する。また、第３判定部４４３は、転送依頼を生成する場合、転送元及び転送先を決定する。さらに第３判定部４４３は、サブスクライブ依頼を生成する場合、サブスクライビー及びサブスクライバーを決定する。コマンド生成部４４４は、第３判定部４４３の決定に基づいて各種コマンドを生成し、プレゼンスサーバ１０ｉに送信する。

図４６は、カテゴリ記憶部４４２内に記憶される情報の概念説明図である。同図（ａ）は、ユーザ−プレゼンステーブル４４２ａに蓄積される情報の概念説明図を示す。このテーブル４４２ａには、ユーザＩＤとそのユーザに与えるプレゼンスとが対応付けられている。例えば、トラックのユーザＩＤ“Ｔ”にはプレゼンス“集荷場ＣＰ１”が、商品のユーザＩＤ“Ｇ１”、“Ｇ２”にはプレゼンス“商品”が、それぞれ対応付けられている。ここで、商品のプレゼンス“商品”は、ユーザのカテゴリを示すように設定されている。

図４６（ｂ）は、プレゼンス−コマンドテーブル４２２ｂに蓄積される情報の概念説明図を示す。このテーブル４２２ｂには、プレゼンスとコマンド種類とが対応付けられている。プレゼンス“集荷場ＣＰ１”には“更新依頼”が、プレゼンス“商品”には“転送依頼”が、それぞれ対応付けられている。
ユーザ−プレゼンステーブル４４２ａとプレゼンス−コマンドテーブル４４２ｂとにより、ユーザＩＤとコマンド種類とを対応付けることができる。この２つのテーブル４４２ａ、４４２ｂは、予めプレゼンス記憶部４４２に記憶されている。

図４６（ｃ）は、履歴テーブル４４２ｃに蓄積される履歴情報の概念説明図を示す。履歴情報には、時刻及びユーザＩＤが少なくとも含まれる。ここで、時刻は、ＩＣカードから情報が読み込まれた時刻である。ユーザＩＤは、読み込まれたＩＣカードに記録されているプレゼンスシステム１００ｉ上のユーザＩＤである。履歴情報は、カードリーダ４４がＩＣカードを読み込むたびに記憶される。

［コマンド生成処理］
図４７は、カードリーダ４４が実行するコマンド生成処理の流れの一例を示すフローチャートである。ここでは、集荷場ＣＰ１において複数のトラックに次々に商品が積み込まれる。１つのトラックに商品が積み込まれると１グループの積み込み処理が終了したと見なされる。１グループの積み込み処理終了後、所定時間以上あけた後で、次のグループの積み込み処理が開始される。

ステップＳ２１：カードリーダ４４の読込部４４１は、トラックまたは商品に付されたＩＣカードのユーザＩＤを読み込むと（Ｓ２１）、履歴情報をプレゼンス記憶部４４２に格納する（Ｓ２２）。例えば、時刻“15:10”、ユーザＩＤ“Ｇ３”という履歴情報を、履歴情報部４４２に格納したとする（図４６参照）。以下では、この読み込んだ最新の履歴情報のエントリをカレントエントリと呼ぶ。

ステップＳ２３：第３判定部４４３は、ユーザ−プレゼンステーブル４４２ａから、カレントエントリ内のユーザＩＤに対応するプレゼンスを読み出す。
ステップＳ２４：第３判定部４４３は、プレゼンス−コマンドテーブル４４２ｂから、前記ユーザＩＤに対応するコマンド種類を読み出す。第３判定部４４３は、履歴情報中のユーザＩＤと、読み出したプレゼンスと、それに対応するコマンド種別とを１レコードとして対応付け、図示しないバッファなどに一時的に記憶する。

ステップＳ２５：第３判定部４４３は、１グループの積み込み処理が終了したか否かを判断する。この判断は、例えば履歴テーブル４４２ｃを参照し、カレントエントリ内の時刻とその１つ前のエントリの時刻との間の時間が所定時間以上か否かにより行うことができる。この判断は、前記第７実施形態と同様である。
ステップＳ２６：１グループの積み込み処理が終了した場合、第３判定部４４３は、前記バッファに蓄積されている１グループの各レコード毎にコマンドを生成する。あるレコード中のコマンド種類が転送依頼の場合、例えば転送元をプレゼンス“集荷場ＣＰ１”で特定し、転送先をそのレコード中のユーザＩＤとすることができる。サブスクライブ依頼の生成についても同様に行うことができる。

ステップＳ２７：その後、生成された１グループ分のコマンドは、コマンド生成部４４４によりプレゼンスサーバ１０ｉに次々に送信される。プレゼンスサーバ１０ｉは、コマンドに基づいてプレゼンスの更新や転送設定、サブスクライブ設定などを行う。
以上の処理により、前記第７実施形態とは別の方法により、カードリーダ４４が１つのグループ単位でコマンドを自動的に生成することができる。

なお、上記の処理で１グループ分の情報をバッファに記憶してからコマンドを生成するのは、１グループの中で転送元やサブスクライビーを特定するためである。この点は第７実施形態と同様である。こうすることで、例えばトラックのＩＣカードを、１グループの最初ではなく途中や最後に読み込むような態様にも対応することができる。ただし、前記第５実施形態のように、最初にトラックのＩＣカードを読み込むと決まっている場合などは、トラックを転送元に最初から特定可能であるので、ＩＣカードを読み込む毎にコマンドを生成・送信しても良い。

また上記の処理では、１グループの積み込み処理が終了したか否かを時間間隔で判断しているが、別の方法で判断しても良いのは前記第７実施形態と同様である。例えば、積み込んだ商品の個数や、明示の終了コマンドの入力の有無に基づいて判断することが考えられる。
さらに上記の処理において、ユーザＩＤから読み込んだ種別情報またはカードリーダ４２に対応する種別情報を、生成したコマンドに含めても良い。その場合には、種別情報付きの更新依頼、転送依頼、サブスクライブ依頼がプレゼンスサーバ１０ｇに送信されることになる。

＜第１０実施形態＞
図４８は、第１０実施形態に係るプレゼンスシステム１００ｊの概略構成図である。このプレゼンスシステム１００ｊでは、カードリーダで読み込んだ情報に基づいて、プレゼンスサーバ内で更新依頼などのコマンドを生成する。
プレゼンスシステム１００ｊは、前記第９実施形態のプレゼンスシステム１００ｉと同様、プレゼンスサーバ１０ｊとプレゼンスクライアント２０とがネットワークを介して接続されて構成されている。プレゼンスシステム１００ｊは、種別情報管理サーバ３０を含んでいても良い。また、プレゼンスサーバ１０ｊは、カードリーダ４５とネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。

［プレゼンスサーバ］
プレゼンスサーバ１０ｊは、前記第９実施形態のプレゼンスサーバ１０ｊの構成に加え、さらに以下の構成要素を含んでいる。
（ａ）readコマンド受信部１１５：カードリーダ４５からのreadコマンドを受信し、後述するプレゼンス記憶部１１８に履歴情報を格納する。履歴情報は、前記第９実施形態と同様の情報を含む。

（ｂ）第３判定部１１６：前記第９実施形態のカードリーダ４５における第３判定部４４３と同様の機能を有する。すなわち、生成するコマンドの種類などを、後述するプレゼンス記憶部１１８内の情報に基づいて決定する。
（ｃ）コマンド生成部１１７：前記第９実施形態のカードリーダ４５におけるコマンド生成部４４４と同様の機能を有する。すなわち、コマンドを生成し、プレゼンス管理部１３またはウォッチャー管理部１４に通知する。

（ｄ）プレゼンス記憶部１１８：前記第９実施形態のプレゼンス記憶部４４２と同様の情報を記憶する（前記図４６参照）。履歴情報は、カードリーダ４５からのreadコマンドと共に取得可能である。
すなわち、プレゼンスサーバ１０ｊは、第９実施形態のプレゼンスサーバ１０ｉに、カードリーダ４４の一部の構成を付加した構成を有している。このように構成されたプレゼンスサーバ１０ｊは、readコマンドに基づいて更新依頼などのコマンドを生成し、生成したコマンドに基づくプレゼンスの更新・転送・サブスクライブを行う。

［カードリーダ］
カードリーダ４５は、読込部４５１と、readコマンド生成部４５２とを有している。読込部４５１は、第９実施形態のカードリーダ４４の読込部４４１と同様、ＩＣカード（図１参照）上の情報を読み込む。readコマンド生成部４５２は、読み込んだ情報をプレゼンスサーバ１０ｊに送信する。

［コマンド生成処理］
以上のように構成されたプレゼンスシステムｊにおいては、プレゼンスサーバ１０ｊがreadコマンドに基づいてコマンドを生成し、プレゼンス管理部１３またはウォッチャー管理部１４に通知する。生成するコマンドの種類の判別、転送元や転送先の決定、サブスクライバーやサブスクライビーの決定は、前記第９実施形態の第３判定部４４３と同様にして第３判定部１１６が行う。

本実施形態では、プレゼンスサーバ１０ｊ側において、１つのグループ単位でコマンドを自動的に生成することができる。
＜第１１実施形態＞
図４９は、第１１実施形態に係るプレゼンスシステム１００ｋの概略構成図である。本実施形態では、カードリーダが転送依頼または転送解除依頼のコマンドを自動的に生成し、プレゼンスサーバに送信する。

プレゼンスシステム１００ｋは、プレゼンスサーバ１０ｋとプレゼンスクライアント２０とがネットワークを介して接続されて構成されている。プレゼンスシステム１００ｋは、種別情報管理サーバ３０を含んでいても良い。また、プレゼンスサーバ１０ｋは、カードリーダ４４とネットワークを介して接続されている。図中、第１実施形態と同様の機能を持つ構成要素については、同一の符号番号を付して示している。プレゼンスサーバ１０ｋは、前記第５実施形態と同様の構成を有している。

［カードリーダ］
カードリーダ４６は、読込部４６１と、第４判定部４６２と、コマンド生成部４６３とを有している。読込部４５１は、ＩＣカード（図１参照）上のユーザＩＤを読み込む。
第４判定部４６２は、前記ユーザＩＤ及びカードリーダの種別情報に対応するプレゼンスをプレゼンスサーバ１０ｋから取得する。第４判定部４６２は、取得したプレゼンスに基づいて転送依頼または転送解除依頼のいずれかを生成するか決定する。さらに、第４判定部４６２は、転送依頼を生成する場合、転送元及び転送先を決定する。この決定方法としては、前記第５〜１０実施形態で記載した方法を用いることができる。

コマンド生成部４６３は、第４判定部４６２の決定に基づいて、転送依頼または転送解除依頼のコマンドを生成し、プレゼンスサーバ１０ｋに送信する。これを受けたプレゼンスサーバ１０ｋのウォッチャー管理部１４は、転送処理部１４２により転送設定または転送設定の解除を行う。
［コマンド生成処理］
図５０は、カードリーダ４６が実行するコマンド生成処理の流れの一例を示すフローチャートである。

ステップＳ３１：カードリーダ４６の読込部４６１は、トラックまたは商品に付されたＩＣカードから少なくともユーザＩＤを読み込む。
ステップＳ３２：第４判定部４６２は、読み込んだユーザＩＤとカードリーダ４６内に記憶する種別情報とに対応するプレゼンスを、プレゼンスサーバ１０ｋから取得する。さらに第４判定部４６２は、前記ユーザＩＤ及び種別情報に対応するプレゼンスＩＤを特定し、そのプレゼンスＩＤに転送元が設定されているか否かを判断する。

プレゼンスの記憶形態によっては、必要に応じて、ユーザＩＤに基づいて当該ユーザＩＤのプレゼンスに対応付けて記憶されている転送元情報を取得するようにしても良い。
ステップＳ３３：転送元が設定されている場合、第４判定部４６２はコマンド種類を“転送解除“と決定する。その後、コマンド生成部４６３は、転送解除依頼コマンドを生成し、プレゼンスサーバ１０ｋに送信する。このコマンドにはユーザＩＤ及びプレゼンスＩＤが含まれる。これを受信したプレゼンスサーバ１０ｋの転送処理部１４２は、ユーザＩＤ及びプレゼンスＩＤで特定されるプレゼンス転送設定を解除する。

ステップＳ３４：第４判定部４６２が特定したプレゼンスＩＤに転送元が設定されていない場合、第４判定部４６２はコマンド種類を“転送依頼“と決定する。転送元は、前記第５〜１０に述べた方法で決定することができる。その後、コマンド生成部４６３は、転送依頼コマンドを生成し、プレゼンスサーバ１０ｋに送信する。
以上の処理により、カードリーダ４６において転送依頼または転送解除依頼のコマンドを生成し、プレゼンスサーバ１０ｋに送信することができる。同様にして、プレゼンスに既にウォッチャーが設定されているか否かにより、サブスクライブコマンドまたはサブスクライブ解除コマンドを生成することもできる。

なお、プレゼンスサーバ１０ｋに第４判定部４６２の機能を設け、プレゼンスサーバ１０ｋ側で転送依頼または転送解除依頼のコマンドを生成することもできる。この場合、カードリーダ４６が読み込んだユーザＩＤ及び種別情報をプレゼンスサーバ１０ｋに送信すればよい。種別情報管理サーバ３０が存在する場合には、種別情報をそちらから取得することもできる。

＜その他の実施形態＞
（Ａ）上記実施形態は、必要に応じ適宜組み合わせて用いることができる
（Ｂ）上記の方法を実行するためのプログラム及びそのプログラムを記録したコンピュータ読み取り可能な記録媒体は、本発明の範囲に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、光磁気ディスク（ＭＯ）、その他のものが挙げられる。

＜付記＞
以上の実施形態に関し、更に以下の付記を開示する。
（付記１）
ユーザを特定するユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンスシステムであって、
プレゼンスの所有者以外のユーザである更新者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスを所有する更新対象者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスと、を含む更新依頼を受け付ける受付手段と、
プレゼンスの内容の種別を表す種別情報であって、前記更新者に対応付けられた種別情報を取得する種別取得手段と、
前記更新対象者の各プレゼンスの識別子と種別情報との関連付けを記憶する関連付テーブルと、
前記関連付テーブルを参照し、前記更新者に対応する種別情報に関連付けられたプレゼンス識別子を特定するプレゼンス特定手段と、
前記特定したプレゼンス識別子に対し、前記更新依頼に含まれていたプレゼンスを設定するプレゼンス設定手段と、
を備えるプレゼンスシステム。
更新者は、第３者のプレゼンスを更新する際に、その第３者のプレゼンス全体の構成や各プレゼンス識別子を予め知る必要がない。従って、更新者の更新処理に要する手間を軽減することができる。また、更新者にプレゼンスを更新される更新対象者は、自分のプレゼンスの構成などを更新者に公開せずにすむ。従って、更新対象者のプライバシーを保護することができる。

（付記２）
前記更新依頼は前記種別情報をさらに含み、
前記種別取得手段は、前記受付手段から前記種別情報を取得する、付記１に記載のプレゼンスシステム。
更新者が種別情報を指定して更新依頼を送信すると、その種別情報に関連付けられたプレゼンス識別子に対してプレゼンスが設定される。例えば、更新者Ｘ、更新対象者Ａ、種別情報「位置」、プレゼンス「会議室」を送信する。すると、ユーザＡのプレゼンスのうち、種別情報「位置」に関連付けられたプレゼンス識別子ａ１のプレゼンスが「会議室」に更新される。つまり、更新者が指定する種別情報に対応するプレゼンス識別子がある限り、更新者は自由に種別情報を指定して更新依頼を送信できる。

（付記３）
前記種別情報と前記更新者のユーザ識別子とを対応付けて記憶する種別情報管理テーブルを記憶する種別情報管理手段をさらに有し、
前記種別取得手段は、前記種別情報管理手段から前記更新者に対応する種別情報を取得する、
付記１に記載のプレゼンスシステム。
種別情報管理手段は、プレゼンスサーバの内部または外部に設けられる。種別情報管理手段が記憶している情報を参照することで、更新者がどの種別情報に対応するプレゼンスを更新したいのかを特定することができる。

（付記４）
前記更新依頼に含まれるプレゼンスを別のプレゼンスに変換する変換ルールを記憶する変換ルールテーブルと、
前記更新依頼に含まれているプレゼンスを、前記変換ルールに従って変換する変換手段と、
をさらに備える付記１に記載のプレゼンスシステム。
変換ルールを用いてプレゼンスを変換することにより、更新者にとって理解可能なプレゼンスを更新設定者のウォッチャーにとって分かりやすいプレゼンスに変更することができる。例えば、プレゼンスの所有者である更新設定者が荷物Ａであるとする。更新者は運送業者であるとする。運送業者が設定するプレゼンス「集荷店舗ＩＤ」を「集荷済」に変換することにより、荷物Ａのプレゼンスのウォッチャーは荷物Ａの状態を把握しやすくなる。

（付記５）
各ユーザのプレゼンスのプレゼンス識別子、種別情報及びプレゼンスと対応付けて記憶する種別付プレゼンステーブルと、
各ユーザのプレゼンス識別子毎に、プレゼンスを参照するウォッチャーを記憶するウォッチャーリストと、
サブスクライバーが購読したいプレゼンスに対応する種別情報、前記サブスクライバーのユーザ識別子、サブスクライビーのユーザ識別子を含むサブスクライブを受信する第１サブスクライブ受信手段と、
種別付プレゼンステーブルを検索して、前記サブスクライブに含まれるサブスクライビーのユーザ識別子及び種別情報に対応するプレゼンス識別子を特定し、当該プレゼンス識別子のウォッチャーリストに前記サブスライバーのユーザの識別子を登録する登録手段と、
を備えるプレゼンスシステム。
サブスクライバーは、種別情報を指定してサブスクライブを送信するので、サブスクライビーのプレゼンスの構成や各プレゼンス識別子を予め調べなくても良い。従って、サブスクライバーは、手軽にサブスクライブを行うことができる。

（付記６）
各ユーザのプレゼンスの公開条件を、プレゼンス識別子、種別情報及びプレゼンスと対応付けて記憶する種別付プレゼンステーブルと、
各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶するウォッチャーリストと、
サブスクライバーが購読したいプレゼンスに対応する種別情報、前記サブスクライバーのユーザ識別子、サブスクライビーのユーザ識別子を含むサブスクライブを受信する第１サブスクライブ受信手段と、
前記サブスクライビーのプレゼンスの公開条件のうち、前記サブスクライブに含まれる種別情報に対応するプレゼンスの公開条件を前記サブスクライバーが満たしているか否かを判断し、満たしていれば前記サブスクライバーを前記サブスクライビーのウォッチャーリストに登録する公開判定手段と、
を備えるプレゼンスシステム。
サブスクライバーは、種別情報を指定してサブスクライブを送信するので、サブスクライビーのプレゼンスの構成や各プレゼンス識別子を予め調べなくても良い。従って、サブスクライバーは、手軽にサブスクライブを行うことができる。

（付記７）
前記第１サブスクライブ受信手段は、サブスクライバーのユーザの識別子と種別情報とを対応づけて記憶している種別情報管理テーブルを参照して、前記サブスクライバーのユーザの識別子に対応づけられている種別情報を取得する種別情報取得手段を備える、付記５ないし付記６に記載のプレゼンスシステム。
プレゼンスシステムは、ユーザのプレゼンスを管理するプレゼンスサーバと、プレゼンスの更新通知や参照要求をプレゼンスサーバに送信するプレゼンスクライアントとを含む。種別情報管理手段は、プレゼンスサーバの内部または外部に設けられる。種別情報管理手段が記憶している情報を参照することで、サブスクライバーがどの種別情報に対応するプレゼンスを参照したいのかを特定することができる。

（付記８）
各ユーザのプレゼンスを、プレゼンス識別子及び種別情報と対応付けて記憶する第１プレゼンステーブルと、
各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶する第１ウォッチャーリストと、
プレゼンスの転送元のユーザ識別子と、前記プレゼンスの転送先のユーザ識別子と、前記プレゼンスの転送に対応付けられた種別情報と、を含む転送依頼を受信する第１転送依頼受信手段と、
前記転送依頼の受信に応じ、前記転送先をサブスクライバーとし、前記転送元をサブスクライビーとし、前記転送依頼中の種別情報を含むサブスクライブを生成する第１サブスクライブ生成手段と、
前記サブスクライブに基づいて、前記転送元のウォッチャーリストに、前記転送先のユーザ識別子及び前記転送依頼中の種別情報を対応付けて登録する第１ウォッチャー登録手段と、
前記転送元のプレゼンスが更新された場合、前記転送先に対し、前記転送依頼に含まれる前記種別情報と前記転送元のプレゼンスとを通知する種別情報付通知手段と、
を含むプレゼンスシステム。
転送先に転送元のプレゼンスを通知するときに、種別情報を同時に通知することができる。従って、転送依頼者は、転送元からのプレゼンスを転送先のどのプレゼンスに反映させたいかを、種別情報により指定することができる。すなわち、転送によるプレゼンスの自動更新の仕組みを、必要に応じて自由に変えることができる。

（付記９）
前記第１プレゼンステーブルは、プレゼンスの公開条件をさらに記憶し、
前記種別情報付通知手段は、前記転送先のプレゼンスのうち前記転送依頼に含まれる種別情報と対応するプレゼンスの公開条件に、前記転送元の公開条件を設定する、
付記８に記載のプレゼンスシステム。
種別情報を用いて転送したいプレゼンスの種別を指定すると、その種別情報に対応する転送元のプレゼンスの公開条件が、その種別情報に対応する転送先のプレゼンスの公開条件として設定される。従って、種別情報を用いた転送依頼により、転送元のプライバシーを簡単に保護することができる。

（付記１０）
前記種別情報付通知手段は、前記転送元のプレゼンスの公開条件が変化した場合、前記転送先のプレゼンスのうち前記転送依頼に含まれる種別情報に対応するプレゼンスの公開条件に、前記転送元の公開条件の変化を反映させる、付記９に記載のプレゼンスシステム。
転送元の公開条件を種別情報を用いて転送先の公開条件に設定した後、転送元の公開条件の変化を転送先にも反映させる。従って、転送元の公開条件が変化しても、転送元のプライバシーを動的に保護することができる。

（付記１１）
前記第１転送依頼受信手段は、サブスクライバーのユーザの識別子と種別情報とを対応づけて記憶している種別情報管理テーブルを参照して、前記サブスクライバーのユーザの識別子に対応づけられている種別情報を取得する種別情報取得手段を備える、付記８ないし付記１０に記載のプレゼンスシステム。
プレゼンスシステムは、ユーザのプレゼンスを管理するプレゼンスサーバと、プレゼンスの更新通知や参照要求をプレゼンスサーバに送信するプレゼンスクライアントとを含む。種別情報管理手段は、プレゼンスサーバの内部または外部に設けられる。種別情報管理手段が記憶している情報を参照することで、転送依頼者がどの種別情報に対応するプレゼンスの転送を依頼しているのかを特定することができる。

（付記１２）
各ユーザのプレゼンスを、プレゼンス識別子及び前記プレゼンスの公開条件と対応付けて記憶する第２プレゼンステーブルと、
各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶する第２ウォッチャーリストと、
プレゼンスの転送元のユーザ識別子と、前記プレゼンスの転送先のユーザ識別子と、を含む転送依頼を受信する第２転送依頼受信手段と、
前記転送依頼の受信に応じ、前記転送先をサブスクライバーとし、前記転送元をサブスクライビーとし、前記転送先のウォッチャーリストを含むサブスクライブを生成する第２サブスクライブ生成手段と、
前記サブスクライブに基づいて、前記転送元のプレゼンスのうちその公開条件を前記転送先が満たすプレゼンスを前記プレゼンステーブルから検索し、検索したプレゼンスのウォッチャーリストに、前記転送先のユーザ識別子を登録する第２ウォッチャー登録手段と、
をさらに含む、付記８に記載のプレゼンスシステム。
転送元Ａが自分のプレゼンスの配信を許可している範囲内で、その転送元のプレゼンスの転送を行う。従って、転送元のプライバシーを保護することができる。

（付記１３）
各ユーザのプレゼンスを、プレゼンス識別子及び前記プレゼンスの公開条件と対応付けて記憶する第３プレゼンステーブルと、
各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶する第３ウォッチャーリストと、
プレゼンスの転送元のユーザ識別子と、前記プレゼンスの転送先のユーザ識別子と、を含む転送依頼を受信する第３転送依頼受信手段と、
前記転送依頼の受信に応じ、前記転送先をサブスクライバーとし、前記転送元をサブスクライビーとし、前記転送先の公開条件を含むサブスクライブを生成する第３サブスクライブ生成手段と、
前記サブスクライブに基づいて、前記転送元のプレゼンスのうちその公開条件を前記転送先が満たすプレゼンスを前記プレゼンステーブルから検索し、検索したプレゼンスのウォッチャーリストに前記転送先のユーザ識別子を登録する第３ウォッチャー登録手段と、
をさらに含む、付記８に記載のプレゼンスシステム。
この構成により、転送先と転送元との両方の公開条件が満たされる範囲での転送が可能となる。転送依頼者は、転送元や転送先のプレゼンスの構成やプライバシーへの配慮を気にせずに転送依頼を行うことができる。

（付記１４）
前記第３ウォッチャー登録手段は、前記転送先のプレゼンスの公開条件が変化した場合、前記転送先の公開条件に基づいて、前記ウォッチャーリストの登録内容を変更する、付記１３に記載のプレゼンスシステム。
転送先の公開条件が変化すると、転送元と転送先の公開条件が一致する範囲が変化する可能性がある。その場合には、転送されるプレゼンスのウォッチャーリストの見直しを行うことで、転送元のプライバシーを保護することができる。

（付記１５）
各ユーザのプレゼンスを、プレゼンス識別子、前記プレゼンスの公開条件及び前記プレゼンスの転送元と対応付けて記憶する公開条件付プレゼンステーブルと、
各ユーザのプレゼンス毎に、プレゼンスを参照するウォッチャーを記憶するウォッチャーリストと、
サブスクライバーのユーザ識別子と、サブスクライビーのユーザ識別子と、を含むサブスクライブを受信する第２サブスクライブ受信手段と、
前記サブスクライビーのプレゼンスの転送元に対するサブスクライブであって、前記サブスクライバーのユーザ識別子、前記サブスクライビーのユーザ識別子及び前記転送元のユーザ識別子を含むサブスクライブを生成する間接サブスクライブ生成手段と、
前記転送元のプレゼンスのうち前記サブスクライバーがその公開条件を満たしているプレゼンスであって前記サブスクライビーをウォッチャーリストに含むプレゼンスを、前記公開条件付プレゼンステーブルから検索し、検索結果に基づいて前記サブスクライビーのウォッチャーリストに前記サブスクライバーを登録する間接サブスクライブ手段と、
を備えるプレゼンスシステム。
例えばサブスクライバーＹ、サブスクライビーＢのサブスクライブを受信したとする。サブスクライビーＢのプレゼンスは、転送元のユーザＡから転送される。ユーザＡのプレゼンス“ａ１”のウォッチャーリストにサブスクライビーＢが含まれているとする。しかも、プレゼンス“ａ１”の公開条件がサブスクライバーＹへのプレゼンスの公開を許可しているとする。この場合、サブスクライブにより、転送元Ａから転送先Ｂへ、転送先ＢからサブスクライバーＹへ、転送元Ａのプレゼンス“ａ１”が送信される。従って、サブスクライバーＹ、サブスクライビーＢのサブスクライブにより、サブスクライバーＹはサブスクライビーのウォッチャーリストに登録される。この登録は、結局、転送元のユーザＡの公開条件の範囲内でサブスクライバーＢのウォッチャーを追加する。

（付記１６）
ユーザを特定するユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンス管理方法であって、
プレゼンスの所有者以外のユーザである更新者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスを所有する更新対象者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスと、を含む更新依頼を受け付ける受付ステップと、
プレゼンスの内容の種別を表す種別情報であって、前記更新者に対応付けられた種別情報を取得する種別取得ステップと、
前記更新対象者の各プレゼンスの識別子と種別情報との関連付けを記憶する関連付テーブルを記憶する関連付記憶ステップと、
前記関連付テーブルを参照し、前記更新者に対応する種別情報に関連付けられたプレゼンス識別子を特定するプレゼンス特定ステップと、
前記特定したプレゼンス識別子に対し、前記更新依頼に含まれていたプレゼンスを設定するプレゼンス設定ステップと、
を含むプレゼンス方法。

（付記１７）
ユーザを特定するユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンス管理プログラムを記録した、コンピュータ読み取り可能な記録媒体であって、
プレゼンスの所有者以外のユーザである更新者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスを所有する更新対象者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスと、を含む更新依頼を受け付ける受付ステップと、
プレゼンスの内容の種別を表す種別情報であって、前記更新者に対応付けられた種別情報を取得する種別取得ステップと、
前記更新対象者の各プレゼンスの識別子と種別情報との関連付けを記憶する関連付テーブルを記憶する関連付記憶ステップと、
前記関連付テーブルを参照し、前記更新者に対応する種別情報に関連付けられたプレゼンス識別子を特定するプレゼンス特定ステップと、
前記特定したプレゼンス識別子に対し、前記更新依頼に含まれていたプレゼンスを設定するプレゼンス設定ステップと、
を実行するためのプレゼンス管理プログラムを記録した、コンピュータ読み取り可能な記録媒体。

（付記１８）
ユーザを特定するユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンス管理プログラムであって、
プレゼンスの所有者以外のユーザである更新者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスを所有する更新対象者のユーザ識別子と、前記更新者が設定しようとしているプレゼンスと、を含む更新依頼を受け付ける受付手段、
プレゼンスの内容の種別を表す種別情報であって、前記更新者に対応付けられた種別情報を取得する種別取得手段、
前記更新対象者の各プレゼンスの識別子と種別情報との関連付けを記憶する関連付テーブル、
前記関連付テーブルを参照し、前記更新者に対応する種別情報に関連付けられたプレゼンス識別子を特定するプレゼンス特定手段、及び
前記特定したプレゼンス識別子に対し、前記更新依頼に含まれていたプレゼンスを設定するプレゼンス設定手段、
としてコンピュータを機能させるプレゼンスプログラム。

（付記１９）
前記更新者のユーザ識別子と、前記更新者に対応付けられた種別情報と、を記憶する依頼者記憶手段と、
前記受付手段が前記更新依頼を受け付ける前に、前記更新者に対応付けられた種別情報を、前記更新対象者に通知する種別情報通知手段と、
前記更新対象者の各プレゼンスの識別子と、前記更新者に対応付けられた種別情報と、の関連付を受け付け、前記関連付テーブルに格納する関連付受付手段と、
をさらに有する、付記１に記載のプレゼンスシステム。
例えば更新者がカードリーダの場合を例にとる。カードリーダのユーザ識別子とカードリーダの種別情報とは、カードリーダ内に記憶されている。更新対象者が使用するであろうカードリーダの種別情報を予め更新対象者に通知し、更新対象者に自分のプレゼンスＩＤとの関連付を生成させる。これにより、カードリーダが種別情報付き更新依頼をプレゼンスサーバに送信した時には、種別情報に対応するプレゼンスＩＤが確実に存在するようになる。

（付記２０）
前記サブスクライバーのユーザ識別子と、前記サブスクライバーに対応付けられた種別情報と、を記憶する依頼者記憶手段と、
前記第１サブスクライブ受信手段が前記サブスクライブを受信する前に、前記サブスクライバーに対応付けられた種別情報を、前記サブスクライビーに通知する種別情報通知手段と、
前記サブスクライビーの各プレゼンスの識別子と、前記サブスクライバーに対応付けられた種別情報と、の関連付けを受け付け、前記種別付プレゼンステーブルに格納する関連付受付手段と、をさらに有し、
前記登録手段は、前記サブスクライビーの各プレゼンスの識別子と前記サブスクライバーに対応付けられた種別情報との関連付けに基づいて、前記当該プレゼンス識別子を特定する、付記５に記載のプレゼンスシステム。
例えばサブスクライバーがカードリーダの場合を例にとる。カードリーダのユーザ識別子とカードリーダの種別情報とは、カードリーダ内に記憶されている。サブスクライビーが使用するであろうカードリーダの種別情報を予めサブスクライビーに通知し、サブスクライビーに自分のプレゼンスＩＤとの関連付を生成させる。これにより、カードリーダが種別情報付きサブスクライブをプレゼンスサーバに送信した時には、種別情報に対応するプレゼンスＩＤが確実に存在するようになる。

（付記２１）
前記サブスクライバーのユーザ識別子と、前記サブスクライバーに対応付けられた種別情報と、を記憶する依頼者記憶手段と、
前記第１サブスクライブ受信手段が前記サブスクライブを受信する前に、前記サブスクライバーに対応付けられた種別情報を、前記サブスクライビーに通知する種別情報通知手段と、
前記サブスクライビーの各プレゼンスの識別子と、前記サブスクライバーに対応付けられた種別情報と、の関連付けを受け付け、前記種別付プレゼンステーブルに格納する関連付受付手段と、をさらに有し、
前記公開判定手段は、前記サブスクライビーの各プレゼンスの識別子と前記サブスクライバーに対応付けられた種別情報との関連付けに基づいて、前記サブスクライブに含まれる種別情報に対応する前記サブスクライビーのプレゼンス識別子を特定し、そのプレゼンス識別子に対応する公開条件を前記サブスクライバーが満たしていれば前記サブスクライバーをウォッチャーリストに登録する、付記６に記載のプレゼンスシステム。
例えばサブスクライバーがカードリーダの場合を例にとる。カードリーダのユーザ識別子とカードリーダの種別情報とは、カードリーダ内に記憶されている。サブスクライビーが使用するであろうカードリーダの種別情報を予めサブスクライビーに通知し、サブスクライビーに自分のプレゼンスＩＤとの関連付を生成させる。これにより、カードリーダが種別情報付きサブスクライブをプレゼンスサーバに送信した時には、種別情報に対応するプレゼンスＩＤが確実に存在するようになる。従って、サブスクライビーの公開条件をサブスクライバーが満たしていれば、サブスクライバーはサブスクライビーのウォッチャーリストに登録される。

（付記２２）
前記転送先のユーザ識別子と、前記転送先に対応付けられた種別情報と、を記憶する依頼者記憶手段と、
前記受付手段が前記転送依頼を受け付ける前に、前記転送先に対応付けられた種別情報を、前記転送元に通知する種別情報通知手段と、
前記転送元の各プレゼンスの識別子と、前記転送先に対応付けられた種別情報と、の関連付を受け付け、前記第１プレゼンステーブルに格納する関連付受付手段と、をさらに有し、
前記第１ウォッチャー登録手段は、前記転送依頼及びサブスクライブに含まれる種別情報に対応する転送元のプレゼンス識別子を特定し、そのプレゼンス識別子のウォッチャーリストに前記転送先のユーザ識別子及び前記種別情報を登録する、付記８に記載のプレゼンスシステム。
例えば転送依頼者がカードリーダの場合を例にとる。カードリーダのユーザ識別子とカードリーダの種別情報とは、カードリーダ内に記憶されている。転送先が使用するであろうカードリーダの種別情報を予め転送先に通知し、転送先に自分のプレゼンスＩＤとの関連付を生成させる。これにより、カードリーダが種別情報付き転送依頼をプレゼンスサーバに送信した時には、種別情報に対応するプレゼンスＩＤが確実に存在するようになる。

（付記２３）
ユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンスシステムであって、
あるプレゼンスの所有者以外のユーザである依頼者のユーザ識別子と、前記プレゼンスを所有する対象者のユーザ識別子と、任意のプレゼンスの種別を表し前記更新者または前記対象者に対応付けられた種別情報と、を取得する取得手段と、
前記対象者のプレゼンスを処理するコマンドの種類を決定する判定手段と、
前記判定手段が決定したコマンドの種類と、前記取得手段が取得した種別情報と、前記依頼者のユーザ識別子と、前記対象者のユーザ識別子とを含むコマンドを生成するコマンド生成手段と、
前記コマンド生成手段が生成したコマンドを受け付け、そのコマンドに従って前記対象者のプレゼンスの更新、サブスクライブ／サブスクライブの解除または転送／転送の解除を行うコマンド実行手段と、
を有するプレゼンスシステム。
このプレゼンスシステムは、付記１〜１８のプレゼンスシステムにおいて用いられる更新依頼・サブスクライブ／サブスクライブの解除・転送／転送の解除のためのコマンドを生成する。すなわち、種別情報付きのこれらのコマンドを、カードリーダやプレゼンスサーバ内で自動的に生成することができる。

（付記２４）
前記取得手段は、前記依頼者のユーザ識別子の取得時刻をさらに取得し、
前記対象者のユーザ識別子と取得時刻とを含む取得履歴を記憶する履歴記憶手段をさらに有し、
前記判定手段は、新たな依頼者のユーザ識別子を取得するたびに、前記取得履歴に基づいて過去所定時間ΔＴ内に前記対象者のユーザ識別子を取得しているか否かを判断し、前記判断に基づいてコマンドの種類を決定する、前記付記２３に記載のプレゼンスシステム。
例えば、過去ΔＴ内に取得したデータが取得履歴中にある場合、コマンドの種類は“転送依頼”となる。逆に過去ΔＴ内に取得したデータがない場合、コマンドの種類は“更新依頼”となる。

（付記２５）
前記判定手段は、決定したコマンドの種類が転送である場合、過去所定時間ΔＴ内に取得した前記対象者のユーザ識別子のいずれかを転送元ユーザのユーザ識別子とする、前記付記２４に記載のプレゼンスシステム。
例えば、過去所定時間ΔＴで最も古い取得時刻を有する対象者を、転送元ユーザとすることが考えられる。

（付記２６）
前記対象者のユーザ識別子とコマンドの種類との対応付けを記憶する対応記憶手段をさらに有し、
前記判定手段は、前記対応記憶手段に記憶された対応付けに基づいて、前記対象者のユーザ識別子に対応するコマンド種類を決定する、
前記付記２３に記載のプレゼンスシステム。
対象者のユーザ識別子とコマンドの種類とを直接的または間接的に対応付けることにより、前記取得手段が取得した対象者に対応するコマンドを決定することができる。

（付記２７）
前記取得手段は、前記依頼者のユーザ識別子の取得時刻をさらに取得し、
前記対象者のユーザ識別子とその取得時刻とを含む取得履歴を記憶する履歴記憶手段をさらに有し、
前記判定手段は、前記取得履歴に基づいて前記対象者のユーザ識別子をグルーピングし、コマンド種類が転送またはサブスクライブの場合は１グループ内で転送元及びサブスクライバーとなるユーザ識別子を特定する、付記２６に記載のプレゼンスシステム。
例えば、取得時刻が一定時間以上あいている場合、そこが１グループの区切りと判断し、取得履歴中の対象者をグルーピングすることが考えられる。グルーピングすることにより、新たな取得履歴を取得する毎ではなく、取得履歴をある程度蓄積してからコマンドを生成するバッファ処理が可能になる。なぜなら、１グループ内で転送元やサブスクライビーを決定することができるからである。

（付記２８）
前記対象者のユーザ識別子と、前記依頼者または前記対象者に対応する種別情報と、に基づいてプレゼンスの内容を取得するプレゼンス内容取得手段をさらに含み、
前記判定手段は、前記取得したプレゼンス内容に転送元が設定されているか否かを判断し、前記判断結果に基づいてコマンド種類を転送または転送解除のいずれかに決定する、前記付記２３に記載のプレゼンスシステム。
コマンドを自動的に生成する別の方法として、プレゼンスに既に転送が設定されているか否かにより、転送コマンドまたは転送解除コマンドを生成する方法がある。同様にして、プレゼンスに既にウォッチャーが設定されているか否かにより、サブスクライブコマンドまたはサブスクライブ解除コマンドを生成することもできる。

本発明は、インスタントメッセージングシステムなどの状態通知システムに適用可能である。

本発明の概念説明図 プレゼンティティＡのプレゼンスの更新依頼がユーザＹからあったことを示す画面例 本発明の第１実施形態に係るプレゼンスシステムの概略構成図 関連付テーブルの一例を示す説明図 図４の関連付テーブルをプレゼンスサーバに登録するための画面例 関連付テーブルの別の一例を示す説明図 図６の関連付テーブルをプレゼンスサーバに登録するための画面例 関連付テーブルの別の一例を示す説明図 図８の関連付テーブルを登録するための画面例 更新依頼に含まれるプレゼンスを変換して対象者のプレゼンスに設定する説明図 設定内容決定部がプレゼンスクライアントに提供する画面例 種別情報と更新者との対応付けに基づくプレゼンスの更新の説明図 種別情報を用いたサブスクライブの流れを示す説明図 （ａ）種別情報付サブスクライブをサブスクライバーが生成するための画面例（ｂ）サブスクライビーがプレゼンスと種別情報とを関連付けるための画面例（ｃ）種別情報付サブスクライブの受信時の画面例（ｄ）前記（ｃ）で「ユーザに問い合わせる」を選択した場合の画面例 本発明の第２実施形態に係るプレゼンスシステムの概略構成図 種別情報付転送依頼を受信したプレゼンスサーバ１０の処理の流れを示す説明図 転送依頼者からの転送依頼の設定を受け付ける画面例 ウォッチャーリスト付転送依頼に基づいてウォッチャーリスト付サブスクライブを生成する説明図 公開条件付転送の説明図 （ａ）ウォッチャーリスト付サブスクライブの受信時の画面例（ｂ）転送元に対し、ウォッチャーリスト付サブスクライブ（図中、転送依頼）を通知する画面例 転送元の公開条件を転送先に設定する説明図 転送元の公開条件の変更を、転送先の公開条件に反映させる説明図 転送先の公開条件の変更を、転送元の公開条件に反映させる説明図 間接的なサブスクライブの説明図 （ａ）ウォッチャーリスト追加依頼発生時にプレゼンスサーバの操作者に通知する画面例（ｂ）転送元に通知する画面例 本発明の第３実施形態に係るプレゼンスシステムの概略構成図 本発明の第４実施形態に係るプレゼンスシステムの概略構成図 図２７の各カードリーダに記憶される種別リストの概念説明図 図２７のプレゼンスシステムにおける、種別情報を用いた更新依頼の流れを示す説明図 種別情報リスト通知画面の一例を示す説明図 図２７のプレゼンスシステムが行う処理の流れを示す説明図 本発明の第５実施形態に係るプレゼンスシステムの概略構成図 図３２の履歴記憶部に記憶される履歴情報の概念説明図 図３２のカードリーダが実行するコマンド生成処理の流れの一例を示すフローチャート 図３２のプレゼンスシステムにおける、種別情報を用いた転送依頼の流れを示す説明図 図３２のプレゼンスシステムにおける、種別情報を用いた更新依頼の流れを示す説明図 本発明の第６実施形態に係るプレゼンスシステムの概略構成図 図３７のプレゼンスサーバが行うコマンド生成処理の流れの一例を示す説明図 図３７のプレゼンスシステムにおける、種別情報を用いた転送依頼の流れを示す説明図 図３７のプレゼンスシステムにおける、種別情報を用いた更新依頼の流れを示す説明図 本発明の第７実施形態に係るプレゼンスシステムの概略構成図 （ａ）図４１のカテゴリ記憶部に記憶されるユーザ−カテゴリテーブルの概念説明図（ｂ）図４１のカテゴリ記憶部に記憶されるカテゴリ−コマンドテーブルの概念説明図（ｃ）図４１のカテゴリ記憶部に記憶される履歴テーブルの概念説明図 図４１のカードリーダが実行するコマンド生成処理の流れの一例を示すフローチャート 本発明の第８実施形態に係るプレゼンスシステムの概略構成図 本発明の第９実施形態に係るプレゼンスシステムの概略構成図 （ａ）図４５のプレゼンス記憶部に記憶されるユーザ−プレゼンステーブルの概念説明図（ｂ）図４５のプレゼンス記憶部に記憶されるプレゼンス−コマンドテーブルの概念説明図（ｃ）図４５のプレゼンス記憶部に記憶される履歴テーブルの概念説明図 図４５のカードリーダが実行するコマンド生成処理の流れの一例を示すフローチャート 本発明の第１０実施形態に係るプレゼンスシステムの概略構成図 本発明の第１１実施形態に係るプレゼンスシステムの概略構成図 図４９のカードリーダが実行するコマンド生成処理の流れの一例を示すフローチャート

符号の説明

１００：プレゼンスシステム
１０：プレゼンスサーバ
２０：プレゼンスクライアント
３０：種別情報管理サーバ
４０−４７：カードリーダ

Claims (5)

1. ユーザを特定するユーザ識別子で識別されるユーザのプレゼンスを管理するプレゼンスシステムであって、
   あるプレゼンスの所有者以外のユーザである依頼者のユーザ識別子と、前記プレゼンスを所有する対象者のユーザ識別子と、任意のプレゼンスの種別を表し前記依頼者または前記対象者に対応付けられた種別情報と、前記依頼者のユーザ識別子の取得時刻と、を取得する取得手段と、
   前記対象者のユーザ識別子と取得時刻とを含む取得履歴を記憶する履歴記憶手段と、
   新たな依頼者のユーザ識別子を取得するたびに、前記取得履歴に基づいて過去所定時間ΔＴ内に前記対象者のユーザ識別子を取得しているか否かを判断し、前記判断に基づいてコマンドの種類を決定する判定手段と、
   前記判定手段が決定したコマンドの種類と、前記種別情報と、前記依頼者のユーザ識別子と、前記対象者のユーザ識別子と、を含み、前記対象者のプレゼンスの更新、サブスクライブ／サブスクライブの解除、転送／転送の解除のいずれかを行うコマンドを生成するコマンド生成手段と、
   前記コマンド生成手段が生成したコマンドを受け付け、そのコマンドに従って前記対象者のプレゼンスの更新、サブスクライブ／サブスクライブの解除または転送／転送の解除を行うコマンド実行手段と、
   を有するプレゼンスシステム。
2. 前記判定手段は、決定したコマンドの種類が転送である場合、過去所定時間ΔＴ内に取得した前記対象者のユーザ識別子のいずれかを転送元ユーザのユーザ識別子とする、請求項１に記載のプレゼンスシステム。
3. 前記対象者のユーザ識別子とコマンドの種類との対応付けを記憶する対応記憶手段をさらに有し、
   前記判定手段は、前記対応記憶手段に記憶された対応付けに基づいて、前記対象者のユーザ識別子に対応するコマンド種類を決定する、請求項１に記載のプレゼンスシステム。
4. 前記判定手段は、前記取得履歴に基づいて前記対象者のユーザ識別子をグルーピングし、コマンド種類が転送またはサブスクライブの場合は１グループ内で転送元及びサブスクライバーとなるユーザ識別子を特定する、請求項３に記載のプレゼンスシステム。
5. 前記対象者のユーザ識別子と、前記依頼者または前記対象者に対応する種別情報と、に基づいてプレゼンスの内容を取得するプレゼンス内容取得手段をさらに含み、
   前記判定手段は、前記取得したプレゼンス内容に転送元が設定されているか否かを判断し、前記判断結果に基づいてコマンド種類を転送または転送解除のいずれかに決定する、請求項１に記載のプレゼンスシステム。

Images