情報検索コラム
情報検索・調査・利用について
“知っていると便利”“こんなときどうする”“コレにはご注意！”などなど思いつくままに書かせていただきます。
ちなみに「三月うさぎ」はルイス・キャロル著『不思議の国のアリス』に出てくる「いつまでも終わらないお茶会をしている」ちょっとヘンなうさぎです。
「ティールーム」は、お仕事の休憩時間のお茶といっしょに読んでいただけるくらいの長さと内容というコンセプトを、アリスの三月うさぎの「お茶会」にかけてあります。（毎月1回更新します）
ビジネス方法特許の調査での注意点 ーICTの具体的内容を確認ー
注意：記載内容やリンクは執筆時点での情報です。
ビジネス方法、またはビジネスモデルの特許。このような特許はビジネス方法のアイディアそのものが特許になるわけではありません。このことについて特許庁のウェブページでは次のように説明しています。
----------
ビジネス関連発明とは、ビジネス方法が ICT（Information and Communication Technology: 情報通信技術）を利用して実現された発明です。特許制度は発明の保護を通じて産業の発展に寄与することを目的としており、販売管理や物流、生産管理などのビジネス方法のアイデアそのものは特許法上の発明とは認められず、特許の保護対象にはなりません。一方で、ビジネス方法のアイデアが
ICT を利用して実現された発明は、ビジネス関連発明として特許の保護対象となります（出典：ビジネス関連発明の出願状況調査 2025年12月 特許庁 審査第四部 審査調査室 https://www.jpo.go.jp/system/patent/gaiyo/sesaku/biz_pat.html）
----------
このようなことは特許関連の仕事をしてる我々には常識なのですが、一般のかたは正しく理解していない場合が多いと思われます。よってビジネス方法特許の意味を正しく理解していないかたから特許調査の依頼をいただくこともあるわけです。このとき調査依頼者がビジネス方法特許の意味を正しく理解していないということに気付かないまま調査を進めると、少し（場合によってはかなり）厄介な事態になってしまうことが多いです。
というわけで今までに見てきたいくつかの事例から、ビジネス方法特許の調査を行う場合の注意点を書きたいと思います。コラムのポイントは、ICTの具体的な内容が示されているかどうか、です。ビジネス方法特許の調査ではこの点に注意する必要があります。
なお今回のコラムは実際の特許公報から３件を引用しました。公報の文章は読みにくいと思います。「具体的な内容が示された例１」「具体的な内容が示された例２」「具体的な内容が示されていない例」の３例のうち、「具体的な内容が示された例２」だけ読んで頂いても構いません。後半で引用するのは２番目の「具体的な内容が示された例２」だけですので。もっと言うと、いっそ３例とも読まずに後半の「具体的な内容が示されていない発明を調査するとどうなるか」の項から読んでいただいても大丈夫だと思います。
ICT（情報通信技術）の具体的な内容が示されているかどうか
上で引用した特許庁の説明では「ビジネス方法が ICT（Information and Communication Technology: 情報通信技術）を利用して実現」と書かれていますが、単にICTを使っているだけでは不十分です。ICTの具体的な内容が示されているかどうかを確認する必要があります。
例えば次のような場合に注意が必要です。
----------------------------------------------
【例１】
お客様側から特定のデータを通信回線を通じてサーバーが受信
↓
解析・処理する
↓
お客様側へ結果を返信
↓
お客様に結果が表示される
----------------------------------------------
----------------------------------------------
【例２】
お客様側に特定のデータを処理するアプリケーションソフトをダウンロードしてもらう
↓
お客様が内部または外部の特定のデータを受信
↓
アプリケーションソフトが特定のデータを解析・処理する
↓
解析・処理した結果、お客様側の機器が制御される
----------------------------------------------
例１、例２とも色文字の箇所がICTを使っています。そのためビジネス方法特許に該当するのですが、特に大事なのは情報技術である解析や処理、制御の具体的な内容です。調査を依頼された時点のヒアリングのときに、情報技術について具体的な内容が示されるかどうかが大事です。
具体的な内容が示された例１、例２
私たちサーチャーに依頼される場合は調査ですが、ビジネス方法を特許出願したい場合は弁理士への依頼になります。特許出願するときは基本として明細書に情報技術についての具体的な内容を書きます。
例えば特許請求の範囲に「解析する」「処理する」「制御する」等と書いた場合に「解析」「処理」「制御」がどのように行われるのか、明細書に具体的に明記する必要があります。
●具体的な内容が示された例１：特表2012-511190 「 」内は特表2012-511190から引用
具体的な内容が示された例として「特表2012-511190」の請求項と詳細な説明から引用します。特表2012-511190の発明の名称は「メッセージ処理のための方法及びシステム」です。発明の内容は段落０００４に書いてあるとおり「例えば、電子商取引において、取引が成功裏に成されたとき、取引処理システムなどのメッセージ配信者は、その取引の成功を通知する通知メッセージを送信」する技術です。特に「取引ログサーバなどのメッセージ購読者は、取引ログを記録するためにその通知メッセージを購読登録し、売り主通知サーバなどの別のメッセージ購読者もまた、商品が売れたことを売り主に通知するためにその通知メッセージを購読登録し得る。」と書かれているとおり「通知メッセージ」は「取引ログサーバなどのメッセージ購読者」と「売り主通知サーバなどの別のメッセージ購読者」の双方に「通知メッセージを送信」する技術です。ビジネス方法特許にズバリ該当します。
この技術について【請求項１５】に次のような記述があります（・・・は省略箇所）「メッセージ処理システムであって、 メッセージタイプを含むメッセージを配信するように構成されたメッセージ配信者と、 ・・・メッセージ購読者ノードに前記メッセージを送るように構成される、 ミドルウェアサーバと、 前記メッセージを受信して、前記メッセージの内容に基づいて適切な処理行動をとるように構成された前記メッセージ購読者ノードと、 を備えるメッセージ処理システム」。要するに「メッセージ処理システム」として「メッセージ配信者」と、「メッセージを受信」する側の「メッセージ購読者ノード」について書かれています。この記述の中の「適切な処理行動」に注意してください。
請求項１５を読んだだけでは「メッセージ購読者ノード」で行われる「適切な処理行動」がどんな処理行動なのか具体的には分かりません。これについて段落００３８には次のように書かれています。「メッセージを受信すると、ノードは、メッセージを処理して適切な行動をとる。例えば、取引成功メッセージがログサーバ及び売り主通知サーバによって受信された場合には、前者はログ情報を更新し、後者はｅｍａｉｌ（電子メール）による通知を売り主に送信する」。具体的かつ明瞭な記述です。つまり請求項１５の「メッセージ購読者ノード」は複数です。段落００３８では例として「ログサーバ」と「売り主通知サーバ」の２つのノードが示されます。そして「前者（注：ログサーバ）はログ情報を更新」することが「適切な処理行動」であり、「後者（注：売り主通知サーバ）はｅｍａｉｌ（電子メール）による通知を売り主に送信」することが「適切な処理行動」であることが分かります。
●具体的な内容が示された例２：特開2022-031032 「 」内は特開2022-031032から引用
具体的な内容が示されたもうひとつの例として「特開2022-031032」の請求項と詳細な説明から引用します。特開2022-031032の発明の名称は「搬送装置」です。「製造工程における物品の搬送に用いる」技術です。特許請求の範囲の【請求項３】には次のように書かれています。「前記搬送経路には、前記物品に対して処理を施す処理部が配置されており、
前記制御部は、前記物品の位置情報に基づいて、前記物品に適切な処理を施すように前記処理部の動作を制御する」。太文字で示した箇所に書かれている「適切な処理」「動作を制御」は抽象的な書き方であり、どのような処理や制御なのかを発明の詳細な説明に書く必要があります。またよく読むと「物品の位置情報」という記述も抽象的な表現であり、どのような「情報」なのかが不明確です。
この点について段落【０２０９】に次のとおり書かれています（・・・は省略箇所）「物品Ｐｃを保持していると判断した場合・・・、制御部６００は、励磁コイル情報Ｉｍから物品Ｐｃの第１搬送経路Ｔｃ１における位置を取得する・・・。そして、制御部６００は、物品Ｐｃに適切な処理が行われるように、ストロー貼付部２５および不良品排除部２６の動作を制御する・・・。このように、制御部６００では、物品Ｐｃの位置を正確に取得して、処理部を制御することで、物品Ｐｃに対して適切に処理を行うことができる」。制御部が位置情報として「励磁コイル情報」を取得すること、ストロー貼付部および不良品排除部の動作を制御すること、そして「物品Ｐｃの位置を正確に取得して、処理部を制御する」ことが適切な処理であることが明記されてます。
このようなアイディアをもとに出願前調査をサーチャーに依頼したのであれば、制御として物品の「位置」を取得すること、そして位置情報の取得に「励磁コイル」を使うこと、「ストロー貼付」が処理されること、「不良品が排除」されることが分かります。この特開2022-031032は通信は使わないためビジネス方法特許ではありませんが、情報処理について書かれている分かりやすい例として引用してみました。
具体的な内容が示されなかった例
特許請求の範囲に「解析する」「処理する」「制御する」等と書いてあるけれど、「解析」「処理」「制御」がどのように処理されれることを指すのか、明細書に具体的に明記されていないものを見てみます。
●具体的な内容が示されていない例：特表2014-505299 「 」内は特表2014-505299から引用
「特表2014-505299」の発明の名称は「マイクロウェブログのメッセージを処理するための方法および装置」です。そして【請求項１】には次のように記述されています（・・・は省略箇所）「マイクロウェブログのメッセージを処理するための方法において、統一されたリッチメディアの制御が、マイクロウェブログシステムのそれぞれのクライアント側で構成され、前記リッチメディアの制御が、リッチメディア情報の操作の種類およびメディアの種類に応じてリッチメディア情報処理ロジックをカプセル化することによって得られる、方法であって、前記マイクロウェブログシステムの前記クライアント側によって、マイクロウェブログのメッセージのリッチメディア情報を処理するための操作要求を受信するステップと、前記マイクロウェブログシステムの前記クライアント側によって、要求されたリッチメディア情報の前記操作の種類および前記メディアの種類に応じて対応するリッチメディアの制御を呼び出し、前記制御を実行して前記リッチメディア情報を適切に処理するステップと、を含む方法。」
一通り読んだだけでは何を言っているのか分からないかもしれませんが、段落０００５に書かれているとおり（・・・は省略箇所）「既存のマイクロブログシステムの（上述のさまざまなページまたはホームページのような）メッセージページおよびリストページなどのさまざまなページは、・・・さまざまなページでリッチメディア情報を運ぶマイクロブログのメッセージを処理するためには、各ページで対応するロジックをそれぞれ実行する必要があり、このことは、コードのロジックの冗長性、より低いマイクロブログシステムの効率、および保守の難しさなどの多くの問題を引き起こすことが避けられない」であり、要するに「メッセージページおよびリストページなどのさまざまなページ」の処理を「各ページで対応するロジックをそれぞれ実行する」のは非効率だし保守も大変だということです。この問題の解決方法として請求項１に「クライアント側によって、要求されたリッチメディア情報の前記操作の種類および前記メディアの種類に応じて対応するリッチメディアの制御を呼び出し、前記制御を実行して前記リッチメディア情報を適切に処理する」と書かれています。簡単に言えば様々なページのメッセージについて「クライアント側」で「リッチメディア情報を適切に処理する」ことにより問題を解決する技術思想です。
前置きの説明が長くなりましたが注目してほしいのは「リッチメディア情報を適切に処理する」という記述です。この「適切に処理」が何を行うことなのか、発明の詳細な説明（明細書）を読んでも具体的に書かれていないのです。
この特表2014-505299の拒絶理由通知書には次のとおり書かれています。
「請求項１には「前記制御を実行して前記リッチメディア情報を適切に処理する」との記載があるが、「適切に処理する」とは具体的にメディア情報をどのように処理することを示すのか、明らかでなく発明が不明確である。」（出典：拒絶理由通知書
(特許出願2013-548723)）
この拒絶理由通知書に対して意見書が出されていて、請求項の補正として「適切に処理する」という記述から他の記述に変更していますが、最終的に特表2014-505299は拒絶査定です。
いずれにしても「適切に処理する」は抽象的な表現であり、具体的な内容が示されていません。
具体的な内容が示されていない発明を調査するとどうなるか
上の項で引用した特表2014-505299は「処理」の具体的な内容が示されない状態で特許出願されたものですが、私たちサーチャーに依頼される場合は調査です。例えば製品システム開発にあたって他社の権利侵害を回避したいという依頼の場合に、「解析」「処理」「制御」の具体的な内容が示されないまま調査するとどうなるか、です。
例えば複数の工場で稼働中の機械の様々なデータを取得してデータ処理センターへ送信し、センター側でデータ解析・評価して機械の故障予兆を検知する、という技術について侵害回避調査するとします。この場合に取得する「様々なデータ」が具体的に示されること、「解析・評価」の方法（アルゴリズム）が示されることが必要です。取得するデータならば、速度、温度、角度、位置、振動など様々なデータのうちの何を取得するのか。そして取得方法は何を使うのか。例えば上の例２では「位置」を取得する技術でであり、さらに「励磁コイル」が使われていました。また「解析・評価」を行うときは様々な条件や項目、変数、判断基準値などプログラムに組み込む内容は何なのかが具体化されている必要があります。特許権侵害の大原則は当該製品（イ号：製品化予定のシステム）が他社の特許請求の範囲の全てを含んでいること、です。よって実際に調査する場合は、これらの具体的な条件を考慮した検索を行い、侵害するかしないかの判断はイ号システムの内容と、特許公報の請求項とを照合します。もしも特許公報の請求項にイ号システムに含まれない限定事項が含まれていれば侵害回避できる可能性は高い。しかし特許公報の請求項の全てがイ号システムに含まれていれば侵害の恐れあり、です。
このイ号システムと特許公報の対比・照合を行う場合に、もしもイ号システムの具体的な内容が示されていないならどうなるか。一般的に特許請求の範囲に書かれる発明内容は技術的な特徴が記載されています。取得するデータならば、速度、温度、角度、位置、振動など様々なデータのうちの何を取得するのか、また特徴のあるデータを取得することが書かれている場合があります（例：始動直後から特定の時間内のデータを一定時間間隔を空けてN回取得する、など）。これら特許公報の細かな条件とイ号システムの具体的な内容との照合が必要であるにもかかわらず、イ号システムの具体的な内容が示されていないならば照合は行えません。しかも単に「データ取得 → センターへ送信 → 解析・評価」のみのアイディアだとすると、該当する特許公報が非常に多くなります。そのうえで侵害有無の判断不明のものばかりになる。つまり判断不明による多数の「要検討」の特許公報リストが調査結果となってしまいます。実際にそのような調査結果リストを見たことがあります。
だから調査する側の都合から言えば、侵害回避調査をするならば製品システムの仕様が決定した段階で依頼してもらえるのがベストです。しかし調査依頼者の立場から言えば、システム開発にあたって他社の特許を予め把握しておいて、それらの特許権を侵害しないように開発を進めたいという考え方はあると思います。もしも仕様が決定した段階で調査して、大きく仕様変更しなければいけなくなったならばロスは大きい。だから無駄なコストを避けるためには、大まかなアイディア段階で調査したい、というニーズです。
このように大まかなアイディア段階で調査したいという場合、よくあるケースとして例えば「取得するデータ」について「速度、温度、角度、位置、振動など」と指定されることがあります。この場合の問題点は「など」という指定です。本来は「など」は調査範囲が定まらないので調査条件としては不可です。しかし依頼者の立場から言えば、自分たちが想定していないものも知っておきたいというニーズはあると思います。
結果は分類・整理して報告する
上の項で説明したように、具体的な内容が定まっていなくて大まかなアイディア段階で調査したいという場合の調査は次のような問題点があります。
・該当する公報の件数が多い（独立項が広い範囲で該当する）
・イ号システムに関連する様々な構成要件（従属項での限定事項）が広く見いだされる
・それら多数の公報を依頼者側でチェックする作業は時間、労力とも大きい
このことから、調査結果は分類・整理して報告する方式が好ましいと思います。例えば一般的な侵害回避調査は、まず独立項を確認します。一般に独立項が該当しない場合はノイズ（明らかに無関係・侵害無し）ですが、具体的な内容が定まっていない場合は広く該当することになる場合が多いです。
独立項が該当する場合、従属項の特許請求の範囲に含まれる構成要件（限定事項）とイ号システムとの照合を行い、イ号システムに関連する限定事項である（Ｘ：要注意）、イ号システムに関連するかどうか不明の限定事項有り（Ｙ：要検討）、イ号システムに関連しない限定事項有り（Ａ：参考）等のランク付けします。しかし上で書いたように、具体的な内容が定まっていない場合は「Ｙ：要検討」ばかりの報告書になってしまう。よって普通の報告に使うＸ、Ｙ、Ａなどでの報告ではなく、Ｙの公報に示される構成要件・限定事項をチャートなどを使って分類・整理し、依頼者側でチェックしやすいかたちで報告するのが好ましいと思います。
分類・整理は例えば「速度、温度、角度、位置、振動など」と指定された場合に、「速度」「温度」「角度」「位置」「振動」のどれに該当するのか分類する。また「など」に含まれる構成要件は何なのかを仕分けながら報告する、という方法です。この方法を行う場合は、じつは調査前のヒアリングの段階から準備する必要があります。しかも、この方法はビジネス方法特許に限らず使える方法です。今回のコラムでは書ききれませんので回を改めて書きたいと思います。
というわけで今回のコラムはここまでです。長々書きましたがポイントはひとつです。具体的な内容が示されないにもかかわらずICTを使っているためにビジネス方法特許としての調査を依頼されたときは、依頼された段階で、このまま調査すると不十分な調査結果になってしまう案件であることを見抜かないと良い調査は行えないし、適切な調査報告は書けない、ということです。
今回のコラムで具体的な内容が示されていない例として引用した特表2014-505299について補足説明すると、意見書による請求項の補正で「適切に処理する」という記述に対する拒絶理由は解消されたようです。しかし「請求項 １－２９」について特許法第２９条第２項、つまり先行例技術文献有りで拒絶査定となっています。さらに付け加えると、特表2014-505299は優先権主張国を中国とした国際出願（国際出願番号:PCT/CN2011/084893）です。GooglePtentsで簡単に確認したところ、EP（欧州特許庁）やUS（米国）では特許登録されたようですが、JP（日本）は拒絶査定、CA（カナダ）では出願放棄のようです。特許登録されたEP、USは請求項から「適切に処理」に該当する記述は無くなっていました。参考まで。
