ポートフォリオ機能| 関連審決 | 不服2006-6851 |
|---|
| 関連ワード | 頒布された刊行物 / 進歩性(29条2項) / 容易に発明 / 下位概念 / 同一の発明 / 発明の詳細な説明 / 発明の利用 / 参酌 / 容易に想到(容易想到性) / 実施 / 拒絶査定 / 拒絶理由通知 / 請求の範囲 / 変更 / |
|---|
| 元本PDF |
裁判所収録の全文PDFを見る
 |
|---|
| 事件 |
平成
21年
(行ケ)
10143号
審決取消請求事件
|
|---|---|
|
原告Ｘ 被告特許庁長官 指定代理 人丸山高政 同江嶋清仁 同岩崎伸二 同小林和男 |
|
| 裁判所 | 知的財産高等裁判所 |
| 判決言渡日 | 2009/12/21 |
| 権利種別 | 特許権 |
| 訴訟類型 | 行政訴訟 |
| 主文 |
１原告の請求を棄却する。 ２訴訟費用は原告の負担とする。 |
| 事実及び理由 | |
|---|---|
|
全容
第1請求特許庁が不服2006-6851号事件について平成21年4月20日にした審決を取り消す。 第2争いのない事実1特許庁における手続の経緯原告は,平成14年11月28日,発明の名称を「コンピュータにおける文字型データを使用しての数値計算」とする発明について,特許出願をした(特願2002-382779号,以下「本願」といい,その明細書を「本願明細書」という。請求項の数は1である。甲1 。)原告は,平成18年2月3日付けで拒絶査定を受けたので(甲4 ,同年3)月15日,これに対する不服の審判請求をした(不服2006-6851号,審判請求書は同年3月13日付けである。甲5 。特許庁は,平成21年4月 )20日 「本件審判の請求は,成り立たない 」との審決をし,その謄本は,同 , 。 年5月19日,原告に送達された。 2特許請求の範囲本願明細書の特許請求の範囲の請求項1の記載は次のとおりである。 人が数値として解釈できる,コンピュータ内部で保持する文字列データを,そのまま計算対象の数値として扱い演算する手段 (以下,この発明を「本願 。 発明」という )。 3審決の理由( )別紙審決書写しのとおりである。要するに,本願発明は,本願出願前に1日本国内において頒布された刊行物である「文字列による無限長演算ユニットの製作秘話マガジンPSネットワーク 2001年 平 」(,,(DelphiVol.15),。「」。 成13年 3月1日発行 24ないし37ページ 以下 刊行物1 という甲10,乙1)記載の発明(以下「刊行物1記載発明」という )に基づい。 て当業者が容易に発明をすることができたものであるから,特許法29条2項の規定により特許を受けることができないとするものである。 ( )審決が,本願発明に進歩性がないとの結論を導く過程において認定した2刊行物1記載発明,本願発明と刊行物1記載発明の一致点,相違点は,次のとおりである。 ア刊行物1記載発明数値を型の型で保持することで,桁数制限のない四則演stringTIntStr算をおこなう,上ので実現された,文字列による無限長 WindowsDelphi演算ユニットであって,型の同士の足し算は,一番下の位から,各桁の数値を足しstringTIntStr, , , て 繰り上がりの数があれば覚えておいて 次の桁に足すことを繰り返し型のに文字列を追加するものであって,stringresult型のN1のi桁,N2のi桁,及びの和を型の TIntStr Carryintegerに格納し, calcResultのの演算結果を型のに追加するものであ calcResultmod 10stringresultる,ユニット。 イ一致点「人が数値として解釈できる,コンピュータ内部で保持する文字列データを,計算対象の数値として扱い演算する手段 」である点。。 ウ相違点文字列データの演算が,本願発明では,文字列データを「そのまま」計算対象の数値として扱うのに対して,刊行物1記載発明では,そのようなものか明らかではない点。 第3取消事由に関する原告の主張審決は,次に述べるとおり,本願発明の認定の誤り(取消事由1 ,本願発)明と刊行物1記載発明との相違点の看過(取消事由2 ,顕著な作用効果の看 )過(取消事由3 ,本願発明と刊行物2(特開平2-47787号公報,甲1 )1,以下「刊行物2」といい,そこに記載された発明を「刊行物2記載発明」という )記載発明との相違点の看過(取消事由4)があるから,違法として 。 取り消されるべきである。 1本願発明の認定の誤り(取消事由1)平成20年12月12日付け拒絶理由通知書(甲6)において刊行物1が示されたため,原告は,刊行物1に反論するために平成21年2月16日付け意見書(受付日は同月17日,甲7)及び「桁の大きい数値を計算するシステムマニュアル (甲12)を提出した。しかし,審決は,本願発明を認定するに 」当たって,甲7,甲12も参酌すべきであったにもかかわらず,甲7,甲12を参酌することなく本願発明を認定した誤りがある。 2本願発明と刊行物1記載発明との相違点の看過(取消事由2)( )データ型に関する相違点の看過1刊行物1に 普通の 桁 の概念と型のは一致しません乙 「『』, 」( stringindex1,26頁)との記載があることから,刊行物1記載発明は,数字の桁の概念と文字列の概念が一致しておらず,既存の文字列とは異なる新たなデータ型又は規格を必要とする。そのため,本願発明が文字列型という既存のデータ型を計算に用いており,数字の桁の概念と文字列の概念とを一致させているのに対し,刊行物1記載発明は新たなデータ型又は規格を必要とする点で相違するにもかかわらず,審決は,この相違点を看過しているという誤りがある。 ( )プログラム言語に関する相違点の看過2本願発明は特定のプログラム言語に依存しないように配慮しているのに対し,刊行物1記載発明はという特定のプログラム環境で動作するもDelphiのである点で相違しており,審決は,この相違点を看過しているという誤りがある。 3顕著な作用効果の看過(取消事由3)( )桁落ちに関する作用効果の看過1刊行物1の「型ととの変換」の節(乙1,27頁)に記載 TIntStrIntegerされているように,刊行物1記載発明は,既存のデータ型が扱える範囲の数値しか扱っていないから,桁落ちを解決するという効果を奏し得ない。これに対し,本願発明は文字列数値をそのまま計算対象とすることによって,桁落ちを解決するという顕著な効果を奏するが,審決は,このような本願発明の顕著な作用効果を看過した点で誤りがある。 ( )相互変換のための関数を作成する必要性等に関する作用効果の看過2本願発明は,既存のデータ型である文字列型の数値をそのまま計算に用いているので,文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果,計算の入出力を文字列として行えるという効果,新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果,及び様々なコンピュータで利用ができるという効果を奏するものであるが,審決は,これらの顕著な作用効果を看過している点で誤りがある。 4本願発明と刊行物2記載発明との相違点の看過(取消事由4)本願発明は桁落ちを防ぐために文字列型のまま計算をするものであるのに対し,刊行物2記載発明は文字列型のまま計算をするものではない点において相違するにもかかわらず,審決は,同相違点を看過している点で誤りがある。 第4被告の反論審決の認定,判断に誤りはなく,原告主張の取消事由は,いずれも理由がない。 1本願発明の認定の誤り(取消事由1)に対し原告の平成21年2月16日付け意見書(甲7)における「式を解釈する機能が幹で,計算を行なう機能は枝葉です(甲7,4頁4ないし5行)との主 。」張は,本願明細書の記載と整合しない。特許請求の範囲の請求項1は,実数の処理についての限定はなく,また,本願明細書に実数を処理することの具体的な記述はないから,甲7における「実数を処理する際に小数点の存在をどう扱。」(,), 。 うのか甲7 1頁25行 との内容は 本願明細書には記載されていないまた,甲12の内容も,本願明細書には記載されていない。したがって,本願発明を認定するに当たり甲7,甲12を参酌すべきでない。 2本願発明と刊行物1記載発明との相違点の看過(取消事由2)に対し( )データ型に関する相違点の看過に対し1stringTIntStr刊行物1記載発明は,数値のデータとして,既存の型と同じ型という文字列型を用いているから,新たなデータ型又は規格を必要としな。「『』, 」 い 刊行物1の 普通の桁 の概念と型のは一致しませんstringindex(乙1,26頁)との記載は,数字の文字列の左から何番目かということと何桁目かということが一致しないことを記述したものであり,刊行物1記載発明が新たなデータ型又は規格を必要とすることを記述したものではない。 したがって,刊行物1記載発明が新たなデータ型又は規格を必要とする点で本願発明と相違することを前提とする原告の主張は失当である。 ( )プログラム言語に関する相違点の看過に対し2本願発明は特定のプログラム言語に依存するような限定はないのに対し,刊行物1記載発明は,という特定のプログラム環境のとDelphi Object Pascalいうプログラム言語で記述されているから,刊行物1記載発明は,本願発明の下位概念に該当し,本願発明は刊行物1記載発明を含む発明である。したがって,審決には,本願発明が特定のプログラム言語に依存しないように配慮しているのに対し,刊行物1記載発明がという特定のプログラムDelphi環境で動作するものである点を相違点としなかったことについて誤りはない。 3顕著な作用効果の看過(取消事由3)に対し( )桁落ちに関する作用効果の看過に対し1刊行物1には,刊行物1記載発明が常に大きな桁の数値を扱わないということは記載されておらず,刊行物1記載発明は,桁数の制限すなわち桁落ちの問題を解決するために文字列型を用いて数値を保持するものであるから,刊行物1記載発明は,本願発明と同様に桁落ちを解決するという効果を奏する。したがって,刊行物1記載発明が桁落ちを解決するという作用効果を奏しないことを前提とする原告の主張は,失当である。 ( )相互変換のための関数を作成する必要性等に関する作用効果の看過に対2し刊行物1記載発明は,文字列型と整数型との相互変換のための関数としての標準関数を用いているから,刊行物1発明においても,文字列型とDelphi整数型との相互変換のための関数は別途作成する必要はない。 また,刊行物1記載発明は,型で保持した数値をそのままの形で出string力することを想定している。 さらに,刊行物1には,言語仕様が公開され周知となっているのDelphiというプログラム言語で組まれたプログラムリストが記載さ Object Pascalれ,そのプログラムリストの文字列型は,の標準データ型であ Object Pascalる型と同一の型であるから,刊行物1記載発明を実施するた stringTIntStrめには,当業者は,そのプログラムリストを読めば足り,アルゴリズムや特殊なデータ型は必要としない。そのプログラムリストを読めば,アルゴリズムを理解することができ,そのアルゴリズムを種々の言語でプログラムし直せば,様々なコンピュータで利用ができる。 したがって,既存のデータ型である文字列型を用いているので,文字列型と整数型及び実数型との相互変換のための関数を別途作成する必要がないという効果,計算の入出力を文字列として行えるという効果,新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果,及び様々なコンピュータで利用ができるという効果は,いずれも刊行物1記載発明から予測可能な程度のものであり顕著な作用効果ではない。 4本願発明と刊行物2記載発明との相違点の看過(取消事由4)に対し審決は,仮に本願発明が数式の解釈を包含するものであるとして,数式の解釈の部分について進歩性がないことを示すために,刊行物2を挙げたものであるから,審決の判断に誤りはない。 第5当裁判所の判断1本願発明の認定の誤り(取消事由1)について原告は,平成20年12月12日付け拒絶理由通知書(甲6)において公知文献として刊行物1が示されたため,刊行物1に反論するために甲7,甲12を提出したが,審決は,本願発明の内容を認定するに当たって,甲7,甲12も参酌すべきであったにもかかわらず,甲7,甲12を参酌することなく本願発明を認定した誤りがあると主張する。 しかし,原告の上記主張は,採用することができない。その理由は,以下のとおりである。 ( )平成20年12月12日付け拒絶理由通知書(甲6)において公知文献1として刊行物1が示され,これに対し,原告は,平成21年2月16日付け意見書(甲7)及びその添付資料として甲12を提出した。 以下,甲7,甲12の記載内容について検討する。 ア本願明細書の特許請求の範囲には,実数を演算する場合に小数点位置を整合(桁合わせ)する必要があるとの記載はなく,また,本願明細書の発明の詳細な説明にも,小数点位置を整合(桁合わせ)させて実数を処理することについて具体的な記述はない。 この点について,甲7の「?実数の扱いについて (甲7,2ないし3」頁)との項には,実数を扱う場合,小数点位置を整合(桁合わせ)する必要があるとの記載があるものの 「本願明細書に例1から例4までの仕様 ,を具体的に記述することは,同業者を利する結果となるため,避けなければなりません(甲7,3頁7ないし9行)と記載され,本願明細書にそ 。」のような具体的な記述が存在しないことが明確に示されている。 したがって,甲7の上記記載部分は,本願発明の内容を理解する上で何らかの意味を有するものとはいえない。 イ本願明細書の「発明が解決しようとする課題」の欄には,次のとおりの記載がある。 「ハードウェアによる演算は高速かつ,正確な内容が期待できるが,その数値演算のためのハードウェアの設計段階で数値の桁数に制限が設けられるため,桁数の大きな演算を行う場合に桁落ちが生じる( 0004 )。」【】「コンピュータ内で,計算の対象となる数値データ,もしくは計算途中に算出された数値データに一度桁落ちが生じると,その計算結果における数値の信頼性は大きく損なわれる( 0005 )。」【】「本発明は大きな桁を扱う数値データで,四則演算のうち加算,減算,乗算においては桁落ちの発生しない手法を示す事,除算においては任意の算出桁数を指定することにより,納得のいく計算結果を示す事を最終的な目的としている( 0006 )。」【】「,『』 , 例えば97+34 という文字列の記述をコンピュータに与えれば『97』と『34』は数値として解釈が可能であり,間にある『+』演算子は左右に並ぶ2つの数値を加算するための記号と解釈可能であり,また。」(【】) 式そのものの意味を理解するアルゴリズムは既に存在する0014「式のデータの解釈とは 『12×(34+56 』の文字列を,34と5 ,)6を先に加算して,その演算結果と12を乗算する等,計算の優先順位や手順を式から読み取ることで,この技術は上記にもあるとおり,既存している( 0017 )。」【】上記の本願明細書の記載によれば,本願明細書には,本願発明の課題として,大きな桁を扱う数値データで,四則演算のうち加算,減算,乗算においては桁落ちの発生しない手法を示すこと,除算においては任意の算出桁数を指定することにより,納得のいく計算結果を示すことが記載されており,計算を行うことが本願発明の課題であることが認められる。他方,式のデータの解釈は,周知であることが記載されており,本願明細書の他の箇所を参酌しても,式を解釈することについて具体的な記載はない(なお,本願明細書において 「桁落ち」とは,計算に用いようとする数値の ,桁数が,コンピュータの数値計算において扱うことのできる数値の桁数を超えることを意味すると解される。。)これに対して,甲7の「?式の解釈について (甲7,3ないし4頁) 」との項には 「本願発明の意図とする全体のレイアウトは,式を解釈する ,機能が幹で,計算を行なう機能は枝葉 (甲7,4頁4ないし5行)であ 」り,それによって本願発明は実用性を有する旨記載されている。 ,, , したがって 甲7の上記記載部分は 本願明細書の記載と整合性がなく本願発明の内容を理解する上で何らかの意味を有するものとはいえない。 ウ甲7の実質的内容は,前記アの「?実数の扱いについて (甲7,2な」いし3頁)との項及び前記イの「?式の解釈について (甲7,3ないし」4頁)との項に記載されているものと認められ,甲7に,その他に本願発明の内容を理解する上で意味のある事項が記載されているとは認められない。 また,甲12は,甲7の添付資料として提出されたものであり,その記載内容は,甲7に述べられたのと同じ事項を説明したものにすぎず,以上の判断を左右するものとはならない。 ( )以上のとおりであるから,審決が,甲7,甲12を参酌せずに本願発明2を認定した点に誤りはない。 2本願発明と刊行物1記載発明との相違点の看過(取消事由2)について( )データ型に関する相違点について1原告は,刊行物1に「普通の『桁』の概念と,型のは一致し stringindexません (乙1,26頁)との記載があることから,刊行物1記載発明は, 」数字の桁の概念と文字列の概念が一致しておらず,既存の文字列とは異なる新たなデータ型又は規格を必要とするとの前提に立った上で,本願発明は文字列型という既存のデータ型を計算に用いており,数字の桁の概念と文字列の概念とを一致させているのに対し,刊行物1記載発明は新たなデータ型又は規格を必要とする点で相違するにもかかわらず,審決は,この相違点を看過している点で誤りがあると主張する。 しかし原告の上記主張は,採用することができない。その理由は,以下のとおりである。 ア(ア)a「プログラマのための2入門 (小山裕徳訳学校法人東Delphi 」京電機大学1997年(平成9年)3月20日第1版1刷発行,乙2)には,次のとおりの記載がある。 「はアプリケーションを開発するための環DelphiMicrosoft Windows境であり,ツールです( 訳者まえがき」の頁12ないし13行) 。」「「のプログラミング言語は,が基本になっていまDelphi Object Pascalす(5頁24行)。」「の両方のバージョンとも,変数の型としておよそ15の標準Delphi型があります。には (数え方にもよりますが)さらに7 Delphi 2.0 ,つの型があります。通常は,の型をいくつかに分類して考えまDelphiす。論理型,文字型,整数型,実数型などです(次の章で説明するよ, )。, うに あなた自身で型を定義することもできます以下に示すのはの両方のバージョンで共通な型について概略を説明したものでDelphiす(118頁28行ないし119頁2行) 。」「(文字列)型の変数は,では255字までstringstring Delphi 1.0の文字を保持します。一方,では文法オプションの ASCII Delphi 2.0[長い文字列を使う]がオンになっていて,このデフォルトを変更しないかぎり文字数に基本的に制限がないことを意味します(実際の制限は 2Gバイトですどちらのバージョンでも 数字を大かっこ[] ,)。,でかこって,255字より少ない文字を保持するようにすることができます。たとえば,次のようにします。 var[] (120頁30行ないし121頁2行) Name: string 45 ; 」bプログラマのための入門書である乙2に前記aの記載があることかstringDelphi Object Pascal らすると型がのプログラミング言語である ,の変数の型の一種であり,テキストを扱う文字列型であることは,プログラミングの技術分野の当業者であれば一般的な知識として有していたものと認められる。 (イ)また,刊行物1(乙1)には,次のとおりの記載がある。 a「どうせならば,桁数制限なしに,そのまま四則演算のできる数値型を作ることはできないものなのでしょうか?桁数が増えれば,その,, ぶんだけ自動的に長さが延長されてメモリが確保される型 というとでは,型が思い当たります。 Delphistring数値をで保持しておけば,桁数がどれほど増えようとおそれるstring(), 。 ことはありませんし *4やに表示することも容易です labelEditというような発想でもって,文字列による無限長演算ユニットの製作はスタートしました(25頁「◇そういうわけで,無限桁数演算 。」の可能性を考える」の節)b「データの保持については型と決めていますが,そのまstringstringまでは味気ないので,型という型を定義しました。 TIntStrtypeTIntStr = string;つまり型そのままですが,こうしておくことで,将来何か変更stringするときに他のソースまで書き換える手間を省くことができます 」。 (26頁「◇一般的な定義」の節 )」(ウ)前記(ア)の当業者の一般的知識と上記(イ)a,bの刊行物1の記載によれば,刊行物1記載発明は,のプログラミング言語であるDelphiで記述され,型を数値データの保持に用い,データ Object Pascalstring型として使用するものであることが認められる。 イ(ア)aさらに 「[改訂版]入門 (青山学著ソフトバンク株式会 ,」Delphi社1996年(平成8年)8月24日初版発行,乙3)には,次のとおりの記載がある。 「, 。,type type文は 新しい型を宣言するための予約語です文を使えば任意のデータ型を宣言することができます。 ◇文の構文typetype=;型名宣言する型たとえば,20文字の文字列型をという型として新たに登TNamae録したいときには,次のように宣言します。 typeTNamae = String 20 ;[]type IntegerReal文で型を宣言するとそれを新しい型として型や ,,型などの他の組み込み型とまったく同様に,変数の宣言をすることができます。次に,その例を示しておきましょう。 varAoyamaHikari: TNamae;この例では,型,つまり先ほど文で宣 AoyamaHikariTNamaetype言した[]という型で宣言したことになります(54頁12 String 20 。」ないし27行)bプログラマのための入門書である乙3に上記の記載があることからすると,が,においてプログラムで使用する変数に対してtypeDelphi用いられる新しいデータ型を宣言するための予約語であることは,プログラミングの技術分野の当業者であれば一般的な知識として有していたものと認められる。 (イ)前記(ア)の当業者の一般的知識と前記ア(イ)bの刊行物1の記載によれば,刊行物1記載発明では,新たな型として型を宣言してTIntStrいるが,型は型と同じ型として宣言しており,型と TIntStrstring TIntStr型が実質的に同じであることは,当業者の一般的知識に照らして string明らかである。 ウ原告は,刊行物1に「普通の『桁』の概念と,型のは一致stringindexしません (乙1,26頁)との記載があることから,刊行物1記載発明 」は,数字の桁の概念と文字列の概念が一致しておらず,既存の文字列とは,「『』 異なる新たなデータ型又は規格を必要とすると主張するが普通の 桁の概念と,型のは一致しません」との記載を根拠として,刊stringindex行物1記載発明は,数字の桁の概念と文字列の概念が一致しておらず,既存の文字列とは異なる新たなデータ型又は規格を必要とすると解することはできない。 ,() 。 (ア)すなわち 刊行物1 乙1 の26頁には次のとおりの記載がある「型は型そのままですので,[ ]という具合にしてアTIntStrstringIntstr 3クセスすれば,特定の桁の数字をとってくることができます。しかしなstring がら 図2を見ていただければ分かるように 普通の 桁 の概念と , ,『』,型のは一致しません。 indexそこで,次のような関数を用意しました( ◇桁の数値を取り出す」 。」「の節)図2には,左より1から7までの七つの数字が横書きされ,右から三「」 「」,「」 つ目の 5 が 3桁目の数字 として指示され 左から三つ目の 3が「[ ]」として指示されている。 Intstr 3(イ)前記(ア)の刊行物1の記載によれば,刊行物1記載発明において,ある数値から特定の桁の数字を取り出す場合,[ ](型のIntstrstringindex Intstr 1Intstr) , , は 数字列の左から数えて1文字目を[ ] 2文字目を[ ],3文字目を[ ]・・・のように扱うものであり,文字数がn2Intstr 3, ,, 個の数字列では 普通の位取りでいう1桁目 すなわち1の位の数字は, 。 左から数えてn文字目であるから[ ]ではなく[ ]に当たるIntstr 1Intstr nこのように,普通の位取りでいう桁と,左から数えて何文字目にあるかということ([ ],型の)は一致せず,このことを,刊Intstrstringindex,「『』, 」 行物1では普通の 桁 の概念と型のは一致しません stringindexと記述したものと認められる。 stringindex したがって,刊行物1の「普通の『桁』の概念と,型のは一致しません」との記載を根拠として,刊行物1記載発明は,数字の桁の概念と文字列の概念が一致しておらず,既存の文字列とは異なる新たなデータ型又は規格を必要とすると解することはできない。 stringTIntStr エこのように 刊行物1記載発明は 既存の型と実質的に同じ ,,型の文字列型をデータ型として計算に用いており,新たなデータ型又は規格を必要とするものではない。そうすると,本願発明は文字列型という既存のデータ型を計算に用いており,数字の桁の概念と文字列の概念とを一致させているのに対し,刊行物1記載発明は新たなデータ型又は規格を必要とする点で相違するとは認められず,審決に,この相違点を看過しているという誤りがあるとの原告の主張は,採用することができない。 ( )プログラム言語に関する相違点について2原告は,本願発明は特定のプログラム言語に依存しないように配慮しているのに対し,刊行物1記載発明はという特定のプログラム環境で動Delphi作するものである点で相違しているが,審決は,この相違点を看過しているという誤りがあると主張する。 しかし,原告の上記主張は,採用することができない。その理由は,以下のとおりである。 すなわち,本願発明は,もともと特定のプログラム言語に依存することのない 「人が数値として解釈できる,コンピュータ内部で保持する文字列デ ,ータを,そのまま計算対象の数値として扱い演算する手段 」との技術思想。 であり,いかなるプログラム言語によるものであっても,上記の技術思想を実現するものであれば,本願発明と同一の発明と認められ,採用されているプログラム言語が何かということは,本願発明の技術思想の実現の有無とは直接の関係がないものと解される。そうすると,審決が,本願発明と刊行物1記載発明の対比において,本願発明は特定のプログラム言語に依存しないように配慮しているのに対し,刊行物1記載発明はという特定のプDelphiログラム環境で動作するものである点を相違点として挙げなかった点に誤りはない。 3顕著な作用効果の看過(取消事由3)について( )桁落ちに関する作用効果の看過について1,「 」(,) 原告は 刊行物1の型ととの変換 の節 乙1 27頁 TIntStrIntegerに記載されているように,刊行物1記載発明は,既存のデータ型が扱える範囲の数値しか扱っていないから,桁落ちを解決するという効果を奏し得ない, , とした上で 本願発明は文字列数値をそのまま計算対象とすることによって桁落ちを解決するという顕著な効果を奏するが,刊行物1記載発明はそのような効果を奏し得ず,審決は,このような本願発明の顕著な作用効果を看過した点で誤りがあると主張する。 しかし,原告の上記主張は,採用することができない。その理由は,以下のとおりである。(なお 「桁落ちを解決する」とは,コンピュータの数値計 ,算において扱うことのできる数値の桁数に制限がないようにすることを意味すると解される )。 ア(ア)刊行物1の「型ととの変換」の節には,次のとおりTIntStrIntegerの記載がある。 「型は独自に計算ルーチンを持っていて,独立して数値を保持TIntStrしますが,そうはいっても既存の型とやりとりができないと役にたちません。 の数値をに代入したり,型の数値をとして返Int64TIntStrTIntStrInt64す関数を作成しました。 当然,お互い桁あふれが生じない範囲であることが前提です。 ,,Int64Integer integerはと代入互換性がありますので 普通のの数値もこの関数でに変換することができます(乙1,27頁) TIntStr 。」(イ)前記(ア)の記載によれば,そのうちの「当然,お互い桁あふれが生じない範囲であることが前提です 」との記載は,変換元又は変換先の 。 数値が桁あふれを生じる場合には正しくデータ型の変換ができないことについて注意を喚起しているものと認められ,刊行物1記載発明が大きな桁数の数値を常に扱わないとの趣旨の記載であるとは認められない。 イ(ア)また,刊行物1には,次のとおりの記載がある。 「このような大きな数値の演算は,科学技術計算の分野では頻繁に出てきており,この場合の数値の扱いについても「多倍長計算」というアルIntegerInteger ゴリズムが確立されています。つまり,で足りなければをふたつもってきてで数値を表そう,それで足りなければ4つで64bit,8つでという具合にして,を複数持ってくるこ 128bit256bit...integerとによって演算を行うわけです。 この手法は,桁上がりの部分だけをチェックすれば残りの部分は普通の計算で処理することができるため,計算効率に優れており,多くの分野で利用されています。しかし,実際に使用するには,特殊な数値の型を利用する必要があったり,計算できる桁数に制限があったりして,普通の思考でそのまま計算するには,何かと不便な点が多くあります 」。 (「,」,,) ◇パソコンにおける アップル社購入の計算 の節 乙1 25頁, (イ)刊行物1の前記(ア)の記載及び前記2( )ア(イ)aの記載によれば1刊行物1記載発明は,大きな数値の演算には,桁数の制限があったり,特殊な数値の型を利用する必要があるとの問題点があったので,これらの問題点を解決するために,桁数の制限なしに普通の思考でそのまま四則計算できる数値型として文字列型(の型)を用いるといDelphistringう発想のもとに製作されたことが認められる。 そうすると,刊行物1記載発明は,文字列型(の型)をDelphistring用いることにより,桁落ちを解決する,すなわちコンピュータの数値計算において扱うことのできる数値の桁数に制限がないようにするとの作用効果を奏するものと認められる。 ウこのように,刊行物1記載発明は,文字列型(の型)を用Delphistringいることにより,桁落ちを解決する,すなわちコンピュータの数値計算において扱うことのできる数値の桁数に制限がないようにするとの作用効果を奏するから,本願発明が,文字列数値をそのまま計算対象とすることによって桁落ちを解決するという効果を奏するとしても,それは,顕著な作用効果であるとはいえない。 ( )相互変換のための関数を作成する必要性等に関する作用効果の看過につ2いて原告は,本願発明は,既存のデータ型である文字列型をそのまま計算に用いているので,文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果,計算の入出力を文字列として行えるという効果,新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果及び様々なコンピュータで利用ができるという効果を奏するものであるが,審決は,これらの顕著な作用効果を看過している点で誤りがあると主張する。 しかし,原告の上記主張は,採用することができない。その理由は,以下のとおりである。 ア文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果について(ア)文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという点は,本願発明の作用効果ということができないのみならず,仮にそのような効果があると解する余地があるとしても,その効果を顕著な作用効果とみることはできない。 ,, , まず 以下のとおり 特許請求の範囲及び本願明細書の記載によれば文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果は,本願発明によって必然的にもたらされる作用効果とはいえない。 すなわち,本願明細書には,数値のデータ型に関連して 「このとき,の計算手段は,それぞれ縦1桁の数値だけを対象として行うため,文字型から整数型へ変換して計算し,必要な結果内容を文字型に変換して?のエリアに置いていく方法も考えられる( 0029 )との記載, 。」【】及びIEEE規格等の数値データから文字列データに変換すること0(【033】ないし【0035 )の記載はあるものの,文字列型と整数型 】及び実数型との相互変換のための手段についての記載はない。そうすると,本願発明は,文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する技術を排除しているとは解されず,そのことからすると,文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを作成する必要がないという効果は,本願発明の作用効果と解することはできない。 (イ)のみならず,仮に,文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果があったとしても,同効果は,以下のとおり,刊行物1記載発明から予測可能な程度のものにすぎず,顕著な作用効果とはいえない。 すなわち,刊行物1には,次のとおりの記載がある。 「型は型そのままですので,[ ]という具合にしてアTIntStrstringIntstr 3クセスすれば,特定の桁の数字をとってくることができます。しかしなstring がら 図2を見ていただければ分かるように 普通の 桁 の概念と , ,『』,型のは一致しません。 indexそこで,次のような関数を用意しました。 , 。 getdigitTIntStrKeta は型の数値から桁目の数値をとってくる関数です返り値はとなっていますが,これはTdigitTdigit = 0..9;と定義されています。 function getdigit N:TIntStr;Keta:integer :Tdigit; ()beginif Ketalength Nor Keta 1then result := 0(>( )) (< )else result := StrToIntDef Copy N,length N -Keta+1,1 ,0 ; ((( )) )(乙1,26頁「◇桁の数値を取り出す」の節)end; 」「符号の問題をここで片づけてしまうことにより,,IntStrAddPositiveといった関数の中では,引数が正の数であると想定し IntStrDecPositiveて処理を行うことができます。 符号の問題を片づけてしまえば,あとは小学校一年生で習った足し算を忠実に実行して行くだけです。 一番下の位から,各桁の数値を足して,繰り上がりの数があれば覚えておいて,次の桁に足す,この繰り返しです。 は(型 (判決注:型 」の誤りと認められresultTIntStr=stirng=string )「()る )ですので,()は足し算で 。 result := InttoStr calcResult mod 10+ result;はなくて文字列の追加になるところに注意してください。 (){}function IntStrAddPositive N1, N2:TIntStr :TIntStr; N1+N2vari,calcResult,N1Length,N2Length:integer;Carry:Tdigit;beginresult := '';N1Length := length N1 ;()N2Length := length N2 ;()Carry := 0;i:=1;while i =N1Length or i =N2Length do( <) ( <)begincalcResult := getdigit N1,i +getdigit N2,i+ Carry;()()Carry := calcResult div 10;result := InttoStr calcResult mod 10+ result;()Inc i ; ( )end;if Carry0 then result := Inttostr Carry+ result;>()(乙1,28ないし29頁「◇足し算」の節)end; 」(ウ)前記(イ)の記載によれば,刊行物1記載発明においては,関数IntStrAddPositive N1, N2:TIntStrTIntStrN1N2 ()が型の二つの引数及びN1N2 N1 を取り及びはともに正の整数であることが想定されており , ,を被加数,を加数として加算を行い,加算の結果を型で返すN2 TIntStrものであることが認められ,との加算は,小さい桁から1桁ず N1N2つ順番に行われ,1桁の加算を行う際には,その桁の数字を一度整数型のデータに変換して加算してから,結果を文字列型に再変換していることが認められる。 そして 「プログラマのための2入門 (乙2,136頁)に , 」DelphiDelphiよれば,刊行物1記載発明の上記の演算の過程で用いられているの関数について,関数(乙2,136頁の表の機能欄のStrToIntDef「」との表記は 「」を意味するものと認めら StringToIntDefStrToIntDef ,れる )は,整数を表現する文字列を,その数値(整数型データ)に変 。 換し,文字列が正しい数字の表現でないときにはデフォルトの値にする関数であり,は,整数を文字列に変換する関数であることが認IntToStrめられ,そのため,刊行物1記載発明は,文字列型と整数型の相互変換のための関数としてに標準的に備えられた関数を用いているこDelphiとが認められる。 そうすると,刊行物1記載発明は,既存のデータ型である文字列型(の型)を用いており,文字列型と整数型及び実数型とのDelphistring相互変換のための関数や型変換プログラムを別途作成する必要はないものと認められる。したがって,文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果は,刊行物1記載発明から予測可能な程度のものにすぎず,顕著な作用効果とはいえない。 イ計算の入出力を文字列として行えるという効果について刊行物1には 「数値をで保持しておけば,桁数がどれほど増え ,stringようとおそれることはありませんし(*4 ,やに表示すること ) labelEditも容易です(乙1,25頁「◇そういうわけで,無限桁数演算の可能性 。」を考える」の節)と記載されている。 そして 「プログラミング入門 (玉木彰著2001年(平成1 , 」Delphi3年)4月5日初版第1刷発行,乙4)には 「コンポーネント」 , Label及び「コンポーネント」が,文字列()を表示出力するためのEdit stringものであることが記載されている(乙4,30ないし31頁 。)そうすると,刊行物1記載発明は,型で保持した数値をそのままstring。, の形で出力することを想定しているものであると認められる したがって計算の入出力を文字列として行えるという効果は,顕著なものではなく,刊行物1記載発明から予測可能な程度のものにすぎない。 ウ新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果及び様々なコンピュータで利用ができるという効果について刊行物1には,前記のとおり,文字列型を用いた無限長の数値演算について,のというプログラム言語で組まれたプログラムDelphiObject PascalDelphiObjectリストが記載されている そして 乙2ないし5によればの 。,,の言語仕様は公開され,周知である。さらに,前記のとおり,刊行Pascal物1記載発明のプログラムリストの文字列型は,の標準デー Object Pascalタ型である型と同一型の型である。 stringTIntStrそうすると,当業者は,刊行物1記載のプログラムリストを読むことにより,刊行物1記載発明のアルゴリズムを理解し,その実施ができるものであって,そのためにアルゴリズム及び特殊なデータ型を必要としない。 また,刊行物1記載のプログラムリストを読むことにより,刊行物1記載発明のアルゴリズムを理解することができることから,そのアルゴリズムを種々のプログラム言語でプログラムし直すことは,当業者であれば適宜になし得る設計事項であり,それによって刊行物1記載発明を様々なコンピュータで利用することもできる。そのため,刊行物1記載発明の利用を広めるために,新たなデータ型や規格を国際標準として採用させる必要もない。 したがって,新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果及び様々なコンピュータで利用ができるという効果は,顕著なものではなく,刊行物1記載発明から予測可能な程度のものにすぎない。 エしたがって,本願発明が,文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果,計算の入出力を文字列として行えるという効果,新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果及び様々なコンピュータで利用ができるという効果を奏するものであるとしても,これらは顕著な作用効果であるということはできず,審決に,これらの顕著な作用効果を看過したとの誤りはない。 4本願発明と刊行物2記載発明との相違点の看過(取消事由4)について原告は,本願発明は桁落ちを防ぐために文字列型のまま計算をするものであるのに対し,刊行物2記載発明は文字列型のまま計算をするものではない点において相違するにもかかわらず,審決は,同相違点を看過している点で誤りがあると主張する。 しかし,原告の上記主張は,採用することができない。 審決は,念のため,本願発明と刊行物1記載発明とが「人からコンピュータに与える式のデータを解釈するプログラム」を備えているか否かとの点において相違しているとしても,同相違点に係る事項は,刊行物1記載発明に刊行物2記載発明を適用することによって,当業者が容易に想到し得ると判断した。 すなわち,刊行物2記載発明は,本願発明と刊行物1記載発明との間の前記相違点に係る事項が容易に想到し得ることを示すために用いられたものであるから,本願発明と刊行物2記載発明の相違点を認定しなかったからといって,何ら審決の判断に違法を来すことはない。したがって,この点の原告の主張は,主張自体失当である。 5結論以上のとおり,原告主張の取消事由はいずれも理由がない。原告は,その他縷々主張するが,審決にこれを取り消すべきその他の違法もない。 よって,原告の本訴請求を棄却することとし,主文のとおり判決する。 |
| 裁判長裁判官 | 飯村敏明 |
|---|---|
| 裁判官 | 中平健 |
| 裁判官 | 上田洋幸 |