ビジネスモデル特許の例としては、Amazonのワンクリック特許など海外の古典的な事例が有名です。本記事では視点を変えて、日本のフィンテック企業が2014年以降に実際に登録した特許5件を取り上げます。すべて当所がGoogle Patentsの実ページで権利者・登録日・請求項を確認したものです。銀行アプリの貯蓄機能、会計の自動仕訳、口座連携、決済連動の特典、ロボアドバイザー——「審査を通った仕組み」には共通の型があります。金融分野のビジネス関連発明の出願は2015年から2023年で2.7倍（特許庁調査）。競争は既に権利の層で起きています。
この記事の要点
目次
スマホ専業銀行「みんなの銀行」の看板機能である目的別貯蓄「ボックス」に対応する特許です。権利者は運営会社の親会社である株式会社ふくおかフィナンシャルグループ（「みんなの銀行の特許」と紹介されることが多いものの、登録上の権利者はFFGです）。請求項1は「目的別に貯める」というアイデアではなく、商品・サービスのコンテンツ表示→ユーザーの指定受付→指定コンテンツに関連する目的別預金の作成指示を受け付ける第1画面→預金情報を入力する第2画面へ、という画面遷移を伴う具体的な情報処理としてクレームされています（優先日2020年10月・登録公報2022年10月）。「欲しいものを見つける体験」と「貯蓄の開始」を画面遷移で直結させた点が仕組みの核です。
請求項1の構成を分説すると（要旨）
※Google Patents掲載の請求項に基づく要旨。A→B→C→Dという画面遷移の連鎖そのものが発明特定事項になっている点に注目してください。
クラウド会計の黎明期を象徴する特許です（登録2014年）。取引明細のキーワードから勘定科目を自動で選ぶ仕組みを、対応テーブルの参照と優先ルールという構成でクレーム化しました。この特許は、平成28年に提起されたマネーフォワードに対する訴訟（平成28年(ワ)第35763号）の対象となりましたが、東京地裁（平成29年7月27日・第一審判決）は権利範囲を、優先順位の最も高いキーワード1つで対応表を参照する構成に限定解釈し（判決の要旨）、機械学習による勘定科目の推測が窺われるとして被告製品を非侵害と判断しました。登録された特許でも、クレームの書き方次第で競合の別実装には届かない——事例集の中で最も実務的な教訓を含む1件です（詳細は拒絶理由あるある5選第6章）。
法人インターネットバンキングは電子証明書がなければログインできない——この制約下で明細を自動取得するため、電子証明書を持つユーザー端末とアグリゲーションサーバが連携してログイン・取得を行う構成を権利化したものです（登録2018年）。自社サーバー内で完結しない「外部システムとの境界」の課題を、端末とサーバの協働として解いた好例で、SaaSの連携レイヤーが権利化しやすいことを示しています（SaaS機能マップ診断のレイヤー②）。
2024年6月発行の新しい登録です。電子決済で購入した商品の識別子と決済情報を利用者端末から取得し、購入商品に応じた特典情報を提供する構成がクレームの骨格です。「決済データを販促に使う」というビジネス上の狙いが、決済情報＋商品識別子の取得→判定→提供という情報処理の流れに翻訳されています。決済プラットフォーマーが取引データの活用面まで権利の網を広げていることを示す1件です。
ロボアドバイザー草創期の2017年登録。請求項1は「有価証券の売買に用いられるサーバ装置」として、銘柄ごとの数量・時価単価・目標比率を記憶する記憶手段を起点に、目標比率とのずれを埋めるようにリバランスを伴う追加投資を演算する構成です。投資アルゴリズムの思想ではなく、記憶するデータ項目と演算の構成で特定している点が、境界線の内側に入るための定石どおりの作りです。
対照的に、同じ金融分野でも、電子記録債権の決済方法事件（知財高判令和2年6月18日）では、信号送信への言及があっても発明の実体が金融取引の業務手順というビジネスルール自体にあるとして発明該当性が否定されました。①〜③の型を満たすかどうかが、フィンテックにおける「取れる/取れない」の分水嶺です（理論面はビジネスモデル特許の境界線の記事で解説）。
特許庁の調査（2025年12月公表版）によれば、金融分野（特許分類G06Q20/＝決済アーキテクチャ、G06Q40/＝バンキング・保険等の合算）の日本への出願は、2015年の489件から2023年の1,315件へと約2.7倍に増えました。2015〜2023年の累計は8,686件で、うち日本国籍の出願人が7,196件と大半を占める一方、米国籍752件・欧州籍274件と海外勢の参入もあります。なお、この調査に決済・融資・保険・資産運用といったサブ分野別の内訳統計はなく、分類上はG06Q20（決済）とG06Q40（金融一般・保険）の2区分が合算されています。年間1,300件超──本記事の5件は氷山の一角であり、自社の機能領域で誰が何を出願しているかの定期ウォッチは、フィンテック事業の標準装備になりつつあります。
5つの事例に共通する「型」を、自社機能に当てはめるワークです。プロダクトチームの1時間のミーティングで一巡できます。
| ステップ | やること | 事例での対応物 |
|---|---|---|
| ①自慢の機能を1つ選ぶ | ユーザーに褒められる／競合に真似された機能 | 目的別預金「ボックス」 |
| ②ビジネスの狙いを書く | 「なぜその機能があるのか」を1行で | 「貯蓄を始める心理的ハードルを下げたい」 |
| ③情報処理に翻訳する | 狙いを実現する画面遷移・データの流れ・判定条件に落とす | コンテンツ表示→指定受付→作成画面→入力画面の遷移 |
| ④処理の主体を割り当てる | 各処理を端末／サーバ／記憶部のどれが担うか明確化 | 「売買に用いられるサーバ装置」「記憶手段」 |
| ⑤将来の別実装を考える | 競合が同じ狙いを別の実装で実現する方法を3つ挙げ、クレームの抽象度を検討 | freee事件の教訓（ルールベース限定がML実装に届かず） |
③まで書ければ発明説明シートの主要項目は埋まっています。⑤は専門家との協働領域です──ここを一人で悩む必要はありません。
①金融分野のビジネス関連発明は出願が2.7倍（2015→2023年）に増え、銀行・会計SaaS・決済・ロボアドの各領域で「普通に使っている機能」が既に権利化されている。②審査を通る仕組みには型があり、UI・連携・データ構成として設計すれば境界線の内側に入る。③ただしfreee対マネーフォワード事件のとおり、権利の価値はクレーム設計で決まる——将来の別実装まで見据えた抽象度の設計が必要。新機能のリリース前が出願の勝負どころです（出願の流れ完全ガイド）。
A. 出せます。特許に業種の制限はなく、本記事の事例もIT企業・スタートアップが中心です。金融機関との協業サービスの場合は、権利の帰属（共同出願か単独か）を契約で整理しておくことが重要です。
A. 役割が違います。画面デザインの見た目は意匠（画像意匠）、画面遷移・表示制御の仕組みは特許が受け皿です。ふくおかFGの事例のように遷移の連鎖に仕組みの価値がある場合は特許、ビジュアルの独自性が価値なら意匠、両方に価値があれば併用を検討します。
A. まず自己判断で撤退や設計変更を決める前に、クレームの構成要件と自社実装を突き合わせる侵害予防調査（FTO）をおすすめします。クレームの構成要件を一つでも充足しなければ文言上の侵害は成立せず（均等侵害の検討は別途必要です）、回避設計の余地が見つかることも多くあります（FTO調査の完全ガイド参照）。
A. 本記事は各特許の要旨を紹介したものであり、侵害の成否はクレームの全構成要件と実装の対比によって決まります。機能名や見た目が似ていることと、クレームを充足することは別問題です。心配な場合は個別にご相談ください。
フィンテック・金融サービスの特許相談：自社機能の権利化候補の洗い出し、競合特許の調査（FTO）にも対応します。知財事務所エボリクスのお問い合わせフォームよりご相談ください。
この記事の監修
弁理士 杉浦健文（日本弁理士会 登録第19446号／知的財産事務所EVORIX）。IT・ソフトウェア・AI分野の特許出願を中心に扱い、AI関連発明の特許化をテーマとするセミナー講師の実績があります。記事中の特許はGoogle Patents等の実ページを確認のうえ記載しています。
【免責事項】本記事は2026年7月18日時点の公開情報（Google Patents掲載の登録特許・特許庁「ビジネス関連発明の出願状況調査」・裁判所ウェブサイト掲載の判決等）に基づく一般的な解説であり、法的助言ではありません（2026年7月19日増補）。記事中の特許はいずれも実ページで書誌事項を確認していますが、請求項の分説・要旨は理解のための要約であり、権利範囲の解釈・有効性の評価を示すものではなく、掲載企業と当所の間に取引関係があることを示すものでもありません。権利化ワークは簡易的な整理の手法であり、個別の判断に代わるものではありません。