2017-002133

特願２０１５－５２５７１０「データ配信方法及びデータ配信装置」拒絶査定不服審判事件〔平成２６年　２月１３日国際公開、ＷＯ２０１４／０２３１２７、平成２７年　９月１７日国内公表、特表２０１５－５２７６６３、請求項の数（１０）〕について、次のとおり審決する。

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

【理　由】 第１　手続の経緯 本願は、２０１３年（平成２５年）６月１３日（パリ条約による優先権主張２０１２年８月７日（ＣＮ）中華人民共和国）を国際出願日とする出願であって、平成２８年１月２８日付けで拒絶理由が通知され、同年５月２日に意見書が提出されたが、同年１０月７日付けで拒絶査定がされ、これに対し、平成２９年２月１４日に拒絶査定不服審判が請求されたものである。 第２　原査定の理由の概要 本願の請求項１－１０に係る発明は、その出願前に日本国内又は外国において、頒布された下記の刊行物に記載された発明又は電気通信回線を通じて公衆に利用可能となった発明に基いて、その出願前にその発明の属する技術の分野における通常の知識を有する者が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。 記 引用文献１　特開２００８－２５１０３１号公報 引用文献２　特表２０１２－５０８４７５号公報 第３　本願発明 本願の請求項１－１０に係る発明（以下、「本願発明１」－「本願発明１０」という。）は、特許請求の範囲の請求項１－１０に記載された事項により特定される発明であり、以下のとおりの発明である。 「【請求項１】 データ配信方法であって、 ユーザー端末からのＧＰＲＳ（General Packet Radio Service）トンネリングプロトコル-ユーザプレーンメッセージを解析して、リソース要求のためのＨＴＴＰ（Hyper Text Transport Protocol）要求メッセージを得て、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であるかを判断するステップと、 判断結果においてデータ要求方式がＨＴＴＰ圧縮方式であると判断した場合、前記ＨＴＴＰ要求メッセージを直接的にサーバに送信し、データ要求方式がＨＴＴＰ圧縮方式ではないと判断した場合、前記ＨＴＴＰ要求メッセージのデータ要求方式をＨＴＴＰ圧縮方式に設定してサーバに送信するステップと、 サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットを前記ＨＴＴＰ要求メッセージのデータ要求方式に適したデータフォーマットに設定して、ユーザー端末に送信するステップと を含むことを特徴とする方法。 【請求項２】 前記ＨＴＴＰ要求メッセージを解析して得られたデータ要求方式により、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であるかを判断する ことを特徴とする請求項１に記載の方法。 【請求項３】 前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式ではないと判断した場合、前記ＨＴＴＰ要求メッセージのメッセージヘッダーに圧縮属性を追加して、コアネットワークを介してサーバに送信する ことを特徴とする請求項２に記載のデータ配信方法。 【請求項４】 サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットがＨＴＴＰ非圧縮方式であるが、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式である場合、前記ＨＴＴＰ応答メッセージにおける応答データを抽出し、前記応答データを圧縮して新たなＨＴＴＰ応答メッセージに追加してユーザー端末に送信する ことを特徴とする請求項３に記載の方法。 【請求項５】 サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットがＨＴＴＰ圧縮方式であるが、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ非圧縮方式である場合、前記ＨＴＴＰ応答メッセージにおける応答データを抽出し、前記応答データを解凍して新たなＨＴＴＰ応答メッセージに追加してユーザー端末に送信する ことを特徴とする請求項３に記載の方法。 【請求項６】 サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットがＨＴＴＰ圧縮方式であり、且つ、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式である場合、前記ＨＴＴＰ応答メッセージを直接的にユーザー端末に送信する ことを特徴とする請求項３に記載の方法。 【請求項７】 サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットがＨＴＴＰ非圧縮方式であり、且つ、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ非圧縮方式である場合、前記ＨＴＴＰ応答メッセージを直接的にユーザー端末に送信する ことを特徴とする請求項３に記載の方法。 【請求項８】 データ配信装置であって、 ユーザー端末からのリソース要求のためのＨＴＴＰ（Hyper Text Transport Protocol）要求メッセージを受信するように構成されたアップリンクデータ解析モジュールと、 前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であるかを判断し、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であると判断した場合、前記ＨＴＴＰ要求メッセージを直接的にサーバに送信し、データ要求方式がＨＴＴＰ圧縮方式ではないと判断した場合、前記ＨＴＴＰ要求メッセージのデータ要求方式をＨＴＴＰ圧縮方式に変更して、コアネットワークを介してサーバに送信するように構成されたプロキシ要求モジュールと、 サーバによって応答された、前記ＨＴＴＰ要求メッセージに対するＨＴＴＰ応答メッセージを受信するように構成されたダウンリンクデータ解析モジュールと、 前記ＨＴＴＰ応答メッセージのデータフォーマットを前記ＨＴＴＰ要求メッセージのデータ要求方式に適したデータフォーマットに設定して、ユーザー端末に送信するように構成されたプロキシ応答モジュールと を含むことを特徴とする装置。 【請求項９】 前記プロキシ応答モジュールは、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であるが、前記ＨＴＴＰ応答メッセージのデータフォーマットがＨＴＴＰ非圧縮方式である場合、前記ＨＴＴＰ応答メッセージにおける応答データを抽出し、前記応答データを圧縮して新たなＨＴＴＰ応答メッセージに追加してユーザー端末に送信するように構成される ことを特徴とする請求項８に記載の装置。 【請求項１０】 前記プロキシ応答モジュールは、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ非圧縮方式であるが、前記ＨＴＴＰ応答メッセージのデータフォーマットがＨＴＴＰ圧縮方式である場合、ＨＴＴＰ応答メッセージにおける応答データを抽出し、前記応答データを解凍して新たなＨＴＴＰ応答メッセージに追加してユーザー端末に送信するように構成される ことを特徴とする請求項８に記載の装置。」 第４　引用文献、引用発明等 １．引用文献１について 原査定の拒絶の理由に引用された引用文献１には、図面とともに、以下の事項が記載されている。 「【０００４】 そこで、本発明は、移動局における制約を吸収することのできるウェブコンテンツ変換編集システムを提供することを目的としている。 【課題を解決するための手段】 【０００５】 上記目的を達成するために、本発明のウェブコンテンツ変換編集システムは、移動局とコンテンツ提供元との間で送受信されるメッセージの変換編集を行うウェブコンテンツ変換編集システムであって、前記移動局からのコンテンツを要求する要求メッセージを処理して前記コンテンツ提供元に送信する第１制御手段と、前記要求メッセージに対応して前記コンテンツ提供元から取得した応答メッセージを処理して前記移動局へ送信する第２制御手段とを備え、前記第１制御手段は、前記移動局から圧縮されたコンテンツを要求する要求メッセージを受け取った際に、前記コンテンツ提供元から非圧縮とされているコンテンツを取得する要求メッセージに編集して前記コンテンツ提供元に送信するようにしている。 【０００６】 また、上記本発明のウェブコンテンツ変換編集システムにおいて、前記第２制御手段は、前記編集した要求メッセージに応じて前記コンテンツ提供元から取得した非圧縮とされているコンテンツを、前記移動局から前記要求メッセージにより指定された圧縮タイプになるよう圧縮処理して前記移動局へ送信するようにしてもよい。 さらに、上記本発明のウェブコンテンツ変換編集システムにおいて、前記移動局からのコンテンツを取得する要求メッセージに、受け入れられる圧縮タイプ情報が指定されていた場合は、前記第２制御手段は、前記移動局が受け入れることができるコンテンツサイズが少なくとも設定されている定義ファイルに設定されているコンテンツサイズと、前記編集した要求メッセージに対応して前記コンテンツ提供元から取得した非圧縮のコンテンツのコンテンツサイズとを対比して、取得した当該コンテンツのコンテンツサイズが前記定義ファイルに設定されているコンテンツサイズ以上とされている場合に、前記取得した非圧縮のコンテンツを指定された圧縮タイプになるよう圧縮処理して前記移動局へ送るようにしてもよい。 【発明の効果】 【０００７】 このような本発明によれば、移動局から圧縮されたコンテンツを要求された際には、コンテンツ提供元からは非圧縮のコンテンツを取得し、指定された圧縮タイプに圧縮して送るようにしている。これにより、コンテンツ提供元から取得したコンテンツを解凍した後に、さらに圧縮する処理を行う必要をなくすことができ、処理効率が低下することを防止することができる。また、移動局の仕様上の制約等を極力吸収することができ、移動局におけるウェブ通信におけるユーザビリティを向上することができるようになる。」 「【０００８】 本発明の実施の形態のウェブコンテンツ変換編集システムを備えるネットワークの概略構成を図１に示す。 図１に示すネットワークは、移動通信網とインターネット等の他のネットワークとを有しており、移動通信網は、例えば携帯電話機とされる移動局（ＭＳ）１０と無線通信路１１として示されている。また、他のネットワークはそのネットワーク上に位置しているアプリケーションサーバ１３ａ、１３ｂ、１３ｃとして示されている。本発明にかかるウェブコンテンツ変換編集システム１２は、移動通信網と他のネットワークとの間に配置されており、移動局１０とコンテンツ提供元であるアプリケーションサーバ１３ａ～１３ｃとの間で送受信されるメッセージの変換編集を行っている。 【０００９】 移動局１０は、アプリケーションサーバ１３ａ～１３ｃのいずれかからコンテンツを取得する際にＨＴＴＰ（HyperText Transport Protocol）リクエスト（Request）をアプリケーションサーバ１３ａ～１３ｃに向けて送信する。このＨＴＴＰリクエストを受けたアプリケーションサーバ１３ａ～１３ｃは、要求されたコンテンツをエンティテイボディとするＨＴＴＰレスポンス（Response）を移動局１０へ向けて送り出す。この場合において、移動局１０とアプリケーションサーバ１３ａ～１３ｃとの間に配置されている本発明にかかるウェブコンテンツ変換編集システム１２は、次に説明するウェブコンテンツ変換編集に関する後述する各種処理を実行する。」 「【００２３】 次に、ウェブコンテンツ変換編集システム１２が実行するウェブコンテンツ変換編集処理の一つにＨＴＴＰエンティティボディの圧縮処理がある。 ＨＴＴＰエンティティボディの圧縮処理は、移動局１０側とコンテンツを提供するアプリケーションサーバ１３ａ～１３ｃ側の間で転送されるデータ量を減らし、無線通信路１１のリソースを有効に利用するために行われる。ウェブコンテンツ変換編集システム１２は、アプリケーションサーバ１３ａ～１３ｃ側から受信したＨＴＴＰレスポンスにおいて、移動局１０からの要求に応じエンティティボディ（コンテンツ）を圧縮して移動局１０側に送信する。なお、アプリケーションサーバ１３ａ～１３ｃから圧縮したエンティティボディを送ると、その圧縮タイプを移動局１０において受け入れられない場合があることから、ウェブコンテンツ変換編集システム１２において圧縮されているエンティティボディを解凍してから圧縮することになり、処理効率が低下する。これを防止するために、ウェブコンテンツ変換編集システム１２はアプリケーションサーバ１３ａ～１３ｃ側から非圧縮のエンティティボディを、ＨＴＴＰレスポンスとして受け取るようにする。そして、ウェブコンテンツ変換編集システム１２において、コンテンツの変換及び編集処理を行った後、圧縮処理を行うようにする。 【００２４】 ところで、移動局１０はＨＴＴＰリクエストにおけるアクセプト・エンコーディング（Accept-Encoding）ヘッダにより、受け入れられる圧縮タイプを指定するようにしている。このアクセプト・エンコーディングヘッダにおいて、指定している圧縮タイプの値がＮＵＬＬ値（または、「identify」）とされている場合は、移動局１０においてコンテンツ圧縮が許容されていない場合である。また、圧縮タイプのいずれかが指定されている場合、および、アクセプト・エンコーディングヘッダが指定されていない場合は、移動局１０においてコンテンツ圧縮が許容されている場合であり、この場合に限ってウェブコンテンツ変換編集システム１２において、移動局１０において受け入れられる圧縮タイプのエンティティボディの圧縮を行うようにしている。 【００２５】 この場合、コンテンツ提供側においてはコンテンツを圧縮して送信させないことを通知するため、ウェブコンテンツ変換編集システム１２は、移動局１０からのＨＴＴＰリクエストにＮＵＬＬ値（または、「identify」）を設定したアクセプト・エンコーディングヘッダを追加し、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信する。これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。なお、移動局１０からのＨＴＴＰリクエストにおけるアクセプト・エンコーディングヘッダにおいて、指定している圧縮タイプの値がＮＵＬＬ値（または、「identify」）とされている場合は、前述したようにコンテンツ圧縮が非許容とされているため、ウェブコンテンツ変換編集システム１２は、コンテンツ圧縮を行わない。また、ウェブコンテンツ変換編集システム１２が行う圧縮タイプとしては、一般にDEFLATE形式またはGZIP形式が用いられる。 【００２６】 ここで、ウェブコンテンツ変換編集システム１２が実行するＨＴＴＰエンティティボディ圧縮処理１のフローチャートを図６に示す。このＨＴＴＰエンティティボディ圧縮処理１では、移動局１０からのＨＴＴＰリクエストのヘッダの編集が行われる。 ＨＴＴＰエンティティボディ圧縮処理１がスタートすると、ステップＳ４０にて移動局１０からのＨＴＴＰリクエストのリクエストヘッダにおける圧縮タイプを指定するAccept-Encodingが取得される。次いで、取得したAccept-Encodingにおいて圧縮タイプが指定されているか否かが判断される。ここで、Accept-Encodingにおいて圧縮タイプが指定されていないと判断された場合は、移動局１０においてコンテンツ圧縮が許容されている場合であり、ステップＳ４４に分岐する。ステップＳ４４では、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）を設定して、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信する。これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。 【００２７】 また、ステップＳ４１にてAccept-Encodingにより圧縮タイプが指定されていると判断された場合は、ステップＳ４２に進みリクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）が設定されているか否かが判断される。ここで、Accept-EncodingにＮＵＬＬ値（または、「identify」）が設定されていると判断された場合は、移動局１０においてコンテンツ圧縮が許容されていない場合であり、ステップＳ４５に分岐する。ステップＳ４５ではリクエストヘッダのAccept-Encodingを編集することなく、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信する。これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。 【００２８】 また、ステップＳ４２にてAccept-EncodingにＮＵＬＬ値（または、「identify」）ではない圧縮タイプが設定されていると判断された場合は、移動局１０において設定された圧縮タイプのコンテンツ圧縮が許容されている場合であり、ステップＳ４３に進む。ステップＳ４３では、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）を設定して、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信する。これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮となる。このようにして、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃからのＨＴＴＰレスポンスは非圧縮とされてウェブコンテンツ変換編集システム１２が受信するようになる。そして、ウェブコンテンツ変換編集システム１２は、移動局１０からのＨＴＴＰリクエストにおけるリクエストヘッダのAccept-Encodingの指定に応じた圧縮タイプでエンティティボディを圧縮したＨＴＴＰレスポンスを移動局に送信する。」 以上の記載（特に、下線部）から、引用文献１には、「ウェブコンテンツ変換編集システム」が記載され、該システムの処理を方法として捉えると、引用文献１には、以下の発明（以下、「引用発明」という。）が記載されていると認められる。 ［引用発明］ 「移動局とコンテンツ提供元との間で送受信されるメッセージの変換編集を行うウェブコンテンツ変換編集システムの処理方法であって、 移動局１０からのＨＴＴＰリクエストのリクエストヘッダにおける圧縮タイプを指定するAccept-Encodingが取得され、取得したAccept-Encodingにおいて圧縮タイプが指定されているか否かが判断され、 Accept-Encodingにおいて圧縮タイプが指定されていないと判断された場合は、移動局１０においてコンテンツ圧縮が許容されている場合であり、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）を設定して、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信し、これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮となり、 また、Accept-Encodingにより圧縮タイプが指定されていると判断された場合は、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）が設定されているか否かが判断され、 ここで、Accept-EncodingにＮＵＬＬ値（または、「identify」）が設定されていると判断された場合は、移動局１０においてコンテンツ圧縮が許容されていない場合であり、リクエストヘッダのAccept-Encodingを編集することなく、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信し、これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮となり、 また、Accept-EncodingにＮＵＬＬ値（または、「identify」）ではない圧縮タイプが設定されていると判断された場合は、移動局１０において設定された圧縮タイプのコンテンツ圧縮が許容されている場合であり、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）を設定して、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信し、これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮となり、 このようにして、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃからのＨＴＴＰレスポンスは非圧縮とされてウェブコンテンツ変換編集システム１２が受信するようになり、そして、ウェブコンテンツ変換編集システム１２は、移動局１０からのＨＴＴＰリクエストにおけるリクエストヘッダのAccept-Encodingの指定に応じた圧縮タイプでエンティティボディ（コンテンツ）を圧縮したＨＴＴＰレスポンスを移動局に送信する、ウェブコンテンツ変換編集システムの処理方法」 ２．引用文献２について 原査定の拒絶の理由で引用された引用文献２には、以下の事項が記載されている。 「【００４７】 ＲＡＮＣは、ＲＡＮＡＰメッセージを監視することで、一位の国際移動体装置識別番号（ＩＭＥＩ）または移動機器番号（ＭＥＩ）、及び装置（ｉフォン（商標名）、ブラックベリー（商標名）、ラップトップコンピュータ－、等）のタイプをも識別し得る。加えて、あるいは、ＲＡＮＣはＲＮＣから受けたユーザープレーンＧＴＰ－Ｕパケット内のＨＴＴＰ要求から、ユーザーエージェントの、ウェブブラウザタイプ（インターネットエクスプローラ、サファリ、ファイヤーフォックス等）等を識別可能である。」 第５　対比・判断 １．本願発明１について （１）対比 本願発明１と引用発明とを対比すると、次のことがいえる。 引用発明は、「エンティティボディ（コンテンツ）を圧縮したＨＴＴＰレスポンスを移動局に送信する」ものであるから、「データ配信方法」といえるものであり、この点で本願発明１と一致する。 引用発明の「移動局１０」及び「アプリケーションサーバ１３ａ～１３ｃ」は、本願発明１の「ユーザ端末」及び「サーバ」に相当し、引用発明の「移動局１０からのＨＴＴＰリクエストのリクエストヘッダにおける圧縮タイプを指定するAccept-Encodingが取得され、取得したAccept-Encodingにおいて圧縮タイプが指定されているか否かが判断され」ることは、本願発明１の「ユーザー端末からのＧＰＲＳ（General Packet Radio Service）トンネリングプロトコル-ユーザプレーンメッセージを解析して、リソース要求のためのＨＴＴＰ（Hyper Text Transport Protocol）要求メッセージを得て、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であるかを判断するステップ」と、「ユーザー端末からのメッセージを解析して、リソース要求のためのＨＴＴＰ（Hyper Text Transport Protocol）要求メッセージを得て、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であるかを判断するステップ」である点で共通する。 引用発明における、「コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃからのＨＴＴＰレスポンスは非圧縮とされてウェブコンテンツ変換編集システム１２が受信するようになり、そして、ウェブコンテンツ変換編集システム１２は、移動局１０からのＨＴＴＰリクエストにおけるリクエストヘッダのAccept-Encodingの指定に応じた圧縮タイプでエンティティボディ（コンテンテツ）を圧縮したＨＴＴＰレスポンスを移動局に送信する」ことは、本願発明１の「サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットを前記ＨＴＴＰ要求メッセージのデータ要求方式に適したデータフォーマットに設定して、ユーザー端末に送信するステップ」に相当し、両者は、「サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットを前記ＨＴＴＰ要求メッセージのデータ要求方式に適したデータフォーマットに設定して、ユーザー端末に送信するステップ」を含む点で一致する。 したがって、両者の間には、次の一致点と相違点があるといえる。 ［一致点］ 「データ配信方法であって、 ユーザー端末からのメッセージを解析して、リソース要求のためのＨＴＴＰ（Hyper Text Transport Protocol）要求メッセージを得て、前記ＨＴＴＰ要求メッセージのデータ要求方式がＨＴＴＰ圧縮方式であるかを判断するステップと、 サーバによって応答されたＨＴＴＰ応答メッセージのデータフォーマットを前記ＨＴＴＰ要求メッセージのデータ要求方式に適したデータフォーマットに設定して、ユーザー端末に送信するステップと を含むことを特徴とする方法。」 ［相違点１］ ユーザー端末からのメッセージが、本願発明１では、「ＧＰＲＳ（General Packet Radio Service）トンネリングプロトコル-ユーザプレーンメッセージ」であるのに対し、引用発明では、「ＧＰＲＳ（General Packet Radio Service）トンネリングプロトコル-ユーザプレーンメッセージ」であるか否か明らかではない点。 ［相違点２］ 本願発明１では、「判断結果においてデータ要求方式がＨＴＴＰ圧縮方式であると判断した場合、前記ＨＴＴＰ要求メッセージを直接的にサーバに送信し、データ要求方式がＨＴＴＰ圧縮方式ではないと判断した場合、前記ＨＴＴＰ要求メッセージのデータ要求方式をＨＴＴＰ圧縮方式に設定してサーバに送信するステップ」を含むのに対し、引用発明では、そのようなステップを含まない点。 （２）相違点についての判断 事案に鑑みて、上記相違点２について先に検討する。 引用発明は、「Accept-EncodingにＮＵＬＬ値（または、「identify」）ではない圧縮タイプが設定されていると判断された場合」（本願発明１の「判断結果においてデータ要求方式がＨＴＴＰ圧縮方式であると判断した場合」に相当）は、「移動局１０において設定された圧縮タイプのコンテンツ圧縮が許容されている場合であり、リクエストヘッダにおけるAccept-EncodingにＮＵＬＬ値（または、「identify」）を設定して、コンテンツ提供側であるアプリケーションサーバ１３ａ～１３ｃに送信し、これにより、アプリケーションサーバ１３ａ～１３ｃ側からのＨＴＴＰレスポンスは非圧縮とな」るものである。 換言すれば、引用発明は、移動局１０からのデータ要求方式が圧縮方式である場合に、アプリケーションサーバ１３ａ～１３ｃには非圧縮のデータ要求を行うものである。 引用発明は、そのような構成を採用することにより、「アプリケーションサーバ１３ａ～１３ｃから圧縮したエンティティボディを送ると、その圧縮タイプを移動局１０において受け入れられない場合があることから、ウェブコンテンツ変換編集システム１２において圧縮されているエンティティボディを解凍してから圧縮することになり、処理効率が低下する」（【００２３】の下線部を参照）という課題を解決するものである。 引用発明において、本願発明１のような「判断結果においてデータ要求方式がＨＴＴＰ圧縮方式であると判断した場合、前記ＨＴＴＰ要求メッセージを直接的にサーバに送信」するようにすると、サーバに圧縮したデータの要求を行うこととなり、上記課題が解決できなくなるから、そのようにすることを当業者が容易に想到し得るとはいえない。 したがって、本願発明１は、相違点１について検討するまでもなく、当業者が引用発明に基づいて容易に発明をすることができたものとはいえない。 ２．本願発明２－７について 本願発明２－７は、本願発明１をさらに限定したものであるので、本願発明１と同じ理由により、当業者であっても引用発明に基づいて容易に発明をすることができたものとはいえない。 ３．本願発明８について 本願発明８は、「データ配信方法」に係る本願発明１のカテゴリを代えて装置に係る発明として捉えたものであるから、本願発明１と同様の理由により、当業者であっても引用発明に基づいて容易に発明をすることができたものとはいえない。 ４．本願発明９、１０について 本願発明９、１０は、本願発明８をさらに限定したものであるので、本願発明８と同じ理由により、当業者であっても引用発明に基づいて容易に発明をすることができたものとはいえない。 第６　むすび 以上のとおり、原査定の理由によっては、本願を拒絶することはできない。 また、他に本願を拒絶すべき理由を発見しない。 よって、結論のとおり審決する。