• ポートフォリオ機能


ポートフォリオを新規に作成して保存
既存のポートフォリオに追加保存

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 特許、登録しない(前置又は当審拒絶理由) G06Q
審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06Q
管理番号 1374468
審判番号 不服2020-13874  
総通号数 259 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2021-07-30 
種別 拒絶査定不服の審決 
審判請求日 2020-10-02 
確定日 2021-05-27 
事件の表示 特願2019-213806「情報処理装置及びプログラム」拒絶査定不服審判事件〔令和 2年 3月12日出願公開、特開2020- 38718〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 第1 手続の経緯
本願は、平成30年11月20日(優先日:平成30年1月30日)に出願した特願2018-217614号の一部を令和元年11月27日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。
令和2年 1月20日 :手続補正書の提出
令和2年 4月 2日付け:拒絶理由通知書
令和2年 6月 3日 :意見書、手続補正書の提出
令和2年 7月28日付け:拒絶査定
令和2年10月 2日 :審判請求書、手続補正書の提出
令和2年12月 9日付け:令和2年10月2日付けの手続補正の却下の決定
令和2年12月 9日付け:拒絶理由通知書(最後)

なお、請求人は、令和2年12月9日付けの拒絶理由通知に対して、意見書又は手続補正書を提出しなかった。


第2 本願発明
令和2年10月2日付けの手続補正は、令和2年12月9日付けの補正の却下の決定により却下されたので、本願の請求項1ないし6に係る発明は、令和2年6月3日付けの手続補正によって補正された特許請求の範囲の請求項1ないし6に記載されたとおりであるところ、請求項1に係る発明(以下、「本願発明1」という。)は以下のとおりである。
「【請求項1】
複数の項目から構成される情報を管理する情報処理装置において、
前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する管理手段と、
前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合に、当該変更の原因となる事象が生じた際の基準となる第1タイミングと、前記入力された内容との夫々を、基準タイミングと更新内容との夫々として受け付ける第1受付手段と、
前記第1受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加する追加手段と、
抽出の基準となる、過去から現在のうちの第2タイミングを受け付ける第2受付手段と、
前記複数の項目のうち抽出対象となる1以上の項目毎に、前記第2タイミングの直前の前記基準タイミングを含む前記組から前記更新内容を夫々抽出する抽出手段と、
を備える情報処理装置。」


第3 拒絶の理由
令和2年12月9日付けで当審が通知した拒絶理由の要旨は、次のとおりのものである。

[理由1]
請求項1の「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する管理手段と」との記載では、履歴情報がどのように管理されているのかが不明であるため、当該記載により発明が特定されている請求項1に係る発明は明確でない。
請求項2ないし4に係る発明は請求項1を引用する発明であることから、請求項1と同様な不備を内在しており、また、請求項5及び6は請求項1と同様な記載を有しているため、請求項2ないし6に係る発明は同様な理由により明確でない。
よって、この出願は特許法第36条第6項第2号に規定する要件を満たしていない。

[理由2]
この出願の下記の請求項に係る発明は、その出願前日本国内又は外国において頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
引用文献1:特開平10-69508号公報
引用文献2:特開平10-254741号公報
引用文献3:特開平8-137950号公報


第4 引用文献の記載及び引用発明
1 引用文献1
引用文献1(特開平10-69508号公報)には、図面とともに次の事項が記載されている(なお、下線は当審が付与。以下、同様。)。

(1)「【発明の詳細な説明】
【0001】
【発明の属する技術分野】この発明は、複数の各社員に対する社員情報を管理、処理する人事情報処理装置に関する。
【0002】
【従来の技術】近年、会社の人事管理部門でもコンピュータ化が進み、会社内の各社員に対する各種人事情報を人事ファイルとして記憶させておき、それらの情報は必要に応じ取り出せるようになっている。そしてこの人事ファイルに記憶される各人事情報は通常現在時点での各社員における人事情報であって、将来における人事情報を記憶しているわけではなく、将来に予定される新たな人事異動によって各社員の社員配置がどのようになるのかについては、将来予定される人事発令情報のリスト用紙を元にオペレータがディスプレイ上で各種操作を行なうことによって将来の各社員における人事配置予想マップなるものを作成する必要があった。
【0003】
【発明が解決しようとする課題】上記のようにオペレータ自身が人事発令リストを元に手操作で人事配置予想マップを作成する場合、各社員に対する人事異動の発令日が全て同じであればあまり問題ないが、個々の社員毎に発令日が異なる場合が通常であり、そのような場合は将来のどの時点を基準にするかによって、その人事配置状態が異なるはずであり、上記人事配置予想マップをオペレータが手操作で作成する場合は、その発令日付が何時なのかに注意して作成する必要があり、異なる発令日が多い場合にはミスをおかして誤った人事配置マップを作成してしまう可能性も非常に高かった。
【0004】本発明の課題は、所望する基準日を基準にした場合の各社員における人事配置情報を簡単に得ることができるようにすることである。」

(2)「【0006】
【発明の実施の形態】以下、本発明の一実施例を、図1乃至図4を参照して説明する。図1は本発明の一実施例の人事ファイル処理装置の構成を示すブロック図であり、同図において、参照番号10は全体の制御を行うCPUである。12は発令種別の選択や各種コード、日付などの入力を行うためのキー入力部であり、14及び16はデータを表示及び印字するための表示部及び印字部である。
【0007】また、18は、図2に示すように、社員番号をキーとして、社員それぞれの現職情報(所属コード、役職コード、等)や勤務経歴などの人事管理情報が格納されている人事ファイルであり、そのファイル構造は、従来より広く用いられているものと同じである。そして、20は、発令履歴ファイルであり、図2に示すように、社員番号と発令年月日をキーとして人事発令の履歴情報が蓄積されている。通常の場合、人事ファイル18には、今日時点の情報が保存されており、発令履歴ファイル20には、過去の情報と、既に社内で決定されている未来の人事発令情報とが時系列で保存されている。
【0008】次に、このような構成に於ける動作を説明する。図3は、発令処理の動作フローチャートである。まず、CPU10は、表示部14にメニュー表示を行い(ステップS11)、キー入力部12による発令種別の選択入力を受け付ける(ステップS12)。
【0009】そして、発令種別「入社」が選択されると、キー入力部12による社員番号、発令年月日、所属コード、役職コードのデータ入力を受け付け(ステップS13)、それら入力されたデータに発令区分"01"を付加して発令レコードを作成し、発令履歴ファイル20に追加する(ステップS14)。ここで、発令区分は、図2に示すように、"01"は入社、"02"は移動、"03"は昇格をそれぞれ表すものとする。
【0010】このようにして、発令履歴ファイル20に新しい発令レコードを追加した後、キー入力部12によるその他の社員情報の入力を受け付け(ステップS15)、それを社員番号、所属コード、役職コードと組み合わせて社員レコードを作成し、人事ファイル18に追加する(ステップS16)。
【0011】また、発令種別として「移動」や「昇格」が選択されると、人事ファイル18より全社員レコードを読出して(ステップS17)、表示部14にリスト表示し(ステップS18)、キー入力部12による社員番号の選択を受け付ける(ステップS19)。そして、さらに発令年月日、所属コード、役職コード、発令区分のデータ入力を受け付け(ステップS20)、これら入力されたデータにより選択された社員番号の発令レコードを作成して、発令履歴ファイル20に追加する(ステップS21)
【0012】次に、人事ファイル18の更新処理を、図4のフローチャートに従って説明する。まず、CPU10は、キー入力部12による基準日の入力を受け付ける(ステップS31)。次に、人事ファイル18より1社員レコードを読み出し(ステップS32)、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が上記入力された基準日以前で最も近い発令レコードを発令履歴ファイル20より検索する(ステップS33)。・・・」

(3)「【0017】
【発明の効果】本発明によれば、個々の社員に対して今後新たに発令される"移動"、"昇格"等の発令区分による人事異動について、その人事発令情報をその発令日付で特定して記憶しておくようにしたので、将来における任意の時点での更新対象の社員における社員情報を、その将来の時点を特定する基準日を指定することにより、その基準日を基準にした場合での社員情報、即ち発令区分が"移動"であれば所属情報が変更された社員情報、発令区分が"昇格"であれば役職情報が変更された社員情報、を直ちに得ることができ、その各情報を出力することにより将来における各種人事予測を行なうことができる。」

(4)図1及び段落【0006】の記載からは、本発明の一実施例である人事ファイル処理装置は、全体の制御を行うCPU、発令種別の選択や各種コード、日付などの入力を行うためのキー入力部、及び、人事発令の履歴情報を蓄積する発令履歴ファイルを備えることが見て取れる。

(5)図2、段落【0007】及び段落【0011】の記載からは、発令履歴ファイルには、発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報が発令レコードとして蓄積されることが見て取れる。

上記(1)?(5)によれば、引用文献1には次の発明(以下「引用発明」という。)が記載されていると認められる。

「複数の各社員に対する社員情報を管理、処理する人事ファイル処理装置において(段落【0001】、段落【0006】)、
発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報を発令レコードとして蓄積する発令履歴ファイル(図2、段落【0007】、段落【0011】)と、
発令種別として「移動」や「昇格」が選択されると、社員番号、さらに、発令年月日、所属コード、役職コード、発令区分のデータ入力を受け付けるキー入力部(段落【0008】、段落【0011】)と、
キー入力部による基準日の入力を受け付け、人事ファイルより1社員レコードを読み出し、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が入力された基準日以前で最も近い発令レコードを発令履歴ファイルより検索するCPU(段落【0012】)と、
を備える人事ファイル処理装置。」

2 引用文献2
引用文献2(特開平10-254741号公報)には、図面とともに次の事項が記載されている。

(1)「【0002】
【従来の技術】最近の医療事務システムでは、患者の氏名、生年月日、電話番号等をリレーショナルデータベース化して管理している。図3は、このようなシステムにおける従来のリレーショナルデータベースのテーブルの概念図である。テーブルの各列には、各患者に付与されているユニークなID番号(1、2、3、…)に対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードが保存されている。
【0003】このようなテーブルに登録されているデータが変更された場合、医療システムでは変更前の状態を患者の履歴情報として保存するようになっている。その方法は、例えば、図3に示す患者ID「1」の電話番号に変更があった場合、患者ID「1」の電話番号のデータ項目には新しい電話番号が登録され、他のデータ項目には元のデータがコピーされた最新情報のレコードを、その登録日付とともにテーブルの最後尾に追加する。その結果、元のレコードをこの患者の履歴情報のレコードとして保存する。従って、データベースを検索した結果、同一の患者のレコードが複数個存在する場合は登録日付を参照し、登録日付が最新のレコードを最新情報、その他を履歴情報と判断している。
【0004】
【発明が解決しようとする課題】以上のように、従来のデータベースシステムのデータベース管理方法では、データが変更されたデータ項目以外のデータ項目に元のレコードのデータをコピーして最新情報のレコードを作成し、元のレコードを履歴情報として保存するので、データに変更がなかったデータ項目が二重に登録され、無駄な記憶領域を占有してしまう。この無駄な記憶領域は、一部のデータ項目の変更が繰り返されるに従って、比例的に増加する。
【0005】また、患者のどのデータ項目が現在までどのようなデータで変更されてきたかという履歴を解析する場合、従来のデータベース管理方法では、最新情報のレコードと履歴情報のレコードとの各データ項目を逐一比較しなければどのデータ項目が現在までどのようなデータに変更されてきたかを判別することができないので、履歴の解析が困難である。
【0006】本発明はこのような問題点を解決するためになされたものであって、データを変更されたデータ項目だけを履歴情報として保存することにより、無駄な記憶領域を占有しないデータベース管理方法、またどのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴の解析を容易にするデータベース管理方法及びこのデータベース管理方法を実施するデータベースシステムの提供を目的とする。」

(2)「【0012】
【発明の実施の形態】図1は本発明のデータベース管理方法及びデータベースシステムの一例を説明するためのテーブルの概念図である。第1テーブルの各列には、各患者に付与されているユニークな患者ID(1、2、3、…)に対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別の最新情報のレコードを保存する。
【0013】このような最新情報のテーブルに対して、いずれかのデータ項目のデータが変更される場合、第1テーブルにおいて書き換えられるべきデータ項目の元のデータを、元の登録日付とともに履歴情報として別の第2テーブルに保存する。その後、第1テーブルのそのデータ項目のデータを新しいデータに書き換えるとともに、登録日付を更新して最新情報のレコードを作成する。
【0014】第2テーブルの各列には、患者IDに対応付けて、データが変更されるデータ項目及び元のデータとともに元の登録日付を履歴情報のレコードとして保存する。」

(3)「【0019】以上の方法を図2に基づいて以下に具体的に説明する。最新情報が格納されているテーブルの、患者ID「1」の電話番号(項目ID「3」)「0584-64-1111」が、1996年11月10日に「0584-64-2222」へ変更された場合、患者ID「1」及び電話番号の項目ID「3」に、最新のデータ「0584-64-2222」と登録日付「1996-11-10」とを対応付けた最新情報のレコードを作成し、テーブルの最後尾に保存する。
【0020】この最新情報の保存によって、データが書き換えられた患者ID「1」及び項目ID「3」の列の元のデータ「0584-64-1111」は患者「三洋太郎」の履歴情報となる。テーブルの各列のレコードの登録日付を参照することで、最新情報のレコードであるか履歴情報のレコードであるかが判別できる。なお、項目IDの代わりに属性名を使用してもよいが、項目IDを使用することで記憶領域の占有はさらに減少する。
【0021】本例の方法によれば、無駄な記憶領域を占有しないという利点の他に、最新情報と履歴情報とを同一のテーブルに保存することにより、最新情報と履歴情報との両方を復元する場合、1つのテーブルを参照すればよいという利点がある。」

上記(1)ないし(3)によれば、引用文献2には次の事項が記載されている。

「データを変更されたデータ項目だけを履歴情報として保存することにより、無駄な記憶領域を占有せず、またどのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴の解析を容易にすることを目的として(段落【0006】)、
各患者に付与されているユニークな患者IDに対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードを保存した第1テーブルに対して、いずれかのデータ項目のデータが変更される場合、第1テーブルにおいて書き換えられるべきデータ項目の元のデータを、患者ID、項目ID、変更後の最新のデータ、及び、登録日付からなる最新のレコードを作成し、別の第2テーブルの最後尾に保存することで履歴情報を保存し、どのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴を解析すること(段落【0006】、段落【0012】、段落【0013】、段落【0019】、段落【0020】)。」

3 引用文献3
引用文献3(特開平8-137950号公報)には、図面とともに次の事項が記載されている。

(1)「【0004】このように経歴ファイルには人事異動が発令される都度、異動年月日を含んだデータが異動のあった社員毎に1レコード追加作成される。この経歴ファイルを用いて、データ入力装置33より例えば何年何月何日に本店営業に在籍していた社員を検索するよう入力指示しても、入力年月日と経歴ファイル内データの異動年月日に一致しなければデータ処理装置32での検索処理が不可能であった。また、例えば本店営業に5年以上在籍した社員を検索するようデータ入力装置33より入力指示しても、部店C項目の内容が本店営業→東京→東京→本店営業に変化するようなデータ(以前在籍していた部署に社員が復帰するような場合)であれば、データ処理装置32での検索処理は不可能であった。このため、経歴ファイルの内容そのままを表示装置34あるいは図示しないプリンタに出力して、人手により在籍期間または在籍日等を計算していた。
【0005】
【発明が解決しようとする課題】しかるに、従来の履歴データファイルではデータを、1レコード毎にデータ発生日付で管理していたため、検索条件として複数のデータ項目がある場合、基準日によるデータの復元や本店営業→東京→本店営業とデータ項目が変化する場合に本店営業の内容で何日であるかといった滞留日数の計算が困難となり、従って、データの検索・抽出処理を有効に行えない等の問題点があった。
【0006】本発明は上記の点に鑑みてなされたもので、データの検索・抽出を有効に行なえる履歴データ処理装置を提供することを目的とする。」

(2)「【0012】履歴データファイル部12は社員の勤務店等が異動日毎に記憶された経歴ファイル17、社員の職務が異動日毎に記憶された係歴ファイル18、社員の受けた研修の終了日毎に記憶された研修履歴ファイル19、社員の性別が格納された社員基本ファイル20、データ処理部13で検索された検索結果がファイルされる検索結果ファイル21等よりなる。
【0013】図3、図4に履歴データファイル部12の内容を説明するための図を示す。図3(A)は経歴ファイル17の内容、図3(B)は係歴ファイル18の内容、図3(C)は研修履歴ファイル19の内容、図3(D)は社員基本ファイル20の内容、図4は検索結果ファイル21の内容を示す。経歴ファイル17は図3(A)に示すように社員番号、異動年月日、勤務部店、のデータ項目より構成され、例えば、社員番号(8611115)番の社員は異動年月日1986年4月1日(=19860401)、1986年5月1日(=19860501)1987年4月1日(=19870401)、は目黒支店、1987年8月1日(=19870801)は本店に所属し、その後異動命令がないことを示している。
【0014】また、係歴ファイル18は図3(B)に示すように社員番号、異動年月日、係のデータ項目より構成され、例えば社員番号(861115)番の社員は異動年月日1986年4月1日(=19860401)で融資係、異動年月日1986年6月1日(=19860601)で預金係、異動年月日1986年8月1日(=19860801)で再び融資係になり、現在に至ることを示している。
【0015】研修履歴ファイル19は図3(C)に示すように社員番号、研修終了日、研修内容のデータ項目より構成され、例えば、社員番号(8010012)番の社員は1986年6月1日に、初級行員講座の受講を終了し、1987年6月1日に融資市場担当者研修の受講を終了していることを示している。社員基本ファイル20は図3(D)に示すように社員番号毎にその社員の性別が格納されている。
【0016】検索結果ファイル21は図4に示すように検索・抽出された社員の社員番号、氏名、現在所属の部店、課室、職種、性別、生年月日等の現在の情報、及び検索条件に応じて任意に設定される条件情報より構成され、現在情報は社員番号に応じて履歴データファイル部12内のファイルより抽出され、ファイルされ、また、検索情報は検索・抽出された社員の検索条件に対応した履歴情報がファイルされ、検索・抽出された社員の現在の情報及び履歴がわかる構成とされている。
【0017】以上のように、履歴データファイル部12の経歴ファイル17、係歴ファイル18、研修履歴ファイル19には異動命令の日付に研修の終了日毎に部店、係、研修名が格納されている。つまり、データが発生した日時毎にデータを管理するいわゆるデータ発生主義的な管理が行なわれている。次に本発明の一実施例の動作を説明する。図5に本発明の一実施例のデータ処理部13の検索動作フローチャートを示す。
【0018】データ処理部13は入力部14により検索処理が選択されると、検索条件の入力を要求し、表示装置15に表示する(ステップS1-1、S1-2)。データ処理部13は入力部14から検索条件が入力されると、検索条件に応じたデータ検索を実行する(ステップS1-3、S1-4)。データ処理部13は後述するような検索・抽出処理により検索条件に応じた社員を経歴、係歴、研修履歴ファイル17、18、19に応じて検索・抽出し、検索・抽出された社員のデータを検索結果ファイル21にファイルすると共に、検索結果ファイル21の内容を編集して表示装置15に表示する(ステップS1-5、S1-6)。」

上記(1)及び(2)によれば、引用文献3には次の事項が記載されている。

「従来の履歴データファイルではデータを、1レコード毎にデータ発生日付で管理していたため、データの検索・抽出処理を有効に行えない等の問題点があったことに鑑みて、データの検索・抽出を有効に行なえることを目的として(段落【0005】、段落【0006】)、
履歴データファイルを、異動命令の日付や研修の終了日毎に社員の勤務店、社員の職務、或いは、社員の受けた研修が格納されている経歴ファイル、係歴ファイル、研修履歴ファイル等より構成し(段落【0012】、段落【0017】)、
データが発生した日時毎にデータを管理するいわゆるデータ発生主義的な管理が行なわれ、入力された検索条件に応じたデータ検索を実行する(段落【0017】、段落【0018】)こと。」


第5 理由1(明確性)について
特許を受けようとする発明が明確であるか否かは、特許請求の範囲の記載だけではなく、願書に添付した明細書の記載及び図面を考慮し、また、当業者の出願当時における技術常識を基礎として、特許請求の範囲の記載が、第三者の利益が不当に害されるほどに不明確であるか否かという観点から判断されるべきである。
そのため、本願発明に係る特許請求の範囲の記載が、第三者の利益が不当に害されるほどに不明確であるか否かについて、検討する。

請求項1には、「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する管理手段と」と記載されている(下線は補正箇所を示し、請求人が付与した。)。
本願明細書の段落【0020】?【0026】及び図2には情報管理の具体例が記載されているものの、該具体例の記載を参酌しても、「複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する」ことは明示的に開示されていないとともに、「独立して」が如何なる技術事項を意味するものであるのか(例えば、「入力された内容の履歴を示す履歴情報を」「前記複数の項目毎に」「独立して管理する」ことを意味しているのか、或いは、「入力された内容の履歴を示す履歴情報を」、「前記複数の項目毎に」「管理する」するとともに「独立して管理する」ことを意味しているのか、或いは、これ以外の意味であるのか)が不明であることから、請求項1の上記記載では、履歴情報がどのように管理されているのかが不明である。
このため、上記記載により発明が特定されている請求項1に係る発明は、第三者の利益が不当に害されるほどに不明確である。

よって、本願は特許法第36条第6項第2号に規定する要件を満たしていない。


第6 理由2(進歩性)について
1 対比
本願発明1と引用発明とを対比すると、次のことがいえる。

(1)引用発明の「人事ファイル処理装置」は、「複数の各社員に対する社員情報を管理、処理する人事ファイル処理装置」であって、「発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報が発令レコードとして蓄積する発令履歴ファイル」を備えることから、「複数の各社員に対する社員情報」は、「発令番号」、「発令年月日」、「発令区分」、「所属コード」、「役職コード」などの複数の項目から構成されているといえる。
このため、引用発明の「人事ファイル処理装置」は、本願発明1の「複数の項目から構成される情報を管理する情報処理装置」に相当する。

(2)引用発明の「発令履歴ファイル」は、「発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報を発令レコードとして蓄積する発令履歴ファイル」であって、当該「発令レコード」は「発令番号」、「発令年月日」、「発令区分」、「所属コード」、「役職コード」なる複数の項目を有しており、当該「発令履歴ファイル」は当該「発令レコード」を複数の項目毎に管理しているといえる。
このため、引用発明の「発令履歴ファイル」は、後述の相違点1を除き、「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を」「管理する管理手段」である点で共通する。

(3)引用発明の「キー入力部」は、「発令種別として「移動」や「昇格」が選択されると、社員番号、さらに、発令年月日、所属コード、役職コード、発令区分のデータ入力を受け付けるキー入力部」であって、当該「発令種別として「移動」や「昇格」が選択される」とは「前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合」であるといえ、当該「発令年月日」とは「当該変更の原因となる事象が生じた際の基準となる第1タイミング」であるといえ、当該「発令種別」、「社員番号」、「所属コード」、「役職コード」及び「発令区分」が「前記入力された内容」であるといえる。
このため、引用発明の「キー入力部」は、「前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合に、当該変更の原因となる事象が生じた際の基準となる第1タイミングと、前記入力された内容との夫々を、基準タイミングと更新内容との夫々として受け付ける第1受付手段」を含む。

(4)引用発明は「入力されたデータにより選択された社員番号の発令レコードを作成して、発令番号と発令年月日をキーとして、発令区分、所属コード、役職コードから構成される人事発令の履歴情報発令履歴ファイルに追加する」との動作を奏しているところ、当該動作は「前記第1受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加」しているといえるとともに、引用発明は当該動作を奏するための手段を備えているといえる。
このため、引用発明は、「前記第1受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加する追加手段」を備える。

(5)引用発明は、「キー入力部による基準日の入力を受け付け、人事ファイルより1社員レコードを読み出し、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が入力された基準日以前で最も近い発令レコードを発令履歴ファイルより検索する」との動作を奏しているところ、引用発明の「キー入力部」は基準日の入力を受け付けるものであって、当該「基準日」は「抽出の基準となる、過去から現在のうちの第2タイミング」であるといえる。
このため、引用発明の「キー入力部」は「抽出の基準となる、過去から現在のうちの第2タイミングを受け付ける第2受付手段」を含む。

(6)引用発明の「CPU」は、「キー入力部による基準日の入力を受け付け、人事ファイルより1社員レコードを読み出し、当該社員レコード中の社員番号より、その社員番号が等しく発令年月日が入力された基準日以前で最も近い発令レコードを発令履歴ファイルより検索するCPU」であって、当該「発令年月日が入力された基準日以前で最も近い発令レコード」は「前記第2タイミングの直前の前記基準タイミングを含む前記組から前記更新内容」であるといえる。
このため、引用発明の「CPU」は、後述の相違点1を除き、「前記第2タイミングの直前の前記基準タイミングを含む前記組から前記更新内容を夫々抽出する抽出手段」である点で共通する。

したがって、本願発明1と引用発明とは、次の点で一致及び相違する。

＜一致点＞
「複数の項目から構成される情報を管理する情報処理装置において、
入力された内容の履歴を示す履歴情報を管理する管理手段と、
前記複数の項目のうち所定項目について変更を行うための入力操作が行われた場合に、当該変更の原因となる事象が生じた際の基準となる第1タイミングと、前記入力された内容との夫々を、基準タイミングと更新内容との夫々として受け付ける第1受付手段と、
前記第1受付手段により受け付けられた前記所定項目についての、前記基準タイミングと前記更新内容との組を、当該所定項目の前記履歴情報に、過去に追加された組を残したまま追加する追加手段と、
抽出の基準となる、過去から現在のうちの第2タイミングを受け付ける第2受付手段と、
前記第2タイミングの直前の前記基準タイミングを含む前記組から前記更新内容を夫々抽出する抽出手段と、
を備える情報処理装置。」

＜相違点1＞
本願発明1は、「管理手段」が「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理」し、「抽出手段」が「前記複数の項目のうち抽出対象となる1以上の項目毎に」「更新内容を夫々抽出する」ものであるのに対して、引用発明の「管理手段」及び「抽出手段」はこのようにない点。

2 判断
上記の「第5 理由1(明確性)について」で検討したごとく「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理する」なる記載事項は、「独立して」が如何なる技術事項を意味するものであるのかが不明であることから、履歴情報がどのように管理されているのかが不明である。
このため、上記記載事項について、「入力された内容の履歴を示す履歴情報を」「前記複数の項目毎に」「独立して管理する」との解釈(以下、「解釈1」という。)、及び、「入力された内容の履歴を示す履歴情報を」、「前記複数の項目毎に」「管理する」するとともに「独立して管理する」との解釈(以下、「解釈2」という。)に基づいて判断する。

(1)解釈1に基づく判断
引用文献2には、「各患者に付与されているユニークな患者IDに対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードを保存した第1テーブルに対して、いずれかのデータ項目のデータが変更される場合、第1テーブルにおいて書き換えられるべきデータ項目の元のデータを、患者ID、項目ID、変更後の最新のデータ、及び、登録日付からなる最新のレコードを作成し、別の第2テーブルの最後尾に保存することで履歴情報を保存し、どのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴を解析すること」(以下、「引用文献2記載事項」という。)が記載されている。
ここで、引用文献2記載事項における、各患者に付与されているユニークな患者IDに対応付けて、患者の氏名、生年月日、電話番号、登録日付等のデータを登録するデータ項目からなる患者別のレコードの履歴情報として、患者ID、項目ID、変更後の最新のデータ、及び、登録日付からなるレコードを保存することは、「入力された内容の履歴を示す履歴情報を」「前記複数の項目毎に」「独立して管理する」ことに他ならず、また、このように管理された履歴情報に対して、どのデータ項目が現在までどのようなデータに変更されてきたかに基づいて解析するならば、「前記複数の項目のうち抽出対象となる1以上の項目毎に」「更新内容を夫々抽出する」ような構成となることは明らかである。
そして、「無駄な記憶領域を占有せず、またどのデータ項目が現在までどのようなデータに変更されてきたかに基づく履歴の解析を容易に」したいということは、引用発明を含めた履歴管理を行う上で一般的に内在する技術的な要求であるから、引用発明に引用文献2記載事項を適用し、「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理」し、「前記複数の項目のうち抽出対象となる1以上の項目毎に」「更新内容を夫々抽出する」ように構成することは、当業者であれば容易になし得るものと認められる。
また、本願明細書等の記載を参酌しても、本願発明1が期待する効果は引用発明及び引用文献2記載事項が奏する効果であって、該相違点1に基づいて本願発明1に格別な効果を奏しているとも認められない。
よって、本願発明1は引用発明及び引用文献2記載事項から当業者が容易に発明をすることができたものである。

(2)解釈2に基づく判断
引用文献3には、「履歴データファイルを、異動命令の日付や研修の終了日毎に社員の勤務店、社員の職務、或いは、社員の受けた研修が格納されている経歴ファイル、係歴ファイル、研修履歴ファイル等より構成し、データが発生した日時毎にデータを管理するいわゆるデータ発生主義的な管理が行なわれ、入力された検索条件に応じたデータ検索を実行すること」(以下、「引用文献3記載事項」という。)が記載されている。
ここで、引用文献3記載事項における、「履歴データファイルを、異動命令の日付や研修の終了日毎に社員の勤務店、社員の職務、或いは、社員の受けた研修が格納されている経歴ファイル、係歴ファイル、研修履歴ファイル等より構成」することは、「入力された内容の履歴を示す履歴情報を」、「前記複数の項目毎に」「管理する」するとともに「独立して管理する」ことに他ならず、また、このように管理された履歴情報に対して、入力された検索条件に応じたデータ検索を実行するならば、「前記複数の項目のうち抽出対象となる1以上の項目毎に」「更新内容を夫々抽出する」ような構成となることは明らかである。
そして、引用発明は、履歴データファイルではデータをレコード毎にデータ発生日付で管理する構成となっていることから、「データの検索・抽出処理を有効に行えない等の問題点」を有しているといえ、「データの検索・抽出を有効に行なえる」ようするために、引用発明に引用文献3記載事項を適用し、「前記複数の項目毎に、入力された内容の履歴を示す履歴情報を独立して管理」し、「前記複数の項目のうち抽出対象となる1以上の項目毎に」「更新内容を夫々抽出する」ように構成することは、当業者であれば容易になし得るものと認められる。
また、本願明細書等の記載を参酌しても、本願発明1が期待する効果は引用発明及び引用文献3記載事項が奏する効果であって、該相違点1に基づいて本願発明1に格別な効果を奏しているとも認められない。
よって、本願発明1は引用発明及び引用文献3記載事項から当業者が容易に発明をすることができたものである。

3 小括
以上のとおりであるから、解釈1及び解釈2の何れであっても、本願発明1は引用発明と引用文献2記載事項又は引用文献3記載事項とから容易に発明をすることができたものである。


第7 むすび
以上のとおり、本願は特許法第36条第6項第2号に規定する要件を満たしていないとともに、本願発明1は特許法第29条第2項の規定により特許を受けることができないから、他の請求項に係る発明について特許法第29条第2項の規定に対する検討をするまでもなく、本願は拒絶されるべきものである。
よって、結論のとおり審決する。

 
審理終結日 2021-03-18 
結審通知日 2021-03-23 
審決日 2021-04-07 
出願番号 特願2019-213806(P2019-213806)
審決分類 P 1 8・ 121- WZ (G06Q)
P 1 8・ 537- WZ (G06Q)
最終処分 不成立  
前審関与審査官 青柳 光代  
特許庁審判長 高瀬 勤
特許庁審判官 後藤 嘉宏
佐藤 聡史
発明の名称 情報処理装置及びプログラム  
代理人 岩池 満  
代理人 菅沼 和弘  

プライバシーポリシー   セキュリティーポリシー   運営会社概要   サービスに関しての問い合わせ