ソフトウェア開発の現場では、ゼロから全部のコードを書くことは殆ど無い。 多くの場合、世界中の開発者が公開しているオープンソースソフトウェア（OSS）や、既存のライブラリを組み合わせて作られている。 OSSを使う際は、そのライセンス条件をきちんと遵守できているかを確認する必要があるところ、OSSの数が多くなるとそれらを全て把握するのは至難の業である。 そんな時に頼りになるのが、ソフトウェアの「部品表」、つまりSBOM（Software Bill of Materials）となる。 この記事では、このSBOMが何なのか、そしてOSSライセンスとどんな関係があるのかをまとめておきたい。 特に知財部員（企業によっては、法務部員）としては、開発側がちゃんとOSSライセンス管理を行っているのかチェックする立場になるかと思うので、SBOMについて理解を深めておくに越したことは無いと思う。 そもそもSBOMとは？ SBOMとは、製品に含むソフトウェアを構成するコンポーネントや互いの依存関係、ライセンスデータなどをリスト化した一覧表のことである。 ソフトウェアは、その殆どが自分でゼロから全部作っているわけではなく、OSSや既製のライブラリを組み合わせて作られている。 SBOMは、その「中に何が入っているか」を一覧にしたドキュメントとなる。 例えば、 このアプリは「ライブラリA（バージョン1.2.3）」を使っています さらに「OSSライブラリB（MITライセンス）」も含まれています といった情報がSBOMに含まれる。 なぜSBOMが必要なのか？ SBOMが注目される理由は、大きく３つある。 セキュリティ もし部品のひとつに脆弱性（セキュリティの穴）が見つかった場合、SBOMがあれば「どの製品にその部品が使われているか」がすぐ分かる。 法的リスクの回避 OSSにはさまざまなライセンス条件（MIT、Apache、GPLなど）があり、それぞれに遵守すべきルールがある。SBOMがあれば、どのOSSを使っているかが明確になり、ライセンス違反のリスクを減らせる。 顧客や取引先への透明性 ソフトウェアの品質や安全性を証明する材料として、SBOMは信頼性を高める手段になり得る。 特に、知財部員としては２の観点は見逃せないところである。 SBOMとOSSライセンスの関係 OSSライセンスは、言うなれば「そのソフトウェアやコードをどう使っていいか・配布していいか」を決めたルールブックである。 代表的には、以下のようなものである。 MITライセンス：ほぼ自由に使えるが著作権表示は必要 GPLライセンス：改変・再配布時にソースコードの公開義務あり Apacheライセンス：特許権の扱いも含む詳細な条件あり これらの情報を整理する上で、SBOMが役立つ。 SBOMにソフトウェア部品（パッケージやライブラリ）毎のOSSの名前とライセンス情報が載っていれば、開発チームや法務部門は「このOSSはGPLだから配布方法に注意しよう」などの判断がしやすくなる。 SBOMでリスト化される単位 リスト化される単位だが、基本的には「外部から取得したソフトウェア部品（パッケージやライブラリ）」単位となる。 ただし、用途や生成ツール、利用するSBOM標準によって粒度は変わってくる。 一般的な単位 SBOMでは、次のような単位が多い（下に行くほど小さい単位）。 単位 概要 パッケージ単位 依存関係管理ツールが管理する「1つの外部依存パッケージ」ごとに記載 ライブラリ単位 OSパッケージやシステムライブラリを含む「外部で提供されたライブラリ」ごとに記載 コンポーネント単位 ソフトウェア構成管理ツールが定義する論理的な部品ごとに記載 ファイル単位（詳細） ソースコードやバイナリの特定ファイルごとに記載 標準仕様ごとの傾向 SBOMの主要な仕様には次のようなものがある。 仕様 概要 SPDX パッケージ単位からファイル単位まで細かく書ける。ライセンス情報も詳細に記録可能。 CycloneDX アプリの依存関係やサプライチェーン全体を表すのが得意。パッケージ単位が多い。 SWID インストールされたソフトウェア単位（製品やパッケージ）を識別。 実務では、最小はファイル単位、最大は製品単位まで幅があるものの、現実的には依存パッケージごとの粒度が多い。 目的による単位の違い 目的がセキュリティ管理なら、パッケージ単位で十分なことが多い。 一方、目的がライセンス管理なら、１つのパッケージ内で複数ライセンスが混在する場合もあるので、場合によってはファイル単位まで必要となる。 まとめ SBOMがあればOSSライセンスを極力見落としなくDBとして管理できるので、実務上はSBOM管理ツールを導入し、SBOMをうまく活用することが重要である。 ソフトウェアが社内利用に留まるものであればいざ知らず、外にリリースするものであればライセンス遵守については事前確認するのが当たり前なのだが、これがSBOM管理されていないと、開発部・知財部ともにOSSの洗い出しやライセンスチェックで地獄を見るのではないかと思う。

最近、様々なユーザ向けの自社サービスを展開することとなり、そのサービスの利用規約を作成する機会があった。 法律上、サービス提供者に利用規約を作成する義務はないのだが、利用規約を作成しなければ、実務上色々と不便が生じる。 次回同様の対応があったときに備え、利用規約の位置づけや、個別契約との違いを整理しておきたい。 利用規約とは？ 利用規約とは、不特定多数の利用者に対して、あらかじめ一律に適用される契約条件をまとめたものである。 Webサービスやアプリなどでよく同意を求められる、あれのことである。 利用規約の特徴 １番の特徴は、契約内容が画一的（ユーザ毎のカスタマイズ不可）であってユーザ全員に同じ条件を適用できる点、そして所定条件を満たせばユーザがWeb上で「同意する」ボタンをクリックしたり、サービスの利用を開始することで契約が成立するところとなる。 また、運営側による一定の手続で変更も可能である。 仮に利用規約を設けていないと、サービス提供者は各ユーザに対して遵守してもらいたい事項等について、個別に説明・交渉しなければならない。 民法上は「定型約款」として扱われることが多いが、定型約款に該当するための条件などの詳細については別の記事を参考にしていただきたい。 利用規約に対するユーザ同意取得の運用 ソフトウェアやサービスを提供するにあたって、あらかじめユーザーに利用規約などのの同意取得を求めるケースについて考えてみる。 各ユーザーに紙... 主な記載事項の例 提供するサービスやアプリによって内容は異なるが、汎用的な内容としては以下のような項目が挙げられる。 サービスの利用方法・禁止行為 利用料金・支払方法 知的財産権の扱い 免責事項・責任制限 利用停止や契約解除の条件 規約変更の手続き 個人情報の取り扱い 準拠法・裁判管轄 利用規約と個別契約との違い 利用規約と個別契約は、どちらも取引やサービス提供の条件を定めるものだが、性質や役割がかなり異なる。 個別契約は、特定の相手と交わす、取引内容や条件を個別に定めた契約である。 ここでは、利用規約では決めきれない具体的条件を確定させることとなる。 そして当事者間で交渉し、内容を合意の上で確定させていく点が利用規約とは異なる。 交渉を要するのでコストがかかる反面、内容を柔軟に変更できるというメリットもある。 利用規約と個別契約の組み合わせ 一般的な構成だと、基本ルールは利用規約で定め、特定顧客・特定案件向けの条件は個別契約に定めていく形となる。 個別契約が利用規約と矛盾する場合も考慮し、個別契約側には「個別契約が優先」とする条項を置くことが多い。 実務例だと、SaaSの基本利用条件は利用規約に記載し、大口顧客には別途SLA（Service Level Agreement）や価格条件を個別契約で定めることが考えられる。 まとめ このように、利用規約は、極力契約締結の手間を省きつつトラブルを未然に防ぎ、サービスを円滑に運営するために重要な役割を果たす。 ただし、これだけで契約を完結させる必要は無く、適宜個別契約と組み合わせることでより柔軟な契約形態を構成することができる。

開発委託契約は請負型と準委任型に分類され、委託元に納めるべき成果物がある場合は請負契約とする、という点は以下の記事で紹介している。 請負と準委任との違い 基本的に、開発委託契約の契約形態は、「請負」と「準委任」とに分かれる。 いずれも業務を外部に依頼する契約形態だが、契約の目的・成果・責任範... しかし、もし開発してもらうソフトウェアがこちらに納品されるわけではなく、SaaSという形で提供される場合だと、契約はどのように考えたら良いだろうか？ SaaS提供とは？ SaaS（Software as a Service）とは、インターネット経由でソフトウェアをサービスとして利用する仕組みのことである。 通常、普通に納品してもらえば済むソフトウェアであれば、委託元としてはわざわざ継続して費用の発生するSaaS形式で提供してもらう必要性は低いかと思う。 このため、実際は相手方のSaaS提供ソフトウェアを自社向けにカスタマイズしてもらったり、自社サービスと相手方サービスとを連携させるための開発を行ってもらう際にこのような契約を締結することが想定される。 請負型、準委任型それぞれの課題 SaaSで提供してもらうソフトウェアを作ってもらう場合、厳密には委託先から完成したソフトウェアを自社に納品してもらう訳ではないので、素直に考えると請負契約とするのは少し違和感があるかと思う。 では準委任契約はどうかと言うと、こちらは「成果物の完成」ではなく「一定期間の業務を遂行すること」が契約目的となる。 このため、たとえソフトウェアが完成しなくても委託先が開発業務を遂行していれば対価の支払い義務が生じるが、委託元としてはちょっとリスクのある契約となってしまう。 準委任契約を成果完成型とすることで、未完成時の支払義務を回避することは可能である。 しかし、受注者が負う義務はあくまで善管注意義務に留まり、成果物の完成義務は無いし、契約不適合責任も発生しない。 開発してもらうソフトウェアの品質は担保してもらいたいところ、ちょっとこの建付けでは心許ない。 このような場合、契約書はどのようにドラフティングすべきだろうか？ 契約書の作成方針 結論としては、無理に請負・準委任という類型に当てはめることに固執せず、契約として必要な条項を設けておけば良い。 請負と準委任との間の相違は個別契約の中で修正できるし、請負、準委任と明記しない契約書とすることも実務上は珍しくない。 よって、例えば請負・準委任については明記しない代わりに、SaaSとしてケアすべき点として 委託先によるソフトウェアの完成義務 委託元によるSaaS形式での検収 契約不適合（仕様通りに動かない、バグがあったときの対応義務） SaaS提供の条件（ライセンス条件、保守サポート、アップデート提供など） 知財権の帰属（委託先に権利が帰属し、委託元には使用権のみの場合が多い） に関する条項を設けることが重要である。 注意点 SaaS提供となると、ソフトウェアを買い切る形ではなく、引き続き相手方からサービスを提供してもらうためにSaaS提供関連の条項を設ける必要が生じる点は気を付けたい。 あるいは、開発委託契約とは別にライセンス許諾をはじめとするSaaS利用契約を結ぶといった対応もありうる（個人的には、契約は別々にした方が良いと思う）。

特許明細書を作成する際、発明の説明する上でどうしても登録商標を使用せざるを得ない場合があるかと思う。 この場合、商標権者の許可を取ることなく登録商標を使用することは可能だが、いくつか留意点がある。 その留意点について、概要をまとめておきたい。 商標表示義務の発生 登録商標を明細書等に使用する場合について、「特許法施行規則第24条　様式29［備考9］」には以下の通り記載されている。 登録商標は、当該登録商標を使用しなければ当該物を表示することができない場合に限り使用し、この場合は、登録商標である旨を記載する。 つまり、やむを得ず登録商標を明細書等に使用する場合、**最初の登録商標「○○○」の後に「（登録商標）」といった表示をする（未登録商標であれば、商標名の次に「(商標)」と表示する）**ことが求められる。 仮に商標名をそのまま明細書に記載すると、以下のような不都合や商標権者等への不利益が生じるためである。 物品や物質の普通名称と商標名とが混同をきたすようになる その商標名を商品の普通名称であるかのように誤認させ、商標が本来有している商品の出所表示の機能を弱める結果を生じる なお、商標名である旨の付記は、職権訂正により行ってもよいとされており、表示がないことのみをもって拒絶されることは無いかと思う。 場合によっては拒絶理由となることも また留意すべきは、特許請求の範囲、又は明細書若しくは図面のうち、請求項に係る発明について商標名を記載することで、拒絶理由通知の可能性がある点である。 商標は一定の限られた商品にだけ使用されるとは限らないし、一定の商品について使用される場合であっても、同一の商標でありながら、製造の時期などによって商品の品質、組成、構成などが一定でないことが多い。 このことから、請求項に係る発明について記載された部分に商標名の記載がある場合、 発明の詳細な説明の記載が明確かつ十分に記載されていない（特許法第36条第4項第1号） 特許を受けようとする発明が不明確（特許法第36条第6項第2号） と認定されることがある。 ただし、商標名が以下の要件を満たせば問題ない。 その商標名が物質又は物品の普通名称となっていると認められるとき（登録商標名は本件に該当しない） 物質又は物品の普通名称となっていなくても、次の三つの条件を同時に満たしていると認定できるとき 類似品のうちから特にその商標名のものを選定したことに、発明としての充分な意義が認められること 商標名が記載されていても、その発明が不明確とならないこと（例えば、その商標は、少なくともその発明の特許出願以前から出願当時にかけて、常に一定の品質、組成、構成などのもののみに付されていたことが明瞭であること) 商標名で記載されていても、その発明の技術が充分に公開されていると認めることができること(例えば、その商標名の商品の市販が、何らかの理由で停止されても、その発明と実質上同一の発明を、その発明の属する技術の分野における通常の知識を有する者が容易に実施することができること) まとめ 以上のように、使用の際は明細書中で登録商標等である旨の表示をする必要があり、また商標使用により発明が不明確とならないよう留意することが求められる。 より詳細な情報が知りたければ、特許・実用新案審査ハンドブック「2003 明細書、特許請求の範囲又は図面に商標名が記載されている場合の取扱い」を確認いただきたい。 （参考）使用頻度の高い登録商標のリスト 参考として、特許庁HP「明細書への登録商標の記載について」に掲載されている、明細書等で登録商標である旨の表示がなく使用されている登録商標のうち、使用頻度の高いもののリストを転記しておく。 五十音順 アルファベット順 ウィンドウズ ANDROID ウォークマン BLACKBERRY ウォシュレット Blu-ray カラーコーン BLUETOOTH ガルバリウム鋼板 COMPACTFLASH ケーブルベア DLNA ケーブルベヤ Felica 碁石茶 FIREWIRE コンパクトフラッシュ FRAM サーボパック HDMI サイダック HIT サランラップ iPad セルフォック iPhone セロテープ iPod 宅急便 JAVA テトラパック JAVASCRIPT テフロン Linux テレスコ PENTIUM トルクス PHOTOSHOP ハーモニックドライブ PYREX パイレックス QRコード パトライト SmartMedia パワーゲート TEFLON フォトショップ TETRAPAK ブルートゥース UNIX ベルクロ VELCRO ペンティアム VICS ポラロイド WALKMAN マジックテープ WINDOWS 万歩計 YouTube リナックス ZIGBEE レイデント レバーブロック

ソフトウェア開発において、もはやOSS（オープンソースソフトウェア）の利用はほぼ必須と呼べると思われるが、OSSライセンスについて問題ないかを確認する作業は開発者にとってかなりの負担になっているかと思う。 世の中にはOSSの管理を支援するツールも普及しているものの、一部の言語には対応していなかったり、完全に人のチェックを手離れさせるのはまだ難しいという印象である。 知財部の立場から言えば、自社のプロプライエタリなコードの開示義務が生じたり特許権の許諾義務が生じる可能性もあるので、口酸っぱく注意喚起するしかないのが辛いところである。 ところで、パッケージにちょいちょいOSSのデュアルライセンスが含まれるケースを見かけるのだが、自分の勉強も兼ねてデュアルライセンスについてこの記事で整理しておきたい。 デュアルライセンスの概要 OSSのデュアルライセンスとは、同じソフトウェアに２つのライセンスを重ねて適用するものではなく、２つの異なるライセンス形態で選択的に提供される仕組みである。 ユーザーは、その中からいずれかのライセンス条件を選んで配布することができる。 デュアルライセンスは、いずれもOSSライセンスの場合と、商用ライセンスとOSSライセンス（コピーレフト条項が付いていることが多い）を選択可能なデュアルライセンスの場合とがある。 ちなみに、３つになればトリプルライセンスと呼び、こういった複数ライセンスのうちいずれか１つを選択可能な場合をマルチライセンスと呼ぶらしい。 いずれもOSSライセンスの場合 この場合であれば、企業としてはより条件の緩いライセンスを選択することが普通であろう。 ソースコード開示義務や、特許権の許諾義務を極力回避したいからである。 例えば、GPLとMITのデュアルライセンスの場合は、通常はMIT Licenseを選択する。 商用ライセンスとOSSライセンスとを選択させる場合 例えば、GPLと商用ライセンスとGPLのデュアルライセンスの場合について考えてみる。 商用ライセンスの実務上の位置づけとしては、OSSライセンスの制限を避けたい企業向けの「ライセンス回避の選択肢」として設計されている。 この場合、商用ライセンスでは、OSS版で義務付けられているソース開示や特許ライセンスを免除する旨を明記していることが多い。 したがって、企業が独自の製品に組み込んで販売するなら、対価を支払うことで商用ライセンスを選択し、クローズドな利用とすることが可能である。 一方、対価を払わない場合はGPL条件を遵守する必要があるが、オープンソースプロジェクトならGPLを選択するということもできる。 デュアルライセンスにおける誤解 OSSのソースコードのパッケージには幾つかのコンポーネントが含まれており、それぞれのコンポーネントのライセンスが異なる場合もある。 OSSの勉強をし始めたときはこれがデュアルライセンスかと思っていたが、これはデュアルライセンスではない。 パッケージとして見ると、一部のコンポーネントはその他のコンポーネントとは異なるOSSライセンスが適用されているだけであって、別なライセンスが選択可能というわけではないからである。 開発から「このパッケージのOSSライセンスはこれです」と出された後、開示されているURL先を見に行ったときにOSSライセンスが聞いていたのと違う場合、このパターンであることが多い。 この場合、パッケージから手作業でライセンスの明記されているテキストを漁ったりする必要があり、かなり面倒である。 OSS検知ツールである程度は把握できるとはいえ、たまにこういう事例があるので、なかなか人の目を完全に無くすのは難しいという印象である。 まとめ デュアルライセンスは便利な柔軟性を持つ一方で、「同じコードに複数のライセンスが重なっている」と誤解されやすい。 実務では、著作権者、ライセンス内容、選択の影響を整理した上で運用することが重要である。

近年は生成AIの発達が凄まじく、こちら側のプロンプトに応じてソースコードや画像を作成してくれる。 このとき、作成したものについて特許権や商標権を取得することができるか、現状を整理しておきたい。 特許権について AIが作成した発明であっても、権利取得は可能である。 特許要件（産業上利用可能性、新規性、進歩性など）についても、従来と特段の違いは無い。 ただし、出願書面の発明者の氏名には、AIの名前ではなく、自然人の氏名を記載する必要がある。 日本では、AI自身を発明者と認めていないためである。 また外国の多くの法域でも同様に、AI自身を発明者と認めていない。 AIを発明者とは認定せず AIを発明者と認定せずとの判決を下した「ダバス事件（東京地判令和6年5月16日（令和5年（行ウ）第5001号））」を紹介する。 原告は、発明者の氏名の欄に「ダバス、本発明を自律的に発明した人工知能」と記載した国内書面を提出したが、特許庁は自然人の氏名を記載するよう補正を命じ、最終的には補正しなかった原告の出願を却下した。 ここで、特許法に規定する「発明者」は自然人に限られるか（＝AIは「発明者」に該当し得るか）問題となったのだが、結論としては、自然人に限られるものと解するのが相当であると東京地裁は判決を出している。 判決文から、筆者が抜粋・編集した理由は、以下の通り。 知的財産基本法は、特許その他の知的財産の創造等に関する基本となる事項として、発明とは、自然人により生み出されるものと規定していると解するのが相当 特許法では、発明をした者は、その発明について特許を受けることができる旨規定している。AIは法人格を有するものではないから、「発明をした者」は、特許を受ける権利の帰属主体にはなり得ないAIではなく、自然人をいうものと解するのが相当 では発明者は誰か 発明の過程にAIが利用される場合でも、現状はプロンプトの入力など、人間の関与が一定 程度必要である。 このことから、現状は発明の技術的特徴部分の具体化に創作的に関与した人間を発明者とするという考え方が通常である。 つまり、AIを発明者から除く点以外は、現行の発明者要件の考え方が踏襲される。 2024年に特許庁が行った「AIを利活用した創作の特許法上の保護の在り方に関する調査研究」でも、同様の意見が寄せられているところである。 一方、学説によれば、発明者とは、当該発明の創作行為に現実に加担した者だけを指し、単なる補助者、助言者、資金の提供者あるいは単に命令を下した者は、発明者とはならないとされている。 したがって、人間が抽象的なアイデアを出す助言者という位置づけの場合、現行の考え方ではその人間を発明者として認定できないこととなる。 すると、発明が生まれたにも関わらず発明者が存在しないという、よく分からない状況が生じてしまう。 そこで特許庁は、法解釈の変更を含めた対応を検討しており、2026年にも特許法の改正を目指している状況である。 商標権について AIが作成した商標であっても、基本的には権利化可能である。 商標法は、商品やサービスを他と識別するための「標識」（ネーミング、ロゴ、図形など）を保護する。 生成AIが出力したロゴやブランド名であっても、商標の要件（識別力など）を満たせば登録可能である。 ただし、商標登録出願は使用主体（人または法人）によって行われる必要があるため、こちらも特許権と同様にAI自身を出願人とすることはできないと解する。 一方、商標の場合、創作者という概念が法律に規定されていない。 従って、創作の貢献の有無によらず誰でも出願することができ、権利者（商標権者）になることができる点は特許と事情が異なる。 著作物性について ちなみに、AIが作成したものにも、一定条件が備わっていれば著作権としての保護対象となり得るとされている。 その場合、著作権者はAI自身とはなり得ず、プロンプロト入力した自然人等が著作権者となる。 この際、AIに作らせるという行為には製作者のコントロールが及ばないところはあるのが実情だが、それだけを理由に著作物たり得ないと判断されることは無いようである。 中国の話にはなるが、生成AI（Stable Diffusion）による生成画像の著作物性を認めた北京インターネット裁判所判決（春风送来了温柔事件判決）も存在する。 その他留意点 AI発明を権利化する際は、AIの利用規約に、生成物の知財権の取り扱いについて記載が無いかは確認した方が良い。 多くはAIを使用した時点で利用規約に同意したことになるだろうが、「生成物の権利取得は禁止する」「AI作成者に帰属する」といった規定がされている可能性も考えられるからである。 ただそういった縛りをかけると利用者から敬遠されるのか、近年は生成物のや権利は利用者とする規約も増えている気がする。

In U.S. patent applications, many people struggle with § 101 rejection. Of course I’m one of them. As a personal memorandum, I’d like to leave some countermeasures to avoid § 101 rejection. This is merely my personal opinion and should be taken as such. Decision Flow First, the following is the basic flow for determining patent eligibility. MPEP §2106 Step 1 If the claim falls within one of the statutory categories (process, machine, manufacture, or composition of matter), then it clears the first hurdle and proceeds to Step 2A. If not, it is deemed “ineligible subject matter” and the examination ends immediately. In Japan, program claims are accepted, but in U.S. applications, they need to be amended into something like computer-readable medium claims. ...

避難経路や建物の案内を考えるときに、誰もが一度は目にしたことのある「非常口マーク」。 施設のサインとして使いたい、あるいは説明用の資料に載せたい──そんなときにふと気になるのが、「これって著作権や商標権に引っかからないの？」という点だろう。 実際、世の中にはロゴやマークに関して権利が厳しく設定されているものも多い。 非常口ピクトグラムや、その他の安全標識については、使用前の事前許諾が必要なのだろうか？ 本記事では、日本で広く使われている非常口ピクトグラムを中心に、その法的な扱いを整理してみる。 安全標識はISO/JIS規格で掲載されている 日本で広く使われている非常口ピクトグラムも含めた安全標識の多くは、**国際標準（ISO 7010:2019）やJIS規格（JIS Z8210:2017）**に基づいてデザインされている。 ISO規格、JIS規格のものならどんな使い方も認められるわけではないが、どういった使い方なら認められるのか、著作権、商標権の観点から掘り下げてみたい。 著作権について 著作権法第13条では、著作権が生じない著作物（非保護著作物）を、次のように定義している。 （権利の目的とならない著作物） 第十三条　次の各号のいずれかに該当する著作物は、この章の規定による権利の目的となることができない。 一　憲法その他の法令 二　国若しくは地方公共団体の機関、独立行政法人・・・又は地方独立行政法人・・・が発する告示、訓令、通達その他これらに類するもの 三　裁判所の判決、決定、命令及び審判並びに行政庁の裁決及び決定で裁判に準ずる手続により行われるもの 四　前三号に掲げるものの翻訳物及び編集物で、国若しくは地方公共団体の機関、独立行政法人又は地方独立行政法人が作成するもの 非常口ピクトグラムの取扱いは？ ここで、非常口ピクトグラムは消防庁告示「誘導灯及び誘導標識の基準」にて定められているため、非保護著作物となる（著作権は発生しない）。 その他のピクトグラムの取扱いは？ JISで規定された図記号であっても著作権の保護対象だが、特定の案内用図記号は規格作成の用途で利用することができる。 日本産業標準調査会HPの「JISの引用・転載について」のFAQにも、以下のように記載されている。 図記号を看板、標識、取扱説明書、製品、社内規格、仕様書などに用いるときに、その利用許諾は必要ですか。 A．図記号が規定されているJISの適用範囲においてその図記号を利用する場合は、利用許諾の確認の必要はございません。規格作成の用途以外の利用については、当ウェブサイトの「お問い合わせ」ページより、カテゴリー＜JIS等の引用・転載＞を選択し、お問い合わせください。 では規格作成以外の用途も含め、自由に使おうとするとどうかと言うと、公益財団法人交通エコロジー・モビリティ財団が策定している「標準案内用図記号ガイドライン2021」に掲載された図記号（JISで規定された図記号の一部も含む）は、ガイドラインに従えば誰でも自由に使用することができる。 ※「標準案内用図記号ガイドライン2021に掲載されている図記号一覧」は、こちら ガイドラインでは、表示の際のルールとして、例えば以下の事項が定められている（例：非常口ピクトグラムは左右反転OK）。 図形変形 文字による補助表示 色彩、明度の調整 左右反転の可否 商標権について 案内用図記号であるピクトグラムは、一定の情報を正しく伝達するという公益的な目的があるだけであって、特定人の商品・役務の出所を表示するものではない。 よって、通常は商標登録の必要はないといえる。 他者が自分の商品やサービスに対して用いるため、特定の指定商品・役務に対してピクトグラムを商標登録している可能性も無くはないが、その場合でも公益的な目的で使う限りは「商標的使用」に該当しないため、問題ないと思われる。 例えば、特定のAEDマークについては日本救急医療財団が商標権を取得しているが、「AED設置場所を示すものとして使用する」のであれば、使用しても問題ないとアナウンスされている。 なお、公益財団法人交通エコロジー・モビリティ財団のHPでは以下のように注意書きがされており、商標登録できないとまでは言及していないものの、商標登録は推奨していない様子である。 ４．本図記号のご利用にあたって 本ガイドライン改訂版に掲載されている図記号は、誰でも自由に使用することができます。また、本ガイドラインとこれら図記号のデータは、(公財)交通エコロジー・モビリティ財団のホームページに掲載されていますのでご利用ください。**ただし、これらの図記号を商標又は意匠として登録等を行うと、第三者の権利を侵害する可能性があります。**ご不明な点等ございましたら下記までお問い合わせください。 注意点 デザインを独自にアレンジしてロゴ化し、そのアレンジが誰かの著作物や商標権を持つデザインに似ている場合は権利侵害の可能性がある。 また、海外では国ごとに安全表示デザインの扱いが異なるため、海外展開する場合は現地法を確認する必要がある。 ISO規格の図記号であれば、ものによっては国際標準化機構の承諾が必要となる。 非常口マークは安全のための統一規格なので、形状・色を変えてしまうと法令や規格に違反することもある。 まとめ 非常口ピクトグラムに著作権は発生せず、自由に使用可能 その他JIS規格にあるピクトグラムについては、日本国内で規格通りに安全表示や説明用に使う場合、著作権・商標権は基本的に気にせず使用可能 「標準案内用図記号ガイドライン2021」に掲載されたものは、ガイドラインに従えば誰でも自由に使用可能 独自アレンジや海外利用には注意が必要 おまけ 「標準案内用図記号ガイドライン2021」において、赤、青、黄、緑が使用されている図記号の色彩は、［JIS Z 9103安全色及び安全標識（2017年度改正）］に依っている。 例えば非常口ピクトグラムは緑色だが、これにもちゃんと理由がある。 火の赤と緑が色相環でいうところの「補色」関係であり、火災が起きたときに非常口マークを目立たせるために緑になっている。

特許権や商標権など、自社が保有する知財権を他社に使用させる際の話となる。 まだ契約業務に不慣れだった頃は、権利の許諾先が親子関係であれば、どうせ大元の財布は同じな訳だしライセンス費を無償にしても良いんじゃないかと思っていた。 しかし、うっかりそんな契約を結ぼうものなら、税務調査のときに目をつけられてしまう可能性が高い。 知財権を無償許諾するときのリスク 調査員は「無償」という言葉にとても敏感らしく、法人が知財権を無償で提供する場合、その無償取引によって相手方に移転する経済的利益が「寄附金」に該当するんじゃないか？と思われてしまうのである。 特に、第三者にはロイヤルティを徴収する一方、子会社には無償や不当に低い金額でライセンスを許諾していると、よりリスクは高くなる。 そして、ひとたび寄付金と認定されてしまうと、課税されてしまう。 よって、調査員の厳しいチェックに耐えられるよう、無償とするからには本来得られるはずだった対価に代わるものが使用許諾によって得られる、とか、ビジネス上合理的な理由がある、といったロジックを組んでおく必要がある。 そしてロジックを考えるだけでなく、実際に契約書に落とし込むといった記録を残すのが大事である。 例えば、契約書の条項であれば「◯◯であることから、本契約に基づく商標権の使用の対価は無償とする。」という感じである。 また個人的には、そのロジックに基づき、許諾期間を設定するのもポイントになるのではないかと思う（例：共同研究を根拠とするなら、使用許諾期間が共同研究契約の契約期間とリンクしていること）。 或いは、社内稟議・議事録等に「無償の理由」を残すのも一案である。 知財権が発生する業務委託契約におけるリスク 使用許諾契約だけでなく、業務委託契約で受託者の知財権を召し上がる際も注意が必要である。 業務委託契約で知財権が発生した場合、その知財権が、委託者から受託者に譲渡されたり、使用許諾されることはよくあるケースである。 この際、対価が無償であったあり、不当に低い場合は、独占禁止法や下請法違反となる可能性がある。 実務上はそれらの対価も含めて委託費を算定することが通常であり、別途ライセンス費用を算定することはあまり無いかもしれない。 委託者側としては、業務委託契約の委託費についてあまり低い設定をしないように気をつけておきたい。

特許出願の際は発明の名称を記載するが、ソフトウェア発明で迷ったら、とりあえず「情報処理装置」と付けることがあるかと思う。 日本では補正を命じられた経験は無いが、こういったとき、米国では「発明の名称がよく分らんから、もっと名前を具体的にするように」と審査官から補正を求められることが多い。 知財部に異動したばかりのときは、「どうせ権利範囲とは関係ないし、補正すればいいんでしょ？」位の気持ちでいたが、本当に権利範囲に影響しないかというと、「国によっては影響し得る」ということを知ったときは焦ったものである。 ここでは、「発明の名称」と「要約書」の２点について、日本と米国における権利範囲への影響を整理したい。 日本の特許法における位置づけ 発明の名称や要約書の記載は、権利範囲に影響しない。 以下の特許法第70条1項にもある通り、**特許請求の範囲（クレーム）**が、特許権の権利範囲を定めており、クレーム内の用語の意味するところを解釈する際には、適宜明細書の記載や図面を参照することとしている（審査経過も参酌される）。 （特許発明の技術的範囲） 第七十条　特許発明の技術的範囲は、願書に添付した特許請求の範囲の記載に基づいて定めなければならない。 ２　前項の場合においては、願書に添付した明細書の記載及び図面を考慮して、特許請求の範囲に記載された用語の意義を解釈するものとする。 ３　前二項の場合においては、願書に添付した要約書の記載を考慮してはならない。 「発明の名称」は、発明の技術分野の識別や分類のための形式的情報として記載されるにすぎず、クレームの解釈要素とはされない。 とはいえ、例えば発明の名称が特許請求の範囲と明らかに異なっていたりすると、手続補正命令を受けたり、職権訂正を受けることがあるようである。 特許・実用新案審査ハンドブックによれば、職権訂正の対象になり得る記載不備の例として 発明の名称に「○○装置及び△△方法」とあるのに、特許請求の範囲に「…○○装置」だけ記載されていれば、発明の名称も「○○装置」とするよう訂正する例が挙げられている。 補正等で「…△△方法」のクレームを削るとこのような事態が起こり得るが、実務上は積極的にこちらから発明の名称まで補正する必要性は低いかと思われる（特許性や権利範囲に影響しないので）。 米国特許法における位置づけ 上述の通り、日本は「発明の名称」「要約書」いずれも権利範囲に影響しないが、米国では事情が異なる。 発明の名称に関して 米国における発明の名称の記載ルールとしては、500字を超えない範囲で可能な限り短くかつ発明を特定できるものでなければならず（37 CFR 1.72(a)）、発明を特定するのに十分でない場合には、審査官から「発明の名称」の変更が要求される（MPEP §606.01）。 ソフトウェア発明で「情報処理装置」と記載すると、この変更要求が飛んでくるイメージである。 ここで発明の中身を具体的にするよう名称の補正をすることがあるかもしれないが、このときは発明の名称をいたずらに限定しすぎない方が良い。 米国では、裁判所がクレーム解釈の際に、特許の名称を内部証拠として使ったことがあるからである※。 ※Wastow Enterprises, LLC v. Truckmovers.Com, Inc.事件, Appeal No. 2020-2349, F.3d, (Fed. Cir. May 14, 2021). 要約書に関して 要約書の記載についても、同様に注意したい。 米国では、過去のＣＡＦＣ（連邦巡回控訴裁判所）にて、要約書の記載に基づきクレームを限定解釈する判決がなされたことがあり（※）、「要約書」をクレーム解釈に利用することを禁止する規定が2003年規則改正により削除されている。 このため、日本とは異なり、要約書の内容によっては権利範囲が限定解釈される可能性があると考えた方が良さそうである。 ※Hill Rom Co. v. Kinetic Concepts, Inc. , 209 F.3d 1337, 1341 n.*, 54 USPQ2d 1437, 1440 n.1 (Fed. Cir. 2000) その他の国は？ その他の主要国はどうかというと、欧州・中国においては、日本と同様に、要約の記載を権利範囲の解釈に用いることは禁止されているので、その点は安心である。 発明の名称についても原則権利範囲には影響しないはずであるが、経験上発明の名称の補正を求められたことは殆ど無い。 まとめ 日本では、「発明の名称」「要約書」いずれも権利範囲には影響しないが、米国では（稀かもしれないが）共に限定解釈の材料とされる可能性がある。 少なくとも、日本の出願を基礎にして米国出願するケースでは、「日本では権利に影響しないから」と、これらの項目の記載を限定し過ぎないよう気を付けておいた方が安全かと思われる。