運営:アスタミューゼ株式会社
  • ポートフォリオ機能


追加

この判例には、下記の判例・審決が関連していると思われます。
審判番号(事件番号) データベース 権利
平成17ワ23171損害賠償等請求事件 判例 不正競争防止法
平成13ワ26301損害賠償等請求事件 判例 不正競争防止法
昭和60ワ4131秘密保持義務存在確認等請求事件 判例 不正競争防止法
平成16ワ25297営業行為差止請求事件 判例 不正競争防止法
平成15ワ5711営業差止等請求事件 判例 不正競争防止法
関連ワード 信義則 /  類似性(類似) /  記憶 /  差止請求(差止) /  営業上の利益 /  過失 /  組成した物 /  弁護士費用 /  侵害 /  代理人 /  秘密管理(秘密管理性) /  秘密保持義務 /  有用性 /  非公知性 /  営業秘密 /  2条1項7号 /  プログラム /  不正の利益を得る目的(図利目的) /  他人に損害を加える目的(加害目的) /  損害賠償 / 
元本PDF 裁判所収録の全文PDFを見る pdf
事件 平成 17年 (ワ) 12938号 不正競争行為差止等請求事件
栃木県足利市(以下略)
原告栃木県トーションレース協同組合
訴訟代理人弁護士塚越敏夫
訴訟代理人弁理士工藤一郎
補佐人弁理士渡邉直幸 群馬県桐生市(以下略)
被告A
訴訟代理人弁護士白田佳充
同 久保田寿栄
裁判所 東京地方裁判所
判決言渡日 2006/12/13
権利種別 不正競争
訴訟類型 民事訴訟
主文 1請求第2項記載の訴えをいずれも却下する。
2原告のその余の請求をいずれも棄却する。
3訴訟費用は原告の負担とする。
事実及び理由
全容
第1請求1被告は,別紙物件目録記載のソフトウェアを製造し,使用し,譲渡し(電気通信回線を通じた提供を含む。),貸し渡し,又は譲渡若しくは貸渡しのために展示してはならない。
2(1)被告は,上記1の侵害行為を組成した物(侵害の行為により生じた物を含む。)を廃棄し,かつ,侵害の行為に供した設備を除却せよ。
(2)被告は,上記1の侵害の停止又は予防に必要な行為をせよ。
3被告は,原告に対し,次の金員を支払え。
(1)1349万3000円及びこれに対する平成15年11月20日から支払済みまで年5%の割合による金員,(2)130万円及びこれに対する平成17年7月7日から支払済みまで年5%の割合による金員第2事案の概要本件は,トーションレース(ゆるく縒った麻糸・綿糸で編んだ目の粗いレース)の編み機用ソフトウェアの著作権等を有する原告が,ソフトウェア開発会社の社員として原告のソフトウェアを開発した後,個人で第三者用に同様のソフトウェアを開発して譲渡した被告に対し,@原告の営業秘密であるアルゴリズムを使用したものであり,不正競争防止法2条1項7号の不正競争行為に当たる,A被告が勤務していたソフトウェア開発会社との信義則上の秘密保持義務に違反している,B原告の有するプログラム著作権(複製権又は翻案権)を侵害している,C原告が有する画面表示の著作権(複製権又は翻案権)を侵害していると主張して,不正競争防止法3条(上記@),原告とソフトウェア開発会社との開発委託契約に基づく請求権を代位債権とする債権者代位権の行使(上記A)又は著作権法112条(上記B及びC)に基づき,ソフトウェアの製造差止め等を求めるとともに,不正競争防止法4条(上記@)又は著作権侵害の不法行為(上記B及びC)に基づく損害賠償を請求した事案である。
1前提事実(1)当事者。 ア原告は,トーションレースの製造販売業者が設立した事業協同組合であるイ被告は,株式会社両毛システムズ(以下「両毛システムズ」という。)に勤務し,ソフトウェア開発を担当していたが,平成9年6月30日,同社を退社した。
(以上,争いのない事実,弁論の全趣旨)(2)原告ソフト開発の経緯ア原告は,平成8年8月,両毛システムズに対し,トーションレースの編み機を制御するためのソフトウェアの開発を委託した(以下,この契約を「本件開発委託契約」という。)。
(争いのない事実)イ本件開発委託契約には,以下の定めがある。
「(総則)第1条甲(注:原告)は,トーションレースソフトウェア開発(以下対象物件といい,対象物件作成の業務を対象業務という)を乙(注:両毛システムズ)に委託し,乙は,これを受託し付則に定めた委託業務を履行するものとする。
(秘密の保持)第9条乙は,この契約の履行により知り得た委託業務の内容を第三者に漏らしてはならない。
(目的外使用の禁止)第10条乙は,この契約の履行に必要な委託業務の内容を他の用途に使用してはならない。
(著作権の譲渡等)第11条この契約により作成される対象物件(「多少物件」は,誤記と認める。)の著作権等の取り扱いは,次の各号に定めるところによる。
(1)乙は,著作権法に基づく複製権,貸与権,翻訳権・翻案権等及び二次的著作物の利用に関する原著作者(「源著作者」は,誤記と認める。)の権利を,甲に無償で譲渡するものとする。
(2)(略)」(甲1)ウ被告は,両毛システムズにおいて,上記ソフトウェア開発に責任者として関与し,平成9年3月ころ 「トーションレースシステムVersion 2.0」(以下「原 ,告ソフト」という。)の開発を完了した。
(争いのない事実)(3)ア原告ソフトは,プログラムの著作物(著作権法10条1項9号)である。
イ原告は,本件開発委託契約11条(1)に基づき,原告ソフトの著作権を有する。
(以上,争いのない事実)(4)被告は,両毛システムズを退職後の平成11年,トーションレースの編み機を製造販売している株式会社市川鉄工(以下「市川鉄工」という。)の委託により,その制御用ソフトウェアの開発に着手し,平成12年,完成の上納品した(以下,そのソフトウェアを「市川ソフト」という。)。
(乙6,7,弁論の全趣旨)。
2争点(1)営業秘密としてのアルゴリズムの不正使用(2)債権者代位権に基づく差止請求(3)プログラム著作権(複製権又は翻案権)の侵害(4)画面表示の著作権(複製権又は翻案権)の侵害(5)原告の損害3争点に関する当事者の主張(1)営業秘密としてのアルゴリズムの不正使用ア原告の主張(ア)原告アルゴリズムの内容原告ソフトには,原告ソフトの主要機能である@糸の交差位置におけるテンション量に基づいて糸の移動軌跡を計算する処理,A計算した移動軌跡に基づいてトーションレースの図柄を表示する処理,Bトーションレースの図柄のデータを編機用のデータに変換する処理などを具現化するために,別紙「アルゴリズムに関する当事者の主張」原告の主張のとおりのアルゴリズム(以下「原告アルゴリズム」という。)が使用されている。
(イ)営業秘密該当性a秘密管理性原告アルゴリズムに基づいて作成された原告ソフトのソースコード(以下「原告ソースコード」という。)は,原告の代表理事のみが管理し,利用希望の組合員に対しては,ソースコードではなく,原告ソフトのインストール用プログラムファイルが記録されているフロッピーディスクを貸与してインストールさせていた。
b有用性原告アルゴリズムを具現化した原告ソフトは,糸の張力を考慮した実際の編み柄図を画面上に表示するシミュレーション機能により,試し編みという余分な工程を省略したり,組織図データの誤りなどをコンピュータ上で修正したりすることが可能となり,原告ないしその組合員の事業活動において,費用の節約,経営効率の改善等に役立つものである。
c非公知性原告ソフトは,上記aのとおり,原告の代表理事が管理し,一般に入手できないから,原告アルゴリズムも一般に知られていない。
(ウ)示された点a原告は,原告ソフトの開発に当たり,被告と綿密な打合せを行い,糸の太さや張力によってどのような図柄が実際に編み上がるかなど,トーションレースのシミュレーションを行う際の注意点を具体的に教示した(甲21の1〜20)。
よって,原告は,被告に対し,原告アルゴリズムの基礎となる内容を示しており,営業秘密たる原告アルゴリズムを示したといえる。
b仮に,被告が独力で原告アルゴリズムを創作したとしても,その創作は職務としてされたものであり,原告アルゴリズムは本件開発委託契約9条及び10条にいう委託業務の内容に含まれるから,被告は,営業秘密たる原告アルゴリズムを示されたといえる。
(エ)原告アルゴリズムの使用被告は,別紙「アルゴリズムに関する当事者の主張」原告の主張のとおり,原告アルゴリズムを使用して,市川ソフトのソースコード(以下「市川ソースコード」という )の作成のためにアルゴリズム(以下「市川アルゴリズム」という。)を作 。
成し,それに基づき市川ソースコードを作成し,市川鉄工に譲渡した。
(オ)図利加害目的上記(エ)の使用は,原告ソフトと同一の機能を有する市川ソフトを利用して不正の利益を得る目的でされた。
(カ)営業上の利益侵害上記(イ)aのとおり,原告は,原告ソフトを組合員にのみ貸与していたところ,被告が同一の機能を有する市川ソフトを作成し,これが流通したことにより,原告の営業上の利益侵害され,又は侵害されるおそれがある。
イ被告の主張(ア)原告アルゴリズムの内容被告の主張は,別紙「アルゴリズムに関する当事者の主張」被告の主張のとおりである。
(イ)営業秘密該当性原告の主張(イ)aは不知,bは認め,cは否認する。
(ウ)示された点a原告の主張(ウ)aのうち,原告が原告ソフトの開発に当たり,被告と打合せを行ったことは認め,その余は否認する。
原告アルゴリズムは,被告が作成したものであり,原告から示されたものではない。原告が被告と行ったのは,原告ソフトの機能の打合せにすぎない。
b同bは否認する。
(エ)原告アルゴリズムの使用被告の主張は,別紙「アルゴリズムに関する当事者の主張」被告の主張のとおりである。
(オ)図利加害目的原告の主張(オ)は否認する。
(カ)営業上の利益侵害原告の主張(カ)は否認する。
(2)契約に基づく差止請求権の代位行使の可否ア原告の主張(ア)被告は,両毛システムズに対し,信義則上,同社に在職中知り得た秘密を保持する義務を負っている。
(イ)原告は,両毛システムズに対し,本件開発委託契約に基づき,秘密保持ないし目的外使用の禁止請求権を有している。
(ウ)ソフトウェアの開発は,アルゴリズムの作成及びアルゴリズムに基づくソースコードの作成を含むから,本件開発委託契約9条の「知り得た委託業務の内容」には,原告アルゴリズムが含まれる。
(エ)原告は,上記(イ)の請求権に基づき,債権者代位権の行使として,被告に対し,請求第1項及び第2項の請求をする。
イ被告の主張(ア)原告の主張(ア)は否認する。
(イ)原告の主張(イ)は否認する。
(ウ)原告の主張(ウ)は否認する。
プログラムの開発業者が想到したプログラミングの手法や創作したアルゴリズムは,ソフトウェア開発における直接的な業務内容ではなく,本件開発委託契約9条の「知り得た委託業務の内容」に含まれない。
(エ)原告の主張(エ)は争う。
(3)プログラム著作権の侵害の成否ア原告の主張(ア)類似性以下のとおり,市川ソースコードは,原告ソースコードに類似している。
aデータ構造の類似(a)原告ソフトにおいては,インスタンス変数(以下,単に「変数」ということがある。)であるm_ViewHGが,別紙「アルゴリズムに関する当事者の主張」図1の組織図を表わす1次元の配列を指している。この1次元の配列は,m_Spin*4*m_Maisu*2のバイト数の長さを有する(ここでは,長さなどの管理データの部分はないものとする。)。これにより,同図10のように,各行に4バイトの領域がm_Spin個並び,そのような行がm_Maisu*2個からなる2次元の配列が表現される。
(b)また,原告ソフトにおいては,変数であるm_TenshonHGが,糸の交点の座標を格納するための1次元の配列を指している。この1次元の配列は,m_ViewHGの指す1次元の配列と同じく,m_Spin*4*m_Maisu*2のバイト数の長さを有し,各行に4バイトの領域がm_Spin個並び,そのような行がm_Maisu*2個からなる2次元の配列が表現される。ただし,各行の4バイトの領域は,2バイトずつのshort型の2つの小領域から構成され,糸の交点のX座標,Y座標の値がそれぞれの小領域に格納される。
(c)一方,市川ソフトにおいては,SampleCreate()の記述から,変数m_SampleCurrentは,(m_CurrentSize.cx * 3 + 8) * course * 2のバイト数を有する1次元配列を指すと認められる。SamplePoint()の記述から,この1次元配列は,各行が,まず8バイトの領域の後に,3バイトを1単位とする領域がm_CurrentSize.cx個並び,そのような行がcourse * 2個からなる2次元の配列を表現している。
(d)また,市川ソフトにおいては,変数m_SamplePointは,SamplePoint()の記述から,sizeof (CPoint) * m_SampleCurrentSize.cx * m_sampleCurrentSize.cy * 2のバイト数を有する1次元配列を指すと認められる。この1次元配列は,CPointクラスのインスタンスが m_SampleCurrentSize.cx 個並ぶ行が,m_sampleCurrentSize.cy * 2個からなる2次元配列を表わしていると認められる。各行に並ぶCPointクラスのインスタンスは,交点のX座標,Y座標を格納するのに用いられている。
(e)したがって,以下の対応関係が認められる。
原告ソフト市川ソフトm_ViewHGm_SampleCurrentm_TenshonHGm_SamplePointm_Spinm_SampleCurrentSize.cxm_Maisucourse及びm_sampleCurrentSize.cy(f)上記箇所において,原告ソフトと市川ソフトは,いずれも,2次元の並びを1次元の配列というデータ構造で表現している。
(g)相違点の第1として,原告ソフトでは,m_ViewHGが4バイトの領域の並びにより構成される2次元配列を表わすのに対し,市川ソフトでは,m_SampleCurrentの各行が8バイトの領域を持ち,3バイトを1単位とする領域の並びにより構成される2次元配列を表わしている。
相違点の第2としては,原告ソフトでは,m_TenshonHGがshort型の2つの値を持つ小領域の並びにより構成される2次元配列を表わすのに対し,市川ソフトでは,m_SamplePointがCPointクラスのインスタンスの並びにより構成される2次元配列を表わしている。
(h)しかし,第1の相違点については,別紙「アルゴリズムに関する当事者の主張」図9に示すように,原告ソフトでは,m_ViewHGの指す配列を構成する各領域は3つの値を持つことから,4バイトの領域の並びから構成されるか,それとも3バイトを1単位とする領域の並びから構成されるかは,大きな違いとは認められない。
(i)第2の相違点については,CPointクラスのインスタンスは,SamplePoint()における CPointクラスのコンストラクタの呼ばれ方からすると,2つの値を持つことから,short型の2つの値を持つ小領域か,それともCPointのクラスのインスタンスからなるかも大きな違いとは認められない。
bその他の類似点(a)その他の類似点は,別紙「アルゴリズムに関する当事者主張」原告の主張2のとおりである。
(b)また,原告ソースコードでも,市川ソースコードでも,インスタンス @変数には,すべて「m_」との接頭辞が付いている。
また,市川ソースコードでは,SamplePointMove関数からSamplePointMov Ae_Exec関数が呼ばれているが,原告ソースコードでも,TenshonDataFosei関数からTenshonDataFoseiExec関数が呼ばれている。
このように,原告ソースコードと市川ソースコードとは 「m_」との接 B ,頭辞及び「Exec」との接尾辞の使い方において類似している。
(c)市川ソースコードのSamplePoint関数において,m_SampleCurrentは組 @織図を表わすデータを指していると考えられるが,原告ソースコードと同じようにバイト列である。
原告ソースコードと市川ソースコードとは,この点でも類似している。 A被告は,データをバイト列に入れることは,一般的な手法であると反論 Bするが,ここで問題にしているのは,プログラミング言語上の表現である。例えば,組織図は,2次元に広がる図形として認識され,これをプログラミング言語で表現する場合,素直に表現するのであれば,2次元配列を用いる。しかし,原告ソフトでは,m_ViewHG という1次元配列を用いており,市川ソフトでも,m_SampleCurrent という1次元配列を用いている。C++ 言語であれば,2次元配列よりも更に操作のしやすいデータ構造をプログラミング時に定義できるにもかかわらず,被告は,全くそのようなことをしていない。
(イ)依拠被告は,原告ソフトに依拠して,市川ソフトを作成した。
(ウ)故意又は過失被告は,原告の著作権を侵害することにつき,故意又は過失があった。
(エ)まとめ以上のとおり,市川ソフトは,原告ソフトのプログラム著作権(複製権,翻案権)を侵害する。
イ被告の主張(ア)類似性aデータ構造の類似(a)原告の主張(ア)a(a)は認める。
(b)同(b)は認める。
(c)同(c)は認める。
(d)同(d)は認める。
(e)同(e)は認める。
(f)同(f)は認める。
(g)同(g)は認める。
(h)同(h)は否認する。
原告ソフトにおけるm_ViewHGの指す配列を構成する領域と市川ソフトにおけるm_SampleCurrentの指す配列を構成する領域は,両方とも組織図データを格納する領域で,糸の黒丸の情報,交差位置の右側の糸情報,交差位置の左側の糸情報の3種類のデータを取り扱うものであり,2次元の配列に関する3種類のデータを格納するだけの内容では,プログラムとして異なった記述をすることは難しい。その中で,原告ソフトでは4バイト,市川ソフトでは3バイトを使用していること自体が大きな違いである。
また,原告ソフトは,単にこの3種類のデータを管理しているのに対し,市川ソフトでは,先頭の8バイトの付加データに繰り返しの指示に使用するタグ,編み機のスピード,巻き取り停止,機械停止の4種類のデータを付加しているのであり,組織図を格納するデータ領域にも違いが認められる。
(i)同(i)は否認する。
データを処理する場合,2次元配列を使用すると処理速度が遅くなるので,処理速度を上げるため1次元配列のように考えて処理することは,一般的なプログラミングの手法であり,これをもってデータ構造が類似しているとはいえない。
bその他の類似点(a)原告の主張(ア)b(a)に対する被告の認否は,別紙「アルゴリズムに関する当事者の主張」被告の主張2のとおりである。
(b)同(b)のうち,及びは認め,は否認する。 @AB「m_」との接頭辞及び「Exec」との接尾辞の使い方は,単に名前の付け方にすぎない。
(c)同(c)のうち,は認め,は否認する。 @Aデータをバイト列に入れることは,プログラムを書く上で一般的な手法であるし,前記a(i)のとおり,処理速度を上げるために2次元の並びを1次元の配列というデータ構造で表現することも一般的な手法である。
(イ)依拠原告の主張(イ)は否認する。
両毛システムズにおいて原告ソフトを作成する際,原告との打合せ及びソフトの基本設計は,被告が行ったが,実際のプログラミングは,他の2名の従業員と分担し,被告は主にテンション図の作成を行った。そして,被告は,両毛システムズを退職する際,原告ソフト開発時に作成した資料等を全く持ち出していないし,現在その内容を再現することもできない。
(ウ)故意又は過失原告の主張(ウ)は否認する。
(エ)まとめ原告の主張(エ)は争う。
(4)画面表示の著作権の侵害の成否ア原告の主張(ア)画面表示の内容原告ソフトの画面表示(甲10のD)では,縦横の升目状のシートが表示され,スピンドルが交差し得る位置を表示する小さな黒斑点が中央部分に表示されている升目と,黒斑点がない升目とが市松模様状に整然と表示されている。
黒斑点の部分を市松模様状に表示することで,対応する糸掛図(甲10のB)を表示する際に,糸の交差状態を整然かつ明瞭に表示させることができる。
また,黒斑点の升目にてスピンドルを交差させる処理を表示する場合には,楕円状の黒丸が表示される(甲10のC)が,黒丸を表示すると黒斑点は視認できないため,この場合も整然とした様子を観者に与えることができる。
(イ)創作性上記(ア)の画面表示には,創意工夫による表現上の特徴があり,創作性がある。
(ウ)類似性市川ソフトの画面表示(甲11B,C)は,中央部に黒斑点がある升目とない升目とが市松模様状に表示されたり,黒斑点が黒丸で覆われる様子が表されており,原告ソフトの画面表示と酷似している。
(エ)依拠被告は,原告ソフトに依拠して,市川ソフトを作成した。
(オ)故意又は過失被告は,原告ソフトと同様の画面表示となることを知っていたものであり,故意又は過失があった。
イ被告の主張(ア)原告の主張(ア)(画面表示の内容)は認める。
(イ)原告の主張(イ)(創作性)は否認する。
原告の主張するシートや組織図の画面表示は,原告ソフトが作成される以前のトーションレース編み機用ソフトウェア,更に遡れば手書き時代に使用されていたのと同じものであり,創作性は認められない。
(ウ)原告の主張(ウ)(類似性)は明らかに争わない。
(エ)原告の主張(エ)(依拠性)及び(オ)(故意又は過失)は否認する。
(5)原告の損害ア原告の主張(ア)原告は,被告の行為により,少なくとも原告ソフトの開発委託代金の支出が全く無意味になったため,その代金額1349万3000円と同額の損害を被った。
(イ)弁護士費用の損害として,130万円が相当である。
イ被告の主張原告の主張は,いずれも否認する。
第3当裁判所の判断1争点(1)(営業秘密としてのアルゴリズムの不正使用)について(1)請求内容について原告は,不正競争防止法2条1項7号,3条2項に基づき,侵害の停止又は予防に必要な措置として,請求第2項記載の行為を求めているが,その請求内容が特定されていないから,これらの訴えは,不適法なものとして却下されるべきである。
(2)営業秘密の使用についてア被告が原告アルゴリズム全体をそのまま使用して市川ソフトを作成したのであれば,プログラムとしての表現が異なっていても,不正競争防止法2条1項7号の不正競争行為が成立する余地があるが,後記2(2)及び(3)に説示の事実によれば,被告は,市川ソフトを作成するに当たり,原告アルゴリズムをそのまま使用したものではなく,多くの点で原告アルゴリズムとは異なる処理手順を採用し,一部原告アルゴリズムと同様の処理手順を採用した箇所についても,技術上の合理性の観点から当然採用される部類に属する手法を採用したものであり,原告アルゴリズムや原告ソフトそのものを使用又は開示するに等しい結果を何ら招来していないものであるから,被告が市川ソフトを作成するに当たり,原告アルゴリズムを使用したものと認めることはできない。
イよって,原告の不正競争防止法2条1項7号,3条に基づき市川ソフトの製造等の差止め及び侵害の停止又は予防に必要な措置を求める原告の請求(請求第1,第2項),並びに同法4条に基づき損害賠償の支払を求める請求(請求第3項)は,理由がない。
2争点(2)(債権者代位権に基づく差止請求)について(1)請求内容原告は,債権者代位権に基づく差止請求として,請求第2項記載の行為を求めているが,その請求内容が特定されていないから,これらの訴えは,不適法なものとして却下されるべきである。
(2)信義則上の秘密保持義務の内容ア被告は,前提事実(1)イ及び(2)ウのとおり,平成9年6月30日まで両毛システムズに在職し,原告から委託を受けた原告ソフトの開発に責任者として関与したものであるから,信義則上,両毛システムズに在職中知り得た秘密を保持する義務を負っていると考えられる。
イ被告がどのような内容の秘密保持義務を負うかについて検討する。
(ア)被告がソフトウェア開発の前提として原告から開示された原告に特有のトーションレースの編み方のノウハウや,原告アルゴリズム全体をそのまま他に開示するような行為(原告アルゴリズムと全く同じアルゴリズムに基づくソフトを作成して市川鉄工に成果物として交付する行為を含む。)は,信義則上の秘密保持義務に違反すると考えられる。
(イ)しかしながら,システムエンジニア又はプログラマーがあるソフトウェアの開発によって得たものは,一面で委託者から委託されたソフトウェア開発の成果物であるが,他面で,従来からシステムエンジニア又はプログラマーとして有していた技術を適用した結果であったり,技術上の合理性の観点から必然である処理手順であることが考えられ,これらの点を無視して信義則上の秘密保持義務を広く負わせることは,システムエンジニア等に同種のソフトウェアの開発に関与することを実際上禁止して職業選択の自由を制約し,社会経済的にも技術の蓄積によるソフトウェアの開発コストの削減を妨げる結果となりかねない。
以上の点からすると,以前に同種ソフトウェアの開発に関与した被告が信義則上の秘密保持義務に反したか否かは,原告アルゴリズムと市川アルゴリズムとが一致する割合はどの程度か,一致する部分について,当該システムエンジニア等が従来から有していた技術の適用の結果といえるか,又は技術上の合理性の観点からそのような手順を採用することが当然か,市川ソフトウェアやその前提となる市川アルゴリズムの一部が開示されることにより,従前の雇用主である両毛システムズ又は開発委託者である原告のノウハウ等が開示される結果となるか等を総合して判断するほかはない。
(3)秘密保持義務違反の有無ア原告ソフトのTenshonDataSet関数(甲15の1の2837行〜2886行)が,別紙「アルゴリズムに関する当事者の主張」図4のフローチャート(以下「原告フローチャート」という。)に示される処理を行っていることは,当事者間に争いがない。
イそして,TenshonDataSet関数が,組織図からイメージ図を作成する処理の過程において,@移動後の交点の厳密な位置を求めるのではなく,各交点についてその上下に存在する交点位置の存在及び糸の張力を考慮して徐々に移動させることを繰り返しながら近似解を求めること,A糸の張力が大きいほど,その糸のX座標についてTenshonMove_1(X座標) がより多くの回数呼ばれること,B所定の回数だけ関数を呼ぶことで計算を打ち切っていること,さらに,これに対応する市川ソフトのSampleCreate関数が同様の処理を行っていることは,当事者間に争いがない。
ウ原告は,その他のアルゴリズムも共通していると主張しており,その根拠として,@原告ソフトのSetTenshonHG関数と市川ソフトのSamplePoint関数,A原告ソフトのTenshonCenterMove関数と市川ソフトのSamplePointMove関数の類似点を指摘する。
その指摘内容自体は当事者間に争いがないが,いずれも,ソースコードのごく一部について,表現が類似し又は機能が共通しているというものであって,市川ソフトが,上記アのフローチャートに示される処理と同一の処理を行っていることを裏付けるものではない。
エかえって,当事者間に争いのない事実に併せ,証拠(甲15の1)及び弁論の全趣旨によれば,少なくとも以下の相違点が認められる。
(ア)原告ソフトのTenshonDataSet関数と市川ソフトのSampleCreate関数市川ソフトは,組織図データからサンプル図を作成する処理で,編む順番を記述したデータを使用し,ImageProgCouse関数で処理してから実際のサンプル図を作成する処理を行っているため,サンプル図が原告ソフトによる場合と異なる場合がある。
(イ)原告ソフトのSetTenshonHG関数と市川ソフトのSamplePoint関数これらの関数は,組織図の交点データ(黒丸)の位置を,組織図右上を原点とした相対的な距離で示す座標値に変換する処理を行う関数であるが,原告ソフトのSetTenshonHG関数(原告フローチャートのS402)には,組織図1つの升目のサイズを整数で行い,実際にサンプルを作成する大きさで計算するという考え方はないが,市川ソフトにおいては,実際にサンプルを作成する大きさで,1単位を0.1oとして変換するという方法を採用している。
(ウ)原告ソフトのTenshonCenterMove関数と市川ソフトのSamplePointMove関数これらの関数は,交点データを,交点の上下,斜め上,斜め下に別の交点が存在する場合にそれに応じて移動する処理を行う関数であるが,原告ソフトのTenshonC, enterMove関数(原告フローチャートのS403)においては,糸の張力を考慮せず組織図データと交点データを使用して移動処理を行っているが,市川ソフトにおいては,これらに併せ糸のテンション量を考慮して移動を行っている。
なお,原告ソフトにおいては,その後の処理過程において,TenshonYarnHG関数により糸のテンション値の設定を行い(原告フローチャートのS404),張力に伴う交点移動の処理を行っている(原告フローチャートのS405)。
オ以上によれば,結局,原告ソフトと市川ソフトに共通すると認められるアルゴリズムは,@組織図からイメージ図を作成する際,糸の張力に応じて糸の交点位置を移動すること,Aその交点位置の移動を,上記イ@〜Bの手順で行うことであり,それ以外に共通するアルゴリズムがあるとは認められない。
カ上記オ@について検討すると,証拠(乙1の1・2,2の1,3)及び弁論の全趣旨によれば,格子模様で糸の交点を黒丸とした組織図及びこれに糸を掛けた糸掛け図は,本件開発委託契約がされた平成8年8月の時点で,トーションレース業界において手書きの意匠図や編み機用プログラムに広く用いられていたと認められ,また,証拠(乙5)及び弁論の全趣旨によれば,トーションレースを実際に編み上げた場合に糸の張力が影響することは,昭和40年当時のトーションレース編み機の説明書(乙5)にも記載されていることであって,イメージ図を作成する場合に,糸の張力に応じて糸の交点位置を移動させることは当然のことと認められる。
キ上記オAについて,原告は,糸の交点の位置を連立方程式により求めることも可能であると主張するが,弁論の全趣旨によれば,多数の糸が無原則に交差している状態で1本の糸を引っ張った場合の移動を連立方程式で解くことは実際上不可能であると認められる。また,原告は,通常は「安定な条件」に到達したときに計算を打ち切ると主張するが,弁論の全趣旨によれば,そのような安定な条件を見出すことは困難であることが認められる。
そうすると,上記オAの手法以外に採用が容易な手順があると認めることはできず,上記オAの手法は,近似解により組織図からイメージ図を作成する方法として,技術上の合理性の観点から当然採用される部類に属する手法であると認められる。
クさらに,原告は,被告との打合せにおいて,原告アルゴリズムの基礎となる内容を教示したと主張するが,証拠(甲21の1〜20)及び弁論の全趣旨によれば,原告は,被告との打合せにおいて,トーションレースの編み上げの実際を説明し,原告ソフトが有すべき機能の打合せをしたこと認められるものの,それ以上に,原告アルゴリズムを作成するにつき,有用な手順又はそのような手順に到るヒントとなる情報を提供したことを認めるに足りる証拠はない。
また,証拠(乙2の1〜3)及び弁論の全趣旨によれば,トーションレースの編み上げの実際は,トーションレースの編み機の製造等を業とする市川鉄工からも容易に説明を受けられる情報であると認められる。
そして,弁論の全趣旨によれば,トーションレース編み上げ用のソフトウェアの開発に経験の長い被告が協力せず,他のシステムエンジニアが初めから同ソフトウェアの開発を行おうとすれば,トーションレース編み上げの基礎から理解をし,試行錯誤を行わなければならないため,その開発に時間を要することはうかがわれるが,それ以上に,被告が原告ソフトの開発を行ったことによって原告アルゴリズムや原告ソフトそのものが他に開示される結果となったとの事情は認められない。
ケこれらの事実によれば,被告は,市川ソフトの作成に当たり,原告ソフトの開発に関与した経験が大いに役立ったが,原告アルゴリズムをそのまま使用したものではなく,多くの点で原告アルゴリズムとは異なる処理手順を採用し,一部原告アルゴリズムと同様の処理手順を採用した箇所についても,技術上の合理性の観点から当然採用される部類に属する手法を採用したものであり,原告アルゴリズムや原告ソフトそのものを開示するに等しい結果を何ら招来していないものである。
したがって,市川アルゴリズムに想到し,それに基づいて市川ソフトを作成したことをもって,被告が両毛システムズ退職後も負う信義則上の秘密保持義務に反したものと認めることはできない。
コよって,被代位債権が認められないから,債権者代位権に基づく原告の差止請求は,その余の点について判断するまでもなく理由がない。
3争点(3)(プログラム著作権の侵害)(1)請求内容について原告は,プログラム著作権の侵害があったとして,著作権法112条2項に基づき,侵害の停止又は予防に必要な措置として,請求第2項記載の行為を求めているが,その請求内容が特定されていないから,これらの訴えは,不適法なものとして却下されるべきである。
(2)複製権又は翻案権侵害についてア原告ソースコード(甲15の1)とこれに対応する市川ソースコードを比較すると,TenshonDataSet関数に対応するSampleCreate関数,SetTenshonHG関数に対, 応するSamplePoint関数,TenshonCenterMove関数に対応するSamplePointMove関数IchikawaWriteData関数に対応するWriteToWeave関数は,いずれもプログラムとしての表現が全く異なっていると認められる。
イこれに対し,原告は,以下の類似点があると主張するが,以下に述べるとおり,いずれもソースコードの類似性を認めるに足りるものではない。
(ア)データ構造の類似について原告は,原告ソフトの変数m_ViewHGと市川ソフトの変数m_SampleCurrentが,それぞれ組織図データを格納していること,原告ソフトの変数m_TenshonHGと市川ソフトの変数m_SamplePointが,それぞれ交点座標のデータを格納していること,いずれも2次元配列を1次元の配列のデータ構造で表現していることから,原告ソフトと市川ソフトのデータ構造が類似していると主張する。
しかし,弁論の全趣旨によれば,両者は,トーションレース業界で広く用いられている組織図等に関するデータであるところ,組織図データは糸の黒丸の情報,交差位置の右側の糸情報,交差位置の左側の糸情報の3種類のデータであり,交点座標のデータはX座標,Y座標の2種類のデータであって,いずれも単純な内容であること,データ1単位のバイト数,繰返しの指示に使用する付加データの有無,short型(2バイト)の2つの値を持つ小領域から構成されるかCPointクラスのインスタンスの並びにより構成されるかという点において違いがあることが認められるから,この点から両者のソースコードが類似していると認めることはできない。
(イ)その他の類似点についてa原告は,市川ソフトのSampleCreate関数(市川ソースコード1頁43行〜64行)の記述において,TenshonDataSet関数と同じ処理がされていると主張するが,SampleCreate関数全体の半分に満たない箇所において,表現はともかく共通した処理がされているにとどまる。
b原告は,全65行に及ぶSamplePoint関数のうち,作業領域作成に関する7行の記述が実質的に同一であること,繰り返し行うfor文の2行が共通していること,xの値を実質的に2ずつ増やす,Y座標を計算するために4や2で除すこと,CSizeで求めた値を変数に代入して関数が終了する点が共通すると主張するが,いずれも,ごく一部のソースコードの表現や処理内容が類似しているにとどまる。
c原告は,市川ソフトのSamplePointMove関数において,原告ソフトのTenshonCenterMove関数と同じ,Y座標の値を「不連続に大きくする」処理が行われていると主張するが,弁論の全趣旨によれば,これは,組織図で表された柄を繰り返し編む際の組織図上下のつながりを考慮した処理をしているものであって,これが共通しているからといって,交点データを移動する処理を行う関数である上記関数全体が類似しているとはいえない。
d原告は,市川ソフトのWriteToWeave関数の1行「if ( weave != 0 ) dat|=msk;」が原告ソフトのIchikawaWriteData関数と同じ処理を行っていると主張するが,これをもって上記関数全体が類似しているとはいえない。
eインスタンス変数や関数の名前の付け方及び2次元情報を1次元配列のデータ構造で表現する手法は,それ自体でソースコードの類似を認める根拠にはならない。
ウ以上によれば,原告ソースコードと市川ソースコードとが類似していると認めることはできないから,プログラム著作権(複製権又は翻案権)に基づく原告の請求は,その余の点について判断するまでもなく,いずれも理由がない。
4争点(4)(画面表示の著作権の侵害)(1)請求内容について原告は,画面表示の著作権侵害があったとして,著作権法112条2項に基づき,侵害の停止又は予防に必要な措置として,請求第2項記載の行為を求めているが,その請求内容が特定されていないから,これらの訴えは,不適法なものとして却下されるべきである。
(2)複製権又は翻案権侵害についてア原告は,升目状のシートにスピンドルが交差し得る位置を表示する小さな黒斑点が中央部分に表示されている升目と,黒斑点がない升目とが市松模様状に整然と表示されている画面表示(甲10のD),及び黒斑点の升目にてスピンドルを交差させる処理を表示する場合に楕円状の黒丸を表示する画面表示(甲10のC)につき,原告が著作権を有すると主張する。
イしかし,証拠(乙1の1・2,2の1,3)及び弁論の全趣旨によれば,上記画面表示は,コンピュータ化される以前から使われていた手書きシートをコンピュータ画面上に表示したにすぎないものであり,しかも,本件開発委託契約がされた平成8年8月以前に,これらを画面表示した編み機用プログラムが複数存在したことが認められる。
ウしたがって,上記アの各画面表示に,原告の著作権を認めることはできないから,画面表示の著作権(複製権又は翻案権)に基づく原告の請求は,その余の点について判断するまでもなく,いずれも理由がない。
5結論以上のとおり,原告の訴えのうち請求第2項の訴えは,いずれも不適法であるから却下することとし(仮に適法であっても理由がないことは,前記に各説示のとおりである。),その余はいずれも理由がないから棄却することとし,主文のとおり判決する。
追加
(別紙)物件目録株式会社市川鉄工製造のトーションレース編み機(TypeBLC2-64及びBLC2-96)に対応し,そのソフトウェアを装着すると,コンピュータのディスプレイ上で作成した組織図及び編み柄図どおりに,その編み機が自動的にトーションレースを編み上げてくれる,平成12年に開発されたソフトウェア。
上記ソフトウェアの詳細は,以下のとおり。
トーションレースの編成に必要な組織図上のスピンドルの入れ替え位置と各スピンドルで使用される糸の情報とを記憶させ,前記スピンドルの入れ替え位置を画像表示させた後,該画像上で前記位置を修正移動させ,該移動後の確定した位置を繋いで各糸の軌跡を作成することを特徴とするトーションレースの編み上がりイメージ作成方法である。
このイメージ作成方法によれば,トーションレースの編成に必要な組織図上のスピンドルの入れ替え位置と各スピンドルで使用される糸の情報とを記憶させ,前記スピンドルの入れ替え位置を画像表示させた後,該画像上で前記位置を修正移動させ,該移動後の確定した位置を繋いで各糸の軌跡を作成することを特徴としているから,入力されたトーションレースの編成に必要な組織図に,各スピンドルで使用される糸の具体的情報が加味されて実際に糸が交差する位置を割り出されて編み上がりイメージが画像上で簡易に作成・確認できることから,実際にトーションレース機に掛けて試作編みを繰り返す必要がなくなる。
(別紙)アルゴリズムに関する当事者の主張第1原告の主張1原告アルゴリズムの内容(1)TenshonDataSet関数のアルゴリズムアTenshonDataSet関数(甲15の1の2832行〜2886行)は,CTorshonDocクラスのインスタンスが有するメソッドの1つであり,横軸方向に複数のスピンドルが配置され,横軸に平行に複数のコースが縦軸方向に配置されていることを前提として,複数のスピンドルを縦軸方向に移動させる際,スピンドルが交差する位置に黒丸を配置した組織図から,トーションレースの編み上がりのイメージ図を作成する。
イ後記図1〜図3は,組織図からイメージ図を作成する処理の過程の概略を示す。
組織図は,図1のように,格子が2次元に配置され,格子の形成する升目の中には,黒丸を含むものがある。この黒丸の位置において,スピンドルが交差することで糸が交差する。すなわち,横軸方向に配置されたスピンドルが図1の上から下の方向に向かって移動し,その際,黒丸の位置で隣接する2つのスピンドルが交差して糸が交差する。
その結果,図2のようにスピンドルの軌跡を形成する複数本の糸が上下方向の上から下に伸ばされ,図1の黒丸に相当する位置で糸が交差する図が得られる。
しかし,糸には張力がかかっているため,糸の交差位置は図2の位置から移動する。この移動後の糸の交差位置は,張力を考慮にいれた連立方程式により厳密に求めることも可能であるが,原告ソフトでは,各交点についてその上下(斜め上,斜め下を含む。)に存在する交点位置の存在及び糸の張力を考慮して徐々に移動させることを繰り返し,近似解を求めている。イメージ図(図3)は,その結果の図である。
TenshonDataSet関数は,最終的に,図3に相当するビットマップ画像を生成する。
ウTenshonDataSet関数の処理の流れを示すフローチャートは,図4のとおりである。
(ア)ステップS401においては,YarnDataSeiriView関数を呼ぶ。YarnDataSeiriView関数は,糸を流す処理を行う「糸を流す」とは,組織図上で糸を上から。
下に伸ばし,スピンドルが交差する位置で隣接する糸を交差させることをいう。すなわち,図1の黒丸の位置でスピンドルが交差したように糸を交差させながら上から下に伸ばすことを意味する。後に説明するように,組織図に対応するデータ構造は,コース(升目の行)を単位に構成されており,コースのどの位置に何色の糸が通るかの情報が格納される。この情報の行間での整合性を取る処理がYarnDataSeiriView関数の行う処理である。
(イ)ステップS402においては,SetTenshonHG関数を呼ぶ。SetTenshonHG関数は,交点データの作成の処理を行う。すなわち,図1の黒丸ごとの位置を求める。
具体的には,左から右方向へ伸長するX軸と上から下方向へ伸長するY軸とのXY座標による交点の座標位置を求め,その座標位置をその交点に対応する黒丸に関連付けることが行われる。
なお,原告ソフトにおいて,SetTenshonHG関数が計算する交点の位置は,升目の縦と横の長さをTCN_SIZEという整数の定数と考えて計算され,後のステップS406において現実の表示サイズに変換する。
(ウ)ステップS403においては,TenshonCenterMove(0)とTenshonDataFosei()を呼ぶ。これにより,交点位置をセンターに移動する処理が行われる「センタ。
ーに移動する」とは,交点の上と下(斜め上,斜め下を含んでもよい。)に別の交点が存在すれば,その別の交点の位置に応じて,交点の位置を移動することをいう。
なお,TenshonCenterMove(0)の0は引数の値であり,ステップS405では,TenshonCenterMove関数に引数として1を与えて,TenshonCenterMove(1)を呼ぶことが行われる。
(エ)ステップS404においては,SetTenshonYarnHG()を呼ぶ。これにより,各糸の張力(テンション)の値が所定の配列データに格納される。各糸の張力の値は,ソフトの中で定数値として定めることもできるが,原告ソフトでは,CTorshonAppクラスに動的に変更可能に格納された値を用いるようになっている。
(オ)ステップS405においては,張力に伴う交点の移動の処理を行う。図6は,その処理のフローチャートを示す。
aステップS601において,retという変数に1を代入する。retという変数は,ステップS602からステップS606までのステップが形成するループを回るかどうかの制御を行うための変数である。
bステップS602では,retの値が0でないかどうかを判断する。もし,retの値が0であれば,処理を終了し,そうでなければ,ステップS603へ処理を進める。
cステップS603では,いったん,retに0を代入する。
dステップS604では,X軸方向に糸の張力を検査する。糸の張力の値は,,m_TenshonYarnの指すバイト列を参照することにより得ることができる。すなわち例えば,X軸の小さい値から大きな値に向けて変数を大きくしながら,m_TenshonYarnのその変数の値番目の要素に格納されている値を取得する。もし,その値,すなわち糸の張力が0になっていなければ,TenshonMove_1(X座標)を3回呼ぶ「T。
enshonMove_1(X座標)」とは,TenshonMove_1に現在着目しているX座標の値を引,数として与えて呼ぶことを意味する。TenshonMove_1(X座標)を3回呼んだ後には糸の張力を下げる。この処理は,m_TenshonYarnの指すバイト列に格納された値を小さくする(例えば,1を引く。)ことで行われる。次に,retに1を代入する。
eステップS605では,retが0でないかどうかを判断し,0であれば,ステップS602へ戻る。また,0でなければ,ステップS606へ処理を進める。
fステップS606では,TenshonCenterMove(0)を呼び,TenshonDataFosei()を呼ぶ。
gすなわち,糸の張力が大きいほど,その糸のX座標についてTenshonMove_1(X座標)がより多くの回数呼ばれ,糸の張力の総和が大きいほど,TenshonCenterMove(0)とTenshonDataFosei()がより多くの回数呼ばれるようになっている。
,(カ)ステップS406においては,TenshonDataConv関数を呼ぶ。これにより表示サイズに合うように座標位置の変換処理を行う。
(キ)ステップS407において,ビットマップデータの作成の処理を行う。
エ図5は,CTorshonDocクラスのインスタンスの持つ主なデータ構造を示す。
CTorshonDocクラスのインスタンスは,m_TenshonYarn,m_ViewHG,m_TenshonHGというインスタンス変数を持つ。これらのインスタンス変数は,バイト列を指すポインタであり,それぞれのバイト列は,スピンドル数(m_Spin),m_Maisu*m_Spin*8,m_Maisu*m_Spin*8の値に等しいバイト数の長さを持つ(これらのバイト列は動的に確保され,長さなどの管理データを含んでいるが,ここでは管理データの部分が無いものとして説明する。)。
m_TenshonYarnの指すバイト列は,ステップS404でいうところの所定の配列データとなる。
m_ViewHBの指すバイト列は,主に図1に例示される組織図を表現するために用いられ,スロットに黒丸があるかどうか,何色の糸がどの位置に通るかを保持する。
m_TenshonHGの指すバイト列は,糸の交点位置をスロットの中の黒丸に関連付けるために用いられる。
オTenshonDataSet関数に呼び出される関数の概要は,以下のとおりである。
(ア)図7は,YarnDataSeiriView関数が,糸を流す処理において,m_ViewHGの指すバイト列をどのように区切って扱うかを示す。
(イ)図8は,YarnDataSeiriView関数が,糸を流す処理において,二つのポインタ変数としてsbuf1とsbuf2を用いるが,この二つのポインタ変数の位置関係を示す。
(ウ)図9は,YarnDataSeiriView関数が,糸を流す処理において,sbuf1の指すバイト列からの糸情報の読み出しの仕方,また,sbuf2の指す位置を基準とした糸情報の格納の仕方を示す。
(エ)図10は,SetTenshonHG関数が,交点データを作成する処理において,m_ViewHGの指すバイト列をどのように区切って扱うかを示す。
(オ)図11は,SetTenshonHG関数が,交点データを作成する処理の流れの概要を示す。
(カ)図12は,TenshonCenterMove関数が,交点位置を移動させる処理の前半の流れの概要を示す。
(キ)図13は,TenshonCenterMove関数が,交点位置を移動させる処理の後半の流れの概要を示す。
(ク)図14は,TenshonDataFosei関数が,TenshonDataFoseiExec関数にどのような引数を与えて呼出しを行うかを示す。
(ケ)図15は,TenshonDataFoseiExec関数の処理の概要を示す。
(コ)図16は,TenshonMove_1関数の処理の概要を示す。
(2)IchikawaWriteData関数のアルゴリズムアIchikawaWriteData関数(甲15の1の4481行〜4534行)は,dataCourse,inBuf,otBuf,course,tag,Speedという6個の引数を持ち,otBufの指すバイト列に,他の引数の値を格納する処理を行う。
イ具体的な処理は,以下のとおりである。
(ア)courseの値を十進数で表わす文字列に変換してotBufに格納する。
(イ)tagの値を文字列に変換してotBufに格納する。
(ウ)Speedの値を,少なくとも整数部分の桁数が1で小数点以下の桁数が3となる文字列に変換してotBufに格納する。
(エ)inBuf[m_Wale*4*2*dataCourse+(m_ViewCourse-1)*m_Spin*4]の値が0でなければ,文字YをotBufへ書き込み,0であれば,文字NをotBufへ書き込む。ここに,m_Wale,m_ViewCourse,m_Spinは,CTorshonDocクラスのインスタンス変数である。
(オ)otBufへ文字Nを書き込む。
(カ)IchikawaWrite_mdatacnv関数を呼ぶ。
(キ)IchikawaWrite_mdatacnv関数によって得られたデータであるmdataの後ろの要素から,その要素の値を十進数に変換してotBufに格納する。
(ク)図17は,IchikawaWrite_mdatacnv関数の処理の概要を示す。この関数は,buf,mdataを引数として取るが,bufの指すバイト列に格納された値が0かそうでないかを,ビットのon,offとしてmdataに格納する処理を行う。まず,mdataは12バイトのバイト列であるので,全てのバイト位置に0を代入し,bitcnt,by,tcntを0に初期設定し,変数lを0,1,2,…,m_Spin-1まで変化させながら次の処理を行う。すなわち,buf[(l%2)*m_Wale_*4]が0でなければ,mdata[bytcnt]のbitcnt目のビットを1にする。次に,bitcntを1だけ増やす。次に,lが7,15,23,…である場合に,bitcntの値を0として,bytcntを1だけ増やす。そして,bufの指す位置を4バイト右へずらす。なお「l%2」とは,l,を2で割ったときの余りを表わす。
2原告アルゴリズムと市川アルゴリズムの類似点(1)原告ソフトのTenshonDataSet関数と市川ソフトのSampleCreate関数ア原告ソフトのTenshonDataSet(甲15の1の2837行以下)は,2848行〜2869行において,@移動後の交点の厳密な位置を求めるのではなく,各交点についてその上下(斜め上,斜め下を含む。)に存在する交点位置の存在,また糸の張力を考慮して徐々に移動させることを繰り返しながら,近似解を求め,A糸の張力が大きければ大きいほど,その糸のX座標についてTenshonMove_1(X座標)がより多くの回数呼ばれる,B繰り返し関数を呼ぶことによって近似解を求める場合,通常のように(例えば,微分方程式の解を数値的に近似的に求める場合などでは),関数が呼ばれる前後での変化が所定の値以下になるなど安定な条件に到達したと判断されれば計算を打ち切るというのではなく,所定の回数だけ関数を呼ぶことで計算を打ち切っている。
これに対し,市川ソフトのSampleCreate関数(平成18年2月20日付被告第3準備書面添付のソースコード(以下「市川ソースコード」という。)1頁2行〜2頁5行)の1頁の43行「SamplePoint()」〜64行「SamplePointMove(3)」までの記述を検討すると,@SamplePointMove(),SamplePointPull()という関数を繰り返し呼ぶことで,交点の位置を徐々に移動させ,ASpinHGという変数は,m_SampleCurrentSize.cxの大きさを有する一次元配列を指していると思われるところ,SpinHGのX座標に相当する要素の値が大きければ大きいほど,SamplePointPull(X座標)がより多くの回数呼ばれており,B安定な条件に到達したと判断することなく,所定の回数だけ関数を呼ぶことで計算を打ち切っており,原告アルゴリズムと共通している。
イ被告の主張に対する反論(ア)被告は,SampleCreate関数は,組織図データをプログラムされたイメージ展開する処理を行うようになっていると主張する。
しかし,原告ソフトにおいても組織図データを表示する部分はあるのであり,編み上がりのイメージ図を作成する処理において,被告が説明するような「組織図データをプログラムされたイメージに展開する処理を行う」処理を更に実行することは,アルゴリズムの本質的な違いにならない。
また,具体的に,市川ソースコードのどの部分が該当するのかが不明であるが,「intcourse=ImageProgCourse();」の箇所が該当するのであれば,単に,ImageProgCourse()を,SampleCreate関数から呼ぶようにしただけであり,アルゴリズムの本質的違いとはならない。
(イ)被告は,張力の強い方に糸が引っ張られ,交点が移動することは誰でも思いつくことであると主張するが,それは,本件委託契約当時の技術文献などを参照して判断するべきものである。
仮に,張力の強い方に糸が引っ張られ,交点が移動することが誰でも思いつくものであったとしても,交点をどのようなデータ構造でプログラム言語で表現し,張力の強さに応じてどのように移動させるのかは,直ちに思いつくものではなく,一義的に決まるものでもない。
(2)原告ソフトのSetTenshonHG関数と市川ソフトのSamplePoint関数の対比ア原告ソフトにおけるm_TenshonHG(甲15の1の2888行〜)は,市川ソフトにおけるm_SamplePoint(市川ソースコード2頁6行〜最終行)に対応するから,原告ソフトSetTenshonHG関数の記述の一部(甲15の1の2893行〜2899行は,市川ソフトの記述の一部(市川ソースコード2頁13行「//領域」〜19行「…bufSize);」)と実質的に同一である。
イ原告ソフトにおけるm_Maisuは,市川ソフトにおけるm_SampleCurrentSize.cyに対応するから,原告ソフトの記述(甲15の1の2909行)は,市川ソフトの記述(市川ソースコード2頁36行「for…;y++)[」)と同じであり,このyに関するfor文の中に,xに関するfor文(甲15の1の2922行と市川ソースコード2頁55行「for…;x++)[」)が共にあるのも同じである。
ウ原告ソフトでは,xの値は2ずつ増えるのに対して,市川ソフトでは1ずつ増えるという違いはある。しかし,市川ソフトの上記記述とこれに続く同56行「if((x%2=…」によれば,yの値が固定されていれば,for文の内側のifの条件は,xが偶数か奇数の場合のどちらかでしか真にならないので,この点から原告ソフトと市川ソフトとは実質同一である。
エ原告ソフトでは,交点の位置のY座標を計算するために,4で除したり(甲15の1の2914行〜2920行),2で除したり(甲15の1の2923行〜2926行)しているが,市川ソフトでも(市川ソースコード2頁40行「if(stop)[」〜50行「…=ky/2;」),Y座標を計算するために,4で除したり2で除したりしている。
オ原告ソフト(甲15の1の2936行〜2938行)と市川ソフト(市川ソースコード2頁下から3行の「m_SampleSize=…」から下から2行「returnTRU。E;」まで)は,いずれも,CSizeで求めた値を変数に代入して関数が終了しているカ被告の主張に対する反論上記1(1)ウ(イ)のとおり,原告ソフトのSetTenshonHG関数では,TCN_SIZEという整数の定数を升目の大きさとし,整数値で交点の座標を計算しているが,必要に応じてTCN_SIZEの値を512や1024など大きな値に変更することにより,任意の精度で交点の座標を求めることができ,また,0.1mmをどれだけの整数値に対応させるのかも任意のことである。また「実際にサンプルを作成する大きさ」,で計算することと,仮の値で計算した後に縮小ないし拡大をすることとは,アルゴリズムの本質的な違いにならない。
(3)原告ソフトのTenshonCenterMove関数と市川ソフトのSamplePointMove関数の対比ア原告ソフトTenshonCenterMove()(甲15の1の2942行〜)において,着目している交点の右上の交点を探索する記述(甲15の1の2981行〜2996行)の部分においては,着目している交点のY座標の値よりも小さいY座標の値の交点を探索すれば十分なはずであるが(図14参照),2992行で「y1--;」によりY座標の値を小さくした後,2993行,2994行で「y1」の値が負になると「y1」に「m_Maisu*2」を加えてY座標の値を大きくして(このことを,,「不連続に大きくする」という。),着目している交点より右下にある交点を探索している。
これに対応する市川ソフトの部分(市川ソースコード3頁1行〜)は,SamplePointMove()から呼ばれる関数SamplePointMove_Exec()から更に呼ばれる関数SamplePointMove_RighTop()と思われるところ,その記述(市川ソースコード5頁49行「CPointCTochonDoc::…」〜53行「….cy*2;」及び68行「y--;」〜69行「….cy*2;」)は,Y座標の値を格納する変数sy及びyから1を引き,結果が負になれば,yにm_Maisu*2に相当するm_SampleCurrentsize.cy*2を代入し,yの値を不連続に大きくしている。
イY座標の値を不連続に変化させる同様の記述は,原告ソフトにおいては,着目している交点の左上,右下,左下の交点の探索の処理にも存在する。これに対応する市川ソフトの処理の記述は,SamplePointMove_LeftTop(),SamplePointMove_RigthBottom(),SamplePointMove_LeftBottom()の関数の記述の中にあると思われるが,Y座標の値を不連続に大きくしたり小さくしたりしている処理の記述が見られる(原告ソフトでは,右下,左下の交点の探索においてY座標の値がm_Maisu*2を超えると,Y座標の値からm_Maisu*2を減じて不連続に小さくしており,一方,市川ソフトでは,Y座標の値がm_SampleCurrentSize.cy*2を超えると,Y座標の値を1にして不連続に小さくしており,結果として原告ソフトと市川ソフトとでは,同じように不連続に変化する。)。
ウ被告の主張に対する反論(ア)確かに,原告ソフトのTenshonCenterMove関数では,糸の張力を考慮していないが,原告ソフトでは,図6のとおり,糸のテンション量を考慮して交点位置を変更する処理が行われている。したがって,そもそもSamplePointMove関数をTenshonCenterMove関数に対応付けるのは正しくない。
(イ)また,被告は,SamplePointMove関数において,lpYarnという配列を参照していることをもって,市川ソフトでは糸の張力を考慮して交点を計算していると反論していると思われるが,市川ソフトのSamplePointMove関数において,引数signの値が1以下であれば,lpYarnの配列のうち,lpYarn[yn1].yaYarnWidth,l,,pYarn[yn2].yaYarnWidthの値しか参照されず「yaYarnWidth」という名称からはこれらは張力を示すとは思えない。むしろ「yaSpring」という名称から張力を示,すと思われるのは,lpYarn[yn1].yaSpring,lpYarn[yn2].yaSpringであろう。しかし,これらは,引数signの値が1より大となっているときにのみ参照されないことになっている。市川ソフトでのSampleCreate関数でのSamplePointMove関数の呼び方を見ると,SampleCreate関数の後半でのみSamplePointMove(2),SamplePointMove(3)が呼ばれている。以上からすれば,交点の計算の際に張力が考慮されるのは,SampleCreate関数の後半のみである。
一方,SampleCreate関数に対応する原告ソフトのTenshonDataSet関数でも,糸の張力を考慮して交点を移動させるのは,後半部分である2853行目から2869行目である。したがって,原告ソフトと市川ソフトとでは,張力を考慮に入れて交点を移動させるアルゴリズムは,同じ又は類似している。
(4)原告ソフトのIchikawaWriteData関数と市川ソフトのWriteToWeave関数ア市川ソフトのWriteToWeave関数(市川ソースコード8頁10行〜最終行)中の「if(weave!=0)dat|=msk;」は,原告ソフトのIchikawaWriteData関数(甲15の1の4481行〜4534行)「ビットのon,offとしてmdataに格納する処理」(別紙図17参照)に相当する。
イ被告の主張に対する反論被告は「市川ソフトは,バイナリーデータを全て別のブロックに分けて出力す,る」点で異なると主張するが,市川ソフトのWriteToWeave関数では,m_Bufというインスタンス変数と思われる変数が指しているバイト列にデータが書き込まれているので,m_Bufは原告ソフトでのotBufに相当するので,被告の上記主張は,誤りである。
また,被告は,テキストデータを作成する点とバイナリデータを作成する点とで違いがあると主張するが,テキストデータを生成するのか,バイナリデータを生成すのかは,アルゴリズムの違いを生じさせるものではない。
(5)まとめ以上のように,被告が原告ソフトのアルゴリズムをそのまま流用し,市川ソフトを作成したことは,明らかである。
第2被告の主張1原告アルゴリズムの内容原告の主張する内容は,いずれもプログラムの説明にすぎず,具体的にサンプル図を作成するための処理手順として営業秘密となっている部分を示していない。組織図データからサンプル図を作成する処理は,いくつかの工程を踏みながらデータを加工し,実際のサンプルに似せる技術であり,方程式を利用してできるものではない。重要なのは,各工程の具体的内容の構成及び全体の流れである。
2原告アルゴリズムと市川アルゴリズムの類似点(1)原告ソフトのTenshonDataSet関数と市川ソフトのSampleCreate関数ア原告の主張2(1)は明らかに争わないが,市川ソフトが同じアルゴリズムを使用していることは否認する。
イ原告の主張するアルゴリズムが,単に糸の交点を求め,糸の張力に応じて交点位置を移動するという次元のものであるなら,営業秘密には当たらない。従前,組織図として,交点位置に丸穴を書く方法と,糸が通る位置を有線で表す糸掛けという方法があったところ,糸の張力を考慮し,張力の強い方に糸が引っ張られて交点が移動するテンション図を作成することは,誰でも思いつくことである。
ウ原告は,@糸の交点の位置を連立方程式により求めることも可能であると主張するが,多数の糸がランダムに交差している状態で1本の糸を引っ張った場合の移動を公式とするのは不可能である。また,A通常は「安定な条件」に到達したときに計算を打ち切ると主張するが,そのような安定な条件を見出すことは不可能である。そのような不可能な方法をとっていないことをもって,共通点とすべきではない。
エ上記関数は,いずれも,サンプル図を作成するメイン関数であるが,市川ソフトにおいては,交点データ(組織図の黒丸の位置を表すデータ)を作成する前に,組織図データをプログラムされたイメージに展開する処理を1段階で行っており,2段階を要する原告アルゴリズムとは異なる。
原告は「単に,ImageProgCourse()を,SampleCreate関数から呼ぶようにした,だけであり,アルゴリズムの本質的違いとはならない」と主張するが,市川ソフトは,組織図データからサンプル図を作成する処理で,編む順番を記述したデータを使用し,ImageProgCouse関数で処理してから実際のサンプル図を作成する処理を行っている。その結果,例えば,下記の組織図データの○の部分を2回編んでから□の部分を1回編むという指示を行った場合,原告ソフトのサンプル図と市川ソフトのサンプル図は,下記のように異なる。
組織図データ原告ソフトのサンプル図市川ソフトのサンプル図(2)原告ソフトのSetTenshonHG関数と市川ソフトのSamplePoint関数ア原告の主張2(2)は明らかに争わないが,市川ソフトが同じアルゴリズムを使用していることは否認する。
イ原告は,作業領域を作成する方法,繰り返し行うfor文の記述等,ソースコードの一部が似ていると主張しているだけであって,アルゴリズムとは無関係である。
なお,Y軸を計算するために4で除したり2で除したりしているのは,Y軸方向に紋紙1枚分で表される長さを除しているだけで,交点位置を計算するアルゴリズムとは関係がない。
ウ上記関数は,組織図の黒丸の位置を,組織図右上を原点とした相対的な距離で示す座標値に変換する処理を行う関数であるが,原告ソフトにおいては,組織図1つの升目のサイズをX方向8,Y方向8として変換しており,実際にサンプルを作成する大きさで計算するという考え方はないが,市川ソフトにおいては,実際にサンプルを作成する大きさで,1単位を0.1oとして変換するという格段に正確な方法を採用している。
仮の値で計算した後で縮小・拡大する方法と実際のサイズで計算することは,同じ結果とはならない。
(3)原告ソフトのTenshonCenterMove関数と市川ソフトのSamplePointMove関数ア原告の主張2(3)は明らかに争わないが,市川ソフトが同じアルゴリズムを使用していることは否認する。
イ原告が主張する「不連続に大きくする」との内容は,トーションレースを編む場合,組織図で表された柄を繰り返し編んで製品を作るという構造のため,組織図の上下のつながりを考慮して処理する必要があるためであって,アルゴリズムとは無関係である。
ウ交点データを移動する処理を行う関数であるが,原告ソフトにおいては,糸の張力を考慮せず,組織図データと交点データを使用して移動処理を行っているが,市川ソフトにおいては,これらに併せ糸のテンション量を考慮して移動を行っており,より簡素化され,進歩している。
(4)原告ソフトのIchikawaWriteData関数と市川ソフトのWriteToWeave関数ア原告の主張2(4)は明らかに争わないが,市川ソフトが同じアルゴリズムを使用していることは否認する。
イいずれも,市川の編み機データ作成処理を行う関数であるが,原告ソフトと市川ソフトでは,作成する編み機データの形式が異なる。すなわち,原告ソフトは,1レコード内にタグ,スピード,巻き取り等をテキストデータである組織図データと一緒に出力するが,市川ソフトは,バイナリーデータをすべて別のブロックに分けて出力する点で異なる。
(5)まとめ原告の主張2(5)は争う。
以上
裁判長裁判官 市川正巳
裁判官 大竹優子
裁判官 頼晋一