【事件の表示】
　特願２００２−１７２１６１「就業情報申請を受け付けるコンピュータプログラムおよび就業情報申請を受け付ける装置」拒絶査定不服審判事件〔平成１６年　１月２２日出願公開、特開２００４−　２１３６１〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は，平成１４年６月１３日の出願であって，平成２０年５月８日付けで拒絶査定がなされ，これに対して同年６月１２日に拒絶査定に対する審判請求がなされるとともに，同日付けで手続補正がなされ，平成２２年９月２９日付けの当審の拒絶理由通知に対して同年１１月２４日付けで意見書が提出されるとともに手続補正がなされたものである。
　
２．当審の拒絶理由の概要
　当審の拒絶理由の概要は，以下のとおりである。
　
『１．この出願の下記の請求項に係る発明は，その出願前に日本国内又は外国において，頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて，その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。  
　（途中省略）
 　　　　　　　　　　　　　　　　　記 
 引用例１：特開平４−１８１３６１号公報 
 引用例２：特開２０００−２５９７２４号公報 
 引用例３：特開平５−２７４５０８号公報 
 　 
 [理由１]について 
 ・請求項１，２に対して 
 ・引用例１〜３ 
　（途中省略）
　したがって，本願の請求項１，２に係る発明は，引用例１〜３に記載されたものに基づいて当業者が容易に想到し得たものである。』
　
３．本願発明
　本願の請求項１に係る発明（以下，「本願発明」という。）は，平成２２年１１月２４日付けの手続補正書により補正された特許請求の範囲の請求項１に記載された事項により特定される次のとおりのものである。
　
「
【請求項１】　コンピュータを，就業情報申請を受け付ける装置として機能させる勤怠管理プログラムであって，
　
前記コンピュータを，
　
従業員が年休の取得を希望する日を特定する情報を受け付ける年休予定入力手段と，
　
従業員を特定する特定情報と，行動予定の時期を特定する行動予定時期特定情報と，どのような行動を行う予定かを特定する行動予定特定情報と，を関連づけて記録したグループウェアの行動予定ファイルから，前記年休予定入力手段で受け付けた年休の取得を希望する日の前記従業員の行動予定特定情報を抽出する手段と，
　前記年休予定入力手段で受け付けた前記従業員を特定する情報を基に，従業員を特定する情報と該従業員の申請に対する承認者の連絡先を特定する情報とを関連づけて記録した承認者ファイルから，承認者の連絡先を特定し，該特定をした承認者の連絡先に，前記年休予定入力手段で受け付けた前記従業員が年休の取得を希望する日を特定する情報と，前記年休の取得を希望する日の前記従業員の行動予定特定情報と，を送信する手段と，
　して機能させることを特徴とする就業情報申請を受け付ける勤怠管理プログラム。
　
　なお，下線部は，当審の拒絶理由通知に対して提出された手続補正書において，補正を示す個所として審判請求人が付したものである。
　
４．引用例 
　これに対して，当審において，平成２２年９月２９日付けで通知した拒絶の理由において引用した「特開２０００−２５９７２４号公報」（以下，「引用例２」という。）には，図面とともに，次の（ア）乃至（ク）の事項が記載されている。
　
（ア）「【０００１】
【発明の属する技術分野】本発明は，企業の社員等の勤務に関する情報の管理を行う勤務情報管理システム，勤務情報管理方法及び勤務情報管理プログラムを記録した記録媒体に係わり，特に複数の勤務情報の相互チェックを行う技術に関する。」
　
（イ）「【００１０】
【発明の実施の形態】以下，本発明の一実施形態による勤務情報管理システムを図面を参照して説明する。図１は同実施形態の全体の構成を示すブロック図である。この図において，符号１は，勤務情報の管理を行う勤務情報管理システムである。符号２は，勤務に関する申請に対して承認を行う承認端末である。符号３は，勤務に関する申請を行う申請端末である。符号４は，２つの異なるネットワークを接続して，ルーティングを行うルータである。符号５は，勤務情報管理システム１，承認端末２及び申請端末３が接続されたネットワークである。符号６は，ネットワークであり，複数のネットワークがルータ４によって接続されている。」
　
（ウ）「【００１４】次に，図２を参照して図１に示す勤務情報管理システム１の構成を説明する。図２において，符号１１は，ネットワーク５を介して他のシステムとデータの入出力を行うデータ入出力部である。符号１２は，入力されたデータの選別を行うデータ選別部である。符号１３は，申請端末３から送られた申請データの処理を行う申請処理部である。符号１４は，勤務に関する申請処理を行う勤務情報申請部である。符号１５は，勤務に関する情報を記録する勤務票ファイルである。符号１６は，出張に関する申請処理を行う出張情報申請部である。符号１７は，出張情報を記録する出張ファイルである。符号１８は，有給休暇（以下，年休と称する）に関する申請処理を行う年休情報申請部である。符号１９は，年休情報を記録する年休ファイルである。」
　
（エ）「【００１６】次に，図１，２を参照して勤務情報管理システム１の動作を説明する。初めに，申請処理について説明する。申請処理は，勤務，出張及び年休に関する申請処理があり，順に説明する。まず，勤務に関する申請処理を行う動作を説明する。ここでいう勤務に関する申請処理とは，申請者が日毎に出勤したか否かを申請するものである。申請者は，申請端末３を起動して，これから申請を行おうとする申請の種類を指定する。ここでは，勤務に関する申請が指定されたものとする。申請端末３は，申請者によって指定された申請の種類を含む申請処理依頼のデータを勤務情報管理システム１へ出力する。これを受けて，勤務情報管理システム１のデータ入出力部１１は，申請処理依頼のデータを入力して，データ選別部１２へ渡す。データ選別部１２は，このデータが申請処理を行うものであるか，承認処理を行うものであるかを選別して，その結果に基づいて，入力したデータを申請処理部１３または承認処理部２０へ出力する。ここでは，入力されたデータは申請処理を依頼するデータであるので，申請処理部１３へデータが出力される。」
　
（オ）「【００２１】図３は，図２に示す勤務票ファイル１５内に設けられた勤務票テーブルの構造を示す図である。勤務票テーブルは，月度毎でかつ個人毎に１つのテーブルが勤務票ファイル１５内に設けられる。また，勤務票テーブルは，ヘッダフィールド，日付フィールド，勤務状況フィールド，記事フィールド及び承認フィールドからなる。
【００２２】ヘッダフィールドには，予め「月度」，「部署名」及び「氏名」が書き込まれる。また，日付フィールドには，その月の日付と曜日が予め書き込まれている。また，出勤状況フィールドには，申請者が勤務した日は「出勤」が書き込まれ，申請者から入力がされていない場合は，「／」が書き込まれている。すなわち，「／」が書き込まれている日は，予め定められた休日であるか申請者が勤務をしていない日であることを意味する。さらに，記事フィールドは，後述する出張情報または年休情報が書き込まれる。また，予め定められた休日にもこの記事フィールドに「休日」が予め書き込まれている。承認フラグフィールドには，この勤務の申請に関して承認済みであるか否かを示すフラグが書き込まれる。」
　
（カ）「【００２６】次に，年休に関する申請を行う動作を説明する。年休に関する申請においても，勤務に関する申請と同様に，申請者は，申請端末３から年休に関する情報を入力する。ただし，申請者が入力する情報は，申請者の部署名，申請者の氏名，年休を取得する日付，年休種別である。ここでいう年休種別とは，年休の種類のことであり，「２時間」，「半日」，「１日」のいずれかとなる。
【００２７】申請処理部１３は，受け取ったデータが年休に関する申請処理のデータであった場合にこのデータを年休情報申請部１８へ渡す。これを受けて，年休情報申請部１８は，受け取ったデータに含まれる部署名と氏名に基づいて該当する年休テーブルへデータを書き込むようにする。
【００２８】図５は，図２に示す年休ファイル１９内に設けられた年休テーブルの構造を示す図である。年休テーブルは，個人毎に設けられ，ヘッダフィールド，申請番号フィールド，年休日付フィールド，年休種別フィールド及び承認フラグフィールドからなる。ヘッダフィールドには，予め部署名と氏名が書き込まれる。申請番号フィールドには，申請された順に付与された順番号が書き込まれる。年休日付フィールドには，年休の日付が書き込まれる。年休種別フィールドには，年休の種類が書き込まれる。承認フラグフィールドには，この年休申請に関して承認済みであるか否かを示すフラグが書き込まれる。
【００２９】なお，勤務票テーブル，出張テーブル及び年休テーブルの承認フラグフィールドには，申請時点で「０」が書き込まれている。」
　
（キ）「【００３２】次に，勤務，出張及び年休に関する申請に対して承認を行う動作を説明する。まず，勤務に関する承認を行う動作を説明する。申請処理部１３は，勤務，出張及び年休のそれぞれに関する申請を受け付けた時点で，新たな申請があったことを承認処理部２０へ通知する。これを受けて承認処理部２０は，データ入出力部１１を介して，承認端末２へ新たな申請があったので承認するように指示を出力する。
【００３３】次に，承認者は，承認端末２を操作して未承認の申請処理を表示するように指示を出す。これを受けて，承認処理部２０は，勤務情報承認部２１，出張承認部２２及び年休情報承認部２３のそれぞれに対して，未承認の申請データを読み出すように指示を出す。これを受けて，勤務情報承認部２１，出張承認部２２及び年休情報承認部２３は，勤務票ファイル１５，出張ファイル１７，年休ファイル１９のそれぞれに記録されているテーブルを参照して，承認フラグが「０」である申請データを読み出して，承認処理部２０へ渡す。
【００３４】次に，承認処理部２４は受け取った申請データを順に承認端末２へ表示する。承認者は，承認端末２に表示された申請データの内容を確認し，問題が無ければ承認を行う。承認は，承認者が承認のコマンドを入力するなどによって作成された承認データを出力する。これを受けて，勤務情報管理システム１はデータ入出力部１１を介してこの承認データを入力して，データ選別部１２において，このデータが承認データであるために承認処理部２０へ渡される。
【００３５】次に，承認処理部２０は，この承認データが，どの申請データに対する承認であるかを判別して，勤務情報承認部２１，出張情報承認部２２，年休情報承認部２３のいずれかに出力する。これを受けて，勤務情報承認部２１，出張情報承認部２２，年休情報承認部２３のいずれかは，この承認データに対応するする申請データが記録されている各々のファイルの承認フラグフィールドに「１」を書き込む。これによって，この申請データは，承認されたことになり，申請者はこの申請データを修正できなくなる。
【００３６】ただし，承認しようとする申請データが出張または年休に関する申請であった場合には，以下に説明するチェック処理が行われる。まず，承認された申請データが出張に関する申請であった場合に，出張情報承認部２２は，承認された申請データの出張日付と出張種別を勤務情報承認部２１へ渡す。これを受けて勤務情報承認部２１は，この受け取った出張日付に基づいて，勤務票テーブルの該当する日付の記事フィールドに受け取った出張種別を書き込む。このとき，勤務情報承認部２１は，同一日付の記事フィールドに既に他のデータが書き込まれていた場合には，勤務情報承認部２１内に設けられた承認チェックテーブルを参照して，既に書き込まれていたデータと書き込もうとしているデータのチェックを行う。
【００３７】図６は，勤務情報承認部２１内に設けられた承認チェックテーブルのテーブル構造を示す図である。この図に示すように，承認チェックテーブルは，承認項目フィールドとチェック項目フィールドからなる。承認項目フィールドには，出張種別または年休種別が予め書き込まれている。また，チェック項目フィールドには各承認項目毎に，あり得ない条件のデータが書き込まれている。例えば，「年休１日」と「出張日帰」及び「出張宿泊」はあり得ない条件である。また，「出張日帰」と「年休１日」，「出張宿泊」と「年休１日」もあり得ない条件である。さらに，「年休半日」と「年休２時間」は，他の組み合わせがあり得るためにチェック項目は空欄となっている。
【００３８】図６に示した承認チェックテーブルを参照することによって，勤務票テーブルの記事フィールドに書き込もうとした出張種別または年休種別と同じ項目を承認項目フィールドから探し出し，その項目に対応するチェック項目が，既に記事フィールドに書き込まれていた場合，勤務情報承認部２１は，あり得ない条件の承認を行おうとしていることを承認処理部２０へ通知する。
【００３９】これを受けて，承認処理部２０は，修正指示出力処理部２６に対して修正指示を出力するように通知する。修正指示出力処理部２６は，承認端末２に対してあり得ない条件の申請がされていること示すメッセージを表示する。また，承認処理部２０は，あり得ない条件に該当する日付の申請データの承認フラグを「０」にするように，勤務情報承認部２１，出張情報承認部２２，年休情報承認部２３に対して通知する。
【００４０】次に，勤務情報承認部２１，出張情報承認部２２，年休情報承認部２３は，該当する日付の承認フラグを「０」にする。これによって，既に承認されている申請データの承認が解除される。さらに，勤務情報承認部２１は，該当する日付の記事フィールドに書き込まれているデータを削除する。
【００４１】承認者は，あり得ない条件の申請がされていること示すメッセージが表示されたときに，その申請を行った申請者に対して，再度申請のやり直しをするように指示する。
【００４２】申請者は，申請端末３より，再度申請のやり直しをする。以下の動作は前述した動作と同様である。
【００４３】このように，同一日付においてあり得ない条件の申請が行われた場合であっても承認者に対して，修正の指示を出力することができるので，申請の誤りを防止することができる。」
　
（ク）「【００４９】また，図２に示す各機能を実現するためのプログラムをコンピュータ読み取り可能な記録媒体に記録して，この記録媒体に記録されたプログラムをコンピュータシステムに読み込ませ，実行することにより勤務情報管理処理を行ってもよい。なお，ここでいう「コンピュータシステム」とは，ＯＳや周辺機器等のハードウェアを含むものとする。また，「コンピュータ読み取り可能な記録媒体」とは，フロッピー（登録商標）ディスク，光磁気ディスク，ＲＯＭ，ＣＤ−ＲＯＭ等の可搬媒体，コンピュータシステムに内蔵されるハードディスク等の記憶装置のことをいう。」
　
　上記摘記事項（ウ）の「次に，
図２を参照して
勤務情報管理システム１の構成を説明する
図２に示す各機能を実現するためのプログラムを
コンピュータシステムに読み込ませ，実行することにより
　また，上記摘記事項（エ）の「次に，図１，２を参照して勤務情報管理システム１の動作を説明する。初めに，申請処理について説明する。申請処理は，勤務，出張及び
年休に関する申請処理
　してみれば，引用例２には，「コンピュータシステムを，年休申請を受け付ける勤務情報管理システム１として機能させるプログラム」との事項が記載されているといえる。
　
　上記摘記事項（カ）の「次に，年休に関する申請を行う動作を説明する。年休に関する申請においても，勤務に関する申請と同様に，申請者は，申請端末３から年休に関する情報を入力する。ただし，
申請者が
年休を取得する日付
　
　上記摘記事項（キ）の「次に，勤務，出張及び年休に関する申請に対して承認を行う動作を説明する。（途中省略）申請処理部１３は，勤務，出張及び年休のそれぞれに関する申請を受け付けた時点で，新たな申請があったことを承認処理部２０へ通知する。これを受けて
承認処理部２０は，
承認端末２へ新たな申請があったので承認するように指示を出力する
承認処理部２０
は
申請データを
承認端末２へ表示する
　
　上記摘記事項（キ）の「ただし，
承認しようとする申請データが出張または年休に関する申請であった場合には，
チェック処理が行われる
　
　上記摘記事項（キ）の「まず，
承認された申請データが出張に関する申請であった場合に，
受け取った出張日付に基づいて，勤務票テーブルの該当する日付の記事フィールドに受け取った出張種別を書き込む
このとき，
同一日付の記事フィールドに既に他のデータが書き込まれていた場合には，
既に書き込まれていたデータと書き込もうとしているデータのチェックを行う
　
　上記摘記事項（オ）の「図３は，図２に示す勤務票ファイル１５内に設けられた勤務票テーブルの構造を示す図である。
勤務票テーブルは，
勤務票ファイル１５内に設けられ
勤務票テーブルは，ヘッダフィールド，日付フィールド，
記事フィールド
からなる
ヘッダフィールドには，
「氏名」が書き込まれ
日付フィールドには，
日付
が
書き込まれ
記事フィールドは，
出張情報または年休情報が書き込まれる
　
　上記摘記事項（キ）の「図６に示した承認チェックテーブルを参照することによって，
勤務票テーブルの記事フィールドに書き込もうとした
年休種別
の項目に対応するチェック項目が，既に記事フィールドに書き込まれていた場合，
承認端末２に対してあり得ない条件の申請がされていること示すメッセージを表示する
　
　以上の点を踏まえ，上記摘記事項（ア）乃至（ク）の記載及び図面の記載を総合すると，引用例２には，次のとおりの発明（以下，「引用例２発明」という。）が記載されていると認められる。
　
「コンピュータシステムを，年休申請を受け付ける勤務情報管理システム１として機能させるプログラムであって，
　前記コンピュータシステムを，
　申請者が年休を取得する日付を受け取る年休情報申請部１８と，
　承認端末２へ新たな申請があったので承認するように指示を出力するとともに，申請データを承認端末２へ表示する承認処理部２０と，
　承認しようとする申請データが出張または年休に関する申請であった場合には，チェック処理を行う手段であって，承認された申請データが年休に関する申請であった場合に，受け取った年休日付に基づいて，勤務票テーブルの該当する日付の記事フィールドに受け取った年休種別を書き込み，このとき，同一日付の記事フィールドに既に他のデータが書き込まれていた場合には，既に書き込まれていたデータと書き込もうとしているデータのチェックを行う手段と，
　ここで，勤務票テーブルは，勤務票ファイル１５内に設けられ，ヘッダフィールド，日付フィールド，記事フィールドからなり，ヘッダフィールドには，氏名が書き込まれ，日付フィールドには，日付が書き込まれ，記事フィールドは，出張情報または年休情報が書き込まれるものであり，
　勤務票テーブルの記事フィールドに書き込もうとした年休種別の項目に対応するチェック項目が，既に記事フィールドに書き込まれていた場合，承認端末２に対してあり得ない条件の申請がされていること示すメッセージを表示する手段と，
　して機能させることを特徴とする年休申請を受け付けるプログラム。」
　
５．対比
　本願発明と引用例２発明とを対比する。
　
　引用例２発明の「コンピュータシステム」「年休申請」「勤務情報管理システム１」「プログラム」が本願発明の「コンピュータ」「就業情報申請」「装置」「勤怠管理プログラム」にそれぞれ相当する。
　
　引用例２発明の「申請者」「年休を取得する日付」「受け取る」「年休情報申請部１８」が本願発明の「従業員」「年休の取得を希望する日を特定する情報」「受け付ける」「年休予定入力手段」にそれぞれ相当する。
　
　引用例２発明の勤務票テーブルにおける「氏名」「日付」「出張情報または年休情報」が本願発明の行動予定ファイルにおける「従業員を特定する特定情報」「行動予定の時期を特定する行動予定時期特定情報」「どのような行動を行う予定かを特定する行動予定特定情報」にそれぞれ相当する。また，勤務票テーブルにおいて，ヘッダフィールド，日付フィールド，記事フィールドに書き込まれる「氏名」「日付」「出張情報または年休情報」が「関連づけて記録した」ものであることは明らかである。また，勤務票テーブルは勤務票ファイル１５内に設けられているから，「ファイル」に記録されたものであるといえる。
　そうすると，本願発明の「従業員を特定する特定情報と，行動予定の時期を特定する行動予定時期特定情報と，どのような行動を行う予定かを特定する行動予定特定情報と，を関連づけて記録したグループウェアの行動予定ファイル」と引用例２発明の「ヘッダフィールド，日付フィールド，記事フィールドからなり，ヘッダフィールドには，氏名が書き込まれ，日付フィールドには，日付が書き込まれ，記事フィールドは，出張情報または年休情報が書き込まれる勤務票テーブルが設けられる勤務票ファイル１５」とは，後記の点で相違するものの，ともに「従業員を特定する特定情報と，行動予定の時期を特定する行動予定時期特定情報と，どのような行動を行う予定かを特定する行動予定特定情報と，を関連づけて記録したファイル」の点で共通する。
　
　引用例２発明の「チェックを行う手段」は，「承認された申請データが年休に関する申請であった場合に，受け取った年休日付に基づいて，勤務票テーブルの該当する日付の記事フィールドに受け取った年休種別を書き込み，このとき，同一日付の記事フィールドに既に他のデータが書き込まれていた場合には，既に書き込まれていたデータと書き込もうとしているデータのチェックを行う」ものである。そうすると，引用例２発明の「チェックを行う手段」が，当該チェックを行うために，勤務票テーブルから，『年休情報申請部１８（年休予定入力手段）で受け付けた「年休を取得する日付」（年休の取得を希望する日）の申請者（従業員）の「出張情報または年休情報」（行動予定特定情報）を抽出』していることは明らかである。
　そうすると，引用例２発明の「チェックを行う手段」は，本願発明の「年休予定入力手段で受け付けた年休の取得を希望する日の従業員の行動予定特定情報を抽出する手段」を備えているということができる。
　
　引用例２発明の「承認端末２」が本願発明の「承認者の連絡先」に相当する。
　また，本願発明の「前記年休予定入力手段で受け付けた前記従業員が年休の取得を希望する日を特定する情報と，前記年休の取得を希望する日の前記従業員の行動予定特定情報」と引用例２発明の「あり得ない条件の申請がされていること示すメッセージ」とは，ともに「年休の申請に関連する情報」の点で共通する。
　また，引用例２発明の勤務情報管理システム１が，承認端末２に「あり得ない条件の申請がされていること示すメッセージを表示する」ために，当該メッセージを「送信する手段」を備えることは自明である。
　してみれば，本願発明の「前記年休予定入力手段で受け付けた前記従業員を特定する情報を基に，従業員を特定する情報と該従業員の申請に対する承認者の連絡先を特定する情報とを関連づけて記録した承認者ファイルから，承認者の連絡先を特定し，該特定をした承認者の連絡先に，前記年休予定入力手段で受け付けた前記従業員が年休の取得を希望する日を特定する情報と，前記年休の取得を希望する日の前記従業員の行動予定特定情報と，を送信する手段」と引用例２発明の「勤務票テーブルの記事フィールドに書き込もうとした年休種別の項目に対応するチェック項目が，既に記事フィールドに書き込まれていた場合，承認端末２に対してあり得ない条件の申請がされていること示すメッセージを表示する手段」とは，後記する点で相違するものの，ともに，「承認者の連絡先に，年休の申請に関連する情報を送信する手段」の点で共通する。
　
　そうすると，本願発明と引用例２発明とは，
「　コンピュータを，就業情報申請を受け付ける装置として機能させる勤怠管理プログラムであって，
　前記コンピュータを，
　従業員が年休の取得を希望する日を特定する情報を受け付ける年休予定入力手段と，
　従業員を特定する特定情報と，行動予定の時期を特定する行動予定時期特定情報と，どのような行動を行う予定かを特定する行動予定特定情報と，を関連づけて記録したファイルから，前記年休予定入力手段で受け付けた年休の取得を希望する日の前記従業員の行動予定特定情報を抽出する手段と，
　承認者の連絡先に，年休の申請に関連する情報を送信する手段と，
　して機能させることを特徴とする就業情報申請を受け付ける勤怠管理プログラム。」
の点で一致し，以下の点で相違する。
　
［相違点１］
　従業員を特定する特定情報と，行動予定の時期を特定する行動予定時期特定情報と，どのような行動を行う予定かを特定する行動予定特定情報と，を関連づけて記録するファイルが，本願発明では，「グループウェアの行動予定ファイル」であるのに対して，引用例２発明では，そのようなファイルではない点。
　
［相違点２］ 
　本願発明では，「年休予定入力手段で受け付けた従業員を特定する情報を基に，従業員を特定する情報と該従業員の申請に対する承認者の連絡先を特定する情報とを関連づけて記録した承認者ファイルから，承認者の連絡先を特定」しているのに対して，引用例２発明では，承認者の承認端末２をどのようにして特定しているのかが明らかでない点。
　
［相違点３］
　承認者の連絡先に送信する情報が，本願発明では，「年休予定入力手段で受け付けた従業員が年休の取得を希望する日を特定する情報と，前記年休の取得を希望する日の前記従業員の行動予定特定情報」であるのに対して，引用例２発明では，「あり得ない条件の申請がされていること示すメッセージ」である点。
　
６．当審の判断
　上記相違点について検討する。 
　
 ［相違点１］について
　勤怠管理機能やスケジュール管理機能をグループウェアで実現することは，例えば，「特開２００２−１４９９３０号公報」（特に【０００５】〜【０００６】，【００２４】〜【００２７】段落の記載参照），「有岡　治，モバイルソリューション最前線　戦略的にビジネスを進めるＩＴ活用講座　−モバイル環境にも対応したグループウェア　ｉＯｆｆｉｃｅ　Ｖ３　ネオジャパン−，ビジネス　スタンダード，ソフトバンクパブリッシング株式会社，２００２年３月１日，第２巻，第３号，ｐ８０−８２」等に記載されているように周知技術（以下，「周知技術１」という。）であるものと認められる。
　また，当審において，平成２２年９月２９日付けで通知した拒絶の理由において引用した「特開平４−１８１３６１号公報」（以下，「引用例１」という。）には，「スケジュール情報，即ち予定行事と該行事が開始される予定日時の情報を入力して記憶できるスケジュール記憶装置において，既に記憶し登録されているスケジュール情報と予定日時が同一であるスケジュール情報を入力すると（すなわち，予定が重複すると）ブザーなどにより警告を発する技術」（以下，「引用例１記載事項」という。）が記載されている。
　してみれば，引用例２発明に上記周知技術１を適用して，勤怠管理機能をグループウェアで実現し，また，勤怠管理機能に加えてスケジュール管理機能もグループウェアが備えるように構成することには何ら困難性がなく，また，その際，上記引用例１記載事項を適用して，「従業員の行動予定特定情報」を，グループウェアのスケジュール管理機能で作成された「グループウェアの行動予定ファイル」のスケジュール情報から抽出するように構成することにも何ら困難性が無く，当業者が容易に想到し得たことである。
　
　したがって，相違点１に係る本願発明の構成は，引用例２発明，引用例１記載事項，及び周知技術１に基づいて当業者が容易に想到し得たものである。
　
［相違点２］について
　例えば，当審において，平成２２年９月２９日付けで通知した拒絶の理由において引用した「特開平５−２７４５０８号公報」（以下，「引用例３」という。）には，「休暇，出張等の勤休事象の届け出者と，それを承認する権限を有する承認者とを対応付けて承認者データベースに格納すること」が記載されており，また，例えば，特開２００２−１４９９３０号公報（特に【００４７】段落の記載参照）には，「予め格納している管理者データベースを参照して出張申請を行った出張者の管理者を検索し，検索した管理者のＰＣ宛に出張者からの出張申請があった旨を通知する電子メール（通知情報）を送信する」ことが記載されていることから，「従業員を特定する情報と該従業員の申請に対する承認者の連絡先を特定する情報とを関連づけて記録」しておくことは周知技術（（以下，「周知技術２」という。）であるものと認められる。
　してみれば，引用例２発明に上記周知技術２を適用して，「従業員を特定する情報と該従業員の申請に対する承認者の連絡先を特定する情報とを関連づけて記録した承認者ファイル」を設け，『年休情報申請部１８（年休予定入力手段）で受け付けた申請者（従業員）を特定する情報を基に，「承認者ファイル」から，承認者の連絡先を特定する』ように構成することには何ら困難性がなく，当業者が容易に想到し得たことである。
　
　したがって，相違点２に係る本願発明の構成は，引用例２発明及び周知技術２に基づいて当業者が容易に想到し得たものである。
　
［相違点３］について
　引用例２発明において，承認端末２に「あり得ない条件の申請がされていることを示すメッセージを表示する」際に，「年休の申請内容」や「既に記事フィールドに書き込まれていたデータ」を表示することは，当業者であれば，適宜なしうることである。
　してみれば，「年休の申請内容」である「年休予定入力手段で受け付けた従業員が年休の取得を希望する日を特定する情報」や，「既に記事フィールドに書き込まれていたデータ」である「年休の取得を希望する日の従業員の行動予定特定情報」を通知するように構成することには何ら困難性がなく，当業者が容易に想到し得たことである。
　
　したがって，相違点３に係る本願発明の構成は，引用例２発明に基づいて当業者が容易に想到し得たものである。
　
　そして，本願発明の作用効果も，引用例２，引用例１記載事項，及び周知技術１，２から当業者が予測できる範囲のものである。
　
　よって，本願発明は，引用例２発明，引用例１記載事項，及び周知技術１，２に基づいて当業者が容易に発明をすることができたものである。
　
７．むすび 
　以上のとおり，本願発明は，引用例２発明，引用例１記載事項，及び周知技術１，２に基づいて，当業者が容易に発明をすることができたものであるから，特許法第２９条第２項の規定により特許を受けることができない。 
　
　よって，結論のとおり審決する。