長雨（秋雨）が「眺め雨」だったとは何と粋な言葉でしょう。
　昨夜は寝入った後の１２時半頃に「レベル４の土砂崩れ注意報」で叩き起こされました。現代では粋な「眺め雨」なんて言っておられないようです。
　しかし、「レベル４の土砂崩れ注意報」が有りましたが、私共には、何事もなく、平穏・無事に過ごせました。
　ただ、朝になってから、〇〇小学校が避難場所になっている旨の放送が有りました。

　皆様の所も無事でございましたでしょうか？

　線状降水帯は本当に怖いですね。 

　日曜日（６日）は湯河原・光陽館の温泉に浸かって来ました。湯河原の旅館の多くは、町が敷設している共同配管を使っているそうです。しかし、光陽館は自身の源泉から自身の配管を使って温泉を引いているそうです。この為と言う訳ではないでしょうが、湯質は非常に良いです。勿論、源泉かけ流しで循環・消毒なしです。東京・埼玉・千葉と言った遠くから、わざわざ、入りに来る方も多いようです。先ずは朝８時に入りました。温泉から上がった後、幕山に在る「わっしょい（天然酵母パン屋さん）」に行った処、臨時休業。仕方なく、回転寿司花まるで昼食。この後、夕方５時に、もう一度、光陽館に。

　光陽館を出た後、話題のラーメン店・飯田商店へ。

　ラーメン店・飯田商店は写真の通り、外観は何でもない建物ですが、内部は料亭！
　テレビで１時間番組で３回も放映されております。
　ラーメン一杯が２１００円。しかし、あの材料で２１００円は安いと連れ合い曰く。
　そうでしょう。予め予約していないと食べられません。大阪・京都・名古屋からでもラーメンを食べに遣って来る！
　ラーメン代よりも交通費が…
　連れ合いは一度食べてみたいと言っております。

　ラーメン好きな方、一度、ネットで予約して召し上がってみては如何でしょうか。

　ラーメンを召し上がった後、光陽館の温泉に浸かれば、もう最高だと思います。 

　今回の知財情報はタクシー配車事件です。
令和６年（ワ）第７０５５号　損害賠償請求事件
令和８年（ネ）第１０００７号 損害賠償請求控訴事件
特許第６５４６５６２号
【請求項１】
　ネットワークにそれぞれ接続可能な、ユーザ端末と、タクシー移動端末と、アプリ管理サーバと、タクシー事業者端末と、を備え、
　前記ユーザ端末は、
　　ユーザ操作によりその端末にインストールしたアプリを起動し、ネットワークを介してアプリ管理サーバにアクセスし、タクシー迎車依頼地情報とタクシー選択範囲情報を送信し、
　　前記アプリ管理サーバからのタクシー情報を確認可能とし、前記タクシー情報の中からユーザが希望するタクシーを指定した配車確認要求を前記タクシー移動端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知し、
　　前記タクシー移動端末からの迎車可否情報を確認可能とし、
　　ユーザがタクシーへ乗車完了したとき乗車完了情報を前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知し、
　前記タクシー移動端末は、
　　その端末にインストールしたアプリを起動し、ネットワークを介して前記アプリ管理サーバにアクセスし、かつＧＰＳ機能を用いてポーリングによる位置情報を取得し、その位置情報を前記アプリ管理サーバに送信し、
　　前記ユーザ端末からの前記配車確認要求に応答して前記迎車可否情報を前記ユーザ端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知し、
　前記アプリ管理サーバは、
　　前記ユーザ端末から送信されたユーザ情報を登録するユーザ情報データベースと、前記タクシー移動端末から送信されたポーリング情報を受信して登録する移動端末情報データベースと、前記ユーザ端末からの前記配車確認要求、前記乗車完了情報、及び前記タクシー移動端末からの前記迎車可否情報を登録する結果情報データベースとを備え、
　　前記ユーザ端末から前記タクシー迎車依頼地情報と前記タクシー選択範囲情報を受信したとき、前記移動端末情報データベースを確認してユーザ希望の範囲に存在する前記タクシー情報を前記ユーザ端末に通知し、
　　前記タクシー移動端末から迎車可の情報を受信したとき、ユーザの前記タクシー迎車依頼地情報を前記タクシー移動端末に通知し、
　前記タクシー事業者端末は、
　　前記ユーザ端末からの前記配車確認要求、前記乗車完了情報、及び前記タクシー移動端末からの前記迎車可否情報を登録する結果情報データベースを備える、
タクシー配車管理システム。 

　宇高は、上記特許発明において、朱書き箇所の要件は無くても済むと考えます。
　例えば、「ユーザ端末は、アプリ管理サーバに、タクシー迎車依頼地情報とタクシー選択範囲情報とを送信」となっておりますが、
　宇高は、ユーザ端末が「タクシー選択範囲情報」を送信しなくても済むと考えます。
　なぜならば、ユーザ端末が「タクシー選択範囲情報」を送信せずとも、
　アプリ管理サーバがユーザ端末からタクシー迎車依頼地情報を受信した時に、アプリ管理サーバが、タクシー迎車依頼地情報に基づいて、例えば１００ｍ以内にはタクシーＡ１，Ａ２，Ａ３が存在、例えば５００ｍ以内にはタクシーＡ１，Ａ２，Ａ３，Ａ４，Ａ５，Ａ６，Ａ７が存在、例えば１Ｋｍ以内にはタクシーＡ１，Ａ２，Ａ３，Ａ４，Ａ５，Ａ６，Ａ７，Ａ７，Ａ８，Ａ９，Ａ10が存在している情報をユーザ端末に送信できますから、
　これを受けて、ユーザ端末がタクシーＡ１～Ａ10の中から選択するようにしても良いと考えるからです。

　宇高は、そもそも、ユーザにタクシーを選択させる必要がないと考えます。
　なぜならば、ユーザは「一番早く到着する（一番近距離に居る）タクシーを回して欲しい」だから、アプリ管理サーバは最適と考えられるタクシーをユーザ端末に通知するのみでも良い筈です。 

　宇高は、他の朱書き箇所の要件も必須構成要件ではないだろうと考えております。

　それ以外にも、タクシー事業者端末がアプリ管理サーバの結果情報データベースにアクセス可能になっておれば、「共有し得るように通知」の要件を外す事が出来、特許権侵害を回避できそうです。 

　宇高は、例えば下記の発明を考えました。
【請求項１】
　ネットワークを介して接続されるユーザ端末とタクシー移動端末と管理サーバとを具備してなり、
　前記ユーザ端末は、タクシー配車要求通知部を具備し、
　前記タクシー移動端末は、タクシー位置情報通知部と迎車可情報通知部とを具備し、
　前記管理サーバは、タクシー位置情報受信部とタクシー情報通知部とデータベースとを具備し、
　前記管理サーバのデータベースは、データベース部Ａとデータベース部Ｂとを具備してなり、
　前記データベース部Ａには、前記タクシー位置情報通知部からの情報を受けてタクシー位置情報とタクシー情報とが関連付けて記憶されており、
　前記ユーザ端末のタクシー配車要求通知部は、前記管理サーバに対して、ユーザ端末の位置情報を通知してタクシーの配車を要求するものであり、
　前記管理サーバのタクシー情報通知部は、前記ユーザ端末からのタクシー配車要求を受けて、前記ユーザの所在位置に近接するタクシーの情報を前記データベース部Ａに記憶されている情報の中から選択し、前記近接するタクシーのタクシー移動端末に向けて、通知するものであり、
　前記タクシー移動端末の迎車可情報通知部は、前記管理サーバのタクシー情報通知部からの通知を受けて、迎車可否の情報を前記管理サーバに向けて通知すると共に、迎車可の場合には迎車可の情報を前記ユーザ端末に向けて通知するものであり、
　前記データベース部Ｂには、前記ユーザ端末からのタクシー配車要求と、前記配車要求を受けて前記管理サーバのデータベース部Ａから読み出されたタクシー情報と、前記タクシー情報の通知を受けての前記タクシー移動端末からの迎車可否の情報とが関連付けて記憶される
タクシー配車システム。
【請求項２】
　タクシー配車システムはネットワークを介して接続されるタクシー事業者端末を具備してなり、
　前記タクシー事業者端末は閲覧部を具備してなり、
　前記閲覧部は、管理サーバのデータベースＢに記憶されている情報を閲覧できる
請求項１のタクシー配車システム。
【請求項３】
　タクシー配車システムはネットワークを介して接続されるタクシー事業者端末を具備してなり、
　タクシー移動端末は、管理サーバのタクシー情報通知部からの通知をタクシー事業者端末に通知する通知部を具備する
請求項１のタクシー配車システム。 

　ビジネスモデル特許発明には様々なパターンが考えられます。

　富士山に登る登山ルートが、富士吉田ルート、富士宮ルート、須走ルート、御殿場ルートと言った具合に幾つか有るのと同じです。

　宇高は、例えば上記提案のタクシー配車システムを考えました。斯のタクシー配車システムは第６５４６５６２号特許発明を侵害しません。 

　それでは、全てのパターンを想定して網羅した請求項（権利範囲）を纏めれば良いのでしょうが、是が実は中々大変です。

　依頼者からすると、そのような内容に纏めて欲しいと思われるのが当然でしょうが、様々なパターンを想定する事が大変な上、そのような様々なパターンを網羅した請求項の場合、発明の実施形態が非常に複雑になって来ます。

　そもそもが一つの出願に纏められるのかすら疑問です。

　宇高が提案したタクシー配車システムと特許第６５４６５６２号発明とを包含した上位請求項の発明が考えられるのかと言う問題が有ります。

　大方の特許事務所はそのような複雑な作業を嫌がるでしょうね。

　その結果、抜け穴だらけの権利の特許となってしまいます。 

　上記朱書き箇所の要件を欠いた技術が実施された場合、この技術に対しては少なくとも文言侵害が成立しません。つまり、特許権侵害とは言えなくなります。
　後は均等侵害が成立するか否かです。
　しかし、本件特許発明は「ユーザが最終的に配車決定するようにしているので、情報の公平性・透明性を保ち、配車アプリ使用に対する費用請求を適切に行える。」を特長としております。つまり、宇高は、情報がアプリ管理サーバとタクシー事業者端末との間で共有されるから、「情報の公平性・透明性を保ち、配車アプリ使用に対する費用請求を適切に行える」のだろうと考えます。
　そうすると、共有の要件を外せば、共有の要件を欠く事になるので、上記特長を奏し得ないと主張できます。その結果、均等論の主張を封じる事が出来そうです。　

　皆様は、特許権は、真似する者が出て来た場合に、それを排除する権利としか考えません。

　しかし、上記のような抜け穴だらけの特許でも、利用価値は大いに有ります。

　宇高の願いは皆様に特許発明の有効活用法を知って欲しい事です。

　とは言うものの、宇高は、勿論、抜け穴だらけの特許明細書を作成しません。ご安心下さい。 

　ビジネスモデル特許のもう一つの難しさは技術用語が少ない事です。
　本件特許訴訟でも「タクシー情報」の解釈が勝敗の帰趨を決めたようです。 

　皆様は「タクシー情報」の何処に問題が有るのかと思われるでしょう。
　恐らく、明細書作成時には、発明者も作成者も「タクシー情報」が問題になるとは思ってなかったと考えます。

　問題になったのは、特許発明が想定もしていなかったケースに出会った為、無理矢理にでも、そのケースを特許権侵害と主張する為の窮余の一策であったからだろうと考えます。
　しかし、窮余の一策は、やはり、破綻するケースが多いです。 

　以下は本件特許訴訟における原告・被告・裁判所の判断の抜粋です。
【原告らの主張】
本件明細書の【0019】には、「…図２（ｃ）に示すような複数候補が表示される。画面に表示される候補のタクシー情報には、選択タクシー会社、…を含ませることができる。ユーザはこれら情報を参考にして的確にタクシー配車依頼を行うことができる。」と記載され、さらに、【0020】には、「ユーザは、ユーザ端末の画面に表示された受信情報結果を見て、気に入ったタクシーが有れば、それを選択する。」と記載され、図２（ｃ）には、複数のタクシー会社が示されている。このように、構成要件Ｃの「タクシー情報」には、選択タクシー会社（タクシー事業者）も含まれ、ユーザにより選択される「（ユーザが希望する）タクシー」がタクシー事業者であってもよいことが示されている。そうすると、構成要件Ｃの「タクシー情報」及びユーザが希望する「タクシー」との文言の意味は、特定のタクシー車両に限定されるものではないし、クレーム全体を通覧しても、そのような限定がされているとはいえない。加盟事業者間及びアプリ運営主体と加盟事業者間の公平性・透明性の確保という本件発明の目的効果に照らしても、ユーザによりタクシー事業者（タクシー会社）が指定されれば、特定のタクシー車両を指定することまでは課題解決に必須のものではない。仮に、「タクシー」の用語につき「タクシー会社」を含む概念との解釈が困難であったとしても、構成要件Ｃにおける「ユーザが希望するタクシー」とは、「ユーザが希望する特定のタクシー会社の任意のタクシー車両」とは解釈できる。
そして、別紙「被告製品の構成」の構成要件Ｃに係る「原告らの主張」欄記載のとおり、被告製品においては、「タクシー情報」として会社単位での情報がユーザ端末に表示され、ユーザがその情報から希望したタクシー会社を指定すれば、（同会社の任意のタクシー車両の）配車依頼がアプリ管理サーバに送信されるのであり、「配車確認要求を前記タクシー移動端末、前記アプリ管理サーバ及び前記タクシー事業者端末に共有し得るように通知」されることになる。

したがって、被告製品は、構成要件Ｃを充足する。
【被告の主張】
構成要件Ｃの「タクシー」との文言は、広辞苑の定義、クレーム全体において「タクシー」と「タクシー事業者」が書き分けられていること、本件明細書の各記載（ユーザの選択の対象は特定のタクシー車両を念頭に置いていること）等からすれば、特定のタクシー車両を指すと解釈するのが自然である。
また、「タクシー情報」との文言は、上記の「タクシー」の解釈のほか、本件明細書【0028】（「情報結果とは、ユーザ希望の範囲に存在するタクシー情報であり、この情報には、タクシー事業者名、料金、車種等が含まれる。」）等の記載に照らすと、ユーザが希望した範囲に存在する配車依頼可能なタクシー車両の情報を指すと解釈すべきである。
これに対し、被告製品においては、ユーザ端末からは個別のタクシー車両の情報が確認可能となることはなく、また、個別のタクシーの中からユーザが希望する個別車両を指定した配車確認要求がされることもない。そもそも、ユーザが個別車両を指定するわけではなく、アプリ管理サーバがＡＩマッチング機能に基づき配車車両を選定している。
したがって、被告製品は、「前記タクシー情報の中からユーザが希望するタクシーを指定した配車確認要求を…通知し」との構成要件Ｃを充足しない。
【裁判所の判断】
本件発明は、構成要件Ｆにおいて「タクシー移動端末」を、構成要件Ｋにおいて「タクシー事業者端末」をそれぞれ構成要素としており、タクシー移動端末は、個々の車両に備えられるもの、タクシー事業者端末は、個々の車両を統括・管理する拠点に備えられるものであるから、構成要件上、「タクシー」と、「タクシー事業者」は区別されている。
本件明細書上もこれらの区別を前提としており、「タクシー」が個々の車両ではなく、タクシー会社ないしタクシー事業者であると理解する根拠となる記載は存在しない。
そして、配車管理装置ではなくユーザが配車するタクシーを決定することにより公平性を保つとの本件発明の前記特徴も考慮すると、構成要件Ｃの「タクシー（情報）」とは、個々の車両（の情報）をいうものと解され、本件発明における「ユーザが希望するタクシーを指定した配車確認要求」とは、構成要件Ｃの個々のタクシーの情報を前提として、ユーザが選択した特定のタクシーの配車を依頼する旨の要求を指すものと解される。
被告製品においては、前提事実記載のとおり、被告アプリの③Ａ画面においてユーザ端末に示されるものは「タクシー会社を指定する」画面であって、個々の車両の情報が示されるものではないし、ユーザが選択するのは特定の車両ではないから、「ユーザが希望するタクシーを指定した配車確認要求」も備えない（なお、構成要件Ｃのうち、配車確認要求を「前記タクシー移動端末…及び前記タクシー事業者端末に共有し得るように通知し」の構成を被告製品が備えていることについては、主張はそもそも欠落している。）。

したがって、被告製品は、構成要件Ｃを充足しない。

原告らは、本件明細書の【0019】には、「…図２（ｃ）に示すような複数候補が表示される。画面に表示される候補のタクシー情報には、選択タクシー会社、…を含ませることができる。ユーザはこれら情報を参考にして的確にタクシー配車依頼を行うことができる。」と記載され、さらに、【0020】には、「ユーザは、ユーザ端末の画面に表示された受信情報結果を見て、気に入ったタクシーがあれば、それを選択する。」と記載され、図２（ｃ）には、複数のタクシー会社が示されていることからすると、構成要件Ｃの「タクシー情報」には、選択タクシー会社（タクシー事業者）も含まれ、ユーザにより選択される「（ユーザが希望する）タクシー」がタクシー事業者であってもよいことが示されている旨主張する。
しかし、本件明細書上、「タクシー」とは個々の車両をいうものと解されることは前記のとおりであるし、【0019】の記載は、「画面に表示される候補のタクシー情報には、選択タクシー会社、料金体系、車種、宣伝文等を含ませることができる。」というものであり、「料金体系、車種」との記載もあることからすると、「タクシー情報」とは、飽くまで個々の車両の情報であって（同一のタクシー会社であっても、車種等によって料金体系が異なることがあるのは当業者にとって明らかである。）、その情報に「タクシー会社」等の情報を含ませることができるにすぎないものと当業者は理解するというべきである。また、原告らが指摘する図２（ｃ）も、個々の車両の情報の一つとしてタクシー会社が記載されているにすぎず、原告らの主張の根拠とはなり得ない。なお、原告らは、「ユーザが希望するタクシー」は、少なくとも「ユーザが希望する特定のタクシー会社の任意のタクシー車両」とは解釈できる旨主張するが、ユーザにより特定の車両が選択されているものではないことに変わりはないし、そもそも「タクシー情報」はタクシー会社の情報のみで足りるものではないことは前記のとおりであるから、いずれにしても原告らの主張は成り立たない。

したがって、原告ら主張のクレーム解釈は取り得ない。

原告らは、構成要件Ｃの「タクシー」を「タクシー会社」に置換した構成について均等侵害を主張する（争点３－２）。

しかし、前記の本件発明の課題及びその解決手段からすると、配車管理装置が、ユーザの希望する条件に適合する車両を提示し、最終的にユーザが配車要求する車両を決定し、その決定に配車管理装置が関与せず、かつ当該決定に係る情報のやり取りをアプリ運営主体とタクシー事業者とで共有することにより、ユーザとアプリ運営主体、アプリ運営主体とタクシー事業者間の公平性及び情報の透明性を確保することは、本件発明の本質的な特徴である。そうすると、ユーザが具体的な配車候補車両ではなく、タクシー会社のみを定め、その後は配車管理装置において、配車する車両を決定するとのプロセスを経ることは、まさに前記の本質的な特徴にそぐわないこととなる。

したがって、原告らの置換に係る主張は、本件発明の本質的部分に関するものというべきであって、均等の第１要件を満たさない。

さらに、ユーザが「タクシー会社」のみを選択するとした場合、選択対象となり得る同社の複数の車両のうち、アプリ運営主体においていずれの車両を選択し、配車決定すべきかについては一概に決められるものではないし、そもそも、アプリ運営主体がかかる決定に関与することにより、本件発明の目的である前記の公平性・透明性の確保が損なわれることは前記のとおりであるから、当業者にとって原告ら主張の置換が可能かつ容易であるとは認められない。そうすると、均等の第２要件及び第３要件も満たさない。