UNITED STATES PATENT AND TRADEMARK OFFICE
`
`____________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`AIRE TECHNOLOGY LIMITED,
`Patent Owner
`______________
`
`IPR2022-01137
`Patent No. 8,581,706
`____________
`
`
`PATENT OWNER’S SUR-REPLY
`
`
`
`
`
`
`
`
`
`____________
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`____________
`
`APPLE INC.,
`Petitioner,
`
`v.
`
`AIRE TECHNOLOGY LIMITED,
`Patent Owner
`______________
`
`IPR2022-01137
`Patent No. 8,581,706
`____________
`
`
`PATENT OWNER’S SUR-REPLY
`
`
`
`
`
`
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`
`Table of Contents
`
`Introduction ....................................................................................................... 1
`I.
`II. The Petition’s Lack of Supporting Evidence .................................................... 2
`III. The Petition Does Not Establish That A POSITA Would Have
`Been Motivated To Combine Guthery With Nozawa ....................................... 6
`IV. The Petition Does Not Establish That A POSITA Would Have
`Been Motivated To Combine Guthery With RFID Handbook ....................... 17
`V. Conclusion ...................................................................................................... 18
`
`
`
`
`
`i
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`
`Table of Authorities
`
`Cases
`
`Application of Wesslau,
`353 F.2d 238 (C.C.P.A. 1965) ............................................................................. 11
`
`
`MobileMedia Ideas LLC v. Apple Inc.,
`780 F.3d 1159 (Fed. Cir. 2015) ............................................................................. 4
`
`
`Skky, Inc. v. MindGeek, s.a.r.l.,
`859 F.3d 1014 (Fed. Cir. 2017) ............................................................................. 4
`
`
`Smartmatic USA Corp. v. Election Sys. & Software,
`IPR2019-00527, Paper 32 (Aug. 5, 2020) ............................................................. 4
`
`
`TQ Delta, LLC v. CISCO Sys., Inc.,
`942 F.3d 1352 (Fed. Cir. 2019) ............................................................................. 4
`
`
`Xerox Corp. v. Bytemark, Inc.,
`IPR2022-00624, Paper 12 (PTAB Feb. 10, 2023) ................................................ 3
`
`
`Xerox Corp. v. Bytemark, Inc.,
`IPR2022-00624, Paper No. 9 (PTAB Aug. 24, 2022) (precedential) ............. 3, 14
`
`
`
`
`
`
`
`
`ii
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`
`Exhibits
`
`Description
`
`Notice of IPR Petitions, Aire Technology Ltd. v. Apple Inc., Case No.
`6:21-cv-01101-ADA, Dkt. No. 37 (W.D. Tex. Jun. 24, 2022)
`Amended Scheduling Order, Aire Technology Ltd. v. Apple Inc., Case
`No. 6:21-cv-01101-ADA, Dkt. No. 61 (W.D. Tex. Sep. 21, 2022)
`Law360 Article: West Texas Judge Says He Can Move Faster Than
`PTAB
`Text Order Denying Motion to Stay Pending IPR, Solas OLED Ltd. v.
`Google, Inc., Case No. 6:19-cv-00515-ADA (W.D. Tex. June 23,
`2020)
`Order Denying Motion to Stay Pending IPR, Multimedia Content
`Management LLC v. DISH Network L.L.C., Case No. 6:18-cv-00207-
`ADA, Dkt. No. 73 (W.D. Tex. May 30, 2019)
`Standing Order Governing Proceedings in Patent Cases, Judge Alan
`D. Albright
`Claim Construction Order, Solas OLED Ltd. v. Apple Inc., Case No.
`6:19-cv-00537-ADA, Dkt. No. 61 (W.D. Tex. Aug. 30, 2020)
`Plaintiff Aire Technology Ltd.’s Preliminary Disclosure of Asserted
`Claims and Infringement Contentions to Apple Inc. in Aire
`Technology Ltd. v. Apple Inc., Case No. 6:21-cv-01101-ADA (W.D.
`Tex.)
`Defendant Apple Inc.’s Preliminary Invalidity Contentions in Aire
`Technology Ltd. v. Apple Inc., Case No. 6:21-cv-01101-ADA (W.D.
`Tex.)
`September 30, 2021 Federal District Court Trial Statistics
`December 31, 2021 Federal District Court Trial Statistics
`March 31, 2022 Federal District Court Trial Statistics
`
`iii
`
`
`
`Exhibit
`No.
`2001
`
`2002
`
`2003
`
`2004
`
`2005
`
`2006
`
`2007
`
`2008
`
`2009
`
`2010
`2011
`2012
`
`
`
`
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`
`I.
`
`Introduction
`
`As explained in the Patent Owner’s Response, Petitioner’s Grounds 1 and 2
`
`challenges to independent claims 1 and 11, as well as the claims depending
`
`therefrom, fail because a POSITA would not have been motivated to modify
`
`Guthery’s smart card system in view of Nozawa. A POSITA would understand that
`
`the proposed combination would be detrimental to Guthery because, for example, it
`
`contradicts Guthery’s stated goal of tightly coupling the execution of applications
`
`and thereby communication with them with efficient management of the smart
`
`card’s limited RAM memory. To process multiple-packet inputs requested by a
`
`host, a requisite aspect of the operation of Guthery’s smart card, an application
`
`determines “how many packets to expect and therefore how many permissions to
`
`send it must grant to the host to receive the entire message.” Ex. 1005, 13:1-4.
`
`Because Petitioner’s proposed combination with Nozawa would deprive the
`
`application of the ability to make this determination, the proposed combination
`
`renders Guthery’s smart card system inoperable for its intended purpose. A POSITA
`
`would thus not have been motivated to make the proposed combination.
`
`Petitioner’s Ground 2 challenge to dependent claim 16 and the Ground 4
`
`challenge to independent claim 20 also fail because a POSITA would not have been
`
`motivated to modify Guthery’s smart card system in view of RFID Handbook. The
`
`Petition generically asserts that Guthery’s smart card would benefit from improved
`
`
`
`1
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`security by dividing Guthery’s EEPROM memory into segments such that each
`
`application corresponds to its own segment. As explained in the Patent Owner’s
`
`Response, all data communicated between the smart card and the host passes through
`
`Guthery’s RAM memory. Contrary to Petitioner’s assertions, because the RAM
`
`memory is shared across all of the applications on the smart card, it cannot be
`
`segmented. Guthery’s smart card would therefore still be subject to security issues
`
`with respect to the data communicated between the smart card and the host. A
`
`POSITA would thus not have been motivated to make the proposed combination.
`
`For these reasons, the Petition cannot show any challenged claim in Ground 2 or
`
`Ground 4 to be unpatentable.
`
`II. The Petition’s Lack of Supporting Evidence
`
`Petitioner contends that “[t]hroughout its Response, Patent Owner presents
`
`technical arguments related to aspects of the proposed obviousness combination, ….
`
`[but] does not rely upon any evidence—declaration or otherwise—for support.”
`
`Reply at 13. Petitioner therefore concludes that, “[w]ithout supporting evidence,
`
`Patent Owner’s Response amounts to nothing more than attorney argument that is
`
`insufficient to rebut the Petition’s expert-supported positions.” Id. Petitioner is
`
`mistaken because the Petition does not really offer any “expert-supported positions.”
`
`Because the Petition is based on nothing more than “unsupported” attorney
`
`argument, this argument is specious at best and hypocritical at worst.
`
`
`
`2
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`At every relevant turn, the declaration of Dr. Joshua Phinney, Ex. 1003,
`
`submitted in “support” of the Petition is either identical or substantially identical
`
`(when the declaration recites in toto a cited reference passage). The declaration
`
`diverges slightly in only a few instances. As is evident, the declaration is merely
`
`repeating verbatim the assertion in the Petition it purportedly supports. In the table
`
`set forth at the end of this Section II is a table summarizing the corresponding
`
`identical (or nearly identical), or substantially identical paragraphs in Dr. Phinney’s
`
`declaration and the Petition, as well as any exceptions thereto, for the relevant
`
`sections discussed in the Patent Owner’s Response.
`
`Dr. Phinney “does not cite to any additional supporting evidence or provide
`
`any technical reasoning to support his statement[s],” all of which bear the hallmark
`
`of being copied and pasted from the draft of the Petition. Xerox Corp. v. Bytemark,
`
`Inc., IPR2022-00624, Paper No. 9 at 15 (PTAB Aug. 24, 2022) (precedential).
`
`“Thus, the cited declaration testimony is conclusory and unsupported, adds little to
`
`the conclusory assertion for which it is offered to support, and is entitled to little
`
`weight.” Id. In Xerox, on sua sponte review, the Director affirmed the decision to
`
`deny institution of an inter partes review. Xerox Corp. v. Bytemark, Inc., IPR2022-
`
`00624, Paper 12 (PTAB Feb. 10, 2023). In doing so, the Director emphasized that
`
`the rationale set forth in the petitioner’s expert declaration “is an exact restatement
`
`
`
`3
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`of the [p]etition’s arguments without any additional supporting evidence or
`
`reasoning.” Id. at 4.
`
`As set forth above, these are the same circumstances. “[T]he Board was
`
`correct in giving little weight to [p]etitioner’s expert because the expert declaration
`
`merely offered conclusory assertions without underlying factual support.” Id. at 5;
`
`see also Smartmatic USA Corp. v. Election Sys. & Software, IPR2019-00527, Paper
`
`32 at 34 (Aug. 5, 2020) (giving no weight to an expert declaration that “merely
`
`parrots the language in the Petition”); Skky, Inc. v. MindGeek, s.a.r.l., 859 F.3d 1014,
`
`1022 (Fed. Cir. 2017) (the Board is “not required to credit [a party’s] expert evidence
`
`simply because [the party] offered it”); TQ Delta, LLC v. CISCO Sys., Inc., 942 F.3d
`
`1352, 1359 (Fed. Cir. 2019) (“This court’s opinions have repeatedly recognized that
`
`conclusory expert testimony is inadequate to support an obviousness determination
`
`on substantial evidence review.”); MobileMedia Ideas LLC v. Apple Inc., 780 F.3d
`
`1159, 1172 (Fed. Cir. 2015). Consequently, Dr. Phinney’s declaration should be
`
`given no weight. Petitioner is therefore mistaken in its assertion that the Patent
`
`Owner’s Response is insufficient to rebut the positions set forth in the Petition.
`
`
`
`4
`
`
`
`Table of Relevant Identical Paragraphs in Petition and Declaration
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`
`Summary of Guthery (Petition at 24-29, Ex. 1003, ¶¶ 37-44)
`- Ex. 1003, ¶ 37 substantially identical to Petition at 24-25
`- Ex. 1003, ¶ 38 substantially identical to Petition at 25
`- Ex. 1003, ¶ 39 identical to Petition at 25
`- Ex. 1003, ¶ 40 identical to Petition at 26-27
`- Ex. 1003, ¶ 41 substantially identical to Petition at 27
`- Ex. 1003, ¶ 42 substantially identical to Petition at 28
`- Ex. 1003, ¶ 43 identical to Petition at 28-29
`- Ex. 1003, ¶ 44 substantially identical to Petition at 29
`Summary of Nozawa (Petition at 29-30, Ex. 1003, ¶¶ 45-49)
`- Ex. 1003, ¶ 45 substantially identical to Petition at 29
`- Ex. 1003, ¶ 46 substantially identical to Petition at 29-30
`- Ex. 1003, ¶ 47 identical to Petition at 30
`- Ex. 1003, ¶ 48 identical to Petition at 30
`- Ex. 1003, ¶ 49 identical to Petition at 30
`Reasons to Combine Guthery and Nozawa
`(Petition at 30-35, Ex. 1003, ¶¶ 50-60)
`- Ex. 1003, ¶ 50 identical to Petition at 30-31
`- Ex. 1003, ¶ 51 substantially identical to Petition at 31
`- Ex. 1003, ¶ 52 substantially identical to Petition at 31-32
`- Ex. 1003, ¶ 53 identical to Petition at 32
`- Ex. 1003, ¶ 54 identical to Petition at 32-33
`- Ex. 1003, ¶ 55 identical to Petition at 33
`- Ex. 1003, ¶ 56 identical to Petition at 33-34
`- Ex. 1003, ¶ 57 is unique to the exhibit and is not cited in Petition
`- Ex. 1003, ¶ 58 identical to Petition at 34
`- Ex. 1003, ¶ 59 identical to Petition at 35
`- Ex. 1003, ¶ 60 identical to Petition at 35
`
`
`
`5
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`
`Table of Relevant Identical Paragraphs in Petition and Declaration
`
`Summary of the RFID Handbook (Petition at 64-66, Ex. 1003, ¶¶ 114-119)
`- Ex. 1003, ¶ 114 substantially identical to Petition at 64
`- Ex. 1003, ¶ 115 substantially identical to Petition at 64-65
`- Ex. 1003, ¶ 116 identical to Petition at 65-66
`- Ex. 1003, ¶ 117 identical to Petition at 66
`- Ex. 1003, ¶ 118 identifies background art and is cited in Petition at 23
`- Ex. 1003, ¶ 119 identifies background art and is cited in Petition at 23
`Reasons to Combine the RFID Handbook with Guthery and Nozawa
`(Petition at 66-70, Ex. 1003, ¶¶ 120-126)
`- Ex. 1003, ¶ 120 identical to Petition at 66
`- Ex. 1003, ¶ 121 identical to Petition at 66-67
`- Ex. 1003, ¶ 122 identical to Petition at 67-68
`- Ex. 1003, ¶ 123 substantially identical to Petition at 68
`- Ex. 1003, ¶ 124 identical to Petition at 68
`- Ex. 1003, ¶ 125 identical to Petition at 68-69
`- Ex. 1003, ¶ 126 identical to Petition at 69-70
`
`III. The Petition Does Not Establish That A POSITA Would Have Been
`Motivated To Combine Guthery With Nozawa
`Petitioner asserts that “Patent Owner’s arguments fail because they rely on a
`
`strawman version of the combination proposed by the Petition and ignore the actual
`
`teachings of Guthery.” Reply at 1. Petitioner contends that Patent Owner’s
`
`arguments are based on an “alternative embodiment in Guthery that is not part of the
`
`proposed combination,” id. at 4 (emphasis in original), as opposed to the “main
`
`embodiment” upon which Petitioner relies. Id. Petitioner is again incorrect.
`
`An examination of Guthery shows that the term “embodiment” is used loosely
`
`to refer to the specific implementation of aspects or features of Guthery’s invention.
`
`
`
`6
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`As a first example, Guthery states that “[i]n one embodiment, upon the start of a
`
`usage session, an application-identification packet for each application on the smart
`
`card is sent to the host…” Ex. 1005, 3:35-37. At column 8, “several key packet
`
`types are discussed,” including the “Application-Identification packet of the present
`
`invention.” Id., 8:25-26, 8:30-32. “When a smart card is electrically activated, for
`
`example at the start of a usage session or when a mobile telephone is switched on,
`
`the card manager 34 sends to the host computer an application-identification packet
`
`60 for each application 32 on the smart card that identifies the application.” Id.,
`
`8:32-36. Guthery further notes that “[i]n one embodiment of the present invention,
`
`application index 0 [zero] is reserved for the card manager 34 itself.” Id., 8:49-50.
`
`Guthery does not disclose any other form of the application-identification packet or
`
`an application index other than 0 (zero) for the card manager and, thus, does not
`
`differentiate between a preferred (or “main”) embodiment and an alternative
`
`embodiment.
`
`As a second example, Guthery describes that “FIG. 5 is a schematic diagram
`
`illustrating a packet as employed by an embodiment of the present invention.” Id.,
`
`7:51-52. “The first byte of an incoming packet 50 holds the application index 52 of
`
`the application 32 for which the packet is intended.” Id., 7:52-55. “The second byte
`
`contains a packet type field 56 that indicates the type of the packet. In addition, the
`
`high bit 54 of the second byte holds the value 1 to indicate that this packet is not the
`
`
`
`7
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`last packet of a series of packets comprising this data transfer. If the high bit 54 is
`
`0, then this is last packet, and perhaps the only packet, of the data transfer.” Id.,
`
`7:57-61. “The remaining bytes, if any, contain the actual data 58 being sent to or
`
`from the smart card application.” Id., 7:66-67. As with the “application-
`
`identification packet,” Guthery does not describe any other packet structure, yet ties
`
`the packet structure to “an embodiment of the present invention.” Again, Guthery’s
`
`use of “embodiment” does not differentiate between a preferred (or “main”)
`
`embodiment and an alternative embodiment. Moreover, as will be discussed, infra,
`
`the packet structure described with respect to Fig. 5 allows for transmission of not
`
`only a single packet as part of the communication between host and application, but
`
`also many packets that form a “packet chain.” See id., 7:62-6, 8:1-6, Fig. 6.
`
`In addition to these examples, Guthery’s specification ubiquitously uses “an
`
`embodiment,” “one embodiment,” or “further embodiment” all to describe the
`
`features/aspects of the “present invention.” See id., 3:58, 4:1, 4:20, 4:31, 4:48, 4:63,
`
`4:66, 7:9-10, 7:43, 8:67, 8:55, 9:38-39, 10:10, 11:52, 12:11-12, 12:19-20, 12:56,
`
`12:62, 12:65, 13:23, 13:45, 14:41, 14:65, 15:8, 15:21, 15:37, 15:48, 16:40. In no
`
`instance does Guthery differentiate between a preferred (or “main”) embodiment
`
`and an alternative embodiment. Petitioner’s contention to the contrary does not
`
`withstand scrutiny. This is especially true with respect to Guthery’s numerous
`
`exemplary timelines related to data transfer between the host and an application. In
`
`
`
`8
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`each instance, Guthery specifically refers to the timelines in the figures as
`
`“illustrating the operation of an embodiment” for an exemplary case:
`
`• “FIG. 14 … illustrating the operation of an embodiment of the present
`
`invention for the simple exemplary case of a host communicating with
`
`one application on the smart card.” Id., 12:17-21;
`
`• “FIG. 15 … illustrating the operation … of an embodiment of the
`
`present
`
`invention
`
`for an exemplary case of simultaneous
`
`communication between a host and two applications, Application M
`
`and Application N, on the smart card.” Id., 12:54-59;
`
`• “FIG. 16 … illustrating the operation … of an embodiment of the
`
`present invention for an exemplary case of communication between a
`
`host and a single application that provides a multi-packet chained
`
`response.” Id., 12:60-64;
`
`• “FIG. 17 … illustrating the operation … of an embodiment of the
`
`present invention for an exemplary case of communication with a
`
`single application using a multi-packet input and multi-packet output
`
`where the entire message, comprising two packets is received before
`
`processing by the smart card.” Id., 13:21-26; and
`
`• “FIG. 18 … illustrating the operation … of an embodiment of the
`
`present invention for an exemplary case of communication with a
`
`
`
`9
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`single application using a multi-packet input and multi-packet
`
`response, where message parts are processed by the smart card as they
`
`are received.” Id., 13:43-49.
`
`In its Reply, Petitioner urges the Board to exclude Figs. 17-18 because they
`
`are “an alternative embodiment” which renders the inclusion of message size in the
`
`Request-to-Send packet “optional.” Reply at 7. Petitioner would have the Board
`
`rely solely on Figs. 14-15, as set forth in the Petition (pp. 28-29, 31, 34). But Figs.
`
`14-15 are limited to a single packet transferred from the host to smart card
`
`application,1 and vice versa.2 But, as explained above with respect to Fig. 5, Guthery
`
`does not contemplate communications between the host and individual applications
`
`using only single packets. See also id., 2:60-63 (“Packets comprising partial
`
`communication with multiple, concurrently running applications on the smart card
`
`can be intermixed on the single physical communication channel with the card.”).
`
`Consequently, Guthery describes
`
`the exemplary cases
`
`for multi-packet
`
`communication in addition to single-packet communications. Petitioner cannot
`
`
`
` 1
`
` See Fig. 14B (single packet data message sent from host to Application M at Step
`220); Fig. 15B (single packet data message sent from host to Application M at Step
`330); Fig. 15C (single packet data message sent from host to Application N at Step
`350).
`2 See Fig. 14B (single packet response from Application M output from buffer at 244
`and received by host at Step 246); Fig. 15D (single packet response from Application
`M output from buffer at 372 and received by host at Step 376; single packet response
`from Application N output from buffer at 386 and received by host at Step 388).
`
`
`
`10
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`“pick and choose from any one reference only so much of it as will support a given
`
`position, to the exclusion of other parts necessary to the full appreciation of what
`
`such reference fairly suggests to one of ordinary skill in the art.” Application of
`
`Wesslau, 353 F.2d 238, 241 (C.C.P.A. 1965).
`
`First, Fig. 16 illustrates a single packet data message sent from host to
`
`Application M, see id., Fig. 16 at Step 420, which is followed by the first packet of
`
`the response from Application M that is output from buffer and received by host, see
`
`id., Fig. 16 at Steps 440, 442, followed by the second packet of the response from
`
`Application M that is output from buffer and received by host, see id., Fig. 16 at
`
`Steps 448, 450.
`
`Guthery then describes the requirements for multi-packet input – “the original
`
`request to send packet contains an indication of the size of the message, e.g., the total
`
`number of bytes that the host seeks to send to an application.” Id., 12:65-13:1.
`
`“Because packets are a fixed size, the application can determine how many packets
`
`to expect and therefore how many permissions to send it must grant to the host to
`
`receive the entire message.” Id., 13:1-4. This is not “optional” as Petitioner
`
`contends, but the requisite disclosure for Guthery’s smart card applications to
`
`receive and process a “packet chain” from the host. “[A]n application may require
`
`only one buffer or it may need to have a number of blocks sufficient to handle the
`
`entire request allocated at one time to process the request.” Id., 13:8-10. For the
`
`
`
`11
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`instance where the application needs to have the blocks for the entire message
`
`allocated at one time, Guthery provides the example of message encryption where
`
`the encryption is dependent upon the whole message. See id., 13:26-30. Because
`
`“[n]either the sender for [sic, nor] the operating system can know which of these two
`
`cases apply in any particular situation … it is up to the smart-card application to
`
`strobe the packets onto the card one at a time.” Id., 13:11-14.
`
`Guthery illustrates both scenarios in timelines. First, Fig. 17 illustrates the
`
`“case of communication with a single application using a multi-packet input and
`
`multi-packet output where the entire message, comprising two packets is received
`
`before processing by the smart card.” Id., 13:21-26:
`
`In the example of FIG. 17, a first request to send (RTS) is sent to the
`host at step 802. When a permission to send (PTS) is received (step
`818), the host sends the first packet of the message (step 820). After
`receiving the first packet (step 826), the application sends out a second
`PTS (step 828). Upon receipt of the second PTS (step 832), the host
`sends the second packet to the application (step 834).
`When the application receives the second packet of the message (step
`840), it then processes the message (steps 844, 848) and finally outputs
`its multi-packet response at steps 882 and 890.
`Id., 13:31-42.
`
`Next, Fig. 18 illustrates the “case of communication with a single application
`
`using a multi-packet input and multi-packet response, where message parts are
`
`processed by the smart card as they are received.” Id., 13:46-49:
`
`
`
`12
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`In this case, a first request to send (RTS) is sent from the host at step
`902. The application immediately asks for enough buffers to process a
`first packet (step 908), and when the requested number of buffers is
`provided (step 912), the application sends a permission to send (PTS)
`to the host (step 914).
`Upon receipt of the PTS (step 918), the host sends the first packet of
`the message to the application (step 920). When the application receives
`the first packet (step 926), it processes the packet immediately (step
`930) and then requests the next packet by sending another PTS to the
`host (step 934).
`When the host receives this second PTS (step 938), it sends the second
`packet of the message (step 940). When the application receives the
`second packet (step 946), it processes the message (steps 950, 954).
`Upon completion of the processing, two packets are output to the host
`(steps 958, 966).
`Id., 13:53 – 14:3.
`
`Petitioner argues that Guthery’s system “would preemptively prepare the
`
`buffers and transmit the Permission-to-Send packet without waiting to receive the
`
`Request-to-Send packet.” Reply at 9 (citing Petition at 35). Petitioner again ignores
`
`that Guthery “tightly couples
`
`the execution of applications and
`
`thereby
`
`communication with them with efficient management of the smart card’s limited
`
`RAM memory.” Ex. 1005, 2:54-58. As detailed in the Patent Owner Response with
`
`respect to the tight coupling of application execution and communication, an
`
`application on Guthery’s smart card determines “how many packets to expect and
`
`therefore how many permissions to send it must grant to the host to receive the entire
`
`message.” Id., 13:1-4. Because the application may process packets after all packets
`
`
`
`13
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`have been received, id., 13:21-31; or process packets as they are received, id., 13:43-
`
`52, the application will ask for the number of buffers from the card manager after
`
`the Request-to-Send has been received by the application. See Patent Owner’s
`
`Response at 12-13. Guthery refers to this tight control by the application of the
`
`communications between the application and the host as providing “‘lightweight’ or
`
`fine grain scheduling of applications.” Petitioner’s argument lacks merit.
`
`Petitioner refers to the “supporting evidence in the Petition” to assert that “it
`
`would have been within the level of ordinary skill in the art to make whatever
`
`changes necessary for implementation of Nozawa’s techniques in Guthery’s smart
`
`card.” Reply at 9 (citing Petition at 33 Ex. 1003 at ¶ 59). There are two problems
`
`with this assertion. First, as discussed above in Section II, Dr. Phinney’s declaration,
`
`encompassing ¶¶ 50-56 and ¶¶ 58-59, repeat verbatim the Petition section entitled
`
`“Reasons to Combine Guthery and Nozawa.”3 Dr. Phinney’s declaration should be
`
`accorded no weight. Xerox, IPR2022-00624, Paper No. 9 at 15. Second, the issue
`
`is not that a POSITA could have made the changes to Guthery, but whether they
`
`would have made the changes. Because the proposed combination renders Guthery
`
`inoperable for its intended purpose, the answer is no.
`
`
`
` 3
`
` The Petition does not cite to or rely on ¶ 57, which should be excluded from the
`Board’s consideration.
`
`
`
`14
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`As part of that tight coupling of application execution and communication, an
`
`application on Guthery’s smart card determines “how many packets to expect and
`
`therefore how many permissions to send it must grant to the host to receive the entire
`
`message.” Id., 13:1-4. In certain instances, an application may process packets after
`
`a collection of packets has arrived, for example when the message is encrypted and
`
`the encryption depends on the whole message, id., 13:21-31; or the application may
`
`be able to process packets as they are received, id., 13:43-52. For this reason, the
`
`application will ask for the number of buffers from the card manager after the
`
`Request-to-Send has been received by the application.
`
`As part of this buffer allocation and communication processes, Guthery’s
`
`application and card manager make the most efficient use of the limited RAM on the
`
`smart card. Id., 10:42-43, 10:62-64. More importantly, the allocation of buffers and
`
`Permissions-to-Send does not occur until a Request-to-Send is first received by the
`
`application. See id., Fig. 17A, 18A. In other words, Guthery’s efficiency in using
`
`the limited RAM and processing capabilities is predicated upon a process that begins
`
`with a Request-to-Send that allows the application to understand the processing and
`
`data being sought by the host. Petitioner’s assertion that removing the Request-to-
`
`Send would result in improved efficiency because Guthery’s system would
`
`preemptively prepare the buffers is therefore incorrect.
`
`
`
`15
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`By modifying Guthery’s system to immediately receive packets without
`
`having received a Request-to-Send as Petitioner suggests, Guthery’s application
`
`would not know (i) the size of the message to be received from the host (see, e.g.,
`
`id., 12:65-13:4); (ii) the type of data to be received from the host (see, e.g., id., 13:46-
`
`52); (iii) the number of buffers the application should request from the card manager
`
`(see, e.g., id., 13:5-12);or (iv) how the application will issue Permissions-to-Send,
`
`first to the card manager and then to the host (see, e.g., id., Figs. 17B-17C (receiving
`
`multiple packets before running steps of application), Figs. 18B-18C (running steps
`
`of application in between receiving packets)). Without this information, the
`
`application is unable to determine a buffer request to make to the card manager, the
`
`number of Permissions-to-Send for the host, or the operational scheduling of the
`
`application. This would render Guthery’s application inoperable for its intended
`
`purpose.
`
`Scheduling of buffer requests, Permissions-to-Send, and application runtime
`
`is dependent upon the process beginning with the Request-to-Send from the host.
`
`See id., Fig. 14, 12:23-24; Fig. 15A, Fig. 15B, Fig. 16A, Fig. 17A, 13:32-33, Fig.
`
`18A, 13:53-54. Because the proposed combination removes the initial Request-to-
`
`Send, a POSITA would therefore not be motivated to modify Guthery’s system to
`
`implement Nozawa’s automatic application selection process.
`
`
`
`16
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`IV. The Petition Does Not Establish That A POSITA Would Have Been
`Motivated To Combine Guthery With RFID Handbook
`Grounds 2 and 4 of the Petition propose a combination of Guthery with the
`
`RFID Handbook, inter alia, to allege invalidity of challenged claims 16 and 20 of
`
`the ’706 Patent. More specifically, Petitioner proposes to take Guthery’s smart card
`
`and its concurrent operation of applications, add Nozawa’s automatic application
`
`selection process for claim 16, and add the segmented memory taught in the RFID
`
`Handbook to satisfy claims 16 and 20.
`
`Guthery’s smart card does not utilize a memory divided into sectors. As a
`
`result, Petitioner originally proposed to use the segmented memory taught by the
`
`RFID Handbook to separate the EEPROM on Guthery’s smart card into sectors,
`
`which would enhance security in Guthery’s smart card by “effectively isolating each
`
`application.” See Petition at 66-70 (relying solely on RFID Handbook for the use of
`
`segmented EEPROM in Guthery’s smart card). Patent Owner pointed out that
`
`Guthery’s RAM was too limited to be subject to segmentation and the proposed
`
`combination would leave the RAM memory still subject to security issues, i.e., all
`
`data communicated between the smart card and the host would be vulnerable. See
`
`Patent Owner’s Response at 19.
`
`In Reply, Petitioner asserts that “Guthery’s RAM is always segmented—and
`
`segmented by application.” Reply at 12 (“The Petition did not have to propose
`
`modifying Guthery’s RAM because Guthery’s RAM is already segmented.”).
`
`
`
`17
`
`
`
`IPR2022-01137 (’706 Patent)
`Patent Owner’s Sur-Reply
`Petitioner points to Fig. 3 of Guthery to “illustrate[] the segmentation of the RAM.”
`
`Reply at 11 (citing Ex. 1005, 7:12-15 (“FIG. 3 is a schematic diagram illustrating
`
`that at least a portion of the RAM 14 of FIG. 2 is logically divided into several
`
`buffers 40. One or more buffers 40 can be assigned to an application 32 according
`
`to the application’s needs.”). But Petitioner’s citation confirms Patent Owner’s point
`
`—the buffers in RAM, the alleged segments, are shared among applications to
`
`service the applications’ packet storage needs. See Ex. 1005, 10:64-66 (“The
`
`primary use of RAM memory in a smart card is to hold incoming data, as it is being
`
`processed and outgoing data as it is being constructed.”), Figs. 15, 16, 17, and 18.
`
`Because the buffers are shared, Guthery’s RAM cannot be divided such that “each
`
`of the [sectors/memories] [has] no more than one of the at least two applications
`
`stored therein” as required by claims 16 and 20 of the ’706 Patent. As explained in
`
`the Patent Owner’s Response, a POSITA would t
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
