- 1 -平成２１年１２月２１日判決言渡平成２１年（行ケ）第１０１４３号審決取消請求事件平成２１年１０月２８日口頭弁論終結判決原告Ｘ被告特許庁長官指定代理人丸山高政同江嶋清仁同岩崎伸二同小林和男主文 原告の請求を棄却する。 訴訟費用は原告の負担とする。 事実 及び 理由 第１請求特許庁が不服２００６－６８５１号事件について平成２１年４月２０日にした審決を取り消す。 第２争いのない事実 特許庁における手続の経緯原告は，平成１４年１１月２８日，発明の名称を「コンピュータにおける文字型データを使用しての数値計算」とする発明について，特許出願をした（特願２００２－３８２７７９号，以下「本願」といい，その明細書を「本願明細書」という。請求項の数は１である。甲１。 ）原告は，平成１８年２月３日付けで拒絶査定を受けたので（甲４，同年３）月１５日，これに対する不服の審判請求をした（不服２００６－６８５１号，審判請求書は同年３月１３日付けである。甲５。特許庁は，平成２１年４月）- 2 -２０日「本件審判の請求は，成り立たない」との審決をし，その謄本は，同，。 年５月１９日，原告に送達された。 特許請求の範囲本願明細書の特許請求の範囲の請求項１の記載は次のとおりである。 人が数値として解釈できる，コンピュータ内部で保持する文字列データを，そのまま計算対象の数値として扱い演算する手段（以下，この発明を「本願。 発明」という）。 審決の理由( )別紙審決書写しのとおりである。要するに，本願発明は，本願出願前に 日本国内において頒布された刊行物である「文字列による無限長演算ユニットの製作秘話マガジンＰＳネットワーク２００１年平」（， 書写しのとおりである。要するに，本願発明は，本願出願前に 日本国内において頒布された刊行物である「文字列による無限長演算ユニットの製作秘話マガジンＰＳネットワーク２００１年平」（，，（DelphiVol.15），。 「」。 成１３年３月１日発行２４ないし３７ページ以下刊行物１という甲１０，乙１）記載の発明（以下「刊行物１記載発明」という）に基づい。 て当業者が容易に発明をすることができたものであるから，特許法２９条２項の規定により特許を受けることができないとするものである。 ( )審決が，本願発明に進歩性がないとの結論を導く過程において認定した 刊行物１記載発明，本願発明と刊行物１記載発明の一致点，相違点は，次のとおりである。 ア刊行物１記載発明数値を型の型で保持することで，桁数制限のない四則演stringTIntStr算をおこなう，上ので実現された，文字列による無限長WindowsDelphi演算ユニットであって，型の同士の足し算は，一番下の位から，各桁の数値を足しstringTIntStr，，，て繰り上がりの数があれば覚えておいて次の桁に足すことを繰り返し型のに文字列を追加するものであって，stringresult型のＮ１のｉ桁，Ｎ２のｉ桁，及びの和を型のTIntStrCarryinteger- 3 -に格納し，calcResultのの演算結果を型のに追加するものであcalcResultmodstringresultる，ユニット。 イ一致点「人が数値として解釈できる，コンピュータ内部で保持する文字列データを，計算対象の数値として扱い演算する手段」である点。 。 ウ相違点文字列データの演算が，本願発明では，文字列デ ト。 イ一致点「人が数値として解釈できる，コンピュータ内部で保持する文字列データを，計算対象の数値として扱い演算する手段」である点。 。 ウ相違点文字列データの演算が，本願発明では，文字列データを「そのまま」計算対象の数値として扱うのに対して，刊行物１記載発明では，そのようなものか明らかではない点。 第３取消事由に関する原告の主張審決は，次に述べるとおり，本願発明の認定の誤り（取消事由１，本願発）明と刊行物１記載発明との相違点の看過（取消事由２，顕著な作用効果の看）過（取消事由３，本願発明と刊行物２（特開平２－４７７８７号公報，甲１）１，以下「刊行物２」といい，そこに記載された発明を「刊行物２記載発明」という）記載発明との相違点の看過（取消事由４）があるから，違法として。 取り消されるべきである。 本願発明の認定の誤り（取消事由１）平成２０年１２月１２日付け拒絶理由通知書（甲６）において刊行物１が示されたため，原告は，刊行物１に反論するために平成２１年２月１６日付け意見書（受付日は同月１７日，甲７）及び「桁の大きい数値を計算するシステムマニュアル（甲１２）を提出した。しかし，審決は，本願発明を認定するに」当たって，甲７，甲１２も参酌すべきであったにもかかわらず，甲７，甲１２を参酌することなく本願発明を認定した誤りがある。 本願発明と刊行物１記載発明との相違点の看過（取消事由２）( )データ型に関する相違点の看過 - 4 -刊行物１に普通の桁の概念と型のは一致しません乙「『』，」（stringindex１，２６頁）との記載があることから，刊行物１記載発明は，数字の桁の概念と文字列の概念が一致しておらず，既存の文字列とは異なる新たなデータ型又は規格を必要とする。そのため，本願発明が gindex１，２６頁）との記載があることから，刊行物１記載発明は，数字の桁の概念と文字列の概念が一致しておらず，既存の文字列とは異なる新たなデータ型又は規格を必要とする。そのため，本願発明が文字列型という既存のデータ型を計算に用いており，数字の桁の概念と文字列の概念とを一致させているのに対し，刊行物１記載発明は新たなデータ型又は規格を必要とする点で相違するにもかかわらず，審決は，この相違点を看過しているという誤りがある。 ( )プログラム言語に関する相違点の看過 本願発明は特定のプログラム言語に依存しないように配慮しているのに対し，刊行物１記載発明はという特定のプログラム環境で動作するもDelphiのである点で相違しており，審決は，この相違点を看過しているという誤りがある。 顕著な作用効果の看過（取消事由３）( )桁落ちに関する作用効果の看過 刊行物１の「型ととの変換」の節（乙１，２７頁）に記載TIntStrIntegerされているように，刊行物１記載発明は，既存のデータ型が扱える範囲の数値しか扱っていないから，桁落ちを解決するという効果を奏し得ない。これに対し，本願発明は文字列数値をそのまま計算対象とすることによって，桁落ちを解決するという顕著な効果を奏するが，審決は，このような本願発明の顕著な作用効果を看過した点で誤りがある。 ( )相互変換のための関数を作成する必要性等に関する作用効果の看過 本願発明は，既存のデータ型である文字列型の数値をそのまま計算に用いているので，文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果，計算の入出力を文字列として行えるという効果，新たなデータ型や規格を国際標準として採用させ- 5 -る手間が不必要であると 互変換のための関数や型変換プログラムを別途作成する必要がないという効果，計算の入出力を文字列として行えるという効果，新たなデータ型や規格を国際標準として採用させ- 5 -る手間が不必要であるという効果，及び様々なコンピュータで利用ができるという効果を奏するものであるが，審決は，これらの顕著な作用効果を看過している点で誤りがある。 本願発明と刊行物２記載発明との相違点の看過（取消事由４）本願発明は桁落ちを防ぐために文字列型のまま計算をするものであるのに対し，刊行物２記載発明は文字列型のまま計算をするものではない点において相違するにもかかわらず，審決は，同相違点を看過している点で誤りがある。 第４被告の反論審決の認定，判断に誤りはなく，原告主張の取消事由は，いずれも理由がない。 本願発明の認定の誤り（取消事由１）に対し原告の平成２１年２月１６日付け意見書（甲７）における「式を解釈する機能が幹で，計算を行なう機能は枝葉です（甲７，４頁４ないし５行）との主。」張は，本願明細書の記載と整合しない。特許請求の範囲の請求項１は，実数の処理についての限定はなく，また，本願明細書に実数を処理することの具体的な記述はないから，甲７における「実数を処理する際に小数点の存在をどう扱。」（，），。 うのか甲７１頁２５行との内容は本願明細書には記載されていないまた，甲１２の内容も，本願明細書には記載されていない。したがって，本願発明を認定するに当たり甲７，甲１２を参酌すべきでない。 本願発明と刊行物１記載発明との相違点の看過（取消事由２）に対し( )データ型に関する相違点の看過に対し stringTIntStr刊行物１記載発明は，数値のデータとして，既存の型と同じ型という文字列型を用いているから，新たなデータ型又は ２）に対し( )データ型に関する相違点の看過に対し stringTIntStr刊行物１記載発明は，数値のデータとして，既存の型と同じ型という文字列型を用いているから，新たなデータ型又は規格を必要としな。 「『』，」い刊行物１の普通の桁の概念と型のは一致しませんstringindex（乙１，２６頁）との記載は，数字の文字列の左から何番目かということと何桁目かということが一致しないことを記述したものであり，刊行物１記載- 6 -発明が新たなデータ型又は規格を必要とすることを記述したものではない。 したがって，刊行物１記載発明が新たなデータ型又は規格を必要とする点で本願発明と相違することを前提とする原告の主張は失当である。 ( )プログラム言語に関する相違点の看過に対し 本願発明は特定のプログラム言語に依存するような限定はないのに対し，刊行物１記載発明は，という特定のプログラム環境のとDelphiObjectPascalいうプログラム言語で記述されているから，刊行物１記載発明は，本願発明の下位概念に該当し，本願発明は刊行物１記載発明を含む発明である。したがって，審決には，本願発明が特定のプログラム言語に依存しないように配慮しているのに対し，刊行物１記載発明がという特定のプログラムDelphi環境で動作するものである点を相違点としなかったことについて誤りはない。 顕著な作用効果の看過（取消事由３）に対し( )桁落ちに関する作用効果の看過に対し 刊行物１には，刊行物１記載発明が常に大きな桁の数値を扱わないということは記載されておらず，刊行物１記載発明は，桁数の制限すなわち桁落ちの問題を解決するために文字列型を用いて数値を保持するものであるから，刊行物１記載発明は，本願発明と同様に の数値を扱わないということは記載されておらず，刊行物１記載発明は，桁数の制限すなわち桁落ちの問題を解決するために文字列型を用いて数値を保持するものであるから，刊行物１記載発明は，本願発明と同様に桁落ちを解決するという効果を奏する。したがって，刊行物１記載発明が桁落ちを解決するという作用効果を奏しないことを前提とする原告の主張は，失当である。 ( )相互変換のための関数を作成する必要性等に関する作用効果の看過に対 し刊行物１記載発明は，文字列型と整数型との相互変換のための関数としての標準関数を用いているから，刊行物１発明においても，文字列型とDelphi整数型との相互変換のための関数は別途作成する必要はない。 また，刊行物１記載発明は，型で保持した数値をそのままの形で出string- 7 -力することを想定している。 さらに，刊行物１には，言語仕様が公開され周知となっているのDelphiというプログラム言語で組まれたプログラムリストが記載さObjectPascalれ，そのプログラムリストの文字列型は，の標準データ型であObjectPascalる型と同一の型であるから，刊行物１記載発明を実施するたstringTIntStrめには，当業者は，そのプログラムリストを読めば足り，アルゴリズムや特殊なデータ型は必要としない。そのプログラムリストを読めば，アルゴリズムを理解することができ，そのアルゴリズムを種々の言語でプログラムし直せば，様々なコンピュータで利用ができる。 したがって，既存のデータ型である文字列型を用いているので，文字列型と整数型及び実数型との相互変換のための関数を別途作成する必要がないという効果，計算の入出力を文字列として行えるという効果，新たなデータ型や規格を国際標準として採用させる手間が不必要 ので，文字列型と整数型及び実数型との相互変換のための関数を別途作成する必要がないという効果，計算の入出力を文字列として行えるという効果，新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果，及び様々なコンピュータで利用ができるという効果は，いずれも刊行物１記載発明から予測可能な程度のものであり顕著な作用効果ではない。 本願発明と刊行物２記載発明との相違点の看過（取消事由４）に対し審決は，仮に本願発明が数式の解釈を包含するものであるとして，数式の解釈の部分について進歩性がないことを示すために，刊行物２を挙げたものであるから，審決の判断に誤りはない。 第５当裁判所の判断 本願発明の認定の誤り（取消事由１）について原告は，平成２０年１２月１２日付け拒絶理由通知書（甲６）において公知文献として刊行物１が示されたため，刊行物１に反論するために甲７，甲１２を提出したが，審決は，本願発明の内容を認定するに当たって，甲７，甲１２も参酌すべきであったにもかかわらず，甲７，甲１２を参酌することなく本願発明を認定した誤りがあると主張する。 - 8 -しかし，原告の上記主張は，採用することができない。その理由は，以下のとおりである。 ( )平成２０年１２月１２日付け拒絶理由通知書（甲６）において公知文献 として刊行物１が示され，これに対し，原告は，平成２１年２月１６日付け意見書（甲７）及びその添付資料として甲１２を提出した。 以下，甲７，甲１２の記載内容について検討する。 ア本願明細書の特許請求の範囲には，実数を演算する場合に小数点位置を整合（桁合わせ）する必要があるとの記載はなく，また，本願明細書の発明の詳細な説明にも，小数点位置を整合（桁合わせ）させて実数を処理することについて具体的な記述はない。 この点について，甲 点位置を整合（桁合わせ）する必要があるとの記載はなく，また，本願明細書の発明の詳細な説明にも，小数点位置を整合（桁合わせ）させて実数を処理することについて具体的な記述はない。 この点について，甲７の「①実数の扱いについて（甲７，２ないし３」頁）との項には，実数を扱う場合，小数点位置を整合（桁合わせ）する必要があるとの記載があるものの「本願明細書に例１から例４までの仕様，を具体的に記述することは，同業者を利する結果となるため，避けなければなりません（甲７，３頁７ないし９行）と記載され，本願明細書にそ。」のような具体的な記述が存在しないことが明確に示されている。 したがって，甲７の上記記載部分は，本願発明の内容を理解する上で何らかの意味を有するものとはいえない。 イ本願明細書の「発明が解決しようとする課題」の欄には，次のとおりの記載がある。 「ハードウェアによる演算は高速かつ，正確な内容が期待できるが，その数値演算のためのハードウェアの設計段階で数値の桁数に制限が設けられるため，桁数の大きな演算を行う場合に桁落ちが生じる（０００４）。」【】「コンピュータ内で，計算の対象となる数値データ，もしくは計算途中に算出された数値データに一度桁落ちが生じると，その計算結果における数値の信頼性は大きく損なわれる（０００５）。」【】- 9 -「本発明は大きな桁を扱う数値データで，四則演算のうち加算，減算，乗算においては桁落ちの発生しない手法を示す事，除算においては任意の算出桁数を指定することにより，納得のいく計算結果を示す事を最終的な目的としている（０００６）。」【】「，『』，例えば９７＋３４という文字列の記述をコンピュータに与えれば『９７』と『３４』は数値として解釈が可能であり，間にある『＋』演算子は左右に 的としている（０００６）。」【】「，『』，例えば９７＋３４という文字列の記述をコンピュータに与えれば『９７』と『３４』は数値として解釈が可能であり，間にある『＋』演算子は左右に並ぶ２つの数値を加算するための記号と解釈可能であり，また。」（【】）式そのものの意味を理解するアルゴリズムは既に存在する００１４「式のデータの解釈とは『１２×（３４＋５６』の文字列を，３４と５，）６を先に加算して，その演算結果と１２を乗算する等，計算の優先順位や手順を式から読み取ることで，この技術は上記にもあるとおり，既存している（００１７）。」【】上記の本願明細書の記載によれば，本願明細書には，本願発明の課題として，大きな桁を扱う数値データで，四則演算のうち加算，減算，乗算においては桁落ちの発生しない手法を示すこと，除算においては任意の算出桁数を指定することにより，納得のいく計算結果を示すことが記載されており，計算を行うことが本願発明の課題であることが認められる。他方，式のデータの解釈は，周知であることが記載されており，本願明細書の他の箇所を参酌しても，式を解釈することについて具体的な記載はない（なお，本願明細書において「桁落ち」とは，計算に用いようとする数値の，桁数が，コンピュータの数値計算において扱うことのできる数値の桁数を超えることを意味すると解される。 。）これに対して，甲７の「②式の解釈について（甲７，３ないし４頁）」との項には「本願発明の意図とする全体のレイアウトは，式を解釈する，機能が幹で，計算を行なう機能は枝葉（甲７，４頁４ないし５行）であ」り，それによって本願発明は実用性を有する旨記載されている。 - 10 -，，，したがって甲７の上記記載部分は本願明細書の記載と整合性がなく本願発明 能は枝葉（甲７，４頁４ないし５行）であ」り，それによって本願発明は実用性を有する旨記載されている。 - 10 -，，，したがって甲７の上記記載部分は本願明細書の記載と整合性がなく本願発明の内容を理解する上で何らかの意味を有するものとはいえない。 ウ甲７の実質的内容は，前記アの「①実数の扱いについて（甲７，２な」いし３頁）との項及び前記イの「②式の解釈について（甲７，３ないし」４頁）との項に記載されているものと認められ，甲７に，その他に本願発明の内容を理解する上で意味のある事項が記載されているとは認められない。 また，甲１２は，甲７の添付資料として提出されたものであり，その記載内容は，甲７に述べられたのと同じ事項を説明したものにすぎず，以上の判断を左右するものとはならない。 ( )以上のとおりであるから，審決が，甲７，甲１２を参酌せずに本願発明 を認定した点に誤りはない。 本願発明と刊行物１記載発明との相違点の看過（取消事由２）について( )データ型に関する相違点について 原告は，刊行物１に「普通の『桁』の概念と，型のは一致しstringindexません（乙１，２６頁）との記載があることから，刊行物１記載発明は，」数字の桁の概念と文字列の概念が一致しておらず，既存の文字列とは異なる新たなデータ型又は規格を必要とするとの前提に立った上で，本願発明は文字列型という既存のデータ型を計算に用いており，数字の桁の概念と文字列の概念とを一致させているのに対し，刊行物１記載発明は新たなデータ型又は規格を必要とする点で相違するにもかかわらず，審決は，この相違点を看過している点で誤りがあると主張する。 しかし原告の上記主張は，採用することができない。その理由は，以下のとおりである。 ア(ア)ａ「プログラマのための るにもかかわらず，審決は，この相違点を看過している点で誤りがあると主張する。 しかし原告の上記主張は，採用することができない。その理由は，以下のとおりである。 ア(ア)ａ「プログラマのための２入門（小山裕徳訳学校法人東Delphi」京電機大学１９９７年（平成９年）３月２０日第１版１刷発行，乙- 11 -２）には，次のとおりの記載がある。 「はアプリケーションを開発するための環DelphiMicrosoftWindows境であり，ツールです（訳者まえがき」の頁１２ないし１３行）。」「「のプログラミング言語は，が基本になっていまDelphiObjectPascalす（５頁２４行）。」「の両方のバージョンとも，変数の型としておよそ１５の標準Delphi型があります。 には（数え方にもよりますが）さらに７Delphi2.0，つの型があります。通常は，の型をいくつかに分類して考えまDelphiす。論理型，文字型，整数型，実数型などです（次の章で説明するよ，）。 ，うにあなた自身で型を定義することもできます以下に示すのはの両方のバージョンで共通な型について概略を説明したものでDelphiす（１１８頁２８行ないし１１９頁２行）。」「（文字列）型の変数は，では２５５字までstringstringDelphi1.0の文字を保持します。一方，では文法オプションのASCIIDelphi 2.0［長い文字列を使う］がオンになっていて，このデフォルトを変更しないかぎり文字数に基本的に制限がないことを意味します（実際の制限は２Ｇバイトですどちらのバージョンでも数字を大かっこ[]，）。 ，でかこって，２５５字より少ない文字を保持するようにすることができます。たとえ 的に制限がないことを意味します（実際の制限は２Ｇバイトですどちらのバージョンでも数字を大かっこ[]，）。 ，でかこって，２５５字より少ない文字を保持するようにすることができます。たとえば，次のようにします。 var[]（１２０頁３０行ないし１２１頁２行）Name: string 45 ;」ｂプログラマのための入門書である乙２に前記ａの記載があることかstringDelphiObjectPascalらすると型がのプログラミング言語である，の変数の型の一種であり，テキストを扱う文字列型であることは，プログラミングの技術分野の当業者であれば一般的な知識として有していたものと認められる。 - 12 -(イ)また，刊行物１（乙１）には，次のとおりの記載がある。 ａ「どうせならば，桁数制限なしに，そのまま四則演算のできる数値型を作ることはできないものなのでしょうか？ 桁数が増えれば，その，，ぶんだけ自動的に長さが延長されてメモリが確保される型というとでは，型が思い当たります。 Delphistring数値をで保持しておけば，桁数がどれほど増えようとおそれるstring（），。 ことはありませんし＊４やに表示することも容易ですlabelEditというような発想でもって，文字列による無限長演算ユニットの製作はスタートしました（２５頁「◇そういうわけで，無限桁数演算。」の可能性を考える」の節）ｂ「データの保持については型と決めていますが，そのまstringstringまでは味気ないので，型という型を定義しました。 TIntStrtypeTIntStr = string;つまり型そのままですが，こうしておくことで，将来何か変更stringするときに他のソースまで書き換える 型という型を定義しました。 TIntStrtypeTIntStr = string;つまり型そのままですが，こうしておくことで，将来何か変更stringするときに他のソースまで書き換える手間を省くことができます」。 （２６頁「◇一般的な定義」の節）」(ウ)前記(ア)の当業者の一般的知識と上記(イ)ａ，ｂの刊行物１の記載によれば，刊行物１記載発明は，のプログラミング言語であるDelphiで記述され，型を数値データの保持に用い，データObjectPascalstring型として使用するものであることが認められる。 イ(ア)ａさらに「[改訂版]入門（青山学著ソフトバンク株式会，」Delphi社１９９６年（平成８年）８月２４日初版発行，乙３）には，次のとおりの記載がある。 「，。 ，typetype文は新しい型を宣言するための予約語です文を使えば任意のデータ型を宣言することができます。 - 13 -◇文の構文typetype=;型名宣言する型たとえば，２０文字の文字列型をという型として新たに登TNamae録したいときには，次のように宣言します。 typeTNamae = String 20 ;[]typeIntegerReal文で型を宣言するとそれを新しい型として型や，，型などの他の組み込み型とまったく同様に，変数の宣言をすることができます。次に，その例を示しておきましょう。 varAoyamaHikari: TNamae;この例では，型，つまり先ほど文で宣AoyamaHikariTNamaetype言した[]という型で宣言したことになります（５４頁１２String。」ないし２７行）ｂプログラマのための入門書である乙３に上 宣AoyamaHikariTNamaetype言した[]という型で宣言したことになります（５４頁１２String。」ないし２７行）ｂプログラマのための入門書である乙３に上記の記載があることからすると，が，においてプログラムで使用する変数に対してtypeDelphi用いられる新しいデータ型を宣言するための予約語であることは，プログラミングの技術分野の当業者であれば一般的な知識として有していたものと認められる。 (イ)前記(ア)の当業者の一般的知識と前記ア(イ)ｂの刊行物１の記載によれば，刊行物１記載発明では，新たな型として型を宣言してTIntStrいるが，型は型と同じ型として宣言しており，型とTIntStrstringTIntStr型が実質的に同じであることは，当業者の一般的知識に照らしてstring明らかである。 ウ原告は，刊行物１に「普通の『桁』の概念と，型のは一致stringindex- 14 -しません（乙１，２６頁）との記載があることから，刊行物１記載発明」は，数字の桁の概念と文字列の概念が一致しておらず，既存の文字列とは，「『』異なる新たなデータ型又は規格を必要とすると主張するが普通の桁の概念と，型のは一致しません」との記載を根拠として，刊stringindex行物１記載発明は，数字の桁の概念と文字列の概念が一致しておらず，既存の文字列とは異なる新たなデータ型又は規格を必要とすると解することはできない。 ，（）。 (ア)すなわち刊行物１乙１の２６頁には次のとおりの記載がある「型は型そのままですので，[ ]という具合にしてアTIntStrstringIntstrクセスすれば，特定の桁の数字をとってくることができます。しか ２６頁には次のとおりの記載がある「型は型そのままですので，[ ]という具合にしてアTIntStrstringIntstrクセスすれば，特定の桁の数字をとってくることができます。しかしなstringがら図２を見ていただければ分かるように普通の桁の概念と，，『』，型のは一致しません。 indexそこで，次のような関数を用意しました（◇桁の数値を取り出す」。」「の節）図２には，左より１から７までの七つの数字が横書きされ，右から三「」「」，「」つ目の が３桁目の数字として指示され左から三つ目の が「[ ]」として指示されている。 Intstr(イ)前記(ア)の刊行物１の記載によれば，刊行物１記載発明において，ある数値から特定の桁の数字を取り出す場合，[ ]（型のIntstrstringindexIntstrIntstr），，は数字列の左から数えて１文字目を[ ]２文字目を[ ]，３文字目を[ ]・・・のように扱うものであり，文字数がｎ Intstr，，，個の数字列では普通の位取りでいう１桁目すなわち１の位の数字は，。 左から数えてｎ文字目であるから[ ]ではなく[ ]に当たるIntstrIntstrnこのように，普通の位取りでいう桁と，左から数えて何文字目にあるかということ（[ ]，型の）は一致せず，このことを，刊Intstrstringindex，「『』，」行物１では普通の桁の概念と型のは一致しませんstringindex- 15 -と記述したものと認められる。 stringindexしたがって，刊行物１の「普通の『桁』の概念と，型のは一致しません」との記載を根拠として， 致しませんstringindex- 15 -と記述したものと認められる。 stringindexしたがって，刊行物１の「普通の『桁』の概念と，型のは一致しません」との記載を根拠として，刊行物１記載発明は，数字の桁の概念と文字列の概念が一致しておらず，既存の文字列とは異なる新たなデータ型又は規格を必要とすると解することはできない。 stringTIntStrエこのように刊行物１記載発明は既存の型と実質的に同じ，，型の文字列型をデータ型として計算に用いており，新たなデータ型又は規格を必要とするものではない。そうすると，本願発明は文字列型という既存のデータ型を計算に用いており，数字の桁の概念と文字列の概念とを一致させているのに対し，刊行物１記載発明は新たなデータ型又は規格を必要とする点で相違するとは認められず，審決に，この相違点を看過しているという誤りがあるとの原告の主張は，採用することができない。 ( )プログラム言語に関する相違点について 原告は，本願発明は特定のプログラム言語に依存しないように配慮しているのに対し，刊行物１記載発明はという特定のプログラム環境で動Delphi作するものである点で相違しているが，審決は，この相違点を看過しているという誤りがあると主張する。 しかし，原告の上記主張は，採用することができない。その理由は，以下のとおりである。 すなわち，本願発明は，もともと特定のプログラム言語に依存することのない「人が数値として解釈できる，コンピュータ内部で保持する文字列デ，ータを，そのまま計算対象の数値として扱い演算する手段」との技術思想。 であり，いかなるプログラム言語によるものであっても，上記の技術思想を実現するものであれば，本願発明と同一の発明と認められ，採用されているプログラム言語が 値として扱い演算する手段」との技術思想。 であり，いかなるプログラム言語によるものであっても，上記の技術思想を実現するものであれば，本願発明と同一の発明と認められ，採用されているプログラム言語が何かということは，本願発明の技術思想の実現の有無とは直接の関係がないものと解される。そうすると，審決が，本願発明と刊行物- 16 -１記載発明の対比において，本願発明は特定のプログラム言語に依存しないように配慮しているのに対し，刊行物１記載発明はという特定のプDelphiログラム環境で動作するものである点を相違点として挙げなかった点に誤りはない。 顕著な作用効果の看過（取消事由３）について( )桁落ちに関する作用効果の看過について ，「」（，）原告は刊行物１の型ととの変換の節乙１２７頁TIntStrIntegerに記載されているように，刊行物１記載発明は，既存のデータ型が扱える範囲の数値しか扱っていないから，桁落ちを解決するという効果を奏し得ない，，とした上で本願発明は文字列数値をそのまま計算対象とすることによって桁落ちを解決するという顕著な効果を奏するが，刊行物１記載発明はそのような効果を奏し得ず，審決は，このような本願発明の顕著な作用効果を看過した点で誤りがあると主張する。 しかし，原告の上記主張は，採用することができない。その理由は，以下のとおりである。(なお「桁落ちを解決する」とは，コンピュータの数値計，算において扱うことのできる数値の桁数に制限がないようにすることを意味すると解される）。 ア(ア)刊行物１の「型ととの変換」の節には，次のとおりTIntStrIntegerの記載がある。 「型は独自に計算ルーチンを持っていて，独立して数値を保持TIntStrしますが，そうは (ア)刊行物１の「型ととの変換」の節には，次のとおりTIntStrIntegerの記載がある。 「型は独自に計算ルーチンを持っていて，独立して数値を保持TIntStrしますが，そうはいっても既存の型とやりとりができないと役にたちません。 の数値をに代入したり，型の数値をとして返Int64TIntStrTIntStrInt64す関数を作成しました。 当然，お互い桁あふれが生じない範囲であることが前提です。 ，，Int64Integerintegerはと代入互換性がありますので普通のの数値も- 17 -この関数でに変換することができます（乙１，２７頁）TIntStr。」(イ)前記(ア)の記載によれば，そのうちの「当然，お互い桁あふれが生じない範囲であることが前提です」との記載は，変換元又は変換先の。 数値が桁あふれを生じる場合には正しくデータ型の変換ができないことについて注意を喚起しているものと認められ，刊行物１記載発明が大きな桁数の数値を常に扱わないとの趣旨の記載であるとは認められない。 イ(ア)また，刊行物１には，次のとおりの記載がある。 「このような大きな数値の演算は，科学技術計算の分野では頻繁に出てきており，この場合の数値の扱いについても「多倍長計算」というアルIntegerIntegerゴリズムが確立されています。つまり，で足りなければをふたつもってきてで数値を表そう，それで足りなければ４つで64bit，８つでという具合にして，を複数持ってくるこ128bit256bit...integerとによって演算を行うわけです。 この手法は，桁上がりの部分だけをチェックすれば残りの部分は普通の計算で処理することができるため，計算効率に優れており，多くの分野で利用されてい ..integerとによって演算を行うわけです。 この手法は，桁上がりの部分だけをチェックすれば残りの部分は普通の計算で処理することができるため，計算効率に優れており，多くの分野で利用されています。しかし，実際に使用するには，特殊な数値の型を利用する必要があったり，計算できる桁数に制限があったりして，普通の思考でそのまま計算するには，何かと不便な点が多くあります」。 （「，」，，）◇パソコンにおけるアップル社購入の計算の節乙１２５頁，(イ)刊行物１の前記(ア)の記載及び前記２( )ア(イ)ａの記載によれば 刊行物１記載発明は，大きな数値の演算には，桁数の制限があったり，特殊な数値の型を利用する必要があるとの問題点があったので，これらの問題点を解決するために，桁数の制限なしに普通の思考でそのまま四則計算できる数値型として文字列型（の型）を用いるといDelphistringう発想のもとに製作されたことが認められる。 そうすると，刊行物１記載発明は，文字列型（の型）をDelphistring- 18 -用いることにより，桁落ちを解決する，すなわちコンピュータの数値計算において扱うことのできる数値の桁数に制限がないようにするとの作用効果を奏するものと認められる。 ウこのように，刊行物１記載発明は，文字列型（の型）を用Delphistringいることにより，桁落ちを解決する，すなわちコンピュータの数値計算において扱うことのできる数値の桁数に制限がないようにするとの作用効果を奏するから，本願発明が，文字列数値をそのまま計算対象とすることによって桁落ちを解決するという効果を奏するとしても，それは，顕著な作用効果であるとはいえない。 ( )相互変換のための関数を作成する必要性等に関する作用効果 文字列数値をそのまま計算対象とすることによって桁落ちを解決するという効果を奏するとしても，それは，顕著な作用効果であるとはいえない。 ( )相互変換のための関数を作成する必要性等に関する作用効果の看過につ いて原告は，本願発明は，既存のデータ型である文字列型をそのまま計算に用いているので，文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果，計算の入出力を文字列として行えるという効果，新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果及び様々なコンピュータで利用ができるという効果を奏するものであるが，審決は，これらの顕著な作用効果を看過している点で誤りがあると主張する。 しかし，原告の上記主張は，採用することができない。その理由は，以下のとおりである。 ア文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果について(ア)文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという点は，本願発明の作用効果ということができないのみならず，仮にそのような効果があると解する余地があるとしても，その効果を顕著な作用効果とみることはできない。 - 19 -，，，まず以下のとおり特許請求の範囲及び本願明細書の記載によれば文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果は，本願発明によって必然的にもたらされる作用効果とはいえない。 すなわち，本願明細書には，数値のデータ型に関連して「このとき，の計算手段は，それぞれ縦１桁の数値だけを対象として行うため，文字型から整数型へ変換して計算し，必要な結果内容を文字型に変換して④ 。 すなわち，本願明細書には，数値のデータ型に関連して「このとき，の計算手段は，それぞれ縦１桁の数値だけを対象として行うため，文字型から整数型へ変換して計算し，必要な結果内容を文字型に変換して④のエリアに置いていく方法も考えられる（００２９）との記載，。」【】及びＩＥＥＥ規格等の数値データから文字列データに変換すること （【０３３】ないし【００３５）の記載はあるものの，文字列型と整数型】及び実数型との相互変換のための手段についての記載はない。そうすると，本願発明は，文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する技術を排除しているとは解されず，そのことからすると，文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを作成する必要がないという効果は，本願発明の作用効果と解することはできない。 (イ)のみならず，仮に，文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果があったとしても，同効果は，以下のとおり，刊行物１記載発明から予測可能な程度のものにすぎず，顕著な作用効果とはいえない。 すなわち，刊行物１には，次のとおりの記載がある。 「型は型そのままですので，[ ]という具合にしてアTIntStrstringIntstrクセスすれば，特定の桁の数字をとってくることができます。しかしなstringがら図２を見ていただければ分かるように普通の桁の概念と，，『』，型のは一致しません。 indexそこで，次のような関数を用意しました。 - 20 -，。 getdigitTIntStrKetaは型の数値から桁目の数値をとってくる関数です返り値はとなっていますが，これはTdigitTd のような関数を用意しました。 - 20 -，。 getdigitTIntStrKetaは型の数値から桁目の数値をとってくる関数です返り値はとなっていますが，これはTdigitTdigit = 0..9;と定義されています。 functiongetdigitN:TIntStr;Keta:integer :Tdigit;()beginifKetalengthNorKetathenresult :=(>( ))(< )elseresult := StrToIntDefCopyN,lengthN -Keta+1,1 ,0 ;((( )) )（乙１，２６頁「◇桁の数値を取り出す」の節）end;」「符号の問題をここで片づけてしまうことにより，，IntStrAddPositiveといった関数の中では，引数が正の数であると想定しIntStrDecPositiveて処理を行うことができます。 符号の問題を片づけてしまえば，あとは小学校一年生で習った足し算を忠実に実行して行くだけです。 一番下の位から，各桁の数値を足して，繰り上がりの数があれば覚えておいて，次の桁に足す，この繰り返しです。 は（型（判決注：型」の誤りと認められresultTIntStr=stirng=string）「（）る）ですので，()は足し算で。 result := InttoStrcalcResultmod+ result;はなくて文字列の追加になるところに注意してください。 (){}functionIntStrAddPositiveN1, N2:TIntStr :TIntStr;N1+N2vari,calcResult,N1Length,N2Length (){}functionIntStrAddPositiveN1, N2:TIntStr :TIntStr;N1+N2vari,calcResult,N1Length,N2Length:integer;Carry:Tdigit;beginresult := '';N1Length := lengthN1 ;()- 21 -N2Length := lengthN2 ;()Carry := 0;i:=1;whilei =N1Lengthori =N2Lengthdo( <)( <)begincalcResult := getdigitN1,i +getdigitN2,i+ Carry;()()Carry := calcResultdiv 10;result := InttoStrcalcResultmod+ result;()Inci ;( )end;ifCarry 0 thenresult := InttostrCarry+ result;>()（乙１，２８ないし２９頁「◇足し算」の節）end;」(ウ)前記(イ)の記載によれば，刊行物１記載発明においては，関数IntStrAddPositiveN1,N2:TIntStrTIntStrN1N2()が型の二つの引数及びN1N2N1を取り及びはともに正の整数であることが想定されており，，を被加数，を加数として加算を行い，加算の結果を型で返すN2TIntStrものであることが認められ，との加算は，小さい桁から１桁ずN1N2つ順番に行われ，１桁の加算を行う際には，その桁の数字を一度整数型のデータに変換して加算してから，結果を文字列型に再変換してい ものであることが認められ，との加算は，小さい桁から１桁ずN1N2つ順番に行われ，１桁の加算を行う際には，その桁の数字を一度整数型のデータに変換して加算してから，結果を文字列型に再変換していることが認められる。 そして「プログラマのための２入門（乙２，１３６頁）に，」DelphiDelphiよれば，刊行物１記載発明の上記の演算の過程で用いられているの関数について，関数（乙２，１３６頁の表の機能欄のStrToIntDef「」との表記は「」を意味するものと認めらStringToIntDefStrToIntDef，れる）は，整数を表現する文字列を，その数値（整数型データ）に変。 - 22 -換し，文字列が正しい数字の表現でないときにはデフォルトの値にする関数であり，は，整数を文字列に変換する関数であることが認IntToStrめられ，そのため，刊行物１記載発明は，文字列型と整数型の相互変換のための関数としてに標準的に備えられた関数を用いているこDelphiとが認められる。 そうすると，刊行物１記載発明は，既存のデータ型である文字列型（の型）を用いており，文字列型と整数型及び実数型とのDelphistring相互変換のための関数や型変換プログラムを別途作成する必要はないものと認められる。したがって，文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果は，刊行物１記載発明から予測可能な程度のものにすぎず，顕著な作用効果とはいえない。 イ計算の入出力を文字列として行えるという効果について刊行物１には「数値をで保持しておけば，桁数がどれほど増え，stringようとおそれることはありませんし（＊４，やに表示すること）labelEditも容 として行えるという効果について刊行物１には「数値をで保持しておけば，桁数がどれほど増え，stringようとおそれることはありませんし（＊４，やに表示すること）labelEditも容易です（乙１，２５頁「◇そういうわけで，無限桁数演算の可能性。」を考える」の節）と記載されている。 そして「プログラミング入門（玉木彰著２００１年（平成１，」Delphi３年）４月５日初版第１刷発行，乙４）には「コンポーネント」，Label及び「コンポーネント」が，文字列（）を表示出力するためのEditstringものであることが記載されている（乙４，３０ないし３１頁。 ）そうすると，刊行物１記載発明は，型で保持した数値をそのままstring。 ，の形で出力することを想定しているものであると認められるしたがって計算の入出力を文字列として行えるという効果は，顕著なものではなく，刊行物１記載発明から予測可能な程度のものにすぎない。 ウ新たなデータ型や規格を国際標準として採用させる手間が不必要である- 23 -という効果及び様々なコンピュータで利用ができるという効果について刊行物１には，前記のとおり，文字列型を用いた無限長の数値演算について，のというプログラム言語で組まれたプログラムDelphiObjectPascalDelphiObjectリストが記載されているそして乙２ないし５によればの。 ，，の言語仕様は公開され，周知である。さらに，前記のとおり，刊行Pascal物１記載発明のプログラムリストの文字列型は，の標準デーObjectPascalタ型である型と同一型の型である。 stringTIntStrそうすると，当業者は，刊行物１記載のプログラムリストを読むことにより，刊行物１ 字列型は，の標準デーObjectPascalタ型である型と同一型の型である。 stringTIntStrそうすると，当業者は，刊行物１記載のプログラムリストを読むことにより，刊行物１記載発明のアルゴリズムを理解し，その実施ができるものであって，そのためにアルゴリズム及び特殊なデータ型を必要としない。 また，刊行物１記載のプログラムリストを読むことにより，刊行物１記載発明のアルゴリズムを理解することができることから，そのアルゴリズムを種々のプログラム言語でプログラムし直すことは，当業者であれば適宜になし得る設計事項であり，それによって刊行物１記載発明を様々なコンピュータで利用することもできる。そのため，刊行物１記載発明の利用を広めるために，新たなデータ型や規格を国際標準として採用させる必要もない。 したがって，新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果及び様々なコンピュータで利用ができるという効果は，顕著なものではなく，刊行物１記載発明から予測可能な程度のものにすぎない。 エしたがって，本願発明が，文字列型と整数型及び実数型との相互変換のための関数や型変換プログラムを別途作成する必要がないという効果，計算の入出力を文字列として行えるという効果，新たなデータ型や規格を国際標準として採用させる手間が不必要であるという効果及び様々なコンピュータで利用ができるという効果を奏するものであるとしても，これらは- 24 -顕著な作用効果であるということはできず，審決に，これらの顕著な作用効果を看過したとの誤りはない。 本願発明と刊行物２記載発明との相違点の看過（取消事由４）について原告は，本願発明は桁落ちを防ぐために文字列型のまま計算をするものであるのに対し，刊行物２記載発明は文字列型のまま計算を はない。 本願発明と刊行物２記載発明との相違点の看過（取消事由４）について原告は，本願発明は桁落ちを防ぐために文字列型のまま計算をするものであるのに対し，刊行物２記載発明は文字列型のまま計算をするものではない点において相違するにもかかわらず，審決は，同相違点を看過している点で誤りがあると主張する。 しかし，原告の上記主張は，採用することができない。 審決は，念のため，本願発明と刊行物１記載発明とが「人からコンピュータに与える式のデータを解釈するプログラム」を備えているか否かとの点において相違しているとしても，同相違点に係る事項は，刊行物１記載発明に刊行物２記載発明を適用することによって，当業者が容易に想到し得ると判断した。 すなわち，刊行物２記載発明は，本願発明と刊行物１記載発明との間の前記相違点に係る事項が容易に想到し得ることを示すために用いられたものであるから，本願発明と刊行物２記載発明の相違点を認定しなかったからといって，何ら審決の判断に違法を来すことはない。したがって，この点の原告の主張は，主張自体失当である。 結論 以上のとおり，原告主張の取消事由はいずれも理由がない。原告は，その他縷々主張するが，審決にこれを取り消すべきその他の違法もない。 よって，原告の本訴請求を棄却することとし，主文のとおり判決する。 知的財産高等裁判所第３部- 25 -裁判長裁判官飯村敏明裁判官中平健裁判官上田洋幸
▼ クリックして全文を表示