ポートフォリオ機能
| ポートフォリオを新規に作成して保存 |
|
|
| 既存のポートフォリオに追加保存 |
|
PDFをダウンロード
|
| 審決分類 |
審判 査定不服 2項進歩性 取り消して特許、登録 G06F 審判 査定不服 特36条6項1、2号及び3号 請求の範囲の記載不備 取り消して特許、登録 G06F |
|---|---|
| 管理番号 | 1391426 |
| 総通号数 | 12 |
| 発行国 | JP |
| 公報種別 | 特許審決公報 |
| 発行日 | 2022-12-28 |
| 種別 | 拒絶査定不服の審決 |
| 審判請求日 | 2021-06-16 |
| 確定日 | 2022-11-15 |
| 事件の表示 | 特願２０１７−２０１６９４「サーバシステム、クライアント装置及びプログラム」拒絶査定不服審判事件〔平成３０年 １月２５日出願公開、特開２０１８− １４１３９、請求項の数（４）〕について、次のとおり審決する。 |
| 結論 | 原査定を取り消す。 本願の発明は、特許すべきものとする。 |
| 理由 |
第１ 手続の経緯 本願は、平成２８年３月２日の出願である特願２０１６−４０４８９号の一部を、平成２９年１０月１８日に新たな特許出願（特願２０１７−２０１６９４号）としたものであって、その後の手続の概要は、以下のとおりである。 令和２年 １月 ７日付け：拒絶理由通知書 令和２年 ３月１７日： 意見書の提出 令和２年 ８月２８日付け：拒絶理由通知書 令和２年１０月２３日： 意見書、手続補正書の提出 令和３年 ３月３１日付け：拒絶査定 令和３年 ６月１６日： 審判請求書の提出 令和４年 ２月２２日付け：拒絶理由通知書（以下、「当審拒絶理由（１ ）」という。） 令和４年 ４月２８日： 意見書、手続補正書の提出 令和４年 ８月１６日付け：拒絶理由通知書（以下、「当審拒絶理由（２ ）」という。） 令和４年 ９月 ９日： 意見書、手続補正書の提出 第２ 原査定の概要 原査定（令和３年３月３１日付け拒絶査定）の概要は次のとおりである。 理由１（進歩性） 本願請求項１に係る発明は、以下の引用文献Ａ−Ｃに基づいて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 引用文献等一覧 Ａ．特開２０１１−１５４４９３号公報 Ｂ．特開２０１６−０２７４８９号公報 Ｃ．hifive，h5.js，hifivetools [オンライン]，日本，２０１６年１月１４日[検索日 ２０２０年１月７日]，P.51-58，インターネット： <ＵＲＬ： http://github.com/hifive/hifivetools/blob/master/lib/H5SourceCodeConverter/js/h5.js>, 第2405-第2718行目 第３ 当審拒絶理由の概要 １ 当審拒絶理由（１）の概要 理由１（明確性） この出願は、特許請求の範囲の請求項１の記載が、特許法第36条第6項第2号に規定する要件を満たしていない。 理由２（サポート要件） この出願は、特許請求の範囲の請求項１の記載が、特許法第36条第6項第1号に規定する要件を満たしていない。 理由３（進歩性） 本願請求項１に係る発明は、引用文献１−５に基づいて、当業者が容易に発明をすることができたものであるから、特許法第29条第2項の規定により特許を受けることができない。 引用文献等一覧 １．特開２０１１−１５４４９３号公報（拒絶査定時の引用文献Ａ） ２．特開２０１６−０２７４８９号公報（拒絶査定時の引用文献Ｂ） ３．hifive，h5.js，hifivetools [オンライン]，日本，２０１６年１月１４日[検索日 ２０２２年２月２日]，ｐ，７０−７９，インターネット： <ＵＲＬ： http://github.com/hifive/hifivetools/blob/master/lib/H5SourceCodeConverter/js/h5.js>, 第2405-第2718行目（拒絶査定時の引用文献Ｃ） ４．処理中のユーザーの誤操作を防止しよう，hifive[オンライン]，日本，２０１７年１２月３１日[検索日 ２０２２年２月２日]，ｐ．１−９，ＵＲＬ，htttp://www.htmlhifive.com/conts/web/view/recipe/indicator（当審において新たに引用した文献） ５．インジケータに表示/非表示判定。hifiveの便利なUI機能を紹介します，hifive開発者ブログ [オンライン]，日本，２０１４年８月２７日[検索日 ２０２２年２月２日]，ｐ．１−５，インターネット： <ＵＲＬ： http://blog.htmlhifive.com/2014/08/27/hifive-ui-tips-indicator-isinview/>（当審において新たに引用した文献） ２ 当審拒絶理由（２）の概要 理由１（明確性） この出願は、特許請求の範囲の請求項４の記載が、特許法第36条第6項第2号に規定する要件を満たしていない。 第４ 本願発明 本願請求項１−４に係る発明（以下、それぞれ「本願発明１」−「本願発明４」という。）は、令和４年９月９日付けの手続補正で補正された特許請求の範囲の請求項１−４に記載された事項により特定される、以下のとおりの発明である。 「【請求項１】 クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に、当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをクライアント装置に送信する送信部を有し、 前記通知は、前記クライアント装置において前記コンテンツ画面をロードする際に操作不可能な状態で表示されていた前記コンテンツ画面を操作可能とする、サーバシステム。 【請求項２】 前記コンテンツ画面は、ユーザにより選択される、請求項１に記載のサーバシステム。 【請求項３】 前記送信部は、前記コンテンツ画面に対する操作を不可能な状態で当該コンテンツ画面を前記クライアント装置において表示させる制御情報を送信する、請求項１又は２に記載のサーバシステム。 【請求項４】 クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に、当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをサーバシステムがクライアント装置に送信する工程を有し、 前記通知は、前記クライアント装置において前記コンテンツ画面をロードする際に操作不可能な状態で表示されていた前記コンテンツ画面を操作可能とする、方法。」 第５ 引用文献、引用発明等 １ 引用文献１及び引用発明 （１） 引用文献１ 当審拒絶理由（１）の理由３において引用された引用文献１には、図面とともに、以下の記載がある（下線は、特に着目した箇所を示す。以下同様。）。 ア 段落【００１９】 「【００１９】 本発明は、以上の点に着目したもので、その目的は、現状の広告配信システムをそのまま活用しつつ、必要が生じた時点で任意に広告の差し替えを行うことである。他の目的は、広告の差し替えを簡便に行なって、効率的な広告・宣伝を行うことである。更に他の目的は、低いスペックや細い通信回線でも運用可能な広告差し替えのためのシステムを提供することである。更に他の目的は、複数の広告を差し替えるための管理作業や、機械的及び人的な作業リスクを軽減し、広告原稿の差替えのための再入稿に伴う負担を軽減することである。」 イ 段落【００２７】 「【００２７】 次に、媒体コンテンツ運用サーバ１２２は、クライアント１１０のディスプレイ１１２上に、ポータルサイトの広告媒体としてのｗｅｂページ１１４を表示するためのサーバである。ｗｅｂページ１１４には、例えば、ニュース，天気予報などのコンテンツが表示されており、更に広告を表示するための広告枠１１６が設けられている。一方、広告配信サーバ１２４及び広告配信代行サーバ１３２は、前記ｗｅｂページ１１４の広告枠１１６に広告画像を表示するためのサーバである。」 ウ 図２−図３ 「【図２】  【図３】  」 エ 段落【００３１】−【００３６】 「【００３１】 ＜実施例の動作＞・・・次に、図２及び図３も参照しながら、本実施例の動作を説明する。図２は動作の手順を示すシーケンス図であり、図３は主要動作を示す図である。まず、広告主１４０は、広告原稿ファイル２００を、広告配信サーバ１２４（もしくは広告配信代行サーバ１３２）に入稿する。本例では、広告原稿ファイル２００に、図３に示す広告画像２２１〜２２３の３つが含まれている。また、広告主１４０は、表示設定サーバ２１２に対して表示設定データ２０２を送信する。なお、これらの広告原稿ファイル２００の入稿や、表示設定データ２０２の送信も、インターネット１００を通じて行うようにしてよい。 【００３２】 クライアント１１０が、パソコン１１１によってポータルサイト運営会社１２０が運営するポータルサイトにインターネット１００を通じてアクセスすると（図２ステップＳＡ）、媒体コンテンツ運用サーバ１２２は、当該ポータルサイトのｗｅｂページ１１４のコンテンツデータをインターネット１００を通じてクライアント１１０に送信する（ステップＳＢ）。 【００３３】 一方、広告配信サーバ１２４は、ｗｅｂページ１１４の広告枠１１６に表示すべき広告原稿ファイル２００を、当該ポータルサイトのｗｅｂページを構成する要素として広告枠１１６に表示されるように、同時にクライアント１１０にインターネット１００を通じて送信する（ステップＳＣ）。クライアント１１０では、パソコン１１１によってウェブブラウザ内にコンテンツと広告原稿ファイル２００がインターネット１００を通じて読み込まれる。このとき、広告原稿ファイル２００に含まれている表示設定プログラム２０１が実行される（ステップＳＤ）。すると、クライアント１１０は、まず表示設定サーバ２１２にインターネット１００を通じてアクセスし、表示設定プログラム２０１から広告判別情報を表示設定サーバ２１２に送信する（ステップＳＥ）。通常広告配信サーバ１２４には、多数の広告主１４０からそれぞれ広告原稿ファイル２００が入稿されており、同時に、表示設定サーバ２１２にも多数の表示設定データ２０２が用意されている。これらの多数の表示設定データ２０２がいずれの広告原稿ファイル２００のものかを判別するためのデータが広告判別情報である。 【００３４】 表示設定サーバ２１２は、インターネット１００を通じて広告判別情報を受信し（ステップＳＦ）、該当する表示設定データ２０２を該当するクライアント１１０に送信する（ステップＳＧ）。クライアント１１０では、インターネット１００を通じて表示設定データ２０２を受信し（ステップＳＨ）、受信した表示設定データ２０２において指定されている表示態様に基づいて（ステップＳＩ）、ファイル内で指示通りに広告画像を組み立てる。この広告画像は、媒体コンテンツ運用サーバ１２２から送信されたコンテンツが表示されるｗｅｂページ１１４の広告枠１１６内に表示される（ステップＳＪ）。 【００３５】 図３の例では、広告原稿ファイル２００に、広告画像２２１〜２２３及び表示設定プログラム２０１が含まれており、これがクライアント１１０のパソコン１１２にインターネット１００を通じて広告配信サーバ１２４から送信される。一方、表示設定データ２０２においては、２番目の広告画像２２２が指定されている。このため、クライアント１１０では、表示設定プログラム２０１によって、表示設定データ２０２で指示された広告画像２２２のみがｗｅｂページ１１４の広告枠１１６内に表示されることとなる。なお、広告画像２２２が表示されるまでは、例えば「Now Loading...」といった表示が広告枠１１６内に表示される。 【００３６】 この場合において、ポータルサイトのｗｅｂページ１１４に広告画像２２２を表示したときのユーザの反応は、広告配信サーバ１２４において管理されており、広告主は広告画像２２２のクリック数を知ることができる。その結果、クリック数が予想よりも低いときは、表示設定データ２０２の設定を、広告画像２２２から他の広告画像，例えば広告画像２２１に変更する。すると、変更後の表示設定データ２０２に基づいて、広告原稿ファイル２００から広告画像２２１が選択され、次にクライアント１１０がポータルサイトにアクセスした際には、ポータルサイトのｗｅｂページ１１４に広告画像２２１が表示されるようになる。広告配信代行サーバ１３２による広告の代行配信の場合も同様である。」 （２） 引用発明 よって、引用文献１には、次の発明（以下、「引用発明」という。）が開示されているものと認められる。 「媒体コンテンツ運用サーバ１２２は、クライアント１１０のディスプレイ１１２上に、ポータルサイトの広告媒体としてのｗｅｂページ１１４を表示するためのサーバであり、 ｗｅｂページ１１４には、例えば、ニュース，天気予報などのコンテンツが表示されており、更に広告を表示するための広告枠１１６が設けられ、 広告配信サーバ１２４及び広告配信代行サーバ１３２は、前記ｗｅｂページ１１４の広告枠１１６に広告画像を表示するためのサーバであり、 クライアント１１０が、パソコン１１１によってポータルサイト運営会社１２０が運営するポータルサイトにインターネット１００を通じてアクセスすると（ステップＳＡ）、 媒体コンテンツ運用サーバ１２２は、当該ポータルサイトのｗｅｂページ１１４のコンテンツデータをインターネット１００を通じてクライアント１１０に送信し（ステップＳＢ）、 一方、広告配信サーバ１２４は、ｗｅｂページ１１４の広告枠１１６に表示すべき広告原稿ファイル２００を、当該ポータルサイトのｗｅｂページを構成する要素として広告枠１１６に表示されるように、同時にクライアント１１０にインターネット１００を通じて送信し（ステップＳＣ）、 クライアント１１０では、パソコン１１１によってウェブブラウザ内にコンテンツと広告原稿ファイル２００がインターネット１００を通じて読み込まれ、このとき、広告原稿ファイル２００に含まれている表示設定プログラム２０１が実行され（ステップＳＤ）、 クライアント１１０では、インターネット１００を通じて表示設定データ２０２を受信し（ステップＳＨ）、受信した表示設定データ２０２において指定されている表示態様に基づいて（ステップＳＩ）、ファイル内で指示通りに広告画像を組み立て、この広告画像は、媒体コンテンツ運用サーバ１２２から送信されたコンテンツが表示されるｗｅｂページ１１４の広告枠１１６内に表示され（ステップＳＪ）、 なお、広告画像２２２が表示されるまでは、例えば「Now Loading...」といった表示が広告枠１１６内に表示され、 ポータルサイトのｗｅｂページ１１４に広告画像２２２を表示したときのユーザの反応は、広告配信サーバ１２４において管理されており、広告主は広告画像２２２のクリック数を知ることができる、 媒体コンテンツ運用サーバ１２２、広告配信サーバ１２４及び広告配信代行サーバ１３２。」 ２ 引用文献２−５ （１） 引用文献２ 引用文献２の段落【００５７】−【００５８】には、以下の記載がある。 「【００５７】 〔５−１．複数の広告枠（１）〕 上記実施形態では、単一の広告枠を例に挙げて説明したが、上述してきた広告配信装置１００は、複数の広告枠に表示される広告コンテンツを配信することもできる。このとき、広告配信装置１００は、広告枠の優先度が決められている場合には、優先度の高い広告枠の順に、かかる広告枠に表示される配信候補の広告コンテンツとして、単位評価値が高い順に広告コンテンツを抽出してもよい。この点について図６を用いて説明する。図６は、変形例に係る広告抽出処理の一例を示す説明図である。なお、図６に示した広告配信装置１００は、図１の例と同様に、広告コンテンツＣ１１〜Ｃ１５を保持するものとする。 【００５８】 図６の例では、端末装置１０は、高さ「６」の広告枠Ｒ２１及びＲ２２を含むウェブページを表示している。ここで、広告枠Ｒ２１及びＲ２２は、広告コンテンツを表示させる優先度が決められている。図６の例では、広告枠を示す矩形内に示した数値が優先度を示し、数値が低いほど優先度が高いことを示すものとする。すなわち、広告枠Ｒ２１の優先度「１」であり、広告枠Ｒ２２の優先度「２」であり、広告枠Ｒ２２の優先度よりも広告枠Ｒ２１の優先度の方が高い。このような広告枠の優先度は、ウェブページを配信する情報提供装置３０によって決定される。例えば、情報提供装置３０は、ウェブページ毎に、ユーザにクリックされる回数が多い広告枠の順に高い優先度を設定する。」 （２） 引用文献３−５について 引用文献３の２６００−２６０３行には、コメント行として、以下の記載がある。 「2600 * 指定された要素に対して、インジケータ(メッセージ・画面ブロック・ 進捗)の表示や非表示を行うためのオブジェクトを取得します。 2601 * 使用例2602 * 画面全体をブロックする場合 2603 * ・画面全体をブロックする場合、targetオプションにdocument、windowまたはbodyを指定する。 」 上記２６００行には、「指定された要素に対して、インジケータ(メッセージ・画面ブロック・進捗)の表示や非表示を行うためのオブジェクトを取得します」と記載され、使用例が記載される２６０３行においては、インジケータの「ｔａｒｇｅｔオプション」指定において、「document」すなわちＨＴＭＬ文書全体を指定することで、「画面全体をブロックする」ことが記載されているといえる。 また、引用文献３の２４０５−２４１５行には、コメント行として、以下の「インジケータ」クラスの定義がある。 「2405 * インジケータ(メッセージ・画面ブロック・進捗表示)の表示や非表示を行うクラス。 2406 * 2407 * @class 2408 * @name Indicator 2409 * @param {String|Object} target インジケータを表示する対象のDOMオブジェクトまたはセレクタ 2410 * @param {Object} [option] オプション 2411 * @param {String} [option.message] メッセージ 2412 * @param {Number} [option.percent] 進捗を0〜100の値で指定する。 2413 * @param {Boolean} [option.block] 操作できないよう画面をブロックするか (true:する/false:しない) 2414 * @param {Promise|Promise[]} [option.promises] Promiseオブジェクト (Promiseの状態と合わせてインジケータの表示・非表示する) 2415 * @param {String} [options.cssClass] インジケータの基点となるクラス名 (CSSでテーマごとにスタイルをする場合に使用する)」 上記２４０９行には、「インジケータを表示する対象のDOMオブジェクトまたはセレクタ」を指定する「ｔａｒｇｅｔ」オプションが記載されている。 ここで、インジケータの表示範囲を指定する「target」オプションについて、さらに、 引用文献４、１ページ下から４行目「target: document,」、及び、同１ページ最下行の「このように書くとドキュメント全体にインジケータを表示します」の記載、及び、 引用文献５、３ページ下から５〜４行目「ｔａｒｇｅｔはインジケータを表示する範囲を指定するオプションです。指定しない場合はコントローラをバインドした要素に対してインジケータを表示します。（今回はｔａｒｇｅｔを指定しなくてＯＫです。）」の記載を参照すると、引用文献３の「ｔａｒｇｅｔ」オプションの指定により、インジケータを表示させる範囲として、画面全体のうちの所定の位置を指定できるものと認められる。 また、引用文献３の２４１３行には、 「2413 * @param {Boolean} [option.block] 操作できないよう画面をブロックするか (true:する/false:しない)」 との記載があり、「ｂｌｏｃｋ」オプションの指定により、「画面」全体の操作をブロックできることが読み取れる。 第６ 対比・判断 １ 本願発明１について （１） 対比 本願発明１と引用発明とを対比すると、次のことがいえる。 ア 引用発明の「クライアント１１０」は、本願発明１の「クライアント装置」に相当する。 引用発明の「ポータルサイトの広告媒体としてのｗｅｂページ１１４」は、本願発明１の「コンテンツ収容画面」に相当する。 引用発明の「ｗｅｂページ１１４には、例えば、ニュース，天気予報などのコンテンツが表示されており、更に広告を表示するための広告枠１１６が設けられ」ていることにおける「広告を表示するための広告枠１１６」は、本願発明１の「ユーザによる操作が可能な複数のコンテンツ画面」と、「ユーザによる操作が可能なコンテンツ画面」である点で共通するといえる よって、引用発明の「クライアント１１０が、パソコン１１１によってポータルサイト運営会社１２０が運営するポータルサイトにインターネット１００を通じてアクセスすると（ステップＳＡ）、 媒体コンテンツ運用サーバ１２２は、当該ポータルサイトのｗｅｂページ１１４のコンテンツデータをインターネット１００を通じてクライアント１１０に送信し（ステップＳＢ）、 一方、広告配信サーバ１２４は、ｗｅｂページ１１４の広告枠１１６に表示すべき広告原稿ファイル２００を、当該ポータルサイトのｗｅｂページを構成する要素として広告枠１１６に表示されるように、同時にクライアント１１０にインターネット１００を通じて送信し（ステップＳＣ）、 クライアント１１０では、パソコン１１１によってウェブブラウザ内にコンテンツと広告原稿ファイル２００がインターネット１００を通じて読み込まれ、このとき、広告原稿ファイル２００に含まれている表示設定プログラム２０１が実行され（ステップＳＤ）、 クライアント１１０では、インターネット１００を通じて表示設定データ２０２を受信し（ステップＳＨ）、受信した表示設定データ２０２において指定されている表示態様に基づいて（ステップＳＩ）、ファイル内で指示通りに広告画像を組み立て、この広告画像は、媒体コンテンツ運用サーバ１２２から送信されたコンテンツが表示されるｗｅｂページ１１４の広告枠１１６内に表示され（ステップＳＪ）」ることは、本願発明１の「クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に、当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをクライアント装置に送信する送信部を有」することと、「クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能なコンテンツ画面をロードする際に、当該コンテンツ画面をクライアント装置に送信する送信部を有」する点で共通するといえる。 ウ 引用発明の「媒体コンテンツ運用サーバ１２２、広告配信サーバ１２４及び広告配信代行サーバ１３２」は、本願発明１の「サーバシステム」に相当する。 よって、本願発明１と引用発明との一致点・相違点は次のとおりであるといえる。 ［一致点］ 「クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能なコンテンツ画面をロードする際に、当該コンテンツ画面をクライアント装置に送信する送信部を有する、 サーバシステム。」 ［相違点１］ 本願発明１では、「クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に」、「当該コンテンツ画面」「をクライアント装置に送信する」のに対して、引用発明では、「広告画像２２２が表示されるまでは、例えば「Now Loading...」といった表示が広告枠１１６内に表示され」るものであって、「広告を表示するための広告枠１１６」が、「複数」あることが特定されていない点。 ［相違点２］ 本願発明１では、さらに、「当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをクライアント装置に送信する送信部を有し、 前記通知は、前記クライアント装置において前記コンテンツ画面をロードする際に操作不可能な状態で表示されていた前記コンテンツ画面を操作可能とする」のに対して、引用発明では、コンテンツ画面とともに「送信完了通知」を送信するものではなく、「前記通知」により、「コンテンツ画面を操作可能とする」ことが特定されていない点。 （２） 当審の判断 事案に鑑みて、上記［相違点２］について先に検討すると、本願発明１の上記［相違点２］に係る、「当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをクライアント装置に送信する送信部を有し、 前記通知は、前記クライアント装置において前記コンテンツ画面をロードする際に操作不可能な状態で表示されていた前記コンテンツ画面を操作可能とする」構成については、上記引用文献１−５には記載されておらず、周知技術であるともいえない。 引用文献２には、ウェブページにおいて広告枠を複数設ける周知技術が記載され、引用文献３には、インジケータの「ｔａｒｇｅｔオプション」指定において、「document」すなわちＨＴＭＬ文書全体を指定することで、画面全体をブロックできること、さらに、引用文献４−５の記載も参照すると、画面全体のうちの所定の範囲を指定して、インジケータを「表示」できること、「ｂｌｏｃｋオプション」により、「画面」全体の操作をブロックできることは開示されているといえるが、「コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に」、「コンテンツ画面の送信完了通知」をクライアント装置に送信する送信部であって、「前記通知は、前記クライアント装置において前記コンテンツ画面をロードする際に操作不可能な状態で表示されていた前記コンテンツ画面を操作可能とする」構成は、開示されていない。 よって、当業者といえども、引用発明及び引用文献２−５に記載された技術的事項から、本願発明１の上記［相違点２」に係る構成を容易に想到することはできない。 したがって、他の相違点について判断するまでもなく、本願発明１は、当業者であっても引用発明及び引用文献２−５に記載された技術的事項に基づいて容易に発明できたものであるとはいえない。 ２ 本願発明２−４について 本願発明２−４も、本願発明１の上記［相違点２」に係る、「当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをクライアント装置に送信する送信部を有し、 前記通知は、前記クライアント装置において前記コンテンツ画面をロードする際に操作不可能な状態で表示されていた前記コンテンツ画面を操作可能とする」構成と、（実質的に）同一の構成を備えるものであるから、本願発明１と同様の理由により、当業者であっても、引用発明及び引用文献２−５に記載された技術的事項に基づいて容易に発明をすることができたものとはいえない。 第７ 当審拒絶理由（２）の理由１について 令和４年９月９日付けの補正による、補正後の請求項４は、「クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に、当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをサーバシステムがクライアント装置に送信する工程」と補正された結果、「クライアント装置に送信する工程」の主体が明確となり、当審拒絶理由（２）の理由１（明確性）は解消した。 第８ 当審拒絶理由（１）の理由１−２について １ 理由１（明確性）について 令和４年９月９日付けの補正による、補正後の請求項１には、「クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に」とあり、用語「コンテンツ」と「コンテンツ画面」の定義と、両者の対応関係が、明確に特定されており、当審拒絶理由（１）の理由１（明確性）は解消した。 ２ 理由２（サポート要件）について 令和４年９月９日付けの補正による、補正後の請求項１には、「クライアント装置において、コンテンツ収容画面に包含され、ユーザによる操作が可能な複数のコンテンツ画面をロードする際に、当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをクライアント装置に送信する送信部を有し」とあり、「コンテンツの送信」と、「コンテンツ画面をロードする」ことのタイミングの前後関係が明確に特定されており、当審拒絶理由（１）の理由２（サポート要件）は解消した。 第９ 原査定についての判断 令和４年９月９日付けの補正による、補正後の請求項１−４は、本願発明１の上記［相違点２」に係る、「当該コンテンツ画面と当該コンテンツ画面の送信完了通知とをクライアント装置に送信する送信部を有し、 前記通知は、前記クライアント装置において前記コンテンツ画面をロードする際に操作不可能な状態で表示されていた前記コンテンツ画面を操作可能とする」という技術的事項を有するものである。当該技術的事項は、原査定における引用文献Ａ−Ｃには記載されておらず、周知技術でもないので、本願発明１−４は、当業者であっても、原査定における引用文献Ａ−Ｃに基づいて容易に発明をすることができたものではない。したがって、原査定を維持することはできない。 第１０ むすび 以上のとおり、原査定の理由によって、本願を拒絶することはできない。 他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。 |
| 審決日 | 2022-11-01 |
| 出願番号 | P2017-201694 |
| 審決分類 |
P
1
8・
121-
WY
(G06F)
P 1 8・ 537- WY (G06F) |
| 最終処分 | 01 成立 |
| 特許庁審判長 |
▲吉▼田 耕一 |
| 特許庁審判官 |
稲葉 和生 石井 則之 |
| 発明の名称 | サーバシステム、クライアント装置及びプログラム |
| 代理人 | 伊東 忠彦 |
| 代理人 | 伊東 忠重 |
