どぶ板PR専門！新規開拓訪問営業PR×ポスター広告許可貼り交渉＋ビラチラシ配布ポスティング＝あなたの街の「ポスターPRドットコム」
あなたの街の「ポスターPR」貼る(掲示許可交渉)前に知っておきたい地域情報「デザイン印刷」7
裁判年月日 令和 4年 8月30日 裁判所名 東京地裁 裁判区分 判決
事件番号 平３０（ワ）１７９６８号
事件名 著作権に基づく差止等請求事件
裁判結果 棄却 文献番号 2022WLJPCA08309006
出典
裁判所ウェブサイト
裁判年月日 令和 4年 8月30日 裁判所名 東京地裁 裁判区分 判決
事件番号 平３０（ワ）１７９６８号
事件名 著作権に基づく差止等請求事件
裁判結果 棄却 文献番号 2022WLJPCA08309006
原告 株式会社ヒューマンライフ・マネジメント
同訴訟代理人弁護士 竹花元
日高義允
被告 ＮＴＴエレクトロニクステクノ株式会社
同訴訟代理人弁護士 佐藤安紘
末吉亙
主文
１ 原告の各請求をいずれも棄却する。
２ 訴訟費用は原告の負担とする。
事実及び理由
第１ 請求等
１ 被告は、「モバカルネット」という名称の「コンピュータ上で動作する在宅医療用のカルテ等の文書作成、資料管理、情報共有及び予定管理のために利用されるソフトウェア」のプログラム（以下「被告プログラム」という。）を複製、翻案してはならない。
２ 被告は、被告プログラムを廃棄せよ。
３ 被告は、原告に対し、６１０万円及びこれに対する平成２４年８月３１日から支払済みまで年５分の割合による金員を支払え。
４ 仮執行宣言
第２ 事案の概要
本件は、原告が、別紙原告プログラム目録記載の各プログラム（以下、符号に応じて「原告プログラム１⑴」、「原告プログラム２⑴ア」等といい、原告プログラム１⑴から４を併せて「各原告プログラム」という。）について原告が著作権を有し、被告が各原告プログラムを複製又は翻案した被告プログラムをサーバにインストールして定期的に修正したこと等により、原告の各著作権（複製権又は翻案権）が侵害され損害を被った等と主張して、被告に対し、各著作権による差止請求権及び廃棄等請求権（著作権法１１２条１項、２項）に基づき、被告プログラムの複製、翻案の差止め及び廃棄を求めるとともに、不法行為による損害賠償請求権に基づき、損害の一部として６１０万円及びこれに対する不法行為より後の日である平成２４年８月３１日から支払済みまで平成２９年法律第４４号による改正前の民法所定の年５分の割合による遅延損害金の支払を求める事案である。
１ 前提事実（当事者間に争いがない事実及び証拠上容易に認められる事実。証拠は文末に括弧で付記した。なお、書証は特記しない限り枝番を全て含む。以下同じ。）
⑴ 当事者
原告は、医療機関等の運営支援等を目的とする株式会社である。（甲１）
被告は、光、電子部品、通信機器等電子機械器具、装置の研究開発、設計、製造及び販売等を目的とする株式会社である。（甲３）
⑵ 在宅医療情報システム株式会社管理のシステムウェア
ア 在宅医療情報システム株式会社は、クラウド型の在宅医療対応電子カルテ及びレセプトシステムである「ＨＯＭＩＳ」を管理している。
ＨＯＭＩＳは、同一法人が在宅医療を提供する複数の診療所を開設する場合に使用することを想定したシステムであり、①診療支援システム、②電子カルテ及びレセプトシステム並びに③患者情報共有システムの３つから構成されている。
イ ＨＯＭＩＳのうち②電子カルテ及びレセプトシステム（以下「ＨＯＭＩＳ②部分」という。）は、医療従事者が、モバイル端末を用いて、在宅患者の診療情報を記録、参照したり、診断書等の文書を作成したりするための電子カルテシステムと、医療事務員が、電子カルテに記録された患者診療情報に基づいて診療報酬を算定し、診療報酬の請求を行うためのレセプトシステムから成り、これらのシステムは、㋐Ｗｅｂフレームワーク、㋑ＨＯＭＩＳ管理ツール（利用者登録及びシステム作動に不可欠なマスタデータの管理等の機能を実現するプログラム群）、㋒電子カルテアプリケーション（在宅患者の診療情報の記録、入力補助、医事文書作成等の機能を実現するプログラム群）、㋓レセプトソフトウェア接続アプリケーション（電子カルテアプリケーションとＯＲＣＡレセプトソフトウェアの連結を実現するプログラム）及び㋔ＯＲＣＡレセプトソフトウェアの５つのモジュール群（以下、各モジュール群を上記の各符号に応じて「㋐部分」等ということがある。）から構成されている。
㋐から㋔部分は全てクラウド上の同一のサーバに存在しており、各部分の間の通信はセキュア（情報、システム、通信路などが保護されている状態）である必要がないため非セキュア通信が採用されている。
(ア) このうち、㋐部分は、原告プログラム１⑷、３⑴を含む。
また、㋒部分は、原告プログラム１⑴から⑶、２⑴から⑼ウ、３⑵を含む。
㋐及び㋒部分のファイル構成は、概ね、別紙㋐及び㋒部分のファイル構成記載のとおりであり、２０５ファイル、９万７７６３行から成る。
(イ) ㋓部分は、原告プログラム４を含む。
㋓部分は、㋐から㋒部分と㋔部分を連結するプログラムであり、このうち原告プログラム４は、㋔部分から受信したＸＭＬデータを解析する機能を有する。原告プログラム４には、オープンソースである「XML_Unserializer.php」（クラス）が用いられている。
(ウ) ㋔部分には、社団法人日本医師会（以下「日本医師会」という。）がＯＲＣＡ（Online Receipt Computer Advantage）プロジェクトによって開発して著作権を保有し、日本医師会ＯＲＣＡ管理機構株式会社がオープンソースとして提供するレセプトシステムである「日医標準レセプトソフト」（以下、便宜上「ＯＲＣＡ」という。）が用いられている。
（⑵につき、争いがない事実のほか、甲２、３１、乙２、弁論の全趣旨）
⑶ 被告プログラム
ア 被告プログラムは、クラウド型の在宅医療電子カルテ及びレセプトシステムであり、主に、単一の診療所での利用を想定している。被告プログラムは、カルテ入力支援機能、医事文書作成・管理機能、ＯＲＣＡとの連結機能などを備えている。（争いがない事実のほか、甲５）
イ 被告プログラムにおいては、サービス提供者が、アプリケーション、ＯＳ、ストレージ、ネットワーク基盤等を管理し、利用者は、ウェブブラウザやプログラムインターフェースを通じて、サービス提供者がサーバにインストールしたプログラムによって提供されるサービスを利用する方式（software as a service；ＳａａＳ）を採用している。したがって、被告は、被告プログラムをサーバに蔵置し、定期的にバグの修正やバージョンアップを行っている。また、被告プログラムは、仮想マシンによって随時複製されている。（争いがない事実）
ウ 被告プログラムのうち、ＯＲＣＡとの連結機能を担う部分は、ＯＲＣＡから受信したＸＭＬデータを解析する機能を有する。同部分には、オープンソースである「XML_Unserializer.php」（クラス）が用いられており、また、原告プログラム４のＸＭＬデータを解析する部分のソースコードのうち別紙原告プログラム４抜粋の赤字部分（以下「本件共通箇所」という。）と同じ記述を含む。（甲３１、乙４７、弁論の全趣旨）
⑷ 事実経過
ア 被告の従業員であるＡ（以下「ａ」という。）は、平成２１年６月頃、スケジュール、タスク及びプロジェクトの管理、文書の作成及び管理、入力支援などの基本的な機能を提供する「ＰＭ Ｐｏｒｔａｌ」（以下「ＰＭポータル」という。）というプログラムを作成した。ＰＭポータルは、「Ｗｅｂフレームワーク」及び「Ｗｅｂアプリケーション部」という各プログラム群によって構成されている。被告は、ＰＭポータルの著作権を有する。（乙１、８、６８、弁論の全趣旨）
イ 在宅医療情報システム株式会社及び被告は、平成２３年１０月２０日頃、情報処理業務に係る業務委託基本契約（以下「本件契約」という。）を締結した。本件契約においては、被告が納入物に関して著作した著作物に係る著作権は納入物の所有権移転と同時に在宅医療情報システム株式会社に移転すること、ただし、被告が従前から著作権を保有する著作物を納入物に組み込んだ場合には被告がその著作権を留保すること（１６条２項）等が定められていた。（争いがない事実のほか、甲８）
被告は、平成２３年１１月８日頃、本件契約に基づき、契約期間を同年１２月１日から平成２４年３月３１日として、Ｂ（以下「ｂ」という。）が代表者を務める医療法人社団悠翔会（以下「悠翔会」という。）向け電子カルテシステム及びレセプトシステム開発業務を請け負った。（争いがない事実のほか、甲９、弁論の全趣旨）
被告は、本件契約に基づき、平成２４年３月３１日までに、電子カルテ及びレセプトシステムであるＨＯＭＩＳ②部分を完成し、悠翔会に対して納入した。被告は、このうちの少なくとも㋓部分（ただし、Ｗｅｂフレームワーク、「XML_Unserializer.php」を用いた部分を除く。）を新たに作成し、その著作権が、納入と同時に、被告から在宅医療情報システム株式会社に譲渡された。なお、被告におけるＨＯＭＩＳ②部分の開発担当者はａであった。（争いがない事実のほか、甲２３、弁論の全趣旨）
ウ 被告は、平成２４年９月、在宅医療対応電子カルテシステムである被告プログラムの利用サービスの提供を開始し、平成２５年３月頃、被告プログラムに情報共有機能のサービスを追加した。なお、開発担当者はａであった。（弁論の全趣旨）
⑸ 一般的知見
ア インターネットを利用するシステムであるウェブシステムにおいては、利用者がウェブブラウザから入力したデータは、インターネットを介してウェブサーバに送信される。ウェブサーバには、Java、JavaScript、ＰＨＰ（Hypertext Preprocessor）、Python等のプログラミング言語を用いて作成されたウェブアプリケーションプログラムが実装されており、これによって利用者から送信されたデータが処理される。その後、データ処理結果を表示するために作成されたＨＴＭＬ文書がウェブブラウザに送信され、表示される。（争いがない事実のほか、乙７、９～１１）
ウェブページ（ブラウザの画面に表示されるページ）は、ウェブブラウザがウェブサーバに対してデータを送信して表示したいウェブページを要求し（ＨＴＴＰリクエスト）、これに対してウェブサーバからウェブページを表示するために必要なデータ（画像、動画、音声、文章等）が送り返される（ＨＴＴＰレスポンス）ことによって表示される。ウェブページを表示するために必要なデータのうちＨＴＭＬ文書がウェブページの文章構造を定義する中心的な役割を果たしている。ＨＴＭＬ文書は、画面表示用の言語、具体的には、ＨＴＭＬ言語（ウェブページのコンテンツや構造を決定する言語）、ＣＳＳ（ウェブページの見た目を決定する言語）、JavaScript（ウェブページに所定の動きを与える言語）によって構成される。ＨＴＭＬ言語のみでは、デザイン（配置や装飾）やインタラクティブな動作を定義することはできず、ＣＳＳを組み合わせることによりウェブページを装飾することが可能になり、JavaScriptを組み合わせることによりウェブページに動きをつけることが可能になる。ＨＴＭＬ文書は、ウェブサーバからクライアントサイドに送られウェブブラウザ上で起動することから、利用者側でその内容を確認することができる。他方、ＰＨＰは、ＨＴＴＰレスポンスの内容を制御するプログラミング言語であり、ＰＨＰにより記述されたプログラムは、ウェブサーバにインストールされウェブサーバ上で起動する。これらのプログラムは、ＨＴＴＰレスポンスに含まれるＨＴＭＬ言語、ＣＳＳ、JavaScriptなどの静的なデータをあらかじめウェブサーバ側で動的に作成したり、変更したりするため、ＰＨＰのプログラム構成の中には、ＨＴＭＬ、ＣＳＳ、JavaScriptにより記述されたプログラムが含まれることになる。ＨＴＴＰレスポンスとして送り返す部分以外は、利用者側で内容を確認することはできない。（乙３３）
イ 関数とは、入力されたデータを受け取り、定められたとおりの処理を実行して結果を返す一連のプログラム群をいう。
クラスとは、ウェブアプリケーションの機能を実現するための変数及び機能処理を定義したプログラムをいう。クラスは、いずれも具体的なコードとして記述されたものであり、クラスごとに一つのファイルが作成されている。
インスタンスとは、クラスを基に実行形式のプログラムを生成し、クラスの変数に値を設定して、機能処理を実行するプログラムをいう。
フレームワークとは、ウェブシステムの開発を行う際に頻繁に必要とされる基本的な機能、一般的な処理の流れをまとめたプログラム群をいう。フレームワークを用いる場合には、フレームワークが定めるルールに従ってソースコードを記述する必要がある。
（本項につき、争いがない事実のほか、乙９～１７、弁論の全趣旨）
ウ ウェブアプリケーションにおいては、あるプログラムのソースコードに、ＵＲＬを記述してインターネット上に存在するプログラムやデータの場所を指定してこれらを呼び出す方法、「include」、「include_once」、「require」、「require_once」等の構文を記述して他のプログラムファイルを呼び出す方法、繰り返し記述することが予想される命令文の組合せをまとめて関数として定義し、関数名を記述してあらかじめ定義された関数を呼び出す方法、JavaScriptプログラムにおいて「$.ajax」という関数を記述してウェブサーバに存在するＰＨＰプログラムを指定して呼び出す方法（Ajax通信。ウェブページを表示した状態のまま、別のページの表示や再読み込みなどを伴わずにウェブサーバと通信を行って表示内容を変更する。）などにより、複数のプログラムの動作を実現させることが一般的に行われている。（乙４０～４２、７０～７４）
２ 争点及び争点に関する当事者の主張
本件の争点は、
① 原告プログラム１⑴から３⑵（以下、併せて「本件３１個の各プログラム」という。）の各著作権が被告から在宅医療情報システム株式会社に譲渡されたか。
② 各原告プログラムの著作権が、在宅医療情報システム株式会社から原告、原告から悠翔会、悠翔会から原告に順次譲渡されたか。
③ 被告が各原告プログラムを複製、翻案しているか。
④ 損害の発生及び額
である。
⑴ 争点①（本件３１個の各プログラムの各著作権が被告から医療情報システム株式会社に譲渡されたか。）について
（原告の主張）
ア 本件３１個の各プログラムは、いずれも、被告が本件契約に基づき新たに作成した部分であり、各原告プログラムの各著作権は、本件契約に基づき、被告から医療情報システム株式会社に譲渡された。
なお、本件において、原告が著作権を有するプログラムは、本件プログラム４のほか本件３１個の各プログラムのそれぞれのプログラムであり、その各プログラムに創作性があり著作物であるといえる根拠は以下のとおりである。
イ 本件３１個の各プログラムには、それぞれについて創作性が認められる。
すなわち、ＰＭポータルは、複数の定型的なプログラムの構文をあらかじめまとめておき、コードを作成する際に構文を呼び出して個々の素材を当て込んでいくプログラム作成や業務管理のツールにすぎないから、ＰＭポータルを用いて作成されたプログラムは、個々の素材を組み合わせて新たに作成された著作物である。本件３１個の各プログラムにＷｅｂフレームワークが使用されていたとしても、ソースコードのうちＷｅｂフレームワーク自体の記述及びこれを利用した記述は一部にすぎず、自由に選択できる関数、変数は多々存在する。また、本件３１個の各プログラムは、ｂが、医師としての経験に基づき在宅医療の特性を踏まえて独自に工夫した機能を実現するためのものであるから、これらの機能を実行するソースコードには個性が発揮されている。ＨＯＭＩＳ②部分は、量的、機能的な側面から、ＰＭポータルとは全体的な構成が異なり、この点が、具体的には、次のとおり、本件３１個の各プログラムの創作性に反映されている。
(ア) ＨＯＭＩＳ②部分のファイル、フォルダは、大半が新たに作成されたものであり、本件３１個の各プログラムの記述は、その内容はＰＭポータルから流用されていたとしても電子カルテに必要な機能を抽出、分類している。
(イ) 本件３１個の各プログラムは、次のとおり、ＨＯＭＩＳ②部分の関数、変数、データ定義に係るファイルと連動等しており、ＰＭポータルと異なるＨＯＭＩＳ②部分の関数、変数、データ定義の共通化の仕方の特徴、すなわち、各ファイルの処理機能をどのような関数を使用してどの範囲でどのファイルにおいてサブルーチン化したかという点、ＰＭポータルと異なるデータベース構造やデータの格納方法、どの情報に共通変数を使用してどの範囲で共通変数を参照したかという点が、本件３１個の各プログラムの各ソースコードの記述に表われている。
ａ 原告プログラム１⑷は、共通関数を定義するファイルであるところ、３６個の関数のうち２９個が電子カルテに関するＨＯＭＩＳ独自のものである。そして、記述されている個々の関数は、必ずしも原告プログラム１⑷に記述する必要はなく、共通関数とすることなく各プログラムに直接実行処理文を記述する、代わりに「config.php」に記述する等の選択肢の無数の組合せの中から選択され作成されたものであり、他の選択肢を選択した場合にはソースコードが違うものになる。
ｂ 「variant.php」（原告プログラム１⑵、２⑴、２⑺ウ、２⑼ウによって参照されている。）は、アプリケーション全体の共通変数を定義するファイルであるところ、定義されている共通変数はＨＯＭＩＳ独自のものである。そして、どの情報を共通変数とするか、変数についてデータをどのような名称で定義するか（例えば、「variant.php」においては、性別について、ＯＲＣＡのデータ定義に合わせて、男性を「MALE」と、女性を「FEMALE」と定義したが、他の選択肢もある。）、どこで共通変数を定義するか、変数を参照するか各プログラムに直接実行処理文を記述するか等の選択肢の無数の組合せの中から選択され作成されたものであり、他の選択肢を選択した場合にはソースコードは違うものになる。
ｃ 原告プログラム３⑴（原告プログラム１⑶と連動している。）は、アプリケーション全体で共用するJavaScript関数を定義するファイルであり、うち３個の関数はＨＯＭＩＳ独自のものであり、ＨＯＭＩＳの中のプログラムを呼び出す内容のものであるから、ＨＯＭＩＳのプログラムの構造が前提となったものであり、ＨＯＭＩＳのプログラム構造がソースコードに表われている。
ｄ 「docs/config.php」（原告プログラム２⑵ア、２⑶アからウ、２⑷イ、２⑸アからウ、２⑹アからウ、２⑺アからウ、２⑻ア、イ、２⑼アからウによって参照されている。）は、各文書作成プログラムにおける共通関数２個、共通変数５０個を定義するファイルである。また、「pdetail/config.php」（原告プログラム１⑵によって参照されている。）も、共通変数を定義するファイルである。これらについては、どのような処理機能をどの範囲で共通関数とするか、共通関数を参照するか各プログラムに直接実行処理文を記述するか、どの情報をどの範囲で共通変数とするか、変数をどのように定義するか、どこで共通変数を定義するか、変数を参照するか各プログラムに直接実行処理文を記述するか等の選択肢の無数の組合せの中から選択され作成されたものであり、他の選択肢を選択した場合にはソースコードは違うものになる。
(ウ) 作成する医事文書の拡張性を高めた点が、プログラムの相互関係、呼出方法（どういう手段でどの画面を呼び出すかという点）、データの受渡方法、格納方法に表われ、ひいては、本件３１個の各プログラムのソースコードの記述に表われている。
具体的には、ＨＯＭＩＳ②部分には「model/docs」フォルダが設けられており、作成する文書の種類が増えた場合であっても、プログラム名に新しく数字を割り当てて、文書ごとに、原告プログラム２⑵アから⑼ウと同様の入力、編集、印刷プログラムを追加することができ、その結果、各プログラムを参照して呼び出す際には新たに数字を割り当てられた各プログラム名がソースコードに記述される。
また、入力、編集、印刷プログラムにおける表示、実行等は、ＵＲＬを記述することによりプログラムを呼び出して実現している。ここで、どの画面を呼び出すかは業務用アプリケーションの内容次第であり無数に選択肢が存在する。
原告プログラム２⑶から⑼の各イの各表示プログラムに対応する実行プログラムは「edit-do2.php」のみである。
さらに、原告プログラム２⑴により表示される画面において、「PDF」をクリックすればＰＤＦファイルが表示され文書を印刷することができるようになっており、ＰＤＦファイルを端末に表示することができる点がソースコードに記述されている。他方、ＰＤＦファイルの作成については、ＰＤＦの作成に失敗した場合について、原告プログラム２⑶から⑼の各ウでは使用されたオープンソースのバグがそのまま引き継がれているのに対し、原告プログラム２⑵ウではバグが修正されており、エラーメッセージを表示することができる点がソースコードに記述されており、この点について選択肢があったことを示している。
(エ) モバイル環境において電波状況によってカルテの保存ができない状況を回避するため通信状況を確認するようにした点が、ソースコードに表われている。
具体的には、原告プログラム１⑴においてカルテの編集完了後にAjax通信により原告プログラム３⑵を参照して呼び出し、通信に成功すると原告プログラム１⑴に定義した関数を呼び出し、他方、原告プログラム３⑵の呼出しに失敗した場合には、原告プログラム３⑴で通信エラーを表示する。これらの記述は、上記の業務用アプリケーションの内容に依存している。
(オ) その他、原告プログラム１⑴から⑶、２⑴、２⑵から⑼の各アからウは、ＵＲＬ、プログラムファイル呼出し、関数記述、Ajax通信により、他のプログラムや共通関数を呼び出しており、相互に関連している。そして、共通関数や他のプログラムを呼び出す方法のほか、どのような処理機能をどの範囲で共通関数とするか、共通関数を参照するか各プログラムに直接実行処理文を記述するか、どの範囲でプログラムをまとめるか、プログラムをどのフォルダ下に格納するか、プログラムを参照するか各プログラムに直接実行処理文を記述するかという点にも選択肢があり、他の選択肢を選択した場合にはソースコードは違うものになる。
（被告の主張）
ア 本件３１個の各プログラムの各著作権は、被告から医療情報システム株式会社に譲渡されていない。本件３１個の各プログラムを含む㋐及び㋒部分は、被告が著作権を有するＰＭポータルを用いて作成されたものであり、同部分に係る著作権は、従前から被告が保有していたものであり、本件契約に基づき、被告に留保されている。すなわち、㋐部分は、ＰＭポータルのＷｅｂフレームワークを用いている。㋒部分も、ＰＭポータルのＷｅｂフレームワーク（クラス、関数）を呼び出し、クラスのインスタンスを生成し、クラスの変数に値を設定したプログラムであって、ＰＭポータルのＷｅｂフレームワークを組み込んだものである上に、既に作成されていたＰＭポータルのＷｅｂアプリケーション部を電子カルテ用に形式的に修正して作成したにすぎない。
イ(ア) 原告プログラム１⑴から⑶、原告プログラム２⑴から２⑼ウは、Ｗｅｂフレームワークを基盤としてＷｅｂアプリケーション部を参照しながら、別のファイルを呼び出し、変数への値の設定、ＨＴＭＬ文書の定義等の単純な作業を行う指令を複数記述したものにすぎず、定型的にありふれたものであって作成者が個性を発揮する余地はない。このようなありふれた個々のソースコードの記載の順序や組合せも、表示する画面に対応した表現にすぎず、画面の内容はカルテや医事文書等の様式によりあらかじめ定められているから、この点についても創作性はない。
ＰＭポータルは、データ処理及び結果の画面表示等の一連の流れを記述統合したＷｅｂフレームワーク（クラス群等）とＷｅｂアプリケーション部（インスタンス群等）から構成されるプログラムである。一般的に、フレームワーク（クラス、関数）は、プログラムのひな型を構成するソースコードであり、その書き方には限定がなく、表現も作成者によって様々であり、創作性が認められる。他方、プログラム作成において、フレームワークを用いる場合、作成者はフレームワークに従ってプログラムを作成する必要があるため、個性を発揮する余地がほとんどなく、同じ目的を実現するためのコードであれば誰が作成しても同じようなものになる。したがって、ＰＭポータルのＷｅｂフレームワークを用いて作成された㋐及び㋒部分のうちＷｅｂアプリケーション部を修正した部分についても創作性は全くないか、あったとしても極めて微小である。
(イ) また、各ファイルの機能処理をどの範囲でどのファイルにおいてサブルーチン化したかという点、データベース構造やデータの格納方法、どの情報に共通変数を使用してどの範囲で共通変数を参照したかという点は、本件３１個の各プログラムの創作性とは何らの関係もない。
ａ 原告プログラム１⑷は、繰り返し使用される処理を関数としてまとめたものであり、具体的には、ＰＭポータルに記述されている関数をそのまま利用したもの、ＰＭポータルに記述されている関数を参照して作成したもの、ＰＭポータルに記述されているソースコードを参照して作成したもの、汎用的に使用されている関数を利用されているもののいずれかである。繰り返し記述されることが予想される命令文の組合せをまとめて関数とすることは一般的な手法であり、表現ではなくプログラミングに関するアイデアにすぎず、仮に表現があるとしてもありふれている上、その内容は、ＰＭポータルに記述されている関数等であり、まとめ方はいずれもＰＭポータルの「custom_util.php」と同じである。
ｂ 「variant.php」（原告プログラム１⑵、２⑴、２⑺ウ、２⑼ウによって参照されている。）は、いずれも画面に表示されるセレクトボックス（プルダウン形式やリスト形式のメニュー）の選択項目を定義したものにすぎず、選択項目を一つの配列の中で定義することはＰＭポータルにおいて採用されていたし、画面の選択項目に対応した配列の定義にすぎないから個性を発揮する余地もない。
また、データやデータの名称は保護の対象ではなく、どこで共通変数を定義するかは原告プログラム１⑵、２⑴、２⑺ウ、２⑼ウの創作性とは何ら関係がない。変数を参照するか各プログラムに直接実行処理文を記述するか等の選択肢は、現実的には存在しない。
ｃ 原告プログラム３⑴は、そもそもソースコードのどの部分に具体的に創作性があるという主張であるのか不明であるが、原告プログラム３⑴に含まれる２３個の関数のうち２０個はＰＭポータルの記述と同一である上、残り３個も繰り返し実行することが想定される画面表示処理（画面サイズの変更等）を汎用的な記述を用いて作成したものである。繰り返し記述されることが予想される命令文の組合せをまとめて関数とすることは一般的な手法であり、表現ではなくプログラミングに関するアイデアにすぎず、仮に表現があるとしてもありふれている上、まとめ方はいずれもＰＭポータルにおけるものと同じである。
ｄ 「docs/config.php」（原告プログラム２⑵ア、２⑶アからウ、２⑷イ、２⑸アからウ、２⑹アからウ、２⑺アからウ、２⑻ア、イ、２⑼アからウによって参照されている。）について、このうち関数は、繰り返し記述されることが予想される命令文の組合せをまとめて関数にしたものにすぎない。共通関数として定義するか否かという点は、表現の選択の幅の議論とは無関係であるし、直接実行処理文が記載されている部分もＰＭポータルの記述を使用しているから創作性が発揮される余地はない。また、変数は、画面に表示されるラジオボタン又はチェックボックスの選択項目を一つの変数として定義したものである。共通変数として定義するか否かという点は、表現の選択の幅の議論とは無関係であるし、どこで変数を定義するかは原告プログラム２⑵ア、２⑶ア～ウ、２⑷イ、２⑸アからウ、２⑹アからウ、２⑺アからウ、２⑻ア、イ、２⑼アからウの創作性とは何ら関係がない。選択項目を一つの変数として定義することはＰＭポータルにおいて採用されており、画面の選択項目に対応した配列の定義にすぎないから個性を発揮する余地もない。
「pdetail/config.php」（原告プログラム１⑵によって参照されている。）についても、共通変数として定義するか否かという点は、表現の選択の幅の議論とは無関係であるし、どこで変数を定義するかは原告プログラム１⑵の創作性とは何ら関係がない。
(ウ) ファイル名に数字を割り当てたり、医事文書に関するファイルを同一のフォルダの下に配置したりすることは、電子計算機に対する指令の組合せではなく、電子計算機に対する指令についての創意工夫ではない。プログラムの名称は著作権法の保護の対象ではない。
遷移元のプログラムから遷移先のプログラムに対し遷移元のプログラムにおいて入力された情報を引き渡し、遷移先のプログラムにおいてその受信した情報を処理して処理完了画面を表示させることは、ＰＨＰによりプログラムを記述するに当たり頻用される一般的な手法であり、複数のプログラムが同一のファイルをＵＲＬにより呼び出すことは、表現ではなくプログラミングに関するアイデアにすぎない。どの画面を呼び出すかという点は、表現の選択の幅の議論とは無関係である。仮に編集登録の実行を「edit-do2.php」という一つのファイルで行うことができる点に創意工夫があるというのであれば、そのような創意工夫はＷｅｂフレームワークの「dbCtl.php」により実現されている。
原告プログラム２⑴によりＰＤＦファイルを表示して文書を印刷することができる点はプログラミングに関するアイデアにすぎない。また、ＰＤＦファイルの作成についても単に仕様を指摘しているにすぎず、プログラムの具体的記述における表現上の創作性は何ら主張されていない。
(エ) 原告プログラム３⑵は、わずか１行から成るプログラムであり、創作性がないことは明らかである。Ajax通信により通信が成功した場合には所定の関数を起動させる一方、通信が失敗した場合にはエラーメッセージを表示させることはごく一般的に行われている。
(オ) 共通関数として定義するか否かという点は、表現の選択の幅の議論とは無関係であるし、直接実行処理文が記述されている部分もＰＭポータルの記述を使用しているから創作性が発揮される余地はない。また、同様に、繰り返し使用されることが予想される処理をまとめて共通プログラムとして定義するか否かという点は、表現の選択の幅の議論とは無関係であるし、結果として一つのプログラムを呼び出すか複数のプログラムを呼び出すかはいずれにしろごく単純な処理を記述するものである。プログラムをどのフォルダ下に格納するかはプログラミングに関するアイデアにすぎない。
⑵ 争点②（各原告プログラムの著作権が、在宅医療情報システム株式会社から原告、原告から悠翔会、悠翔会から原告に順次譲渡されたか。）について
（原告の主張）
在宅医療情報システム株式会社は、被告から原告プログラムの納入を受けた時点で原告に各原告プログラムに係る著作権を譲渡し、さらに、原告は、悠翔会にこれを譲渡した。悠翔会は、平成２５年１０月１日、原告に対し、原告プログラムに係る著作権を譲渡した。
（被告の主張）
各原告プログラムの著作権が、在宅医療情報システム株式会社から原告、原告から悠翔会、悠翔会から原告に順次譲渡されたことは何ら立証されていない。すなわち、原告が示す在宅医療情報システム株式会社と原告、原告と悠翔会の間の契約では、在宅医療情報システム株式会社が著作した著作物の著作権、原告が著作した著作物の著作権が、それぞれ納入に当たり譲渡されることになっているが、各契約が正式に成立したこと、各契約がＨＯＭＩＳを対象としていること、ＨＯＭＩＳのうち在宅医療情報システム株式会社及び原告が著作した部分は明らかではないし、在宅医療情報システム株式会社及び原告は各原告プログラムを著作していない。
⑶ 争点③（被告が各原告プログラムを複製、翻案しているか。）について
（原告の主張）
被告プログラムは、次のとおり、各原告プログラムに依拠し、各原告プログラムのソースコードを複製又は翻案することにより作成された。被告は、サービス提供開始に当たりサーバに被告プログラムを蔵置して各原告プログラムを複製、翻案し、定期的にバグの修正やバージョンアップを行って各原告プログラムを翻案し、仮想マシンによって随時複製している。
ア 本件３１個の各プログラムについて
被告プログラムは、本件各３１個の各プログラムによって実現される機能と同一又は類似の機能を備えており、データ名、データ名の並び順、データ名のミス（最高血圧を「bp_l」で、最低血圧を「bp_h」で表示しているなど。）、プログラム名、文書タイプなどにおいて、Ｗｅｂフレームワークを使用しているというだけでは説明できない多くの一致点が見られるところ、本件３１個の各プログラムに依拠して作成されたものであることは明らかである。
イ 原告プログラム４について
原告プログラム４は、ＯＲＣＡからＸＭＬデータを受信してこれを解析する機能を有し、同部分は高度な技術を必要とすることから、原告プログラム４のＸＭＬデータを解析する部分が被告プログラムに流用された可能性が高い。すなわち、被告プログラムのソースコードのうち一部は、原告プログラム４のうちの本件共通箇所と一致しており、本件共通箇所には創作性が認められる。
本件共通箇所にはオープンソースである「XML_Unserializer.php」が用いられているが、プログラムの作成者は、オープンソースに存在するバグや不十分な機能を前提に使用する部分や組合せを選択してコーディングを行うのであり、オープンソースのうちどの部分をどのように組み合わせるかについて創作性が認められる。
また、原告プログラム４は、ＯＲＣＡから受信するＸＭＬデータを解析し情報を取り出して作成したのであり、規約に定義されていないタグもある。
（被告の主張）
ア 本件３１個の各プログラムについて
本件３１個の各プログラムの著作権は被告が保有している（前記⑴（被告の主張））。
本件３１個の各プログラムの大部分は医事文書やカルテの入力画面や編集画面を生成して表示するものであり、これらのプログラムの記述はウェブブラウザ上で表示される各画面を構成するＨＴＭＬ文書の記述に対応するところ、ＨＯＭＩＳのＨＴＭＬ文書と被告プログラムのＨＴＭＬ文書は分量が全く異なり内容も多くの点で相違しているから、本件３１個の各プログラムとそれに対応する被告プログラムは類似していないことが明らかである。なお、データ名やデータ名の並び順が一致しているのは、所定の書式に従っているからにすぎず、そもそもソースコードの記述においてどのようなデータ名を付するかは重要な意味を持たない。
イ 原告プログラム４について
被告プログラムのうちのＸＭＬデータを解析する部分は、原告プログラム４とは全く別の構成により独自に創作した異なるプログラムであり、表現形式も全く異なっており、原告プログラム４の本質的な特徴を感得させるものではない。具体的には、原告プログラム４のＸＭＬデータを解析する部分は、所定の処理の内容をその処理の順序に従って記述しているにすぎないのに対し、被告プログラムのうちのＸＭＬデータを解析する部分は、解析処理の内容をクラスとして記述し、そのクラスのインスタンスを生成して機能処理を実行しているのであって、両者の表現形式は全く異なっている。そして、本件共通箇所は、オープンソースである「XML_Unserializer.php」（クラス）を用いたありふれた表現であるか（そのライブラリにバグが存在したとしても、利用者は、ソースコードをライブラリの仕様どおりに記述する必要があり、変数名を除き自動的にソースコードが決定されるから、作成者の個性が表れる余地はない。）、プログラム名又は変数名（タグの定義）という作成者の個性が表れない部分であり、いずれも創作性がなく、したがって、被告から医療情報システム株式会社に著作権が移転した部分に含まれない。
⑷ 争点④（損害の発生及び額）について
（原告の主張）
被告は、２８０の診療所に対して被告プログラムを販売しており、原告は、被告による侵害行為がなければＨＯＭＩＳの使用権を販売することができたところ、原告は、少なくとも上記の譲渡等数量２８０に原告プログラムの単位数量当たりの利益の額である２万円を乗じた５６０万円の損害をうけた（著作権法１１４条１項）。
また、原告が本件訴訟追行に要した弁護士費用のうち５０万円は、被告の不法行為と相当因果関係のある損害として、被告が負担すべきである。
したがって、損害の合計は６１０万円となる。
（被告の主張）
否認ないし争う。
第３ 当裁判所の判断
１ 認定事実
前提事実、掲記の証拠及び弁論の全趣旨によれば、次の各事実が認められる。
⑴ ＰＭポータルについて
ＰＭポータルは、組織内外のプロジェクトを効率的に管理することを目的としたウェブアプリケーションのプログラムである。
具体的には、ＰＭポータルは、利用者が、メッセージ、予定、プロジェクトの進捗状況などを入力してデータベース登録し、これを他の利用者と共有したり、所定の事項を入力、登録して、プロジェクトに関連する報告書や見積書等の文書を作成し、これらの文書をＰＤＦファイルとして表示したりすることができるプログラムであり、プログラミング言語としてＰＨＰとJavaScript、データベースとしてＭｙＳＱＬが用いられている。
ＰＭポータルは、ＷｅｂフレームワークとＷｅｂアプリケーション部という各プログラム群によって構成されている。
Ｗｅｂフレームワークは、ウェブシステムを開発するために頻繁に使用される基本的な機能、一般的な処理の流れをまとめたプログラム群であり、ウェブ画面表示処理、データベース処理、文書作成処理の各機能をまとめたＰＨＰ言語によって記述されたクラス群と、クラスを利用し様々な機能をまとめたＰＨＰ言語又はJavaScript言語によって記述された関数群から構成されている。具体的には、例えば、「dbCtl」（平成３１年３月２５日被告第２準備書面別紙１）がデータベース処理を実行するクラスとして定義され、「dispCtl」（同別紙２）がデータ処理結果の画面表示及びエラー画面表示の処理を実行するクラスとして定義され、「mbfpdf」がＰＤＦファイルを生成するクラスとして定義されている。
Ｗｅｂアプリケーション部は、Ｗｅｂフレームワークに記述されたクラスを呼び出し、クラスからインスタンスを生成し、生成したインスタンスに値を設定し、生成したインスタンスを実行して、プロジェクト管理用のウェブ画面表示処理、データベース処理、文書作成処理を行う実行インスタンス群から構成されている。各アプリケーションプログラムは、機能ごとにフォルダにまとめられており、各フォルダには、「config.php」という設定ファイルのほか、基本的に、入力（「_input1.php 」）、入力実行（「_input2.php 」）、編集（「_edit1.php 」）、編集実行（「_edit2.php」）、画面・ＰＤＦ表示（「_pdf1.php」等）の各プログラムファイルが存在する。Ｗｅｂアプリケーション部には、各「config.php」以外に共通処理のためのソースコード（関数、クラス等）は記述されていない。
ア ＰＭポータルのうちプロジェクト管理画面を作成、表示するプログラムにおいては、入力プログラム（project_input.php）により表示される管理画面において情報が入力され「登録する」ボタンがクリックされると、入力実行プログラム（project_input2.php、乙６５別紙１）によりデータベースへの登録処理が実行され「閉じる」画面を表示する処理が実行される。また、編集プログラム（project_edit.php、乙６５別紙２）により表示される編集画面において一度データベースに登録された情報が編集され「登録する」ボタンがクリックされると、編集実行プログラム（project_edit2.php）によりデータベースへの登録処理が実行される。このとき、JavaScript関数である「util.js」（乙６５別紙４）により必須項目が空欄になっていないかが確認され空欄がある場合には警告文が表示される。データベースに登録されたこれらの情報は表示プログラム（project_detail.php、乙６５別紙３）により、所定の方式で画面に表示される。
このうち、入力実行プログラム（project_input2.php）、編集プログラム（project_edit.php）、表示プログラム（project_detail.php）は、いずれも、初期設定をするプログラム、入力画面に入力された情報又は画面表示のための情報を登録するプログラム、画面を表示するプログラムの各部分から構成されている。初期設定をするプログラムの部分においては、Ｗｅｂフレームワークのインスタンス生成、利用者認証処理、リクエストデータの整形、変数の定義などの処理を、require 文により「config.php」を呼び出すなどして行う。入力画面に入力された情報又は画面表示のための情報を登録するプログラムの部分においては、Ｗｅｂフレームワークの「dbCtl」のインスタンスによってデータベースにアクセスするほか、変数に値を設定する処理が記述されている。画面を表示するプログラムの部分は、主に画面を表示するためのＨＴＭＬ文書であり、Ｗｅｂフレームワークの「dispCtl」のインスタンスによって同ＨＴＭＬ文書の内容が画面に表示される。
（本項につき、乙６５）
イ ＰＭポータルにおいては、「custom_util.php」において、頻繁に使用される関数がまとめて定義されている。このうち、例えば、「getMaxRevision」は特定ドキュメントの改版最大値を取得する関数であり、「getTypeMember」は任意の区分のプロジェクトメンバーを取得する関数であり、「getReportConfMember」は報告書確認対象メンバーを取得する関数であり、「getSmallStatus」はステータスを取得する関数である。（乙６６）
ウ ＰＭポータルの「project_index.php」は、プロジェクトのリストを作成し、画面上に表示するプログラムであり、初期設定をするプログラム、画面表示のための情報を登録するプログラム、画面を表示するプログラムの各部分から構成されている。初期設定をするプログラムの部分においては、Ｗｅｂフレームワークのインスタンス生成、利用者認証処理、リクエストデータの整形、変数の定義などの処理を、require文により「config.php」を呼び出すなどして行う。画面表示のための情報を登録するプログラムの部分においては、Ｗｅｂフレームワークの「allViews」のインスタンスを生成し、変数に値を設定する処理が記述されている。画面を表示するプログラムの部分は、主に画面を表示するためのＨＴＭＬ文書であり、Ｗｅｂフレームワークの「dispCtl」のインスタンスによって同ＨＴＭＬ文書の内容が画面に表示される。（乙６４）
エ ＰＭポータルのうち営業報告書をコンピュータ上で作成、表示するプログラムにおいては、入力プログラム（contract_report_input1.php、乙６３別紙１）において必要な情報が入力、選択され「送信」ボタンがクリックされるとデータベースへの登録処理が実行される。また、編集プログラム（contract_report_edit1.php、乙６３別紙２）において一度データベースに登録された情報が編集され「送信」ボタンがクリックされるとデータベースへの登録処理が実行される。登録処理が実行される際、JavaScript関数である「util.js」（乙６５別紙４）により必須項目が空欄になっていないかが確認され空欄がある場合には警告文が表示される。さらに、データベースに登録されたこれらの情報は出力プログラム（contract_report_pdf.php、乙６３別紙３）により、「営業報告書」という所定の書式によりＰＤＦ文書として画面に表示される。
これらのプログラムは、初期設定をするプログラム、画面表示のための情報を登録するプログラム、画面を表示するプログラムの各部分から構成されている。初期設定をするプログラムの部分においては、Ｗｅｂフレームワークのインスタンス生成、利用者認証処理、リクエストデータの整形、変数の定義などの処理を、require文により「config.php」を呼び出すなどして行う。画面表示のための情報を登録するプログラムの部分においては、Ｗｅｂフレームワークの「dbCtl」、「getDateList」等のインスタンスを生成し、データベースにアクセスしたり変数に値を設定したりする処理が記述されている。入力プログラム及び編集プログラムにおいては、画面を表示するプログラムの部分は、主に画面を表示するためのＨＴＭＬ文書であり、Ｗｅｂフレームワークの「dispCtl」のインスタンスによって同ＨＴＭＬ文書の内容が画面に表示される。他方、出力プログラムにおいては、画面を表示するプログラムの部分は、Ｗｅｂフレームワークの「mbfpdf」（オープンソース）のインスタンスにパラメータが順に設定され、ＰＤＦ文書が画面に表示される。
（⑴につき、各項に掲記のほか、乙１、８、１８、２３）
⑵ 各原告プログラムについて
ア ＨＯＭＩＳは、クラウド型の在宅医療電子カルテ及びレセプトシステムを提供するウェブアプリケーションであり、同一法人が在宅医療を提供する複数の診療所を開設する場合に使用することを想定している。
イ 本件３１個の各プログラムを含む㋐部分（Ｗｅｂフレームワーク）及び㋒部分（電子カルテアプリケーション）は、ＰＭポータルを基盤として開発された、医療従事者が、モバイル端末を用いて、在宅患者の診療情報を記録、参照したり、診断書等の文書を作成し、これらの文書をＰＤＦファイルとして表示したりすることができるプログラムであり、電子カルテ及びレセプトシステムを実現するに当たり、Ｗｅｂフレームワークを利用しており、プログラミング言語としてＰＨＰとJavaScript、データベースとしてＭｙＳＱＬが用いられている。
㋐部分（Ｗｅｂフレームワーク）は、ＰＭポータルのＷｅｂフレームワークを用いて作成された。㋐部分は、一部を除きＰＭポータルのＷｅｂフレームワークを構成するプログラムファイルから構成され、利用者が入力した情報は、「dbCtl」クラスによってデータベース処理が実行され、「dispCtl」クラスによってデータ処理結果等の画面表示が実行される。また、「mbfpdf」クラスによってＰＤＦファイルが生成される。
㋒部分（電子カルテアプリケーション）は、㋐部分すなわちＷｅｂフレームワークに記述されたクラスを呼び出し、クラスからインスタンスを生成し、生成したインスタンスに値を設定し、生成したインスタンスを実行して、電子カルテのウェブ画面表示処理、データベース処理、文書作成処理を行う実行インスタンス群から構成されている。各アプリケーションプログラムは、機能ごとにフォルダにまとめられており、各フォルダには、「config.php」という設定ファイルのほか、基本的に、入力（「_input1.php 」等） 、入力実行（「_input-do1.php」等）、編集（「_edit1.php」等）、編集実行（「_edit-do1.php」等）、画面・ＰＤＦ表示（「_pdf1.php」等）の各プログラムファイルが存在する。㋒部分には、各「config.php」以外に共通処理のためのソースコード（関数、クラス等）は記述されていない。
(ア) 原告プログラム１⑴から⑶は、入力プログラム（karteinput.php）、編集実行プログラム（karteedit-do.php）と一体として、カルテ画面をコンピュータ上で作成、表示するプログラムであり、㋒部分に含まれる。具体的には、入力プログラムにより表示される画面において情報が入力され「診察完了」ボタンがクリックされると、入力実行プログラム（原告プログラム１⑶）によりデータベースへの登録処理が実行され「カルテを登録しました」、「登録した画面を見る」という画面を表示する処理が実行される。また、編集プログラム（原告プログラム１⑴）により表示される編集画面において一度データベースに登録された情報が編集され「編集完了」ボタンがクリックされると、編集実行プログラムによりデータベースへの登録処理が実行される。データベースに登録されたこれらの情報は表示プログラム（原告プログラム１⑵）により、所定の方式で画面に表示される。
原告プログラム１⑴から⑶は、ＰＭポータルのプロジェクト管理画面を作成、表示するプログラム（前記⑴ア）を参照して記述された。具体的には、原告プログラム１⑴についてＰＭポータルの編集プログラム（project_edit.php）を、原告プログラム１⑵についてＰＭポータルの表示プログラム（project_detail.php）を、原告プログラム１⑶についてＰＭポータルの入力実行プログラム（project_input2.php）をそれぞれ参照して記述された。これらは、いずれも、初期設定をするプログラム、入力画面に入力された情報又は画面表示のための情報を登録するプログラム、画面を表示するプログラムの各部分から構成されている。初期設定をするプログラムの部分においては、Ｗｅｂフレームワークのインスタンス生成、利用者認証処理、リクエストデータの整形、変数の定義などの処理を、require文により「pdetail/config.php」を呼び出すなどして行う。入力画面に入力された情報又は画面表示のための情報を登録するプログラムの部分においては、Ｗｅｂフレームワークの「dbCtl」のインスタンスによってデータベースにアクセスするほか、変数に値を設定する処理が記述されている。画面を表示するプログラムの部分は、主に画面を表示するためのＨＴＭＬ文書であり、Ｗｅｂフレームワークの「dispCtl」のインスタンスによって同ＨＴＭＬ文書の内容が画面に表示される。また、原告プログラム１⑴においては、ＰＭポータルの「util.js」及びオープンソースライブラリである「jQuery」を参照して作成されたJavaScriptの記述により、必須項目が空欄になっていないかが確認され空欄がある場合には警告文が表示される。原告プログラム１⑵においては、「jQuery 」を参照して作成された汎用的なJavaScriptの記述により動きのある画面が表示される。
その結果、原告プログラム１⑴から⑶の記述のうち初期設定をするプログラム、画面表示のための情報を登録するプログラムの部分には、ＰＭポータルのソースコードの記述に類似した記述が多数存在する。
（本項につき、乙６５）
(イ) 原告プログラム１⑷は、原告プログラム１⑴から⑶、２⑴、２⑵アから⑼ウ等において繰り返し使用される処理を３６個の関数として記述しこれらをまとめたファイルであり、㋐部分に含まれる。
原告プログラム１⑷に記述された関数は、ＰＭポータルにおいて頻繁に使用される処理を関数として記述しこれらをまとめたファイル（custom_util.php）（前記⑴イ）や、ＰＭポータルのその他の記述や汎用的な記述を参照して記述された。
具体的には、６個の関数は、ＰＭポータルの「custom_util.php」に記述されている関数をそのまま使用したものであり、２２個の関数は、「custom_util.php」に記述されている関数を参照して作成されたものであり（具体的には、ＰＭポータルの「custom_util.php」に記述されている「getMaxRevision」や「getTypeMember」が所定のデータベースから所定の情報を取得する関数の、「getReportConfMember」を配列から指定の情報を参照し一致不一致を出力する関数の、「getSmallStatus」がcount関数で繰り返し回数を算出しfor文とif文で配列データの値により場合分けを繰り返しそれぞれの場合で異なる値を設定する関数の作成に参照された。）、７個の関数は、ＰＭポータルに記述されているソースコードを参照して作成されたものであり、２個の関数は、汎用的に記述されている関数を使用したものである。
その内容は、所定のデータベースから所定の情報を取得する関数やＰＨＰの一般的な記述による画面表示用の関数など、いずれも単純な作業が記述されたものである。
その結果、原告プログラム１⑷の記述のうち相当部分が、ＰＭポータルのソースコードに類似したものとなっている。
（本項につき、甲４１、乙６６）
(ウ) 原告プログラム２⑴は、原告プログラム２⑵アから２⑼ウによって作成される医事文書のリストを作成し、画面上に表示するプログラムであり、㋒部分に含まれる。
原告プログラム２⑴は、ＰＭポータルのプロジェクトのリストを作成、表示するプログラム、具体的には「project_index.php」（前記⑴ウ）を参照して記述された。原告プログラム２⑴は、初期設定をするプログラム、画面表示のための情報を登録するプログラム、画面を表示するプログラムの各部分から構成されている。初期設定をするプログラムの部分においては、Ｗｅｂフレームワークのインスタンス生成、利用者認証処理、リクエストデータの整形、変数の定義などの処理を、require文により「pdetail/config.php」を呼び出すなどして行う。画面表示のための情報を登録するプログラムの部分においては、Ｗｅｂフレームワークの「allViews」のインスタンスを生成し、変数に値を設定する処理が記述されている。画面を表示するプログラムの部分は、主に画面を表示するためのＨＴＭＬ文書であり、Ｗｅｂフレームワークの「dispCtl」のインスタンスによって同ＨＴＭＬ文書の内容が画面に表示される。
その結果、原告プログラム２⑴の記述のうち初期設定をするプログラム、画面表示のための情報を登録するプログラムの部分には、ＰＭポータルのソースコードの記述に類似した記述が多数存在する。
（本項につき、乙６４）
(エ) 原告プログラム２⑵アから⑼ウは、医事文書（診断書、主治医意見書、診療情報提供書（医療機関）及び（居宅）、訪問看護指示書、特別訪問看護指示書、死亡診断書、マッサージ同意書）をコンピュータ上で作成、表示するプログラムであり、㋒部分に含まれる。
原告プログラム２⑵アから⑼ウは、ＰＭポータルの「営業報告書」を作成、表示するプログラム（前記⑴エ）を参照して記述された。具体的には、入力プログラムである原告プログラム２⑵から⑼の各アについてはＰＭポータルの「contract_report_input1.php」を参照して記述され、編集プログラムである原告プログラム２⑵から⑼の各イについてはＰＭポータルの「contract_report_edeit1.php」を参照して記述され、印刷プログラムである原告プログラム２⑵から⑼の各ウについてはＰＭポータルの「contract_report_pdf.php」を参照して記述された。
これらのプログラムは、いずれも、初期設定をするプログラム、画面表示のための情報を登録するプログラム、画面を表示するプログラムの各部分から構成されている。
初期設定をするプログラムの部分においては、Ｗｅｂフレームワークのインスタンス生成、利用者認証処理、リクエストデータの整形、変数の定義などの処理を、require文により「docs/config.php」を呼び出すなどして行う。
画面表示のための情報を登録するプログラムの部分においては、Ｗｅｂフレームワーク等の関数にデータを代入したり、Ｗｅｂフレームワークのインスタンスによりデータベースにアクセスしたり変数に値を設定したりする処理が記述されている。入力プログラム及び編集プログラムにおいては、画面を表示するプログラムの部分は、主に画面を表示するためのＨＴＭＬ文書であり、Ｗｅｂフレームワークの「dispCtl」のインスタンスによって同ＨＴＭＬ文書の内容が画面に表示される。また、Ｐ Ｍ ポータルの「util.js」及びオープンソースライブラリである「jQuery」を参照して作成されたJavaScriptの記述により、必須項目が空欄になっていないかが確認され空欄がある場合には警告文が表示される。入力プログラム（原告プログラム２⑵から⑼の各ア）においては、入力終了後、それぞれＵＲＬを記述して対応する登録プログラムが呼び出される。また、編集プログラムについては、編集終了後、原告プログラム２⑵イにおいてはＵＲＬを記述して「edit-do1.php」が登録プログラムとして呼び出されるのに対し、原告プログラム２⑶から⑼の各イにおいては、ＵＲＬを記述していずれも「edit-do2.php」が登録プログラムとして呼び出される。印刷プログラムにおいては、画面を表示するプログラムの部分は、Ｗｅｂフレームワークの「mbfpdf」のインスタンスにパラメータが順に設定され、ＰＤＦ文書が画面に表示される。
なお、原告プログラム２⑵アから⑼ウにおいて作成、表示される医事文書について、基本的な様式は通知により定められるなどしていて、その各記載事項は性質上概ね定まっている（厚生労働省保険局医療課長等通知「診療報酬の算定方法の一部改正に伴う実施上の留意事項について」、本件医療機関及び保険医療療養担当規則２２条、２３条、様式１、２）。
（本項につき、乙２４、２６～３２、４６、６３）
(オ) 原告プログラム３⑴は、繰り返し使用される処理を２３個のJavaScript関数として記述しこれらをまとめたファイルであり、㋐部分に含まれる。
原告プログラム３⑴に記述された関数のうち、２０個はＰＭポータルに記述されている関数をそのまま使用したものであり、３個は、画面サイズの変更など画面表示処理を汎用的に記述されている関数を参照して作成したものである。
その内容は、いずれも、画面表示、入力確認やメニューの設定などの機能を実現する短い記述である。
（本項につき、争いがない事実のほか、甲４５）
(カ) 原告プログラム３⑵は、ＰＨＰの開始タグ及び終了タグと空白行のほかは、「echo 1;」という、echo文により定数である「１」を送信する処理を行う１行から成るプログラムであり、㋒部分に含まれる。
原告プログラム３⑵は、通信が確立されているかを確認する機能を実現するものであり、具体的には、原告プログラム１⑴（編集プログラム）により表示される編集画面において情報が編集され「編集完了」ボタンがクリックされると（前記(ア)）、原告プログラム３⑴に定義された関数が参照されAjax通信により原告プログラム３⑵が呼び出され、この通信に成功した場合には編集データ登録プログラムによりデータベースへの登録処理が実行される一方、この通信に失敗した場合には警告が表示される。
（本項につき、甲４５）
(キ) 「variant.php」は、原告プログラム１⑵、２⑴、２⑺ウ、２⑼ウ等において共通して使用される４２個の変数を定義してこれらをまとめたファイルであり、㋐部分に含まれる。
これらの変数は、画面に表示されるセレクトボックス（プルダウン形式やリスト形式のメニュー）の選択項目を一つの配列の中で定義したものである。
（本項につき、甲４５）
(ク) 「pdetail/config.php」は、原告プログラム１⑵等において共通して使用される４個の変数を定義してこれらをまとめたファイルであり、また、「docs/config.php」は、原告プログラム２⑵ア、２⑶アからウ、２⑷イ、２⑸アからウ、２⑹アからウ、２⑺アからウ、２⑻ア、イ、２⑼アからウ等において、繰り返し使用される処理を２個の関数として記述し、共通して使用される５０個の変数を定義してこれらをまとめたファイルであって、いずれも㋒部分に含まれる。
「docs/config.php」において定義された関数の内容は、所定のデータベースから所定の情報を取得する関数やＰＨＰの一般的な記述による画面表示用の関数など、いずれも単純な作業が記述されたものである。また、「docs/config.php」において定義された変数は、概ね、ラジオボタン又はチェックボックスの選択項目を一つの配列の中で定義したものである。
（本項につき、甲４５）
ウ(ア) 原告プログラム４を含む㋓部分（レセプトソフトウェア接続アプリケーション）は、㋒部分と㋔部分の連結を実現するプログラムである。
㋓部分は、クラウド上の㋐から㋒部分及び㋔部分と同一のサーバに存在しており、各部分の間の通信はセキュアである必要がないため非セキュア通信が採用されている。
ＨＯＭＩＳにおいてレセプトシステムを使用する方法は、新規に患者情報を登録する場合には、㋔部分において、患者情報をＯＲＣＡのデータベースに登録した後、この情報を同データベースからＸＭＬデータとして出力し、㋓部分において、これを受信、解析して、ＨＯＭＩＳのデータベースに登録するというものであり、また、既に登録されている患者についての診療情報を登録する場合には、㋒部分において、ＨＯＭＩＳのデータベースから診療情報を取得した上、これを直接ＯＲＣＡのデータベースに登録するというものである。（乙２０）
(イ) ㋓部分に含まれる原告プログラム４は、概ね、ＸＭＬデータを解析する部分（１～１２６行）と患者情報をＨＯＭＩＳのデータベースに登録する部分（１２７行～）から成る。
このうちＸＭＬデータを解析する部分は、ＸＭＬ解析処理の内容がその順序に従って記述されている。具体的には、オープンソースであるクラス「XML_Unserializer.php」を用いるため、その仕様に基づくインスタンスを記述し（９～１１行）、ＸＭＬ文字列を解析しタグ（用語）ごとに配列する。なお、ＯＲＣＡは、異なる施設間で診療情報を電子的に交換するために、ＭｅｄＸＭＬコンソーシアム制作担当委員会等により制作された医療情報交換規約（Medical Markup Language；ＭＭＬ）及びその下位に位置付けられる電子カルテシステムとレセプトシステムの間で診療情報を電子的に交換する際の仕様（Clinical AccountingInforMation；ＣＬＡＩＭ）を用いており、原告プログラム４のＸＭＬデータを解析する部分において用いられているタグ（用語）も、ＭＭＬ及びＣＬＡＩＭにおいて定義されたものである。
また、患者情報をＨＯＭＩＳのデータベースに登録する部分は、Ｗｅｂフレームワークの「dbCtl.php」を呼び出し、クラスからインスタンスを生成し、生成したインスタンスにデータを設定し、生成したインスタンスを実行する。
（本項につき、甲３１、乙５６～６２、弁論の全趣旨）
(ウ) 被告は、ＰＭポータルのＷｅｂフレームワークに含まれるクラス「dbCtl」及び「XML_Unserializer」を用いた部分を除き、㋓部分を新たに作成した。したがって、原告プログラム４ を含む㋓部分（「dbCtl」及び「XML_Unserializer」を用いた部分を除く。）の著作権は、本件契約に基づき、納入と同時に、被告から在宅医療情報システム株式会社に譲渡された。
⑶ 被告プログラムについて
ア 被告プログラムは、クラウド型の在宅医療電子カルテ及びレセプトシステムを提供するウェブアプリケーションであり、主に、単一の診療所での利用を想定している。
被告は、被告プログラムをサーバに蔵置して管理し、利用者は、ウェブブラウザやプログラムインターフェースを通じて、被告プログラムによって提供されるサービスを利用する。
イ 被告プログラムのうちカルテ入力支援機能、医事文書作成・管理機能を担う部分は、Ｗｅｂフレームワークと、電子カルテアプリケーションによって成り、被告は、これらを、利用者別データベースと共にサーバに蔵置している。（乙２１、弁論の全趣旨）
ウ 被告プログラムのうちレセプトソフトウェア接続アプリケーション（モバカルＯＲＣＡ－ＩＦ）は、被告プログラムにおいて、電子カルテアプリケーションとＯＲＣＡレセプトソフトウェアの連結を実現するプログラムである。
被告プログラムにおいては、Ｗｅｂフレームワーク、電子カルテアプリケーションがクラウド上に、レセプトソフトウェア接続アプリケーション及びＯＲＣＡレセプトソフトウェアが顧客の院内サーバに存在する。その結果、レセプトソフトウェア接続アプリケーションは、暗号化通信と電子証明書による送信元認証を実施しているほか、クラウド上のデータベースは、厚生労働省、総務省及び経済産業省が定めるセキュリティガイドラインに準拠するため、医療機関ごとに独立して複数構築している。
被告プログラムにおいてレセプトシステムを使用する方法は、新規に患者情報を登録する場合には、ＯＲＣＡレセプトソフトウェアにおいて、患者情報をＯＲＣＡのデータベースに登録した後、この情報を同データベースからＸＭＬデータとして出力し、レセプトソフトウェア接続アプリケーションにおいて、これを受信、暗号化して、クラウド上の電子カルテアプリケーションに送信し、電子カルテアプリケーションにおいて、当該医療機関に係るデータベースを選択した上、データを解析し、同データベースに登録するというものであり、また、既に登録されている患者についての診療情報を登録する場合には、レセプトソフトウェア接続アプリケーションにおいて、電子カルテアプリケーションに診療情報のリクエストを送信し、電子カルテアプリケーションにおいて、データベースを選択して診療情報を取得した上、ＸＭＬデータとして出力し、レセプトソフトウェア接続アプリケーションにおいて、これを受信し、ＯＲＣＡレセプトソフトウェアに転送して、ＯＲＣＡのデータベースにこれを登録するというものである。（乙２１）
このうち、ＸＭＬデータを解析する部分は、ＸＭＬ解析処理の内容をクラス「MMLParser.php」として定義し（乙４７（平成３０年１月頃のもの）においては１９～６３８行）、インスタンスを生成した上（同９５１行）、インスタンスを実行する（同９５２行）という形式で記述されている。具体的には、「XML_Unserializer.php」を用いるため、その仕様に基づくインスタンスを記述し（乙４７においては４２～４６行）、ＸＭＬ文字列を解析しタグ（用語）ごとに配列する。ここにおいて用いられているタグ（用語）は、ＭＭＬ及びＣＬＡＩＭにおいて定義されたものである。（乙４７、５５、６０、６２）
２ 争点①（本件３１個の各プログラムの各著作権が被告から在宅医療情報システム株式会社に譲渡されたか。）について
⑴ 本件３１個の各プログラムの創作性について
ア プログラムは、「電子計算機を機能させて一の結果を得ることができるようにこれに対する指令を組み合わせたものとして表現したもの」（著作権法２条１項１０号の２）であり、所定のプログラム言語、規約および解法に制約されつつ、コンピュータに対する指令をどのように表現するか、その指令の表現をどのように組み合わせ、どのような表現順序とするかなどについて、著作権法により保護されるべき作成者の個性が表れることになる。
したがって、プログラムに著作物性があるというためには、指令の表現自体、その指令の表現の組合せ、その表現順序からなるプログラムの全体に選択の幅があり、かつ、それがありふれた表現ではなく、作成者の個性、すなわち表現上の創作性が表れていることを要する。
イ 原告プログラム１⑷、３⑴を含む㋐部分（Ｗｅｂフレームワーク）及び原告プログラム１⑴から⑶、２⑴から⑼ウ、３⑵を含む㋒部分（電子カルテアプリケーション）は、Ｗｅｂフレームワークを用いたＰＭポータルを基盤として開発され、電子カルテ及びレセプトシステムを実現するに当たり、Ｗｅｂフレームワークを利用している（前記１⑵）。このことに起因して、㋐及び㋒部分のソースコードは、Ｗｅｂフレームワークの定めるルールに従って記述される必要があった（前記第２の１⑸イ）。
具体的には、㋐部分の多くは、ＰＭポータルのＷｅｂフレームワークを構成するプログラムファイルから構成されている（前記１⑴、⑵）。
また、㋒部分は、ＰＭポータルのＷｅｂアプリケーション部を参照して作成され、㋐部分すなわちＷｅｂフレームワークに記述されたクラスを呼び出し、クラスからインスタンスを生成し、生成したインスタンスに値を設定し、生成したインスタンスを実行して、電子カルテのウェブ画面表示処理、データベース処理、文書作成処理を行う実行インスタンス群から構成されており、共通処理のためのソースコード（関数、クラス等）は基本的には記述されていない。電子カルテにおいては所定の様式に合わせた表示項目が多いことから、これに応じて同じ内容の処理が繰り返されているものの、データの処理や画面の表示などの中核的な機能は㋐部分を参照して実行するため、㋒部分の内容は自由度が制約され、基本的な命令文を列挙して、変数に値を設定する処理や画面を表示するためのＨＴＭＬ文書が記述された部分が多くを占めている。（以上につき、前記１⑴、⑵、乙９～１８、６３～６７）
ウ 以上を前提に、原告が本件３１個の各プログラムの創作的表現であると主張する各点（前記２⑴（原告の主張）イ）について検討する。
(ア) 電子カルテに必要な機能を抽出、分類しているという点（前記２⑴（原告の主張）イ(ア)）について
本件３１個の各プログラムを含む㋐及び㋒部分は、ＰＭポータルを基盤として開発された、医療従事者が、モバイル端末を用いて、在宅患者の診療情報を記録、参照したり、診断書等の文書を作成し、これらの文書をＰＤＦファイルとして表示したりすることができるプログラムである（前記１⑵イ）のに対し、ＰＭポータルは、組織内外のプロジェクトを効率的に管理することを目的としたウェブアプリケーションである（同⑴ア）。したがって、㋐及び㋒部分の作成に当たっては、ＰＭポータルに様々な修正が施されている。もっとも、㋐及び㋒部分は、電子カルテ及びレセプトシステムを実現するに当たり、Ｗｅｂフレームワークを利用しているから、㋐部分の多くはＰＭポータルのＷｅｂフレームワークを構成するプログラムファイルから構成されている。また、㋒部分は、ＰＭポータルのＷｅｂアプリケーション部を参照して作成され、データの処理や画面の表示などの中核的な機能は㋐部分を参照して実行するものであるため、その内容は、自由度が制約されるものであり、基本的な命令文を列挙して、変数に値を代入する処理や画面を表示するためのＨＴＭＬ文書が記述された部分が多くを占めている（前記イ）。
また、原告プログラム２⑵アから⑼ウにおいて作成、表示される医事文書の基本的な様式は通知により定められるなどしていて、各記載事項は性質上概ね定まっている（前記１⑵イ(エ)）から、上記各プログラムにおいて変数に値を設定する処理や画面を表示するためのＨＴＭＬ文書を記述するに当たっても個性を発揮する余地が乏しい。
電子カルテに必要な機能を抽出、分類しているという原告主張の点は機能をいうものでプログラムの創作性を直接述べるものとはいえず、上記のような㋐及び㋒部分の特性に照らすと、電子カルテシステムに適用するために、ＰＭポータルを修正し新たに作成した部分があるからといって、そのことが直ちに本件３１個の各プログラムの表現上の創作性につながるとはいえない。
(イ) 関数、変数、データ定義の共通化の仕方の特徴がソースコードの記述に表われているという点（前記２⑴（原告の主張）イ(イ)）について
ａ 原告プログラム１⑷は、原告プログラム１⑴から⑶、２⑴、２⑵アから⑼ウ等において繰り返し使用される処理を３６個の関数として記述しこれらをまとめたファイルである（前記１⑵イ(イ)）。繰り返し記述することが予想される命令文の組合せをまとめて関数として定義し、関数名を記述してあらかじめ定義された関数を呼び出す方法により複数のプログラムの動作を実現させることは一般的に行われていることである（前記第２の１⑸ウ）。そして、原告プログラム１⑷に記述された各関数は、ＰＭポータルにおいて頻繁に使用される処理を関数として記述しこれらをまとめたファイルや、ＰＭポータルのその他の記述、汎用的な記述を参照して記述され、その内容は、所定のデータベースから所定の情報を取得する関数やＰＨＰの一般的な記述による画面表示用の関数など、いずれも単純な作業が記述されたものであって（前記１⑵イ(イ)）、表現の幅は狭い。これらによれば、原告プログラム１⑷の記述は、繰り返し記述される命令文の組合せを一般的な共通化の手法によってそのまま表現したものであって、その記述をすることやその内容はありふれたといえるものである。
ｂ 「variant.php」は、原告プログラム１⑵、２⑴、２⑺ウ、２⑼ウ等において共通して使用される４２個の変数を定義してこれらをまとめたファイルである（前記１⑵イ(キ)）。もっとも、「variant.php」は、本件３１個の各プログラムに含まれておらず、それらの創作性の有無が本件３１個の各プログラムの創作性に直接つながるものではない。
そして、アプリケーション全体において共通して使用される変数をまとめて定義して共通の定義ファイルとすることはプログラムの作成、変更の効率化を図るために一般的に行われていることであるといえ、原告プログラム１⑵、２⑴、２⑺ウ、２⑼ウにおいて、他のプログラムファイルを呼び出したり、共通の定義ファイルにおいて定義された変数を使用して定義された変数の名称がソースコードに書き表されたりしたということのみをもって、直ちにこれらについてプログラムの表現上の創作性が認められるものではない。なお、「variant.php」において定義された各変数は、画面に表示されるセレクトボックス（プルダウン形式やリスト形式のメニュー）の選択項目を一つの配列の中で定義したものであり（同前）、そのような変数の定義方法は、Ｐ Ｍ ポータルにおいても採用されていた（ 乙７ ５ ） 。変数「$GENDER_ARY」において「性別」の選択項目である「男」及び「女」のデータを「MALE」及び「FEMALE」としたという原告が指摘する例について、データの名称は電子計算機に対する指令を組み合わせたものとして表現したものとはいえない。
ｃ 原告プログラム３ ⑴ は、繰り返し使用される処理を２ ３ 個のJavaScript関数として記述しこれらをまとめたファイルである（前記１⑵イ(オ)）。繰り返し記述することが予想される命令文の組合せをまとめて関数として定義し、関数名を記述してあらかじめ定義された関数を呼び出す方法により複数のプログラムの動作を実現させることは一般的に行われている（前記第２の１⑸ウ）。また、原告プログラム３⑴に記述された関数のうち、２０個はＰＭポータルに記述されている関数をそのまま使用したものであり、３個は、画面サイズ変更など画面表示処理を汎用的に記述されている関数を参照して作成したもので、いずれも、画面表示、入力確認やメニューの設定などの機能を実現する短い記述であって（前記１⑵イ(オ)）、表現の幅は狭い。したがって、原告プログラム３⑴の記述は、繰り返し記述される命令文の組合せを一般的な共通化の手法によってそのまま表現したものであって、その記述をすることやその内容はありふれたといえるものである。
ｄ 「pdetail/config.php」は、原告プログラム１⑵等において共通して使用される４個の変数を定義してこれらをまとめたファイルであり、また、「docs/config.php」は、原告プログラム２⑵ア、２⑶アからウ、２⑷イ、２⑸アからウ、２⑹アからウ、２⑺アからウ、２⑻ア、イ、２⑼アからウ等において、繰り返し使用される処理を２個の関数として記述し、共通して使用される５０個の変数を定義してこれらをまとめたファイルである（ 前記１⑵イ(ク)） 。もっとも、「pdetail/config.php」及び「docs/config.php」は本件３１個の各プログラムに含まれておらず、それらの創作性の有無が本件３１個の各プログラムの創作性に直接つながるものではない。
そして、繰り返し記述することが予想される命令文の組合せをまとめて関数として定義し、関数名を記述してあらかじめ定義された関数を呼び出す方法により複数のプログラムの動作を実現させることは一般的に行われていることであり（前記第２の１⑸ウ）、アプリケーション全体において共通して使用される変数をまとめて定義して共通の定義ファイルとすることはプログラムの作成、変更の効率化を図るために一般的に行われていることであるといえ、原告プログラム１⑵、２⑵、２⑵ア、２⑶アからウ、２⑷イ、２⑸アからウ、２⑹アからウ、２⑺アからウ、２⑻ア、イ、２⑼からウにおいて、他のプログラムファイルや関数を呼び出したり、共通の定義ファイルにおいて定義された変数を使用して定義された変数の名称がソースコードに書き表されたりしたということのみをもって、直ちにこれらについてプログラムの表現上の創作性が認められるものではない。
なお、「docs/config.php」において定義された関数は、所定のデータベースから所定の情報を取得する関数やＰＨＰの一般的な記述による画面表示用の関数など、いずれも単純な作業を記述したものであって（前記１⑵イ(ク)）、表現の幅は狭く、「docs/config.php」のうち関数を定義した部分の記述は、繰り返し記述される命令文の組合せを一般的な共通化の手法によってそのまま表現したありふれたものといえる。また、「docs/config.php」において定義された変数は、概ね、ラジオボタン又はチェックボックスの選択項目を一つの配列の中で定義したものである（同前）ところ、そのような変数の定義方法は、ＰＭポータルにおいても採用されていた（乙６５）。
(ウ) 作成する医事文書の拡張性を高めた点がソースコードの記述に表われているという点（前記２⑴（原告の主張）イ(ウ)）について
ＨＯＭＩＳ②部分において、新たに作成する医事文書の種類が増えた場合に、プログラム名に新しく数字を割り当てて、文書ごとに、原告プログラム２⑵アから⑼ウと同様の入力、編集、印刷プログラムを「model/docs」というファイルに追加することができるとしても、このようなシステムの拡張性をいう点はプログラムによって実現される機能をいうものであり、プログラムの名称やファイルの格納場所も、これを電子計算機に対する指令を組み合わせたものとして表現したものとはいえず、原告の主張によって具体的なプログラムの創作性を認めるには足りない。
そして、原告プログラム２⑵から⑼の各ア及びイにおいては、入力又は編集の終了後、ＵＲＬを記述することにより登録プログラムを呼び出して実現している（前記１⑵イ(エ)）。ＵＲＬを記述してインターネット上に存在するプログラムやデータの場所を指定してこれらを呼び出す方法により複数のプログラムの動作を実現させることは一般的に行われているものである（前記第２の１⑸ウ）し、複数のプログラムが同一のプログラム（例えば「edit-do2.php」）を呼び出すことについても同様といえる。したがって、上記記述の指令自体はありふれたといえるものであり、また、その記述をすることもありふれたものといえる。
また、原告プログラム２⑴により表示される画面においてＰＤＦファイルを端末に表示することができるという点や、原告プログラム２⑵ウではＰＤＦファイルの作成に失敗した場合にはエラーメッセージが表示できるのに対し、原告プログラム２⑶から⑼の各ウではオープンソースをそのまま使用したことによりこのような表示がされないという点は、プログラムによって実現される機能ないしプログラムの仕様をいうものであり、原告の主張によって具体的なプログラムの創作性を認めるには足りない。
(エ) モバイル環境において電波状況によってカルテの保存ができない状況を回避するため通信状況を確認するようにした点がソースコードに表われているという点（前記２⑴（原告の主張）イ(エ)）について
原告プログラム３⑵は、原告プログラム１⑴において、原告プログラム３⑴に定義された関数が参照されAjax通信により呼び出されることにより、通信が確立されているかを確認する機能を実現する（前記１⑵イ(カ)）。関数名を記述してあらかじめ定義された関数を呼び出したり、「$.ajax」等記述して他のプログラムファイルを呼び出したりして、複数のプログラムの動作を実現させることは一般的に行われている（前記第２の１⑸ウ）。そして、原告プログラム３⑵は、「echo 1;」という、echo文により定数である「１」を送信する処理を行う１行から成るプログラムであり（前記１⑵イ(カ)）、極めて簡単な内容を一つの命令のみのごく短い構文で記述したありふれた表現であって、原告プログラム３⑵に創作性があるとは認められない。
(オ) 関数やプログラムの参照の仕方等の特徴がソースコードに表われているという点（前記２⑴（原告の主張）イ(オ)）について
原告プログラム１⑴から⑶、２⑴、２⑵から⑼の各アからウは、ＵＲＬ、「require」や「$.ajax」等を記述して他のプログラムファイルを呼び出したり、関数名を記述してあらかじめ定義された関数を呼び出したりしている（甲２９の１から３、３０の１から９の３、４５）が、これらの方法により複数のプログラムの動作を実現させることが一般的に行われている（前記第２の１⑸ウ）。原告プログラム１⑴から⑶、２⑴、２⑵から⑼の各アからウにおいて、上記の記述をすることはありふれたといえるものであり、そのことから直ちにプログラムの表現上の創作性が認められるものではない。
エ 以上のように、ＰＭポータルを基盤としＰＭポータルのＷｅｂフレームワークを用いて作成されたことに起因して、㋐部分の多くはＰＭポータルのＷｅｂフレームワークを構成するプログラムファイルから構成されており、㋒部分は、ＰＭポータルのＷｅｂアプリケーション部を参照して作成され、データの処理や画面の表示などの中核的な機能は㋐部分を参照して実行するため、その内容は、自由度が制約され、基本的な命令文を列挙して、変数にデータを代入する処理や画面を表示するためのＨＴＭＬ文書が記述された部分が多くを占めていること（前記第２の１⑸イ、前記イ）、作成、表示される医事文書の基本的な様式も通知により定められるなどしていることから、各プログラムにおいて変数に値を設定する処理や画面を表示するためのＨＴＭＬ文書を記述するに当たっても個性を発揮する余地が乏しい。これらの㋐及び㋒部分の特性から、電子カルテシステムに適用するために、ＰＭポータルを修正し新たに作成した部分があるからといって、そのことが直ちに本件３１個の各プログラムの表現上の創作性につながるとはいえない（前記ウ(ア)）。そして、原告は、本件各３１個の各プログラムがそれぞれ著作物であり、それらに創作性があると主張するところ、原告が本件３１個の各プログラムの創作的表現であると主張する具体的な各点について、本件３１個の各プログラムを含む㋐及び㋒部分が上記のとおりの特性を有する部分でありそこにおけるプログラムもその特性の下にあるものであることにも関係し、原告が創作性があるとして主張する具体的な記述等はいずれもありふれたといえるものなどであって、それらに独自に著作物といえる程度の表現上の創作性を認めるに足りない（前記ウ(イ)～(オ)）。
以上のとおり、本件３１個の各プログラムにＰＭポータルを離れた独自の創作性があるとは認めるに足りない。
⑵ 小括
本件契約においては、被告が納入物に関して著作した著作物に係る著作権は、被告が従前から著作権を保有する著作物を納入物に組み込んだ場合の当該組み込まれた著作物に係る著作権を除き、納入物の所有権移転と同時に在宅医療情報システム株式会社に移転することとされている（前記第２の１⑷イ）ところ、本件３１個の各プログラムにＰＭポータルを離れた独自の創作性があると認めるに足りない（前記⑴）から、本件３１個の各プログラムについての各著作権が被告から在宅医療情報システム株式会社に譲渡されたとも認められない。
３ 争点③（被告が原告プログラムを複製、翻案しているか。）について
原告プログラム４と被告プログラムにおいて共通する本件共通箇所は、原告プログラム４においては、㋔部分に用いられているＯＲＣＡから受信したＸＭＬデータを解析する部分の一部である。
本件共通箇所のうち、オープンソースである「XML_Unserializer.php」を用いた部分は、その仕様に基づくインスタンスを記述したものであり（前記１⑵ウ(イ)）、その記述例もインターネットウェブサイトにおいて公開されているものであって（乙５６）、ありふれた表現であって、創作性が認められない。
また、本件共通箇所のその余の部分は、異なる施設間で診療情報を電子的に交換するために制作された規約であるＭＭＬ及びＣＬＡＩＭにおいて定義されたタグ（用語）（前記１⑵ウ(イ)）を、「XML_Unserializer.php」の仕様に従って記述した（乙６２）ありふれた表現であって、創作性が認められない。
以上によれば、本件共通箇所に創作性があると認めるに足りない。
したがって、被告プログラムが原告プログラム４と共通するのは、表現上の創作性がない部分においてであり、その余を判断するまでもなく、被告が、原告プログラム４に係る原告の複製権、翻案権を侵害したと認めることはできない。
第４ 結論
以上によれば、各原告プログラムのうち、本件３１個の各プログラムについての各著作権が被告から在宅医療情報システム株式会社に譲渡されたとは認められず（前記第３の２）、原告プログラム４に係る原告の複製権、翻案権を被告が侵害したと認めることはできない（前記第３の３）から、原告の各請求はいずれも理由がなく、棄却すべきである。
よって、主文のとおり判決する。
東京地方裁判所民事第４６部
（裁判長裁判官 柴田義明 裁判官 佐伯良子 裁判官 仲田憲史）
別紙 目録 省略
*******
あなたの街の「ポスターPR」貼る(掲示許可交渉)前に知っておきたい地域情報一覧
インターネット広告 | SNS広告 | アフィリエイト広告 | タイアップ広告 | ダイレクトメール広告 | ディスプレイ広告 | テレビ広告 | 新聞広告出稿 | 雑誌広告 | ラジオ広告 | リスティング広告 | 交通広告ポスター | 動画広告 | 屋外広告OOH | ビジネスPR | フリーペーパー | プレスリリース | プロモーション | ポスター | ポスターセールス | ポスター営業 | ポスター掲示 | ポスター訴求 | ポスター販売促進 | ポスター集客 | ポスティング | マーケティング | イベント出展 | イベント開催 | セールスプロモーション | 新規開拓 | 商品販売営業地域 | 商店街 | 地域住民挨拶 | 地域密着 | 広告代理店 | 広告出稿 | 広告媒体 | 広告宣伝 | 広報公報 | 店舗看板 | 折り込みチラシ | 祭り | 貼り紙 | 通行人認知 | デザイン印刷 | 選挙ポスター | 政治ポスター | 政治団体 | 政治選挙 | 国政選挙 | 選挙管理委員会 | 街宣活動 | 街頭演説 | 弁士演説 | 応援弁士 | 掲示管理許可承諾 | 掲示許可交渉 | 掲示責任者 | 都議会議員選挙 | 道議会議員選挙 | 府議会議員選挙 | 県議会議員選挙 | 市議会議員選挙 | 区議会議員選挙 | 町議会議員選挙 | 村議会議員選挙
 |
 |
 | ||
 |  |  |
 |  |  |
 |  |  |
 | ||
 |  |  |
 |  |  |
 |  |  |
 | ||
 |  |  |
 |  |  |
 |  |  |
【よくある質問 Q&A 一覧】
■街頭ポスター貼り(掲示交渉)代行について
Q&A【1】街頭ポスター貼付(掲示交渉代行)サービスとはどのようなものですか？
Q&A【2】どのくらいの期間で何枚くらいの街頭ポスター貼付ができるのですか？
Q&A【3】街頭ポスターを貼る際は先方(許可承諾者)に許可をいただいて貼るのですか？
Q&A【4】ポスターの①貼付依頼～②貼付開始～③貼付完了等の流れについて教えていただけますか？
Q&A【5】ポスターの料金は１枚いくらで貼ってくれるのですか？
Q&A【6】ポスターの貼付エリアや貼り付け枚数等は指定できますか？
Q&A【7】ポスター貼付後のメンテナンス(貼り替え・剥がし)も依頼できますか？
Q&A【8】最低何枚から街頭ポスター貼りを依頼できますか？
Q&A【9】ポスター貼り替え期間の指定はできますか？貼りっぱなしではないですか？
Q&A【10】街頭ポスターの貼付交渉(新規掲示)の実績や事例はありますか？
■政治活動における広報支援について
Q&A【11】「ドブ板選挙プランナー」とはどのようなお仕事ですか？
Q&A【12】「ポスタリング」とはどのようなサービスですか？
Q&A【13】政治活動等の特殊な業界についてのポスター掲示交渉は難しいですか？
Q&A【14】政治活動用の街頭ポスター(二連|三連)貼りをお願いしたいのですが、特定政党の支援は可能ですか？
Q&A【15】政治活動におけるポスターについて公職選挙法や政治資金規正法等の知識はありますか？
Q&A【16】街頭で無料の「ウィン！ワッポン」をよく見かけますが、これで選挙の勝率が上がりますか？
Q&A【17】二連ポスターや三連ポスター製作前に「弁士の相手」のご提案もしてくれますか？
Q&A【18】ポスター「掲示責任者代行」とはどのようなものでしょうか？
Q&A【19】選挙妨害やその他クレーム対応等の代行も可能でしょうか？
Q&A【20】政治活動(選挙運動)における広報支援プランはどのようなものがありますか？
■営業専門会社による広報PR支援について
Q&A【21】飛び込み訪問、戸別訪問、挨拶回り代行等、ポスター貼り以外でもお願いできますか？
Q&A【22】飲食店や実店舗等の店内やトイレ等にポスターを貼ったり、ビジネスカード設置、チラシ配布等は可能ですか？
Q&A【23】全国どこでもポスター貼りが可能なのですか？
■ご検討中の方々に
Q&A【24】お問い合わせについて
Q&A【25】資料をダウンロード
Q&A【26】ノウハウ・テクニックを大公開！
■ご依頼(お申し込み)の前に
Q&A【27】お申し込みの流れ
Q&A【28】ご用意いただきたいもの
■ご依頼(ご契約)の後に
Q&A【29】進捗報告について
Q&A【30】お友達ご紹介キャンペーンについて
■ポスターPRプラン一覧(枚数・サイズの選択)
選挙区エリアにおいて、ポスターの当該掲示許可承諾者に対して交渉し、同一箇所にどのように掲示するかをお選びいただきます。
【臨機応変型PR】ポスター掲示許可貼付交渉代行プラン ※ご発注選択率88％ ★こちらをご確認下さい。
【連続二枚型PR】ポスター掲示許可貼付交渉代行プラン ※ご発注選択率6％ ★こちらをご確認下さい。
【限定一枚型PR】ポスター掲示許可貼付交渉代行プラン ※ご発注選択率4％ ★こちらをご確認下さい。
【個別指定型PR】ポスター掲示許可貼付交渉代行プラン ※ご発注選択率2％ ★こちらをご確認下さい。
※ポスターのサイズは、A1サイズ、A2サイズをはじめ、ご希望に応じてご提案させていただきます。
■掲示場所・貼付箇所
「首都圏などの大都市」「田舎などの地方都市」「駅前や商店街」「幹線道路沿いや住宅街」等により、訪問アプローチ手段が異なりますので、ご指定エリアの地域事情等をお聞かせ下さい。
※貼付箇所につきましては、弊社掲示交渉スタッフが当該ターゲットにアプローチをした際の先方とのコミュニケーションにて、現場での判断とさせていただきます。
■訪問アプローチ手段
【徒歩圏内】
駅周辺の徒歩圏内における、商店街や通行人の多い目立つ場所でのPR
【車両移動】
広範囲に車移動が必要な、幹線道路沿いや住宅街等の目立つ場所でのPR
※全国への出張対応も可能ですので、ご要望をお聞かせください。
選挙ドットウィン！の「どぶ板広報PR支援」は、選挙立候補(予定)者様の地獄の政治活動を「営業力」「交渉力」「行動力」でもって迅速にお応えいたします。
「全国統一地方選挙」・「衆議院議員選挙」・「参議院議員選挙」・「都道府県知事選挙」・「都道府県議会議員選挙」・「東京都議会議員選挙」・「市長選挙」・「市議会議員選挙」・「区長選挙」・「区議会議員選挙」・「町長選挙」・「町議会議員選挙」・「村長選挙」・「村議会議員選挙」など、いずれの選挙にもご対応させていただいておりますので、立候補をご検討されている選挙が以下の選挙区エリアに該当するかご確認の上、お問い合わせいただけますようお願いいたします。
(1)政治活動/選挙運動ポスター貼り ☆祝！勝つ！広報活動・事前街頭(単独/二連)選挙ポスター！
勝つ！選挙広報支援事前ポスター 政治選挙新規掲示ポスター貼付！ １枚から貼る事前選挙ポスター！
「政治活動・選挙運動ポスターを貼りたい！」という選挙立候補(予定)者のための、選挙広報支援プロ集団「選挙.WIN！」の事前街頭ポスター新規掲示プランです。
(2)圧倒的に政界No.1を誇る実績！ 政治ポスター(演説会告知|政党|個人|二連三連)掲示交渉実績！
地獄のポスター貼りやります！ ドブ板選挙ポスタリストが貼る！ ポスター掲示交渉実績を大公開！
政治ポスター貼りドットウィン！「ドブ板選挙を戦い抜く覚悟のあなたをぜひ応援したい！」事前街頭PRおよび選挙広報支援コンサルティング実績！
(3)今すぐ無料でお見積りのご相談 ☆大至急スピード無料見積もり！選挙広報支援プランご提案
ポスター掲示難易度ランク調査 ご希望のエリア/貼付箇所/貼付枚数 ☏0120-860-554(貼ろう！ここよ！) ✉info@senkyo.win
「政治活動用のポスター貼り代行」や「選挙広報支援プラン」の概算お見積りがほしいというお客様に、選挙ドットウィンの公職選挙法に抵触しない広報支援プランのご提案が可能です。
(4)政界初！世界発！「ワッポン」 選挙管理委員会の認証確認済みPR型「ウィン！ワッポン」
完全無料使い放題でご提供可能！ 外壁街頭ポスター掲示貼付ツール １枚から対応/大至急/一斉貼付け！
「ガンガン注目される訴求型PRポスターを貼りたい！」というお客様に、選挙ドットウィンの「ウィン！ワッポン」を完全無料使い放題でご提供する、究極の広報支援ポスター新規掲示プランです。
(5)選べるドブ板選挙広報支援一覧 選挙.WIN！豊富な選挙立候補(予定)者広報支援プラン一覧！
政治家/選挙立候補予定者広報支援 祝！当選！選挙広報支援プロ集団 世のため人のため「SENKYO.WIN」
アポイントメント獲得代行/後援会イベントセミナー集客代行/組織構築支援/党員募集獲得代行(所属党本部要請案件)/演説コンサルティング/候補者ブランディング/敵対陣営/ネガティブキャンペーン(対策/対応)
(6)握手代行/戸別訪問/ご挨拶回り 御用聞きによる戸別訪問型ご挨拶回り代行をいたします！
ポスター掲示交渉×戸別訪問ご挨拶 100％のリーチ率で攻める御用聞き １軒でも行くご挨拶訪問交渉支援
ご指定の地域(ターゲットエリア)の個人宅(有権者)を1軒1軒ご訪問し、ビラ・チラシの配布およびアンケート解答用紙の配布収集等の戸別訪問型ポスター新規掲示依頼プランです。
(7)地域密着型ポスターPR広告貼り 地域密着型ポスターPR広告(街頭外壁掲示許可交渉代行)
街頭外壁掲示許可交渉代行/全業種 期間限定！貴社(貴店)ポスター貼り サイズ/枚数/全国エリア対応可能！
【対応可能な業種リスト|名称一覧】地域密着型ポスターPR広告(街頭外壁掲示許可交渉代行)貼り「ガンガン注目される訴求型PRポスターを貼りたい！」街頭外壁掲示ポスター新規掲示プランです。
(8)貼る専門！ポスター新規掲示！ ☆貼！勝つ！広報活動・事前街頭(単独/二連)選挙ポスター！
政治活動/選挙運動ポスター貼り 勝つ！選挙広報支援事前ポスター １枚から貼る事前選挙ポスター！
「政治活動・選挙運動ポスターを貼りたい！」という選挙立候補(予定)者のための、選挙広報支援プロ集団「選挙.WIN！」の事前街頭ポスター新規掲示プランです。
(9)選挙立札看板設置/証票申請代行 絶対ここに設置したい！選挙立札看板(選挙事務所/後援会連絡所)
選挙事務所/後援会連絡所届出代行 公職選挙法の上限/立て札看板設置 １台から可能な選挙立札看板設置
最強の立札看板設置代行/広報(公報)支援/選挙立候補者後援会立札看板/選挙立候補者連絡所立札看板/政治活動用事務所に掲示する立て札・看板/証票申請代行/ガンガン独占設置！
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
