IT・ソフトウェア分野、ビジネスモデル特許、UI特許の取得例の紹介

以前にもちょいちょい紹介していますが、最近特に、IT分野の特許出願件数が伸びています。
これからのIT系スタートアップは、特許にも注力すべきだと考えています。

ただ、特許に慣れていない方にとっては、どういうものが特許になるのかピンと来ず、もやもやした疑問を持っている方も多いです。
例えば、
・ソフトウェアで特許って取れるの？
・IT系の特許って、弱くて回避可能なので取る意味ないんじゃないの？
・そもそもビジネスモデル特許って何？
・UI特許が強いって聞いたけど、どういう風に取るの？
・AIの特許って取れるの？どういう観点で取るの？
みたいな。

こういう疑問に対しては、言葉で説明してもなかなか難しく、具体的にどのような特許が取れているかという取得例を見てもらうのが一番分かりやすいのではないかと思います。

ということで、うちの事務所でこれまで取得した、IT分野の特許の取得例を、いくつか紹介します。

 

特許の見方

と、その前に、いきなり特許の公報を貼って、こんな特許が取れてますよと言っても、それをどう見るか分からないと思うので、特許の見方を説明しておきます。（分かる人は読み飛ばしてください）

特許は、
・願書
・特許請求の範囲
・明細書
・図面
・要約書
という５つの項目からなります。

願書は、出願人や発明者を記載するところで、特許公報の最初のページ上部がそれに当たります。

次に特許請求の範囲ですが、これが一番大事な項目です。特許請求の範囲に書かれている記載でもって、権利範囲が決まりますし、新規性進歩性などの審査も特許請求の範囲に書かれている事項で判断されます。

特許請求の範囲は、請求項１から始まって、請求項２、請求項３・・と続いていきます。
請求項１に一番広い概念の発明を記載しておいて、請求項2以下ではそれを段階的に限定していく記載となっています。
なぜこのような書き方をするかというと、権利の広さと特許の取りやすさはトレードオフの関係にあり、つまり発明を具体的に限定するほど権利範囲は狭くなるが、具体化するので特許は取りやすくなる。理想的には余計な限定を加えず広い範囲で取りたいが、あまり広すぎると発明が抽象化して新規性進歩性が認められにくくなる。そこで、請求項を分けて段階的に限定することによって、どこまで限定すれば特許が取れるかを審査段階で見極めるために、このような段階的な限定を加える請求項の書き方をします。

ここから紹介するのは登録になった後の特許公報なので、請求項１の内容で権利が取れている状態です。このような特許公報を見る場合は、請求項２以下はあまり重要ではなく、請求項１だけを見て、権利範囲を確認することができます。

ただ、請求項の記載は独特で、権利範囲を広くするために抽象的な表現がされているため、これだけ見ても具体例がよく分かりません。そこで、明細書や図面という、具体例が書かれている項目や、要約書を見ることで、具体的な内容を把握する、ということになります。
乱暴な言い方をすると、明細書や図面は特許請求の範囲の内容を説明するためのものであって、権利範囲は原則として特許請求の範囲の文言で決まります。

なので、以下の紹介では、請求項１の文言を基本的に紹介していきます。
請求項１の中にも、複数の構成要件が書かれていますが（AとBとCを備える発明、みたいな）、この全ての構成要件のAND条件で権利範囲が定まります。

 

 

IT分野の特許の取得例

特許6442807　対話サーバ

【請求項１】
既登録の質問パターン及びそれに対する回答パターンをもとに質問回答を行う対話サーバであって、
回答パターンとそれに対応する質問パターンとを記憶する記憶部と、
ユーザ端末に対話形式のインタフェースを提供し、ユーザ端末により入力された質問文を取得する質問文取得部と、
前記取得した質問文と記憶部に記憶している前記質問パターンとの類似度を算出する類似度算出部と、
前記算出された類似度に基づいて、対応する回答パターンをユーザ端末に表示させる回答パターン表示部と、
管理者端末に対話形式のインタフェースを提供し、前記管理者端末により入力された質問文と類似度が高い質問パターンに対応する回答パターンを、前記管理者端末に表示させ、表示された回答パターンの承認、または、別の回答パターンの選択により、入力された質問文を新たな質問パターンとして、承認または選択された回答パターンに関連付けて記憶させ学習を行うトレーニング部と、を備える対話サーバ。

チャットボットAIに関する発明ですが、アルゴリズムではなくUIの特徴で特許を取得しています。

チャットボットを賢くさせていくにはトレーニング（質問と回答というデータセットを追加させていく作業）が欠かせませんが、管理者端末でそのトレーニング作業をする際にも、ユーザと同じような対話形式のUIを提供して、入力した質問に対応する回答から適切なものを選択することで、学習をさせていく、という内容です。これによって、ユーザと同じような気持ちで、この質問文入れたらどうなるかな？と試しながら学習データの蓄積ができるという効果ですね。

これがいわゆるUI特許と呼ばれるようなもので、アルゴリズムの特許だとなかなか侵害しているか分かりにくいですが、UIの特徴で特許を取っているので、トレーニングを行う管理者アカウントにも対話形式のインタフェースを提供していたら大体侵害、みたいな強い特許となっています。

UI特許と言っても、意匠のように図面で直接権利範囲を定めるのではなく、あくまでも文章で表示制御の特徴を表現することになります。

JPB-0006442807

特許6379271　見守りシステム

【請求項１】
移動端末を携行する見守り対象者の位置をモニタリングする見守りシステムであって、
現在位置を取得する手段を有する前記移動端末と、前記移動端末から信号を受信するサーバと、前記サーバと通信可能に構成され見守り者が前記モニタリングに用いる見守り端末と、を備え、
地図上に略円形の領域を複数重ね合わせてエリアを定義し、定義した前記エリアを設定するように構成されたエリア設定部と、
前記移動端末の前記現在位置が設定された前記エリア内にあるか否かを判定する判定部と、
前記判定部の判定結果に基づいて、前記移動端末の現在の位置が設定された前記エリアから逸脱した旨の通知を前記見守り端末に送信する通知部と、
を含み、
前記エリア設定部は、ライン設定モードを選択する操作を受け付けると、
地図を表示中の前記見守り端末の表示画面の上において、第１のタップ操作が完了した後に、前記第１のタップ操作の操作位置とは異なる位置で第２のタップ操作を受け付けることで、
前記表示画面に表示中の地図上において、前記第１のタップ操作の操作位置と前記第２のタップ操作の操作位置の間を結ぶ線に沿って、隣接する略円形の領域同士の径方向における重複幅が各々の前記略円形の略半径となるように複数の前記略円形の領域を重ね合わせて自動配列する、
見守りシステム。

見守り対象者の位置が、設定したエリアを外れるとアラームを出すというシステムで、それ自体は公知の技術。
そのエリアの設定の仕方に関するUI特許で、2点をタップするとそれを適切な間隔の円で結んでエリアを作成するというものです。
頑張れば回避はできる権利範囲ですが、円によるエリア作成のモジュールの組み合わせのみでエリア設定ができるという点で、実装の観点で最も簡易かつ現実的なやり方を押さえることができているので、わりと良い特許という評価です。
見守りシステム自体は公知のものですが、UI的な工夫の観点を掘り下げることで特許取得可能という良い例かと思います。

JPB-0006379271

特許6347532　評価装置

【請求項１】
Ｗｅｂサイトへのユーザのアクセス状況を取得するアクセス状況取得部と、
前記ユーザの前記Ｗｅｂサイトへのアクセスごとの読了率を算出する読了率算出部と、
所定期間における前記読了率の総和が閾値以上の高エンゲージメントユーザを抽出するユーザ抽出部と、
前記高エンゲージメントユーザの数及び／又は割合に基づき、前記Ｗｅｂサイトの評価値を算出する評価部と、を備える評価装置。

Webサイトの評価をするシステムで、評価手法に特徴のある特許です。
PVや滞在時間を用いるものはよくありますが、読了率の高いユーザの数や割合で評価スコアを出すというものです。
このような特許では、最終的にはスコアを算出する式がありますが、そこまで限定する必要はなく、どのような情報を基にスコアを出すか、という程度で特許が取れるものもあります。
今回の特許はまさにそれで、読了率が高いユーザを抽出して、そのユーザの数か割合かを使って評価をすれば侵害、という権利範囲なので、かなり広い特許となっています。
何の情報に基づいて、何を出力するかという、インプットとアウトプットの特徴で特許を取りに行くのが原則かなと思います。

JPB-0006347532

特許6315528　異常検知モデル構築装置

【請求項１】
アルゴリズムに基づいて異常を検知する異常検知モデルを構築するための異常検知モデル構築装置であって、
時系列のサンプリングデータをデータセットとして受け付けるデータ取得部と、
前記データ取得部が取得したデータセットが、予め定められた複数の特性のうちユーザによって選択されたいずれか一つ以上の特性を有しているか否かを判別する特性判別部と、
前記データセットにおいて、ユーザによる正常データ又は異常データの特定を受け付けるデータ特定受付部と、
前記いずれか一つ以上の特性のうち前記特性判別部により特性を有していると判別されたいずれか一つの特性に関連づけられた前記アルゴリズムに基づいて、前記データセットに対して異常検知のシミュレーションを実行し、前記データ特定受付部が特定を受け付けた正常データ又は異常データを正答とした場合の該アルゴリズムの評価を行うシミュレーション実行部と、
を備えることを特徴とする異常検知モデル構築装置。

　AIを用いた異常検知に関するシステムの特許ですが、AIのアルゴリズムではなく、入力してデータに応じた異常検知モデルを構築するという、汎用的なモデル構築の機能に関する特許です。
　それぞれの検知モデル自体はOSSを用いていて、OSSを使っているというだけで特許は取れないと考えられがちですが、それらをどう組み合わせるかという機能が特徴的であれば、特許を取ることができます。

JPB-0006315528

特許6161141　検出システム

【請求項１３】
ネットワークを介して種類が異なる複数の検出器から送信される前記複数の検出器が検出した情報である検出情報と検出器の特性を示す特性情報とを受信する通信部と、
前記検出器の種類を特定する前記特性情報に関連付けられている同じ種類の検出器に共通する変換アルゴリズムを記憶する記憶部と、
前記通信部で受け付けた前記特性情報に対応する前記変換アルゴリズムを用いて、前記通信部で受け付けた前記検出情報を共通フォーマットの出力情報に変換する制御部とを備えることを特徴とするサーバ。

IoTにおけるサーバの機能に関する特許です。
センサによって出力されるデータの形式が異なるので、サーバ側でそのフォーマットを正規化するという、ある意味IoTサーバに必須で求められるような機能で権利化できています。
IoTの分野においては、センサ側・通信規格・サーバの機能と様々な観点から権利化ができますが、サーバ側の機能で特許を取るのが比較的取りやすいように感じています。

JPB-0006161141

特許6157711　コンテンツ提供装置

【請求項１】
自撮りにより生成されたコンテンツの投稿を受け付ける投稿受付部と、
前記投稿受付部により受け付けたコンテンツが所定の基準を満たしているかどうかを判断する判断部と、
前記判断部により前記所定の基準を満たしていると判断されたコンテンツをコンテンツ記憶部に記憶する記憶処理部と、
前記コンテンツ記憶部からコンテンツを読み出し、読み出したコンテンツに基づいてプレビュー用のコンテンツを生成する生成部と、
前記生成部により生成されたプレビュー用のコンテンツを出力する出力部と、
端末装置からコンテンツを購入するリクエストを受け付けるリクエスト受付部と、
前記リクエスト受付部により受け付けたリクエストに応じて課金処理を行う課金処理部と、
前記課金処理部による課金処理が行われた後に、リクエストされたコンテンツを前記コンテンツ記憶部から読み出し、読み出したコンテンツを端末装置に送信する送信部とを備え、
前記所定の基準を満たしているとは、少なくとも、コンテンツに投稿者本人が含まれている場合をいうコンテンツ提供装置。

自撮りコンテンツを販売するという新しいビジネスモデルを保護するための特許。いわゆるビジネスモデル特許（ビジネス関連発明）に当たるものです。
ビジネスモデル特許と言うと、ビジネスモデル自体を保護する特許だと誤解されがちですが、実際にはそのビジネスモデルを実現するための機能を備えたサーバとして特許を取ることが多いです。
ビジネスモデルを実現する最小限の機能だけだと、なかなか進歩性が認められにくく、今回の場合は、コンテンツが満たすべき要件（投稿者本人が写っていること）をサーバ側で判断するという機能込みで権利化が出来ています。

JPB-0006157711

特許第5988345号　評価装置

【請求項１】
Ｗｅｂサイトにおいて第１情報が埋め込まれている記事のアクセス状況を解析する第１解析部と、
前記第１解析部の解析結果に基づいて、前記記事のパフォーマンスデータを生成するパフォーマンスデータ生成部と、
前記記事の内容を解析する第２解析部と、
前記第２解析部の解析結果に基づいて、前記記事の特性を特定する記事特性特定部と、
前記パフォーマンスデータと前記記事の特性とを当該記事を作成したライターに関連付ける関連付け部と、
前記パフォーマンスデータに基づいて、ライターの評価を行う評価部と、を備える評価装置。

タグを埋め込んだ記事から、アクセス状況と記事の特性（分野等）を取得して、
ライターと紐づけて、ライターの評価を行うというシステムの特許です。
これも、具体的な評価の仕方のアルゴリズムや解析手法ではなく、インプットとアウトプットのみの特定で特許を取れているので、かなり強い特許になっていると思います。

JPB-0005988345

特許第6346708号　遊興提供システム

【請求項１】
複数の消費者の支払い関連情報を取得する情報取得部と、
前記情報取得部が取得した支払い関連情報が示す支払い相当額に基づいて、複数の前記消費者のいずれか一人以上にベット権を設定するベット権設定部と、
前記消費者が前記ベット権に基づいてベットしたベット情報を受け付けるベット情報受付部と、
前記支払い相当額の合計値に基づいて、賞金の合計値の上限値を算出し、該支払い相当額の個別値に基づいて、前記ベットを行った前記消費者ごとに該ベットが当たった場合に支払われる賞金の個別値の上限値を算出し、算出した該賞金の合計値の上限値及び該賞金の個別値の上限値に基づいて、前記消費者ごとの前記賞金を設定する賞金設定部と、
当たりが確定した前記ベットを行った前記消費者に対して、前記賞金設定部が設定した前記賞金を受領する権利を与える受領権付与部と、
を備えることを特徴とするサーバ装置。

支払い関連情報に基づいてベット権を付与して、そのベットに対する賞金の上限を設定するというシステムの特許です。
賞金の上限設定は法令に基づいて定められるものですが、それを適切に設定するためにシステムで支払い関連情報を取得して、設定するという内容。
以前に別の記事でも書きましたが、法改正に伴って、それに適切に対応するための特許というのは、強い特許を取得するチャンスになることがあります。

JPB-0006346708

 

 

以上、いくつかの特許の取得例を紹介しました。

冒頭の質問に言葉で回答するより、実際の特許の例を見て、こんな特許が、こんな権利範囲で取れているんだと確認する方が分かりやすかったんじゃないかと思います。
参考になれば幸いです。

 

 

 - スタートアップ, 特許

  関連記事