Posts

EUで商標登録出願を行うには、直接出願かマドプロ経由での出願が必要となるところ、各国に対して個別に出願するだけでなく、EUTM制度（欧州連合商標）による出願を行うことができる。 EUTM制度とは EUTM制度とは、EU全域に効力が及ぶ単一の商標登録をすることができる制度である。 かつては欧州共同体商標（CTM）と呼ばれていたが、2016年3月に改称されている。 EUTMのメリット EU加盟27か国のすべてで個別に権利化し、更新する場合に比べると、大きな経済的メリットが得られる。 もし国毎に登録しても、１ヵ国あたりEUTMの半額程度の費用は必要なケースがあるので、EUTMはかなり費用を浮かせられることとなる。 また、更新手続きも１度で済むのが嬉しい。 欧州統一特許（Unitary Patent）と似たメリットではあるが、特許の場合は最低３～４か国で権利化しないと費用面のメリットが得られないので、経済的メリットはより大きいといえるかもしれない。 べルギー、オランダ、ルクセンブルクについては、個々の国へ直接出願することはできず、ベネルクス商標登録出願という手続きを踏む必要があるのだが、EUTMであればこの３国についてもカバーされる。 さらに、５年間商標を不使用の場合は取り消される可能性があるところ、EUTMの場合はEU加盟27か国のどこか１国で商標を使用していれば、不使用取消を免れられる。 なお要件を満たせば、マドプロを利用してEUTM出願をすることも可能である。 EUTMのデメリット EUTMは一体不可分の権利なので、EU加盟国の一部のみを選択して出願することはできない。 したがって、１国で拒絶理由があった場合は全体で拒絶されるし、異議申立を受ける可能性も高まる点は注意である。 この辺りは、マドプロ出願でいうセントラルアタックのリスクと近い概念となる。 例えば、商標が加盟国のどこかの言語でその商品の一般名称となっていれば、その名称が他の加盟国では知られていない商標でも、拒絶されることとなる。 また、これは正確にはデメリットではないが、EU非加盟国、例えば英国について権利化したい場合は別途個別に出願する必要が生じる点は注意が必要である。 EU加盟国でも一部の地域に権利を及ばすことはできない デンマーク王国はデンマーク本国、フェロー諸島、そしてグリーンランドの３つの地域で構成される。 ここで注意したいのは、デンマークはEU加盟国ではあるにもかかわらず、EUTMがフェロー諸島とグリーンランドには適用されない点である。 もしこれらの地域にも商標権の保護を及ばせたいのであれば、デンマーク王国全体を統括するデンマーク特許商標庁を通じた手続きが必要となる。 イタリアでも同様の話があり、EUTMはサンマリノ共和国やバチカン市国では有効ではないが、イタリアとの特別な条約により、イタリア国内商標庁に商標登録出願をすればサンマリノ共和国やバチカン市国でも保護される。 したがって、これらの地域にまで商標権の保護を及ばせるのであれば、デンマークやイタリアへ直接出願することが求められる。 しかし、今後グリーンランドについてはデンマークの自治領であり続けるかは不透明かもしれないが…

細かい話になるかもしれないが、特許のクレームを英語に翻訳するとき、「○○の数」という表現をどう英語に翻訳すべきだろうか？ 選択肢としては、 a number of ○○ the number of ○○ が挙げられる。 「a number of」は「複数の」「多数の」と解釈されうるため「the number of」とすべき、という意見もあれば、初出で「the number of」と用いるのは適切でないため、「a number of」とすべき、という意見もある。 本来の英語としては、「複数の」ではなく「○○の数」であることを明確化するという観点では、「the number of」と記載するのが正しいようにも思われる。 中学校でも、そのように習ったのではないだろうか。 しかし、米国の審査官によっては「初出の単語にtheという定冠詞を設けるのは不適切。初回はaを使いなさい」と反射的にObjectionを出すことも多い印象である。 そんな審査官に対して「いや、これは数を表すのでtheとすべきです」と意見書で反論を試みることも可能だが、現実としては審査官がObjectionを維持する可能性が大いにあり得る。 ただ、それで権利解釈に大きな影響があるかというと、明細書の中で合理的に解釈すれば「a number of ○○」が「○○の数」を意味するようになっていれば、別に問題にはならないと考えられる。 実際、USPTOの審査官が審査手続を進めるための審査基準（MPEP 2111）でも、クレームの文言そのものだけでなく、明細書全体（詳細な説明、図面など）を参照して「当業者（person having ordinary skill in the art）」が理解するであろう最も広く合理的な意味で解釈されるとしている。 これらの事情を考慮すると、個人的には、初回は「a number of」を、それ以降は「the number of」と表現すれば問題ないと思う。 因みに、「a number of」を「複数の（２つ以上を全て包含する形）」という意味で用いることもあるだろうが、「多数の」と解釈されうる（権利範囲が狭く解釈される）リスクを考慮すると、実務上は「a plurality of」と表現することが多いと考えられる。

2026年1月より、下請法（下請代金支払遅延等防止法）が取適法（製造委託等に係る中小受託事業者に対する代金の支払の遅延等の防止に関する法律）という法律に変更される。 気になったので、改めてどんな内容の法律で、委託業務での注意点をメモにしてみた。 適用対象取引 対象となる取引は、取引の内容と、委託者/受託者の資本金基準または従業員基準によって決定される。 資本金基準または従業員基準については、いずれかの基準に該当すれば適用対象となる。 なお、取適法では新たに従業員基準が設けられるとともに、適用対象となる取引の内容に「特定運送委託（製造等の目的物の引渡しに必要な運送の委託）」が追加されたことで、規制及び保護の対象が拡充されている。 具体的には、以下の通りである。 「製造委託」「修理委託」「特定運送委託」「情報成果物作成委託」「役務提供委託（プログラム作成、運送、物品の倉庫における保管、情報処理に限る）」 委託事業者 中小受託事業者 資本金３億円超 資本金３億円以下 資本金１千万円～３億円 資本金１千万円以下 従業員300人超 従業員300人以下 「情報成果物作成委託」「役務提供委託」（プログラム作成、運送、物品の倉庫における保管、情報処理を除く） 委託事業者 中小受託事業者 資本金５千万円超 資本金５千万円以下 資本金１千万円～５千万円 資本金１千万円以下 従業員100人超 従業員100人以下 義務・禁止事項 委託事業者には、４つの義務と１１の禁止事項が課されている。 ４つの義務 発注書面の交付（発注内容を書面または電子メール等の電気的方法により明示） 書類の作成・保存義務（取引記録を電磁的記録等として２年間保存する） 支払期日を定める義務（成果物の受領日から60日以内に支払期日を定める） 遅延利息の支払義務（遅延日数に応じ、年率14.6%の利息を支払う） １１の禁止事項 受領拒否 支払遅延（手形等での支払い手段もNG） 減額 不当返品 買いたたき 購入・利用強制 報復措置 有償支給原材料等の対価の早期決済 不当な経済上の利益の提供要請 不当な給付内容の変更、やり直し 協議に応じない一方的な代金決定（※） ※取適法で新たに追加 発注前の作業依頼は違法？ ところで、委託業務の内容に齟齬が生じないよう、まずは委託予定の企業にサンプルケースを提示し、そのケースを処理してもらった上でその成果物を確認し、それがOKなら正式に委託する、というプロセスを踏むことがあり得る。 その場合は、サンプルケースで行った具体的な作業内容を踏まえて委託予定の企業に見積書を作成してもらうこととなるであろう。 このような発注前の作業は、発注書面の交付義務に違反することとなるだろうか？ こちらについては、サンプルケースの処理が委託業務内容の把握や見積書の作成に必要な行為であれば、問題ない ただし、その内容が実質的に先行して委託業務を行っているとみなされないように注意する必要がある。 特に、その作業から生じたサンプル成果物を、本当の成果物の一部として委託元が取り扱わないようにするよう気を付けておきたい。 委託元からすれば、「せっかくなら、本チャンのケースをやってもらおうかな」と考えるところではあるのだが。 取引内容の見直しによる減額は違法？ 発注後、社内事情により急遽成果物が不要となったり、計画が大幅に変更となることで、委託していた業務を中止することがあるかと思う。 このとき、残りの業務を中止する代わりに、支払い費用を減額するのは取適法違反となるだろうか？ 結論から言うと、不当な減額とならないよう委託先と合意形成がなされていれば問題ない（メール等で合意形成した場合であっても、ちゃんと証拠資料として保存しておきたい）。 例えば、委託先が業務１→業務２という順番で遂行する予定だったとき、業務１まで完了した段階で委託元が中止を求めたとする。 その場合は、業務１に要した工数等を踏まえて算定した対価を支払えば良い。 見積書でそれぞれの内訳が記載されていればその金額を支払うことが考えられるが、そんなに都合よく見積もりを取っていないこともあるので、その場合は客観的に見て不自然でない程度の金額にするよう協議で定めていくことになるのではないかと思う。 もし、委託元が業務２まで遂行することを見込んで当初の業務１の対価を相場より安く見積もっていた場合は、委託先側で業務２が中止となった事情を踏まえて、もう少し高い対価を請求してもらうことがベターかと思われる。

自社のソフトウェアをユーザーに販売・ライセンスする上で利用規約を定める際、不正コピー、リバースエンジニアリング、等といった事項を禁止行為とすることが多いと思う。 ここで、提供するソフトウェアがAIモデルの場合は、更に考慮すべき事項として、欧州AI法（EU Artificial Intelligence Act）が挙げられる。 これは世界初となるAIの開発や運用を包括的に規制する法律（2024年5月21日に成立し、8月1日に発効）であり、AIをリスクの程度で分類し、その程度に応じた規制を適用するものとなる。 具体的には、AIシステムは次の4段階に分類され、最上位の「容認できないリスク」に該当するAIシステムは禁止される。 分類 詳細 規制内容 容認できないリスク（Unacceptable risk） 人々の安全、生活、基本的人権に対する明白な脅威となるもの 禁止 高リスク（High risk） 人々の健康、安全、基本的人権に重大なリスクをもたらす可能性のあるもの 厳しい手続きの義務付け 限定的リスク（Limited risk） AI利用における透明性が欠如するもの 生成AIによるコンテンツであることを明示 最小のリスク（Minimal risk） リスクが最小限またはリスクなしとみなされる 自由に利用可能 特に「容認できないリスク」には倫理的なものが多分に含まれるため、欧州では勿論のこと、欧州以外の国に販売する場合であっても、欧州AI法で定める容認できないリスクとなる使い方を禁止するよう利用規約に定めておくのが個人的には安全かと思う。 以下、長文にはなるが、「容認できないリスク」について自分なりにまとめたものを掲載する。 世の中にはChatGPTやGeminiをはじめとする様々なAIツールがあるが、皆これらを遵守するよう出力を制御するのにかなりの気を遣っているのだろう。 欧州AI法における「容認できないリスク」は原則禁止 上述の通り、欧州では「容認できないリスク」に該当するAIシステムは禁止されており、具体的な禁止行為は以下の通りとなる。 概要だけ知りたければここだけ見てもらえば良いが各項目の詳細が気になるなら、以降にも目を通してみて欲しい。 禁止行為 内容 有害な操作と欺瞞 視覚・聴覚・その他の刺激を利用して、本人が気づかないうちに判断を歪め、重大な不利益を与える使い方 脆弱層への悪用 子供、高齢者、障害のある人、経済的弱者などの脆弱性につけ込み、行動や判断を誘導して害を与える使い方 社会的信用スコアリング 個人の行動や推測された性格などから「スコア」を作り、公共サービス・待遇・権利に不利益を与えるような運用 犯罪予測のためのリスク評価 住所、年齢、国籍、婚姻状況などの属性情報だけから「犯罪を起こしそう」と判断すること 顔認識データベースの無差別収集 インターネットや監視映像から、本人の同意なく人の顔を収集・学習・照合する行為 職場・教育現場での感情推定 従業員や学生の「感情」を読み取り、監視・評価・選抜に利用すること 生体情報によるセンシティブ属性の推定 顔・声・歩き方などから、人種、宗教、政治的意見、性的指向などを推測・分類すること 公共空間での「リアルタイム」遠隔生体認証 公共の場で、リアルタイムに個人を特定する 有害な操作と欺瞞（Article5(1)(a)） サブリミナル操作や、意図的に人を欺く・操作するAIを使って、人の判断力を損なわせ、本人が本来取らなかったであろう行動を取らせて重大な害を与える使い方は禁止される。 禁止される具体例 視覚的サブリミナル：意識的には認識できないほど短時間に画像や文字を表示 聴覚的サブリミナル：他の音に紛れる、または非常に小さい音量でメッセージを流す 触覚的サブリミナル：人が気づかない程度の刺激で感情や行動を左右する 不可知刺激：人間の感覚では全く検知できないレベルの刺激（高速の点滅や可聴範囲外の音）の使用 例えば、広告で潜在的に購買行動を誘導し、経済的損失を与えるようなものは良くない、ということである。 禁止されない具体例 サブリミナル療法で喫煙などの悪習慣を断つよう促す治療用チャットボット ユーザーの感情を推測し、抑うつ的な楽曲への過度な接触を回避する音楽サービス 教育目的でフィッシング攻撃を模倣するために用いられる、AIを活用した欺瞞的手法 このように、サブリミナル操作であっても、それがユーザーの利益に繋がる場合は例外的に認められる。 脆弱層への悪用（Article5(1)(b)） 年齢、障害、社会的・経済的弱者などの脆弱性を利用して、その人や集団の行動を歪め、重大な害を及ぼす使い方は禁止される。 禁止される具体例 子供に対し、高い棚の探索、鋭利な物体の取り扱いなど、次第に危険度を増す課題を達成するよう促す対話型AI 高齢者の認知能力の低下を悪用し、欺瞞的な個別対応型オファーや詐欺を仕掛けるAI 精神障害を持つ人々に対し、高額な医療製品の購入を促す治療用チャットボット 深刻な財政状況にある人々を標的に、搾取的な金融商品の広告を配信するAIシステム 社会的信用スコアリング（Article5(1)(c)） 個人の行動や推定された人格特性に基づいてスコア化し、そのスコアをもとに不当・不均衡な扱いをすることは禁止される。 禁止される具体例 所得・資産に関係のないネット利用等のデータを使い、特定個人を納税の重点調査対象にすること 配偶者の国籍、SNS行動、職場評価など無関係な情報をもとに不正給付リスクを推定すること 婚姻状況など、必要性と無関係な情報を使って失業支援の判断を行うこと 「リスク家庭」判断で、社会的行動データや軽微な違反まで用いて過剰な介入につなげること 住民の社会的行動（ゴミ出し違反、図書返却遅れなど）から「信頼スコア」を作り、監視強化すること 保険会社が適正判断と無関係な銀行の財務情報を収集し、保険料率に利用すること 住宅ローン審査で、信用判断に無関係な個人特性をAIで利用すること 禁止されない具体例 金融的に関連する収入・支出・債務情報を使った公平な信用評価 サービス関連の取引履歴やメタデータによる詐欺リスク評価（不利益が詐欺行為に比例して正当化される場合は問題なし） 運転データに基づく保険料の調整（プレミアム増額が運転リスクに比例していれば適法） 診断に必要な健康データを使う行為（不当な差別的取扱いを伴わなければ適法） プラットフォームの安全確保のため、コンテキストに関連するデータを使ってユーザー行動を評価（処分が行為の重大性に比例していれば合法） ユーザーの嗜好など適切なデータに基づき、消費者保護・データ保護法に従って行う広告（不当な価格差別などがなければ対象外） 難民キャンプで、再定住や雇用判断のため、目的に関連する行動データを使用する場合（移民法上の手続が守られ、比例的な扱いであれば合法） ECサイトの購入履歴や等に基づき、特典を付与（他者に不当な不利益を与えなければ問題なし） 犯罪防止・捜査目的で、関連する社会行動データを利用する場合（法に基づき、正当かつ比例的な扱いなら適法） 犯罪予測のためのリスク評価（Article5(1)(d)） 個人の性格や特徴の分析だけに基づいて、「この人が犯罪を犯す可能性がある」と予測する行為は禁止される。 ただし、既に犯罪活動に関する客観的事実がある場合に、それを補助するAIは例外となる。 禁止される具体例 ある法執行機関がAIシステムを使い、個人の年齢、国籍、住所、車の種類、婚姻状況といった特性のみに基づいて、テロリズムなどの犯罪行為を予測する行為 国税当局がAI予測ツールを用いて全納税者の申告書を審査し、二重国籍、出生地、子供の数といった性格特性から潜在的な脱税犯罪を予測して追加調査が必要な事例を特定する行為 禁止されない具体例 個人ではなく「場所」や「地域」に基づく予測 過去の犯罪発生率や地図情報などを分析し、地域ごとに侵入盗・刃物犯罪などの発生確率スコアを算出 既知の密輸経路などを基にAIが違法薬物や物品の所在可能性を予測 都市部に設置した音響センサーで銃声をリアルタイム検出し、発砲地点を特定 顔認識データベースの無差別収集（Article5(1)(e)） インターネットや監視カメラから無差別に顔画像をスクレイピングして顔認識データベースを作成・拡張する行為は禁止される。 禁止される具体例 企業が自動画像スクレイピングツールを使って、SNSから人の顔を含む写真を収集 画像の出典URL、位置情報、名前などの付随データも同時に取得 顔の特徴量を抽出し、数値化・ハッシュ化してデータベース化 ユーザーが他人の写真をアップロードすると、その画像を変換してデータベース内の顔と照合できる仕組み 職場・教育現場での感情推定（Article5(1)(f)） 職場や教育機関で、人の感情を推定する行為は禁止される。 ただし、医療目的や安全確保のための利用は例外。 禁止される具体例 顧客に対して不幸せ、悲しみ、怒りを感じていると（例えば、身振り、眉をひそめる、笑顔の欠如などから）推論するシステム 声や身体動作から学生が激怒し暴力的になりそうだと推論するシステム 禁止されない具体例 人が病気かどうかを特定すること ニュースキャスターがカメラに向かって笑顔を見せる回数を追跡する装置をテレビ局が使用すること 事故防止のためプロのパイロットや運転手の疲労をAI認識システムで推論し、休憩を促すこと（感情認識には痛みや疲労といった身体状態は含まれないため） このパートでは、職場や教育機関での事例も紹介されている。 職場での使用 禁止される具体例 ...

Gopgleマップを社内資料に貼り付ける場合、基本的には帰属表示をすれば良いと紹介した。 社内の電子資料にGoogleマップを使うには 社内資料として、Googleマップの地図画像をPDF、PowerPointなどの電子資料に貼り付けたくなることがあるかもしれない。 しかし... しかし、商用利用の場合は、その利用形態によってはライセンス料を支払わなければならない。 そこで、気にせず無償で商用利用したいのであれば、より自由度の高い「OpenStreetMap」を利用することをお勧めする。 日本地図に限定しても問題なければ、「国土地理院」の地図画像を使うのも良い。 しかし、両方とも帰属表示が必要な点はGoogleマップと共通する。 OpenStreetMapの使い方 ボランティアが地図データを編集・更新する仕組みなので、地域によってデータの詳細度にばらつきがある場合があり、正直Googleマップより見た目は洗練されてはない気がするものの、商用利用可能な点は大きなメリットである。 まずはOpenStreetMapの地図画像を商用利用するための方法を説明する。 帰属表示とリンク貼り付けすればOK 用いるデータや媒体や用途によって表示形態は異なるが、電子資料に地図画像を貼り付けるのであれば、以下２点を行えば商用利用も可能で、地図画像の複製、配布、送信、改変を自由に行うことができる（データを改変または利用する場合は、同じライセンス下でのみ配布可能）。 帰属表示 著作権とライセンスのページへのリンク貼り付け 詳細はLicence/Attribution Guidelinesに記載されているので、そちらを以下に要約する。 具体的な帰属表示/リンク貼り付けの方法 帰属表示には「OpenStreetMap」の文字を入れる必要がある。 「© OpenStreetMap contributors」や 「© OpenStreetMap」という帰属表示でも問題ないが、読みやすい見た目（フォントサイズ、色など）にしておくことが求められる。 更に、「OpenStreetMap」のテキストに「openstreetmap.org/copyright」へのリンクを設定する必要がある。 もし印刷物等のようにリンクを設定できない媒体であれば、URLを直接記述すれば良い。 OpenStreetMapに由来しない素材と区別するため、使用しているOpenStreetMapのコンテンツを説明するクレジット表記を自由に行うことができる。 例えば、OpenStreetMapデータを独自のデザインでレンダリングした場合は、「OpenStreetMapの地図データ」と表記することができる。 同じ文書に複数の静止画像が含まれている場合は、帰属表示は１つで足りる。 なお、以下の画像には帰属表示は不要である。 100個未満の地物を含む静止画像 10,000平方メートル未満の面積を含む静止画像 小さなサムネイル／アイコン データセット、AIモデルに関する規定も OpenStreetMapデータから大量に抽出された学習データセットは派生データベースとみなされ、公開する場合はODbLの条件に従って利用可能にする必要がある。 このような学習データセットを用いて学習されたモデルは、モデルを使用するユーザーが情報を期待できるドキュメント（モデルのコードベースのREADMEなど）や、モデルをダウンロードできるウェブページなど）に、その帰属を明記する必要がある。 このようなモデルを用いて行われた予測は、ODbLの対象外となる。 ただし、OpenStreetMapデータの大部分を抽出、複製、または再作成するために制作作品が使用される場合、それは派生データベースとみなされることには注意が必要である。 国土地理院のコンテンツの使い方 日本地図のみの利用で問題なければ、国土地理院のコンテンツを用いることが選択肢となる。 一般ユーザーには使いづらい見た目かもしれないが、日本国内の詳細な地理情報が提供されている点がメリットである。 次に、国土地理院の地図画像を商用利用するための方法を述べておきたい。 出典の記載をすればOK 出典を記載すれば利用可能であり、記載方法は「国土地理院コンテンツ利用規約」に以下の通り例示されている。 （出典記載例） 出典：国土地理院ウェブサイト　（当該ページのURL） ※学術論文や図書等に引用する際は、学会誌等が定めたルールに適した方法で引用すること （コンテンツを編集・加工等して利用する場合の記載例） 地理院タイル （標高タイル（基盤地図情報数値標高モデル））を加工して作成 「○○データ」（国土地理院） （当該ページの URL）をもとに○○株式会社作成 第三者のコンテンツを含む場合は注意 コンテンツのうち第三者が権利を有しているもの、例えば地理院地図（タイルデータ含む）のうち他機関の情報であることが示されているものについては、権利侵害とならないよう、別途それらのライセンス条件や利用規約を遵守する必要がある。 例えば、追加でクレジット表記をする等の表記等を行うなどの対応が求められる。

社内資料として、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の詳細については別の記事で紹介しているので、気になるようなら目を通してみて欲しい。

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

生成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利用の可能性大・要ライセンス確認