Patent 8666062
Obviousness
Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.
Active provider: Google · gemini-2.5-pro
Obviousness
Combinations of prior art that suggest the claimed invention would have been obvious under 35 U.S.C. § 103.
Obviousness Analysis under 35 U.S.C. § 103
An invention is considered obvious if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art (PHOSITA). This analysis considers whether a PHOSITA would have been motivated to combine teachings from different prior art references to arrive at the claimed invention with a reasonable expectation of success.
Person Having Ordinary Skill in the Art (PHOSITA)
For the '062 patent, a PHOSITA would be an individual with a background in computer science, electrical engineering, or applied mathematics. This person would possess practical experience in implementing cryptographic algorithms, particularly public-key systems like Elliptic Curve Cryptography (ECC). They would be knowledgeable about finite field arithmetic (over both prime fields Fp and binary fields F2m), the representation of large numbers in computer memory (i.e., multi-word arithmetic), and standard software engineering principles such as modular design and code reusability.
The Core Concept of the '062 Patent
The central inventive concept claimed in US 8,666,062 is a modular, two-step software architecture for performing finite field operations. This architecture is defined by:
- Executing a first, generic set of "wordsized" instructions to perform an arithmetic operation (e.g., multiplication) on multi-word operands, producing a larger, unreduced result. This set of instructions is independent of the specific finite field.
- Executing a second, field-specific set of instructions to perform a modular reduction on the unreduced result, yielding the final value within the target finite field.
This separation allows the generic arithmetic code to be reused, while specific reduction modules can be "plugged in" to support different finite fields, thereby enhancing flexibility and reducing code size.
Obviousness Combination of Prior Art
The claims of the '062 patent appear vulnerable to an obviousness challenge based on a combination of prior art and the general knowledge of a PHOSITA at the time of the invention. The motivation to create a flexible cryptographic system capable of supporting multiple field sizes was well-established, as different standards and security levels required different underlying mathematical structures.
Combination 1: Zukowski (U.S. 6,189,021) in view of standard software engineering principles.
Zukowski ('021) teaches a "finite field arithmetic processor" that is explicitly "configurable to handle different field sizes." This reference establishes the problem the '062 patent aims to solve: creating a single, flexible system for multiple finite fields. Zukowski's focus is on a processor architecture, but it directly addresses the need for adaptability.
Motivation to Combine: A PHOSITA tasked with implementing a software-based cryptographic library with the flexibility described by Zukowski would naturally turn to standard software engineering principles. The principle of modularity—decomposing a problem into independent, interchangeable components—is fundamental to efficient software design.
A PHOSITA would recognize that in finite field arithmetic, the process of multiplying two large numbers (the "wordsized" operation) is algorithmically distinct from the final step of reducing the product modulo a specific prime or polynomial. The multiplication logic is generic, while the reduction logic is unique to each field. The most straightforward and efficient way to implement Zukowski's "configurable" system in software would be to:
- Write a single, optimized function for multi-word multiplication that produces a double-precision (unreduced) result.
- Write separate, distinct functions for modular reduction, one for each finite field that needs to be supported.
- Call the appropriate reduction function after the multiplication is complete.
This approach, which directly maps to the method in Claim 1 of the '062 patent, is not an inventive leap but rather a standard and obvious application of modular design to the known problem of implementing multi-field cryptography. It reduces redundancy, simplifies maintenance, and allows for easy extension to new cryptographic standards—all well-understood goals in software engineering. Therefore, it would have been obvious to combine the goal of Zukowski with this standard design practice to arrive at the claimed invention.
Combination 2: Moshier (U.S. 6,233,603) or Rosati (U.S. 6,904,452) in view of Zukowski (U.S. 6,189,021).
Moshier ('603) and Rosati ('452) both disclose efficient methods for finite field multiplication. Any multi-word multiplication inherently produces an intermediate result that is approximately twice the length of the operands before it is reduced to the size of the field. This "unreduced result" is therefore an implicit, if not explicit, part of any standard multiplication algorithm known in the art.
Zukowski ('021), as noted, provides the motivation for a system that can handle different finite fields.
Motivation to Combine: A PHOSITA looking to build the flexible system described in Zukowski would need an efficient multiplication routine, such as those taught by Moshier or Rosati. In adapting such a routine for a multi-field system, the developer would be faced with the fact that the reduction step is the only part of the process that changes from one field to another.
To avoid writing and maintaining a completely separate, monolithic multiplication-and-reduction function for every single field, the PHOSITA would have been motivated to separate the common multiplication logic from the variable reduction logic. This would involve taking a known multiplication method (like Moshier's), implementing it as a generic "wordsized" function that returns the unreduced product, and then creating a library of separate reduction functions. This combination of a known multiplication technique (Moshier/Rosati) with the goal of configurability (Zukowski) would lead directly to the two-step process of Claim 1: executing a first set of instructions for the multiplication to get an unreduced result, and then a second set of instructions for the field-specific reduction.
Conclusion on Obviousness
The core claims of the '062 patent describe an architecture that separates a general arithmetic computation from a specific modular reduction. While the cited prior art may not explicitly disclose this exact modular software structure in a single reference, the structure itself represents a standard and logical application of well-known software engineering principles (modularity, code reuse) to the known problem of building flexible cryptographic systems that can support multiple finite fields. The motivation to combine a generic, wordsized arithmetic engine with specific, interchangeable reduction modules would have been readily apparent to a PHOSITA seeking to create an efficient and extensible cryptographic library. Consequently, the claims of U.S. Patent 8,666,062 are likely vulnerable to an invalidity challenge based on obviousness under 35 U.S.C. § 103.
Generated 5/10/2026, 12:46:06 AM