2023-020719

特願２０２１－１６９８７９「ソース場所からターゲット場所への移動に対しルートまたはルート所要時間を提供する方法およびコンピュータシステム」拒絶査定不服審判事件〔令和 ４年 １月１１日出願公開、特開２０２２－ ３３５３、請求項の数（１）〕について、次のとおり審決する。

結 論 原査定を取り消す。 本願の発明は、特許すべきものとする。

理 由 第１ 手続の経緯 本願は、２０１８年（平成３０年）１１月７日（パリ条約による優先権主張２０１８年１月５日、アメリカ合衆国、２０１８年４月１８日、アメリカ合衆国、２０１７年１２月２１日、アメリカ合衆国、２０１８年４月１９日、アメリカ合衆国、２０１８年１１月５日、アメリカ合衆国）を国際出願日とする特願２０２０－５２４２６８号の一部を令和３年１０月１５日に新たな特許出願としたものであって、その手続の経緯の概略は以下のとおりである。 令和３年１０月１５日 上申書の提出 令和４年１１月２４日付け 拒絶理由通知書 令和５年 ４月２５日 意見書、手続補正書の提出 令和５年 ７月３１日付け 拒絶査定（以下、「原査定」という。） 令和５年１２月 ６日 審判請求書、手続補正書の提出 令和６年 ６月１０日付け 拒絶理由通知書 令和６年 ９月１１日 意見書、手続補正書の提出 なお、令和６年６月１０日付け拒絶理由通知書で指摘する拒絶の理由を、以下、「当審の理由」という。 第２ 当審の理由について １ 拒絶理由 「１．（明確性）この出願は、特許請求の範囲の記載が下記の点で、特許法第３６ 条第６項第２号に規定する要件を満たしていない。 記 ●理由１（明確性）について ・請求項 １ （１）請求項１の記載は、全体的に、動作主体が、人間であるのか、コンピュータであるのか明確でない。 なお、発明の詳細な説明の段落【０１１９】以下の記載を参照すると、請求項１の「前記方法は以下の事を含む：」との記載を、例えば、「前記方法は以下の事をコンピュータシステムが実行することを含む：」と補正すると、この理由は解消する。 （２）請求項１の次の記載は、（ｉｉｉ）、（ｉｖ）、（ｖ）、（Ａ）及び（Ｂ）が主語になるため、日本語として不明確である。なお、下線は、当審で付与した。 「ここにおいて、各見込エッジ、 （ｉｉｉ）は前記複数のグラフエッジに含まれ、 （ｉｖ） は前記見込エッジの始頂点から前記見込エッジの着頂点に通じ、前記始頂点と前記着頂点の両方が前記複数のグラフ頂点に含まれ、および （ｖ） は２つ以上の見込ルート(prospect routes)を決定して計算され、 ここにおいて、各見込ルート： （Ａ）は前記始頂点の場所から前記着頂点の場所までの前記移動を表す、 および （Ｂ）は前記移動のルートに含まれる移動の選択肢である、および」 なお、上記（ｉｉｉ）、（ｉｖ）、（ｖ）について「各見込みエッジ」が主語であり、また、上記（Ａ）、（Ｂ）について、「各見込ルート」が主語であるならば、次のとおりに補正するとこの理由は解消する。「ここにおいて、各見込エッジは、 （ｉｉｉ） 前記複数のグラフエッジに含まれ、 （ｉｖ） 前記見込エッジの始頂点から前記見込エッジの着頂点に通じ、前記始頂点と前記着頂点の両方が前記複数のグラフ頂点に含まれ、および （ｖ） ２つ以上の見込ルート(prospect routes)を決定して計算され、ここにおいて、各見込ルートは、 （Ａ） 前記始頂点の場所から前記着頂点の場所までの前記移動を表す、および （Ｂ） 前記移動のルートに含まれる移動の選択肢である、および」」 ２ 当審の判断 （１）「●理由１（１）」について ア 請求人は、当審の当該理由について、令和６年９月１１日に提出した意見書で、次のとおり主張する。 「§3 各請求項は以下の原則を使用して解釈されます。 “請求項の解釈の原則” 発明の詳細な説明及び図面の記載を参酌して、 当業者による最も広範な合理的解釈」 「§15 “主体”又は“方法”の拒絶理由は、上述の“請求項の解釈の原理”により既に解消された。」 イ そこで、発明の詳細な説明を参照すると、次の記載がある。なお、下線は当審で付与した。 「【０１１８】 （５ コンピュータシステム） 本発明の実施形態の１つは、ルート決めクエリに応答するコンピュータシステムである。 【０１１９】 一実施形態において、本システムは、出発時刻が与えられると、場所間の最短ルートのクエリに応答する：ここで、任意のクエリは、所定形式（ソース、ターゲット、ｍｉｎｕｔｅＯｆＤａｙ（分時刻））を有する。応答は、所要時間、選択肢付きルート、の形式である。実施形態の説明は図１３にある。 【０１２０】 本明細書では「モジュール」という用語を用いる。この用語は、特定の機能を提供するコンピュータ（サブ）システムを意味することは当技術分野で知られている。コンピュータシステムを特定のモジュールに分割するというこの選択は例示的なものであり、必須ではない。当業者は、本発明の範囲から逸脱することなく、システムを他の方法でモジュールに編成できることに気付くであろう。 【０１２１】 システムの１つのモジュール（１２０２）は、複数のデータソース（１２０１）から大都市交通システムに関する情報を読み取る。このモジュールは、どの車両、ルート、またはそれらの各部が、固定時刻表のものと見なされ、どの非固定時刻表のものと見なされるかを決定する。このモジュールは、固定時刻表車両のルートを計算する。このモジュールは、また、非固定時刻表車両の時間に基づいて、待ち所要時間と乗車所要時間の分布を計算する。 【０１２２】 出力は、見込エッジを計算するモジュール（１２０４）に渡される。そのモジュールは、複数のデータソース（１２０３）からの徒歩に関する情報を照会する。選択された見込クラスタｃとｃ’、およびｃにおけるの乗客の到着時間について、モジュールは、ｃにおける乗客の到着時間を条件とするランダム変数を用いて、見込エッジの重みＰ（ｃ、ｃ’）と選択肢を計算する。結果はストレージ（１２０５）に保存される。 【０１２３】 モジュール（１２０２）および（１２０４）は、継続的に動作する。その結果、システムは、輸送システムの新しいモデルを維持する。 【０１２４】 その間、他のモジュール（１２０６）は最短経路を事前計算する。モジュールは、時々、（１２０５）から見込エッジを読み取り、（１２０２）から非見込エッジを読み取とって、場所をつなぐグラフを構築する。所定形式（停留所／駅クラスタソース、停留所／駅クラスタターゲット、ｍｉｎｕｔｅＯｆＤａｙ）のクエリから選択されたクエリについて、経路を計算するため、最短経路アルゴリズムがグラフに適用される。結果は、後で必要になったときストレージ（１２０７）から結果を検索できるように、保存される。 【０１２５】 同時に、クエリ応答モジュール（１２０８）がクエリに応答する。クエリ（ソース、ターゲット、ｍｉｎｕｔｅＯｆＤａｙ）（１２０９）が届くと、モジュールはセクション４に従って最短経路を計算する。モジュールは、（１２０３）に連絡して、ソースとターゲット、および停留所／駅クラスタ間の徒歩を決定する。モジュールは、（１２０７）から関連する事前計算された最短経路を検索する。必要であるがまだ利用できない場合、モジュールは、モジュール（１２０６）に最短経路を要求し、結果の最短経路を将来の使用のためにストレージ（１２０７）に保存する。モジュール（１２０８）は、（１２０５）からの選択肢と時間も検索する。これらの徒歩、最短経路、および選択肢が組み合わされて、クエリに対する応答（１２１０）が生成される。 【０１２６】 本発明の態様は、ハードウェアの実施形態、ソフトウェアの実施形態、またはこの２つの組み合わせの形をとることができる。本発明のステップは、任意のフローチャートのブロックを含み、機能性および最適化に応じて、順不同で、部分的に並行して、または貯蔵所から提供されて、実行され得る。態様は、シーケンシャルシステムまたはパラレル／分散システムの形をとることができ、各コンポーネントは他のコンポーネントと重複する可能性のあるいくつかの態様を実現し、コンポーネントは、例えばあらゆる種類のネットワークを用いて通信できる。本発明の態様のための動作を実行するコンピュータプログラムは、Ｃ＋＋，Ｊａｖａ（登録商標）、またはＪａｖａＳｃｒｉｐｔ（登録商標）を含む任意のプログラミング言語で書かれてもよい。任意のプログラムは、中央処理装置（ＣＰＵ）、グラフィック処理装置（ＧＰＵ）、および関連するメモリとストレージデバイスを含む、任意のハードウェアプラットフォームで実行できる。プログラムは、本発明の態様を１つ以上のソフトウェアプラットフォーム上で実行でき、そのプラットフォームは、ＡｎｄｒｏｉｄまたはｉＯＳなどのオペレーティングシステム、またはＦｉｒｅｆｏｘ，Ｃｈｒｏｍｅ，Ｉｎｔｅｒｎｅｔ Ｅｘｐｌｏｒｅｒ、またはＳａｆａｒｉなどを含むＷｅｂブラウザ、を実行するスマートフォンを含むが、これらに限定されない。」 ウ 発明の詳細な説明の記載には、請求項１に記載された「方法」について、動作主体が、コンピュータであることが記載されるのみで、人間であることは記載されていない。 そうすると、請求項１に係る「方法」の発明の動作の主体は、コンピュータシステムであるといえる。 よって、意見書を参照することで、当該理由は解消した。 （２）「●理由１（２）」について 当該理由は、当審の示唆に基づいて令和６年９月１１日に提出した手続補正書で補正したことから、解消した。 ３ 小括 以上のとおりであるから、当審で指摘した拒絶理由は全て解消した。 第３ 原査定について １ 原査定における拒絶の理由 原査定の請求項１についての拒絶の理由の概要は次のとおりである。 「１．（サポート要件）この出願は、特許請求の範囲の記載が下記の点で、特許法第３６条第６項第１号に規定する要件を満たしていない。」 「・請求項１ 出願人は、意見書中、本願の親出願である特願２０２０－５２４２６８号の審査経過書類や図１４を根拠にして、本願発明が本願明細書に記載されたものである旨を主張する。 しかしながら、本願と親出願である特願２０２０－５２４２６８号とは別出願であるから、親出願の審査経過書類を根拠にして、本願発明が本願明細書に記載されていることにはならない。 また、参考のために、この親出願の審査経過書類を確認したものの、何故、本願発明が本願明細書に記載されているといえるのか、依然として不明である。 さらに、図１４を参照しても、何故、本願発明が本願明細書に記載されているといえるのか、依然として不明である。」 ２ 当審の判断 （１）本願の発明の詳細な説明には次の事項が記載されている。 「【００２７】 頂点を追加し、乗客が地下鉄の出発に合わせて駅への到着を時間指定されているかのように待ちなしで搭乗する地下鉄を、モデル化する。各地下鉄駅ｓに、次の２つの頂点を導入する、 ＳＵＢＷＡＹ＿ＦＲＯＭ＿ｓ、 ＳＵＢＷＡＹ＿ＳＴＡＴＩＯＮ＿ｓ。 任意の２つの異なる駅ｓ，ｓ’は、次のエッジを有する。 ＳＵＢＷＡＹ＿ＦＲＯＭ＿ｓ→ＳＵＢＷＡＹ＿ＳＴＡＴＩＯＮ＿ｓ’ これは、ｓからｓ’への乗車所要時間を表し、地下鉄の乗り換えと徒歩を含むことができ（例えば、駅ｓから、まず地下鉄Ａに乗って駅Ｂに行き、次に駅Ｃに歩いてから、地下鉄Ｄに乗って駅ｓ’に行く）、このエッジは、ＲｉｄｅＭａｎｙＧｅｔＯｆｆ（多乗車下車）とラベル付けされる。・・・」 「【００３１】 全てのバス路線について、バス停と、バス停におけるバスとをモデル化する頂点を追加する。前者はバス外の乗客を抽象化し、後者はバス内の乗客を抽象化する。ｂ１，．．，ｂｎを、バス路線ｅに沿ったｎ個の連続したバス停（オンデマンド停留所を含む）とする。次の頂点を、各ｋ、１≦ｋ≦ｎについて、追加する、 ＢＵＳ＿ＳＴＯＰ＿ｂｋ および ＢＵＳ＿ＡＴ＿ＢＵＳ＿ＳＴＯＰ＿ｂｋ＿ｋ＿ｅ。 ２つのバス路線は、バス停を共有できる。次のエッジがあり、このバス停でバスを降りることを示すＧｅｔＯｆｆ（下車）とラベル付けされ、このエッジの重みはゼロである、 ＢＵＳ＿ＡＴ＿ＢＵＳ＿ＳＴＯＰ＿ｂｋ＿ｋ＿ｅ→ＢＵＳ＿ＳＴＯＰ＿ｂｋ。」 「【００３６】 （４．２．４ 制約） 次に、ルートに沿った最初の待ちでの制約のモデリングを可能にする補助頂点を追加する。一実施形態において、待ちはゼロであり、これは、出発するバス／地下鉄に乗るのに十分に早いが、早すぎることなく、停留所／駅まで歩く乗客をモデル化する。他の実施形態において、待ちは移動の開始時間に依存し、特定の時間に、例えば午前８時に家を出て、移動を開始する乗客をモデル化する。 【００３７】 バスの停留所と地下鉄の駅を地理的な近接度に基づいてクラスタ化する(cluster)。一実施形態において、クラスタ半径を２メートルに固定する。・・・ 【００３８】 各クラスタｃに対して、次の頂点が追加され、 ＳＴＯＰＳＴＡＴＩＯＮ＿ＣＬＵＳＴＥＲ＿ＳＯＵＲＣＥ＿ｃ そして、ｂｋまたはｓがクラスタｃにある場合に、クラスタをバスと地下鉄に接続する次のエッジが追加される、 ＳＴＯＰＳＴＡＴＩＯＮ＿ＣＬＵＳＴＥＲ＿ＳＯＵＲＣＥ＿ｃ →ＢＵＳ＿ＡＴ＿ＢＵＳ＿ＳＴＯＰ＿ｂｋ＿ｋ＿ｅ、および ＳＴＯＰＳＴＡＴＩＯＮ＿ＣＬＵＳＴＥＲ＿ＳＯＵＲＣＥ＿ｃ →ＳＵＢＷＡＹ＿ＦＲ０Ｍ＿ｓ。 エッジは、ＦｉｒｓｔＷａｉｔＧｅｔＯｎ（第１乗車待ち）とラベル付けされる。」 「【００４３】 （４．２．５ 見込エッジ） 次に、いくつかの車両のいずれかを使用することによる移動所要時間の改善を示す補助の頂点とエッジを追加する。改善は、車両の待ち時間の短縮または車両の乗車時間の短縮によってなされ得る。 【００４４】 乗り物に乗るのを待つ所要時間は、乗客がランダムな時間に停留所／駅に到着すると仮定することによってモデル化でき、これは、非固定時刻表を用いる車両の確率的性質による。もし、グラフ経路上に２つの連続したＲｉｄｅＭａｎｙＧｅｔＯｆｆ（多乗車下車）乗車エッジがあれば、エッジを１つのＲｉｄｅＭａｎｙＧｅｔＯｆｆ（多乗車下車）エッジに置き換えることができる。」 「【００４６】 このセクションにおいて、見込エッジで接続された２つの場所は、車両の停留所の近くにある。ただし、これは本方法を制限するものではない。実際、後のセクションでは、車両の停留所から遠くなる可能性のある任意の場所で終了する見込エッジについて説明する。一般に、見込エッジは、グラフ内の任意の２つの頂点を接続できる。ただし、説明のために、このセクションでは、車両の停留所の近くの見込エッジに焦点を当てる。」 「【００５８】 例えば、図７は、下記の３つの選択肢（ｃｈｏｉｃｅｓ）を含む、ｃからｃ’への移動を示す： ・区間［０，９００］で均一な待ちと徒歩＆乗車１７００を有するバス路線ｅ’、 ・区間［０，３６００］で均一な待ちと徒歩＆乗車１０００を有するバス路線ｅ”、 ・区間［０，３００］で均一な待ちと徒歩＆乗車２２００を有する地下鉄。 この場合、最小の予想される移動所要時間は２１５０＝ｍｉｎ｛２１５０，２８００，２３５０｝であり、「どちらか速い方」による移動の改善を反映していない。ただし、予想される最小値は低くなる：Ｐ（ｃ、ｄ）＝１９３３。」 「【００７１】 （４．３．１ ソースが既知） いくつかの実施形態において、ルート決めクエリのソース場所は事前に知られている。例えば、首都圏の全てのレストランからの最短ルートを見つけることに興味があり、レストランの場所がわかっているとする。これは、拡張グラフＧ０を用いて実現できる。 【００７２】 一実施形態において、そのようなソースｓ毎に、下記頂点を追加する ＳＯＵＲＣＥ＿ｓ。 図１参照。一実施形態において、 ＳＯＵＲＣＥ＿ｓ から、任意のバス停と地下鉄駅のクラスタ ＳＴＯＰＳＴＡＴＩＯＮ＿ＣＬＵＳＴＥＲ＿ＳＯＵＲＣＥ＿ｃ に向かうエッジを、グラフＧ０に追加する。エッジはＷａｌｋとラベル付けされ、その重みは徒歩の所要時間を表す。他の実施形態において、大きくともしきい値までの所要時間を有する最短徒歩、またはセクション４．２．３のような他の実施形態、を用いる。」 「【００７３】 得られるグラフは、Ｇ１（Ｇ０を含む）で表示される。Ｇ１は、任意の、 ＳＯＵＲＣＥ＿ｓ から、任意の ＳＴＯＰＳＴＡＴＩＯＮ＿ＣＬＵＳＴＥＲ＿ＴＡＲＧＥＴ＿ｃ への最短経路を計算するために用いることができる。一実施形態において、クエリが提示されると、いくつかの経路が事前計算され、保存され、ストレージから取得される。 【００７４】 他の実施形態において、ターゲットが事前に知られている場合、対称方法が用いられる。各ターゲットｔについて、下記頂点を追加し、 ＴＡＲＧＥＴ＿ｔ、 任意の ＳＴＯＰＳＴＡＴＩＯＮ＿ＣＬＵＳＴＥＲ＿ＴＡＲＧＥＴ＿ｃ から任意の ＴＡＲＧＥＴ＿ｔ への、Ｗａｌｋ（徒歩）とラベル付けされるエッジを追加する。得られるグラフは、Ｇ１’で表示される。」 「【００９２】 グラフＧ１において、次のソース、 ＳＯＵＲＣＥ＿ｓ およびグラフに表されてなくともよい任意のターゲット場所ｔ、に対して提示されたクエリを（ｓ，ｔ）とする。 【００９３】 ｓからｔへの最短経路には、バスが１本のみ、または地下鉄のみが含まれる場合がある。その場合、見込エッジを考慮する必要はない。グラフＧ１を取得し、これをさらに拡張する。頂点、 ＴＡＲＧＥＴ＿ｔ、 と、任意のｃについて、 ＳＴＯＰＳＴＡＴＩＯＮ＿ＣＬＵＳＴＥＲ＿ＴＡＲＧＥＴ＿ｃ、 から、 ＴＡＲＧＥＴ＿ｔ。 へのエッジを追加する。これらの各エッジは、Ｗａｌｋとラベル付けられ、その重みは徒歩所要時間である。一実施形態において、任意のエッジは、大きくともしきい値までの持続時間を有する最短徒歩所要時間、またはセクション４．２．３のような他の実施形態を表す。得られたグラフにおいて、 ＳＯＵＲＣＥ＿ｓ から ＴＡＲＧＥＴ＿ｔ までの、最短経路を計算し、経路の長さをＡ（ｓ，ｔ）で表す。この長さは、ｓからｔまでの最短移動所要時間の候補である。 【００９４】 他の候補がある。最短経路には、より多くの車両が含まれることもある。その場合、経路に沿って最後から２番目の停留所／駅がある。このケースをカバーするために、ｔへの見込エッジを計算する。この処理は図１２に示されている。図を簡略化するため、図面には１枚札（ｓｉｎｇｌｅｔｏｎ）の見込クラスタが描かれている（それぞれにバス停が１つ、または地下鉄の駅が１つだけある）。 【００９５】 ｔへの見込エッジを計算するには、グラフＧ１から始める。最後から２番目の停留所／駅で終わるｓからｔまでの移動の各部を列挙する。具体的には、 ＳＯＵＲＣＥ＿ｓ から、各ｃについて、 ＰＲＯＳＰＥＣＴ＿ＣＬＵＳＴＥＲ＿ＳＯＵＲＣＥ＿ｃ、 までの最短移動所要時間を決定する。・・・ 【００９６】 最後から２番目の停留所／駅からターゲットｔまで、移動がどのように続くかを、見込エッジと徒歩を用いて決定する。全ての ＰＲＯＳＰＥＣＴ＿ＣＬＵＳＴＥＲ＿ＳＯＵＲＣＥ＿ｃ、 について、最初に、選択肢（ｃ，ｃ’）と呼ばれる中間体、 ＰＲＯＳＰＥＣＴ＿ＣＬＵＳＴＥＲ＿ＴＡＲＧＥＴ＿ｃ’ に移動してｃ’からｔへの徒歩を続けることにより、ｃからｔに移動する選択肢を決定する。一実施形態において、大きくともしきい値までの所要時間を有する最短徒歩ｃ’からｔのみ、またはセクション４．２．３にあるような他の実施形態、を考慮する。例えば、図１２において、選択肢（ｂ１，ｂ０）は、 ＢＵＳ＿ＳＴＯＰ＿ｂ１ から ＢＵＳ＿ＳＴＯＰ＿ｂ０ へのエッジに付されて示されており、２つの選択肢があり、１つは、バス路線ｅ”であり、［０，９００］において待ち所要時間が均一、移動所要時間１６００、他の１つは、バス線ｅ’”であり、［０，３６００］において待ち所要時間が均一、所要所要時間１０００である。続いて、 ＢＵＳ＿ＳＴＯＰ＿ｂ０ から ＴＡＲＧＥＴ＿ｔ まで、徒歩２４０を要する。」 「【０１２８】 一実施形態において、サービスは、スマートフォンアプリケーションからアクセスされる。ユーザは、スマートフォン上のアプリケーションのユーザインターフェイスを操作して、出発時間、ソース、およびターゲットを指定する。すると、サービスは、ルートを生成してスマートフォン上にルートを示す。図１４は、午前８時にＡからＬに出発するクエリの結果例を、示す。 【０１２９】 一実施形態において、サービスは、どの選択肢が現在最短の移動所要時間をもたらすかを報告する。一実施形態において、システムは、このより速い選択肢を強調表示する（ルート上に１４０１で示されている）か、その選択肢の移動所要時間を示すか、現在の待ち所要時間（Ｄ付近の１４０２で示されている）を示す。一実施形態において、車両の現在場所が与えられると、このより速い選択が計算される。一実施形態において、このレポートは、ユーザが現在選択の場所の近くにいるときに示され、例えば、ユーザがＡから出発しようとしている場合、サービスは、現在の状況化で、ＢおよびＣ経由ではなく、ＤおよびＥ経由でＦに到達する方が高速になる可能性がある、ことを示す。 【０１３０】 一実施形態において、サービスは、ある場所の選択肢の中から各選択肢の現在の待ち所要時間（Ｆ付近の１４０３で示されている）、または各選択肢の予想される乗車所要時間（１４０４で示されている）を示す。これは、最適ではない場合でも、ユーザが自分で選択を決定するのに役立つ。 【０１３１】 一実施形態において、サービスは、ある場所での全ての選択肢に対する１つの予想される待ち所要時間を報告する。その所要時間は、予想される最小移動所要時間（Ｈ近くの１４０５で示されている）を達成する選択肢にユーザが乗ることを想定した予想される待ち時間である。一実施形態において、この報告は、例えば、ユーザの現在位置と比較して道路のはるか先であるルートの部分について、車両場所が不確実なときに示される。これは、車両を待っている停留所／駅で暇な状態になる時間をユーザに通知する。 【０１３２】 一実施形態において、サービスは、２つの場所（ルート上の１４０６によって示されている）間の見込移動の所要時間を報告する。これは、セクション４でＰ（ｃ，ｃ’）で示されている値である。」 「 ［図：0001417414000001.jpg］ 」（【図１４】） （２）発明の詳細な説明の、少なくとも上記記載を参照すると、請求項１に係る発明は、発明の詳細な説明に記載されているといえる。 ３ 小括 以上のとおりであるから、請求項１に係る発明は、発明の詳細な説明に記載されたものである。 第４ むすび 以上のとおり、原査定及び当審の理由によって、本願を拒絶することはできない。 他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。