【事件の表示】
　平成　５年特許願第２８２８９４号「索引順次編成ファイルに対するレコード処理方式」拒絶査定に対する審判事件［平成　７年　６月　２日出願公開、特開平　７−１４１２３９］について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成５年１１月１２日の出願であって、その請求項１に係る発明は、平成１２年１２月２５日付けの手続補正書により補正された明細書及び図面の記載からみて、特許請求の範囲の請求項１に記載されたとおりの次のものと認める。（以下、「本願発明」という。）
「索引順次編成ファイル中の同一キーを持つ複数のレコードのそれぞれについて更新または削除処理を行う索引順次編成ファイルに対するレコード処理方式であって、
　既存レコードの置換または削除時に、置換または削除したいレコードと同一キーを保持する複数のレコードの内の物理的に先頭のレコードに位置づけ、置換または削除したいレコードが当該先頭のレコードから何件目であるかをカウントして前記カウンタに記憶しておき、当該カウンタに記憶したレコードの件数にしたがって置換または削除したいレコードに位置づけ、当該レコードに対して置換または削除処理を行うことを特徴とする索引順次編成ファイルに対するレコード処理方式。」
　
２．引用例
　これに対して、当審において平成１３年１１月１６日付けで通知した拒絶の理由に引用した特開平４−２３６６４１号公報（平成４年８月２５日出願公開、以下「引用例」という。）には、「電子計算機システムにおける索引順編成ファイル複数レコード保守方式」（第２頁左欄第３５〜３６行）に関し、次の記載がなされている。
「【００２３】例えば、図５の索引順編成ファイル“ＲＥｉ”についてレコードＲ１〜Ｒ４のレコード群を保守の対象としようとする場合には、検索キー値として“ａ１”が入力される。
【００２４】次いで、図１において、複数レコード読み込み手段８は、検索キー値入力手段７により入力された検索キー値で補助記憶装置１上の索引順編成ファイルを乱アクセスし、目的とするレコード群の先頭のレコードを読み込み、その後、続くレコードを順次読み込み、検索キー値と比較し、値が異なるまで、すなわち次のレコード群に達するまでレコード群を読み込み、また、読み込んだレコード数を数える。このレコード数は保守の対象が既に存在するレコードであるか新たに追加されるレコードであるかを判断するために用いられる。
【００２５】この複数レコード読み込み手段８の具体的な処理は図３に示すように行われる。すなわち、変数ＯＬＤＳＵに“０”を設定し（ステップ８１）、レコード群の先頭からレコードを１つ読み込む（ステップ８２）。そして、読み込んだレコードの検索キーフィールドの値が検索キー値と同じか否かを判断し（ステップ８３）、同じである場合（ステップ８３のＹＥＳ）には、変数ＯＬＤＳＵに“１”を加え（ステップ８４）、ステップ８２に戻る。また、読み込んだレコードの検索キーフィールドの値が検索キー値と同じでない場合（ステップ８３のＮＯ）には、処理レコード件数として“０”を設定すると共に、レコード数として変数ＯＬＤＳＵの値を設定し（ステップ８５）、処理を終了する。
【００２６】例えば、図５の索引順編成ファイル“ＲＥｉ”について検索キーフィールドをフィールドＡとし、検索キー値を“ａ１”とした場合、レコードＲ１〜Ｒ４が順次に読み込まれ、レコード数は“４”と計数される。
【００２７】次いで、図１において、フィールド入力判断手段９は、複数レコード読み込み手段８で読み込んだレコード数と、画面情報格納手段５に格納されている索引情報および画面フィールド情報とから、今、処理しようとしているレコードがレコード群に新たに追加するレコードか既にあるレコードかを判断した上で、レコード内の各フィールドを端末画面に表示させるだけで入力（変更）を禁止するか、画面より入力させて内容を修正させるかを判断する。
【００２８】このフィールド入力判断手段９の具体的な処理は図４に示すように行われる。すなわち、先ず、フィールドに入力が可能か否かを示すフィールド入力フラグに初期値として“入力”を設定する（ステップ９１）。次いで、処理の対象となる処理レコード番号と複数レコード読み込み手段８で取得したレコード数とを比較判断し（ステップ９２）、処理レコード番号がレコード数より大きい場合（ステップ９２のＮＯ）には、追加の処理であると断定し、そのまま処理を終了する。また、処理レコード番号がレコード数以下である場合（ステップ９２のＹＥＳ）には、既に存在するレコードに対する更新であると断定し、続いて、今処理しているフィールドと索引順編成ファイルの索引キーフィールドとの間に重なりがあるか否かを判断し（ステップ９３）、重なりがある場合（ステップ９３のＹＥＳ）には、修正を禁止するためにフィールド入力フラグに“表示”を設定し（ステップ９４）、処理を終了する。一方、重なりがない場合（ステップ９３のＮＯ）には、そのまま処理を終了する。これらの処理を、各フィールドにつき、同時もしくは順次に行う。
【００２９】例えば、図５の索引順編成ファイル“ＲＥｉ”の場合、レコードＲ１〜Ｒ４が読み込まれている場合、レコードＲ１〜Ｒ４について更新を行う場合にはフィールドＢは索引キーフィールドと重なっているので表示のみ行われて修正は行えないものとされ、新たにレコードを追加する場合にはフィールドＢは入力を行えるものとされる。また、他のフィールドＣ，Ｄ，Ｅについては索引キーフィールドと重なっていないので、表示されると共に修正も行えるものとされる。
【００３０】次いで、図１において、フィールド表示・入力手段１０は、フィールド入力判断手段９により決定された内容に従って、読み込んだレコードの各フィールドを画面に表示させるだけにしたり、画面から入力した値により変更したりという処理を行う。」（第４頁左欄第７行〜右欄第３１行）
　
　上記記載中の段落【００２５】〜【００２６】には、「【００２５】この複数レコード読み込み手段８の具体的な処理は図３に示すように行われる。すなわち、変数ＯＬＤＳＵに“０”を設定し（ステップ８１）、レコード群の先頭からレコードを１つ読み込む（ステップ８２）。そして、読み込んだレコードの検索キーフィールドの値が検索キー値と同じか否かを判断し（ステップ８３）、同じである場合（ステップ８３のＹＥＳ）には、変数ＯＬＤＳＵに“１”を加え（ステップ８４）、ステップ８２に戻る。また、読み込んだレコードの検索キーフィールドの値が検索キー値と同じでない場合（ステップ８３のＮＯ）には、処理レコード件数として“０”を設定すると共に、レコード数として変数ＯＬＤＳＵの値を設定し（ステップ８５）、処理を終了する。
【００２６】例えば、図５の索引順編成ファイル“ＲＥｉ”について検索キーフィールドをフィールドＡとし、検索キー値を“ａ１”とした場合、レコードＲ１〜Ｒ４が順次に読み込まれ、レコード数は“４”と計数される。」とあり、同一検索キー値“ａ１”を保持する複数のレコードＲ１〜Ｒ４の内のどれかを修正しようとしてレコードを読み込む場合、最初に物理的に先頭のレコードＲ１に位置づくものと解される。　
　よって、上記記載から、引用例には、次の発明（以下、「引用例記載の発明」という。）が記載されているものと認められる。
　索引順編成ファイル“ＲＥｉ”中の同一検索キー値“ａ１”を持つ複数のレコードＲ１〜Ｒ４のそれぞれについて更新処理を行う索引順次編成ファイル“ＲＥｉ”に対するレコード処理方式であって、
　既存レコードを修正する際の複数レコード読み込み時に、修正したいレコードと同一検索キー値“ａ１”を保持する複数のレコードＲ１〜Ｒ４の内の物理的に先頭のレコードＲ１に位置づけ、レコードＲ１から順次レコードを読み込み検索キー値“ａ１”を保持するレコード数をカウントし、処理の対象となる処理レコード番号が、検索キー値“ａ１”を保持するレコードの総数以下の場合に、当該レコードに対して修正処理を行う索引順編成ファイルに対するレコード処理方式。
　
３．対比
　本願請求項１に係る発明（以下、「本願発明」という。）と引用例記載の発明とを対比すると、引用例記載の発明における「索引順編成ファイル」、「検索キー値」、は、本願発明における「索引順次編成ファイル」、「キー」、に相当するものであり、また、本願発明における「置換」は、引用例記載の発明における「修正」を行う場合の一手法であると解されるから、本願発明においては、レコードに対して「置換処理」を行っているが、レコードのデータ部分を「置換」して、結局、レコードに対して「修正処理」を行うことには変わりない。
　よって、本願発明と引用例記載の発明とは、
　索引順次編成ファイル中の同一キーを持つ複数のレコードのそれぞれについて更新処理を行う索引順次編成ファイルに対するレコード処理方式であって、
　既存レコードの修正時に、修正対象レコードに対して修正処理を行う索引順次編成ファイルに対するレコード処理方式
である点で一致し、次の点が相違する。
　相違点（１）：本願発明が、「既存レコードの置換または削除時」に対処するものであるのに対し、引用例記載の発明は、既存レコードの修正時に対処するものであるが、既存レコードを置換するとはされておらず、また、削除時についての記載はなされていない点。
　相違点（２）：本願発明においては、「置換または削除したいレコードが先頭のレコードから何件目であるかをカウントしてカウンタに記憶しておき、当該カウンタに記憶したレコードの件数にしたがって置換または削除したいレコードに位置づけ、当該レコードに対して置換または削除処理を行う」のに対し、引用例記載の発明においては、「処理レコード番号」によって修正したいレコードを指定していると読みとれる点。
　
４．当審の判断
　上記相違点（１）、（２）について検討する。
［相違点（１）について］　
　本願発明と引用例記載の発明とは、ともに、索引順次編成ファイルに対するレコード処理方式において、処理対象レコードに対してどのようにアクセスするかということに関する技術の点では共通するものであり、処理対象レコードに対してアクセスさえできれば、その後の処理内容は、「修正」の一手法であると解される「置換」であろうと、また、「修正」とは異なる「削除」であろうと任意に選べる事項である。
　よって、引用例記載の発明を「既存レコードの置換または削除時」に対処するものとすることは、当業者が適宜になし得ることと認められる。
　
［相違点（２）について］
　引用例において、上記段落【００２６】に「レコードＲ１〜Ｒ４が順次に読み込まれ、レコード数は“４”と計数される。」と記載されていて、この計数動作は、上記段落【００２５】に「すなわち、変数ＯＬＤＳＵに“０”を設定し（ステップ８１）、レコード群の先頭からレコードを１つ読み込む（ステップ８２）。そして、読み込んだレコードの検索キーフィールドの値が検索キー値と同じか否かを判断し（ステップ８３）、同じである場合（ステップ８３のＹＥＳ）には、変数ＯＬＤＳＵに“１”を加え（ステップ８４）、ステップ８２に戻る。」と記載されていることから読みとれるように、レコードを１つカウントする毎に変数ＯＬＤＳＵに“１”を加えて行くものであるので、上記「変数ＯＬＤＳＵ」は、レコードＲ１に対しては“１”、レコードＲ２に対しては“２”というように、対応するレコードが先頭のレコードから何件目であるかを示す数字となるということは、当業者にとって明らかである。
　また、引用例において、構成要素としてカウンタを用いるとは明記されていないが、計数動作をするためにカウンタを用いることは、常套手段にすぎない。
　してみれば、引用例記載の発明において、上記「変数ＯＬＤＳＵ」によって、置換または削除したいレコードを特定し、もって置換または削除処理を行うようにし、「置換または削除したいレコードが先頭のレコードから何件目であるかをカウントしてカウンタに記憶しておき、当該カウンタに記憶したレコードの件数にしたがって置換または削除したいレコードに位置づけ、当該レコードに対して置換または削除処理を行う」ようにすることは、当業者が適宜に設計できる事項にすぎないものと認められる。
　
　そして、本願発明の構成によってもたらされる効果も、引用例記載の発明から当業者ならば容易に予測することができる程度のものであって、格別のものとはいえない。
　
　なお、請求人は、平成１４年１月２１日付けの意見書において、引用例の技術は、その［００２４］欄の記載の通り、複数レコード読み込み手段が、検索キー値が同一のレコード群の数を数えて変数ＯＬＤＳＵに記憶し、次にフィールド入力判定手段が、処理の対象となる処理レコード番号と変数ＯＬＤＳＵとを比較してレコードの修正（変数ＯＬＤＳＵが処理レコード番号以下の場合）または登録（変数ＯＬＤＳＵが処理レコード番号より大きい場合）を行うというもので、あくまで処理対象レコードをどのように処理（修正または登録）するかを決定するための技術であって、変数ＯＬＤＳＵは検索キー値が同一のレコード群の総数を示すもので、処理対象のレコードに位置づけるためのものではないのに対し、本願発明は、置換または削除したいレコードが先頭のレコードから何件目であるかをカウンタに記憶し、当該カウンタに記憶したレコードの件数のレコードに位置づけ、当該レコードに置換または削除処理を行うというもので、どのレコードを処理の対象にするのかを決定するための技術であって、カウンタは、処理対象のレコードを示すもので、キーが同一のレコード群の総数を示すものではない旨の主張をしている。
　しかしながら、上記相違点（２）で既に検討したように、引用例記載の発明において、上記のようにすることは、当業者が適宜に設計できる事項にすぎないものと認められるから、意見書における請求人の主張を採用することはできない。
　
５．むすび
　したがって、本願発明は、引用例記載の発明に基いて、当業者が容易に発明をすることができたものであるので、特許法第２９条第２項の規定により特許を受けることができない。
　よって、結論のとおり審決する。