`Patent 6,993,658
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`________________
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`_________________
`
`UNIFIED PATENTS, LLC,
`
`Petitioner,
`
`v.
`
`DYNAPASS IP HOLDINGS, LLC
`
`Patent Owner.
`__________________
`
`Inter Partes Review No. IPR2023-00425
`
`Patent No. 6,993,658
`
`PATENT OWNER’S PRELIMINARY RESPONSE TO THE PETITION
`FOR INTER PARTES REVIEW OF U.S. PATENT NO. 6,993,658
`PURSUANT TO 37 C.F.R. § 42.107
`
`Filed on behalf of Patent Owner by:
`
`John Wittenzellner (Reg. No. 61,662)
`1735 Market Street, Suite A #453
`Philadelphia, PA 19103
`
`Todd E. Landis (Reg. No. 44,200)
`2633 McKinney Ave., Suite 130
`Dallas, TX 75204
`
`Mark McCarthy (Reg. No. 69,575)
`601 Congress Ave., Suite 600
`Austin, TX 78701
`
`WILLIAMS SIMONS & LANDIS PLLC
`
`
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`TABLE OF CONTENTS
`
`INTRODUCTION ........................................................................................... 1
`I.
`STATEMENT OF THE PRECISE RELIEF REQUESTED .......................... 3
`II.
`III. THE PETITION SHOULD BE DENIED BECAUSE IT DOES NOT
`ESTABLISH A REASONABLE LIKELIHOOD OF SUCCESS ON
`ANY CHALLENEGED CLAIM. ................................................................... 4
`A. The ’658 Patent ....................................................................................... 4
`B. Level of Ordinary Skill in the Art ........................................................ 11
`C. Claim Construction ............................................................................... 11
`D. Ground 1 – The Combination of Veneklase and Jonsson Does Not
`Render Obvious Claim 5 of the ’658 Patent. ........................................ 11
`
`1.
`
`Independent Claim 5 .................................................................15
`
`i.
`
`ii.
`
`[5.3] “a control module . . . configured to create a
`new password based at least upon a token and a
`passcode” ...........................................................................15
`
`[5.4] “a communication module configured to
`transmit the token to the personal communication
`device through the cell phone network” ...........................22
`
`iii.
`
`[5.5] “an authentication module configured to
`receive the password from the user through a
`secure computer network” .................................................25
`
`iv.
`
`[5.6] “wherein the authentication module activates
`access to the account in response to the password
`and deactivates the account within a predetermined
`amount of time after activating the account” ....................29
`E. Ground 2 – The Combination of Kew and Sormunen Does Not Render
`Obvious Claims 1 and 3-6 of the ’658 Patent. ..................................... 32
`
`1.
`
`Independent Claim 5 .................................................................35
`
`i.
`
`[5.3] “a control module . . . configured to create a
`new password based at least upon a token and a
`
`-i-
`
`
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`passcode, wherein the token is not known to the
`user and wherein the passcode is known to the
`user” ...................................................................................36
`
`ii.
`
`[5.6] “wherein the authentication module . . .
`deactivates the account within a predetermined
`amount of time after activating the account” ....................38
`
`Dependent Claim 6....................................................................43
`
`Independent Claim 1 .................................................................43
`
`2.
`
`3.
`
`i.
`
`[1.2] “receiving a request from the user for a token
`via the personal communication device, over the
`second network” ................................................................43
`
`Dependent Claims 3 and 4 ........................................................47
`4.
`IV. THE PETITION SHOULD BE DENIED BECAUSE THE BOARD
`DOES NOT HAVE JURISDICTION OVER EXPIRED PATENTS. ..........47
`CONCLUSION ..............................................................................................49
`
`
`V.
`
`
`
`
`
`-ii-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`TABLE OF AUTHORITIES
`
`Cases
`In re Ratti,
`270 F.2d 810 (CCPA 1959) ........................................................................... 18, 45
`Intelligent Bio-Systems, Inc. v. Illumina Cambridge, Ltd.,
`821 F.3d 1359 (Fed. Cir. 2016) ............................................................................45
`KSR Int’l Co. v. Teleflex Inc.,
`550 U.S. 398 (2007) .............................................................................................47
`McGinley v. Franklin Sports, Inc.,
`262 F.3d 1339 (Fed. Cir. 2001) ............................................................................24
`Oil States Energy Servs., LLC v. Greene’s Energy Grp., LLC,
`138 S. Ct. 1365 (2018) .........................................................................................48
`Plas-Pak Indus. v. Sulzer Mixpac AG,
`600 F. App’x. 755 (Fed. Cir. 2015) ............................................................... 18, 46
`Other Authorities
`MPEP § 2143.01 ............................................................................................... 18, 45
`
`
`EXHIBIT LIST
`
`Exhibit
`
`2001
`
`Description
`Google Patents webpage for U.S. Patent No. 6,993,658,
`
`https://patents.google.com/patent/US6993658B1/
`
`-iii-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`I.
`
`INTRODUCTION
`
`Dynapass IP Holdings, LLC (“Patent Owner”) respectfully submits this
`
`Preliminary Response (the “Response”) to the Petition for Inter Partes Review of
`
`U.S. Patent No. 6,993,658 (IPR2023-00425, the “Petition” or “Pet.”) filed by
`
`Unified Patents, LLC (“Petitioner”). The ’658 Patent relates to “the authentication
`
`of users of secure systems and, more particularly, the invention relates to a system
`
`through which user tokens required for user authentication are supplied through
`
`personal communication devices such as mobile telephones and pagers.” Ex. 1001
`
`at 1:7-11.
`
`Institution should be denied because the Petition fails to demonstrate a
`
`reasonable likelihood that any challenged claim of the ’658 Patent is unpatentable.
`
`As detailed herein, the combination of references applied by the Petition against the
`
`independent claims of the ’658 Patent has numerous glaring deficiencies. For
`
`example, the independent claims require activation of the user’s account in response
`
`to creation of a new “password” for the user (the “password” in the claims is “based
`
`at least upon a token and a passcode”). The account remains active until the
`
`expiration of “a predetermined amount of time after activating the account.” That
`
`process is depicted in Figure 5, a portion of which is reproduced below:
`
`-1-
`
`
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`Ex. 1001, Fig. 5 (excerpted).
`
`The asserted references do not discuss activation of a user account. Putting
`
`that aside, Petitioner disregards the requirement that activation occurs in response to
`
`creation of a new “password” for the user. Instead, Petitioner incorrectly relies on
`
`steps in the prior art that occur well after the claimed “password” is created:
`
` In Veneklase, Petitioner relies on processes that occur after the user has
`
`received a random code (the alleged “token”), sent it back to the system,
`
`and the system performs a compare operation to determine whether to
`
`grant access; and
`
`-2-
`
`
`
`
`
` In Kew, perhaps recognizing the weakness in its position, Petitioner relies
`
`IPR2023-00425
`Patent 6,993,658
`
`on several processes that occur after the user has received “Code A” (the
`
`alleged “token”), such as when the “security server” performs a compare
`
`operation to determine whether to grant access.
`
`In another example, Petitioner argues that the term “not known to the user” in
`
`the independent claims means that “a POSITA would have understood that the token
`
`would eventually need to be known to the user.” Pet., p. 10 (emphasis added). But
`
`the Petition fails to cite any evidence that the “token” is ever known to the user. That
`
`is because the asserted prior art uses the alleged “token” internally as a variable for
`
`performing calculations, without any need to make the alleged “token” known to the
`
`user.
`
`Finally, institution should be denied because the Board does not have
`
`jurisdiction over expired patents. For these reasons, institution should be denied.
`
`II.
`
`STATEMENT OF THE PRECISE RELIEF REQUESTED
`
`Petitioner asserts that claims 1 and 3-6 of the ’658 Patent are unpatentable
`
`under the following grounds:
`
`
`
`-3-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`Pet., p. 2.
`
`Patent Owner requests that the Board deny institution of the Petition with
`
`respect to all challenged claims and all asserted grounds. A full statement of the
`
`reasons for the relief requested is set forth in Sections III and IV of this Response.
`
`III.
`
`THE PETITION SHOULD BE DENIED BECAUSE IT DOES NOT
`ESTABLISH A REASONABLE LIKELIHOOD OF SUCCESS ON ANY
`CHALLENEGED CLAIM.
`
`As shown below, the Petition fails to demonstrate a reasonable likelihood that
`
`Petitioner would prevail with respect to any claim of the ’658 Patent. The Petition
`
`challenges claims 1 and 3-6 of the ’658 Patent (the “Challenged Claims”). Pet. at 2.
`
`As detailed herein, each proposed Ground fails to disclose key limitations of each
`
`Challenged Claim, so trial should not be instituted.
`
`A. The ’658 Patent
`
`The ’658 Patent, which is titled “Use of Personal Communication Devices for
`
`User Authentication,” was filed on March 6, 2000, and issued on January 31, 2006.
`
`Ex. 1001. The ’658 Patent relates to “the authentication of users of secure systems
`
`and, more particularly, the invention relates to a system through which user tokens
`
`required for user authentication are supplied through personal communication
`
`devices such as mobile telephones and pagers.” Ex. 1001 at 1:7-11.
`
`-4-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`At the time of the claimed inventions, “secure systems”1 used “a user ID and
`
`password pair to identify and authenticate system users.” See id. at 1:13-14.
`
`Although user ID/password pairs were ubiquitous, they suffered from several
`
`shortcomings, as recognized by the inventors of the ’658 Patent:
`
`Passwords created by users are often combinations of words and names,
`which are easy to remember but also easily guessed. Guessing
`passwords is a frequent technique used by “hackers” to break into
`systems. Therefore, many systems impose regulations on password
`formats that require mixtures of letters of different cases and symbols
`and that no part of a password be a word in the dictionary. A user’s
`inability to remember complex combinations of letters, numbers, and
`symbols often results in the password being written down, sometimes
`on a note stuck to the side of a workstation.
`
`Id. at 1:28-38.
`
`The increasing use of remote connectivity at the time of the claimed
`
`inventions further exacerbated the shortcomings of user ID/password pairs. See id.
`
`at 1:20-26. As a result, then-current systems faced several issues:
`
`Present systems face several problems: users dread frequent password
`changes, frequent password changes with hard-to-remember passwords
`inevitably result in users surreptitiously writing down passwords, and
`security is compromised when users write down their passwords.
`
`
`1 The ’658 Patent describes many non-limiting examples of a “secure system,”
`including Novell NetWare-, Microsoft NT-, Windows 2000-, and UNIX/Linux-
`based computers, as well as “any system, device, account, . . . a user account on a
`network of computer workstations, a user account on a website, or a secure area of
`a building.” Ex. 1001 at 1:13-19, 4:13-23.
`
`-5-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`Id. at 1:39-43. Two-factor authentication (a form of multi-factor authentication)
`
`improves user ID/password pairs by adding “unpredictable, one-time-only access
`
`codes.” See id. at 1:49-51. The first factor is “a user passcode or personal
`
`identification number.” See id. at 1:46-47. The second factor is the “unpredictable,
`
`one-time-only access codes.” See id. at 1:49-51. In two-factor authentication,
`
`system access is based upon:
`
` “nonsecret information known to the user, such as the user ID;”
`
` secret information known to the user, such as the passcode;” and
`
` “information provided to the user through an object possessed by the user,
`
`such as the token.”
`
`Id. at 2:11-15.
`
`The ’658 Patent acknowledges the existence of the RSA Security, Inc.
`
`SecurID product at the time of the claimed inventions, but identified significant
`
`deficiencies in the product:
`
`The SecurID product, however, requires users to carry an additional
`item on their person in order to access a secure system. It would be
`advantageous if the benefits of the SecurID system could be achieved
`using a device
`that many users already carry—a personal
`communication device such as a mobile phone or a pager.
`
`Id. at 1:54-59. The ’658 Patent requires the use of a personal communication device,
`
`which teaches away from a separate device like the SecurID product. See id.
`
`-6-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`The ’658 Patent solves the deficiencies of the SecurID product and further
`
`improves two-factor authentication in a unique, novel, non-obvious way. Figure 1
`
`of the ’658 Patent, reproduced below, depicts an embodiment of a user
`
`authentication system (identified as “100” in the figure):
`
`
`
`Id. at Fig. 1; see also id. at 3:31-33.
`
`Authentication system (100) regulates access to secure system (110). Id. at
`
`4:9-13. User authentication server (102) “preferably includes a program or a suite
`
`of programs running on a computer system to perform user authentication services.”
`
`Id. at 4:27-29. “The authentication information preferably includes a user ID 152, a
`
`-7-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`passcode 154 and a user token 156.” Id. at 4:36-39. Tokens are received on the
`
`user’s personal communication device (106), which can be, for example, “a pager or
`
`mobile phone having SMS (short message service) receive capability.” Id. at 4:13-
`
`15.
`
`It is important to be aware of the terminology used by the ’658 Patent. The
`
`“user ID may be publicly known and used to identify the user.” Id. at 4:39-40. The
`
`’658 Patent uses the term “passcode” to refer to what is commonly called a
`
`“password:” “For example, the user 108 can combine a valid, memorized passcode
`
`of ‘abcd’ . . . .” Id. 4:54-55; see also id. at 1:27-29 (“Passwords created by users are
`
`often combinations of words and names, which are easy to remember but also easily
`
`guessed.”), 4:40 (The passcode 154 is preferably secret and known only to the user
`
`108.”). The “token” can be, for example, “a random or pseudo-random sequence of
`
`numbers or digits or both numbers and digits.” Id. at 9:22-24.
`
`The ’658 Patent uses the term “password” to refer to the combination of at
`
`least the “passcode” and a “token.” Id. at 4:52-53 (“In the preferred embodiment,
`
`the user 108 combines the token 156 with the passcode 154 to form a password
`
`158.”). For example, if the passcode is “abcd” and the token is “1234,” the password
`
`could be “abcd1234” or “1234abcd.” See id. at 4:54-56. The components of the
`
`password (e.g., the passcode and token) can be combined or sent to the system as
`
`separate components. See id. at 4:52-65.
`
`-8-
`
`
`
`
`
`Figure 5, reproduced below, depicts an embodiment of how the system
`
`provides tokens and authenticates users.
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`Id. at Fig. 5; see also id. at 3:41-43.
`
`In step 502, the system associates the user’s user ID and passcode with the
`
`user’s personal communication device. Id. at 8:53-60. By doing so, the system
`
`transmits the token only to the associated user. See id. In steps 504, 506, and 508,
`
`-9-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`the system receives a request for a token, determines which user made the request
`
`(i.e., associates the request with a user ID), and generates the token. See id. at 9:3-
`
`27, Fig. 5. Those steps differ from other systems that continually generate access
`
`codes. See, e.g., id. at 1:49-51 (“The SecurID card generates and displays
`
`unpredictable, one-time-only access codes that automatically change every 60
`
`seconds.”). In step 510, the system generates a new “password” based on at least
`
`the “token” and “passcode.” Id. at 9:28-33, Fig. 5. That password is then stored and
`
`the user’s account can be activated if it was deactivated. Id. at 9:34-41, Fig. 5 (step
`
`512).
`
`In step 514, the system transmits the token to the user’s personal
`
`communication device. See id. at 9:44-53, Fig. 5. Claim 1 of the ’658 Patent
`
`requires that the “personal communication device” be “in communication over a
`
`second network, wherein said network is a cell phone network. . . .” Id. at 11:47-50.
`
`Claim 5 requires that the token is transmitted to the “personal communication
`
`device” through a “cell phone network.” Id. at 12:34-36. The claims also require
`
`that the user’s account is deactivated “within a predetermined amount of time” after
`
`the account is activated. Id. at 12:9-13 (claim 1), 12:41-47 (claim 5).
`
`The Patent Office issued the ’658 Patent issued after several office actions.
`
`Since then, the ’658 Patent has been cited by more than 200 patent applications. Ex.
`
`2001, https://patents.google.com/patent/US6993658B1/. Amongst those patent
`
`-10-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`applications are patent applications filed by major industry entities, including IBM
`
`Corporation, Microsoft Corporation, Lucent Technologies, Honeywell International,
`
`Inc., British Telecommunications PLC, AT&T, Visa, and Google Inc. See id. They
`
`also include a patent application filed by JPMorgan Chase Bank, N.A., a defendant
`
`in the parallel district court proceedings in the Eastern District of Texas. See id.
`
`B.
`
`Level of Ordinary Skill in the Art
`
`For the purposes of this Response only, Patent Owner does not dispute the
`
`level of skill of a person of ordinary skill in the art (“POSITA”) identified in the
`
`Petition.
`
`C. Claim Construction
`
`Due to the substantial deficiencies in the Petition, Patent Owner contends that
`
`claim construction is not necessary for the Board to determine that the Petition fails
`
`to demonstrate a reasonable likelihood that any challenged claim of the ’658 Patent
`
`is unpatentable. Patent Owner reserves the right to address claim construction of
`
`any term in the challenged claims if the Board institutes inter partes proceedings.
`
`D. Ground 1 – The Combination of Veneklase and Jonsson Does Not
`Render Obvious Claim 5 of the ’658 Patent.
`
`Petitioner contends that the combination of Veneklase and Jonsson renders
`
`obvious claim 5 of the ’658 Patent. Pet. at 2, 13-46. That combination does not
`
`render obvious claim 5 of the ’658 Patent for at least the following reasons.
`
`-11-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`Veneklase discloses a computer security system including a user’s “computer
`
`406,” a user’s “pager 420,” and a “host computer 402.” Ex. 1005, 7:29-51, Fig. 6.
`
`Figure 6 of Veneklase is reproduced below:
`
`
`
`Ex. 1005, Fig. 6 (annotated and cropped). During an authentication process, the user
`
`transmits a “password” from “computer 406” to “host computer 402.” Ex. 1005,
`
`7:58-8:27. “Host computer 402” then “cross references the received password []
`
`against a pager phone number list” stored within “host computer 402.” Id. The
`
`“pager phone number list” stores the passwords of authorized users and the pager
`
`numbers for the authorized users. See id., 6:10-26, Fig. 5. Assuming the user is an
`
`authorized user, the pager number for user’s “pager 420” would be associated with
`
`-12-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`the user’s “password” in the “pager phone number list.” See id. A “pseudo-random
`
`code” is generated by “host computer 402” and transmitted to user’s “pager 420”
`
`using the pager number in the “pager phone number list” associated with the
`
`“received password.” See id., 8:1-26. Accordingly, Veneklase’s computer security
`
`system needs the user’s “password” to trigger generation of the “pseudo-random
`
`code” and to transmit the “pseudo-random code” to the user’s “pager 420.”
`
`The user’s “pager 420” displays the received “pseudo-random code” to the
`
`user. See id., 8:15-26. The user “enters the [pseudo-random] code he or she has
`
`received from the pager 420” into user “computer 406.” Id. The user-entered
`
`“pseudo-random code” is transmitted “back to computer 402, where it is compared”
`
`with the “pseudo-random code” sent to the user’s “pager 420.” See id. “If the
`
`comparison yields a match, the user 404 is allowed access to computer 402.” Id.,
`
`8:25-27.
`
`Accordingly, Veneklase’s system allows for authentication through user input
`
`of a password and a pseudo-random code at separate times in a two-step process.
`
`This two-step authentication process “ensure[s] that an authorized user of a
`
`computer system is notified that someone or something is seeking access to the
`
`computer system with his or her password . . . [and] allows for multiple levels of
`
`security before access to the computer system is achieved and provides enhanced
`
`security over the prior art.” Ex. 1005, 7:16-28.
`
`-13-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`Jonsson discloses a user authentication apparatus including a “service node
`
`26,” an “authentication center 30,” a “personal unit 20,” and a user “terminal 22.”
`
`See Ex. 1006, 9:1-10:2, Fig. 1. Figure 1 of Jonsson is reproduced below:
`
`
`
`
`
`Ex. 1006, Fig. 1 (annotated). In Jonsson’s authentication process, “authentication
`
`center 30” generates a “challenge code” and sends the “challenge code” to the
`
`“personal unit 20.” Ex. 1006, 9:1-7. When the personal unit 20 receives the
`
`challenge code, “it prompts the user to input a PIN” and “generates a response code”
`
`using a stored algorithm that utilizes the PIN as an input. Id., 9:9-25. But the
`
`“challenge code” is not displayed to the user. See id. Instead, the calculated
`
`“response code” is displayed to the user “for manual input to terminal 22.”
`
`“Terminal 22” transmits the “response code” back to “authentication center 30
`
`-14-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`which may then compare the response code to [an] expected response.” Id., 9:26-
`
`10:1. If there is a match between the received “response code” and the “expected
`
`response,” the “service node 26 permits the user to access the services offered.” Id.
`
`1.
`
`Independent Claim 5
`
`The combination of Veneklase and Jonsson does not render obvious
`
`independent claim 5 because the combination does not teach or suggest the following
`
`elements of the claim.
`
`i.
`
`[5.3] “a control module . . . configured to create a new
`password based at least upon a token and a passcode”
`
`Claim element [5.3] recites “a control module executed on the computer
`
`processor configured to create a new password based at least upon a token and a
`
`passcode, wherein the token is not known to the user and wherein the passcode is
`
`known to the user, the control module further configured to set a password associated
`
`with the user to be the new password.” Petitioner mapped Veneklase’s
`
`“user/password check” module to the claimed “control module” (see Pet., pp. 26-
`
`27), but concedes that Veneklase does not disclose this claim element. See Pet., p.
`
`28 (Veneklase “does not disclose creating a new password based on those two
`
`items.”). Petitioner argues that the combined teachings of Veneklase and Jonsson
`
`meet the requirements of claim element [5.3]. See Pet., pp. 28-34. But Petitioner’s
`
`proposed combination fails to support a conclusion of obviousness for multiple
`
`reasons.
`
`-15-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`Petitioner argues that “Veneklase teaches a system which a user inputs a
`
`password known beforehand, receives a randomly generated previously-unknown
`
`code, and then inputs that [randomly generated code] for authentication purposes.”
`
`Pet. at 31 (citing Ex. 1005, 7:52-8:27). In other words, “Veneklase’s system allows
`
`for authentication through user input of a known and unknown code at separate times
`
`in a two-step process.” Id. (emphasis added).
`
`Jonsson discloses an authentication process in which a “personal unit 20
`
`receives an authentication challenge code, it prompts the user to input a PIN or other
`
`identifying information, and generates a response code by an algorithm having the
`
`challenge code . . . and the PIN.” See Ex. 1006, 9:1-13. This response code is then
`
`“displayed on a display unit [of personal unit 20] for manual input to [user’s]
`
`terminal,” and then transmitted from the user’s terminal to the system for
`
`comparison with an expected response code. Id., 9:26-35.
`
`Petitioner’s proposed combination includes replacing Veneklase’s two-step
`
`authentication process (i.e., user transmission of Veneklase’s password, and
`
`subsequent user transmission of Veneklase’s random code) with the single step in
`
`Jonsson (i.e., user transmission of Jonsson’s response code). See Pet. at 28
`
`(“Veneklase teaches an authentication system in which the user inputs both a token
`
`. . . and a passcode . . . it would have been obvious to combine those two steps and
`
`instead create a new password based on both of them”) (emphasis added), 31 (“A
`
`-16-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`POSITA would have been motivated to make such a combination because having
`
`only the one password transmitted via the computer system is more efficient and
`
`secure . . . Veneklase’s system allows for authentication through user input of a
`
`known and unknown code at separate times in a two-step process, while a POSITA
`
`would look to Jonsson because it would provide the added benefit of reducing the
`
`steps to a single step”) (emphasis added), 34 (“A POSITA would have had a
`
`reasonable expectation of success in modifying Veneklase’s authentication system,
`
`which requires the use of both a known password and a previously-unknown
`
`randomly generated code, to create a new password based on those two values . . .
`
`because doing so would have merely made two steps into one without requiring any
`
`additional hardware.”) (emphasis added).
`
`But modifying Veneklase’s system by abolishing the two-step authentication
`
`process, as proposed by Petitioner, would violate Veneklase’s principle of operation.
`
`Veneklase’s two-step authentication process “ensure[s] that an authorized user of a
`
`computer system is notified that someone or something is seeking access to the
`
`computer system with his or her password . . . [and] allows for multiple levels of
`
`security before access to the computer system is achieved and provides enhanced
`
`security over the prior art.” Ex. 1005, 7:16-28. Accordingly, this two-step
`
`authentication process is a key feature of Veneklase’s principle of operation, and a
`
`POSITA would not seek to remove steps as Petitioner proposes. See id.
`
`-17-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`Accordingly, the proposed modification of Veneklase is far too drastic to be
`
`considered obvious, and thus the combination of Veneklase and Jonsson fails to
`
`render claim 5 obvious. See MPEP § 2143.01(VI) (citing In re Ratti, 270 F.2d 810,
`
`813 (CCPA 1959)) (“If the proposed modification or combination of the prior art
`
`would change the principle of operation of the prior art invention being modified,
`
`then the teachings of the references are not sufficient to render the claims prima facie
`
`obvious.”); see also Plas-Pak Indus. v. Sulzer Mixpac AG, 600 F. App’x. 755, 758
`
`(Fed. Cir. 2015) (“combinations that change the basic principles under which the
`
`[prior art] was designed to operate or that render the prior art inoperable for its
`
`intended purpose may fail to support a conclusion of obviousness.”) (cleaned up).
`
`Petitioner also argues, contrary to its previous argument, that “a POSITA
`
`would have been motivated to make such a combination because implementing
`
`Veneklase’s authentication system with the algorithm of Jonsson’s system provides
`
`an additional layer of security . . . a POSITA would have been motivated to use an
`
`algorithm for creating a new password based on the known password and the
`
`previously-unknown randomly generated code, such as described in Jonsson, to
`
`provide additional security.” Pet., pp. 31-32 (emphasis added). But Petitioner
`
`argued that a POSITA would have been motivated to reduce the number of steps in
`
`Veneklase. See Pet. at 31 (“a POSITA would look to Jonsson because it would
`
`provide the added benefit of reducing the steps to a single step.”) (emphasis added).
`
`-18-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`Moreover, Veneklase’s two-step authentication process already “allows for multiple
`
`levels of security before access to the computer system is achieved.” Ex. 1005, 7:26-
`
`27. For example, Veneklase’s system does not transmit the randomly generated code
`
`to the user until Veneklase’s password is received from the user (i.e., the first step in
`
`the two-step authentication process) and “cross reference[d] . . . against a pager
`
`phone number list resident within the user table 414.” Ex. 1005, 8:2-5. Petitioner
`
`concedes as much. See Pet., p. 42 (“Veneklase discloses that this system is
`
`implemented only when the password is found within the master password list.”)
`
`(emphasis added). Veneklase identifies the two-step process as providing a security
`
`benefit: should a hacker or other unauthorized user gain access to the user’s
`
`password, this first step in Veneklase’s system also has the added bonus of notifying
`
`the user “that someone or something is seeking access to the computer system with
`
`his or her password.” See Ex. 1005, 7:16-21.
`
`Petitioner’s proposed combination dismantles Veneklase’s existing multi-
`
`level security by discarding user transmission of the password and thus discarding
`
`the cross-referencing security feature and notification feature. Petitioner provides
`
`zero evidence that the security of its proposed combination is superior to the existing
`
`multi-layer/level security in Veneklase. Accordingly, there is no motivation to
`
`combine Veneklase and Jonsson.
`
`-19-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`
`Petitioner also argues that combining the algorithm of Jonsson with Veneklase
`
`would thwart “SIM swapping” attacks. Pet., p.32. The Petition contends that “SIM
`
`swapping is a well-known trick of hackers in which they contact your service
`
`provider and activate a new SIM card on a different device in order to receive the
`
`user’s authentication token.” Id. at 32. It further contends that SIM swapping
`
`“would not work in the combined system, because [hackers] would need access to
`
`the device containing the correct algorithm.” Id. But SIM swapping would also not
`
`work in Veneklase’s existing system because the hackers would still need
`
`Veneklase’s password. Accordingly, there is no motivation to combine Veneklase
`
`and Jonsson.
`
`Petitioner also argues that “Veneklase explicitly provides a teaching,
`
`suggestion, and motivation for combining it with an authentication system that uses
`
`an algorithm, such as taught in Jonsson, because it explicitly discloses embodiments
`
`in which datastreams are encoded and decoded using algorithms for additional
`
`security.” Pet., p. 32 (citing Ex. 1005, 9:26-10:11). The Petition fails to describe
`
`that “algorithm” in any detail, which is not surprising, because the section of
`
`Veneklase cited by Petitioner does not pertain to an algorithm.
`
`The portion of Veneklase cited by Petitioner discloses “a commercially
`
`available one input and two channel output time division or statistical multiplexor
`
`which samples the bits of [] data and places, in a certain predetermined manner (e.g.
`
`-20-
`
`
`
`IPR2023-00425
`Patent 6,993,658
`
`
`alternately) some of the [] data bits onto the first communications channel 76 [for
`
`transmission to a receiver] and some of the [] data bits onto the second
`
`communications channel 78 [for transmission to the receiver].” Ex. 1005, 8:35-41.
`
`The receiver “contains [a] ‘mirror image’ of the algorithm used to divide the data
`
`stream . . . In this manner, the data from each of the channels 76,78 is reconstituted
`
`[at the receiver] onto single channel 89.” Ex. 1005, 8:53-57. In other words, the
`
`“algorithm” disclosed in Veneklase does