`
`
`
`
`
`
`
`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-00701
`
`
`
`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
`
`
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
