IoT 特許ダイアグラム
IoT のクレームは3つの高度に存在します——デバイス、ネットワーク、そして両方にまたがって走る方法。それぞれの高度に固有のダイアグラムタイプがあり、3つが互いに、そしてクレームと整合して初めてセットは機能します。
- 3層トポロジー図
- ノードの分解図
- プロトコルフローチャート
- クレームと一致するデバイス数
30秒でわかる答え
- クレームの高度を対応させます:システムクレーム → デバイス・ゲートウェイ・クラウドのトポロジーブロック図、デバイスクレーム → ノードの分解図またはブロック図、方法クレーム → クレームのステップを反映したフローチャート、セキュリティクレーム → プロビジョニングのシーケンスフロー。
- クラウドは装飾的なアートでなく、参照符号付きの素っ気ないラベル付きブロックか輪郭として描き、トポロジー内のデバイス数はクレームの記載と一致させます。
- 各ダイアグラムを記述やスケッチから PatentFig AI で生成し、出願前にセットを庁規則でチェックしてください。
IoT ダイアグラムの例
各例は架空の発明です。開くとプロンプトがジェネレーターに読み込まれます。
どの図面がどのクレームを支えるか
IoT のクレームは3つの高度でやって来ます——それぞれに定番のダイアグラムを与えましょう。
システムクレーム → 3層トポロジーブロック図
エッジデバイス、ゲートウェイ、クラウドプラットフォームを3層のラベル付きブロックとして、番号付き通信リンクで結びます——システムクレームが要素ごとに記載するその図面です。
デバイスクレーム → 分解図またはブロック図
センサーノードを開いて:ハウジング、基板、センサーモジュール、無線、アンテナ、バッテリーを分解図に——内部が電子的なら、ハードウェアブロック図でも構いません。
プロトコル・方法クレーム → フローチャート
クレームの文言を正確に反映した番号付きステップ——検知、送信、確認応答、再試行——こうすれば各クレームステップが1つの箱を引用できます。
セキュリティ・プロビジョニングクレーム → シーケンス型フロー
デバイス、ゲートウェイ、サーバーを縦の列に、間に番号付きメッセージを:登録、鍵交換、アテステーション——認証クレームが必要とする構造です。
データ処理クレーム → パイプラインブロック図
取り込み、エッジでのフィルタリング、集約、クラウド分析を、データフロー矢印付きの番号付きステージとして。
オフィスアクションを招く IoT ダイアグラムの失敗
コネクテッドデバイス図面に特有の失敗パターンです。
装飾的なクラウド
符号のないふわふわしたアートのクラウドは装飾であって開示ではありません。クラウドプラットフォームは他の要素と同じく、参照符号付きのラベル付きブロックか素っ気ない輪郭として描いてください。
クレームと矛盾するデバイス数
「複数のセンサーノード」を記載するクレームを1個のノードで支える——あるいはクレームの論理が2クラスを要求するのに3ノードを描く——のは指摘の元です。トポロジーをクレームの鏡にしてください。
ゲートウェイ層の欠落
クレームがゲートウェイやハブを記載しているのに、デバイスからクラウドへ1本の矢印に潰してしまうと、クレームされた要素を消すことになります。記載された層にはすべてブロックが必要です。
番号のないプロトコルステップ
ステップ番号のないフローチャートは明細書からもクレームからも引用できません。すべての箱に番号を付け(102、104、…)、系列を図面ごとに保ってください。
汎用ダイアグラムツール vs PatentFig AI
Visio でもネットワーク図は描けます。しかし特許図面には、より厳しい規則と、整合を保つべきより長いセットがあります。
PatentFig AI が合うのは
- 出願にトポロジー図、デバイス図、フローチャートが1つの整合したセットとして必要なとき
- クレーム補正のたびに方法ステップの番号を振り直す必要があるとき
- 出発点がアーキテクチャのスケッチやスライドのダイアグラムのとき
- ファミリーを USPTO 以外にも出願し、複数庁チェックが必要なとき
他のツールが合うのは
- 必要なのが特許図面でなくエンジニアリング用のネットワーク図のとき
- クレームがデバイス層のない純粋なソフトウェアで、汎用フローチャートツールで足りるとき
- 訴訟級のセットに専門家の認証が必要なとき
業界別ガイド