判例検索β > 平成31年(ネ)第10034号
損害賠償請求控訴事件 特許権 民事訴訟
事件番号平成31(ネ)10034
事件名損害賠償請求控訴事件
裁判年月日令和元年10月31日
法廷名知的財産高等裁判所
原審裁判所名東京地方裁判所
原審事件番号平成29(ワ)31706
裁判日:西暦2019-10-31
情報公開日2019-11-14 18:00:34
戻る / PDF版
令和元年10月31日判決言渡
平成31年(ネ)第10034号

損害賠償請求控訴事件

(原審・東京地方裁判所平成29年(ワ)第31706号)
口頭弁論終結日

令和元年9月3日
判控決訴人
訴訟代理人弁護士

株式会社パッセルインテグレーション

訴人
訴訟代理人弁護士

隆夫藤伸樹我控村加被中妻崇明
ソフトバンクロボティクス株式会社

島正洋和田祐造森主鮫下梓文1
本件控訴を棄却する

2
控訴費用は控訴人の負担とする。
事実及び理由

第1控訴の趣旨
1
原判決を取り消す。

2
被控訴人は,控訴人に対し,3億4915万5000円及びこれに対する平成29年10月18日から支払済みまで年5分の割合による金員を支払え。
第2事案の概要(略称は,特に断りのない限り,原判決に従う。)1
事案の要旨
本件は,発明の名称を情報管理方法,情報管理プログラム,及び情報管理装置とする特許(特許第3754438号。請求項の数15。以下本件特許という。)に係る特許権(以下本件特許権という。)を有していた控訴人が,被控訴人においてウェブサイト上で提供している別紙プログラム目録記載のプログラム(以下被告プログラムという。)が本件特許の特許請求の範囲の請求項14に係る発明(以下本件発明という。)の技術的範囲に属し,被控訴人による被告プログラムのウェブサイト上での提供等が本件特許権の侵害に当たる旨主張して,被控訴人に対し,本件特許権侵害の不法行為に基づく損害賠償として3億4915万5000円及びこれに対する不法行為の後の日である平成29年10月18日(訴状送達の日の翌日)から支払済みまで民法所定の年5分の割合による遅延損害金の支払を求めた事案である。原判決は,被告プログラムは本件発明の技術的範囲に属すると認めることはできないから,その余の点について判断するまでもなく,控訴人の請求は理由がないとして,これを棄却した。
控訴人は,原判決を不服として,本件控訴を提起した。

2
前提事実
以下のとおり訂正するほか,原判決の事実及び理由の第2の2記載のとおりであるから,これを引用する。


原判決2頁16行目から20行目までを次のとおり改める。
本件特許の特許請求の範囲の請求項1及び14の記載は,次のとおりである。【請求項1】コンピュータが情報を管理する情報管理方法であって,前記コンピュータに複数のノードそれぞれに対応付けて入力された管理すべき情報を,前記ノードを識別するノード識別情報に対応付けられた複数のノードデータを含む文書ファイルとして前記コンピュータが記憶する情報記憶ステップと,前記情報記憶ステップで記憶された前記文書ファイルの情報を前記コンピュータが表示する情報表示ステップと,前記ノードデータに含まれるスクリプトを前記コンピュータが実行する情報評価ステップとを備え,前記ノードデータは,ルートノードを除いて,当該ノードの親ノードを特定する親ノード識別情報を含んでおり,前記スクリプトは,当該ノードデータに含まれる変数データである自ノード変数データと,当該ノードの直系上位ノードのノードデータに含まれる変数データである上位ノード変数データを利用した演算を行って,前記自ノード変数データの値を求める代入用スクリプトを含んでおり,前記情報表示ステップは,前記親ノード識別情報を利用して,前記ノードの木構造を表示する木構造表示ステップと,前記表示された木構造のノードのうちの選択されたノードの前記自ノード変数データ,前記上位ノード変数データ及び前記スクリプトを表示するノードデータテーブル表示ステップを含み,前記情報評価ステップは,前記代入用スクリプトの実行により,前記自ノード変数データの値を更新するステップを含む情報管理方法。【請求項14】請求項1ないし13のいずれか1項記載の情報管理方法における各ステップを,コンピュータに実行させるための情報管理プログラム。⑷本件発明の構成要件の分説本件発明は,請求項1記載の情報管理方法における各ステップを発明特定事項に含むものであるところ,かかる本件発明を構成要件に分説すると,次のとおりである(以下,頭書の記号に従って,「構成要件Aなどという。)。」
(2)

原判決4頁13行目の本件behavior.xarを本件behavior.xar1と改め,同行末尾に行を改めて次のとおり加える。ウ被告プログラムの内容は,原判決別紙3-1被告プログラム説明書(以下「別紙被告プログラム説明書という。)記載のとおりである。」


原判決4頁16行目の甲4~6を甲4ないし7,30ないし33
と改める。

3
争点


被告プログラムの本件発明の技術的範囲の属否(争点1)

構成要件AないしDの充足性(争点1-1)


構成要件Eの充足性(争点1-2)


構成要件Fの充足性(争点1-3)


構成要件Gの充足性(争点1-4)


構成要件H及びIの充足性(争点1-5)



無効の抗弁の成否(争点2)

本件特許出願の優先日前に頒布された刊行物である乙9(特開平6-175852号公報)に記載された発明(以下乙9発明という。)を主引用例とする本件発明の新規性又は進歩性の欠如(争点2-1)


本件特許出願の優先日前に頒布された刊行物である乙16(特開平10-69379号公報)に記載された発明(以下乙16発明という。)を主引用例とする本件発明の新規性又は進歩性の欠如(争点2-2)

本件特許は特許法36条6項1号及び同条4項1号に違反しているか
(争点2-3)


4
本件特許は特許法36条6項2号に違反しているか(争点2-4)損害の発生の有無及びその額(争点3)

争点に関する当事者の主張


争点1(被告プログラムの本件発明の技術的範囲の属否)についてア
争点1-1(構成要件AないしDの充足性)について
【控訴人の主張】
(ア)

本件発明の特許請求の範囲(請求項1記載の各ステップを発明特定
事項に含む請求項14。以下同じ。)の記載によれば,構成要件Bの管理すべき情報は,ノードを識別するノード識別情報に対応付けられた複数のノードデータを含む文書ファイルとしてコンピュー
タに記憶されるものであり,このノードデータは,スクリプト,
親ノード識別情報,自ノード変数データ,上位ノード変数データ及び木構造を表示するための情報を含むものを意味する。また,ノードは,木構造を前提とし,木構造は,数学の
一分野であるグラフ理論に由来するところ,
グラフ理論では,
グラフ
とは
いくつかの点とそれらを結ぶ何本かの線からなる図ないし構造

木とは閉路を含まないグラフ,閉路とは頂点を順につないで輪にしたものとそれぞれ定義される(甲23の1)。しかるところ,控訴人は,本件特許出願の当時,本件発明により表示される図形には閉路を持つグラフが含まれることを前提としていたが,単にグラフという用語でクレームすると,これが閉路を持つグラフを意味するものとされ,木だけで表示されるケースは,より基本的な概念しか用いていないとして,クレームを充足しないものとされるのを懸念したため,
木構造
という用語を選択したものであるから,
本件発明の木構造の表示の用語は,閉路を含むグラフを表示することを排除するものではない。したがって,構成要件Bのノードは,ノード(頂点)と2つのノードを結ぶエッジ(辺)により構成されるグラフにおける頂点を意味するものであり,このグラフには,閉路を持つものも,閉路を持たないものも含まれる。
さらに,本件特許出願の願書に添付した明細書(以下,図面を含めて本件明細書という。甲3)の記載(【0009】)に鑑みれば,構成要件Bの文書ファイルとは,テキストエディタ等で読むことのできるテキスト形式のファイルであり,1つの文書データを意味する。(イ)

別紙被告プログラム説明書の記載によれば,被告プログラムの構成
は,原判決別紙4被告プログラムの構成(原告)(以下別紙4という。)記載のとおりである。
(ウ)

被告プログラムは,ボックスを接続する形で本件ロボットのソフト
ウェアを実装することができる開発環境であり,別紙被告プログラム説明書及び別紙4に記載のとおり,コンピュータによって情報を管理するものであるから,構成要件A(コンピュータが情報を管理する情報管理方法)を充足する。次に,被告プログラムにおいて表示されるフローダイアグラムは,閉路を含まず,結合線により結合されたボックスで構成されているから,これらのボックスは,構成要件Bのノードに該当し,各ボックスを識別するボックス識別番号(idの番号)は,構成要件Bのノード識別情報に該当する。また,被告プログラムにおいてロボットの動作に関する情報がまとめられた文書ファイルであるbehavior.xar内で,ボックスに対応付けて入力されたスクリプトは,構成要件Bの管理すべき情報及びノードデータに該当する。そうす
ると,被告プログラムは,ノードデータを含む文書ファイルとしてコンピュータが記憶する情報記憶ステップを備えているから,構成要件Bを充足する。
さらに,被告プログラムは,文書ファイルであるbehavio
r.xarを読み込んで表示し,behavior.xarに含まれるスクリプトを実行するステップを備えているから,構成要件C及びDを充足する。
【被控訴人の主張】
(ア)

本件明細書の記載(【0007】,【0009】),構成要件H


自ノード変数データの値を更新するステップと規定していることに照らせば,構成要件Bの管理すべき情報は,変数データの値を意味するから,情報管理方法における情報及び当該情報を含む文書ファイル(構成要件B)は,それ自体,多人数で共有し,再利用する価値のある,変数データの値を意味する。
また,構成要件Bの複数のノードそれぞれに対応付けて入力された管理すべき情報との文言によれば,構成要件Bのノードは,管理すべき情報を含むものであり,木構造を前提とした概念である。
次に,本件明細書の記載(【0029】)によれば,構成要件Bのノード識別情報は,ノードを識別する情報であって,ノード生成時に自動的に一意の番号が付与される情報を意味する。そして,本件特許の特許請求の範囲の請求項2及び9の記載並びに本件明細書の記載(【0042】,【0049】)によれば,ノードの結合関係を表す参照リードは,構成要件Eの親ノード識別情報に基づく階層リードと区別されているから,構成要件Bのノード識別情報は,ノードの結合関係を表す情報を含まないものを意味する。
(イ)

被告プログラムの構成が別紙4記載のとおりであるとの控訴人の主
張は,争う。
別紙被告プログラム説明書の記載及び証拠(乙3ないし7,19,28ないし31)によれば,被告プログラムの構成は,原判決別紙5被告プログラムの構成(被告)記載のとおりである。
(ウ)

被告プログラムが管理するbehavior.xarに含まれるの
はロボットを動作させるためのプログラムコードであって,人間がこの意味を読み取り,多人数で共有して再利用するものではないから,被告プログラムには情報に該当するものが存在しない。そうすると,被告プログラムは,本件ロボットを動作させるためのソフトウェアを開発するためのソフトウェア開発環境であり,
構成要件Aの
情報管理方法
であるとはいえず,構成要件Bの管理すべき情報,ノード及び
文書ファイルを備えていない。
また,木構造は,階層構造を備えるものであるが,被告プログラ
ムのフローダイアグラムはプロセスを規定するものであって,階層構造を備えていないから,被告プログラムにおけるボックスは,構成要件Bの
ノード
に該当するとはいえない。
したがって,
被告プログラムは,
ノードデータ及び情報記憶ステップを備えていない。
さらに,被告プログラムには,同一のidを有する複数のボックスデータが存在するから,idによってボックスを識別することは不可能である上,idは編集可能であって,固有の識別情報ではなく,ボックス生成時に自動的に一意の番号が付与されるものではないから,idは構成要件Bのノード識別情報に該当するとはいえない。したがって,被告プログラムは,構成要件Bのノード識別情報を備えていない。以上によれば,被告プログラムは,構成要件A及びBを充足しない。そして

上記のとおり,被告プログラムは,構成要件Bの情報記憶ステップ,文書ファイル及びノードデータを備えていないから,これらの存在を前提とする構成要件C及びDも充足しない。

争点1-2(構成要件Eの充足性)について
【控訴人の主張】
(ア)

本件発明の構成要件Eの親ノードとは,あるノードに対して,

当該ノードが属する順序系列内において,当該ノードに直近して先行するノードを指し,構成要件Eのルートノードとは,当該ノードが属する順序系列内における一番最初のノードを指し,ルートノードに対する親ノードは存在しない。
次に,前記アの【控訴人の主張】のとおり,本件発明の木構造の表示は,閉路を含むグラフの表示を排除するものではなく,構成要件Bのノードは,ノード(頂点)とエッジ(辺)により構成されるグラフにおける頂点を意味するものである。
本件明細書の記載(【0042】,【0049】,【0054】)によれば,親子のノード間を接続するリードは階層リードと呼ばれ,階層リードは親子関係に基づいて表示されるから,親は,専ら
木構造の表示におけるノード間のリードの接続に関するものを意味する。そして,
構成要件Gの文言及び本件明細書の記載(【0038】,【0
060】)によれば,木構造は階層ごとに表示されるから,構成要件Eの親ノード識別情報は,階層ごとの木構造表示のために親ノードを識別する機能を有する情報を意味する。(イ)

被告プログラムでは,各ボックスに入力コネクタと出力コネクタが
含まれており,コネクタ同士を線でつなげることによって,ボックス間に結合関係が生じ(別紙被告プログラム説明書第2の3(2)),各ボックスは,コネクタを介して結合されると,出力コネクタのある結合元のボックスから,入力コネクタのある結合先のボックスへと,結合ボックス同士の処理順序が指定される
(別紙被告プログラム説明書第2の4ア)

コネクタを介したボックスの結合により各ボックスの処理順序が指定されることは,①ボックスの結合関係を無視した順序で各ボックスのスクリプト処理が行われることがないこと,②Pepperプログラミング基本動作からアプリの企画・演出までと題する解説書(甲7の2
9頁)において,ボックスの結合線に従って最初のボックスから次のボックスへと,処理が順番に移っていくことを順序実行と呼んでいることからも明らかである。
したがって,被告プログラムにおいては,各ボックスをコネクタを介して結合することによって,ボックス間に階層関係が生じ,先に処理される
(出力コネクタのある)親ボックスと,後に処理される(入
力コネクタのある)子ボックスの親子関係が成立する。
(ウ)a

原判決別紙3-2(以下別紙3-2という。甲17)の本件

behavior.xar1をフローダイアグラムに表示した場合の接続関係は,次のとおりである。
(a)

各ボックスのidは,次のとおりである。ボックス自体とは異

なる各
内壁コネクタ
(左側内壁コネクタ及び右側内壁コネクタ)
(原判決別紙6(以下別紙6という。)の図1及び図2参照)
のidは0である。
SetLanguage

LocalizedText

SayText

Say

id="2"

id="5"

id="2"

id="1"

(18行)

(180行)

(125行)

(92行)



別紙3-2のrootボックスタグ内の結合情報(301行ない
し303行)及びSayボックスタグ内の結合情報(292行ないし294行)は,次のとおりである。各結合情報のinputowner=及びoutputowner=の次に記載された数字部分の"1","2"及び"5"は,括弧内の行(例えば,180行)において定
義されたボックスのidの番号を表す(例えば,
inputowner="5"及びoutputowner="5"の"5"は,id5のLocalized
Textボックスを意味する。)。

【rootボックスタグ内の結合情報】
301:
302:
303:
rootボックスのフローダイアグラムは,①id0(rootボックスの左側内壁コネクタ)からid2(Set
uageボックス)へ(303行),②id2(Set
Lang
Lan

guageボックス)からid1(Sayボックス)へ(301
行),③id1(Sayボックス)からid0(rootボックスの右側内壁コネクタ)へ(302行)と結合していることを表している。
【Sayボックスタグ内の結合情報】
292:
293:
294:
Sayボックスのフローダイアグラムは,①id0(Sayボックスの左側内壁コネクタ)id5
から
(Localized
extボックス)へ(293行),②id5(Setuageボックス)からid2(Say
(294行),③id2(Say

T
Lang

Textボックス)へ

Textボックス)からid0(Sayボックスの右側内壁コネクタ)へ(292行)と結合していることを表している。
そして,被告プログラムにおいては,あるボックスの入力コネクタに結合されている出力コネクタ及び当該出力コネクタを有しているボックスの情報がbehavior.xarという文書ファイル上に記載されるから(別紙被告プログラム説明書第2の3(2)),ボックス及びコネクタ同士の結合情報が,ボックスデータの一部としてbehavior.xarに集積され,その結合情報によってボックス間の親子関係を読み取り,あるボックスに対する親ボックスを特定することができる。
したがって,上記結合情報のうち,ボックスの親ボックスを特定する情報(例えば,301行のinputowner="1"に対するoutputowner="2")は,構成要件Eの親ノードを特定する親ノード識別情報に該当する。b
また,被告プログラムにおいては,他のボックスの出力コネクタとの結合情報を持たないボックスが存在し,これは,当該ボックスが属する順序系列内における一番最初のボックスとなる。
したがって,被告プログラムにおけるボックスのうち,当該ボックスの入力コネクタと他のボックスの出力コネクタとの結合情報を含まない特定のボックスが,構成要件Eのルートノードに該当する。

c
(エ)

以上によれば,被告プログラムは,構成要件Eを充足する。

a
(当審における控訴人の追加主張)
別紙7-1(甲25の1)記載のbehavior.xar(以下本件behavior.xar2という。)をフローダイアグラ
ムに表示した場合の接続関係は,次のとおりである。
各ボックスのidは,次のとおりである。ボックス自体とは異なる内壁コネクタ(左側内壁コネクタ及び右側内壁コネクタ)(別紙
7-2(甲25の2)参照)のidは0である。

SetLanguage

LocalizedText

SayText

id="2"

id="5"

id="3"

(18行)

(147行)

(92行)

別紙7-1のrootボックスタグ内の結合情報(259行ないし262行)は,次のとおりである。各結合情報のinputowner=及びoutputowner=の次に記載された数字部分の"2","3"及び"5"は,ボックスのidの番号を表す。
259:
260:
261:
262:
上記結合情報は,①id0(rootボックスの左側内壁コネクタ)からid2(Set

Languageボックス)へ(2

61行),②id2(Set

Languageボックス)から

id5
(Localized

Textボックス)(260行)



③id5(Localized
3」(Say
ay

Textボックス)からidTextボックス)へ(259行),④「id3(S
Textボックス)からid0(rootボックスの右側

内壁コネクタ)へ(262行)と結合していることを表している。したがって,前記(ウ)aと同様に,上記結合情報のうち,ボックスの親ボックスを特定する情報(例えば,259行のinputowner="3"に対するoutputowner="5")は,構成要件Eの親ノードを特定する親ノード識別情報に該当する。
b
また,前記(ウ)bと同様に,被告プログラムにおけるボックスのうち,当該ボックスの入力コネクタと他のボックスの出力コネクタとの結合情報を含まない特定のボックスが構成要件Eのルートノード
に該当する。

c
以上によれば,被告プロクラムは,構成要件Eを充足する。

【被控訴人の主張】
(ア)

構成要件Eは,親ノード識別情報は,ノードデータに含ま

れると規定している。本件明細書の記載(【0036】,【0038】ないし【0042】,図2ないし図4,図9,図14)によれば,構成要件Eのノードデータは,ノードを示す特定の開始タグと,そのエンドタグとの間に挟まれた領域内のデータを意味するから,構成要件Eの親ノード識別情報は,ノードを示す特定の開始タグと,そのエンドタグとの間に挟まれた領域内のデータに含まれるものを意味する。また,
本件明細書の記載【0010】【0013】【0049】




図6,図8)によれば,構成要件Eの親ノードは,木構造を前提とした概念であるところ,木構造は,基本となるルートノードから複数の要素に枝分かれをした階層構造を意味するから,親は,1つの基本となる要素から複数の要素に枝分かれをした階層構造によって規定される親子関係における親を意味する。
(イ)

被告プログラムのフローダイアグラムは,rootボックス,Se
t
Languageボックス,Sayボックス及びrootボックス
の実行順序の処理の流れを定めたものであり,rootボックスから出てrootボックスに戻る閉路を構成しており,階層構造は存在しないから,木構造であるとはいえず,親子及び上下という概念は存在しない。したがって,被告プログラムは,木構造を前提とした概念である構成要件Eの親ノード及びルートノードを備えていない。
また,控訴人が構成要件Eの親ノード識別情報であると主張する
Linkタグ内の情報は,ボックス間の結合関係を表すものである上,各ボックスのBoxタグの開始タグとエンドタグとに挟まれた領域の外にあり(例えば,本件behavior.xar1のSet

lang

uageボックス(18行ないし91行)に係るLinkタグは,このボックスの領域外である301行ないし303行に存在する。),ノードデータに含まれているといえないから,構成要件Eの親ノード識別情報に当たらない。以上によれば,被告プログラムは,親ノード,ルートノード
及び親ノード識別情報を備えていないから,構成要件Eを充足しない。
(ウ)

当審における控訴人の追加主張は,争う。

争点1-3(構成要件Fの充足性)について
【控訴人の主張】
(ア)

構成要件Fの文言及び本件明細書の記載(【0031】,【003
2】)によれば,構成要件Fの(直系)上位ノードとは,順序系列内において,当該ノードに先行するノードを意味し,上位は,専ら下位ノードによるデータの承継に関するものを意味する。また,本件明細書の記載(【0007】)によれば,上位ノード変数データが表示されることによって,選択したノードで用いられている上位ノード変数データを容易に把握することができ,管理すべき情報の更新を,簡単かつ効率的に行うことができるのであるから,構成要件Fの上位ノード変数データは,当該ノードの直系上位ノードのノードデータに含まれる変数データを意味する。そして,本件明細書の記載(【0056】,【0066】)によれば,変数データは,変数名及び変数の値の2つの要素からなるものであり,変数名のみによって特定することもできるものである。
次に,構成要件Fの代入用スクリプトには,単純な代入処理だけ
でなく,数式を含んだ代入処理を行うスクリプトも含まれる。
(イ)

被告プログラムにおいて,Set

Languageボックス,S

ayボックス及びLocalized

Textボックスは,順序系列

内において,Say

Textボックスに先行するボックスであるから

(別紙被告プログラム説明書の図11及び図22),(直系)上位ノードを有し,その変数名又は変数の値は,上位ノード変数データに該当する。
次に,別紙4記載の被告プログラムの構成fにおいては,被告プログラムのLocalized
るSet

Textボックスは,直系上位ノードであ

Languageボックスにおいて入力された,上位ノード

変数データである変数langの値であるEnglishやJapaneseを利用して演算を行い,Localized
Text

ボックスの自ノード変数データであるHelloやこんにちは
を決定しているから,被告プログラムは,構成要件Fの代入用スクリプトを備えている。また,別紙4記載の被告プログラムの構成f’においては,被告プログラムのSay

Textボックスは,親からの変数を取得機能を

使用する場合,直系上位ノードであるSayボックスにおいて入力された上位ノード変数データであるSpeed(%)やVoiceShaping(%)の値を利用して演算を行うことにより,SayTextボックスの自ノード変数であるsentenceに代入し,Say

Textボックスの自ノード変数データであるsentence

の値を更新しているから,被告プログラムは,構成要件Fの代入用スクリプトを備えている。以上のとおり,被告プログラムは,(直系)上位ノード,上位ノード変数データ及び代入用スクリプトを備えているから,構成要件Fを充足する。
【被控訴人の主張】
(ア)

構成要件Fの文言によれば,上位ノード変数データは,直系上位ノードのノードデータに含まれるものであるところ,ノードデータは,ノードを示す特定の開始タグと,そのエンドタグとの間に挟まれた領域内のデータであるから,上位ノード変数データは,直系上位ノードのノードを示す特定の開始タグと,そのエンドタグとの間に挟まれた領域内のデータに含まれる変数データを意味する。
また,本件発明は木構造を前提とするものであるから,構成要件
Fの直系上位ノードも木構造を前提とした概念であるところ,
直系とは,一般に,人と人との間の血統が親子の関係で続いている系統を意味するから,直系上位ノードは,木構造を前提として,自ノードと親子関係にあり,自ノードよりもルートノードに近いノードを意味する。
さらに,構成要件Fは,代入用スクリプトは,上位ノード変数データを利用した演算を行って自ノード変数データの値を求めるものである旨を規定しているところ,上位ノード変数データの変数名だけでは,変数名を利用した演算を行って,自ノード変数データの値を求めることは不可能であり,本件明細書の記載(【0031】,【0032】)にも照らせば,上位ノード変数データは,変数名のみならず,変数の値を意味するか,少なくとも変数の値を含むものと解釈される。
次に,構成要件Dは,前記ノードデータに含まれるスクリプトと
規定し,構成要件Fは,この記載を受けて前記スクリプトは…自ノード変数データの値を求める代入用スクリプトを含んでおりと規定しているから,構成要件Fの代入用スクリプトは,自ノードのノードデータに含まれるものでなければならない。また,本件明細書記載の実施例(【0072】,【0073】)に照らせば,構成要件Fの代入用スクリプトは,親ノード変数データの値を自ノード変数データの値として代入するスクリプトを意味する。
(イ)

被告プログラムのフローダイアグラムにおける処理の流れは,閉路
を構成し,
親子,
上下という概念は存在しないから,
被告プログラムは,
構成要件Fの(直系)上位ノード及び上位ノード変数データを
利用した演算を行って自ノード変数データの値を求める代入用スクリプトを備えていない。控訴人の被告プログラムの構成fに関する主張についてみると,変数langは,
Set

Languageボックスに含まれる一時変数
(ソ

ースコードの実行後にはメモリから破棄される値を一時的に格納するもの)であり,自ノードであるSayボックス内に記載されたスクリプトには利用されておらず,また,langの値はSet

Languag

eボックスに記憶されていない。さらに,被告プログラムでは,Localized

Textボックスに予め記載された値であるHelloやこんにちはという値を,Set
Languageボックス

の変数データを用いて選択しているにすぎず,自ボックス変数に上位ボックス変数の値を代入していないから,構成fは,構成要件Fの代入用スクリプトに当たらない。次に,控訴人の被告プログラムの構成f’に関する主張についてみると,被告プログラムのSayTextボックスにおけるSpeed(%)及びVoiceShaping(%)は,いずれも上位ノード変数ではなく,Say
る。また,Say

Textボックスの自ボックス変数であ

Textボックスが親からの継承機能によって

Speed(%)及びVoiceShaping(%)の値

を継承する際,Sayボックスはその継承元のボックスであるところ,SayボックスとSay

Textボックスは結合情報で結合されてい

ないから,SayボックスはSay

Textボックスの上位ノードに

該当しない。
さらに,
Speed(%)及びVoiceShaping(%)

は,直系上位ノードのノードデータに含まれるものではなく,上位ノードのノードデータ中に変数の値を含むものではない。
加えて,本件behavior.xar1には,親からの継承機
能を実行するスクリプトは存在しないから,被告プログラムは,自ノードのノードデータに含まれる代入用スクリプトに利用され,代入用スクリプトが親ノード変数データの値を自ノード変数データの値として代入するスクリプトという構成が存在しない。
以上のとおり,被告プログラムは,(直系)上位ノード,上位ノード変数データ及び代入用スクリプトを備えていないから,構成要件Fを充足しない。

争点1-4(構成要件Gの充足性)について
【控訴人の主張】
(ア)
a
構成要件Gの木構造表示ステップについて
本件発明の木構造の表示の用語は,閉路を含むグラフを表示す
ることを排除するものではなく,構成要件Bのノードは,ノード
(頂点)と2つのノードを結ぶエッジ(辺)により構成されるグラフにおける頂点を意味するものであり,このグラフには,閉路を持つものも,閉路を持たないものも含まれることは,前記アの【控訴人の主張】の主張のとおりである。
被告プログラムは,Linkタグ内のinputowner(入力側・子)とoutputowner(出力側・親)により結合情報を認識し,これに従ってフローダイアグラム上でボックスとボックス間の結合線で表現することによって木構造を表示している。また,
Sayボックスのフローダイアグラムの表示において,左側の内壁コネクタと右側の内壁コネクタは別の図形
(点)
として表示されており,
ここに閉路は存在しないから,親ノード識別情報を利用してノードの木構造を表示しているといえる。したがって,被告プログラムは,構成要件Gの木構造表示ステップを備えている。b
この点に関し,原判決は,本件発明の木構造とは,ノードを表
示するラベルとラベル間を接続する結合線であるリードから構成される図として表現される表示に関する概念であって,基本となる要素,すなわちルートから複数の要素に枝分かれをした階層構造を意味し,閉路を含まないものと解される,被告プログラムのSayボックスのフローダイアグラムにおけるボックスの接続関係は,Sayボックスから出発してSayボックスに戻る閉路として表示されており,木構造であるとはいえないから,被告プログラムは,木構造を表示するものとはいえず,構成要件Gの木構造表示ステップを備え
ていない旨判断した。
しかしながら,前記aのとおり,本件発明の木構造の表示の用
語は,閉路を含むグラフを表示することを排除するものではなく,また,Sayボックスのフローダイアグラムの表示において,左側の内壁コネクタと右側の内壁コネクタは別の図形(点)として表示されており,ここに閉路は存在しない。
したがって,被告プログラムは,親ノード識別情報を利用して
ノードの木構造を表示しているといえるから,原判決の上記
判断は誤りである。
(イ)
a
構成要件Gのノードデータテーブル表示ステップについて
本件明細書の記載(【0046】)によれば,デザインテーブル20は,ツリービューア10に表示されたノードのうちの選択されたノードが有する情報を表示する領域であることからすると,構成要件Gのノードデータテーブル表示ステップにいうテーブルと
は,情報を表示する領域を意味する。
被告プログラムのフローダイアグラム画面上でボックスを選択してダブルクリックすると,当該ボックスに対応して管理されているスクリプトをスクリプトエディタによって表示することができるから
(別紙被告プログラム説明書の図14),被告プログラムは,スクリプトを表示するノードデータテーブル表示ステップを備えている。

b
被告プログラムのフローダイアグラム画面上でボックスを選択してクリックすると,右下に区分けされたインスペクタという名称のウィンドウ(以下インスペクタという。)に,①当該ボックスが有している入力・出力コネクタの名称,②当該ボックスの変数名が表示される。インスペクタ上のアイコンをクリックすると,当該ボックスのコネクタや変数の追加,コネクタの名称やタイプ等の編集,削除をすることができる。このインスペクタに表示された入力コネクタの名称は,スクリプトエディタにより表示されるスクリプトにも含まれている。
このうち,上記②の当該ボックスの変数名は,自ノード変数データを表示するものである(例えば,別紙被告プログラム説明書の図15及び図16記載の変数:VoiceShaping(%))。

したがって,被告プログラムは,自ノード変数データを表示す
るノードデータテーブル表示ステップを備えている。
c
次に,入力コネクタには,アプリを実行した際に,直近の親ボックスから引き渡される値が,当該コネクタに対応した引数へ書き込まれる。例えば,被告プログラムでは,Say
であるpは,Say

Textボックスの変数

Textボックスの入力コネクタ”onInp

ut_onStart()”という関数(別紙3-2の150行)の構成要素であり,直系上位ノードであるLocalized

Tex

tボックスの出力コネクタonStopped(Self,sentences[sDefaultLang])
(別紙3-2の219行)

ら出力された値を受け取る,コネクタの内部領域である。
そして,入力コネクタとは,親ボックスから引き渡される値を記憶する変数が図形化されたものであり,入力コネクタの名称が構成要件Gにおける上位ノード変数データに該当する。この入力コネクタ
の名称は,インスペクタに表示される。
したがって,インスペクタ及びスクリプトエディタにおける入力コネクタの名称に関する情報の表示は,上位ノード変数データを表示するものであるから,被告プログラムは,上位ノード変数データを
表示するノードデータテーブル表示ステップを備えている。
d
被告プログラムの構成g’に関し,被告プログラムのSay

Te

xtボックスのスクリプトエディタにおいて親からの変数を取得機能を使う場合,上位ノードであるSayボックスの変数から利用可能なものを一覧表示する機能がある。
したがって,被告プログラムは,上位ノード変数データを表示
するノードデータテーブル表示ステップを備えている。なお,本
件発明において,インスペクタとスクリプトエディタを同時に表示する必要はないが,被告プログラムにおいては,スクリプトエディタをインスペクタと同時に表示することも可能である。
e
以上によれば,被告プログラムは,構成要件Gの自ノード変数データ,上位ノード変数データ及びスクリプトを表示するノードデータテーブル表示ステップを備えている。
f
この点に関し原判決は,①構成要件Gのノードデータテーブル表示ステップにいうノードデータテーブルとは,ノードデータの一覧表であり,上位ノード変数データ,自ノード変数データ及び代入用スクリプトを同時に表示するものと解される,
②本件明細書の
【0
032】の記載から,ノードデータテーブルが表示するノード変数データは,変数の値を意味すると解されるとした上で,③被告プログラムの構成gについて被告プログラムのフローダイアグラム画面上のインスペクタに表示された入力コネクタの名称は変数の値ではないから,上位ノード変数データに当たらず,また,被告プログ
ラムの構成g’についてインスペクタ上にSay

Textボックス

の変数Speed(%)の値が表示されるが(別紙被告プログラム説明書の図19),これはSay

Textボックスにおいて表示され

るものであり,自ノード変数を表示しているものと認められ,上位ノード変数データを表示しているとみることはできないから,被告プログラムは,一覧表として自ノード変数データ及び上位ノード変数データを同時に表示しているということはできない,④さらに,親からの継承の機能に関して,本件behavior.xa
r1内に,自ノード変数データ及び上位ノード変数データを利用した演算を行って自ノード変数データの値を求める代入用スクリプト
があると認めるに足りる証拠はないとして,被告プログラムは,構成要件Gの自ノード変数データ,前記上位ノード変数データ及び前記スクリプトを表示するノードデータテーブル表示ステップを備えていない旨判断した。
しかしながら,本件明細書の記載(【0046】,【0079】,図6)によれば,本件明細書では,図6のデザインテーブルに示
すように,代入用スクリプト表示領域,生成用スクリプト表示領域,操作ボタン表示領域の表示は表形式というよりは,個々の情報をまとめて表示する領域という意味でテーブルという用語が使われてお
り,
その領域で表示すべき情報を,
画面上でひとまとめに配置するか,
分割して配置するかは,設計事項にすぎない。加えて,本件発明の技術的思想に照らせば,ノードデータテーブル表示ステップは,表
示された木構造の個々のノードに対応付けられた詳細情報を簡単に表示することができること(【0009】)により,文書ファイル(プログラム)の編集を容易にするためのものであるから,一覧表でなければならない等との制約を付けて解釈されるべきではない。
また,本件明細書の【0032】における変数の値(「変数データと記述する場合もある。)」との記載は,変数データという用語を,文脈によって,変数の値を指す意味で用いることもあるという注意書きであると理解できること,変数データは,変数名と変
数の型を意味するというのが,プログラミングに関する通常の用語であること(甲24),実質的にも,本件発明がノードデータテーブル表示ステップにおいて上位ノード変数データを表示させる目的は,
表示された木構造の個々のノードに対応付けられた詳細情報を簡単に表示することができる(【0009】)ことにより,文書ファイル(プログラム)の編集を容易にする点にあり,変数名が分かれば,その目的を達成することができることからすると,
本件発明の
変数データ
は,本件明細書において文脈上変数の値を意味すべき場合を除き,変数名を指すと解すべきである。
さらに,別紙3の2の153行では,self.getParameter("Speed(%)")は,SayボックスのSpeed(%)の値を代入し,これと自ノード変数データを組み合わせて発話に関する変数sentenceを求めているから,代入用スクリプトに該当する。
したがって,原判決の上記判断は,その前提を欠くものであって,誤りである。
(ウ)

小括
前記(ア)及び(イ)によれば,被告プログラムにおける情報表示ステップは,木構造表示ステップとノードデータテーブル表示ステップを含むものといえるから,構成要件Gを充足する。【被控訴人の主張】
(ア)

前記イの【被控訴人の主張】のとおり,木構造は,基本となる

ルートノードから複数の要素に枝分かれをした階層構造を意味するところ,被告プログラムのフローダイアグラムは,rootボックス,Set
Lauguageボックス,Sayボックス,rootボックスと
いう順序の処理の流れを定めており,rootボックスから出てrootボックスに戻る閉路を構成しているから,階層構造は存在せず,親子及び上下という概念は存在しない。
したがって,被告プログラムは,木構造を備えていないから,構
成要件Gの木構造表示ステップを備えていない。
(イ)a

テーブルは表を意味すること,本件明細書の記載(【006

5】,【0066】,【0057】,図6,図9,図10,図13)によれば,構成要件Gのノードデータテーブル表示ステップは,
変数名と変数の値とを表形式で表示するステップを意味し,また,自ノード変数データ,上位ノード変数データ並びに当該自ノード変数データ及び上位ノード変数データを用いた代入用スクリプトを,全て同時に表示するものを意味する。
b
この点に関し,控訴人は,控訴人主張の被告プログラムの構成gに関し,インスペクタに表示される入力コネクタの名称が上位ノード変数データに該当する旨主張するが,入力コネクタの名称は,コネクタ名であって変数ではない上,変数の値を含まないから,構成要件Gの上位ノード変数データに当たらない。
また,控訴人主張の被告プログラムの構成g’は,Say

Tex

tボックスのスクリプトエディタに表示される
p
は,
前記ウの
【被
控訴人の主張】のとおり,自ボックス関数の引数であって上位ノード変数ではなく,一時変数であり,pの値はSay

Textボックス

に記憶されておらず,被告プログラムにおいてpの値を表示することはできないから,構成要件Gの上位ノード変数データに当たらな
い。
そして,被告プログラムにおいて,親からの変数を取得機能に
よって表示されるのは,変数名にとどまり,変数の値は表示されないから,親からの変数を取得機能による表示は上位ノード変数データに当たらない。したがって,被告プログラムは,上位ノード変数データを表示
するノードデータテーブル表示ステップを備えていない。
c
以上によれば,被告プログラムは,構成要件Gの自ノード変数データ,上位ノード変数データ及びスクリプトを表示するノードデータテーブル表示ステップを備えていない。
(ウ)

前記(ア)及び(イ)によれば,被告プログラムは,木構造表示ステップ及びノードデータテーブル表示ステップをいずれも備えていないから,構成要件Gを充足しない。

争点1-5(構成要件H及びIの充足性)について
【控訴人の主張】
(ア)

更新とは,文書ファイルを変更するか否かに関わらず,自ノー

ド変数データの値を更新することを意味し,構成要件Hの更新するステップは,このような意味での更新を行うステップを意味する。被告プログラムでは,
SayTextボックスの自ノード変数である
sentenceの値が,代入用スクリプトの実行によって導かれるところ,sentenceの値は,直系上位ノードであるSayボックスのSpeed(%)及びVoiceの値の設定や,SetocalizedShaping(%)
Languageボックスで設定した言語,L

Textボックスで言語に対応して入力されるあい

さつ文に応じて更新されるから,被告プログラムは,構成要件Hの更新するステップを備えており,構成要件Hを充足する。(イ)

以上によれば,被告プログラムは,構成要件AないしHを充足する
から,これを前提とする構成要件Iを充足する。
したがって,被告プログラムは,本件発明の構成要件を全て充足するから,その技術的範囲に属する。
【被控訴人の主張】
(ア)

構成要件B,
C及びGの文言並びに本件明細書の記載【0043】



【0064】,【0067】,【0073】,図10)に照らせば,構成要件Hの更新ステップにおいては,文書ファイルに含まれる自ノード変数データが変更される必要がある。
しかしながら,被告プログラムにおいては,スクリプトの実行によりbehavior.xarの値が変更されることはないから,被告プログラムは,更新するステップを備えておらず,構成要件Hを充足しない。
(イ)

以上によれば,被告プログラムは,構成要件AないしHをいずれも
充足しないから,これを前提とする構成要件Iを充足しない。
したがって,被告プログラムは,本件発明の技術的範囲に属さない。⑵

争点2(無効の抗弁の成否)について
以下のとおり訂正するほか,原判決の事実及び理由の第2の4⑵記載のとおりであるから,これを引用する。

原判決18頁17行目から18行目までをア争点2-1(乙9発明を主引用例とする本件発明の新規性又は進歩性の欠如)についてと改める。

原判決18頁21行目の出願時を本件特許出願の優先日当時と
改める。


原判決19頁12行目の乙9発明の公報を乙9と,同頁13行
目から14行目にかけての

実質的相違点ではないから,新規性を欠く。

実質的相違点ではない。したがって,本件発明は,新規性を欠く。

と改める。


原判決19頁18行目の設計事項にすぎないから,の次に本件発明は,を加える。

原判決19頁23行目から24行目にかけての
相違点について相を違点に係る本件発明の構成がと,同行目のよってから25行目末尾までを

したがって,被控訴人の主張は理由がない。

と改める。

原判決19頁末行から20頁1行目までをイ争点2-2(乙16発明を主引用例とする本件発明の新規性又は進歩性の欠如)についてと改める。

原判決20頁4行目の出願時を本件特許出願の優先日当時と,
同頁10行目の相違点が既存のを相違点に係る本件発明の構成が
と改める。

原判決21頁9行目及び13行目の各本件明細書等を本件明細書
と改める。



争点3(損害の発生の有無及びその額)について
以下のとおり訂正するほか,原判決の事実及び理由の第2の4⑶記載のとおりであるから,これを引用する。

原判決21頁19行目,20行目及び23行目の各売上を売上げ
と改める。


原判決21頁23行目の本件特許権を本件発明と,同頁24行
目の本件におけるライセンス料率を本件発明の実施に対して受けるべき金銭の額に相当する損害額を算定するに当たっての実施料率と改める。


原判決22頁1行目の不法行為を本件特許侵害の不法行為と,
同頁2行目の本件特許権のライセンス料(特許法102条3項)に相当する損害額を本件発明の実施に対して受けるべき金銭の額に相当する損害額(特許法102条3項)と改める。
第3当裁判所の判断
当裁判所も,控訴人の請求は理由がないものと判断する。その理由は,以下のとおりである。
1
本件明細書の記載事項


本件明細書(甲3)の発明の詳細な説明には,次のような記載がある(下記記載中に引用する図1ないし図4,図6,図10は,別紙明細書図面のとおりである。)。

【技術分野】
【0001】
本発明は,コンピュータを用いて情報を管理する情報管理方法,情報管理プログラム,及び情報管理装置に関する。
【背景技術】
【0002】
コンピュータを用いて各種情報の管理を行う場合,それぞれの情報を記憶したファイル(文書ファイル,画像ファイル等)を,所定のフォルダに保管することによって行うのが一般的である。しかし,作成したフォルダの構造及びそれぞれのフォルダに保管するファイルの種類等は,任意であってフォルダの作成者に依存するため,作成者以外の者が必要な情報に適確にアクセスすることは,必ずしも簡単ではない。すなわち,多数の者が情報を共有化し,再利用できるように,情報管理を行うことは容易ではない。
【0003】
特許文献1には,情報の共有化,再利用を効率よく実現することができる文書情報管理システムが記載されている。
この文書情報管理システムは,
案件(プロジェクト)毎にツリーを作成して表示し,作成した文書ファイルを,表示されたツリーの任意のノードに付随させて,サーバコンピュータに保管するものである。
【0004】
また,異なる計算機やアプリケーションで共通に取扱うことができるデータ形式として,XML(ExtensibleMarkupLanguage)等の構造化文書規格があるが,特許文献2には,このような構造化文書を木構造として捉えて処理する構造化文書処理システムが記載されている。
【0005】
しかし,管理される各種情報の更新については,上記した管理システムにおいても,効率化が十分図られているとはいえない。すなわち,木構造のノードに含まれる情報は,相互に関連するものが多いが,上記した管理システムにおいては,それぞれの文書の該当する部分を個別に更新する必要があり,十分効率的とはいえない。
【0007】
本発明は,上記事情に鑑みなされたもので,管理すべき情報の更新を,簡単かつ効率的に行うことができる情報管理情報を提供することを目的とする。

【課題を解決するための手段】
【0008】
本発明の情報管理方法は,コンピュータが情報を管理する情報管理方法であって,前記コンピュータに複数のノードそれぞれに対応付けて入力された管理すべき情報を,前記ノードを識別するノード識別情報に対応付けられた複数のノードデータを含む文書ファイルとして前記コンピュータが記憶する情報記憶ステップと,前記情報記憶ステップで記憶された前記文書ファイルの情報を前記コンピュータが表示する情報表示ステップと,前記ノードデータに含まれるスクリプトを前記コンピュータが実行する情報評価ステップとを備え,前記ノードデータは,ルートノードを除いて,当該ノードの親ノードを特定する親ノード識別情報を含んでおり,前記スクリプトは,当該ノードデータに含まれる変数データである自ノード変数データと,当該ノードの直系上位ノードのノードデータに含まれる変数データである上位ノード変数データを利用した演算を行って,前記自ノード変数データの値を求める代入用スクリプトを含んでおり,前記情報表示ステップは,前記親ノード識別情報を利用して,前記ノードの木構造を表示する木構造表示ステップと,前記表示された木構造のノードのうちの選択されたノードの前記自ノード変数データ,前記上位ノード変数データ及び前記スクリプトを表示するノードデータテーブル表示ステップを含み,前記情報評価ステップは,前記代入用スクリプトの実行により,前記自ノード変数データの値を更新するステップを含むものである。
【0009】
本発明によれば,利用者が入力したデータに含まれるスクリプトを利用して,ノードデータを更新することができるので,管理すべき情報の更新を,簡単かつ効率的に行うことができる。また,複数のノードデータを含む1つの文書データを用いて,個々の業務や案件に関する情報を管理しているので,多数の利用者による情報の共有化,再利用を,簡単かつ効率的に行うことができるとともに,文書データに基づいて,簡単にノードの木構造を表示させることができ,業務や案件全体の把握を簡単に行うことができる。さらに,表示された木構造の個々のノードに対応付けられた詳細情報を簡単に表示することができる。
【0010】
本発明の情報管理方法は,前記木構造表示ステップが,前記ノードを示すノードラベルと,前記親ノードの前記ノードラベルとの間を接続する階層リードとの表示を含むものを含む。本発明によれば,ノードの階層関係を容易に識別することができる。
【0013】
本発明の情報管理方法は,前記ルートノードの前記ノードデータが,前記ルートノードが形成するページを識別する自己ページ番号を含んでおり,前記ルートノードを除くノードの前記ノードデータが,当該ノードが所属する所属ページを識別する所属ページ番号を含むとともに,当該ノードが形成する自己ページを識別する自己ページ番号を含むことが可能であり,前記木構造表示ステップが,前記自己ページ番号及び前記所属ページ番号に基づいて,前記ルートノードを先頭とする木構造を表示するとともに,前記自己ページ番号を有する前記ノードを先頭とする木構造を,異なるページに表示可能であるものを含む。本発明によれば,大きな木構造でも効率よく表示することができ,管理すべき情報の全体構成を容易に把握することができる。また,特定のノードから別の木構造を作成することができるので,別の観点の木構造を簡単に作成することができ,管理すべき情報の整理が容易になる。
【0015】
本発明の情報管理方法は,前記ノードデータテーブル表示ステップが,当該ノードの直系下位ノードの前記スクリプトでも利用される公開変数と,当該ノードの前記スクリプトでのみ利用される限定変数を含むものを含む。本発明によれば,必要な変数データのみを下位ノードに継承させることができる。
【0022】
本発明の情報管理プログラムは,上記した情報管理方法における各ステップを,コンピュータに実行させるための情報管理プログラムである。【発明の効果】
【0024】
以上の説明から明らかなように,本発明によれば,管理すべき情報の更新を,簡単かつ効率的に行うことができる。

【0027】
コンピュータにインストールする情報管理プログラムは,管理すべき情報をノードに対応付けて入力する情報入力ステップ,情報入力ステップで入力されたデータを,各ノードを識別するノード識別情報に対応付けられた複数のノードデータを含む文書として記憶する情報記憶ステップ,情報記憶ステップで記憶された文書の情報を表示する情報表示ステップ,及びノードデータに含まれるスクリプトを実行する情報評価ステップを実行するためのプログラムを含んでいる。
【0028】
図1に,ノードデータとして記憶される情報の一例を示す。記憶される情報は,ノード番号,ページ番号,親ノード番号,ノードラベル,ノード表示属性情報,変数情報,代入用スクリプト,生成用スクリプト,リンク情報を含む。
【0029】
ノード番号は,ノードを識別する情報であり,ノード生成時に自動的に一意の番号が付与される。ページ番号は,文書に含まれるノードを複数の木構造として表示するためのもので,そのノードが所属するページを識別する所属ページ番号に,そのノードが別のページを形成する場合にそのページを識別する自己ページ番号を含む。したがって,両方のページ番号が記憶されているノードは,2つのページに属することになる。親ノード番号は,そのノードの親ノードを識別する番号であり,ノード生成時に親ノードを指定することにより,その指定された親ノードのノード番号が自動的に記憶される。
【0030】
ノードラベルは,木構造表示時にそのノードを示す情報であり,ノード名称等任意の情報を記憶することができる。ノード表示属性情報は,ノード表示時の背景,文字の色,フォント等の文字属性,枠の形状,大きさ等の枠属性等を指定する情報である。ここで,JPG画像等をノードに表示したい場合は,
その画像ファイルの場所を指定するURL等が記憶される。
【0031】
変数情報は,各ノードが保持するデータであって,変数名に対応させて記憶される。記憶される変数は,下位ノードから参照される公開変数と,自ノード内でのみ使用する限定変数を含む。また,変数の値(変数データと記述する場合もある。)は,固定値が設定されても,スクリプトの実行によって演算された値が設定されてもよい。また,URLが設定されてもよい。どのような値が設定されるかは任意である。
【0032】
代入用スクリプトは,
自ノードの変数の値を演算するためのものである。
代入用スクリプトは,自ノードの変数の値である自ノード変数データと,そのノードの直系上位ノードの公開変数の値である上位ノード変数データを利用して記述することが可能である。
【0033】
生成用スクリプトは,辞書に登録してある別のノードやノード群(木構造の複数ノード)を利用して,新規にそのノードの下位のノードを生成するものである。生成用スクリプトを条件文と併用することにより,代入用スクリプトの実行により求められた変数データの結果によって,子ノードや孫ノードを生成することができる。生成用スクリプトを利用することにより,例えば,部品管理を行う場合,親部品のサイズによって子部品が変わるケースの子部品のデータを簡単に生成することができる。
【0034】
なお,
代入用スクリプト及び生成用スクリプトに使用する言語としては,スクリプト言語として使用されている任意の言語を使用することができる。【0035】
リンク情報は,各ノードにリンクするファイルに関する情報である。スタンドアローン型のコンピュータで実施する場合,この情報はリンクファイルのインデックス情報である。また,クライアント-サーバ型のコンピュータで実施する場合,リンクファイルをサーバに転送後,インデックス情報を作成し,記憶する。リンク情報を記憶することにより,各ノードをフォルダとして利用することが可能となる。
【0036】
ノードデータは,例えばタグ付き文書情報として記憶される。図2に,ノードデータの一例を示す。図2のデータは,ルートノードのノードデータの例であり,
ノード番号
(nodeNo)3450自己ページ番号


(ownPageNo)
が10,ノードラベル(label)がパッセル操作マニュアルである。所属ページ番号を示す(belongPageNo)が0,親ノード番号を示す(parentNodeNo)が0であることで,ルートノードであることを示している。図2のx=”100”からcolor=”0”までは,ノードの表示位置等のノード表示属性情報である。
【0037】
この形式では,変数情報が,の間に挿入され,代入用スクリプトが,の間に挿入され,生成用スクリプトが,の間に,リンク情報が,の間に挿入される。ただし,図2の例では,変数情報,代入用スクリプト,生成用スクリプトは,記憶されていない。
【0038】
図3に,ノードデータの別の例を示す。図3のデータは,ルートノード以外のノードデータの例である。所属ページ番号が3484,親ノード番号が3488となっており,ルートノード以外のノードのノードデータであることが把握できる。また,自己ページ番号が3526となっていることから,別ページの木構造の先頭ノードであることも把握できる。【0039】
図4に,管理すべきデータを複数のノードデータを含む文書情報として記憶させたものの一例を示す。図4の文書は,ヘッダ部40,ノードデータ部41a~41n,ライン部42,レポート部43を備える。
【0040】
ヘッダ部40は,管理される案件等を指すプロジェクトのプロジェクト番号,
名称
(プロジェクト名)
等を示す情報を含んでいる。
図4の例では,
プロジェクト名がManualver2,プロジェクト番号が10であることを示している。
【0041】
ノードデータ部41aは,ルートノードのノードデータを示し,ノードデータ部41b~41nは,ルートノード以外のノードのノードデータである。
【0042】
ライン部42は,
ノード間を接続するリードを定義する情報が記憶され
る領域である。ノード間を接続するリードは,親子のノード間を接続する階層リードと,階層関係とは無関係に一時的に変数を参照する参照元ノードと参照先ノード間を接続する参照リードがあるが,ライン部42は,参照リードの存在及び,位置,表示属性等を規定する。

【0043】
次に,記憶された文書情報の表示について説明する。図5に,文書情報の表示を行う場合の概略動作フローを示し,図4に示す文書の表示を行った場合の表示画面の例を図6に示す。
【0044】
図6の表示画面は,ツリービューア10とデザインテーブル20を有する。ツリービューア10は,ノードの木構造を表示する領域であり,情報管理時の各種操作を行うためのプルダウンメニュー,及びポップアップメニューを表示する領域も兼ねる。ノードの木構造の表示は,ラベルとリードの表示によって行い,図6の例では,ルートノードのラベル表示11aとルートノード以外のノードのラベル表示11b,11c,11dと,それらの間を接続する階層リード12b,
12c,
12dが表示されている。
【0045】
ラベル表示11a~11dは,ノード表示属性情報に基づいて表示されるが,ルートノードのラベル表示11aには,ルートノードであることを示すマーク13aが付加される。また,ルートノード以外のノードで自己ページ番号を有するノードは,その旨を示すマーク14b,14dが付加される。マーク14b,14dが付加されていることで,別ページの木構造が存在することを簡単に認識することができる。
【0046】
デザインテーブル20は,ツリービューア10に表示されたノードのうちの選択されたノードが有する情報を表示する領域であり,公開変数表示領域21,限定変数表示領域22,代入用スクリプト表示領域23,生成用スクリプト表示領域24,操作ボタン表示領域21a,22a,20aを有する。操作ボタン表示領域21aの各操作ボタンは,公開変数に対する各種操作を行うためのものであり,操作ボタン表示領域22aの各操作ボタンは,限定変数に対する各種操作を行うためのものである。また,操作ボタン表示領域20aの各操作ボタンは,デザインテーブル20に関する各種操作を行うためのものである。
【0047】
プロジェクト毎に作成された文書ファイルを選択し,開くと,図5に示す手順で表示処理が行われる。ステップS101では,文書データからルートノードを認識する。既述のように,ルートノードのノードデータは,所属ページ番号及び親ページ番号が0であるので,そのようなノードを探すことにより,ルートノードを認識することができる。なお,文書番号を一義的に割り当て,ルートノードの自己ページ番号を文書番号と一致させておくと,ルートノードの認識がさらに簡単になる。
【0048】
ステップS102では,認識したルートノードの自己ノード番号を認識し,ステップS103では,認識したページ番号のページに属するノードを認識する。すなわち,ルートノードの自己ページ番号を所属ページ番号として有するノードを認識する。
【0049】
次いで,ステップS103で認識したノードのラベル表示を行う(ステップS104)。ラベル表示は,そのノードのノードラベル及びノード表示属性情報に基づいて表示する。そして,表示したノードの親子関係に基づいて階層リードを表示し,さらに,文書のライン部42の情報を参考にして,参照リードを表示する(ステップS105)。
【0050】
この状態では,ツリービューア10に木構造が表示された状態である。ステップS106では,ツリービューア10に表示されたノードが選択されたかどうかを判定し,選択されている場合,デザインテーブル20の表示を行い(ステップS107),そのノードの変数,スクリプト等を表示する(ステップS108)。図6は,ルートノードを選択した場合の例であり,ルートノードには,変数情報等が記憶されていないので,デザインテーブル20に,データの表示はない。この状態で,別のノードを選択すると,そのノードの変数等が表示される。
【0051】
記憶された変数の値が,URL又はファイルパスである場合は,その変数を選択した状態で領域21a,22aの実行ボタンをおすことにより,そのURL又はファイルパスの内容を表示する。
【0052】
デザインテーブル20は,ノードを選択することで表示されるが,各ノードのリンク情報,及びノードレポートの表示は,ノード選択後メニューを表示させて行う。リンク情報表示が指示されると,そのノードのノードデータのリンク情報のリストを別ウィンドウで表示する。リンク情報が記憶されていない場合は,リストが空欄である。表示されたリストの中のファイルが選択されると,そのファイルの内容に応じた情報の表示を行う。ノードレポート表示が指示されると,別ウィンドウに表示するとともに,レポート領域43を参照し,
該当ノードの情報が記憶されている場合には,
その情報を表示した別のウィンドウに表示する。
【0053】
ノードのリンク情報,及びノードレポートは,リンク情報のリスト,あるいはレポート表示ウィンドウを表示した状態で,追加,削除を行うことができる。

【0054】
図6に示した状態で,表示された木構造及びノードデータの編集が可能であり,編集操作に対応した表示を行う(ステップS109)。ツリービューア10上では,ノードの追加,削除,表示位置移動,表示属性変更,ノードラベル変更等を,プルダウンメニュー,ポップアップメニューの設定により行う。例えば,表示位置の変更は,ラベル表示をドラッグすることによって行い,ノードラベル及び表示属性の変更は,変更用のウィンドウを表示させて行う。また,ノードの削除は,削除したいノードを選択した状態で,メニューを表示させて削除する。ノードの追加は,メニューで追加モードに設定後,追加したいノードの親となるノードを選択し,そのままドラッグすることにより,新規ノードを生成する。また,ノードの繋ぎ換えは,繋ぎ換えたいノードを選択し,メニューを表示させてノード繋ぎ換えを選択し,変更したい繋ぎ先のノード(親ノードとしたいノード)を選択することによって行う。生成されたノードのノードラベル,表示属性情報は,修正用のウィンドウを表示させて設定する。
【0055】
それぞれのノードに関するデータは,ノードデータとして1まとまりになっているので,これらの編集を行った場合でも,編集を行ったノードのノードデータに反映させるだけでよく,軽い処理負担で編集作業を行うことができる。
【0056】
デザインテーブルの情報を追加,
修正する場合は,
領域21a,
22a,
20aの該当するボタンを押すことによって行う。変数の追加は,領域21a又は22a追加ボタンを押して,新規の変数を生成し,変数名,値,修飾情報を入力する。変数の入力は,別ウィンドウで入力フォームを表示させて行ってもよい。
【0057】
代入用スクリプト及び生成用スクリプトは,公開変数領域21および限定変数領域22に表示された変数を利用して作成する。公開変数領域21には,自ノードの公開変数だけでなく,直系上位のすべてのノードの公開変数が表示される。直系上位のノード以外のノードの変数を参照したい場合は,参照リードを生成して,参照先のノードと関連付けておく。代入用スクリプト及び生成用スクリプトは代入用スクリプト領域23及び生成用スクリプト領域24に直接入力してもよいし,別のウィンドウを開いて入力するようにしてもよい。
【0058】
なお,デザインテーブル20の編集内容は,領域20aの更新ボタンを押すことによって,文書情報に反映される。
【0059】
続いて,ステップS110では,表示終了,すなわち文書クローズが指示されたかどうかを判定し,表示終了が支持されていない場合は,階層移動指示がされているか否かを判定する
(ステップS111)階層移動は,

マーク14b,14d等別の木構造の先頭ノードとなるノードを選択した状態で,ポップアップメニューから指示する。
【0060】
階層移動が指示されていると判定した場合,ステップS112で別ページの木構造を表示する。
木構造の表示は,
表示すべきページ番号を認識後,
ステップS103~ステップS105の処理と同様の処理を行う。木構造の先頭でないノードに対して階層移動が指示される(階層を降りる旨の指示)と,そのノードを先頭とするノードを表示する。その時のページ番号は,そのノードの自己ページ番号である。木構造の先頭ノードを選択して階層移動を指示すると,そのノードの所属ページ番号が示すページの木構造を表示する。

【0064】
図8から明らかなように,部分foreは,3つのMW70巾木(表)と3つのMW70パネル(表)から構成される。図9に,1つの部品MW70巾木(表)に対応するノード(図8では,便宜的に右肩に*を付してある。)のノードデータの一部を示し,図10に,そのノードが選択された場合の公開変数表示領域21の表示例を,図11に,限定変数表示領域の表示例を示す。
【0065】
公開変数表示領域に表示される公開変数は,
自ノードの公開変数51と,
直系上位ノードの公開変数52を含み,直系上位のノードの公開変数52は,自ノードの公開変数51と異なる色で表示される(図10では,フォントを変えて示してある。)。また,公開変数には,固定値が入力される公開変数と,
代入用スクリプトの実行によって計算される公開変数があり,
修飾領域になしあるいは要計算を表示することによりに区別され
る。
【0066】
要計算の公開変数の値は,後述するように代入用スクリプトが実行されるまでは空欄であり,図9及び図10は,代入用スクリプト実行前の状態を示している。なお,直系上位ノードに要計算の公開変数が含まれ,その公開変数の値が代入スクリプトの実行前で定まっていない場合,その公開変数は,下位ノードの公開変数領域21に表示されない。すなわち,他のノードからの参照が一時停止される。
【0067】
代入用スクリプト及び生成用スクリプトは,操作ボタン表示領域20aの評価ボタンを押すことにより実行される。図12に,スクリプト実行時の概略動作フローを示す。スクリプトを実行したいターゲットのノード選択し,評価ボタンが押されると,評価条件設定用のダイアログボックスを表示する(ステップS301)。このダイアログボックスでは,評価対象スクリプトの種類と,評価階層が少なくとも可能となっている。すなわち,代入用スクリプトのみの実行,生成用スクリプトの実行,両スクリプトの実行の設定と,自ノードのみを評価するか直系下位ノードの指定階層まで評価するかを設定する。
【0071】
ステップS307で,スクリプトを実行すべきノードが残っていると判断された場合は,ステップS303に戻り,下位のノードについて同様の判断を行い,スクリプトの実行を行う。

【0072】
次に,代入用スクリプト及び生成用スクリプトの具体例を,図8の*を付したノードをターゲットノードとして説明する。図9に示すように,ターゲットノードは,要計算の公開変数として,スライス数と色
を有しており,代入用スクリプトとして,スライス数=同一面数;と色=同一面数を有している。評価前は,図10に示すように,公開変数スライス数と色の値は空欄となっている。
【0073】
この状態で,このノードを選択し,評価ボタンを押し,評価条件として代入用スクリプトの実行を設定すると,記憶された代入用スクリプトを実行する。したがって,公開変数スライス数の値は,上位ノードの公開変数である同一面数の値1となり,公開変数色の値は,
同様に上位ノードの公開変数である
巾木色
の値
F-205
となる。
代入用スクリプト実行後のデザインテーブルの公開変数表示領域21の表示例を,図13に示す。


前記⑴の記載事項によれば,本件明細書には,本件発明に関し,次のとおりの開示があることが認められる。

コンピュータを用いて各種情報の管理を行う場合,それぞれの情報を記憶したファイルを,所定のフォルダに保管することによって行うのが一般的であるが,作成したフォルダの構造及びそれぞれのフォルダに保管するファイルの種類等は,任意であってフォルダの作成者に依存するため,作成者以外の者が必要な情報に適確にアクセスすることは簡単ではなく,多数の者が情報を共有化し,再利用できるように,情報管理を行うことは容易ではない(【0002】)。
また,従来,案件(プロジェクト)毎にツリーを作成して表示し,作成した文書ファイルを表示されたツリーの任意のノードに付随させてサーバコンピュータに保管することができる文書情報管理システムや,異なる計算機やアプリケーションで共通に取扱うことができるXML等の構造化文書を木構造として捉えて処理する構造化文書処理システムが存在したが,木構造のノードに含まれる情報は,相互に関連するものが多いにもかかわらず,上記各システムにおいては,それぞれの文書の該当する部分を個別に更新する必要があり,管理される各種情報の更新として,十分効率的とはいえなかった(【0003】ないし【0005】)。

本発明は,上記事情に鑑み,管理すべき情報の更新を,簡単かつ効率的に行うことができる情報管理方法を提供することを目的とするものであり,その課題を解決する手段として,コンピュータが情報を管理する情報管理方法であって,前記コンピュータに複数のノードそれぞれに対応付けて入力された管理すべき情報を,前記ノードを識別するノード識別情報に対応付けられた複数のノードデータを含む文書ファイルとして前記コンピュータが記憶する情報記憶ステップと,前記情報記憶ステップで記憶された前記文書ファイルの情報を前記コンピュータが表示する情報表示ステップと,前記ノードデータに含まれるスクリプトを前記コンピュータが実行する情報評価ステップとを備え,前記ノードデータは,ルートノードを除いて,
当該ノードの親ノードを特定する親ノード識別情報を含んでおり,前記スクリプトは,当該ノードデータに含まれる変数データである自ノード変数データと,当該ノードの直系上位ノードのノードデータに含まれる変数データである上位ノード変数データを利用した演算を行って,前記自ノード変数データの値を求める代入用スクリプトを含んでおり,前記情報表示ステップは,前記親ノード識別情報を利用して,前記ノードの木構造を表示する木構造表示ステップと,前記表示された木構造のノードのうちの選択されたノードの前記自ノード変数データ,前記上位ノード変数データ及び前記スクリプトを表示するノードデータテーブル表示ステップを含み,前記情報評価ステップは,前記代入用スクリプトの実行により,前記自ノード変数データの値を更新するステップを含むという構成を採用した(【0007】,【0008】)。
本発明によれば,利用者が入力したデータに含まれるスクリプトを利用してノードデータを更新し,管理すべき情報の更新を簡単かつ効率的に行うことができ,また,複数のノードデータを含む1つの文書データを用いて個々の業務や案件に関する情報を管理しているので,多数の利用者による情報の共有化,再利用を,簡単かつ効率的に行うことができるとともに,文書データに基づいて,簡単にノードの木構造を表示させることができ,業務や案件全体の把握を簡単に行うことができる上,表示された木構造の個々のノードに対応付けられた詳細情報を簡単に表示することができるため,管理すべき情報の更新を,簡単かつ効率的に行うことができるという効果を奏する(【0009】,【0024】)。
2
争点1(被告プログラムの本件発明の技術的範囲の属否)について本件の事案に鑑み,まず,争点1-2について判断し,次いで争点1-4について判断する。


争点1-2(構成要件Eの充足性)について

被告プログラムについて
原判決33頁15行目の17,及び同頁17行目の(ア)を削

るほか,同頁15行目から34頁2行目までに記載のとおりであるから,これを引用する。

構成要件Eのルートノードの意義について
(ア)

本件発明の構成要件Eの前記ノードデータは,ルートノードを除いて,当該ノードの親ノードを特定する親ノード識別情報を含んでおりとの記載によれば,親ノード識別情報はノードの親ノードを特定する識別情報であり,当該ノードのノードデータに含まれていることを理解できる。
そして,本件発明の特許請求の範囲には,ノードデータに関し,
前記コンピュータに複数のノードそれぞれに対応付けて入力された管理すべき情報を,前記ノードを識別するノード識別情報に対応付けられた複数のノードデータを含む文書ファイルとして前記コンピュータが記憶する情報記憶ステップ(構成要件B),親ノード識別情報に関し,前記情報表示ステップは,前記親ノード識別情報を利用して,前記ノードの木構造を表示する木構造表示ステップ(構成要件G)との記載がある。これらの構成要件B及びGの記載によれば,本件発明においては,複数のノードが木構造を有し,各ノードは当該ノ
ードを識別するノード識別情報を有すること,親ノード識別情報
は,木構造における親子関係にあるノードの親ノードを識別する情報であることを理解できる。
そして,構成要件Eの記載から,本件発明には,ルートノードと
ルートノード以外のノードが存在し,ルートノード以外の
ノードのノードデータは,親ノード識別情報を含んでいる
が,ルートノードのノードデータは,親ノード識別情報を
含んでいないことを理解できる。
(イ)

本件明細書には,ルートノードを定義した記載はないが,ルートノードに関し,…前記木構造表示ステップが,前記自己ページ番号及び前記所属ページ番号に基づいて,前記ルートノードを先頭とする木構造を表示するとともに,…(【0013】),

ノードデータは,例えばタグ付き文書情報として記憶される。図2に,ノードデータの一例を示す。図2のデータは,ルートノードのノードデータの例であり,ノード番号(nodeNo)が「3450

,自己ページ番号(ownPageNo)が10,ノードラベル(label)がパッセル操作マニュアルである。所属ページ番号を示す(belongPageNo)が0,親ノード番号を示す(parentNodeNo)が0であることで,ルートノードであることを示している。」(【0036】),

…図4の文書は,ヘッダ部40,ノードデータ部41a~41n,ライン部42,レポート部43を備える。

(【0039】),

ノードデータ部41aは,ルートノードのノードデータを示し,ノードデータ部41b~41nは,ルートノード以外のノードのノードデータである。

(【0041】),ライン部42は,ノード間を接続するリードを定義する情報が記憶される領域である。ノード間を接続するリードは,親子のノード間を接続する階層リードと,階層関係とは無関係に一時的に変数を参照する参照元ノードと参照先ノード間を接続する参照リードがある…【0042】,(
)図6の表示画面は,ツリービューア10とデザインテーブル20を有する。ツリービューア10は,ノードの木構造を表示する領域であり,情報管理時の各種操作を行うためのプルダウンメニュー,及びポップアップメニューを表示する領域も兼ねる。ノードの木構造の表示は,ラベルとリードの表示によって行い,図6の例では,ルートノードのラベル表示11aとルートノード以外のノードのラベル表示11b,11c,11dと,それらの間を接続する階層リード12b,12c,12dが表示されている。(【0044】)との記載がある。そして,図4には,ノードデータ部41aのnodeNoが3450のノードは,ルートノードであり,parentNodeNoが0であること,ノードデータ部41bのnodeNoが3451のノードは,parentNodeNoが3450であることが示されている。また,図6には,ルートノードのラベル表示11aが,階層関係にあるノードの最初のノードとして表示されており,親ノードに当たるノードが存在しないことが示されている。
これらの記載から,本件明細書には,ルートノードは,階層関係
にあるノードの木構造の先頭のノードであり,親ノードに当たるノードが存在しないこと,このため,ルートノードのノードデータの親ノード番号(parentNodeNo)0は,親ノードを
特定する識別情報には当たらないことが開示されていることが認められる。
(ウ)

以上の本件発明の特許請求の範囲の記載及び本件明細書の記載によ
れば,構成要件Eのルートノードは,階層関係にあるノードの木構造の先頭のノードであって,そのノードデータに親ノードを特定する親ノード識別情報が含まないものであると解される。

控訴人の主張について
控訴人は,本件behavior.xar1(別紙3-2)及び本件behavior.xar2(別紙7-1)の記載に基づいて,被告プログラムにおけるボックスにおいては,当該ボックスが属する順序系列内における一番最初のボックスであって,当該ボックスの入力コネクタと他のボックスの出力コネクタとの結合情報を持たないボックスが存在し,このボックスは,構成要件Eのルートノードに該当する旨主張するので,以下において判断する。
(ア)
a
本件behavior.xar1について
被告プログラムにより,本件ロボットにこんにちはを意味する
単語をしゃべらせる振る舞いを構築した際に作成されたbehavior.xarが本件behavior.xar1(別紙3-2)であり,この内容をフローダイアグラムとして示したものが,別紙6の図1ないし図3である。
本件behavior.xar1で記述されるSayボックスは,別紙6の図1に示され,SayボックスのonStartコネクタとonStoppedコネクタの間のフローダイアグラムは,別紙6の図2のとおり,①SayボックスのonStartコネクタ,②Localized

Textボックス,③Say
Textボックス,

④SayボックスのonStoppedコネクタの順にリードで接続されている。
本件behavior.
xar1においては,
rootボックス
(3
行ないし308行)
の階層,
rootボックスに包含されるSet

L
anguageボックス(18行ないし91行)及びSayボックス(92行ないし300行)の階層並びにSayボックスに包含されるSay

Textボックス(125行ないし179行)及びLoca

lized

Textボックス(180行ないし291行)の階層が

存在し,各ボックスを識別するために割り振られたidは,rootボックスが-1(3行),Set

Languageボックスが

2(18行),Sayボックスが1(92行),Say
extボックスが2(125行),Localized

T
Tex

tボックスが5(180行)である。
そして,上記各ボックス間の結合情報については,292行ないし294行及び301行ないし303行の<Linkinputowner=…/>という形式で記載されたLinkタグ内において,
inputownerが入力側のボックスのidを,outputownerが出力側のボックスのidをそれぞれ表している。ただし,292行及び293行のLinkタグ内においては,Sayボックスのidが1から0に,302行及び303行のLi
nkタグ内においては,rootボックスのidが-1から0
に,それぞれ置き換えられている。
292:293:294:301:302:303:b
前記aの認定事実によれば,本件behavior.xar1におけるボックス間の結合関係は,Linkタグ内のinputowner及びoutputownerのidを用いて,本件発明の親ノードに相当する結合元のボックスを識別する情報(outputownerの番号)と本件発明の(子)ノードに相当する結合先のボックスを識別する情報(inputownerの番
号)とにより示されていること,本件behavior.xar1の302行においては,idが0のrootボックスの結合元であ
る親としてidが1のSayボックスが記述されていることが認
められる。

c
控訴人は,
本件behavior.
xar1記載のボックスのうち,
当該ボックスが属する順序系列内における一番最初のボックスであって,当該ボックスの入力コネクタと他のボックスの出力コネクタとの結合情報を持たないボックスが,構成要件Eのルートノードに該
当する旨主張するところ,具体的にどのボックスがルートノード
に該当するのか明示していないが,rootボックスタグ内の結合情報を取り上げて主張を構築していることに照らすと,rootボックスがルートノードに該当する旨主張しているものと解される。
しかるところ,前記b認定のとおり,本件behavior.xar1には,rootボックスの結合情報(Linkタグ内のinputowner及びoutputownerのid)として,結合元である親を示すSayボックスのidである1が記述され
ており,このid1は,rootボックスの親ノードを特定する
親ノード識別情報に該当するものと認められる。
そうすると,rootボックスは,そのノードデータに親ノード識別情報が含まないものとはいえないから,構成要件Eのルートノードに該当しない。(イ)

別紙7-1の本件behavior.xar2について

a
本件behavior.xar2(別紙7-1)も,被告プログラムにより,本

件ロボットにこんにちはを意味する単語をしゃべ

らせる振る舞いを構築した際に作成されたbehavior.xarであるが,本件behavior.xar1と異なり,フローダイアグラムボックスが存在しないものである。
本件behavior.xar2の内容をフローダイアグラムとして示したものが,別紙7-2である。
本件behavior.
xar2においては,
rootボックス
(3
行ないし267行)の階層並びにrootボックスに包含されるSet
Languageボックス(18行ないし91行),Say

T
extボックス
(92行ないし146行)
及びLocalized

T
extボックス(147行ないし258行)の階層が存在し,各ボックスを識別するために割り振られたidは,rootボックスが-1(3行)SetLanguageボックスが

2
(18行)

Say

Textボックスが3(92行),Localized
Textボックスが5(147行)である。
そして,上記各ボックス間の結合情報については,259行ないし262行のLinkタグ内において,次のとおり記述されている。前記(ア)bと同様に,Linkタグ内において,inputownerが入力側のボックスのidを,outputownerが出力側のボックスのidをそれぞれ表している。ただし,261行及び262行のLinkタグ内においては,
rootボックスのidが
-1から0に置き換えられている。
259:260:261:262:b
前記aの認定事実によれば,本件behavior.xar2におけるボックス間の結合関係も,本件behavior.xar1と同様に,outputownerの番号とinputowner
の番号)により示されていること,本件behavior.xar2の262行においては,idが0のrootボックスの結合元と
してidが3のSay

Textボックスが記述されていること

が認められる。
c
控訴人は,前記(ア)と同様に,本件behavior.xar2記載のボックスのうち,具体的にどのボックスがルートノードに該
当するのか明示していないが,
rootボックスタグ内の結合情報
を取り上げて主張を構築していることに照らすと,rootボックスがルートノードに該当する旨主張しているものと解される。しかるところ,前記b認定のとおり,本件behavior.xar2には,rootボックスの結合情報(Linkタグ内のinputowner及びoutputownerのid)として,結合元である親を示すSay

Textボックスのidである3

が記述されており,このid3は,rootボックスの親ノード
を特定する親ノード識別情報に該当するものと認められる。
そうすると,rootボックスは,そのノードデータに親ノード識別情報が含まないものとはいえないから,構成要件Eのルートノードに該当しない。(ウ)

以上によれば,被告プログラムは構成要件Eのルートノードに

該当するボックスを備えているとの控訴人の主張は,理由がない。エ
小括
以上のとおり,被告プログラムは,構成要件Eのルートノードに該当する構成を備えているものと認められないから,同構成要件を充足しない。



争点1-4(構成要件Gの充足性)について

構成要件Gの木構造表示ステップについて
控訴人は,被告プログラムは,Linkタグ内のinputowner(入力側・子)とoutputowner(出力側・親)により結合情報を認識し,これに従ってフローダイアグラム上でボックスとボックス間の結合線で表現することによって木構造を表示しており,親ノード識別情報を利用して
ノードの木構造を表示しているといえるから,
被告プログラムは,構成要件Gの前記親ノード識別情報を利用して,前記ノードの木構造を表示する木構造表示ステップを備えている旨主張する。
そこで検討するに,本件発明は,複数のノードが木構造を有し
ていること,このノードの木構造の先頭のノードが構成要件Eのルートノードであることは,前記(1)イ(ア)及び(ウ)認定のとおりである。しかるところ,前記(1)ウ認定のとおり,被告プログラムは,構成要件Eの
ルートノード
に該当する構成を備えているものと認められないから,
被告プログラムは,複数のノードが木構造を有しているものと認
めることはできない。
そうすると,控訴人が挙げるフローダイアグラム上のボックスとボックス間の結合線の表現(表示)は,本件発明のノードの木構造の表示に当たるものと認めることはできないから,被告プログラムが構成要件Gの前記親ノード識別情報を利用して,前記ノードの木構造を表示する木構造表示ステップを備えているとの控訴人の上記主張は理由がない。イ
構成要件Gのノードデータテーブル表示ステップについて
(ア)
a
構成要件Gの前記上位ノード変数データの意義について
本件発明の構成要件Fの前記スクリプトは,当該ノードデータに含まれる変数データである自ノード変数データと,当該ノードの直系上位ノードのノードデータに含まれる変数データである上位ノード変数データを利用した演算を行って,前記自ノード変数データの値を求める代入用スクリプトを含んでおりとの記載及び構成要件Gの前記表示された木構造のノードのうちの選択されたノードの前記自ノード変数データ,前記上位ノード変数データ及び前記スクリプトを表示するノードデータテーブル表示ステップとの記載から,本件発明の上位ノード変数データは,当該ノードの直系上位ノードのノードデータに含まれる変数データであり,構成要件Fの前記自ノード変数データの値を求める代入用スクリプトによる演算に利用される変数データであることを理解できる。
次に,本件明細書には,上位ノード変数データに関し,

変数情報は,各ノードが保持するデータであって,変数名に対応させて記憶される。記憶される変数は,下位ノードから参照される公開変数と,自ノード内でのみ使用する限定変数を含む。また,変数の値(「変数データ

と記述する場合もある。)は,固定値が設定されても,スクリプトの実行によって演算された値が設定されてもよい。また,URLが設定されてもよい。
どのような値が設定されるかは任意である。

(【0031】),代入用スクリプトは,自ノードの変数の値を演算するためのものである。代入用スクリプトは,自ノードの変数の値である自ノード変数データと,そのノードの直系上位ノードの公開変数の値である上位ノード変数データを利用して記述することが可能である。(【0032】),公開変数表示領域に表示される公開変数は,自ノードの公開変数51と,直系上位ノードの公開変数52を含み,直系上位のノードの公開変数52は,自ノードの公開変数51と異なる色で表示される(図10では,フォントを変えて示してある。。)また,公開変数には,固定値が入力される公開変数と,代入用スクリプトの実行によって計算される公開変数があり,修飾領域に「なしあるいは要計算を表示することによりに区別される。」(【00
65】)との記載がある。
そして,図10には,直系上位ノードの公開変数の値である上位ノード変数データとして,52に変数名及びそれに対応する値が示されている(例えば,変数名の欄パネル色値

欄KW-400)。
これらの記載によれば,
本件明細書には,
上位ノード変数データ
にいう変数データは,変数の値を含むデータであることの開
示があることが認められる。
以上の本件発明の特許請求の範囲の記載及び本件明細書の記載によれば,構成要件Gの前記表示された木構造のノードのうちの選択されたノードの前記自ノード変数データ,前記上位ノード変数データ及び前記スクリプトを表示するノードデータテーブル表示ステップにいう前記上位ノード変数データは,当該ノードの直系上位ノードのノードデータに含まれる変数の値を含むデータであると解される。
b
これに対し控訴人は,本件明細書の【0032】における変数の値(「変数データと記述する場合もある。)」との記載は,変数データという用語を,文脈によって,変数の値を指す意味で用いることもあるという注意書きであると理解できること,変数データ
は,変数名と変数の型を意味するというのが,プログラミングに関する通常の用語であること(甲24),実質的にも,本件発明がノードデータテーブル表示ステップにおいて上位ノード変数データを表示させる目的は,表示された木構造の個々のノードに対応付けられた詳細情報を簡単に表示することができる【0009】ことにより,(

文書ファイル(プログラム)の編集を容易にする点にあり,変数名が分かれば,その目的を達成することができることからすると,本件発明の上位ノード変数データは,本件明細書において文脈上変数の
値を意味すべき場合を除き,変数名を指すと解すべきである旨主張する。
しかしながら,本件明細書には,上位ノード変数データが変数
名のみで構成される場合を含むことについての記載や示唆はない。また,前記aの本件明細書の記載に照らすと,【0032】の変数の値(「変数データと記述する場合もある。)」との記載は,変数データは変数の値を意味することを示した記載であると解するのが自然であり,これが変数の値を指す意味で用いることもあるという注意書きであるということはできない。
したがって,控訴人の上記主張は採用することができない。
(イ)

被告プログラムにおけるノードデータテーブル表示ステップの

有無について
a
控訴人は,入力コネクタは,親ボックスから引き渡される値を記憶する変数が図形化されたものであり,入力コネクタの名称が構成要件Gにおける上位ノード変数データに該当すること,インスペクタ
及びスクリプトエディタに表示される入力コネクタの名称に関する情報の表示は,上位ノード変数データを表示するものであることからすると,
被告プログラムは,
上位ノード変数データ
を表示する
ノードデータテーブル表示ステップを備えている旨主張する。
しかしながら,前記(ア)a認定のとおり,構成要件Gの前記上位ノード変数データは,当該ノードの直系上位ノードのノードデータに含まれる
変数の値
を含むデータであると認められるところ,
入力コネクタの名称は,変数の値であるとはいえないから,控訴
人の上記主張は,その前提を欠くものであり,理由がない。

b
控訴人は,被告プログラムの構成g’に関し,被告プログラムのSay

Textボックスのスクリプトエディタにおいて親からの変数を取得機能を使う場合,上位ノードであるSayボックスの変数から利用可能なものを一覧表示する機能があるから,被告プログラムは,上位ノード変数データを表示するノードデータテーブル表示ステップを備えている旨主張する。しかしながら,控訴人の上記主張は,スクリプトエディタにお
いて,どのような上位ノード変数データが表示されるのかについ
て具体的に主張するものではないから,その主張自体理由がない。c
以上によれば,被告プログラムは,上位ノード変数データを表
示するノードデータテーブル表示ステップを備えているものと認
めることはできないから,構成要件Gの前記表示された木構造のノードのうちの選択されたノードの前記自ノード変数データ,前記上位ノード変数データ及び前記スクリプトを表示するノードデータテーブル表示ステップを備えているものと認めることはできない。

まとめ
以上のとおり,被告プログラムは,構成要件Gの木構造を表示する木構造表示ステップ及びノードデータテーブル表示ステップを備えているものと認められないから,構成要件Gを充足しない。

(3)

小括
以上によれば,被告プログラムは,本件発明の構成要件E及びGを充足し
ないから,その余の点について判断するまでもなく,本件発明の技術的範囲に属するものと認めることはできない。
したがって,その余の点について判断するまでもなく,控訴人の請求は理由がない。
3
結論
以上のとおり,控訴人の請求は理由がないから,控訴人の請求を棄却した原判決は相当である。
したがって,本件控訴は理由がないからこれを棄却することとし,主文のとおり判決する。

知的財産高等裁判所第4部

裁判長裁判官

大鷹一郎
裁判官

國分隆文
裁判官

筈井卓矢
(別紙)
プ名称ログラム目録
Choregraphe(コレグラフ)

バージョン

2.3及び2.4

対象OS

Mac

OS,Windows及びLinux

(別紙7-1)

(別紙7-2)

(別紙)
明細書図面

【図1】

【図2】

【図3】

【図4】

【図6】

【図10】

トップに戻る

saiban.in