JP2009009400A - スケジュール調整装置およびスケジュール調整プログラム - Google Patents

Abstract

【課題】データ量を増大させることなく、会議等のイベントの内容に応じた適切な参加者を自動的に選択することができるスケジュール調整装置およびスケジュール調整プログラムを提供する。
【解決手段】イベント参加者の属性として必須の条件が予め必須参加者条件として定められており、入力された新規イベントの内容に対応する必須参加条件の有無が判断される（Ｓ２１）。対応する必須参加者条件がある場合は（Ｓ２１：ＹＥＳ）、入力された新規イベント参加者の属性データが取得され（Ｓ２３）、必須参加者条件をすべて満たしているか否かが判断される（Ｓ２４）。入力された参加者のみでは必須参加者条件が満たされない場合には（Ｓ２４：ＮＯ）、満たされていない条件を満足する属性を有するユーザが選択され（Ｓ２６）、追加参加者候補とされる（Ｓ２７）。
【選択図】図８

Description

本発明は、スケジュール調整装置およびスケジュール調整プログラムに関し、より具体的には、会議等のイベントの内容に応じて、参加者を自動的に追加することができるスケジュール調整装置およびスケジュール調整プログラムに関する。

従来から、ユーザによって入力された会議等のイベントの日時、参加者等の情報に基づいて、参加者のスケジュールを自動的に調整する装置が知られている。その中で、例えば、特許文献１に記載のスケジュール調整装置では、ユーザは「参加者」を個人として特定するのではなく、役割を特定して入力を行う。そして、特定された役割に適合する者が参加者として自動的に選択される。
特開２００７−１１４７９号公報

しかしながら、特許文献１に記載のスケジュール調整装置では、参加者の役割が様々なイベント毎に記憶されているため、イベントが多数になると、データの量が膨大になるという問題があった。また、役割の入力を誤ると、適切な参加者が選択されない場合があるという問題もあった。

本発明は、上記問題点を解決するためになされたものであり、データ量を増大させることなく、会議等のイベントの内容に応じた適切な参加者を自動的に選択することができるスケジュール調整装置およびスケジュール調整プログラムを提供することを目的とする。

上記目的を達成するために、請求項１に係る発明のスケジュール調整装置は、新規イベントの開催スケジュールを調整するスケジュール調整装置において、新規イベントの内容および前記新規イベントへの参加者である新規イベント参加者を含む、新規イベント情報を取得する新規イベント情報取得手段と、複数のユーザの識別情報と前記ユーザの属性とを対応づけて記憶する属性情報記憶手段から、前記新規イベント参加者の前記属性を取得する参加者属性取得手段と、前記参加者属性取得手段によって取得された前記新規イベント参加者の前記属性である新規イベント参加者属性が、前記新規イベント参加者の属性として必須の条件である新規イベント参加者条件を充足するものであるか否かを判断する条件充足判断手段と、前記条件充足判断手段によって、前記新規イベント参加者属性が前記新規イベント参加者条件をすべて充足していないと判断された場合に、前記新規イベントへの追加参加者として、前記属性情報記憶手段から、前記新規イベント参加者属性が充足していない前記新規イベント参加者条件を充足する属性を有する前記ユーザを選択する追加参加者選択手段とを備えている。

また、請求項２に係る発明のスケジュール調整装置は、請求項１に記載の発明の構成に加えて、イベントの内容と当該イベントへの参加者の属性として必須の条件であるイベント参加者条件とを対応づけて記憶する参加者条件記憶手段から、前記新規イベントの前記内容に対応する前記イベント参加者条件を、前記新規イベント参加者条件として取得する参加者条件取得手段をさらに備え、前記条件充足判断手段は、前記新規イベント参加者属性が、前記参加者条件取得手段によって取得された前記新規イベント参加者条件を充足するものであるか否かを判断することを特徴とする。

また、請求項３に係る発明のスケジュール調整装置は、請求項１または２に記載の発明の構成に加えて、前記新規イベント情報取得手段によって取得される前記新規イベント情報は、前記新規イベント参加者条件を含むことを特徴とする。

また、請求項４に係る発明のスケジュール調整装置は、請求項１〜３のいずれかに記載の発明の構成に加えて、前記属性は、少なくとも前記ユーザの所属、役職、または職種に関する情報のいずれか１つを含むことを特徴とする。

また、請求項５に係る発明のスケジュール調整装置は、請求項１〜４のいずれかに記載の発明の構成に加えて、前記ユーザの前記識別情報と、すでに登録されたイベントである登録イベントの登録日時を含む個人スケジュール情報とを対応づけて記憶する個人スケジュール記憶手段から、前記新規イベント参加者条件を充足する前記ユーザの前記個人スケジュール情報を取得する個人スケジュール取得手段をさらに備え、前記新規イベント情報は、前記新規イベントの開催を希望する日時または期間を含み、前記追加参加者選択手段は、前記個人スケジュール取得手段によって取得された前記個人スケジュール情報に基づいて、前記日時または前記期間に前記登録イベントがない前記ユーザを、前記追加参加者として選択することを特徴とする。

また、請求項６に係る発明のスケジュール調整装置は、請求項５に記載の発明の構成に加えて、前記追加参加者選択手段は、前記個人スケジュール取得手段によって取得された前記個人スケジュール情報に基づいて、前記日時の前後に前記登録イベントがない前記ユーザ、または前記期間内で最も前記登録イベントが少ない前記ユーザを、前記追加参加者として選択することを特徴とする。

また、請求項７に係る発明のスケジュール調整装置は、請求項４〜６のいずれかに記載の発明の構成に加えて、前記追加参加者選択手段は、前記ユーザの前記役職に関する情報が最も下位である前記ユーザを、前記追加参加者として選択することを特徴とする。

また、請求項８に係る発明のスケジュール調整プログラムは、請求項１〜７のいずれかに記載のスケジュール調整装置の各種処理手段としてコンピュータを機能させる。

請求項１に係る発明のスケジュール調整装置は、新規イベントへの参加者の属性が、新規イベントへの参加者の属性として必須の条件である新規イベント参加者条件を満たしていない場合、自動的に条件を充足するユーザを追加参加者として選択する。したがって、新規イベント情報の入力者が、本来新規イベントへの出席が必要なユーザを参加者として入力し忘れた場合でも、適切な参加者も含めたスケジュール調整を行うことができる。また、ユーザの属性は、特に企業等では通常人事データとして管理されている情報であるため、新たな情報を登録する必要がなく、データの記憶量が徒に増大する虞がない。

また、請求項２に係る発明のスケジュール調整装置では、入力された新規イベントの内容に応じて、予め定められ記憶された新規イベント参加者条件が取得される。したがって、請求項１に記載の発明の効果に加え、入力時には新規イベントの内容さえ入力すればよく、細かい条件設定をする手間を省くことができる。

また、請求項３に係る発明のスケジュール調整装置では、新規イベント情報に新規イベント参加者条件が含まれている。すなわち、請求項１または２に記載の発明の効果に加え、新規イベント情報の入力者が、入力の際、新規イベント参加者条件を臨機応変に設定することができる。

また、請求項４に係る発明のスケジュール調整装置では、新規イベント参加者条件として要求される参加者の属性に、少なくとも所属、役職、または職種に関する情報のいずれか１つが含まれている。したがって、請求項１〜３のいずれかに記載の発明の効果に加え、イベントの内容に応じて、適切な所属の担当者、責任者に相当する役職、または専門の職種等を考慮して、新規イベント参加者条件を定めることができる。

また、請求項５に係る発明のスケジュール調整装置では、新規イベント情報に新規イベントの開催希望日時または期間を含んでおり、この日時または期間に他にすでに登録されたイベントがないユーザが追加参加者として選択される。すなわち、請求項１〜４のいずれかに記載の発明の効果に加え、すでに登録イベントがあるユーザのスケジュールが変更されることがないので、追加参加者として選択されたユーザのスケジュールには支障が出ない。

また、請求項６に係る発明のスケジュール調整装置では、新規イベントの開催希望日時前後または期間内にスケジュールの空きが多いユーザが追加参加者として選択される。したがって、請求項５に記載の発明の効果に加え、追加参加者として選択されても負担の少ないユーザを選択することができる。

また、請求項７に係る発明のスケジュール調整装置では、役職に関する情報が最も下位のユーザが追加参加者として選択される。したがって、請求項４〜６のいずれかに記載の発明の効果に加え、一般的に多忙である役職の高いユーザが追加参加者として選択される可能性を低減することができる。

また、請求項８に係る発明のスケジュール調整プログラムは、請求項１〜７のいずれかに記載のスケジュール調整装置の各種処理手段としてコンピュータを機能させることができる。したがって、請求項１〜７のいずれかに記載の発明の効果を奏することができる。

以下、本発明を具体化したスケジュール調整装置の実施の形態について、図面を参照して説明する。なお、これらの図面は、本発明が採用しうる技術的特徴を説明するために用いられるものであり、記載されている装置の構成、各種処理のフローチャートなどは、特に特定的な記載がない限り、それのみに限定する趣旨ではなく、単なる説明例である。

<第１の実施形態>
まず、図１〜図１３を参照して、本発明の第１の実施の形態について説明する。最初に、図１〜図７を参照して、本実施形態に係るスケジュール調整システム１の構成について説明する。図１は、スケジュール調整システム１のシステム構成図である。図２は、スケジュール調整システム１の備えるサーバ１０の電気的構成を示すブロック図である。図３は、パーソナルデータデータベース１０２４に登録されたパーソナルデータの説明図である。図４は、必須属性データベース１０２５に登録された必須属性データの説明図である。図５は、スケジュール調整システム１の備えるユーザ端末２０の電気的構成を示すブロック図である。図６は、ユーザ端末２０のＲＡＭ２０１３の記憶エリアの説明図である。

図１に示すように、スケジュール調整システム１は、サーバ１０と、サーバ１０にネットワークを介して接続されたユーザ端末２１、２２、ほか複数のユーザ端末２０を備えている。スケジュール調整システム１では、ユーザ端末２０のユーザ２００がユーザ端末２０からネットワークを介してサーバ１０にアクセスし、必要なデータを入手して、ユーザ端末２０において後述するスケジュール調整処理を行う。なお、図中のユーザ端末２１、２２・・・他はすべて同じ構成を有するため、これ以降、「ユーザ端末２０」という場合には、複数のユーザ端末２１、２２・・・他のすべてのユーザ端末を総称するか、または不特定のユーザ端末を指し、「ユーザ端末２１」という場合には、ある特定の「ユーザ端末２１」を指すものとする。また、各ユーザ端末２０は、それぞれについてユーザが特定されており、「ユーザ２００」という場合には、不特定のユーザ端末２０のユーザを指し、「ユーザ２１０」、「ユーザ２２０」等という場合には、それぞれ「ユーザ端末２１のユーザ２１０」、「ユーザ端末２２のユーザ２２０」等を指すものとする。

次に、図２のブロック図を参照して、サーバ１０の電気的構成について説明する。サーバ１０は、所謂パーソナルコンピュータであり、汎用型の装置である。図２に示すように、サーバ１０には、サーバ１０の制御を司るＣＰＵ１０１１、ＢＩＯＳ等を記憶したＲＯＭ１０１２および各種データを一時的に記憶する記憶エリアを有するＲＡＭ１０１３を備えた制御部１０１が設けられている。そして、ＲＯＭ１０１２およびＲＡＭ１０１３は、それぞれＣＰＵ１０１１に接続されている。ＣＰＵ１０１１にはさらに、バス１０９を介して、後述する記憶装置１０２、各種データの入力を行うためのキーボード１０３、各種データを表示するディスプレイ１０４、ネットワークを介して行われるユーザ端末２０との通信を制御する通信制御部１０５、ＣＤ−ＲＯＭ等の記憶媒体を駆動する記憶媒体駆動装置１０６、およびデータの受け渡しの仲介を行う入出力インターフェース（Ｉ／Ｆ）１０７とが接続されている。

サーバ１０の記憶装置１０２には、複数の記憶エリアが設けられており、これらの記憶エリアには、個人スケジュールデータベース（以下、個人スケジュールＤＢという）１０２２、会議室スケジュールデータベース（以下、会議室ＤＢという）１０２３、パーソナルデータデータベース（以下、パーソナルＤＢという）１０２４、必須属性データベース（以下、必須属性ＤＢという）１０２５、およびＣＰＵ１０１１により実行される各種プログラム（図示外）等がそれぞれ記憶されている。個人スケジュールＤＢ１０２２には、すべてのユーザ端末２０のユーザ２００毎に、識別コードおよび氏名とともに、そのユーザ２００のスケジュールとして、すでに調整が行われて登録されたイベントの区分、内容、日時、場所、参加者等を含むスケジュール情報が記憶されている。会議室ＤＢ１０２３には、サーバ１０の管理する会議室毎に、会議室の名称、場所、予約の日時、予約の登録者、イベントの区分、イベント参加者等を含む会議室予約情報が記憶されている。

ここで、図３を参照して、パーソナルＤＢ１０２４に登録されたパーソナルデータについて説明する。パーソナルＤＢ１０２４には、すべてのユーザ端末２０のユーザ２００毎に、そのユーザ２００の個人情報がパーソナルデータとして記憶されている。具体的には、ユーザ２００の識別コード、氏名、会社、部署、役職、役職レベル、住所、電話番号、Ｅメールアドレス、職種等が記憶されている。例えば、図３に示すように、ユーザ端末２１のユーザ２１０（ＡＡ）のパーソナルデータとしては、識別コードとしてユーザ２１０の社員コードである「２１０」、氏名としてユーザ２１０の氏名である「ＡＡ」、会社として「Ａ社」、部署として「開発部」が記憶されている。役職としては、ＡＡは役職者ではないため、データは記憶されていない。ところで、役職は、会社や部署によって名称が異なり、例えばある会社の「マネージャー」が他の会社の「主任」に相当したりする。よって、役職レベルには、こういった役職名の相違に関係なく、すべての役職の上下関係を比較できるように、１〜５までの数字が記憶されている。なお、本実施形態では、役職レベルは、小さい数字ほど上位の役職を示している。ＡＡのように役職者でない場合には、図３に示すように、役職レベルとして最下位の「５」が記憶される。また、ユーザ２１０の住所、電話番号、Ｅメールアドレスとして、それぞれ「○○県△△市◇◇町」、「００−００００−００００」、「Ａａａａ＠ａ．ｃｏ．ｊｐ」が記憶されている。さらに、職種として「開発（ハード）」が記憶されている。この職種は、ユーザ２００の現在の業務に対応する内容が登録されるものである。すなわち、ユーザ２１０（ＡＡ）は、現在、Ａ社においてハードウェアの開発に携わっていることを示している。

次に、図４を参照して、必須属性ＤＢ１０２５に記憶された必須属性データについて説明する。必須属性ＤＢ１０２５には、各イベントの「内容」に対応づけて、その内容のイベントへの参加者の少なくとも１名が備えるべき必須の属性が記憶されている。例えば、イベントが会議である場合には、図４に示すように、「定例会」、「戦略会議」、「特許面談」、「予算会議」等の会議の名称が、イベントの内容として記憶されている。そして、各会議毎に、参加者の属性の具体例である「部署」、「役職」、「職種」について、必須の条件が登録されている。

図４の例では、イベントの内容が「定例会」であれば、その定例会には、部署および職種が「入力者と同じ」である任意のユーザ２００の参加が必須であることを示している。なお、役職レベルに関する条件は「何でもよい」であるから、そのユーザ２００は役職者であってもなくてもよいことを示している。同様に、例えばイベントの内容が「予算会議」の場合は、役職レベルは何でもよいが、部署が「財務部」で職種が「経理」の任意のユーザ２００と、職種は何でもよいが、部署が「入力者と同じ」で役職レベルが部長クラスである「１」の任意のユーザ２００の２名の参加が必須である。すなわち、予算を決定するための予算会議には、会社全体の予算を管理する財務部で経理を担当する人物と、その部署の予算について決裁権限を有する部長クラスの人物の参加が必須であることを示している。このように、本実施形態では、各イベント（会議）の内容に応じて、そのイベントに参加が必須とされる必須参加者の属性に関する条件（以下、必須参加者条件という）が定められている。この必須参加者条件は、後で詳述するように、入力時に指定された参加者のみでイベントを開催してよいか否か、すなわち、他に参加者を追加すべきか否かの判断に利用される。なお、本実施形態では、説明の簡略化のため、イベントの内容が会議の場合のみを想定して例示しているが、研修、展示会等、会議以外の他のイベントについても、内容に応じて同様に必須の属性との対応関係を登録してもよい。また、必須参加者条件として定められる属性については、「部署」、「役職」、「職種」に限られず、他に「保有資格」、「知識レベル」等を用いてもよいし、「部署」、「役職」、「職種」のうち１つまたは２つのみを用いることもできる。

次に、図５のブロック図を参照して、ユーザ端末２０の電気的構成について説明する。ユーザ端末２０は、所謂パーソナルコンピュータであり、汎用型の装置である。図５に示すように、ユーザ端末２０には、サーバ１０と同様、ユーザ端末２０の制御を司るＣＰＵ２０１１、ＢＩＯＳ等を記憶したＲＯＭ２０１２および各種データを一時的に記憶するＲＡＭ２０１３を備えた制御部２０１が設けられている。そして、ＲＯＭ２０１２およびＲＡＭ２０１３は、それぞれＣＰＵ２０１１に接続されている。なお、ＲＡＭ２０１３の詳細については後述する。ＣＰＵ２０１１にはさらに、バス２０９を介して、後述する記憶装置２０２、各種データの入力を行うためのキーボード２０３、各種データを表示するディスプレイ２０４、ネットワークを介して行われるサーバ１０および他のユーザ端末２０との通信を制御する通信制御部２０５、ＣＤ−ＲＯＭ等の記憶媒体を駆動する記憶媒体駆動装置２０６、およびデータの受け渡しの仲介を行う入出力インターフェース（Ｉ／Ｆ）２０７とが接続されている。記憶装置２０２には、複数の記憶エリアが設けられており、そのうちの１つには、キーボード２０３を用いたユーザ２００からの入力を受けて、スケジュール調整処理を行うスケジュール調整プログラム２０２１が記憶されている。このスケジュール調整プログラムによる処理については、後で詳述する。また、図示しないが、他の記憶エリアには、ＣＰＵ２０１１で実行されるその他のプログラム等が記憶されている。

ここで、図６を参照して、ＲＡＭ２０１３の詳細について説明する。図６に示すように、各種データを一時的に記憶するＲＡＭ２０１３には、新規イベント情報記憶エリア２３１、必須参加者条件記憶エリア２３２、参加者情報記憶エリア２３３、不足条件記憶エリア２３４、追加参加者候補記憶エリア２３５、参加者スケジュール記憶エリア２３６、会議室情報記憶エリア２３７、候補日程記憶エリア２３８、処理対象日程記憶エリア２３９、追加参加者スケジュール記憶エリア２４０、選択候補記憶エリア２４１、およびエラーフラグ記憶エリア２４２を含む複数の記憶エリアが設けられている。

新規イベント情報記憶エリア２３１には、ユーザ２００が、新たにスケジュールの登録を希望する新規イベントに関する情報を入力した場合に、入力された新規イベント情報が記憶される。必須参加者条件記憶エリア２３２には、前述の必須属性ＤＢ１０２５から取得された、新規イベントの内容に対応する必須参加者条件が記憶される。参加者情報記憶エリア２３３には、前述のパーソナルＤＢ１０２４から取得された、新規イベントの参加者のパーソナルデータが記憶される。不足条件記憶エリア２３４には、入力された参加者のみでは満たされていない必須参加者条件である不足条件が記憶される。追加参加者候補記憶エリア２３５には、不足条件を満たすことができるユーザ２００が、追加参加者候補として記憶される。参加者スケジュール記憶エリア２３６には、前述の個人スケジュールＤＢ１０２２から取得された、新規イベントの参加者のスケジュール情報が記憶される。会議室情報記憶エリア２３７には、前述の会議室ＤＢ１０２３から取得された会議室予約情報が記憶される。候補日程記憶エリア２３８には、新規イベントのスケジュール調整の過程で、新規イベントの開催日時および場所の候補として選択された候補日程が記憶される。処理対象日程記憶エリア２３９には、候補日程のすべてについて、登録が可能か否かを判断する処理を順に１つずつ行うために、処理対象として選択される１つの候補日程が記憶される。追加参加者スケジュール記憶エリア２４０には、前述の個人スケジュールＤＢ１０２２から取得された、新規イベントの追加参加者候補のスケジュール情報が記憶される。選択候補記憶エリア２４１には、追加参加者候補のうち、１つの必須参加者条件に対して最終的な候補として選択される１名の選択候補のパーソナルデータが記憶される。エラーフラグ記憶エリア２４２には、エラーの有無を示すエラーフラグが記憶される。

次に、図７〜図１３を参照して、各ユーザ端末２０で行われるスケジュール調整処理について説明する。なお、説明の便宜上、以下では、ユーザ端末２１においてユーザ２１０（ＡＡ）が新規イベント情報の入力を行ったものとして説明するが、他のユーザ端末２２、２３等で処理を行う場合も同様である。図７は、スケジュール調整処理のメイン処理のフローチャートである。図８は、図７のメイン処理の中で行われる参加者確認処理のフローチャートである。図９は、図７のメイン処理の中で行われるスケジュール決定処理のフローチャートである。図１０は、図９のスケジュール決定処理の中で行われる追加参加者決定処理のフローチャートである。図１１は、新規スケジュール入力画面５１の説明図である。図１２は、パーソナルデータの具体例の説明図である。図１３は、パーソナルデータの別の具体例の説明図である。なお、図７〜図１０の各処理は、記憶装置２０２に記憶されたスケジュール調整プログラム２０２１（図５参照）に従って、ＣＰＵ２０１１が実行するものである。

ユーザ端末２１でスケジュール調整プログラム２０２１（図５参照）が起動され、図７に示すメイン処理が開始されると、ＣＰＵ２０１１はまず、新規イベントに関する情報を入力するための新規スケジュール入力画面５１（図１１参照）をユーザ端末２１のディスプレイ２０４に表示させる（Ｓ１１）。

ここで、図１１の新規スケジュール入力画面５１を参照して、このとき入力される新規イベント情報について説明する。なお、新規スケジュール入力画面５１を介して入力される新規イベントの情報を総称して、「新規イベント情報」というものとする。図１１に示すように、新規スケジュール入力画面５１には、区分欄５１１、内容欄５１２、日時欄５１３、所要時間欄５１４、場所欄５１５、および参加者欄５１６が設けられている。まず、区分欄５１１には、「会議」、「外出」、「出張」の３区分に対応するチェックボックスが設けられており、これらのいずれか１つをチェックすることにより、新規イベントの区分の選択を行うことができる。内容欄５１２には、新規イベントの内容が入力される。なお、本実施形態では、「内容」として会議の名称が入力される場合を例として説明する。日時欄５１３は、新規イベントの開催希望日時を指定する欄である。ここには、特定の開始日時を指定するための指定日時欄５１３１と、日時を特定できない場合に、一定の幅をもたせて、「この期間内ならばよい」という期間を特定するための指定期間欄５１３２が設けられている。所要時間欄５１４には、新規イベントの所要時間が入力される。場所欄５１５には、開催希望場所が入力される。参加者欄５１６には、新規イベントへの参加を要請するユーザ２００の氏名が入力される。なお、参加者欄５１６は、複数の氏名を入力できるように、複数の入力欄５１６１〜５１６６にそれぞれ分けられている。図１１の入力例では、区分欄５１１に「会議」が、内容欄５１２に「予算会議」が、指定日時欄５１３１に「２００７年０４月１６日 １０：００」が、所要時間欄５１４に「１時間」が、参加者欄５１６１〜５１６３に「ＡＡ」および「ＣＣ」が、それぞれ入力されている。なお、参加者欄５１６１に入力された「ＡＡ」は入力者の「ユーザ２１０」である。また、場所欄５１５には入力されたデータがなく、会議の開催場所は特に指定されていない状態である。

さらに、新規スケジュール入力画面５１の右下には、「設定」ボタン５１７および「キャンセル」ボタン５１８が設けられている。「設定」ボタン５１７がクリックされると、入力した情報が確定され（Ｓ１２：ＹＥＳ）、ＲＡＭ２０１３の新規イベント情報記憶エリア２３１に記憶される（Ｓ１３）。なお、本実施形態では、所要時間欄５１４および参加者欄５１６は必須入力項目とされている。よって、これらの項目のいずれかに入力がされないまま「設定」ボタン５１７がクリックされると、エラー音が発せられ、次の処理には進めないように構成されている。一方、「キャンセル」ボタン５１８がクリックされた場合には（Ｓ１２：ＮＯ）、入力された新規イベント情報は無効とされ、未入力状態の新規スケジュール入力画面５１に戻る（Ｓ１１）。

新規イベント情報の入力が確定され（図７、Ｓ１２：ＹＥＳ）、新規イベント情報記憶エリア２３１に記憶されると（Ｓ１３）、ＣＰＵ２０１１は、新規イベント情報に「内容」が含まれているか否かを判断する（Ｓ１４）。「内容」が含まれていなければ（Ｓ１４：ＮＯ）、新規イベントの内容に応じた追加参加者の要否判断を行うことができないため、そのまま「追加参加者なし」と決定して（Ｓ１６）、後述するスケジュール決定処理（Ｓ３０）に移る。一方、例えば、図１１に示すように新規イベント情報が入力された場合には、新規イベント情報記憶エリア２３１に記憶された新規イベント情報には、「内容」として「予算会議」が含まれている（Ｓ１４：ＹＥＳ）。このような場合には、ＣＰＵ２０１１は参加者確認処理（Ｓ２０）に移る。

ここで、図８を参照して、参加者確認処理（Ｓ２０）の詳細について説明する。この参加者確認処理は、入力時に指定された参加者のみで、新規イベントの内容に対応する必須参加者条件（図４参照）が満たされているか否かを判断し、満たされてない場合には、追加参加者候補を抽出するための処理である。

図８に示す処理が開始されると、ＣＰＵ２０１１はまず、サーバ１０の記憶装置１０２に記憶された必須属性ＤＢ１０２５にアクセスし、必須属性ＤＢ１０２５に、新規イベント情報の「内容」に対応する必須参加者条件が記憶されているか否かを判断する（Ｓ２１）。例えば、新規イベント情報記憶エリア２３１に新規イベントの「内容」として「予算会議」が記憶されている場合、必須属性ＤＢ１０２５には、図４に示すように「予算会議」に対応する必須参加者条件が記憶されている（Ｓ２１：ＹＥＳ）。したがって、この場合、ＣＰＵ２０１１は、必須属性ＤＢ１０２５から「予算会議」に対応する必須参加者条件を取得し、ＲＡＭ２０１３の必須参加者条件記憶エリア２３２に記憶させる（Ｓ２２）。具体的には、「部署：財務部、役職レベル：何でもよい、職種：経理」および「部署：入力者と同じ、役職レベル：１、職種：何でもよい」の２つの必須参加者条件が、このとき必須参加者条件記憶エリア２３２に取得される。

その後、ＣＰＵ２０１１は、サーバ１０の記憶装置１０２に記憶されたパーソナルＤＢ１０２４にアクセスし、新規イベント情報記憶エリア２３１に記憶された新規イベントの「参加者」のパーソナルデータを、ＲＡＭ２０１３の参加者情報記憶エリア２３３に取得して記憶させる（Ｓ２３）。例えば、図１１に示すように新規イベント情報が入力された場合には、参加者である「ＡＡ」および「ＣＣ」のパーソナルデータが、参加者情報記憶エリア２３３に取得される。なお、ＡＡのパーソナルデータは前述したように図３の通りであり、ＣＣのパーソナルデータは図１３の通りであるものとする。すなわち、ＣＣは、Ａ社の財務部のマネージャー（役職レベル：３）であり、職種は経理である。

次いでＣＰＵ２０１１は、必須参加者条件記憶エリア２３２および参加者情報記憶エリア２３３にそれぞれ取得された必須参加者条件および参加者のパーソナルデータを参照して、入力時に指定された参加者の属性が、必須参加者条件をすべて満たしているか否かを判断する（Ｓ２４）。なお、以下では入力者の属性については考慮しないものとして説明するが、入力者の属性について考慮するようにしてもよい。この例では、ＡＡは入力者（ユーザ２１０）であるため、ＣＣの属性である「部署」、「役職レベル」および「職種」のみが、「部署：財務部、役職レベル：何でもよい、職種：経理」および「部署：入力者と同じ、役職レベル：１、職種：何でもよい」を満たすか否かの判断に用いられる。ここで、ＲＡＭ２０１３に記憶されているＣＣの「部署」、「役職レベル」および「職種」は、図１３に示すように、それぞれ「財務部」、「３」、「経理」である。すなわち、前述した２つの必須参加者条件のうちの１つである「部署：財務部、役職レベル：何でもよい、職種：経理」を満たしている。しかし、ＣＣ以外に考慮される参加者がないため、もう１つの必須参加者条件である「部署：入力者と同じ、役職レベル：１、職種：何でもよい」は満たされていない。したがって、このような場合、ＣＰＵ２０１１は、必須参加者条件がすべて満たされてはいないと判断し（Ｓ２４：ＮＯ）、後述するように、必須参加者条件を満たす他のユーザ２００を追加参加者として選択する処理を行う。一方、入力時の参加者のみで、その新規イベントの内容に対応する必須参加者条件が満たされている場合には（Ｓ２４：ＹＥＳ）参加者を追加する必要はないため、ＣＰＵ２０１１は、「追加参加者なし」と決定し（Ｓ２９）、そのまま図７のメイン処理に戻る。

Ｓ２４において、必須参加者条件がすべて満たされてはいないと判断した場合（Ｓ２４：ＮＯ）、ＣＰＵ２０１１は、不足している（満たされていない）必須参加者条件を特定する（Ｓ２５）。前述の例では、「部署：入力者と同じ、役職レベル：１、職種：何でもよい」が不足している必須参加者条件として特定され、ＲＡＭ２０１３の不足条件記憶エリア２３４に記憶される。次いでＣＰＵ２０１１は、サーバ１０の記憶装置１０２のパーソナルＤＢ１０２４にアクセスし、Ｓ２５で特定された必須参加者条件を満たす任意のユーザ２００を選択し（Ｓ２６）、追加参加者候補に決定して、ＲＡＭ２０１３の追加参加者候補記憶エリア２３５に記憶させる（Ｓ２７）。前述の例では、入力者であるＡＡ（ユーザ２１０）の部署は、図３に示す通り「開発部」であり、この情報がＳ２３で取得され、参加者情報記憶エリア２３３に記憶されている。よって、ＣＰＵ２０１１は、パーソナルＤＢ１０２４に記憶されたパーソナルデータの中から、「部署：開発部、役職レベル：１」を満たすデータを選択し、このパーソナルデータを有するユーザ２００を特定する。なお、この例では、「職種」に関する必須参加者条件は「何でもよい」なので、「職種」については選択条件には含まれない。ここで、例えば、図１２に示すＢＢ（ユーザ２２０）のパーソナルデータによれば、ＢＢの部署は「開発部」、役職レベルは部長クラスを示す「１」であるから、「部署：開発部、役職レベル：１」を満たしている。よって、このような場合には、ＢＢが追加参加者候補として選択され（Ｓ２６）、ＢＢのパーソナルデータが追加参加者候補記憶エリア２３５に記憶される（Ｓ２７）。なお、Ｓ２６において、不足している条件を満たすユーザ２００が複数いる場合には、これらの複数のユーザ２００がすべて追加参加者候補として選択され（Ｓ２６）、そのパーソナルデータが追加参加者候補記憶エリア２３５に記憶される（Ｓ２７）。その後、ＣＰＵ２０１１は、図７のメイン処理に戻る。

図７のＳ１６において「追加参加者なし」と決定されるか、またはＳ２０において参加者確認処理（図８）が行われた後、図７のメイン処理では、続いてスケジュール決定処理が行われる（Ｓ３０）。その後、ＣＰＵ２０１１は、スケジュール決定処理（Ｓ３０）において決定された結果をディスプレイ２０４に表示させ（Ｓ１８）、メイン処理を終了する。ここで、スケジュール決定処理の詳細について、図９および図１０を参照して説明する。この決定処理は、新規イベント情報入力時に指定された参加者、および参加者確認処理（Ｓ２０、図８）で選択された追加参加者候補のスケジュール情報に基づいて、新規イベントの開催日時および場所を決定する処理である。

図９に示すスケジュール決定処理が開始されると、ＣＰＵ２０１１はまず、新規イベント情報記憶エリア２３１に記憶された新規イベント情報を参照し、スケジュール調整の対象とする期間と参加者を特定する。ここでいう「期間」とは、具体的には、新規イベント入力時に、新規スケジュール入力画面５１の指定日時欄５１３１において特定の開始日時が入力されていれば、その開始日時から所要時間欄５１４で入力された所要時間分の時間帯をいう。例えば、図１１の入力例では、開始日時として「２００７年４月１６日 １０：００」が入力され、所要時間として「１時間」が入力されているので、「２００７年４月１６日 １０：００〜１１：００」が特定される。また、開始日時はなく、指定期間欄５１３２で入力された指定期間が新規イベント情報記憶エリア２３１に記憶されている場合には、その指定期間をいう。一方、開始日時も指定期間も記憶されていない場合には、例えば、「処理日から１週間」など、所定の期間を定めればよい。その後、ＣＰＵ２０１１は、サーバ１０の記憶装置１０２に記憶された個人スケジュールＤＢ１０２２にアクセスし、前述のように特定された期間内の全参加者のスケジュール情報をＲＡＭ２０１３の参加者スケジュール記憶エリア２３６に取得し、記憶させる（Ｓ３１）。例えば、図１１の入力例では、「２００７年４月１６日 １０：００〜１１：００」のＡＡおよびＣＣのスケジュール情報が取得される。

ＣＰＵ２０１１はさらに、サーバ１０の記憶装置１０２に記憶された会議室ＤＢ１０２３にアクセスし、前述のように特定された期間内の会議室予約情報をＲＡＭ２０１３の会議室情報記憶エリア２３７に取得し、記憶させる（Ｓ３２）。ここで取得される会議室予約情報は、新規イベント情報入力時に特定の会議室が「場所」として入力され、新規イベント情報記憶エリア２３１に記憶されていれば、その会議室の情報である。一方、１つの会議室が特定されておらず、例えば「本社」のみが記憶されているような場合は、会議室ＤＢ１０２３から、「場所」に「本社」が含まれる会議室の情報が取得される。また、図１１の入力例のように、何ら場所が入力されなかった場合は、新規イベント情報記憶エリア２３１には「場所」は記憶されていないため、全会議室の情報が取得される。

続いて、ＣＰＵ２０１１は、新規イベントの開始日時および所要時間と、Ｓ３１で参加者スケジュール記憶エリア２３６に取得した参加者のスケジュール情報とを参照して、全参加者に新規イベントの所要時間分の共通の空きがあるか否かを判断する。取得したスケジュール情報中、共通の空きがまったくない場合には（Ｓ３３）、入力された条件では、新規イベントは登録不可能である。よって、後で入力者であるＡＡ（ユーザ２１０）にその旨を知らせるために、エラーフラグをＯＮとしてＲＡＭ２０１３のエラーフラグ記憶エリア２４２に記憶させる（Ｓ３９）。そして、続くＳ３７において、ＣＰＵ２０１１はエラーフラグがＯＮであると判断し（Ｓ３７：ＹＥＳ）、そのまま図７のメイン処理に戻ってディスプレイ２０４にエラーメッセージを表示させてから（Ｓ１８）、処理を終了する。

一方、参加者に所要時間分の共通の空きがあれば（Ｓ３３：ＹＥＳ）、Ｓ３２で会議室情報記憶エリア２３７に取得した会議室予約情報を参照して、その時間帯に会議室に空きがあるか否かを判断する（Ｓ３４）。会議室にまったく空きがない場合には（Ｓ３４：ＮＯ）、前述の場合と同様に、エラーフラグをＯＮとしてエラーフラグ記憶エリア２４２に記憶させる（Ｓ３９）。そして、続くＳ３７において、ＣＰＵ２０１１はエラーフラグがＯＮであると判断し（Ｓ３７：ＹＥＳ）、そのまま図７のメイン処理に戻ってディスプレイ２０４にエラーメッセージを表示させてから（Ｓ１８）、処理を終了する。一方、会議室に空きがあると判断した場合には（Ｓ３４：ＹＥＳ）、ＣＰＵ２０１１は、新規イベントを登録可能な日時と場所の組合せである候補日程を選定し、ＲＡＭ２０１３の候補日程記憶エリア２３８に記憶させる（Ｓ３５）。このとき、新規イベントを登録可能な日時と場所の組合せが複数あれば、例えば「４月１６日 １０：００〜１１：００ 会議室１」および「４月１７日 １４：００〜１５：００ 会議室３」のように、複数の候補日程が選定されることになる。候補日程を選定した後（Ｓ３５）、ＣＰＵ２０１１は、追加参加者決定処理（Ｓ７０）に移る。

ここで、図１０を参照して、追加参加者決定処理（図９、Ｓ７０）の詳細について説明する。追加参加者決定処理は、前述の参加者確認処理（図７、Ｓ２０および図８）において選択された追加参加者候補のスケジュール情報も考慮して、追加参加者１名を決定するとともに、新規イベントの開催日程を決定するための処理である。

図１０に示す追加参加者決定処理が開始されると、ＣＰＵ２０１１はまず、前述のように選択され（図９、Ｓ３５）、候補日程記憶エリア２３８に記憶されている候補日程のうち、最も早い日時のものを処理対象日程として選択し、ＲＡＭ２０１３の処理対象日程記憶エリア２３９に記憶させる（Ｓ７１）。なお、候補日程記憶エリア２３８に候補日程が１つしか記憶されていない場合には、その候補日程が選択される。また、最も早い日時の候補日程が複数ある場合には、例えば、場所とされている会議室が会議室ＤＢ１０２３で先に登録されている候補日程を選択すればよい。

次いで、ＣＰＵ２０１１は、追加参加者候補記憶エリア２３５を参照して、追加参加者候補が記憶されているか否かを判断する（Ｓ７２）。ここに追加参加者候補が記憶されていなければ（Ｓ７２：ＮＯ）、これ以上他のユーザ２００のスケジュールを考慮する必要はないため、そのまま図９のスケジュール決定処理に戻る。この場合、エラーフラグはＯＮとして記憶されていないため（図９、Ｓ３７：ＮＯ）、ＣＰＵ２０１１は、図１０のＳ７１で選択され、処理対象日程記憶エリア２３９に記憶された処理対象日程の日時と場所を新規イベントの開催日時および場所としてスケジュールを決定する（Ｓ３８）。さらに、ＣＰＵ２０１１は、サーバ１０の個人スケジュールＤＢ１０２２にアクセスする。そして、処理対象日程記憶エリア２３９に記憶されている日時と場所、および新規イベント情報記憶エリア２３１に記憶されている新規イベント情報の区分、参加者、内容等を、新規イベントの各参加者のスケジュール情報として新たに登録する（Ｓ３９）。例えば、図１１の入力例の場合、参加者であるＡＡ（ユーザ２１０）およびＣＣ（ユーザ２０００３）のスケジュール情報が、個人スケジュールＤＢ１０２２に登録される。また、ＣＰＵ２０１１は、サーバ１０の会議室ＤＢ１０２３にもにアクセスし、同様にして、決定された日程の会議室予約情報を新たに登録する（Ｓ３９）。その後、ＣＰＵ２０１１は、図７のメイン処理に戻ってディスプレイ２０４に決定したスケジュールを表示させてから（Ｓ１８）、処理を終了する。

一方、図１０のＳ７２において、追加参加者候補記憶エリア２３５に追加参加者候補が記憶されていると判断した場合には（Ｓ７２：ＹＥＳ）、ＣＰＵ２０１１は、サーバ１０の記憶装置１０２の個人スケジュールＤＢ１０２２にアクセスする。そして、処理対象日程の日時およびその前後（例えば、前後１時間）の追加参加者候補のスケジュール情報を取得して、ＲＡＭ２０１３の追加参加者スケジュール記憶エリア２４０に記憶させる（Ｓ７３）。なお、追加参加者候補が複数記憶されている場合には、すべての追加参加者候補のスケジュール情報が取得される。

次いでＣＰＵ２０１１は、追加参加者スケジュール記憶エリア２４０を参照して、追加参加者候補のいずれかのスケジュールが処理対象日程の日時に空いているか否かを判断する（Ｓ７６）。これは、追加参加者として選択されても、スケジュールの変更が必要なく、特に支障がないユーザ２００を優先的に選択するためである。追加参加者候補のいずれにも空きがない場合には（Ｓ７６：ＮＯ）、追加参加者候補記憶エリア２３５に記憶された追加参加者候補のパーソナルデータを参照する。そして、役職レベルが最下位の追加参加者候補を１名選択し、選択候補としてＲＡＭ２０１３の選択候補記憶エリア２４１に記憶させる（Ｓ９３）。ここで役職レベルが最下位の追加参加者候補を選択するのは、役職レベルが高いユーザ２００ほど多忙であることが多いため、新たにスケジュールが追加されても、より支障が少ないと思われる候補を選択する趣旨である。なお、前述したように、本実施形態では、役職レベルは、小さい数字ほど上位の役職を示す１〜５までの数字であるから、例えば役職レベルが「５」の追加参加者候補がいれば、その追加参加者が選定される。役職レベルが最下位の追加参加者候補が複数いる場合には、例えば、識別コード（社員コード）が最も小さい追加参加者候補を選定すればよい。また、もともと追加参加者候補が１名しか記憶されていない場合には、その追加参加者候補が選択される。このようにして追加参加者候補のうち１名のみを選択候補として選択すると（Ｓ９３）、ＣＰＵ２０１１は、選択候補の利用するユーザ端末２０に対して、処理対象日時にすでに登録されている別のイベントである登録イベントを、他の日時に移動するように依頼する（Ｓ９４）。

登録イベントの移動依頼に対して、選択候補の利用するユーザ端末２０から、了承できない旨の返答を受けた場合には（Ｓ９５：ＮＯ）、ＣＰＵ２０１１は、追加参加者スケジュール記憶エリア２４０から、この選択候補のスケジュール情報を消去して、候補から除外する（Ｓ９６）。その後、可能であれば他の追加参加者候補に登録イベントの移動依頼を行うために、追加参加者スケジュール記憶エリア２４０を参照して、すべての追加参加者候補について、登録イベント移動可否の確認が済んだか否かを判断する（Ｓ９７）。具体的には、追加参加者スケジュール記憶エリア２４０に記憶されているスケジュール情報がまだあれば、まだすべての追加参加者候補について確認が完了していないことを意味する（Ｓ９７：ＮＯ）。よって、この場合、ＣＰＵ２０１１は、Ｓ９３に戻り、この時点でまだ記憶されている追加参加者候補のうち、役職レベルが最下位の候補を新たに選択候補として選択し、前述のＳ９３〜Ｓ９７の処理を繰り返す。

その後、すべての追加参加者候補について確認が済み、追加参加者スケジュール記憶エリア２４０に記憶されているスケジュール情報がなくなると（Ｓ９７：ＹＥＳ）、現在の処理対象日時では、新規イベントを登録可能な追加参加者候補がいない状態となる。そこで、ＣＰＵ２０１１は、日時の変更が可能か否かを判断する（Ｓ９８）。具体的には、ＣＰＵ２０１１は、候補日程記憶エリア２３８に、現在の処理対象日程の日時と異なる日時の候補日程が記憶されていれば、日時変更は可能であると判断する（Ｓ９８：ＹＥＳ）。よって、この場合ＣＰＵ２０１１は、Ｓ７１に戻り、日時が異なる候補日程のうち最も早い日時のものを選択して処理対象日程とし、前述の処理を繰り返す。その結果、いずれの候補日程についても追加参加者候補の調整がつかないと、最終的にＳ９８においてそれ以上の日時変更は不可能と判断され（Ｓ９８：ＮＯ）、エラーフラグがＯＮとされて、エラーフラグ記憶エリア２４２に記憶される（Ｓ９９）。そして、図９のスケジュール決定処理に戻り、Ｓ３７において、ＣＰＵ２０１１はエラーフラグがＯＮであると判断し（Ｓ３７：ＹＥＳ）、そのまま図７のメイン処理に戻ってディスプレイ２０４にエラーメッセージを表示させてから（図７、Ｓ１８）、処理を終了する。

一方、初回または何度目かの処理において、処理対象日程の日時に空きのある追加参加者候補がいると判断した場合（Ｓ７６：ＹＥＳ）、ＣＰＵ２０１１は、それが複数か否かを判断する（Ｓ７７）。複数いる場合には（Ｓ７７：ＹＥＳ）、ＣＰＵ２０１１は、追加参加者スケジュール記憶エリア２４０を参照し、処理対象日程前後のスケジュールが空いている候補を選択候補として選択し、選択候補記憶エリア２４１に記憶させる（Ｓ７８）。これは、自動的に追加参加者を設定する場合に、なるべく多忙でないユーザ２００を選択するためである。なお、このとき前後のスケジュールが空いている候補が複数ある場合には、例えば、識別コード（社員コード）が最も小さい追加参加者候補を選択すればよい。続いて、ＣＰＵ２０１１は、Ｓ７８で選択した選択候補をディスプレイ２０４に表示させて、ユーザ２１０（ＡＡ）の確認を促す（Ｓ７９）。なお、このときディスプレイ２０４には、選択候補とともに、「了承」、「変更」、および「削除」の３つのボタンが合わせて表示される。一方、処理対象日程の日時に空きのある追加参加者候補が１名だった場合は（Ｓ７７：ＮＯ）、ＣＰＵ２０１１は、その候補を選択候補として選択候補記憶エリア２４１に記憶させるとともに、ディスプレイ２０４に表示させる（Ｓ７９）。また、処理対象日程の日時に空きのある候補がなく（Ｓ７６：ＮＯ）、前述のように、役職レベルが最下位の候補に対して登録イベントの移動を依頼した結果、了承が得られた場合には（Ｓ９３→Ｓ９４→Ｓ９５：ＹＥＳ）、同様に、その候補が表示される（Ｓ７９）。なお、本実施形態では、選択候補は、各必須参加者条件について１名が選択される。すなわち、必須参加者条件が複数ある場合には、複数名の選択候補が選択されることになる。一方、１名だけではなく、追加参加者候補をすべて参加者として追加するのが適切な場合には、Ｓ７７およびＳ７８の処理は省略し、すべての追加参加者候補を複数の選択候補としてＳ７９で表示させてもよい。

ユーザ２１０（ＡＡ）がディスプレイ２０４に表示された選択候補を確認し、この候補を参加者として追加することを了承する「了承」ボタンを選択した場合（Ｓ８１：ＹＥＳ）、ＣＰＵ２０１１は、選択候補記憶エリア２４１に記憶されている選択候補を追加参加者として決定する（Ｓ８２）。その後、ＣＰＵ２０１１は図９のスケジュール決定処理に戻り、エラーフラグ記憶エリア２４２にエラーフラグがＯＮとして記憶されているか否かを判断する。この場合、エラーフラグはＯＮとされていないため（Ｓ３７：ＮＯ）、ＣＰＵ２０１１は、図１０のＳ７１で選択され、処理対象日程記憶エリア２３９に記憶されている処理対象日程の日時と場所を新規イベントの開催日時および場所としてスケジュールを決定する（Ｓ３８）。さらに、ＣＰＵ２０１１は、サーバ１０の記憶装置１０２の個人スケジュールＤＢ１０２２にアクセスする。そして、処理対象日程記憶エリア２３９に記憶されている日時と場所、新規イベント情報記憶エリア２３１に記憶されている新規イベント情報の区分、参加者、および内容等、さらに選択候補記憶エリア２４１に記憶されている選択候補に基づいて、スケジュール情報を新たに登録する（Ｓ３９）。具体的には、例えば、図１１の例のように新規イベントの参加者としてＡＡ（ユーザ２１０）およびＣＣ（ユーザ２０００３）が入力され、その後の処理で追加参加者としてＢＢ（ユーザ２２０）が決定された場合、ＡＡ、ＢＢ、およびＣＣのスケジュール情報が新たに登録される（Ｓ３９）。また、ＣＰＵ２０１１は、サーバ１０の会議室ＤＢ１０２３にもにアクセスし、同様にして、会議室予約情報を新たに登録する（Ｓ３９）。その後、ＣＰＵ２０１１は、図７のメイン処理に戻ってディスプレイ２０４に決定したスケジュールを表示させてから（Ｓ１８）、処理を終了する。

一方、Ｓ７９においてディスプレイ２０４に表示された選択候補を確認した結果、ユーザ２１０（ＡＡ）が追加参加者を他のユーザ２００に変更するように指示する「変更」ボタンを選択する場合がある。このような場合、例えば、ＣＰＵ２０１１は、ディスプレイ２０４に必須参加者条件を満たすその他の追加参加者候補をリスト表示させる。そして、ユーザ２１０は、リストから所望の追加参加者候補を選択することにより、変更入力を行う。変更入力を受け付けると（Ｓ８１：ＮＯ→Ｓ８６：ＹＥＳ）、ＣＰＵ２０１１は、選択候補記憶エリア２４１に変更後の追加参加者候補を選択候補として記憶させる。さらに、ＣＰＵ２０１１は、追加参加者スケジュール記憶エリア２４０に記憶されている変更後の選択候補のスケジュール情報を参照して、現在の処理対象日程の日時に空きがあるか否かを判断する（Ｓ８７）。そして、変更後の選択候補のスケジュールに空きがあれば（Ｓ８７：ＹＥＳ）、ＣＰＵ２０１１はこの候補を追加参加者として決定し（Ｓ８２）、図９のスケジュール決定処理に戻る。一方、変更後の選択候補のスケジュールに空きがなければ（Ｓ８７：ＮＯ）、この候補の利用するユーザ端末２０に対して、この日時にすでに登録されている別のイベントである登録イベントを、他の日時に移動するように依頼する（Ｓ８８）。そして、了承する旨の返答を受けた場合には（Ｓ８９：ＹＥＳ）、ＣＰＵ２０１１はこの候補を追加参加者として決定し（Ｓ８２）、図９のスケジュール決定処理に戻る。了承できない旨の返答を受けた場合には（Ｓ８９：ＮＯ）、ユーザ２１０の希望する変更は不可能なので、ＣＰＵ２０１１はエラーフラグをＯＮとしてエラーフラグ記憶エリア２４２に記憶させてから（Ｓ９０）、図９のスケジュール決定処理に戻る。

また、Ｓ７９においてディスプレイ２０４に表示された選択候補を確認した結果、ユーザ２１０（ＡＡ）が「削除」ボタンを選択した場合には（Ｓ９１：ＹＥＳ）、ＣＰＵ２０１１は、追加参加者を決定することなく、そのまま図９のスケジュール決定処理に戻る。これは、例えば、必須参加者条件として入力者と同じ部署の部長クラス（役職レベル１）が要求される場合であっても、このときに限って課長に会議での決裁が一任されている場合のように、追加参加者が不要な場合もある。そこで、このような場合には自動的に追加参加者を決定せず、臨機応変な対応を可能とするためである。追加参加者候補を変更（Ｓ８６：ＹＥＳ）または削除し（Ｓ９１：ＹＥＳ）、図９のスケジュール決定処理に戻った後は、いずれの場合も前述と同様の処理が行われる。

以上に説明したように、本実施形態では、イベントの内容毎に、参加者の属性として必須とされる必須参加者条件が予め定められ、その対応関係が必須属性ＤＢ１０２５に記憶されている。また、スケジュール調整システム１を利用する全ユーザ２００の属性は、パーソナルＤＢ１０２４に記憶されている。新規イベント情報が入力されると、入力された新規イベントの内容に対応する必須参加者条件が必須属性ＤＢ１０２５から取得される。そして、入力された参加者だけではこの条件を満たすことができないと判断されると、パーソナルＤＢ１０２４を参照して、条件を満たす属性を有する追加参加者が自動的に選択される。したがって、新規イベント情報の入力者が、本来新規イベントへの出席が必要なユーザ２００を参加者として入力し忘れた場合でも、適切な参加者を含めたスケジュール調整を行うことができる。また、入力時に新規イベントの内容さえ入力すれば、細かい条件設定を行わなくても、適切な参加者を追加することができる。

また、必須参加者条件として要求される参加者の属性には、所属、役職（役職レベル）、または職種に関する情報が含まれている。したがって、イベントの内容に応じて、適切な所属の担当者、決裁権限を有する責任者に相当する役職、または専門の職種等を考慮して、必須参加者条件を予め定めておくことができる。また、これらの属性に関する情報は、特に企業等では通常管理されている情報なので、新たな情報としてパーソナルＤＢ１０２４登録する手間も必要なく、データ量が徒に増大する虞がない。

本実施形態では、ユーザ端末２０が、本発明の「スケジュール調整装置」に相当し、スケジュール調整プログラム２０２１が「スケジュール調整プログラム」に相当する。また、図７のＳ１３において、入力された新規イベント情報を取得するＣＰＵ２０１１が、「新規イベント情報取得手段」に相当する。また、図８のＳ２２において、必須属性ＤＢ１０２５から必須参加者条件を取得するＣＰＵ２０１１が、「参加者条件取得手段」に相当し、Ｓ２３において、新規イベント参加者のパーソナルデータを取得するＣＰＵ２０１１が、「参加者属性取得手段」に相当する。また、図８のＳ２４において、参加者の属性が必須参加者条件をすべて満たしているか否かを判断するＣＰＵ２０１１が、「条件充足判断手段」に相当する。また、図８のＳ２７において、追加参加者候補を選択するＣＰＵ２０１１が、「追加参加者選択手段」に相当する。さらに、図１０のＳ７３において、追加参加者候補のスケジュール情報を個人スケジュールＤＢ１０２２から取得するＣＰＵ２０１１が、「個人スケジュール取得手段」に相当する。

<第２の実施形態>
次に、図１４〜図１６を参照して、第１の実施形態と異なる点を主として、本発明の第２の実施形態について説明する。図１４は、本実施形態に係るスケジュール調整処理のメイン処理のフローチャートである。図１５は、図１４のメイン処理の中で行われる参加者確認処理のフローチャートである。図１６は、本実施形態に係る新規スケジュール入力画面５２の説明図である。なお、図１４および図１５の処理は、第１の実施形態と同様、記憶装置２０２に記憶されたスケジュール調整プログラム２０２１（図５参照）に従って、ＣＰＵ２０１１が実行する。

前述の第１の実施形態では、予めイベントの内容毎に定められた必須参加者条件を記憶する必須属性ＤＢ１０２５のみを参照して、新規イベント情報入力時に指定された参加者が必須参加者条件を満たしているか否かが判断されていた。本実施形態は、新規イベント情報の入力時に、ユーザ２００が必須参加者条件を適宜変更入力できるように構成されている点に特徴を有するものである。本実施形態に係るスケジュール調整システム１およびその構成要素であるサーバ１０およびユーザ端末２０の構成は、第１の実施形態と同一であるため、説明を省略し、以下に、本実施形態においてユーザ端末２０で行われるスケジュール調整処理について説明する。

ユーザ端末２０においてスケジュール調整プログラム２０２１が起動され、図１４に示す本実施形態に係るメイン処理が開始されると、ＣＰＵ２０１１はまず、ディスプレイ２０４に新規スケジュール入力画面５２（図１６参照）を表示させる（Ｓ４０）。図１６に示すように、本実施形態でディスプレイ２０４に表示される新規スケジュール入力画面５２には、第１の実施形態に係る新規スケジュール入力画面５１（図１１参照）の各種の入力欄５１１〜５１６の他、必須属性欄５２１が設けられている。必須属性欄５２１は、入力者であるユーザ２１０（ＡＡ）が、入力中の新規イベントに参加が必須とされる必須参加者の属性（必須参加者条件）を必要に応じて指定するための欄である。必須属性欄５２１は、さらに部署欄５２１１、役職欄５２１２、および職種５２１３に区分されており、それぞれについて、「何でもよい」、「入力者と同じ」、および「指定」の３種類のチェックボックスが設けられている。なお、「指定」チェックボックスの横には、具体的な指定内容を入力する入力ボックスも設けられている。

必須属性欄５２１から入力が可能な必須参加者条件である部署、役職、および職種は、第１の実施形態で説明した、必須属性ＤＢ１０２５（図２参照）に登録された必須参加者条件（図４参照）に対応している。新規スケジュール入力画面５２が表示された時点では、必須属性欄５２１のチェックボックスはすべて「何でもよい」がチェックされた状態で表示される。しかしその後、ユーザ２１０により内容欄５１２に内容が入力されると（Ｓ４２：ＹＥＳ）、サーバ１０の必須属性ＤＢ１０２５が参照され、入力された内容に対応する必須参加者条件の有無が判断される（Ｓ４２）。対応する必須参加者条件が記憶されていれば（Ｓ４２：ＹＥＳ）、ＣＰＵ２０１１はその条件をＲＡＭ２０１３に読み出して（Ｓ４３）、新規スケジュール入力画面５２の部署欄５２１１、役職欄５２１２、および職種５２１３に表示させる（Ｓ４４）。

例えば、内容欄５１２において、内容として「定例会」が入力されると、必須属性ＤＢ１０２５（図４参照）から、「定例会」に対応する必須参加者条件、すなわち、部署として「入力者と同じ」、役職レベルとして「何でもよい」、職種として「入力者と同じ」が読み出される（Ｓ４３）。そして、新規スケジュール入力画面５２の部署欄５２１１、役職欄５２１２、および職種５２１３において、それぞれ「入力者と同じ」、「何でもよい」、「入力者と同じ」のチェックボックスがチェックされた状態となる（Ｓ４４）。一方、例えば「事務担当者打合せ」等のように、必須属性ＤＢ１０２５（図４参照）に必須参加者条件が登録されていない内容が内容欄５１２に入力された場合には（Ｓ４２：ＮＯ）、必須属性欄５２１はすべて「何でもよい」が表示された状態のままとなる。ユーザ２１０は、必須属性欄５２１が初期表示（すべて「何でもよい」）の場合、および前述のように自動入力がされた場合、いずれの場合にも、必須属性欄５２１において、所望の属性を入力することができる。例えば、図１６の例では、内容として「戦略会議」が入力されている。よって、入力時には、必須属性ＤＢ１０２５（図４参照）から読み出した「戦略会議」に対応する必須参加者条件である部署、役職レベル、職種として「入力者と同じ」、「指定：２以上」、「何でもよい」のチェックボックスがチェックされた状態となる。その後、ユーザ２１０が、役職レベルを「レベル２：上級職」に変更し、職種を「企画」に変更すると、図１６のような状態となる、。このように、本実施形態では、入力された新規イベントの内容が必須属性ＤＢ１０２５（図４参照）に登録されているものであれば、対応する必須参加者条件が表示されるが、その都度、ユーザ２１０の所望の条件を設定することもできる。

第１の実施形態の場合と同様に、新規スケジュール入力画面５２においてユーザ２１０による入力が完了し、「設定」ボタン５１７が選択されて入力が確定されると（Ｓ４５：ＹＥＳ）、入力された新規イベント情報がＲＡＭ２０１３の新規イベント情報記憶エリア２３１に記憶される（Ｓ４６）。なお、本実施形態では、必須参加者条件は、ここで新規スケジュール入力画面５２を介して入力された他の情報とともに新規イベント情報として確定され、記憶される。続いてＣＰＵ２０１１は、新規イベント情報記憶エリア２３１を参照して、必須参加者条件が指定されているか否かを判断する（Ｓ４７）。具体的には、必須参加者条件の部署、役職、および職種がいずれも「何でもよい」として記憶されている場合以外は、新規イベントの内容に対応する必須属性ＤＢ１０２５から読み出されたか、またはユーザ２１０によって所望の条件が入力されている。したがって、ＣＰＵ２０１１は、このような場合、必須参加者条件が指定されていると判断して（Ｓ４７：ＹＥＳ）後述する参加者確認処理を行う（Ｓ５０）。一方、必須参加者条件の部署、役職、および職種がいずれも「何でもよい」として記憶されている場合、すなわち、必須参加者条件が指定されていない場合には（Ｓ４７：ＮＯ）、ＣＰＵ２０１１は、「追加参加者なし」と決定する（Ｓ４８）。そして、いずれの場合も、ＣＰＵ２０１１は続いてスケジュール決定処理（Ｓ３０、図９）を行い、結果をディスプレイ２０４に表示させてから（Ｓ４９）処理を終了する。なお、スケジュール決定処理については、第１の実施形態の処理（図９参照）と同様のため、ここでは説明を省略する。

ここで、本実施形態に係る参加者確認処理（Ｓ５０）について、図１５を参照して以下に説明する。本実施形態では、前述したように、メイン処理において新規イベント情報の入力が確定された段階で、必須参加者条件が新規イベント情報の一部としてすでに新規イベント情報記憶エリア２３１に記憶されている。そこで、図１５の参加者確認処理が開始されると、ＣＰＵ２０１１はまず、サーバ１０のパーソナルＤＢ１０２４にアクセスし、新規イベント情報記憶エリア２３１に記憶された新規イベントの参加者のパーソナルデータを、参加者情報記憶エリア２３３に記憶させる（Ｓ５１）。その後のＳ５２〜Ｓ５６の処理は、第１の実施形態の参加者確認処理（図８参照）のＳ２４〜Ｓ２９の処理と同様であるため、説明を省略する。この参加者確認処理を通じて、第１の実施形態と同様、必須属性ＤＢ１０２５から読み出された、またはユーザ２１０によって入力された必須参加者条件が入力された参加者だけでは満たされない場合、不足している条件を満たす適切な追加参加者が自動的に選択される。

以上に説明したように、本実施形態では、第１の実施形態と同様、イベントの内容毎に参加者の属性として必須とされる必須参加者条件が予め定められ、その対応関係が必須属性ＤＢ１０２５に記憶されている。そして、入力された新規イベントの内容に対応する必須参加者条件が必須属性ＤＢ１０２５から取得され、新規スケジュール入力画面５２に表示された後、入力者であるユーザ２００は、必須参加者条件を構成する各属性について、所望の条件に変更することができる。したがって、新規イベント情報を入力する際、新規イベント参加者条件を臨機応変に設定することができる。

本実施形態では、ユーザ端末２０が、本発明の「スケジュール調整装置」に相当し、スケジュール調整プログラム２０２１が「スケジュール調整プログラム」に相当する。また、図１４のＳ４６において、入力された新規イベント情報を取得するＣＰＵ２０１１が、「新規イベント情報取得手段」に相当する。また、図１４のＳ４３において、必須属性ＤＢ１０２５から必須参加者条件を取得するＣＰＵ２０１１が、「参加者条件取得手段」に相当する。また、図１５のＳ５２において、参加者の属性が必須参加者条件をすべて満たしているか否かを判断するＣＰＵ２０１１が、「条件充足判断手段」に相当する。また、図１５のＳ５５において、追加参加者候補を選択するＣＰＵ２０１１が、「追加参加者選択手段」に相当する。

なお、本発明のスケジュール調整装置およびスケジュール調整プログラムは、上記した第１の実施形態および第２の実施形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において各種の変形が可能なことは言うまでもない。

例えば、前述の実施形態では、ネットワークを介して接続されたサーバ１０とユーザ端末２０のうち、ユーザ端末２０の記憶装置２０２にスケジュール調整プログラム２０２１が記憶されており、ユーザ端末２０が主なスケジュール調整機能を有していた。これを、サーバ１０の記憶装置１０２に、スケジュール調整プログラム２０２１を記憶し、サーバ１０においてスケジュール調整処理を行うように構成してもよい。この場合、ユーザ端末２０においてキーボード２０３等を介して入力された新規イベント情報をサーバ１０に送信し、サーバ１０が受信した新規イベント情報を基に図７のＳ１３以降の処理を行う。そして、Ｓ１８において、スケジュール決定処理（図７、Ｓ３０）の結果をディスプレイ１０４に表示させる代わりに、入力者のユーザ端末２０に送信すればよい。なお、この場合には、サーバ１０が、本発明の「スケジュール調整装置」に相当し、サーバ１０のＣＰＵ１０１１が、「新規イベント情報取得手段」、「参加者条件取得手段」、「条件充足判断手段」、および「追加参加者選択手段」に相当する。

スケジュール調整システム１のシステム構成図である。 サーバ１０の電気的構成を示すブロック図である。 パーソナルデータデータベース１０２４に登録されたパーソナルデータの説明図である。 必須属性データベース１０２５に登録された必須属性データの説明図である。 ユーザ端末２０の電気的構成を示すブロック図である。 ユーザ端末２０のＲＡＭ２０１３の記憶エリアの説明図である。 第１の実施形態に係るスケジュール調整処理のメイン処理のフローチャートである。 図７のメイン処理の中で行われる参加者確認処理のフローチャートである。 図７のメイン処理の中で行われるスケジュール決定処理のフローチャートである。 図９のスケジュール決定処理の中で行われる追加参加者決定処理のフローチャートである。 第１の実施形態に係る新規スケジュール入力画面５１の説明図である。 パーソナルデータの具体例の説明図である。 パーソナルデータの別の具体例の説明図である。 第２の実施形態に係るスケジュール調整処理のメイン処理のフローチャートである。 図１４のメイン処理の中で行われる参加者確認処理のフローチャートである。 第２の実施形態に係る新規スケジュール入力画面５２の説明図である。

符号の説明

１ スケジュール調整システム
１０ サーバ
１０１１ ＣＰＵ
１０２２ 個人スケジュールデータベース
１０２３ 会議室スケジュールデータベース
１０２４ パーソナルデータデータベース
１０２５ 必須属性データベース
２０ ユーザ端末
２０２１ スケジュール調整プログラム

Claims (8)

1. 新規イベントの開催スケジュールを調整するスケジュール調整装置において、
   新規イベントの内容および前記新規イベントへの参加者である新規イベント参加者を含む、新規イベント情報を取得する新規イベント情報取得手段と、
   複数のユーザの識別情報と前記ユーザの属性とを対応づけて記憶する属性情報記憶手段から、前記新規イベント参加者の前記属性を取得する参加者属性取得手段と、
   前記参加者属性取得手段によって取得された前記新規イベント参加者の前記属性である新規イベント参加者属性が、前記新規イベント参加者の属性として必須の条件である新規イベント参加者条件を充足するものであるか否かを判断する条件充足判断手段と、
   前記条件充足判断手段によって、前記新規イベント参加者属性が前記新規イベント参加者条件をすべて充足していないと判断された場合に、前記新規イベントへの追加参加者として、前記属性情報記憶手段から、前記新規イベント参加者属性が充足していない前記新規イベント参加者条件を充足する属性を有する前記ユーザを選択する追加参加者選択手段とを備えたことを特徴とするスケジュール調整装置。
2. イベントの内容と当該イベントへの参加者の属性として必須の条件であるイベント参加者条件とを対応づけて記憶する参加者条件記憶手段から、前記新規イベントの前記内容に対応する前記イベント参加者条件を、前記新規イベント参加者条件として取得する参加者条件取得手段をさらに備え、
   前記条件充足判断手段は、前記新規イベント参加者属性が、前記参加者条件取得手段によって取得された前記新規イベント参加者条件を充足するものであるか否かを判断することを特徴とする請求項１に記載のスケジュール調整装置。
3. 前記新規イベント情報取得手段によって取得される前記新規イベント情報は、前記新規イベント参加者条件を含むことを特徴とする請求項１または２に記載のスケジュール調整装置。
4. 前記属性は、少なくとも前記ユーザの所属、役職、または職種に関する情報のいずれか１つを含むことを特徴とする請求項１〜３のいずれかに記載のスケジュール調整装置。
5. 前記ユーザの前記識別情報と、すでに登録されたイベントである登録イベントの登録日時を含む個人スケジュール情報とを対応づけて記憶する個人スケジュール記憶手段から、前記新規イベント参加者条件を充足する前記ユーザの前記個人スケジュール情報を取得する個人スケジュール取得手段をさらに備え、
   前記新規イベント情報は、前記新規イベントの開催を希望する日時または期間を含み、
   前記追加参加者選択手段は、前記個人スケジュール取得手段によって取得された前記個人スケジュール情報に基づいて、前記日時または前記期間に前記登録イベントがない前記ユーザを、前記追加参加者として選択することを特徴とする請求項１〜４のいずれかに記載のスケジュール調整装置。
6. 前記追加参加者選択手段は、前記個人スケジュール取得手段によって取得された前記個人スケジュール情報に基づいて、前記日時の前後に前記登録イベントがない前記ユーザ、または前記期間内で最も前記登録イベントが少ない前記ユーザを、前記追加参加者として選択することを特徴とする請求項５に記載のスケジュール調整装置。
7. 前記追加参加者選択手段は、前記ユーザの前記役職に関する情報が最も下位である前記ユーザを、前記追加参加者として選択することを特徴とする請求項４〜６のいずれかに記載のスケジュール調整装置。
8. 請求項１〜７のいずれかに記載のスケジュール調整装置の各種処理手段としてコンピュータを機能させるためのスケジュール調整プログラム。

Images