2021-005536
アップリンクデータ解凍、圧縮方法および装置
- 審判番号
- 2021-005536
- 法域
- 特許
- 審判種別
- 拒絶査定不服審判（拒絶査定不服の審決）
- 出願番号
- 特願2019-558705外部サイト（J-PlatPat）へ移動します
- 請求日
- 2021年04月28日
- 審決日
- 2022年01月05日
- 公報発行日
- 2022年02月25日
- 結論
- 原査定取消（特許/登録すべき）
- 当事者
- 【請求人】大唐移▲動▼通信▲設▼▲備▼有限公司
- 【請求人代理人】特許業務法人 信栄特許事務所
- 分類
- P18 .121-WY (H04L)
- 条文（本文から自動抽出・参考）
- 特許法第29条第2項
- データ出所
- 審決公報（XML）
事件の表示
結論
理由
目次 ▾ 19項目
第１ 手続の経緯
折りたたみ中（クリックで表示）
本願は、２０１８年（平成３０年）３月８日（パリ条約による優先権主張 外国庁受理 ２０１７年４月２８日 中国）を国際出願日とする出願であって、令和元年１０月２８日に手続補正書が提出され、令和２年７月３１日付けで拒絶理由通知がされ、令和２年１１月１３日に意見書とともに手続補正書が提出され、令和２年１２月２２日付けで拒絶査定（原査定）がされ、これに対し、令和３年４月２８日に拒絶査定不服審判の請求がされたものである。
第２ 原査定の概要
原査定（令和２年１２月２２日付け拒絶査定）の概要は次のとおりである。
本願請求項１ないし４、６ないし１２、１４及び１５に係る発明は、以下の引用文献１又は引用文献２に記載された発明に基いて、その発明の属する技術の分野における通常の知識を有する者（以下、「当業者」という。）が容易に発明をすることができたものであるから、特許法第２９条第２項の規定により特許を受けることができない。
引用文献１： Qualcomm Inc.、A Low-Complexity Uplink Data Compression Solution [online]、3GPP TSG-RAN WG2 #97bis R2-1703583、Internet: <URL: http://www.3gpp.org/ftp/tsg_ran/WG2_RL2/TSGR2_97bis/Docs/R2-1703583.zip>、２０１７年 ３月２５日、[検索日 ２０１７年１２月１３日]
第３ 本願発明
本願請求項１ないし１５に係る発明（以下、それぞれ「本願発明１」ないし「本願発明１５」という。）は、令和２年１１月１３日に提出された手続補正書に係る手続補正で補正された特許請求の範囲の請求項１ないし１５に記載された事項により特定される発明であり、このうち本願発明１、７、１２及び１４は以下のとおりの発明である。
［本願発明１］
「 解凍エンドが、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケットを受信すると、前記ＰＤＣＰパケットのうち、少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダを検査することと、前記解凍エンドが、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行うこととを含み、前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む、アップリンクデータ解凍方法。」
［本願発明７］
「 圧縮エンドが、ＰＤＣＰパケットを解凍エンドに送信することを含み、前記解凍エンドが、前記ＰＤＣＰパケットのうち、少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣヘッダを検査し、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行い、前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む、アップリンクデータ圧縮方法。」
［本願発明１２］
「 解凍エンドであって、ＰＤＣＰパケットを受信すると、前記ＰＤＣＰパケットのうち、少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣヘッダを検査する検査モジュールと、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行う第１処理モジュールとを含み、前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む、解凍エンド。」
［本願発明１４］
「 ＰＤＣＰパケットを解凍エンドに送信する送信モジュールを含む圧縮エンドであって、前記解凍エンドが、前記ＰＤＣＰパケットのうち、少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣヘッダを検査し、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行い、前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む、圧縮エンド。」
なお、本願発明２ないし６は、本願発明１を減縮した発明であり、本願発明８ないし１１は、本願発明７を減縮した発明であり、本願発明１３は、本願発明１２を減縮した発明であり、また、本願発明１５は、本願発明１４を減縮した発明である。
第４ 引用文献、引用発明等
１ 引用文献１について
（１）引用文献１記載事項
折りたたみ中（クリックで表示）
原査定の拒絶の理由に引用された上記引用文献１には、図面とともに次の事項が記載されている。（下線は、強調のため当審が付与した。以降においても同様。）
ア 「2 Main idea of the UDC SolutionBoth UE and eNB maintains UL Compression Memory to remember uncompressed contents of previous packets. When a new packet arrives, the UE tries to match (partially or fully) with the stored packets. If a match is found, then the UE sends pointers (addresses/locations of matched data block in both the compression memory and the packet) instead of the actual data bytes, to the eNB. The decompression algorithm is similar to the famous C language library function “memcpy(src addr, dest addr, length)” which simply copies the pointed data from the compression memory to the current packet, to recover the original packet. So the compressed data format mainly contains the following parameters.…（以下省略）」
［当審訳］
「２ ＵＤＣソリューションの主旨ＵＥとｅＮＢの双方は、以前のパケットの非圧縮コンテンツを記憶するために、ＵＬ圧縮メモリを保持している。新しいパケットが到着すると、ＵＥは保存されているパケットと（部分的または完全に）一致するかどうかを試す。一致した場合、ＵＥは、実際のデータバイトではなく、ポインター（圧縮メモリとパケットの両方で一致したデータブロックのアドレス／位置）をｅＮＢに送信する。解凍アルゴリズムは、有名なＣ言語ライブラリ関数である”memcpy(src addr, dest addr, length)”に似ている。この関数は、圧縮メモリから現在のパケットにポインティングされたデータを単純にコピーすることで、元のパケットを復元する。そのため、圧縮データのフォーマットには、主に以下のようなパラメータが含まれる。…（以下省略）」
イ 「3.1 Compressed Data Format［図：0001381559000001.jpg］Figure 1: UL Compression Packet Format」
［当審訳］
「３．１ 圧縮データフォーマット…（図面中の文字の訳は省略）…図１：ＵＬ圧縮パケットフォーマット」
ウ 「UDC common header (first octet)■ Packet action (upper 3 bits)□ 011 - Decompression shall be performed as indicated by the UDC header that follows the first octet. The entire packet (decompressed) shall be pushed to UL compression memory. The UDC header shall be pushed to UDC header memory if the UDC header length is less than or equal to udcHeaderMemorySize.□ 010 - Decompression shall be performed as indicated by the UDC header that follows the first octet. The packet header (of the decompressed packet), as indicated by udcHeaderLength, shall be pushed to UL compression memory. The UDC header shall be pushed to UDC header memory if the UDC header length is less than or equal to udcHeaderMemorySize.□ 001 - For this packet action, there is no following header and no decompression needs to be performed. The entire packet shall be pushed to UL compression memory. The UDC header shall not be pushed to UDC header memory.□ 000 - For this packet action, there is no following header and no decompression needs to be performed. The packet shall not be pushed to UL compression memory. The UDC header shall not be pushed to UDC header memory.□ 100 - This is an exact match of the UDC header with the contents of UDC header memory. Decompression shall be performed, as indicated by the previous UDC header, as contained in UDC header memory. The entire packet or packet header only shall be pushed to UL compression memory, depending on the packet action in the previous packet (011 or 010 respectively). The UDC header shall not be pushed to UDC header memory.□ 101 - Reset UL compression memory to all zeros. For this packet action, there are no following header and no decompression needs to be performed. The entire packet shall be pushed to UL compression memory. The UDC header shall not be pushed to UDC header memory.■ Checksum (next 4 bits) - The checksum is used by the decompressor to detect UL compression memory out-of-sync conditions between the compressor and decompressor.」
［当審訳］
「ＵＤＣ共通ヘッダ（第１オクテット）■ パケットアクション（最初の３ビット）□ ０１１：解凍は、第１オクテットに続くＵＤＣヘッダが示すとおりに行う。伸長されたパケット全体は、ＵＬ圧縮メモリにプッシュされる。ＵＤＣヘッダの長さがudcHeaderMemorySize以下の場合、ＵＤＣヘッダをＵＤＣヘッダメモリにプッシュする。□ ０１０：解凍は、第１オクテットに続くＵＤＣヘッダが示すとおりに行う。udcHeaderLengthで示される（伸長されたパケットの）パケットヘッダは、ＵＬ圧縮メモリにプッシュする。ＵＤＣヘッダの長さがudcHeaderMemorySize以下の場合は、ＵＤＣヘッダをＵＤＣヘッダメモリにプッシュしなければならない。□ ００１：このパケットアクションでは、次のヘッダはなく、解凍を行う必要はない。パケット全体がＵＬ圧縮メモリにプッシュされる。ＵＤＣヘッダはＵＤＣヘッダメモリにプッシュしてはならない。□ ０００：このパケットアクションでは、次のヘッダはなく、解凍を行う必要はない。このパケットは、ＵＬ圧縮メモリにプッシュしてはならない。ＵＤＣヘッダをＵＤＣヘッダメモリにプッシュしてはならない。□ １００：これは、ＵＤＣヘッダとＵＤＣヘッダメモリの内容が完全に一致していることを意味する。ＵＤＣヘッダメモリに含まれる、前のＵＤＣヘッダが示すとおりに、解凍を行う。前パケットのパケットアクション（それぞれ０１１または０１０）に応じて、パケット全体またはパケットヘッダのみをＵＬ圧縮メモリにプッシュすること。ＵＤＣヘッダは、ＵＤＣヘッダメモリにプッシュしてはならない。□ １０１：ＵＬ圧縮メモリをすべて０にリセットする。このパケットアクションでは、次のヘッダがなく、解凍を行う必要がない。パケット全体をＵＬ圧縮メモリにプッシュすること。ＵＤＣヘッダは、ＵＤＣヘッダメモリにプッシュしないこと。■ チェックサム（次の４ビット）：チェックサムは、解凍器が、圧縮器と解凍器間のＵＬ圧縮メモリの同期不能状態を検出するために使用される。」
エ 「3.2 Decompressor AlgorithmThe decompressor must look into the UL compressed packet to determine if the packet is compressed. If the packet is not compressed, it must remove the header byte. If the packet is compressed, it must perform decompression on the packet as shown in the below figure:［図：0001381559000002.jpg］Figure 4: Decompressor Flow Chart」
［当審訳］
「３．２ 解凍アルゴリズム解凍器は、ＵＬ圧縮パケットを調べて、そのパケットが圧縮されているかどうかを判断しなければならない。パケットが圧縮されていない場合は、ヘッダバイトを削除しなければならない。パケットが圧縮されている場合には、以下の図に示されるようにパケットの解凍を行わなければならない。…（フローチャートの訳は省略）…図４：解凍器フローチャート」
オ 「4 Performance Evaluation4.1 Simulation Assumption…（中略）…- UDC entity is considered to be located in PDCP layer…（以下省略）」
［当審訳］
「４ 性能評価４．１ シミュレーションの条件…（中略）…－ ＵＤＣエンティティはＰＤＣＰ層に位置するものとする。…（以下省略）」
（２）引用発明１
前記（１）ア及びエより、ｅＮＢは、ＵＥにより圧縮されたデータバイトを含むＵＬ圧縮パケットをＵＥから受信して、圧縮されたデータバイトを解凍する方法を実行するものといえ、また、ｅＮＢは解凍器、ＵＥは圧縮器と同一視できる。
また、「ＵＤＣ」は、引用文献１のタイトルに含まれる「Uplink Data Compression」（アップリンクデータ圧縮）の略語であり、「ヘッダ」がパケットに含まれる情報であること、及び、ＵＥがｅＮＢに送信することがアップリンク（ＵＬ）と称されることは本願優先日前の技術常識であるから、前記（１）イの「UDC Header」（「ＵＤＣヘッダ」）は、ＵＬ圧縮パケットに含まれるものといえる。
また、前記（１）イから、前記（１）ウの「ＵＤＣ共通ヘッダ」が「ＵＤＣヘッダ」に含まれることが見て取れる。
また、前記（１）イ（特に図１）及びウより、「ＵＤＣ共通ヘッダ」は、３ビットの「パケットアクション」と４ビットの「チェックサム」を含むものといえる。
また、前記（１）ウ及びエ（特に図４）より、「パケットアクション」は、パケットが圧縮されているか否か、ＵＬ圧縮メモリをどの部分で更新するか、及び、ＵＬ圧縮メモリをリセットするか否かを指示する情報であり、また、「チェックサム」は、解凍器が、圧縮器と解凍器間のＵＬ圧縮メモリの同期不能状態を検出するために使用される情報といえる。
以上から、引用文献１には次の発明（以下、「引用発明１」という。）が記載されていると認められる。
「 ｅＮＢ（解凍器）が、ＵＥ（圧縮器）により圧縮されたデータバイトを含むＵＬ圧縮パケットをＵＥから受信して、圧縮されたデータバイトを解凍する方法であって、ＵＬ圧縮パケットは、３ビットのパケットアクションと４ビットのチェックサムを含む共通ＵＤＣヘッダを含むＵＤＣヘッダを含み、パケットアクションは、パケットが圧縮されているか否か、ＵＬ圧縮メモリをどの部分で更新するか、及び、ＵＬ圧縮メモリをリセットするか否かを指示する情報であり、チェックサムは、解凍器が、圧縮器と解凍器間のＵＬ圧縮メモリの同期不能状態を検出するために使用される情報であり、解凍器は、ＵＬ圧縮パケットを調べて、そのパケットが圧縮されているかどうかを判断し、パケットが圧縮されていない場合は、ヘッダバイトを削除し、パケットが圧縮されている場合には、パケットの解凍を行い、ＵＤＣエンティティはＰＤＣＰ層に位置するものとする、方法。」
２ 引用文献２について
（１）引用文献２記載事項
折りたたみ中（クリックで表示）
原査定の拒絶の理由に引用された上記引用文献２には、図面とともに次の事項が記載されている。
「[0051] Uplink data compression (UDC) aims to reduce the size of uplink data packets including, but not limited to, transport control protocol (TCP) headers, user datagram protocol (UDP) headers, Internet protocol (IP) headers, and data fields, for example. In UDC, the user device (e.g., such as user terminal 120) compresses the data, which may then be decompressed at a receiving end, for example, by the radio network controller (RNC).[0052] UDC may enable shorter transmit durations and low transmit power, which in tum may result in reduced interference, system capacity gains, and better user experience.[0053] UDC is performed by compressing packets headers and/or payloads based on prior packets sent. For example, a memory such as an uplink Compression Memory may be employed at both the transmitter and/or receiver side to remember past packets. Looking at the existing memory, repetitive strings in the prior packets may be identified and matched to strings in current packets. Matched blocks of data (e.g., bytes) in the current packet may be replaced with Pointer Metadata that points to a location in the UL Compression Memory of a block of matched bytes.[0054] FIG. 3 illustrates an example UDC packet format 300. As shown in FIG. 3, the UDC packet format 300 includes a Packet action field, a Checksum field, an Extension field, a UDC static header, a UDC dynamic header, a mismatched bytes field, and a remaining bytes field. The UDC static header includes a Number of matches field. The UDC dynamic header includes pointer metadata for each match being referenced for compression. The pointer metadata includes a Distance to pointer in bytes field, a Lookback length field and a Length in bytes fields.[0055] As shown in FIG. 3, the Packet action field may be the upper 3 bits of the packet header. The values of the 3 bits in the Packet action field can indicate various actions. A value of 011 for the Packet action field indicates full packet compression. In this case, the entire packet is pushed to the UL Compression (Comp) Memory. A value of 010 for the Packet action field indicates Header-only compression. In this cases, only the header is pushed to UL Compression Memory. A value of 100 for the Packet action field indicates Full packet compression, but the packet is not pushed to the UL Compression Memory. In this case, the packet is not pushed to the UL Compression Memory. For the above three Packet action field values (011, 010, and 100), decompression can be performed as indicated by the Number of Matches field and the pointer metadata fields.[0056] A value of 001 for the Packet action field indicates that compression was attempted but no matches were found. In this case, the entire packet is pushed to UL Compression Memory. A value of 000 for the Packet action field indicates no compression was attempted. In this case, the packet is not pushed to UL Compression Memory. A value of 101 for the Packet action field indicate for all bits in the UL Comp Memory to be reset to values of all zeros. In this case, the entire packet is pushed to UL Compression Memory. If the Packet action field is set to any one of these three Packet action values (001, 000, and 101), the Number of Matches and Pointer Metadata fields will not be present.[0057] As shown in FIG. 3, the Checksum field can be 4 bits. The Checksum field is used by the decompressor (e.g., the RNC) to detect UL Compression Memory Out of Sync conditions between the compressor and decompressor. For Packet action field values of 011, 010 and 100, the Checksum field includes the sum of the first 5 bytes of the first match in this packet. For a Packet action field value of 001, the Checksum field includes the sum of the last 5 bytes in the UL Compression Memory before the packet that includes the checksum is pushed into the UL Compression Memory. For a Packet action field value of 000, the checksum bits are invalid and may not be checked. For a Packet action field value of 101, the checksum bits can be set to all zeros.」
［当審訳］
「[0051]アップリンクデータ圧縮（ＵＤＣ）は、たとえば、限定はしないが、トランスポート制御プロトコル（ＴＣＰ）ヘッダ、ユーザデータグラムプロトコル（ＵＤＰ）ヘッダ、インターネットプロトコル（ＩＰ）ヘッダ、およびデータフィールドを含む、アップリンクデータパケットのサイズを低減することを目的とする。ＵＤＣでは、ユーザデバイス（たとえば、ユーザ端末１２０など）がデータを圧縮し、それは、次いで、たとえば、無線ネットワークコントローラ（ＲＮＣ）によって受信端において解凍され得る。[0052]ＵＤＣは、より短い送信持続時間および低送信電力を可能にし得、これは、干渉の低減、システム容量利得、およびより良いユーザエクスペリエンスを生じ得る。[0053]ＵＤＣは、送られた先行パケットに基づいてパケットヘッダおよび／またはペイロードを圧縮することによって実行される。たとえば、アップリンク圧縮メモリなどのメモリが、過去のパケットを記憶するために送信機側および／または受信機側の両方において採用され得る。既存のメモリを見ながら、先行パケット中の反復的なストリングが識別され、現在のパケット中のストリングにマッチされ得る。現在のパケット中のデータのマッチしたブロック（たとえば、バイト）は、マッチしたバイトのブロックのＵＬ圧縮メモリ中のロケーションを指すポインタメタデータと置き換えられ得る。[0054]図３は、例示的なＵＤＣパケットフォーマット３００を示す。図３に示されているように、ＵＤＣパケットフォーマット３００は、パケットアクションフィールドと、チェックサムフィールドと、拡張フィールドと、ＵＤＣ静的ヘッダと、ＵＤＣ動的ヘッダと、ミスマッチしたバイトフィールドと、残りのバイトフィールドとを含む。ＵＤＣ静的ヘッダはマッチ数フィールドを含む。ＵＤＣ動的ヘッダは、圧縮のために参照されている各マッチについてのポインタメタデータを含む。ポインタメタデータは、バイト単位のポインタまでの距離フィールド（Distance to pointer in bytes field）と、ルックバック長さフィールドと、バイト単位の長さフィールド（Length in bytes field）とを含む。[0055]図３に示されているように、パケットアクションフィールドはパケットヘッダの上部の３ビットであり得る。パケットアクションフィールド中の３ビットの値は様々なアクションを示すことができる。パケットアクションフィールドのための０１１の値がフルパケット圧縮を示す。この場合、パケット全体がＵＬ圧縮（Ｃｏｍｐ）メモリにプッシュされる。パケットアクションフィールドのための０１０の値がヘッダのみの圧縮を示す。この場合、ヘッダのみがＵＬ圧縮メモリにプッシュされる。パケットアクションフィールドのための１００の値がフルパケット圧縮を示すが、パケットはＵＬ圧縮メモリにプッシュされない。この場合、パケットはＵＬ圧縮メモリにプッシュされない。上記の３つのパケットアクションフィールド値（０１１、０１０、および１００）の場合、解凍が、マッチ数フィールドおよびポインタメタデータフィールドによって示されるように実行され得る。[0056]パケットアクションフィールドのための００１の値は、圧縮が試みられたが、マッチが見つけられなかったことを示す。この場合、パケット全体がＵＬ圧縮メモリにプッシュされる。パケットアクションフィールドのための０００の値は、圧縮が試みられなかったことを示す。この場合、パケットはＵＬ圧縮メモリにプッシュされない。パケットアクションフィールドのための１０１の値は、ＵＬ圧縮メモリ中のすべてのビットがすべて０の値にリセットされることを示す。この場合、パケット全体がＵＬ圧縮メモリにプッシュされる。パケットアクションフィールドがこれらの３つのパケットアクション値（００１、０００、および１０１）のうちのいずれか１つに設定される場合、マッチ数フィールドおよびポインタメタデータフィールドは存在しない。[0057]図３に示されているように、チェックサムフィールドは４ビットであり得る。チェックサムフィールドは、圧縮器と解凍器との間のＵＬ圧縮メモリ同期外れ条件を検出するために解凍器（たとえば、ＲＮＣ）によって使用される。０１１、０１０、および１００のパケットアクションフィールド値の場合、チェックサムフィールドは、このパケット中の最初のマッチの最初の５バイトの和を含む。００１のパケットアクションフィールド値の場合、チェックサムフィールドは、チェックサムを含むパケットがＵＬ圧縮メモリにプッシュされる前のＵＬ圧縮メモリ中の最後の５バイトの和を含む。０００のパケットアクションフィールド値の場合、チェックサムビットは無効であり、チェックされないことがある。１０１のパケットアクションフィールド値の場合、チェックサムビットはすべて０に設定され得る。」
「[0071] At 406, the sender may transmit the compressed current packet (e.g., to a receiver). In aspects, the present methods and apparatus include complementary methods and apparatus on the receive side. In such aspects, one or more blocks of data in one or more portions of one or more previous packets (e.g., the immediately preceding packet or any other prior packet) may be stored in a memory, and such data may be employed to decode and/or reassemble such packets after receipt, for example. In aspects, the data stored in memory on the transmit side in step 402 may also be provided to or obtained, and stored on the receive side.」
［当審訳］
「[0071]４０６において、送信側は、圧縮された現在のパケットを（たとえば、受信機に）送信する。態様では、本方法および本装置は、受信側上の相補的方法および装置を含む。そのような態様では、１つまたは複数の前のパケット（たとえば、直前のパケットまたは他の先行パケット）の１つまたは複数の部分中のデータの１つまたは複数のブロックはメモリに記憶され得、そのようなデータは、たとえば、受信の後にそのようなパケットを復号および／または再組立するために採用され得る。態様では、ステップ４０２中に送信側上のメモリに記憶されたデータはまた、受信側に与えられるかまたは取得され、受信側上に記憶され得る。」
「FIG.3［図：0001381559000003.jpg］」
（当審訳は省略）
（２）引用発明２
引用文献２には、「アップリンク圧縮（ＵＤＣ）」に関するものであって、「アップリンク」の技術的性質に鑑みれば、引用文献２の[0051]に記載の「受信端」（ＲＮＣ）及び「ユーザデバイス」はそれぞれ、送信機及び受信機といい得るものである。
よって、引用文献２の[0051]より、引用文献２には、アップリンクデータ圧縮（ＵＤＣ）において、受信機が、送信機によって圧縮されたデータを受信して、解凍する方法が記載されているといえる。
また、引用文献２の[0057]に記載の「圧縮器」及び「解凍器」はそれぞれ、「アップリンク圧縮（ＵＤＣ）」に関する限りにおいては、前記「送信機」及び「受信機」と同一視できる。
また、引用文献２のFIG.3を参酌すれば、[0057]に記載の「チェックサムフィールド」は、「パケットアクションフィールド」に続くものである。
よって、前記（１）より、引用文献２には次の発明（以下、「引用発明２」という。）が記載されていると認められる。
「 アップリンクデータ圧縮（ＵＤＣ）において受信機が、送信機によって圧縮されたデータを受信して、解凍する方法であって、ＵＤＣパケットフォーマット３００は、パケットアクションフィールドと、これに続くチェックサムフィールドとを含み、パケットアクションフィールドはパケットヘッダの上部の３ビットであり、パケットアクションフィールド中の３ビットの値は様々なアクションを示すことができ、０１１の値がフルパケット圧縮を示し、この場合、パケット全体がＵＬ圧縮（Ｃｏｍｐ）メモリにプッシュされ、続きを表示（全13行）０１０の値がヘッダのみの圧縮を示し、この場合、ヘッダのみがＵＬ圧縮メモリにプッシュされ、１００の値がフルパケット圧縮を示すが、パケットはＵＬ圧縮メモリにプッシュされず、この場合、パケットはＵＬ圧縮メモリにプッシュされず、００１の値は、圧縮が試みられたが、マッチが見つけられなかったことを示し、この場合、パケット全体がＵＬ圧縮メモリにプッシュされ、０００の値は、圧縮が試みられなかったことを示し、この場合、パケットはＵＬ圧縮メモリにプッシュされず、１０１の値は、ＵＬ圧縮メモリ中のすべてのビットがすべて０の値にリセットされることを示し、この場合、パケット全体がＵＬ圧縮メモリにプッシュされ、チェックサムフィールドは４ビットであり、送信機と受信機との間のＵＬ圧縮メモリ同期外れ条件を検出するために受信機によって使用され、チェックサムフィールドは、０１１、０１０、および１００のパケットアクションフィールド値の場合、このパケット中の最初のマッチの最初の５バイトの和を含み、００１のパケットアクションフィールド値の場合、チェックサムを含むパケットがＵＬ圧縮メモリにプッシュされる前のＵＬ圧縮メモリ中の最後の５バイトの和を含み、０００のパケットアクションフィールド値の場合、無効であり、送信側は、圧縮された現在のパケットを受信機に送信し、１つまたは複数の前のパケットの１つまたは複数の部分中のデータの１つまたは複数のブロックはメモリに記憶され得、そのようなデータは、受信の後にそのようなパケットを復号および／または再組立するために採用され得る、方法。」
第５ 引用文献１に基づく進歩性の判断
１ 本願発明１について
（１）対比
本願発明１と引用発明１とを対比する。
ア 引用発明１の「ｅＮＢ（解凍器）」及び「ＵＥ（圧縮器）」はそれぞれ、本願発明１の「解凍エンド」及び「圧縮エンド」に相当する。
引用発明１の「ＵＬ圧縮パケット」は、所定の通信プロトコルの下で送信されることは自明であるから、本願発明１の「ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケット」とは、「所定のパケット」である点において共通する。
また、引用発明１において、「圧縮されたデータバイト」を含む「ＵＬ圧縮パケット」は、「所定のパケット」のうちの「データパケット」といい得るものである。
そして、引用発明１の「パケットアクション」は、「パケットが圧縮されているか否か」を指示する情報であるから、本願発明１の「データパケットの圧縮コンテキスト情報」に相当する。
加えて、引用発明１の「パケットアクション」は、「ＵＬ圧縮メモリをどの部分で更新するか、及び、ＵＬ圧縮メモリをリセットするか否かを指示する情報」でもあり、また、「チェックサム」は、「解凍器が、圧縮器と解凍器間のＵＬ圧縮メモリの同期不能状態を検出するために使用される情報」であり、引用発明１の「圧縮器」の「ＵＬ圧縮メモリ」及び「解凍器」の「ＵＬ圧縮メモリ」はそれぞれ、本願発明１の「圧縮エンドの圧縮キャッシュエリア」及び「解凍エンドの圧縮キャッシュエリア」に相当する。
よって、引用発明１の「パケットアクション」と「チェックサム」は、本願発明１の「圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報」に相当する。
また、引用発明１において、「ＵＬ圧縮パケットをＵＥから受信」すると「パケットアクション」を含む「ＵＤＣヘッダ」を検査するものといえる。
また、引用発明１の「ＵＤＣヘッダ」は、「ＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダ」といい得るものである。
よって、引用発明１と、本願発明１の「解凍エンドが、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケットを受信すると、前記ＰＤＣＰパケットのうち、少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダを検査すること」とは、「解凍エンドが、所定のパケットを受信すると、前記所定のパケットのうち、少なくとも所定のパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダを検査すること」との共通の構成を備える。
イ 引用発明１において、「ｅＮＢ（解凍器）」は、「パケットアクション」と「チェックサム」の指示に基づいて、「ＵＬ圧縮パケット」に対して対応する処理を行うものである。
よって、前記アを参酌すれば、引用発明１と本願発明１の「前記解凍エンドが、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行うこと」とは、「前記解凍エンドが、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記所定のパケットのうちのデータパケットに対し、対応する処理を行うこと」との共通の構成を備える。
ウ 引用発明１の「パケットアクション」は、３ビットからなる１つの「指示ビットフィールド」といえる。
また、引用発明１の「パケットアクション」は、「パケットが圧縮されているか否かを指示する」機能と、「ＵＬ圧縮メモリをリセットするか否かを指示する」機能とを備え、これらの機能はそれぞれ、本願発明１の「ＵＤＣ圧縮を行うか否かを指示する」機能及び「解凍キャッシュエリア復元を指示する」機能に相当する。
よって、引用発明１の、「ＵＤＣヘッダ」が「パケットアクション」を含むことと、本願発明１の「前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む」こととは、「前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示し、及び解凍キャッシュエリア復元を指示するための指示ビットフィールドを含む」との点において共通する。（なお、本願明細書【００７９】の記載「解凍キャッシュエリア検査用の指示ビットフィールド（Ｃ情報：６ビット）」からすると、本願発明１に係る「指示ビットフィールド」は、１ビットの情報には限定されていない。）
エ 引用発明１の「ｅＮＢ（解凍器）が、ＵＥ（圧縮器）により圧縮されたデータバイトを含むＵＬ圧縮パケットをＵＥから受信して、圧縮されたデータバイトを解凍する方法」は、本願発明１の「アップリンクデータ解凍方法」に相当する。
（２）一致点、相違点
前記（１）より、本願発明１と引用発明１は、次の点において一致ないし相違する。
［一致点］
「 解凍エンドが、所定のパケットを受信すると、前記所定のパケットのうち、少なくとも所定のパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダを検査することと、前記解凍エンドが、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記所定のパケットのうちのデータパケットに対し、対応する処理を行うこととを含み、前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示し、及び解凍キャッシュエリア復元を指示するための指示ビットフィールドを含む、アップリンクデータ解凍方法。」
［相違点］
＜相違点１－１＞
「パケット」が、本願発明１では、「ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケット」であり、「データパケット」が、本願発明１では、「（少なくとも）ＰＤＣＰパケットのうちの」ものであるのに対し、引用発明１は、「ＵＤＣエンティティはＰＤＣＰ層に位置するものとする」との技術事項を備えるものの、当該技術事項から直ちに「ＵＬ圧縮パケット」が「ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケット」のうちのものであるとはいえない点。
＜相違点１－２＞
本願発明１は、「ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む」との構成を備え、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能とを異なる「ビットフィールド」で実現するのに対し、引用発明１の「パケットアクション」は、「ＵＤＣ圧縮を行うか否かを指示する」ことと「解凍キャッシュエリア復元を指示する」ことを１つの指示ビットフィールドで実現するものである点。
（３）相違点についての判断
事案に鑑みて、先に上記相違点１－２について検討するに、引用発明１において、「パケットアクション」は、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能のみならず、「ＵＬ圧縮メモリをどの部分で更新するかを指示する」機能とを組み合わせて３ビットで表現するものであり、このうち、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能のみを切り離してこれらの各々を異なるビットフィールドで実現するように変更する動機付けを当業者といえども見出すことはできない。
また、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能とを、２つの異なる「指示ビットフィールド」により実現することが本願優先日前に周知技術であったともいえない。
したがって、上記相違点１－１について判断するまでもなく、本願発明１は、当業者であっても、引用発明１に基いて容易に発明をすることができたものとはいえない。
２ 本願発明２ないし６について
本願発明２ないし６も、相違点１－２に係る本願発明１の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明１に基いて容易に発明をすることができたものとはいえない。
３ 本願発明７ないし１１について
本願発明７は、本願発明１を、「アップリンクデータ圧縮方法」として特定したものであって、本願発明８ないし１１は、本願発明７を減縮したものである。
よって、本願発明７ないし１１は、相違点１－２に係る本願発明１の構成に対応する技術事項を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明１に基いて容易に発明をすることができたものとはいえない。
４ 本願発明１２及び１３について
本願発明１２は、本願発明１を「解凍エンド」の発明として特定したものであり、本願発明１３は、本願発明１２を減縮したものである。
よって、本願発明１２及び１３は、相違点１－２に係る本願発明１の構成に対応する技術事項を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明１に基いて容易に発明をすることができたものとはいえない。
５ 本願発明１４及び１５について
本願発明１４は、本願発明７を、「圧縮エンド」として特定したものであって、本願発明１５は、本願発明１４を減縮したものである。
よって、本願発明１４及び１５は、本願発明７と同様に、相違点１－２に係る本願発明１の構成に対応する技術事項を備えるものであるから、本願発明７と同じ理由により、当業者であっても、引用発明１に基いて容易に発明をすることができたものとはいえない。
第６ 引用文献２に基づく進歩性の判断
１ 本願発明１について
（１）対比
本願発明１と引用発明２とを対比する。
ア 引用発明２は、「受信機が、送信機によって圧縮されたデータを受信して、解凍する方法」であるから、引用発明２の「受信機」及び「送信機」はそれぞれ、本願発明１の「解凍エンド」及び「圧縮エンド」に相当する。
また、引用発明２において、「送信側は、圧縮された現在のパケットを受信機に送信」すると、「受信機」は、当該「圧縮されたパケット」を「解凍」するものといえる。
ここで、「圧縮された現在のパケット」は所定のプロトコルの下で送信されることは自明であるから、本願発明１の「ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケット」とは、「所定のパケット」である点において共通する。
また、「圧縮された現在のパケット」は、「圧縮されたデータ」を含む「データパケット」といえるものであって、「所定のパケット」のうちの「データパケット」といい得るものである。
また、引用発明２において、前記「圧縮された現在のパケット」は、「ＵＤＣパケットフォーマット」の形式であると認められ、引用発明２の「ＵＤＣパケットフォーマット３００は、パケットアクションフィールドと、これに続くチェックサムフィールドとを含み」及び「パケットアクションフィールドはパケットヘッダの上部の３ビット」との構成からすれば、「パケットアクションフィールド」及び「チェックサムフィールド」は、「パケットヘッダ」に含まれ、「ＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダ」といい得るものである。
そして、引用発明２の「パケットアクションフィールド」は、その値に関して、
「 ０１０の値がヘッダのみの圧縮を示し、この場合、ヘッダのみがＵＬ圧縮メモリにプッシュされ、１００の値がフルパケット圧縮を示すが、パケットはＵＬ圧縮メモリにプッシュされず、この場合、パケットはＵＬ圧縮メモリにプッシュされず、００１の値は、圧縮が試みられたが、マッチが見つけられなかったことを示し、この場合、パケット全体がＵＬ圧縮メモリにプッシュされ、０００の値は、圧縮が試みられなかったことを示し、この場合、パケットはＵＬ圧縮メモリにプッシュされず、１０１の値は、ＵＬ圧縮メモリ中のすべてのビットがすべて０の値にリセットされることを示し、この場合、パケット全体がＵＬ圧縮メモリにプッシュされ、」と規定され、また、「チェックサムフィールド」は、
「チェックサムフィールドは４ビットであり、送信機と受信機との間のＵＬ圧縮メモリ同期外れ条件を検出するために受信機によって使用され、チェックサムフィールドは、０１１、０１０、および１００のパケットアクションフィールド値の場合、このパケット中の最初のマッチの最初の５バイトの和を含み、００１のパケットアクションフィールド値の場合、チェックサムを含むパケットがＵＬ圧縮メモリにプッシュされる前のＵＬ圧縮メモリ中の最後の５バイトの和を含み、０００のパケットアクションフィールド値の場合、無効であり」と規定されるものであるから、「パケットアクションフィールド」は、パケットの圧縮がなされているか否か又はパケットのどの部分が圧縮されているかという圧縮のコンテキストを示す機能と、送信機と受信機との間のＵＬ圧縮メモリ同期外れ条件を検出するために、ＵＬ圧縮メモリのリセットを指示したり、チェックサムフィールドが、どのパケットのどの部分の和であるのか又は無効であるのかを指示したりする、ＵＬ圧縮メモリの制御を指示する機能とを備えているといえる。
ここで、引用発明２において、「送信機」の「ＵＬ圧縮メモリ」及び「受信機」の「ＵＬ圧縮メモリ」はそれぞれ、本願発明１の「圧縮エンドの圧縮キャッシュエリア」及び「解凍エンドの解凍キャッシュエリア」に相当し、また、引用発明２において「送信機と受信機との間のＵＬ圧縮メモリ同期外れ条件を検出する」ことは、本願発明２の「圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御する」ことに相当する。
そうすると、引用発明２の「パケットアクションフィールド」は、本願発明１の「データパケットの圧縮コンテキスト情報」と「圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報」とを兼ねた情報といえる。
また、引用発明２において、「受信機」が、「送信機」から受信した「圧縮されたパケット」を解凍するにあたり、当該パケットの「ＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダ」を検査するものといえる。
以上から、引用発明２と、本願発明１の「解凍エンドが、ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケットを受信すると、前記ＰＤＣＰパケットのうち、少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダを検査すること」とは、「解凍エンドが、所定のパケットを受信すると、前記所定のパケットのうち、少なくとも所定のパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダを検査すること」との共通の構成を備える。
イ 前記アより、引用発明２において、「受信機」が「パケットアクションフィールド」に示された指示に対応する処理を行うものといえる。
よって、前記アを参酌すれば、引用発明２と、本願発明１の「前記解凍エンドが、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行うこと」とは、「前記解凍エンドが、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記所定のパケットのうちのデータパケットに対し、対応する処理を行うこと」との共通の構成を備える。
ウ 引用発明２の「パケットアクションフィールド」は、３ビットからなる１つの「指示ビットフィールド」といえる。
また、前記アを参酌すれば、引用発明２の「パケットアクションフィールド」は、パケットの圧縮がなされているか否かを示す機能と、ＵＬ圧縮メモリのリセットを指示する機能とを備え、これらの機能はそれぞれ、本願発明１の「ＵＤＣ圧縮を行うか否かを指示する」機能及び「解凍キャッシュエリア復元を指示する」機能に相当する。
よって、引用発明２の、「パケットヘッダ」が「パケットアクションフィールド」を含むことと、本願発明１の「前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む」こととは、「前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示し、及び解凍キャッシュエリア復元を指示するための指示ビットフィールドを含む」との点において共通する。
エ 引用発明２の「アップリンクデータ圧縮（ＵＤＣ）において受信機が、送信機によって圧縮されたデータを受信して、解凍する方法」は、本願発明１の「アップリンクデータ解凍方法」に相当する。
（２）一致点、相違点
前記（１）より、本願発明１と引用発明２は、次の点において一致ないし相違する。
［一致点］
「 解凍エンドが、所定のパケットを受信すると、前記所定のパケットのうち、少なくとも所定のパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダを検査することと、前記解凍エンドが、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記所定のパケットのうちのデータパケットに対し、対応する処理を行うこととを含み、前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示し、及び解凍キャッシュエリア復元を指示するための指示ビットフィールドを含む、アップリンクデータ解凍方法。」
［相違点］
＜相違点２－１＞
「パケット」が、本願発明１では、「ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケット」であり、「データパケット」が、本願発明１では、「（少なくとも）ＰＤＣＰパケットのうちの」ものであるのに対し、引用発明２の「圧縮された現在のパケット」は「ＰＤＣＰ（Ｐａｃｋｅｔ Ｄａｔａ Ｃｏｎｖｅｒｇｅｎｃｅ Ｐｒｏｔｏｃｏｌ）パケット」のうちのものであるとは特定されてない点。
＜相違点２－２＞
本願発明１は、「ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む」との構成を備え、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能とを異なる「ビットフィールド」で実現するのに対し、引用発明２の「パケットアクションフィールド」は、「ＵＤＣ圧縮を行うか否かを指示する」ことと「解凍キャッシュエリア復元を指示する」ことを１つの指示ビットフィールドで実現するものである点。
（３）相違点についての判断
事案に鑑みて、先に上記相違点２－２について検討するに、引用発明２において、「パケットアクションフィールド」は、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能のみならず、パケットのどの部分が圧縮されているかを指示する機能、チェックサムフィールドが、どのパケットのどの部分の和であるのか又は無効であるのかを指示する機能とを組み合わせて３ビットで表現するものであり、このうち、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能のみを切り離してこれらの各々を異なるビットフィールドで実現するように変更する動機付けを当業者といえども見出すことはできない。
また、「ＵＤＣ圧縮を行うか否かを指示する」機能と「解凍キャッシュエリア復元を指示する」機能とを、２つの異なる「指示ビットフィールド」により実現することが本願優先日前に周知技術であったともいえない。
したがって、上記相違点２－１について判断するまでもなく、本願発明１は、当業者であっても、引用発明２に基いて容易に発明をすることができたものとはいえない。
２ 本願発明２ないし６について
本願発明２ないし６も、相違点２－２に係る本願発明１の構成を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明２に基いて容易に発明をすることができたものとはいえない。
３ 本願発明７ないし１１について
本願発明７は、本願発明１を、「アップリンクデータ圧縮方法」として特定したものであって、本願発明８ないし１１は、本願発明７を減縮したものである。
よって、本願発明７ないし１１は、相違点２－２に係る本願発明１の構成に対応する技術事項を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明２に基いて容易に発明をすることができたものとはいえない。
４ 本願発明１２及び１３について
本願発明１２は、本願発明１を「解凍エンド」の発明として特定したものであり、本願発明１３は、本願発明１２を減縮したものである。
よって、本願発明１２及び１３は、相違点２－２に係る本願発明１の構成に対応する技術事項を備えるものであるから、本願発明１と同じ理由により、当業者であっても、引用発明２に基いて容易に発明をすることができたものとはいえない。
５ 本願発明１４及び１５について
本願発明１４は、本願発明７を、「圧縮エンド」として特定したものであって、本願発明１５は、本願発明１４を減縮したものである。
よって、本願発明１４及び１５は、本願発明７と同様に、相違点２－２に係る本願発明１の構成に対応する技術事項を備えるものであるから、本願発明７と同じ理由により、当業者であっても、引用発明２に基いて容易に発明をすることができたものとはいえない。
［補足］
なお、令和２年７月３１日付けの拒絶理由通知書においては、
「 上記解凍エンドにおける処理は、解凍エンドにおける解凍方法がどのようなものであるのかについて特定する一方で、圧縮エンドにおける圧縮方法を、以下の点（ａ）を除いて、何ら特定していない。（ａ）ＰＤＣＰパケットは、少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣヘッダを含む点。したがって、以下では、解凍エンドにおける処理は、上記した点（ａ）を除いて、サブコンビネーションの発明である圧縮エンドにおける圧縮方法を特定するための意味を有しないものとして、請求項７に係る発明を認定する。また、請求項８－１１、１４－１５についても同様である。」と説示され、また、原査定では、
「この認定では、（ａ）を除くと述べているように、ＵＤＣヘッダがどのような情報を含んでいるのかという点については、圧縮エンドにおける圧縮方法を特定するための意味を有するものとしている。すなわち、（Ａ）や（Ｂ）は圧縮エンドにおける圧縮方法を特定するための意味を有するものとしている。」と説示されている。
なお、原査定において参照されている上記「（Ａ）」及び「（Ｂ）」は、令和２年１１月１３日に提出された意見書によれば、
「（А）少なくともＰＤＣＰパケットのうちのデータパケットの圧縮コンテキスト情報と、圧縮エンドの圧縮キャッシュエリアとの一致を確保するように前記解凍エンドの解凍キャッシュエリアを制御することを前記解凍エンドに指示するための解凍キャッシュエリア関連情報とを含むＵＤＣ（Ｕｐｌｉｎｋ Ｄａｔａ Ｃｏｍｐｒｅｓｓｉｏｎ）ヘッダ、（Ｂ）前記ＵＤＣヘッダは、ＵＤＣ圧縮を行うか否かを指示するための第１指示ビットフィールド、及び解凍キャッシュエリア復元を指示するための第２指示ビットフィールドを含む」
との技術事項である。
そうすると、原査定の上記説示は、請求項７ないし１１、１４及び１５に係る発明（本願発明７ないし１１、１４及び１５）に含まれる「前記解凍エンドが」「ＵＤＣヘッダを検査し、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行い」という、他のサブコンビネーションの発明である「アップリンクデータ解凍方法」又は「解凍エンド」の構成が、請求項７ないし１１、１４及び１５に係るサブコンビネーションの発明（「アップリンクデータ圧縮方法」又は「圧縮エンド」）の構成を特定するものではない、との趣旨と理解できる。
ここで、「圧縮」と「解凍」とが互いに対応した処理であることは本願優先日前における技術常識であるから、本願発明７ないし１１、１４及び１５における「前記解凍エンドが」「ＵＤＣヘッダを検査し、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行い」との構成が「解凍エンド」及びその「解凍方法」を具体的に特定している以上、それに対応した「圧縮エンド」及びその「圧縮方法」を具体的に特定しているといえる。
したがって、本願発明７ないし１１、１４及び１５の「前記解凍エンドが」「ＵＤＣヘッダを検査し、前記圧縮コンテキスト情報と解凍キャッシュエリア関連情報に基づいて、前記ＰＤＣＰパケットのうちのデータパケットに対し、対応する処理を行い」との他のサブコンビネーションの発明に係る構成は、本願発明７ないし１１、１４及び１５に係るサブコンビネーションの発明の構成を特定するものではないとはいえない。
第７ むすび
以上のとおり、本願発明１ないし１５は、当業者が引用文献１又は引用文献２に記載された発明に基いて容易に発明をすることができたものではない。
したがって、原査定の理由によっては、本願を拒絶することはできない。
また、他に本願を拒絶すべき理由を発見しない。
審決本文（J-PlatPat）
J-PlatPatの審決検索トップを開きます。番号入力で「審判番号」を選び、下の番号を貼り付けて検索してください。
2021-005536