T 1281/19 (LDPC coding/HUGHES) of 28.7.2022

European Case Law Identifier: ECLI:EP:BA:2022:T128119.20220728
Date of decision: 28 July 2022
Case number: T 1281/19
Application number: 13832765.5
IPC class: H03M 13/11
H03M 13/00
H04L 1/00
Language of proceedings: EN
Distribution: D
Download and more information:
Decision text in EN (PDF, 382 KB)
Documentation of the appeal procedure can be found in the Register
Bibliographic information is available in: EN
Versions: Unpublished
Title of application: System and method for communicating with low density parity check codes
Applicant name: Hughes Network Systems, LLC
Opponent name: -
Board: 3.5.03
Headnote: -
Relevant legal provisions:
European Patent Convention Art 84
European Patent Convention Art 123(2)
European Patent Convention R 103(4)(c)
Rules of procedure of the Boards of Appeal Art 12(4)
Keywords: Clarity - main and 1st to 7th auxiliary requests (no)
Added subject-matter - main request and 1st to 7th auxiliary requests (yes)
Admittance of requests not admitted by the examining division - 8th auxiliary request (no): no discretionary error and fresh case
Partial reimbursement of appeal fee at 25% - (yes): timely withdrawal of the request for oral proceedings
Catchwords:

-

Cited decisions:
-
Citing decisions:
-

Summary of Facts and Submissions

I. The appeal is against the decision of the examining division to refuse the present European patent application for lack of clarity (Article 84 EPC) and for added subject-matter (Article 123(2) EPC) with respect to a main request and first to seventh auxiliary requests. Furthermore, the claims of an eighth auxiliary request were not admitted into the examination proceedings under Rule 137(3) EPC.

II. With its statement setting out the grounds of appeal, the appellant requested that the decision under appeal be set aside and that a patent be granted on the basis of the above claim requests, i.e. main request and auxiliary requests I to VIII.

III. In a communication annexed to the summons to oral proceedings pursuant to Article 15(1) RPBA 2020, the board expressed its negative preliminary opinion on the appeal, including objections under Articles 123(2), 84 and 56 EPC and admittance considerations under Article 12(4) RPBA 2007.

IV. By its letter of reply, the appellant informed the board that it withdrew the request for oral proceedings and that it would not be attending the scheduled oral proceedings (cf. Rule 103(4)(c) EPC). It did not submit any comments on the substance of the board's communication under Article 15(1) RPBA 2020.

V. Oral proceedings were then cancelled.

VI. Claim 1 of the main request reads as follows (labelling by the board):

"A method comprising:

(a) receiving a first string of data bits of a length k2 bits; and

encoding the first string of data bits to generate a code block of a length N2 bits for transmission over a channel of a wireless communications network using parity matrices;

(b) wherein the first string of data bits is encoded based on a supported (N1,k1) forward error correction (FEC) code of a code rate R = k1/N1 configured to encode a string of data bits of a length k1 bits to generate a code block of a length N1 bits; and

wherein, to facilitate the encoding of the first string of data bits based on the (N1,k1) FEC code, the encoding comprises one or more of padding, repeating and puncturing the first string of data bits and a resulting N1 bit code block to generate the N2 bit code block; and

wherein the FEC code comprises a low density parity check (LDPC) code; and

(c) wherein the supported (N1,k1) FEC code is a one of a plurality of supported FEC codes, each being a different (N,k) code of a respective code rate

R = k/N configured to encode a string of data bits of a length k bits to generate a code block of a length N bits,

(d) and the length k2 of the first string of data bits does not correspond to any of the supported FEC codes and

(e) selecting the (N1,k1) FEC code as the one of the plurality of supported FEC codes with respect to which the length N1 of the resulting N1 bit code block reflects a bit length that is a next size larger than the length N2 of the N2 bit code block

characterized by

(f) encoding a string of data bits using a LDPC portion; and

(g) determining the optimum LDPC portion to be used to encode the data bits based on performance considerations, by choosing the transmitted block sizes such that the minimum transmitted size is maximized."

VII. Claim 1 of auxiliary request I differs from claim 1 of the main request in that feature (e) is deleted, the wording "characterized by" follows feature (d) and in that features (a), (f) and (g) now read as follows (underlining of added text and labelling by the board):

(a1) "receiving a first string of data bits of a

length k2 bits; and

encoding by an encoder the first string of data bits to generate a code block of a transmitted block size for transmission over a channel of a wireless communications network using parity matrices;"

(f1) "encoding a first string of data bits using at

least one of the plurality of LDPC portions of the encoder; and"

(g1) "determining the optimum LDPC portion to be

used to encode the data bits based on performance considerations, by choosing a supported data stream length of the transmitted code block size such that the minimum transmitted code block size is maximized."

VIII. Claim 1 of auxiliary request II differs from claim 1 of auxiliary request I in that feature (g1) now reads as follows (underlining of added text and labelling by the board):

(g2) "determining the optimum LDPC portion to be

used to encode the data bits based on performance considerations, by choosing a supported data stream length of the transmitted code block size such that the minimum transmitted code block size is maximized, and

wherein each code block is equally and fully be filled with information."

IX. Claim 1 of auxiliary request III differs from claim 1 of auxiliary request I in that feature (g1) now reads as follows (underlining of added text and labelling by the board):

(g3) "determining the optimum LDPC portion to be

used to encode the data bits based on performance considerations, by choosing a supported data stream length of the transmitted code block size such that the minimum transmitted code block size is maximized; and

wherein each code block has the longest possible length without using dummy bits."

X. Claim 1 of auxiliary request IV differs from claim 1 of auxiliary request I in that feature (g1) now reads as follows (underlining of added text and labelling by the board):

(g4) "determining the optimum LDPC portion to be

used to encode the data bits based on performance considerations, by choosing a supported data stream length of the transmitted code block size such that the minimum transmitted code block size is maximized; and

wherein each code block is equally and fully be filled with information; and

wherein each code block has the longest possible length without using dummy bits."

XI. Claim 1 of auxiliary request V differs from claim 1 of auxiliary request II in that feature (g2) now reads as follows (underlining of added text and labelling by the board):

(g5) "determining the optimum LDPC portion to be

used to encode the data bits based on performance considerations, by choosing a supported data stream length of the transmitted code block size such that the minimum transmitted code block size is maximized; and

converting a first string of data bits into lengths that can be put into supported data stream length of the transmitted code block sizes; and

wherein each code block is equally and fully be filled with information."

XII. Claim 1 of auxiliary request VI differs from claim 1 of auxiliary request V in that feature (g5) now reads as follows (underlining of added text and labelling by the board):

(g6) "determining the optimum LDPC portion to be

used to encode the data bits based on performance considerations, by choosing a supported data stream length of the transmitted code block size such that the minimum transmitted code block size is maximized; and

converting a first string of data bits into lengths that can be put into supported data stream length of the transmitted code block sizes; and

wherein each code block is equally and fully be filled with information; and

wherein each code block has the longest possible length without using dummy bits."

XIII. Claim 1 of auxiliary request VII differs from claim 1 of auxiliary request I in that feature (g1) now reads as follows (underlining of added text and labelling by the board):

(g7) "determining the optimum LDPC portion to be

used to encode the data bits based on performance considerations, by choosing a supported data stream length of the transmitted code block size such that the minimum transmitted code block size is maximized, and

wherein the first string of data bits is divided into lengths that fit into transmitted code block size, so that

each code block is equally and fully be filled with information."

XIV. Claim 1 of auxiliary request VIII reads as follows:

"A method comprising:

receiving a first string of data bits of a length k2 bits; and

encoding the first string of data bits to generate a code block of a length N2 bits for transmission over a channel of a wireless communications network;

wherein the first string of data bits is encoded based on a supported (N1,k1) forward error correction (FEC) code of a code rate R = k1/N1 configured to encode a string of data bits of a length k1 bits to generate a code block of a length N1 bits; and

wherein, to facilitate the encoding of the first string of data bits based on the (N1,k1) FEC code, the encoding comprises one or more of padding, repeating and puncturing the first string of data bits and a resulting N1 bit code block to generate the N2 bit code block; and

wherein the FEC code comprises a low density parity check (LDPC) code, and

wherein:

for an LDPC code of a code rate R equal to one of the group consisting 1/2, 2/3, 4/5, 3/4 and 5/6, the punctured bits are punctured from parity bits of the N1 bit code block; and

for an LDPC code of a code rate R equal to one of the group consisting of 8/9 and 9/10, the punctured bits are punctured from data bits of the N1 bit code block."

Reasons for the Decision

1. Background of the invention

The present invention relates to the encoding of a data stream of kx data bits with an LDPC (low density parity check) code, which is an FEC (forward error correction) code, into Nx encoded bits to be transmitted. Each individual length of a code block to be encoded requires a corresponding LDPC code (paragraphs [0047] and [0048]).

If a data stream is to large for the maximum supported code block length, it has to be split up which may lead to partially filled blocks, it being noted that it is more power-efficient to transmit larger data blocks than smaller data blocks (paragraph [0020]). Therefore, the block size should be maximised and at the same time the empty spaces in the transmitted blocks minimised (paragraph [0050]).

2. Main request - clarity and added subject-matter (Articles 84 and 123(2) EPC)

2.1 Claim 1 of the main request includes essentially the following limiting features (the labelling follows the labelling used in the section summary of facts and submissions):

A method comprising:

(a) encoding a first string of data of k2 bits to generate a code block with N2 bits;

(b) wherein the first string of k2 data bits is encoded based on a supported (N1,k1) FEC code configured to encode a string of data of k1 bits to generate a code block of N1 bits, wherein, one or more of padding, repeating and puncturing the first string of data bits and a resulting N1 bit code block to generate the N2 bit code block, the FEC code comprising an LDPC code;

(c) wherein the supported (N1,k1) FEC code is one of a plurality of different supported FEC codes, and

(d) the length k2 of the first string of data bits does not correspond to any of the supported FEC codes;

(e) selecting for encoding among the supported FEC codes the one with respect to which the length N1 of the resulting N1 bit code block is a next size larger than the length N2,

(f) encoding a string of data bits using an LDPC portion;

(g) determining the optimum LDPC portion to be used to encode the data bits based on performance considerations, by choosing the transmitted block sizes such that the minimum transmitted size is maximised.

2.2 Clarity (Article 84 EPC)

2.2.1 As to the expression "a next size larger" in feature (e), it is unclear whether the selected code is larger by the "next size" than the length N2 and what "size" refers to.

2.2.2 Feature (f) refers to "a string" of data without specifying which data are actually to be encoded. In the following, the "string" in this feature is understood to be the "first string of data to be encoded".

Further, this feature refers to an "LDPC portion" which leaves it unclear whether the full LDPC code required for encoding a given number of bits is used or only a part of it. In the following, "LDPC portion" is understood as the "code for encoding" (see paragraph [0056] of the present application as published).

2.2.3 Feature (g) refers to "the data bits", thereby leaving it unclear which ones of the several data bits are meant. Feature (g) further refers to "the transmitted block sizes" for which there is no antecedent.

Furthermore, even understanding that the "code block of a length N2 bits for transmission" (cf. beginning of claim 1) is later transmitted and becomes a transmitted block, it is unclear which is the at least one further transmitted block implied by "transmitted block sizes" (emphasis added). This also renders the term "minimum transmitted transmitted size" of feature (g) unclear since, in the absence of other transmitted blocks, a "minimum" cannot be defined.

2.2.4 Claim 1 of the main request therefore lacks clarity (Article 84 EPC).

2.3 Added subject-matter (Article 123(2) EPC)

2.3.1 The application as filed nowhere refers in general to an FEC code but only to an LDPC code. Feature (b), however, also includes that an FEC code is used comprising an LDPC code and a code not being an LDPC code, for which there is no basis.

2.3.2 According to feature (e), an FEC code is selected for encoding data block which has a length that is next size larger than the length of the first data string which is to be encoded. However, there is no disclosure in the originally filed application for this feature. Paragraphs [0084] to [0086] and [0109] to [0115] only show that a data string of 6720 bit is divided into two strings of 3360 bits respectively which then are encoded using a code block with 3600 bits which is no doubt more than 3360. However, there is no disclosure of a selection of an FEC code with a length "the next size larger" than the length of the data string to be encoded.

2.3.3 According to feature (g), the transmitted block sizes are chosen such that the minimum transmitted size is maximised and thereby the optimum LDPC code is determined. Paragraphs [0109] to [0115] disclose how an LDPC code for a supported code size can be used to encode smaller code sizes by means of shortening, puncturing and repeating and the details of adding and removing dummy bits are explained. However, no details as to the determination which LDPC code is to be used are given in that context. Paragraphs [0118] and [0119] refer to a case in which the data block to be transmitted is larger than the maximum supported size and more than one block needs to be transmitted. The large code block is divided such that the minimum transmitted size is maximised. Again, no reference is made to the LDPC code and its determination.

Paragraphs [0084] to [0086] disclose that there are multiple LDPC portions adapted to generate LDPC codes of different sizes and that, if the data string is larger than the largest LDPC portion, the data string need to be broken into separate pieces. The optimum LDPC portion used for encoding is determined based on performance considerations. As the examining division pointed out correctly in point 2.3.2 of the impugned decision, there is no disclosure that the LDPC code to be used for encoding is determined by choosing the transmitted block sizes such that the minimum transmitted size is maximised.

2.3.4 The appellant argued that paragraphs [0084] and [0085] disclosed the disputed feature and referred inter alia to the wording "[t]he encoder additionally includes a controller that can instruct a number of the LDPC portions to encode the information bits into a plurality of LDPC code blocks such that the minimum encoded block size is maximised".

However, the cited paragraphs do not refer to the determination of an LDPC code. Hence, claim 1 of the main request does not comply with Article 123(2) EPC.

2.3.5 In view of the above, the main request is not allowable under Articles 84 and 123(2) EPC.

3. Auxiliary requests I to VII

3.1 Claim 1 of auxiliary requests I to VII comprises essentially the following amendments:

feature (a1):

the generated code block has a transmitted block size (instead of the length N2 as specified in claim 1 of the main request)

feature (e): - deleted -

feature (f1):

one of multiple LDPC portions is used for encoding

features (g1) to (g7):

(i) each code block is equally and fully filled (only auxiliary requests II, IV, V, VI and VII)

(ii) each code block has the longest possible length without using dummy bits (only auxiliary requests III, IV and VI)

(iii) a [sic] first data string is converted into lengths of the transmitted code block sizes that can be put into supported data stream length (only auxiliary requests V and VI)

(iv) the first data string is divided into lengths that fit into transmitted code block size (only auxiliary request VII).

3.2 Clarity (Article 84 EPC)

3.2.1 The objections raised in point 2.2 above apply mutatis mutandis to claim 1 of auxiliary requests I to VII, it being noted that, in feature (f1), it is further unclear to which data "a first string of data" (emphasis added) refers.

3.2.2 Amendments (i) and (ii) refer to "each code block" although claim 1 does not disclose further code blocks, it being noted that "equally filled" requires a further block for comparison.

3.2.3 In amendment (iii), it is unclear whether "a first data string" corresponds to "the first data string" introduced at the beginning of claim 1. Further, it is unclear whether "converted into lengths" means to divide the data string or to simply shorten it, notwithstanding that it is unclear how an "information item" can be converted into a "length".

3.2.4 As to amendment (iv), it is noted that the "first data string" is unencoded and a "transmitted block" is encoded and thus by nature larger. It is thus unclear how data could be transmitted in the case that the unencoded data string is divided into lengths which are smaller than the transmitted data block sizes but larger after encoding.

3.2.5 Claim 1 of auxiliary requests I to VII is therefore likewise unclear (Article 84 EPC).

3.3 Added subject-matter (Article 123(2) EPC)

3.3.1 The objection raised in point 2.3.1 above applies also to claim 1 of auxiliary requests I to VII.

3.3.2 The objection raised in point 2.3.3 above applies to claim 1 of auxiliary requests I to VII, since all the amendments made to features (g1) to (g7) only refer to dividing the data string to be encoded but not to determining the optimum LDPC portion.

3.3.3 Amendments (i) and (ii) have their sole basis in paragraphs [0128] and [0129] respectively which, however, relate to a case in which no dummy bits are used and in which the size of the data block to be encoded is supported (see paragraph [0126]). This case is however not disclosed in combination with feature (b) which relates to padding, i.e. the use of dummy bits, and feature (d) which states that the size of the block to be encoded is not supported.

3.3.4 Amendment (iii) has its only basis in paragraph [0124] which however states that the data stream needs to be converted into data stream lengths that can be put into packet sizes that are supported by the receiver hardware. Claim 1, however, relates to the encoding, i.e. to the sender side. Paragraph [0124] therefore cannot provide a disclosure of amendment (iii).

3.3.5 Amendment (iv) has its only basis in paragraph [0124] which however states that the data stream is divided into smaller lengths that will fit into a supported data packet size, not a transmitted code block size.

3.3.6 Claim 1 of each of auxiliary requests I to VII therefore does not comply with Article 123(2) EPC.

3.4 In summary, auxiliary requests I to VII are likewise not allowable under Articles 84 and 123(2) EPC.

4. Auxiliary request VIII - admittance (Article 12(4) RPBA 2007)

4.1 Auxiliary request VIII was not admitted by the examining division under Rule 137(3) EPC because it

re-introduced previously raised novelty objections (cf. Reasons X, points 1.6 to 1.8).

4.2 The board holds that the examining division exercised its discretion correctly on the basis of the right principles and criteria (i.e. lack of clear allowability).

4.3 Furthermore, claim 1 of auxiliary request VIII lacks the determination of the optimum LDPC portion, which was included in claim 1 of all preceding claim requests, and limits the code rate of the LDPC code to specific values, contrary to claim 1 of all preceding requests. A "fresh case" has therefore been created, which is not in line with the main purpose of appeal proceedings, i.e. to assess the correctness of the impugned decision, and not to provide an opportunity to continue the examination proceedings (cf. Article 12(2) RPBA 2020).

4.4 Hence, the board holds auxiliary request VIII to be inadmissible pursuant to Article 12(4) RPBA 2007.

Order

For these reasons it is decided that:

The appeal is dismissed.

Quick Navigation