Posts

実務者なら分かると思うが、USPTOの審査官は、その審査の質にかなりバラツキがあるなと感じる。 人が審査しているので仕方ない面はあるのだが、特許が許可となる確率も大きく異なるし、インタビューの有無などによる許可率の変化の仕方も違いがある。 つまり、あらかじめ審査官の傾向を把握しておけば、例えば以下のような感じでOAの戦略を考えることができるわけである。 許可率が低く、拒絶が厳しい審査官なら・・・ 早期にクレームを絞り込み、無理に争わず着地点を探る 1st OA後すぐに審査官インタビューを設定し、認識のズレを解消する AppealやRCEも視野に入れた中長期戦を前提に動く 許可率が高く、比較的柔軟な審査官なら・・・ 意見書・補正書のみでスムーズな許可を狙う コスト増に繋がるため、インタビューは控える クレームスコープを維持しつつ、最小限の補正で通す インタビュー実施時に許可率が大きく上がる審査官なら・・・ 初期段階から積極的なインタビューを行う ※ただし、以下記事に記載の通り、2026年度より審査ラウンド毎のインタビューは原則１回に限定される USPTO審査変更の影響（審査官インタビューの制限） 米国の審査に影響する話となる。 2026年度のUSPTOによる審査官業務評価計画で、新たな変更が導入されるとのこと。 １案件につき、審査官... そこで、OA対応方針の検討時に審査官の難易度を調べることが重要となるわけだが、この情報を検索できるUSPTO審査官評価サイトをいくつか紹介したい。 無料でも使えるUSPTO審査官評価サイト 2026年4月時点では、以下４つのサイトからUSPTOの審査官の統計データを見ることができる。 PatentsBots このサイトの「Patent Examiner Statistics」というサービスでは、有料登録により審査官個人の様々な過去の審査情報を入手できるが、無料でも以下３つの統計データが得られる。 大体の審査官の難易度を把握するのには丁度良い。 3-Year Grant rate：直近３年間の許可率 Difficulty：難易度 (Extremely Easy, Very Easy, Easier, Medium, Harder, Very Hard, Extremely Hardの7段階) Difficulty Percentile：最も許可を出しやすい審査官からを順に並べた際に、全体の何パーセント目にあたるかを示す「位置」。0〜100の数値で表され、高いほど難関。 Unified Patents 2001年1月1日以降の案件から集計しており、以下の基本情報を入手可能。 Total Apps（総件数） Issued（許可件数） Abandoned（放棄件数） Pending（継続件数） 面白いのは、以下の項目の有無による許可率の比較、そして対象の審査官が所属するArt Unitの平均許可率値との比較ができる点である。 例えば、審査官インタビューがあると許可率が大きく上がる審査官であれば、「じゃあ多少費用がかかっても現地代理人にインタビューをお願いしてみようかな」と判断をすることも考えられる。 Final Rejection 審査官インタビュー Appeal RCE Big Patent Data 直近３年間のデータを対象に以下の情報を入手可能。 しかし、PatentsBotsより扱っている件数が少ない。 blogは2022年4月を最後に更新されておらず、最近のデータは集計していない可能性が高い。 Allowance Rate：許可率 Actions per Allowance：許可までに要する平均OA回数 Actions per Abandonment：放棄までに費やす平均OA回数 Months to 1st Action：1st OAまでの平均月数 Months to 1st Allowance：許可までに要する平均月数 Smartpat こちらでも審査官データを閲覧できるものの、2020年8月を最後にデータがアップデートされていない。 おすすめの無料サイトは？ ４つの無料サイトを紹介したが、最近の統計データも集計しているのは「PatentsBots」と「Unified Patents」の２つである。 基本的には、例えば以下のような用途に応じて両者を使い分けると良いと思う。 ざっくりした難易度が知りたいなら、PatentsBots 審査官インタビューやRCEによる効果まで見たいなら、Unified Patents

ビジネスを展開する上では商品・サービス名に関係する商標には注意が働くだろうが、その商品・サービス名をWebサイトのドメインとしても用いるのであれば、その「ドメイン」の取り扱いについても配慮しておく必要がある。 商標とドメインの違い まずは基本的な整理から触れておく。 ドメインとは何か ドメインはインターネット上の「住所」であり、同一の文字列は世界に一つしか存在しない。 これは早い者勝ちで取得され、ブランド的な役割を持つことも多い。 ドメイン中の末尾にある「co.jp」や「.com」といった、 一般ユーザーが直接ドメインを取得できる末尾の文字列をパブリックサフィックスと呼ぶ。 パブリックサフィックスとしては、メジャーな「.com」が人気であり、既に多くのドメイン名が取得されていることから新たな取得難易度も高い。 また、パブリックサフィックスによって取得費用はまちまちである。 ドメイン取得は早いもの勝ちではあるが、「○○.com」○○の部分を既存のドメイン名と同じものとしつつ、パブリックサフィックスを変えれば（例：.netなど）、別途取得できるという特徴がある。 フィッシングサイト等で、パブリックサフィックスだけ変えたURLを見かけたことがあるかと思う。 商標とは何か 商標は、商品・サービス（役務）の出所を識別するための標識であり、国ごとに登録される権利である。 こちらも所定要件を満たせば早い者勝ちであり、既に同一・類似商標があれば基本的には登録はできない（コンセント制度を活用すれば登録も可能）。 両者の関係 重要なのは、ドメイン登録と商標登録は完全に別制度であるという点である。 例えば、先に同一・類似の商標登録が存在していても、その文字列のドメインが未取得であれば原則としてドメインは取得できてしまう。 つまり、正式にドメイン取得したはずの企業が、そのドメインの使い方によっては商標権を保有する企業から訴えられる可能性があるというわけである。 また、図利加害目的で、他人の商品・役務の表示（特定商品等表示）と同一・類似のドメイン名を使用する権利を取得・保有、又はそのドメイン名を使用する行為は、不正競争防止法違反となる（不正競争防止法第2条第1項第19号）。 したがって、他者が商標登録済の文字列に関しては、ドメイン取得することはお勧めしない。 また逆に、商標登録した企業であっても、その名称のドメインが別企業に取得されてしまっている場合もある。 よって、商標登録、ドメイン取得の際は、お互いの登録・取得状況について事前に調べておくのが望ましい。 ブランド管理としての一体運用 商標とドメインは、制度上は別でも、ブランドという観点では同一の資産であるため、一体的に管理することが望ましい。 つまり、ドメイン取得の際には商標登録の必要性についても検討するということである。 ドメインの商標登録の必要性判断 もし、単なるURL（アドレス）としてのみ使用する場合なら、商標的使用とはならず、商標登録は不要である。 一方、Webサイト上でブランド表示したり、広告やプロモーションで使用するのであれば、商標登録することが考えられる。 ただし、商標登録出願時には識別力の無いパブリックサフィックス（「.co.jp」「.jp」「.com」「.net」など）まで含める必要は無く、例えば「○○.com」であれば、「○○」の文字部分を出願するのが基本となる。 グローバル展開時の留意点 商標であれば、国によっては権利維持に使用実績が求められる点は注意である（米国など）。 各国の判断によるところだが、上記の通り、単なるURL（アドレス）として使用するだけでなく、実際の商品・サービス名として使用しているところまで求められる可能性があるのではないだろうか？ また、ドメイン観点ではブランド展開のために国別にドメインを押さえることも一案である。 例えば、「.com」とは別に、「.jp」（日本用）、「.cn」（中国用）を取得するという具合である。 商標とドメインの管理 商標権の維持には年金を納めつつ、国によっては継続使用する必要があるところ、ドメインに関しても更新費用を納める必要がある。 また商標とは異なり、ドメイン名ハイジャックを防ぐためのセキュリティ対策が必要となる。 模倣ドメインへの対応 ブランドが成長すると、問題になるのが「模倣ドメイン」である。 自社の商品・サービス名を使ったドメイン名を取得・使用し、ブランドイメージにあやかろうとする輩が現れるかもしれないので、その対策が求められる。 複数ドメインの取得 「.com」「.co.jp」といった主要ドメインを取得すれば、模倣ドメインが取得されるリスクは減らせる。 取得・更新費用は嵩んでしまうが、その他ドメインについても取得検討するとベターである。 監視の重要性 継続的なドメイン監視は有効な対策の１つとなる。 例えば、企業が提供するドメイン監視サービスを利用することで、自社ブランドやサービス名に類似したドメイン名の新規登録・運用状況を定期的にチェックし、フィッシング詐欺や商標権侵害などの不正利用を早期発見することが容易となる。 紛争解決手段 もし模倣ドメインを発見し、その廃止等を求めるのであれば、当事者間の交渉や裁判のほか、UDRP（Uniform Domain-Name Dispute-Resolution Policy）の利用が挙げられる。 これは、不正なドメイン取得に対して、ドメインの移転や廃止を求めることができる制度であり、裁判に比べて大幅な時間短縮とコスト節減が期待できるWIPOのサービスである。 ただし、単に第三者に取得されているだけでは足りず、「不正の目的（転売やなりすまし等）による登録・使用」が必要という制約がある点には注意である。 なおJPドメインについては、日本知的財産仲裁センターが認定紛争処理機関として紛争処理を担う。 もちろんUDRPの対象とならない正当な権利者間の紛争であれば、裁判による解決も選択肢となる。 ドメインを巡る主な裁判例 ドメイン使用を巡り生じた紛争として、次のようなものがある。 リシュ活.jp事件 事件番号：平成30年（ワ）第11672号 原告：学情株式会社（「Re就活」商標保有） 被告：一般社団法人履修履歴活用コンソーシアム（「risyu-katsu.jp」使用者） 裁判所は、ドメイン名と商標の類似性を認定し、被告による使用の差止等を認容した。 → ドメインと商標の類似が問題となる典型例 マリカー事件 事件番号：平成30年（ネ）第10081号ほか 原告：任天堂株式会社 被告：株式会社MARIモビリティ開発（「maricar.jp」「maricar.co.jp」「fuji-maricar.jp」「maricar.com」使用者） 原告は「マリカー」の商標を登録していなかったため、不正競争防止法に基づく請求を行い、裁判所は、ドメイン使用の差止と、一部ドメインの抹消を認めた。 まとめ 商標とドメインは制度上は別物だが、その活用方法の共通性から、ブランド管理上は一体で考えるべきである。 そして、商標・ドメインいずれも以下の点が基本となるであろう。 使用・登録前に事前調査する 先に登録する 広く押さえる 継続的に監視し、有事に備える

契約において、損害賠償条項や免責条項といった条項で責任の範囲を規定する際は、必ずと言っていいほど以下の用語を目にすることかと思う。 故意 過失 重過失 責めに帰すべき理由 故意と過失の違いは直感的に理解できても、どこからが「重過失」と評価されるのか、また「責めに帰すべき理由」はどのレベルを含むのか、という点は、契約レビュー時に意識しておきたいポイントである。 責任の範囲を規定する各用語の意味 以下、それぞれの用語の概念を整理しておきたい。 故意 結果が発生することを認識しながら、意図的に何かをすること、または何もしないでいることを意味する。 したがって、主観的な要件といえる。 当たり前だが、通常、故意は過失よりも法的な責任は重くなる。 過失 結果を予見でき、かつその結果を回避できたにも関わらず、必要な注意を怠ることを意味する。 従来は、その人が十分緊張して注意したかどうかの心理的な問題だと考えられてきた（主観説）。 しかし、その人の心理的状態（注意していたのか、うっかりしていたのか）を判断するのが難しいことから、現在は、各分野（例：ソフトウェアベンダ）に属する平均的な人にとって「通常とるべき行動をしたかどうか」の問題と捉えるのが通説とされている。（客観説）。 「これは過失だ」と判断できる明確な基準を示すのは難しく、裁判では、サービスの性質などに応じて案件毎に判断がなされるのが実情である。 ソフトウェアベンダでいえば、運用や保守作業にあたっていたスタッフに人的ミスがあれば、過失と認められる可能性があると思われる。 重過失 わずかな注意をすれば、容易に結果を予見し回避できたにもかかわらず、漫然と見逃すような著しい注意欠如の状態であり、ほとんど故意に近いとされる。 この「ほとんど故意に近い著しい注意欠如の状態」があるという点が、過失との決定的な違いとなる。 ソフトウェアベンダの場合は、長期間既知の重大な脆弱性を放置したとか、セキュリティ標準から大きく外れた運用をしていた、という事情があれば重過失が認められ得るが、過失の認定よりもハードルが高いのは言うまでもない。 責めに帰すべき事由（帰責性） 「責めに帰すべき事由」とは、故意もしくは過失、または信義則上これらと同視すべき事由をいい、単なる「故意・過失」よりも広い概念となっている。 「信義則上故意・過失と同視すべき事由」として重要なのは、いわゆる「履行補助者の故意・過失」である。 ここで「履行補助者」とは、債務者が債務を履行するために使用する者を指す。 例えば、業務委託契約の受託者が第三者に業務を再委託する場合、この第三者が受託者の履行補助者に該当する。 もし受託者自身に故意・過失がないとしても、履行補助者に故意・過失があれば、受託者は委託者に対して損害賠償責任を負うと解される。 履行補助者の使用は、あくまで委託者が希望したものではなく受託者側の都合によるものであり、履行補助者の故意・過失は受託者自身の故意・過失と信義則上同視すべき、という理屈となる。 その他留意点 上記概念のほか、免責や損害賠償の検討に際し留意すべき点をいくつか挙げておきたい。 免責対象から故意・重過失の場合を除くこと 損害賠償責任の免責条項が、信義則や公序良俗に反し不当である場合には、無効になる場合がある。 具体的には、故意・重過失がある場合に損害賠償責任を免除・制限する条項に関しては、無効であると判断される可能性は高い。 また、利用者が消費者である場合、事業者に故意又は重過失がある場合にまで責任を限定する条項は無効と明確に定められている（消費者契約法8条1項2号）。 そのため、故意・重過失の場合については損害賠償責任の免責を定めない方が無難である。 過失相殺の減額 過失相殺とは、ベンダのみならずユーザーにも過失があった場合は両者の責任を相殺し、ベンダが支払う損害賠償額を減額することをいう（民法第722条2項）。 ユーザーに過失相殺に値する事情があれば、過失相殺の有無も個別案件で判断されることとなるが、例えばベンダの過失でユーザのデータが消失したとき、ユーザー側で簡単にバックアップすることができたにも関わらずそれを怠っていた場合には、損害賠償額が減額され得る。 したがって、利用者の立場であれば利用時の義務は守るよう努めるべきだし、ベンダ側の立場なら少しでも賠償額を減らすために過失相殺の主張をする検討余地があるかと思う。 損害賠償範囲に逸失利益を含めるか 民法第416条では、債務不履行（契約違反など）による損害賠償の範囲として、以下２点を請求可能な損害と定めている。 通常生ずべき損害（通常損害） 特別の事情によって生じた損害（予見できた場合に限る。特別損害） ここで注意したいのは、民法に従えば項目2も含まれるところ、いわゆる逸失利益（契約違反がなければ、将来得られたはずの収入や利益）も損害賠償の対象となる可能性がある、という点である。 したがって、民法の定めとは異なり逸失利益を対象外としたい場合は、契約書で「現実に生じた直接かつ通常の損害に限る」といった限定を設ける運用が一般的である。

昨今は、AI生成画像を商用利用する機会が多くなってきている。 個人で楽しむ分には問題ないが、商用利用する上では「AIが出してくれた画像なら安心」というわけではない。 この記事では、AI生成画像を商用利用する際の法的留意点を押さえておきたい。 生成AIの利用規約 まず気にすべきは利用規約となる。 生成画像の所有権は誰になるのか、また禁止行為としてどんなものがあるのかを確認したい。 生成画像の所有権 幸い、作成画像の所有権はユーザーとする生成AIが殆どのようである。 一方、利用規約によっては社内サービス等のために生成画像の利用を許諾しなければいけないこともあるので、許諾しても問題無いか念のため確認しておきたい。 以下の表に、主な生成AIと、ユーザーに所有権がある旨の根拠記載をまとめた。 生成AI 画像利用OK? 利用規約 根拠となる記載 ChatGPT OK 利用規約（2026年1月1日発効） コンテンツの所有権限。お客様と OpenAI との間において、適用される法律で認められる範囲において、お客様は、（a）インプットに対する所有権を保持し、（b）アウトプットを所有します。当社はアウトプットに関する権利、権原、及び利益がある場合、これらすべての権限をお客様に譲渡します。 Gemini OK Google利用規約（2024年5月22日発効） ユーザーのコンテンツ Google の一部のサービスは、ユーザーによるオリジナル コンテンツの生成を許可しています。Google がそのコンテンツに対する所有権を主張することはありません。 Copilot OK Microsoft Copilot 使用条件（2025年10月24日発効） 「お客様のコンテンツ」とは、Copilot との会話に含まれるプロンプトと応答を意味しますが、Microsoft が別途所有するコンテンツ (Xbox ゲーム クリップなど) は含まれません。 Microsoft はお客様のコンテンツを所有していませんが、Copilot の運営および改善のためにお客様のコンテンツを使用することがあります。Copilot を使用することにより、お客様は、お客様のコンテンツを使用する許可を Microsoft に付与することになります。 Claude OK Consumer Terms of Service（2025年10月8日発効） Rights and Responsibilities. …Subject to your compliance with our Terms, we assign to you all of our right, title, and interest—if any—in Outputs. Grok OK Terms of Service - Consumer（2025年11月4日発効） User Content: You Own Your User Content. You may provide input (e.g., text, audio, images, video, code, files, folders, drives, etc.) to the Service (”Input”) and receive output from the Service (excluding output from Grokipedia) based on the Input (”Output”). Collectively, Input and Output are “User Content.” 禁止行為 生成AIによって禁止行為の記載内容は若干異なるが、どの生成AIでも、違法/暴力的/性的/プライバシー、知財権等の権利侵害コンテンツの生成は禁止されている。 ...

Webスクレイピングは、Webサイト上のコンテンツやデータを自動的に抽出・収集する手法であり、競合調査やデータ分析、AI開発などのための情報収集手段として注目されている。 例えば、SNSや電子掲示板の書き込みを元に自社サービスの評判を調査する際、Webスクレイピングを活用することで、非常に短時間で調査することが可能となるわけである。 ここでWebスクレイピングそのものが問題というわけではないのだが、情報を自動収集するという性質上、無自覚に実行すると複数の法領域にまたがるリスクを抱える。 多くのサイトでも議論されているところかと思うが、備忘録もかねて主要な論点を整理しておく。 利用規約 まず最初に問題になるのが、収集先となるWebサイトやSNSの利用規約となる。 いくつかのECサイトやSNSでは、スクレイピング等の自動取得行為を明確に禁止している。 この規約に反してデータ取得を行えば、アカウント停止や損害賠償請求のリスクがある。 これに関しては、後述の訴訟のように「ログインせずにアクセスできる公開データ」だけを取得対象にするなら利用規約の効力が及ばないと判断される可能性もあるが、正直日本ではセーフとまでは言い切れるほどの判例や庁見解が揃っていないと思う。 よって、利用規約でスクレイピングを禁止する旨が記載されていれば、スクレイピング行為は控えた方が無難である。 米国の議論（参考） 米国地裁の訴訟であるMeta v. Bright Dataでは、「公開情報については利用規約の効力が制限され得る」という判断が示されている。 ただし、あくまで米国での判断であり、事案依存性が強いという点から、日本でも同様に安全とは言えない。 基本的には公式APIを使うこと もし情報収集したいSNS等に公式APIがあれば、そちらから情報取得するのが安全である。 もし公式APIがあるにも関わらず、スクレイピングで情報収集しようとする行為は利用規約違反となる可能性が高い。 公式APIがあればWebサイトの利用規約とは別にAPI利用規約が公開されているかと思うので、利用の際はAPI利用規約も遵守する必要がある。 著作権法 スクレイピング対象には、テキスト・画像・動画などの著作物が含まれ得る。 日本の著作権法では、著作権法30条の4により、AI学習などの情報解析目的であれば、原則として著作物の利用が認められる。 ただし、取得データをそのまま掲載する行為は認められない。 掲載する場合は、非類似レベルや統計データへの加工といった対応が必要になる。 個人情報保護法 スクレイピング対象に個人情報が含まれる場合、リスクは一気に高まる。 「公開されているから自由に使える」とは限らず、目的外利用、要配慮個人情報（病歴や犯罪歴など）の取得、第三者提供するといった場合は、個人情報取得に本人同意が必要となる。 一方、現在の個人情報保護法の改正方針案によれば、統計情報等の作成（統計情報等の作成と整理できるAI開発等も含む）のみの利用なら本人同意取得不要とする方針が示されている。 ただし、これはあくまで2026年3月時点では方針案レベルであり、確定ルールではない点に注意が必要である。 改正案については、以下の記事でも触れている。 AI学習用データとして使うなら、個人情報の同意取得が不要となる？ 個人情報保護法では、原則として、利用目的の通知またはHP上等での公表を行っておけば、個人情報取得・利用の際の本人同意は不要である。 一方、... 基本的には、個人情報は取得しない、適切に匿名化する、といった対応が必要となる。 不正競争防止法 一般公開されていない営業秘密を不正にスクレイピングした場合、営業秘密の不正取得（不正競争防止法違反）となる場合がある。 公開情報であればともかく、ログインを要する情報の場合はリスクが生じることとなる。 刑法（偽計業務妨害、電子計算機損壊等業務妨害） スクレイピングは、リクエストの頻度が多すぎると刑事問題にも発展すし得る。 具体的には、サービス提供に支障が出るほどサーバーに過剰な負荷をかける程の頻度になると問題になる。 この問題となる頻度を定量的に判断するのが難しく、一見すると大した頻度でないように見えても、サーバー能力等との兼ね合いで、現実に障害が発生すると問題とされる可能性が高まるようである。 過去に岡崎市中央図書館事件というものがあり、この事件では、約1秒1アクセス程度という頻度にも関わらず、実際に閲覧障害が発生したという事情から、偽計業務妨害容疑で逮捕されている（業務妨害の強い意図が認められないとして、後に起訴猶予処分となった）。 その他 ログインしないと閲覧できないサイトへのスクレイピングは、相当リスクが上がる。 利用規約違反の認定が容易となるし、ログイン認証の突破は、不正アクセス禁止法違反ともなり得る。 またWebサイトには、検索エンジンクローラーに対し、Webサイト内のどのページをクロールしてよいか/拒否すべきかを指示するテキストファイルとして「robots.txt」というものがある。 このrobots.txt自体は、法的拘束力を持つものではない。 ただし、サイト運営者の明確な意思表示と評価されるため、これを無視すると後の紛争で不利に働く可能性がある。 実務的な安全ライン 最後に、スクレイピングを検討する際の実務上の対応策を整理しておく。 利用規約でスクレイピング行為が禁止されていれば避ける 公式APIがあればそちらを利用する（API利用規約にも注意） ログイン不要な公開情報のみをスクレイピング対象にする アクセス頻度を厳格に制御する 個人情報は原則扱わない（収集した場合は適切に加工・削除） 取得データはそのまま公開しない robots.txtを尊重する 利用規約の章でも述べた通り、利用規約でスクレイピングを禁止する旨が記載されている場合は、米国地裁の判断があるとはいえ、公開情報であろうとグレーゾーンと考えて避けた方が安全だと思う（公開情報は明確に除外する旨が規定されていれば別だが）。

それほど需要は高くないだろうが、企業によっては、創業者や社長の氏名を冠した製品やサービスを提供する可能性はゼロではないと思う。 このとき、社長等の氏名を付した製品・サービス名を商標登録する必要があるのかについて考えてみたい。 なお冒頭に変な画像を載せておいて何だが、この記事では決して氏名を付した商標登録出願を止めるよう促すものではないので、そこは理解いただけるとありがたい。 商標登録の目的 商標登録をする目的としては、 第三者の使用を排除：第三者による同一・類似範囲での商標使用の排除 第三者による商標登録排除：他社に同じ商標を登録された場合に、後から自分の商標が使えなくなるリスクを回避 が挙げられるところ、「2. 第三者による商標登録排除」という観点で言えば、あえて商標登録する必要性は低い。 次のパートで理由を説明したい。 他社が商標登録できる可能性は非常に低い そもそも他人の氏名を登録するには、以下の「商標法4条1項8号」という高いハードルがある。 （商標登録を受けることができない商標） 第四条　次に掲げる商標については、前条の規定にかかわらず、商標登録を受けることができない。 八　他人の肖像若しくは他人の氏名（商標の使用をする商品又は役務の分野において需要者の間に広く認識されている氏名に限る。）若しくは名称若しくは著名な雅号、芸名若しくは筆名若しくはこれらの著名な略称を含む商標（その他人の承諾を得ているものを除く。）又は他人の氏名を含む商標であつて、政令で定める要件に該当しないもの この条文を整理すると、以下の図のようになる。 ここで、自社とは無関係の他社が、自社の社長の氏名について商標登録できるかというと、少なくとも以下の政令要件を満たす必要がある。 社長と他社との間に相当の関連性（例：社長と他社がライセンス契約を結んでいる）があり、かつ 商標登録が不正目的（例：他人への嫌がらせの目的、先取りして商標を買い取らせる目的）でない このように関連性等の要件が立ち塞がることから、他社が勝手に商標登録するリスクは極めて低いというわけである。 なお、自社が出願人であれば、創業者や代表者とは相当の関連性が認められることとなる。 それでも登録した方が良い？ では商標登録しないと「1. 第三者の使用を排除」ができないのでは？というと、確かにその通りではある。 一方、もしその氏名が著名であれば、著名人のパブリシティ権（法律上明示的に認められた権利ではなく、人格権に由来する権利として裁判例上認められてきた権利）の侵害や、不正競争防止法違反となる可能性もある。 このため、社長の氏名がどれだけ周知かにもよるが、商標登録が無かったとしても、他社が勝手に使用する場合には一定の抑制力が働くこととなる。 また商標登録しておくと、登録の事実を公表することでブランドの信頼性をアピールできるし、ライセンス契約によって他社に有償で使用させることも可能となる。 後は、社長の自己顕示欲を満たすことができる・・・かもしれない。 商標登録には以下の通り出願・登録費用がかかるので、本当に必要だと思ったものに対して出願すべきであることは間違いない。 項目 金額 出願料 3,400円＋（区分数×8,600円） 登録料 区分数×32,900円（10年毎にかかる） ※2026年3月20日時点の費用 ※中間処理含めた特許事務所の手数料は除く

個人情報保護法では、原則として、利用目的の通知またはHP上等での公表を行っておけば、個人情報取得・利用の際の本人同意は不要である。 一方、以下の行為を行う場合は本人の同意を得る必要がある。 個人情報の目的外利用（18条1項） 要配慮個人情報（病歴や犯罪歴など）の取得（20条2項） 第三者提供（27条1項） 例えば、利用目的に自社製品開発を記載していなかったものの、取得した個人情報を自社のAIモデルの学習用データとして流用したくなった場合は、本人同意が必要となる。 また、学習用データに使うため、他企業が取得した個人情報を提供してもらう場合も、本人同意が必要となる。 しかし、既に個人情報を取得した後、各個人に同意を取りに行くのは正直現実的ではない。 ところで、個人情報保護委員会は2026年1月9日に「個人情報保護法の改正方針（案）」を公表した。 この改正が、AIモデル開発企業にとっては朗報となるかもしれない。 統計情報等の作成なら同意取得不要 上記の通り、第三者提供等の場合は本人の同意が必要である。 例外として学術研究目的の場合は本人の同意を取得しなくて良いところ、改正方針ではこれが更に緩和する動きとなる。 具体的には、第三者提供及び公開されている要配慮個人情報の取得について、統計情報等の作成にのみ利用される場合は、本人同意を不要とするとのことである。 ここで注目すべきは、統計情報等の作成には、統計情報等の作成と整理できるAI開発等も含むという点である。 これまでは、あらかじめ公表した目的にAI開発に用いる旨が記載されてなければ同意取得が必要であったし、仮に記載があっても個人情報を第三者に提供する場合は別途同意取得が必要であった。 第三者提供の場合は、同意取得を避けるためAI開発業務を委託するという形を取るスキームもあったが、契約などの検討コストが馬鹿にならない。 しかし、 統計情報等の作成のために複数の事業者が持つデータを共有し横断的に解析するニーズが高まっている 特定の個人との対応関係が排斥された統計情報等の作成や利用はこれによって個人の権利利益を侵害するおそれが少ない という背景から、統計情報等の作成等（AI開発含む）に限るなら、本人の同意がなくても利用・第三者提供を可能にしよう、というわけである。 また、AIモデルのユーザ企業としても、入力したプロンプトに個人情報が含まれたとしても、プロンプトをモデル学習に利用する規約となっている生成AIサービスを利用する際に同意取得する必要が無くなる。 ###同意不要となる条件 ただ手放しでOKではなく、「統計情報等の作成」にのみ利用される場合は、それを担保するための規律として、以下の条件を課すよう検討されている。 一定の事項の公表 氏名・名称（要配慮個人情報取得なら取得者、第三者提供なら提供元・提供先） 行おうとする「統計情報等の作成等」の内容等 第三者提供の場合は、「統計情報等の作成」のみを目的とした提供である旨の書面による提供元・提供先間の合意 取得者及び提供先による、目的外の利用及び第三者提供の禁止（要配慮個人情報取得、第三者提供） 等 Webスクレイピングにも適用 改正方針が適用されれば、AIモデルの学習用データをWeb上から収集する際に要配慮個人情報を取得する場合も同意取得が不要となり、学習用データが収集しやすくなると考えられる。 なお、Webスクレイピングで収集した場合も上に述べた条件を満たす必要があるので、どのような統計を作成するかを公表したり、複数企業の個人データを集めて統計分析を行う場合は、両社間の合意内容を公表させ第三者が検証できるようにする、といった運用が想定される。 ソフトウェア開発企業にとっては朗報 仮にこの改正方針が採用されれば、個人情報を使ったAIモデル開発の自由度が高まるため、ソフトウェア企業にとっては嬉しいニュースとなるだろう。 もちろん、情報の活用にあたってはその他知財権の侵害も避ける必要があるが、例えば学習モデルとしての利用であれば、著作権法上は問題ないとされている（著作権法第30条の4）。 個人的には、今回の改正方針が過去に取得された個人情報の取り扱いについても効力が及ぶかという点は気になるところである。 通常、取得時期ごとに取り扱いが異なると管理が非常にに煩雑になるはずなので、過去取得済みの個人情報についても適用されるものと考えられるが、改正に関する情報は引き続きウォッチしておきたい。 Webスクレイピングについては個人情報保護法以外にも考えるべき点（取得先サービスの利用規約など）が色々あるが、それはまた別の記事で検討することとしたい。

知財部に所属していると、先に出願した日本語明細書をベースに米国、欧州、中国へ外国出願を検討することは多いと思う。 ここでは備忘録として、特にソフトウェア発明について主要外国（米国、欧州、中国）向けのクレームや明細書を準備する際の留意点を整理しておきたい。 ただし、外国向け明細書に新規事項を追加することはできないため、日本語明細書作成の時点で「技術的課題」「技術的手段」「技術的効果」といった情報はしっかり記載するとともに、クレームで上位概念化した発明の実施形態となるものを複数記載しておくことが理想的である。 米国 MPF対策として、クレームで「means」表現は避け、代わりに「one or more processors configured to」と記載する。 「module」「unit」「device」も、できるだけ避ける。「processor」の部分を「processing circuitry」としてもよい。 それでも、極力112条 (f)が適用されないよう、processorが機能を実行するための構造で修飾されるようにする。 プログラムクレームは「コンピュータ読み取り可能な不揮発性記録媒体（non-transitory computer-readable medium）」クレームに変更する。 明細書では、先行技術（Prior Art）ではなく、関連技術（Related Art）という表現を用いるとともに、具体例を挙げすぎないようにする。 先行技術（Prior Art）は「自認先行技術（Admitted Prior Art）」とみなされ、審査で拒絶理由に使われるリスクがある。 ただし、あまりに記載が不足すると、解決したい課題が不明確となり、101条対応（クレームが上の司法例外を含んでいても、追加の要素が司法例外を実用的な応用に統合している、等の主張）が困難となる点は注意。 ジェプソンクレーム（～において）は、Preamble部分が本発明を限定したり、自認した先行技術として扱われる可能性があるため、避ける。 ソフトウェア関連は、101条違反となることが多い。クレームそのものへの手当ては不要だが、明細書で反論できる情報をあらかじめ入れておくこと。詳細は以下の記事の通り。 米国特許法101条（特許適格性） 米国への特許出願では、101条について悩まされている人は多いだろう。 自分もその一人だ。 ここで備忘録として、101条違反を回避するための対... EPO 原則、１カテゴリ（物、方法、使用）あたり１独立クレームとすること。 記録媒体クレームやプログラムクレームを設けてもOKだが、技術的な性質が認められることが必要。 コンピュータの内部処理を超えた技術的効果（CPU負荷低減、データ転送効率、センサ処理改善など）を明細書に記載すること（クレームに記載する必要はない）。 GUIに関する発明については、単なるレイアウトや表示方法に過ぎない場合はNGだが、ユーザー操作の技術的支援といった技術的貢献があれば特許となり得る。 マルチマルチクレームはOK。 中国 物品の一種であることを明確にするために、「プログラム」クレームを「プログラム製品」クレームに変更すること。 記載要件（サポート要件）に非常に厳格。クレームに記載した抽象的なステップに対し、明細書で十分な具体的アルゴリズムやフローチャートを提示すること。 明細書では、「技術的課題」「技術的手段」「技術的効果」の三者を一貫させること。 クレームカテゴリ 国 装置 方法 プログラム US ○ ○ ×（non-transitory computer-readable mediumなら○） EPO ○ ○ 技術的性質が認められれれば○ CN ○ ○ ×（プログラム製品クレームなら○） クレーム数/従属クレーム 国 独立クレーム数 総クレーム数 マルチクレーム マルチマルチクレーム US 3まで無料 20まで無料 ○（追加料金発生） × EPO 原則1カテゴリ1独立クレーム 15まで無料 ○ ○ CN 総クレーム数に収まれば○ 10まで無料 ○ 原則×

委託業務において、成果物に係る特許権・著作権等の知財権を委託元が取得する場面は多い。 権利を取得すること自体は別に良いのだが、その召し上げ方や交渉過程によっては、以下の関連法令上問題となる可能性がある。 優越的地位の濫用（独禁法２条９項） 不当な経済上の利益の提供要請（取適法５条２項２号） 以下、受託者からの知財権取得に関する基本的な考え方を整理してみたい。 優越的地位の濫用 独占禁止法では、取引上「優越的地位」にある事業者が、その地位を利用して「濫用行為」をすることを禁止している。 優越的地位の要件 優越的地位とは、取引を打ち切られると相手方の事業運営に重大な支障が生じるため、こちらが相手方にとって著しく不利益な要請等を行っても受け入れざるを得ない状態を指す。 自分から見たとき、「相手が自分と取引する際の依存度」「自らの市場における地位」「相手にとっての取引先変更の容易性」「自分と取引することの必要性」等を総合考慮するとされているが、後述の通り重要なのは「濫用行為」があったかどうかである。 濫用行為の判断基準 濫用行為とは、取引の相手方に対し、その地位を利用して、正常な商慣習に照らし不当に不利益を与える行為のことを指す。 濫用行為に該当するかは、以下の点を考慮する。 相手方にあらかじめ計算できない不利益かどうか 直接の利益を勘案し合理的範囲を超えた負担かどうか 事前に不利益が分からないくらい雑な交渉で条件が決まっていたり、あらかじめ計算できたとしても経済的合理性を超えた負担を強いられる場合は濫用行為となる。 大事なのは、濫用行為があったかどうか 上記の通り、形式的には優越ガイドラインでは 優越的地位の有無 濫用行為の有無 が要件となっている。 だが公正取引委員会の審査実務では、「濫用行為があったのに経済合理性の無い要求を飲んでいるなら、優先的地位はあったよね？」との推認がなされている。 つまり、濫用行為が認定されれば、優越的地位もあったと推認されるということである。 濫用行為の有無を把握せず、「優越的地位が無いからセーフでしょ」と判断するのは、リスキーと言わざるを得ない。 知財に関する濫用行為 では、情報成果物の知財権に関してどんな行為が濫用行為になるのか？というと、以下のような一方的な取り扱いが該当する（公正取引委員会のHPから引用しただけだが）。 情報成果物の権利の譲渡 本来は受託者に帰属する著作権・特許権等を、委託取引で作成されたことや費用負担を理由に、一方的に譲渡させること 二次利用収益の配分を条件に譲渡させたにもかかわらず、委託者が合理的理由なく二次利用を認めないこと 情報成果物の二次利用の制限等 委託者に権利がないのに、権利があると主張して二次利用条件や収益配分を一方的に決めること 費用負担等を理由に、受託者の二次利用を一方的に制限すること 二次利用収益を前提に委託したにもかかわらず、合理的理由なく二次利用を拒否すること 受託者が情報成果物を作成する過程で発生した取引対象外の成果物等の権利の譲渡及び二次利用の制限等 開発過程で生じた取引対象外の成果物や技術についても、委託者が上記1や2と同様の行為を行うこと 不当な経済上の利益の提供要請（取適法５条２項２号） 冒頭にも紹介の通り、独占禁止法のほか、取適法上問題となる行為についても取り上げておく。 取適法は資本金基準または従業員基準を満たす事業者間の取引を対象としており、11の禁止事項を掲げている点は以下の記事で紹介している通りである。 発注前の作業依頼や取引額の減額は常に問題？ 2026年1月より、下請法（下請代金支払遅延等防止法）が取適法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律... 知財権に関する問題行為は、この11の禁止事項の１つの「不当な経済上の利益の提供要請」に該当する場合がある。 例えば、以下のような行為は、同号に該当する可能性がある。 受託者の知財権を、作成目的たる使用の範囲を超えて、無償で譲渡又は許諾させること 二次利用の制限や収益配分割合を一方的に決定すること 発注時に合意されていなかった知財権を含む技術資料を無償で提供させること 関連法に違反しないために 独禁法、取適法に違反しないためには、契約締結前に 委託者がどの範囲の知財権を取得するのか（成果物に関する知財権だけでなく、委託業務の過程で生じるものも含まれるのか） 受託者の二次利用をどこまで制限するのか を明示したうえで価格交渉を行うこと、そして合意した権利条件（知財権の譲渡等）を前提として見積額を提示してもらい、発注することが不可欠である。 ここでは、契約書に記載のない権利の追加要求をしないようにするのは勿論のこと、委託者と受託者との間に認識の齟齬があったが故に、契約上明確に整理されていなかった権利範囲について、後から一方的に拡張的解釈を主張するといった後出しジャンケンをしないことが重要となる。 「権利取得の範囲」と「対価」とはセットで設計することとなるので、仮に全ての知財権を受託者から召し上げるのであれば、先方からの価格要請にはある程度応じる必要も出てくるかと思う。

この記事では、たまにソフトウェア開発者から問い合わせのある「DockerとGPLライセンスの関係」について整理してみたいが、その前置きとして「Dockerって何なの？」という点を噛み砕いて説明しておきたい。 Dockerとは Dockerとは、ソフトウェアの実行環境をDockerイメージとしてパッケージ化して配布し、そのイメージから「コンテナ」と呼ばれる実行環境を起動できる仕組みである。 通常、ソフトウェアを動かすためには OS ライブラリ 依存パッケージ アプリケーション本体 といった複数の要素を正しくインストールする必要があるが、この環境構築はかなり面倒である。 OSが違う、依存パッケージが足りない、といった場合だけでなく、ライブラリのバージョンが違うといった理由でも動かないという問題が起きやすい。 Dockerは、この問題を解決するためにアプリケーションとその実行環境を丸ごとパッケージ化するというわけである。 ここで顧客への配布形態として登場するのが、DockerfileとDockerイメージという概念である。 Dockerfileとは Dockerfileとは、コンテナを作るための手順を記載したファイルである。 いわば「コンテナのレシピ」のようなものであり、どのOSを使い、どのパッケージをインストールし、どのアプリを配置するかを記述する。 Dockerfile自体は、あくまでビルド手順を記述したテキストファイルにすぎない。 Dockerイメージとは Dockerfileを実行して作成されるのがDockerイメージである。 Dockerイメージは、OS、ライブラリ、アプリケーション など（開発環境を含めたアプリケーション一式）を含んだ完成済みのソフトウェア環境である。 これを配布すれば、受け取った側は一から開発環境を整える必要なく「コンテナ」としてソフトウェアを動かすことができる。 このようにDockerは、ソフトウェア配布を非常に便利にする技術である。 しかしその一方で、GPLソフトウェアが含まれている場合のライセンス関係が問題になることがある。 以下では、DockerとGPLの関係を整理する。 DockerとGPLライセンスとの関係 DockerfileやDockerイメージを配布する場合、パッケージな中にGPLソフトウェアが含まれているとライセンス義務が発生するのではないか、という点が問題になる。 結論から言えば、以下の整理になる。 条件 GPL義務 Dockerfileのみを配布する場合 GPL義務は基本的に発生しない Dockerイメージを配布する場 GPLソフトと自社ソフトが単なる集積（aggregation） 自社ソフトの開示義務なし GPLソフトと自社ソフトがリンクして一体のプログラム 自社ソフトにもGPL義務が及ぶ可能性あり 以下、それぞれ説明する。 Dockerfileを配布するだけの場合 Dockerfileは、コンテナイメージを作成するためのビルド手順書にすぎない。 このDockerfileにはGPLプログラムそのものは含まれておらず、単に「ビルド時に取得する」という指示が書かれているだけである。 この場合、配布しているのはあくまでビルド手順であり、GPLプログラムそのものを配布しているわけではない。 したがって、通常はGPLのソースコード提供義務は発生しない。 Dockerイメージを配布する場合 一方、Dockerイメージをそのまま配布する場合は事情が異なる。 Dockerイメージは、内部にOS、ライブラリ、アプリケーションなどを含む実体のあるソフトウェアパッケージである。 そのため、配布物にGPLプログラムが含まれていれば、そのGPL部分についてはライセンス義務が発生する。 ただし、ここで重要になるのが 「単なる集積」かどうかである。 単なる集積の場合 例えば、Dockerイメージの中にGPLライセンスのLinuxツールと自社開発のアプリケーションが入っていたとしても、両者が独立して動作するだけなら、これはGPL上の「単なる集積」に該当する可能性が高い。 この場合、GPL部分のソースコード提供義務はあるが、自社のプロプリエタリコードを公開する必要はない、という整理になる。 リンクしている場合 問題になるのは、自社プログラムがGPLプログラムとリンクしている場合である。 この場合、そのプログラムはGPLソフトウェアの派生物と評価される可能性がある。 その結果、プログラム全体がGPLの条件に従う必要が生じ、自社プログラムのソースコードに対しても開示義務が発生する、というリスクが生じる。 ポイント Dockerイメージの配布の場合は通常のソフトウェア配布の判断と相違ないが、ポイントとなるのは、いわゆるレシピに相当するDockerfileのみの配布であれば、Dockerイメージ内にGPLソフトウェアを含んでもDockerイメージ内のソフトウェアのGPL義務を免れるという点である。 もちろん、Dockerfile自身にOSSライセンスが含まれれば、それに遵守する必要はあるが、それはDockerイメージ内のソフトウェアのライセンスは別問題である。