Posts

社内の電子資料にGoogleマップを使うには

社内資料として、Googleマップの地図画像をPDF、PowerPointなどの電子資料に貼り付けたくなることがあるかもしれない。しかし、地図画像もGoogleの立派な著作物である（著作権法第10条1項6号）。こう思うと資料への貼付けが躊躇われるが、あくまで電子資料が社内使用に留まるものであり、商用の広告として用いたり、多くに配布するものでなければ、帰属表示をはじめとする利用規約を守っておけば貼り付けは可能である。遵守すべき利用規約遵守すべき利用規約として「Google 利用規約」と「Googleマップ追加利用規約」の２つがある。 Google 利用規約には、Googleアカウント利用時の年齢要件、サービスの不正利用の禁止等が規定されているが、この中で「サービス固有の追加規約」の遵守を求めており、Googleマップの場合は「Googleマップ追加利用規約」がそれに当たる。 Googleマップ追加利用規約の概要 Googleマップ追加利用規約では、「適切な権利帰属を伴うコンテンツを、オンライン、動画形式、印刷形式で公開表示する」ことを許可している。言い換えると、適切な権利帰属のないコンテンツの使用は認められないということである。「適切な権利帰属」とは、要するに「ちゃんと帰属表示をしてね」ということで、その具体的な内容は「Googleマップ、Google Earth、ストリートビューの使用にあたっての許可に関するページ」に記載されている。その中身は、以下の通りである。帰属表示の内容 Googleマップでは、コンテンツの下部に、例えば「Map data ©2019 Google」などの著作権表示とともに帰属表示が記載される（正確な帰属表示のテキストは、地域やコンテンツの種類によって異なる）この帰属表示は、web embeds,、API、Google Earth Pro、Earth StudioといったGoogleのツールで地図画像を出力すると自動で表示されるようになっている。これを、以下のルールに従って表示することが求められる。遵守事項帰属表示は地図画像の近くに表示することスクリーンショットを使用する場合は、画像中の標準的な帰属表示をそのまま記載することデータや画像の一部がGoogle以外のプロバイダから提供されていれば、帰属表示のテキストに「Google」＋「データプロバイダ（複数可）」を明記すること（例：「地図データ：Google、Maxar Technologies」）禁止行為帰属表示を地図画像から離れた場所（書籍の末尾、映画や番組のクレジット、ウェブサイトのフッターなど）に表示する行為帰属表示を削除したり、隠したり、切り取る行為 Googleロゴをインラインで使用する行為（例: 「これらの地図は [Google ロゴ] から提供されています」という表示を入れる行為） Google以外のプロバイダのデータが含まれているのに、「Google」またはGoogleロゴのみを記載する行為認められる行為必要に応じて、帰属表示テキストのスタイルや配置をカスタマイズ可能（ただし、閲覧者が判読できるよう、テキストはコンテンツの近くに表示する必要あり）その他、禁止行為帰属表示の他にも、Googleマップ追加利用規約では以下の行為を禁止している。 Googleマップを再配布・販売したり、そこから新しいサービスを作る行為地図や画像などのコンテンツを勝手にコピーする行為（例外あり）大量にダウンロードしたり、自動でデータを取る仕組みを作る行為 Googleマップの情報を使って、別の地図サービスやデータベースを作る行為リアルタイムのナビや自動運転用に、他社のサービスと組み合わせて使う行為用途によっては、更なる決まり事も地図画像をどう使うか（印刷するのか、動画に使うのか、等）によって、次のように更なる遵守事項が課される。地図画像を印刷する場合は、非営利目的または個人的な使用に限る埋め込みコードでウェブサイトにGoogleマップを埋め込むだけならOK（Googleマップへのリンクを貼ることも可能）映画やテレビ番組でGoogleマップを使用する場合（例：俳優がスマートフォンでGoogleマップを使用）は、事前承認が必要オンライン動画広告やプロモーション目的（例：不動産会社が賃貸物件の空き状況を表示するなど）で使用する場合は、事前承認が必要 PDFやPowerPointといった電子資料に貼り付けるだけであれば、基本的には帰属表示を守っておけば良い。まとめ最もシンプルにGoogleマップの地図画像を社内の電子資料に使いたければ、Googleのツールで帰属表示付きの画像を出力し、何も加工せずに貼り付けるのが手っ取り早い。しかし、商用利用含めてもっと制約なく使いたければ、OpenStreetMap（クレジット表記は必要）等の別のコンテンツを使うのが良い。 OpenStreetMapの詳細については別の記事で紹介しているので、気になるようなら目を通してみて欲しい。

USPTO審査変更の影響（審査官インタビューの制限）

米国の審査に影響する話となる。 2026年度のUSPTOによる審査官業務評価計画で、新たな変更が導入されるとのこと。１案件につき、審査官インタビューが合計１時間までに限定されることとなる。以下に、その詳細を記載する。審査官へのクレジットこれまでは、審査官インタビュー１回につき１時間分のクレジットぎ付与されていた。今回の変更により、１審査ラウンド（新規出願か、RCE毎）あたり合計１時間分のクレジットが付与されるだけとなる。つまり、実質的に２回目以降の審査官インタビューにはクレジットが付与されない。２回目以降の審査官インタビューは可能か結論、理論上可能ではある。しかし、審査官自身で審査促進に繋がることを示す必要がある上、スーパーバイザー審査官による正式承認を要する。果たして、クレジットも付与されないのに審査官がそこまで審査官インタビューを実施してくれるものだろうか？また、仮に応じてくれたとしても、クレジットが得られないことから審査官による準備が充分に行われず、審査官インタビューの質が低下する可能性も否めない。この方針は、審査促進のための対話を奨励するMPEP §713の精神と整合性が取れないものだが、それだけ審査官の工数不足を補う必要があるという表れなのかもしれない。対話を繰り返す方法はお勧めできないこれまでは、OA時に限定的な補正を行った上で相手方の反応を確認し、その後に複数の審査官インタビューを通じた対話を繰り返して論点を絞っていく方法もあったかと思う。しかし、今後はそのような方法だとRCEを繰り返すこととなり、コスト面からも望ましいアプローチとはいえなくなる。最初のOA後の審査官インタビューが重要審査ラウンド毎の審査官インタビューが原則１回に限定されたことで、最初の拒絶理由通知後に行う審査官インタビューの価値が高まったといえる。今後は、最初の拒絶理由通知後（最後の拒絶理由通知後よりも補正の自由度が高いタイミング）に審査官インタビューを行うことが有効と思われる。ここでは、あらかじめ論点を整理しつつ、いくつか補正案を作成した上で、インタビューでは審査官と効率的に議論を行うことが求められる。

ソフトウェア等の販売における輸出規制

製品や技術をを外国企業に輸出する際には、輸出規制・倫理的制約・リスク管理などの観点から、販売国・地域、使用者（企業・組織）を限定・禁止することが一般的である。特に、ソフトウェアはクラウドを介して世界に販売・ライセンスすることが比較的容易なので、あらかじめ販売先の限定を検討しておくことが重要である。知財業務の観点からは離れるかもしれないが、ソフトウェア販売において頭の片隅に入れておいたほうが良いと思うので、販売国・地域、使用者の観点で整理してみたい。国（使用地域）の限定日本の輸出規制は外国為替及び外国貿易法（外為法）に基づき行われており、外為法には大きく２つの規制「リスト規制」「キャッチオール規制」が設けられている。規制概要リスト規制・軍事転用される恐れが高い貨物・技術の輸出にあたって経済産業大臣の許可を求める制度・リスト掲載品目が対象キャッチオール規制・輸出される技術等の使用者や使用目的が軍事転用などの懸念がある場合、経済産業大臣の許可を求める規制・木材・食料品を除くほぼ全ての品目が対象以下、それぞれについて詳細を説明したい。リスト規制輸出される技術等が「輸出貿易管理令」の別表第一または「外国為替及び外国貿易法」の別表の1～15の項に該当する場合であってⅠ物等省令で定める仕様に該当するものは、事前に経済産業大臣の許可を必要とする制度である。対象品目または役務（技術）の内容は、以下の通り。武器関連（輸出貿易管理令別表第一1の項）核兵器、化学・生物兵器およびミサイル（輸出貿易管理令別表第一2～4の項）通常兵器関連汎用品（輸出貿易令別表第一5～15の項）ただし、貿易外省令第9条において、許可を必要としない技術提供が規定されている。例外規定に当たる場合は、提供する技術等がたとえリスト規制の対象であっても、許可を取得する必要はない。例えば、以下のようなものは許可を取得しなくても良い。公知の技術を提供する取引又は技術を公知とするために当該技術を提供する取引（第9条第2項第1号）工業所有権の出願・登録を行うために必要な最小限の技術を提供する取引（同項第11号）ソフトウェアの場合、OSSであれば許可の取得は必要ないが、OSSの一部を改変しかつ改変後のソースコードを公開せず、改変後OSSを組み込んで提供する場合は、例外規定には当たらない。キャッチオール規制リスト規制の対象外となる技術等であっても、その技術等が、大量破壊兵器等や通常兵器の開発等に用いられるおそれがある場合に、経済産業大臣の許可を必要とする制度である。このキャッチオール規制では、木材・食料品を除くほぼ全ての品目が規制の対象となっている。また、キャッチオール規制は更に以下の小項目に分かれている。大量破壊兵器キャッチオール規制大量破壊兵器等の開発、製造、使用又は貯蔵に用いられる恐れがある場合には、経済産業大臣の輸出許可が必要となる。対象地域は、後述のグループA以外の国・地域(インフォーム要件はグループAも含む)となる。通常兵器キャッチオール規制通常兵器の開発、製造又は使用に用いられる恐れがある場合には、経済産業大臣の輸出許可が必要となる。対象地域は、国連武器禁輸国・地域となり、大量破壊兵器キャッチオール規制よりも対象地域は狭い。許可要件「キャッチオール規制」の許可要件は、経済産業省から許可を受けるべき旨の通知を受けた場合に許可を要する「インフォーム要件」と、輸出者自身で技術等の用途や需要者の確認を要するかを確認する「客観要件」との2要件から構成されている。インフォーム要件：経済産業省から許可申請すべき旨の通知を受けた場合に許可申請が必要となる要件客観要件：輸出者が技術等の用途や需要者の確認を行った結果、以下に当てはまる場合に許可申請が必要となる要件用途要件：技術等が大量破壊兵器等の開発等や通常兵器の開発等に用いられる恐れがある需要者要件：需要者が大量破壊兵器等の開発等を行う、または外国ユーザーリストに該当する優遇を受けられる国（グループA）リスト規制の対象ではあるが、キャッチオール規制のうち、客観要件は対象外（インフォーム要件は対象）という優遇を受けられる国々があり、これらはグループA（旧ホワイト国）と呼ばれる。グループAは大量破壊兵器などの拡散を防ぐための輸出管理が厳格に行われている国々とされているため、キャッチオール規制の要件が緩くなっている。グループAの具体的な国々は「輸出貿易管理令」の別表第三で定められており、2025年時点では以下の国々となる。アルゼンチン、オーストラリア、オーストリア、ベルギー、ブルガリア、カナダ、チェコ、デンマーク、フィンランド、フランス、ドイツ、ギリシャ、ハンガリー、アイルランド、イタリア、大韓民国、ルクセンブルク、オランダ、ニュージーランド、ノルウェー、ポーランド、ポルトガル、スペイン、スウェーデン、スイス、英国、アメリカ合衆国確認フローここでは、リスト規制、キャッチオール規制の確認フローについて触れておく。技術等を輸出する場合、まずその技術等がリスト規制に該当するかどうかを確認し、該当する場合は、例外規定を除き経済産業省の輸出許可が必要となる。リスト規制に該当しなかった場合は、次にキャッチオール規制の確認を行い、キャッチオール規制に該当すれば、やはり経済産業省の輸出許可が必要となる。企業・組織（使用者）の限定・禁止例リスト規制/キャッチオール規制の他、以下のような特定企業等には輸出しないという社内ルールを設けることも考えられる。制裁リスト掲載企業米国OFACリスト（SDNリスト） EU制裁リスト経産省の外国ユーザーリスト競合他社その他、社内事情で指定する企業等ソフトウェアを輸出する場合はどうする？ここで、企業としてソフトウェアを取り扱う場合を考えてみたい。まず、輸出対象となるソフトウェアがリスト規制の対象となるかだが、輸出貿易管理令別表第１に記載の貨物の「設計、製造及び使用」に関するプログラムが関係してくる。軍事利用を想定しやすいソフト（例：ミサイル設計ソフト、核関連解析ソフト）であれば該当すると判断しやすいだろうが、工作機械の制御ソフトや半導体制御装置向けソフトであっても軍事用途の貨物の製造を可能であったり、暗号技術であっても軍事転用リスクがあれば規制対象となり得る点は注意したい。リスト規制の対象とはならない通常のソフトウェアであれば、後は通常の判断フローに従うことになろうかと思う。なお、輸出許可申請の必要性とは別に、企業として実際にソフトウェアを輸出するかどうかの判断基準だが、例えば以下のような社内ポリシーを設けることが考えられる。グループA：特定企業（競合企業など）でなければOK 国連武器禁輸国：原則NG 上記以外の国：個別判断なお、上述の通り輸出対象がOSSだけ（非公開の改変コードが含まれる場合は別）であれば公知技術として取り扱われるため、輸出の事前許可は不要となる。

ライセンサー目線で知財権の保証条項を設けるリスク

ライセンス契約における保証条項では、次のような事項をライセンサー（権利者）が保証することがよくある。有効性保証：特許等が有効に存在することを保証非侵害保証：ライセンシーの利用が第三者の権利を侵害しないさらっと書かれているのだが、ライセンサーから見れば、これらを100％保証するのは事実上不可能といっても過言ではない。ライセンシーの立場であれば「しめしめ」で済む話かもしれないが、ライセンサーとしては、ある程度遵守できる範囲の内容にするための交渉が求められる。保証する側（ライセンサー）の主なリスク各保証の項目について、もう少し詳しく述べておきたい。無効・取消しのリスク特許権等に無効理由があることが確定すると、特許権等ははじめから無かったものとみなされる（特許法第125条、商標法第46条の２）。無効理由の有無はライセンサーではなく特許庁や裁判所が判断する上、権利化後に新たに見つかった資料によって無効となる可能性もあるため、権利の有効性はライセンサーにも完全にはコントロールできない。仮にライセンサーが「有効であることを保証」してしまうと、特許や商標が後に無効審判で無効となった場合、契約違反・債務不履行を問われる可能性がある。このため、ライセンサーとしては「保証しない」と規定したいところである。とはいえ、ある程度の譲歩が求められることもあると思うが、その際は、例えば「**ライセンサーの知る限り、契約締結日において、**無効審判の請求、その他特許の有効性を争う法的手続がなされたことがないことを保証する」といった条件を設けることが考えられる。このような規定であれば、ライセンサーもより確信を持って保証することができる。その他、「契約締結時においてライセンサーの知る限り無効理由はないことを保証する」という書き方もあるが、個人的には上述のように「法的手続きがなされたことがない」という書きっぷりにした方が、より疑義のない内容になると思う。とはいえ、実務上インパクトのある差ではないと思う。第三者権利侵害のリスクたとえ特許権が登録となっていても、ライセンシーの実施行為が第三者の特許権等を侵害する場合がある。例えば、特許が第三者の特許権に対して下位概念や利用関係にあって、当該特許の実施が当該第三者の特許権を侵害する場合が挙げられる。この場合、ライセンサーが非侵害を保証したにもかかわらず、実際には第三者の特許・著作権・商標を侵害していたということであれば、損害賠償責任を負う可能性がある。特にソフトウェアや複合技術の場合、全ての構成要素について侵害の有無を完全に確認することは困難である。また、パテントトロールからの攻撃を受けるというリスクも存在する。もちろん、特許権の実施行為以外の部分が原因で訴えられることもあるが、ライセンサーとしては無用なリスクは回避したいところである。そもそもライセンサーの立場としては、ライセンス行為はあくまで「おたくに権利行使しませんよ」という地位を与えているに過ぎず、第三者の権利の非侵害を保証するのは過度な負担であると考えられるので、ライセンサーとしては「保証しない」と規定したくなる。それでも交渉により何らかの保証をせざるを得ない場合には、「契約締結時に知り得る限り第三者の権利を侵害していないことを保証する」と規定することが考えられる。または、「これまで権利侵害の通知を受けたことがないことを保証する」という記載もあり得るが、必ずしもライセンサー自身が特許権等を実施しているとは限らないため、ライセンシーからはもっと確実な保証を要求される可能性はある。より相手方に歩み寄る案としては、「第三者からの請求があった場合に、協議の上、合理的な範囲で協力する」ことを義務付けることが考えられるが、この辺りになると現実的に何らかの対応を迫られることも視野に入れておくべきかと思う。ライセンサー視点の実務対応以下に保証の条項案のまとめておく。このほか、損害賠償義務が発生することが想定される場合は、上限額を設けたり、免責条項で「間接損害・逸失利益については賠償しない」等と規定することが考えられる。 | 保証内容 | 最善策 | 譲歩案 | | —- | —- | | 有効性保証 | 保証しない | ・契約締結時において無効審判の請求等がないことを保証する・契約締結時において知る限り無効理由はないことを保証する | | 非侵害保証 | 保証しない | ・契約締結時において知る限り非侵害を保証する・これまで権利侵害の通知を受けたことがないことを保証する・第三者から請求があった場合、協議の上合理的な範囲で協力する |

ソースコード中のOSS検知

生成AIでソースコードを作成した場合、意図せずOSSが混入してしまう場合がある。 OSSライセンスの再配布・表記義務・改変条件に沿う必要性から、これらOSSおよびOSSライセンスは検知しておくことが求められる。実務上はツールでコードスニペットをスキャンするのが有用であるが、「どれくらい一致していたら、そのOSSを使っていると判断できるか？」は、慎重に扱うべきポイントとなる。法的・実務的な判断ポイントソースコードの著作権侵害に関しては下記の通りまとめているものの、今のところ、具体的な法律上の行数基準はない。ソースコードの著作権侵害プログラムのソースコードが著作権法上の保護対象に含まれる（著作権法第10条第1項第9号）ことはよく知られている。しかし、アルゴリズムは流... そこで、実務上は主に以下の観点で判断することなろうかと思う。「創作的表現」の有無が重要著作権上の保護対象は「創作的表現」であり、単に短い定型コード（例：forループ、import文など）は保護されない。しかし、短いならOSSを使っていないと判断するのは早計である。たとえ5～10行程度でも特定OSSの独自ロジックや特徴的な関数構造に一致していれば、利用している疑いは残る。逆に、仮に多くの行が一致していても、定型コードの実装に過ぎないのなら著作物性は低く、OSS利用とは断定できない。コードの著作権に関する判例下記判例は著作権侵害に関するものである上、日本と米国の判例が入り交じっており、あくまで参考という位置づけだが、コードの一致する行数は客観的な事実として重要なポイントとして参酌されていることが伺える。ただし、それのみをもってOSSライセンスの適用可否が決まるものではないことは付け加えておく。判例１：測量業務用ソフトウェア事件（一審）東地 H19（ワ）24698 ここでは、ソースコードの同一/実質同一の割合が全体の９０％を下ることはないことを理由に、被告プログラムと原告プログラムは、原告プログラムの作成者の個性が表現された部分について、実質的同一性ないし類似性が認められる、と判断している。さすがに全体の９割以上が実質同一であれば、妥当な判決だと思う。ソースコードの記載が全く同一であるものソースコードの記載が実質的に同一であるもの（会社名の置換え、変数名、フォーム名等、プログラムとして機能する上で、その名称の違いに意味のない違いであり、これらの違いがプログラムの表現として実質的な意味を持たないもの。）判例２：Oracle v. Google (2010-2021) GoogleのAndroidで、OracleのJava APIを利用する際に11000行ものコードをコピーしていたと訴えられていたが、このAPIはプログラマーが広く利用しているものとして、最高裁は米国著作権法上の「フェアユース」に該当すると判断した。ある判事は、「ここでOracleの著作権の権利行使を認めることは、公衆に損害を与えるリスクがある」と述べている点が興味深い。もはや、実務上はJava APIが一般的な構文であると認定されたということだろうか。スニペットスキャンの実務ガイド判例からも分かる通り「何行」一致は大事な目安の１つであるが、ポイントは「一致部分が特定OSSの創作的ロジックかどうか」となる。行数に囚われず、疑わしい一致が出た段階で、ライセンスを確認するのが最も安全である。実際は手作業で各コードとOSSとの一致度を確認するのは無理ゲーだと思うので、現実的にはBlack DuckなどのOSS管理ツールを使って一致度を確認し、どこかで閾値を定めることになるかと思う。リスク特徴対応低一般的な構文・短い定型コード対応不要（著作物性なし）中特定OSSの関数名・処理が部分一致出典確認・必要に応じライセンス確認高例えば30行以上一致、特徴的構造・コメント一致 OSS利用の可能性大・要ライセンス確認

脱OSSの動きと利用者のリスク

ソフトウェア企業の中には、自社技術のアピール、利用者のコミュニティ形成のため、自社プロダクトをOSS化するところもある。こういった企業が収益を確保するには、例えば、プロダクトは無償で提供しつつも、導入サポートやプロダクトを利用するプラットフォームを有償とすることで儲けるという方法が考えられる。 OSSによる収益化の課題と脱OSS しかし、近年は競合参入（大きなクラウドベンダーなど）によって上記のビジネスモデルが脅かされるリスクが大きくなっている。 OSSコミュニティによって得られる恩恵は大きいものの、「純粋にOSSを使って商用展開する事業者（クラウドベンダー）」が恩恵を受ける一方で、開発元への還元が少ないというわけである。その結果、これまでは自由な再配布を認めていたライセンスの再策定が進んでおり、いくつかの製品では、非OSSのソース公開型ライセンス（Source-available License, SAL）に移行してきている。具体的には、ビジネスモデルを保護できるよう「競合他社を排除する」という観点が取り入れられたSALへ変更する動きである。 OSSの定義ここで、OSSの定義について振り返っておきたい。 OSS（オープンソースソフトウェア）とは、Open Source Initiativeによって以下のように定義されている。自由に再頒布できること（無償か有償かは利用者の自由）ソースコードが入手可能であること派生ソフトウェアの作成・派生ソフトウェアを元と同じライセンスで配布することの許可作者のソースコードの完全性（integrity）個人や団体に対する差別の禁止利用分野に対する差別の禁止再配布時の追加ライセンスの禁止特定製品でのみ有効なライセンスの禁止他のソフトウェアを制限するライセンスの禁止ライセンスは技術中立的でなければならないこのように、OSSでは「個人やグループに対する差別の禁止」「利用する分野に対する差別の禁止」という項目があるため、競合他社の参入を防ぐことはできない。 Source-available License (SAL) これに対し、各企業が移行を進めているのが非OSSのSource-available License (SAL)である。 SALは「ソースコードが利用可能なライセンス」を意味し、OSSも含んだ概念であるので、ここでは非OSSのSALという少しまどろっこしい表現となっている。非OSSのSALとして、例えば以下のようなものが挙げられる。ご覧の通り、競合参入を抑制するべく、利用時には特有の制限事項が設けられていることが多い。ライセンス名特徴 Business Source License (BSL) ・一定期間は商用利用/競合製品開発など特定用途への制限あり・商用利用時に商用ライセンス契約が必要な場合あり・一定期間経過後、通常のOSS（Apache 2.0など）に変わる・多くの場合、非商用目的では無償で自由に利用可能 Server Side Public License (SSPL) ・SaaS提供の場合、SaaS運用に必要な管理ツール/関連ソースコードの公開も必要・非公開でSaaS提供する場合、商用ライセンス契約が必要 Elastic License 2.0 (ELv2) ・製品をマネージドサービスとして提供する行為の禁止・ライセンスキー保護機構の回避や、ライセンスキーで保護される機能の削除/隠蔽の禁止・使用許諾/著作権/その他の通知を削除したり、分かりにくくする行為の禁止 SAL移行のメリットとデメリット自社のコードを非OSSのSALとするメリットは、競合他社による商用利用を規制し、自社製品の収益化を強化できる点である。一方、OSSの精神（自由な利用）からの逸脱によりコミュニティからの信頼が低下し、その利用リスクから利用者や貢献者が逃げる可能性がある。また、制約に関係する用語の定義が曖昧なライセンスもあるのが懸念となる。例えば、BSLの場合だと、「競合製品とはどこまでを指すのか」が良く分からず、提供元から突然「おたく、うちから見たら競合他社ですわ」だと言われると、コードを使えなくなる状況が生じることもあり得るわけである。まとめと所感以上のように、OSSは成長段階で収益化とのバランスを取るために、非OSSのSALへの移行が増加している。こういった取り組みは、「OSSとしての自由」と「持続可能な商用ビジネス」のせめぎ合いを象徴している。しかしコードを利用する立場としては色々と制限事項もあるわけで、あくまで個人の意見ではあるが、開発部から「これ使いたい」と言われると、判断が中々難しい。 OSSライセンスのように知見が蓄積されていないケースも多く、場合によっては想定外の利用制限が発生し、コードの入れ替えであったり、最悪ソフトウェアの販売を中止するというリスクもゼロではない。知財業務として一番避けるべきは特許侵害による差止請求であるところ、特定のSALについても同様に製品販売に支障をきたす可能性が捨てきれないのであれば、そのコードの利用は避けるよう開発部に提言することになるのだと思う。「知財がブロッカーになって開発がスピーディに進まない」と思うエンジニアもいるかもしれないが、そこは丁寧に背景を説明するしかない。

開発委託における、請負契約と準委任契約（成果完成型）との違い

開発委託契約においては、主に以下の2つの契約形態が用いられる。請負契約（民法632条）準委任契約（民法656条）履行割合型成果完成型従来の準委任契約は業務そのものの遂行が目的であって、成果物の納品義務はないものとしているところ（履行割合型）、実務上は準委任契約の中でも「成果完成型」と呼ばれる慣行があり、これが請負契約との違いを分かりにくくしている。以下に、準委任契約の「履行割合型」と「成果完成型」との違い、更に「成果完成型」と請負契約との主な違いを整理して示す。準委任契約の「履行割合型」と「成果完成型」準委任契約における「履行割合型」と「成果完成型」は、いずれも成果物の完成義務を負わないという点で共通するが、報酬の支払基準や業務の性質において実務的に大きな違いがある。履行割合型では業務の遂行自体を目的とするため、業務自体が報酬の対象となり、「作業時間」「作業工数」「作業量」等に基づいて、業務遂行の割合に応じて対価の額が決定される。対価の支払いタイミングは、例えば月毎に請求するといった対応が考えられる。一方、成果完成型は、一定の成果に向けた作業（例：プロトタイプ作成、設計書の作成など）が求められることから、成果物の完成は義務ではないものの、成果物の納品が報酬対象とされる。したがって、請負契約と同様に、納品をもって対価を支払うこととし、対価の額は納品物の性質によって決められる。このように、履行割合型とは異なり成果物の受け取りをもって対価を支払うため、成果物が得られないのに対価を支払わないといけないというリスクは小さくなる。準委任契約（成果完成型）と請負契約との違いいずれの契約も、成果物の納品が対価の対象となっている点は共通する。しかし、成果完成型の準委任契約は「成果物の納品をもって対価を支払う」約束をするだけであり、請負契約のような仕事を完成させる義務は無い点が異なる。また、受託者が善管注意義務を払って仕事を履行した結果である限りは、成果物が求める水準に達していなくても問題ないとされる。また、成果物の種類・品質・数量が契約内容に適合しなくとも良い（契約不適合責任を負わない）。これだと、委託元としては所望の成果物を確実に受け取ることができる請負契約の方が望ましいようにも見える。一方、成果完成型だと成果の完成義務はないものの、途中で成果物の仕様が変わるケースにも対応しやすい点がメリットとなる。だからこそ、契約不適合責任が無いともいえる。実務での使い分けの目安委託業務内容や納品物の性質によって、どの契約類型が望ましいかを以下の表に整理する。しかし、契約書に「準委任」「請負」とあれば、委託者、受託者とも概ねどんな責任が発生するのかを把握することが可能なので、各企業ともそれぞれに対応したひな型を持っているのではないだろうか。契約類型契約の特徴適した業務内容準委任契約（履行割合型）・業務遂行（時間/工数など）が価値の中心・成果物は求めない（業務完了報告書を成果物にするのはあり）・運用/保守・プロジェクト管理・技術支援・コンサルティング準委任契約（成果完成型）・成果物納品が期待されるが、完成責任は負わない・成果物が求める水準である必要はない（契約不適合責任なし）・要件定義書/設計書/プロトタイプ作成・技術調査/評価レポート作成・ユーザーマニュアル草案作成請負契約・成果物の完成義務あり・契約不適合責任が発生・実装されるプログラムの作成・アプリ/Webシステムの作成・ハードウェアの作成個人的な実務上の話上述のように３種類の契約形態があるものの、実務上は無理に請負・準委任という類型に当てはめない（請負、準委任とは明記しない）場合もある。その場合は、納品物の有無、納品物に関する事項（納品物の内容、引き渡し方法、検収方法など）、対価の額、対価の支払い条件、契約不適合責任の有無など、必要な条項をきちんと設けて、後で齟齬のないよう契約書を手当てしておきたいところである。なお、個人的な経験則ではあるが、準委任契約（成果完成型）で求めるような成果物（技術調査/評価レポート作成など）を作成してもらう場合でも、実際は準委任契約（履行割合型）とするケースが多い印象である。成果完成型だと、作業してみないとどんなものができるか分からない成果物の納品を求められる上、成果物に対する対価の見積もりが難しい。一方、履行割合型であれば対価の計算表（時間×単価など）を載せておけば良いので、その点揉めることも少ない。そして、業務報告書という形で評価レポートなどの成果物を出してもらうわけである。委託者目線では確実に成果を受け取りたいため、成果完成型に寄せたくなるところもあるかもしれない。ただ、準委任契約の場合は、受託者側にも善管注意義務が発生するため、善管注意義務に違反した結果、成果物が完成しなかった場合には、受託者が債務不履行責任を負うこととなる点は付け加えておきたい。

個人情報からの匿名加工情報の作成

個人情報保護法によれば、個人情報を利用する際には、利用目的を具体的に特定した（同法17条）上で、それを公表したり本人へ通知（場合によっては同意取得も）しなければならない（同法第18条、21条、27条）。例えば、企業が実験を行うにあたって多数の参加者を募り、参加者たちの個人情報を扱うことがあると思うが、同意書の取得や管理にかなり労力を要するのはないだろうか。しかし、個人情報を「匿名加工情報」に加工すれば、上記義務を課されることはなく、利用の自由度が上がるというメリットが得られる。また、「匿名加工情報」より緩い加工に留まる場合でも、「仮名加工情報」であれば、利用目的の公表は要するものの、本人への同意取得が不要となる。企業にとってみれば朗報だが、しっかりと活用できるよう、匿名加工情報/仮名加工情報の概要を整理しておきたい。匿名加工情報とは？これは日本の個人情報保護法で定められている概念で、2017年の法改正で導入されたものである。個人情報保護法2条6項によれば、「匿名加工情報」とは、以下の２つの要件を満たす個人に関する情報をいう。特定の個人を識別できないように個人情報を加工して得られるもの元の個人情報を復元できないようにしたもの個人情報を匿名加工情報にするには？個人情報を匿名加工情報に加工するには、以下の措置全てを行う必要がある。特定の個人を識別することができる記述等の全部又は一部を削除すること氏名、生年月日など個人識別符号（個人情報の保護に関する法律施行令に定めあり）の全部を削除すること個人の身体的特徴に関する符号（例：指紋や静脈などの生体情報）個人に割り当てられる符号（例：パスポート番号、マイナンバー、住民票コード）個人情報と他の情報とを連結する符号を削除すること事業者内で個人情報を分散管理してデータベース等を相互に連結するために割り当てられているIDなど特異な記述等を削除すること年齢116歳のように、国内で数名しかいない場合など上記のほか、個人情報とデータベース内の他の個人情報との差異等の性質を勘案し、適切な措置を講ずること例えば画像データを匿名加工情報にする場合は、以下のような処理を行うことが考えられる。別データへの変換属性情報（性別、年代等、個人情報を特定できないものに留める）キャプション（個人名等を含まない説明文）統計データ画像中に含まれる個人情報（氏名、顔画像など）にマスキングをかける匿名加工情報の取り扱い方匿名加工情報であれば、本人の同意なく、第三者に提供できる。しかし、それでも個人情報保護法の第43条〜第46条に記載の以下の義務は生じる。公表の義務まずは、以下のような公表義務が発生する。匿名加工情報を作成したときの公表義務（法43条3項）作成後遅滞なく公表匿名加工情報に含まれる「個人に関する情報の項目」を公表匿名加工情報を第三者提供するときの事前公表義務（法43条4項・44条）第三者に提供する匿名加工情報に含まれる情報の項目を公表匿名加工情報の提供方法を公表提供前にあらかじめ公表その他義務上記公表義務のほか、以下の義務も生じる。安全管理措置を講じる義務（個人情報保護法43条2項、第6項及び第46条）匿名加工情報の加工方法等情報の漏えい防止匿名加工情報に関する苦情の処理・適正な取扱い措置と公表識別行為の禁止（個人情報保護法43条5項及び45条）自らが作成した匿名加工情報を、本人を識別するために他の情報と照合する行為の禁止受領した匿名加工情報の加工方法等情報を取得する行為や、受領した匿名加工情報を、本人を識別するために他の情報と照合する行為の禁止仮名加工情報とは？次に、「仮名加工情報」にも触れておきたい。匿名加工情報と似たような概念だが、こちらは本人を直接識別できないように加工しつつも、他の情報（対応表など）と照合すれば識別できる可能性のある情報である点が匿名加工情報と異なる（個人情報保護法2条5項）。仮名加工情報の取り扱い方加工の条件が匿名加工情報よりは緩いものの、代わりにその利用目的を公表する必要がある。また利用目的の変更を行った場合には、原則として、変更後の利用目的を公表する必要がある。逆に言うと、公表すれば後から利用目的を追加することも可能であり、しかも本人からの同意取得が不要というメリットがある。しかし、匿名加工情報とは異なり、仮名加工情報の第三者提供はできない。仮名加工情報を共同利用することにより第三者に提供することは可能だが、仮名加工情報である個人データの提供の前に仮名加工情報である個人データを共同利用する旨共同して利用される仮名加工情報である個人データの項目共同して利用する者の範囲利用する者の利用目的当該仮名加工情報である個人データの管理について責任を有する者の氏名又は名称及び住所並びに法人にあっては、その代表者の氏名を公表する必要がある。匿名加工情報/仮名加工情報の対比表ここで、両者の対比表を作成してみた。いずれも、情報の利用にあたって本人の同意が不要な点は共通する。分類概要義務・制限例匿名加工情報・本人を識別できないよう加工・他情報と照合しても復元不能・公表の義務・その他義務（安全管理措置など）・年代/地域別人数のみの統計データ・商品毎の販売数を集計したデータ・年齢を「20代」などに丸めたデータ・個人特定可能な要素を削除したアンケート結果・従業員を部署/年齢層別の人数にまとめた人事情報仮名加工情報・本人を識別できないよう加工・他情報と照合すると復元可能・利用目的の公表義務・第三者提供不可・共同利用による第三者提供可（条件あり）・氏名を削除し、顧客番号だけで管理する購買履歴・社員名を社員番号に変えた人事情報・連絡先を削除、IDだけで管理する利用履歴・患者名を管理番号とした医療データ・会員情報を仮IDに変えた分析データ具体的な公表方法は？匿名加工情報/仮名加工情報を利用する前に、各種情報の公表の義務などを果たすには、インターネットなどで公表するのが手っ取り早い。公表サンプル以下、これまで整理した内容をもとに、インターネット上で掲載するための公表サンプルを作成してみた。あくまで参考という位置づけで見てみて欲しい。当社は、「個人情報の保護に関する法律」（平成15年法律第57号。「個人情報保護法」といいます。）に基づく個人情報の適正な取扱いの確保について組織として取り組んでいます。このたび、同法に基づく「匿名加工情報」「仮名加工情報」の作成・提供を行いますので、公表いたします。匿名加工情報匿名加工情報に関する措置内容当社が作成および取得する匿名加工情報に対して、当社は以下の措置を実施します。匿名加工情報の安全管理措置当社は、識別と認証に基づくアクセス制御、外部からの不正アクセスの防止、移送・送信時の暗号化など、匿名加工情報の取扱いの各局面のリスクに応じた適切な安全管理措置を実施します。匿名加工情報の適正な取扱いを確保するための措置当社は、匿名加工情報等の取扱いに関する相談対応などの社内体制を整備し、匿名加工情報等を取り扱う従業者や委託先管理を含めた匿名加工情報等の管理ルールを整備し、識別行為の禁止などの利用ルールを取扱い者へ周知して、匿名加工情報等を適正に取り扱います。匿名加工情報の作成当社が作成した匿名加工情報について、以下の通り公表します。個人に関する情報の項目年代、性別、職業（業種）、家族構成、住所（都道府県）などの属性情報当社提供アプリの使用状況データ(ログイン頻度など) 当社が提供する○○サービスの利用に関して、ユーザーから取得したアンケートやフィードバック結果 ○○画像（映り込んだ人物の画像をぼかし加工）当社は、今後も継続的に同様の匿名加工情報を作成することを予定しております。匿名加工情報の第三者提供当社が作成した匿名加工情報を第三者に提供する場合の目的、匿名加工情報に含まれる項目およびその提供方法は以下の通りです。匿名加工情報に含まれる個人に関する情報の項目上記の項目すべて提供の方法パスワードにより保護された電子ファイルを外部記憶媒体で手交アクセス制御したファイル共有システムによりファイルを提供セキュア情報交換サイト経由で提供当社は、今後も継続的に同様の匿名加工情報を第三者に提供することを予定しております。仮名加工情報仮名加工情報の利用目的当社は、仮名加工情報の利用目的として、以下の通り公表します。仮名加工情報の元データの概要当社が提供する○○サービスにて取得した個人情報利用目的当社の商品・サービスの企画・設計・開発、品質向上のため仮名加工情報の共同利用上記の利用目的達成のために、当社は以下の通り仮名加工情報を共同利用します。共同して利用される仮名加工情報である個人データの項目お客様の年代、性別、○○サービスに関する情報（利用状況など）共同して利用する者の範囲当社、株式会社○○、●●株式会社利用する者の利用目的当社の商品・サービスの品質向上のため当該仮名加工情報である個人データの管理について責任を有する者の氏名又は名称及び住所並びに法人にあっては、その代表者の氏名当社　代表者の氏名はこちら（企業HPのリンク）をご覧ください。お問い合わせ匿名加工情報または仮名加工情報に関するご質問やご意見がございましたら、以下の連絡先までお問い合わせください。 xxxxxx ...

知財契約における任意規定と強行規定

契約を行う上で、民法には「任意規定」と「強行規定」という規定が存在することを留意しておく必要がある。「任意規定」とは、当事者の合意で排除できる規定であり、契約で別の内容を定めれば、その合意が優先される一方、もし契約で何も決めていなければ、適用される規定である。民法でも、次のように規定されている。（任意規定と異なる意思表示）第九十一条　法律行為の当事者が法令中の公の秩序に関しない規定と異なる意思を表示したときは、その意思に従う。一方、「強行規定」とは、当事者の合意で排除できない規定を指し、公序良俗や弱者保護など、社会的に重要な価値を守るために必ず適用される。したがって、契約において、当事者間で強行規定に反する内容に合意したとしてもその部分は無効となる。例えば、民法では第5条（未成年者の法律行為）等が強行規定である。では、契約時の知財の取扱いに関して、強行規定となる条文は存在するのだろうか？民法における「知財」に関する規定結論からいうと、民法には知的財産権の帰属や利用許諾に関する直接の規定は存在しない。民法は物権・債権の一般原則を定めるもので、知財の詳細は特別法（著作権法、特許法、商標法、不正競争防止法など）に委ねられている。ただし、直接ではないものの、次のような一般規定が知財契約にも作用する。契約自由の原則（民法521条）当事者は契約内容を自由に決められる。知財の帰属・利用許諾についても、特別法の強行規定に反しない限り、自由に定められる。請負契約（民法632条以下）・委任契約（民法643条以下）開発委託契約は請負や準委任の性質を持つ。ただし、請負の目的は「成果物の完成」であって「知財の帰属」まで規定していない。不法行為・契約責任（民法709条、415条）知財を契約外で利用した場合、不法行為責任・債務不履行責任が問われる。これも一般原則であり、知財特有の規律ではない。強行規定があるのは「特別法」知財分野で強行規定といえそうなものは特別法に存在するが、その数は少ない。例えば、以下のものは民法の契約自由の原則に対する「特別法による制約」といえる。著作権法59条（著作者人格権は譲渡できない」）：強行規定特許法35条（職務発明に関する取扱い）：強行規定と考える判例が多いしかし、特許法35条等、強行規定/任意規定のいずれと考えるべきか、未だ論争のあるものが多いのが実情である。まとめ知財に関する任意/強行規定は、概ね以下の通りとなる。民法には知財の帰属や許諾についての直接規定はなく、契約自由の原則に基づき「任意規定」として処理される。著作権法・特許法など特別法の一部には強行規定がある（著作者人格権は譲渡不可、など）。実務上は、民法の任意規定に頼らず、契約で明示的に知財の帰属・許諾範囲等を定める必要がある。知財で取り分けポイントとなる権利帰属、許諾範囲（期間、地域、対象など）、ライセンス費、サブライセンス権の有無などは、当事者同士の合意のもと契約で定めておけば強行規定によって無効化されること無さそうである。しかし、あまりに一方に有利な契約内容となっている場合は、不公正な取引方法に該当するとして、独占禁止法違反となる可能性がある点は要注意である。独占禁止法から見たライセンス契約上の留意点については、また別の記事で整理してみたい。

結合商標の分離観察の可否

自社で新しい製品を販売するとき、製品名について他社商標のクリアランスを行う上で、次のような場合に結合商標の類否判断に迷うことがある。自社製品名「○○ △△」（結合商標）に対し、他社商標「○○」が見つかるパターン自社製品名「○○」に対し、他社商標「○○ △△」（結合商標）が見つかるパターン商標出願人は、商標の構成全体から他人の商標と識別するように商標を考案しているため、基本的には商標は全体として観察されるべきものである。しかしながら、複数の要素からなる結合商標に関しては、一部の要素から生ずる呼び名や概念が識別標識として働く場合があるため、商標法の判例では商標の分離観察を認めている。ここで実務での参考とすべく、結合商標の類否判断の方法が示された判例を紹介したい。結合商標の分離観察に関して過去の判例では結合商標の分離観察の可否及び要部認定の判断基準が言及されており、具体的には以下の３つの類型のいずれかに当てはまる場合は、分離観察も可とされている。しかし、分離観察の可否の判例は統一された状況とはいえず、あくまで分離観察の可否を検討する上での一助という位置づけとなるかもしれない。類型概要類型１その部分が取引者、需要者に対し商品又は役務の出所識別標識として強く支配的な印象を与えると認められる場合類型２それ以外の部分から出所識別標識としての称呼、観念が生じないと認められる場合類型３商標の外観等に照らし、商標全体としての構成上の一体性が希薄で、取引者、需要者がこれを分離して理解・把握し、その一部を略称等として認識する結果、当該構成部分が独立した出所識別標識としての機能を果たすと考えられる場合（分離された各構成部分の全てが当然に抽出して類否判断を行うことが許される要部となるものではない）参考として、以下２つの判例の内容を掘り下げてみたい。つつみのおひなっこや事件（最判、平成19年（行ヒ）第223号、平成20年9月8日） VENTURE事件（知財高判、令和5年（行ケ）第10063号、令和5年11月30日）つつみのおひなっこや事件以下の本件商標（結合商標）が、引用各商標と類似するか否かが争われた事件である。項目出願・登録番号商標本件商標第4798358号引用商標１第2354191号引用商標２第2365147号類型1：非該当以下の通り、判決文を要約すると、「つつみ」の部分が強く支配的な印象を与えるものではない、ということである。判決の要約本件商標は、「つつみのおひなっこや」の文字を標準文字で横書きして成るものであり、各文字の大きさ及び書体は同一であって、その全体が等間隔に１行でまとまりよく表されているものであるから、「つつみ」の文字部分だけが独立して見る者の注意をひくように構成されているということはできない。本件商標の「つつみ」から地名、人名としての「堤」ないし堤人形の「堤」の観念が生じるとしても、本件審決当時、それを超えて、「つつみ」の文字部分が、本件指定商品の取引者や需要者に対し引用各商標の商標権者である被上告人が本件指定商品の出所である旨を示す識別標識として強く支配的な印象を与えるものであったということはできない。類型2：非該当以下のように、「おひなっこや」の部分から出所識別標識としての称呼、観念が生じていると判断されている。判決の要約本件商標の「おひなっこや」については、これに接した全国の本件指定商品の取引者、需要者は、ひな人形ないしそれに関係する物品の製造、販売等を営む者を表す言葉と受け取るとしても、「ひな人形屋」を表すものとして一般に用いられている言葉ではないから、新たに造られた言葉として理解するのが通常であると考えられる。そうすると、土人形等に密接に関連する一般的、普遍的な文字であるとはいえず、自他商品を識別する機能がないということはできない。 VENTURE事件以下の本件商標と引用商標（結合標章）の類否判断において、分離観察が許される第3の類型を示した事件である。項目出願・登録番号商標本件商標商願2020-128329 引用商標第6434159号類型3：該当（一部要素は類否判断の対象外）本件では、引用商標の「遊」の部分が独立した出所識別標識としての機能を果たす一方、「VENTURE」の部分では果たさないとの判断がなされている。確かに、「遊」の占める部分が大半なので、納得感のある判断ではないかと思う。判決の要約引用商標の各構成部分を比較すると、文字の大きさの違いからくる「遊」の文字部分の圧倒的な存在感、書体の違いからくる訴求力の差、全体構成における配置から自ずと導かれる主従関係性、称呼及び観念において一連一体の文字商標と理解すべき根拠も見出せない等の事情を総合すると、引用商標に接した取引者、需要者は、「遊」の文字部分と「ＶＥＮＴＵＲＥ」の文字部分を分離して理解し、中心的な構成要素として強い存在感と訴求力を発揮する「遊」の文字部分を略称等として認識し、これを独立した出所識別標識として理解することもあり得る。「ＶＥＮＴＵＲＥ」の文字部分は、商標全体の構成の中で明らかに存在感が希薄であり、従たる構成部分という印象を拭えず、取引者、需要者がこれに着目し、引用商標の略称等として認識するということは、常識的に考え難く、引用商標の要部と認定することはできない。知財部としての判断基本的には結合商標も全体として観察すべきところ、以下の類型のいずれかに当てはまる場合は分離観察する場合もある、ということとなる。類型１：その部分が強く支配的な印象を与える類型２：それ以外の部分から出所識別標識としての称呼、観念が生じない類型３：一部を略称等として認識する結果、当該構成部分が独立した出所識別標識としての機能を果たすただ、これらは商標審査基準として明文化されたものではないので、知財部としては、結合商標の一部が他社商標と同一となる場合は、同一となる範囲などの程度にもよるが、例えば半分以上同一だったり、同一部分がそこそこ識別力がありそうであれば使用を控えてもらうよう事業部に促すのが安全な判断になるのではないかと個人的には思う。事業部としては「ちょっと慎重になり過ぎな判断では？」と疑問を持たれることがあるかもしれないが、特許とは異なりネーミングを変更することはそれ程難しいことではないと思われるので、そこは何とか納得してもらえるように説得するのが大事である（ブランド戦略上必要なネーミングであれば再考の余地はある）。既に製品を量産したり、プロモーションを展開している場合は修正が大変となるかもしれないが、それは事前にクリアランスを怠った結果と言ってしまえばそれまでである。