• ポートフォリオ機能


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

  • この表をプリントする
PDF PDFをダウンロード
審決分類 審判 査定不服 2項進歩性 特許、登録しない(前置又は当審拒絶理由) G06F
管理番号 1214192
審判番号 不服2006-6851  
総通号数 125 
発行国 日本国特許庁(JP) 
公報種別 特許審決公報 
発行日 2010-05-28 
種別 拒絶査定不服の審決 
審判請求日 2006-03-13 
確定日 2010-04-23 
事件の表示 特願2002-382779「コンピュータにおける文字型データを使用しての数値計算」拒絶査定不服審判事件〔平成16年 6月24日出願公開、特開2004-178539〕について、次のとおり審決する。 
結論 本件審判の請求は、成り立たない。 
理由 1.手続の経緯・本願発明
本願は、平成14年11月28日の出願であって、その請求項1に係る発明(以下、「本願発明」という。)は、特許請求の範囲の請求項1に記載された事項により特定される、以下のとおりのものと認める。

【請求項1】
人が数値として解釈できる、コンピュータ内部で保持する文字列データを、そのまま計算対象の数値として扱い演算する手段。

2.刊行物の記載
(1)刊行物1の記載
平成20年12月12日付けの当審の拒絶理由通知において引用された、「文字列による無限長演算ユニットの製作秘話」、Delｐhiマガジン、PSネットワーク、日本、2001.03.01発行、15号、24-37ページ(以下、「刊行物1」という。)には、図面と共に以下の記載がなされている。

「 Delｐhiに限らず、Windｏｗｓ上の開発環境において扱える数値は、一般に32biｔ、多くて64biｔが限界です。」
(25ページ「パソコンにおける、アップル社購入の計算」欄)

「 どうせならば、桁数制限なしに、そのまま四則演算のできる数値型を作ることはできないものなのでしょうか?桁数が増えれば、そのぶんだけ自動的に長さが延長されてメモリが確保される型、というと、Delｐhiでは、ｓｔｒing型が思い当たります。
数値をｓｔｒingで保持しておけば、桁数がどれほど増えようとおそれることはありませんし(*4)、labelやEdiｔに表示することも容易です。
というような発想でもって、文字列による無限長演算ユニットの製作はスタートしました。」
(25ページ「そういうわけで、無限桁数演算の可能性を考える」欄)

「 まずは、具体的にどんな型でどういう風に操作するかを考えます。
データの保持についてはｓｔｒing型と決めていますが、ｓｔｒingそのままでは味気ないので、TInｔSｔｒ型という型を定義しました。
つまりｓｔｒing型そのままですが、こうしておくことで、将来何か変更するときに他のソースまで書き換える手間を省くことができます。
TInｔｓｔｒ型はｓｔｒing型そのままですので、Inｔｓｔｒ[3]という具合にしてアクセスすれば、特定の桁の数字をとってくることができます。しかしながら、図2を見ていただければ分かるように、普通の「桁」の概念と、ｓｔｒing型のindeｘは一致しません。
そこで、次のような関数を用意しました。
geｔdigiｔは、TInｔｓｔｒ型の数値からKeｔa桁目の数値をとってくる関数です。返り値はTdigiｔとなっていますが、これは
Tdigiｔ = 0..9;
と定義されています。」
(26ページ「一般的な定義」及び「桁の数値を取り出す」欄)

「 TInｔSｔｒ型は独自に計算ルーチンを持っていて、独立して数値を保持しますが、そうはいっても既存の型とやりとりができないと役に立ちません。
Inｔ64の数値をTInｔｓｔｒに代入したり、TInｔSｔｒ型の数値をInｔ64として返す関数を作成しました。
当然、お互い桁あふれが生じない範囲であることが前提です。
Inｔ64型はInｔegeｒと代入互換性がありますので、普通のinｔegeｒの数値も、この関数でTInｔｓｔｒに変換することができます。」
(27ページ「TinｔSｔｒ型とInｔegeｒとの変換」欄)

「 さて、いよいよ四則演算に入りましょう。
InｔｓｔｒAddはTInｔｓｔｒ同士の足し算を行う関数です。
まず、負の数の問題を片づけてしまいましょう。
N1とN2の正負によっては、足し算のはずが引き算になったり、絶対値の足し算のあと符号を反転したり、というような処理が必要になります。
符号の問題をここで片づけてしまうことにより、InｔSｔｒAddPｏｓiｔiｖe、InｔSｔｒDecPｏｓiｔiｖeといった関数の中では、引数が正の数であると想定して処理を行うことができます。
符号の問題を片づけてしまえば、あとは小学校一年生で習った足し算を忠実に実行して行くだけです。
一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足す、この繰り返しです。
ｒeｓｕlｔはTInｔｓｔｒ(=ｓｔiｒng型)ですので、ｒeｓｕlｔ:=InｔｔｏSｔｒ(calcReｓｕlｔ mｏd 10)+ｒeｓｕlｔ;は足し算ではなくて文字列の追加になるところに注意してください。」
(28ページ「足し算」欄、当審注:「ｓｔiｒng型」は「ｓｔｒing型」の誤記である。)

29ページには、「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; 」

「 引き算も、足し算同様、まず最初に符号の問題を片づけてしまいます。
引き算に関しては、N1よりN2が大きいときは負の結果も出てくる可能性に注意してください。
(-1)-(-2)の答えは+1ですが、ここでは-(1-2)=-(-1)=1という演算を行っています。
引き算のアルゴリズムは「下の桁から順番に。足りないときは、上の桁から1借りてくる」です。
処理の都合上、一番上の桁に0が来て「0238」のような数になってしまうことがあるため、最後に0を削ることにしました。」
(29ページ「引き算」欄)

「 かけ算もやっぱり、まず符号の処理から入ります。二つの数値の符号さえ見れば結果の符号が分かる分、引き算よりは簡単かと思います。
で、絶対値同士のかけ算。
かけ算のアルゴリズムは、筆算を忠実に再現したものになっています。すなわち、N1に対してN2の各桁の数をかけていき、それらを集めたものがかけ算の結果です。InｔSｔｒTime1という関数で、N1×各桁の数の計算を実行しています。」
(31ページ「かけ算」欄)

「 ｓｔｒing型を使って、桁数制限のない数値演算を行うユニットを作成しました。」
(37ページ「まとめ」欄)

以上の記載において、以下の事項が認められる。

上記「28ページ「足し算」欄」及び上記「29ページ「 function IntStrAddPositive 」のソース」より、足し算では、
TInｔｓｔｒ型のN1のi桁、N2のi桁、及びCaｒｒｙの和をinｔegeｒ型のcalcReｓｕlｔに格納し、
calcReｓｕlｔの mod 10 の演算結果をｓｔｒing型のｒeｓｕlｔに追加することが、記載されていると認められる。

以上の刊行物1の記載によれば、刊行物1には、次の発明(以下、「刊行物1記載発明」という。)が記載されていると認められる。

数値をｓｔｒing型のTInｔｓｔｒ型で保持することで、桁数制限のない四則演算をおこなう、Windｏｗｓ上のDelｐhiで実現された、文字列による無限長演算ユニットであって、
ｓｔｒing型のTInｔｓｔｒ同士の足し算は、一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足すことを繰り返し、ｓｔｒing型のｒeｓｕlｔに文字列を追加するものであって、
TInｔｓｔｒ型のN1のi桁、N2のi桁、及びCaｒｒｙの和をinｔegeｒ型のcalcReｓｕlｔに格納し、
calcReｓｕlｔの mod 10 の演算結果をｓｔｒing型のｒeｓｕlｔに追加するものである、ユニット。

(2)刊行物2の記載
同じく、上記拒絶理由通知において引用された、特開平2-47787号公報(以下、「刊行物2」という。)には、以下の記載がなされている。

「2.特許請求の範囲
数字及び記号を含む文字からなる数式を座標値で入力する座標入力手段と、
該座標入力手段により入力された座標値の集合に基づいて、入力された数字及び記号を含む文字を認識する認識手段と、
認識された文字の座標値を基に数式として認識される文字列を抽出する抽出手段と、
前記数式の終結を指示する文字を認識すると前記数式の演算を実行して表示する演算手段とを備えることを特徴とする数式認識装置。」
(1ページ左欄4行?同欄14行)

「 第1A図において、1は人出力一体の手書き座標入力装置であり、ペン11とタブレット12及び液晶デイスプレイ13とで構成される。タブレット12及び液晶デイスプレイ13は、左上を原点とし、X座標が0?255、Y座標が0?127の範囲を有する座標平面であり、ペン11でタブレット12の任意の位置に触れると、その座標値が外部に出力される。また外部から任意の座標値を入力すると、液晶デイスプレィ13の対応する位置にドツトが表示される。
2はマイクロコンピュータ等を含む処理ブロックであり、手書き文字認識手段21と、複数ある数式の中の特定の式に属することを判断する判断手段22と、数式認識手段23と、演算手段24、及び表示制御手段25とから構成される。手書き文字認識手段21は、入力部21から送られてくる数字等の文字の1文字分の座標データを受取り、従来からあるストローク方式等の認識方法によって文字認識を行い、文字コード、文字のｘ,ｙ座標位置文字の大きさ等を求めて判断手段22に送出する。判断手段22はこの文字のｘ,ｙ座標値によって表示画面13に存在する複数の数式の中の特定の式に属することを判別して記憶しておき、文字コード、文字位置、文字の大きさを数式認識手段23に出力する。
数式認識手段23は手書き文字認識手段21から送られてくる文字コード、文字位置、文字の大きさ等によって数式の認識を行い、整列した文字列のデータを演算手段24に送り、1文字ずつのデータは表示のために表示制御手段25に送る。演算手段24は数式認識手段23よりの文字列を入力してその数式を計算し、その計算結果を表示制御手段25に出力する。表示制御手段25は数式認識手段23からの数式の文字データと演算手段24からの計算結果とを入力し、その文字コード、文字位置、文字の大きさを示すデータによって表示ドツト座標データを作成し、液晶デイスプレィ13に出力して文字を表示する。」
(2ページ右下欄8行?3ページ右上欄13行)

「 第2図は実施例の数式認識装置の処理の流れを示す処理フローチャートである。
座標入力部31は透明電極を縦横に張り巡らせた透明の入力盤で、盤面上を入力ペン11で圧着することにより、その圧着された部分の座標データが手書き文字認識手段21に送られる。認識手段21では座標入力部31からの座標データを入力すると、その手書き文字の認識を実施し、その認識結果である文字コードや文字位置及び文字の大きさ等のデータを表示制御手段25に出力する。表示制御手段25ではそれらのデータを基に表示用のドツトデータを作成し、液晶表示部13に出力して表示する。
[数式データの説明 (第3図?第6図)]
第3図はRAMに記憶している数式データ構造を示す図である。
cｏde(1)は第1式の1文字目の文字コードを示し、一般的なアスキーコードと文字の大きさを表すコードとからなる2バイトで構成されている。ｘ(1)は1文字目の文字の表示位置のｘ座標を示し、第4図の表示画面で説明すると第1文字“3”のA点のｘ座標を示している。ｙ(1)は1文字目“3”のA点のｙ座標を示している。dｘ(1)は1文字目の文字“3”の横幅を示し、ｘ(1)+dｘ(1)が第4図の文字41のB点のｘ座標である。dｙ(1)は1文字目の文字の縦方向の長さを示し、ｙ(1)+dｙ(1)が第4図の文字41のB点のｙ座標を示している。
cｏde(1),ｘ(1),ｙ(1),dｘ(1),dｙ(1)はそれぞれ2バイトで構成され、1文字のデータは10バイトで構成されている。dｙ(1)の後には2文字目の文字コードであるcｏde(2)が記憶されている。そして、2文字目のdｙ(2)の後には式終端コード“7FFF”が記憶されていて、第1式のデータの終りを示している。そして、この式終端コードの後には、第2式の1文字目の文字コードcｏde(3)が記憶されている。このように、式データが記憶されている最後の式のデータの式終端コードの後には、数式終端コード“0000”が記憶されている。」
(3ページ左下欄9行?4ページ左上欄2行)

「 第5図は液晶表示部13の表示画面の一例を示す図である。
51から53までが第1式の表示文字であり、60から63までが第2式の表示文字である。なお、これらのデータは第3図に示したようにRAM29に記憶されている。
第6図は同じく液晶表示部13に表示された表示画面の一例を示す図であり、第5図のように第2式を入力した結果、この実施例の処理を実行することにより、第2式の計算結果を示す文字列64と65“10”が表示されている。
[数式認識処理 (第7図?第10図)]
第7図はこの実施例における処理を示すフローチャートで、第8図は第7図のステップS71の処理をより詳しく示したフローチャートである。これら制御プログラムはROM28に記憶されており、座標入力部31より1文字分手書き入力されることにより開始される。
ステップS1で手書きで入力された文字の認識を行い、その結果を基にステップS2でその文字が属する数式を決定する。これは第3図に示すようなRAM29に記憶されているコードデータ等を基に、入力された文字がどの数式に属するかを決定するものである。
ステップS3ではその決定された数式に対応して第3図のコードデータをRAM29に記憶していく。即ち、ある1つの式の属するデータのときは、入力された文字順にコードや座標値等を格納していき、その式の終端が検出されると式終端コードを格納する。そして、ステップS4でその認識された数式を表示部13に表示する。
ステップS5で“=”が入力されたかを調べ、“=”が入力されたときはステップS6に進み、RAM29に格納されている文字コードやｘ、ｙ、dｘ、dｙ等によって数式を認識し、ステップS7でその文字コードに従って数式を演算する。そして、ステップS8でその結果を表示部13に表示して処理を終了する。」
(4ページ右上欄13行?5ページ左上欄2行)

図5には、液晶表示部13に第1式「3+3」と、第2式「3+7=」とが表示されることが、
図6には、液晶表示部13に第2式「3+3」と、第2式「3+7=10」が表示されることが、それぞれ、図示されている。

3.対比
本願発明と刊行物1記載発明とを対比すると、刊行物1記載発明の「ｓｔｒing型」が文字列型であることは当業者に明らかであるから、刊行物1記載発明の「ｓｔｒing型のTInｔｓｔｒ型で保持された数値」は、本願発明の「文字列データ」に相当する。
刊行物1記載発明の「ｓｔｒing型のTInｔｓｔｒ型で保持された数値」は、文字列型である点で「人が数値として解釈できる文字列データ」といえる。
刊行物1記載発明のユニットは、Windｏｗｓ上のDelｐhiで実現されるから、刊行物1記載発明の「数値」は「コンピュータ内部で保持される」といえる。
刊行物1記載発明は、ｓｔｒing型のTInｔｓｔｒ型で保持された数値の四則演算を行うから、刊行物1記載発明の「数値をｓｔｒing型のTInｔｓｔｒで保持することで、桁数制限のない四則演算をおこなう、文字列による無限長演算ユニット」は、「文字列データを計算対象の数値として扱い演算する手段」といえる。

すると、本願発明と刊行物1記載発明との一致点及び相違点は、以下のとおりである。

＜一致点＞
「人が数値として解釈できる、コンピュータ内部で保持する文字列データを、計算対象の数値として扱い演算する手段。」である点。

＜相違点＞
文字列データの演算が、本願発明では、文字列データを「そのまま」計算対象の数値として扱うのに対して、刊行物1記載発明では、そのようなものか明らかではない点。

4.相違点の検討
本願発明の「文字列データを、そのまま計算対象の数値として扱い演算する手段」について、発明の詳細な説明には、
「 【0015】
【発明の実施の形態】
本発明は、本明細書「請求項1」で「文字列をそのまま数値として扱う手段」としているが、実際にはこの理論をプログラム化して、実際にコンピュータ上で稼動可能とするアプリケーションプログラムを作成することが大きな課題となる。
【0016】
基本的に作成する必要のあるアプリケーションプログラムは、人からコンピュータに与える式のデータを解釈するプログラムと、解釈された式の内容を加減乗除に振り分け演算を行うための4つのプログラム、計5つとなり、計算の機能をさらに拡張すればそれ以上の数となる。
【0017】
式のデータの解釈とは、「12×(34+56)」の文字列を、34と56を先に加算して、その演算結果と12を乗算する等、計算の優先順位や手順を式から読み取ることで、この技術は上記にもあるとおり、既存している。」、
「 【0020】
【実施例】
本発明の加算の例として、「97+34」の計算を以下に記述する。
【0021】
このとき、式中の数値「97」は、2バイトの文字列であり、終端記号が存在すれば、3バイトの文字列である。
【0022】
文字列データであるゆえに、このときの数値「97」は、コンピュータは内部データとして「3937」(16進数)と記憶している。
【0023】
さらに、式中の数値「34」も2バイトもしくは3バイトであり、記号「+」は1バイトもしくは2バイトの文字列であり、コンピュータの内部データではそれぞれ「3334」(16進数)「2B」(16進数)と記憶している。
【0024】
97(丸1)
34(丸2)
+)110(丸3)
??????????????
131(丸4)
【0025】
上記丸1と丸2は文字列データで、演算の対象であり、加算することが目的である。
【0026】
丸3は桁上がりのために用意されたメモリの臨時割り当て文字列データエリアで、演算子が「+」と既知であるため必要とする大きさは予想できる。
【0027】
丸4は計算結果が格納される文字列データエリアで、計算結果の桁数は予想できるため、メモリの臨時割り当ては可能である。
【0028】
丸4の計算結果は、丸1丸2のそれぞれの桁を加算し、丸3のエリアに桁上がりを記述し、実際には丸1丸2丸3のそれぞれの桁を加算した結果の一桁目を表示している。
【0029】
このときの計算手段は、それぞれ縦1桁の数値だけを対象として行うため、文字型から整数型へ変換して計算し、必要な結果内容を文字型に変換して丸4のエリアに置いていく方法も考えられる。」(当審注:数字を丸で囲む文字については「丸数字」、例えば「丸1」と表記した。)と記載されているのみで、発明の詳細な説明に、他の具体的な記述は見られない。

一方、刊行物1記載発明の「一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足すことを繰り返し、ｓｔｒing型のｒeｓｕlｔに文字列を追加するものであって、TInｔｓｔｒ型のN1のi桁、N2のi桁、及びCaｒｒｙの和をinｔegeｒ型のcalcReｓｕlｔに格納し、calcReｓｕlｔの mod 10 の演算結果をｓｔｒing型のｒeｓｕlｔに追加することにより、ｓｔｒing型のTInｔｓｔｒ同士の足し算をする、文字列による無限長演算ユニット」は、本願【0029】と同じ技術である点で、文字列データをそのまま計算対象の数値として扱い演算している、といえるから、
刊行物1記載発明の「一番下の位から、各桁の数値を足して、繰り上がりの数があれば覚えておいて、次の桁に足すことを繰り返し、ｓｔｒing型のｒeｓｕlｔに文字列を追加するものであって、TInｔｓｔｒ型のN1のi桁、N2のi桁、及びCaｒｒｙの和をinｔegeｒ型のcalcReｓｕlｔに格納し、calcReｓｕlｔの mod 10 の演算結果をｓｔｒing型のｒeｓｕlｔに追加することにより、ｓｔｒing型のTInｔｓｔｒ同士の足し算をする、文字列による無限長演算ユニット」を、文字列データを、そのまま計算対象の数値として扱い演算する手段とすることは、当業者が容易になし得ることである。

そして、本願発明の作用効果も、刊行物1記載発明から当業者が予測できる範囲のものである。

5.平成21年2月17日付け意見書について
(1) 「▲2▼ 式の解釈について」の「本願発明の意図とする全体のレイアウトは、式を解釈する機能が幹で、計算を行なう機能は枝葉です。」との主張について
この主張に係る「式を解釈する機能」とは、発明の詳細な説明【0016】の「人からコンピュータに与える式のデータを解釈するプログラム」のことと考えられる。

発明の詳細な説明の
「 【0004】
【発明が解決しようとする課題】
ハードウェアによる演算は高速かつ、正確な内容が期待できるが、その数値演算のためのハードウェアの設計段階で数値の桁数に制限が設けられるため、桁数の大きな演算を行う場合に桁落ちが生じる。
【0005】
コンピュータ内で、計算の対象となる数値データ、もしくは計算途中に算出された数値データに一度桁落ちが生じると、その計算結果における数値の信頼性は大きく損なわれる。
【0006】
本発明は大きな桁を扱う数値データで、四則演算のうち加算、減算、乗算においては桁落ちの発生しない手法を示す事、除算においては任意の算出桁数を指定することにより、納得のいく計算結果を示す事を最終的な目的としている。」、
「 【0014】
例えば、「97+34」という文字列の記述をコンピュータに与えれば、「97」と「34」は数値として解釈が可能であり、間にある「+」演算子は左右に並ぶ2つの数値を加算するための記号と解釈可能であり、また式そのものの意味を理解するアルゴリズムは既に存在する。」、及び
「 【0017】式のデータの解釈とは、「12×(34+56)」の文字列を、34と56を先に加算して、その演算結果と12を乗算する等、計算の優先順位や手順を式から読み取ることで、この技術は上記にもあるとおり、既存している。」より、
本願明細書には、発明を解決しようとする課題として、大きな桁を扱う数値データで、加算、減算、乗算においては桁落ちの発生しない事、除算においては任意の算出桁数を指定することにより、納得のいく計算結果を示す事が記載されている。そして、本願明細書には、式を解釈する機能は周知であると記載され、また、式を解釈することの具体的な記載はない。
よって、「式を解釈する機能が幹で、計算を行なう機能は枝葉です。」という主張は、本願明細書の記載と整合しない。

仮に、請求項1に係る発明を、人からコンピュータに与える式のデータを解釈するプログラムを備える発明と仮定すると(以下、「仮定発明」という。)、仮定発明と、刊行物1記載発明とは、上記「3.対比 ＜相違点＞」に係る相違点のほかに、「人からコンピュータに与える式のデータを解釈するプログラム」を備えるのか明らかではない点で相違する。
刊行物2には、「ペン、タブレット及び液晶ディスプレイとで構成される座標入力装置からの座標データの文字認識を行い、認識結果のアスキーコード(人間が数値として解釈できる文字)をRAMのcｏde(i)(i=1,2,・・・)に順に格納し、“=”が入力されたときはRAMに格納されている文字コードによって数式(人間が数値として解釈できる、コンピュータ内で保持する文字列)を認識し、その文字コードに従って数式を演算することであって、たとえば数式“3+7=”が入力されると、当該数式の演算結果“10”が表示されること」が記載されており、これは、「人からコンピュータに与える式のデータを解釈すること」といえる。
そして、刊行物1記載発明に刊行物2を適用して、人からコンピュータに与える式のデータを解釈するプログラムを備えるようにすることは、当業者が容易になし得ることである。
また、仮定発明の作用効果も、刊行物1記載発明及び刊行物2記載発明から当業者が予測できる範囲のものである。

(2) 「審判請求人は「刊行物Delｐhiマガジン、2001年3月1日発行、15号、24?37ページ」(以下「刊行物D写し」と記述)を2009年1月6日現在まで手にした事がありません。さらにすべての号の刊行物Delｐhiマガジンを手にしたことがありません。今回特許庁により送付された「刊行物D写し」に目を通すことで、初めて参照する事になりました。過去に「刊行物D写し」を審判請求人が読んだと証明するのは、特許庁も審判請求人も双方不可能で、この論争は不毛であると主張します。限りなく不確かな推測の上に、特許法第29条第2項を適用するのは不合理であると主張します。」旨の主張について

特許法には、次の規定がある。
特許法第29条第1項
「 産業上利用することができる発明をした者は、次に掲げる発明を除き、その発明について特許を受けることができる。
…(中略)…
三 特許出願前に日本国内又は外国において、頒布された刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となつた発明」
同条第2項
「 特許出願前にその発明の属する技術の分野における通常の知識を有する者が前項各号に掲げる発明に基いて容易に発明をすることができたときは、その発明については、同項の規定にかかわらず、特許を受けることができない。」
そして、刊行物1は、本願の出願前に頒布された刊行物である。
したがって、請求人が刊行物1を2009年1月6日現在まで手にした事がないから、特許法第29条第2項を適用するのは不合理であるという主張は、採用することができない。

(3) 「▲1▼実数を処理する際に小数点の存在をどう扱うのか。」について
同意見書に「本願明細書に例1から例4までの仕様を具体的に記述することは、同業者を利する結果となるため、避けなければなりません。」とあるように、実数の演算について、請求項はそのような限定をしておらず、さらに、本願明細書に実数を処理することの具体的な記述がないから、「▲1▼実数を処理する際に小数点の存在をどう扱うのか。」の主張は認められない。

6.むすび
以上のとおりであるから、本願発明は、刊行物1記載発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
そして、仮に、請求項1に係る発明を上記「5.(1)」の仮定発明と仮定しても、刊行物1記載発明及び刊行物2記載発明に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。
したがって、本願は、その他の請求項について検討するまでもなく、拒絶すべきものである。
よって、結論のとおり審決する。
 
審理終結日 2009-03-30 
結審通知日 2009-04-07 
審決日 2009-04-20 
出願番号 特願2002-382779(P2002-382779)
審決分類 P 1 8・ 121- WZ (G06F)
最終処分 不成立  
前審関与審査官 田中 友章  
特許庁審判長 江嶋 清仁
特許庁審判官 深津 始
清水 稔
発明の名称 コンピュータにおける文字型データを使用しての数値計算  

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