戻る

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

戻る