(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公開特許公報(A)
(11)【公開番号】P2024024489
(43)【公開日】2024-02-22
(54)【発明の名称】予定管理システム、通知方法、及びプログラム
(51)【国際特許分類】
G06Q 10/109 20230101AFI20240215BHJP
G06Q 50/10 20120101ALI20240215BHJP
【FI】
G06Q10/10 340
G06Q50/10
【審査請求】有
【請求項の数】11
【出願形態】OL
(21)【出願番号】P 2022127341
(22)【出願日】2022-08-09
【新規性喪失の例外の表示】特許法第30条第2項適用申請有り 令和3年10月20日、https://garoon.cybozu.co.jp/、https://garoon.cybozu.co.jp/mtcontents/support/cloud/update/211114.html 令和3年11月12日、https://jp.cybozu.help/、https://jp.cybozu.help/g/ja/user/basic/mention.html、https://jp.cybozu.help/g/ja/user/application/scheduler/comment.html 令和3年11月14日、https://cybozu.com/
(71)【出願人】
【識別番号】500022557
【氏名又は名称】サイボウズ株式会社
(74)【代理人】
【識別番号】110000154
【氏名又は名称】弁理士法人はるか国際特許事務所
(72)【発明者】
【氏名】河合 真知子
(72)【発明者】
【氏名】河内山 琢哉
(72)【発明者】
【氏名】桝山 光也
(72)【発明者】
【氏名】松井 雅和
【テーマコード(参考)】
5L049
【Fターム(参考)】
5L049AA13
5L049CC11
(57)【要約】
【課題】コメントに関する宛先を指定する手間を軽減する。
【解決手段】予定管理システム(1)は、複数の参加者が参加する予定を管理する。表示制御部(101)は、予定に関するコメントの入力と、コメントに関する通知の宛先を個別に指定する個別指定と、複数の参加者の全員をまとめて宛先に指定する全員指定と、を受付可能な予定画面を表示させる。通知部(102)は、個別指定が受け付けられた場合に、個別指定で指定された者に通知を行い、全員指定が受け付けられた場合に、全員に通知を行う。
【選択図】
図8
【特許請求の範囲】
【請求項1】
複数の参加者が参加する予定を管理する予定管理システムであって、
前記予定に関するコメントの入力と、前記コメントに関する通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部と、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部と、
を含む予定管理システム。
【請求項2】
前記通知部は、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に、自分が前記宛先に指定されたことを示す自分宛通知を行い、かつ、前記個別指定で指定されなかった前記参加者に、前記自分宛通知とは異なる他の通知を行い、
前記全員指定が受け付けられた場合に、前記全員に前記自分宛通知を行う、
請求項1に記載の予定管理システム。
【請求項3】
前記通知部は、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に、前記個別指定により自分が前記宛先に指定されたことを示す第1自分宛通知を行い、かつ、前記個別指定で指定されなかった前記参加者に、前記他の通知を行い、
前記全員指定が受け付けられた場合に、前記全員に、前記全員指定により自分が前記宛先に指定されたことを示す第2自分宛通知を行う、
請求項2に記載の予定管理システム。
【請求項4】
前記個別指定は、個人名又はグループ名が入力されることによって行われ、
前記全員指定は、前記全員分の個人名又はグループ名を入力する操作とは異なる操作によって行われる、
請求項1~3の何れかに記載の予定管理システム。
【請求項5】
前記予定画面では、前記宛先から除外する除外指定を更に受付可能であり、
前記通知部は、前記全員指定又は前記個別指定が受け付けられ、かつ、前記除外指定が受け付けられた場合に、前記除外指定により指定された前記宛先を除外して前記通知を行う、
請求項4に記載の予定管理システム。
【請求項6】
前記個別指定は、個人名又はグループ名が入力されることによって行われ、
前記予定管理システムは、前記全員指定が行われた場合に、前記全員分の名前を自動入力する自動入力部を更に含む、
請求項1~3の何れかに記載の予定管理システム。
【請求項7】
前記予定には、前記参加者として、個人又はグループを登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記グループには前記通知を行わずに、前記個人に前記通知を行う、
請求項1~3の何れかに記載の予定管理システム。
【請求項8】
前記予定には、前記複数の参加者以外の他の者も登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記他の者には前記通知を行わずに、前記全員に前記通知を行う、
請求項1~3の何れかに記載の予定管理システム。
【請求項9】
前記予定管理システムは、前記複数の参加者のうちの何れかが前記個別指定で指定され、かつ、前記全員指定が受け付けられた場合に、当該参加者の端末に前記通知が重複して表示されないように制御する重複制御部を更に含む、
請求項1~3の何れかに記載の予定管理システム。
【請求項10】
前記予定管理システムでは、
前記全員指定であることを意味する所定の文字又は文字列が入力されることによって前記全員指定が行われる第1の方法と、
前記予定画面に表示された所定の画像が選択された場合に、前記全員分の名前が自動入力されることによって前記全員指定が行われる第2の方法と、
が可能であり、
前記予定管理システムは、前記複数の参加者の人数に基づいて、前記予定画面において前記第1の方法又は前記第2の方法の何れを受け付けるかを決定する決定部を更に含む、
請求項1~3の何れかに記載の予定管理システム。
【請求項11】
複数の参加者が参加する予定に関する通知方法であって、
前記予定に関するコメントの入力と、前記コメントに関する通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御ステップと、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知ステップと、
を含む通知方法。
【請求項12】
複数の参加者が参加する予定を管理するコンピュータを、
前記予定に関するコメントの入力と、前記コメントに関する通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部、
として機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【0001】
本開示は、予定管理システム、通知方法、及びプログラムに関する。
【背景技術】
【0002】
従来、複数のユーザが参加する予定に関するコメントを入力可能な予定管理システムが知られている。このような予定管理システムでは、コメントに気付きやすくなるように、予定の参加者に通知を行うことが考えられる。例えば、特許文献1には、ユーザが宛先に指定されたコメントが入力されると、ユーザが宛先に指定されたことを示す自分宛通知を行い、ユーザが宛先に指定されずにコメントが入力されると、自分宛以外の通知を行うシステムが記載されている。ユーザの端末には、自分宛通知と、自分宛以外の通知と、を区別した画面が表示される。
【先行技術文献】
【特許文献】
【0003】
【発明の概要】
【発明が解決しようとする課題】
【0004】
例えば、上記のような予定管理システムに、特許文献1の技術を適用したとする。この場合、宛先が指定されたコメントが入力されると、自分宛通知が行われるので、宛先に指定された者は、コメントに気付きやすくなる。しかしながら、予定の参加者が増えると、宛先を指定するのに手間がかかる。この点は、自分宛通知と、自分宛以外の通知と、を区別する場合に限られず、何らかの通知の宛先を指定する場合も同様である。
【0005】
本開示の目的の1つは、コメントに関する宛先を指定する手間を軽減することである。
【課題を解決するための手段】
【0006】
本開示に係る予定管理システムは、複数の参加者が参加する予定を管理する予定管理システムであって、前記予定に関するコメントの入力と、前記コメントに関する通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部と、前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部と、を含む。
【発明の効果】
【0007】
本開示によれば、コメントに関する宛先を指定する手間を軽減できる。
【図面の簡単な説明】
【0008】
【
図1】予定管理システムのハードウェア構成の一例を示す図である。
【
図6】ユーザBのユーザ端末に表示される通知画面の一例を示す図である。
【
図7】ユーザCのユーザ端末に表示される通知画面の一例を示す図である。
【
図8】予定管理システムで実現される機能の一例を示す図である。
【
図11】予定管理システムで実行される処理の一例を示す図である。
【
図12】変形例における機能の一例を示す図である。
【発明を実施するための形態】
【0009】
[1.予定管理システムのハードウェア構成]
本開示に係る予定管理システムの実施形態の一例を説明する。
図1は、予定管理システムのハードウェア構成の一例を示す図である。例えば、予定管理システム1は、サーバ10及びユーザ端末20を含む。サーバ10及びユーザ端末20の各々は、インターネット又はLAN等のネットワークNに接続される。
【0010】
サーバ10は、サーバコンピュータである。例えば、サーバ10は、制御部11、記憶部12、及び通信部13を含む。制御部11は、少なくとも1つのプロセッサを含む。記憶部12は、RAM等の揮発性メモリと、フラッシュメモリ等の不揮発性メモリと、を含む。通信部13は、有線通信用の通信インタフェースと、無線通信用の通信インタフェースと、の少なくとも一方を含む。
【0011】
ユーザ端末20は、ユーザのコンピュータである。例えば、ユーザ端末20は、パーソナルコンピュータ、タブレット端末、又はスマートフォンである。例えば、ユーザ端末20は、制御部21、記憶部22、通信部23、操作部24、及び表示部25を含む。制御部21、記憶部22、及び通信部23のハードウェア構成は、それぞれ制御部11、記憶部12、及び通信部13と同様であってよい。操作部24は、マウス、タッチパネル、又はキーボード等の入力デバイスである。表示部25は、液晶ディスプレイ又は有機ELディスプレイである。
【0012】
なお、記憶部12,22に記憶されるプログラムは、ネットワークNを介して供給されてもよい。サーバ10及びユーザ端末20の各々のハードウェア構成は、
図1の例に限られない。例えば、コンピュータ読み取り可能な情報記憶媒体を読み取る読取部(例えば、光ディスクドライブやメモリカードスロット)、又は、外部機器と直接的に接続するための入出力部(例えば、USB端子)が含まれてもよい。この場合、情報記憶媒体に記憶されたプログラムが読取部又は入出力部を介して供給されてもよい。
【0013】
また、予定管理システム1は、少なくとも1つのコンピュータを含めばよい。予定管理システム1に含まれるコンピュータは、
図1の例に限られない。例えば、予定管理システム1は、ユーザ端末20を含まなくてもよい。この場合、ユーザ端末20は、予定管理システム1の外部に存在し、予定管理システム1は、サーバ10だけを含む。予定管理システム1は、サーバ10と、他のサーバコンピュータと、を含んでもよい。
【0014】
[2.予定管理システムの概要]
予定管理システム1は、複数の参加者が参加する予定を管理する。参加者は、予定に参加するユーザである。予定は、所定の場所で所定の日時に行われるイベント又は行動である。予定自体は、種々のタイプであってよく、例えば、会議、セミナー、説明会、面接、レクリエーション、外出、又はその他のイベントである。予定は、現実空間で行われるものに限られず、バーチャル空間又はオンライン上で行われるものであってもよい。
【0015】
本実施形態では、クラウド型のグループウェアがユーザに提供される場合を例に挙げる。グループウェアは、ユーザの業務を支援するサービス又はプログラムである。グループウェアは、クラウド型に限られず、オンプレミス型であってもよい。本実施形態では、グループウェアで利用可能な機能のうち、主に、予定の管理に関する機能を説明する。例えば、ユーザがグループウェアにログインすると、カレンダー形式で予定を表示するためのカレンダー画面が表示部25に表示される。
【0016】
図2は、カレンダー画面の一例を示す図である。本実施形態では、ブラウザ上で各画面が表示される場合を説明するが、各画面は、グループウェア専用のプログラム上で表示されてもよい。ユーザは、カレンダー画面SC1から、新たな予定を登録したり、登録済みの予定を確認したりすることができる。例えば、ユーザが、
図2のカレンダー画面SC1の中から、2022年8月5日の16時~17時の予定「会議:Y社」を選択すると、この予定の詳細を示す予定画面が表示部25に表示される。
【0017】
図3は、予定画面SC2の一例を示す図である。例えば、予定画面SC2には、予定の日時、予定の名前、予定の補足説明としてのメモ、参加者の名前(
図3では、ユーザA~Jの10人の名前)、予定で利用する施設、アップロードされた添付ファイル、及び予定に対するリアクションといった種々の情報が表示される。ユーザは、予定画面SC2から、予定を変更又は削除したり、自身が参加者として登録されている予定から抜けたりすることもできる。
【0018】
図3の予定画面SC2は、入力フォームF20から、予定に関するコメントを入力できるようになっている。コメントは、予定に関係する何らかの者に対するメッセージである。この者は、参加者であってもよいし、参加者以外の他の者であってもよい。先述したメモも、コメントの一種である。コメントは、任意の文章であってよい。例えば、コメントは、予定に関する内容だけではなく、予定には関係のない雑談であってもよい。予定に参加しない者がコメントを入力可能であってもよい。
【0019】
図3の例では、参加者の1人であるユーザAが、予定画面SC2を表示させている。例えば、ユーザAは、入力フォームF20に、任意のコメントを入力する。ユーザAがボタンB21を選択すると、予定に関連付けられてコメントが登録される。再び予定画面SC2を表示させると、コメントが予定画面SC2に表示される。ユーザAとともに予定に参加するユーザB~Jは、通知を受け取る。
【0020】
通知は、コメントが入力されたことを示す情報である。メンション又はアラートも通知の一種である。本実施形態では、グループウェアの画面上で通知が行われる場合を説明するが、通知は、他の方法を利用して行われてもよい。例えば、通知は、電子メール、SMS、SNS、メッセージアプリ、又はOSが有する通知機能(例えば、プッシュ又はバナー)といった他の方法を利用して行われてもよい。通知は、複数の方法を組み合わせて行われてもよい。例えば、グループウェアの画面上で表示されるメンションと、ユーザのメールアドレス宛に送信される電子メールと、の各々が通知に相当してもよい。
【0021】
本実施形態では、ユーザが宛先に指定されたことを示す「自分宛通知」と、自分宛通知とは異なる「自分宛以外の通知」と、の2種類の通知が存在する。自分宛通知は、ユーザが宛先として指定されたコメントが入力されたことを示す通知である。自分宛以外の通知は、ユーザが宛先として指定されなかったコメントが入力されたことを示す通知である。これらの通知を区別することによって、ユーザは、より重要な自分宛通知に気付きやすくなる。以降、自分宛通知と、自分宛以外の通知と、を区別しない時は、単に通知という。
【0022】
なお、通知は、本実施形態のような2種類に限られない。例えば、自分宛通知と、自分宛以外の通知と、を区別せずに、1種類の通知だけが存在してもよい。例えば、コメントを入力したユーザの役職又は部署に応じて通知を使い分けることによって、3種類以上の通知が存在してもよい。通知は、コメントの入力時以外の場面で行われてもよい。例えば、予定の登録時、変更時、又は削除時に通知が行われてもよい。例えば、予定の管理以外にも、何らかの情報が登録、変更、又は削除された場合に、通知が行われてもよい。
【0023】
図3の例であれば、ユーザAは、コメントに気付いてほしい他のユーザを、宛先に指定する。本実施形態では、参加者以外の他の者も宛先に指定できる場合を説明するが、参加者だけを宛先に指定できるようにしてもよい。予定管理システム1では、宛先の指定方法として、宛先を個別に指定する個別指定と、参加者の全員をまとめて宛先に指定する全員指定と、の2種類が用意されている。ユーザAは、個別指定及び全員指定の少なくとも一方を利用して、宛先を指定する。
【0024】
図4は、個別指定の流れの一例を示す図である。例えば、ユーザAが、ボタンB22を選択すると、入力フォームF20の上部に宛先を入力できるようになる。ユーザAは、宛先の指定を意味する「@」と、宛先として指定する他のユーザの名前と、を入力フォームF20に入力する。「@」は、ボタンB22の選択に応じて自動入力されてもよい。ユーザAは、ボタンB22を選択せずに、コメントの本文中に「@」と他のユーザの名前を手入力してもよい。ユーザAは、他のユーザの名前を手入力してもよいし、他のユーザ名の名前を示すリストの中から、宛先となる他のユーザの名前を選択してもよい。
【0025】
本実施形態では、「@」とユーザの名前を入力する一連の操作が、個別指定に相当する。
図4の例では、個別指定によって、ユーザB,D,Fの3人が宛先に指定されている。入力フォームF20には、ユーザB,D,Fをそれぞれ示す3つのアイコンI24が表示される。例えば、ユーザAは、更に宛先を追加したり、逆に宛先を削除したりすることもできる。宛先の削除は、アイコンI24の「×」を選択することによって行われてもよいし、キーボードのDeleteボタン等を利用して行われてもよい。
【0026】
なお、
図4の例では、アイコンI24が入力フォームF20の上部に表示される場合が示されているが、アイコンI24は、他の位置に表示されてもよい。例えば、アイコンI24は、コメントの本文中に挿入されてもよいし、入力フォームF20の下部又は外部に表示されてもよい。例えば、アイコンI24ではなく、「@ユーザB」といった文字列が表示されてもよい。また、個別指定が行われてからコメントが入力されてもよいし、コメントが入力されてから個別指定が行われてもよい。
【0027】
図4の例において、コメントの入力が完了すると、宛先に指定されたユーザB,D,Fは、自分宛通知を受け取る。宛先に指定されなかった参加者であるユーザC,E,G,H,I,Jは、自分宛以外の通知を受け取る。本実施形態では、コメントを入力した本人であるユーザAは、通知を受け取らないものとするが、コメントを入力した本人であるユーザAも、通知を受け取れるようにしてもよい。また、宛先に指定されなかった参加者であるユーザC,E,G,H,I,Jは、通知を受け取らないようにしてもよい。
【0028】
図5は、全員指定の流れの一例を示す図である。例えば、ユーザAが、ボタンB23を選択すると、「参加者」の文字列を示すアイコンI25が入力フォームF20に表示される。ユーザAは、ボタンB23を選択せずに、コメントの本文中に「@参加者」といった文字列を手入力してもよい。本実施形態では、ボタンB23を選択する操作が、全員指定に相当する。1回の全員指定をすることは、実質的に、ユーザB~Jの9人分の個別指定をすることと同等の結果が得られる。
【0029】
例えば、ユーザAは、参加者以外の者を宛先に追加したり、逆に宛先を削除したりすることもできる。宛先の削除は、アイコンI25の「×」を選択することによって行われてもよいし、キーボードのDeleteボタン等を利用して行われてもよい。個別指定と同様に、アイコンI25は、任意の位置に表示可能である。アイコンI25ではなく、「@参加者」といった文字列が表示されてもよい。また、全員指定が行われてからコメントが入力されてもよいし、コメントが入力されてから全員指定が行われてもよい。
【0030】
図5の例において、コメントの入力が完了すると、宛先に指定された参加者の全員であるユーザB~Jは、自分宛通知を受け取る。本実施形態では、参加者がコメントを入力した場合に、コメントを入力した本人は通知を受け取らない。このため、参加者がコメントを入力した場合の「全員」は、コメントを入力した本人を除いた参加者の全員を意味する。コメントを入力した本人も通知を受け取るようにする場合には、「全員」は、コメントを入力した本人も含む。
【0031】
本実施形態では、グループウェア上の通知画面で通知が表示される。通知画面では、自分宛通知と、自分宛以外の通知と、が区別される。例えば、通知画面では、自分宛通知だけを表示する状態と、自分宛通知と自分宛以外の通知の両方を含む全ての通知を表示する状態と、を切り替えられるようになっている。以降、
図4,5のコメントが入力された後にユーザB,Cのユーザ端末20に表示される通知画面を例に挙げる。なお、説明の簡略化のために、ユーザB,Cは、他の通知を受け取っていないものとする。
【0032】
図6は、ユーザBのユーザ端末20に表示される通知画面の一例を示す図である。例えば、ボタンB30が選択されると、未読の通知だけが通知画面SC3に表示される。ボタンB31が選択されると、既読の通知だけが通知画面SC3に表示される。ボタンB32が選択されると、自分宛通知と自分宛以外の通知の両方を含む全ての通知が通知画面SC3に表示される。ボタンB33が選択されると、自分宛通知だけが通知画面SC3に表示される。
【0033】
なお、ボタンB30,B31は、何れか一方しか選択できないものとする。ボタンB32,B33も、何れか一方しか選択できないものとする。これらの掛け合わせによって、通知画面SC3の表示が切り替わる。
図6の例では、ボタンB30,33が選択されているので、未読の自分宛通知だけが通知画面SC3に表示される。ユーザBは、
図4のコメントが入力されたことを示す自分宛通知と、
図5のコメントが入力されたことを示す自分宛通知と、を受け取る。これら2つの自分宛通知が両方とも未読だったとすると、
図6のように、これら2つの自分宛通知が通知画面SC3に表示される。
【0034】
図7は、ユーザCのユーザ端末20に表示される通知画面の一例を示す図である。
図4,5の例では、ユーザCは、
図4のコメントでは宛先に指定されておらず、
図5のコメントで宛先に指定されている。このため、ユーザCは、
図4のコメントが入力されたことを示す自分宛以外の通知と、
図5のコメントが入力されたことを示す自分宛通知と、を受け取る。
図5のコメントが入力されたことを示す自分宛通知が未読だったとすると、
図7の上側の通知画面SC3では、ボタンB30,B33が選択されているので、この自分宛通知だけが表示される。
【0035】
例えば、ユーザCがボタンB32を選択すると、自分宛通知と自分宛以外の通知の両方を含む全ての未読の通知が通知画面SC3に表示される。
図4のコメントが入力されたことを示す自分宛以外の通知も未読だったとすると、
図7の下側の通知画面SC3のように、この自分宛以外の通知も表示される。以上のように、予定管理システム1は、コメントが入力された場合の通知に関する種々の構成を有する。特に、予定管理システム1は、全員指定によって宛先を指定する手間を軽減する構成を有する。以降、予定管理システム1の詳細について説明する。
【0036】
[3.予定管理システムで実現される機能]
図8は、予定管理システム1で実現される機能の一例を示す図である。
【0037】
[3-1.サーバで実現される機能]
例えば、サーバ10は、データ記憶部100、表示制御部101、及び通知部102を含む。データ記憶部100は、記憶部12により実現される。表示制御部101及び通知部102の各々は、制御部11により実現される。
【0038】
[データ記憶部]
データ記憶部100は、予定を管理するために必要なデータを記憶する。例えば、データ記憶部100は、ユーザデータベースDB1と、予定データベースDB2と、を記憶する。
【0039】
図9は、ユーザデータベースDB1の一例を示す図である。ユーザデータベースDB1は、ユーザに関する各種データが格納されたデータベースである。例えば、ユーザデータベースDB1には、ユーザID、パスワード、ユーザの名前、ユーザの所属、及び通知データが格納される。ユーザに関する何らかの情報が表示される場合には、ユーザデータベースDB1に格納された情報が参照される。ユーザデータベースDB1に格納されるデータは、ユーザに関する任意のデータであってよく、
図9の例に限られない。例えば、ユーザデータベースDB1には、ユーザのメールアドレス又は電話番号といった通知の送信先になりうるデータが格納されてもよい。
【0040】
ユーザID及びパスワードは、ログイン時に必要な認証情報である。ユーザの名前は、宛先を指定するために利用される。所属は、ユーザが属するグループに関する情報である。例えば、所属は、会社の名前と、部署の名前と、を含む。通知データは、ユーザが受け取った通知に関する情報を含む。例えば、通知データは、通知ID、通知の種類、未読/既読フラグ、通知のタイトル、通知の内容、通知が行われる要因となった行為をしたユーザの名前、及び通知の日時を含む。通知データは、後述の通知部102により生成されてユーザデータベースDB1に格納される。
【0041】
通知IDは、通知を一意に識別可能な情報である。通知の種類は、自分宛通知であるか、又は、自分宛以外の通知であるかを示す。自分宛以外の通知は、自分宛通知とは異なる他の通知の一例である。このため、自分宛以外の通知と記載した箇所は、他の通知と読み替えることができる。通知のタイトルは、通知の要因となった情報を示す。
図3~
図7の例であれば、「会議:Y社」の予定に関するコメントが通知の要因になっているので、通知のタイトルは、「会議:Y社」となる。通知の内容は、コメントの全部又は一部である。ユーザの名前は、
図3~
図7の例であれば、コメントを入力したユーザAの名前である。通知の日時は、通知が行われた時の日時である。
【0042】
なお、通知データは、ユーザデータベースDB1以外の他のデータベースに格納されてもよい。他のデータベースは、通知に関する各種データが格納される通知専用のデータベースであってもよい。通知データに含まれる情報は、任意の情報であってよく、
図9の例に限られない。例えば、通知データには、通知に起因するアプリケーション等の他の情報が含まれてもよい。サーバ10は、通知データに基づいて、通知画面SC3をユーザ端末20に表示させる。ユーザがボタンB30~B33を選択した場合には、サーバ10は、通知データに含まれる未読/既読フラグや通知の種類に基づいて、表示すべき通知を特定して通知画面SC3の表示を切り替えればよい。
【0043】
図10は、予定データベースDB2の一例を示す図である。予定データベースDB2は、登録済みの予定に関する各種データが格納されたデータベースである。例えば、予定データベースDB2には、予定ID、予定の種類、日時、タイトル、メモ、参加者、予約済みの施設の名前、添付ファイル、リアクション、登録者、変更者、及びコメントデータが格納される。予定データベースDB2に格納されるデータは、予定に関する任意のデータであってよく、
図10の例に限られない。
【0044】
予定IDは、予定を一意に識別可能な情報である。予定の種類は、単発の通常予定、一定の期間にまたがる期間予定、又は繰り返し発生する繰り返し予定の何れかを示す。予定の日時、タイトル、メモ、参加者、予約済みの施設の名前、及び添付ファイルは、予定の登録時又は変更時に入力される。登録者は、予定を登録したユーザである。変更者は、予定を変更したユーザである。コメントデータは、コメントに関する情報を含む。例えば、コメントデータは、コメント本文、宛先、入力者、及び入力日時を含む。入力者は、コメントを入力したユーザである。入力日時は、コメントが入力された時の日時である。
【0045】
例えば、サーバ10は、グループウェア上で新たな予定が作成されると、この予定の予定IDを新たに発行する。サーバ10は、予定データベースDB2に新たなレコードを作成し、予定IDと、予定の作成時に指定された種類や日時等の情報と、を関連付けてレコードに格納する。サーバ10は、ある予定に関するコメントが入力されると、この予定の予定IDに関連付けて、当該コメントのコメントデータを格納する。本実施形態では、コメントデータに含まれる宛先は、後述の通知部102によって特定されるものとする。通知部102は、特定した宛先をコメントデータに含めるようにして、予定データベースDB2に格納する。
【0046】
なお、データ記憶部100に記憶されるデータは、上記の例に限られない。データ記憶部100は、任意のデータを記憶可能である。例えば、データ記憶部100は、各種画面を表示するためのデータ、又は、予定で利用可能な施設の予約状況を示すデータといった他のデータを記憶してもよい。
【0047】
[表示制御部]
表示制御部101は、各種画面をユーザ端末20に表示させる。本実施形態では、表示制御部101がサーバ10に含まれるので、表示制御部101は、ユーザ端末20に対し、画面の表示データを送信することによって、画面を表示させる。本実施形態では、ブラウザ上で画面が表示されるので、表示データがHTML形式である場合を説明するが、表示データは、任意の形式であってよい。例えば、専用のプログラムで画面を表示させる場合には、表示データは、プログラムでサポートされている形式であればよい。
【0048】
本実施形態では、表示制御部101は、予定に関するコメントの入力と、コメントに関する通知の宛先を個別に指定する個別指定と、複数の参加者の全員をまとめて宛先に指定する全員指定と、を受付可能な予定画面SC2を表示させる。例えば、表示制御部101は、ユーザ端末20に対し、予定画面SC2の表示データを送信することによって、予定画面SC2を表示させる。
【0049】
なお、予定画面SC2の表示データの元となるデータは、データ記憶部100に記憶されているものとする。例えば、表示制御部101は、予定データベースDB2を参照し、ユーザが選択した予定に関する各種データを取得する。表示制御部101は、当該元となるデータと、当該取得した各種データと、に基づいて、予定画面SC2の表示データを生成する。予定画面SC2は、コメントの入力、個別指定、及び全員指定といった3つの操作を受付可能な画面であればよい。予定画面SC2は、任意のレイアウトであってよく、本実施形態の例に限られない。
【0050】
コメントの入力を受付可能な予定画面SC2とは、コメントを入力するためのコメント入力画像を含む画面である。本実施形態では、入力フォームF20がコメント入力画像に相当する場合を説明するが、コメント入力画像は、コメントを何らかの形で入力可能な画像であればよく、他の画像であってもよい。例えば、コメント入力画像は、プルダウン等の他のフォームであってもよい。例えば、定型文のコメントを入力する場合には、定型文を選択するためのラジオボタン又はチェックボックスがコメント入力画像に相当してもよい。例えば、音声入力を受け付けるための画像がコメント入力画像に相当してもよい。
【0051】
個別指定を受付可能な予定画面SC2とは、個別指定をするための個別指定画像を含む画面である。本実施形態では、入力フォームF20及びボタンB22が個別指定画像に相当する場合を説明するが、個別指定画像は、宛先となるユーザを何らかの形で指定可能な画像であればよく、他の画像であってもよい。例えば、ボタンB22を利用しない場合には、入力フォームF20だけが個別指定画像に相当してもよい。入力フォームF20を利用しない場合には、ボタンB22だけが個別指定画像に相当してもよい。例えば、ユーザのリストが個別指定画像に相当してもよい。例えば、宛先として指定する参加者を選択するためのラジオボタン又はチェックボックスが個別指定画像に相当してもよい。
【0052】
全員指定を受付可能な予定画面SC2とは、全員指定をするための全員指定画像を含む画面である。本実施形態では、入力フォームF20又はボタンB23が全員指定画像に相当する場合を説明するが、全員指定画像は、宛先として参加者の全員を指定する意思をコンピュータに伝達するための画像であればよく、他の画像であってもよい。例えば、全員指定をするためのラジオボタン又はチェックボックスが全員指定画像に相当してもよい。
【0053】
本実施形態では、個別指定は、個人名又はグループ名が入力されることによって行われる。例えば、個別指定は、「@」と、個人名又はグループ名と、の組み合わせが入力されることによって行われてもよい。「@」は、宛先の指定を意味する所定の記号の一例である。このため、「@」と記載した箇所は、宛先の指定を意味する所定の記号と読み替えることができる。この記号は、任意の記号であってよく、「@」に限られない。例えば、「+」、「#」、又は「%」といった他の記号が利用されてもよい。個人名は、宛先となるユーザの名前である。グループ名は、宛先となるグループの名前である。「営業部」といったグループも宛先として指定可能であってよい。この場合、グループに属する全員に通知が行われてもよい。
【0054】
本実施形態では、全員指定は、全員分の個人名又はグループ名を入力する操作とは異なる操作によって行われる。この操作は、先述したチェックボックスに対する操作等であってもよい。例えば、全体指定は、ボタンB23を選択し、入力フォームF20に「参加者」と入力されることによって行われる。例えば、全員指定は、「@」と、「参加者」と、の組み合わせが入力されることによって行われてもよい。「参加者」は、全員指定であることを意味する所定の文字列の一例である。このため、「参加者」と記載した箇所は、全員指定であることを意味する所定の文字列と読み替えることができる。この文字列は、任意の文字列であってよく、「参加者」に限られない。例えば、「出席者」、「全員」、又は「ALL」といった他の文字列が利用されてもよい。全員指定は、文字列ではなく、全員指定であることを意味する所定の文字が利用されてもよい。即ち、「皆」又は「全」といった1文字だけで全員指定であることを表現されてもよい。この文字も任意の文字であってよい。
【0055】
なお、宛先の指定方法は、本実施形態で説明した方法以外の他の方法であってもよい。例えば、「@」等の記号を利用せずに、個人名又はグループ名だけで個人指定が行われてもよい。例えば、「@」等の記号を利用せずに、「参加者」といった文字列、又は、「皆」といった1文字だけで全員指定が行われてもよい。逆に、文字列又は文字を利用せずに、全員指定を示す特定の記号だけを利用して、全員指定が行われてもよい。例えば、「*」が全員指定を意味する場合には、「*」を入力するだけで全員指定が行われるようにしてもよい。
【0056】
また、宛先の指定方法は、文字列を入力する方法に限られない。例えば、参加者の名前と、ラジオボタン又はチェックボックスと、の組み合わせを全員分並べて予定画面SC2に表示させる場合には、ラジオボタン又はチェックボックスを選択することによって、個別指定が行われてもよい。例えば、ユーザのリストを予定画面SC2に表示させる場合には、リストの中のユーザを選択することによって、個別指定が行われてもよい。例えば、全員指定を示すラジオボタン又はチェックボックスを予定画面SC2に表示させる場合には、ラジオボタン又はチェックボックスを選択することによって、全員指定が行われてもよい。
【0057】
[通知部]
通知部102は、予定管理システム1における通知を行う。通知を行うとは、通知に関するデータを生成してデータ記憶部100に記録すること、又は、通知自体をユーザ端末20に送信することである。本実施形態では、通知データを生成してユーザデータベースDB1に格納することが通知を行うことに相当する場合を説明するが、他のデータベースに通知データを格納することが通知を行うことに相当してもよいし、電子メール又はその他のメッセージをユーザ端末20に送信することが通知を行うことに相当してもよい。
【0058】
本実施形態では、通知部102は、個別指定が受け付けられた場合に、個別指定で指定された者に通知を行う。例えば、通知部102は、個別指定で指定された者のユーザIDと、コメントが入力されたことを示す通知の通知データと、を関連付けてユーザデータベースDB1に格納することによって、この者に通知を行う。
図4の例であれば、個別指定によってユーザB,D,Fが宛先に指定されるので、通知部102は、ユーザB,D,Fの各々のユーザIDと、通知データと、を関連付けてユーザデータベースDB1に格納する。本実施形態では、通知部102は、入力フォームF20の上部(
図4,5の例では、アイコンI24,I25が表示された部分)に入力された情報に基づいて、宛先を特定する。通知部102は、その下に入力された情報は、コメントの本文として特定する。
【0059】
例えば、通知部102は、個別指定が受け付けられた場合に、個別指定で指定された者に、自分が宛先に指定されたことを示す自分宛通知を行い、かつ、個別指定で指定されなかった参加者に、自分宛以外の通知を行う。通知部102は、個別指定で指定された者のユーザIDと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースDB1に格納する。
【0060】
例えば、通知部102は、コメントとともに受信した宛先を参照することによって、個別指定で指定された宛先を特定する。コメントの本文中に「@」と文字列を入力して宛先を指定する場合には、通知部102は、コメントに「@」が含まれるか否かを判定する。通知部102は、コメントに「@」が含まれると判定した場合に、その後に配置されたユーザの名前がユーザデータベースDB1に存在するか否かを判定する。通知部102は、ユーザの名前がユーザデータベースDB1に存在すると判定した場合に、個別指定によりこのユーザが宛先に指定されたことを特定する。
図4の例であれば、通知部102は、ユーザB,D,Fが宛先に指定されたことを特定する。
【0061】
例えば、通知部102は、ユーザB,D,Fの各々が受け取る通知の通知IDを発行し、通知データを生成する。通知部102は、当該発行された通知ID、自分宛通知を示す種類、未読であることを示す未読/既読フラグ、コメントが入力された予定のタイトル、コメントの内容、コメントを入力した入力者、及び現在の日時を通知データに含める。通知部102は、ユーザB,D,Fの各々のユーザIDと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースDB1に格納する。
【0062】
例えば、通知部102は、予定データベースDB2を参照し、宛先に指定されなかった参加者を特定する。
図4の例であれば、通知部102は、ユーザC,E,G,H,I,Jを、宛先に指定されなかった参加者として特定する。通知部102は、ユーザC,E,G,H,I,Jの各々が受け取る通知の通知IDを発行し、通知データを生成する。通知データは、自分宛以外の通知であることを種類が示すこと以外は、ユーザB,D,Fの通知データと同様である。通知部102は、ユーザC,E,G,H,I,JのユーザIDと、自分宛以外の通知であることを示す通知データと、を関連付けてユーザデータベースDB1に格納する。
【0063】
本実施形態では、通知部102は、全員指定が受け付けられた場合に、全員に通知を行う。先述したように、コメントを入力した者が予定の参加者本人であれば、本実施形態の全員とは、コメントを入力した者以外の全員を意味する。ただし、コメントを入力した本人にも通知を行う場合には、本実施形態の全員は、コメントを入力した本人も含む。参加者以外の者がコメントを入力した場合には、参加者の人数と、通知を行う「全員」が意味する人数と、は一致する。通知部102は、全員のユーザIDと、コメントが入力されたことを示す通知の通知データと、を関連付けてユーザデータベースDB1に格納することによって、全員に通知を行う。
【0064】
例えば、通知部102は、全員指定が受け付けられた場合に、全員に自分宛通知を行う。通知部102は、全員のユーザIDと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースDB1に格納する。通知部102は、コメントとともに受信した宛先を参照することによって、全員指定が受け付けられたか否かを判定する。コメントの本文中に「@」と「参加者」を入力して宛先を指定する場合には、通知部102は、コメントに「@参加者」が含まれるか否かを判定する。通知部102は、コメントに「@参加者」が含まれると判定した場合に、全員指定により全員が宛先に指定されたことを特定する。通知部102は、コメントを入力した者が参加者である場合には、この者を宛先から除外する。
【0065】
図5の例であれば、全員指定によってユーザB~Jが宛先に指定されるので、通知部102は、ユーザB~Jの各々のユーザIDと、通知データと、を関連付けてユーザデータベースDB1に格納する。通知部102は、ユーザB~Jの各々が受け取る通知の通知IDを発行し、通知データを生成する。通知部102は、当該発行された通知ID、自分宛通知を示す種類、未読であることを示す未読/既読フラグ、コメントが入力された予定のタイトル、コメントの内容、コメントを入力した入力者、及び現在の日時を通知データに含める。通知部102は、ユーザB~Jの各々のユーザIDと、自分宛通知であることを示す通知データと、を関連付けてユーザデータベースDB1に格納する。
【0066】
なお、通知部102が実行する処理は、上記の例に限られない。例えば、自分宛通知と、自分宛以外の通知と、を区別せずに1種類だけの通知が存在する場合には、通知部102は、通知の種類を含まない通知データを生成すればよい。この場合、個別指定が行われた場合には、個別指定で宛先に指定されなかった参加者には、通知が行われない。通知部102は、ユーザのメールアドレスに電子メールを送信したり、ユーザの電話番号宛てにメッセージを送信したりすることによって、通知を行ってもよい。
【0067】
また、宛先の特定方法も、上記の例に限られない。例えば、「@」以外の他の記号を利用して個別指定又は全員指定が行われる場合には、通知部102は、他の記号が入力されたか否かを判定することによって、個別指定又は全員指定で指定された宛先を特定してもよい。例えば、ラジオボタン又はチェックボックスによって個別指定又は全員指定が行われる場合には、通知部102は、ラジオボタン又はチェックボックスの選択状況に基づいて、個別指定又は全員指定が行われたか否かを判定して宛先を特定してもよい。
【0068】
[3-2.ユーザ端末で実現される機能]
例えば、ユーザ端末20は、データ記憶部200、表示制御部201、及び操作受付部202を含む。データ記憶部200は、記憶部22により実現される。表示制御部201及び操作受付部202の各々は、制御部21により実現される。
【0069】
[データ記憶部]
データ記憶部200は、予定を管理するために必要なデータを記憶する。例えば、データ記憶部200は、予定管理システム1に関する各種画面を表示するためのブラウザを記憶する。例えば、データ記憶部200は、グループウェア専用のアプリケーションを記憶する。
【0070】
[表示制御部]
表示制御部201は、予定管理システム1における各種画面を、表示部25に表示させる。例えば、表示制御部201は、サーバ10から受信した表示データに基づいて、予定画面SC2、カレンダー画面SC1、予定画面SC2、又は通知画面SC3を、表示部25に表示させる。
【0071】
[操作受付部]
操作受付部202は、予定管理システム1における各種操作を受け付ける。例えば、カレンダー画面SC1、予定画面SC2、又は通知画面SC3の各々に対する操作を受け付ける。操作受付部202が受け付けた操作内容は、サーバ10に適宜送信される。例えば、操作受付部202は、予定画面SC2から、コメントの入力、個別指定、及び全員指定を受け付ける。これらの操作は、入力フォームF20に入力されたコメント(
図4,5の例であれば、入力フォームF20の下部に入力されたコメントの本文と、入力フォームF20の上部に入力された宛先部分の情報と、を含むコメント全体)に反映される。操作受付部202は、当該コメントをサーバ10に送信することによって、予定画面SC2で受け付けた操作がサーバ10に伝達される。
【0072】
[4.予定管理システムで実行される処理]
図11は、予定管理システム1で実行される処理の一例を示す図である。
図11では、予定管理システム1で実行される処理のうち、主に、予定画面SC2でコメントが入力されて通知が行われる処理を説明する。制御部11,21が、それぞれ記憶部12,22に記憶されたプログラムを実行することによって、
図11の処理が実行される。
【0073】
図11に示すように、サーバ10及びユーザ端末20の間で、ユーザがグループウェアにログインするためのログイン処理が実行される(S1)。S1では、ユーザ端末20は、サーバ10に対し、ユーザが入力したユーザID及びパスワードを送信する。サーバ10は、ユーザデータベースDB1を参照し、ユーザID及びパスワードの正当性を確認する。ログイン処理が成功すると、ユーザはグループウェアを利用できる。以降、予定の詳細が確認される場合の処理を説明する。
【0074】
例えば、カレンダー画面SC1から予定が選択されると、サーバ10及びユーザ端末20の間で、予定画面SC2を表示するための処理が実行される(S2)。S2では、ユーザ端末20は、サーバ10に対し、ユーザが選択した予定の予定IDを送信する。予定IDは、カレンダー画面SC1の表示データに含まれているものとする。サーバ10は、予定IDを受信すると、予定データベースDB2を参照し、当該予定IDに関連付けられたデータを取得する。サーバ10は、当該データに基づいて、予定画面SC2の表示データを生成してユーザ端末20に送信する。ユーザ端末20は、当該表示データを受信すると、予定画面SC2を表示部25に表示させる。
【0075】
ユーザ端末20は、操作部24の検出信号に基づいて、予定画面SC2に対するユーザの操作を特定する(S3)。S3では、入力フォームF20に対するコメントの入力と、ボタンB21~B23の選択と、が行われるものとする。予定を変更又は削除する等の他の操作が行われた場合には、他の操作に応じた処理が実行されて本処理は終了する。なお、予定画面SC2の表示データには、ボタンB22が選択された場合に入力フォームF20上で宛先の入力を受け付けるスクリプト、その後の入力によってアイコンI24を表示するスクリプト、及びボタンB23が選択された場合にアイコンI25を表示するスクリプトが含まれるものとする。後述のS4とS6の処理は、これらのスクリプトにより実行されるものとする。スクリプトではなく、その都度サーバ10に要求が実行されて、一連の処理がサーバ10側で実行されてもよい。
【0076】
S3において、ボタンB22が選択された場合(S3:B22)、ユーザ端末20は、入力フォームF20の上部で「@」の入力を受け付けて(S4)、宛先となるユーザの名前の入力を受け付ける(S5)。S3でボタンB22を選択する操作と、S5で「@」の後に名前を入力する操作と、の組み合わせが個別指定に相当する。S5で個別指定が完了すると、アイコンI24が入力フォームF20に表示される。S3において、ボタンB23が選択された場合(S3:B23)、ユーザ端末20は、「参加者」のアイコンI25を入力フォームF20に表示させる(S6)。S3でボタンB23を選択する操作が全員指定に相当する。
【0077】
S3において、入力フォームF20に対するコメントの入力が行われた場合(S3:F20)、ユーザ端末20は、ユーザが入力したコメントを入力フォームF20に表示させる(S7)。S7では、ユーザ端末20は、ユーザが入力した任意の文字列を、入力フォームF20に表示させる。S7において、コメントの本文中に、「@」の後にユーザの名前を入力することが、個別指定に相当してもよい。S7において、コメントの本文中に、「@」の後に「参加者」と入力することが、全員指定に相当してもよい。
【0078】
S3において、ボタンB21が選択された場合(S3:B21)、ユーザ端末20は、サーバ10に対し、入力フォームF20に対する入力内容を送信する(S8)。サーバ10は、ユーザ端末20から入力内容を受信すると、通知の宛先を特定する(S9)。S9では、サーバ10は、ユーザデータベースDB1を参照し、個別指定で指定された名前がユーザデータベースDB1に存在すれば、この名前のユーザを宛先として特定する。サーバ10は、全員指定が行われていれば、予定データベースDB2を参照し、参加者の全員を宛先として特定する。
【0079】
サーバ10は、S9で特定した宛先に基づいて、通知を行い(S10)、本処理は終了する。S10では、サーバ10は、宛先として指定されたユーザのユーザIDと、自分宛通知の通知データと、を関連付けてユーザデータベースDB1に格納する。サーバ10は、宛先として指定されなかった参加者のユーザIDと、自分宛以外の通知の通知データと、を関連付けてユーザデータベースDB1に格納する。通知画面SC3が表示される場合には、これらの通知データが参照される。
【0080】
本実施形態の予定管理システム1は、予定画面SC2で個別指定が受け付けられた場合に、個別指定で指定された者に通知を行う。予定管理システム1は、予定画面SC2で全員指定が受け付けられた場合に、参加者の全員に通知を行う。これにより、複数の参加者を宛先にした場合には全員指定をすれば済み、参加者の数だけ宛先を指定する必要がなくなるので、宛先を指定する手間を軽減できる。例えば、
図5の例であれば、ユーザB~Jの9人分の個別指定をすることも可能であるが、全員指定であれば1回の操作で済むので、手間を軽減できる。サーバ10からしても、9人分の個別指定をする場合には、宛先を特定する処理を9回実行する必要があるが、全員指定であれば1回の処理で済むので、サーバ10の処理負荷を軽減できる。また、個別指定の場合には、ユーザB~Jの9人分を入力する必要があるが、全員指定であれば、1回の操作で済むので、コメントを短くすることができる。その結果、コメントの視認性が高まり、かつ、コメントのデータサイズを抑える(メモリ消費量を抑える)ことができる。
【0081】
また、予定管理システム1は、個別指定が受け付けられた場合に、個別指定で指定された者に、自分が宛先に指定されたことを示す自分宛通知を行い、かつ、個別指定で指定されなかった参加者に、自分宛以外の通知を行う。予定管理システム1は、全員指定が受け付けられた場合に、全員に自分宛通知を行う。これにより、宛先として指定された者が、コメントが入力されたことに気付きやすくなる。また、宛先として指定されなかった参加者にも、自分宛以外の通知が届くので、コメントが入力されたことに気付かせることができる。特にコメントに気付かせたい者に対して自分宛通知を送り、コメントに気付かせたいが優先度は相対的に低い者に対して自分宛以外の通知を送ることによって、通知に強弱を持たせることができる。
【0082】
また、個別指定は、個人名又はグループ名が入力されることによって行われる。全員指定は、全員分の個人名又はグループ名を入力する操作とは異なる操作によって行われる。これにより、シンプルかつ直感的に分かりやすい方法によって、個別指定と全員指定を行うことができる。
【0083】
[5.変形例]
なお、本開示は、以上説明した実施形態に限定されるものではない。本開示の趣旨を逸脱しない範囲で、適宜変更可能である。
【0084】
図12は、変形例における機能の一例を示す図である。例えば、ユーザ端末20は、自動入力部203を含む。自動入力部203は、制御部21により実現される。サーバ10は、出欠確認部103、重複制御部104、及び決定部105を含む。出欠確認部103、重複制御部104、及び決定部105の各々は、制御部11により実現される。
【0085】
[5-1.変形例1]
例えば、実施形態では、個別指定で指定された参加者が受け取る自分宛通知と、全員指定で指定された参加者が受け取る自分宛通知と、が同じ種類である場合を説明したが、これらの通知を、別々の種類の通知として区別してもよい。変形例1では、個別指定により自分が宛先に指定されたことを示す第1自分宛通知、全員指定により自分が宛先に指定されたことを示す第2自分宛通知、及び自分宛以外の通知の3種類の通知が存在する。通知データに含まれる種類によって、これらの通知が区別される。
【0086】
変形例1の通知部102は、個別指定が受け付けられた場合に、個別指定で指定された者に第1自分宛通知を行い、かつ、個別指定で指定されなかった参加者に、自分宛以外の通知を行う。通知部102は、個別指定で指定された者のユーザIDと、第1自分宛通知であることを示す通知データと、を関連付けてユーザデータベースDB1に格納する。この通知データは、通知の種類が第1自分宛通知であることを示す点で、実施形態で説明した自分宛通知の通知データとは異なるが、他の点については同様である。個別指定で指定されなかった参加者に対する自分宛以外の通知については、実施形態で説明した通りである。
【0087】
変形例1の通知部102は、全員指定が受け付けられた場合に、全員に第2自分宛通知を行う。通知部102は、全員のユーザIDと、第2自分宛通知であることを示す通知データと、を関連付けてユーザデータベースDB1に格納する。この通知データは、通知の種類が第2自分宛通知であることを示す点で、実施形態で説明した自分宛通知の通知データとは異なるが、他の点については同様である。
【0088】
変形例1の通知画面SC3では、第1自分宛通知と、第2自分宛通知と、が区別されて表示される。例えば、通知画面SC3は、第1自分宛通知だけが表示される状態と、第1自分宛通知と第2自分宛通知の両方が表示され、かつ、自分宛通知以外の通知が表示されない状態と、第1自分宛通知、第2自分宛通知、及び自分宛通知以外の通知を含む全ての通知が表示される状態と、の各々が切り替えられるようにしてもよい。これらの切り替えは、通知データに含まれる種類に応じて実行されるようにすればよい。
【0089】
変形例1の予定管理システム1は、個別指定が受け付けられた場合に、個別指定で指定された者に、第1自分宛通知を行う。予定管理システム1は、全員指定が受け付けられた場合に、全員に第2自分宛通知を行う。これにより、第1自分宛通知と第2自分宛通知を使い分けることができるので、利便性が高まる。例えば、個別指定の場合には、個人名又はグループ名が直々に指定されているので、個人又はグループにとって、全員指定が行われるよりも重要度が高い可能性がある。この場合に、第1自分宛通知を第2自分宛通知と区別することによって、より重要度が高い通知に気付きやすくなる。
【0090】
[5-2.変形例2]
例えば、全員指定が行われる場合に、一部の参加者だけを宛先から除外したいことがある。
図4の例であれば、ユーザHが普段から受け取る通知があまりにも多い場合には、ユーザHが受け取る通知を減らすために、ユーザHだけを宛先から除外したいことがある。この場合に、ユーザB~G,Jの8人分を個別指定すると手間がかかるので、全員指定により入力された「参加者」の後に、「-」の記号と、宛先から除外したい「ユーザH」と、を含む「-ユーザH」といった文字列を入力することによって、ユーザHが宛先から除外されるようにしてもよい。
【0091】
変形例2の予定画面SC2では、宛先から除外する除外指定を更に受付可能である。例えば、除外指定は、「-」と、宛先から除外する参加者と、の組み合わせが入力されることによって行われてもよい。「-」は、宛先から除外することを意味する所定の記号の一例である。このため、「-」と記載した箇所は、宛先から除外することを意味する所定の記号と読み替えることができる。この記号は、任意の記号であってよく、「-」に限られない。例えば、「×」又は「/」といった他の記号が利用されてもよい。特にこのような記号が利用されることなく、宛先から除外したい参加者の名前が入力されることによって、除外指定が行われてもよい。除外指定は、個人ではなく、グループが指定されてもよい。
【0092】
除外指定を受付可能な予定画面SC2とは、除外指定をするための除外指定画像を含む画面である。変形例2では、入力フォームF20が除外指定画像に相当する場合を説明するが、除外指定画像は、宛先から除外するユーザを何らかの形で指定可能な画像であればよく、他の画像であってもよい。例えば、参加者のリストが除外指定画像に相当してもよい。例えば、除外する参加者を選択するためのラジオボタン又はチェックボックスが除外指定画像に相当してもよい。
【0093】
変形例2の通知部102は、全員指定又は個別指定が受け付けられ、かつ、除外指定が受け付けられた場合に、除外指定により指定された宛先を除外して通知を行う。全員指定と除外指定が受け付けられた場合には、通知部102は、参加者の全員の中から、除外指定により指定された宛先を除外する。個別指定と除外指定が受け付けられた場合には、通知部102は、個別指定で指定された宛先の中から、除外指定により指定された宛先を除外する。例えば、通知部102は、除外指定により指定された参加者には自分宛通知を行わず、他の参加者に自分宛通知を行う。除外された参加者に自分宛通知が行われないという点で、実施形態とは異なるが、他の点については実施形態と同様である。変形例2では、除外指定により指定された参加者には、自分宛以外の通知が行われるものとするが、何の通知も行われないようにしてもよい。
【0094】
例えば、通知部102は、アイコンI25の「参加者」の後に、「-」の記号と、参加者の名前と、の組み合わせが含まれるか否かを判定する。通知部102は、この組み合わせが含まれる場合には、「-」の記号の後に名前が入力された参加者を宛先から除外する。アイコンI25の「参加者」の後に「-ユーザH-ユーザJ」といったように、複数の参加者が指定された場合には、通知部102は、複数の参加者を宛先から除外する。宛先から除外するとは、宛先に指定されなかったとみなすことである。除外指定でグループを指定する場合には、アイコンI25の「参加者」の後に「-営業部」といったように、宛先から除外したいグループが指定される。個別指定でグループが指定された場合に、グループの中から除外したい宛先が指定されてもよい。例えば、「営業部」が参加者である場合に「営業部-ユーザA」といったように、宛先から除外したい個人名が指定されてもよい。
【0095】
なお、除外する参加者の特定方法は、宛先の特定方法と同様に、他の方法であってもよい。例えば、「-」以外の他の記号を利用して除外指定が行われる場合には、通知部102は、当該他の記号に基づいて、除外指定が行われたか否かを判定すればよい。例えば、ラジオボタン又はチェックボックスが利用される場合には、通知部102は、ラジオボタン又はチェックボックスの選択状況によって、除外したいが行われたか否かを判定すればよい。
【0096】
変形例2の予定管理システム1は、全員指定が受け付けられ、かつ、除外指定が受け付けられた場合に、除外指定により指定された参加者を宛先から除外し、全員のうちの他の参加者に通知を行う。これにより、宛先から除外したい参加者がいる場合にも、手間を軽減できる。例えば、
図5の例では、全員指定をすると9人の参加者が宛先に指定される。このうち、1人だけを宛先から除外したい場合に、除外指定を受け付けることができなかったとすると、残りの8人分を個別指定する必要がある。この点、変形例2では、除外指定により、全員指定及び除外指定といった2つの操作で済むので、手間を軽減できる。
【0097】
[5-3.変形例3]
例えば、実施形態では、予定画面SC2のボタンB23が選択されることによって、全員指定が行われる場合を説明したが、ボタンB23が選択された場合に、入力フォームF20に「参加者」と入力されるのではなく、個人名又はグループ名と、の組み合わせが全員分表示されてもよい。ボタンB23は、所定の画像の一例である。このため、ボタンB23について説明している箇所は、所定の画像と読み替えることができる。所定の画像は、任意の画像であってよく、ボタンB23に限られない。例えば、所定の画像は、ラジオボタン又はチェックボックスであってもよい。所定の画像は、実施形態で説明した全員指定画像であってよい。
【0098】
変形例3の予定管理システム1は、自動入力部203を含む。自動入力部203は、全員指定が行われた場合に、全員分の名前を自動入力する。
図5の例であれば、自動入力部203は、ボタンB23が選択された場合に、入力フォームF20に「参加者」と入力するのではなく、「ユーザB」、「ユーザC」、「ユーザD」、「ユーザE」、「ユーザF」、「ユーザG」、「ユーザH」、「ユーザI」、及び「ユーザJ」といった9人分の名前を一度に自動入力する。即ち、アイコンI25の代わりに、9人分のアイコンI24が一度に表示される。全員指定がボタンB23の選択以外の操作である場合にも、これら9人分のアイコンI24が一度に表示されるようにすればよい。
【0099】
例えば、自動入力部203は、予定データベースDB2を参照し、自動入力すべき参加者を特定する。自動入力部203は、コメントを入力する者が参加者であれば、この者を除外した残り全員分の「@」と名前の組み合わせを入力フォームF20に自動入力し、全員分のアイコンI24を表示させる。自動入力部203は、コメントを入力する者が参加者以外の他の者であれば、参加者の全員分の「@」と名前の組み合わせを、入力フォームF20に自動入力する。通知部102は、全員が個別指定された場合と同様の処理を実行することによって、全員の通知を行うことになる。
【0100】
変形例3の予定管理システム1は、ボタンB23が選択された場合に、全員分の名前を自動入力する。これにより、宛先を指定する手間を軽減できる。例えば、実施形態のように「参加者」のアイコンI25を1つだけ表示させる場合には、一部の参加者を宛先から除外する場合には、変形例2のように除外指定をする必要があるが、変形例3によれば、除外したい参加者のアイコンI24を削除すれば済むので、一部の参加者を宛先から除外する場合の手間を軽減できる。
【0101】
[5-4.変形例4]
例えば、実施形態の例では、予定には、参加者として、個人又はグループを登録可能である。この場合、通知部102は、全員指定が受け付けられた場合に、グループには通知を行わずに、個人に通知を行ってもよい。例えば、予定の参加者として、「営業部」といったグループが登録されていたとする。この場合、通知部102は、全員指定が受け付けられた場合に、「営業部」の全員を宛先としては通知を行わずに、あくまで個人として参加する参加者にだけ通知を行ってもよい。
【0102】
参加者が個人であるかグループであるかを示す情報は、データ記憶部100に予め記録されているものとする。例えば、ユーザデータベースDB1に、ユーザの1つとしてグループも登録されている。この場合、ユーザデータベースDB1には、個人であるかグループであるかを示す属性が格納されてもよい。通知部102は、この属性に基づいて、参加者が個人であるかグループであるかを特定する。通知部102は、全員指定が受け付けられた場合に、参加者の全員の中にグループが含まれている場合には、グループを宛先に設定せずに、個人の参加者だけを宛先に設定する。グループに所属する者には、そもそも通知が行われないようにしてもよいし、自分宛以外の通知が行われてもよい。
【0103】
変形例4の予定管理システム1は、全員指定が受け付けられた場合に、グループには通知を行わずに、個人に通知を行う。グループ全員に通知が行われると、予定に関連性の薄い多くの者に通知が行われる可能性があるが、グループには通知を行わないことによって、予定に関連性の薄い者に通知が行われることを防止できる。また、関連性の薄い者への通知が多数行われることを防止できるので、サーバ10の処理負荷を軽減できる。
【0104】
[5-5.変形例5]
例えば、予定管理システム1は、予定の参加者に対し、出欠確認を行う機能を有してもよい。変形例5の予定管理システム1は、出欠確認部103を含む。出欠確認部103は、複数の参加者の各々に、予定への出欠確認を行う。出欠確認自体は、種々の方法によって行われてよい。例えば、出欠確認部103は、出欠するか否かを回答するための画面を、グループウェア上の画面として、参加者のユーザ端末20に表示させ、当該画像に対する選択結果に基づいて、出欠確認を行う。
【0105】
例えば、出欠確認部103は、電子メール等の他の手段を利用して、参加者に対し、出欠確認を行ってもよい。出欠確認部103は、グループウェア上の画面又は電子メール等における参加者の操作に基づいて、出欠確認の結果を取得する。変形例5では、出席、欠席、又は保留といった3種類の回答が可能な場合を説明するが、回答の種類は、出席又は欠席のみであってもよいし、他の回答が可能であってもよい。出欠確認部103は、出欠確認部103は、参加者のユーザ端末20から受信した出欠確認の結果を、予定データベースDB2に格納する。
【0106】
変形例5の通知部102は、出欠確認に対する回答に関係なく、全員に通知を行うものとする。即ち、通知部102は、出席の回答をした参加者だけではなく、欠席の回答をした参加者と、回答をしていない又は保留にした参加者と、についても通知を行う。通知部102は、未回答の参加者についても通知を行う。通知部102は、予定に登録された参加者であれば、通知を行うことになる。
【0107】
変形例5の予定管理システム1は、出欠確認に対する回答に関係なく、全員に通知を行う。これにより、参加者が欠席の回答をしたとしてもコメントに気付きやすくなる。例えば、参加者が欠席の回答をしたとしても、通知によって重要な議題があることに気付き、予定に出席するといった判断材料を与えることができる。
【0108】
[5-6.変形例6]
例えば、予定には、複数の参加者以外の他の者も登録可能であってもよい。他の者は、予定には参加しないが予定に何らかの関係のある者である。例えば、予定に関する情報を共有する共有先は、他の者に相当する。共有先に指定された者は、予定の日時等の情報を閲覧できる。例えば、参加者の上司又はアシスタントが共有先に指定される。予定の登録時又は変更時に、任意のユーザが他の者として指定される。他の者の名前は、予定データベースDB2に格納される。
【0109】
変形例6の通知部102は、全員指定が受け付けられた場合に、他の者には通知を行わずに、参加者の全員に通知を行うものとする。共有先等として指定された他の者が通知を受け取らない点で実施形態とは異なるが、参加者の全員に通知を行う処理自体は、実施形態で説明した通りである。なお、他の者は、参加者以外の者であればよく、共有先に限られない。例えば、出欠確認をする場合に、欠席の回答をした者は、参加者以外の他の者とみなしてもよい。この場合、当初は出席者として登録されたが、欠席の回答をした者には通知が行われないことになる。回答を保留した者、又は、出欠確認に対して未回答の者が、他の者に相当してもよい。
【0110】
変形例6の予定管理システム1は、全員指定が受け付けられた場合に、予定に登録された他の者には通知を行わずに、参加者の全員に通知を行う。これにより、予定に何らか関係するが、コメントに気付かなくても問題ない他の者に通知が行われることを防止できる。また、予定への関連性が相対的に薄い者への通知が行われることを防止できるので、サーバ10の処理負荷を軽減できる。
【0111】
[5-7.変形例7]
例えば、
図4,5の例において、ユーザAが、個別指定でユーザB,D,Fを宛先に指定したあとに、やはり全員指定しようと思って全員指定をすることがある。ユーザAがそのままコメントの入力を完了すると、ユーザB,D,Fは、個別指定及び全員指定の両方で宛先が指定されたことになる。この場合、ユーザB,D,Fが同じ通知を2つ受け取らないように制御してもよい。
【0112】
変形例7の予定管理システム1は、重複制御部104を含む。重複制御部104は、複数の参加者のうちの何れかが個別指定で指定され、かつ、全員指定が受け付けられた場合に、当該参加者のユーザ端末20に通知が重複して表示されないように制御する。ユーザ端末20は、参加者の端末の一例である。参加者の端末は、ユーザ端末20以外の任意の名前であってよい。
【0113】
例えば、重複制御部104は、ある参加者が個別指定及び全員指定の両方で宛先に指定された場合に、1つの通知データだけをユーザデータベースDB1に登録する。この場合の通知データの生成方法は、実施形態で説明した通りである。重複制御部104は、個別指定によって通知データを生成する処理、又は、全員指定によって通知データを生成する処理の何れか一方だけを実行するように、通知部102を制御すればよい。
【0114】
例えば、通知部102は、個別指定によって生成された通知データと、全員指定によって生成された通知データと、の両方をユーザデータベースDB1に登録してもよい。この場合、重複制御部104は、通知画面SC3をユーザ端末20に表示させる場合に、これらの通知データに基づいて同じ通知を2つ表示させるのではなく、1つの通知にまとめて表示させるようにしてもよい。同じ通知であるか否かは、通知IDによって判定されてもよいし、通知に対応するコメントの内容が同じであれば同じ通知であると判定されるようにしてもよい。
【0115】
変形例7の予定管理システム1は、複数の参加者のうちの何れかが個別指定で指定され、かつ、全員指定が受け付けられた場合に、当該参加者のユーザ端末20に通知が重複して表示されないように制御する。これにより、参加者が同じ通知を複数受け取って困惑するといったことを防止できる。通知画面SC3の煩雑さを減らすことができる。
【0116】
[5-8.変形例8]
例えば、全員指定の方法として、主に、実施形態で説明した第1の方法と、変形例3で説明した第2の方法と、の2つを例に挙げた。参加者の人数が多いと、第2の方法では多数の名前が表示されるので、第1の方法の利便性が高いと考えられる。一方、参加者の人数が少ないと、第1の方法では一部の参加者を宛先から除外しにくいので、第2の方法の利便性が高いと考えられる。このため、予定の人数に応じて、第1の方法と第2の方法の何れで全員指定を行うかが変わるようにしてもよい。
【0117】
予定管理システム1では、全員指定であることを意味する所定の文字又は文字列が入力されることによって全員指定が行われる第1の方法と、予定画面SC2に表示された所定の画像が選択された場合に、全員分の名前が自動入力されることによって全員指定が行われる第2の方法と、が可能である。第1の方法と第2の方法は、それぞれ実施形態と変形例3で説明した通りである。
【0118】
予定管理システム1は、決定部105を含む。決定部105は、複数の参加者の人数に基づいて、予定画面SC2において第1の方法又は第2の方法の何れを受け付けるかを決定する。例えば、決定部105は、人数が閾値以上である場合に、第1の方法を受け付けると決定する。決定部105は、人数が閾値未満である場合に、第2の方法を受け付けると決定する。閾値は、任意の数値であってよく、例えば、5~10人程度であってもよいし、それ以上又はそれ以下であってもよい。ユーザが自身で閾値を設定できるようにしてもよい。閾値は、グループウェアのユーザ数等に応じて動的に設定されてもよい。
【0119】
例えば、予定画面SC2の表示データは、決定部105の決定結果に応じて生成される。例えば、サーバ10は、決定部105により第1の方法が決定された場合には、ボタンB23が選択された場合に「参加者」を自動入力してアイコンI25を表示させるスクリプトを含む表示データを生成する。サーバ10は、決定部105により第2の方法が決定された場合には、ボタンB23が選択された場合に全員分の名前を自動入力して全員分のアイコンI24を表示させるスクリプトを含む表示データを生成する。ボタンB23が選択された場合には、スクリプトに応じた処理が実行され、「参加者」又は名前が自動入力されてアイコンI24又はアイコンI25が表示される。
【0120】
変形例8の予定管理システム1は、複数の参加者の人数に基づいて、予定画面SC2において第1の方法又は第2の方法の何れを受け付けるかを決定する。これにより、人数に応じた使い勝手の良い全員指定をすることができるので、ユーザの利便性が高まる。
【0121】
[5-9.その他の変形例]
例えば、変形例1~8を組み合わせてもよい。
【0122】
例えば、通知が1種類だけの場合には、個別指定で宛先に指定されなかった参加者には、通知が行われないようにしてもよい。例えば、予定管理システム1は、グループウェアではない他のサービスの予定を管理してもよい。他のサービスとしては、業務を支援する目的以外の目的で予定を管理するサービス(例えば、学校生活を支援するサービス)であってもよいし、公共施設又は娯楽施設といった施設の予約を受け付けるサービスであってもよい。
【0123】
例えば、上記説明した各機能は、予定管理システム1における任意の装置で実現されるようにすればよい。例えば、サーバ10で実現されるものとして説明した機能がユーザ端末20によって実現されてもよい。この場合、表示制御部101及び通知部102と同様の機能が、ブラウザのスクリプトによって実行されたり、ユーザ端末20にインストールされたアプリケーションによって実行されたりすることによって実現されるようにすればよい。例えば、各機能は、複数のコンピュータによって分担されてもよいし、1つのコンピュータによって実現されてもよい。
【符号の説明】
【0124】
1 予定管理システム、10 サーバ、11,21 制御部、12,22 記憶部、13,23 通信部、20 ユーザ端末、24 操作部、25 表示部、N ネットワーク、100 データ記憶部、101 表示制御部、102 通知部、103 出欠確認部、104 重複制御部、105 決定部、200 データ記憶部、201 表示制御部、202 操作受付部、203 自動入力部、B21,B22,B23,B30,B31,B32,B33 ボタン、I24,I25 アイコン、DB1 ユーザデータベース、DB2 予定データベース、F20 入力フォーム、SC1 カレンダー画面、SC2 予定画面、SC3 通知画面。
【手続補正書】
【提出日】2024-01-16
【手続補正1】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項1】
複数の参加者が参加する予定を管理する予定管理システムであって、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部と、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部と、
を含み、
前記予定には、前記参加者として、個人又はグループを登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記グループの前記参加者として前記予定に登録された前記グループに所属する者であって、前記個人の前記参加者として前記予定に登録されていない者には前記通知を行わずに、前記個人の前記参加者として前記予定に登録された者に前記通知を行う、
予定管理システム。
【請求項2】
前記通知部は、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に、自分が前記宛先に指定されたことを示す自分宛通知を行い、かつ、前記個別指定で指定されなかった前記参加者に、自分が宛先として指定されなかったことを示す自分宛以外の通知を行い、
前記全員指定が受け付けられた場合に、前記全員に前記自分宛通知を行う、
請求項1に記載の予定管理システム。
【請求項3】
前記通知部は、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に、前記個別指定により自分が前記宛先に指定されたことを示す第1自分宛通知を行い、かつ、前記個別指定で指定されなかった前記参加者に、前記自分宛以外の通知を行い、
前記全員指定が受け付けられた場合に、前記全員に、前記全員指定により自分が前記宛先に指定されたことを示す第2自分宛通知を行う、
請求項2に記載の予定管理システム。
【請求項4】
前記個別指定は、前記宛先の指定を意味する記号の後に個人名又はグループ名の文字列が入力されることによって行われ、
前記全員指定は、前記予定画面に表示された前記全員の指定を示す情報を選択する操作、又は、前記記号の後に前記全員の指定を示す文字列を入力する操作によって行われる、
請求項1~3の何れかに記載の予定管理システム。
【請求項5】
前記予定画面では、前記宛先から除外する除外指定を更に受付可能であり、
前記通知部は、前記全員指定又は前記個別指定が受け付けられ、かつ、前記除外指定が受け付けられた場合に、前記除外指定により指定された前記宛先を除外して前記通知を行う、
請求項4に記載の予定管理システム。
【請求項6】
前記個別指定は、個人名又はグループ名が入力されることによって行われ、
前記予定管理システムは、前記全員指定が行われた場合に、前記全員分の名前を自動入力する自動入力部を更に含む、
請求項1~3の何れかに記載の予定管理システム。
【請求項7】
前記予定には、前記複数の参加者以外の他の者も登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記他の者には前記通知を行わずに、前記全員に前記通知を行う、
請求項1~3の何れかに記載の予定管理システム。
【請求項8】
前記予定管理システムは、前記複数の参加者のうちの何れかが前記個別指定で指定され、かつ、前記全員指定が受け付けられた場合に、当該参加者の端末に前記通知が重複して表示されないように制御する重複制御部を更に含む、
請求項1~3の何れかに記載の予定管理システム。
【請求項9】
複数の参加者が参加する予定を管理する予定管理システムであって、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部と、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部と、
を含み、
前記全員指定であることを意味する所定の文字又は文字列が入力されることによって前記全員指定が行われる第1の方法と、
前記予定画面に表示された所定の画像が選択された場合に、前記全員分の名前が自動入力されることによって前記全員指定が行われる第2の方法と、
が可能であり、
前記予定管理システムは、前記複数の参加者の人数が閾値以上である場合に、前記予定画面において前記第1の方法を受け付けると決定し、前記人数が前記閾値未満である場合に、前記第2の方法を受け付けると決定する決定部を更に含む、
予定管理システム。
【請求項10】
複数の参加者が参加する予定に関する通知方法であって、コンピュータが、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御ステップと、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知ステップと、
を実行し、
前記予定には、前記参加者として、個人又はグループを登録可能であり、
前記通知ステップは、前記全員指定が受け付けられた場合に、前記グループの前記参加者として前記予定に登録された前記グループに所属する者であって、前記個人の前記参加者として前記予定に登録されていない者には前記通知を行わずに、前記個人の前記参加者として前記予定に登録された者に前記通知を行う、
通知方法。
【請求項11】
複数の参加者が参加する予定を管理するコンピュータを、
前記予定に関するコメントの入力と、前記コメントが入力されたことを示す通知の宛先を個別に指定する個別指定と、前記複数の参加者の全員をまとめて前記宛先に指定する全員指定と、を受付可能な予定画面を表示させる表示制御部、
前記個別指定が受け付けられた場合に、前記個別指定で指定された者に前記通知を行い、前記全員指定が受け付けられた場合に、前記全員に前記通知を行う通知部、
として機能させ、
前記予定には、前記参加者として、個人又はグループを登録可能であり、
前記通知部は、前記全員指定が受け付けられた場合に、前記グループの前記参加者として前記予定に登録された前記グループに所属する者であって、前記個人の前記参加者として前記予定に登録されていない者には前記通知を行わずに、前記個人の前記参加者として前記予定に登録された者に前記通知を行う、
プログラム。