【事件の表示】
　特願２０１９−２１３８０６「情報処理装置及びプログラム」拒絶査定不服審判事件〔令和　２年　３月１２日出願公開、特開２０２０−　３８７１８〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
第１　手続の経緯
　本願は、平成３０年１１月２０日（優先日：平成３０年１月３０日）に出願した特願２０１８−２１７６１４号の一部を令和元年１１月２７日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。
　　令和２年　１月２０日　　：手続補正書の提出
　　令和２年　４月　２日付け：拒絶理由通知書
　　令和２年　６月　３日　　：意見書、手続補正書の提出
　　令和２年　７月２８日付け：拒絶査定
　　令和２年１０月　２日　　：審判請求書、手続補正書の提出
　　令和２年１２月　９日付け：令和２年１０月２日付けの手続補正の却下の決定
　　令和２年１２月　９日付け：拒絶理由通知書（最後）
　なお、請求人は、令和２年１２月９日付けの拒絶理由通知に対して、意見書又は手続補正書を提出しなかった。
第２　本願発明
　令和２年１０月２日付けの手続補正は、令和２年１２月９日付けの補正の却下の決定により却下されたので、本願の請求項１ないし６に係る発明は、令和２年６月３日付けの手続補正によって補正された特許請求の範囲の請求項１ないし６に記載されたとおりであるところ、請求項１に係る発明（以下、「本願発明１」という。）は以下のとおりである。
「【請求項１】
　複数の項目から構成される情報を管理する情報処理装置において、
　前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する管理手段と、
　前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合に、当該変更の原因となる事象が生じた際の基準となる第１タイミングと、前記入力された内容との夫々を、基準タイミングと更新内容との夫々として受け付ける第１受付手段と、
　前記第１受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加する追加手段と、
　抽出の基準となる、過去から現在のうちの第２タイミングを受け付ける第２受付手段と、
　前記複数の項目のうち抽出対象となる１以上の項目毎に、前記第２タイミングの直前の前記基準タイミングを含む前記組から前記更新内容を夫々抽出する抽出手段と、
　を備える情報処理装置。」
第３　拒絶の理由
　令和２年１２月９日付けで当審が通知した拒絶理由の要旨は、次のとおりのものである。
［理由１］
　請求項１の「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する管理手段と」との記載では、履歴情報がどのように管理されているのかが不明であるため、当該記載により発明が特定されている請求項１に係る発明は明確でない。
　請求項２ないし４に係る発明は請求項１を引用する発明であることから、請求項１と同様な不備を内在しており、また、請求項５及び６は請求項１と同様な記載を有しているため、請求項２ないし６に係る発明は同様な理由により明確でない。
　よって、この出願は特許法第３６条第６項第２号に規定する要件を満たしていない。
［理由２］
　この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　引用文献１：特開平１０−６９５０８号公報
　引用文献２：特開平１０−２５４７４１号公報
　引用文献３：特開平８−１３７９５０号公報
第４　引用文献の記載及び引用発明
１　引用文献１
　引用文献１（特開平１０−６９５０８号公報）には、図面とともに次の事項が記載されている（なお、下線は当審が付与。以下、同様。）。
（１）「【発明の詳細な説明】
【０００１】
【発明の属する技術分野】この発明は、
複数の各社員に対する社員情報を管理、処理する人事情報処理装置
【０００２】
【従来の技術】近年、会社の人事管理部門でもコンピュータ化が進み、会社内の各社員に対する各種人事情報を人事ファイルとして記憶させておき、それらの情報は必要に応じ取り出せるようになっている。そしてこの人事ファイルに記憶される各人事情報は通常現在時点での各社員における人事情報であって、将来における人事情報を記憶しているわけではなく、将来に予定される新たな人事異動によって各社員の社員配置がどのようになるのかについては、将来予定される人事発令情報のリスト用紙を元にオペレータがディスプレイ上で各種操作を行なうことによって将来の各社員における人事配置予想マップなるものを作成する必要があった。
【０００３】
【発明が解決しようとする課題】上記のようにオペレータ自身が人事発令リストを元に手操作で人事配置予想マップを作成する場合、各社員に対する人事異動の発令日が全て同じであればあまり問題ないが、個々の社員毎に発令日が異なる場合が通常であり、そのような場合は将来のどの時点を基準にするかによって、その人事配置状態が異なるはずであり、上記人事配置予想マップをオペレータが手操作で作成する場合は、その発令日付が何時なのかに注意して作成する必要があり、異なる発令日が多い場合にはミスをおかして誤った人事配置マップを作成してしまう可能性も非常に高かった。
【０００４】本発明の課題は、所望する基準日を基準にした場合の各社員における人事配置情報を簡単に得ることができるようにすることである。」
（２）「【０００６】
【発明の実施の形態】以下、本発明の一実施例を、図１乃至図４を参照して説明する。
図１は本発明の一実施例の人事ファイル処理装置の構成を示すブロック図であり
【０００７】また、１８は、図２に示すように、社員番号をキーとして、社員それぞれの現職情報（所属コード、役職コード、等）や勤務経歴などの人事管理情報が格納されている人事ファイルであり、そのファイル構造は、従来より広く用いられているものと同じである。そして、２０は、発令履歴ファイルであり、図２に示すように、社員番号と発令年月日をキーとして人事発令の履歴情報が蓄積されている。通常の場合、人事ファイル１８には、今日時点の情報が保存されており、発令履歴ファイル２０には、過去の情報と、既に社内で決定されている未来の人事発令情報とが時系列で保存されている。
【０００８】次に、このような構成に於ける動作を説明する。図３は、発令処理の動作フローチャートである。まず、ＣＰＵ１０は、表示部１４にメニュー表示を行い（ステップＳ１１）、
キー入力部１２による発令種別の選択入力を受け付ける（ステップＳ１２）。
【０００９】そして、発令種別「入社」が選択されると、キー入力部１２による社員番号、発令年月日、所属コード、役職コードのデータ入力を受け付け（ステップＳ１３）、それら入力されたデータに発令区分０１を付加して発令レコードを作成し、発令履歴ファイル２０に追加する（ステップＳ１４）。ここで、発令区分は、図２に示すように、０１は入社、０２は移動、０３は昇格をそれぞれ表すものとする。
【００１０】このようにして、発令履歴ファイル２０に新しい発令レコードを追加した後、キー入力部１２によるその他の社員情報の入力を受け付け（ステップＳ１５）、それを社員番号、所属コード、役職コードと組み合わせて社員レコードを作成し、人事ファイル１８に追加する（ステップＳ１６）。
【００１１】また、
発令種別として「移動」や「昇格」が選択されると、人事ファイル１８より全社員レコードを読出して（ステップＳ１７）、表示部１４にリスト表示し（ステップＳ１８）、キー入力部１２による社員番号の選択を受け付ける（ステップＳ１９）。そして、さらに発令年月日、所属コード、役職コード、発令区分のデータ入力を受け付け（ステップＳ２０）、これら入力されたデータにより選択された社員番号の発令レコードを作成して、発令履歴ファイル２０に追加する（ステップＳ２１）
【００１２】次に、人事ファイル１８の更新処理を、図４のフローチャートに従って説明する。まず、
ＣＰＵ１０は、キー入力部１２による基準日の入力を受け付ける（ステップＳ３１）。次に、人事ファイル１８より１社員レコードを読み出し（ステップＳ３２）、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が上記入力された基準日以前で最も近い発令レコードを発令履歴ファイル２０より検索する（ステップＳ３３）。
（３）「【００１７】
【発明の効果】本発明によれば、個々の社員に対して今後新たに発令される移動、昇格等の発令区分による人事異動について、その人事発令情報をその発令日付で特定して記憶しておくようにしたので、将来における任意の時点での更新対象の社員における社員情報を、その将来の時点を特定する基準日を指定することにより、その基準日を基準にした場合での社員情報、即ち発令区分が移動であれば所属情報が変更された社員情報、発令区分が昇格であれば役職情報が変更された社員情報、を直ちに得ることができ、その各情報を出力することにより将来における各種人事予測を行なうことができる。」
（４）図１及び段落【０００６】の記載からは、本発明の一実施例である
人事ファイル処理装置は、全体の制御を行うＣＰＵ、発令種別の選択や各種コード、日付などの入力を行うためのキー入力部、及び、人事発令の履歴情報を蓄積する発令履歴ファイルを備える
（５）図２、段落【０００７】及び段落【００１１】の記載からは、
発令履歴ファイルには、発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報が発令レコードとして蓄積される
　上記（１）〜（５）によれば、引用文献１には次の発明（以下「引用発明」という。）が記載されていると認められる。
「複数の各社員に対する社員情報を管理、処理する人事ファイル処理装置において（段落【０００１】、段落【０００６】）、
　発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報を発令レコードとして蓄積する発令履歴ファイル（図２、段落【０００７】、段落【００１１】）と、
　発令種別として「移動」や「昇格」が選択されると、社員番号、さらに、発令年月日、所属コード、役職コード、発令区分のデータ入力を受け付けるキー入力部（段落【０００８】、段落【００１１】）と、
　キー入力部による基準日の入力を受け付け、人事ファイルより１社員レコードを読み出し、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が入力された基準日以前で最も近い発令レコードを発令履歴ファイルより検索するＣＰＵ（段落【００１２】）と、
　を備える人事ファイル処理装置。」
２　引用文献２
　引用文献２（特開平１０−２５４７４１号公報）には、図面とともに次の事項が記載されている。
（１）「【０００２】
【従来の技術】最近の医療事務システムでは、患者の氏名、生年月日、電話番号等をリレーショナルデータベース化して管理している。図３は、このようなシステムにおける従来のリレーショナルデータベースのテーブルの概念図である。テーブルの各列には、各患者に付与されているユニークなID番号（１、２、３、…）に対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードが保存されている。
【０００３】このようなテーブルに登録されているデータが変更された場合、医療システムでは変更前の状態を患者の履歴情報として保存するようになっている。その方法は、例えば、図３に示す患者ID「１」の電話番号に変更があった場合、患者ID「１」の電話番号のデータ項目には新しい電話番号が登録され、他のデータ項目には元のデータがコピーされた最新情報のレコードを、その登録日付とともにテーブルの最後尾に追加する。その結果、元のレコードをこの患者の履歴情報のレコードとして保存する。従って、データベースを検索した結果、同一の患者のレコードが複数個存在する場合は登録日付を参照し、登録日付が最新のレコードを最新情報、その他を履歴情報と判断している。
【０００４】
【発明が解決しようとする課題】以上のように、従来のデータベースシステムのデータベース管理方法では、データが変更されたデータ項目以外のデータ項目に元のレコードのデータをコピーして最新情報のレコードを作成し、元のレコードを履歴情報として保存するので、データに変更がなかったデータ項目が二重に登録され、無駄な記憶領域を占有してしまう。この無駄な記憶領域は、一部のデータ項目の変更が繰り返されるに従って、比例的に増加する。
【０００５】また、患者のどのデータ項目が現在までどのようなデータで変更されてきたかという履歴を解析する場合、従来のデータベース管理方法では、最新情報のレコードと履歴情報のレコードとの各データ項目を逐一比較しなければどのデータ項目が現在までどのようなデータに変更されてきたかを判別することができないので、履歴の解析が困難である。
【０００６】本発明はこのような問題点を解決するためになされたものであって、
データを変更されたデータ項目だけを履歴情報として保存することにより、無駄な記憶領域を占有しないデータベース管理方法、またどのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴の解析を容易にするデータベース管理方法及びこのデータベース管理方法を実施するデータベースシステムの提供を目的とする。
（２）「【００１２】
【発明の実施の形態】図１は本発明のデータベース管理方法及びデータベースシステムの一例を説明するためのテーブルの概念図である。
第１テーブルの各列には、各患者に付与されているユニークな患者ID（１、２、３、…）に対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別の最新情報のレコードを保存する。
【００１３】
このような最新情報のテーブルに対して、いずれかのデータ項目のデータが変更される場合、第１テーブルにおいて書き換えられるべきデータ項目の元のデータを、元の登録日付とともに履歴情報として別の第２テーブルに保存する。
【００１４】第２テーブルの各列には、患者IDに対応付けて、データが変更されるデータ項目及び元のデータとともに元の登録日付を履歴情報のレコードとして保存する。」
（３）「【００１９】以上の方法を図２に基づいて以下に具体的に説明する。最新情報が格納されているテーブルの、患者ID「１」の電話番号（項目ID「３」）「0584-64-1111」が、1996年11月10日に「0584-64-2222」へ変更された場合、
患者ID「１」及び電話番号の項目ID「３」に、最新のデータ「0584-64-2222」と登録日付「1996-11-10」とを対応付けた最新情報のレコードを作成し、テーブルの最後尾に保存する。
【００２０】
この最新情報の保存によって、データが書き換えられた患者ID「１」及び項目ID「３」の列の元のデータ「0584-64-1111」は患者「三洋太郎」の履歴情報となる。テーブルの各列のレコードの登録日付を参照することで、最新情報のレコードであるか履歴情報のレコードであるかが判別できる。
【００２１】本例の方法によれば、無駄な記憶領域を占有しないという利点の他に、最新情報と履歴情報とを同一のテーブルに保存することにより、最新情報と履歴情報との両方を復元する場合、１つのテーブルを参照すればよいという利点がある。」
　上記（１）ないし（３）によれば、引用文献２には次の事項が記載されている。
「データを変更されたデータ項目だけを履歴情報として保存することにより、無駄な記憶領域を占有せず、またどのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴の解析を容易にすることを目的として（段落【０００６】）、
　各患者に付与されているユニークな患者ＩＤに対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードを保存した第１テーブルに対して、いずれかのデータ項目のデータが変更される場合、第１テーブルにおいて書き換えられるべきデータ項目の元のデータを、患者ＩＤ、項目ＩＤ、変更後の最新のデータ、及び、登録日付からなる最新のレコードを作成し、別の第２テーブルの最後尾に保存することで履歴情報を保存し、どのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴を解析すること（段落【０００６】、段落【００１２】、段落【００１３】、段落【００１９】、段落【００２０】）。」
３　引用文献３
　引用文献３（特開平８−１３７９５０号公報）には、図面とともに次の事項が記載されている。
（１）「【０００４】このように経歴ファイルには人事異動が発令される都度、異動年月日を含んだデータが異動のあった社員毎に１レコード追加作成される。この経歴ファイルを用いて、データ入力装置３３より例えば何年何月何日に本店営業に在籍していた社員を検索するよう入力指示しても、入力年月日と経歴ファイル内データの異動年月日に一致しなければデータ処理装置３２での検索処理が不可能であった。また、例えば本店営業に５年以上在籍した社員を検索するようデータ入力装置３３より入力指示しても、部店Ｃ項目の内容が本店営業→東京→東京→本店営業に変化するようなデータ（以前在籍していた部署に社員が復帰するような場合）であれば、データ処理装置３２での検索処理は不可能であった。このため、経歴ファイルの内容そのままを表示装置３４あるいは図示しないプリンタに出力して、人手により在籍期間または在籍日等を計算していた。
【０００５】
【発明が解決しようとする課題】しかるに、従来の履歴データファイルではデータを、１レコード毎にデータ発生日付で管理していたため、検索条件として複数のデータ項目がある場合、基準日によるデータの復元や本店営業→東京→本店営業とデータ項目が変化する場合に本店営業の内容で何日であるかといった滞留日数の計算が困難となり、従って、データの検索・抽出処理を有効に行えない等の問題点があった。
【０００６】本発明は上記の点に鑑みてなされたもので、データの検索・抽出を有効に行なえる履歴データ処理装置を提供することを目的とする。」
（２）「【００１２】
履歴データファイル部１２は社員の勤務店等が異動日毎に記憶された経歴ファイル１７、社員の職務が異動日毎に記憶された係歴ファイル１８、社員の受けた研修の終了日毎に記憶された研修履歴ファイル１９、社員の性別が格納された社員基本ファイル２０、データ処理部１３で検索された検索結果がファイルされる検索結果ファイル２１等よりなる。
【００１３】図３、図４に履歴データファイル部１２の内容を説明するための図を示す。図３（Ａ）は経歴ファイル１７の内容、図３（Ｂ）は係歴ファイル１８の内容、図３（Ｃ）は研修履歴ファイル１９の内容、図３（Ｄ）は社員基本ファイル２０の内容、図４は検索結果ファイル２１の内容を示す。経歴ファイル１７は図３（Ａ）に示すように社員番号、異動年月日、勤務部店、のデータ項目より構成され、例えば、社員番号（８６１１１１５）番の社員は異動年月日１９８６年４月１日（＝１９８６０４０１）、１９８６年５月１日（＝１９８６０５０１）１９８７年４月１日（＝１９８７０４０１）、は目黒支店、１９８７年８月１日（＝１９８７０８０１）は本店に所属し、その後異動命令がないことを示している。
【００１４】また、係歴ファイル１８は図３（Ｂ）に示すように社員番号、異動年月日、係のデータ項目より構成され、例えば社員番号（８６１１１５）番の社員は異動年月日１９８６年４月１日（＝１９８６０４０１）で融資係、異動年月日１９８６年６月１日（＝１９８６０６０１）で預金係、異動年月日１９８６年８月１日（＝１９８６０８０１）で再び融資係になり、現在に至ることを示している。
【００１５】研修履歴ファイル１９は図３（Ｃ）に示すように社員番号、研修終了日、研修内容のデータ項目より構成され、例えば、社員番号（８０１００１２）番の社員は１９８６年６月１日に、初級行員講座の受講を終了し、１９８７年６月１日に融資市場担当者研修の受講を終了していることを示している。社員基本ファイル２０は図３（Ｄ）に示すように社員番号毎にその社員の性別が格納されている。
【００１６】検索結果ファイル２１は図４に示すように検索・抽出された社員の社員番号、氏名、現在所属の部店、課室、職種、性別、生年月日等の現在の情報、及び検索条件に応じて任意に設定される条件情報より構成され、現在情報は社員番号に応じて履歴データファイル部１２内のファイルより抽出され、ファイルされ、また、検索情報は検索・抽出された社員の検索条件に対応した履歴情報がファイルされ、検索・抽出された社員の現在の情報及び履歴がわかる構成とされている。
【００１７】以上のように、
履歴データファイル部１２の経歴ファイル１７、係歴ファイル１８、研修履歴ファイル１９には異動命令の日付に研修の終了日毎に部店、係、研修名が格納されている。つまり、データが発生した日時毎にデータを管理するいわゆるデータ発生主義的な管理が行なわれている。
【００１８】
データ処理部１３は入力部１４により検索処理が選択されると、検索条件の入力を要求し、表示装置１５に表示する（ステップＳ１-1、Ｓ１-2）。データ処理部１３は入力部１４から検索条件が入力されると、検索条件に応じたデータ検索を実行する（ステップＳ１-3、Ｓ１-4）。
　上記（１）及び（２）によれば、引用文献３には次の事項が記載されている。
「従来の履歴データファイルではデータを、１レコード毎にデータ発生日付で管理していたため、データの検索・抽出処理を有効に行えない等の問題点があったことに鑑みて、データの検索・抽出を有効に行なえることを目的として（段落【０００５】、段落【０００６】）、
　履歴データファイルを、異動命令の日付や研修の終了日毎に社員の勤務店、社員の職務、或いは、社員の受けた研修が格納されている経歴ファイル、係歴ファイル、研修履歴ファイル等より構成し（段落【００１２】、段落【００１７】）、
　データが発生した日時毎にデータを管理するいわゆるデータ発生主義的な管理が行なわれ、入力された検索条件に応じたデータ検索を実行する（段落【００１７】、段落【００１８】）こと。」
第５　理由１（明確性）について
　特許を受けようとする発明が明確であるか否かは、特許請求の範囲の記載だけではなく、願書に添付した明細書の記載及び図面を考慮し、また、当業者の出願当時における技術常識を基礎として、特許請求の範囲の記載が、第三者の利益が不当に害されるほどに不明確であるか否かという観点から判断されるべきである。
　そのため、本願発明に係る特許請求の範囲の記載が、第三者の利益が不当に害されるほどに不明確であるか否かについて、検討する。
　請求項１には、「
前記
独立して
　本願明細書の段落【００２０】〜【００２６】及び図２には情報管理の具体例が記載されているものの、該具体例の記載を参酌しても、「複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する」ことは明示的に開示されていないとともに、「独立して」が如何なる技術事項を意味するものであるのか（例えば、「入力された内容の履歴を示す履歴情報を」「前記複数の項目毎に」「独立して管理する」ことを意味しているのか、或いは、「入力された内容の履歴を示す履歴情報を」、「前記複数の項目毎に」「管理する」するとともに「独立して管理する」ことを意味しているのか、或いは、これ以外の意味であるのか）が不明であることから、請求項１の上記記載では、履歴情報がどのように管理されているのかが不明である。
　このため、上記記載により発明が特定されている請求項１に係る発明は、第三者の利益が不当に害されるほどに不明確である。
　よって、本願は特許法第３６条第６項第２号に規定する要件を満たしていない。
第６　理由２（進歩性）について
１ 対比
　本願発明１と引用発明とを対比すると、次のことがいえる。
（１）引用発明の「人事ファイル処理装置」は、「複数の各社員に対する社員情報を管理、処理する人事ファイル処理装置」であって、「発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報が発令レコードとして蓄積する発令履歴ファイル」を備えることから、「複数の各社員に対する社員情報」は、「発令番号」、「発令年月日」、「発令区分」、「所属コード」、「役職コード」などの複数の項目から構成されているといえる。
　このため、引用発明の「人事ファイル処理装置」は、本願発明１の「複数の項目から構成される情報を管理する情報処理装置」に相当する。
（２）引用発明の「発令履歴ファイル」は、「発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報を発令レコードとして蓄積する発令履歴ファイル」であって、当該「発令レコード」は「発令番号」、「発令年月日」、「発令区分」、「所属コード」、「役職コード」なる複数の項目を有しており、当該「発令履歴ファイル」は当該「発令レコード」を複数の項目毎に管理しているといえる。
　このため、引用発明の「発令履歴ファイル」は、後述の相違点１を除き、「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を」「管理する管理手段」である点で共通する。
（３）引用発明の「キー入力部」は、「発令種別として「移動」や「昇格」が選択されると、社員番号、さらに、発令年月日、所属コード、役職コード、発令区分のデータ入力を受け付けるキー入力部」であって、当該「発令種別として「移動」や「昇格」が選択される」とは「前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合」であるといえ、当該「発令年月日」とは「当該変更の原因となる事象が生じた際の基準となる第１タイミング」であるといえ、当該「発令種別」、「社員番号」、「所属コード」、「役職コード」及び「発令区分」が「前記入力された内容」であるといえる。
　このため、引用発明の「キー入力部」は、「前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合に、当該変更の原因となる事象が生じた際の基準となる第１タイミングと、前記入力された内容との夫々を、基準タイミングと更新内容との夫々として受け付ける第１受付手段」を含む。
（４）引用発明は「入力されたデータにより選択された社員番号の発令レコードを作成して、発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報発令履歴ファイルに追加する」との動作を奏しているところ、当該動作は「前記第１受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加」しているといえるとともに、引用発明は当該動作を奏するための手段を備えているといえる。
　このため、引用発明は、「前記第１受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加する追加手段」を備える。
（５）引用発明は、「キー入力部による基準日の入力を受け付け、人事ファイルより１社員レコードを読み出し、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が入力された基準日以前で最も近い発令レコードを発令履歴ファイルより検索する」との動作を奏しているところ、引用発明の「キー入力部」は基準日の入力を受け付けるものであって、当該「基準日」は「抽出の基準となる、過去から現在のうちの第２タイミング」であるといえる。
　このため、引用発明の「キー入力部」は「抽出の基準となる、過去から現在のうちの第２タイミングを受け付ける第２受付手段」を含む。
（６）引用発明の「ＣＰＵ」は、「キー入力部による基準日の入力を受け付け、人事ファイルより１社員レコードを読み出し、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が入力された基準日以前で最も近い発令レコードを発令履歴ファイルより検索するＣＰＵ」であって、当該「発令年月日が入力された基準日以前で最も近い発令レコード」は「前記第２タイミングの直前の前記基準タイミングを含む前記組から前記更新内容」であるといえる。
　このため、引用発明の「ＣＰＵ」は、後述の相違点１を除き、「前記第２タイミングの直前の前記基準タイミングを含む前記組から前記更新内容を夫々抽出する抽出手段」である点で共通する。
　したがって、本願発明１と引用発明とは、次の点で一致及び相違する。
＜一致点＞
　「複数の項目から構成される情報を管理する情報処理装置において、
　入力された内容の履歴を示す履歴情報を管理する管理手段と、
　前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合に、当該変更の原因となる事象が生じた際の基準となる第１タイミングと、前記入力された内容との夫々を、基準タイミングと更新内容との夫々として受け付ける第１受付手段と、
　前記第１受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加する追加手段と、
　抽出の基準となる、過去から現在のうちの第２タイミングを受け付ける第２受付手段と、
　前記第２タイミングの直前の前記基準タイミングを含む前記組から前記更新内容を夫々抽出する抽出手段と、
　を備える情報処理装置。」
＜相違点１＞
　本願発明１は、「管理手段」が「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理」し、「抽出手段」が「前記複数の項目のうち抽出対象となる１以上の項目毎に」「更新内容を夫々抽出する」ものであるのに対して、引用発明の「管理手段」及び「抽出手段」はこのようにない点。
２　判断
　上記の「第５　理由１（明確性）について」で検討したごとく「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する」なる記載事項は、「独立して」が如何なる技術事項を意味するものであるのかが不明であることから、履歴情報がどのように管理されているのかが不明である。
　このため、上記記載事項について、「入力された内容の履歴を示す履歴情報を」「前記複数の項目毎に」「独立して管理する」との解釈（以下、「解釈１」という。）、及び、「入力された内容の履歴を示す履歴情報を」、「前記複数の項目毎に」「管理する」するとともに「独立して管理する」との解釈（以下、「解釈２」という。）に基づいて判断する。
（１）解釈１に基づく判断
　引用文献２には、「各患者に付与されているユニークな患者ＩＤに対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードを保存した第１テーブルに対して、いずれかのデータ項目のデータが変更される場合、第１テーブルにおいて書き換えられるべきデータ項目の元のデータを、患者ＩＤ、項目ＩＤ、変更後の最新のデータ、及び、登録日付からなる最新のレコードを作成し、別の第２テーブルの最後尾に保存することで履歴情報を保存し、どのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴を解析すること」（以下、「引用文献２記載事項」という。）が記載されている。
　ここで、引用文献２記載事項における、各患者に付与されているユニークな患者ＩＤに対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードの履歴情報として、患者ＩＤ、項目ＩＤ、変更後の最新のデータ、及び、登録日付からなるレコードを保存することは、「入力された内容の履歴を示す履歴情報を」「前記複数の項目毎に」「独立して管理する」ことに他ならず、また、このように管理された履歴情報に対して、どのデータ項目が現在までどのようなデータに変更されてきたかに基づいて解析するならば、「前記複数の項目のうち抽出対象となる１以上の項目毎に」「更新内容を夫々抽出する」ような構成となることは明らかである。
　そして、「無駄な記憶領域を占有せず、またどのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴の解析を容易に」したいということは、引用発明を含めた履歴管理を行う上で一般的に内在する技術的な要求であるから、引用発明に引用文献２記載事項を適用し、「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理」し、「前記複数の項目のうち抽出対象となる１以上の項目毎に」「更新内容を夫々抽出する」ように構成することは、当業者であれば容易になし得るものと認められる。
　また、本願明細書等の記載を参酌しても、本願発明１が期待する効果は引用発明及び引用文献２記載事項が奏する効果であって、該相違点１に基づいて本願発明１に格別な効果を奏しているとも認められない。
　よって、本願発明１は引用発明及び引用文献２記載事項から当業者が容易に発明をすることができたものである。
（２）解釈２に基づく判断
　引用文献３には、「履歴データファイルを、異動命令の日付や研修の終了日毎に社員の勤務店、社員の職務、或いは、社員の受けた研修が格納されている経歴ファイル、係歴ファイル、研修履歴ファイル等より構成し、データが発生した日時毎にデータを管理するいわゆるデータ発生主義的な管理が行なわれ、入力された検索条件に応じたデータ検索を実行すること」（以下、「引用文献３記載事項」という。）が記載されている。
　ここで、引用文献３記載事項における、「履歴データファイルを、異動命令の日付や研修の終了日毎に社員の勤務店、社員の職務、或いは、社員の受けた研修が格納されている経歴ファイル、係歴ファイル、研修履歴ファイル等より構成」することは、「入力された内容の履歴を示す履歴情報を」、「前記複数の項目毎に」「管理する」するとともに「独立して管理する」ことに他ならず、また、このように管理された履歴情報に対して、入力された検索条件に応じたデータ検索を実行するならば、「前記複数の項目のうち抽出対象となる１以上の項目毎に」「更新内容を夫々抽出する」ような構成となることは明らかである。
　そして、引用発明は、履歴データファイルではデータをレコード毎にデータ発生日付で管理する構成となっていることから、「データの検索・抽出処理を有効に行えない等の問題点」を有しているといえ、「データの検索・抽出を有効に行なえる」ようするために、引用発明に引用文献３記載事項を適用し、「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理」し、「前記複数の項目のうち抽出対象となる１以上の項目毎に」「更新内容を夫々抽出する」ように構成することは、当業者であれば容易になし得るものと認められる。
　また、本願明細書等の記載を参酌しても、本願発明１が期待する効果は引用発明及び引用文献３記載事項が奏する効果であって、該相違点１に基づいて本願発明１に格別な効果を奏しているとも認められない。
　よって、本願発明１は引用発明及び引用文献３記載事項から当業者が容易に発明をすることができたものである。
３　小括
　以上のとおりであるから、解釈１及び解釈２の何れであっても、本願発明１は引用発明と引用文献２記載事項又は引用文献３記載事項とから容易に発明をすることができたものである。
第７　むすび
　以上のとおり、本願は特許法第３６条第６項第２号に規定する要件を満たしていないとともに、本願発明１は特許法第２９条第２項の規定により特許を受けることができないから、他の請求項に係る発明について特許法第２９条第２項の規定に対する検討をするまでもなく、本願は拒絶されるべきものである。
　よって、結論のとおり審決する。