Secret point illustration, a document describing the scope of confidential know-how, plays an irreplaceable role in know-how infringement trials. But, due to lack of uniform guidelines on how to prove technological know-how or draft a piece of secret point illustration, various protection scope claims and secret point structures have emerged in practice. This article is based on the author’s experience in dealing with relevant cases and aims to summarise burden-of-proof strategies for secret point illustration for both sides of source code know-how cases.

Plaintiff tactic

The claimed scope of know-how protection should be flexible and reflect the actual protection needs. When it comes to protecting source code know-how, most rights holders incorporate all code files of computer software in the claimed scope of protection. This includes source code and execution code, and follows the example set in software copyright protection cases.

This practice may have some advantages under the current burden of proof distribution mechanism. For example, the complexity of the file architecture and function naming will create obstacles for the defendant to effectively defend against the “non-public nature” claim.

However, this mode of evidence organisation cannot help the rights holder or the judge to better define the scope of know-how protection. When it comes to proving and identifying the infringing act of “using any know-how acquired by improper means”, the rights holder can only rely on text-by-text comparison to prove the infringement. If the infringer used the know-how in a “transformative” or “disguised” manner, further proof of an infringement would be impossible.

The Copyright Law and the Regulations on Computers Software Protection focus on protecting specific expressions of computer software. In source code know-how cases, however, the rights holder can also seek protection for technical solutions or data.

Computer software is essentially the automatic implementation of a series of technical solutions. Therefore, a piece of source code that can be effectively executed must be describable by a generalised technical solution.

For example, in cases where large-capacity audiovisual files are distributed between servers, preprocessing those files helps reduce the volume of data transmission and improves the efficiency of server network distribution. A computer program designed for this purpose essentially serves as a technical solution to encrypting, encoding, decoding and decrypting the data in transmission.

In the above-mentioned circumstances, it is advisable to include the programmer’s specific ideas and methods to write the corresponding code in the scope of know-how protection. Software design flowcharts, data processing models and other files can be used as carriers of know-how, with specific ideas and methods reduced into secret descriptions.

The running of computer programs is the processing and operation of data. So, obviously, the specific data pending execution and processing is also a possible source of secrets in source code know-how cases, which is particularly notable in computer software infringement cases involving industrial design.

For example, in the selection design software for large-scale industrial plants, the data parameters accumulated by the rights holder based on industrial experience and product experiments will take part in the specific execution and operation of the design program. These data parameters are exactly at the core of the computer program that the rights holder desires to protect.

Another example would be a computing program involving large-scale numerical operations where frequent calls to operating functions in the system interface library lead to a surge in the volume of operations and cause the program to crash. To avoid such circumstances, the developer will define the numerical matrixes in advance in the source code and simplify numerical operations via table lookup, ensuring the “robustness” of the program’s running.

Although this series of numerical matrixes defined in advance is not the core part of the computer program, it is what the infringers cannot circumvent by means of “transformative” or “disguised” use. Taking specific data as secrets in source code know-how cases will work wonders.

The defendant’s perspective

The defendant should reasonably use burden-of-proof rules to require the rights holder to clarify the scope of source code know-how protection in its secret point illustration. The basis on which the rights holder claims know-how is the carrier submitted to the court. Know-how is embodied by the carrier but is not the carrier itself.

For example, in source code know-how protection cases, the property to be protected should be the functions implemented by the source code instead of the underlying library of the operating system referenced by the source code, which is something all program codes must reference and is obviously known to all developers.

Therefore, if the rights holder chooses to claim all source code falls within the scope of know-how protection, its scope of proof can be effectively narrowed by distinguishing between the underlying library, external interface and open source software.

Certain rights holders may reject the practice of submitting secret point illustrations for the software source code, mainly due to concerns about secondary leakage in court proceedings. However, submitting all the source code as the know-how carrier without documented illustration will seriously affect the smooth progression of evidence production and cross-examination.

One reasonable defence available to the defendant in the discovery stage is that, since the rights holder cannot clearly describe the scope of know-how protection, how can the defendant carry out non-public nature retrieval to complete the cross-examination of secrecy?

The rights holder refusing to submit secret point illustration may submit a plausible report on non-public nature verification to convince the judge that the evidence production for secrecy has been completed. In such circumstances, it would be difficult for the judge to confirm the objectivity of the retrieval and the accuracy of the conclusion.

Given the absence of a well-defined scope of protection, the verification agency can hardly justify its non-public nature retrieval method. Therefore, the defendant may choose to attack the uncertainty of the scope of know-how protection claimed by the plaintiff, or target the inaccuracy of the retrieval method and conclusion of the verification agency.