特許 7470156 予定管理システム、通知方法、及びプログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】

(24)【登録日】2024-04-09

(45)【発行日】2024-04-17

(54)【発明の名称】予定管理システム、通知方法、及びプログラム

(51)【国際特許分類】

   G06Q 10/109 20230101AFI20240410BHJP

   G06Q 50/10 20120101ALI20240410BHJP

【ＦＩ】

G06Q10/109

G06Q50/10

【請求項の数】 11

(21)【出願番号】P 2022127341

(22)【出願日】2022-08-09

(65)【公開番号】P2024024489

(43)【公開日】2024-02-22

【審査請求日】2022-08-09

【新規性喪失の例外の表示】特許法第３０条第２項適用 令和３年１０月２０日、ｈｔｔｐｓ：／／ｇａｒｏｏｎ．ｃｙｂｏｚｕ．ｃｏ．ｊｐ／、ｈｔｔｐｓ：／／ｇａｒｏｏｎ．ｃｙｂｏｚｕ．ｃｏ．ｊｐ／ｍｔｃｏｎｔｅｎｔｓ／ｓｕｐｐｏｒｔ／ｃｌｏｕｄ／ｕｐｄａｔｅ／２１１１１４．ｈｔｍｌ 令和３年１１月１２日、ｈｔｔｐｓ：／／ｊｐ．ｃｙｂｏｚｕ．ｈｅｌｐ／、ｈｔｔｐｓ：／／ｊｐ．ｃｙｂｏｚｕ．ｈｅｌｐ／ｇ／ｊａ／ｕｓｅｒ／ｂａｓｉｃ／ｍｅｎｔｉｏｎ．ｈｔｍｌ、ｈｔｔｐｓ：／／ｊｐ．ｃｙｂｏｚｕ．ｈｅｌｐ／ｇ／ｊａ／ｕｓｅｒ／ａｐｐｌｉｃａｔｉｏｎ／ｓｃｈｅｄｕｌｅｒ／ｃｏｍｍｅｎｔ．ｈｔｍｌ 令和３年１１月１４日、ｈｔｔｐｓ：／／ｃｙｂｏｚｕ．ｃｏｍ／

(73)【特許権者】

【識別番号】500022557

【氏名又は名称】サイボウズ株式会社

(74)【代理人】

【識別番号】110000154

【氏名又は名称】弁理士法人はるか国際特許事務所

(72)【発明者】

【氏名】河合 真知子

(72)【発明者】

【氏名】河内山 琢哉

(72)【発明者】

【氏名】桝山 光也

(72)【発明者】

【氏名】松井 雅和

【審査官】谷川 智秀

(56)【参考文献】

【文献】特開２００２－０９２２７７（ＪＰ，Ａ）

【文献】特開２０１９－０１２５７１（ＪＰ，Ａ）

【文献】特開２０１４－１７４７７３（ＪＰ，Ａ）

【文献】特開２００３－３１６７０９（ＪＰ，Ａ）

(58)【調査した分野】(Int.Cl.，ＤＢ名)

Ｇ０６Ｑ １０／００－９９／００

(57)【特許請求の範囲】

【請求項1】

複数の参加者が参加する予定を管理する予定管理システムであって、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部と、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部と、
を含み、
前記予定には、前記参加者として、個人又はグループを登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記グループの前記参加者として前記予定に登録された前記グループに所属する者であって、前記個人の前記参加者として前記予定に登録されていない者には前記通知を行わずに、前記個人の前記参加者として前記予定に登録された者に前記通知を行う、
予定管理システム。

【請求項2】

前記通知部は、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に、自分が前記宛先に指定されたことを示す自分宛通知を行い、かつ、前記個別指定で指定されなかった前記参加者に、自分が宛先として指定されなかったことを示す自分宛以外の通知を行い、
前記全員指定が受け付けられた場合に、前記全員に前記自分宛通知を行う、
請求項１に記載の予定管理システム。

【請求項3】

前記通知部は、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に、前記個別指定により自分が前記宛先に指定されたことを示す第１自分宛通知を行い、かつ、前記個別指定で指定されなかった前記参加者に、前記自分宛以外の通知を行い、
前記全員指定が受け付けられた場合に、前記全員に、前記全員指定により自分が前記宛先に指定されたことを示す第２自分宛通知を行う、
請求項２に記載の予定管理システム。

【請求項4】

前記個別指定は、前記宛先の指定を意味する記号の後に個人名又はグループ名の文字列が入力されることによって行われ、
前記全員指定は、前記予定画面に表示された前記全員の指定を示す情報を選択する操作、又は、前記記号の後に前記全員の指定を示す文字列を入力する操作によって行われる、
請求項１～３の何れかに記載の予定管理システム。

【請求項5】

前記予定画面では、前記宛先から除外する除外指定を更に受付可能であり、
前記通知部は、前記全員指定又は前記個別指定が受け付けられ、かつ、前記除外指定が受け付けられた場合に、前記除外指定により指定された前記宛先を除外して前記通知を行う、
請求項４に記載の予定管理システム。

【請求項6】

前記個別指定は、個人名又はグループ名が入力されることによって行われ、
前記予定管理システムは、前記全員指定が行われた場合に、前記全員分の名前を自動入力する自動入力部を更に含む、
請求項１～３の何れかに記載の予定管理システム。

【請求項7】

前記予定には、前記複数の参加者以外の他の者も登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記他の者には前記通知を行わずに、前記全員に前記通知を行う、
請求項１～３の何れかに記載の予定管理システム。

【請求項8】

前記予定管理システムは、前記複数の参加者のうちの何れかが前記個別指定で指定され、かつ、前記全員指定が受け付けられた場合に、当該参加者の端末に前記通知が重複して表示されないように制御する重複制御部を更に含む、
請求項１～３の何れかに記載の予定管理システム。

【請求項9】

複数の参加者が参加する予定を管理する予定管理システムであって、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部と、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部と、
を含み、
前記全員指定であることを意味する所定の文字又は文字列が入力されることによって前記全員指定が行われる第１の方法と、
前記予定画面に表示された所定の画像が選択された場合に、前記全員分の名前が自動入力されることによって前記全員指定が行われる第２の方法と、
が可能であり、
前記予定管理システムは、前記複数の参加者の人数が閾値以上である場合に、前記予定画面において前記第１の方法を受け付けると決定し、前記人数が前記閾値未満である場合に、前記第２の方法を受け付けると決定する決定部を更に含む、
予定管理システム。

【請求項10】

複数の参加者が参加する予定に関する通知方法であって、コンピュータが、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御ステップと、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知ステップと、
を実行し、
前記予定には、前記参加者として、個人又はグループを登録可能であり、
前記通知ステップは、前記全員指定が受け付けられた場合に、前記グループの前記参加者として前記予定に登録された前記グループに所属する者であって、前記個人の前記参加者として前記予定に登録されていない者には前記通知を行わずに、前記個人の前記参加者として前記予定に登録された者に前記通知を行う、
通知方法。

【請求項11】

複数の参加者が参加する予定を管理するコンピュータを、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部、
として機能させ、
前記予定には、前記参加者として、個人又はグループを登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記グループの前記参加者として前記予定に登録された前記グループに所属する者であって、前記個人の前記参加者として前記予定に登録されていない者には前記通知を行わずに、前記個人の前記参加者として前記予定に登録された者に前記通知を行う、
プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本開示は、予定管理システム、通知方法、及びプログラムに関する。

【背景技術】

【0002】

従来、複数のユーザが参加する予定に関するコメントを入力可能な予定管理システムが知られている。このような予定管理システムでは、コメントに気付きやすくなるように、予定の参加者に通知を行うことが考えられる。例えば、特許文献１には、ユーザが宛先に指定されたコメントが入力されると、ユーザが宛先に指定されたことを示す自分宛通知を行い、ユーザが宛先に指定されずにコメントが入力されると、自分宛以外の通知を行うシステムが記載されている。ユーザの端末には、自分宛通知と、自分宛以外の通知と、を区別した画面が表示される。

【先行技術文献】

【特許文献】

【0003】

【文献】特開２０１４－１７４７７３号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

例えば、上記のような予定管理システムに、特許文献１の技術を適用したとする。この場合、宛先が指定されたコメントが入力されると、自分宛通知が行われるので、宛先に指定された者は、コメントに気付きやすくなる。しかしながら、予定の参加者が増えると、宛先を指定するのに手間がかかる。この点は、自分宛通知と、自分宛以外の通知と、を区別する場合に限られず、何らかの通知の宛先を指定する場合も同様である。

【0005】

本開示の目的の１つは、コメントに関する宛先を指定する手間を軽減することである。

【課題を解決するための手段】

【0006】

本開示に係る予定管理システムは、複数の参加者が参加する予定を管理する予定管理システムであって、前記予定に関するコメントの入力と、前記コメントに関する通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部と、前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部と、を含む。

【発明の効果】

【0007】

本開示によれば、コメントに関する宛先を指定する手間を軽減できる。

【図面の簡単な説明】

【0008】

【図1】予定管理システムのハードウェア構成の一例を示す図である。

【図2】カレンダー画面の一例を示す図である。

【図3】予定画面の一例を示す図である。

【図4】個別指定の流れの一例を示す図である。

【図5】全員指定の流れの一例を示す図である。

【図6】ユーザＢのユーザ端末に表示される通知画面の一例を示す図である。

【図7】ユーザＣのユーザ端末に表示される通知画面の一例を示す図である。

【図8】予定管理システムで実現される機能の一例を示す図である。

【図9】ユーザデータベースの一例を示す図である。

【図10】予定データベースの一例を示す図である。

【図11】予定管理システムで実行される処理の一例を示す図である。

【図12】変形例における機能の一例を示す図である。

【発明を実施するための形態】

【0009】

［１．予定管理システムのハードウェア構成］
本開示に係る予定管理システムの実施形態の一例を説明する。図１は、予定管理システムのハードウェア構成の一例を示す図である。例えば、予定管理システム１は、サーバ１０及びユーザ端末２０を含む。サーバ１０及びユーザ端末２０の各々は、インターネット又はＬＡＮ等のネットワークＮに接続される。

【0010】

サーバ１０は、サーバコンピュータである。例えば、サーバ１０は、制御部１１、記憶部１２、及び通信部１３を含む。制御部１１は、少なくとも１つのプロセッサを含む。記憶部１２は、ＲＡＭ等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、を含む。通信部１３は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。

【0011】

ユーザ端末２０は、ユーザのコンピュータである。例えば、ユーザ端末２０は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。例えば、ユーザ端末２０は、制御部２１、記憶部２２、通信部２３、操作部２４、及び表示部２５を含む。制御部２１、記憶部２２、及び通信部２３のハードウェア構成は、それぞれ制御部１１、記憶部１２、及び通信部１３と同様であってよい。操作部２４は、マウス、タッチパネル、又はキーボード等の入力デバイスである。表示部２５は、液晶ディスプレイ又は有機ＥＬディスプレイである。

【0012】

なお、記憶部１２，２２に記憶されるプログラムは、ネットワークＮを介して供給されてもよい。サーバ１０及びユーザ端末２０の各々のハードウェア構成は、図１の例に限られない。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部（例えば、光ディスクドライブやメモリカードスロット）、又は、外部機器と直接的に接続するための入出力部（例えば、ＵＳＢ端子）が含まれてもよい。この場合、情報記憶媒体に記憶されたプログラムが読取部又は入出力部を介して供給されてもよい。

【0013】

また、予定管理システム１は、少なくとも１つのコンピュータを含めばよい。予定管理システム１に含まれるコンピュータは、図１の例に限られない。例えば、予定管理システム１は、ユーザ端末２０を含まなくてもよい。この場合、ユーザ端末２０は、予定管理システム１の外部に存在し、予定管理システム１は、サーバ１０だけを含む。予定管理システム１は、サーバ１０と、他のサーバコンピュータと、を含んでもよい。

【0014】

［２．予定管理システムの概要］
予定管理システム１は、複数の参加者が参加する予定を管理する。参加者は、予定に参加するユーザである。予定は、所定の場所で所定の日時に行われるイベント又は行動である。予定自体は、種々のタイプであってよく、例えば、会議、セミナー、説明会、面接、レクリエーション、外出、又はその他のイベントである。予定は、現実空間で行われるものに限られず、バーチャル空間又はオンライン上で行われるものであってもよい。

【0015】

本実施形態では、クラウド型のグループウェアがユーザに提供される場合を例に挙げる。グループウェアは、ユーザの業務を支援するサービス又はプログラムである。グループウェアは、クラウド型に限られず、オンプレミス型であってもよい。本実施形態では、グループウェアで利用可能な機能のうち、主に、予定の管理に関する機能を説明する。例えば、ユーザがグループウェアにログインすると、カレンダー形式で予定を表示するためのカレンダー画面が表示部２５に表示される。

【0016】

図２は、カレンダー画面の一例を示す図である。本実施形態では、ブラウザ上で各画面が表示される場合を説明するが、各画面は、グループウェア専用のプログラム上で表示されてもよい。ユーザは、カレンダー画面ＳＣ１から、新たな予定を登録したり、登録済みの予定を確認したりすることができる。例えば、ユーザが、図２のカレンダー画面ＳＣ１の中から、２０２２年８月５日の１６時～１７時の予定「会議：Ｙ社」を選択すると、この予定の詳細を示す予定画面が表示部２５に表示される。

【0017】

図３は、予定画面ＳＣ２の一例を示す図である。例えば、予定画面ＳＣ２には、予定の日時、予定の名前、予定の補足説明としてのメモ、参加者の名前（図３では、ユーザＡ～Ｊの１０人の名前）、予定で利用する施設、アップロードされた添付ファイル、及び予定に対するリアクションといった種々の情報が表示される。ユーザは、予定画面ＳＣ２から、予定を変更又は削除したり、自身が参加者として登録されている予定から抜けたりすることもできる。

【0018】

図３の予定画面ＳＣ２は、入力フォームＦ２０から、予定に関するコメントを入力できるようになっている。コメントは、予定に関係する何らかの者に対するメッセージである。この者は、参加者であってもよいし、参加者以外の他の者であってもよい。先述したメモも、コメントの一種である。コメントは、任意の文章であってよい。例えば、コメントは、予定に関する内容だけではなく、予定には関係のない雑談であってもよい。予定に参加しない者がコメントを入力可能であってもよい。

【0019】

図３の例では、参加者の１人であるユーザＡが、予定画面ＳＣ２を表示させている。例えば、ユーザＡは、入力フォームＦ２０に、任意のコメントを入力する。ユーザＡがボタンＢ２１を選択すると、予定に関連付けられてコメントが登録される。再び予定画面ＳＣ２を表示させると、コメントが予定画面ＳＣ２に表示される。ユーザＡとともに予定に参加するユーザＢ～Ｊは、通知を受け取る。

【0020】

通知は、コメントが入力されたことを示す情報である。メンション又はアラートも通知の一種である。本実施形態では、グループウェアの画面上で通知が行われる場合を説明するが、通知は、他の方法を利用して行われてもよい。例えば、通知は、電子メール、ＳＭＳ、ＳＮＳ、メッセージアプリ、又はＯＳが有する通知機能（例えば、プッシュ又はバナー）といった他の方法を利用して行われてもよい。通知は、複数の方法を組み合わせて行われてもよい。例えば、グループウェアの画面上で表示されるメンションと、ユーザのメールアドレス宛に送信される電子メールと、の各々が通知に相当してもよい。

【0021】

本実施形態では、ユーザが宛先に指定されたことを示す「自分宛通知」と、自分宛通知とは異なる「自分宛以外の通知」と、の２種類の通知が存在する。自分宛通知は、ユーザが宛先として指定されたコメントが入力されたことを示す通知である。自分宛以外の通知は、ユーザが宛先として指定されなかったコメントが入力されたことを示す通知である。これらの通知を区別することによって、ユーザは、より重要な自分宛通知に気付きやすくなる。以降、自分宛通知と、自分宛以外の通知と、を区別しない時は、単に通知という。

【0022】

なお、通知は、本実施形態のような２種類に限られない。例えば、自分宛通知と、自分宛以外の通知と、を区別せずに、１種類の通知だけが存在してもよい。例えば、コメントを入力したユーザの役職又は部署に応じて通知を使い分けることによって、３種類以上の通知が存在してもよい。通知は、コメントの入力時以外の場面で行われてもよい。例えば、予定の登録時、変更時、又は削除時に通知が行われてもよい。例えば、予定の管理以外にも、何らかの情報が登録、変更、又は削除された場合に、通知が行われてもよい。

【0023】

図３の例であれば、ユーザＡは、コメントに気付いてほしい他のユーザを、宛先に指定する。本実施形態では、参加者以外の他の者も宛先に指定できる場合を説明するが、参加者だけを宛先に指定できるようにしてもよい。予定管理システム１では、宛先の指定方法として、宛先を個別に指定する個別指定と、参加者の全員をまとめて宛先に指定する全員指定と、の２種類が用意されている。ユーザＡは、個別指定及び全員指定の少なくとも一方を利用して、宛先を指定する。

【0024】

図４は、個別指定の流れの一例を示す図である。例えば、ユーザＡが、ボタンＢ２２を選択すると、入力フォームＦ２０の上部に宛先を入力できるようになる。ユーザＡは、宛先の指定を意味する「＠」と、宛先として指定する他のユーザの名前と、を入力フォームＦ２０に入力する。「＠」は、ボタンＢ２２の選択に応じて自動入力されてもよい。ユーザＡは、ボタンＢ２２を選択せずに、コメントの本文中に「＠」と他のユーザの名前を手入力してもよい。ユーザＡは、他のユーザの名前を手入力してもよいし、他のユーザ名の名前を示すリストの中から、宛先となる他のユーザの名前を選択してもよい。

【0025】

本実施形態では、「＠」とユーザの名前を入力する一連の操作が、個別指定に相当する。図４の例では、個別指定によって、ユーザＢ，Ｄ，Ｆの３人が宛先に指定されている。入力フォームＦ２０には、ユーザＢ，Ｄ，Ｆをそれぞれ示す３つのアイコンＩ２４が表示される。例えば、ユーザＡは、更に宛先を追加したり、逆に宛先を削除したりすることもできる。宛先の削除は、アイコンＩ２４の「×」を選択することによって行われてもよいし、キーボードのＤｅｌｅｔｅボタン等を利用して行われてもよい。

【0026】

なお、図４の例では、アイコンＩ２４が入力フォームＦ２０の上部に表示される場合が示されているが、アイコンＩ２４は、他の位置に表示されてもよい。例えば、アイコンＩ２４は、コメントの本文中に挿入されてもよいし、入力フォームＦ２０の下部又は外部に表示されてもよい。例えば、アイコンＩ２４ではなく、「＠ユーザＢ」といった文字列が表示されてもよい。また、個別指定が行われてからコメントが入力されてもよいし、コメントが入力されてから個別指定が行われてもよい。

【0027】

図４の例において、コメントの入力が完了すると、宛先に指定されたユーザＢ，Ｄ，Ｆは、自分宛通知を受け取る。宛先に指定されなかった参加者であるユーザＣ，Ｅ，Ｇ，Ｈ，Ｉ，Ｊは、自分宛以外の通知を受け取る。本実施形態では、コメントを入力した本人であるユーザＡは、通知を受け取らないものとするが、コメントを入力した本人であるユーザＡも、通知を受け取れるようにしてもよい。また、宛先に指定されなかった参加者であるユーザＣ，Ｅ，Ｇ，Ｈ，Ｉ，Ｊは、通知を受け取らないようにしてもよい。

【0028】

図５は、全員指定の流れの一例を示す図である。例えば、ユーザＡが、ボタンＢ２３を選択すると、「参加者」の文字列を示すアイコンＩ２５が入力フォームＦ２０に表示される。ユーザＡは、ボタンＢ２３を選択せずに、コメントの本文中に「＠参加者」といった文字列を手入力してもよい。本実施形態では、ボタンＢ２３を選択する操作が、全員指定に相当する。１回の全員指定をすることは、実質的に、ユーザＢ～Ｊの９人分の個別指定をすることと同等の結果が得られる。

【0029】

例えば、ユーザＡは、参加者以外の者を宛先に追加したり、逆に宛先を削除したりすることもできる。宛先の削除は、アイコンＩ２５の「×」を選択することによって行われてもよいし、キーボードのＤｅｌｅｔｅボタン等を利用して行われてもよい。個別指定と同様に、アイコンＩ２５は、任意の位置に表示可能である。アイコンＩ２５ではなく、「＠参加者」といった文字列が表示されてもよい。また、全員指定が行われてからコメントが入力されてもよいし、コメントが入力されてから全員指定が行われてもよい。

【0030】

図５の例において、コメントの入力が完了すると、宛先に指定された参加者の全員であるユーザＢ～Ｊは、自分宛通知を受け取る。本実施形態では、参加者がコメントを入力した場合に、コメントを入力した本人は通知を受け取らない。このため、参加者がコメントを入力した場合の「全員」は、コメントを入力した本人を除いた参加者の全員を意味する。コメントを入力した本人も通知を受け取るようにする場合には、「全員」は、コメントを入力した本人も含む。

【0031】

本実施形態では、グループウェア上の通知画面で通知が表示される。通知画面では、自分宛通知と、自分宛以外の通知と、が区別される。例えば、通知画面では、自分宛通知だけを表示する状態と、自分宛通知と自分宛以外の通知の両方を含む全ての通知を表示する状態と、を切り替えられるようになっている。以降、図４，５のコメントが入力された後にユーザＢ，Ｃのユーザ端末２０に表示される通知画面を例に挙げる。なお、説明の簡略化のために、ユーザＢ，Ｃは、他の通知を受け取っていないものとする。

【0032】

図６は、ユーザＢのユーザ端末２０に表示される通知画面の一例を示す図である。例えば、ボタンＢ３０が選択されると、未読の通知だけが通知画面ＳＣ３に表示される。ボタンＢ３１が選択されると、既読の通知だけが通知画面ＳＣ３に表示される。ボタンＢ３２が選択されると、自分宛通知と自分宛以外の通知の両方を含む全ての通知が通知画面ＳＣ３に表示される。ボタンＢ３３が選択されると、自分宛通知だけが通知画面ＳＣ３に表示される。

【0033】

なお、ボタンＢ３０，Ｂ３１は、何れか一方しか選択できないものとする。ボタンＢ３２，Ｂ３３も、何れか一方しか選択できないものとする。これらの掛け合わせによって、通知画面ＳＣ３の表示が切り替わる。図６の例では、ボタンＢ３０，３３が選択されているので、未読の自分宛通知だけが通知画面ＳＣ３に表示される。ユーザＢは、図４のコメントが入力されたことを示す自分宛通知と、図５のコメントが入力されたことを示す自分宛通知と、を受け取る。これら２つの自分宛通知が両方とも未読だったとすると、図６のように、これら２つの自分宛通知が通知画面ＳＣ３に表示される。

【0034】

図７は、ユーザＣのユーザ端末２０に表示される通知画面の一例を示す図である。図４，５の例では、ユーザＣは、図４のコメントでは宛先に指定されておらず、図５のコメントで宛先に指定されている。このため、ユーザＣは、図４のコメントが入力されたことを示す自分宛以外の通知と、図５のコメントが入力されたことを示す自分宛通知と、を受け取る。図５のコメントが入力されたことを示す自分宛通知が未読だったとすると、図７の上側の通知画面ＳＣ３では、ボタンＢ３０，Ｂ３３が選択されているので、この自分宛通知だけが表示される。

【0035】

例えば、ユーザＣがボタンＢ３２を選択すると、自分宛通知と自分宛以外の通知の両方を含む全ての未読の通知が通知画面ＳＣ３に表示される。図４のコメントが入力されたことを示す自分宛以外の通知も未読だったとすると、図７の下側の通知画面ＳＣ３のように、この自分宛以外の通知も表示される。以上のように、予定管理システム１は、コメントが入力された場合の通知に関する種々の構成を有する。特に、予定管理システム１は、全員指定によって宛先を指定する手間を軽減する構成を有する。以降、予定管理システム１の詳細について説明する。

【0036】

［３．予定管理システムで実現される機能］
図８は、予定管理システム１で実現される機能の一例を示す図である。

【0037】

［３－１．サーバで実現される機能］
例えば、サーバ１０は、データ記憶部１００、表示制御部１０１、及び通知部１０２を含む。データ記憶部１００は、記憶部１２により実現される。表示制御部１０１及び通知部１０２の各々は、制御部１１により実現される。

【0038】

［データ記憶部］
データ記憶部１００は、予定を管理するために必要なデータを記憶する。例えば、データ記憶部１００は、ユーザデータベースＤＢ１と、予定データベースＤＢ２と、を記憶する。

【0039】

図９は、ユーザデータベースＤＢ１の一例を示す図である。ユーザデータベースＤＢ１は、ユーザに関する各種データが格納されたデータベースである。例えば、ユーザデータベースＤＢ１には、ユーザＩＤ、パスワード、ユーザの名前、ユーザの所属、及び通知データが格納される。ユーザに関する何らかの情報が表示される場合には、ユーザデータベースＤＢ１に格納された情報が参照される。ユーザデータベースＤＢ１に格納されるデータは、ユーザに関する任意のデータであってよく、図９の例に限られない。例えば、ユーザデータベースＤＢ１には、ユーザのメールアドレス又は電話番号といった通知の送信先になりうるデータが格納されてもよい。

【0040】

ユーザＩＤ及びパスワードは、ログイン時に必要な認証情報である。ユーザの名前は、宛先を指定するために利用される。所属は、ユーザが属するグループに関する情報である。例えば、所属は、会社の名前と、部署の名前と、を含む。通知データは、ユーザが受け取った通知に関する情報を含む。例えば、通知データは、通知ＩＤ、通知の種類、未読／既読フラグ、通知のタイトル、通知の内容、通知が行われる要因となった行為をしたユーザの名前、及び通知の日時を含む。通知データは、後述の通知部１０２により生成されてユーザデータベースＤＢ１に格納される。

【0041】

通知ＩＤは、通知を一意に識別可能な情報である。通知の種類は、自分宛通知であるか、又は、自分宛以外の通知であるかを示す。自分宛以外の通知は、自分宛通知とは異なる他の通知の一例である。このため、自分宛以外の通知と記載した箇所は、他の通知と読み替えることができる。通知のタイトルは、通知の要因となった情報を示す。図３～図７の例であれば、「会議：Ｙ社」の予定に関するコメントが通知の要因になっているので、通知のタイトルは、「会議：Ｙ社」となる。通知の内容は、コメントの全部又は一部である。ユーザの名前は、図３～図７の例であれば、コメントを入力したユーザＡの名前である。通知の日時は、通知が行われた時の日時である。

【0042】

なお、通知データは、ユーザデータベースＤＢ１以外の他のデータベースに格納されてもよい。他のデータベースは、通知に関する各種データが格納される通知専用のデータベースであってもよい。通知データに含まれる情報は、任意の情報であってよく、図９の例に限られない。例えば、通知データには、通知に起因するアプリケーション等の他の情報が含まれてもよい。サーバ１０は、通知データに基づいて、通知画面ＳＣ３をユーザ端末２０に表示させる。ユーザがボタンＢ３０～Ｂ３３を選択した場合には、サーバ１０は、通知データに含まれる未読／既読フラグや通知の種類に基づいて、表示すべき通知を特定して通知画面ＳＣ３の表示を切り替えればよい。

【0043】

図１０は、予定データベースＤＢ２の一例を示す図である。予定データベースＤＢ２は、登録済みの予定に関する各種データが格納されたデータベースである。例えば、予定データベースＤＢ２には、予定ＩＤ、予定の種類、日時、タイトル、メモ、参加者、予約済みの施設の名前、添付ファイル、リアクション、登録者、変更者、及びコメントデータが格納される。予定データベースＤＢ２に格納されるデータは、予定に関する任意のデータであってよく、図１０の例に限られない。

【0044】

予定ＩＤは、予定を一意に識別可能な情報である。予定の種類は、単発の通常予定、一定の期間にまたがる期間予定、又は繰り返し発生する繰り返し予定の何れかを示す。予定の日時、タイトル、メモ、参加者、予約済みの施設の名前、及び添付ファイルは、予定の登録時又は変更時に入力される。登録者は、予定を登録したユーザである。変更者は、予定を変更したユーザである。コメントデータは、コメントに関する情報を含む。例えば、コメントデータは、コメント本文、宛先、入力者、及び入力日時を含む。入力者は、コメントを入力したユーザである。入力日時は、コメントが入力された時の日時である。

【0045】

例えば、サーバ１０は、グループウェア上で新たな予定が作成されると、この予定の予定ＩＤを新たに発行する。サーバ１０は、予定データベースＤＢ２に新たなレコードを作成し、予定ＩＤと、予定の作成時に指定された種類や日時等の情報と、を関連付けてレコードに格納する。サーバ１０は、ある予定に関するコメントが入力されると、この予定の予定ＩＤに関連付けて、当該コメントのコメントデータを格納する。本実施形態では、コメントデータに含まれる宛先は、後述の通知部１０２によって特定されるものとする。通知部１０２は、特定した宛先をコメントデータに含めるようにして、予定データベースＤＢ２に格納する。

【0046】

なお、データ記憶部１００に記憶されるデータは、上記の例に限られない。データ記憶部１００は、任意のデータを記憶可能である。例えば、データ記憶部１００は、各種画面を表示するためのデータ、又は、予定で利用可能な施設の予約状況を示すデータといった他のデータを記憶してもよい。

【0047】

［表示制御部］
表示制御部１０１は、各種画面をユーザ端末２０に表示させる。本実施形態では、表示制御部１０１がサーバ１０に含まれるので、表示制御部１０１は、ユーザ端末２０に対し、画面の表示データを送信することによって、画面を表示させる。本実施形態では、ブラウザ上で画面が表示されるので、表示データがＨＴＭＬ形式である場合を説明するが、表示データは、任意の形式であってよい。例えば、専用のプログラムで画面を表示させる場合には、表示データは、プログラムでサポートされている形式であればよい。

【0048】

本実施形態では、表示制御部１０１は、予定に関するコメントの入力と、コメントに関する通知の宛先を個別に指定する個別指定と、複数の参加者の全員をまとめて宛先に指定する全員指定と、を受付可能な予定画面ＳＣ２を表示させる。例えば、表示制御部１０１は、ユーザ端末２０に対し、予定画面ＳＣ２の表示データを送信することによって、予定画面ＳＣ２を表示させる。

【0049】

なお、予定画面ＳＣ２の表示データの元となるデータは、データ記憶部１００に記憶されているものとする。例えば、表示制御部１０１は、予定データベースＤＢ２を参照し、ユーザが選択した予定に関する各種データを取得する。表示制御部１０１は、当該元となるデータと、当該取得した各種データと、に基づいて、予定画面ＳＣ２の表示データを生成する。予定画面ＳＣ２は、コメントの入力、個別指定、及び全員指定といった３つの操作を受付可能な画面であればよい。予定画面ＳＣ２は、任意のレイアウトであってよく、本実施形態の例に限られない。

【0050】

コメントの入力を受付可能な予定画面ＳＣ２とは、コメントを入力するためのコメント入力画像を含む画面である。本実施形態では、入力フォームＦ２０がコメント入力画像に相当する場合を説明するが、コメント入力画像は、コメントを何らかの形で入力可能な画像であればよく、他の画像であってもよい。例えば、コメント入力画像は、プルダウン等の他のフォームであってもよい。例えば、定型文のコメントを入力する場合には、定型文を選択するためのラジオボタン又はチェックボックスがコメント入力画像に相当してもよい。例えば、音声入力を受け付けるための画像がコメント入力画像に相当してもよい。

【0051】

個別指定を受付可能な予定画面ＳＣ２とは、個別指定をするための個別指定画像を含む画面である。本実施形態では、入力フォームＦ２０及びボタンＢ２２が個別指定画像に相当する場合を説明するが、個別指定画像は、宛先となるユーザを何らかの形で指定可能な画像であればよく、他の画像であってもよい。例えば、ボタンＢ２２を利用しない場合には、入力フォームＦ２０だけが個別指定画像に相当してもよい。入力フォームＦ２０を利用しない場合には、ボタンＢ２２だけが個別指定画像に相当してもよい。例えば、ユーザのリストが個別指定画像に相当してもよい。例えば、宛先として指定する参加者を選択するためのラジオボタン又はチェックボックスが個別指定画像に相当してもよい。

【0052】

全員指定を受付可能な予定画面ＳＣ２とは、全員指定をするための全員指定画像を含む画面である。本実施形態では、入力フォームＦ２０又はボタンＢ２３が全員指定画像に相当する場合を説明するが、全員指定画像は、宛先として参加者の全員を指定する意思をコンピュータに伝達するための画像であればよく、他の画像であってもよい。例えば、全員指定をするためのラジオボタン又はチェックボックスが全員指定画像に相当してもよい。

【0053】

本実施形態では、個別指定は、個人名又はグループ名が入力されることによって行われる。例えば、個別指定は、「＠」と、個人名又はグループ名と、の組み合わせが入力されることによって行われてもよい。「＠」は、宛先の指定を意味する所定の記号の一例である。このため、「＠」と記載した箇所は、宛先の指定を意味する所定の記号と読み替えることができる。この記号は、任意の記号であってよく、「＠」に限られない。例えば、「＋」、「＃」、又は「％」といった他の記号が利用されてもよい。個人名は、宛先となるユーザの名前である。グループ名は、宛先となるグループの名前である。「営業部」といったグループも宛先として指定可能であってよい。この場合、グループに属する全員に通知が行われてもよい。

【0054】

本実施形態では、全員指定は、全員分の個人名又はグループ名を入力する操作とは異なる操作によって行われる。この操作は、先述したチェックボックスに対する操作等であってもよい。例えば、全体指定は、ボタンＢ２３を選択し、入力フォームＦ２０に「参加者」と入力されることによって行われる。例えば、全員指定は、「＠」と、「参加者」と、の組み合わせが入力されることによって行われてもよい。「参加者」は、全員指定であることを意味する所定の文字列の一例である。このため、「参加者」と記載した箇所は、全員指定であることを意味する所定の文字列と読み替えることができる。この文字列は、任意の文字列であってよく、「参加者」に限られない。例えば、「出席者」、「全員」、又は「ＡＬＬ」といった他の文字列が利用されてもよい。全員指定は、文字列ではなく、全員指定であることを意味する所定の文字が利用されてもよい。即ち、「皆」又は「全」といった１文字だけで全員指定であることを表現されてもよい。この文字も任意の文字であってよい。

【0055】

なお、宛先の指定方法は、本実施形態で説明した方法以外の他の方法であってもよい。例えば、「＠」等の記号を利用せずに、個人名又はグループ名だけで個人指定が行われてもよい。例えば、「＠」等の記号を利用せずに、「参加者」といった文字列、又は、「皆」といった１文字だけで全員指定が行われてもよい。逆に、文字列又は文字を利用せずに、全員指定を示す特定の記号だけを利用して、全員指定が行われてもよい。例えば、「＊」が全員指定を意味する場合には、「＊」を入力するだけで全員指定が行われるようにしてもよい。

【0056】

また、宛先の指定方法は、文字列を入力する方法に限られない。例えば、参加者の名前と、ラジオボタン又はチェックボックスと、の組み合わせを全員分並べて予定画面ＳＣ２に表示させる場合には、ラジオボタン又はチェックボックスを選択することによって、個別指定が行われてもよい。例えば、ユーザのリストを予定画面ＳＣ２に表示させる場合には、リストの中のユーザを選択することによって、個別指定が行われてもよい。例えば、全員指定を示すラジオボタン又はチェックボックスを予定画面ＳＣ２に表示させる場合には、ラジオボタン又はチェックボックスを選択することによって、全員指定が行われてもよい。

【0057】

［通知部］
通知部１０２は、予定管理システム１における通知を行う。通知を行うとは、通知に関するデータを生成してデータ記憶部１００に記録すること、又は、通知自体をユーザ端末２０に送信することである。本実施形態では、通知データを生成してユーザデータベースＤＢ１に格納することが通知を行うことに相当する場合を説明するが、他のデータベースに通知データを格納することが通知を行うことに相当してもよいし、電子メール又はその他のメッセージをユーザ端末２０に送信することが通知を行うことに相当してもよい。

【0058】

本実施形態では、通知部１０２は、個別指定が受け付けられた場合に、個別指定で指定された者に通知を行う。例えば、通知部１０２は、個別指定で指定された者のユーザＩＤと、コメントが入力されたことを示す通知の通知データと、を関連付けてユーザデータベースＤＢ１に格納することによって、この者に通知を行う。図４の例であれば、個別指定によってユーザＢ，Ｄ，Ｆが宛先に指定されるので、通知部１０２は、ユーザＢ，Ｄ，Ｆの各々のユーザＩＤと、通知データと、を関連付けてユーザデータベースＤＢ１に格納する。本実施形態では、通知部１０２は、入力フォームＦ２０の上部（図４，５の例では、アイコンＩ２４，Ｉ２５が表示された部分）に入力された情報に基づいて、宛先を特定する。通知部１０２は、その下に入力された情報は、コメントの本文として特定する。

【0059】

例えば、通知部１０２は、個別指定が受け付けられた場合に、個別指定で指定された者に、自分が宛先に指定されたことを示す自分宛通知を行い、かつ、個別指定で指定されなかった参加者に、自分宛以外の通知を行う。通知部１０２は、個別指定で指定された者のユーザＩＤと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースＤＢ１に格納する。

【0060】

例えば、通知部１０２は、コメントとともに受信した宛先を参照することによって、個別指定で指定された宛先を特定する。コメントの本文中に「＠」と文字列を入力して宛先を指定する場合には、通知部１０２は、コメントに「＠」が含まれるか否かを判定する。通知部１０２は、コメントに「＠」が含まれると判定した場合に、その後に配置されたユーザの名前がユーザデータベースＤＢ１に存在するか否かを判定する。通知部１０２は、ユーザの名前がユーザデータベースＤＢ１に存在すると判定した場合に、個別指定によりこのユーザが宛先に指定されたことを特定する。図４の例であれば、通知部１０２は、ユーザＢ，Ｄ，Ｆが宛先に指定されたことを特定する。

【0061】

例えば、通知部１０２は、ユーザＢ，Ｄ，Ｆの各々が受け取る通知の通知ＩＤを発行し、通知データを生成する。通知部１０２は、当該発行された通知ＩＤ、自分宛通知を示す種類、未読であることを示す未読／既読フラグ、コメントが入力された予定のタイトル、コメントの内容、コメントを入力した入力者、及び現在の日時を通知データに含める。通知部１０２は、ユーザＢ，Ｄ，Ｆの各々のユーザＩＤと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースＤＢ１に格納する。

【0062】

例えば、通知部１０２は、予定データベースＤＢ２を参照し、宛先に指定されなかった参加者を特定する。図４の例であれば、通知部１０２は、ユーザＣ，Ｅ，Ｇ，Ｈ，Ｉ，Ｊを、宛先に指定されなかった参加者として特定する。通知部１０２は、ユーザＣ，Ｅ，Ｇ，Ｈ，Ｉ，Ｊの各々が受け取る通知の通知ＩＤを発行し、通知データを生成する。通知データは、自分宛以外の通知であることを種類が示すこと以外は、ユーザＢ，Ｄ，Ｆの通知データと同様である。通知部１０２は、ユーザＣ，Ｅ，Ｇ，Ｈ，Ｉ，ＪのユーザＩＤと、自分宛以外の通知であることを示す通知データと、を関連付けてユーザデータベースＤＢ１に格納する。

【0063】

本実施形態では、通知部１０２は、全員指定が受け付けられた場合に、全員に通知を行う。先述したように、コメントを入力した者が予定の参加者本人であれば、本実施形態の全員とは、コメントを入力した者以外の全員を意味する。ただし、コメントを入力した本人にも通知を行う場合には、本実施形態の全員は、コメントを入力した本人も含む。参加者以外の者がコメントを入力した場合には、参加者の人数と、通知を行う「全員」が意味する人数と、は一致する。通知部１０２は、全員のユーザＩＤと、コメントが入力されたことを示す通知の通知データと、を関連付けてユーザデータベースＤＢ１に格納することによって、全員に通知を行う。

【0064】

例えば、通知部１０２は、全員指定が受け付けられた場合に、全員に自分宛通知を行う。通知部１０２は、全員のユーザＩＤと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースＤＢ１に格納する。通知部１０２は、コメントとともに受信した宛先を参照することによって、全員指定が受け付けられたか否かを判定する。コメントの本文中に「＠」と「参加者」を入力して宛先を指定する場合には、通知部１０２は、コメントに「＠参加者」が含まれるか否かを判定する。通知部１０２は、コメントに「＠参加者」が含まれると判定した場合に、全員指定により全員が宛先に指定されたことを特定する。通知部１０２は、コメントを入力した者が参加者である場合には、この者を宛先から除外する。

【0065】

図５の例であれば、全員指定によってユーザＢ～Ｊが宛先に指定されるので、通知部１０２は、ユーザＢ～Ｊの各々のユーザＩＤと、通知データと、を関連付けてユーザデータベースＤＢ１に格納する。通知部１０２は、ユーザＢ～Ｊの各々が受け取る通知の通知ＩＤを発行し、通知データを生成する。通知部１０２は、当該発行された通知ＩＤ、自分宛通知を示す種類、未読であることを示す未読／既読フラグ、コメントが入力された予定のタイトル、コメントの内容、コメントを入力した入力者、及び現在の日時を通知データに含める。通知部１０２は、ユーザＢ～Ｊの各々のユーザＩＤと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースＤＢ１に格納する。

【0066】

なお、通知部１０２が実行する処理は、上記の例に限られない。例えば、自分宛通知と、自分宛以外の通知と、を区別せずに１種類だけの通知が存在する場合には、通知部１０２は、通知の種類を含まない通知データを生成すればよい。この場合、個別指定が行われた場合には、個別指定で宛先に指定されなかった参加者には、通知が行われない。通知部１０２は、ユーザのメールアドレスに電子メールを送信したり、ユーザの電話番号宛てにメッセージを送信したりすることによって、通知を行ってもよい。

【0067】

また、宛先の特定方法も、上記の例に限られない。例えば、「＠」以外の他の記号を利用して個別指定又は全員指定が行われる場合には、通知部１０２は、他の記号が入力されたか否かを判定することによって、個別指定又は全員指定で指定された宛先を特定してもよい。例えば、ラジオボタン又はチェックボックスによって個別指定又は全員指定が行われる場合には、通知部１０２は、ラジオボタン又はチェックボックスの選択状況に基づいて、個別指定又は全員指定が行われたか否かを判定して宛先を特定してもよい。

【0068】

［３－２．ユーザ端末で実現される機能］
例えば、ユーザ端末２０は、データ記憶部２００、表示制御部２０１、及び操作受付部２０２を含む。データ記憶部２００は、記憶部２２により実現される。表示制御部２０１及び操作受付部２０２の各々は、制御部２１により実現される。

【0069】

［データ記憶部］
データ記憶部２００は、予定を管理するために必要なデータを記憶する。例えば、データ記憶部２００は、予定管理システム１に関する各種画面を表示するためのブラウザを記憶する。例えば、データ記憶部２００は、グループウェア専用のアプリケーションを記憶する。

【0070】

［表示制御部］
表示制御部２０１は、予定管理システム１における各種画面を、表示部２５に表示させる。例えば、表示制御部２０１は、サーバ１０から受信した表示データに基づいて、予定画面ＳＣ２、カレンダー画面ＳＣ１、予定画面ＳＣ２、又は通知画面ＳＣ３を、表示部２５に表示させる。

【0071】

［操作受付部］
操作受付部２０２は、予定管理システム１における各種操作を受け付ける。例えば、カレンダー画面ＳＣ１、予定画面ＳＣ２、又は通知画面ＳＣ３の各々に対する操作を受け付ける。操作受付部２０２が受け付けた操作内容は、サーバ１０に適宜送信される。例えば、操作受付部２０２は、予定画面ＳＣ２から、コメントの入力、個別指定、及び全員指定を受け付ける。これらの操作は、入力フォームＦ２０に入力されたコメント（図４，５の例であれば、入力フォームＦ２０の下部に入力されたコメントの本文と、入力フォームＦ２０の上部に入力された宛先部分の情報と、を含むコメント全体）に反映される。操作受付部２０２は、当該コメントをサーバ１０に送信することによって、予定画面ＳＣ２で受け付けた操作がサーバ１０に伝達される。

【0072】

［４．予定管理システムで実行される処理］
図１１は、予定管理システム１で実行される処理の一例を示す図である。図１１では、予定管理システム１で実行される処理のうち、主に、予定画面ＳＣ２でコメントが入力されて通知が行われる処理を説明する。制御部１１，２１が、それぞれ記憶部１２，２２に記憶されたプログラムを実行することによって、図１１の処理が実行される。

【0073】

図１１に示すように、サーバ１０及びユーザ端末２０の間で、ユーザがグループウェアにログインするためのログイン処理が実行される（Ｓ１）。Ｓ１では、ユーザ端末２０は、サーバ１０に対し、ユーザが入力したユーザＩＤ及びパスワードを送信する。サーバ１０は、ユーザデータベースＤＢ１を参照し、ユーザＩＤ及びパスワードの正当性を確認する。ログイン処理が成功すると、ユーザはグループウェアを利用できる。以降、予定の詳細が確認される場合の処理を説明する。

【0074】

例えば、カレンダー画面ＳＣ１から予定が選択されると、サーバ１０及びユーザ端末２０の間で、予定画面ＳＣ２を表示するための処理が実行される（Ｓ２）。Ｓ２では、ユーザ端末２０は、サーバ１０に対し、ユーザが選択した予定の予定ＩＤを送信する。予定ＩＤは、カレンダー画面ＳＣ１の表示データに含まれているものとする。サーバ１０は、予定ＩＤを受信すると、予定データベースＤＢ２を参照し、当該予定ＩＤに関連付けられたデータを取得する。サーバ１０は、当該データに基づいて、予定画面ＳＣ２の表示データを生成してユーザ端末２０に送信する。ユーザ端末２０は、当該表示データを受信すると、予定画面ＳＣ２を表示部２５に表示させる。

【0075】

ユーザ端末２０は、操作部２４の検出信号に基づいて、予定画面ＳＣ２に対するユーザの操作を特定する（Ｓ３）。Ｓ３では、入力フォームＦ２０に対するコメントの入力と、ボタンＢ２１～Ｂ２３の選択と、が行われるものとする。予定を変更又は削除する等の他の操作が行われた場合には、他の操作に応じた処理が実行されて本処理は終了する。なお、予定画面ＳＣ２の表示データには、ボタンＢ２２が選択された場合に入力フォームＦ２０上で宛先の入力を受け付けるスクリプト、その後の入力によってアイコンＩ２４を表示するスクリプト、及びボタンＢ２３が選択された場合にアイコンＩ２５を表示するスクリプトが含まれるものとする。後述のＳ４とＳ６の処理は、これらのスクリプトにより実行されるものとする。スクリプトではなく、その都度サーバ１０に要求が実行されて、一連の処理がサーバ１０側で実行されてもよい。

【0076】

Ｓ３において、ボタンＢ２２が選択された場合（Ｓ３：Ｂ２２）、ユーザ端末２０は、入力フォームＦ２０の上部で「＠」の入力を受け付けて（Ｓ４）、宛先となるユーザの名前の入力を受け付ける（Ｓ５）。Ｓ３でボタンＢ２２を選択する操作と、Ｓ５で「＠」の後に名前を入力する操作と、の組み合わせが個別指定に相当する。Ｓ５で個別指定が完了すると、アイコンＩ２４が入力フォームＦ２０に表示される。Ｓ３において、ボタンＢ２３が選択された場合（Ｓ３：Ｂ２３）、ユーザ端末２０は、「参加者」のアイコンＩ２５を入力フォームＦ２０に表示させる（Ｓ６）。Ｓ３でボタンＢ２３を選択する操作が全員指定に相当する。

【0077】

Ｓ３において、入力フォームＦ２０に対するコメントの入力が行われた場合（Ｓ３：Ｆ２０）、ユーザ端末２０は、ユーザが入力したコメントを入力フォームＦ２０に表示させる（Ｓ７）。Ｓ７では、ユーザ端末２０は、ユーザが入力した任意の文字列を、入力フォームＦ２０に表示させる。Ｓ７において、コメントの本文中に、「＠」の後にユーザの名前を入力することが、個別指定に相当してもよい。Ｓ７において、コメントの本文中に、「＠」の後に「参加者」と入力することが、全員指定に相当してもよい。

【0078】

Ｓ３において、ボタンＢ２１が選択された場合（Ｓ３：Ｂ２１）、ユーザ端末２０は、サーバ１０に対し、入力フォームＦ２０に対する入力内容を送信する（Ｓ８）。サーバ１０は、ユーザ端末２０から入力内容を受信すると、通知の宛先を特定する（Ｓ９）。Ｓ９では、サーバ１０は、ユーザデータベースＤＢ１を参照し、個別指定で指定された名前がユーザデータベースＤＢ１に存在すれば、この名前のユーザを宛先として特定する。サーバ１０は、全員指定が行われていれば、予定データベースＤＢ２を参照し、参加者の全員を宛先として特定する。

【0079】

サーバ１０は、Ｓ９で特定した宛先に基づいて、通知を行い（Ｓ１０）、本処理は終了する。Ｓ１０では、サーバ１０は、宛先として指定されたユーザのユーザＩＤと、自分宛通知の通知データと、を関連付けてユーザデータベースＤＢ１に格納する。サーバ１０は、宛先として指定されなかった参加者のユーザＩＤと、自分宛以外の通知の通知データと、を関連付けてユーザデータベースＤＢ１に格納する。通知画面ＳＣ３が表示される場合には、これらの通知データが参照される。

【0080】

本実施形態の予定管理システム１は、予定画面ＳＣ２で個別指定が受け付けられた場合に、個別指定で指定された者に通知を行う。予定管理システム１は、予定画面ＳＣ２で全員指定が受け付けられた場合に、参加者の全員に通知を行う。これにより、複数の参加者を宛先にした場合には全員指定をすれば済み、参加者の数だけ宛先を指定する必要がなくなるので、宛先を指定する手間を軽減できる。例えば、図５の例であれば、ユーザＢ～Ｊの９人分の個別指定をすることも可能であるが、全員指定であれば１回の操作で済むので、手間を軽減できる。サーバ１０からしても、９人分の個別指定をする場合には、宛先を特定する処理を９回実行する必要があるが、全員指定であれば１回の処理で済むので、サーバ１０の処理負荷を軽減できる。また、個別指定の場合には、ユーザＢ～Ｊの９人分を入力する必要があるが、全員指定であれば、１回の操作で済むので、コメントを短くすることができる。その結果、コメントの視認性が高まり、かつ、コメントのデータサイズを抑える（メモリ消費量を抑える）ことができる。

【0081】

また、予定管理システム１は、個別指定が受け付けられた場合に、個別指定で指定された者に、自分が宛先に指定されたことを示す自分宛通知を行い、かつ、個別指定で指定されなかった参加者に、自分宛以外の通知を行う。予定管理システム１は、全員指定が受け付けられた場合に、全員に自分宛通知を行う。これにより、宛先として指定された者が、コメントが入力されたことに気付きやすくなる。また、宛先として指定されなかった参加者にも、自分宛以外の通知が届くので、コメントが入力されたことに気付かせることができる。特にコメントに気付かせたい者に対して自分宛通知を送り、コメントに気付かせたいが優先度は相対的に低い者に対して自分宛以外の通知を送ることによって、通知に強弱を持たせることができる。

【0082】

また、個別指定は、個人名又はグループ名が入力されることによって行われる。全員指定は、全員分の個人名又はグループ名を入力する操作とは異なる操作によって行われる。これにより、シンプルかつ直感的に分かりやすい方法によって、個別指定と全員指定を行うことができる。

【0083】

［５．変形例］
なお、本開示は、以上説明した実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。

【0084】

図１２は、変形例における機能の一例を示す図である。例えば、ユーザ端末２０は、自動入力部２０３を含む。自動入力部２０３は、制御部２１により実現される。サーバ１０は、出欠確認部１０３、重複制御部１０４、及び決定部１０５を含む。出欠確認部１０３、重複制御部１０４、及び決定部１０５の各々は、制御部１１により実現される。

【0085】

［５－１．変形例１］
例えば、実施形態では、個別指定で指定された参加者が受け取る自分宛通知と、全員指定で指定された参加者が受け取る自分宛通知と、が同じ種類である場合を説明したが、これらの通知を、別々の種類の通知として区別してもよい。変形例１では、個別指定により自分が宛先に指定されたことを示す第１自分宛通知、全員指定により自分が宛先に指定されたことを示す第２自分宛通知、及び自分宛以外の通知の３種類の通知が存在する。通知データに含まれる種類によって、これらの通知が区別される。

【0086】

変形例１の通知部１０２は、個別指定が受け付けられた場合に、個別指定で指定された者に第１自分宛通知を行い、かつ、個別指定で指定されなかった参加者に、自分宛以外の通知を行う。通知部１０２は、個別指定で指定された者のユーザＩＤと、第１自分宛通知であることを示す通知データと、を関連付けてユーザデータベースＤＢ１に格納する。この通知データは、通知の種類が第１自分宛通知であることを示す点で、実施形態で説明した自分宛通知の通知データとは異なるが、他の点については同様である。個別指定で指定されなかった参加者に対する自分宛以外の通知については、実施形態で説明した通りである。

【0087】

変形例１の通知部１０２は、全員指定が受け付けられた場合に、全員に第２自分宛通知を行う。通知部１０２は、全員のユーザＩＤと、第２自分宛通知であることを示す通知データと、を関連付けてユーザデータベースＤＢ１に格納する。この通知データは、通知の種類が第２自分宛通知であることを示す点で、実施形態で説明した自分宛通知の通知データとは異なるが、他の点については同様である。

【0088】

変形例１の通知画面ＳＣ３では、第１自分宛通知と、第２自分宛通知と、が区別されて表示される。例えば、通知画面ＳＣ３は、第１自分宛通知だけが表示される状態と、第１自分宛通知と第２自分宛通知の両方が表示され、かつ、自分宛通知以外の通知が表示されない状態と、第１自分宛通知、第２自分宛通知、及び自分宛通知以外の通知を含む全ての通知が表示される状態と、の各々が切り替えられるようにしてもよい。これらの切り替えは、通知データに含まれる種類に応じて実行されるようにすればよい。

【0089】

変形例１の予定管理システム１は、個別指定が受け付けられた場合に、個別指定で指定された者に、第１自分宛通知を行う。予定管理システム１は、全員指定が受け付けられた場合に、全員に第２自分宛通知を行う。これにより、第１自分宛通知と第２自分宛通知を使い分けることができるので、利便性が高まる。例えば、個別指定の場合には、個人名又はグループ名が直々に指定されているので、個人又はグループにとって、全員指定が行われるよりも重要度が高い可能性がある。この場合に、第１自分宛通知を第２自分宛通知と区別することによって、より重要度が高い通知に気付きやすくなる。

【0090】

［５－２．変形例２］
例えば、全員指定が行われる場合に、一部の参加者だけを宛先から除外したいことがある。図４の例であれば、ユーザＨが普段から受け取る通知があまりにも多い場合には、ユーザＨが受け取る通知を減らすために、ユーザＨだけを宛先から除外したいことがある。この場合に、ユーザＢ～Ｇ，Ｊの８人分を個別指定すると手間がかかるので、全員指定により入力された「参加者」の後に、「－」の記号と、宛先から除外したい「ユーザＨ」と、を含む「－ユーザＨ」といった文字列を入力することによって、ユーザＨが宛先から除外されるようにしてもよい。

【0091】

変形例２の予定画面ＳＣ２では、宛先から除外する除外指定を更に受付可能である。例えば、除外指定は、「－」と、宛先から除外する参加者と、の組み合わせが入力されることによって行われてもよい。「－」は、宛先から除外することを意味する所定の記号の一例である。このため、「－」と記載した箇所は、宛先から除外することを意味する所定の記号と読み替えることができる。この記号は、任意の記号であってよく、「－」に限られない。例えば、「×」又は「／」といった他の記号が利用されてもよい。特にこのような記号が利用されることなく、宛先から除外したい参加者の名前が入力されることによって、除外指定が行われてもよい。除外指定は、個人ではなく、グループが指定されてもよい。

【0092】

除外指定を受付可能な予定画面ＳＣ２とは、除外指定をするための除外指定画像を含む画面である。変形例２では、入力フォームＦ２０が除外指定画像に相当する場合を説明するが、除外指定画像は、宛先から除外するユーザを何らかの形で指定可能な画像であればよく、他の画像であってもよい。例えば、参加者のリストが除外指定画像に相当してもよい。例えば、除外する参加者を選択するためのラジオボタン又はチェックボックスが除外指定画像に相当してもよい。

【0093】

変形例２の通知部１０２は、全員指定又は個別指定が受け付けられ、かつ、除外指定が受け付けられた場合に、除外指定により指定された宛先を除外して通知を行う。全員指定と除外指定が受け付けられた場合には、通知部１０２は、参加者の全員の中から、除外指定により指定された宛先を除外する。個別指定と除外指定が受け付けられた場合には、通知部１０２は、個別指定で指定された宛先の中から、除外指定により指定された宛先を除外する。例えば、通知部１０２は、除外指定により指定された参加者には自分宛通知を行わず、他の参加者に自分宛通知を行う。除外された参加者に自分宛通知が行われないという点で、実施形態とは異なるが、他の点については実施形態と同様である。変形例２では、除外指定により指定された参加者には、自分宛以外の通知が行われるものとするが、何の通知も行われないようにしてもよい。

【0094】

例えば、通知部１０２は、アイコンＩ２５の「参加者」の後に、「－」の記号と、参加者の名前と、の組み合わせが含まれるか否かを判定する。通知部１０２は、この組み合わせが含まれる場合には、「－」の記号の後に名前が入力された参加者を宛先から除外する。アイコンＩ２５の「参加者」の後に「－ユーザＨ－ユーザＪ」といったように、複数の参加者が指定された場合には、通知部１０２は、複数の参加者を宛先から除外する。宛先から除外するとは、宛先に指定されなかったとみなすことである。除外指定でグループを指定する場合には、アイコンＩ２５の「参加者」の後に「－営業部」といったように、宛先から除外したいグループが指定される。個別指定でグループが指定された場合に、グループの中から除外したい宛先が指定されてもよい。例えば、「営業部」が参加者である場合に「営業部－ユーザＡ」といったように、宛先から除外したい個人名が指定されてもよい。

【0095】

なお、除外する参加者の特定方法は、宛先の特定方法と同様に、他の方法であってもよい。例えば、「－」以外の他の記号を利用して除外指定が行われる場合には、通知部１０２は、当該他の記号に基づいて、除外指定が行われたか否かを判定すればよい。例えば、ラジオボタン又はチェックボックスが利用される場合には、通知部１０２は、ラジオボタン又はチェックボックスの選択状況によって、除外したいが行われたか否かを判定すればよい。

【0096】

変形例２の予定管理システム１は、全員指定が受け付けられ、かつ、除外指定が受け付けられた場合に、除外指定により指定された参加者を宛先から除外し、全員のうちの他の参加者に通知を行う。これにより、宛先から除外したい参加者がいる場合にも、手間を軽減できる。例えば、図５の例では、全員指定をすると９人の参加者が宛先に指定される。このうち、１人だけを宛先から除外したい場合に、除外指定を受け付けることができなかったとすると、残りの８人分を個別指定する必要がある。この点、変形例２では、除外指定により、全員指定及び除外指定といった２つの操作で済むので、手間を軽減できる。

【0097】

［５－３．変形例３］
例えば、実施形態では、予定画面ＳＣ２のボタンＢ２３が選択されることによって、全員指定が行われる場合を説明したが、ボタンＢ２３が選択された場合に、入力フォームＦ２０に「参加者」と入力されるのではなく、個人名又はグループ名と、の組み合わせが全員分表示されてもよい。ボタンＢ２３は、所定の画像の一例である。このため、ボタンＢ２３について説明している箇所は、所定の画像と読み替えることができる。所定の画像は、任意の画像であってよく、ボタンＢ２３に限られない。例えば、所定の画像は、ラジオボタン又はチェックボックスであってもよい。所定の画像は、実施形態で説明した全員指定画像であってよい。

【0098】

変形例３の予定管理システム１は、自動入力部２０３を含む。自動入力部２０３は、全員指定が行われた場合に、全員分の名前を自動入力する。図５の例であれば、自動入力部２０３は、ボタンＢ２３が選択された場合に、入力フォームＦ２０に「参加者」と入力するのではなく、「ユーザＢ」、「ユーザＣ」、「ユーザＤ」、「ユーザＥ」、「ユーザＦ」、「ユーザＧ」、「ユーザＨ」、「ユーザＩ」、及び「ユーザＪ」といった９人分の名前を一度に自動入力する。即ち、アイコンＩ２５の代わりに、９人分のアイコンＩ２４が一度に表示される。全員指定がボタンＢ２３の選択以外の操作である場合にも、これら９人分のアイコンＩ２４が一度に表示されるようにすればよい。

【0099】

例えば、自動入力部２０３は、予定データベースＤＢ２を参照し、自動入力すべき参加者を特定する。自動入力部２０３は、コメントを入力する者が参加者であれば、この者を除外した残り全員分の「＠」と名前の組み合わせを入力フォームＦ２０に自動入力し、全員分のアイコンＩ２４を表示させる。自動入力部２０３は、コメントを入力する者が参加者以外の他の者であれば、参加者の全員分の「＠」と名前の組み合わせを、入力フォームＦ２０に自動入力する。通知部１０２は、全員が個別指定された場合と同様の処理を実行することによって、全員の通知を行うことになる。

【0100】

変形例３の予定管理システム１は、ボタンＢ２３が選択された場合に、全員分の名前を自動入力する。これにより、宛先を指定する手間を軽減できる。例えば、実施形態のように「参加者」のアイコンＩ２５を１つだけ表示させる場合には、一部の参加者を宛先から除外する場合には、変形例２のように除外指定をする必要があるが、変形例３によれば、除外したい参加者のアイコンＩ２４を削除すれば済むので、一部の参加者を宛先から除外する場合の手間を軽減できる。

【0101】

［５－４．変形例４］
例えば、実施形態の例では、予定には、参加者として、個人又はグループを登録可能である。この場合、通知部１０２は、全員指定が受け付けられた場合に、グループには通知を行わずに、個人に通知を行ってもよい。例えば、予定の参加者として、「営業部」といったグループが登録されていたとする。この場合、通知部１０２は、全員指定が受け付けられた場合に、「営業部」の全員を宛先としては通知を行わずに、あくまで個人として参加する参加者にだけ通知を行ってもよい。

【0102】

参加者が個人であるかグループであるかを示す情報は、データ記憶部１００に予め記録されているものとする。例えば、ユーザデータベースＤＢ１に、ユーザの１つとしてグループも登録されている。この場合、ユーザデータベースＤＢ１には、個人であるかグループであるかを示す属性が格納されてもよい。通知部１０２は、この属性に基づいて、参加者が個人であるかグループであるかを特定する。通知部１０２は、全員指定が受け付けられた場合に、参加者の全員の中にグループが含まれている場合には、グループを宛先に設定せずに、個人の参加者だけを宛先に設定する。グループに所属する者には、そもそも通知が行われないようにしてもよいし、自分宛以外の通知が行われてもよい。

【0103】

変形例４の予定管理システム１は、全員指定が受け付けられた場合に、グループには通知を行わずに、個人に通知を行う。グループ全員に通知が行われると、予定に関連性の薄い多くの者に通知が行われる可能性があるが、グループには通知を行わないことによって、予定に関連性の薄い者に通知が行われることを防止できる。また、関連性の薄い者への通知が多数行われることを防止できるので、サーバ１０の処理負荷を軽減できる。

【0104】

［５－５．変形例５］
例えば、予定管理システム１は、予定の参加者に対し、出欠確認を行う機能を有してもよい。変形例５の予定管理システム１は、出欠確認部１０３を含む。出欠確認部１０３は、複数の参加者の各々に、予定への出欠確認を行う。出欠確認自体は、種々の方法によって行われてよい。例えば、出欠確認部１０３は、出欠するか否かを回答するための画面を、グループウェア上の画面として、参加者のユーザ端末２０に表示させ、当該画像に対する選択結果に基づいて、出欠確認を行う。

【0105】

例えば、出欠確認部１０３は、電子メール等の他の手段を利用して、参加者に対し、出欠確認を行ってもよい。出欠確認部１０３は、グループウェア上の画面又は電子メール等における参加者の操作に基づいて、出欠確認の結果を取得する。変形例５では、出席、欠席、又は保留といった３種類の回答が可能な場合を説明するが、回答の種類は、出席又は欠席のみであってもよいし、他の回答が可能であってもよい。出欠確認部１０３は、出欠確認部１０３は、参加者のユーザ端末２０から受信した出欠確認の結果を、予定データベースＤＢ２に格納する。

【0106】

変形例５の通知部１０２は、出欠確認に対する回答に関係なく、全員に通知を行うものとする。即ち、通知部１０２は、出席の回答をした参加者だけではなく、欠席の回答をした参加者と、回答をしていない又は保留にした参加者と、についても通知を行う。通知部１０２は、未回答の参加者についても通知を行う。通知部１０２は、予定に登録された参加者であれば、通知を行うことになる。

【0107】

変形例５の予定管理システム１は、出欠確認に対する回答に関係なく、全員に通知を行う。これにより、参加者が欠席の回答をしたとしてもコメントに気付きやすくなる。例えば、参加者が欠席の回答をしたとしても、通知によって重要な議題があることに気付き、予定に出席するといった判断材料を与えることができる。

【0108】

［５－６．変形例６］
例えば、予定には、複数の参加者以外の他の者も登録可能であってもよい。他の者は、予定には参加しないが予定に何らかの関係のある者である。例えば、予定に関する情報を共有する共有先は、他の者に相当する。共有先に指定された者は、予定の日時等の情報を閲覧できる。例えば、参加者の上司又はアシスタントが共有先に指定される。予定の登録時又は変更時に、任意のユーザが他の者として指定される。他の者の名前は、予定データベースＤＢ２に格納される。

【0109】

変形例６の通知部１０２は、全員指定が受け付けられた場合に、他の者には通知を行わずに、参加者の全員に通知を行うものとする。共有先等として指定された他の者が通知を受け取らない点で実施形態とは異なるが、参加者の全員に通知を行う処理自体は、実施形態で説明した通りである。なお、他の者は、参加者以外の者であればよく、共有先に限られない。例えば、出欠確認をする場合に、欠席の回答をした者は、参加者以外の他の者とみなしてもよい。この場合、当初は出席者として登録されたが、欠席の回答をした者には通知が行われないことになる。回答を保留した者、又は、出欠確認に対して未回答の者が、他の者に相当してもよい。

【0110】

変形例６の予定管理システム１は、全員指定が受け付けられた場合に、予定に登録された他の者には通知を行わずに、参加者の全員に通知を行う。これにより、予定に何らか関係するが、コメントに気付かなくても問題ない他の者に通知が行われることを防止できる。また、予定への関連性が相対的に薄い者への通知が行われることを防止できるので、サーバ１０の処理負荷を軽減できる。

【0111】

［５－７．変形例７］
例えば、図４，５の例において、ユーザＡが、個別指定でユーザＢ，Ｄ，Ｆを宛先に指定したあとに、やはり全員指定しようと思って全員指定をすることがある。ユーザＡがそのままコメントの入力を完了すると、ユーザＢ，Ｄ，Ｆは、個別指定及び全員指定の両方で宛先が指定されたことになる。この場合、ユーザＢ，Ｄ，Ｆが同じ通知を２つ受け取らないように制御してもよい。

【0112】

変形例７の予定管理システム１は、重複制御部１０４を含む。重複制御部１０４は、複数の参加者のうちの何れかが個別指定で指定され、かつ、全員指定が受け付けられた場合に、当該参加者のユーザ端末２０に通知が重複して表示されないように制御する。ユーザ端末２０は、参加者の端末の一例である。参加者の端末は、ユーザ端末２０以外の任意の名前であってよい。

【0113】

例えば、重複制御部１０４は、ある参加者が個別指定及び全員指定の両方で宛先に指定された場合に、１つの通知データだけをユーザデータベースＤＢ１に登録する。この場合の通知データの生成方法は、実施形態で説明した通りである。重複制御部１０４は、個別指定によって通知データを生成する処理、又は、全員指定によって通知データを生成する処理の何れか一方だけを実行するように、通知部１０２を制御すればよい。

【0114】

例えば、通知部１０２は、個別指定によって生成された通知データと、全員指定によって生成された通知データと、の両方をユーザデータベースＤＢ１に登録してもよい。この場合、重複制御部１０４は、通知画面ＳＣ３をユーザ端末２０に表示させる場合に、これらの通知データに基づいて同じ通知を２つ表示させるのではなく、１つの通知にまとめて表示させるようにしてもよい。同じ通知であるか否かは、通知ＩＤによって判定されてもよいし、通知に対応するコメントの内容が同じであれば同じ通知であると判定されるようにしてもよい。

【0115】

変形例７の予定管理システム１は、複数の参加者のうちの何れかが個別指定で指定され、かつ、全員指定が受け付けられた場合に、当該参加者のユーザ端末２０に通知が重複して表示されないように制御する。これにより、参加者が同じ通知を複数受け取って困惑するといったことを防止できる。通知画面ＳＣ３の煩雑さを減らすことができる。

【0116】

［５－８．変形例８］
例えば、全員指定の方法として、主に、実施形態で説明した第１の方法と、変形例３で説明した第２の方法と、の２つを例に挙げた。参加者の人数が多いと、第２の方法では多数の名前が表示されるので、第１の方法の利便性が高いと考えられる。一方、参加者の人数が少ないと、第１の方法では一部の参加者を宛先から除外しにくいので、第２の方法の利便性が高いと考えられる。このため、予定の人数に応じて、第１の方法と第２の方法の何れで全員指定を行うかが変わるようにしてもよい。

【0117】

予定管理システム１では、全員指定であることを意味する所定の文字又は文字列が入力されることによって全員指定が行われる第１の方法と、予定画面ＳＣ２に表示された所定の画像が選択された場合に、全員分の名前が自動入力されることによって全員指定が行われる第２の方法と、が可能である。第１の方法と第２の方法は、それぞれ実施形態と変形例３で説明した通りである。

【0118】

予定管理システム１は、決定部１０５を含む。決定部１０５は、複数の参加者の人数に基づいて、予定画面ＳＣ２において第１の方法又は第２の方法の何れを受け付けるかを決定する。例えば、決定部１０５は、人数が閾値以上である場合に、第１の方法を受け付けると決定する。決定部１０５は、人数が閾値未満である場合に、第２の方法を受け付けると決定する。閾値は、任意の数値であってよく、例えば、５～１０人程度であってもよいし、それ以上又はそれ以下であってもよい。ユーザが自身で閾値を設定できるようにしてもよい。閾値は、グループウェアのユーザ数等に応じて動的に設定されてもよい。

【0119】

例えば、予定画面ＳＣ２の表示データは、決定部１０５の決定結果に応じて生成される。例えば、サーバ１０は、決定部１０５により第１の方法が決定された場合には、ボタンＢ２３が選択された場合に「参加者」を自動入力してアイコンＩ２５を表示させるスクリプトを含む表示データを生成する。サーバ１０は、決定部１０５により第２の方法が決定された場合には、ボタンＢ２３が選択された場合に全員分の名前を自動入力して全員分のアイコンＩ２４を表示させるスクリプトを含む表示データを生成する。ボタンＢ２３が選択された場合には、スクリプトに応じた処理が実行され、「参加者」又は名前が自動入力されてアイコンＩ２４又はアイコンＩ２５が表示される。

【0120】

変形例８の予定管理システム１は、複数の参加者の人数に基づいて、予定画面ＳＣ２において第１の方法又は第２の方法の何れを受け付けるかを決定する。これにより、人数に応じた使い勝手の良い全員指定をすることができるので、ユーザの利便性が高まる。

【0121】

［５－９．その他の変形例］
例えば、変形例１～８を組み合わせてもよい。

【0122】

例えば、通知が１種類だけの場合には、個別指定で宛先に指定されなかった参加者には、通知が行われないようにしてもよい。例えば、予定管理システム１は、グループウェアではない他のサービスの予定を管理してもよい。他のサービスとしては、業務を支援する目的以外の目的で予定を管理するサービス（例えば、学校生活を支援するサービス）であってもよいし、公共施設又は娯楽施設といった施設の予約を受け付けるサービスであってもよい。

【0123】

例えば、上記説明した各機能は、予定管理システム１における任意の装置で実現されるようにすればよい。例えば、サーバ１０で実現されるものとして説明した機能がユーザ端末２０によって実現されてもよい。この場合、表示制御部１０１及び通知部１０２と同様の機能が、ブラウザのスクリプトによって実行されたり、ユーザ端末２０にインストールされたアプリケーションによって実行されたりすることによって実現されるようにすればよい。例えば、各機能は、複数のコンピュータによって分担されてもよいし、１つのコンピュータによって実現されてもよい。

【符号の説明】

【0124】

１ 予定管理システム、１０ サーバ、１１，２１ 制御部、１２，２２ 記憶部、１３，２３ 通信部、２０ ユーザ端末、２４ 操作部、２５ 表示部、Ｎ ネットワーク、１００ データ記憶部、１０１ 表示制御部、１０２ 通知部、１０３ 出欠確認部、１０４ 重複制御部、１０５ 決定部、２００ データ記憶部、２０１ 表示制御部、２０２ 操作受付部、２０３ 自動入力部、Ｂ２１，Ｂ２２，Ｂ２３，Ｂ３０，Ｂ３１，Ｂ３２，Ｂ３３ ボタン、Ｉ２４，Ｉ２５ アイコン、ＤＢ１ ユーザデータベース、ＤＢ２ 予定データベース、Ｆ２０ 入力フォーム、ＳＣ１ カレンダー画面、ＳＣ２ 予定画面、ＳＣ３ 通知画面。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】