`
`
`
`
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`_____________________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_____________________________
`
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`CALIFORNIA INSTITUTE OF TECHNOLOGY,
`Patent Owner.
`
`_____________________________
`
`Patent No. 7,116,710
`_____________________________
`
`
`DECLARATION OF DR. HUI JIN
`
`
`
`CALTECH - EXHIBIT 2020
`Apple Inc. v. California Institute of Technology
`IPR2017-00210
`
`
`
`I, Hui Jin, declare as follows:
`
`1.
`
`I am a named inventor on U.S. Patent No. 7,116,710. I have personal
`
`knowledge of the facts set forth in this declaration.
`
`2.
`
`I am currently a Co-Founder at JinYi Capital Management, where I
`
`am based out of New York, NY. Prior to that I was a Vice President at Goldman
`
`Sachs, also in New York. I worked at Flarion, which later became Qualcomm after
`
`an acquisition, in a Senior Technical Staff position. I received my Ph.D. in
`
`Electrical Engineering from Caltech in 2001, and my B.S. from Caltech in 1998,
`
`also in Electrical Engineering. My work has resulted in over 35 issued and
`
`pending patents.
`
`3.
`
`During the 1999-2000 academic year, I was a graduate student at
`
`Caltech. Together with another graduate student, Aamod Khandekar, I worked
`
`under the supervision of Prof. Robert McEliece. Dr. McEliece’s research was in
`
`the area of reliable storage and transmission of information. Aamod Khandekar
`
`(now Dr. Khandekar) and I specifically focused on research in the field of error
`
`correcting codes. Our goal was to create new, improved error correction codes that
`
`performed as close as possible to the Shannon limit while at the same time
`
`providing low-complexity encoding and decoding to allow practical
`
`implementation in real-world applications.
`
`
`
`1
`
`
`
`4.
`
`Aamod and I met regularly with Dr. McEliece during the academic
`
`year to discuss our work. As part of our work we developed and tested numerous
`
`different coding structures, running simulations to assess their performance and
`
`determine whether they presented potential improvements to known error
`
`correcting codes.
`
`5.
`
`In early 2000, Dr. McEliece, Aamod, and I had conceived of the
`
`Irregular Repeat Accumulate code that is described and claimed in the ’710 patent.
`
`We then spent several weeks reducing our invention to practice, which was
`
`completed by early March. As part of our research for our invention, we found
`
`that the outer coder in a repeat-accumulate code could be generalized as a low-
`
`density generator matrix. We were then interested in studying the impact of
`
`combining an LDGM with an accumulator, but at that point we were not yet sure
`
`about their performance. We then experimented with different variations of the
`
`LDGM and discovered that specific irregular LDGMs could potentially lead to
`
`improved performance. I spent much of my time during this period figuring out
`
`irregular degree profiles that resulted in a significant improvement under different
`
`channel conditions and code rates. For all channel types we studied, we discovered
`
`through experimentation that carefully designed IRA codes came extremely close
`
`to channel capacity. For the Binary Erasure Channel, we were also able to prove
`
`
`
`2
`
`
`
`that it achieved channel capacity. These were all significant developments at the
`
`time.
`
`6.
`
`Our discovery of IRA codes is reflected in contemporaneous emails
`
`and notebooks from Dr. McEliece. On March 7, 2000 Dr. McEliece sent an email
`
`to Aamod and me, conveying a new realization of his that the generalized RA
`
`codes could alternatively be viewed as low density generator matrix codes
`
`followed by an accumulator. Ex. 2021. With this new understanding, Dr.
`
`McEliece stated that “what we want to consider is whether irregular LDGM outer
`
`codes gain us anything.” Id. This confirms that we had already discussed the use
`
`of irregular LDGM outer codes, and were researching whether they could lead an
`
`improvement.
`
`7.
`
`This development is also recorded in Dr. McEliece’s lab notebook
`
`entry for that same day, March 7, 2000. Ex. 2022 at 21-22. In it, he noted that
`
`generalizing the RA code as an LDGM code followed by an accumulator “gets rid
`
`of the interleaver (sort of) and lets us focus on irregularity, etc.” Id. This again
`
`confirms that we had already conceived of the irregular repeat-accumulate code as
`
`a new class of error correction code and were focused on researching whether they
`
`could improve performance. The Tanner graph in this entry also reflects other
`
`structural changes we discussed that made our IRA code different from the RA
`
`
`
`3
`
`
`
`code: the summation of information bits before accumulation, as shown by the
`
`middle “check nodes” having more than one edge coming from the information
`
`nodes u1 through u3. This summation step was not in our original RA code. In
`
`addition, the Tanner graph shows that the check nodes have an irregular degree
`
`profile, which indicates we had already thought about using irregular LDGMs.
`
`8.
`
`After we had conceived of the invention, Dr. McEliece, Aamod and I
`
`spent several weeks working out the implementation details of our Irregular Repeat
`
`Accumulate code. I devoted my time to figuring out which irregular degree
`
`profiles might improve performance in the AWGN channel, while Aamod worked
`
`on the Binary Erasure Channel. In early March, I had designed an irregular degree
`
`profile for an IRA code that I wished to simulate using practical block lengths, so I
`
`went to work writing code to implement and simulate the invention. By March 10,
`
`2000, I had written code that created an Irregular Repeat Accumulate structure
`
`with a user-specified irregular degree profile. These code files were called IRA.h
`
`and IRA.cpp, and the first working versions were completed March 10, 2000. See
`
`Exs. 2023; 2024. For example, the file IRA.h was the “Head file for IRA.” Ex.
`
`2023, p. 1. As I explained in the notes of that file: “This file defines the class of
`
`Irregular Repeat Accumulate code. the code is essentially a concatenate of LDGM
`
`code and Accumulate code.” Id. By March 13, 2000, I had an irregular degree
`
`
`
`4
`
`
`
`profile that I intended to use with the IRA code, defined in the file “RA15_6.prm.”
`
`Ex. 2025. For example, that profile indicates that 48.972% of the variable nodes
`
`(i.e. information bits) would be repeated 15 times and 0.240% of the variable
`
`nodes would be repeated 14 times. Id. I recall that this profile took me several
`
`weeks to discover. By March 20, 2000, I had completed the simulation source
`
`code file IRAsimu.cpp which uses the IRA.h and IRA.cpp files to simulate the
`
`performance of IRA codes using custom degree profiles, such as the one defined in
`
`RA15_6.prm. Ex.2026 (IRAsimu.cpp).
`
`9.
`
`As explained below, the source code files IRA.h and IRA.cpp reflect
`
`the structure of the IRA code invention that is identical to Figure 3 of the ’710
`
`patent, reproduced below.
`
`
`
`5
`
`
`
`
`
`10. The first step in constructing the IRA code is the creation of the nodes
`
`and edges on the left side of the graph in Figure 3, labeled u1 through uk—these
`
`correspond to information bits. The variable “var_node *LVarNode” defined in
`
`IRA.h is an array of var_node objects that correspond to those left side nodes. Ex.
`
`2023, p. 2. This array is initialized in the IRAcode constructor implemented in
`
`IRA.cpp, and given a length of “infobits_len,” that is, the number of information
`
`bits. Ex. 2024, p. 2. The nodes are created in the method IRAcode::initLVNode().
`
`Id., pp. 2-3. This method assigns edges to the variable nodes that correspond to the
`
`
`
`6
`
`
`
`irregular degree sequence array pLV, which IRA.h describes as “LDGM variable
`
`degree profile.” Ex. 2023, p. 1. These edges are interleaved, just like the edges in
`
`Figure 3. Ex. 2024, p. 2. The array nv[] is also used, which corresponds to the
`
`number of nodes for each degree, whereas pLV includes the percentage of nodes
`
`for each degree. Id., pp. 2-3. For our simulations, the array nv[] was generated in
`
`IRAsimu.cpp using the provided parameter file and the number of variable nodes.
`
`Ex. 2026, pp. 3-4. The relevant code from the initLVNode() method is excerpted
`
`below:
`
`
`
`
`
`7
`
`
`
`
`
`11. The next step in constructing the IRA code is the creation of the nodes
`
`and edges on the right side of the graph in Figure 3, labeled x1 through xr—these
`
`correspond to parity bits. The variable “var_node *RVarNode” defined in IRA.h is
`
`an array of var_node objects that correspond to these right-side nodes. Ex. 2023,
`
`p. 2. This array is initialized in the IRA code constructor implemented in IRA.cpp,
`
`and given a length of “checkbits_len,” that is, the number of check nodes (which as
`
`seen in Figure 3 is also the number of parity nodes because of the rate-1
`
`accumulator structure). Ex. 2024, p. 2. The nodes are created in the method
`
`IRAcode::initRVNode(). Id., p. 3. Like the initLVNode() method discussed
`
`above, the initRVNode() method assigns edges to the variable nodes on the right
`
`side, but it does not use a custom degree profile. Instead, all of these right-side
`
`variable nodes are given a degree of 2, except the last node which has a degree of
`
`
`
`8
`
`
`
`1. Id. (“the last bit has degree 1.”). Also, these edges are not interleaved. The
`
`relevant code is excerpted below:
`
`
`
`12. Finally, the last step is the creation of the check nodes in the middle of
`
`the graph in Figure 3, labeled v1 through vr. The variable “var_node *CheckNode”
`
`defined in IRA.h is an array of var_node objects that correspond to these check
`
`nodes. Ex. 2023, p. 2 (commented as “check nodes”). This array is initialized in
`
`the IRA code constructor implemented in IRA.cpp and given a length of
`
`“checkbits_len,” that is, the number of check nodes. Ex. 2024, pp. 2. The nodes
`
`are created in the method IRAcode::initCNode(). Id, pp. 4-5. The method first
`
`assigns edges to the left side of the check nodes—that is, edges that are already
`
`connected to left-side variable nodes that correspond to information bits. Each
`
`check node receives left-side edges corresponding to the custom degree profile,
`
`although typically we used degree profiles where check nodes all had the same
`
`
`
`9
`
`
`
`degree (which corresponds to “degree a” in Figure 3). See, e.g., Ex. 2025
`
`(RA15_6.prm) (custom irregular degree profile showing a single check degree of
`
`6); Ex. 2029 (IRA48_8.prm) (custom irregular degree profile showing a single
`
`check degree of 8). These check nodes correspond to the summation step
`
`described in the ’710 patent. The method then assigns edges to the right side of the
`
`check node, which are edges that are already connected to the right-side variable
`
`nodes that correspond to parity bits. Like in Figure 3, each check node receives
`
`two of these edges, except the first check node which receives one edge. The
`
`relevant code is excerpted below:
`
`
`
`
`
`10
`
`
`
`
`
`13. The creation of this IRA code structure is the core of our invention.
`
`Per the creation of left-side variable nodes and assignment of interleaved edges
`
`using a custom degree profile, it has irregular repetition of information bits that are
`
`interleaved. Per the creation of right-side variable nodes each having 2 edges
`
`connected to check nodes, except the last which has 1 edge, it has a rate-1
`
`accumulator.
`
`14. The above code reflected in Exhibits 2023 and 2024, the IRA.h and
`
`IRA.cpp files, was complete by March 10, 2000. It was my practice to add
`
`
`
`11
`
`
`
`changelog entries to the top of a source code file if I made any substantive
`
`changes. The IRA.h and IRA.cpp files latest changelog entries are March 10,
`
`2000, indicating that any revisions to those files were non-substantive, such as
`
`adding comments and debug statements. These changelog entries are consistent
`
`with my recollection that the above-discussed code was completed by March 10,
`
`2000. In addition, the file reflected in Exhibit 2027 (makefile.bak) was completed
`
`by March 12, 2000 and is a file I created to compile the completed IRA source
`
`code, further corroborating my recollection that the IRA.h and IRA.cpp files were
`
`completed by March 10, 2000.
`
`15. The irregular degree profile reflected in Exhibit 2025 (RA15_6.prm)
`
`was complete by March 13, 2000. The format of this file was chosen to be
`
`compatible with the completed IRA.h and IRA.cpp source code. I recall it took me
`
`several weeks to discover the irregular degree profile reflected in this file.
`
`16. After writing the code that defined the IRA code structure, I began
`
`working on software that would test its effectiveness. I worked on this simulation
`
`code over the next few days and completed it by March 20, 2000. The file
`
`“IRAsimu.cpp” reflects this work. Ex. 2026. As it explains in the header
`
`comments, the file is the “simulation file of Irregular Repeat Accumulative code,”
`
`for which the first version was complete by “3/20/2000”. Id., p. 1.
`
`
`
`12
`
`
`
`17. The IRAsimu.cpp file creates an IRAcode object using a custom
`
`irregular degree profile defined in an external file passed into the command line,
`
`such as the “RA15_6.prm” file I created on March 13. It will then perform many
`
`iterations of the decoding of a codeword that has been passed through a simulated
`
`noisy channel, and then check how many bits, if any, were not decoded.
`
`18. During the development, and immediately upon completion, of the
`
`IRAsimu.cpp file, I ran simulations to test the performance of the IRA code
`
`defined in IRA.h, IRA.cpp, and RA15_6.prm. These tests yielded extremely
`
`impressive results, which I discussed with Aamod Khandekar and Dr. McEliece.
`
`Over the next few weeks, I diligently worked on improving the implementation of
`
`the core IRA code invention, such as figuring out better performing degree profiles
`
`and interleavers. For example, by April 11, 2000, I had created a degree profile in
`
`the file “IRA48_8.prm” that reflects the degree profile we discussed in our paper.
`
`Ex. 2029. Another example is reflected in the comments of Exhibit 2028, the
`
`GetInter.cpp file, which is the source code that generates the interleaver. The top
`
`of that file indicates various dates and changes I made from March 12, 2000 (the
`
`“first version”) to April 12, 2000. Ex. 2028. I diligently continued to work on the
`
`implementation of the IRA code into May 18, 2000 and beyond.
`
`
`
`13
`
`
`
`19. When we realized the additional improvements in our simulation, we
`
`knew this was a remarkable discovery worth patenting. I am aware that Caltech’s
`
`intellectual property counsel used material I created by May 12, 2000 to prepare
`
`the provisional patent application filed on May 18, 2000, which reflects the IRA
`
`code we invented and implemented.
`
`20.
`
`In signing this declaration, I understand that the declaration will be
`
`filed as evidence in a contested case before the Patent Trial and Appeal Board of
`
`the United States Patent and Trademark Office. I acknowledge that I may be
`
`subject to cross-examination in this case and that cross-examination will take place
`
`within the United States. If cross-examination is required of me, I will appear for
`
`cross-examination within the United States during the time allotted for cross-
`
`examination.
`
`21.
`
`I declare that all statements made herein of my knowledge are true,
`
`and that all statements made on information and belief are believed to be true, and
`
`that these statements were made with the knowledge that willful false statements
`
`and the like so made are punishable by fine or imprisonment, or both, under
`
`Section 1001 of Title 18 of the United States Code.
`
`
`
`
`
`
`
`14
`
`
`
`Dated: H47/20'7
`
`By: (i?./,"—>
`
`HuiJm, h.D.
`
`15
`
`