オブジェクト管理装置
【課題】ユーザ情報、文書情報、スケジュール情報等をオブジェクトとして管理し、簡易な操作でシステム的な連携を容易に行えるオブジェクト管理装置を提供する。
【解決手段】管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する手段と、上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する手段と、外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う手段と、外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う手段と、外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する手段とを備える。
【解決手段】管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する手段と、上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する手段と、外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う手段と、外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う手段と、外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する手段とを備える。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ユーザ情報、文書情報、スケジュール情報等を管理し、システム的な連携を容易にする技術に関する。
【背景技術】
【０００２】
ユーザ情報、文書情報、スケジュール情報等を集中的に管理し、複数のシステム間で共通に利用する場合がよくある。例えば、ユーザ管理方式では、ＬＤＡＰ（Lightweight Directory Access Protocol）やＳｕｎのＮＩＳ（Network Information System）等がある。
【０００３】
一方、特許文献１には、文書情報をＷｅｂサービスとして提供する技術の開示がある。
【特許文献１】特開２００４−８６４９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したような従来から存在するユーザ情報、文書情報、スケジュール情報等の管理方式は、個々の情報につき様々な操作や情報提供を行える点で優れたものではあるが、
（１）仕様が複雑である。
（２）利用するクライアントが限定（UNIX（登録商標）、Windows（登録商標）等）される。
（３）情報の変更に関して柔軟性が低い。
等の問題があった。
【０００５】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ユーザ情報、文書情報、スケジュール情報等をオブジェクトとして管理し、簡易な操作でシステム的な連携を容易に行えるオブジェクト管理装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する手段と、上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する手段と、外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う手段と、外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う手段と、外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する手段とを備えるオブジェクト管理装置を要旨としている。
【０００７】
また、請求項２に記載されるように、請求項１に記載のオブジェクト管理装置において、上記メタデータの出力に際し、タグとして特殊タグが指定されている場合に、上記メタデータの出力前に当該メタデータに所定の加工を施す手段を備えるようにすることができる。
【０００８】
また、請求項３に記載されるように、請求項１に記載のオブジェクト管理装置において、上記接続先情報はＵＲＬであるものとすることができる。
【０００９】
また、請求項４に記載されるように、請求項１に記載のオブジェクト管理装置において、上記外部からのアクセスはＨＴＴＰにより行われるものとすることができる。
【００１０】
また、請求項５に記載されるように、請求項１に記載のオブジェクト管理装置において、上記メタデータの出力はＲＳＳにより行うものとすることができる。
【００１１】
また、請求項６に記載されるように、請求項１に記載のオブジェクト管理装置において、上記外部からのアクセス時にユーザ認証を行う手段を備えるようにすることができる。
【００１２】
また、請求項７に記載されるように、請求項１に記載のオブジェクト管理装置において、管理対象情報のオブジェクトに変更があった場合に外部の装置に変更を通知する手段を備えるようにすることができる。
【００１３】
また、請求項８〜１１に記載されるように、オブジェクト管理方法として構成することができる。
【発明の効果】
【００１４】
本発明のオブジェクト管理装置にあっては、ユーザ情報、文書情報、スケジュール情報等をオブジェクトとして管理して情報操作を可能とし、各オブジェクトに対してタグ付けを行い、タグを用いた検索により必要十分なメタデータを提供するようにしたため、簡易な操作でシステム的な連携を容易に行うことができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の好適な実施形態につき説明する。
【００１６】
＜システム構成＞
図１は本発明の一実施形態にかかるオブジェクト管理サーバＸ１の構成例を示す図である。
【００１７】
オブジェクト管理サーバＸ１は、以下のような機能を備えている。
（１）オブジェクト一覧を、それぞれに付けられたタグとともに管理する。
（２）オブジェクトの編集、タグの追加、削除を他のシステムから行える。
（３）タグによる検索を行い、結果をＲＳＳ（RDF(Resource Description Framework) Site Summary、Rich Site Summary、Really Simple Syndication）で出力する。
（４）特定のタグに反応して検索結果のＲＳＳに対して所定の処理を行う。
【００１８】
図１において、オブジェクト管理サーバＸ１は、オブジェクトの管理を行うオブジェクト管理部Ｘ１−１００と、外部からのアクセスに対するサーバ機能を提供するサーバ部Ｘ１−２００とを備えている。
【００１９】
オブジェクト管理部Ｘ１−１００は、オブジェクトを複数のタグに関連付けて管理するオブジェクト・タグデータベースＸ１−１１０と、外部からのアクセスに対してユーザ認証を行う認証処理部Ｘ１−１２０とを備えている。
【００２０】
サーバ部Ｘ１−２００は、外部からの操作を受け付けて該当する操作を行う操作受付部Ｘ１−２１０と、タグによる検索操作に対して検索結果としてのＲＳＳを出力するＲＳＳ出力部Ｘ１−２２０とを備えている。
【００２１】
ＲＳＳ出力部Ｘ１−２２０は、指定されたタグのうち検索用のタグと特殊タグとに応じて検索および情報加工の処理を行うタグ処理部Ｘ１−２２１と、検索結果からＲＳＳを生成するＲＳＳ生成部Ｘ１−２２２とを備えている。
【００２２】
図２はオブジェクト・タグデータベースＸ１−１１０の例を示す図である。
【００２３】
オブジェクト・タグデータベースＸ１−１１０はオブジェクトを複数のタグに関連付けて管理し、あるオブジェクトに対してそれが関連付けられたタグの一覧を検索することができる。また、逆に特定のタグ（複数指定可能）に関連付けられたオブジェクト（のＩＤ）の一覧を取り出すこともできる。オブジェクト・タグデータベースＸ１−１１０にはオブジェクトテーブルとタグテーブルがあり、オブジェクトとタグの間はオブジェクト・タグ関係テーブルによって多対多の関係でつながっている。
【００２４】
図２（ａ）はオブジェクトとしてユーザ情報を対象とした場合のオブジェクトテーブル（ユーザテーブル）の例であり、「obj-id」「key」「name」「password」「contact」「owner」等のフィールドを含んでいる。
【００２５】
（ｂ）は文字列で表現できないオブジェクトを扱う場合のオブジェクトテーブルの例を示しており、「obj-id」「key」「path」「owner」等のフィールドを含んでおり、「path」フィールドにファイルシステム上のファイル名が格納されており、オブジェクトの読み書きは実際にはファイルに対して行われる。なお、「path」フィールドはあくまでも一例であり、オブジェクトを読み出すことができる情報であればよい。
【００２６】
また、オブジェクトの内容としてセットされるデータ形式は、ＣＳＶやアプリケーション固有のデータ形式のように、オブジェクト管理サーバＸ１の実装によって異なる。
【００２７】
（ｃ）はタグテーブルの例であり、「tag_id」「tag」等のフィールドを含んでいる。
【００２８】
（ｄ）はオブジェクト・タグ関係テーブルの例であり、「obj-id」「tag_id」等のフィールドを含んでいる。
【００２９】
図３はオブジェクトに付与されたＵＲＬの例を示す図であり、ユーザ管理サーバ「u1」のユーザ「john」に対応付けられたＵＲＬの例である。なお、ＵＲＬの形式、その持つ意味についてはこれに限るものではない。
【００３０】
オブジェクト管理サーバＸ１に登録された各オブジェクトにはこのような固有の接続先情報がそれぞれ付与されており、そのＵＲＬにアクセスすることによって、オブジェクトに対して操作を行うことができる（操作内容については後述）。
【００３１】
図４はオブジェクトの内容を示すＸＭＬの例を示す図であり、ユーザ情報の例（図２（ａ）に対応）である。なお、情報取得時にはパスワードは空欄となる。
【００３２】
図５はタグ処理部Ｘ１−２２１の構成例を示す図である。
【００３３】
図５において、タグ処理部Ｘ１−２２１は、指定されたタグを検索用のタグと特殊タグとに識別するタグ識別部Ｘ１−２２１ａと、検索用のタグに基づいてオブジェクト・タグデータベースＸ１−１１０を検索するタグ検索部Ｘ１−２２１ｂと、特殊タグに対応する処理を行う特殊タグ処理部Ｘ１−２２１ｃとを備えている。
【００３４】
特殊タグ処理部Ｘ１−２２１ｃは、特殊タグに対応するタグ処理モジュールを選択するタグ処理モジュール選択部Ｘ１−２２１ｄと、特殊タグとタグ処理モジュールとを対応付けて管理するタグ処理モジュールテーブルＸ１−２２１ｅと、タグ処理モジュールとのインタフェースを行うタグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆと、所定の処理を実行するタグ処理モジュールＸ１−２２１ｇとを備えている。
【００３５】
図６はタグ処理モジュールテーブルＸ１−２２１ｅの例を示す図であり、「tag」「module_name」等のフィールドを含んでいる。
【００３６】
＜動作＞
（オブジェクトの操作）
図７はオブジェクトの操作を行うリクエストの例を示す図である。
【００３７】
（ａ）の「ＧＥＴ〜」は、指定した名前のオブジェクトの内容を取得するものである。例えば、ユーザ管理サーバの場合、そのユーザに関する情報を含むＸＭＬデータを返すことができる。
【００３８】
（ｂ）の「ＰＵＴ〜」は、指定した名前のオブジェクトを作成するものである。
【００３９】
（ｃ）の「ＰＯＳＴ〜」は、指定した名前のオブジェクトに内容をセットするものである。例えば、ユーザ管理サーバでは、ＧＥＴで得られるのと同じ（または近い）形式のＸＭＬをＰＯＳＴのボディーとして投入することで内容を設定する。
【００４０】
（ｄ）の「ＤＥＬＥＴＥ〜」は、指定した名前のオブジェクトを削除するものである。
【００４１】
このように、オブジェクト固有のＵＲＬ等の接続先情報に対して簡単なリクエストを行うことでオブジェクトを操作することができる。
【００４２】
図８はオブジェクトの操作を行うＵＲＬの例を示す図であり、ＵＲＬのパラメータによりオブジェクトの操作を指定するものである。
【００４３】
（ａ）では、末尾の「/read?user=john」によって、ユーザ「john」のユーザ情報を読み出すことを示している。
【００４４】
（ｂ）では、末尾の「/write?name=John+Smith&contact=mailto://john@example.com」によって、ユーザ「John Smith」の「contact」を「mailto://john@example.com」に設定することを示している。
【００４５】
（タグの付与および削除）
図９はタグの付与および削除を行うリクエストの例を示す図であり、操作受付部Ｘ１−２１０への指示によって、オブジェクト（ＵＲＬ）に対するタグの付与や削除行うことができる。
【００４６】
（ａ）は、ユーザ管理サーバでユーザ「john」のＵＲＬに対してタグ「Coffee Working Group」「Software Engineer」の付与を行うＨＴＴＰリクエストの例である。
【００４７】
（ｂ）は、ユーザ管理サーバでユーザ「john」のＵＲＬに対してタグ「Coffee Working Group」の削除を行うＨＴＴＰリクエストの例である。
【００４８】
このように、オブジェクト固有のＵＲＬ等の接続先情報に対して簡単なリクエストを行うことでタグの付与および削除を行うことができる。
【００４９】
（タグ検索によるＲＳＳ出力）
オブジェクト管理サーバＸ１のＲＳＳ出力機能について説明する。
【００５０】
特定のＵＲＬへのタグを指定したＧＥＴリクエストによって、指定したタグを持つオブジェクトのＵＲＬの一覧がＲＳＳで返される。返されるＲＳＳには指定したタグを含めてすべてのタグがcategory要素として出力される。
【００５１】
また、以下に述べる特殊タグにより、出力するＲＳＳが変化する。
【００５２】
オブジェクトに対して静的に関連付けられるタグは、そのタグの付いたオブジェクトを検索、一覧するのに使われることはすでに述べた。
【００５３】
オブジェクト管理サーバＸ１は、その他に、実際に付与されていなくても、あるルールに従って情報を選択、加工する機能を持ったタグを指定できる。これを特殊タグと呼ぶことにする。
【００５４】
特殊タグが指定されると、オブジェクト管理サーバＸ１は検索結果をタグ処理モジュールＸ１−２２１ｇに入力する。どのような機能を持つタグ処理モジュールＸ１−２２１ｇを利用するかは、指定された特殊タグによって選択される。
【００５５】
以下、タグ処理モジュールＸ１−２２１ｇの呼び出しおよびその処理内容について説明する。
【００５６】
タグ処理モジュールテーブルＸ１−２２１ｅにはタグとそのタグに対応するタグ処理モジュールＸ１−２２１ｇの対が記述されている。このテーブルはオブジェクト管理サーバＸ１に設けられたウェブブラウザ向けＵＩや専用ツールを使って管理者が設定するものとする。
【００５７】
選択されたタグ処理モジュールＸ１−２２１ｇに対して、タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆから以下のデータが渡される。
（１）モジュール選択の元になったタグ（「a:recipients」、「Freshman」等）
（２）同時に渡されたその他のタグ
（３）一般のタグによって検索されたオブジェクトの一覧（データベースの検索結果集合）
タグ処理モジュールＸ１−２２１ｇは、内蔵するロジックに基づき、入力されたタグと、必要に応じて外部のデータを参照しながら、オブジェクト一覧に対して処理を行う。
【００５８】
ユーザ管理サーバにおける二つのモジュールの動作を例として示す。
【００５９】
link_rewriter：
・入力されたタグが「recipients」であれば、
・検索されたユーザ一覧それぞれについて、
・専用の外部のテーブルを参照し、
・link要素をユーザ固有のＵＲＬから情報受信用のＵＲＬ（mailto:のメールアドレス等）に書き換える。
・あるユーザについて、外部のテーブルに受信用ＵＲＬが登録されていなければ何もしない。
【００６０】
condition_selector：
・タグが「Freshman」であれば、
・検索されたユーザ一覧それぞれについて、
・ユーザの入社年度が今年度であるユーザのみを残してその他を削除し、出力する。
【００６１】
図１０はタグ検索によるＲＳＳ出力の処理例を示すフローチャートである。
【００６２】
図１０において、先ず、オブジェクト管理サーバＸ１は外部から特定のタグにより選択されたオブジェクト一覧を取得するリクエストを受け取る（ステップＳ１０１）。図１１はＲＳＳを受け取るためのリクエストの例を示す図であり、ユーザ管理サーバにおいて、二つのタグ「Coffee Working Group」「a:recipients」を持つユーザを検索するものである。なお、「a:recipients」は特殊タグである。
【００６３】
図１０に戻り、タグ識別部Ｘ１−２２１ａは、タグ処理モジュールテーブルＸ１−２２１ｅを用いて、指定されたタグを検索用のタグと特殊タグに分類する（ステップＳ１０２）。タグ処理モジュールテーブルＸ１−２２１ｅに登録されていないタグは一般のタグであると識別できる。
【００６４】
タグ検索部Ｘ１−２２１ｂは、オブジェクト・タグデータベースＸ１−１１０を利用して、指定された検索用のタグに対応付けられたオブジェクトを識別する（ステップＳ１０３）。
【００６５】
特殊タグ処理部Ｘ１−２２１ｃは、タグ識別部Ｘ１−２２１ａにより識別された特殊タグのそれぞれについて以下の処理を行う（ステップＳ１０４）。
【００６６】
タグ処理モジュール選択部Ｘ１−２２１ｄはそのタグの文字列に対応付けられたタグ処理モジュールＸ１−２２１ｇをタグ処理モジュールテーブルＸ１−２２１ｅで検索する（ステップＳ１０５）。
【００６７】
タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆを通じて、検索されたオブジェクト一覧をタグ処理モジュールＸ１−２２１ｇに入力し、変換された出力を受け取る（ステップＳ１０６）。
【００６８】
処理が終わったら、ＲＳＳ生成部Ｘ１−２２２はオブジェクト一覧をＲＳＳの形式にフォーマットして出力する（ステップＳ１０７）。
【００６９】
図１２は出力されるＲＳＳの例を示す図であり、タグ「Coffee Working Group」「a:recipients」が指定されたリクエストに対し、「Coffee Working Group」というタグがセットされているユーザ（ここでは「john」）について、「a:recipients」というタグに応答するタグ処理モジュール（link_rewriter）を適用（ここではlink要素が「john」のメールアドレスになる）することで得られたＲＳＳである。
【００７０】
なお、item要素の中にあるcategory要素には、検索条件として指定されたタグ、ユーザにセットされているタグのすべてが出力される。指定したタグには、検索条件のタグも特殊タグも同じように含まれる。この例では特殊タグに「a:」のプレフィックスを付けているが、「Coffe Working Group」のような一見普通のタグが特殊タグになっていてもよく、その場合ＲＳＳを受け取る側は特殊タグであることを意識せずに利用することになる。
【００７１】
図１３はタグ検索によるＲＳＳ出力の他の処理例を示すフローチャートであり、タグ処理モジュールＸ１−２２１ｇが検索結果を受け取らず、自身で検索を行って一覧を生成するようにしたものである。
【００７２】
図１３において、オブジェクト管理サーバＸ１は外部から特定のタグにより選択されたオブジェクト一覧を取得するリクエストを受け取る（ステップＳ１１１）。
【００７３】
タグ識別部Ｘ１−２２１ａは、タグ処理モジュールテーブルＸ１−２２１ｅを用いて、指定されたタグを検索用のタグと特殊タグに分類する（ステップＳ１１２）。タグ処理モジュールテーブルＸ１−２２１ｅに登録されていないタグは一般のタグであると識別できる。
【００７４】
特殊タグ処理部Ｘ１−２２１ｃはタグ識別部Ｘ１−２２１ａにより識別された特殊タグのそれぞれについて以下の処理を行う（ステップＳ１１３）。
【００７５】
タグ処理モジュール選択部Ｘ１−２２１ｄはそのタグの文字列に対応付けられたタグ処理モジュールＸ１−２２１ｇをタグ処理モジュールテーブルＸ１−２２１ｅで検索する（ステップＳ１１４）。
【００７６】
タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆを通じて、特殊タグ、一般のタグすべてをタグ処理モジュールＸ１−２２１ｇに入力する（ステップＳ１１５）。
【００７７】
タグ処理モジュールＸ１−２２１ｇは与えられた条件に従ってオブジェクトを抽出および変換し、オブジェクト一覧を作成する（ステップＳ１１６）。
【００７８】
タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆはタグ処理モジュールＸ１−２２１ｇからオブジェクト一覧を受け取る（ステップＳ１１７）。
【００７９】
処理が終わったら、ＲＳＳ生成部Ｘ１−２２２はオブジェクト一覧をＲＳＳの形式にフォーマットして出力する（ステップＳ１１８）。
【００８０】
（認証処理）
上記の動作フローでは記述していないが、操作受付部Ｘ１−２１０へのリクエストとともに認証情報を受け取ることにより、認証処理部Ｘ１−１２０により以下のように動作を制限する。認証方法はＨＴＴＰのＢａｓｉｃ認証やＷＳＳＥ認証のような公知の技術を利用することができる。
【００８１】
先ず、オブジェクトにその所有者（owner）を合わせて記録しておく。タグの追加や削除を認証ユーザがオブジェクトの所有者である場合のみに制限する。閲覧は匿名で可能とする。
【００８２】
また、タグ処理モジュールＸ１−２２１ｇの呼び出し時に、認証されたユーザ情報を与えることにより、特定のユーザのみ効力を持つタグ処理モジュールＸ１−２２１ｇを実現する。例えば、ユーザ管理サーバにおいて、以下の条件を満たす場合に出力する情報にユーザの緊急連絡先を加えるlink_rewriterモジュールが実現できる。
・「emergency」タグが検索のタグに含まれていること。
・認証ユーザが対象オブジェクトのユーザより上位の職位であること。
【００８３】
＜応用例＞
以下、オブジェクト管理サーバＸ１を応用したシステムの例として、資料の回覧を行う場合の構成について述べる。
【００８４】
資料の回覧とは、ミーティング資料、特定の業務に関係する情報等を必要な人に提供するものである。必要な人は随時変わるかも知れない。
【００８５】
従来、会議資料等を電子配布しようとする場合、電子メールで同報送信されるか、共有を目的とする掲示板に掲載するといった形をとることが多かった。そのため、次のような問題が生じていた。
・グループに変更があった場合、変更情報を漏れなく反映する必要があるが、漏れが生じることが多かった。
・情報の配信は配信する側がコントロールするもので、受け取り手が方法を個別に指定するのは煩雑だった。
【００８６】
このような従来の問題点を解決するため、本実施形態では次のような構成をとっている。
・ユーザ一覧をそれらに付けられたタグと合わせて管理するユーザ管理サーバと、配信を担当する配信エージェントを置く。
・ユーザ管理サーバはスケジュール管理サーバからスケジュールを受信し、参加者に付随するタグとして記憶する。
・配信エージェントは文書管理サーバの文書に付されたタグに従って、ユーザ管理サーバにタグで問い合わせを行い、ＲＳＳで宛先一覧を受け取り、指定された宛先に送信を行う。
【００８７】
図１４は本発明を資料回覧に応用したシステム構成例を示す図である。
【００８８】
図１４において、本システムは、ネットワーク上に、ユーザ管理サーバＵ１とスケジュール管理サーバＳ１と文書管理サーバＤ１と配信エージェントＡ１と操作用クライアント（ＰＣ等）Ｃ１とが接続されて構成される。
【００８９】
ユーザ管理サーバＵ１には個人またはグループの情報に対応するエントリがタグを付されて登録されている。個々のエントリは一つのＵＲＬに割り当てられている。図１５（ａ）はユーザ管理サーバＵ１で管理されるユーザ情報（ＸＭＬ形式）の例を示している。
【００９０】
スケジュール管理サーバＳ１には個人またはグループに対応するスケジュールや一連のテーマに対応するエントリがタグを付されて登録されている。ユーザ管理サーバＵ１と同様に、それらはそれぞれが一つのＵＲＬに割り当てられている（ＵＲＬ例：http://s1.example.com/sched/2006/08/01/11323）。図１５（ｂ）はスケジュール管理サーバＳ１で管理されるスケジュール情報の例を示しており、ここではiCalendar形式（iCalendar:RFC2445,http://www.ietf.org/rfc/rfc2445.txt）のデータとしている。
【００９１】
文書管理サーバＤ１には文書の情報に対応するエントリがタグを付されて登録されている。ユーザ管理サーバＵ１と同様に、それらはそれぞれが一つのＵＲＬに割り当てられている（ＵＲＬ例：http://d1.example.com/doc/98af13c6）。図１５（ｃ）は文書管理サーバＤ１で管理される文書情報（ＸＭＬ形式）の例を示している。
【００９２】
配信エージェントＡ１は、サーバ（Ｕ１、Ｓ１、Ｄ１）からの変更通知をトリガーとして、ユーザ管理サーバＵ１からＲＳＳを受信して適切な処理を行う。
【００９３】
図１６はユーザ管理サーバＵ１の構成例を示す図であり、図１に示したオブジェクト管理サーバＸ１の構成において管理対象のオブジェクトをユーザ情報に変更したことに伴う名称の変更（オブジェクト→ユーザ）があるほか、サーバ部Ｕ１−２００にユーザ管理用ウェブＵＩ Ｕ１−２３０が設けられるとともに、他のサーバにアクセスするためのＨＴＴＰクライアント部Ｕ１−４００が設けられている。ＨＴＴＰクライアント部Ｕ１−４００には、タグ操作クライアント部Ｕ１−４１０と変更通知部Ｕ１−４２０とが設けられている。
【００９４】
図１７はスケジュール管理サーバＳ１の構成例を示す図であり、図１に示したオブジェクト管理サーバＸ１の構成において管理対象のオブジェクトをスケジュール情報に変更したことに伴う名称の変更（オブジェクト→スケジュール）があるほか、サーバ部Ｓ１−２００にスケジュール管理用ウェブＵＩ Ｓ１−２３０が設けられるとともに、他のサーバにアクセスするためのＨＴＴＰクライアント部Ｓ１−４００が設けられている。ＨＴＴＰクライアント部Ｓ１−４００には、タグ操作クライアント部Ｓ１−４１０と変更通知部Ｓ１−４２０とが設けられている。
【００９５】
図１８は文書管理サーバＤ１の構成例を示す図であり、図１に示したオブジェクト管理サーバＸ１の構成において管理対象のオブジェクトを文書情報に変更したことに伴う名称の変更（オブジェクト→文書）があるほか、サーバ部Ｄ１−２００に文書管理用ウェブＵＩ Ｄ１−２３０が設けられるとともに、他のサーバにアクセスするためのＨＴＴＰクライアント部Ｄ１−４００が設けられている。ＨＴＴＰクライアント部Ｄ１−４００には、タグ操作クライアント部Ｄ１−４１０と変更通知部Ｄ１−４２０とが設けられている。
【００９６】
図１９は配信エージェントＡ１の構成例を示す図であり、他のサーバからＲＳＳを受信するＲＳＳ受信部Ａ１−１００と、受信したＲＳＳを解析するＲＳＳ解析部Ａ１−２００と、メール等のデータ送信を行うデータ送信部Ａ１−３００と、他のサーバから変更通知を受信する変更通知受信部Ａ１−４００とを備えている。
【００９７】
ＲＳＳ解析部Ａ１−２００はｌｉｎｋ要素解析部Ａ１−２１０とｃａｔｅｇｏｒｙ要素解析部Ａ１−２２０とを備え、データ送信部Ａ１−３００はメール送信部Ａ１−３１０とブックマーク登録部Ａ１−３２０とを備えている。
【００９８】
以下、上記システムの動作を説明する。なお、ユーザ管理サーバＵ１のタグをスケジュール管理サーバＳ１が変更できるように信頼関係が結ばれているものとする。スケジュール管理サーバＳ１を操作するのが誰であっても、スケジュール管理サーバＳ１はユーザ管理サーバＵ１のタグを変更できるものとする。文書管理サーバＤ１のタグを変更できるのは、ドキュメントを作成した人だけとする。また、この実施形態では、ユーザ管理サーバＵ１について、「a:recipient」タグが指定された場合に特別な処理（詳細は前記したlink_rewriterの項を参照）が行われるようになっている。
【００９９】
図２０は会議設定の処理例を示すフローチャートである。
【０１００】
図２０において、操作用クライアントＣ１からスケジュール管理サーバＳ１の操作ＵＩを利用して、ユーザは個別に、または一括して会議スケジュールの登録を行う（ステップＳ２０１）。
【０１０１】
スケジュール管理サーバＳ１はスケジュールに指定されたユーザ名をユーザ管理サーバＵ１に問い合わせ、そのユーザ固有のＵＲＬ（例：http://u1.example.com/users/john/）を得る（ステップＳ２０２）。
【０１０２】
スケジュール管理サーバＳ１はタグ操作クライアント部Ｓ１−４１０を介してユーザ管理サーバＵ１にアクセスし、上記ＵＲＬに関するタグとして、スケジュールを示すＩＤ（例：sched:2006/08/01/1328）を登録する（ステップＳ２０３）。
【０１０３】
図２１は文書登録の処理例を示すフローチャートである。
【０１０４】
図２１において、操作用クライアントＣ１は文書管理サーバＤ１に対して回覧する文書の登録を行う（ステップＳ３０１）。
【０１０５】
操作用クライアントＣ１はスケジュール管理サーバＳ１にアクセスし、スケジュールの一覧を取得する（ステップＳ３０２）。
【０１０６】
ユーザは操作用クライアントＣ１上で目的のスケジュールを選択し、そのタグを取得する（ステップＳ３０３）。
【０１０７】
操作用クライアントＣ１は文書管理サーバＤ１に対し、ユーザ認証を行い、登録した文書のタグ一覧に目的のスケジュールのタグを追加する（ステップＳ３０４）。
【０１０８】
図２２は文書配信の処理例を示すフローチャートである。
【０１０９】
図２２において、文書管理サーバＤ１はタグが追加されたことで、配信エージェントＡ１に変更通知を送信する（ステップＳ４０１）。なお、変更通知の形式は、ネットワークを介したものであれば何でもよく、例えば、配信エージェントＡ１は特定のＴＣＰポートへのコマンド入力によって処理を開始する等が考えられる。
【０１１０】
配信エージェントＡ１は文書管理サーバＤ１から最新変更分のＲＳＳ（１）を受信する（ステップＳ４０２）。図２３は文書管理サーバＤ１からのＲＳＳ取得の例を示す図であり、（ａ）は配信エージェントＡ１から文書管理サーバＤ１へのリクエスト、（ｂ）は文書管理サーバＤ１から配信エージェントＡ１へ返されるＲＳＳ（１）の例である。
【０１１１】
図２２に戻り、配信エージェントＡ１は受信したＲＳＳからスケジュールのＩＤを示す文字列がcategory要素として入っている文書を識別する（ステップＳ４０３）。
【０１１２】
配信エージェントＡ１はユーザ管理サーバＵ１にアクセスし、スケジュールのＩＤおよび「a:recipients」をタグとして与えてＲＳＳを要求する（ステップＳ４０４）。
【０１１３】
ユーザ管理サーバＵ１はスケジュールを表すタグがついたユーザ一覧を選択する（ステップＳ４０５）。
【０１１４】
ユーザ管理サーバＵ１はタグ「a:recipients」に割り当てられた処理を検索し、適用する（ステップＳ４０６）。すなわち、link要素をユーザの文書配信先に変更する。
【０１１５】
ユーザ管理サーバＵ１はＲＳＳ（２）を配信エージェントＡ１に対して返す（ステップＳ４０７）。図２４はユーザ管理サーバＵ１からのＲＳＳ取得の例を示す図であり、（ａ）は配信エージェントＡ１からユーザ管理サーバＵ１へのリクエスト、（ｂ）はユーザ管理サーバＵ１から配信エージェントＡ１へ返されるＲＳＳ（２）の例である。
【０１１６】
図２２に戻り、配信エージェントＡ１は得られたＲＳＳ（２）の各itemのlink要素を検出する（ステップＳ４０８）。
【０１１７】
配信エージェントＡ１はＲＳＳ（２）の各itemのlink要素に従ってＲＳＳ（１）に現れた文書の配信処理を行う（ステップＳ４０９）。
【０１１８】
図２５はスケジュールへのユーザ追加・変更の処理例を示すフローチャートである。
【０１１９】
図２５において、スケジュールへのユーザ追加、変更時、操作用クライアントＣ１はスケジュール管理サーバＳ１に対して参加者の変更処理を行う（ステップＳ５０１）。
【０１２０】
スケジュール管理サーバＳ１はユーザ管理サーバＵ１に対して、ユーザに対するタグの追加／削除を行う（ステップＳ５０２）。
【０１２１】
これにより、スケジュールのタグで検索したユーザ一覧も変更されるため、次回の配信から配信エージェントＡ１は変更されたユーザ一覧に対して配信を行うようになる（ステップＳ５０３）。
【０１２２】
図２６はユーザ追加・変更後の処理例を示すフローチャートである。
【０１２３】
図２６において、配信エージェントＡ１はＲＳＳ（２）を受信すると（ステップＳ６０１）、link要素の内容からＵＲＬのスキーム部分を判断し（ステップＳ６０２）、ＵＲＬのスキーム部分がhttpである場合、そのＵＲＬに文書のＵＲＬを結合してＨＴＴＰのＧＥＴリクエストを送る（ステップＳ６０３）。図２７はリクエストの例を示す図である。
【０１２４】
これにより、配信エージェントＡ１からリクエストを受けたサーバは所定の処理（ＵＲＬからデータを取得して記録する、ＵＲＬ情報のみを格納する等）を実行する（ステップＳ６０４）。
【０１２５】
また、ＵＲＬのスキーム部分がmailtoの場合、指定されたメールアドレスに、文書を参照できるＵＲＬをメールで通知する（ステップＳ６０４）。
【０１２６】
＜総括＞
以上説明したように、本発明の実施形態によれば、次のような利点がある。
（１）登録されたオブジェクトについてあるシステムが与えた情報を別のシステムが利用する形の連携がＵＲＬに対するタグを通じて容易に実現できる。
（２）幅広いクライアントから利用できる。すなわち、他のシステムを構成するプログラムから利用できることに加えて、例えば、ＲＳＳリーダで特定のタグを持つオブジェクトの一覧を定期的に取得しておけば、そのタグに関わるオブジェクトの最新の一覧および変更情報が得られることになる。タグに与える意味によって幅広い応用が可能である。
（３）特殊タグの利用によって、情報の利用目的に応じた提供情報の制御を行うことができる。
【０１２７】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【０１２８】
【図１】本発明の一実施形態にかかるオブジェクト管理サーバの構成例を示す図である。
【図２】オブジェクト・タグデータベースの例を示す図である。
【図３】オブジェクトに付与されたＵＲＬの例を示す図である。
【図４】オブジェクトの内容を示すＸＭＬの例を示す図である。
【図５】タグ処理部の構成例を示す図である。
【図６】タグ処理モジュールテーブルの例を示す図である。
【図７】オブジェクトの操作を行うリクエストの例を示す図である。
【図８】オブジェクトの操作を行うＵＲＬの例を示す図である。
【図９】タグの付与および削除を行うリクエストの例を示す図である。
【図１０】タグ検索によるＲＳＳ出力の処理例を示すフローチャートである。
【図１１】ＲＳＳを受け取るためのリクエストの例を示す図である。
【図１２】出力されるＲＳＳの例を示す図である。
【図１３】タグ検索によるＲＳＳ出力の他の処理例を示すフローチャートである。
【図１４】本発明を資料回覧に応用したシステム構成例を示す図である。
【図１５】各サーバの管理するオブジェクトの例を示す図である。
【図１６】ユーザ管理サーバの構成例を示す図である。
【図１７】スケジュール管理サーバの構成例を示す図である。
【図１８】文書管理サーバの構成例を示す図である。
【図１９】配信エージェントの構成例を示す図である。
【図２０】会議設定の処理例を示すフローチャートである。
【図２１】文書登録の処理例を示すフローチャートである。
【図２２】文書配信の処理例を示すフローチャートである。
【図２３】文書管理サーバからのＲＳＳ取得の例を示す図である。
【図２４】ユーザ管理サーバからのＲＳＳ取得の例を示す図である。
【図２５】スケジュールへのユーザ追加・変更の処理例を示すフローチャートである。
【図２６】ユーザ追加・変更後の処理例を示すフローチャートである。
【図２７】リクエストの例を示す図である。
【符号の説明】
【０１２９】
Ｘ１ オブジェクト管理サーバ
Ｘ１−１００ オブジェクト管理部
Ｘ１−１１０ オブジェクト・タグデータベース
Ｘ１−１２０ 認証処理部
Ｘ１−２００ サーバ部
Ｘ１−２１０ 操作受付部
Ｘ１−２２０ ＲＳＳ出力部
Ｘ１−２２１ タグ処理部
Ｘ１−２２１ａ タグ識別部
Ｘ１−２２１ｂ タグ検索部
Ｘ１−２２１ｃ 特殊タグ処理部
Ｘ１−２２１ｄ タグ処理モジュール選択部
Ｘ１−２２１ｅ タグ処理モジュールテーブル
Ｘ１−２２１ｆ タグ処理モジュールＩ／Ｆ
Ｘ１−２２１ｇ タグ処理モジュール
Ｘ１−２２２ ＲＳＳ生成部
Ｕ１ ユーザ管理サーバ
Ｕ１−１００ ユーザ管理部
Ｕ１−１１０ ユーザ・タグデータベース
Ｕ１−１２０ 認証処理部
Ｕ１−２００ サーバ部
Ｕ１−２１０ 操作受付部
Ｕ１−２２０ ＲＳＳ出力部
Ｕ１−２２１ タグ処理部
Ｕ１−２２２ ＲＳＳ生成部
Ｕ１−２３０ ユーザ管理用ウェブＵＩ
Ｕ１−４００ ＨＴＴＰクライアント部
Ｕ１−４１０ タグ操作クライアント部
Ｕ１−４２０ 変更通知部
Ｓ１ スケジュール管理サーバ
Ｓ１−１００ スケジュール管理部
Ｓ１−１１０ スケジュール・タグデータベース
Ｓ１−１２０ 認証処理部
Ｓ１−２００ サーバ部
Ｓ１−２１０ 操作受付部
Ｓ１−２２０ ＲＳＳ出力部
Ｓ１−２２１ タグ処理部
Ｓ１−２２２ ＲＳＳ生成部
Ｓ１−２３０ スケジュール管理用ウェブＵＩ
Ｓ１−４００ ＨＴＴＰクライアント部
Ｓ１−４１０ タグ操作クライアント部
Ｓ１−４２０ 変更通知部
Ｄ１ 文書管理サーバ
Ｄ１−１００ 文書管理部
Ｄ１−１１０ 文書・タグデータベース
Ｄ１−１２０ 認証処理部
Ｄ１−２００ サーバ部
Ｄ１−２１０ 操作受付部
Ｄ１−２２０ ＲＳＳ出力部
Ｄ１−２２１ タグ処理部
Ｄ１−２２２ ＲＳＳ生成部
Ｄ１−２３０ 文書管理用ウェブＵＩ
Ｄ１−４００ ＨＴＴＰクライアント部
Ｄ１−４１０ タグ操作クライアント部
Ｄ１−４２０ 変更通知部
Ａ１ 配信エージェント
Ａ１−１００ ＲＳＳ受信部
Ａ１−２００ ＲＳＳ解析部
Ａ１−２１０ ｌｉｎｋ要素解析部
Ａ１−２２０ ｃａｔｅｇｏｒｙ要素解析部
Ａ１−３００ データ送信部
Ａ１−３１０ メール送信部
Ａ１−３２０ ブックマーク登録部
Ａ１−４００ 変更通知受信部
Ｃ１ 操作用クライアント
【技術分野】
【０００１】
本発明は、ユーザ情報、文書情報、スケジュール情報等を管理し、システム的な連携を容易にする技術に関する。
【背景技術】
【０００２】
ユーザ情報、文書情報、スケジュール情報等を集中的に管理し、複数のシステム間で共通に利用する場合がよくある。例えば、ユーザ管理方式では、ＬＤＡＰ（Lightweight Directory Access Protocol）やＳｕｎのＮＩＳ（Network Information System）等がある。
【０００３】
一方、特許文献１には、文書情報をＷｅｂサービスとして提供する技術の開示がある。
【特許文献１】特開２００４−８６４９０号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
上述したような従来から存在するユーザ情報、文書情報、スケジュール情報等の管理方式は、個々の情報につき様々な操作や情報提供を行える点で優れたものではあるが、
（１）仕様が複雑である。
（２）利用するクライアントが限定（UNIX（登録商標）、Windows（登録商標）等）される。
（３）情報の変更に関して柔軟性が低い。
等の問題があった。
【０００５】
本発明は上記の従来の問題点に鑑み提案されたものであり、その目的とするところは、ユーザ情報、文書情報、スケジュール情報等をオブジェクトとして管理し、簡易な操作でシステム的な連携を容易に行えるオブジェクト管理装置を提供することにある。
【課題を解決するための手段】
【０００６】
上記の課題を解決するため、本発明にあっては、請求項１に記載されるように、管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する手段と、上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する手段と、外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う手段と、外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う手段と、外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する手段とを備えるオブジェクト管理装置を要旨としている。
【０００７】
また、請求項２に記載されるように、請求項１に記載のオブジェクト管理装置において、上記メタデータの出力に際し、タグとして特殊タグが指定されている場合に、上記メタデータの出力前に当該メタデータに所定の加工を施す手段を備えるようにすることができる。
【０００８】
また、請求項３に記載されるように、請求項１に記載のオブジェクト管理装置において、上記接続先情報はＵＲＬであるものとすることができる。
【０００９】
また、請求項４に記載されるように、請求項１に記載のオブジェクト管理装置において、上記外部からのアクセスはＨＴＴＰにより行われるものとすることができる。
【００１０】
また、請求項５に記載されるように、請求項１に記載のオブジェクト管理装置において、上記メタデータの出力はＲＳＳにより行うものとすることができる。
【００１１】
また、請求項６に記載されるように、請求項１に記載のオブジェクト管理装置において、上記外部からのアクセス時にユーザ認証を行う手段を備えるようにすることができる。
【００１２】
また、請求項７に記載されるように、請求項１に記載のオブジェクト管理装置において、管理対象情報のオブジェクトに変更があった場合に外部の装置に変更を通知する手段を備えるようにすることができる。
【００１３】
また、請求項８〜１１に記載されるように、オブジェクト管理方法として構成することができる。
【発明の効果】
【００１４】
本発明のオブジェクト管理装置にあっては、ユーザ情報、文書情報、スケジュール情報等をオブジェクトとして管理して情報操作を可能とし、各オブジェクトに対してタグ付けを行い、タグを用いた検索により必要十分なメタデータを提供するようにしたため、簡易な操作でシステム的な連携を容易に行うことができる。
【発明を実施するための最良の形態】
【００１５】
以下、本発明の好適な実施形態につき説明する。
【００１６】
＜システム構成＞
図１は本発明の一実施形態にかかるオブジェクト管理サーバＸ１の構成例を示す図である。
【００１７】
オブジェクト管理サーバＸ１は、以下のような機能を備えている。
（１）オブジェクト一覧を、それぞれに付けられたタグとともに管理する。
（２）オブジェクトの編集、タグの追加、削除を他のシステムから行える。
（３）タグによる検索を行い、結果をＲＳＳ（RDF(Resource Description Framework) Site Summary、Rich Site Summary、Really Simple Syndication）で出力する。
（４）特定のタグに反応して検索結果のＲＳＳに対して所定の処理を行う。
【００１８】
図１において、オブジェクト管理サーバＸ１は、オブジェクトの管理を行うオブジェクト管理部Ｘ１−１００と、外部からのアクセスに対するサーバ機能を提供するサーバ部Ｘ１−２００とを備えている。
【００１９】
オブジェクト管理部Ｘ１−１００は、オブジェクトを複数のタグに関連付けて管理するオブジェクト・タグデータベースＸ１−１１０と、外部からのアクセスに対してユーザ認証を行う認証処理部Ｘ１−１２０とを備えている。
【００２０】
サーバ部Ｘ１−２００は、外部からの操作を受け付けて該当する操作を行う操作受付部Ｘ１−２１０と、タグによる検索操作に対して検索結果としてのＲＳＳを出力するＲＳＳ出力部Ｘ１−２２０とを備えている。
【００２１】
ＲＳＳ出力部Ｘ１−２２０は、指定されたタグのうち検索用のタグと特殊タグとに応じて検索および情報加工の処理を行うタグ処理部Ｘ１−２２１と、検索結果からＲＳＳを生成するＲＳＳ生成部Ｘ１−２２２とを備えている。
【００２２】
図２はオブジェクト・タグデータベースＸ１−１１０の例を示す図である。
【００２３】
オブジェクト・タグデータベースＸ１−１１０はオブジェクトを複数のタグに関連付けて管理し、あるオブジェクトに対してそれが関連付けられたタグの一覧を検索することができる。また、逆に特定のタグ（複数指定可能）に関連付けられたオブジェクト（のＩＤ）の一覧を取り出すこともできる。オブジェクト・タグデータベースＸ１−１１０にはオブジェクトテーブルとタグテーブルがあり、オブジェクトとタグの間はオブジェクト・タグ関係テーブルによって多対多の関係でつながっている。
【００２４】
図２（ａ）はオブジェクトとしてユーザ情報を対象とした場合のオブジェクトテーブル（ユーザテーブル）の例であり、「obj-id」「key」「name」「password」「contact」「owner」等のフィールドを含んでいる。
【００２５】
（ｂ）は文字列で表現できないオブジェクトを扱う場合のオブジェクトテーブルの例を示しており、「obj-id」「key」「path」「owner」等のフィールドを含んでおり、「path」フィールドにファイルシステム上のファイル名が格納されており、オブジェクトの読み書きは実際にはファイルに対して行われる。なお、「path」フィールドはあくまでも一例であり、オブジェクトを読み出すことができる情報であればよい。
【００２６】
また、オブジェクトの内容としてセットされるデータ形式は、ＣＳＶやアプリケーション固有のデータ形式のように、オブジェクト管理サーバＸ１の実装によって異なる。
【００２７】
（ｃ）はタグテーブルの例であり、「tag_id」「tag」等のフィールドを含んでいる。
【００２８】
（ｄ）はオブジェクト・タグ関係テーブルの例であり、「obj-id」「tag_id」等のフィールドを含んでいる。
【００２９】
図３はオブジェクトに付与されたＵＲＬの例を示す図であり、ユーザ管理サーバ「u1」のユーザ「john」に対応付けられたＵＲＬの例である。なお、ＵＲＬの形式、その持つ意味についてはこれに限るものではない。
【００３０】
オブジェクト管理サーバＸ１に登録された各オブジェクトにはこのような固有の接続先情報がそれぞれ付与されており、そのＵＲＬにアクセスすることによって、オブジェクトに対して操作を行うことができる（操作内容については後述）。
【００３１】
図４はオブジェクトの内容を示すＸＭＬの例を示す図であり、ユーザ情報の例（図２（ａ）に対応）である。なお、情報取得時にはパスワードは空欄となる。
【００３２】
図５はタグ処理部Ｘ１−２２１の構成例を示す図である。
【００３３】
図５において、タグ処理部Ｘ１−２２１は、指定されたタグを検索用のタグと特殊タグとに識別するタグ識別部Ｘ１−２２１ａと、検索用のタグに基づいてオブジェクト・タグデータベースＸ１−１１０を検索するタグ検索部Ｘ１−２２１ｂと、特殊タグに対応する処理を行う特殊タグ処理部Ｘ１−２２１ｃとを備えている。
【００３４】
特殊タグ処理部Ｘ１−２２１ｃは、特殊タグに対応するタグ処理モジュールを選択するタグ処理モジュール選択部Ｘ１−２２１ｄと、特殊タグとタグ処理モジュールとを対応付けて管理するタグ処理モジュールテーブルＸ１−２２１ｅと、タグ処理モジュールとのインタフェースを行うタグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆと、所定の処理を実行するタグ処理モジュールＸ１−２２１ｇとを備えている。
【００３５】
図６はタグ処理モジュールテーブルＸ１−２２１ｅの例を示す図であり、「tag」「module_name」等のフィールドを含んでいる。
【００３６】
＜動作＞
（オブジェクトの操作）
図７はオブジェクトの操作を行うリクエストの例を示す図である。
【００３７】
（ａ）の「ＧＥＴ〜」は、指定した名前のオブジェクトの内容を取得するものである。例えば、ユーザ管理サーバの場合、そのユーザに関する情報を含むＸＭＬデータを返すことができる。
【００３８】
（ｂ）の「ＰＵＴ〜」は、指定した名前のオブジェクトを作成するものである。
【００３９】
（ｃ）の「ＰＯＳＴ〜」は、指定した名前のオブジェクトに内容をセットするものである。例えば、ユーザ管理サーバでは、ＧＥＴで得られるのと同じ（または近い）形式のＸＭＬをＰＯＳＴのボディーとして投入することで内容を設定する。
【００４０】
（ｄ）の「ＤＥＬＥＴＥ〜」は、指定した名前のオブジェクトを削除するものである。
【００４１】
このように、オブジェクト固有のＵＲＬ等の接続先情報に対して簡単なリクエストを行うことでオブジェクトを操作することができる。
【００４２】
図８はオブジェクトの操作を行うＵＲＬの例を示す図であり、ＵＲＬのパラメータによりオブジェクトの操作を指定するものである。
【００４３】
（ａ）では、末尾の「/read?user=john」によって、ユーザ「john」のユーザ情報を読み出すことを示している。
【００４４】
（ｂ）では、末尾の「/write?name=John+Smith&contact=mailto://john@example.com」によって、ユーザ「John Smith」の「contact」を「mailto://john@example.com」に設定することを示している。
【００４５】
（タグの付与および削除）
図９はタグの付与および削除を行うリクエストの例を示す図であり、操作受付部Ｘ１−２１０への指示によって、オブジェクト（ＵＲＬ）に対するタグの付与や削除行うことができる。
【００４６】
（ａ）は、ユーザ管理サーバでユーザ「john」のＵＲＬに対してタグ「Coffee Working Group」「Software Engineer」の付与を行うＨＴＴＰリクエストの例である。
【００４７】
（ｂ）は、ユーザ管理サーバでユーザ「john」のＵＲＬに対してタグ「Coffee Working Group」の削除を行うＨＴＴＰリクエストの例である。
【００４８】
このように、オブジェクト固有のＵＲＬ等の接続先情報に対して簡単なリクエストを行うことでタグの付与および削除を行うことができる。
【００４９】
（タグ検索によるＲＳＳ出力）
オブジェクト管理サーバＸ１のＲＳＳ出力機能について説明する。
【００５０】
特定のＵＲＬへのタグを指定したＧＥＴリクエストによって、指定したタグを持つオブジェクトのＵＲＬの一覧がＲＳＳで返される。返されるＲＳＳには指定したタグを含めてすべてのタグがcategory要素として出力される。
【００５１】
また、以下に述べる特殊タグにより、出力するＲＳＳが変化する。
【００５２】
オブジェクトに対して静的に関連付けられるタグは、そのタグの付いたオブジェクトを検索、一覧するのに使われることはすでに述べた。
【００５３】
オブジェクト管理サーバＸ１は、その他に、実際に付与されていなくても、あるルールに従って情報を選択、加工する機能を持ったタグを指定できる。これを特殊タグと呼ぶことにする。
【００５４】
特殊タグが指定されると、オブジェクト管理サーバＸ１は検索結果をタグ処理モジュールＸ１−２２１ｇに入力する。どのような機能を持つタグ処理モジュールＸ１−２２１ｇを利用するかは、指定された特殊タグによって選択される。
【００５５】
以下、タグ処理モジュールＸ１−２２１ｇの呼び出しおよびその処理内容について説明する。
【００５６】
タグ処理モジュールテーブルＸ１−２２１ｅにはタグとそのタグに対応するタグ処理モジュールＸ１−２２１ｇの対が記述されている。このテーブルはオブジェクト管理サーバＸ１に設けられたウェブブラウザ向けＵＩや専用ツールを使って管理者が設定するものとする。
【００５７】
選択されたタグ処理モジュールＸ１−２２１ｇに対して、タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆから以下のデータが渡される。
（１）モジュール選択の元になったタグ（「a:recipients」、「Freshman」等）
（２）同時に渡されたその他のタグ
（３）一般のタグによって検索されたオブジェクトの一覧（データベースの検索結果集合）
タグ処理モジュールＸ１−２２１ｇは、内蔵するロジックに基づき、入力されたタグと、必要に応じて外部のデータを参照しながら、オブジェクト一覧に対して処理を行う。
【００５８】
ユーザ管理サーバにおける二つのモジュールの動作を例として示す。
【００５９】
link_rewriter：
・入力されたタグが「recipients」であれば、
・検索されたユーザ一覧それぞれについて、
・専用の外部のテーブルを参照し、
・link要素をユーザ固有のＵＲＬから情報受信用のＵＲＬ（mailto:のメールアドレス等）に書き換える。
・あるユーザについて、外部のテーブルに受信用ＵＲＬが登録されていなければ何もしない。
【００６０】
condition_selector：
・タグが「Freshman」であれば、
・検索されたユーザ一覧それぞれについて、
・ユーザの入社年度が今年度であるユーザのみを残してその他を削除し、出力する。
【００６１】
図１０はタグ検索によるＲＳＳ出力の処理例を示すフローチャートである。
【００６２】
図１０において、先ず、オブジェクト管理サーバＸ１は外部から特定のタグにより選択されたオブジェクト一覧を取得するリクエストを受け取る（ステップＳ１０１）。図１１はＲＳＳを受け取るためのリクエストの例を示す図であり、ユーザ管理サーバにおいて、二つのタグ「Coffee Working Group」「a:recipients」を持つユーザを検索するものである。なお、「a:recipients」は特殊タグである。
【００６３】
図１０に戻り、タグ識別部Ｘ１−２２１ａは、タグ処理モジュールテーブルＸ１−２２１ｅを用いて、指定されたタグを検索用のタグと特殊タグに分類する（ステップＳ１０２）。タグ処理モジュールテーブルＸ１−２２１ｅに登録されていないタグは一般のタグであると識別できる。
【００６４】
タグ検索部Ｘ１−２２１ｂは、オブジェクト・タグデータベースＸ１−１１０を利用して、指定された検索用のタグに対応付けられたオブジェクトを識別する（ステップＳ１０３）。
【００６５】
特殊タグ処理部Ｘ１−２２１ｃは、タグ識別部Ｘ１−２２１ａにより識別された特殊タグのそれぞれについて以下の処理を行う（ステップＳ１０４）。
【００６６】
タグ処理モジュール選択部Ｘ１−２２１ｄはそのタグの文字列に対応付けられたタグ処理モジュールＸ１−２２１ｇをタグ処理モジュールテーブルＸ１−２２１ｅで検索する（ステップＳ１０５）。
【００６７】
タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆを通じて、検索されたオブジェクト一覧をタグ処理モジュールＸ１−２２１ｇに入力し、変換された出力を受け取る（ステップＳ１０６）。
【００６８】
処理が終わったら、ＲＳＳ生成部Ｘ１−２２２はオブジェクト一覧をＲＳＳの形式にフォーマットして出力する（ステップＳ１０７）。
【００６９】
図１２は出力されるＲＳＳの例を示す図であり、タグ「Coffee Working Group」「a:recipients」が指定されたリクエストに対し、「Coffee Working Group」というタグがセットされているユーザ（ここでは「john」）について、「a:recipients」というタグに応答するタグ処理モジュール（link_rewriter）を適用（ここではlink要素が「john」のメールアドレスになる）することで得られたＲＳＳである。
【００７０】
なお、item要素の中にあるcategory要素には、検索条件として指定されたタグ、ユーザにセットされているタグのすべてが出力される。指定したタグには、検索条件のタグも特殊タグも同じように含まれる。この例では特殊タグに「a:」のプレフィックスを付けているが、「Coffe Working Group」のような一見普通のタグが特殊タグになっていてもよく、その場合ＲＳＳを受け取る側は特殊タグであることを意識せずに利用することになる。
【００７１】
図１３はタグ検索によるＲＳＳ出力の他の処理例を示すフローチャートであり、タグ処理モジュールＸ１−２２１ｇが検索結果を受け取らず、自身で検索を行って一覧を生成するようにしたものである。
【００７２】
図１３において、オブジェクト管理サーバＸ１は外部から特定のタグにより選択されたオブジェクト一覧を取得するリクエストを受け取る（ステップＳ１１１）。
【００７３】
タグ識別部Ｘ１−２２１ａは、タグ処理モジュールテーブルＸ１−２２１ｅを用いて、指定されたタグを検索用のタグと特殊タグに分類する（ステップＳ１１２）。タグ処理モジュールテーブルＸ１−２２１ｅに登録されていないタグは一般のタグであると識別できる。
【００７４】
特殊タグ処理部Ｘ１−２２１ｃはタグ識別部Ｘ１−２２１ａにより識別された特殊タグのそれぞれについて以下の処理を行う（ステップＳ１１３）。
【００７５】
タグ処理モジュール選択部Ｘ１−２２１ｄはそのタグの文字列に対応付けられたタグ処理モジュールＸ１−２２１ｇをタグ処理モジュールテーブルＸ１−２２１ｅで検索する（ステップＳ１１４）。
【００７６】
タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆを通じて、特殊タグ、一般のタグすべてをタグ処理モジュールＸ１−２２１ｇに入力する（ステップＳ１１５）。
【００７７】
タグ処理モジュールＸ１−２２１ｇは与えられた条件に従ってオブジェクトを抽出および変換し、オブジェクト一覧を作成する（ステップＳ１１６）。
【００７８】
タグ処理モジュールＩ／Ｆ Ｘ１−２２１ｆはタグ処理モジュールＸ１−２２１ｇからオブジェクト一覧を受け取る（ステップＳ１１７）。
【００７９】
処理が終わったら、ＲＳＳ生成部Ｘ１−２２２はオブジェクト一覧をＲＳＳの形式にフォーマットして出力する（ステップＳ１１８）。
【００８０】
（認証処理）
上記の動作フローでは記述していないが、操作受付部Ｘ１−２１０へのリクエストとともに認証情報を受け取ることにより、認証処理部Ｘ１−１２０により以下のように動作を制限する。認証方法はＨＴＴＰのＢａｓｉｃ認証やＷＳＳＥ認証のような公知の技術を利用することができる。
【００８１】
先ず、オブジェクトにその所有者（owner）を合わせて記録しておく。タグの追加や削除を認証ユーザがオブジェクトの所有者である場合のみに制限する。閲覧は匿名で可能とする。
【００８２】
また、タグ処理モジュールＸ１−２２１ｇの呼び出し時に、認証されたユーザ情報を与えることにより、特定のユーザのみ効力を持つタグ処理モジュールＸ１−２２１ｇを実現する。例えば、ユーザ管理サーバにおいて、以下の条件を満たす場合に出力する情報にユーザの緊急連絡先を加えるlink_rewriterモジュールが実現できる。
・「emergency」タグが検索のタグに含まれていること。
・認証ユーザが対象オブジェクトのユーザより上位の職位であること。
【００８３】
＜応用例＞
以下、オブジェクト管理サーバＸ１を応用したシステムの例として、資料の回覧を行う場合の構成について述べる。
【００８４】
資料の回覧とは、ミーティング資料、特定の業務に関係する情報等を必要な人に提供するものである。必要な人は随時変わるかも知れない。
【００８５】
従来、会議資料等を電子配布しようとする場合、電子メールで同報送信されるか、共有を目的とする掲示板に掲載するといった形をとることが多かった。そのため、次のような問題が生じていた。
・グループに変更があった場合、変更情報を漏れなく反映する必要があるが、漏れが生じることが多かった。
・情報の配信は配信する側がコントロールするもので、受け取り手が方法を個別に指定するのは煩雑だった。
【００８６】
このような従来の問題点を解決するため、本実施形態では次のような構成をとっている。
・ユーザ一覧をそれらに付けられたタグと合わせて管理するユーザ管理サーバと、配信を担当する配信エージェントを置く。
・ユーザ管理サーバはスケジュール管理サーバからスケジュールを受信し、参加者に付随するタグとして記憶する。
・配信エージェントは文書管理サーバの文書に付されたタグに従って、ユーザ管理サーバにタグで問い合わせを行い、ＲＳＳで宛先一覧を受け取り、指定された宛先に送信を行う。
【００８７】
図１４は本発明を資料回覧に応用したシステム構成例を示す図である。
【００８８】
図１４において、本システムは、ネットワーク上に、ユーザ管理サーバＵ１とスケジュール管理サーバＳ１と文書管理サーバＤ１と配信エージェントＡ１と操作用クライアント（ＰＣ等）Ｃ１とが接続されて構成される。
【００８９】
ユーザ管理サーバＵ１には個人またはグループの情報に対応するエントリがタグを付されて登録されている。個々のエントリは一つのＵＲＬに割り当てられている。図１５（ａ）はユーザ管理サーバＵ１で管理されるユーザ情報（ＸＭＬ形式）の例を示している。
【００９０】
スケジュール管理サーバＳ１には個人またはグループに対応するスケジュールや一連のテーマに対応するエントリがタグを付されて登録されている。ユーザ管理サーバＵ１と同様に、それらはそれぞれが一つのＵＲＬに割り当てられている（ＵＲＬ例：http://s1.example.com/sched/2006/08/01/11323）。図１５（ｂ）はスケジュール管理サーバＳ１で管理されるスケジュール情報の例を示しており、ここではiCalendar形式（iCalendar:RFC2445,http://www.ietf.org/rfc/rfc2445.txt）のデータとしている。
【００９１】
文書管理サーバＤ１には文書の情報に対応するエントリがタグを付されて登録されている。ユーザ管理サーバＵ１と同様に、それらはそれぞれが一つのＵＲＬに割り当てられている（ＵＲＬ例：http://d1.example.com/doc/98af13c6）。図１５（ｃ）は文書管理サーバＤ１で管理される文書情報（ＸＭＬ形式）の例を示している。
【００９２】
配信エージェントＡ１は、サーバ（Ｕ１、Ｓ１、Ｄ１）からの変更通知をトリガーとして、ユーザ管理サーバＵ１からＲＳＳを受信して適切な処理を行う。
【００９３】
図１６はユーザ管理サーバＵ１の構成例を示す図であり、図１に示したオブジェクト管理サーバＸ１の構成において管理対象のオブジェクトをユーザ情報に変更したことに伴う名称の変更（オブジェクト→ユーザ）があるほか、サーバ部Ｕ１−２００にユーザ管理用ウェブＵＩ Ｕ１−２３０が設けられるとともに、他のサーバにアクセスするためのＨＴＴＰクライアント部Ｕ１−４００が設けられている。ＨＴＴＰクライアント部Ｕ１−４００には、タグ操作クライアント部Ｕ１−４１０と変更通知部Ｕ１−４２０とが設けられている。
【００９４】
図１７はスケジュール管理サーバＳ１の構成例を示す図であり、図１に示したオブジェクト管理サーバＸ１の構成において管理対象のオブジェクトをスケジュール情報に変更したことに伴う名称の変更（オブジェクト→スケジュール）があるほか、サーバ部Ｓ１−２００にスケジュール管理用ウェブＵＩ Ｓ１−２３０が設けられるとともに、他のサーバにアクセスするためのＨＴＴＰクライアント部Ｓ１−４００が設けられている。ＨＴＴＰクライアント部Ｓ１−４００には、タグ操作クライアント部Ｓ１−４１０と変更通知部Ｓ１−４２０とが設けられている。
【００９５】
図１８は文書管理サーバＤ１の構成例を示す図であり、図１に示したオブジェクト管理サーバＸ１の構成において管理対象のオブジェクトを文書情報に変更したことに伴う名称の変更（オブジェクト→文書）があるほか、サーバ部Ｄ１−２００に文書管理用ウェブＵＩ Ｄ１−２３０が設けられるとともに、他のサーバにアクセスするためのＨＴＴＰクライアント部Ｄ１−４００が設けられている。ＨＴＴＰクライアント部Ｄ１−４００には、タグ操作クライアント部Ｄ１−４１０と変更通知部Ｄ１−４２０とが設けられている。
【００９６】
図１９は配信エージェントＡ１の構成例を示す図であり、他のサーバからＲＳＳを受信するＲＳＳ受信部Ａ１−１００と、受信したＲＳＳを解析するＲＳＳ解析部Ａ１−２００と、メール等のデータ送信を行うデータ送信部Ａ１−３００と、他のサーバから変更通知を受信する変更通知受信部Ａ１−４００とを備えている。
【００９７】
ＲＳＳ解析部Ａ１−２００はｌｉｎｋ要素解析部Ａ１−２１０とｃａｔｅｇｏｒｙ要素解析部Ａ１−２２０とを備え、データ送信部Ａ１−３００はメール送信部Ａ１−３１０とブックマーク登録部Ａ１−３２０とを備えている。
【００９８】
以下、上記システムの動作を説明する。なお、ユーザ管理サーバＵ１のタグをスケジュール管理サーバＳ１が変更できるように信頼関係が結ばれているものとする。スケジュール管理サーバＳ１を操作するのが誰であっても、スケジュール管理サーバＳ１はユーザ管理サーバＵ１のタグを変更できるものとする。文書管理サーバＤ１のタグを変更できるのは、ドキュメントを作成した人だけとする。また、この実施形態では、ユーザ管理サーバＵ１について、「a:recipient」タグが指定された場合に特別な処理（詳細は前記したlink_rewriterの項を参照）が行われるようになっている。
【００９９】
図２０は会議設定の処理例を示すフローチャートである。
【０１００】
図２０において、操作用クライアントＣ１からスケジュール管理サーバＳ１の操作ＵＩを利用して、ユーザは個別に、または一括して会議スケジュールの登録を行う（ステップＳ２０１）。
【０１０１】
スケジュール管理サーバＳ１はスケジュールに指定されたユーザ名をユーザ管理サーバＵ１に問い合わせ、そのユーザ固有のＵＲＬ（例：http://u1.example.com/users/john/）を得る（ステップＳ２０２）。
【０１０２】
スケジュール管理サーバＳ１はタグ操作クライアント部Ｓ１−４１０を介してユーザ管理サーバＵ１にアクセスし、上記ＵＲＬに関するタグとして、スケジュールを示すＩＤ（例：sched:2006/08/01/1328）を登録する（ステップＳ２０３）。
【０１０３】
図２１は文書登録の処理例を示すフローチャートである。
【０１０４】
図２１において、操作用クライアントＣ１は文書管理サーバＤ１に対して回覧する文書の登録を行う（ステップＳ３０１）。
【０１０５】
操作用クライアントＣ１はスケジュール管理サーバＳ１にアクセスし、スケジュールの一覧を取得する（ステップＳ３０２）。
【０１０６】
ユーザは操作用クライアントＣ１上で目的のスケジュールを選択し、そのタグを取得する（ステップＳ３０３）。
【０１０７】
操作用クライアントＣ１は文書管理サーバＤ１に対し、ユーザ認証を行い、登録した文書のタグ一覧に目的のスケジュールのタグを追加する（ステップＳ３０４）。
【０１０８】
図２２は文書配信の処理例を示すフローチャートである。
【０１０９】
図２２において、文書管理サーバＤ１はタグが追加されたことで、配信エージェントＡ１に変更通知を送信する（ステップＳ４０１）。なお、変更通知の形式は、ネットワークを介したものであれば何でもよく、例えば、配信エージェントＡ１は特定のＴＣＰポートへのコマンド入力によって処理を開始する等が考えられる。
【０１１０】
配信エージェントＡ１は文書管理サーバＤ１から最新変更分のＲＳＳ（１）を受信する（ステップＳ４０２）。図２３は文書管理サーバＤ１からのＲＳＳ取得の例を示す図であり、（ａ）は配信エージェントＡ１から文書管理サーバＤ１へのリクエスト、（ｂ）は文書管理サーバＤ１から配信エージェントＡ１へ返されるＲＳＳ（１）の例である。
【０１１１】
図２２に戻り、配信エージェントＡ１は受信したＲＳＳからスケジュールのＩＤを示す文字列がcategory要素として入っている文書を識別する（ステップＳ４０３）。
【０１１２】
配信エージェントＡ１はユーザ管理サーバＵ１にアクセスし、スケジュールのＩＤおよび「a:recipients」をタグとして与えてＲＳＳを要求する（ステップＳ４０４）。
【０１１３】
ユーザ管理サーバＵ１はスケジュールを表すタグがついたユーザ一覧を選択する（ステップＳ４０５）。
【０１１４】
ユーザ管理サーバＵ１はタグ「a:recipients」に割り当てられた処理を検索し、適用する（ステップＳ４０６）。すなわち、link要素をユーザの文書配信先に変更する。
【０１１５】
ユーザ管理サーバＵ１はＲＳＳ（２）を配信エージェントＡ１に対して返す（ステップＳ４０７）。図２４はユーザ管理サーバＵ１からのＲＳＳ取得の例を示す図であり、（ａ）は配信エージェントＡ１からユーザ管理サーバＵ１へのリクエスト、（ｂ）はユーザ管理サーバＵ１から配信エージェントＡ１へ返されるＲＳＳ（２）の例である。
【０１１６】
図２２に戻り、配信エージェントＡ１は得られたＲＳＳ（２）の各itemのlink要素を検出する（ステップＳ４０８）。
【０１１７】
配信エージェントＡ１はＲＳＳ（２）の各itemのlink要素に従ってＲＳＳ（１）に現れた文書の配信処理を行う（ステップＳ４０９）。
【０１１８】
図２５はスケジュールへのユーザ追加・変更の処理例を示すフローチャートである。
【０１１９】
図２５において、スケジュールへのユーザ追加、変更時、操作用クライアントＣ１はスケジュール管理サーバＳ１に対して参加者の変更処理を行う（ステップＳ５０１）。
【０１２０】
スケジュール管理サーバＳ１はユーザ管理サーバＵ１に対して、ユーザに対するタグの追加／削除を行う（ステップＳ５０２）。
【０１２１】
これにより、スケジュールのタグで検索したユーザ一覧も変更されるため、次回の配信から配信エージェントＡ１は変更されたユーザ一覧に対して配信を行うようになる（ステップＳ５０３）。
【０１２２】
図２６はユーザ追加・変更後の処理例を示すフローチャートである。
【０１２３】
図２６において、配信エージェントＡ１はＲＳＳ（２）を受信すると（ステップＳ６０１）、link要素の内容からＵＲＬのスキーム部分を判断し（ステップＳ６０２）、ＵＲＬのスキーム部分がhttpである場合、そのＵＲＬに文書のＵＲＬを結合してＨＴＴＰのＧＥＴリクエストを送る（ステップＳ６０３）。図２７はリクエストの例を示す図である。
【０１２４】
これにより、配信エージェントＡ１からリクエストを受けたサーバは所定の処理（ＵＲＬからデータを取得して記録する、ＵＲＬ情報のみを格納する等）を実行する（ステップＳ６０４）。
【０１２５】
また、ＵＲＬのスキーム部分がmailtoの場合、指定されたメールアドレスに、文書を参照できるＵＲＬをメールで通知する（ステップＳ６０４）。
【０１２６】
＜総括＞
以上説明したように、本発明の実施形態によれば、次のような利点がある。
（１）登録されたオブジェクトについてあるシステムが与えた情報を別のシステムが利用する形の連携がＵＲＬに対するタグを通じて容易に実現できる。
（２）幅広いクライアントから利用できる。すなわち、他のシステムを構成するプログラムから利用できることに加えて、例えば、ＲＳＳリーダで特定のタグを持つオブジェクトの一覧を定期的に取得しておけば、そのタグに関わるオブジェクトの最新の一覧および変更情報が得られることになる。タグに与える意味によって幅広い応用が可能である。
（３）特殊タグの利用によって、情報の利用目的に応じた提供情報の制御を行うことができる。
【０１２７】
以上、本発明の好適な実施の形態により本発明を説明した。ここでは特定の具体例を示して本発明を説明したが、特許請求の範囲に定義された本発明の広範な趣旨および範囲から逸脱することなく、これら具体例に様々な修正および変更を加えることができることは明らかである。すなわち、具体例の詳細および添付の図面により本発明が限定されるものと解釈してはならない。
【図面の簡単な説明】
【０１２８】
【図１】本発明の一実施形態にかかるオブジェクト管理サーバの構成例を示す図である。
【図２】オブジェクト・タグデータベースの例を示す図である。
【図３】オブジェクトに付与されたＵＲＬの例を示す図である。
【図４】オブジェクトの内容を示すＸＭＬの例を示す図である。
【図５】タグ処理部の構成例を示す図である。
【図６】タグ処理モジュールテーブルの例を示す図である。
【図７】オブジェクトの操作を行うリクエストの例を示す図である。
【図８】オブジェクトの操作を行うＵＲＬの例を示す図である。
【図９】タグの付与および削除を行うリクエストの例を示す図である。
【図１０】タグ検索によるＲＳＳ出力の処理例を示すフローチャートである。
【図１１】ＲＳＳを受け取るためのリクエストの例を示す図である。
【図１２】出力されるＲＳＳの例を示す図である。
【図１３】タグ検索によるＲＳＳ出力の他の処理例を示すフローチャートである。
【図１４】本発明を資料回覧に応用したシステム構成例を示す図である。
【図１５】各サーバの管理するオブジェクトの例を示す図である。
【図１６】ユーザ管理サーバの構成例を示す図である。
【図１７】スケジュール管理サーバの構成例を示す図である。
【図１８】文書管理サーバの構成例を示す図である。
【図１９】配信エージェントの構成例を示す図である。
【図２０】会議設定の処理例を示すフローチャートである。
【図２１】文書登録の処理例を示すフローチャートである。
【図２２】文書配信の処理例を示すフローチャートである。
【図２３】文書管理サーバからのＲＳＳ取得の例を示す図である。
【図２４】ユーザ管理サーバからのＲＳＳ取得の例を示す図である。
【図２５】スケジュールへのユーザ追加・変更の処理例を示すフローチャートである。
【図２６】ユーザ追加・変更後の処理例を示すフローチャートである。
【図２７】リクエストの例を示す図である。
【符号の説明】
【０１２９】
Ｘ１ オブジェクト管理サーバ
Ｘ１−１００ オブジェクト管理部
Ｘ１−１１０ オブジェクト・タグデータベース
Ｘ１−１２０ 認証処理部
Ｘ１−２００ サーバ部
Ｘ１−２１０ 操作受付部
Ｘ１−２２０ ＲＳＳ出力部
Ｘ１−２２１ タグ処理部
Ｘ１−２２１ａ タグ識別部
Ｘ１−２２１ｂ タグ検索部
Ｘ１−２２１ｃ 特殊タグ処理部
Ｘ１−２２１ｄ タグ処理モジュール選択部
Ｘ１−２２１ｅ タグ処理モジュールテーブル
Ｘ１−２２１ｆ タグ処理モジュールＩ／Ｆ
Ｘ１−２２１ｇ タグ処理モジュール
Ｘ１−２２２ ＲＳＳ生成部
Ｕ１ ユーザ管理サーバ
Ｕ１−１００ ユーザ管理部
Ｕ１−１１０ ユーザ・タグデータベース
Ｕ１−１２０ 認証処理部
Ｕ１−２００ サーバ部
Ｕ１−２１０ 操作受付部
Ｕ１−２２０ ＲＳＳ出力部
Ｕ１−２２１ タグ処理部
Ｕ１−２２２ ＲＳＳ生成部
Ｕ１−２３０ ユーザ管理用ウェブＵＩ
Ｕ１−４００ ＨＴＴＰクライアント部
Ｕ１−４１０ タグ操作クライアント部
Ｕ１−４２０ 変更通知部
Ｓ１ スケジュール管理サーバ
Ｓ１−１００ スケジュール管理部
Ｓ１−１１０ スケジュール・タグデータベース
Ｓ１−１２０ 認証処理部
Ｓ１−２００ サーバ部
Ｓ１−２１０ 操作受付部
Ｓ１−２２０ ＲＳＳ出力部
Ｓ１−２２１ タグ処理部
Ｓ１−２２２ ＲＳＳ生成部
Ｓ１−２３０ スケジュール管理用ウェブＵＩ
Ｓ１−４００ ＨＴＴＰクライアント部
Ｓ１−４１０ タグ操作クライアント部
Ｓ１−４２０ 変更通知部
Ｄ１ 文書管理サーバ
Ｄ１−１００ 文書管理部
Ｄ１−１１０ 文書・タグデータベース
Ｄ１−１２０ 認証処理部
Ｄ１−２００ サーバ部
Ｄ１−２１０ 操作受付部
Ｄ１−２２０ ＲＳＳ出力部
Ｄ１−２２１ タグ処理部
Ｄ１−２２２ ＲＳＳ生成部
Ｄ１−２３０ 文書管理用ウェブＵＩ
Ｄ１−４００ ＨＴＴＰクライアント部
Ｄ１−４１０ タグ操作クライアント部
Ｄ１−４２０ 変更通知部
Ａ１ 配信エージェント
Ａ１−１００ ＲＳＳ受信部
Ａ１−２００ ＲＳＳ解析部
Ａ１−２１０ ｌｉｎｋ要素解析部
Ａ１−２２０ ｃａｔｅｇｏｒｙ要素解析部
Ａ１−３００ データ送信部
Ａ１−３１０ メール送信部
Ａ１−３２０ ブックマーク登録部
Ａ１−４００ 変更通知受信部
Ｃ１ 操作用クライアント
【特許請求の範囲】
【請求項１】
管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する手段と、
上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する手段と、
外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う手段と、
外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う手段と、
外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する手段とを備えたことを特徴とするオブジェクト管理装置。
【請求項２】
請求項１に記載のオブジェクト管理装置において、
上記メタデータの出力に際し、タグとして特殊タグが指定されている場合に、上記メタデータの出力前に当該メタデータに所定の加工を施す手段を備えたことを特徴とするオブジェクト管理装置。
【請求項３】
請求項１に記載のオブジェクト管理装置において、
上記接続先情報はＵＲＬであることを特徴とするオブジェクト管理装置。
【請求項４】
請求項１に記載のオブジェクト管理装置において、
上記外部からのアクセスはＨＴＴＰにより行われることを特徴とするオブジェクト管理装置。
【請求項５】
請求項１に記載のオブジェクト管理装置において、
上記メタデータの出力はＲＳＳにより行うことを特徴とするオブジェクト管理装置。
【請求項６】
請求項１に記載のオブジェクト管理装置において、
上記外部からのアクセス時にユーザ認証を行う手段を備えたことを特徴とするオブジェクト管理装置。
【請求項７】
請求項１に記載のオブジェクト管理装置において、
管理対象情報のオブジェクトに変更があった場合に外部の装置に変更を通知する手段を備えたことを特徴とするオブジェクト管理装置。
【請求項８】
管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する工程と、
上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する工程と、
外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う工程と、
外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う工程と、
外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する工程とを備えたことを特徴とするオブジェクト管理方法。
【請求項９】
請求項８に記載のオブジェクト管理方法において、
上記メタデータの出力に際し、タグとして特殊タグが指定されている場合に、上記メタデータの出力前に当該メタデータに所定の加工を施す工程を備えたことを特徴とするオブジェクト管理方法。
【請求項１０】
請求項８に記載のオブジェクト管理方法において、
上記外部からのアクセス時にユーザ認証を行う工程を備えたことを特徴とするオブジェクト管理方法。
【請求項１１】
請求項８に記載のオブジェクト管理方法において、
管理対象情報のオブジェクトに変更があった場合に外部の装置に変更を通知する工程を備えたことを特徴とするオブジェクト管理方法。
【請求項１】
管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する手段と、
上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する手段と、
外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う手段と、
外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う手段と、
外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する手段とを備えたことを特徴とするオブジェクト管理装置。
【請求項２】
請求項１に記載のオブジェクト管理装置において、
上記メタデータの出力に際し、タグとして特殊タグが指定されている場合に、上記メタデータの出力前に当該メタデータに所定の加工を施す手段を備えたことを特徴とするオブジェクト管理装置。
【請求項３】
請求項１に記載のオブジェクト管理装置において、
上記接続先情報はＵＲＬであることを特徴とするオブジェクト管理装置。
【請求項４】
請求項１に記載のオブジェクト管理装置において、
上記外部からのアクセスはＨＴＴＰにより行われることを特徴とするオブジェクト管理装置。
【請求項５】
請求項１に記載のオブジェクト管理装置において、
上記メタデータの出力はＲＳＳにより行うことを特徴とするオブジェクト管理装置。
【請求項６】
請求項１に記載のオブジェクト管理装置において、
上記外部からのアクセス時にユーザ認証を行う手段を備えたことを特徴とするオブジェクト管理装置。
【請求項７】
請求項１に記載のオブジェクト管理装置において、
管理対象情報のオブジェクトに変更があった場合に外部の装置に変更を通知する手段を備えたことを特徴とするオブジェクト管理装置。
【請求項８】
管理対象情報のオブジェクトを外部からアクセス可能な接続先情報と関連付けて保持する工程と、
上記オブジェクトと、任意に設定可能なタグとを関連付けて保持する工程と、
外部からのアクセスに応じて上記オブジェクトの内容取得、作成、内容設定および削除の操作を行う工程と、
外部からのアクセスに応じて上記オブジェクトへのタグの付与および削除を行う工程と、
外部からのアクセスに応じてタグが指定されている場合に当該タグと関連付けられた上記オブジェクトのメタデータを出力する工程とを備えたことを特徴とするオブジェクト管理方法。
【請求項９】
請求項８に記載のオブジェクト管理方法において、
上記メタデータの出力に際し、タグとして特殊タグが指定されている場合に、上記メタデータの出力前に当該メタデータに所定の加工を施す工程を備えたことを特徴とするオブジェクト管理方法。
【請求項１０】
請求項８に記載のオブジェクト管理方法において、
上記外部からのアクセス時にユーザ認証を行う工程を備えたことを特徴とするオブジェクト管理方法。
【請求項１１】
請求項８に記載のオブジェクト管理方法において、
管理対象情報のオブジェクトに変更があった場合に外部の装置に変更を通知する工程を備えたことを特徴とするオブジェクト管理方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２４】
【図２５】
【図２６】
【図２７】
【公開番号】特開２００８−１５２５３７（Ｐ２００８−１５２５３７Ａ）
【公開日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願番号】特願２００６−３３９９０９（Ｐ２００６−３３９９０９）
【出願日】平成１８年１２月１８日（２００６．１２．１８）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２０年７月３日（２００８．７．３）
【国際特許分類】
【出願日】平成１８年１２月１８日（２００６．１２．１８）
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]