コンテンツまでスキップ
お問い合わせ

【弁理士解説】Notionの初出願はSynced Blockだった｜米国特許11,868,706のクレームに見るデータ構造の権利化

Picture of 弁理士 杉浦健文

Notionには、あるページで書いた内容を別のページにも置き、どちらを編集しても両方が同時に変わる「Synced Block（同期ブロック）」という機能があります。地味に見えて、社内マニュアルや共通仕様の管理では手放せない機能です。

実はこの機能こそ、Notionが創業から8年を経て初めて出願した特許でした。米国特許第11,868,706号。本記事では請求項1を原文で引用し、「なぜ最初の一件がこれだったのか」をクレームの構造から読み解きます。データ構造を持つプロダクトを開発している企業にとって、権利化の考え方の参考になる一件です。

💡 要点：本記事はNotion特許シリーズの個別解説編です。ポートフォリオ全体の分析はNotionの特許戦略（総論）をご覧ください。

書誌事項｜Notionの「一件目」

特許番号 US 11,868,706 B1
発明の名称 System, method, and computer program for syncing content across workspace pages
（ワークスペースのページ間でコンテンツを同期するシステム・方法・プログラム）
出願人 Notion Labs, Inc.
発明者 He Lu、Simon Townsend-Last
出願日／優先日 2021年12月13日（両者同一）
登録日 2024年1月9日
請求項数 全27項（独立項3：請求項1、14、15）

末尾の「B1」という符号は、登録前に公開公報が発行されていないことを意味します。つまりこの出願は、内容が世に出ないまま登録に至りました。競合が公開公報を監視していても、この特許は登録されるまで検知できなかったことになります。

実務Tips（独立項が3つある意味）：本件は「方法」「システム」「コンピュータプログラム」に対応する独立項を揃えていると読めます。同じ発明を複数の類型で押さえておくと、権利行使の場面で相手方の行為態様に合わせて主張を組み立てやすくなります。ソフトウェア発明では定番の設計です。

対応する機能｜Synced Blockとは何か

Synced Blockは、簡単に言えば「同じ中身を複数のページに置き、どこを直しても全部が直る」仕組みです。たとえば、次のような使い方がされます。

  • 全社共通の行動指針を、部署ごとのページに埋め込む
  • 製品スペックを、営業資料ページと開発ページの両方に置く
  • 更新頻度の高い連絡事項を、複数のプロジェクトページに反映する

単なるコピーではなく、また単なるリンクでもありません。実体は一つで、複数の場所に「窓」が開いている状態です。この「窓」の作り方が、まさに請求項の中身になっています。

請求項1の原文（逐語引用）

US 11,868,706 B1 特許請求の範囲 請求項1（原文引用）

A method, performed by a computer system, for syncing content across workspace pages, the method comprising: creating a first synced block on a first workspace page, wherein content on workspace pages rendered by the system is stored in blocks, wherein each of the workspace pages has a hierarchy of blocks, wherein each block has 1) attributes that describe the block itself including a unique identifier, a list of properties, and a type attribute that determines how the block is displayed and 2) attributes that define the block's relationships with other blocks including an array of child blocks and a pointer to its parent block, and wherein, in response to a user changing a block's type attribute from a first block type to a second block type, changing how the block is rendered from a first rendering to a second rendering, including whether or not to render one or more properties of the block and whether or not to indent content of the block; adding one or more child blocks to the first synced block as content to be synced; creating a reference synced block on a second workspace page; and adding a pointer to the reference synced block that points to the first synced block in order to sync the one or more child blocks of the first synced block across the first and second workspace pages, wherein editing the first synced block or the reference synced block comprises editing the one or more child blocks of the first synced block.

構成要件の分説｜5つの要素に分解する

要件 内容（日本語による分説）
A（生成） 第1のワークスペースページ上に第1の同期ブロックを作成すること
B（構造） コンテンツがブロックとして格納され、各ページがブロックの階層を持つこと。各ブロックが次の2種類の属性を持つこと：
①自身を記述する属性（一意識別子／プロパティのリスト／表示方法を決める型属性）
②他ブロックとの関係を定める属性（子ブロックの配列／親へのポインタ）
C（型変更） ユーザーがブロックの型属性を変更したことに応じて、描画のしかたを変えること。
その変化にはプロパティを描画するか否かと内容をインデントするか否かが含まれること
D（内容付与） 第1の同期ブロックに、同期対象となる子ブロックを追加すること
E（参照） 第2のページに参照同期ブロックを作成し、そこに第1の同期ブロックを指すポインタを付与すること。
いずれの同期ブロックを編集しても、それは第1の同期ブロックの子ブロックを編集することになること

注目点｜請求項の半分が「データ構造の定義」

この請求項を読んで真っ先に気づくのは、「同期する」という動作そのものの記述が驚くほど短いことです。実質的な同期処理は要件Eの数行だけ。残りの大半は、ブロックというデータ構造がどういうものかの定義に費やされています。

これは偶然ではありません。「複数箇所に同じ内容を表示し、片方を直すと両方直る」というアイデア自体は、ワープロソフトのフィールド機能やWikiのトランスクルージョンなど、古くから存在します。アイデアだけでは特許になりません。

弁理士の視点：だからこそこの請求項は、「Notionというプロダクト固有のデータの持ち方」を先に定義し、その上で同期を語るという構造になっています。一意識別子、プロパティのリスト、型属性、子ブロックの配列、親ポインタ——これらを組み合わせた具体的な構造の上で成立する同期、という限定によって、先行技術との距離を確保していると読めます。

実務Tips（ドラフティング）：「機能のアイデアは既にありそうだ」と感じる発明でも、自社のデータモデルまで踏み込んで書くと権利化の道が開けることがあります。権利範囲は狭くなりますが、自社実装をしっかりカバーでき、かつ無効化されにくい権利になり得ます。SaaSのどの層が特許になり得るかはSaaSプロダクトの機能マップで整理しています。

最大の謎｜なぜ「型変更」の限定が入っているのか

この請求項でいちばん不思議に見えるのが、要件Cです。ブロックの型を変えると描画が変わり、その変化にはプロパティを描画するかどうかとインデントするかどうかが含まれる——同期の話をしているのに、なぜ突然「型変更時の描画」の話が入ってくるのでしょうか。

Notionを使ったことがある方なら、この挙動には馴染みがあるはずです。段落を箇条書きに変える、見出しに変える、トグルに変える——スラッシュコマンドで型を切り替えると、見た目もインデントも変わる、あの動きです。

【分析】この限定は、審査の過程で追加されたものである可能性があります。米国では、審査官から先行技術を引用されたときに、明細書に記載された特徴を請求項に加えて差別化を図るのが通常の対応です。「同期」だけでは近い先行技術があり、「ブロックの型を切り替えると描画が動的に変わる」という、より具体的な実装特徴を加えることで登録に至った——そう読むのが自然です。ただし出願経過の原本までは確認していないため、断定はしません。

注意：上記は請求項の文言から読み取れる推測であり、実際の審査経過に基づく事実の記述ではありません。正確な経緯はUSPTOの包袋（file wrapper）で確認する必要があります。

権利範囲の勘所｜広いのか、狭いのか

この特許の権利範囲を評価すると、次のように整理できます。

観点 評価
自社実装のカバー 十分にカバーしていると考えられます。要件はいずれもNotionの実装そのものです
他社への牽制力 限定的です。同期機能を持っていても、ブロック階層／親子ポインタ／型変更時の描画変化のいずれかが異なれば、原則として構成要件を充足しません
無効化されにくさ 要件が具体的なぶん、これらを全て開示する先行技術は見つけにくく、比較的安定した権利と考えられます
回避のしやすさ データモデルが違う競合にとっては、回避の余地があると考えられます

つまりこの特許は、「他社を広く止める矛」ではなく「自社の看板機能を守る盾」としての性格が強いと言えます。競合が丸ごと真似てきたときに主張できる、という位置づけです。

実務Tips（広い権利と狭い権利）：「広い請求項が良い権利」とは限りません。広い権利は無効審判で潰されるリスクを抱えます。実務では、広めの独立項と、具体的な限定を加えた従属項を階層的に用意し、無効主張に備えるのが定石です。本件も独立項3つ・全27項という構成で、その備えが見て取れます。

実務への示唆｜「看板機能から取りにいく」という選択

Notionが最初の特許にSynced Blockを選んだ事実からは、いくつかの実務的な示唆が得られます。

① 「基本特許から」ではなく「模倣されたら困る順に」

教科書的には基盤技術から押さえるのが理想です。しかし予算が限られる企業にとって、「顧客がこの製品を選ぶ理由になっている機能」から権利化するという順序も、実務的な選択肢の一つです。

② データ構造は「書ける資産」である

自社プロダクトのデータモデルは、外からは見えにくく、しかし機能の独自性を支えています。それを請求項に書き込むことで、機能の模倣に対して主張できる権利になり得ます。逆に、外から観測できない処理を秘匿する選択もあります。切り分けの基準は特許かノウハウ秘匿かで解説しています。

③ 出願が遅れると、その機能はもう出せない

本件の出願は2021年12月ですが、Synced Blockはそれ以前から提供されていたとされています。公表済みの機能は原則として新規性を失い、後から特許にすることはできません。Notionの初期機能の多くは、この理由で権利化の対象外になっていると考えられます。

ここが実務で最も多い相談です：「リリース済みの機能を今から特許にできますか」というご質問をよくいただきます。原則として難しく、例外的に新規性喪失の例外規定（日本では特許法30条、公表から1年以内など要件あり）が使える場合に限られます。迷ったら公表前にご相談ください。

よくある質問（FAQ）

Q. 自社ツールにも同期機能がありますが、問題になりますか？

A. まず、この特許は米国特許であり、効力は米国内の実施に限られます。そのうえで、請求項1の要件A〜Eをすべて満たすかが判断の基準です。特に「ブロックの階層構造」「親ポインタと子ブロック配列」「型変更に応じた描画変化」がそろっているかが分かれ目になり得ます。米国展開がある場合は、実装との照合を弁理士にご相談ください。

Q. 「B1」の特許は普通の特許と違うのですか？

A. 登録後の効力は同じです。違うのは、登録前に出願内容が公開されていなかったという点です。第三者からは事前に察知しにくい一方、出願人側は公開に基づく補償金請求の基礎を持ちません。競合調査では、公開公報だけでなく登録公報も追う設計にしておくことをおすすめします。

Q. データ構造そのものは特許になりますか？

A. 単なるデータの並べ方だけでは、日本でも「発明」に該当しないと判断される場合があります。ポイントは、そのデータ構造を用いて情報処理が具体的に実現されているかです。本件も、データ構造の定義に加えて「同期する」という処理が組み合わされています。

Q. なぜ日本ではなく米国に出願したのでしょうか？

A. Notionは米国企業であり、主要市場も米国です。特許権の効力は国ごとに独立しているため（属地主義）、まず自社の主戦場で権利を確保するのは合理的な判断です。ポートフォリオ全体の国別の構えは総論記事で分析しています。

まとめ

US 11,868,706 は、「同期」というありふれたアイデアを、自社固有のデータ構造とセットで書くことで権利化した一件です。請求項の大半をデータ構造の定義に充て、そこに型変更時の描画挙動という具体的な限定を重ねる——権利範囲は決して広くありませんが、自社の看板機能をしっかりカバーし、無効化されにくい形に仕上がっています。

「うちの機能はありふれているから特許にならない」と考えている企業にこそ、参考にしていただきたい書き方です。

知的財産事務所エボリクスへのご相談

エボリクス（evorix.jp）では、SaaS・Webサービスの特許出願を承っております。「ありふれた機能に見えるが権利化できるか」「リリース前に何を出願しておくべきか」といったご相談に、データモデルまで踏み込んで対応いたします。まずはお問い合わせフォームよりお気軽にご相談ください。

本記事の注意事項：本記事は2026年7月時点の公開特許情報に基づく一般的な解説です。引用した請求項は公開データベースの記載に基づきますが、権利範囲は最終的にUSPTOの正本と出願経過により定まります。本記事の分説・解説は理解を助けるための整理であり、権利範囲を画定するものではありません。侵害の成否、特許の有効性について本記事は何ら断定するものではなく、個別事案の結論を保証するものでもありません。事業判断にあたっては専門家の個別検討をご利用ください。

出典