2025-003804

特願２０２３－ ７６６６７「会合設定システム、会合設定サーバ、会合設定方法、及び会合設定プログラム」拒絶査定不服審判事件〔令和 ５年 ６月２２日出願公開、特開２０２３－ ８７１０４〕について、次のとおり審決する。

結 論 本件審判の請求は、成り立たない。

理 由 第１ 手続の経緯 本願は、平成２９年６月１３日を出願日とする特許出願（特願２０１７－１１５８６１号）の一部を、令和３年８月２６日に新たな特許出願（特願２０２１－１３７８４３号）とし、その一部を、令和５年５月８日に新たな特許出願としたものであって、その手続の経緯は以下のとおりである。 令和６年 ８月２３日付け：拒絶理由通知書 令和６年１０月２５日 ：意見書、手続補正書の提出 令和６年１１月２８日付け：拒絶査定 令和７年 ３月１０日 ：拒絶査定不服審判の請求 令和７年１１月１４日付け：拒絶理由通知書 令和８年 １月１６日 ：意見書、手続補正書の提出 第２ 本願発明 令和８年１月１６日提出の手続補正書により補正された特許請求の範囲の請求項２に係る発明（以下「本願発明」という。）は、以下のとおりである。 「複数のユーザの端末装置から、会合の設定を希望する設定要求を受信する受信部と、 前記設定要求に基づいて、前記複数のユーザのうち、一つの会合に組み入れるユーザを選択し、当該会合に参加するユーザの情報を含む参加者情報を生成する選択部と、 前記参加者情報を、当該参加者情報に含まれるユーザの端末装置各々に対して送信する送信部とを備え、 前記設定要求において前記会合を希望する日時に関する情報が指定されなくても、前記設定要求に含まれる情報であって場所に関する情報と参加人数に関する情報との少なくとも一方からなる情報に基づいて、前記会合を設定可能である、 会合設定サーバ。」 第３ 拒絶の理由 令和７年１１月１４日付けで当審が通知した拒絶理由（以下「当審拒絶理由」という。）のうちの理由１の概要は、以下のとおりである。 本願請求項１～９に係る発明は、以下の引用文献１、２に記載された発明に基づいて、その出願前にその発明の属する技術の分野における通常の知識を有する者（以下「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 引用文献１：特開２００９－１８１２７７号公報 引用文献２：特許第６４２７００８号公報 第４ 引用文献の記載、引用発明等 １ 引用文献１、引用発明 （１）当審拒絶理由にて引用された引用文献１には、図面とともに、以下の記載がある（下線は当審による。以下同様。）。 「【００５９】 図１は、本発明の一実施形態に係る会合設定システムの構成を示した図である。 同図に示すように、この会合設定システム１００は、複数のクライアント１と、サーバ２とで構成される。各クライアント１及びサーバ２は、例えばインターネットやＬＡＮ（Local Area Network）のようなネットワーク３に接続され、互いに通信が可能となっている。 【００６０】 各クライアント１は、例えば携帯電話機、ＰＤＡ、スマートフォン、ノート型ＰＣ等の携帯型の電子機器であるが、デスクトップ型ＰＣ等の据置型の電子機器であってもよい。サーバ２は、例えば据置型のＰＣ等であるが、その他の電子機器であっても構わない。 【００６１】 この会合設定システム１００においては、各クライアント１が、プライベートな会合に関する希望会合情報を生成してサーバ２へ送信し、サーバ２が、各クライアント１の希望会合情報を調整して、相互に干渉の少ない複数の会合を自動的に設定する。」 「【００７１】 図４は、クライアント１の機能ブロックの構成を示した図である。 同図に示すように、各クライアント１は、交友関係推定部３１、交友関係モデル構築部３２、アベイラビリティ推定部３３、会合場所範囲推定部３４、会合メンバ候補生成器３５、希望会合情報生成器３６、希望会合情報送信部３７、設定会合情報受信部３８及び会合参加履歴管理部３９の各機能ブロックを有する。これらは上記ＣＰＵ１１と協働するプログラム（以下、エージェントと称する）の形態を有する。」 「【００８０】 希望会合情報生成器３６は、上記アベイラビリティ推定部３３、会合場所範囲推定部３４、会合メンバ候補生成器３５でそれぞれ生成された希望会合日時、希望会合場所範囲、会合メンバ候補を、一まとめのデータ構造（以下、希望会合情報と称する）に加工し、希望会合情報送信部３７へ出力する。 【００８１】 希望会合情報送信部３７は、希望会合情報生成器３６の出力である希望会合情報を、サーバ２へ適時送信する。 【００８２】 なお、この希望会合情報は、クライアント１の操作入力部１４を用いてユーザが直接入力できる構成を採ってもよい。すなわち、ユーザから希望会合日時、希望会合場所範囲、会合メンバ候補の直接入力があった場合には、その希望会合情報を優先させてサーバ２に送信を行う。 【００８３】 設定会合情報受信部３８は、サーバ２により自動設定された会合の情報（以下、設定会合情報と称する）を受信する。この設定会合情報は、スケジューラ４４により閲覧可能な状態で記憶される。クライアント１のユーザは、スケジューラ４４及び表示部１６を介してこの設定会合情報を閲覧、確認する。この設定会合情報は、メーラ４３により電子メールとして受信され、記憶されても構わない。」 「【００８５】 図５は、サーバ２の機能ブロックの構成を示した図である。 同図に示すように、サーバ２は、クライアント交友関係モデル管理部５１、クライアント希望会合情報バッファ部５２、クライアント希望会合情報マッチング部５３、最適会合クライアント群集合生成部５４、会合設定部５５及び設定会合情報送信部５６の各機能ブロックを有する。これらの各機能ブロックは、ＣＰＵ２１と協働するプログラムの形態を有する。また、サーバ２は、各クライアント１から受信した交友関係モデルを交友関係モデルデータベース５７として記憶する。 【００８６】 クライアント交友関係モデル管理部５１は、各クライアント１の交友関係モデル構築部３２から適時送信されてきた各クライアント１のユーザの交友関係モデルを、ファイルシステムにより管理する。当該クライアント交友関係モデル管理部５１に対する問い合わせは参照対象のクライアント１のクライアントＩＤで行われ、当該問い合わせに対する出力はそのクライアント１の交友関係モデルとなる。 【００８７】 クライアント希望会合情報バッファ部５２は、各クライアント１の希望会合情報送信部３７から適時送信された各クライアント１の希望会合情報を一時的にバッファする。 【００８８】 クライアント希望会合情報マッチング部５３は、上記クライアント希望会合情報バッファ部５２にバッファされた希望会合情報を基に、当該希望会合情報中の、会合メンバ候補となっているクライアント１のうち、希望会合日時及び希望会合場所範囲が適合するクライアント群（以下、適合クライアント群と称する）を、クライアント１毎に抽出する。 【００８９】 最適会合クライアント群集合生成部５４は、上記クライアント希望会合情報マッチング部５３により抽出された全クライアント１の適合クライアント群から、クライアント１の重なりが無く、かつ、なるべく多くのクライアント１の要求（希望会合情報）を満たすような、最適会合クライアント群集合の生成を行う。 【００９０】 会合設定部５５は、最適会合クライアント群集合生成部５４で生成された最適会合クライアント群集合の各要素である最適会合クライアント群について、それに属する複数のクライアント１の希望会合情報をさらに調停し、最終的な会合の設定を行う。 【００９１】 設定会合情報送信部５６は、各最適会合クライアント群に対して決定された、最終的な会合の日時、待ち合わせ場所の情報を、設定会合情報として、当該最適会合クライアント群に属するクライアント１全員に送信する。」 「【０１９８】 図６のフローチャートに戻り、ＣＰＵ２１は、設定会合情報送信部５６により、各Ｏｉに対して決定された、最終的な会合の日時、待ち合わせ場所の情報を、Ｏｉに属するクライアント全員に配信する。ここで、設定会合情報送信部５６は、その会合の情報が送られるクライアント群（つまり会合に参加が誘われている人）の情報も送信することが可能であるが、サービスの形態によってはその情報を隠蔽することによる効果が大きい場合もある。例えば、会合の待ち合わせ場所に行くまで、参加者が分からないような「意外性」「偶然性」を会合自動設定サービスの特徴に出すことができる。」 「【図４】 ［図：0001435927000001.jpg］ 【図５】 ［図：0001435927000002.jpg］ 」 （２）上記（１）の記載から、以下のことがいえる。 ア 会合設定システム１００は、複数のクライアント１と、サーバ２とで構成され（【００５９】）、各クライアント１は、プライベートな会合に関する希望会合情報を生成してサーバ２へ送信し（【００６１】）、希望会合情報生成器３６、希望会合情報送信部３７及び設定会合情報受信部３８の各機能ブロックを有し（【００７１】）、希望会合情報生成器３６は、希望会合日時、希望会合場所範囲、会合メンバ候補を、希望会合情報に加工し、希望会合情報送信部３７へ出力し（【００８０】）、希望会合情報送信部３７は、希望会合情報生成器３６の出力である希望会合情報を、サーバ２へ適時送信し（【００８１】）、ユーザから希望会合日時、希望会合場所範囲、会合メンバ候補の直接入力があった場合には、その希望会合情報を優先させてサーバ２に送信を行い（【００８２】）、また、サーバ２は、クライアント希望会合情報バッファ部５２の機能ブロックを有し（【００８５】）、クライアント希望会合情報バッファ部５２は、各クライアント１の希望会合情報送信部３７から適時送信された各クライアント１の希望会合情報を一時的にバッファする（【００８７】）とされているから、サーバ２は、複数のクライアント１から、ユーザにより入力される希望会合日時、希望会合場所範囲及び会合メンバ候補が含まれる希望会合情報を受信するものである。 イ サーバ２は、クライアント希望会合情報マッチング部５３、最適会合クライアント群集合生成部５４及び会合設定部５５の各機能ブロックを有し（【００８５】）、クライアント希望会合情報マッチング部５３は、クライアント希望会合情報バッファ部５２にバッファされた希望会合情報を基に、当該希望会合情報中の、会合メンバ候補となっているクライアント１のうち、希望会合日時及び希望会合場所範囲が適合するクライアント群である適合クライアント群を、クライアント１毎に抽出し（【００８８】）、最適会合クライアント群集合生成部５４は、クライアント希望会合情報マッチング部５３により抽出された全クライアント１の適合クライアント群から、クライアント１の重なりが無く、かつ、なるべく多くのクライアント１の要求（希望会合情報）を満たすような、最適会合クライアント群集合の生成を行い（【００８９】）、会合設定部５５は、最適会合クライアント群集合生成部５４で生成された最適会合クライアント群集合の各要素である最適会合クライアント群について、それに属する複数のクライアント１の希望会合情報をさらに調停し、最終的な会合の設定を行う（【００９０】）とされているから、サーバ２は、希望会合情報中の、会合メンバ候補となっているクライアント１のうち、希望会合日時及び希望会合場所範囲が適合するクライアント群である適合クライアント群を、クライアント１毎に抽出するクライアント希望会合情報マッチング部５３、抽出された全クライアント１の適合クライアント群から、最適会合クライアント群集合の生成を行う最適会合クライアント群集合生成部５４、及び生成された最適会合クライアント群集合の各要素である最適会合クライアント群について、それに属する複数のクライアント１の希望会合情報をさらに調停し、最終的な会合を設定する会合設定部５５を有するものである。 ウ サーバ２は、設定会合情報送信部５６の機能ブロックを有し（【００８５】）、設定会合情報送信部５６は、各最適会合クライアント群に対して決定された、最終的な会合の日時、待ち合わせ場所の情報を、設定会合情報として、当該最適会合クライアント群に属するクライアント１全員に送信し（【００９１】）、さらに、設定会合情報送信部５６は、その会合の情報が送られるクライアント群（つまり会合に参加が誘われている人）の情報も送信することが可能である（【０１９８】）とされているから、サーバ２は、各最適会合クライアント群に対して決定された、最終的な会合の日時、待ち合わせ場所の情報を、設定会合情報として、当該最適会合クライアント群に属するクライアント１全員に送信し、さらに、会合に参加が誘われている人の情報を送信する、設定会合情報送信部５６を有するものである。 （３）上記（１）の記載及び上記（２）から、引用文献１には、以下の発明（以下「引用発明」という。）が記載されていると認められる。 「複数のクライアント１から、ユーザにより入力される希望会合日時、希望会合場所範囲及び会合メンバ候補が含まれる希望会合情報を受信し、 希望会合情報中の、会合メンバ候補となっているクライアント１のうち、希望会合日時及び希望会合場所範囲が適合するクライアント群である適合クライアント群を、クライアント１毎に抽出するクライアント希望会合情報マッチング部５３、抽出された全クライアント１の適合クライアント群から、最適会合クライアント群集合の生成を行う最適会合クライアント群集合生成部５４、及び生成された最適会合クライアント群集合の各要素である最適会合クライアント群について、それに属する複数のクライアント１の希望会合情報をさらに調停し、最終的な会合を設定する会合設定部５５と、 各最適会合クライアント群に対して決定された、最終的な会合の日時、待ち合わせ場所の情報を、設定会合情報として、当該最適会合クライアント群に属するクライアント１全員に送信し、さらに、会合に参加が誘われている人の情報を送信する、設定会合情報送信部５６とを有する、 サーバ２。」 ２ 周知技術 （１）当審拒絶理由にて引用された引用文献２には、図面とともに、以下の記載がある。 「【００５６】 （処理フロー） 図６Ａ，６Ｂは、本発明の実施形態に係る検索処理フローを示す図である。以下の処理フロー図（フローチャート）においては、各ステップの入力と出力の関係を損なわない限り、各ステップの処理順序を入れ替えてもよい。 【００５７】 検索処理では、まず、検索サーバ１００の検索条件取得部１３が、ユーザ端末２００から検索条件（検索クエリと検索範囲）を取得する（ステップＳ１０）。そして、検索条件解析部１４が、検索条件の中に日時情報があるかを判定する（ステップＳ１１）。日時情報とは、何日何時という明確なものでなくともよく、「週末」、「今度の休み」、「年明けに」とかいったものでもよい。日時情報が検索条件にある場合は、その日時が特定されているかを判定し（ステップＳ１２）、特定されていなければ、その範囲内の日時を推定する（ステップＳ１３）。例えば、「週末の夜」であれば、ユーザの個人登録情報を参照して、直近の土日の１８時以降であると推定する。 【００５８】 次に、日時情報がある場合もない場合もステップＳ１４に進み、今度は場所情報が検索条件にあるかを判定する。場所情報がない場合は、検索者（ユーザ）の現在位置をＧＰＳ等で取得し、現在地周辺の駅リストを作成する（ステップＳ１５）。駅リストとは、検索対象とする駅をすべて含んだリストのことである。場所情報がある場合は、その場所情報が路線又は駅を指定しているかどうかを判定する（ステップＳ１６）。路線又は駅を指定している場合は、指定された範囲内の駅を抽出し、駅リストを作成する（ステップＳ１７）。 【００５９】 ステップＳ１６において、路線又は駅を指定していない場合は、エリアが指定されているかどうかを判定する（ステップＳ１８）。既に述べたように、エリアはユーザが独自に定義可能であるが、ユーザがエリアを特に定義していない場合は、デフォルトの定義が用いられる。例えば、エリアを単に「渋谷」と指定した場合は、各路線の渋谷駅全体又は渋谷区にある駅がすべて検索対象となる。エリアが検索条件に指定されている場合は、そのエリア内の駅を、ユーザのエリアの定義に基づいて抽出し、駅リストを作成する（ステップＳ１９）。ステップＳ１８でエリアが指定されていないと判定した場合は、場所情報が指定されていないことになるので、ステップＳ１５に移り、現在地周辺の駅を検索対象とする。 【００６０】 場所情報の処理（ステップＳ１４～Ｓ１９）が終わると、ステップＳ２０に移り、今度は店舗／施設情報が検索条件にあるかを判定する。店舗／施設情報がない場合は、目的情報があるかを判定する（ステップＳ２１）。目的情報とは、日時情報、場所情報以外で、検索の目的を判定できる情報のことである。例えば、店や施設を指定していなくとも、「飲み会」、「女子会」、「歓迎会」、「忘年会」、「新年会」、「誕生会」、「ぶらり歩き」、「デート」等が目的情報となる。 【００６１】 ステップＳ２１において、目的情報もないと判定された場合は、検索対象が不明と判断し、検索条件の再入力を要求し（ステップＳ２２）、ステップＳ１０に戻る。ステップＳ２１で目的情報があると判定された場合は、その目的情報に応じて店舗／施設を推定する（ステップＳ２３）。 【００６２】 例えば、目的が「飲み会」であれば、居酒屋、料理店、バーなどが推定されるが、ユーザの個人登録情報のプロフィールを参照して、ユーザの予算に合いそうな店舗を中心に検索するようにしてもよい。また、友達検索が指定されていれば、その友達のプロフィールをさらに参照してもよい。そして、推定された店舗／施設に応じて、必要であれば外部の検索サイトを決定する（ステップＳ２４）。ステップＳ２０において、店舗／施設情報があると判定された場合は、指定された店舗／施設に応じて、必要であれば外部の検索サイトを決定する（ステップＳ２５）。 【００６３】 検索実行部１５は、上記で決定された検索サイト又は自らの検索エンジンによって店舗／施設の検索を実行し、その検索結果を取得する（ステップＳ２６）。この検索においては、路線情報ＤＢ２１、店舗／施設情報ＤＢ２２、エリア別店舗／施設情報ＤＢ２３を参照する。また、外部の検索サイトを利用するときは、外部検索サイト連携部１６が外部検索サイトの特性に応じて検索クエリを作成し、検索を実行させる。そして検索実行部１５は、上記のステップＳ２０～Ｓ２６を、駅リストの全駅について実行したかを判定し（ステップＳ２７）、全駅について終了していなければ検索する駅のＩＤを変更し（ステップＳ２８）、ステップＳ２０に戻る。全駅について処理を完了していれば、図6BのステップＳ３０に移る。 【００６４】 次に検索結果表示部１７は、図6BのステップＳ３０では、友達検索の指定があるかどうかを判定する。友達検索の指定があれば、登録ＳＮＳサイト又はユーザ情報ＤＢ２０から、友達の情報を取得し（ステップＳ３１）、ステップＳ４１にスキップする。 【００６５】 ステップＳ３０で友達検索の指定がないと判定される場合は、ステップＳ３２に移り、目的情報が検索条件の中にあるかを判定する。目的情報が宴会の場合（ステップＳ３３：Ｙ）、その宴会の種類に応じて、登録ＳＮＳ等からその宴会にふさわしいと考えられるメンバを抽出し、参加候補者に指定する（ステップＳ３４～Ｓ３９）。例えば、歓送会であれば同僚を、同窓会であれば同窓会メンバを、女子会であれば女性の友達を抽出して参加候補者に指定する。図示していないが、歓送会、同窓会、女子会以外の宴会についても、ステップＳ３４～Ｓ３９と同様の処理が続く。 【００６６】 そして、参加候補者にユーザ自身（検索実行者）も指定する（ステップＳ４０）。参加候補者の指定が終わると、ステップＳ４１に進む。なお、図のフローでは、目的情報が宴会でない場合は、参加候補者を抽出していないが、目的情報によって参加候補者を抽出できる場合は、その目的に応じて参加候補者を抽出するようにしてもよい。 【００６７】 次に検索結果表示部１７は、ステップＳ４１では定期券区間の指定があるかを判定する。定期券区間の指定がなければステップＳ４４にスキップする。定期券区間の指定がある場合は、参加候補者が定期券情報を登録していれば、その定期券情報を取得し（ステップＳ４２）、参加候補者の交通費（定期券情報を登録している参加候補者の場合は「＋交通費」）を算出する（ステップＳ４３）。 【００６８】 そして、算出された交通費を含む参加候補者の情報を検索結果に表示する（ステップＳ４４）。また、友達参加依頼部１８は、次にステップＳ４５で、参加候補者にメッセージ（ＳＭＳ又はメール）を送る指定があるかどうかを判定し、指定があれば参加候補者を検索結果の中からユーザに選択させ、参加依頼や参加者募集のメッセージを送信する（ステップＳ４６）。その後、友達参加依頼部１８は、参加者の集まり具合を検出する機能を有するが、これについては後述の画面で説明することにする。以上で、検索サーバ１００が行う主な処理が終了する。」 「【図６Ａ】 ［図：0001435927000003.jpg］ 【図６Ｂ】 ［図：0001435927000004.jpg］ 」 以上の記載から、引用文献２には、以下の事項が記載されていると認められる。 「ユーザ端末２００から取得される検索条件（検索クエリと検索範囲）に含まれる日時情報、場所情報、目的情報等に基づいて店舗／施設の検索や参加候補者の情報を検索する処理を行う場合に、何日何時という明確な日時情報が特定されていなくても、それを特定するための他の情報（例えば、日時情報が「週末の夜」であれば、直近の土日の１８時以降という情報）、場所情報、目的情報等に基づいて処理を可能とすること。」 （２）特開２００８－１４６５２５号公報（以下「引用文献３」という。）には、図面とともに、以下の記載がある。 「【００７２】 次に、図23を参照して、スケジュール調整システム２のサーバ１２のＣＰＵ１２１１において実施されるスケジュール調整プログラム１２２１の全体処理について説明する。図23は、スケジュール調整プログラム１２２１の全体処理のフローチャートである。 【００７３】 図23に示すスケジュール調整処理は、サーバ１２においてスケジュール調整プログラム１２２１が起動されると開始される。処理が開始されると、ＣＰＵ１２１１は、ユーザ端末３０のいずれかにおいて、ユーザ３００がネットワークを介してサーバ１２のスケジュール調整プログラム１２２１にアクセスし、新規イベントに関するデータをユーザ端末３０で入力し、サーバ１２に送信してきたかどうかをチェックする（Ｓ９０１）。ユーザ端末３０からデータが入力され、サーバ１２のＲＡＭ１２１３に記憶されると（Ｓ９０１：ＹＥＳ）、ＣＰＵ１２１１は、後で詳述するスケジュール決定処理を行い（Ｓ９０２）、この過程でエラーが発生した場合は（Ｓ９０３：ＹＥＳ）、再び、ユーザ端末３０からの入力の有無の監視に戻る（Ｓ９０１）。 【００７４】 一方、スケジュール決定処理（Ｓ９０２）においてエラーが生じなかった場合には（Ｓ９０３：ＮＯ）、社内の参加メンバーの利用するユーザ端末３０に、スケジュール決定処理（Ｓ９０２）において決定された新規スケジュールの区分、日時、所要時間、場所、参加メンバーおよび内容（会議名称）を含む「新規スケジュール登録完了通知」を電子メールで送信するとともに、社外の参加メンバーの利用する社外端末１００に、前述の内容で新規スケジュールの登録を依頼する「新規スケジュール登録依頼通知」を送信する（Ｓ９１１）。」 「【００８０】 次に、図24～図27を参照して、図23のスケジュール調整プログラム１２２１の全体処理で行われるスケジュール決定処理について説明する。図24は、スケジュール決定処理のメイン処理のフローチャートである。図25は、スケジュール決定処理で行われる場所決定処理のサブルーチンのフローチャートである。図26は、スケジュール決定処理で行われる日時決定処理のサブルーチンのフローチャートである。図27は、スケジュール決定処理で行われる日時・場所決定処理のサブルーチンのフローチャートである。 【００８１】 まず、図24のフローチャートと、図9、図11、および図15を参照して、スケジュール決定処理のメイン処理について説明する。処理が開始されると、ＣＰＵ１２１１はまず、ＲＡＭ１２１３に設けられたエラーフラグ記憶エリア（図示外）をＯＦＦにする（Ｓ５００）。そして、個人スケジュールデータベース１２２２から、社内の参加メンバー全員分の個人スケジュールデータを取得して、ＲＡＭ１２１３に記憶させる（Ｓ５０１）。そして、ユーザ端末３０から入力され、ＲＡＭ１２１３に記憶された新規イベントデータに、特定の日時データが含まれているか否かを判断する（Ｓ５０２）。図9の例のように、「２００６年１２月４日１０：００」などの特定の日時が入力されている場合は（Ｓ５０２：ＹＥＳ）、取得したスケジュールデータから、その指定日時から所要時間分、社内の参加メンバー全員に空きがあるか否かを判断する（Ｓ５１１）。社内の参加メンバーのいずれかのスケジュールデータに、すでに他のイベントが登録されている場合には、指定された日時では新規スケジュールを登録できないため、エラーフラグをＯＮにして（Ｓ５１２）、入力者であるユーザ３０１の利用するユーザ端末３０に、その旨を電子メールで通知する（Ｓ５１３）。」 「【００８４】 一方、ユーザ端末３０から入力され、ＲＡＭ１２１３に記憶された新規イベントに関する入力データに、特定の日時データが含まれていない場合には（Ｓ５０２：ＮＯ）、ＣＰＵ１２１１は、入力データに、特定の場所データが含まれているか否かを判断する（Ｓ５５１）。特定の場所データが含まれている場合には、後述する日時決定処理を行う（Ｓ５６１）。特定の場所データがない場合には（Ｓ５５１：ＮＯ）、第１の実施形態と同様のイベント希望場所決定処理を行い（Ｓ５６２）、さらに後述する日時・場所決定処理を行う（Ｓ５６３）。そして、日時決定処理（Ｓ５６１）および日時・場所決定処理（Ｓ５６３）が終了した後は、いずれも図23に示すスケジュール調整プログラム１２２１のメイン処理に戻る。」 「【００８８】 次に、図26のフローチャートを参照して、図24のスケジュール決定処理に行われる日時決定処理について説明する。この処理は、ユーザ端末３０からの入力データにおいて、特定の場所は指定されているが、特定の日時は指定されていない場合に行われる処理である。 【００８９】 図26に示す日時決定処理が開始されると、ＣＰＵ１２１１はまず、ＲＡＭ１２１３に記憶された新規イベントの入力データから、入力時に指定された場所が、社内か社外かを判断する（Ｓ７０２）。指定場所が社内、すなわち、社内の会議室のいずれかであれば（Ｓ７０２：ＹＥＳ）、次に、スケジュール決定処理のＳ５０１（図24）で取得された社内の参加メンバーのスケジュールデータから、入力時に指定された指定期間または所定期間（例えば、１週間）中に全員が所要時間分空いている日時があるか否かをチェックする（Ｓ７１１）。全員空いている日時がまったくなければ（Ｓ７１１：ＮＯ）、スケジュールを決定できないため、エラーフラグをＯＮにして（Ｓ７１２）、入力者であるユーザ３０１の利用するユーザ端末３０に、その旨を電子メールで通知する（Ｓ７１３）。全員が空いている日時があれば、会議室スケジュールデータベース１２２３から、指定期間または所定期間中の指定された会議室のデータを取得する（Ｓ７１５）。そして、取得された指定会議室のデータから、この期間中には空いている日時がまったくないと判断した場合は（Ｓ７２１：ＮＯ）、エラーフラグをＯＮにして（Ｓ７１２）、入力者であるユーザ３０１の利用するユーザ端末３０に、その旨を電子メールで通知する（Ｓ７１３）。指定会議室が所要時間分空いている日時があれば、これを候補日時として抽出する（Ｓ７２２）。そして、候補日時が一つだけであれば（Ｓ７３１：ＮＯ）、その日時を開催日時として決定し、複数ある場合は（Ｓ７３１：ＹＥＳ）、候補日時のうち、最も早い日時を開催日時として決定し（Ｓ７４１）、図24のスケジュール決定処理に戻る。」 以上の記載から、引用文献３には、以下の事項が記載されていると認められる。 「ユーザ３００がユーザ端末３０で入力した新規イベントに関するデータに基づいてスケジュール決定処理を行う場合に、新規イベントに関するデータに特定の日時データが含まれていなくても、日時を特定するための他の情報（「所定期間（例えば、１週間）」という情報）及び特定の場所データ（指定会議室）に基づいて処理を可能とすること。」 （３）特開２００８－９０５２０号公報（以下「引用文献４」という。）には、図面とともに、以下の記載がある。 「【００４０】 ここで、図4乃至図29を参照して、第１の実施の形態について説明する。第一の実施の形態では、ユーザ端末１０においてユーザにより入力された希望情報に基づいて、サーバ２０においてスケジュール調整の処理が行われる。」 「【００５９】 次に、図15乃至図18を参照して、ユーザ端末１０において表示される画面について説明する。図15は、新規スケジュール入力画面９０１の説明図であり、図16は、登録確認画面９０２の説明図であり、図17は、出欠確認画面９０３の説明図であり、図18は、屋外キャンセル画面９０４の説明図である。 【００６０】 図15に示す新規スケジュール入力画面９０１は、ユーザ端末１０において、端末プログラムを起動させ、「新規スケジュールの登録」を指示するとディスプレイ１４に表示される。図15に示すように、会議名入力欄、希望日時入力欄、希望開催場所入力欄、参加者入力欄、出欠判定条件入力欄、天候判定条件入力欄、登録ボタン、キャンセルボタンが設けられている。会議名入力欄には、当該スケジュールの名称が入力される。希望日時欄には、「日時で指定」のラジオボタン及び「期間で指定」のラジオボタンが設けられている。「日時で指定」ラジオボタンが選択されている場合には、開始時刻及び所要時間を入力可能となっており、「期間で指定」ラジオボタンが選択されている場合には、所要時間及び、希望時間帯を入力可能となっている。図15に示す例では、３つの希望時間帯が入力可能となっており、それぞれに日付入力欄と、時間帯の開始時刻及び時間の入力欄、又は午前午後指定リストボックスとが設けられている。 【００６１】 そして、希望開催場所には「屋外」ラジオボタン及び「屋内」ラジオボタンが設けられている。そして、「屋外」ラジオボタンが選択されている場合には、建物を選択するリストボックス及びスペースを選択するリストボックスが選択可能となっている。なお、建物選択のリストボックスでは、場所ＤＢ記憶エリア２８２に「屋外」として記憶されているデータの建物欄に記憶されている建物の名称が選択肢とされ、スペース選択のリストボックスでは、「屋外」として記憶されているデータの部屋欄に記憶されている屋外スペースの名称が選択肢とされる。そして、「屋内」ラジオボタンが選択されている場合には、建物を選択するリストボックス及び部屋を選択するリストボックスが選択可能となっている。なお、建物選択のリストボックスでは、場所ＤＢ記憶エリア２８２に「屋内」として記憶されているデータの建物欄に記憶されている建物の名称が選択肢とされ、スペース選択のリストボックスでは、「屋内」として記憶されているデータの部屋欄に記憶されている部屋の名称が選択肢とされる。 【００６２】 そして、参加者欄には、参加者の指名が入力される。なお、ここでは、この会議に必ず出席して欲しい参加者を「必須参加者」とし、その氏名の頭には「＊」をつけるように指示されている。そして、出欠判定条件欄には、何パーセント以上の出席者がいるときにこのスケジュールを本決まりとするかを示す値が入力される。そして、天候判定条件欄には、天気が晴れに関する天気でない（以下、雨天候とする）場合に、参加者の移動距離に関する値である「移動距離値」に基づいて、実施場所が遠すぎないかを判定する。その際の基準値となる値が記憶される。 【００６３】 そして、登録ボタンが選択されると、この新規スケジュール入力画面９０１に入力された情報が「希望情報」としてサーバ２０へ送信される。また、キャンセルボタンが選択されると、入力された情報は破棄され、サーバ２０への情報の送信は行われない。」 「【００６８】 次に、図19乃至図29を参照して、サーバ２０のＣＰＵ２１サーバプログラムが十されて行われるスケジュール調整処理について説明する。図19は、メイン処理のフローチャートであり、図20は、メイン処理で実施される日時場所指定処理のフローチャートであり、図21は、希望日時処理及び日情報未指定場所指定処理で行われる場所検討処理のフローチャートであり、図22は、メイン処理で実施される日時未指定場所指定処理のフローチャートであり、図23は、日時未指定場所指定処理で実施される晴れ日時検討処理のフローチャートであり、図24は、日時指定場所未指定処理のフローチャートである。そして、図25乃至図27は、日時場所未指定処理のフローチャートであり、図26は、図25のフローチャートの続きであり、図27は、図26のフローチャートの続きである。そして、図28は、出欠確認処理のフローチャートであり、図29は、実施判定処理のフローチャートである。 【００６９】 まず、図19を参照して、メイン処理について説明する。このメイン処理は、ユーザ端末１０において、新規スケジュール入力画面９０１に入力が行われ、そこで入力された情報である希望情報を受信したことを契機に開始される処理である。ここでは、希望情報の内容により、「日時、場所共に唯一に指定されている」場合、「場所のみ唯一に指定されている」場合、「日時のみ唯一に指定されている」場合、「日時も場所も唯一に指定されていない」場合の４つの場合分けが行われ、それぞれの場合に応じた処理が行われる。なお、ここでは新規スケジュール入力画面９０１の入力が行われた起案者のユーザ端末１０をユーザ端末１１ということとする。 【００７０】 そこで、まず、受信された希望情報が希望情報記憶エリア２３４に記憶される（Ｓ１）。ここで、希望日時として日時が指定されていない場合には、本日より後の１週間の営業時間が希望日時とされる。例えば、本日が９月１日（金）であれば、９月４日(月)～９月８日(金)の９：００～１８：００が希望日時とされる。そして、希望日時に唯一の日時が指定され、日時が決まっているか否かの判断が行われる（Ｓ２）。新規スケジュール入力画面９０１（図15参照）において希望日時入力欄において「日時で指定」ラジオボタンが選択されて、唯一の日時が指定されていた場合に、日時が決まっていると判断される（Ｓ２：ＹＥＳ）。そして、唯一の場所が指定され、場所が決まっているか否かの判断が行われる（Ｓ４）。新規スケジュール入力画面９０１において希望場所入力欄において部屋又はスペースが選択されていれば、場所が決まっていると判断される（Ｓ４：ＹＥＳ）。これは「日時、場所共に唯一に指定されている」場合であるので、日時場所指定処理が行われる（Ｓ８、図20参照）。また、日時は決まっているが（Ｓ２：ＹＥＳ）、場所は決まっていない場合には（Ｓ４：ＮＯ）、「日時のみ唯一に指定されている」場合に該当するので、日時指定場所未指定処理が行われる（Ｓ５、図24参照）。また、日時が決まっておらず（Ｓ２：ＮＯ）、場所は決まっている場合には（Ｓ３：ＹＥＳ）、「場所のみ唯一に指定されている」場合に該当するので、日時未指定場所指定処理が行われる（Ｓ６、図22参照）が行われる。そして、日時も決まっておらず（Ｓ２：ＮＯ）、場所も決まっていない場合には（Ｓ３：ＮＯ）、日時場所未指定処理が行われる（Ｓ７、図25参照）。」 「【００８３】 次に、図22及び図23のフローチャートを参照して、「場所のみ唯一に指定されている」場合に実施される日時未指定場処理について説明する。ここでは、「希望場所」が唯一に指定されており、「希望日時」は唯一に指定されていない。例えば、２００６年９月４日の１０：００から１時間、２００６年９月４日の１４：００から１時間、２００６年９月４日の１６：００から１時間が「希望日時」とされており、建物「開発センター」の部屋「１階応接会議室」が「希望場所」として指定されているものとする。 【００８４】 まずは、希望場所が「実施場所」として実施場所記憶エリア２３２に記憶される（Ｓ２１）。そして、希望日時における実施場所の予約状況が開催場所予約状況記憶エリア２８５から読み出され、実施場所に予約の入っていない日時が「参加可能日時」として、参加可能日時記憶エリア２３５の参加可能日時欄に記憶される（Ｓ２２）。そして、参加可能日時があったか否かの判断が行われる（Ｓ２３）。参加可能日時記憶エリア２３５の参加可能日時欄に日時が記憶されており、参加可能日時があれば（Ｓ２３：ＹＥＳ）、Ｓ２４へ進むが、参加可能日時記憶エリア２３５の参加可能日時欄に日時が記憶されておらず、参加可能日時がなければ（Ｓ２３：ＮＯ）、起案者のユーザ端末１１へ「希望日時では参加者の都合があわない」旨を示すメッセージ画面を表示させるための情報が送信される（Ｓ４６）。そして、日時未指定処理は終了し、メイン処理へ戻り、メイン処理も終了する。 【００８５】 そして、参加可能日時があった場合には（Ｓ２３：ＹＥＳ）、参加可能日時が１つだけであるか否かの判断が行われる（Ｓ２４）。参加可能日時が１つだけであった場合には（Ｓ２４：ＹＥＳ）、その日時が「実施日時」として実施日時記憶エリア２３１に記憶され（Ｓ４７）、実施場所も実施日時も唯一に決定されたことになるので、場所検討処理が行われ（Ｓ４８、図21参照）、日時未指定処理は終了してメイン処理へ戻り、メイン処理も終了する。なお、場所検討処理については、「日時、場所共に唯一に指定されている」場合において、日時場所指定処理のＳ１４で実施された内容と同様であるので、説明を引用して省略する。」 以上の記載から、引用文献４には、以下の事項が記載されていると認められる。 「ユーザがユーザ端末１０において入力した希望日時、希望開催場所等の情報に基づいてスケジュール調整の処理を行う場合に、希望日時が指定されていなくても、それを特定するための他の情報（「本日より後の１週間の営業時間」という情報）及び希望開催場所に基づいて処理を可能とすること。」 （４）上記（１）～（３）の引用文献２～４に記載された技術は、いずれも「飲み会」、「会議」等の会合の開催を支援（参加候補者のスケジュール調整に関する処理や、会合を行う店舗／施設の検索を行う等）するシステムに関するものと認められるところ、そのいずれも、「ユーザが入力した情報に基づいて希望する情報処理を行う場合に、希望する日時等の一部の情報が指定されていなくても、それを特定するための他の情報が指定されているものとして、ユーザが入力した情報に基づいて処理を可能とする」ものであり、当該技術は周知技術と認められる。 第５ 対比 １ 本願発明と引用発明とを対比する。 （１）引用発明の「サーバ２」が、「複数のクライアント１から、ユーザから入力される希望会合日時、希望会合場所範囲及び会合メンバ候補が含まれる希望会合情報を受信」することに関し、「希望会合日時、希望会合場所範囲及び会合メンバ候補が含まれる希望会合情報」は、「ユーザ」が「会合」の設定を希望する場合におけるその設定の要求を示す情報であることは明らかであり、本願発明１の「会合の設定を希望する設定要求」に相当し、「サーバ２」がその受信手段を備えていることは明らかであり、当該手段は、本願発明の「受信部」に相当する。 また、引用発明の「クライアント１」は、本願発明の「端末装置」に相当する。 よって、引用発明の「サーバ２」は、本願発明の「複数のユーザの端末装置から、会合の設定を希望する設定要求を受信する受信部」に相当する構成を備えるものである。 （２）引用発明の「希望会合情報中の、会合メンバ候補となっているクライアント１のうち、希望会合日時及び希望会合場所範囲が適合するクライアント群である適合クライアント群を、クライアント１毎に抽出するクライアント希望会合情報マッチング部５３、抽出された全クライアント１の適合クライアント群から、最適会合クライアント群集合の生成を行う最適会合クライアント群集合生成部５４、及び生成された最適会合クライアント群集合の各要素である最適会合クライアント群について、それに属する複数のクライアント１の希望会合情報をさらに調停し、最終的な会合を設定する会合設定部５５」に関し、「最終的な会合」が「設定」される「最適会合クライアント群」は、「希望会合情報」に基づいて、「希望会合情報」の送信元の「会合メンバ候補となっているクライアント１」のうち、一つの「最終的な会合」に組み入れる「最適会合クライアント群」に「属する」「複数のクライアント１」を選択することにより「生成」されるものといえる。 また、ここで、「クライアント１」は「希望会合日時」等を「入力」する「ユーザ」が所有するものであることは明らかであるから、「クライアント群」の選択は、「会合メンバ候補となっているクライアント１」を所有する複数の「ユーザ」のうち、一つの「最終的な会合」に組み入れる「ユーザ」の選択といえる。 （３）引用発明の「最適会合クライアント群に対して決定された、最終的な会合の日時、待ち合わせ場所の情報を、設定会合情報として、当該最適会合クライアント群に属するクライアント１全員に送信し、さらに、会合に参加が誘われている人の情報を送信する、設定会合情報送信部５６」に関し、「送信」される「情報」（「最終的な会合の日時、待ち合わせ場所の情報」及び「会合に参加が誘われている人の情報」）中に、上記（２）の選択の対象とされ、「最適会合クライアント群に属するクライアント１全員」である、「会合に参加が誘われている」各「ユーザ」の情報が含まれること、及び「送信」が、当該「送信」される「情報」に含まれる、「最適会合クライアント群に属するクライアント１全員」すなわち「ユーザ」の「クライアント１」各々に対して行われることは明らかであり、当該「送信」される「情報」は、本願発明の「会合に参加するユーザの情報を含む参加者情報」に相当する。 また、上記（２）の「ユーザ」の選択及び上記「送信」される「情報」の生成を行う手段が、引用発明の「サーバ２」が「有する」「クライアント希望会合情報マッチング部５３」、「最適会合クライアント群集合生成部５４」及び「会合設定部５５」に存在していることは明らかであり、引用発明の当該手段は、本願発明の「選択部」に相当し、さらに、引用発明の「サーバ２」が「有する」「設定会合情報送信部５６」は、本願発明の「送信部」に相当する。 よって、引用発明の「サーバ２」は、本願発明の「前記設定要求に基づいて、複数のユーザのうち、一つの会合に組み入れるユーザを選択し、会合に参加するユーザの情報を含む参加者情報を生成する選択部」及び「前記参加者情報を、当該参加者情報に含まれるユーザの端末装置各々に対して送信する送信部」に相当する構成を備えるものである。 （４）本願発明の「前記設定要求に含まれる情報であって場所に関する情報と参加人数に関する情報との少なくとも一方からなる情報」との発明特定事項は、換言すれば、「場所に関する情報と参加人数に関する情報との少なくとも一方からなる情報」が「前記設定要求に含まれる情報」であることであり、また、当該発明特定事項は、「前記設定要求」に「場所に関する情報」が含まれているが、「参加人数に関する情報」は含まれていない場合を包含していると解し得るものである。 一方、引用発明の「希望会合日時、希望会合場所範囲及び会合メンバ候補が含まれる希望会合情報」における「希望会合場所範囲」は、本願発明の「場所に関する情報」に相当する。 よって、本願発明の上記発明特定事項と、引用発明の「希望会合日時、希望会合場所範囲及び会合メンバ候補が含まれる希望会合情報」とは、「場所に関する情報と参加人数に関する情報との少なくとも一方からなる情報が前記設定要求に含まれる情報である」という点で一致している。 （５）引用発明の「サーバ２」は、その「会合設定部５５」が「最終的な会合を設定する」から、本願発明１の「会合設定サーバ」に相当する。 ２ 上記１から、本願発明と引用発明とは、以下の点で一致する。 （一致点） 「複数のユーザの端末装置から、会合の設定を希望する設定要求を受信する受信部と、 前記設定要求に基づいて、前記複数のユーザのうち、一つの会合に組み入れるユーザを選択し、当該会合に参加するユーザの情報を含む参加者情報を生成する選択部と、 前記参加者情報を、当該参加者情報に含まれるユーザの端末装置各々に対して送信する送信部とを備え、 場所に関する情報と参加人数に関する情報との少なくとも一方からなる情報が前記設定要求に含まれる情報である、 会合設定サーバ。」 ３ また、本願発明と引用発明とは、以下の点で相違する。 （相違点） 本願発明は、「前記設定要求において前記会合を希望する日時に関する情報が指定されなくても、前記設定要求に含まれる情報であって場所に関する情報と参加人数に関する情報との少なくとも一方からなる情報に基づいて、前記会合を設定可能である」であるのに対して、引用発明は、「ユーザにより入力される希望会合日時、希望会合場所範囲及び会合メンバ候補が含まれる希望会合情報」に基づいて、「最終的な会合を設定する」ものの、「希望会合情報」に「希望会合日時」が含まれていなくても、それが可能であることが特定されるものではない点。 第６ 当審の判断 １ 相違点についての検討 上記相違点について、以下に検討する。 上記第４の２（４）の周知技術は、ユーザが一部の情報の入力を省略しても適切な情報処理が可能となる点で利便性が向上するものであり、ユーザの利便性の向上はサーバ等を含めたコンピュータシステムにおいて一般的な課題であるところ、引用発明において、「最終的な会合を設定する」処理の利便性を向上させるため、当該周知技術を適用して、「希望会合情報」に「希望会合日時」が含まれていなくても、「希望会合情報」に含まれる「希望会合場所範囲」等に基づいて「最終的な会合を設定する」ものとすることは、当業者が容易に想到し得ることである。 なお、人が（必ずしもコンピュータシステムを使用せずに）会合を企画する際に、まず、具体的な日時は設定せずに場所や人数等の概略等の決定（参加者募集等）を行い、その後、日時等の詳細を調整することも広く行われているところ、引用発明に当該広く行われている事項を適用し、前者の概略等を決定する過程について「最適会合クライアント群」を生成することを「会合設定サーバ」を利用して行うものとし、もって、「前記設定要求において前記会合を希望する日時に関する情報が指定されなくても、前記設定要求に含まれる情報であって場所に関する情報と参加人数に関する情報との少なくとも一方からなる情報に基づいて、前記会合を設定可能」とすることは、当業者が容易に想到し得ることともいえる。 ２ 作用効果について 本願発明の作用効果は、引用発明及び周知技術から、当業者が容易に予測し得る程度のものである。 ３ 請求人の主張について （１）請求人は、令和８年１月１６日提出の意見書において、引用文献２に記載された発明は、単に「店舗／施設」を検索するものであって、「会合」を設定する本願発明とは根本的に異なり、ユーザ及び友達の定期券情報を利用して、定期券を有効に利用できる（つまりプラスで発生する交通費を抑えられる）ような立地の店舗／施設を検索するものであり、その上で、「日時情報が検索条件にある場合」には、当該日時情報を加味して店舗／施設を検索し、「日時情報」が「ない場合」には、日時情報を加味せずに店舗／施設を検索するというものにすぎず、要するに、引用文献２には、そもそも本願発明のように「会合」を設定することすら記載されていないのであって、このような引用文献２の記載に触れただけの当業者が、会合の設定に関する上記相違点に係る本願発明の構成に想到することは、到底容易とはいえない旨主張している。 引用発明は、「会合設定部５５」が「最終的な会合を設定する」ものであり、請求人のいう「会合」を設定する点について本願発明と相違するものではないことからすれば、請求人は、引用文献２に記載された発明は「会合」を設定するものではなく、引用発明と技術分野が相違することを根拠に、引用発明に引用文献２に記載された発明を適用することは困難であり、本願発明は当業者が容易に想到することができたものではないことを主張しているものと解される。 しかしながら、引用文献２のみならず、上記第４の２（４）の事項が周知技術であることは引用文献３、４からも明らかであって、引用発明と当該周知技術とは、会合の開催を支援する点で技術分野が共通しており、適用が困難なほどに技術分野が相違するものとはいえず、上記１のとおり、引用発明に当該周知技術を適用することは当業者が容易に想到し得ることである。 （２）請求人はまた、引用文献１の記載から出発して、本願発明の構成に想到するためには、引用文献２に記載された技術的事項（検索条件中に日時情報がある場合もない場合も店舗／施設を検索する）を適用した上で、さらに、「会合」を希望する日時に関する情報が指定されなくても、（設定要求に含まれる場所に関する情報と参加人数に関する情報との少なくとも一方に基づいて）前記「会合」を設定可能とすることを想到する必要があり、このように、引用発明に基づいて２つの段階を経て初めて上記相違点に係る本願発明の構成に至ることは、格別の努力を要するものといえ、当業者にとって容易に想到できるものではない旨主張している。 しかしながら、引用文献２には、上記第４の２（１）の末尾に記載したとおりの、「店舗／施設の検索や参加候補者の情報を検索する処理」を含む事項が記載されていると認められるところ、当該事項における「店舗／施設」は、検索処理の対象の一例にすぎず、当該事項からすれば、処理の内容が「店舗／施設の検索」に限られない上記第４の２（４）の事項が周知技術であることは明らかである。 そして、上記１のように引用発明に当該周知技術を適用する際、請求人のいう「２つの段階を経て」本願発明の構成に至るものではないことも上記１から明らかである。 （３）よって、請求人の主張はいずれも採用できない。 ４ 小括 したがって、本願発明は、引用発明及び周知技術に基づいて、当業者が容易に発明をすることができたものである。 第７ むすび 以上のとおり、本願発明は、引用文献１に記載の発明及び周知技術に基づいて、当業者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。 よって、結論のとおり審決する。