in re: u.s. patent 8,284,833 : attorney docket no. 082944...

UNITED STATES PATENT AND TRADEMARK OFFICE BEFORE THE PATENT TRIAL AND APPEAL BOARD

In Re: U.S. Patent 8,284,833 : Attorney Docket No. 082944.0102

Inventor: Hui Jin, et. al. :

Filed: Mar. 28, 2011 :

Claimed Priority: May 18, 2000 :

Issued: Oct. 9, 2012 : IPR No. Unassigned

Assignee: California Institute of Technology

Title: Serial Concatenation of Interleaved Convolutional Codes Forming Turbo-Like Codes

Mail Stop PATENT BOARD Patent Trial and Appeal Board U.S. Patent and Trademark Office P.O. Box 1450 Alexandria, Virginia 22313-1450

Submitted Electronically via the Patent Review Processing System

PETITION FOR INTER PARTES REVIEW OF CLAIMS 1, 2, 4, 6, 8, 9, 10, 11, 13 OF U.S. PATENT NO. 8,284,833 UNDER 35 U.S.C. §§ 311-319 AND 37

C.F.R. §§ 42.100 ET SEQ. BASED ON THE MACKAY SOFTWARE AND THE ‘710 PATENT

Petition for Inter Partes Review of U.S. Patent No. 8,284,833

i

TABLE OF CONTENTS

I. MANDATORY NOTICES, STANDING, AND FEES .................................. 1

II. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED .................... 2

A. Publications Relied Upon ........................................................................ 2

B. Grounds For Challenge ............................................................................ 3

III. OVERVIEW OF THE ’833 PATENT ............................................................ 4

A. Summary of the Claimed Subject Matter ................................................ 4

B. Prosecution History of the ’833 Patent .................................................... 4

C. Effective Date of the ’833 Patent ............................................................. 5

IV. SUMMARY OF PRIOR ART ......................................................................... 6

A. State of the Art ......................................................................................... 6

B. Summary of References Relied Upon ..................................................... 9

V. CLAIM CONSTRUCTION .......................................................................... 10

A. Level of Ordinary Skill in the Art .......................................................... 11

B. "wherein two or more memory locations of the first set of memory locations are read by the permutation module different times from one another" ........................................................................................... 11

C. “Permutation module” ........................................................................... 12

D. “Combine” ............................................................................................. 12

E. “Index” ................................................................................................... 12

VI. A REASONABLE LIKELIHOOD EXISTS THAT THE CHALLENGED CLAIMS ARE UNPATENTABLE .............................................................. 13

A. Ground 1: The ‘833 Patent Claims 1, 2, 4, 6, 8, 9, 10, 11, 13 are anticipated by the MacKay Software. .................................................... 13


ii

B. Ground 2: The ‘833 Patent Claims 1, 2, 4, and 6 are obvious over the MacKay Software in view of Kernigan ................................................. 39

C. Ground 3: The ‘833 Patent Claims 1, 2, 4, 6, 8, 9, 10, 11, and 13 are Obvious Under 35 U.S.C. § 103 Over the ‘710 Patent in view of Hennessy ................................................................................................ 40

VII. CONCLUSION .............................................................................................. 60


iii

LIST OF EXHIBITS

1001 U.S. Patent No. 7,116,710 by Hui Jin, et. al. entitled “Serial Concatenation of Interleaved Convolutional Codes Forming Turbo-Like Codes.” (the “’710 Patent”)

1002 Prosecution History of the ’710 Patent







1009 U.S. Provisional Application Ser. No. 60/205,095 by Hui Jin, et. al. (the “’095 Provisional Application”)

1010 Declaration of Henry D. Pfister, Ph.D.

1011 D. Divsalar, H. Jin, and R. J. McEliece, “Coding Theorems for "Turbo-like" Codes.” Proc. 36th Allerton Conf. on Comm., Control and Computing, Allerton, Illinois, pp. 201-210, Sept. 1998 (“Divsalar”) (published no later than April 30, 1999 at the University of Texas library)

1012 B.J. Frey and D.J.C. MacKay, “Irregular Turbocodes.” from the 37th Allerton Conference (“Frey”) (published no later than October 8, 1999 at the website of D.J.C. MacKay)


iv

1013 E.K. Hall and S.G. Wilson, “Stream-Oriented Turbo Codes.” 48th IEEE Vehicular Technology Conference, pp. 71-76, 1998 (“Hall”) (published no later than June 23, 1998 at the Library of Congress)

1014 L. Ping, W. K. Leung, N. Phamdo, “Low Density Parity Check Codes with Semi-random Parity Check Matrix.” Electron. Letters, Vol. 35, No. 1, pp. 38-39, Jan. 7th, 1999 (“Ping”) (published no later than April 22, 1999 at the Library of Congress)

1015 M. Luby, M. Mitzenmacher, A. Shokrollah, D. Spielman, “Analysis of Low Density Codes and Improved Designs Using Irregular Graphs.” STOC ’98 Proceedings of the Thirtieth Annual ACM symposium on Theory of Computing, pp. 249-258, 1998 (“Luby”) (published no later than July 30, 1998 at the University of Washington)

1016 U.S. Patent No. 6,081,909 by Michael Luby, et. al. entitled “Irregularly Graphed Encoding Technique.” (“the Luby ’909 Patent”) (filed November 6, 1997 and issued June 27, 2000)

1017 F. R. Kschischang and B. J. Frey, “Iterative decoding of compound codes by probability propagation in graphical models.” IEEE Journal on Selected Areas in Communications, 16, 219-230. 1998. (“Kschischang”) (published no later than Febuary 23, 1998 at the Library of Congress)

1018 U.S. Patent No. 7,089,477 by Michael Divsalar, et. al. entitled “Interleaved Serial Concatenation Forming Turbo-Like Codes .” (“the ’477 Patent”)

1019 RA.c code (including RA.c, and supporting files)

1020 J.L. Hennessy and D.A. Patterson, Computer organization and design: the hardware/software interface. 1994. (“Hennessy”) (published no later than November 8, 1994 at the Library of Congress)

1021 Complaint, California Institute of Technology v. Hughes Communications, Inc. et. al., No. 13-CV-07245 (CACD)

1022 Amended Complaint, California Institute of Technology v. Hughes Communications, Inc. et. al., No. 13-CV-07245 (CACD)


v

1023 D. J. C. MacKay, S. T. Wilson, and M. C. Davey, “Comparison of Constructions of Irregular Gallager codes.” IEEE Trans. Commun., Vol. 47, No. 10, pp. 1449-1454, Oct. 1999 (“MacKay”) (published no later than December 3, 1999 at the Library of Congress)

1024 Corrected Claim Construction Order (D.I. 105)

1025 Joint Claim Construction and Prehearing Statement (D.I. 60)

1026 Reporter’s Transcript of Claims Construction and Motion Hearing of July 9, 2014

1027 U.S. Patent No. 4,623,999 by Patricia Patterson, entitled “Look-up Table Encoder for Linear Block Codes .” (“the ’999 Patent”) (issued November 18, 1986)

1028 Luby, Mitzenmacher, Shokrollahi, Spielman, and Stemann, “Practical loss-resilient codes” in STOC '97 Proceedings of the twenty-ninth annual ACM symposium on Theory of Computing, 1997

1029 Richardson, Shokrollahi, and Urbanke, “Design of Provably Good Low-Density Parity Check Codes”

1030 Bond, Hui, and Schmidt, “Constructing Low-Density Parity-Check Codes with Circulant Matrices” ITW 1999, Metsovo, Greece (June 27-July 1 1999).

1031 Viterbi and Viterbi, “New results on serial concatenated and accumulated-convolutional turbo code performance” in Annales Des Télécommunications 1999

1032 Benedetto, Divsalar, Montorsi, and Pollara, “Serial concatenation of interleaved codes: Performance analysis, design, and iterative decoding” in IEEE Transactions on Information Theory, Vol. 44 (3), 1998

1033 McEliece, MacKay, and Cheng “Turbo Decoding as an Instance of Pearl’s “Belief Propagation” Algorithm”, as published to http://wol.ra.phy.cam.ac.uk/mackay/, under the filename “BPTD.ps.gz” by August 14, 1997


vi

1034 B.J. Frey and D.J.C. MacKay, slide presentation entitled “Irregular Turbocodes” presented at the 1999 Allerton Conference held September 22-24, 1999 (Published Sept 22-24, 1999)

1035 B.J. Frey, slide presentation entitled “Irregular Turbocodes” presented at the 2000 ISIT conference, on June 25, 2000 (Published June 25, 2000)

1036 B.J. Frey, slide presentation entitled “Irregular Turbocodes” presented at the Second International Symposium on Turbocodes and Related Topics in Brest, France in September 2000 (Published June 25, 2000)

1037 D.J.C. MacKay, slide presentation entitled “Gallagher Codes-Recent” presented at the 1999 IMA Summer Program at the University of Minnesota in Minneapolis, Minnesota (Published Aug. 3-5, 1999)

1038 Wayback Machine capture of the May 7, 1999 contents of http://wol.ra.phy.cam.ac.uk/mackay/README.html

1039 D. J. C. MacKay, S. T. Wilson, and M. C. Davey, “Comparison of Constructions of Irregular Gallager Codes” as published to http://wol.ra.phy.cam.ac.uk/mackay/, under the filename “ldpc-irreg.ps.gz” on July 30, 1998 (Published July 30, 1998)

1040 Screen capture of last-modified time information of MacKay website content

1041 D. J. C. MacKay, “Gallager codes — Recent Results” as published to http://wol.ra.phy.cam.ac.uk/mackay/, under the filename “sparsecodes.ps.gz” by July 16, 1999 (Published July 16, 1999)

1042 D.J.C. Mackay, Abstract “Gallager Codes — Recent Results” as published to http://vol.ra.phy.com.ac.wh/mackay/ under file name “sparsecodes0.ps.gz by June 2, 1999

1043 D. J. C. MacKay, “Gallager codes — Recent Results.” Proceedings of the International Symposium on Communication Theory and Applications, Ambleside, 1999, ed. by M. D. B. Honary and P. Farrell. Research Studies Press, 1999 (the “Ambleside Presentation”). (published no later than July 16, 1999 at the website of D.J.C. MacKay)


vii

1044 Portion of electronic log of D.J.C. MacKay dated July 16, 1999

1045 McEliese, et. al., slide presentation entitled “RA” presented at the Institute for Mathematics and its Applications conference on August 3, 1999.

1046 Screen capture of last modified dates of slides from https://www.ima.umn.edu/talks/workshops/aug2-13.99/mackay/mackay.html

1047 B.J. Frey and D.J.C. MacKay, “Irregular Turbocodes.” Proc. 37th Allerton Conf. on Comm., Control and Computing, Monticello, Illinois, Sep. 1999 (published no later than May 11, 2000 at the British Library Boston Spa)

1048 B.J.Frey and D.J.C. MacKay, “Irregular Turbocodes” ISIT 2000 Conference, Sorrento, Italy June 25-30, 2000

1049 D.J.C. MacKay, R.J. McEliece, J-F.Cheng, “Turbo Decoding as an Instance of Pearl’s ‘Belief Propagation’ Algorithm” as appearing on the MacKay websites as of May 7, 1999

1050 D.J.C. MacKay, “Encyclopedia of Sparse Graph Codes” as it appeared on the MacKay websites as of May 7, 1999

1051 D.J.C. MacKay, “Low Density Parity Check Codes over GF(q)” as it appeared on the MacKay websites as of May 7, 1999

1052 D.J.C. MacKay, “Decoding Times of Irregular Gallager Codes” as it appeared on the MacKay websites as of May 7, 1999

1053 D.J.C. MacKay, “Good Error-Correcting Codes Based on Very Sparse Matrices” as it appeared on the MacKay websites as of May 7, 1999

1054 D.J.C. MacKay, “Decoding Times of Repeat-Accumulate Codes” as it appeared on the MacKay websites as of May 7, 1999

1055 B.J. Frey, D.J.C. MacKay, “Trellis-Constrained Codes” as it appeared on the MacKay websites as of May 7, 1999


viii

1056 D.J.C. MacKay, “Turbo Codes are Low Density Parity Check Codes” as it appeared on the MacKay websites as of May 7, 1999

1057 H. D. Pfister and P. H. Siegel, “The serial concatenation of rate-1 codes through uniform random interleavers.” Proc. 37th Allerton Conf. on Comm., Control and Computing, Monticello, Illinois, pp. 260-269, Sep. 1999 (“Pfister”) (published no later than May 11, 2000 at the British Library Boston Spa)

1058 R. J. McEliece, “Repeat-Accumulate Codes [A Class of Turbo-like Codes that we can analyse].” 1999 Summer Program: Codes, Systems, and Graphical Models, University of Minnesota, Institute for Mathematics and its Applications, Aug. 2-13, 1999 (the “IMA Presentation”).

1059 Declaration of Brendan J. Frey

1060 Declaration of David J.C. Mackay

1061 C. Berrou, A. Glavieux, and P. Thitimajshima, “Near Shannon Limit Error Correcting Coding and Decoding.” IEEE International Conference on Communications, ICC '93 Geneva. Technical Program, Conference Record, (1993)

1062 MacKay and Neal, “Near Shannon Limit Performance of Low Density Parity Check Codes.” Electronic Letters(August 29, 1996)

1063 S. Benedetto , G. Montorsi, “Unveiling Turbo Codes: Some Results on Parallel Concatenated Coding Schemes.” IEEE Transactions on Information Theory, vol. 42, no. 2 (March 1996)

1064 Declaration of Robin Fradenburgh Concerning the “Proceedings, 36th Allerton Conference on Communications, Control, and Computing” Reference

1065 Wayback Machine capture of the December 9, 2006 contents of http://wol.ra.phy.cam.ac.uk/mackay/SourceC.html

1066 E-mail from Paul Siegel to Henry D. Pfister


ix

1067 B.W. Kernighan and D.M. Ritchie, The C Programming Language, 1988 (“Kernighan”).

1068 Declaration of Stephen B. Wicker in Support of Caltech’s Opposition to Defendants’’ Motion for Summary Judgment of Invalidity under 35 U.S.C. § 101 (DI 130-10)

1069 Statement of Genuine Disputes in Support of Caltech’s Opposition to Defendants’ Motion for Summary Judgment of Invalidity under 35 U.S.C. § 101 (DI 130-1)


1

I. MANDATORY NOTICES, STANDING, AND FEES

Real Party in Interest: Hughes Network Systems, LLC and Hughes

Communications, Inc. (“Petitioner” or “Hughes”) are the real parties in interest.

Hughes is a provider of broadband satellite services. EchoStar Corporation is the

parent of Hughes Satellite Systems Corporation, which is the parent of Hughes

Communications, Inc.

Related Matters: The ’833 Patent is currently involved in a pending lawsuit

entitled California Institute of Technology v. Hughes Communications, Inc. et. al.,

No. 13-CV-07245 (CACD) (the “Lawsuit”). See Ex. 1015. The Lawsuit

includes the following patents: (i) U.S. Patent No. 7,116,710; (ii) U.S. Patent No.

7,421,032; (iii) U.S. Patent No. 7,916,781; and (iv) U.S. Patent No. 8,284,833.

The complaint was filed on October 1, 2013 and waiver of service was filed on

November 12, 2013. Petitioner previously filed petitions for Inter Partes review

for the patents identified above, including another petition for U.S. Patent No.

8,284,833 on other grounds.

Lead Counsel and Request for Authorization: Pursuant to 37 C.F.R.

§§ 42.8(b)(3) and 42.10(a), Petitioner designates the following: Lead Counsel is

Eliot D. Williams (Reg. No. 50,822) of Baker Botts L.L.P.; Back-up Counsel is G.

Hopkins Guy (Reg. No. 35,886) of Baker Botts L.L.P.

Service Information: Service information is as follows: Baker Botts L.L.P.,


2

1001 Page Mill Rd., Palo Alto, CA 94304-1007 Tel. 650 739 7500; Fax 650-736-

7699. Petitioner consents to service by electronic mail at

[email protected] and [email protected]. A Power of

Attorney is filed concurrently herewith under 37 C.F.R. § 42.10(b).

Certification of Grounds for Standing: Petitioner certifies under 37 C.F.R.

§ 42.104(a) that the ’833 Patent is available for inter partes review and that

Petitioner is not barred or estopped from requesting inter partes review on the

grounds set forth herein.

Fees: The Office is authorized to charge the fee set forth in 37 C.F.R.

§ 42.15(a) to Deposit Account No. 02-0384 as well as any additional fees that

might be due in connection with this Petition.

II. OVERVIEW OF CHALLENGE AND RELIEF REQUESTED

Petitioner challenges claims 1, 2, 4, 6, 8, 9, 10, 11, 13 of U.S. Patent No.

8,284,833 by Hui Jin, et. al. (“the ’833 Patent”), titled “Serial Concatenation of

Interleaved Convolutional Codes Forming Turbo-Like Codes.” See Ex. 1007.

A. Publications Relied Upon

Petitioner relies upon the following patents and publications:

Exhibit 1019 - Various computer code for the program “RA.c” published to

the website of David J.C. MacKay by David J.C. MacKay, (“the MacKay

Software”) at least by December 6, 2006 and available as prior art under 35 U.S.C.


3

§ 102(b). See Ex. 1060 at ¶¶ 77, 83. The MacKay Software is available as prior

art because the ‘833 Patent is not entitled to its claimed priority date. See section

III.C, infra.

Exhibit 1001 - U.S. Patent No. 7,116,710 by Hui Jin, et. al. entitled “Serial

Concatenation of Interleaved Convolutional Codes Forming Turbo-Like Codes.”

(the “’710 Patent”) and available as prior art under 35 U.S.C. § 102(b). The ‘710

Patent is available as prior art because the ‘833 Patent is not entitled to its claimed

priority date. See section III.C, infra.

Exhibit 1020 - Computer Organization & Design The Hardware / Software

Interface by J. Hennessy and D. Patterson (“Hennessy”), published in 1994 and

available as prior art under 102(b).

Exhibit 1067 - The C Programming Language by B.W. Kernighan and D.M.

Ritchie (“Kernighan”), published in 1988 and available as prior art under 102(b).

B. Grounds For Challenge

Petitioner requests cancellation of the claims on the following grounds:

1. Claims 1, 2, 4, 6, 8, 9, 10, 11, 13 are anticipated by the MacKay

Software.

2. Claims 1, 2, 4, and 6 are obvious over the MacKay Software in

view of Kernighan.


4

3. Claims 1, 2, 4, 6, 8, 9, 10, 11, 13 are obvious over the ’710 Patent

in view of Hennessy.

III. OVERVIEW OF THE ’833 PATENT

A. Summary of the Claimed Subject Matter

The ’833 Patent relates to regular and irregular repeat accumulate (“RA”)

coding for transmission of communication signals. Claims 1 and 8 describe

encoding of information bits stored in a first set of memory locations, combining a

read bit with a parity bit in a second set of memory locations, and accumulating the

bits in the second set of memory locations. Claims 2, 4, 6, 9, 10, 11, and 13

describe additional details about the encoding steps.

B. Prosecution History of the ’833 Patent

The application resulting in the ’833 Patent was filed on March 28, 2011 and

purports to be a continuation of application No. 12/165,606 filed on June 30, 2008,

now U.S. Patent No. 7,916,781, which is a continuation of application No.

11/542,950, filed on Oct. 3, 2006, now U.S. Patent No. 7,421,032, which is a

continuation of U.S. Application No. 09/861,102, filed on May 18, 2001, now U.S.

Patent No. 7,116,710, and is also a continuation-in-part of U.S. Application No.

09/922,852, filed on Aug. 18, 2000, now Pat. No. 7,089,477. U.S. Application

No. 09/861,102 claims priority to U.S. Provisional Application Serial No.

60/205,095, filed on May 18, 2000. Ex. 1007.


5

The application was filed with claims 1-14 pending. Ex. 1008 at 16-18.

The patent examiner allowed the claims seven months later Oct. 27, 2011. Id. at

72. The patent holder then requested continued examination to further consider

the references cited in an information disclosure statement. Id. at 101-122. The

patent examiner allowed the claims again on Feb. 6, 2012. Id. at 145. The

patent holder then attempted to amend claims 1 and 8. Id. at 156-161. The patent

examiner rejected the amendments as changing the scope of the claims. Id. at 166-

167. In response, the patent holder filed a request for continued examination, to

which the patent examiner allowed the claims. Id. at 168-177; 201.

C. Effective Date of the ’833 Patent

Review of the specifications and file wrappers of the ‘710, ‘032, ‘781, ‘833,

and ‘477 patents and the provisional application to which the ‘710, ‘032, ‘781, and

‘833 patents claim priority (serial number 60/205,095) illustrates that the claims of

the ‘833 patent are the first written description of the claim limitations of

independent claim 1 and 8. Ex. 1010 at ¶ 42. For example, the patent

specifications and provisional application do not include any disclosure of memory

locations or indexes. Id. Moreover, the claim elements that are missing in the

original disclosure are precisely the elements Patent Owner has relied upon in the

Litigation in response to the defendants’ motion for summary judgment of

invalidity under 35 U.S.C. § 101. See Ex. 1068 (Declaration of Patent Owner’s


6

expert, Dr. Wicker) at ¶ 148 (“[‘833 Claim 1] describes how the permutations are

performed (i.e., based on the indices of the memory locations)” and its therefore

“not generic”). See also Ex. 1069, Fact 78 (Patent Owner’s admission that a

memory locations and indexes of the claims are combined in a novel way, and are

not conventional). Thus by Patent Owner’s own admissions, these elements that

are missing in the ‘710 disclosure are important to the purported patentability of

the claims.

In order to claim the earlier priority of the previously-filed applications, “the

prior application must satisfy ‘the disclosure requirements of the first paragraph of

§ 112. . .with respect to the subject matter now claimed.’” In re Smith, 458 F.2d

1389, 1394 (C.C.P.A. 1972) (citing Martin v. Johnson, 454 F.2d 746 (CCPA 1972);

In re Brower, 433 F.2d 813 (CCPA 1970)) (emphasis in original). It is not

enough that the claim would be obvious from the earlier application, that

application itself must describe the invention. PowerOasis, Inc. v. T-Mobile USA,

Inc., 522 F.3d 1299, 1305-07 (Fed. Cir. 2008). Because these elements are missing

in the earlier applications, the earliest priority date that the claims of the ‘833

patent are entitled is March 28, 2011, the date those claims were first filed. Id.

IV. SUMMARY OF PRIOR ART

A. State of the Art

The ’833 Patent relates to error detection and correction codes used in


7

encoding information before transmission as a communication signal over a

communication channel. Ex. 1010 at ¶ 34. During transmission, information

contained in communication signals may be affected by channel noise, leading to

potential errors in the information when received at the receiver. Ex. 1010 at ¶¶ 16-

23. Accordingly, various coding techniques were used in the art to generate

parity bits, which are then combined with the information bits into a codeword that

is sent in the communication signal. Id. The recipient of the codeword uses the

parity bits to check the integrity of the information bits and perform subsequent

remedial action in order to recover the transmitted information. Id. at ¶¶ 16-21.

One prior art technique for generating parity information based on bipartite

graphs was known as low density parity check (“LDPC”) codes, and were first

introduced by Robert G. Gallager in 1963 and refined by David J.C. MacKay. Ex.

1010 at ¶ 26. Another technique, known as repeat/accumulate (“RA”) encoding,

was published by two of the three inventors of the ‘833 Patent in September 1998,

more than one year before the earliest (albeit defective) priority claim of the ‘833

Patent. Ex. 1010 at ¶ 32; Ex. 1011. Turbo codes were also known in the prior

art. Ex. 1010 at ¶ 24. One paper, which Patent Owner has attached to and

quoted from in its parallel district court complaint, classified LDPC codes, RA

codes, and turbo codes as members of the field of “random-like codes.” Ex. 1022

at ¶ 24 & at p. 88 (hereinafter, the “Roumy paper”).


8

It was also known that making a coding technique “irregular,” wherein

different message bits contribute to different numbers of parity bits, would

improve performance of coding techniques. Ex. 1010 at ¶¶ 28-29, 33. For

instance, by 1998 Michael Luby and others showed that codes based on regular

graphs could not “give rise to codes that are close to optimal.” Ex. 1028 at 9.

Instead, Luby et al. showed that making codes irregular yields “much better

performance than regular” codes. Ex. 1010. at ¶ 28; Ex. 1015 at 249; Ex. 1028 at

9. See also Ex. 1010 at ¶¶ 28-29; Ex. 1029 at 621. In August 1999, Dr. David

MacKay presented a talk at the IMA academic conference on sparse graph codes,

in the speaking slot directly before one of the named inventors of the ‘833 patent

(McEliece). Ex. 1037 at p. 3. In his presentation, Dr. MacKay showed on one

page a graph of a Gallager code, a Repeat-accumulate code, a turbo code, and a

recursive convolutional code. Id. at 42. On the very next slide, the suggestion

“make irregular” appears as the second bullet under the heading “Where to go from

Regular Gallagher Codes.” Id. at 43. The immediate juxtaposition of these sparse

graph codes, which includes a repeat-accumulate code, with a suggestion to “make

irregular,” demonstrates that a person of ordinary skill in the art would recognize

that irregularity would improve a repeat-accumulate code. Ex. 1010 at ¶ 32.

Finally, as discussed below, the ‘710 Patent, which shares a specification with

the ’833 Patent, was published in 2006 and is prior art under 102(b). That patent


9

discloses irregular RA codes. Thus, the prior art provided motivation to use

irregularity in coding to improve performance. Ex. 1010 at ¶ 33.

B. Summary of References Relied Upon

The MacKay Software (Exhibit 1019)

The MacKay Software includes a computer program file entitled “RA.c” and

other supporting computer program files, all included within Exhibit 1019. The

MacKay Software was made available as a group of source code files in an archive

named “code.tar.gz” on Dr. MacKay’s website at least as early as December 6,

2006. Ex. 1060 at ¶¶ 77, 83. The “RA” stands for “repeat-accumulate.” Ex.

1060 at ¶ 77. MacKay used the software to create, simulate, and compare the

performance of RA codes of different block lengths. Id. The simulation results

of its use were published in, for example, papers in Exhibits 1041 and 1045. Id.

The MacKay Software could simulate regular and irregular RA codes. Id. at ¶ 79.

The comments contained in the MacKay Software explicitly taught and permitted

an arbitrary number of repetitions for each of its input bits. Id. Thus, the

MacKay Software discloses making an arbitrary number of repeats per bit to make

the code irregular. Id. at ¶ 80. The operation of the MacKay Software made it

clear that information and parity bits were stored in memory locations indexed and

accessible by addressing, and was run by a computer. Id. at ¶ 82.

The ‘710 Patent (Exhibit 1001)


10

The ‘833 Patent is incorrectly identified as a series of continuation

applications to the ‘710 Patent. See section III.C, supra. The specification of

the ‘710 Patent is substantively identical to the specification of the ‘833 Patent.

The ‘710 Patent’s specification, at minimum, does not disclose reading of memory

locations or indexes as the claims of the ‘833 Patent require. Ex. 1010 at ¶ 126.

Hennessy (Exhibit 1020)

The Hennessy reference is a computer science textbook that describes basic

computer functionality, including the use of memory locations and indexes to those

locations to carry out computations. Ex. 1020.

Kernighan (Exhibit 1067)

Kernighan is a textbook describing the operation of the C programming

language for operation on a variety of computers. Ex. 1067.

V. CLAIM CONSTRUCTION

Claims 1, 4, 6, 15, 16, 20, and 22 of the ’833 Patent are unpatentable when

given their “broadest reasonable construction in light of the specification.” See

37 C.F.R. § 42.100(b).1 Consistent with the broadest reasonable standard, claim

1 Petitioner reserves the right to seek different claim constructions than those

determined by the Board or sought herein in a different forum (e.g., District Court)

that applies different standards of proof and analysis.


11

terms “are generally given their ordinary and customary meaning,” as understood

by “a person of ordinary skill in the art in question at the time of the invention.”

Phillips v. AWH Corp., 415 F.3d 1303, 1312-13 (Fed. Cir. 2005). The claim

terms of the ’833 Patent should be given their plain and ordinary meaning under

the “broadest reasonable construction” with the considerations discussed infra.

A. Level of Ordinary Skill in the Art

A person of ordinary skill in the art would have a very high skill level, and

would have a Ph.D. in electrical or computer engineering with emphasis in signal

processing, communications, or coding, or a master’s degree in the above area with

at least three years of work experience in this field at the time of the alleged

invention. Ex. 1010 at ¶ 46. The patent owner has accepted this level of skill in

the Lawsuit. Ex. 1026 at 98.

B. "wherein two or more memory locations of the first set of

memory locations are read by the permutation module different times

from one another"

The term appears in claims 1 and 8 of the ‘833 patent. In the District Court

Action, the parties agreed that this means: “where two or more memory locations

of the first set of memory locations are read by the permutation module a different

number of times from one another.” Ex. 1025 at 1. This agreed definition is

within the broadest reasonable interpretation of “wherein two or more memory

locations of the first set of memory locations are read by the permutation module


12

different times from one another.” Ex. 1010 at ¶ 48. Additionally, an

interpretation of “a first memory location in the first set of memory locations is

read at a different time from a second memory location in the first set of memory

locations” is within the broadest reasonable construction. Id.

C. “Permutation module”

This term appears in claims 1, 2, 3, 6, and 8. In the District Court Action,

the parties agreed that the term “permutation module” should be construed as “a

module that changes the order of data.” Ex. 1025 at 1. This is within the

broadest reasonable interpretation of “permutation module.” Ex. 1010 at ¶¶ 49-50.

D. “Combine”

This term appears in claims 1, 2, 3, 8, 9, and 10. In the District Court Action,

the court ruled that the construction of “combine” is “perform logical operations

on.” Ex. 1024 at 18-19. The court’s construction is within the broadest

reasonable interpretation of “combine.” Ex. 1010 at ¶¶ 51-52.

E. “Index”

This term appears in claims 1, 4, 6, 8, 10, 11 and 13. The specification of the

‘833 patent does not mention an “index.” A person of ordinary skill at the time of

the alleged invention would consider “a data item that identifies a particular

element in a set of items,” to be within the broadest reasonable interpretation of the

clamed “index.” Ex. 1010 at ¶ 53.


13

VI. A REASONABLE LIKELIHOOD EXISTS THAT THE

CHALLENGED CLAIMS ARE UNPATENTABLE

Pursuant to 37 C.F.R. § 42.104(b)(4)-(5), all of the challenged claims are

unpatentable for the reasons set forth in detail below.

A. Ground 1: The ‘833 Patent Claims 1, 2, 4, 6, 8, 9, 10, 11, 13 are

anticipated by the MacKay Software.

As demonstrated below, each and every element of claims 1, 2, 4, 6, 8, 9, 10,

11, 13 is disclosed by the MacKay Software. Thus, the MacKay Software

anticipates these claims.

‘833 Claim 1 The MacKay Software 1[p] 1. An apparatus for performing encoding operations,

See, e.g., Ex. 1019 at p. 17, lines 4-5 : “I want a structure to define the code which is given to an encoder or a decoder.”

See, e.g., Ex. 1019 at p. 1, line 5 : “Repeat-accumulate code simualtor”

See, e.g., Ex. 1019 at p.5, lines 231-233: “ int RA_encode ( unsigned char *d , RA_control *c , unsigned char *t ) { int n , k ; int status = 0 ; alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'”

See, e.g., Ex. 1060 at ¶ 82 (discussing Ex. 1019) “The operation of the RA.c code makes it clear that the information and parity bits are stored in memory locations that are indexed and accessible by addressing as is typical of any executable C code on a general purpose computer. The RA.c code could be executed on any personal computer with a C code compiler. I typically ran the C code on a personal


14

‘833 Claim 1 The MacKay Software computer myself.”

The MacKay Software is used by compiling the source code and executing

the compiled source code on a computer. Ex. 1010 at ¶ 56. The computer

executing the MacKay Software meets the broadest reasonable interpretation of

this preamble. Id. Patent Owner’s expert has admitted that a computer is

necessary to perform the encoding operations taught in the claims. Ex. 1068 ¶ 42.

‘833 Claim 1 The MacKay Software 1[a] the apparatus comprising: a first set of memory locations to store information bits;

See, e.g., Ex.1019 at p.3, lines 126-129: “printf ( "source vector:\n" ) ;

for ( k = 1 ; k <= c.K ; k ++ ) { if ( c.s[k] ) printf ("1 ") ; else printf ( "0 " );

}”

See, e.g., Ex. 1019 at p.3, line 132: “RA_encode ( c.s , &c , c.t ) ;”

See, e.g., Ex. 1019 at p.5, line 233: “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'

doubles as 's' */ “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'”

See, e.g., Ex. 1019 at p. 53, line 40: “unsigned char *cvector(int nl,int nh)”

See, e.g., Ex. 1019 at p.5, lines 244-246: “for ( n = 2 ; n <= c->N ; n ++ ) { t[n] = t[n]^t[n-1] ; }”

See, e.g., Ex. 1019 at p.12, line 599: “c->s = cvector ( 1 , c->K ) ;”


15

‘833 Claim 1 The MacKay Software See, e.g., Ex. 1019 at p.17, lines 22-23:

“unsigned char *s , *t ; /* data, (before reordered and repeated,)

transmitted */”

In the MacKay Software, the information bits are stored in a vector denoted

by “c.s.” Ex. 1019 at p. 5, lines 244-246; Ex. 1010 at ¶ 58. The variable “c” is a

data structure type defined as “RA_control.” As part of the definition for the

RA_control data structure, the source code comments that “c.s” is for “data, before

reordered and repeated.” Ex. 1019 at p. 17, line 22; Ex. 1010 at ¶ 58. This

vector is stored in memory that is allocated by the command “c->s = cvector ( 1 ,

c->K ) ;”. Ex. 1019 at p. 12, line 599; Ex. 1010 at ¶ 58. This line calls the

subroutine “cvector” which calls the standard C routine “malloc” to allocate

memory for the vector “c.s”. Ex. 1019 at p.53, line 44; Ex. 1010 at ¶ 58. A

person of ordinary skill in the art would know that the C “malloc” command is to

allocate memory locations for storage of a variable which is an array of

information bits. Ex. 1010 at ¶ 58. A person of ordinary skill in the art would

understand that a source vector is used to store information bits to an encoder. Ex.

1010 at ¶ 58. The allocated memory for “c.s” stores the information bits. Ex.

1010 at ¶ 58. The MacKay Software populates the “c.s” vector with a randomized

set of bits at line 123 of RA.c with the command “c.sourceweight =

random_cvector( c.s , c.fs , 1, c.K ) ;.” Ex. 1019 at p.3, line 123; Ex. 1010 at ¶ 58.


16

Thus, the RA.c source file of MacKay Software satisfies the broadest reasonable

interpretation of using “a first set of memory locations to store information bits.”.

Id.

‘833 Claim 1 The MacKay Software 1[b] a second set of memory locations to store parity bits;

See, e.g., Ex. 1019 at p.3, line 132: “RA_encode ( c.s , &c , c.t ) ;” See, e.g., Ex. 1019 at p.5, lines 231-233: “ int RA_encode ( unsigned char *d , RA_control *c , unsigned char *t ) { int n , k ; int status = 0 ; alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'”

See, e.g., Ex. 1019 at p. 12, line 600: “c->t = cvector ( 1 , c->N ) ;”


See, e.g., Ex. 1019 at pp. 25-26, lines 49-65: “void alist_transpose_cvector_sparse_mod2 ( alist_matrix *a , unsigned char *x , unsigned char *y ) {

int m , n , i ; int *mlist ; for ( n = 1 ; n <= a->N ; n++ ) { y[n] = 0 ; } for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; >= 1 ; i -- ) { y[ mlist[i] ] ^= 1 ; } }


17

‘833 Claim 1 The MacKay Software } }”

In the MacKay Software, the parity bits are also stored in a vector that is

denoted by “c.t”. Ex. 1010 at ¶ 59. That memory location is allocated by the

command “c->t = cvector ( 1 , c->N ) ;” on line 600 of RA.c. Ex. 1019 at p.12,

line 600. This line calls the subroutine “cvector” which calls the standard C

routine “malloc” to allocate memory lcoations for the vector “c.t.” Ex. 1019 at p.

53, line 40. Ex. 1010 ¶ 60.

The memory locations referenced by “c.t” store parity bits as demonstrated

by code at lines 132 and 233 of RA.c because the command “RA_encode ( c.s ,

&c , c.t );” passes “c.t” as the third argument to the “RA_encode” function, which

calls the function “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t )” on line

233 to generate the parity bits and store them in the vector “c.t.” Ex. 1019 at p.3,

line 13; p.5, line 233; Ex. 1010 at ¶ 60. The memory location allocated for c.t is

initially populated in RA_encode function by the call to

“alist_transpose_cvector_sparse_mod2 ( &c->a , d , t);” at line 233. Ex. 1019 at 5,

line 233; Ex. 1010 at ¶ 60. The results of that function are then accumulated-in-

place to generate the parity bits at the memory location allocated for c.t. Ex. 1019

at 5, line 244-246; Ex. 1010 at ¶ 60. The parity bits are therefore stored in the

memory locations allocated for c.t. Ex. 1010 at ¶ 60.


18

Thus, the MacKay Software satisfies the broadest reasonable

interpretation of using “a second set of memory locations to store parity bits.” Ex.

1010 at ¶ 61.

‘833 Claim 1 The MacKay Software 1[c] a permutation module to read a bit from the first set of memory locations and combine the read bit to a bit in the second set of memory locations based on a corresponding index of the first set of memory locations and a corresponding index of the second set of memory locations;

See, e.g., Ex. 1019 at p.3, line 132: “RA_encode ( c.s , &c , c.t ) ;” See, e.g., Ex. 1019 at p.5, lines 231-233: “ int RA_encode ( unsigned char *d , RA_control *c , unsigned char *t ) { int n , k ; int status = 0 ; alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'”

See, e.g., Ex. 1019 at pp. 25-26, lines 49-65.

“void alist_transpose_cvector_sparse_mod2 ( alist_matrix *a , unsigned char *x , unsigned char *y ) {

int m , n , i ; int *mlist ; for ( n = 1 ; n <= a->N ; n++ ) { y[n] = 0 ; } for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; >= 1 ; i -- ) { y[ mlist[i] ] ^= 1 ; } } } }”


19

‘833 Claim 1 The MacKay Software See, e.g, Ex. 1019 at p. 4, lines 215-218.

“Encoding method . . . source bits d[1] . . d[K] are mapped via an alist . . . into a pre-transmission vector . . . s[1]..s[N].”

See, e.g, Ex. 1019 at p. 4, line 233.

“alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't' doubles as 's' */”

The permutation module of the MacKay Software is invoked on line 233 of

RA.c by the function call “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ).”

Ex. 1019 at p.5, lines 244-246; Ex, 1010 at ¶ 62. This function implements a

transposed matrix-multiply between its first argument, the alist matrix “c->a”, and

its second argument, the information bit vector “d”. Ex. 1019 at pp. 25-26, lines

49-65; Ex. 1010 at ¶ 62. The alist matrix “c->a” is a data structure that stores data

representing indices into the first set of memory locations and indices into the

second set of memory locations. Ex. 1010 at ¶ 63. Lines 215-218 of RA.c state

“Encoding method . . . source bits d[1] . . d[K] are mapped via an alist . . . into a

pre-transmission vector . . . s[1]..s[N].” Ex. 1019 at p. 4, lines 215-218; Ex. 1010 at

¶ 63. The MacKay Software uses the same set of memory locations for the pre-

transmission vector “s” and the transmission vector “t.” Ex. 1010 at ¶ 63. At

line 233, the source code states “here ‘t’ doubles as ‘s’.” Ex. 1019 at p. 5, lines

233; Ex. 1010 at ¶ 63. The result of the operation is stored in its third argument,

the vector of binary elements, “t.” Id. The code for


20

“alist_transpose_cvector_sparse_mod2” shows that that lines 54-56 first zero out

the destination vector, whose local variable name is “y.” Id.; Ex. 1019 at p.25, lines

54-56. Next, in line 57 of cmatrix.c, a “for” loop iterates through each data

element in the input vector “x.” Ex. 1019 at pp.25-26, lines 57-65; Ex. 1010 at ¶ 63.

If the data element “x[m]” is 1, then the command “y[ mlist[i] ] ^= 1 ;” is executed.

Ex. 1019 at p. 26, line 61; Ex. 1010 at ¶ 63. Together, these commands therefore

perform exclusive OR operation on the value “x[m]” from the first set of memory

locations and “y[ mlist[i] ]” in the second set of memory locations. Ex. 1010 at

¶ 63. The value of mlist[i] is an index into the second set of memory locations.

Id. This portion of the code functions as a permutation module because the order

of the information bits is changed based on corresponding values in the alist data

structure. Ex. 1010 at ¶ 63. These operations satisfy the broadest reasonable

interpretation of “a permutation module to read a bit from the first set of memory

locations and combine the read bit to a bit in the second set of memory locations

based on a corresponding index of the first set of memory locations and a

corresponding index of the second set of memory locations.” Id.

‘833 Claim 1 The MacKay Software

1[d] and an accumulator to perform accumulation operations on the

See, e.g., Ex. 1019 at p. 5, lines 5, 244-253:

“for ( n = 2 ; n <= c->N ; n ++ ) { t[n] = t[n]^t[n-1] ; }


21

‘833 Claim 1 The MacKay Software bits stored in the second set of memory locations,

if ( c->verbose > 2) { printf ( "accumulated transmission:\n" ) ; for ( k = 1 ; k <= c->N ; k ++ ) { if ( t[k] ) printf ("1 ") ; else printf ( "0 " ); } printf ( "\n" ) ;”

This limitation is satisfied by the operation implemented on lines 244-246 of

“RA.c,” which is part of the RA_encode function, above. Ex. 1019 at p. 5, lines 5,

244-246; Ex. 1010 at ¶ 64. These commands compute the in-place sequential

cumulative sum (modulo 2) of the vector “t”, which is stored in the second set of

memory locations and contains the output of the permutation module. Ex. 1010

at ¶ 65. The vector “t” contains the sequence of bits to be accumulated. Id.

The operation “t[n] = t[n]^t[n-1]” on line 245 of “RA.c” instructs the computer to

perform an exclusive OR operation with the bit at “t[n]” and the bit at “t[n-1]” and

store the result (i.e., overwrite) in “t[n].” Id. The vector “t” contains the sequence

of bits to be accumulated. Id. The MacKay software further confirms that this

is an accumulate operation by the command on line 249 of RA.c that displays the

words “accumulated transmission” before displaying the contents of the “t” vector

as shown above. Ex. 1019 at p.5, lines 248-253. Ex. 1010 at ¶ 65. Thus, these

operations satisfy the broadest reasonable interpretation of “an accumulator to

perform accumulation operations on the bits stored in the second set of memory

locations. Ex. 1010 at ¶ 66.


22


1[e] wherein two or more memory locations of the first set of memory locations are read by the permutation module different times from one another.

See, e.g., Ex. 1019 at p.1, lines 16-17: “Use of alist allows arbitrary numbers of repetitions of each bit.”

See, e.g., Ex. 1019 at p.4, lines 216-217: “source bits d[1]..d[K] are mapped via an alist into a pre-transmission vector.”

See, e.g., Ex. 1019 at pp. 25-26, lines 57-65:

“for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; i >= 1 ; i -- ) { y[ mlist[i] ] ^= 1 ; } } }” See, e.g., Ex. 1060 at ¶¶ 79-81 (discussing Ex. 1019):

“My RA.c code could simulate either regular or irregular RA codes. RA.c explicitly allowed an arbitrary number of repetitions for each of the input bits. I noted this capability in the introduction to the software…The “Alist” file contained a list of variables setting the number of repetition for each bit….To make the RA code “regular,” a user had to intentionally enter the same repetition-number for each bit of the source block…a user is not constrained to repeat all bits the same number of times. By using an appropriate ‘alist’ a user can simulate an irregular repeat-accumulate structure or a regular one.”

The broadest reasonable interpretation of this claim includes the case where

two or more memory locations of the first set of memory locations are read by the

permutation module at different times. Ex. 1010 at ¶ 67. This requires that the

permutation module reads two different bits at different times. Id. The


23

permutation module of the MacKay Software output depends on all the input bits.

Id. Ex. 1019 at pp. 25-26, lines 57-58. Ex. 1010 at ¶ 67; Ex. 1019 at pp. 25-26,

lines 49-65. As part of the loop defined by “for (m=1 ; m <= a-M ; m++)” The

values of the source vector in input bits (x[m] at line 58) are read sequentially and

therefore at different times. Ex. 1019, at pp. 25-26, lines 49-65; Ex. 1010 ¶¶ 67-

68.

The RA.c file states that the number of input bits will be two or more with

the statement at lines 216-27 that “source bits d[1]..d[K] are mapped via an alist

into a pre-transmission vector.” Ex. 1019 at p.4, lines 216-217; Ex. 1010 at ¶ 68.

Thus, the MacKay Software satisfies the broadest reasonable interpretation of this

limitation. Ex. 1010 at ¶ 68.

If, however, the Board determines that this limitation should be construed as

“where two or more memory locations of the first set of memory locations are

read by the permutation module a different number of times from one another”,

then this limitation is also disclosed by the MacKay Software. Ex. 1010 at ¶ 69.

In particular, different values from the first set of memory locations (the

source vector c.s) are read a different number of times based on their

corresponding value of “a->mlist[m].” Ex. 1010 ¶ 69. The values of a->mlist[m]

can range from 1 to K. That is, the each bit in source vector c.s is repeated 1, 2, . . .,

or K times based on the corresponding value in “a->mlist[m].” Ex. 1010 ¶ 69.


24

This is identical to combining different bits from the first set of memory locations

a different number of times during the combination operation. Id. RA.c

discloses the use of irregular combination patterns on lines 16-18, which state that

“[u]se of alist allows arbitrary numbers of repetitions of each bit; K source block

length; n_1 n_2 ... n_K number of repetitions of each source bit.” Ex. 1019 at p.1,

lines 16-17. A person of ordinary skill in the art would understand the MacKay’s

Software’s “arbitrary numbers of repetitions of each bit” to be within the broadest

reasonable interpretation this element. Ex. 1010 at ¶ 69. This was also

recognized by the author of RA.c, as shown above. Ex. 1060 at ¶¶ 77-81.

‘833 Claim 2 The MacKay Software 2. The apparatus of claim 1, wherein the permutation module is configured to perform the combine operation to include performing mod-2 or exclusive OR sum.

See, e.g., Ex. 1019 at p. 5, line 233: “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'” See, e.g., Ex. 1019 at pp.25-26, lines 49-65: “void alist_transpose_cvector_sparse_mod2 ( alist_matrix *a , unsigned char *x , unsigned char *y ) { int m , n , i ; int *mlist ; for ( n = 1 ; n <= a->N ; n++ ) { y[n] = 0 ; } for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; i >= 1 ; i -- ) { y[ mlist[i] ] ^= 1 ; } }


25

‘833 Claim 2 The MacKay Software }

}”

See, e.g, Ex. 1019 at p. 4, lines 215-218.


See, e.g, Ex. 1019 at p. 4, line 233.


In the MacKay Software, the permutation module is invoked on line 233 of

RA.c by the function call “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ).”

Ex. 1019 at p.5, line 233. Ex. 1010 at ¶ 71. This function implements a

transposed matrix-multiply between its first argument (the alist matrix “c->a”), and

its second argument (the information bit vector “d”). Ex. 1019 at pp.25-26, lines

49-65. The alist matrix “c->a” is a data structure that stores data representing

indices into the first set of memory locations and indices into the second set of

memory locations. Ex. 1010 at ¶ 72. Line 57 of cmatrix.c iterates through each

data element in the input vector “x” and, if the data element “x[m]” is 1, then the

command “y[ mlist[i] ] ^= 1 ;” is executed. Ex. 1019 at p.26, line 61. Ex. 1010

at ¶72. These commands perform an exclusive OR operation on the value “x[m]”

from the first set of memory locations and “y[ mlist[i] ]” in the second set of


26

memory locations. Ex. 1010 at ¶72. The value of mlist[i] is an index into the

second set of memory locations. Id. The MacKay Software therefore meets the

broadest reasonable interpretation of “wherein the permutation module is

configured to perform the combine operation to include performing mod-2 or

exclusive OR sum.” Id.

‘833 Claim 4 The MacKay Software 4. The apparatus of claim 1, wherein the accumulator is configured to perform the accumulation operation to include a mod-2 or exclusive OR sum of the bit stored in a prior index to a bit stored in a current index based on a corresponding index of the second set of memory locations.

See, e.g., Ex. 1019 at p.5, lines 244-246:

“for ( n = 2 ; n <= c->N ; n ++ ) { t[n] = t[n]^t[n-1] ; }”

This limitation is satisfied by the operation implemented on lines 244-246 of

“RA.c,” which is part of the RA_encode function, shown above. Ex. 1010 at ¶ 74.

These commands compute the in-place sequential cumulative sum (modulo 2) of

the vector “t”, which is stored in the second set of memory locations and contains

the output of the permutation module. Ex. 1010 at ¶ 75. In particular, the

operation “t[n] = t[n]^t[n-1]” performs an exclusive or operation with the value

“t[n]” and the value “t[n-1]” and stores the result (i.e., overwrites the value) in


27

“t[n].” Ex. 1019 at p. 5, line 245. Ex. 1010 at ¶ 75; The vector “t” contains

the sequence of bits to be accumulated. Ex. 1010 at ¶ 75. The value t[n] is the

bit in the vector t at the current index (i.e.., n) and the value t[n-1] is the bit at the

prior index (i.e., n-1). Id. Both t[n] and t[n-1] are stored in the second set of

memory locations. Id. Thus, these operations satisfy the broadest reasonable

interpretation of “wherein the accumulator is configured to perform the

accumulation operation to include a mod-2 or exclusive OR sum of the bit stored

in a prior index to a bit stored in a current index based on a corresponding index of

the second set of memory locations.” Id. at ¶ 76.


6. The apparatus of claim 1, wherein the permutation module further comprises a permutation information module to generate pairs of an index of the first set of memory locations and an index of the second set of memory locations

See, e.g., Ex. 1019 at p. 5, line 233: “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'” See, e.g., Ex. 1019 at pp. 25-26, lines 49-65: “void alist_transpose_cvector_sparse_mod2 ( alist_matrix *a , unsigned char *x , unsigned char *y ) { int m , n , i ; int *mlist ; for ( n = 1 ; n <= a->N ; n++ ) { y[n] = 0 ; } for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; i >=1; i -- ) { y[ mlist[i] ] ^= 1 ; }


28

‘833 Claim 6 The MacKay Software } } }” See, e.g, Ex. 1019 at p. 4, lines 215-218.


See, e.g, Ex. 1019 at p. 4, line 233.


In the MacKay Software, the permutation module is invoked by the function

call “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ).” Ex. 1019 at p. 5,

line 233l Ex. 1010 at ¶ 79. This function implements a transposed matrix-

multiply between its first argument, the alist matrix “c->a”, and its second

argument, the information bit vector “d” as shown above. Ex. 1019 at pp. 25-26,

lines 49-65. Ex. 1010 at ¶ 79. The alist matrix “c->a” is a data structure that

stores data representing indices into the first set of memory locations and indices

into the second set of memory locations. Ex. 1010 at ¶ 80.

As part of the permutation process, the values of alist matrix are used to

generate pairs of index values to the first set of memory locations and second set of

memory locations as part of the set of for loops at lines 57-64 of cmatrix.c,

reproduced above (“for (m=1...”). Ex. 1010 at ¶ 80. The indexes to the first set

of memory locations is generated as part of the loop defined by “for ( m = 1 ; m <=


29

a->M ; m++ ),” at line 57. Ex. 1019 at p. 25, line 57; Ex. 1010 at ¶ 81. The

indexes for the second set of memory location is generated by the for loop defined

by “for ( i = a->num_mlist[m] ; i >= 1 ; i -- ),” on line 60. Ex. 1019 at p. 26, line 60;

Ex. 1010 at ¶ 81. This is therefore within the broadest reasonable interpretation

of “wherein the permutation module further comprises a permutation information

module to generate pairs of an index of the first set of memory locations and an

index of the second set of memory locations.” Id.

‘833 Claim 8 The MacKay Software 8[p] A method of performing encoding operations,

See, e.g., Ex. 1019 at p.1, line 5: “Repeat-accumulate code simulator”.

See, e.g., Ex. 1019 at p. 5, lines 231-235:

“int RA_encode ( unsigned char *d , RA_control *c , unsigned char *t ) {

int n , k ; int status = 0 ;

alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't' doubles as 's' */

/* accumulate */”


the compiled source code on a computer. The MacKay Software defines a

computerized process for performing encoding operations. The software is a

“[r]epeat-accumulate code simulator.” Ex. 1019 at p.1, line 5; Ex. 1010 at ¶ 84.


30

The RA.c file includes a function named “RA_encode” that performs a repeat

accumulate encoding operation. Ex. 1019 at p.5, lines 231-235; Ex. 1010 at ¶ 84.

‘833 Claim 8 The MacKay Software 8[a] the method comprising: receiving a sequence of information bits from a first set of memory locations

See, e.g., Ex.1019 at p.3, lines 126-129: “printf ( "source vector:\n" ) ;

for ( k = 1 ; k <= c.K ; k ++ ) { if ( c.s[k] ) printf ("1 ") ; else printf ( "0 " );

}”

See, e.g., Ex. 1019 at p.3, line 132: “RA_encode ( c.s , &c , c.t ) ;”

See, e.g., Ex. 1019 at p.5, line 233: “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'

doubles as 's' */ “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'”


See, e.g., Ex. 1019 at p.5, lines 244-246: “for ( n = 2 ; n <= c->N ; n ++ ) { t[n] = t[n]^t[n-1] ; }”

See, e.g., Ex. 1019 at p.12, line 599: “c->s = cvector ( 1 , c->K ) ;”

See, .eg., Ex. 1019 at p. 17, lines 22-33:

“unsigned char *s , *t ; /* data, (before reordered and repeated,) transmitted */”

In the MacKay Software, the information bits are stored in a vector denoted

by “c.s.” Ex. 1019 at p. 5, lines 244-246; Ex. 1010 at ¶ 85. The source code

comments indicate that “c.s” is for “data, before reordered and repeated.” Ex. 1019


31

at p. 17, line 22; Ex. 1010 at ¶ 85. This vector is stored in memory that is allocated

by the command “c->s = cvector ( 1 , c->K ) ;” which calls the subroutine

“cvector,” which in turn calls the standard C routine “malloc” to allocate memory

for the vector “c.s”. Ex. 1019 at p.53, line 44; Ex. 1010 at ¶ 85. A person of

ordinary skill in the art would know that the C “malloc” command is to allocate

memory for storage of a variable. Ex. 1010 at ¶ 85. A person of ordinary skill

in the art would understand that a source vector is used to store information bits to

an encoder. Ex. 1010 at ¶ 85. At line 132 of RA.c, the command “RA_encode

( c.s , &c , c.t ) ;” calls the RA_encode function and passes the vector c.s as the

first parameter. Ex. 1019 at p.3, line 132. At line 233 of RA.c, the RA_encode

function receives the c.s vector. This is within the broadest reasonable

interpretation of “receiving a sequence of information bits from a first set of

memory locations.” Ex. 1010 at ¶ 86.


8 [b] performing an encoding operation using the received sequence of information bits as an input,

8[c] said encoding operation comprising: reading a bit from the received

See element 1[c] above.

Ex. 1019 at p.12, line 600: “c->t = cvector ( 1 , c->N ) ;”

Ex. 1019 at p. 53, line 40: ““unsigned char *cvector(int nl,int nh)”

Ex. 1019 at p.53, line 44: “v=(unsigned char *)malloc((unsigned) (nh-nl+1)*sizeof(unsigned char));”

Ex. 1019 at p. 3, line 132: “RA_encode ( c.s , &c , c.t ) ;”

Ex. 1019 at p.5, line 231-233:

“int RA_encode ( unsigned char *d , RA_control *c , unsigned char *t ) {


32

‘833 Claim 8 The MacKay Software sequence of information bits, and combining the read bit to a bit in a second set of memory locations based on a corresponding index of the first set of memory locations for the received sequence of information bits and a corresponding index of the second set of memory locations;

int n , k ; int status = 0 ; alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'

doubles as 's' */ “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'” Ex. 1019 at pp. 25-26, lines 49-65: “void alist_transpose_cvector_sparse_mod2 ( alist_matrix *a , unsigned char *x , unsigned char *y ) { int m , n , i ; int *mlist ; for ( n = 1 ; n <= a->N ; n++ ) { y[n] = 0 ; } for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; i >=1; i -- ) { y[ mlist[i] ] ^= 1 ; } } } }”

As explained above with respect to the permutation module of element 1[c],

the MacKay Software dislcoses this functionality. Ex. 1010 at ¶¶ 139-142.


8[d] and accumulating the bits in the second set of memory locations,

See, e.g., Ex. 1019 at p. 5, lines 5, 244-253:

“for ( n = 2 ; n <= c->N ; n ++ ) { t[n] = t[n]^t[n-1] ; }

if ( c->verbose > 2) { printf ( "accumulated transmission:\n" ) ;


33

‘833 Claim 8 The MacKay Software for ( k = 1 ; k <= c->N ; k ++ ) { if ( t[k] ) printf ("1 ") ; else printf ( "0 " ); } printf ( "\n" ) ;”

This limitation is satisfied by the operation implemented in the RA_encode

function, shown in the chart above. Ex. 1019 at ¶ 93. These commands compute

the in-place sequential cumulative sum (modulo 2) of the vector “t”, which is

stored in the second set of memory locations. Ex. 1019 at ¶ 94. The vector “t”

contains the sequence of bits to be accumulated. Id. The operation “t[n] =

t[n]^t[n-1]” instructs the computer to perform an exclusive OR operation with the

bit at “t[n]” and the bit at “t[n-1]” and store the result (i.e., overwrite the value) in

“t[n].” Id. The vector “t” contains the sequence of bits to be accumulated. Id.

The MacKay software further confirms that this is an accumulate operation by

displaying the words “accumulated transmission” before displaying the contents of

the “t” vector. Id.



See, e.g., Ex. 1019 at p.1, lines 16-17: “Use of alist allows arbitrary numbers of repetitions of each bit.”

See, e.g., Ex. 1019 at p.4, lines 216-217: “source bits d[1]..d[K] are mapped via an alist. . .into a pre-transmission vector.”

See, e.g., Ex. 1019 at pp. 25-26, lines 49-65:

“void alist_transpose_cvector_sparse_mod2 ( alist_matrix *a , unsigned char *x , unsigned char *y ) {


34

‘833 Claim 8 The MacKay Software int m , n , i ; int *mlist ; for ( n = 1 ; n <= a->N ; n++ ) { y[n] = 0 ; } for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; i >=1; i -- ) { y[ mlist[i] ] ^= 1 ; } } } }”

See, e.g., Ex. 1060 at ¶¶ 79-81 (discussing Ex. 1019):

“My RA.c code could simulate either regular or irregular RA codes. RA.c explicitly allowed an arbitrary number of repetitions for each of the input bits. I noted this capability in the introduction to the software…The “Alist” file contained a list of variables setting the number of repetition for each bit….To make the RA code “regular,” a user had to intentionally enter the same repetition-number for each bit of the source block…a user is not constrained to repeat all bits the same number of times. By using an appropriate ‘alist’ a user can simulate an irregular repeat-accumulate structure or a regular one.”

The broadest reasonable interpretation of this claim includes the case where

two or more memory locations of the first set of memory locations are read by the

permutation module at different times. Ex. 1010 at ¶ 67. This requires that the

permutation module read two different bits at different times. Id. The

permutation module of the MacKay Software output depends on all the input bits.


35

Id. Ex. 1019 at pp. 25-26, lines 57-58. Ex. 1010 at ¶ 67; Ex. 1019 at pp. 25-26,

lines 49-65. As part of the loop defined by “for (m=1 ; m <= a-M ; m++)” The

values of the source vector in input bits (x[m] at line 58) are read sequentially and

therefore at different times. Ex. 1019, at pp. 25-26, lines 49-65; Ex. 1010 ¶¶ 67-

68.

The RA.c file states that the number of input bits will be two or more with

the statement at lines 216-27 that “source bits d[1]..d[K] are mapped via an alist

into a pre-transmission vector.” Ex. 1019 at p.4, lines 216-217; Ex. 1010 at ¶ 68.

Thus, the MacKay Software satisfies the broadest reasonable interpretation of this

limitation. Ex. 1010 at ¶ 68.

If, however, the Board determines that this limitation should be construed as

“where two or more memory locations of the first set of memory locations are

read by the permutation module a different number of times from one another”,

then this limitation is also disclosed by the MacKay Software. Ex. 1010 at ¶ 69.

In particular, different values from the first set of memory locations (the

source vector c.s) are read a different number of based on a corresponding

value of “a->mlist[m].” Ex. 1010 ¶ 69. The values of a->mlist[m] can range

from 1 to K. That is, the each bit in source vector c.s is repeated 1, 2, . . ., or K

times based on the corresponding value in “a->mlist[m].” Ex. 1010 ¶ 69. This is

identical to combining different bits from the first set of memory locations a


36

different number of times during the combination operation. Id. RA.c discloses

the use of irregular combination patterns on lines 16-18, which state that “[u]se of

alist allows arbitrary numbers of repetitions of each bit; K source block length; n_1

n_2 ... n_K number of repetitions of each source bit.” Ex. 1019 at p.1, lines 16-17.

A person of ordinary skill in the art would understand the MacKay’s Software’s

“arbitrary numbers of repetitions of each bit” to be within the broadest reasonable

interpretation this element. Ex. 1010 at ¶ 69. This was also recognized by the

author of RA.c, as shown above. Ex. 1060 at ¶¶ 77-81.

‘833 Claim 9 The MacKay Software 9. The method of claim 8, wherein performing the combine operation comprises performing mod-2 or exclusive OR sum.

See claim 2, above.

See, e.g., Ex. 1019 at p.5, line 233; pp.25-26, lines 49-65.

The MacKay Software discloses all limitations of Claim 9, as discussed

above within the context of Claim 2. Ex. 1010 at ¶¶ 99-101.

‘833 Claim 10 The MacKay Software 10. The method of claim 9, wherein performing the combine operation comprises writing the sum to the second set of memory locations based on a corresponding index.

See, e.g., Ex. 1019 at p.5, line 233: “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ) ; /* here 't'” See, e.g., Ex. 1019 at pp. 25-26, lines 49-65. “void alist_transpose_cvector_sparse_mod2 ( alist_matrix *a , unsigned char *x , unsigned char *y ) { int m , n , i ; int *mlist ; for ( n = 1 ; n <= a->N ; n++ ) { y[n] = 0 ; }


37

‘833 Claim 10 The MacKay Software for ( m = 1 ; m <= a->M ; m++ ) { if ( x[m] ) { mlist = a->mlist[m] ; for ( i = a->num_mlist[m] ; >= 1 ; i -- ) { y[ mlist[i] ] ^= 1 ; } } } }”

In the MacKay Software, the combination operation is invoked by the

function call “alist_transpose_cvector_sparse_mod2 ( &c->a , d , t ).” Ex. 1019 at ¶

103; Ex. 1019 at p.5, line 233. This function implements a transposed matrix-

multiply between its first argument, the alist matrix “c->a”, and its second

argument, the information bit vector “d” as shown above. Ex. 1019 at pp. 25-26,

lines 49-65. Ex. 1010 at ¶ 103.

The alist matrix “c->a” is a data structure that stores data representing

indices into the first set of memory locations and indices into the second set of

memory locations. Ex. 1010 at ¶ 104. The result of the operation is stored in its

third argument, the vector of binary elements, “t.” Id. The code for

“alist_transpose_cvector_sparse_mod2” first zeros out the destination vector,

whose local variable name is “y.” Ex. 1019 at p. 26, lines 54-56. Next, line 57 of

cmatrix.c iterates through each data element in the input vector “x.” Id. at line 57.

If the data element “x[m]” is 1, then the command “y[ mlist[i] ] ^= 1 ;” on line 61


38

is executed. Id. at lines 58, 61. Together, these commands therefore perform

exclusive OR operation on the value “x[m]” from the first set of memory locations

and “y[ mlist[i] ]” in the second set of memory locations. Ex. 1010 at ¶ 104.

The value of mlist[i] is an index into the second set of memory locations and the

result of the operation on these bits is stored to y[ mlist[i] ]. Id. The value of

mlist[i] is the corresponding index into the second set of memory locations. Id.

The MacKay Software therefore meets the broadest reasonable interpretation of

“wherein performing the combine operation comprises writing the sum to the

second set of memory locations based on a corresponding index.” Id.

‘833 Claim 11 The MacKay Software 11. The method of claim 8, wherein performing the accumulation operation comprises performing a mod-2 or exclusive OR sum of the bit stored in a prior index to a bit stored in a current index based on a corresponding index of the second set of memory locations.

See claim 4, above.

See, e.g., Ex. 1019 at p.5, lines 244-246.

As discussed above within the context of Claim 4, the MacKay Software

discloses all limitations of this claim. Ex. 1010 at ¶¶ 106-109.


13. The method of claim 8, wherein the combining operation comprises generating pairs of an index of the first set of memory locations and an index of the second set of memory locations.

See Claim 6, above.

See, e.g., Ex. 1019 at p.5, line 233; pp.25-26, lines 49-65.


39

As discussed above within the context of Claim 6, the MacKay Software

discloses all limitations of this claim. Ex. 1010 at ¶¶ 106-109.

B. Ground 2: The ‘833 Patent Claims 1, 2, 4, and 6 are obvious over

the MacKay Software in view of Kernigan

Ground 2 is presented in the unlikely case that the Board rules that an

“apparatus” of Claims 1, 2, 4, and 6 are not inherent based upon the teaching of the

MacKay Software.

1. All limitations are disclosed by the MacKay Software in

view of Kernighan

As shown in the charts of section VI.A, all limitations of claims 1, 2, 4, and

6 are disclosed by the MacKay Software.


the compiled source code on a computer. Ex. 1010 at ¶ 56. The computer

executing the MacKay Software meets the broadest reasonable interpretation of

this preamble. Id.

To the extent that the Board finds that this element is not met explicitly by

the MacKay Software, then a person of ordinary skill in the art would find this

element to be obvious over the MacKay Software combined with Kernighan. Ex.

1010 at ¶ 57. Kernighan is a well-known and seminal introductory text on the C

programming language Ex. 1010 ¶ 57. The subject of Kernighan is the C


40

programming language, which is the language used in the MacKay Software. Id.;

Ex. 1067 at xi (“C is a general-purpose programming language.”) Kernighan

discloses that C language source code is compiled and then run on computers. Ex.

1067 at 5-7. A person of ordinary skill in the art would therefore know to

compile the MacKay Software so that it would run on a computer, and would be

motivated to do so in order to use the software for its intended purpose. Ex. 1010

at ¶ 57. Patent Owner’s expert in the Litigation has similarly admitted that a

computer is necessary to perform the elements of the claims of the ‘833 Patent.

Ex. 1068 ¶ 42. This combination would therefore be obvious to one of ordinary

skill in the art.

C. Ground 3: The ‘833 Patent Claims 1, 2, 4, 6, 8, 9, 10, 11, and 13 are Obvious Under 35 U.S.C. § 103 Over the ‘710 Patent in view of Hennessy

This ground is presented in the unlikely event that the Board disagrees with

petitioner that the MacKay Software (alone or with Kernighan) discloses the claim

elements of the challenged claims, .

1. The cited reference combination discloses all limitations

As demonstrated below, each and every element of claims 1, 2, 4, 6, 8, 9, 10,

11, 13 is disclosed by the ‘710 Patent in view of Hennessy.

‘833 Claim 1 The ‘710 Patent in view of Hennessy 1[p] 1. An apparatus for performing

See, e.g., Ex. 1001 at 2:33-35, Figure 2: “FIG. 2 illustrates a coder 200 according to an embodiment. The coder 200 may


41

‘833 Claim 1 The ‘710 Patent in view of Hennessy encoding operations,

include an outer coder 202, an interleaver 204, and inner coder 206.”

See, e.g., Ex. 1001 at Fig. 3:

The ‘710 patent describes encoders. Ex. 1010 at ¶115. The ‘710 Patent

states that Figures 2 and 3 illustrate coders, as shown above. Ex. 1001 at 2:33-35,

2:18-19, Figures 2-3. At the time of the alleged invention of the ‘833 patent, a

person of ordinary skill in the art would recognize that the encoding and decoding

methods described in the ‘710 Patent would be implemented using an apparatus,

such as a computer. Ex. 1010 at ¶ 115; Ex. 1068 ¶ 42.


42

‘833 Claim 1 The ‘710 Patent in view of Hennessy 1[a] the apparatus comprising: a first set of memory locations to store information bits;

See, e.g., Ex. 1001 at 1:57-58: “A coding system according to an embodiment is configured to receive a portion of a signal to be encoded, for example, a data block including a fixed number of bits.”

See, e.g., Ex. 1001 at 2:41-42: “The outer coder 202 receives the uncoded data. The data may be partitioned into blocks of fixed size, say k bits.”

See, e.g., Ex. 1001 at 3:33-34 “There are k variable nodes 302 on the left, called information nodes.”

See, e.g., Ex. 1020 at 98: “Hence data structures, like arrays, are kept in memory. . . . To access a word in memory, the instruction must supply its address. Memory is really just a large, single-dimensional array, with the address acting as the index to that array.”

See, e.g., Ex. 1001 at Fig. 3:


43

The encoder of the ‘710 Patent receives information bits in a data block. Ex.

1010 at ¶ 116. The ‘710 Patent describes that the coding system is configured to

“receive a portion of a signal to be encoded” as shown above. Ex. 1001 at 1:57-58,

2:41-42. In Figure 3, the information nodes u1 . . uk represent information bits. Ex.

1001 at 3:33-34; Ex. 1010 at ¶ 116. It would be obvious to a person of ordinary

skill in the art to store the ‘710 Patent’s data block to a first set of memory

locations as described in Hennessy and reproduced above. Ex. 1020 at 98; Ex. 1010

at ¶ 116.

‘833 Claim 1 The ‘710 Patent in view of Hennessy 1[b] a second set of memory locations to store parity bits;

See, e.g., Ex. 1001 at 3:60-64: “If the permutation performed in permutation block 310 is fixed, the Tanner graph represents a binary linear block code with k information bits (u1, . . . , uk) and r parity bits (x1, . . . , xr), as follows.”


The output of the ‘710 Patent’s encoders includes parity bits as shown above.

Ex. 1010 at ¶ 117. It would be obvious to store the r parity bits output from the

‘710 Patent’s encoder in a second set of memory locations as discussed in

Hennessy and reproduced above. Ex. 1020 at 98; Ex. 1010 at ¶ 117.


44

‘833 Claim 1 The ‘710 Patent in view of Hennessy 1[c] a permutation module to read a bit from the first set of memory locations and combine the read bit to a bit in the second set of memory locations based on a corresponding index of the first set of memory locations and a corresponding index of the second set of memory locations;

See, e.g., Ex. 1001 at Figure 2:


See., e.g, Ex. 1001 at 4:5-10:

See, e.g., Ex. 1001 at 3:35-36:


45

‘833 Claim 1 The ‘710 Patent in view of Hennessy “There are r variable nodes 306 on the right, called parity nodes.”

See, e.g., Ex. 1020 at 98: “Hence data structures, like arrays, are kept in memory. . . . To access a word in memory, the instruction must supply its address. Memory is really just a large, single-dimensional array, with the address acting as the index to that array.” (emphasis added)

See, e.g, Ex 1020 at 261: “The full MIPS instruction set has two more logical operations not mentioned thus far: xor and nor. The operation xor stands for exclusive OR.”

In Figure 2, the ‘710 Patent discusses an encoder with an outer coder 202

and an interleaver (P) 204 as shown above. Ex. 1001 at Figure 2, 2:41-58

(discussing outer coder 202), 3:18-22 (discussing interleaver 204). To one skilled

in the art, Figure 3 represents an encoder of the ‘710 Patent. Ex. 1001 at Fig. 3;

Ex. 1010 at ¶ 120. To implement the encoder of the Tanner graph, it would be

obvious to store the information bits u1 . . uk, shown in Figure 3 in a first set of

memory locations and the x1 .. . xr parity bits, also shown in Figure 3, in the second

set of memory locations. Ex. 1020 at 98; Ex. 1010 at ¶ 121. The random

permutation module of the Tanner graph calculates the exclusive OR sum of the

repeated information bits needed for each parity check node. Ex. 1001 at Fig. 3; Ex.

1010 at 121. Given the Tanner graph of Figure 3 and the equation in the ‘710

Patent at 4:5-10, an obvious way to implement the encoding is to perform r first

sums of the information bits and then an accumulation of the r fist sums, where r is

the number of parity checks. Ex. 1001 at Fig. 3, 3:34-35; Ex. 1010 at ¶ 121. The


46

equation at 4:5-10 is . Ex. 1001 at Fig. 3; 4:5-10; Ex.

1010 at ¶ 121. The r first sums corresponds to the portion of

the equation. Ex. 1001 at Fig. 3; 4:5-10; Ex. 1010 at ¶ 121. An obvious way

to perform the r first sums is to sequentially combine, by an exclusive OR

operation, the values of the information bits into a location in the second set of

memory locations. Ex. 1010 at ¶ 121. Each of the sequential exclusive OR

operations is a combination of an information bit, which is in the first set of

memory locations, with the current value of the sum, which is in the second set of

memory locations. Ex. 1010 at ¶ 121. The use of the exclusive OR operation

on memory locations is well known. Ex. 1020 at 261; Ex. 1010 at ¶ 121. The

combination of the ‘710 Patent and Hennessy therefore provides the claimed “a

permutation module to read a bit from the first set of memory locations and

combine the read bit to a bit in the second set of memory locations based on a

corresponding index of the first set of memory locations and a corresponding index

of the second set of memory locations.”

‘833 Claim 1 The ‘710 Patent in view of Hennessy

1[d] and an accumulator to perform accumulation operations on the bits stored in the second set of

Ex.1001 at 2:65-3:15:

“In an embodiment, the inner coder 206 is an accumulator, which produces outputs that are the modulo two (mod-2) partial sums of its inputs. The accumulator may be a truncated rate-1 recursive convolutional coder with the transfer function 1/(1+D). Such an accumulator may be considered a block coder whose input block [x1, . . . , xn] and output block


47

‘833 Claim 1 The ‘710 Patent in view of Hennessy memory locations, [y1, . . . , yn] are related by the formula

y1=x1 y2 = x1 ⊕ x2 y3 = x1 ⊕ x2 ⊕ x3 yn = x1 ⊕x2 ⊕x3 ⊕ . . . ⊕xn.

where “⊕” denotes mod-2, or exclusive OR (XOR), addition. An advantage of this system is that only mod-2 addition is necessary for the accumulator”


See., e.g, Ex. 1001 at 4:5-10:

See, e.g., Ex. 1020 at 98: “Hence data structures, like arrays, are kept in memory. . . . To access a word in memory, the instruction must supply its address. Memory is really just a


48

‘833 Claim 1 The ‘710 Patent in view of Hennessy large, single-dimensional array, with the address acting as the index to that array.” (emphasis added)

As discussed above, a person of ordinary skill in the art would implement

the Tanner graph of Figure 3, in light of the equation at 4:5-10 by first performing r

first sums of the information bits and then an accumulation of the r fist sums of the

information bits. Ex. 1001 at Fig. 3; 4:5-10; Ex. 1010 at ¶ 121. The

portion of the equation at 4:5-10 could therefore be obviously

implemented as an accumulation of the r first sums. Ex. 1001 at Fig. 3; 4:5-10; Ex.

1010 at ¶ 121. An obvious way to perform the accumulation is to perform the

accumulation in-place such that the bits in the second set of memory locations are

accumulated. Ex. 1010 at ¶ 123. It would be obvious store the accumulated bits in

the second set of memory locations as shown in Hennessy. Ex. 1020 at 98; Ex.

1010 at ¶ 123.


1[e] wherein two or more memory locations of the first set of memory locations are read by the permutation module different times

See, e.g., Ex. 1001 at 3:31-43:

“The Tanner graph includes two kinds of nodes: variable nodes (open circles) and check nodes (filled circles). There are k variable nodes 302 on the left, called information nodes. There are r variable nodes 306 on the right, called parity nodes. There are r=(kΣiif i)/a check nodes 304 connected between the information nodes and the parity nodes. Each information node 302 is connected to a number of check nodes 304. The fraction of information nodes connected to exactly i check nodes is fi. For example, in the Tanner graph 300, each of the f2 information nodes are connected to two check nodes, corresponding to a repeat


49

‘833 Claim 1 The ‘710 Patent in view of Hennessy from one another.

of q=2, and each of the f3 information nodes are connected to three check nodes, corresponding to q=3”


The ‘710 patent describes its IRA encoding in terms of a Tanner graph

shown at Figure 3. Ex. 1001 at Figure 3, 3:23-50. In the Tanner graph, the

information nodes correspond to information bits and the parity nodes correspond

to parity bits. Ex. 1001 at 3:31-43. The ‘710 Patent describes the Tanner graph of

Figure 3 as shown above. Ex. 1010 at ¶ 124.

The ‘710 patent does not disclose that the repeated bits are stored and read

from the first set of memory locations. Ex. 1010 at ¶ 124. It would be obvious

to a person of ordinary skill in the art to read from the first set of memory locations

as described above by Hennessy. Ex. 1020 at 98; Ex. 1010 at ¶ 124. The

combination of the ‘710 Patent and Hennessy therefore meets the broadest

reasonable interpretation of “wherein two or more memory locations of the first set

of memory locations are read by the permutation module different times.” Id.

If, however, the Board determines that the fifth limitation should be

construed as “where two or more memory locations of the first set of memory

locations are read by the permutation module a different number of times from


50

one another”, then this is obvious over the combination ‘710 Patent’s IRA

encoding with Hennessy. Ex. 1010 at ¶ 126. It would be obvious to read values

from memory locations to carry out the IRA encoding described in the ‘710 Patent,

including the Tanner graph of Fig. 3. Id.; Ex. 1020 at 98.

‘833 Claim 2 The ‘710 Patent in view of Hennessy 2. The apparatus of claim 1, wherein the permutation module is configured to perform the combine operation to include performing mod-2 or exclusive OR sum.

See, e.g., Ex. 1020 at 261: “The full MIPS instruction set has two more logical operations not mentioned thus far: xor and nor. The operation xor stands for exclusive OR.”); A-56 (showing syntax of exclusive OR (xor) operation).”


See., e.g, Ex. 1001 at 4:5-10:


51


Given the Tanner graph of Figure 3 and the equation in the ‘710 Patent at

4:5-10, an obvious way to implement the encoding is to perform r first sums of the

information bits and then an accumulation of the r first sums. Ex. 1001 at Fig. 3;

4:5-10; Ex. 1010 at ¶ 121. As discussed above, an obvious way to perform the r

first sums is to sequentially combine, by an exclusive OR operation, the values of

the information bits into a location in the second set of memory locations. Ex. 1001

at Fig. 3; 4:5-10; Ex. 1010 at ¶ 121. It would be obvious to perform the

combination operation using the mod-2 or exclusive or operation. The use of the

exclusive OR operation to combine two bits was well known to those of skill in the

art. Ex. 1020 at 261 and A-56.

‘833 Claim 4 The ‘710 Patent in view of Hennessy 4. The apparatus of claim 1, wherein the accumulator is configured to perform the accumulation operation to include a mod-2 or exclusive OR sum of the bit stored in a prior index to a bit stored in a current index based on a corresponding index of the second set of

Ex.1001 at 2:65-3:15:

“In an embodiment, the inner coder 206 is an accumulator, which produces outputs that are the modulo two (mod-2) partial sums of its inputs. The accumulator may be a truncated rate-1 recursive convolutional coder with the transfer function 1/(1+D). Such an accumulator may be considered a block coder whose input block [x1, . . . , xn] and output block [y1, . . . , yn] are related by the formula

y1=x1

y2 = x1 ⊕ x2

y3 = x1 ⊕ x2 ⊕ x3


52

‘833 Claim 4 The ‘710 Patent in view of Hennessy memory locations. yn = x1 ⊕x2 ⊕x3 ⊕ . . . ⊕xn.

where “⊕” denotes mod-2, or exclusive OR (XOR), addition. An advantage of this system is that only mod-2 addition is necessary for the accumulator”


The accumulation of the ‘710 Patent includes a mod-2 or exclusive OR sum

as claimed as shown above. Ex. 1001 at 2:65-3:15. It would be obvious to use

indexes to memory locations to perform the accumulation operation, as shown in

Hennessy. Ex. 1020 at 98; Ex.1010 at ¶ 132.


6. The apparatus of claim 1, wherein the permutation module further comprises a permutation information module to generate pairs of an index of the first set of memory locations and an index of the second set of memory locations


It would be obvious to a person of ordinary skill in the art to implement the

permutation module by generating a pair of indexes of the first set of memory

location and the second set of memory locations, as shown in Hennessy above. Ex.

1020 at 98; Ex.1010 at ¶ 134. The generation of indexes to memory locations

was therefore well known at the time of the alleged invention. Id.


53

‘833 Claim 8 The ‘710 Patent in view of Hennessy 8[p] A method of performing encoding operations,

See, e.g., Ex. 1001 at 2:33-35, Figure 2: “FIG. 2 illustrates a coder 200 according to an embodiment. The coder 200 may include an outer coder 202, an interleaver 204, and inner coder 206.”


The encoders of the ‘710 Patent performs methods of encoding operations as

shown above.

‘833 Claim 8 The ‘710 Patent in view of Hennessy 8[a] the method comprising: receiving a sequence of information bits

See, e.g., Ex. 1001 at 1:57-58: “A coding system according to an embodiment is configured to receive a portion of a signal to be encoded, for example, a data block including a fixed number of bits.”


54

‘833 Claim 8 The ‘710 Patent in view of Hennessy from a first set of memory locations

See, e.g., Ex. 1001 at 2:41-42: “The outer coder 202 receives the uncoded data. The data may be partitioned into blocks of fixed size, say k bits.”



The encoder of the ‘710 Patent receives information bits in a data block. Ex.

1010 at ¶ 138. The ‘710 Patent describes that the coding system is configured to

“receive a portion of a signal to be encoded” as shown above. Ex. 1001 at 1:57-58,

2:41-42, Fig. 3. It would be obvious to a person of ordinary skill in the art to


55

store the ‘710 Patent’s data block to a first set of memory locations as described in

Hennessy and reproduced above. Ex. 1020 at 98; Ex. 1010 at ¶ 138.


8 [b] performing an encoding operation using the received sequence of information bits as an input,

8[c] said encoding operation comprising: reading a bit from the received sequence of information bits, and combining the read bit to a bit in a second set of memory locations based on a corresponding index of the first set of memory locations for the received sequence of information bits and a corresponding index of the second set of memory locations;

See element 1 [c] above.

See, e.g., Ex. 1001 at Figures 2, 3.

See, e.g., Ex. 1020 at 98.

As explained above with respect to the permutation module of element 1[c],

the ‘710 Patent in view of Hennessy teaches this functionality. Ex. 1010 at ¶¶ 139-

142.


8[d] and accumulating the bits in the second set of memory locations,

See element 1[d] above.

See, e.g., Ex. 1001 at 2:65-3:15.

See, e.g., Ex. 1020 at 98.

As explained above with respect to element 1[d], the ‘710 Patent in view of

Hennessy teaches accumulation to a second set of memory locations. Ex. 1010 at

¶¶ 143-144.


56



See element 1[e] above.

See, e.g., Ex. 1001 at 3:31-43.

See, e.g., Ex. 1020 at 98.


As an initial matter, the claim does not introduce “the permutation module.”

Assuming, arguendo, that such a module performs the claimed step of “combining

the read bit to a bit in a second set of memory locations based on a corresponding

index of the first set of memory locations for the received sequence of information

bits and a corresponding index of the second set of memory locations,” the ‘710


57

Patent in view of Hennessy teaches accumulation to a second set of memory

locations. Ex. 1010 at ¶¶ 145-148.

Additionally it would be obvious to store the information bits u1 . . uk, shown

in Figure 3 in a first set of memory locations and the x1 .. . xr parity bits, also

shown in Figure 3, in the second set of memory locations. Ex. 1001, Figure 3; Ex.

1010 ¶ 141.

‘833 Claim 9 The ‘710 Patent in view of Hennessy 9. The method of claim 8, wherein performing the combine operation comprises performing mod-2 or exclusive OR sum.

See claim 2; see, e.g., Ex. 1020 at 261; see, e.g., Ex. 1001 at Figure 3:

The ‘710 Patent in view of Hennessy discloses all limitations of this claim,

as discussed above within the context of claim 2. Ex. 1010 at ¶¶ 149-150.


58

‘833 Claim 10 The ‘710 Patent in view of Hennessy 10. The method of claim 9, wherein performing the combine operation comprises writing the sum to the second set of memory locations based on a corresponding index.


It would be obvious to write the sum to the second set of memory locations

based on a corresponding index as shown in Hennessy, reproduced above. Ex.

1010 at ¶ 151; Ex. 1020 at 98.


11. The method of claim 8, wherein performing the accumulation operation comprises performing a mod-2 or exclusive OR sum of the bit stored in a prior index to a bit stored in a current index based on a corresponding index of the second set of memory locations.

See claim 4.

See, e.g., Ex. 1001 at 2:65-3:15.

See, e.g., Ex. 1020 at 98.




13. The method of claim 8, wherein the combining operation comprises generating pairs of an index of the first set of memory locations and an index of the second set of memory locations.

See claim 6.

See, e.g., Ex. 1020 at 98.


59



2. One of skill in the art would be motivated to combine the references

A person of ordinary skill in the art would have been motivated to combine

the ‘710 Patent with Hennessy. A person of ordinary skill in the art would

combine the ‘710 Patent with Hennessy to arrive at the claimed subject matter.

Ex. 1010 at ¶ 127. Such a combination would be obvious because computers are

known to be effective at arithmetic computations, such as those in the ‘710 Patent.

Id. Ex. 1068 ¶ 42. At the time of the alleged invention, a person of ordinary skill in

the art would implement an encoding operation in software sequential a general

purpose microprocessor, such as a microprocessor described in Hennessy. Id.

Hennessy states that “data structures, like arrays are kept in memory. . . . To access

a word in memory, the instruction must supply its address. Memory is really just

a large single-dimensional array, with the address acting as the index to that array.”

Ex. 1020 at 98. Therefore, the use of memory to store data was well-known at the

time of the alleged invention. Ex. 1010 at ¶ 127. Furthermore, the use of the

exclusive or operation by a computer on data in memory locations was also well

known at the time of the alleged invention. Id. Hennessy states that “[t]he full

MIPS instruction set has two more logical operations not mentioned thus far: xor

and nor. The operation xor stands for exclusive OR.” Ex. 1020 at 261. When


60

performed on binary data, the exclusive or operation is identical to the mod 2

operation. Ex. 1010 at ¶ 127.

VII. CONCLUSION

Petitioner respectfully requests that inter partes review of the ’833 Patent be

instituted and that claims 1, 4, 6, 15, 16, 20, and 22 be cancelled as unpatentable

under 35 U.S.C. § 318(b).

Respectfully submitted,

BAKER BOTTS L.L.P.

October 17, 2014 /Eliot D. Williams/________________ Date Eliot D. Williams (Reg. No. 50,822)

G. Hopkins Guy III (Reg. No. 35,866) 1001 Page Mill Road, Bld. 1, Suite 200 Palo Alto, California 94304-1007 650.739.7510 Attorneys for Petitioner, Hughes Network Systems, L.L.C. and Hughes Communications, Inc.

CERTIFICATE OF SERVICE

In accordance with 37 C.F.R. §§ 42.6(e) and 42.105, the undersigned

certifies that on the 14th day of October, 2014, a complete and entire copy of the

PETITION FOR INTER PARTES REVIEW OF CLAIMS 1, 2, 4, 6, 8, 9, 10,

11, 13 OF U.S. PATENT NO. 8,284,833 UNDER 35 U.S.C. §§ 311-319 AND 37

C.F.R. §§ 42.100 ET SEQ. BASED ON THE MACKAY SOFTWARE AND

THE ‘710 PATENT (“petition”) including exhibits and testimony relied upon

were served on the patent owner at the correspondence address of record for the

subject patent,

Bing Ai, Esq. Perkins Coie LLP

P.O. Box 1247 Seattle, WA - 98111-1247

via Express Mail and to counsel for patent owner in the Lawsuit,

Quinn Emanuel Urquhart & Sullivan, LLP James R. Aspberger

865 S. Figueroa St., 10th Floor Los Angeles, California 90017

via Express Mail.

October 17, 2014 /Eliot D. Williams/________________ Date Eliot D. Williams (Reg. No. 50,822)

G. Hopkins Guy III (Reg. No. 35,866) 1001 Page Mill Road, Bld. 1, Suite 200 Palo Alto, California 94304-1007 650.739.7510 Attorneys for Petitioner, Hughes Network Systems, L.L.C. and Hughes Communications, Inc.

in re: u.s. patent 8,284,833 : attorney docket no. 082944...

Documents