UNITED STATES PATENT AND TRADEMARK OFFICE
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`AMERICAN MEGATRENDS, INC.,
`MICRO-STAR INTERNATIONAL CO., LTD,
`MSI COMPUTER CORP.,
`GIGA-BYTE TECHNOLOGY CO., LTD., AND
`G.B.T., INC.
`Petitioner,
`
`v.
`
`KINGLITE HOLDINGS INC.
`
`Patent Owner
`
`_________________
`
`Case IPR2015-TBA
`
`U.S. Patent 6,892,304
`
`_________________
`
`
`
`DECLARATION OF JAMES BOTTOMLEY, PHD.
`
`
`1
`
`
`
`
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`AMERICAN MEGATRENDS, INC.,
`MICRO-STAR INTERNATIONAL CO., LTD,
`MSI COMPUTER CORP.,
`GIGA-BYTE TECHNOLOGY CO., LTD., AND
`G.B.T., INC.
`Petitioner,
`
`v.
`
`KINGLITE HOLDINGS INC.
`
`Patent Owner
`
`_________________
`
`Case IPR2015-TBA
`
`U.S. Patent 6,892,304
`
`_________________
`
`
`
`DECLARATION OF JAMES BOTTOMLEY, PHD.
`
`
`1
`
`
`
`
`
`
`
`I, James Bottomley, declare as follows:
`
`
`1.
`
`I have been retained by Hill, Kertscher, & Wharton, LLP, which
`
`represents American Megatrends, Inc., Micro-Star International Co., Ltd, MSI
`
`Computer Corp., Giga-Byte Technology Co., Ltd., and G.B.T., Inc. in connection
`
`with a petition for inter partes review of U.S. Patent No. 6,892,304, titled SYSTEM
`
`AND METHOD FOR SECURELY UTILIZING BASIC INPUT AND OUTPUT
`
`SYSTEM (BIOS) SERVICES (“304 Patent”). I understand that the 304 Patent is
`
`currently assigned to Kinglite Holdings Inc.
`
`
`
`SCOPE OF ANALYSIS
`
`2.
`
`I have reviewed and am familiar with the 304 Patent, which issued to
`
`Galasso et al. on May 10, 2005. I understand that the 304 Patent includes 15
`
`claims. I also understand that the Petition for inter partes review that accompanies
`
`this Declaration seeks to cancel claims 1-9, 11-12 and 15 of the 304 Patent. Thus,
`
`my analysis and opinions will focus on the prior art and knowledge of a POSITA
`
`in relation to claims 1-9, 11-12 and 15 of the 304 Patent.
`
`3.
`
`I have been asked to analyze the 304 Patent. I have been asked by
`
`counsel to assume that the date of invention of the 304 Patent is June 18, 1999.
`
`4.
`
`I have reviewed and am familiar with various references, written
`
`materials, and literature, identified as follows:
`
`
`
`2
`
`
`
`
`
` Ex. 1001 U.S. Patent No. 6,892,304 to Galasso et al. (“304 Patent”)
`
` Ex. 1002
`
`The file history of the 304 Patent
`
` Ex. 1003
`
`The file history of U.S. Patent Appl. No. 08/947,990 (“The
`
`CIP”)
`
` Ex. 1004 U.S. Patent No. 5,844,986 to Davis (“Davis”)
`
` Ex. 1005 PKCS #1: RSA Cryptography Standard
`
` Ex. 1006 Automated Recovery in a Secure Bootstrap Process (“Aegis”)
`
` Ex. 1007 U.S. Patent No. 6,539,480 to Drews (“Drews”)
`
` Ex. 1008 Bootup Integrity Service Specification (“BIS”)
`
` Ex. 1009 DHCP Protocol
`
` Ex. 1010 U.S. Patent No. 4,218,582 to Hellman et al. (“Hellman”)
`
` Ex. 1011 Drews Deposition Transcript (“Drews Depo. Trans”)
`
` Ex. 1012 Galasso Deposition Transcript (“Galasso Depo. Trans.”)
`
` Ex. 1013 AMIBIOS 98 Technical Reference (1998) (“AMIBIOS”)
`
` Ex. 1014 U.S. Patent No. 4,405,829 to Rivest et al (“RSA Patent”)
`
` Ex. 1015 U.S. Patent No. 5,557,678 to Ganesan (“Ganesan”)
`
` Ex. 1016 U.S. Patent No. 6,041,357 to Kunzelman (“Kunzelman”)
`
` Ex. 1017 U.S. Patent No. 4,578,530 to Zeidler (“Zeidler”)
`
` Ex. 1018 CCITT Recommendation X.509 (1988)
`
`
`
`3
`
`
`
` Ex. 1019
`
`Federal Information Processing Standards Publication 191
`
`(“FIPS PUB 191”)
`
` Ex. 1020 U.S. Patent No. 5,732,268 to Bizzari (“Bizzari”)
`
` Ex. 1021 U.S. Patent No. 6,574,588 to Shapiro (“Shapiro”)
`
` Ex. 1022 U.S. Patent No. 5,586,301 to Fisherman (“Fisherman”)
`
` Ex. 1023 U.S. Patent No. 5,652,875 to Taylor (“Taylor”)
`
` Ex. 1024 U.S. Patent No. 6,081,890 to Datta (“Datta”)
`
` Ex. 1025
`
`Schnier, B., Applied Cryptography (2d ed. 1996) (“Schnier”)
`
`5.
`
`I have been asked to consider how a person of ordinary skill in the art
`
`(“POSITA”) would have understood the claims subject to inter partes review in
`
`light of the disclosure of the 304 Patent. I have also been asked how a POSITA
`
`would have understood and applied the AMIBIOS, CCITT Recommendation
`
`X.509, FIPS PUB 191, Drews, BIS, and Aegis references, as well as the other
`
`references mentioned in this declaration.
`
`6.
`
`I am being compensated at my standard hourly rate of $310 dollars
`
`per hour. My compensation is not dependent on the outcome of this inter partes
`
`review and in no way affects the substance of my statements in this declaration, or
`
`any other testimony which I may render in these proceedings.
`
`
`
`
`
`
`
`4
`
`
`
`QUALIFICATIONS AND EXPERTISE
`
`7. My resume/curriculum vitae is attached to this declaration as Exhibit
`
`A. I have over 30 years of experience working with Computer Operating systems
`
`including initial boot systems (both BIOS and systems equivalent to BIOS) as well
`
`as digital signature and encryption technologies.
`
`In 1984 I first encountered the UNIX operating system in Australia, writing
`
`both a device driver for a printer as well as designing and building a printer driving
`
`circuit board for a PDP-11. In 1992 I first encountered Linux, both installing it on
`
`a 486 PC as well as modifying the module loading subsystem for it. In 1998 I
`
`modified Linux to support a proprietary Intel based SMP system designed by NCR
`
`known by the code name Voyager. Part of that experience was integrating the
`
`Linux boot loader into the voyager SUS (Startup Subsystem, a similar system to
`
`BIOS). Part of this experience required mapping the SUS calls to the then standard
`
`BIOS calls that Linux on a PC made. In 2003 I was made Maintainer of the Linux
`
`Storage Subsystem. In 2006 I was appointed to the board of the Linux Foundation
`
`and elected chair of its Technical Advisory Board. In 2011, I became one of the
`
`people responsible for formulating the Linux Response to and Implementation of
`
`Secure Boot for UEFI (a successor system to BIOS) and in 2013, thanks to this
`
`work, I was appointed to the UEFI Security SubTeam which is responsible for
`
`reviewing and advising on all aspects of UEFI security policy. UEFI stands for
`
`
`
`5
`
`
`
`“Unified Extensible Firmware Interface.” The UEFI specification defines a new
`
`model for the interface between personal-computer operating systems and platform
`
`firmware. UEFI represents a community effort by many companies in the
`
`personal-computer industry to modernize the booting process. UEFI Forum is a
`
`world-class nonprofit body overseeing the UEFI standards.
`
`I hold a BA in Natural Science and a PhD in Computational Quantum Field
`
`theory from Cambridge University in the UK. My course studies at both the
`
`undergraduate and graduate level included applied mathematics and computer
`
`programming. I received my B.A. in 1988 and my doctoral degree in 1993.
`
`A PERSON OF ORDINARY SKILL IN THE ART (POSITA)
`
`8.
`
`I am advised and understand that a person of ordinary skill in the art is
`
`a hypothetical person who is presumed to have known the relevant art at the time
`
`of the invention. Factors that may be considered in determining the level of
`
`ordinary skill in the art may include: (1) type of problems encountered in the art;
`
`(2) prior art solutions to those problems; (3) rapidity with which innovations are
`
`made; (4) sophistication of the technology; and (5) educational level of active
`
`workers in the field.
`
`9.
`
`In this case, the 304 Patent reflects the use of cryptographic
`
`approaches to solve problems in computing posed by potentially intrusive attacks.
`
`Cryptography embodies higher level mathematical principles. Known
`
`
`
`6
`
`
`
`cryptographic approaches to remedy potentially invasive computer attacks such as
`
`replay in the prior art included symmetrical and assymetrical systems using public
`
`and/or private keys. In this case, the nature of the computing is BIOS/firmware, so
`
`an understanding of low-level programming would also be helpful to
`
`understanding the 304 Patent.
`
`10.
`
`In my experience, most persons working with cryptography in
`
`computer systems have a technical degree including coursework in applied
`
`cryptographic solutions, whereas most BIOS-related designers and programmers
`
`have a technical degree involving computer science or its equivalent, and at least
`
`two years of experience working with firmware design or programming.
`
`11.
`
`I have been advised and understand that a person having ordinary skill
`
`in the art (“POSITA”) is presumed to be aware of all pertinent art, thinks along
`
`conventional wisdom in the art, and is a person of ordinary creativity.
`
`12. Given the foregoing considerations, my opinion is that a POSITA at
`
`the time of the invention claimed in the 304 Patent is a person having at least a
`
`Bachelor of Science degree (or its equivalent) in a technical field such as electrical
`
`engineering, computer science, applied mathematics or software engineering,
`
`having completed at least basic coursework in regards to basic input/output system
`
`(BIOS) and public key-based cryptography principles, and at least two years of
`
`experience working in firmware computer design or firmware computer
`
`
`
`7
`
`
`
`programming. Of course, this definition has a degree of flexibility within it, such
`
`that a graduate degree in a technical field with more advanced coursework in basic
`
`input/output system (BIOS), firmware and/or public key-based cryptography
`
`principles could offset lesser experience in the field. Likewise, greater experience
`
`in the field could conceivably compensate for a different educational background.
`
`13. At the time of the invention of the 304 Patent, applying the foregoing
`
`definition, I was a POSITA at the time of the invention of the 304 Patent.
`
`14. Throughout the course of my declaration, I refer to what a POSITA
`
`would know, or would have known. In each case, unless I specifically state
`
`otherwise, I intend to refer to what a POSITA knows or would have known at or
`
`before the time of invention of the 304 Patent, which I am advised is June 18,
`
`1999.
`
`MY UNDERSTANDING OF CLAIM CONSTRUCTION
`
`15.
`
`I have been advised and understand that the claims are to be given
`
`their broadest reasonable construction in light of the specification as it would be
`
`read by a POSITA at the time of invention. I am further advised that this principle
`
`is sometimes referred to as the broadest reasonable interpretation, or “BRI”
`
`standard of claim construction.
`
`
`
`
`
`
`
`8
`
`
`
`MY UNDERSTANDING OF ANTICIPATION
`
`16.
`
`I have been advised and understand that a claimed invention is
`
`“anticipated” only if each and every element as set forth in the claim is found
`
`either expressly or inherently described, in a single prior art reference.
`
`17. For purposes of determining whether an element of a claim is found in
`
`a prior art reference, I am advised that an element may be said to be “inherently”
`
`present in a reference if and only if, based on the description in the reference, a
`
`POSITA would conclude that the element was necessarily present in the reference,
`
`even though not explicitly stated. By way of example, if a prior art reference were
`
`to identify a “computer,” and a claim element was a “microprocessor,” the prior art
`
`“computer” could be said to inherently teach a microprocessor because the
`
`computer would necessarily include a microprocessor. This is merely a
`
`hypothetical illustration to elaborate on my understanding of inherency as a
`
`principle in prior art analysis.
`
`MY UNDERSTANDING OF OBVIOUSNESS
`
`18.
`
`I have been advised and understand that a claimed invention is
`
`unpatentable if the differences between the invention and the prior art are such that
`
`the subject matter as a whole would have been obvious at the time the invention
`
`was made to a POSITA to which the subject matter pertains.
`
`
`
`9
`
`
`
`19.
`
`It is my understanding that obviousness is a question of law based on
`
`underlying factual findings: (1) the scope and content of the prior art; (2) the
`
`differences between the claims and the prior art; (3) the level of skill in the art; and
`
`(4) objective considerations of nonobviousness, if there are any.
`
`20.
`
`I understand that for one or more references to render the claimed
`
`invention obvious, a POSITA must have a sufficient reason to combine the
`
`teachings of the references to arrive at the challenged claims. I further understand
`
`that a basis to combine teachings from the references need not be stated expressly
`
`in any prior art reference. However, there must be an articulated reasoning with
`
`rational underpinnings to support a reason to the combine the teachings.
`
`21.
`
`I understand that when considering whether a patent claim is
`
`obviousness, a POSITA should consider whether a teaching, suggestion, or
`
`motivation to combine the references exists so as to avoid impermissibly applying
`
`hindsight.
`
`TECHNICAL ANALYSIS OF THE 304 PATENT
`
`22. The independent claims of the 304 Patent can succinctly be
`
`summarized as applying conventional public-private key authentication to a
`
`message, where the message is a request for BIOS services.
`
`23. The 304 Patent is forthcoming in its statement that it adds nothing
`
`more than conventional authentication algorithms. As an example, the 304 Patent
`
`
`
`10
`
`
`
`defines the “key” to be in accordance with popular, predating algorithms such as
`
`Rivest, Shamir and Adleman (RSA), Data Encryption Algorithm (DEA) as
`
`specified in Data Encryption Standard (DES), and the like. (Ex. 1001, p. 30,
`
`19:39-42).
`
`24. Based on my review of the independent claims, the only difference
`
`between applying an RSA style authentication to a message and the independent
`
`claims, is that the independent claims limit the message to a request for BIOS
`
`services.
`
`25. The field of technology of the 304 Patent can therefore be separated
`
`into two areas: requesting/providing BIOS services, and authenticating said
`
`requests. Each is explored in more detail below.
`
`TECHNICAL EXPLANATION OF A BIOS PRIOR TO THE TIME
`OF INVENTION
`
`26. A BIOS is software enabling a CPU to handle “initialization,
`
`diagnostics, loading the operating system kernel from mass storage, and routine
`
`input/output (I/O) functions.” (Ex. 1001, p.21, 1:65-2:6).
`
`27. A CPU “boots” by fetching instructions from code residing in the
`
`BIOS. (Id. at 2:5-6).
`
`28. More specifically, service requests are made in order to invoke
`
`functions provided by the BIOS. (Id.at 2:8-9).
`
`29. The BIOS includes “configurable sensitive data.” (Id. at 1:63-64).
`
`
`
`11
`
`
`
`30. BIOS is vulnerable to attacks through capturing or replaying service
`
`requests.” (Id. at 2:6-8).
`
`31. At the time of invention, there existed a need to “verify the integrity
`
`of service requests to access or modify data in the BIOS.” (Id. at 2:12-13).
`
`PUBLIC – PRIVATE KEY AUTHENTICATION PRIOR TO THE
`TIME OF INVENTION
`
`
`32. Authentication refers to a process of determining whether a message
`
`was received from a trusted source.
`
`33. Authentication is used for improving computer system security.
`
`34.
`
`In a public-private key cryptographic system used for message
`
`authentication, a digital signature uniquely identifies the sender of a message. (Ex.
`
`1014, p.6, 3:40-52; Ex. 1025, p.8). So if User A wanted to send a signed message
`
`to User B, User A uses his or her private key to sign the message digitally. (Ex.
`
`1014, p.6, 3:40-52; Ex. 1025, p.8). When User B receives the signed message,
`
`User B can verify the message by operating on the signed message with User A's
`
`public key. (Ex. 1014, p.6, 3:40-52; Ex. 25, p.8).
`
`35. Various authentication protocols are recited in the 304 Patent “such as
`
`Rivest, Shamir and Adleman (RSA) [and] Data Encryption Algorithm (DEA) as
`
`specified in Data Encryption Standard (DES).” (Ex. 1001, p.30 , 19:38-41).
`
`
`
`12
`
`
`
`36. Among these protocols, W. Diffie and M. E. Hellman are frequently
`
`credited with inventing public-private key authentication in 1978 as per their U.S.
`
`Pat. No. 4,218,582. (Ex. 1010, p. 9, 2:54-58).
`
`37. Public-private key pairs later became the basis for what is now the
`
`popular RSA algorithm. The algorithm is the subject of U.S. Patent No. 4,405,829
`
`by Rivest, Shamir and Adleman. (Ex. 1014).
`
`38. Using a public key algorithm such as RSA, one can generate two keys
`
`that are mathematically linked: one private and one public. To create a digital
`
`signature, the signing software creates a one-way hash of the electronic data to be
`
`signed. The private key is then used to encrypt the hash.
`
`39. The value of the hash, for all practical purposes, can be treated as
`
`unique to the message. Any change in the data results in a different value. This
`
`attribute enables others to validate the integrity of the data by using the signer's
`
`public key to decrypt the hash. If the decrypted hash matches a second computed
`
`hash of the same data, it proves that the data it unaltered since it was signed.
`
`Conversely, if the two hashes fail to match, this means the data is either tampered
`
`with in some way (and therefore lacks integrity) or the signature was created with a
`
`private key that does not correspond to the public key presented by the signer.
`
`40. This is illustrated further in the following diagram:
`
`
`
`13
`
`
`
`
`
`41. Public-private key authentication has been widely adopted and
`
`standardized since the early 1990‟s. (Ex. 1005; see also Ex. 1025, p.8).
`
`42. As indicated briefly above, when authenticating messages using a
`
`public-private key pair, a private key is generally applied to a message to generate
`
`a digital signature that is included in the message. (Ex. 1025, pp.8).
`
`43. To authenticate the received, signed message, a recipient uses a public
`
`key. (Ex. 1025, p.8).
`
`44.
`
`If authentication is successful, the recipient can validate the sender‟s
`
`identity because the public key used for authentication is uniquely paired with the
`
`private key used to sign the message. (Ex. 1025, pp.5-6).
`
`45. The foregoing conceptual explanation of the use of public-private key
`
`pairs to authenticate messages demonstrates how a POSITA would understand
`
`public-private key authentication at the time of invention. This concept was
`
`
`
`14
`
`
`
`widespread by the 1990‟s, and therefore well-known to a POSITA by the time of
`
`invention of the 304 Patent.
`
`46. The 304 Patent combines the concept of public-private key
`
`authentication with conventional BIOS-related communications. Specifically, the
`
`304 Patent applies standard authentication algorithms to generate a signature for a
`
`BIOS-related service request. The 304 Patent combines the well-known element
`
`of a BIOS service request with a public-private key authentication approach which
`
`applies a standard algorithm such as RSA. (Ex. 1001, p.30, 19:30-60)
`
`47. The 304 Patent approach to security via authenticating BIOS service
`
`requests using key pair authentication techniques teaches an approach to securing a
`
`message (sometimes referred to as asymmetrical key-based cryptography or
`
`private-public key encryption) which at the time was standard in the field.
`
`48. As shown herein through the analysis of the prior art, it was known in
`
`the art before the 304 Patent to combine the standard concepts of BIOS service
`
`requests with standard private-public key encryption. I show this and at least some
`
`of the reasons for the combination of these teachings in my discussion of the prior
`
`art, at paragraphs 66-147 of this declaration. Examples of three case studies
`
`described in prior art references for merging the need for greater security in
`
`connection with BIOS communications and teaching the desirability of private-
`
`public key encryption, include Aegis (Ex. 1006), Drews (Ex. 1007) and the Intel
`
`
`
`15
`
`
`
`Boot Integrity Services specification (“BIS”) (Ex. 1008). I elaborate on these
`
`references below.
`
`MY UNDERSTANDING OF CERTAIN CLAIM TERMS
`
`49.
`
`I have construed the following terms according to their broadest
`
`reasonable construction in light of the specification of the 304 Patent.
`
`“access driver”
`
`50. Under the BRI standard, an “access driver” is at least as broad as “a
`
`software component that generates requests to invoke BIOS services.”
`
`51. The specification of the 304 Patent (Ex. 1001, p. 21, 2:36-37) states:
`
`“Another aspect of the system includes an access driver to generate a service
`
`request to utilize BIOS services.”
`
`52. The access driver, in essence, performs the function of generating
`
`requests. Applying the BRI standard, access driver is at least as broad as “a
`
`software component that generates requests to invoke BIOS services.”
`
`“service request”
`
`53. Under the BRI standard, a “service request” is at least as broad as “a
`
`message that solicits a performance.”
`
`54. The service request, in the content of the claims, seeks performance of
`
`BIOS services. (Ex. 1001, p.21, 2:11-13, and p.30, 20: 25-31).
`
`
`
`16
`
`
`
`55. A POSITA would understand that, under the BRI standard, a service
`
`request may be a message that requests the performance of a read service that
`
`accesses sensitive BIOS data. (Id., p.19, 2:11-13).
`
`56. As another example, a service request may be a message that solicits a
`
`BIOS to perform a write service that updates or modifies sensitive BIOS data. (Ex.
`
`1001, p.30, 20: 25-31).
`
`“to utilize” / “to invoke”
`
`57.
`
`Independent claims 1 and 15 recite: “a service request to utilize BIOS
`
`services” and claim 9 recites “a service request to invoke BIOS services.” While
`
`these are literally different words, in my opinion the practical effect to a POSITA
`
`is the same: the request seeks performance of the service. A POSITA would
`
`understand that performing the requested service means that the service was
`
`invoked and utilized. From the perspective of a POSITA, “to utilize” and “to
`
`invoke” each refer to the ultimate purpose of the service requests – to cause the
`
`performance of BIOS services.
`
`58. As discussed above, the 304 Patent describes examples of BIOS
`
`services to include accessing, updating, or modifying BIOS data. (Ex. 1001, p.19 ,
`
`2:11-13, and p.30, 20:25-31). When any of these services are performed, the
`
`performance implies that the service was invoked and utilized. Accordingly, under
`
`BRI, the claims terms “to utilize” and “to invoke” are met at least when the BIOS
`
`
`
`17
`
`
`
`service request seeks the initiation of performance of BIOS services. As such,
`
`applying BRI, the construction for “to utilize” and “to invoke” is at least as broad
`
`as “to cause performance of the requested BIOS services.”
`
`“service operation code”
`
`59. Under the BRI standard, a “service operation code” is at least as broad
`
`as “an identifier that represents a requested service.”
`
`60. The specification states:
`
`Service operation code 1005 is a numerical value representing one
`
`type of service operation. Illustrative 30 examples of service
`
`operations in one embodiment may include operations to read or write
`
`data stored in nonvolatile memory.
`
`(Ex. 1001, p.31, 22:28-33) (emphasis added).
`
`61. Thus, in operation, a read service for reading/accessing BIOS related
`
`data or instructions may have a particular code identifier and a write service for
`
`updating or modifying BIOS related data or instructions may have a different
`
`identifier.
`
`62.
`
`In view of the specification and the relatively straightforward nature
`
`of the claim term itself, a POSITA would understand that the purpose of the
`
`“service operation code” is to identify the service which is being requested.
`
`
`
`
`
`18
`
`
`
`63. Under the BRI standard, a “session” is at least as broad as a “period of
`
` “session”
`
`active communication.”
`
`64. The specification does not explicitly define “session.” The
`
`specification uses the phrase “session” to convey the notion of communication
`
`between two components in between two points in time, giving the communication
`
`a finite duration of time. (Ex. 1001, p. 30, 20:46-49). Here, the 304 Patent states:
`
`“In a present system, a work session must be established between access driver
`
`1545 and RAPI 1550 before access driver 1545 can send one or more service
`
`requests to RAPI 1550 to utilize BIOS services.” (Ex. 1001, p. 30, 20:46-49).
`
`“authority certificate”
`
`65. Under the BRI standard, an “authority certificate” is at least as broad
`
`as a “digital message from or validated by a trusted authority used to facilitate the
`
`exchange of key-related security data.” This is consistent with the understanding a
`
`POSITA would have of the term at the time of invention. (Ex. 1025, pp.10-11).
`
`The 304 Patent refers to a “certificate” having key and signature-related data. (Ex.
`
`1001, p.30, 19:58-60). A POSITA reading the 304 Patent would understand that
`
`an authority certificate is a mechanism to facilitate the exchange of trusted key-
`
`related security data. A POSITA would further understand that the phrase
`
`“authority certificate” relates to certain key-related data that has been validated or
`
`
`
`19
`
`
`
`“certified” by a trusted third party, such that its contents are known to be
`
`trustworthy. The nature of the key-related data could vary based upon the type of
`
`cryptographic approach employed and based upon the user preference.
`
`OVERVIEW OF OPINIONS OFFERED ON PRIOR ART
`
`66. Having reviewed the 304 Patent and the prior art, it is my opinion that
`
`the 304 Patent merely adapts known digital signature technology (including
`
`cryptographic public and private keys which were well known in in widespread use
`
`at the time of invention) to well-known BIOS service requests having parameters
`
`which include equally well-known operation codes, in order to yield very
`
`predictable results in terms of enhanced security (verifying integrity of messages
`
`seeking BIOS services). To a POSITA at the time of invention, the 304 Patent
`
`claims are obvious, if not anticipated. I elaborate on these opinions in the
`
`following analysis.
`
`PRIMARY REFERENCES
`
`67.
`
`I am going to focus my analysis on two primary references (a)
`
`AMIBIOS and (b) the CCITT Recommendation X.509. I will refer to these two
`
`references as the “Primary References.” AMIBIOS shows certain service requests
`
`to utilize or invoke BIOS services, while CCITT Recommendation X.509
`
`demonstrates the standard teachings of digital signatures and cryptographic key
`
`
`
`20
`
`
`
`pairs discussed above, where the message is signed with the private key, and
`
`validated using the public key.
`
`68. The teachings of the Primary References are very straightforward, and
`
`require little interpretation. In overview, I correlate which of the references teach
`
`which elements of the independent claims.
`
`304 Patent Claims
`
`Primary References
`
`[1P] A system to securely utilize
`Basic Input and Output System
`(BIOS) services, comprising:
`
`
`
`Combination of: (a) AMIBIOS (BIOS
`
`services) and the CCITT
`
`Recommendation X.509 (secure
`
`utilization)
`
`AMIBIOS
`
`
`
`Combination of: (a) AMIBIOS (service
`request) and the CCITT
`Recommendation X.509 (remainder of
`element)
`
`Combination of: (a) AMIBIOS (service
`request) and the CCITT
`Recommendation X.509 (remainder of
`element)
`
`See [1P] of this chart.
`
`[1.1] an access driver to generate a
`service request to utilize BIOS
`services,
`
`[1.2] the service request including a
`service request signature created
`using a private key in a
`cryptographic key pair; and
`
`[1.3] an interface to verify the
`service request signature using a
`public key in the cryptographic key
`pair to ensure the integrity of the
`service request.
`
`[9P] A method to securely invoke
`Basic Input and Output System
`(BIOS) services, comprising:
`
`[9.1] creating a service request to
`
`See [1.1] of this chart.
`
`
`
`21
`
`
`
`invoke BIOS services;
`
`[9.2] signing the service request with
`a service request signature generated
`using a private key in a
`cryptographic key pair; and
`
`[9.3] verifying the service request
`signature using a public key in the
`cryptographic key pair to ensure the
`integrity of the service request.
`
`[15P] A computer program
`embodied on a computer-readable
`medium to securely utilize Basic
`Input and Output System (BIOS)
`services, comprising:
`
`[15.1] an access driver to generate a
`service request to utilize BIOS
`services,
`
`[15.2] the service request including a
`service request signature created
`using a private key in a
`cryptographic key pair; and
`
`[15.3] an interface to verify the
`service request signature using a
`public key in the cryptographic key
`pair to ensure the integrity of the
`service request.
`
`
`
`
`
`See [1.2] of this chart.
`
`See [1.3] of this chart.
`
`See [1P] of this chart.
`
`See [1.1] of this chart.
`
`See [1.2] of this chart.
`
`See [1.3] of this chart.
`
`AMIBIOS describes access drivers and interfaces, elements of the independent
`
`claims 1 and 15. It also teaches service requests to invoke or utilize BIOS services,
`
`elements of independent claims 1, 9 and 15. In the case of AMIBIOS, it also
`
`teaches the service operation code of dependent Claim 11.
`
`
`
`22
`
`
`
`TECHNICAL ANALYSIS OF AMIBIOS
`
` “Access driver” (Claims 1, 15)
`
` “Service requests to [invoke/utilize] BIOS services” (Claims 1, 9 AND
`
`15), AND *
`
` “Service operation code” (Claim 11).
`
`69.
`
`I have reviewed the AMIBIOS 98 Technical Reference. (Ex. 1013,
`
`“AMIBIOS”).
`
`70.
`
`In AMIBIOS, the BIOS is described as resident in ROM. AMIBIOS
`
`further confirms that BIOS is written in Assembly language, which is known to a
`
`POSITA to be a low-level programming language (meaning it is the layer of
`
`software which is closest to the computer hardware).
`
`71. Most programming is currently done using high-level programming
`
`languages, which tend to be easier to read and write. However, unlike Assembly,
`
`these languages need to be compiled (translated into assembly language), or run
`
`through other compiled programs.
`
`72. Using Assembly, AMIBIOS teaches that BIOS service requests may
`
`take the form of service interrupts. (Ex. 1013, pp.8-9). AMIBIOS teaches that
`
`these requests may be software service interrupt requests (id., p.87), or power
`
`management service requests. (Id., p.343).
`
`
`
`23
`
`
`
`73. AMIBIOS states that the OS can send service requests to the BIOS
`
`(Id., p.11), the OS acts as “an access driver to generate a service request to utilize
`
`BIOS services” within the meaning of Claims 1 and 15 of the 304 Patent.
`
`Likewise, it is elemental that an interface would exist to receive incoming service
`
`requests to the BIOS.
`
`74. Here is an example of a service request provided by AMIBIOS to
`
`invoke the keyboard service, which is one of numerous BIOS services identified in
`
`AMIBIOS.
`
`INT 16h ; requests INT 16h Keyboard Service
`
`(Id., p.8). A POSITA would recognize the service interrupts described in
`
`AMIBIOS as service requests “to [utilize/invoke] BIOS services” within the
`
`meaning of Claims 1, 9 and 15 of the 304 Patent. In the latter example of the
`
`interrupt request “INT 16h,” “16h” is further known to a POSITA to be a service
`
`operation code within the meaning of Claim 11 of the 304 Patent, indicating to the
`
`CPU that the operation is the keyboard service. Based on my review of AMIBIOS,
`
`it confirms my understanding that BIOS service requests, including request
`
`parameters such as service operation codes, would have been well-known to a
`
`POSITA at the time of invention.
`
`
`
`
`
`
`
`24
`
`
`
`TECHNICAL ANALYSIS OF CCITT RECOMMENDATION X.509
`
` the [message] including a [message] signature created using a private
`
`key in a cryptographic key pair (Claim 1 and 15)
`
` signing the [message] with a [message] signature generated using a
`
`private key in a cryptographic key pair (Claim 9)
`
` an interface to verify the [message] signature using a public key in the
`
`cryptographic key pair to ensure the integrity of the [message] (Claim 1
`
`and 15)
`
` verifying the [message] signature using a public key in the
`
`cryptographic key pair to ensure the integrity of the service request
`
`(Claim 9)
`
`75.
`
`I have reviewed CCITT Recommendation X.509. (Ex. 1018).
`
`76. CCITT Recommendation X.509 advocates the use of assymetrical
`
`cryptographic authentication practices, including private-public key pairs and
`
`digital signature verification, in order to enhance digital security. (E.g., Ex. 1018,
`
`p.15).
`
`77. Figure 6 of this reference and associated text at p.15 teaches a
`
`message “including a [message\ signature created using a private key in a
`
`cryptographic key pair,” and also teaches “verifying the [message] signature using
`
`
`
`25
`
`
`
`a public key in the cryptographic key pair to ensure the integrity of the [message]”
`
`within the meaning of claims 1, 9 and 15 of the 304 Patent.
`
`78. From the explanation of Figure 6, a POSITA would know that the
`
`“signed information” is any message or other data being sent from a calling entity
`
`through an interface to a recipient entity. A POSITA would desire the digital
`
`signature and asymmetrical key-based authenticatio
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
