【事件の表示】
　特願２００２−３８２７７９「コンピュータにおける文字型データを使用しての数値計算」拒絶査定不服審判事件〔平成１６年　６月２４日出願公開、特開２００４−１７８５３９〕について、次のとおり審決する。
【結　論】
　本件審判の請求は、成り立たない。
【理　由】
１．手続の経緯・本願発明
　本願は、平成１４年１１月２８日の出願であって、その請求項１に係る発明（以下、「本願発明」という。）は、特許請求の範囲の請求項１に記載された事項により特定される、以下のとおりのものと認める。
　
【請求項１】
　人が数値として解釈できる、コンピュータ内部で保持する文字列データを、そのまま計算対象の数値として扱い演算する手段。
　
２．刊行物の記載
（１）刊行物１の記載
　平成２０年１２月１２日付けの当審の拒絶理由通知において引用された、「文字列による無限長演算ユニットの製作秘話」、Ｄｅｌｐｈｉマガジン、ＰＳネットワーク、日本、2001.03.01発行、１５号、２４−３７ページ（以下、「刊行物１」という。）には、図面と共に以下の記載がなされている。
　
「　Ｄｅｌｐｈｉに限らず、Ｗｉｎｄｏｗｓ上の開発環境において扱える数値は、一般に３２ｂｉｔ、多くて６４ｂｉｔが限界です。」
（２５ページ「パソコンにおける、アップル社購入の計算」欄）
　
「　どうせならば、桁数制限なしに、そのまま四則演算のできる数値型を作ることはできないものなのでしょうか？桁数が増えれば、そのぶんだけ自動的に長さが延長されてメモリが確保される型、というと、Ｄｅｌｐｈｉでは、ｓｔｒｉｎｇ型が思い当たります。
　数値をｓｔｒｉｎｇで保持しておけば、桁数がどれほど増えようとおそれることはありませんし（＊４）、ｌａｂｅｌやＥｄｉｔに表示することも容易です。
　というような発想でもって、文字列による無限長演算ユニットの製作はスタートしました。」
（２５ページ「そういうわけで、無限桁数演算の可能性を考える」欄）
　
「　まずは、具体的にどんな型でどういう風に操作するかを考えます。
　データの保持についてはｓｔｒｉｎｇ型と決めていますが、ｓｔｒｉｎｇそのままでは味気ないので、ＴＩｎｔＳｔｒ型という型を定義しました。
　つまりｓｔｒｉｎｇ型そのままですが、こうしておくことで、将来何か変更するときに他のソースまで書き換える手間を省くことができます。
　ＴＩｎｔｓｔｒ型はｓｔｒｉｎｇ型そのままですので、Ｉｎｔｓｔｒ［３］という具合にしてアクセスすれば、特定の桁の数字をとってくることができます。しかしながら、図２を見ていただければ分かるように、普通の「桁」の概念と、ｓｔｒｉｎｇ型のｉｎｄｅｘは一致しません。
　そこで、次のような関数を用意しました。
　ｇｅｔｄｉｇｉｔは、ＴＩｎｔｓｔｒ型の数値からＫｅｔａ桁目の数値をとってくる関数です。返り値はＴｄｉｇｉｔとなっていますが、これは
　　Ｔｄｉｇｉｔ　＝　０．．９；
と定義されています。」
（２６ページ「一般的な定義」及び「桁の数値を取り出す」欄）
　
「　ＴＩｎｔＳｔｒ型は独自に計算ルーチンを持っていて、独立して数値を保持しますが、そうはいっても既存の型とやりとりができないと役に立ちません。
　Ｉｎｔ６４の数値をＴＩｎｔｓｔｒに代入したり、ＴＩｎｔＳｔｒ型の数値をＩｎｔ６４として返す関数を作成しました。
　当然、お互い桁あふれが生じない範囲であることが前提です。
　Ｉｎｔ６４型はＩｎｔｅｇｅｒと代入互換性がありますので、普通のｉｎｔｅｇｅｒの数値も、この関数でＴＩｎｔｓｔｒに変換することができます。」
（２７ページ「ＴｉｎｔＳｔｒ型とＩｎｔｅｇｅｒとの変換」欄）
　
「　さて、いよいよ四則演算に入りましょう。
　ＩｎｔｓｔｒＡｄｄはＴＩｎｔｓｔｒ同士の足し算を行う関数です。
　まず、負の数の問題を片づけてしまいましょう。
　Ｎ１とＮ２の正負によっては、足し算のはずが引き算になったり、絶対値の足し算のあと符号を反転したり、というような処理が必要になります。
　符号の問題をここで片づけてしまうことにより、ＩｎｔＳｔｒＡｄｄＰｏｓｉｔｉｖｅ、ＩｎｔＳｔｒＤｅｃＰｏｓｉｔｉｖｅといった関数の中では、引数が正の数であると想定して処理を行うことができます。
　符号の問題を片づけてしまえば、あとは小学校一年生で習った足し算を忠実に実行して行くだけです。
　一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足す、この繰り返しです。
　ｒｅｓｕｌｔはＴＩｎｔｓｔｒ（＝ｓｔｉｒｎｇ型）ですので、ｒｅｓｕｌｔ：＝ＩｎｔｔｏＳｔｒ（ｃａｌｃＲｅｓｕｌｔ　ｍｏｄ　１０）＋ｒｅｓｕｌｔ；は足し算ではなくて文字列の追加になるところに注意してください。」
（２８ページ「足し算」欄、当審注：「ｓｔｉｒｎｇ型」は「ｓｔｒｉｎｇ型」の誤記である。）
　
　２９ページには、「function IntStrAddPositive 」のソースとして次の記載がある。
「function IntStrAddPositive(N1,N2:TintStr):TintStr;{N1+N2}
var
　i,calcResult,N1Length,N2Length:integer;
　Carry:Tdigit;
begin
　result := '';
　N1Length := length(N1);
　N2Length := length(N2);
　Carry := 0;
　
　i := 1;
　while(i<=N1Length)or(i<=N2Length)do
　begin
　　calcResult := getdigit(N1,i)+getdigit(N2,i) + Carry;
　　Carry := calcResult div 10;
　　result := InttoStr(calcResult mod 10) + result;
　　Inc(i);
　end;
　if Carry>0 then result := Inttostr(Carry) + result;
end;　」
　
「　引き算も、足し算同様、まず最初に符号の問題を片づけてしまいます。
　引き算に関しては、Ｎ１よりＮ２が大きいときは負の結果も出てくる可能性に注意してください。
　（−１）−（−２）の答えは＋１ですが、ここでは−（１−２）＝−（−１）＝１という演算を行っています。
　引き算のアルゴリズムは「下の桁から順番に。足りないときは、上の桁から１借りてくる」です。
　処理の都合上、一番上の桁に０が来て「０２３８」のような数になってしまうことがあるため、最後に０を削ることにしました。」
（２９ページ「引き算」欄）
　
「　かけ算もやっぱり、まず符号の処理から入ります。二つの数値の符号さえ見れば結果の符号が分かる分、引き算よりは簡単かと思います。
　で、絶対値同士のかけ算。
　かけ算のアルゴリズムは、筆算を忠実に再現したものになっています。すなわち、Ｎ１に対してＮ２の各桁の数をかけていき、それらを集めたものがかけ算の結果です。ＩｎｔＳｔｒＴｉｍｅ１という関数で、Ｎ１×各桁の数の計算を実行しています。」
（３１ページ「かけ算」欄）
　
「　ｓｔｒｉｎｇ型を使って、桁数制限のない数値演算を行うユニットを作成しました。」
（３７ページ「まとめ」欄）
　
　以上の記載において、以下の事項が認められる。
　
　上記「２８ページ「足し算」欄」及び上記「２９ページ「 function IntStrAddPositive 」のソース」より、足し算では、
　ＴＩｎｔｓｔｒ型のＮ１のｉ桁、Ｎ２のｉ桁、及びＣａｒｒｙの和をｉｎｔｅｇｅｒ型のｃａｌｃＲｅｓｕｌｔに格納し、 
　ｃａｌｃＲｅｓｕｌｔの mod 10 の演算結果をｓｔｒｉｎｇ型のｒｅｓｕｌｔに追加することが、記載されていると認められる。
　
　以上の刊行物１の記載によれば、刊行物１には、次の発明（以下、「刊行物１記載発明」という。）が記載されていると認められる。
　
　数値をｓｔｒｉｎｇ型のＴＩｎｔｓｔｒ型で保持することで、桁数制限のない四則演算をおこなう、Ｗｉｎｄｏｗｓ上のＤｅｌｐｈｉで実現された、文字列による無限長演算ユニットであって、
　ｓｔｒｉｎｇ型のＴＩｎｔｓｔｒ同士の足し算は、一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足すことを繰り返し、ｓｔｒｉｎｇ型のｒｅｓｕｌｔに文字列を追加するものであって、
　ＴＩｎｔｓｔｒ型のＮ１のｉ桁、Ｎ２のｉ桁、及びＣａｒｒｙの和をｉｎｔｅｇｅｒ型のｃａｌｃＲｅｓｕｌｔに格納し、
　ｃａｌｃＲｅｓｕｌｔの mod 10 の演算結果をｓｔｒｉｎｇ型のｒｅｓｕｌｔに追加するものである、ユニット。
　
（２）刊行物２の記載
　同じく、上記拒絶理由通知において引用された、特開平２−４７７８７号公報（以下、「刊行物２」という。）には、以下の記載がなされている。
　
「２．特許請求の範囲
　数字及び記号を含む文字からなる数式を座標値で入力する座標入力手段と、
　該座標入力手段により入力された座標値の集合に基づいて、入力された数字及び記号を含む文字を認識する認識手段と、
　認識された文字の座標値を基に数式として認識される文字列を抽出する抽出手段と、
　前記数式の終結を指示する文字を認識すると前記数式の演算を実行して表示する演算手段とを備えることを特徴とする数式認識装置。」
（１ページ左欄４行〜同欄１４行）
　
「　第１Ａ図において、１は人出力一体の手書き座標入力装置であり、ペン１１とタブレット１２及び液晶デイスプレイ１３とで構成される。タブレット１２及び液晶デイスプレイ１３は、左上を原点とし、Ｘ座標が０〜２５５、Ｙ座標が０〜１２７の範囲を有する座標平面であり、ペン１１でタブレット１２の任意の位置に触れると、その座標値が外部に出力される。また外部から任意の座標値を入力すると、液晶デイスプレィ１３の対応する位置にドツトが表示される。
　２はマイクロコンピュータ等を含む処理ブロックであり、手書き文字認識手段２１と、複数ある数式の中の特定の式に属することを判断する判断手段２２と、数式認識手段２３と、演算手段２４、及び表示制御手段２５とから構成される。手書き文字認識手段２１は、入力部２１から送られてくる数字等の文字の１文字分の座標データを受取り、従来からあるストローク方式等の認識方法によって文字認識を行い、文字コード、文字のｘ，ｙ座標位置文字の大きさ等を求めて判断手段２２に送出する。判断手段２２はこの文字のｘ，ｙ座標値によって表示画面１３に存在する複数の数式の中の特定の式に属することを判別して記憶しておき、文字コード、文字位置、文字の大きさを数式認識手段２３に出力する。
　数式認識手段２３は手書き文字認識手段２１から送られてくる文字コード、文字位置、文字の大きさ等によって数式の認識を行い、整列した文字列のデータを演算手段２４に送り、１文字ずつのデータは表示のために表示制御手段２５に送る。演算手段２４は数式認識手段２３よりの文字列を入力してその数式を計算し、その計算結果を表示制御手段２５に出力する。表示制御手段２５は数式認識手段２３からの数式の文字データと演算手段２４からの計算結果とを入力し、その文字コード、文字位置、文字の大きさを示すデータによって表示ドツト座標データを作成し、液晶デイスプレィ１３に出力して文字を表示する。」
（２ページ右下欄８行〜３ページ右上欄１３行）
　
「　第２図は実施例の数式認識装置の処理の流れを示す処理フローチャートである。
　座標入力部３１は透明電極を縦横に張り巡らせた透明の入力盤で、盤面上を入力ペン１１で圧着することにより、その圧着された部分の座標データが手書き文字認識手段２１に送られる。認識手段２１では座標入力部３１からの座標データを入力すると、その手書き文字の認識を実施し、その認識結果である文字コードや文字位置及び文字の大きさ等のデータを表示制御手段２５に出力する。表示制御手段２５ではそれらのデータを基に表示用のドツトデータを作成し、液晶表示部１３に出力して表示する。
［数式データの説明　（第３図〜第６図）］
　第３図はＲＡＭに記憶している数式データ構造を示す図である。
　ｃｏｄｅ（１）は第１式の１文字目の文字コードを示し、一般的なアスキーコードと文字の大きさを表すコードとからなる２バイトで構成されている。ｘ（１）は１文字目の文字の表示位置のｘ座標を示し、第４図の表示画面で説明すると第１文字“３”のＡ点のｘ座標を示している。ｙ（１）は１文字目“３”のＡ点のｙ座標を示している。ｄｘ（１）は１文字目の文字“３”の横幅を示し、ｘ（１）＋ｄｘ（１）が第４図の文字４１のＢ点のｘ座標である。ｄｙ（１）は１文字目の文字の縦方向の長さを示し、ｙ（１）＋ｄｙ（１）が第４図の文字４１のＢ点のｙ座標を示している。
　ｃｏｄｅ（１），ｘ（１），ｙ（１），ｄｘ（１），ｄｙ（１）はそれぞれ２バイトで構成され、１文字のデータは１０バイトで構成されている。ｄｙ（１）の後には２文字目の文字コードであるｃｏｄｅ（２）が記憶されている。そして、２文字目のｄｙ（２）の後には式終端コード“７ＦＦＦ”が記憶されていて、第１式のデータの終りを示している。そして、この式終端コードの後には、第２式の１文字目の文字コードｃｏｄｅ（３）が記憶されている。このように、式データが記憶されている最後の式のデータの式終端コードの後には、数式終端コード“００００”が記憶されている。」
（３ページ左下欄９行〜４ページ左上欄２行）
　
「　第５図は液晶表示部１３の表示画面の一例を示す図である。
　５１から５３までが第１式の表示文字であり、６０から６３までが第２式の表示文字である。なお、これらのデータは第３図に示したようにＲＡＭ２９に記憶されている。
　第６図は同じく液晶表示部１３に表示された表示画面の一例を示す図であり、第５図のように第２式を入力した結果、この実施例の処理を実行することにより、第２式の計算結果を示す文字列６４と６５“１０”が表示されている。
［数式認識処理　（第７図〜第１０図）］
　第７図はこの実施例における処理を示すフローチャートで、第８図は第７図のステップＳ７１の処理をより詳しく示したフローチャートである。これら制御プログラムはＲＯＭ２８に記憶されており、座標入力部３１より１文字分手書き入力されることにより開始される。
　ステップＳ１で手書きで入力された文字の認識を行い、その結果を基にステップＳ２でその文字が属する数式を決定する。これは第３図に示すようなＲＡＭ２９に記憶されているコードデータ等を基に、入力された文字がどの数式に属するかを決定するものである。
　ステップＳ３ではその決定された数式に対応して第３図のコードデータをＲＡＭ２９に記憶していく。即ち、ある１つの式の属するデータのときは、入力された文字順にコードや座標値等を格納していき、その式の終端が検出されると式終端コードを格納する。そして、ステップＳ４でその認識された数式を表示部１３に表示する。
　ステップＳ５で“＝”が入力されたかを調べ、“＝”が入力されたときはステップＳ６に進み、ＲＡＭ２９に格納されている文字コードやｘ、ｙ、ｄｘ、ｄｙ等によって数式を認識し、ステップＳ７でその文字コードに従って数式を演算する。そして、ステップＳ８でその結果を表示部１３に表示して処理を終了する。」
（４ページ右上欄１３行〜５ページ左上欄２行）
　
　図５には、液晶表示部１３に第１式「３＋３」と、第２式「３＋７＝」とが表示されることが、
　図６には、液晶表示部１３に第２式「３＋３」と、第２式「３＋７＝１０」が表示されることが、それぞれ、図示されている。
　
３．対比　
　本願発明と刊行物１記載発明とを対比すると、刊行物１記載発明の「ｓｔｒｉｎｇ型」が文字列型であることは当業者に明らかであるから、刊行物１記載発明の「ｓｔｒｉｎｇ型のＴＩｎｔｓｔｒ型で保持された数値」は、本願発明の「文字列データ」に相当する。
　刊行物１記載発明の「ｓｔｒｉｎｇ型のＴＩｎｔｓｔｒ型で保持された数値」は、文字列型である点で「人が数値として解釈できる文字列データ」といえる。
　刊行物１記載発明のユニットは、Ｗｉｎｄｏｗｓ上のＤｅｌｐｈｉで実現されるから、刊行物１記載発明の「数値」は「コンピュータ内部で保持される」といえる。
　刊行物１記載発明は、ｓｔｒｉｎｇ型のＴＩｎｔｓｔｒ型で保持された数値の四則演算を行うから、刊行物１記載発明の「数値をｓｔｒｉｎｇ型のＴＩｎｔｓｔｒで保持することで、桁数制限のない四則演算をおこなう、文字列による無限長演算ユニット」は、「文字列データを計算対象の数値として扱い演算する手段」といえる。
　
　すると、本願発明と刊行物１記載発明との一致点及び相違点は、以下のとおりである。
　
＜一致点＞
「人が数値として解釈できる、コンピュータ内部で保持する文字列データを、計算対象の数値として扱い演算する手段。」である点。
　
＜相違点＞
　文字列データの演算が、本願発明では、文字列データを「そのまま」計算対象の数値として扱うのに対して、刊行物１記載発明では、そのようなものか明らかではない点。
　
４．相違点の検討
　本願発明の「文字列データを、そのまま計算対象の数値として扱い演算する手段」について、発明の詳細な説明には、
「　【００１５】
　【発明の実施の形態】
　本発明は、本明細書「請求項１」で「文字列をそのまま数値として扱う手段」としているが、実際にはこの理論をプログラム化して、実際にコンピュータ上で稼動可能とするアプリケーションプログラムを作成することが大きな課題となる。
　　【００１６】
　基本的に作成する必要のあるアプリケーションプログラムは、人からコンピュータに与える式のデータを解釈するプログラムと、解釈された式の内容を加減乗除に振り分け演算を行うための４つのプログラム、計５つとなり、計算の機能をさらに拡張すればそれ以上の数となる。
　　【００１７】
　式のデータの解釈とは、「１２×（３４＋５６）」の文字列を、３４と５６を先に加算して、その演算結果と１２を乗算する等、計算の優先順位や手順を式から読み取ることで、この技術は上記にもあるとおり、既存している。」、
「　【００２０】
　　【実施例】
　本発明の加算の例として、「９７＋３４」の計算を以下に記述する。
　　【００２１】
　このとき、式中の数値「９７」は、２バイトの文字列であり、終端記号が存在すれば、３バイトの文字列である。
　　【００２２】
　文字列データであるゆえに、このときの数値「９７」は、コンピュータは内部データとして「３９３７」（１６進数）と記憶している。
　　【００２３】
　さらに、式中の数値「３４」も２バイトもしくは３バイトであり、記号「＋」は１バイトもしくは２バイトの文字列であり、コンピュータの内部データではそれぞれ「３３３４」（１６進数）「２Ｂ」（１６進数）と記憶している。
　　【００２４】
　　　　　　　　　　　　９７（丸１）
　　　　　　　　　　　　３４（丸２）
　　　　　　　　　＋）１１０（丸３）
　　　　　　　――――――――――――――
　　　　　　　　　　　１３１（丸４）
　　【００２５】
　上記丸１と丸２は文字列データで、演算の対象であり、加算することが目的である。
　　【００２６】
　丸３は桁上がりのために用意されたメモリの臨時割り当て文字列データエリアで、演算子が「＋」と既知であるため必要とする大きさは予想できる。
　　【００２７】
　丸４は計算結果が格納される文字列データエリアで、計算結果の桁数は予想できるため、メモリの臨時割り当ては可能である。
　　【００２８】
　丸４の計算結果は、丸１丸２のそれぞれの桁を加算し、丸３のエリアに桁上がりを記述し、実際には丸１丸２丸３のそれぞれの桁を加算した結果の一桁目を表示している。
　　【００２９】
　このときの計算手段は、それぞれ縦１桁の数値だけを対象として行うため、文字型から整数型へ変換して計算し、必要な結果内容を文字型に変換して丸４のエリアに置いていく方法も考えられる。」（当審注：数字を丸で囲む文字については「丸数字」、例えば「丸１」と表記した。）と記載されているのみで、発明の詳細な説明に、他の具体的な記述は見られない。
　
　一方、刊行物１記載発明の「一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足すことを繰り返し、ｓｔｒｉｎｇ型のｒｅｓｕｌｔに文字列を追加するものであって、ＴＩｎｔｓｔｒ型のＮ１のｉ桁、Ｎ２のｉ桁、及びＣａｒｒｙの和をｉｎｔｅｇｅｒ型のｃａｌｃＲｅｓｕｌｔに格納し、ｃａｌｃＲｅｓｕｌｔの mod 10 の演算結果をｓｔｒｉｎｇ型のｒｅｓｕｌｔに追加することにより、ｓｔｒｉｎｇ型のＴＩｎｔｓｔｒ同士の足し算をする、文字列による無限長演算ユニット」は、本願【００２９】と同じ技術である点で、文字列データをそのまま計算対象の数値として扱い演算している、といえるから、
　刊行物１記載発明の「一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足すことを繰り返し、ｓｔｒｉｎｇ型のｒｅｓｕｌｔに文字列を追加するものであって、ＴＩｎｔｓｔｒ型のＮ１のｉ桁、Ｎ２のｉ桁、及びＣａｒｒｙの和をｉｎｔｅｇｅｒ型のｃａｌｃＲｅｓｕｌｔに格納し、ｃａｌｃＲｅｓｕｌｔの mod 10 の演算結果をｓｔｒｉｎｇ型のｒｅｓｕｌｔに追加することにより、ｓｔｒｉｎｇ型のＴＩｎｔｓｔｒ同士の足し算をする、文字列による無限長演算ユニット」を、文字列データを、そのまま計算対象の数値として扱い演算する手段とすることは、当業者が容易になし得ることである。
　
　そして、本願発明の作用効果も、刊行物１記載発明から当業者が予測できる範囲のものである。
　
５．平成２１年２月１７日付け意見書について
（１）　「▲２▼　式の解釈について」の「本願発明の意図とする全体のレイアウトは、式を解釈する機能が幹で、計算を行なう機能は枝葉です。」との主張について
　この主張に係る「式を解釈する機能」とは、発明の詳細な説明【００１６】の「人からコンピュータに与える式のデータを解釈するプログラム」のことと考えられる。
　
　発明の詳細な説明の
「　　【０００４】
　　【発明が解決しようとする課題】
　ハードウェアによる演算は高速かつ、正確な内容が期待できるが、その数値演算のためのハードウェアの設計段階で数値の桁数に制限が設けられるため、桁数の大きな演算を行う場合に桁落ちが生じる。
　　【０００５】
　コンピュータ内で、計算の対象となる数値データ、もしくは計算途中に算出された数値データに一度桁落ちが生じると、その計算結果における数値の信頼性は大きく損なわれる。
　　【０００６】
　本発明は大きな桁を扱う数値データで、四則演算のうち加算、減算、乗算においては桁落ちの発生しない手法を示す事、除算においては任意の算出桁数を指定することにより、納得のいく計算結果を示す事を最終的な目的としている。」、
「　　【００１４】
　例えば、「９７＋３４」という文字列の記述をコンピュータに与えれば、「９７」と「３４」は数値として解釈が可能であり、間にある「＋」演算子は左右に並ぶ２つの数値を加算するための記号と解釈可能であり、また式そのものの意味を理解するアルゴリズムは既に存在する。」、及び
「　　【００１７】式のデータの解釈とは、「１２×（３４＋５６）」の文字列を、３４と５６を先に加算して、その演算結果と１２を乗算する等、計算の優先順位や手順を式から読み取ることで、この技術は上記にもあるとおり、既存している。」より、
　本願明細書には、発明を解決しようとする課題として、大きな桁を扱う数値データで、加算、減算、乗算においては桁落ちの発生しない事、除算においては任意の算出桁数を指定することにより、納得のいく計算結果を示す事が記載されている。そして、本願明細書には、式を解釈する機能は周知であると記載され、また、式を解釈することの具体的な記載はない。
　よって、「式を解釈する機能が幹で、計算を行なう機能は枝葉です。」という主張は、本願明細書の記載と整合しない。
　
　仮に、請求項１に係る発明を、人からコンピュータに与える式のデータを解釈するプログラムを備える発明と仮定すると（以下、「仮定発明」という。）、仮定発明と、刊行物１記載発明とは、上記「３．対比　＜相違点＞」に係る相違点のほかに、「人からコンピュータに与える式のデータを解釈するプログラム」を備えるのか明らかではない点で相違する。
　刊行物２には、「ペン、タブレット及び液晶ディスプレイとで構成される座標入力装置からの座標データの文字認識を行い、認識結果のアスキーコード（人間が数値として解釈できる文字）をＲＡＭのｃｏｄｅ（ｉ）（ｉ＝１，２，・・・）に順に格納し、“＝”が入力されたときはＲＡＭに格納されている文字コードによって数式（人間が数値として解釈できる、コンピュータ内で保持する文字列）を認識し、その文字コードに従って数式を演算することであって、たとえば数式“３＋７＝”が入力されると、当該数式の演算結果“１０”が表示されること」が記載されており、これは、「人からコンピュータに与える式のデータを解釈すること」といえる。
　そして、刊行物１記載発明に刊行物２を適用して、人からコンピュータに与える式のデータを解釈するプログラムを備えるようにすることは、当業者が容易になし得ることである。
　また、仮定発明の作用効果も、刊行物１記載発明及び刊行物２記載発明から当業者が予測できる範囲のものである。
　
（２）　「審判請求人は「刊行物Ｄｅｌｐｈｉマガジン、２００１年３月１日発行、１５号、２４〜３７ページ」（以下「刊行物Ｄ写し」と記述）を２００９年１月６日現在まで手にした事がありません。さらにすべての号の刊行物Ｄｅｌｐｈｉマガジンを手にしたことがありません。今回特許庁により送付された「刊行物Ｄ写し」に目を通すことで、初めて参照する事になりました。過去に「刊行物Ｄ写し」を審判請求人が読んだと証明するのは、特許庁も審判請求人も双方不可能で、この論争は不毛であると主張します。限りなく不確かな推測の上に、特許法第２９条第２項を適用するのは不合理であると主張します。」旨の主張について
　
　特許法には、次の規定がある。
特許法第２９条第１項
「　産業上利用することができる発明をした者は、次に掲げる発明を除き、その発明について特許を受けることができる。
　…（中略）…
三　特許出願前に日本国内又は外国において、頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となつた発明」
同条第２項
「　特許出願前にその発明の属する技術の分野における通常の知識を有する者が前項各号に掲げる発明に基いて容易に発明をすることができたときは、その発明については、同項の規定にかかわらず、特許を受けることができない。」
　そして、刊行物１は、本願の出願前に頒布された刊行物である。
　したがって、請求人が刊行物１を２００９年１月６日現在まで手にした事がないから、特許法第２９条第２項を適用するのは不合理であるという主張は、採用することができない。
　
（３）　「▲１▼実数を処理する際に小数点の存在をどう扱うのか。」について
　同意見書に「本願明細書に例１から例４までの仕様を具体的に記述することは、同業者を利する結果となるため、避けなければなりません。」とあるように、実数の演算について、請求項はそのような限定をしておらず、さらに、本願明細書に実数を処理することの具体的な記述がないから、「▲１▼実数を処理する際に小数点の存在をどう扱うのか。」の主張は認められない。
　
６．むすび
　以上のとおりであるから、本願発明は、刊行物１記載発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　そして、仮に、請求項１に係る発明を上記「５．（１）」の仮定発明と仮定しても、刊行物１記載発明及び刊行物２記載発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
　したがって、本願は、その他の請求項について検討するまでもなく、拒絶すべきものである。
　よって、結論のとおり審決する。