【事件の表示】
　特願２０００−３９８２４７「スプレッドシートのセル指定範囲に要素を追加または除去するための方法およびシステム」拒絶査定不服審判事件〔平成１３年　８月１０日出願公開、特開２００１−２１６４６３〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯
　本願は、平成１２年１２月２７日（パリ条約による優先権主張２０００年１月６日、欧州特許庁）の出願であって、平成１５年５月１５日付で拒絶査定がなされ、これに対し、同年７月２５日に拒絶査定に対する審判請求がなされ、さらに、当審において、平成１８年７月２０日付で拒絶理由が通知され、これに対して、平成１９年１月２５日付で手続補正がなされたものである。
　
２．請求項１に係る発明
　本件出願の請求項１に係る発明は、平成１９年１月２５日付の手続補正により補正された請求項１に記載された以下のとおりのものである。
「各々の次元に沿ってセル・アドレスで識別される複数のセルを含む、多次元のスプレッドシートにおいて、セルの与えられたセットの合計値または平均値のような何らかの合計情報を表す範囲合計セルを処理する方法であって、
　関連セル範囲を識別するセル範囲アドレス（４１４）をメモリ上の表（４００）の関連範囲フィールドに、および前記セル範囲アドレス（４１４）の関数である範囲合計セル・アドレス（４１１、４１２、４１３）をメモリ上の表（４００）の行フィールド、列フィールドおよびシートフィールドに、ユーザによる入力により表（４００）上のレコードとして範囲合計セル（４１０）を定義しており、
　前記範囲合計セルに関連する前記セル範囲と共有する行、列およびシートのスプレッドシート要素のいずれかを追加または削除するためのユーザ要求（６０２）に応答して、
　前記ユーザ要求に従い、前記表（４００）の前記範囲合計セルに関連する前記セル範囲の前記セル範囲アドレス（４１４）の対応する関連範囲フィールドを更新するステップ（６０４）と、
　更新された前記セル範囲アドレス（４１４）に従い、前記表（４００）の行フィールド、列フィールドおよびシートフィールドの対応する前記範囲合計セル・アドレス（４１１、４１２、４１３）を更新するステップ（６０５）と、
　前記ユーザ要求に従い、前記スプレッドシート要素を追加または削除するステップと、
　更新された前記範囲合計セル・アドレス（４１１、４１２、４１３）より得られた、前記スプレッドシートの新しい値で指定された新しい位置に前記範囲合計セルを移動するステップ（６１１）と、
　を含む、方法。」
　
３．当審の拒絶理由の概要について
（１）特許法第３６条第６項第２号の規定に関する拒絶理由について
　特許法第３６条第６項第２号の規定に関する拒絶理由（以下「理由１」という。）の概要は、平成１８年７月２０日付で通知された拒絶理由の記載からみて、以下のとおりである。
『本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第６項第２号に規定する要件を満たしていない。  
 　　　　　　　　　　　　　　　　　記 
（中略）
（９）請求項１に「セル範囲アドレス（４１４）の関数である範囲合計セル・アドレス（４１１、４１２、４１３）をメモリ上の表（４００）の行フィールド、列フィールドおよびシートフィールドに記入することにより表（４００）上のレコードとして範囲合計セル（４１０）を定義するステップ（５０９）」とあり、「更新された前記範囲合計セル・アドレス（４１１、４１２、４１３）より得られた、前記スプレッドシートの新しい値で指定された新しい位置に前記範囲合計セルを移動するステップ（６１１）」とあるが、メモリに記憶されているのは、合計セル・アドレスのみであり、関数自体は、記憶されていないから、更新、移動の際に、どのようにして合計セルの新しい値をメモリより得ているのか明確ではない。
（以下省略）』 
　
（２）特許法第３６条第４項の規定に関する拒絶理由について
　特許法第３６条第４項の規定に関する拒絶理由（以下「理由２」という。）の概要は、平成１８年７月２０日付で通知された拒絶理由の記載からみて、以下のとおりである。
『本件出願は、明細書及び図面の記載が下記の点で不備のため、特許法第３６条第４項に規定する要件を満たしていない。  
　　　　　　　　　　　　　　記 
　上記理由１の上記（９）についての明細書第４２，４３段落の記載は、上記理由１の上記（９）と同様の理由で、当業者がその実施をすることができる程度に明確かつ十分に、記載していない。』
　なお、上記（１）で省略した理由１の（５）及び（８）と同様の理由については、上記（１）と同様に省略した。
　
４．当審の拒絶理由に対する審判請求人の主張について
（１）理由１について
　上記理由１に対する審判請求人の主張は、平成１９年１月１５日付の意見書の記載からみて以下のとおりである。
『（以上省略）
（９）関数自体の移動の際にどのようにメモリより得ているかについては、予めメモリに退避したり、またはその都度メモリに瞬間的に退避する（プログラム内でリード処理を行う）方式など当業者には自明の事項で、とくに限定する必要はないと思料します。
（以下省略）』
　
（２）理由２について
　上記理由２に対する審判請求人の主張は、平成１９年１月１５日付の意見書の記載からみて以下のとおりである。
『第００４２段落では、フィールド４１４が更新され（ステップ６０４）、フィールド４１１、４１２、４１３が更新され（ステップ６０５）、新しい位置に移動する（ステップ６１１）旨が記載されており、従って第００４２、００４３段落は、当業者が実施できる程度に明確十分に記載されていると思料します。』
　
５．理由１に対する当審の判断
　請求項１の「関連セル範囲を識別するセル範囲アドレス（４１４）をメモリ上の表（４００）の関連範囲フィールドに、および前記セル範囲アドレス（４１４）の関数である範囲合計セル・アドレス（４１１、４１２、４１３）をメモリ上の表（４００）の行フィールド、列フィールドおよびシートフィールドに、ユーザによる入力により表（４００）上のレコードとして範囲合計セル（４１０）を定義しており」の記載及び「更新された前記範囲合計セル・アドレス（４１１、４１２、４１３）より得られた、前記スプレッドシートの新しい値で指定された新しい位置に前記範囲合計セルを移動するステップ（６１１）」の記載では、「メモリ」に記載されているのは、範囲合計セル・アドレス（４１１、４１２、４１３）のみであり、範囲合計セルの値を決める関数をメモリ等に記憶して退避することが請求項１には記載されているとは認められず、かつ請求項１の記載から自明な事項とも認められない。
　したがって、審判請求人の上記主張を採用することができない。
　そして、範囲合計セルを含むスプレッドシートの要素のいずれかを削除するステップを実行した場合に、その範囲合計セルの関数をメモリ等に記憶して退避していないため、範囲合計セルの関数（計算方法（合計、平均等））の情報が失われ、どのようにして範囲合計セルの更新後の新しい値をメモリから得るのか不明である。
　また、仮に、審判請求人の上記主張のように、範囲合計セルの関数をメモリに退避することが自明であるとしても、請求項１には、退避した関数をどのようにしてスプレッドシートの当該範囲合計セルが該当する更新後の位置のセルに戻すのか具体的に記載されておらず、かつ、請求項１の記載から自明な事項とも認められないので、請求項１の記載では、どのようにして範囲合計セルの更新後の新しい値をメモリから得るのか不明であり、請求人の上記主張を採用することができない。
　したがって、請求項１の記載では、範囲合計セルを含むスプレッドシートの要素のいずれかを削除するステップを実行した場合に、どのようにして範囲合計セルの新しい値をメモリから得るのか不明である。
　
　よって、本件出願の請求項１に係る発明が明確であるとは認められない。
　
６．理由２に対する当審の判断
　請求人の主張の根拠としている段落【００４２】及び【００４３】には、以下の事項が記載されている。
「【００４２】
Ｆ．範囲合計セルを更新する方法
　行、列、およびシートのような要素を削除するときに範囲合計セルを更新するための本発明による方法が、図１４のフローチャート６００にまとめられる。本方法は、従来型セルに適用される通常の方法の拡張として見なすことができ、そして、要素の削除を反映するためにその座標を更新するだけである。本方法は、範囲合計セルのある種の”プリプロセス”に対応しているので、通常の方法の前に呼び出さなければならない。本方法は、次のステップを含む。
・ステップ６０１では、本方法はデフォルトの状態であり、次の処理を始めるためのイベントを待っている。
・ステップ６０２では、スプレッドシート内の要素の削除に伴って従来型セルを更新する通常のルーチンを呼び出す前に、範囲合計セルを更新する方法を実装するルーチンへのコールの結果としてイベントが検出される。
・ステップ６０３では、関連範囲表４００の最初のレコード４１０が選択され、現レコードとなる。
・ステップ６０４では、（フィールド４１４で与えられる）関連範囲の座標が要素の削除を反映するために更新される。例えば、もし、関連範囲が行１０から行２０までと定義され、もし、行１５から行１７までが削除されると、関連範囲フィールド４１４は、このステップの終わりでは行１０から行１７までと定義される。
・ステップ６０５では、フィールド４１１、４１２、および４１３（それぞれに、行、列、およびシート）で与えられる座標が、ステップ６０４の結果として、フィールド４１４より得られた新しい値に従って更新される。例えば、もし、行の定義４１１が関連範囲の最下行になるように指定するならば（関連範囲が行１０から２０までと定義された場合は行２０である）、ステップ６０４の間に、関連範囲が行１０−行１７として再定義されるため、フィールド４１１は、このとき値１７を得る。
・ステップ６０６では、３つのフィールド４１１、４１２、および４１３（それぞれに、行、列、およびシート）がステップ６０５の結果として値が不変であったかどうかをチェックするためにテストが実行される。もし、不変であれば、ステップ６１２に進み、さもなければ、ステップ６０７に進む。
・ステップ６０７では、３つのフィールド４１１、４１２、および４１３（それぞれに、行、列、およびシート）で与えられた値に一致する３つの座標をもつセルが空かどうかをチェックするためにテストが実行される。もし、空であれば、ステップ６１１に進み、さもなければ、ステップ６０８に進む。
・ステップ６０８では、ユーザは、通常のユーザ・インターフェース手段を用いることにより、３つのフィールド４１１、４１２、および４１３（それぞれに、行、列、およびシート）で与えられた値に一致する３つの座標をもつ空でないセルが関連範囲表４００の現レコード４１０に対応する範囲合計セルの内容によって上書きされることを受け入れるかどうかを判断するように促される。
・ステップ６０９では、もし、ユーザが、上述の上書きを受け入れるならば、ステップ６１１に進み、さもなければ、ステップ６１０に進む。
・ステップ６１０では、関連範囲表４００の現レコード４１０が除去される。実際には、これは、範囲合計セルが空でないセルを上書きすることをユーザが拒否した場合に対応し、その場合には、範囲合計セルが消失する。次に、ステップ６１２に進む。
・ステップ６１１では、範囲合計セルは、現在の位置から、ステップ６０５の結果として生じる３つの座標フィールド４１１、４１２、および４１３（それぞれに、行、列、およびシート）より得られた新しい値で指定された新しい位置へ動かされる。
・ステップ６１２では、関連範囲表４００の全てのレコード４１０が処理されたかどうかをチェックするためにテストが実行される。もし、処理済みであれば、さらなるコマンドを処理するために、初めのステップ６０１へ戻り、さもなければ、ステップ６１３に進む。
・ステップ６１３では、現レコードが前のレコードに続くレコードとなるように、関連範囲表４００の中の次のレコード４１０が選択される。次に、新しい現レコードを処理するために、ステップ６０４へ戻る。
【００４３】
　前述の方法に続いて、関連するスプレッドシート要素を削除するための通常の方法が実行されることは理解されよう。そのようなスプレッドシート要素除去の通常の方法の結果として、関連範囲のアドレスと同様に、範囲合計セル・アドレスは更新され、関連範囲表４００のレコード４１０内の情報４１１、４１２、４１３、および４１４もまた更新される。」
　
　以上の発明の詳細な説明の段落【００４２】及び【００４３】の記載について検討すると、ステップ６０３で、関連範囲表（４００）に、範囲合計セルの関連範囲の座標が記載され、ステップ６０４及び６０５で、削除を反映するために、その座標が更新される。
　しかしながら、範囲合計セルの値を計算するための関数をメモリ等に記憶して退避することが記載されておらず、当該事項が、上記記載から自明な事項とも認められないので、発明の詳細な説明の記載には、範囲合計セルを含むスプレッドシート要素のいずれかを削除する際に、範囲合計セルの値を決定する関数をメモリ等に退避することが記載されておらず、かつ発明の詳細な説明の記載から自明な事項とも認められない。
　そして、範囲合計セルを含むスプレッドシートの要素のいずれかを削除するステップを実行した場合に、その範囲合計セルの関数をメモリ等に記憶して退避していないため、範囲合計セルの関数（計算方法（合計、平均等））の情報が失われ、発明の詳細な説明では、どのようにして範囲合計セルの更新後の新しい値をメモリから得るのか不明である。
　また、仮に、範囲合計セルの関数をメモリに退避することが自明であるとしても、退避した関数をどのようにしてスプレッドシートの当該範囲合計セルが該当する更新後の位置のセルに戻すのか具体的に記載されておらず、かつ、上記記載から自明であるとは認められないので、どのようにして範囲合計セルの更新後の新しい値をメモリから得るのかが不明である。
　したがって、発明の詳細な説明の記載では、範囲合計セルを含むスプレッドシートのいずれかを削除するステップを実行した場合に、どのようにして範囲合計セルの新しい値をメモリから得るのか不明である。
　
　よって、本件出願の明細書の発明の詳細な説明が、請求項１に係る発明を当業者が実施できる程度に明確かつ十分に記載されているとは認められず、審判請求人の上記主張を採用することができない。
　
７．まとめ
　上記５．で述べたとおり、本件出願の請求項１に係る発明が明確であるとは認められないので、本件出願は、特許法第３６条第６項第２号に規定する要件を満たしていない。
　また、上記６．で述べたとおり、本件出願の明細書の発明の詳細な説明が、請求項１に係る発明を当業者が実施できる程度に明確かつ十分に記載されているとは認められないので、本件出願は、特許法第３６条第４項に規定する要件を満たしていない。
　よって、結論のとおり審決する。