【事件の表示】
　平成　７年特許願第２２３５８２号「状況集計装置及びその方法」拒絶査定不服審判事件〔平成　９年　３月１１日出願公開、特開平　９−　６９０５７〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成７年８月３１日の出願であって、平成１６年４月２８日付けで拒絶査定がなされ、これに対し、同年６月１０日に審判請求がなされ、同年７月１２日に手続補正がなされたものである。
　
２．平成１６年７月１２日付け手続補正についての補正却下の決定
　
［補正却下の決定の結論］
　平成１６年７月１２日付け手続補正を却下する。
　
［理由］
（１）本件補正発明
　本件補正により、特許請求の範囲は、次のとおりに補正された。
　
「【請求項１】　追加可能な複数の機能を有するデータ処理装置の利用状況を集計する状況集計装置において、
　前記機能と該機能の稼動回数を各機能毎に管理する管理テーブルと、
　前記データ処理装置における前記機能の追加を監視する監視手段と、
　前記監視手段による監視結果に対応して前記追加された機能に関する情報を前記管理テーブルに追加するテーブル管理手段と
　を具備することを特徴とする状況集計装置。
　【請求項２】　前記管理テーブルで管理されたデータに基づき課金処理を行う課金処理手段
　を更に具備することを特徴とする請求項１記載の状況集計装置。
　【請求項３】　前記管理テーブルは、ユーザ毎に個別に管理されることを特徴とする請求項１記載の状況集計装置。
　【請求項４】　追加可能な複数の機能を有するデータ処理装置の利用状況を集計する状況集計方法において、
　前記機能と該機能の稼動回数を各機能毎に管理テーブルを用いて管理するとともに、
　前記データ処理装置における前記機能の追加を監視し、
　該監視結果に対応して前記追加された機能に関する情報を前記管理テーブルに追加する
　ことを特徴とする状況集計方法。
　【請求項５】　前記管理テーブルで管理されたデータに基づき課金処理を行うことを特徴とする請求項４記載の状況集計方法。
　【請求項６】　前記管理テーブルは、ユーザ毎に個別に管理されることを特徴とする請求項４記載の状況集計方法。」
　
　上記補正後の請求項１乃至６は、その記載からして補正前の請求項１乃至６のそれぞれに対応したものであって、補正前の請求項１及び４に記載した発明を特定するために必要な事項である、「前記機能」を「前記データ処理装置における前記機能」に限定し、管理テーブルに追加するものを「機能」から「追加された機能に関する情報」に下位概念化するものであるから、本件補正のうち特許請求の範囲に係る部分は、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的としたものに該当する。
　また、本件補正は、明細書の段落【００１８】及び【００２０】も補正しているが、当該補正は、その内容からして、補正後の特許請求の範囲の記載との整合を図ることを目的としたものである。
　よって、全体としてみれば、本件補正は、特許法第１７条の２第４項第２号の特許請求の範囲の減縮を目的としたものに該当する。
　
　そこで、本件補正後の請求項４に記載された発明（以下、「本願補正発明」という。）が特許出願の際独立して特許を受けることができるものであるか（特許法第１７条の２第５項において準用する同法第１２６条第５項の規定に適合するか）について以下検討する。
　
（２）引用発明
　原査定の拒絶の理由に引用され、本願の出願日前である平成３年９月１９日に頒布された刊行物である国際公開第９１／１４２２３号パンフレット（以下「引用文献」という。）には、次の記載がある。
　
（ア）「この発明は、設置場所等の環境に応じて種々な機能が要求されるＰＯＳ（ポイント・オブ・セールス）ターミナル、ＥＣＲ（電子キャッシュ・レジスタ）、ＡＴＭ（オートメイテド・テラー・マシン）等の端末装置、それに要求される機能に応じたアプリケーション・プログラムを作成して端末装置に供給するプログラム作成装置、このプログラム作成装置と上記端末装置とからなるプログラム作成システム、プログラム作成方法、ならびにアプリケーション・プログラムがロードされた端末装置の動作方法に関する。」
（第１頁第６−１５行）
　
（イ）「ＰＯＳターミナル１３の構成は周知であるのでその詳細な説明は割愛するが、最低限必要な事項のみを述べておく。ＰＯＳターミナル１３はＲＯＭとＲＡＭとを備えている。ＲＯＭには常駐プログラムがあらかじめ格納されている。常駐プログラムはＰＯＳターミナルの行う基本的な処理を制御するためのものであり、たとえば入力受付等を処理する入力処理プログラム、アプリケーション・プログラムのロード処理を行なうプログラム、売上登録処理プログラム、レポート作成プログラム、ハードウェアのチェック等のための自己診断プログラム、後述する第３実施例で説明するパッケージ・インタフェース・プログラム等を含む。ＲＡＭにはアプリケーション・プログラム作成装置１０から供給されかつロードされたアプリケーション・プログラムが格納される。
　アプリケーション・プログラムは機能別にパッケージ化されている。これが上述したアプリケーション・パッケージである。アプリケーション・パッケージとして実現される機能には、たとえば…（以下略）」
（第４１頁１８行−第４２頁第１８行）
　
（ウ）「第３図はアプリケーション・プログラム作成装置１０におけるＲＡＭ２３に設定されるメモリ管理テーブルの一例を示すものである。
　メモリ管理テーブルは各顧客において、異なるＰＯＳターミナルＩＤ番号ごとに作成され、メモリ空間管理テーブルとパッケージ・アドレス管理テーブルとから構成される。
　…（中略）…
　パッケージ・アドレス管理テーブルには、ＰＯＳターミナルのＲＡＭに記憶されるすべてのアプリケーション・パッケージについて、それらのＩＤ番号、スタート・アドレスおよびエンド・アドレスが設定される。…（中略）…　このメモリ管理テーブルはアプリケーション・パッケージの削除や追加を行なうときに参照されるとともに更新される。更新されるのはパッケージ・アドレス管理テーブルのみである。」
（第４２頁第１９行−第４４頁第２行）
　
（エ）「第２実施例
　上述した第１実施例ではアプリケーション・プログラム作成装置がＰＯＳターミナルに備えられたＲＡＭにアプリケーション・パッケージを格納できる空きエリアがあるかどうか、およびアプリケーション・パッケージのロード先アドレスを決定する処理を行なっている。
　第２の発明はこのような処理をＰＯＳターミナルが実行するようにしたものである。アプリケーション・プログラム作成装置は、各ＰＯＳターミナルに既にロードされたアプリケーション・パッケージのＩＤ番号のみを管理する。
　このような第２の発明の実施例について第６図から第１０図を参照して説明する。
　この第２実施例においても第１図に示すＰＯＳターミナル・システムおよび第２図に示すアプリケーション・プログラム作成装置の構成がそのままあてはまる。」
（第５２頁第２−１９行）
　
（オ）「第１０図はＰＯＳターミナル１３におけるＣＰＵ３０の処理手順を示している。
　アプリケーション・プログラム作成装置１０から直接に、またはマスタＰＯＳターミナル１３Ａを介して何らかのコマンドを受信すると（ステップＳ５０）、それがロード・コマンドであるか、削除コマンドであるか、終了コマンドであるかが判定される（ステップＳ５１、Ｓ５２、Ｓ５３、Ｓ６６）。
　…（中略）…
　アプリケーション・プログラム作成装置１０から与えられるコマンドがロード・コマンドの場合には、そのロード・コマンドに付随して伝送されてきた１または複数のアプリケーション・パッケージが受信される（ステップＳ５８）。空きエリア管理テーブルを参照することにより空きエリアの容量が受信した１または複数のアプリケーション・パッケージを格納するのに充分であるかどうかが判断される（ステップＳ５９、Ｓ６０）。
　受信した追加すべきアプリケーション・パッケージを格納するのに充分な空きエリアがＲＡＭ３３にあれば（ステップＳ６０でＹＥＳ）、受信したアプリケーション・パッケージが空きエリアに記憶される（ステップＳ６１）。追加すべきアプリケーション・パッケージのロードにより空きエリアが狭くなる。残った空きエリアを示すアドレス・データを用いて空きエリア管理テーブルが更新される（ステップＳ６２）。また、追加的にロードされたアプリケーション・パッケージのＩＤ番号、ならびにそれがロードされている記憶エリアのスタート・アドレスおよびエンド・アドレスがパッケージ・アドレス管理テーブルに書込まれることにより、このテーブルが更新される（ステップＳ６３）。アプリケーション・パッケージの追加的ロード処理が正常に終了したことを示す応答電文がアプリケーション・プログラム作成装置１０に送信される（ステップＳ６４）。」
（第５８頁第４行−第６０頁第８行）
　
（カ）「第５実施例
　上述した第３実施例で明らかにされたように、ＥＣＲまたはＰＯＳターミナル等の端末装置では、アプリケーション・パッケージｉが他のアプリケーション・パッケージｊを呼出し、アプリケーション・インタフェース・プログラムを経て制御を移すことができる。呼出される回数の多い（使用頻度の高い）アプリケーション・パッケージはその端末装置において重要なまたは有用なものである。アプリケーション・パッケージの使用頻度は端末装置の置かれた状況等によって左右されることもある。したがって、アプリケーション・パッケージの呼出された回数を計数することは重要である。アプリケーション・パッケージ伸しよう頻度に関する統計に基づいて、その重要度、利用度の分析が可能となるとともに、必要頻度の低いアプリケーション・パッケージの開発を中止する等の措置をとることも可能となる。」
（第７９頁第１４行−第８０頁第７行）
　
（キ）「第２４図はメモリ管理／実行回数管理テーブルを示すものであり、これはメモリ管理テーブルに実行回数管理テーブルを追加したものである。メモリ管理テーブルは第１５図に示すものと同じであるが、ここでは簡単のためにアプリケーション・パッケージのＩＤ番号とそれに対応しているプログラムのスタート・アドレスとが記憶されている。メモリ管理／実行回数管理テーブルには上記のデータに加えて、アプリケーション・パッケージＩＤ番号に対応してそのアプリケーション・パッケージが呼出された回数が記憶される。」
（第８０頁第２１行−第８１頁第６行）
　
（ク）「アプリケーション・パッケージｉにしたがう処理を実行しているときにアプリケーション・パッケージｊに移るための命令pacall（ＰＩＤ、ａ、ｂ、ｃ）が読出されたときに、制御はアプリケーション・パッケージｉ内のパッケージ・スーパバイザにまず移る。
　第２６図を参照して、まずメモリ管理テーブルが参照され、命令pacallによって呼出すべき（移るべき）アプリケーション・パッケージがあるかどうかがチェックされる（ステップＳ１００）。呼出すべきアプリケーション・パッケージがなければ（ステップＳ１０１でＮＯ）、制御はこのパッケージ・スーパバイザを抜けてアプリケーション・パッケージｉ内のプログラムの元の位置に戻る。
　呼出すべきアプリケーション・パッケージｊがメモリ管理テーブルにあれば、そのパッケージｊのＩＤ番号に対応して実行回数管理テーブルの呼出された回数が１インクレメントされる（ステップＳ１０１、Ｓ１０２）。」
（第８１頁第２０行−第８２頁１３行）
　
　よって、上記（ア）乃至（ク）からして、引用文献には次の発明（以下「引用発明」という。）が記載されている。
　
　追加可能な複数のアプリケーション・パッケージを有するＰＯＳターミナルの各アプリケーション・パッケージが呼出された回数を計数する呼出回数計数方法において、
　前記アプリケーション・パッケージと該アプリケーション・パッケージの呼び出された回数を各アプリケーション・パッケージ毎にメモリ管理テーブルを用いて管理するとともに、
　ＰＯＳターミナルにおいて受信したコマンドがロード・コマンドであるかどうかを判断し、
　該判断結果に対応して、前記追加されたアプリケーション・パッケージのＩＤ番号とアドレスを前記メモリ管理テーブルに追加する
　ことを特徴とする呼出回数計数方法。
　
（３）対比
　本願補正発明と引用発明とを対比すると、引用発明の「アプリケーション・パッケージ」、「ＰＯＳターミナルの各アプリケーション・パッケージが呼出された回数を計数する」、「呼出回数計数方法」、「アプリケーション・パッケージが呼出された回数」、「メモリ管理テーブル」及び「アプリケーション・パッケージのＩＤ番号とアドレス」は、それぞれ本願補正発明の「機能」、「データ処理装置の利用状況を集計する」、「状況集計方法」、「機能の稼働回数」、「管理テーブル」及び「機能に関する情報」に対応している。
　
　よって、両者は、
　
　追加可能な複数の機能を有するデータ処理装置の利用状況を集計する状況集計方法において、
　前記機能と該機能の稼動回数を各機能毎に管理テーブルを用いて管理するとともに、
　追加された機能に関する情報を前記管理テーブルに追加する
　ことを特徴とする状況集計方法。
　
　の点で一致し、以下の点で相違している。
　
［相違点］
　「追加された機能に関する情報を前記管理テーブルに追加する」処理を、本願補正発明は、データ処理装置における機能の追加を監視し、その監視結果に対応して行うのに対して、引用発明では、ＰＯＳターミナルにおいて受信したコマンドがロード・コマンドであるかどうかを判断し、該判断結果に対応して行う点。
　
（４）判断
　以下、上記相違点について検討するに、引用発明では、引用文献１の第１０図を参酌すると、コマンドの受信を繰り返しチェックし（ステップＳ５０）、コマンドを受信するとそれが「ロード・コマンド」であるかどうかを必ず判断している（ステップＳ５２参照）から、「ロード・コマンド」の受信を監視しているに等しく、かつ、該「ロード・コマンド」は、ＰＯＳターミナルにアプリケーション・パッケージ（本願補正発明の「機能」に相当）を追加する指令であるから、「ロード・コマンド」の受信を監視することは、実質的に、ＰＯＳターミナルにおける機能の追加を行う指令を監視しているに等しい。
　また、本願補正発明において、「機能の追加」とは抽象的な表現であり、機能が追加されたこと（過去の事実）であるのか、機能を追加させること（指令）であるのか、具体的に特定されていないから、引用発明のごとく、機能の追加を行う指令をも含んでいる。
　仮に、本願補正発明の「機能の追加」を、機能が追加されたこと（過去の事実）であるように限定的に解釈したとしても、引用文献の第１０図に記載のフロー・チャートでは、ステップＳ６１の「追加パッケージを空きエリアにロード」の後で、「パッケージ・アドレス管理テーブルを更新」（ステップ６３）を行っており、技術的に見れば、アプリケーション・パッケージの追加が完了したことを確認してから、「パッケージ・アドレス管理テーブル」（「メモリ管理テーブル」に含まれるもの）を更新していることは自明であるから、上位概念において、「機能の追加」がなされたことを「監視」する処理が含まれている。また、本願の発明の詳細な説明には、段落【００３５】〜【００３７】に「監視」に係る実施例が記載されているものの、請求項４の記載では、「監視」を何がどのように行うのかについて具体的に特定されておらず、かつ、請求項４に記載された「監視」を、発明の詳細な説明に記載した実施例に対応する技術的な範囲に限定して解釈しなければならない特別な事情も存在しない。つまり、引用発明の「監視」は、引用文献１の第１０図に記載されたように、「機能の追加」の完了を確認的に「監視」をする構成を含むものであるので、当該「監視」に係る構成をもって、引用発明と本願補正発明との差異を認めることができない。
　さらに付言するならば、明細書の段落【００３５】に記載されているように、「能動的監視方式」による監視は本願の出願時における周知技術であるであると認められるから、引用発明において、ロード・コマンドを受信したかどうか、または、追加のパッケージがロードされたかどうかを、周知技術である「能動的監視方式」により積極的に監視をするよう構成することは、当業者が容易に想到し得たものである。
　よって、いずれにしても、上記相違点は格別のものということはできないから、本願補正発明は、引用発明に基いて当業者が容易に発明をすることができたものである。
　
　そして、本願補正発明の作用効果も、引用発明から当業者が容易に予測できる範囲内のものである。
　
（５）請求人の主張
　平成１４年７月１２日付けの手続補正により補正された請求の理由において、請求人は、「換言すれば、第１引用例において、ＰＯＳターミナル１３に対する新しいアプリケーション・パッケージの追加は、アプリケーション・プログラム作成装置１０を介して行われるものであり、この第１引用例の構成を本願発明のようにデータ処理部側で任意に機能を追加を行う構成には適用できない。」と主張している。この主張の趣旨は、本願補正発明では、外部の装置を用いることなく「データ処理部側」（本願図１の「指定機能処理部」及び本願補正発明の「データ処理装置」に相当するものと認められる。）のみで機能を任意に追加することができるということである。
　しかしながら、本願補正発明（請求項４）には、「前記データ処理装置における前記機能の追加を監視し」と記載されているのみであり、「機能」がいかにして「追加」されるのか具体的に特定されていない。また、本願補正発明では、当該「機能の追加」の「監視」を、何がどのように行っているのか何ら特定していないのは、前記（４）で述べたとおりである。さらに、技術常識からすると、「機能」を追加するためには、「機能」を具現化するためのプログラムを外部のハードディスクやホスト装置からロードすることが一般的であるから、本願補正発明を、データ処理部側のみで機能を任意に追加するという態様に限定して解釈することはできない。
　よって、請求人の前記主張は、特許請求の範囲の記載に基づいたものではないから採用しない。
　
（６）小括
　したがって、本願補正発明は、引用発明に基いて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により、特許出願の際独立して特許を受けることができないものである。
　
（７）むすび
　以上のとおり、本件補正は、平成１５年改正前特許法第１７条の２第５項で準用する特許法第１２６条第５項の規定に違反するものであり、特許法第１５９条第１項で読み替えて準用する特許法第５３条第１項の規定により却下すべきものである。
　
３．本願発明について、
（１）本願発明
　平成１６年７月１２日付けの手続補正は上記のとおり却下されたので、本願の請求項４に係る発明（以下、「本願発明」という。）は、平成１５年１月１７日付け手続補正書の特許請求の範囲の請求項４に記載された次のとおりのものである。
　
「追加可能な複数の機能を有するデータ処理装置の利用状況を集計する状況集計方法において、
　前記機能と該機能の稼動回数を各機能毎に管理テーブルを用いて管理するとともに、
　前記機能の追加を監視し、
　該監視結果に対応して前記管理テーブルが管理する機能を追加する
　ことを特徴とする状況集計方法。」
　
（２）引用例
　原査定の拒絶の理由に引用した引用文献、及びその記載事項は、前記「２．（２）」に記載したとおりである。
　
（３）対比・判断
　本願発明は、前記２．で検討した本願補正発明から、「前記機能」の限定事項である「前記データ処理装置における」の構成を省き、管理テーブルに追加するものを「追加された機能に関する情報」から「機能」に上位概念化したものである。
　そうすると、本願発明の構成要件をすべて含み、さらに他の構成要件を付加したものに相当する本願補正発明が、前記「２．（４）」に記載したとおり、引用発明に基いて、当業者が容易に発明することができたものであるから、本願発明も、同様の理由により、引用発明に基いて、当業者が容易に発明することができたものである。
　
（４）むすび
　以上のとおり、本願発明は、引用発明に基いて、当業者が容易に発明することができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　
　よって、結論のとおり審決する。