2021-013238

特願２０１９－１３１５９７「柔軟なルーティングのためのシステム及び方法」拒絶査定不服審判事件〔令和 ２年 １月２３日出願公開、特開２０２０－ １４２０７〕について、次のとおり審決する。

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

理 由 第１ 手続の経緯 本願は、令和元年７月１７日（パリ条約による優先権主張２０１８年７月１７日、米国、２０１８年１２月２１日、米国）の出願であって、その手続の経緯は、概略、以下のとおりである（以下、２０１８年７月１７日を「優先日」という。）。 令和２年 ６月 ２日付け：拒絶理由通知書 令和２年１２月 ４日 ：意見書、手続補正書の提出 令和３年 ５月２８日付け：拒絶査定 令和３年１０月 １日 ：審判請求書、手続補正書の提出 令和４年 ５月２０日付け：拒絶理由通知書 令和４年 ８月２４日 ：意見書、手続補正書の提出 令和４年１０月１３日付け：拒絶理由通知書（最後） 令和５年 １月１８日 ：意見書、手続補正書、誤訳訂正書の提出 第２ 本件補正について １ 本件補正の内容 令和５年１月１８日に提出された手続補正書による補正（以下「本件補正」という。）の前後の特許請求の範囲の請求項８は、それぞれ、以下の（１）及び（２）のとおりである。 （１）本件補正前の特許請求の範囲の請求項８は、以下のとおりである。 「 【請求項８】 第２の通信デバイスとの第１の通信セッションを確立するリクエストを受信するステップであって、前記第１の通信セッションを確立する前記リクエストは前記第１の通信セッションをルーティングするための第１のルーティング属性を備えるものである、ステップと、 前記第１のルーティング属性に基づきデータベースから１以上のルーティング規則をフェッチさせるステップと、 １以上の規則の集合を含む動的ルーティングフレームワークにおいて前記第１のルーティング属性があると判断した場合、前記第１のルーティング属性及び前記動的ルーティングフレームワークにおいて定義される１以上の規則に基づいて第３の通信デバイス又は送信先に前記第１の通信セッションをルーティングするステップと を備え、 前記第３の通信デバイス又は送信先は前記１以上のルーティング規則に基づき識別される、方法。」 （２）本件補正後の特許請求の範囲の請求項８の記載は、次のとおりである（下線は補正箇所を示し、当審で付した。）。 「 【請求項８】 第２の通信デバイスとの第１の通信セッションを確立するリクエストを受信するステップであって、前記第１の通信セッションを確立する前記リクエストは前記第１の通信セッションをルーティングするための第１のルーティング属性を備えるものである、ステップと、 前記第１のルーティング属性に基づきデータベースから１以上の第１のルーティング規則をフェッチさせるステップと、 １以上の規則の集合を含む動的ルーティングフレームワークにおいて前記第１のルーティング属性があると判断した場合、前記第１のルーティング属性及び前記動的ルーティングフレームワークにおいて含まれる前記１以上の第１のルーティング規則に基づいて第３の通信デバイス又は送信先に前記第１の通信セッションをルーティングするステップと を備え、 前記第３の通信デバイス又は送信先は前記１以上の第１のルーティング規則に基づき識別される、方法。」 なお、本件補正と同日にされた誤訳訂正書による補正は、明細書及び図面の誤訳の訂正を目的とするものである。 ２ 補正の適否について 請求項８に係る本件補正は、当審での令和４年１０月１３日付けの拒絶理由通知（最後）の理由２（明確性）の「１以上のルーティング規則」と動的ルーティングフレームワークにおいて定義される「１以上の規則」との関係が不明確であるとの指摘に対し、両者はともに、動的ルーティングフレームワークに含まれる「１以上の第１のルーティング規則」であることを明確にするためのものと認められる。そのため、請求項８に係る本件補正は、特許法１７条の２第５項４号に掲げる、明瞭でない記載の釈明を目的とするものに該当する。 また、請求項８に係る本件補正は、同法１７条の２第３項及び第４項の規定に違反するものでない。 その他、本件補正に違法は認められない。 したがって、本件補正は、適法になされたものである。 第３ 本願発明 本願の請求項８に係る発明（以下「本願発明」という。）は、前記第２、１（２）の本件補正後の特許請求の範囲の請求項８の記載のとおりのものと認める。 第４ 原査定の拒絶の理由 原査定の請求項８についての拒絶理由のうちの理由２は、次のとおりのものである。 この出願の請求項８に係る発明は、その出願前に日本国内又は外国において、頒布された又は電気通信回線を通じて公衆に利用可能となった下記の引用文献１に記載された発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。 引用文献１．特開２０１６－８２５０７号公報 なお、当審での令和４年５月２０日付けの拒絶理由通知、及び同年１０月１３日付けの拒絶理由通知（最後）は、新規性、進歩性等の特許要件についての判断を留保してなされたものである。 第５ 引用文献の記載及び引用発明 １ 引用文献１の記載 引用文献１には、次の事項が記載されている（下線は、強調のために当審で付した。）。 「【００１３】 本発明の第４の態様における通信接続方法は、ユーザ端末とＩＰネットワークを介して接続されるとともに、複数のオペレータ端末とＩＰネットワークを介して接続されたコンタクトセンタ装置の通信接続方法である。この通信接続方法は、以下のステップ（ａ）～（ｃ）を備える。 （ａ）オペレータへの問い合わせ内容を含むメッセージを前記ユーザ端末から受信するステップ、 （ｂ）前記問い合わせ内容に基づき、問い合わせを受け付けるオペレータ端末を前記複数のオペレータ端末の中から選択するステップ、及び （ｃ）選択したオペレータ端末に前記メッセージを送信することにより、前記ユーザ端末と前記オペレータ端末との間で通信を接続させるステップ。」 「【００２３】 ［実施の形態２］ 実施の形態２では、本発明にかかるコンタクトセンタシステム１の具体的な構成及び通信フローについて、さらに詳細に説明する。実施の形態２にかかるコンタクトセンタシステム１の全体構成は、図１に示した通りである。なお、ＩＰネットワーク３はインターネットであり、ＩＰネットワーク５はイントラネットである。コンタクトセンタ装置４、ＩＰネットワーク５及び複数のオペレータ装置６は、例えば社内ネットワークを形成している。」 「【００２４】 図２には、コンタクトセンタ装置４の構成例が示されている。コンタクトセンタ装置４は、メニュー情報提供部４１、インタラクション制御部４２、オペレータ選定部４３を備える。」 「【００２９】 次に、ユーザ端末２、コンタクトセンタ装置４及びオペレータ端末７の通信処理について、図３のシーケンス図を参照して説明する。」 「【００３３】 ユーザは、ユーザ端末２を用いてメニュー情報に回答することで、問い合わせ内容を入力する（ステップＳ３）。そして、ユーザがユーザ端末２を操作することで、問い合わせ内容を含むメッセージがインタラクション制御部４２に送信される（ステップＳ４）。例えば、図４において、ユーザが「対話開始」のボタン１０２を押下する操作を行うと、作成された問い合わせ内容が含まれるＳＩＰメッセージが、コンタクトセンタ装置４のインタラクション制御部４２に送信される。このメッセージは、ＳＩＰを用いたＩＰ電話の発呼やチャットの発信等において、ユーザ端末２からコンタクトセンタ装置４に初めて送信されるＩＮＶＩＴＥメッセージである。 【００３４】 図５は、ボタン１０２を押下することでコンタクトセンタ装置４に送信されるＳＩＰメッセージのヘッダ部の一例を示した図である。ＳＩＰメッセージのヘッダ部２０１は、必須ヘッダ部２０２と独自ヘッダ部２０３を有する。必須ヘッダ部２０２は、送信者欄「Ｆｒｏｍ」、受信者欄「Ｔｏ」等を有する、メッセージのヘッダが必ず備える情報である。なお、図４において、送信者であるユーザ端末２は「Ｕｓｅｒ＜ＳＩＰ：０９０１１１１２２２２＠１９２．１６８．０．１＞」のＩＰアドレスで示されている。また、受信者であるインタラクション制御部４２は「＜ＳＩＰ：０８０３３３３４４４４＠１９２．１６８.０．２＞」のＩＰアドレスで示されている。このインタラクション制御部４２のＩＰアドレスは、ステップＳ２でメニュー情報提供部４１から取得したものである。 【００３５】 独自ヘッダ部２０３は、ステップＳ３で作成された問い合わせ内容が含まれている部分である。図３における問い合わせの商品種別・問い合わせ商品・問い合わせ事項について、ユーザは例えば「テレビ」・「商品Ａ」・「購入」をそれぞれ選択する。その結果、図５における独自ヘッダ部２０３には、各選択項目を示す「ＴＶ」・「ｐｒｏｄｕｃｔ＿Ａ」・「ｂｕｙ」が問い合わせ内容として含まれる。 【００３６】 ユーザ端末２からメッセージを受信したインタラクション制御部４２は、メッセージ中の問い合わせ内容（図５の独自ヘッダ部２０３の内容）を検出し、その問い合わせ内容を含むオペレータ端末の選定要求をオペレータ選定部４３に出力する（ステップＳ５）。なお、この選定要求には、問い合わせ内容以外のメッセージの内容が一部又は全部含まれていてもよい。 【００３７】 オペレータ選定部４３は、選定要求中の問い合わせ内容に基づいてオペレータ端末の選定を行う（ステップＳ６）。例えば、オペレータ選定部４３には複数のオペレータ端末７のデータが格納されており、オペレータ選定部４３はそのデータと受信した問い合わせ内容とを比較することで、ユーザ端末２と接続される（ユーザの問い合わせを受け付ける）オペレータ端末７を選定する。 【００３８】 図６は、オペレータ選定部４３に格納されている複数のオペレータ端末７のデータである。ここで、複数のオペレータ端末７はｎ台設けられており、対応できる問い合わせ内容（対応可能内容）が１番～ｎ番のオペレータ端末毎に設定されている。図６では、１番のオペレータ端末は「テレビ、パソコン・商品Ａ、商品Ｂ・購入」の問い合わせ内容に対応可能であり、２番のオペレータ端末は「パソコン、オーディオ・商品Ａ、商品Ｃ・故障」の問い合わせ内容に対応可能である。また、ｎ－１番のオペレータ端末は「テレビ、パソコン、オーディオ・商品Ａ、商品Ｂ、商品Ｃ・購入」の問い合わせ内容に対応可能であり、ｎ番のオペレータ端末は「テレビ、オーディオ・商品Ａ、商品Ｃ・故障、その他」の問い合わせ内容に対応可能である。 【００３９】 また、図６のデータには、各オペレータ端末が現在応答可能か否かを示す「応答可能フラグ」も格納されている。オペレータ端末において応答可能フラグが「可」である場合にはそのオペレータ端末は現在応答可能であり、応答可能フラグが「不可」である場合にはそのオペレータ端末は現在応答不可である状態を示す。オペレータ選定部４３は、オペレータ端末が現在ユーザ端末と接続されている場合に、そのオペレータ端末の応答可能フラグを「不可」に設定する。図５では、１番のオペレータ端末の応答可能フラグは「可」であり、２番のオペレータ端末の応答可能フラグは「可」であり、ｎ－１番のオペレータ端末の応答可能フラグは「不可」であり、ｎ番のオペレータ端末の応答可能フラグは「可」である。 【００４０】 オペレータ選定部４３は、ユーザ端末２から送信された問い合わせ内容を参照し、その問い合わせ内容が対応可能内容に全て含まれる端末を最初に選択する。ユーザ端末２から送信された問い合わせ内容は「テレビ・商品Ａ・購入」であるため、オペレータ選定部４３はその問い合わせ内容が対応可能内容に全て含まれる１番及びｎ－１番のオペレータ端末を選択する。 【００４１】 次に、オペレータ選定部４３は、選択されたオペレータ端末のうち応答可能フラグが「可」であるものを選択する。図５では、１番のオペレータ端末の応答可能フラグが「可」であり、ｎ－１番のオペレータ端末の応答可能フラグが「不可」であるため、オペレータ選定部４３は１番のオペレータ端末を選択する。この１番のオペレータ端末が、ユーザ端末２と接続されるオペレータ端末（ユーザからの問い合わせを受けるオペレータ端末）に決定される。なお、１番のオペレータ端末以外にも上述の要件を満たしているオペレータ端末がある場合には、オペレータ選定部４３は要件を満たしている複数のオペレータ端末の中から１つを選択する。 【００４２】 オペレータ選定部４３は、以上のようにして選定されたオペレータ端末７の情報（選定結果）をインタラクション制御部４２に通知する（ステップＳ７）。 【００４３】 オペレータ選定部４３から選定結果を取得したインタラクション制御部４２は、その選定結果に基づき、選定されたオペレータ端末７にステップＳ４で取得したメッセージを送信する（ステップＳ８）。ここで、インタラクション制御部４２は、ステップＳ４で取得したメッセージにおける受信者情報（図５における必須ヘッダ部２０２内のＴｏヘッダの情報）を、インタラクション制御部４２のＩＰアドレスから、選定されたオペレータ端末７のＩＰアドレスに変更する。オペレータ端末７のＩＰアドレスは、例えばオペレータ選定部４３においてオペレータ端末７と関連付けて記憶されている。オペレータ選定部４３は、オペレータ端末７を選定した際に、そのオペレータ端末７に関連付けて記憶されているＩＰアドレスをインタラクション制御部４２に送信する。インタラクション制御部４２は、メッセージ中のＴｏヘッダの情報を、送信されたＩＰアドレスに書き換える。このような処理を行って、インタラクション制御部４２は選定されたオペレータ端末７にメッセージを送信する。 【００４４】 選定されたオペレータ端末７は、インタラクション制御部４２からメッセージを受信することで、ユーザ端末２との間で通信の接続がなされる（ステップＳ９）。具体的には、メッセージを受信したオペレータ端末７は、ユーザ端末２にＯＫレスポンス（ＩＰ電話の場合には呼び出しメッセージ）を送信する。ＯＫレスポンスを受信したユーザ端末２は、ＡＣＫメッセージをオペレータ端末７に送信する。このようにしてユーザ端末２とオペレータ端末７とが接続されるため、ユーザ端末２とオペレータ端末７との間でＩＰ電話やチャットを行うことができる。また、オペレータ端末７は、その画面上に、受信したメッセージに含まれる問い合わせ内容を表示させる（ステップＳ１０）。このため、オペレータは、ユーザからの問い合わせ内容を視認しながらユーザと対話を行うことができる。」 「【図１】 ［図：0001399843000001.jpg］ 」 「【図３】 ［図：0001399843000002.jpg］ 」 「【図５】 ［図：0001399843000003.jpg］ 」 「【図６】 ［図：0001399843000004.jpg］ 」 ２ 引用発明 前記１によれば、引用文献１には、次の発明（以下「引用発明」という。）が記載されていると認められる。なお、後の参照の便宜のため、引用発明をＡ～Ｏに分説した。 「Ａ コンタクトセンタ装置の通信接続方法であって（【００１３】）、 Ｂ コンタクトセンタ装置４は、メニュー情報提供部４１、インタラクション制御部４２、オペレータ選定部４３を備え（【００２４】）、 Ｃ ユーザがユーザ端末２を操作することで、問い合わせ内容が含まれるＳＩＰメッセージがインタラクション制御部４２に送信され、このメッセージは、ＳＩＰを用いたＩＰ電話の発呼やチャットの発信等において、ユーザ端末２からコンタクトセンタ装置４に初めて送信されるＩＮＶＩＴＥメッセージであり（【００３３】）、 Ｄ ＳＩＰメッセージのヘッダ部２０１は、必須ヘッダ部２０２と独自ヘッダ部２０３を有し、必須ヘッダ部２０２は、送信者欄「Ｆｒｏｍ」、受信者欄「Ｔｏ」等を有し、送信者であるユーザ端末２は「Ｕｓｅｒ＜ＳＩＰ：０９０１１１１２２２２＠１９２．１６８．０．１＞」のＩＰアドレスで示され、受信者であるインタラクション制御部４２は「＜ＳＩＰ：０８０３３３３４４４４＠１９２．１６８.０．２＞」のＩＰアドレスで示され（【００３４】）、 Ｅ 独自ヘッダ部２０３は、問い合わせ内容が含まれ（【００３５】）、 Ｆ ユーザ端末２からメッセージを受信したインタラクション制御部４２は、メッセージ中の問い合わせ内容（独自ヘッダ部２０３の内容）を検出し、その問い合わせ内容を含むオペレータ端末の選定要求をオペレータ選定部４３に出力し（【００３６】）、 Ｇ オペレータ選定部４３は、選定要求中の問い合わせ内容に基づいてオペレータ端末の選定を行い、オペレータ選定部４３には複数のオペレータ端末７のデータが格納されており、オペレータ選定部４３はそのデータと受信した問い合わせ内容とを比較することで、ユーザ端末２と接続される（ユーザの問い合わせを受け付ける）オペレータ端末７を選定し（【００３７】）、 Ｈ オペレータ選定部４３に格納されている複数のオペレータ端末７のデータは、対応できる問い合わせ内容（対応可能内容）が１番～ｎ番のオペレータ端末毎に設定され（【００３８】、図６）、 Ｉ 各オペレータ端末が現在応答可能か否かを示す「応答可能フラグ」も格納され（【００３９】）、 Ｊ オペレータ選定部４３は、ユーザ端末２から送信された問い合わせ内容を参照し、その問い合わせ内容が対応可能内容に全て含まれる端末を最初に選択し（【００４０】）、 Ｋ オペレータ選定部４３は、選択されたオペレータ端末のうち応答可能フラグが「可」であるものを選択し（【００４１】）、 Ｌ オペレータ選定部４３は、選定されたオペレータ端末７の情報（選定結果）をインタラクション制御部４２に通知し（【００４３】）、 Ｍ オペレータ選定部４３から選定結果を取得したインタラクション制御部４２は、その選定結果に基づき、選定されたオペレータ端末７に取得したメッセージを送信し（【００４３】）、 Ｎ 選定されたオペレータ端末７は、インタラクション制御部４２からメッセージを受信することで、ユーザ端末２との間で通信の接続がなされる（【００４４】） Ｏ コンタクトセンタ装置の通信接続方法」 第６ 対比 本願発明と引用発明とを対比する。 １ 「第２の通信デバイスとの第１の通信セッションを確立するリクエストを受信するステップであって、前記第１の通信セッションを確立する前記リクエストは前記第１の通信セッションをルーティングするための第１のルーティング属性を備えるものである、ステップと」について （１）ア 引用発明の「コンタクトセンタ装置４」（分説Ｂ）は、通信デバイスといえる。 イ 引用発明の「ＩＮＶＩＴＥメッセージ」は、「ＳＩＰを用いたＩＰ電話の発呼やチャットの発信等において、ユーザ端末２からコンタクトセンタ装置４に初めて送信される」もの（分説Ｃ）であるから、通信セッションをリクエストするものである。 また、引用発明の「ＩＮＶＩＴＥメッセージ」は、「送信者欄「Ｆｒｏｍ」」及び「受信者欄「Ｔｏ」」を有する（分説Ｄ）から、「ＩＮＶＩＴＥメッセージ」によってリクエストされる通信セッションは、送信者欄に示される「ユーザ端末２」と、受信者欄に示される「インタラクション制御部４２」との通信セッションであると認められる。 ウ 前記「インタラクション制御部４２」との通信セッションは、前記「インタラクション制御部４２」を備える「コンタクトセンタ装置４」（分説Ｂ）との通信セッションといえるから、該通信セッション及び「コンタクトセンタ装置４」は、それぞれ本願発明の「第１の通信セッション」及び「第２の通信デバイス」に相当し、引用発明の「ＩＮＶＩＴＥメッセージ」と本願発明の「リクエスト」は、「第２の通信デバイスとの第１の通信セッションを確立するリクエスト」である点で一致する。 （２）引用発明は、「インタラクション制御部４２」が前記（１）の「ＩＮＶＩＴＥメッセージ」を「受信」するものである（分説Ｃ、Ｆ）。 よって、前記（１）も考慮すると、本願発明と引用発明とは「第２の通信デバイスとの第１の通信セッションを確立するリクエストを受信するステップ」を備える点で一致する。 （３）ア 引用発明は、「オペレータ選定部４３」が「オペレータ端末７」を「選定」し（分説Ｇ）、「インタラクション制御部４２」が「選定」された前記「オペレータ端末７」に「ＩＮＶＩＴＥメッセージ」を送信する（分説Ｍ）から、「ＩＮＶＩＴＥメッセージ」を送信する「オペレータ端末７」の前記「選定」は、「ＩＮＶＩＴＥメッセージ」のルーティングである。 また、これにより、前記（１）の通信セッションの確立（接続）先が前記「オペレータ端末７」になる（分説Ｎ）から、引用発明の前記「オペレータ端末７」の「選定」は、本願発明の「通信セッションをルーティングする」ことに相当する。 イ 前記アの「オペレータ端末７」の「選定」には、前記「ＩＮＶＩＴＥメッセージ」に含まれる「問い合わせ内容」が用いられる（分説Ｅ、Ｆ、Ｇ）から、引用発明の前記「問い合わせ内容」は、本願発明の「通信セッションをルーティングするための第１のルーティング属性」に相当する。 ウ 前記ア及びイ並びに前記（１）によれば、引用発明の「ＩＮＶＩＴＥメッセージ」と本願発明の「リクエスト」は、「前記第１の通信セッションをルーティングするための第１のルーティング属性を備える」点で一致する。 （４）前記（１）～（３）によれば、本願発明と引用発明とは、「第２の通信デバイスとの第１の通信セッションを確立するリクエストを受信するステップであって、前記第１の通信セッションを確立する前記リクエストは前記第１の通信セッションをルーティングするための第１のルーティング属性を備えるものである、ステップ」を備える点で一致する。 ２ 「前記第１のルーティング属性に基づきデータベースから１以上の第１のルーティング規則をフェッチさせるステップと」について （１）引用発明の「複数のオペレータ端末７のデータ」は、「オペレータ端末毎」の「対応可能内容」のデータの集合である（分説Ｈ）からデータベースといえる。 （２）引用発明の前記「複数のオペレータ端末７のデータ」は、「問い合わせ内容（対応可能内容）」を「１番～ｎ番のオペレータ端末毎」に設定した（分説Ｈ）ものであり、前記１（３）の「オペレータ端末４３」の「選定」は、「ＩＮＶＩＴＥメッセージ」に含まれる「問い合わせ内容」（分説Ｃ）が、「対応可能内容」に全て含まれる「オペレータ端末７」を選択する（分説Ｊ）ことに基づく。 そうすると、前記「対応可能内容」は、それぞれの「オペレータ端末」を「選定」するための規則といえる（例えば、図６に示されるオペレータ端末「１」番の「対応可能内容」は、「問い合わせ内容」に、テレビ、パソコン、商品Ａ、商品Ｂ又は購入を含み、それら以外のものが含まれない場合に、オペレータ端末「１」番を「選定」する、という規則といえる。）。 したがって、引用発明の「オペレータ端末毎」の「対応可能内容」は、本願発明の「ルーティング規則」に相当する。 （３）前記（２）の「オペレータ端末７」の選択は、「オペレータ選定部４３」に、「複数のオペレータ端末７のデータ」（前記（２）の例では図６の全データ）から「問い合わせ内容」を全て含む「対応可能内容」（前記（２）の例では、図６のオペレータ端末１番のデータ）をフェッチさせることといえる。 してみると、前記フェッチさせる「対応可能内容」は、本願発明の「第１のルーティング規則」に相当し、前記（１）及び（２）並びに前記１（３）も踏まえると、本願発明と引用発明とは、「前記第１のルーティング属性に基づきデータベースから１以上の第１のルーティング規則をフェッチさせるステップ」を備える点で一致する。 ３ 「１以上の規則の集合を含む動的ルーティングフレームワークにおいて前記第１のルーティング属性があると判断した場合、前記第１のルーティング属性及び前記動的ルーティングフレームワークにおいて含まれる前記１以上の第１のルーティング規則に基づいて第３の通信デバイス又は送信先に前記第１の通信セッションをルーティングするステップと」について （１）本願発明の「動的ルーティングフレームワーク」について、明細書【００３３】に「動的ルーティングフレームワーク１２７は、通信セッションのルーティングを定義する規則のあらゆる集合であってもよいし、それを含み得る。動的ルーティングフレームワーク１２７は、管理端末１４０を介して管理者１４１によって動的に定義され得る。」と記載されている。前記記載によれば、本願発明の「動的ルーティングフレームワーク」の「動的」は「動的に定義され得る」ことを意味し、「ルーティングフレームワーク」は「通信セッションのルーティングを定義する規則のあらゆる集合を含み得る」ものを意味すると解される。 他方、前記２（２）のとおり、引用発明の「オペレータ端末毎」の「対応可能内容」は、各「オペレータ端末４」を「選定」することを定義した規則といえる。そして、引用発明の「複数のオペレータ端末７のデータ」（例えば、図６のデータ全体）は、前記「対応可能内容」の集合を含むものであるから、前記「通信セッションのルーティングを定義する規則のあらゆる集合を含み得る」との意味で「ルーティングフレームワーク」といえる。 してみると、引用発明の「複数のオペレータ端末７のデータ」は、本願発明の「１以上の規則の集合を含む動的ルーティングフレームワーク」と、「１以上の規則の集合を含むルーティングフレームワーク」である点で共通するといえる。 （２）引用発明の前記２（２）の「オペレータ端末７」の「選定」は、前記「問い合わせ内容」が「複数のオペレータ端末７のデータ」の「対応可能内容」に全てあると判断したことによるものといえる。 よって、本願発明と引用発明とは、「前記第１のルーティング属性があると判断した場合」の動作が存在する点で共通する。 （３）ア 引用発明の「オペレータ端末７」は、通信デバイスといえる。 イ 前記２（２）の「オペレータ端末７」の「選定」は、前記「問い合わせ内容」及び前記「対応可能内容」に基づいたものであり（分説Ｇ）、選定された「オペレータ端末７」に通信セッションがルーティングされる（前記１（３））から、引用発明の「オペレータ端末７」は、本願発明の「第１のルーティング規則に基づいて」ルーティングされる先である「第３の通信デバイス」に相当する。 ウ そうすると、本願発明と引用発明とは、「前記第１のルーティング属性及び前記ルーティングフレームワークにおいて含まれる前記１以上の第１のルーティング規則に基づいて第３の通信デバイス又は送信先に前記第１の通信セッションをルーティングする」点で共通する。 （４）前記（１）～（３）によれば、本願発明と引用発明とは、「１以上の規則の集合を含むルーティングフレームワークにおいて前記第１のルーティング属性があると判断した場合、前記第１のルーティング属性及び前記ルーティングフレームワークにおいて含まれる前記１以上の第１のルーティング規則に基づいて第３の通信デバイス又は送信先に前記第１の通信セッションをルーティングするステップ」を備える点で共通する。 ４ 「前記第３の通信デバイス又は送信先は前記１以上の第１のルーティング規則に基づき識別される」について 前記２（２）のとおり、引用発明の「選定」は「対応可能内容」に基づくから、「選定」された「オペレータ端末７」は、「対応可能内容」に基づいて識別されたものといえる。そうすると、本願発明と引用発明とは、「前記第３の通信デバイス又は送信先は前記１以上の第１のルーティング規則に基づき識別される」点で一致する。 ５ 「方法」について 引用発明の「コンタクトセンタ装置の通信接続方法」（分説Ｏ）は、後述する相違点を除き、本願発明の「方法」に相当する。 ６ 前記１～５によれば、本願発明と引用発明とは、次の一致点、相違点があるといえる。 ＜一致点＞ 「 第２の通信デバイスとの第１の通信セッションを確立するリクエストを受信するステップであって、前記第１の通信セッションを確立する前記リクエストは前記第１の通信セッションをルーティングするための第１のルーティング属性を備えるものである、ステップと、 前記第１のルーティング属性に基づきデータベースから１以上の第１のルーティング規則をフェッチさせるステップと、 １以上の規則の集合を含むルーティングフレームワークにおいて前記第１のルーティング属性があると判断した場合、前記第１のルーティング属性及び前記ルーティングフレームワークにおいて含まれる前記１以上の第１のルーティング規則に基づいて第３の通信デバイス又は送信先に前記第１の通信セッションをルーティングするステップと を備え、 前記第３の通信デバイス又は送信先は前記１以上の第１のルーティング規則に基づき識別される、方法。」 ＜相違点＞ 「ルーティングフレームワーク」について、本願発明は、「動的」に定義され得るものであるのに対し、引用発明は、「複数のオペレータ端末７のデータ」が動的に定義され得るものであるのか明らかでない点。 第７ 判断 以下、相違点について検討する。 ア 引用発明のコンタクトセンタ装置の運用中に新たな商品が発売されることは、当然に想定される事態であり、それに伴い、各オペレータが対応すべき問い合わせ内容が変わることは明らかである。 そうすると、前記事態に対応すべく、引用発明の各「オペレータ端末７」の「対応可能内容」を随時更新すること、換言すると、「複数のオペレータ端末７のデータ」を動的に定義することは、引用発明を実施するにあたり当然に行われるべきことであるから、このような変更は、当業者が容易になし得たものであるといえる。 イ そして、相違点を勘案しても、本願発明の奏する作用効果は、引用発明の奏する作用効果から予測される範囲内のものにすぎず、格別顕著なものということはできない。 ウ したがって、本願発明は、引用発明に基づいて、当業者が容易に発明をすることができたものである。 第８ 請求人の主張について 請求人は、令和３年１０月１日に提出した審判請求書において、「このように、引用文献１（中略）は「前記第３の通信デバイス又は送信先は前記第１のルーティング属性のルックアップに基づき識別される」という構成を開示および示唆していません。」として、本願の請求項８に係る発明が進歩性を有する旨を主張する。（審判請求書４～５頁） しかしながら、本願発明は、前記構成を備えるものではないから、請求人の前記主張は採用することができない。 第９ むすび 以上のとおり、本願発明は、引用文献１に記載された発明に基いて、その優先日前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法２９条２項の規定により特許を受けることができない。 したがって、他の請求項に係る発明について検討するまでもなく、本願は拒絶すべきものである。 よって、結論のとおり審決する。