(57)【要約】【課題】一度割り当てられた分担の変更に柔軟に対応でき、かつテキストファイルだけでなく複数の形式の資料を結合できる会議情報システムを提供する。【解決手段】この会議情報システム１００は、メールソフト１１３とブラウザを有する開催者端末１０５と、メールソフト１１５、及び資料作成ソフト１１６を有する担当者端末１０２、１０３と、メールソフト１０６、会議ページ操作部１１０、メールの作成、解析部１０７、ＴｏＤｏリスト操作部１１１、ユーザ情報操作部１０８、ファイル操作部１１２、及びデータベース１０９を有する会議情報システムサーバ１０１とを備えて構成されている。【選択図】図１
2011039961.tif 000002
【特許請求の範囲】
【請求項１】
会議情報システムサーバからＴｏＤｏ完了通知、資料結合通知を受け取る際に使用されるメールソフト、及び会議の開催者が会議情報システムサーバにアクセスし、会議ページの作成、ＴｏＤｏリストの作成・依頼・変更・資料の閲覧を行う際に使用されるブラウザを有する開催者端末と、
会議情報システムサーバからＴｏＤｏ依頼・変更通知を受け取る際に使用され、又は、会議情報システムサーバに返信メールを行い会議情報システムサーバにアクションを起こさせる際に使用されるメールソフト、及びＴｏＤｏ依頼通知に従い担当者が資料作成する際に使用される資料作成ソフトを有する担当者端末と、
開催者へ各種通知を送受信する際に使用されるメールソフト、開催者が会議ページの作成、編集、閲覧する際に使用される会議ページ操作部、開催者、担当者への各種通知を作成する際に使用され、担当者からの返信メールを解析し次のアクションを起こす際に使用されるメールの作成、解析部、開催者がＴｏＤｏリストの作成、編集、ステータス管理を行う際に使用され、担当者からの返信メールによりＴｏＤｏリストに変更を行う際に使用され、ＴｏＤｏのステータス更新、資料更新を監視し結合資料の更新を行う際に使用されるＴｏＤｏリスト操作部、開催者、担当者のメールアドレスを取得・変更する際に使用されるユーザ情報操作部、資料の登録、更新、削除、閲覧、形式変換、結合を行う際に使用されるファイル操作部、及び会議情報を管理する際に使用され、ユーザ情報を管理する際に使用され、ＴｏＤｏリストを管理する際に使用され、登録資料を管理する際に使用されるデータベースを有する会議情報システムサーバと、
を備えたことを特徴とする会議情報システム。
【請求項２】
担当者からの返信メールの本文の有無および内容により前記会議情報システムサーバのＴｏＤｏリスト情報のステータスを変化させることを特徴とする請求項１に記載の会議情報システム。
【請求項３】
担当者からの返信メールのカーボンコピーの内容により、前記会議情報システムサーバのＴｏＤｏリスト情報の担当者の追加、および担当者のサブメールアドレスの追加を行うことを特徴とする請求項１に記載の会議情報システム。
【請求項４】
担当者からの返信メールのあて先の内容により、前記会議情報システムサーバの資料の登録、取得、更新、削除を行うことを特徴とする請求項１に記載の会議情報システム。
【請求項５】
前記会議情報システムサーバのＴｏＤｏリスト情報のステータスを変化させること、又はＴｏＤｏリスト情報の担当者の追加、および担当者のサブメールアドレスの追加を行うこと、又は資料の登録、取得、更新、削除を行うことの少なくとも２つ以上を持つことを特徴とする請求項１に記載の会議情報システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、会議情報システムに関し、さらに詳しくは、会議の参加者に一度割り当てられた分担の変更に柔軟に対応でき、かつテキストファイルだけでなく複数の形式の資料を結合できる会議情報システムに関するものである。
【背景技術】
【０００２】
会議情報システムを利用した会議において、発生したアクションアイテムは、そのアクションアイテムを担当する担当者毎に割り振られて処理され、その結果、会議情報システムサーバに資料として登録されることが多い。アクションアイテムが多い場合、資料も多くなり、見づらくなったり一見して内容がわからなくなったりする。また内容に関連があるものの、担当者が違うので別々になってしまう資料も存在し、資料を管理する観点や見せる観点から資料を一つにまとめた方がよい場合が往々にして存在する。
一方、ネットワークを利用した文書をまとめる技術として、編集者があらかじめ担当リストと原稿テンプレートを作成し、それらに従って複数の担当者に執筆と出来上がった原稿の受け渡しをしてもらうことによって、編集者が手作業で行わなければならなかった原稿の結合をコンピュータに行わせ、また、通信に電子メールを使用することにより担当者の端末の制約を緩和する文書編集システムが考えられ既に知られている。
しかし、今までの文書編集システムでは、編集者が一度担当リストと原稿テンプレートを配布したら、それらの変更を行うには編集者が担当リストと原稿テンプレートを作り直し、再配布する必要があり、編集者の作業が増えてしまう。また、担当者が一度原稿を提出してしまうと、修正を行うには編集者が再度担当リストと原稿テンプレートを作り直すか、あるいは編集者が手動で修正箇所を置き換えていく必要があり、作業が煩雑になってしまう。他にも、結合する原稿はテキスト文書のみに限定されており、そのことから画像やパワーポイント形式の資料など、異なった形式のファイルを結合できるものではなかった。
特許文献１には、編集者の作業付加を軽減する目的で、電子メールを利用した文書編集システムが開示されている。この文書編集システムは、執筆者が編集者から電子メールにより受け取った担当リストおよび原稿テンプレートに従い執筆および原稿の受け渡しを行うことにより、自動的に原稿を結合させる構成である。
【発明の概要】
【発明が解決しようとする課題】
【０００３】
しかしながら、特許文献１に開示されている従来技術は、確かに編集者が分担リストを作成し、担当者に原稿作成を依頼して、担当者が電子メールに出来上がった原稿を添付して送付し、メールを受け取った文書編集ソフトが自動的に文書を結合する点では本発明と類似しているが、分担の変更に対応できず、またテキストファイル以外の形式のファイルに対応できないという問題は解消できていない。
本発明は、かかる課題に鑑みてなされたものであり、会議情報システムサーバ上で分担リストの作成、変更と、分担リストに対して資料の登録、更新、削除と、自動で登録された複数の形式の資料の結合と、また資料が更新されたときに自動で資料の再結合を行うことにより、一度割り当てられた分担の変更に柔軟に対応でき、かつテキストファイルだけでなく複数の形式の資料を結合できる会議情報システムを提供することを目的とする。
【課題を解決するための手段】
【０００４】
本発明はかかる課題を解決するために、請求項１は、会議情報システムサーバからＴｏＤｏ完了通知、資料結合通知を受け取る際に使用されるメールソフト、及び会議の開催者が会議情報システムサーバにアクセスし、会議ページの作成、ＴｏＤｏリストの作成・依頼・変更・資料の閲覧を行う際に使用されるブラウザを有する開催者端末と、会議情報システムサーバからＴｏＤｏ依頼・変更通知を受け取る際に使用され、又は、会議情報システムサーバに返信メールを行い会議情報システムサーバにアクションを起こさせる際に使用されるメールソフト、及びＴｏＤｏ依頼通知に従い担当者が資料作成する際に使用される資料作成ソフトを有する担当者端末と、開催者へ各種通知を送受信する際に使用されるメールソフト、開催者が会議ページの作成、編集、閲覧する際に使用される会議ページ操作部、開催者、担当者への各種通知を作成する際に使用され、担当者からの返信メールを解析し次のアクションを起こす際に使用されるメールの作成、解析部、開催者がＴｏＤｏリストの作成、編集、ステータス管理を行う際に使用され、担当者からの返信メールによりＴｏＤｏリストに変更を行う際に使用され、ＴｏＤｏのステータス更新、資料更新を監視し結合資料の更新を行う際に使用されるＴｏＤｏリスト操作部、開催者、担当者のメールアドレスを取得・変更する際に使用されるユーザ情報操作部、資料の登録、更新、削除、閲覧、形式変換、結合を行う際に使用されるファイル操作部、及び会議情報を管理する際に使用され、ユーザ情報を管理する際に使用され、ＴｏＤｏリストを管理する際に使用され、登録資料を管理する際に使用されるデータベースを有する会議情報システムサーバと、を備えたことを特徴とする。
【０００５】
請求項２は、担当者からの返信メールの本文の有無および内容により前記会議情報システムサーバのＴｏＤｏリスト情報のステータスを変化させることを特徴とする。
請求項３は、担当者からの返信メールのカーボンコピーの内容により、前記会議情報システムサーバのＴｏＤｏリスト情報の担当者の追加、および担当者のサブメールアドレスの追加を行うことを特徴とする。
請求項４は、担当者からの返信メールのあて先の内容により、前記会議情報システムサーバの資料の登録、取得、更新、削除を行うことを特徴とする。
請求項５は、前記会議情報システムサーバのＴｏＤｏリスト情報のステータスを変化させること、又はＴｏＤｏリスト情報の担当者の追加、および担当者のサブメールアドレスの追加を行うこと、又は資料の登録、取得、更新、削除を行うことの少なくとも２つ以上を持つことを特徴とする。
【発明の効果】
【０００６】
本発明によれば、会議情報システムサーバ上でＴｏＤｏ（分担）リストの操作を行えるようにしたので、編集者がＴｏＤｏリストの作成および変更を行うことが容易にできる。また一度依頼されたＴｏＤｏ、およびＴｏＤｏリストの変更が即編集者、担当者に周知されるようにしたので、編集者、担当者ともにＴｏＤｏリスト変更に関する通知を手動で行う必要がなく、また通知忘れを減少することができる。
また、資料の更新を感知して自動で結合資料の更新が行える仕組みを構築したので、資料の修正を行う際、編集者が再度担当リストと原稿テンプレートを作り直す、あるいは編集者が手動で修正箇所を置き換えていく手間を省くことができる。
また、原稿テンプレートを廃し、担当者が作成した資料を登録できるようにしたので、ＴｏＤｏリストの変更の際、編集者が原稿テンプレートを作り直す手間を省くことができる。
また、資料の結合方法を、原稿テンプレートを使った文字列のはめ込みではなく、資料の形式を統一してから順番に結合するという方法に変更したので、テキスト形式以外の資料でも結合することができる。
また、担当者は自分のマシン環境で作成できる形式を選択できるので、担当者の端末環境への制限を緩和することができる。
また、画像やプレゼンテーション資料も結合できるので、会議資料として表現力を豊かにすることができる。
【図面の簡単な説明】
【０００７】
【図１】本発明の実施形態に係る会議情報システムのシステム構成を示すブロック図である。
【図２】一人の担当者がＴｏＤｏを最短で完了させる流れについて説明する図である。
【図３】グループのＴｏＤｏ全完了から資料結合の流れについて説明するフローチャートである。
【図４】結合後の資料のイメージについて説明する図である。
【図５】会議ページについて説明する図である。
【図６】ＴｏＤｏリストについて説明する図である。
【図７】ＴｏＤｏの追加について説明する図である。
【図８】ＴｏＤｏの追加について説明する図である。
【図９】ＴｏＤｏの追加について説明する図である。
【図１０】ＴｏＤｏの依頼について説明する図である。
【図１１】ＴｏＤｏの依頼について説明する図である。
【図１２】ＴｏＤｏの依頼について説明する図である。
【図１３】ＴｏＤｏの一括依頼について説明する図である。
【図１４】ＴｏＤｏの一括依頼について説明する図である。
【図１５】ＴｏＤｏの一括依頼について説明する図である。
【図１６】ＴｏＤｏ依頼メール例（グループに所属しないＴｏＤｏ）について説明する図である。
【図１７】ＴｏＤｏ依頼メール例（グループに所属する場合）について説明する図である。
【図１８】ＴｏＤｏリストの編集にかかわるボタンについて説明する図である。
【図１９】ＴｏＤｏのステータス説明について説明する図である。
【図２０】ＴｏＤｏの編集について説明する図である。
【図２１】ＴｏＤｏの編集について説明する図である。
【図２２】ＴｏＤｏの編集について説明する図である。
【図２３】ＴｏＤｏの削除について説明する図である。
【図２４】ＴｏＤｏの削除について説明する図である。
【図２５】ＴｏＤｏの削除について説明する図である。
【図２６】ＴｏＤｏの取り消しについて説明する図である。
【図２７】ＴｏＤｏの取り消しについて説明する図である。
【図２８】ＴｏＤｏの取り消しについて説明する図である。
【図２９】ＴｏＤｏの修正依頼について説明する図である。
【図３０】ＴｏＤｏの修正依頼について説明する図である。
【図３１】ＴｏＤｏの修正依頼について説明する図である。
【図３２】ＴｏＤｏの取り消し解除について説明する図である。
【図３３】ＴｏＤｏの取り消し解除について説明する図である。
【図３４】ＴｏＤｏの取り消し解除について説明する図である。
【図３５】ＴｏＤｏの順番の入れ替えについて説明する図である。
【図３６】ＴｏＤｏの順番の入れ替えについて説明する図である。
【図３７】開催者によるＴｏＤｏ変更によるサーバのアクション一覧の図である。
【図３８】開催者によるＴｏＤｏのステータス遷移について説明する図である。
【図３９】担当者からの返信メールによるサーバのアクション一覧について説明する図である。
【図４０】ユーザ情報テーブルについて説明する図である。
【図４１】サーバがもつ４つのアドレスのあて先にかかわらず共通の処理を行う部分のフローチャートである。
【図４２】資料の登録を行うｔａｓｋ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。
【図４３】資料の閲覧を行うｔａｓｋ＋ｇｅｔ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。
【図４４】資料の更新を行うｔａｓｋ＋ｐｕｔ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。
【図４５】資料の削除を行うｔａｓｋ＋ｄｅｌｅｔｅ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。
【図４６】担当者によるＴｏＤｏのステータス遷移について説明する図である。
【図４７】開催者、担当者によるＴｏＤｏのステータス遷移について説明する図である。
【図４８】添付資料について説明する図である。
【図４９】結合資料の更新の流れについて説明するフローチャートである。
【発明を実施するための形態】
【０００８】
以下、本発明を図に示した実施形態を用いて詳細に説明する。但し、この実施形態に記載される構成要素、種類、組み合わせ、形状、その相対配置などは特定的な記載がない限り、この発明の範囲をそれのみに限定する主旨ではなく単なる説明例に過ぎない。
【０００９】
図１は、本発明の実施形態に係る会議情報システムのシステム構成を示すブロック図である。この会議情報システム１００は、会議情報システムサーバ１０１からＴｏＤｏ完了通知、資料結合通知等を受け取る際に使用されるメールソフト１１３、及び開催者が会議情報システムサーバ１０１にアクセスし、会議ページの作成、ＴｏＤｏリストの作成・依頼・変更・資料の閲覧を行う際に使用されるブラウザを有する開催者端末１０５と、
会議情報システムサーバ１０１からＴｏＤｏ依頼・変更通知など各種通知を受け取る際に使用され、又は、会議情報システムサーバ１０１に返信メールを行い会議情報システムサーバ１０１にアクションを起こさせる際に使用されるメールソフト１１５、及びＴｏＤｏ依頼通知に従い担当者が資料作成する際に使用される資料作成ソフト１１６を有する担当者端末１０２、１０３と、開催者へ各種通知を送受信する際に使用されるメールソフト１０６、開催者が会議ページの作成、編集、閲覧する際に使用される会議ページ操作部１１０、開催者、担当者への各種通知を作成する際に使用され、担当者からの返信メールを解析し次のアクションを起こす際に使用されるメールの作成、解析部１０７、開催者がＴｏＤｏリストの作成、編集、ステータス管理を行う際に使用され、担当者からの返信メールによりＴｏＤｏリストに変更を行う際に使用され、ＴｏＤｏのステータス更新、資料更新を監視し結合資料の更新を行う際に使用されるＴｏＤｏリスト操作部１１１、開催者、担当者のメールアドレスを取得・変更する際に使用されるユーザ情報操作部１０８、資料の登録、更新、削除、閲覧、形式変換、結合を行う際に使用されるファイル操作部１１２、及び会議情報を管理する際に使用され、ユーザ情報を管理する際に使用され、ＴｏＤｏリストを管理する際に使用され、登録資料を管理する際に使用されるデータベース１０９を有する会議情報システムサーバ１０１とを備えて構成されている。また、開催者端末１０５、担当者端末１０２、１０３、会議情報システムサーバ１０１はネットワーク１０４で繋がっており、開催者端末１０５、担当者端末１０２、１０３には入力装置（キーボード、マウス等）と出力装置（モニタ）が備えられている。本実施形態においてＴｏＤｏとは、担当者に業務を割り当てることである。
【００１０】
図２は、一人の担当者がＴｏＤｏを最短で完了させる流れについて説明する図である。ここでは開催者が会議ページ上にＴｏＤｏリストを作成してから、一人の担当者がＴｏＤｏを最短で完了させる流れを見ていく。ここで最短といっているのは本事例ではステータスの遷移する方向は一方向に定まっていないからである（図３８、図４６、図４７参照）。
開催者（仮に開催者Ａとする）２０１は会議情報システムサーバ（以下サーバと略す）１０１にブラウザからアクセスしてログインする。
１．開催者はサーバ１０１上に会議ページ（図５）を作成し、ＴｏＤｏリスト２０２（図６）を作成する。ＴｏＤｏリスト２０２を作成し終わったら、作成したＴｏＤｏの依頼手続きを踏む。（図１０〜１２）
２．サーバはＴｏＤｏリスト２０２の情報を元にＴｏＤｏ依頼メール（図１６）を作成し、ＴｏＤｏの担当者（仮に担当者ａとする）に送信する。
３．担当者ａ２０３はサーバから届いた上記依頼メールにしたがって資料を作成する。
４．担当者ａ２０３は作成した資料を上記依頼メールの返信メールに添付し送信する。返信メールの本文には資料ができたがった旨のコメントを記入しておく。
５．サーバ１０１は担当者２０３からのメールを解析し（図４１−４５）、資料を該当会議ページに登録し、ＴｏＤｏのステータスを完了（図１９）にする。
６．サーバ１０１は開催者Ａ２０１にＴｏＤｏが完了した旨のメールを送信する。
開催者Ａ２０１は担当者ａ２０３だけでなく担当者ｂ、担当者ｃ、・・・といった複数の担当者に同時に依頼を行うことができる。
【００１１】
図３は、グループのＴｏＤｏ全完了から資料結合の流れについて説明するフローチャートである。ＴｏＤｏリストのＴｏＤｏにはグループが設定でき、後で資料を結合したい場合は結合したい資料のＴｏＤｏのグループをあらかじめ同じにしておく（図６）。以下にあるグループのＴｏＤｏが全て完了してから資料を結合するまでの流れを示す。
図２の流れを経てＴｏＤｏリストのあるグループのＴｏＤｏのステータスが全て完了になる（Ｓ３０１）。上記グループのすべてのＴｏＤｏの資料のコピーをとり、そのコピーを一つの形式に変換する（Ｓ３０２）。ここで変換する形式とは、たとえばＰＤＦ形式などである。一つの形式になったコピー資料をＴｏＤｏリストの順番で結合し、結合資料を作成する。もとになったコピー資料は消去する（Ｓ３０３）。上記結合資料を会議ページに登録する（Ｓ３０４）。開催者に上記結合資料が登録されたことを通知する（Ｓ３０５）。
【００１２】
図４は、結合後の資料のイメージについて説明する図である。ここでは複数の形式の資料の結合によって作成された結合資料の中身を見ていく。図の資料ＡのＴｏＤｏと資料ＢのＴｏＤｏはＴｏＤｏリストのなかで同一グループに属し、そのグループのＴｏＤｏは他に存在しないとする。そしてＴｏＤｏリストの中の順番は上から資料ＡのＴｏＤｏ、資料ＢのＴｏＤｏとする。ここで上の二つＴｏＤｏの資料が会議ページに登録され、それらのＴｏＤｏのステータスが完了になり、図３の手順に従って資料Ａと資料Ｂを結合したとする。図４のように資料Ａを全２ページのＰＤＦ形式の資料とし、資料Ｂを全３ページの拡張子ｐｐｔの形式の資料とした場合、ＡとＢの結合資料は全５ページのＰＤＦ形式の資料となり、結合資料の１、２ページは資料Ａの１、２ページ、結合資料の３、４、５ページは資料Ｂの１、２、３ページとなる。同じ形式の資料の結合は、形式変換をせずそのまま結合してもよいし、あるいは形式をＰＤＦ形式にそろえてから結合してもよい。また結合資料の形式をこの説明ではＰＤＦ形式にしているが、他の形式にしてもよい。
【００１３】
図５は、会議ページについて説明する図である。ここでは開催者が作成する会議ページのイメージを示す。今回の実施例において会議ページに必須な項目は以下の通りである。
１）ＴｏＤｏリスト
・会議開催前に担当者に行って欲しいＴｏＤｏを表示する部分（図６）。
・本実施例において開催者はこの領域でＴｏＤｏを作成・依頼・編集・閲覧などをする。
２）添付資料
・担当者により登録された資料のアイコンを表示する部分（図４８）。
・本実施例において開催者が資料を閲覧する方法の一つが、この領域から資料を閲覧する方法である。
他にも会議ページには図５に示している以下の項目があってもよく、それぞれは項目の名前が示す会議の情報を表示する部分になる。
・書誌事項
・アジェンダ
・結論
【００１４】
図６は、ＴｏＤｏリストについて説明する図である。ここでは会議ページ内のＴｏＤｏリストの画面について説明する。この領域にはＴｏＤｏを編集するためのボタンが配置されていて開催者が簡単に編集できるようになっている。
ＴｏＤｏは表の形で管理され、グループ６０１、担当者６０２、納期６０４、ステータス６０５の属性を持つ。
・グループ６０１はＴｏＤｏのグループを示す。ＴｏＤｏの資料を結合したい場合はＴｏＤｏのグループをあらかじめ同じにしておく。
・担当者６０２はＴｏＤｏを行う人を示す。担当者を含むユーザはサーバに図４０のように登録されている。
・アイテム６０３は担当者が行うＴｏＤｏの内容を示す。
・納期６０４は担当者がアイテムを終わらせなければならない期限を示す。
・ステータス６０５はＴｏＤｏの状態を示す。ステータスの説明は図１９で行う。
【００１５】
図７−９は、ＴｏＤｏの追加について説明する図である。ここでは開催者が会議ページ上で、ＴｏＤｏリストを作成する場面を想定している。図７−９の流れでＴｏＤｏの追加を行う。図７のＴｏＤｏの追加ボタン７０１を押すと、新規ＴｏＤｏ作成ボックス８０１が表示される（図８）。ボックス８０１にはＴｏＤｏの属性であるグループ８０２、担当者８０３、アイテム８０４、納期８０５を記入することができる。ここに以下の値を記入してボックスの作成ボタン８０６を押すと、作成したＴｏＤｏがＴｏＤｏリストの一番下に追加される（図９）。追加されたＴｏＤｏのステータスはデフォルトで”依頼前”になる。
・記入する値
グループ＝”−”
担当者＝”担当者ａ”
アイテム＝”ｏｏｏの資料をアップお願いします”
納期＝”２００９／３／３１”
【００１６】
図１０−１２は、ＴｏＤｏの依頼について説明する図である。ここでは開催者がＴｏＤｏリストの出来上がったＴｏＤｏの依頼を行う場面を想定している。ＴｏＤｏが出来上がっているとは、ＴｏＤｏの担当者１００２、アイテム１００３、納期１００４が記入されている状態をさし、その状態のとき依頼ボタン１００６が表示される（図１０）。図１０のように依頼ボタン１００６を押すと、依頼確認ボックス１１０１が表示される（図１１）。ボックス１１０１の中身を確認し依頼内容に相違なければボックス内の依頼ボタン１１０２を押す。ボックス１１０１内の依頼ボタン１１０２を押すと画面上ではＴｏＤｏのステータスが”依頼中”に変化し、依頼ボタン１１０２が消え、取り消しボタン１２０１が表示される（図１２）。サーバはこのときＴｏＤｏのステータスを”依頼中”に変化させ、図１６のような依頼通知を作成し担当者に送信する。
【００１７】
図１３−１５は、ＴｏＤｏの一括依頼について説明する図である。ここでは開催者がＴｏＤｏリストの出来上がった全てのＴｏＤｏを一括で依頼する場面を想定している。図１３−１５の流れでＴｏＤｏの一括依頼を行う。図１３の依頼前の全てのＴｏＤｏに依頼メールを出すボタン１３０１を押すと、ＴｏＤｏの依頼確認ボックス１４０１が表示される（図１４）。確認ボックス１４０１の依頼ボタン１４０２を押すと、サーバは依頼前の全てのＴｏＤｏのステータスを依頼中にし、各担当者にＴｏＤｏ依頼メールを送信する（図１５）。上で紹介したＴｏＤｏの依頼と基本的に同じで、違いは複数のＴｏＤｏを一括して依頼できるかどうかである。
【００１８】
図１６はＴｏＤｏ依頼メール例（グループに所属しないＴｏＤｏ）について説明する図である。ここではサーバが担当者あてに作成するＴｏＤｏ依頼メールの中身を見ていく。ここで開催者は開催者ａ、担当者は担当者ｂとする。上記ＴｏＤｏはグループに属していないとする。以下に依頼メールの中身を説明する。会議ＩＤとＴｏＤｏＩＤはそれぞれ会議ページとＴｏＤｏのＩＤである。
・ヘッダ１６０１にはＭｅｓｓａｇｅ−ＩＤ、Ｔｏ、Ｆｒｏｍ、Ｒｅｐｌｙ−Ｔｏ、Ｓｕｂｊｅｃｔを記入している。
・Ｍｅｓｓａｇｅ−ＩＤとはメールのＩＤであり、他のメールと区別するためのものである。ここでは図のように会議ＩＤとＴｏＤｏＩＤと組み合わせて作成し、Ｍｅｓｓａｇｅ−ＩＤだけから会議ＩＤとＴｏＤｏＩＤが読み取れるようにしておく。これは後にサーバが依頼メールの返信メールを受け取ったときに、返信メールのＲｅｆｅｒｅｎｃｅｓの中のＭｅｓｓａｇｅ−ＩＤを解析して、返信メールがどの会議のどのＴｏＤｏへの返信なのかを判断できるようにするためである。Ｒｅｆｅｒｅｎｃｅｓとは以前やりとりがあったメールのＭｅｓｓａｇｅ−ＩＤを溜め込んだもので、新規作成したメールを受け取ったときには空だが、メールを返信しあうたびにＲｅｆｅｒｅｎｃｅｓに一つ前のメールのＭｅｓｓａｇｅ−ＩＤが追加されていく仕組みになっている。
【００１９】
・Ｔｏとはメールのあて先である。ここでは担当者に依頼を行うために担当者のメインメールアドレスを記入している。
・Ｆｒｏｍとはメールの差し出し人のアドレスのことである。実際のメールの差出元はサーバだが担当者がメールを受け取ったときに、依頼を行ったのが開催者であることが簡単にわかるように、ここには開催者のメインメールアドレスを記入している。
・Ｒｅｐｌｙ−Ｔｏとは、Ｒｅｐｌｙ−Ｔｏを指定してない通常のメールの返信はＦｒｏｍのアドレスに返信するものだが、Ｒｅｐｌｙ−Ｔｏを指定しておくことでＲｅｐｌｙ−Ｔｏに記入されたアドレスにメールを返信するよう指定するものである。ここではメールの返信はサーバに届いて欲しいのでサーバの資料を受け取るアドレスを記入している。
・Ｓｕｂｊｅｃｔはメールの件名である。ここではＴｏＤｏ依頼であることとアイテム名、会議名がわかるように記入している。
・本文には担当者に依頼したＴｏＤｏを記入している。
【００２０】
図１７は、ＴｏＤｏ依頼メール例（グループに所属する場合）について説明する図である。ここでは図１６と同様にサーバが担当者あてに作成するＴｏＤｏ依頼メールの中身を見ていく。図１７と図１６の違いは図１７のＴｏＤｏがグループに属しているという点である。ＴｏＤｏがグループに属している場合でも基本的にはグループに属していない場合（図１６）と同様である。違いはメール本文にグループのＴｏＤｏが全て記入されている点である。これはグループに属するＴｏＤｏの資料は後にＴｏＤｏリストの上から順に結合することになっているからである。たとえば図１７のメール本文のＴｏＤｏリストに従って資料を結合した場合、結合した資料の中で担当者ｂの資料が前にあり、担当者ｃの資料が後になる（図４）。
【００２１】
図１８は、ＴｏＤｏリストの編集にかかわるボタンについて説明する図である。これまでにＴｏＤｏリストのＴｏＤｏの追加と依頼に関するボタンの説明を行ってきたが、図１８から図３８で残りのボタンおよび操作について説明する。それらのボタンおよび操作はＴｏＤｏリストの編集にかかわるものであり、図１８で全体的なボタンおよび操作説明を行う。
・編集ボタン１８０１は、ＴｏＤｏを編集する際に使用される（図２０−２２）。編集を行うと編集内容によって異なるＴｏＤｏ変更通知が関係者（主に担当者）に送信される。ＴｏＤｏがどのステータスのときでも編集ボタンは表示される。
・削除ボタン１８０２は、ＴｏＤｏを削除する際に使用される（図２３−２５）。削除を行うとステータスが依頼中、期限過ぎ、完了の場合、依頼取り消しメールを担当者に送信する。ＴｏＤｏがどのステータスのときでも削除ボタンは表示される。
・取り消しボタン１８０３は、ＴｏＤｏ依頼を取り消しする際に使用される（図２６−２８）。取り消しを行うと担当者に依頼取り消しメールが送信され、ステータスが取り消しになる。ステータスが依頼中、期限過ぎ、完了のとき取り消しボタンは表示される。
・修正依頼ボタン１８０４は、ＴｏＤｏの資料を修正依頼する際に使用される（図２９−３１）。修正依頼を行うと、コメントをアイテム欄に追加した修正依頼メールを担当者に送信する。ステータスが完了の場合、依頼中に変更する。ステータスが依頼中、期限過ぎ、完了でなおかつ資料が登録されているとき修正依頼ボタンが表示される。
・取り消し解除ボタン１８０５は、取り消しされたＴｏＤｏの取り消しを解除する際に使用される（図３２−３４）。取り消し解除を行うとステータスを依頼中に戻すことができる。ステータスが取り消しのとき取り消し解除ボタンが表示される。
・ボタンではないが、ドラッグアンドドロップでＴｏＤｏの順番を入れ替えることが可能（図３５−３６）。資料の結合順番が入れ替わる場合、グループの担当者に変更通知が送信される。
【００２２】
図１９は、ＴｏＤｏのステータス説明について説明する図である。図１９ではＴｏＤｏのステータス一覧を紹介している。
・依頼前１９０１とはＴｏＤｏが作成されてからまだ依頼をされてないことを示す。
・依頼中１９０２とはＴｏＤｏが担当者に通知され、担当者の結果待ちの状態を示す。資料が登録されているがステータスを完了にしていない状態もここに含まれる。
・完了１０３とは、担当者から資料が登録され、ＴｏＤｏが完了した状態を示す。同一グループのＴｏＤｏが全て完了したらグループの資料を結合する。
・取り消し１９０４とは開催者が一度依頼したＴｏＤｏを取り消した状態を示す。
・期限過ぎ１９０５とはＴｏＤｏが依頼中のまま納期が過ぎてしまった状態を示す。
【００２３】
図２０−２２は、ＴｏＤｏの編集について説明する図である。ここでは開催者が一度依頼したＴｏＤｏを編集する場面を想定している。図２０の編集ボタン２００１を押すと、ＴｏＤｏ編集ボックス２１０１が表示される（図２１）。ボックス２１０１の中はグループ２１０１、担当者２１０３、アイテム２１０４、納期２１０５が編集できるようになっていて初期値には元となったＴｏＤｏの値が記入されている。担当者を”担当者ｅ”から”担当者ａ”、納期を”２００９／３／１０”から”２００９／３／３１”に変更して作成ボタンをおすと、編集した内容２２０１がＴｏＤｏに反映される（図２２）。ＴｏＤｏ変更の際、変更内容に応じた変更通知が関係者に送信される。今回は担当者が変更しているので新しい担当者ａと元の担当者ｅに担当が変更する旨と共に納期が変更する旨の通知が送信される。
【００２４】
図２３−２５は、ＴｏＤｏの削除について説明する図である。ここでは開催者が一度依頼したＴｏＤｏを削除する場面を想定している。図２３の削除ボタン２３０１を押すと、削除の確認ボックス２４０１が表示される（図２４）。確認ボックス２４０１の削除ボタン２４０２を押すとリストからＴｏＤｏを削除する（図２５）。依頼中、期限過ぎ、完了のＴｏＤｏを削除した場合、ＴｏＤｏの依頼取り消しメールが担当者に送信される。
【００２５】
図２６−２８は、ＴｏＤｏの取り消しについて説明する図である。ここでは開催者が一度依頼したＴｏＤｏを取り消しする場面を想定している。図の２６の取り消しボタン２６０１を押すと、取り消し確認ボックス２７０１が表示される（図２７）。確認ボックス２７０１のなかの取り消しボタン２７０２を押すと、ＴｏＤｏのステータスが取り消しになる（図２８）。依頼中、期限過ぎ、完了のＴｏＤｏを取り消した場合、ＴｏＤｏの依頼取り消しメールが担当者に送信される。
【００２６】
図２９−３１は、ＴｏＤｏの修正依頼について説明する図である。ここでは開催者が一度完了したＴｏＤｏに修正依頼する場面を想定している。図２９の修正依頼ボタン２９０１を押すと、修正依頼ボックス３００１が表示される（図３０）。修正依頼ボックス３００１にはコメントを記入する欄３００２があり、そこに”資料ｘｘｘの５ページに去年のデータを追加してください。”と記入して修正依頼ボタン３００３を押すと、コメントがアイテムの末尾に追加されて、ステータスが依頼中になる（図３１）。また、担当者に修正依頼通知が送信される。
【００２７】
図３２−３４は、ＴｏＤｏの取り消し解除について説明する図である。ここでは開催者が一度取り消ししたＴｏＤｏの取り消し解除を行う場面を想定している。図３２の取り消し解除ボタン３２０１を押すと、取り消し解除確認ボックス３３０１が表示される（図３３）。確認ボックス３３０１の取り消し解除ボタン３３０２を押すと、ＴｏＤｏのステータスが依頼前に変化する（図３４）。
【００２８】
図３５−３６は、ＴｏＤｏの順番の入れ替えについて説明する図である。ここでは開催者が同じグループに属するＴｏＤｏの順番を入れ替える場面を想定している。図３５のようにリストの３行目を１行目と２行目の間にドラッグアンドドロップすると、リストの３行目と２行目の順番が入れ替わる（図３６）。同じグループ内での順番の移動が証した際にはグループの担当者に順番変更通知が操船される。
【００２９】
図３７は、開催者によるＴｏＤｏ変更によるサーバのアクション一覧の図である。この図は開催者のＴｏＤｏリスト変更によりサーバが取りうるアクションを表にしたものである。表の左２列が開催者が行う変更およびそのときのＴｏＤｏのステータスをあらわし、表の右の列が左２列の状況のときのサーバが行うアクションをあらわしている。たとえば１行目の変更内容が”全ての変更”でステータスが”依頼前、取り消し”で通知内容およびアクションが”通知されない”とは”ステータスが依頼前、取り消しのときの全ての変更は、誰にも通知しない”ということを示している。２行目の変更内容が”担当者変更”でステータスが”依頼中、期限過ぎ、完了”で通知内容およびアクションが”新しい担当者と元の担当者に担当者変更通知”とは”ステータスが依頼中、期限過ぎ、完了のときの担当者変更は、新しい担当者と元の担当者に担当者変更通知を送る。”ということを示している。５行目の変更内容が”ＴｏＤｏの追加”で通知内容およびアクションが”通知されない。ＴｏＤｏのステータスは依頼前になる。”とは”ＴｏＤｏの追加は、誰にも通知されない。ＴｏＤｏのステータスを依頼前にする。”ということを示している。
【００３０】
図３８は、開催者によるＴｏＤｏのステータス遷移について説明する図である。この図は開催者のＴｏＤｏリスト変更によりとりうるＴｏＤｏのステータス遷移を表した図である。図の矢印はステータス遷移の方向を表しており、矢印に伴った文字列はそのステータス遷移を引き起こす操作を表している。たとえばＴｏＤｏの追加を行うとステータスが依頼前のＴｏＤｏができ、ここからステータス遷移が生じる。ステータスが依頼前のときはＴｏＤｏの編集によってはステータスが遷移せず、ＴｏＤｏ依頼によってステータスが依頼中に遷移する。ステータスが依頼中のときは、ＴｏＤｏの編集およびＴｏＤｏの修正依頼によってはステータスが遷移せず、ＴｏＤｏの取り消しによりステータスが取り消しになる。また例外的に時間経過によってステータスが期限過ぎになる。
【００３１】
図３９は、担当者からの返信メールによるサーバのアクション一覧について説明する図である。サーバは４つのアドレスを持ち、担当者はその中のどのアドレスに返信するかによってサーバに実行してもらうアクションを変化させることができる。また４つのアドレスは資料のＣＲＵＤ（新規作成、閲覧、更新、削除）に対応している。
・ｔａｓｋ＠｛会議システムドメイン｝
資料の新規登録
サーバからのＴｏＤｏ依頼メールのデフォルトの返信先であり、残り３つのアドレスに返信する際はこのアドレスに＋ｇｅｔ、＋ｐｕｔ、＋ｄｅｌｅｔｅを手動で書き加えて送信する。
・ｔａｓｋ＋ｇｅｔ＠｛会議システムドメイン｝
資料の閲覧
・ｔａｓｋ＋ｐｕｔ＠｛会議システムドメイン｝
資料の更新
・ｔａｓｋ＋ｄｅｌｅｔｅ＠｛会議システムドメイン｝
資料の削除
なお、上の４つのアドレス名は例であるので実際に上のようである必要はない。
【００３２】
この図は担当者からの返信メールによってサーバが取りうるアクションを表にしたものである。表の左２列は担当者が返信メールを送る際の返信先および返信内容をあらわし、表の右列が左２列の状況のときのサーバ行うアクションをあらわしている。たとえば１行目の返信先が”ｔａｓｋ＠｛システムドメイン｝”で返信内容が”資料を添付、本文に手を加えない”でサーバのアクションが”返信メールのＲｅｆｅｒｅｎｃｅｓから該当会議と該当ＴｏＤｏを求め、添付資料を該当会議および該当ＴｏＤｏと関連付けて登録する。”とは”ｔａｓｋ＠｛システムドメイン｝あての返信メールに作成した資料を添付し、本文に手を加えないで送信するとサーバは返信メールのＲｅｆｅｒｅｎｃｅｓから該当会議と該当ＴｏＤｏを求め、添付資料を該当会議および該当ＴｏＤｏと関連付けて登録する。”ということを表している。
２行目の返信先が”ｔａｓｋ＠｛システムドメイン｝”で返信内容が”  資料を添付し、本文に「作成しました」などのコメントを加える”でシステムのアクションが”返信メールのＲｅｆｅｒｅｎｃｅｓから該当会議と該当ＴｏＤｏを求め、添付資料を該当会議および該当ＴｏＤｏと関連付けて登録する。ＴｏＤｏのステータスを完了にする”とは”ｔａｓｋ＠｛システムドメイン｝あての返信メールに資料を添付し、本文に「作成しました」などのコメントを加えて送信するとサーバは返信メールのＲｅｆｅｒｅｎｃｅｓから該当会議と該当ＴｏＤｏを求め、添付資料を該当会議および該当ＴｏＤｏと関連付けて登録し、該当ＴｏＤｏのステータスを完了にする”ということを表している。
３行目の返信先が”全て”で返信内容が”ＣＣにアドレスを記入”でシステムのアクションが”ＣＣ内のアドレスと同じものがユーザ情報テーブルの中にあればそのユーザをＴｏＤｏの担当者に加える。なければ担当者のサブメールアドレスにＣＣのアドレスを追加する。”とは”送信先が４つのアドレスのどれであっても返信メールのＣＣにアドレスを記入して送信すると、サーバはＣＣのアドレスと同じものがユーザ情報テーブルの中にあればそのユーザをＴｏＤｏの担当者に加える。なければ担当者のサブメールアドレスにＣＣのアドレスを追加する。“ということを表している。
【００３３】
図４１−４５にてサーバが返信メールを受け取った際のフローチャートについて詳しく説明する。図４０は、ユーザ情報テーブルについて説明する図である。図４０ではサーバが管理するユーザ情報について説明する。
・管理ＩＤ４００１はユーザ情報を管理するＩＤである。
・ユーザＩＤ４００２はユーザがサーバにログインするときのＩＤである。
・パスワード４００３はユーザがサーバにログインするときのパスワードである。
・メインメールアドレス４００４とはサーバからユーザ宛にメールが送られる際のユーザのアドレスである。またサーバの受け取り可能メールアドレスになる。
・サブメールアドレス４００５とはサーバがユーザからメールを受け取る際の受け取り可能なメインメールアドレス以外のアドレスである。
・通称４００６とはＴｏＤｏリストの担当者にユーザの通称が書かれたときにサーバがユーザを特定するためのものである。
サブメールアドレスと通称は複数持つことができる。
【００３４】
図４１−４５は、会議システムドメインに届いたメールの処理について説明するフローチャートである。図４１−４５ではサーバが担当者から受け取ったメールを解析し、処理を行うフローチャートを見ていく。
図４１はサーバがもつ４つのアドレスのあて先にかかわらず共通の処理を行う部分のフローチャートである。各アドレスの個別処理は赤い四角に囲まれた「各アドレスの個別処理を行う」で行われる。資料の登録を行うｔａｓｋ＠｛会議システムドメイン｝に届いたメールの個別処理は図４２で説明する。資料の閲覧を行うｔａｓｋ＋ｇｅｔ＠｛会議システムドメイン｝に届いたメールの個別処理は図４３で説明する。資料の更新を行うｔａｓｋ＋ｐｕｔ＠｛会議システムドメイン｝に届いたメールの個別処理は図４４で説明する。資料の削除を行うｔａｓｋ＋ｄｅｌｅｔｅ＠｛会議システムドメイン｝に届いたメールの個別処理は図４５で説明する。以下４つのアドレスにかかわらず共通の処理を行う部分のフローチャートを説明する（図４１）。
【００３５】
はじめにサーバが担当者からメールを受け取る。受け取ったメールのヘッダのＲｅｆｅｒｅｎｃｅｓのＭｅｓｓａｇｅ−ＩＤが図１６のＭｅｓｓａｇｅ−ＩＤと同じ｛会議ＩＤ｝−｛ＴｏＤｏＩＤ｝−｛時刻｝＠｛会議システムドメイン｝という形式となっているか判断し（Ｓ４１０１）、もしその形式でないときはエラーメールを返信して処理を終了する（Ｓ４１０９）。もし上の形式になっていれば処理を続行し、Ｍｅｓｓａｇｅ−ＩＤから会議ＩＤとＴｏＤｏＩＤを取得する（Ｓ４１０２）。次に取得したＴｏＤｏＩＤからＴｏＤｏの担当者を割り出し（Ｓ４１０３）、そのユーザ情報からメインメールアドレスおよびサブメールアドレスを取得する。その中に届いたメールの差し出し元アドレスとマッチするものがあるかどうかを判定する。もしマッチするアドレスがなければ、エラーメールを送信して処理を終了する。もしマッチするアドレスが存在したら処理を続行し、受け取ったメールのＣＣが空であるかどうか判定する（Ｓ４１０４）。もし空であるならば各アドレスの個別処理を行い（Ｓ４１０７）、処理を終了する。もし空でないならばそのＣＣに記入されているメールアドレスとマッチするものがユーザ情報に存在するか判定する（Ｓ４１０５）。もし存在するならばＣＣとマッチしたメールアドレスをもつユーザを取得したＴｏＤｏの担当者に加え（Ｓ４１０６）、各アドレスの個別処理を行い（Ｓ４１０７）、処理を終了する。もし存在しないならば、メールを送信したＴｏＤｏの担当者のサブメールアドレスにＣＣのアドレスを追加し（Ｓ４１０８）、各アドレスの個別処理を行い（Ｓ４１０７）、処理を終了する。
【００３６】
図４２は、資料の登録を行うｔａｓｋ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。図４２は、ｔａｓｋ＠｛会議システムドメイン｝に届いたメールの個別処理のフローチャートである。まず届いたメールに添付資料が存在するかどうかを判定し（Ｓ４２０１）、もし添付資料が存在しないならば、”メール本文に依頼メールの引用以外の内容が記入されているか？”の処理に進む。もし添付資料が存在するならば、共通処理で取得した会議ＩＤとＴｏＤｏＩＤに関連付けて資料を登録し（Ｓ４２０２）、”メール本文に依頼メールの引用以外の内容が記入されているか？”の処理に進む。”メール本文に依頼メールの引用以外の内容が記入されているか？”の処理ではメール本文を解析し、依頼メールの引用以外の内容が記入されているかどうかを判定し（Ｓ４２０３）、もし記入されていなければ担当者に処理完了通知を送信し（Ｓ４２０６）、処理を終了する。もし記入されていれば共通処理で取得したＴｏＤｏＩＤのＴｏＤｏに資料が登録してあるかどうかを判定する（Ｓ４２０４）。もし資料が登録していなければ担当者に処理完了通知を送信し（Ｓ４２０６）、処理を完了する。もし資料が登録してあれば上記ＴｏＤｏのステータスを完了にし、開催者にＴｏＤｏ完了通知を送信する（Ｓ４２０５）。最後に担当者に処理完了通知を送信し、処理を完了する。処理完了通知とは担当者からサーバに届いたメールによってどの処理が行われたかということを担当者に通知するメールである。
【００３７】
図４３は、資料の閲覧を行うｔａｓｋ＋ｇｅｔ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。図４３は、ｔａｓｋ＋ｇｅｔ＠｛会議システムドメイン｝に届いたメールの個別処理のフローチャートである。まずメール本文を解析し、依頼メールの引用以外の内容が記入されているかを判定し（Ｓ４３０１）、もし記入されていなければ、共通処理で取得したＴｏＤｏＩＤのＴｏＤｏに登録されている資料名を記入したメールを作成し、担当者に送信し（Ｓ４３０４）、処理を終了する。もし記入されていれば、メール本文に上記ＴｏＤｏに登録されている資料名が記入されているかどうかを判定する（Ｓ４３０２）。もし記入されていなければ処理を終了する。もし記入されていればメール本文に記入されている資料を添付して担当者に送信し（Ｓ４３０３）、処理を終了する。
【００３８】
図４４は、資料の更新を行うｔａｓｋ＋ｐｕｔ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。まず届いたメールに添付資料が存在するかどうかを判定し（Ｓ４４０１）、もし添付資料が存在しないならば、”メール本文に依頼メールの引用以外の内容が記入されているか？”の処理に進む。もし添付資料が存在するならば、共通処理にて取得したＴｏＤｏＩＤのＴｏＤｏに添付資料と同名の資料が登録されているかを判定し（Ｓ４４０２）、もし登録されてなければ”メール本文に依頼メールの引用以外の内容が記入されているか？”の処理に進む。もし登録されていれば、上記ＴｏＤｏに登録されている添付資料と同名の資料を添付資料で上書きし（Ｓ４４０３）、”メール本文に依頼メールの引用以外の内容が記入されているか？”の処理に進む。”メール本文に依頼メールの引用以外の内容が記入されているか？”の処理ではメール本文を解析し、依頼メールの引用以外の内容が記入されているかを判定し（Ｓ４４０４）、もし記入されていなければ、担当者に処理完了通知を送信し（Ｓ４４０７）、処理を終了する。もし記入されていれば、上記ＴｏＤｏに資料が登録されているかを判定し（Ｓ４４０５）、もし登録されていなければ担当者に処理完了通知を送信し（Ｓ４４０７）、処理を終了する。もし登録されていれば、上記ＴｏＤｏのステータスを完了にし、開催者にＴｏＤｏ完了通知を送信する（Ｓ４４０６）。次に担当者に処理完了通知を送信し、処理を完了する。処理完了通知とは担当者からサーバに届いたメールによってどの処理が行われたかということを担当者に通知するメールである。
【００３９】
図４５は、資料の削除を行うｔａｓｋ＋ｄｅｌｅｔｅ＠｛会議システムドメイン｝に届いたメールの個別処理について説明するフローチャートである。まずメール本文を解析し、メール本文に共通処理にて取得したＴｏＤｏＩＤのＴｏＤｏの資料名が記入されているか判定し（Ｓ４５０１）、もし記入されていなければ、処理を完了する。もし記入されていれば、メール本文に記入されている上記ＴｏＤｏの資料を削除し、ＴｏＤｏのステータスが完了の場合は依頼中にする（Ｓ４５０２）。次に開催者と担当者に処理完了通知を送信し（Ｓ４５０３）、処理を完了する。処理完了通知とは担当者からサーバに届いたメールによってどの処理が行われたかということを担当者に通知するメールである。
【００４０】
図４６は、担当者によるＴｏＤｏのステータス遷移について説明する図である。この図は担当者の返信メールによりとりうるＴｏＤｏのステータス遷移を表した図である。図の矢印はステータス遷移の方向を表しており、矢印に伴った文字列はそのステータス遷移を引き起こす操作を表している。基本的に図３８と同じで違いは操作を行うのが開催者か担当者という点である。たとえば依頼中のＴｏＤｏに対して担当者が資料の登録、更新、削除および担当者の追加を行ってもステータスは遷移せず、資料の登録をして（しないで）完了によりステータスが完了になる。
【００４１】
図４７は、開催者、担当者によるＴｏＤｏのステータス遷移について説明する図である。図４７は図３８と図４６を重ねた図である。
【００４２】
図４８は、添付資料について説明する図である。この図は図５の会議ページの中の添付資料の部分をあらわす。この図は図１８のＴｏＤｏリストのＴｏＤｏのステータスが全て完了になった状態を想定している。つまり図４８のグループ指定なしの資料のｖｖｖ．ｔｉｆとｚｚｚ．ｔｘｔは図１８のリストの上から１番目と５番目のＴｏＤｏの資料である。また図４８のグループ１の資料のｗｗｗ．ｄｏｃとｘｘｘ．ｐｐｔとｙｙｙ．ｐｄｆは図１８のリストの上から２番目から４番目のＴｏＤｏの資料である。そして図４８のグループ１の資料のグループ１の結合資料．ｐｄｆは、ｗｗｗ．ｄｏｃとｘｘｘ．ｐｐｔとｙｙｙ．ｐｄｆを結合したものである。登録されているｖｖｖ．ｔｉｆなどの全ての資料はクリックにより閲覧およびダウンロードが可能となる。開催者はＴｏＤｏリストの確認ボタンからだけでなく、ここからも資料を確認ができる。
【００４３】
図４９は、結合資料の更新の流れについて説明する図である。ここでは結合資料が作成された後、あるいは結合資料の更新が行われたあとにＴｏＤｏの変更が生じることを想定している。
はじめに結合資料が作成されている状態でその結合資料のもとの資料の作成を依頼したＴｏＤｏの変更を検知する。上記ＴｏＤｏ変更により資料更新が行われたかどうかを判定し（Ｓ４９０１）、もし更新が行われていれば”グループの全ステータスが完了か？”の処理に移る。もし更新が行われていなければ、上記ＴｏＤｏの更新でステータス遷移が行われたかどうか判定し（Ｓ４９０２）、もし行われていなければ処理を終了する。もしステータス遷移が行われていたら、”グループの全ステータスが完了か？”の処理に移る。”グループの全ステータスが完了か？”の処理では上記グループの全てのＴｏＤｏのステータスを調べ、その全てのステータスが完了であるかどうかを判定し（Ｓ４９０３）、もし全てのステータスが完了でなければ処理を終了する。もし全てのステータスが完了であれば、新しく資料を結合し、元の結合資料に上書きをし（Ｓ４９０４）、処理を終了する。
【符号の説明】
【００４４】
１００  会議情報システム、１０１  会議情報システムサーバ、１０２  担当者端末、１０３  担当者端末、１０４  ネットワーク、１０５  開催者端末、１０６  メールソフト、１０７  メール作成・解析部、１０８  ユーザ情報操作部、９  データベース、１１０  会議ページ操作部、１１１  ＴｏＤｏリスト操作部、１１２  ファイル操作部、１１３  メールソフト、１１４  ブラウザ、１１５  メールソフト、１１６  資料作成ソフト
【先行技術文献】
【特許文献】
【００４５】
【特許文献１】特開２００２−３７３１６２公報
【図１】
2011039961.tif 000003
【図２】
2011039961.tif 000004
【図３】
2011039961.tif 000005
【図４】
2011039961.tif 000006
【図５】
2011039961.tif 000007
【図６】
2011039961.tif 000008
【図７】
2011039961.tif 000009
【図８】
2011039961.tif 000010
【図９】
2011039961.tif 000011
【図１０】
2011039961.tif 000012
【図１１】
2011039961.tif 000013
【図１２】
2011039961.tif 000014
【図１３】
2011039961.tif 000015
【図１４】
2011039961.tif 000016
【図１５】
2011039961.tif 000017
【図１６】
2011039961.tif 000018
【図１７】
2011039961.tif 000019
【図１８】
2011039961.tif 000020
【図１９】
2011039961.tif 000021
【図２０】
2011039961.tif 000022
【図２１】
2011039961.tif 000023
【図２２】
2011039961.tif 000024
【図２３】
2011039961.tif 000025
【図２４】
2011039961.tif 000026
【図２５】
2011039961.tif 000027
【図２６】
2011039961.tif 000028
【図２７】
2011039961.tif 000029
【図２８】
2011039961.tif 000030
【図２９】
2011039961.tif 000031
【図３０】
2011039961.tif 000032
【図３１】
2011039961.tif 000033
【図３２】
2011039961.tif 000034
【図３３】
2011039961.tif 000035
【図３４】
2011039961.tif 000036
【図３５】
2011039961.tif 000037
【図３６】
2011039961.tif 000038
【図３７】
2011039961.tif 000039
【図３８】
2011039961.tif 000040
【図３９】
2011039961.tif 000041
【図４０】
2011039961.tif 000042
【図４１】
2011039961.tif 000043
【図４２】
2011039961.tif 000044
【図４３】
2011039961.tif 000045
【図４４】
2011039961.tif 000046
【図４５】
2011039961.tif 000047
【図４６】
2011039961.tif 000048
【図４７】
2011039961.tif 000049
【図４８】
2011039961.tif 000050
【図４９】
2011039961.tif 000051