Trials@uspto.gov
`571-272-7822
`
`
`Paper No. 35
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________
`
`
`UNIFIED PATENTS INC.,
`
`
`
`
`
`
`
`
`
`
`
`Petitioner,
`
`v.
`
`MOBILEPAY, LLC.,
`
`Patent Owner.
`
`___________
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`___________
`
`Record of Oral Hearing
`Held: May 4, 2020
`
`____________
`
`
`
`
`Before THU A. DANG, JENNIFER S. BISK, and
`NEIL T. POWELL, Administrative Patent Judges.
`
`
`
`
`
`
`571-272-7822
`
`
`Paper No. 35
`
`
`
`UNITED STATES PATENT AND TRADEMARK OFFICE
`
`
`
`BEFORE THE PATENT TRIAL AND APPEAL BOARD
`
`___________
`
`
`UNIFIED PATENTS INC.,
`
`
`
`
`
`
`
`
`
`
`
`Petitioner,
`
`v.
`
`MOBILEPAY, LLC.,
`
`Patent Owner.
`
`___________
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`___________
`
`Record of Oral Hearing
`Held: May 4, 2020
`
`____________
`
`
`
`
`Before THU A. DANG, JENNIFER S. BISK, and
`NEIL T. POWELL, Administrative Patent Judges.
`
`
`
`
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`
`APPEARANCES:
`
`
`ON BEHALF OF THE PETITIONR:
`
`JESSICA MARKS, ESQUIRE
`Unified Patents, Inc.
`1875 Connecticut Avenue, N.W.
`Floor 10
`Washington, D.C. 200009
`
`
`
`ON BEHALF OF PATENT OWNER:
`
`
`RAYMOND W. MORT, III, ESQUIRE
`The Mort Law Firm, PLLC
`100 Congress Avenue
`Suite 2000
`Austin, TX 78701
`
`
`The above-entitled matter came on for hearing on Monday, May 4,
`2020, commencing at 1:00 p.m., EDT, by video/by telephone.
`
`
`
`
`
`
`
`
` 2
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`
`
`
`P R O C E E D I N G S
` - - - - -
`JUDGE DANG: Good afternoon. Welcome to the Patent
`
`Trial & Appeal Board. We are here today for oral arguments in
`matter No. IPR 2019-00466, challenging patent No. 9,800,706.
`Unified Patents, Inc., is the Petitioner and Mobilepay, LLC., is
`the Patent Owner. Your panel today includes myself Judge
`Dang, Judge Jennifer Bisk and Judge Neil Powell. Let us start
`with appearances. Who do we have for Petitioner?
`
`MS. MARKS: For Petitioner, and I just want to clarify the
`record that it's Unified Patents, LLC., (indiscernible) Paper No.
`17, and for Unified Patents we have myself Jessica Marks and
`Ashraf Fawzy.
`
`JUDGE DANG: Okay. And for Patent Owner.
`
`MR. MORT: For Mobilepay it's Ray Mort.
`
`JUDGE DANG: Thank you all for joining us. I have a few
`administrative details. So let's first, please note to mute yourself
`unless you are speaking. Also please identify yourself before
`speaking. We have all the papers filed before us so when you are
`presenting please refer to your demonstratives by number so that
`we can follow along. Also there may be an audio lag so please
`observe a pause before speaking. Please note also there is a
`public line connected to this video conference so keep this in
`mind.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`
`
`
`
`
` 3
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`Okay. As an initial matter we will address Patent Owner's
`
`objections to Petitioner's demonstratives. The panel will
`overrule Patent Owner's objections and thus we will allow
`presentation of the demonstratives from Petitioner. Patent
`Owner, we understand your concerns about new arguments. We
`will be able to identify and disregard any new issues not argued
`in the petition as we are drafting our decision. We will make
`those determinations then.
`
`Each party will have 45 minutes in total so please indicate
`before speaking whether or not you would like to reserve any
`time. Petitioner, you have the ultimate burden to establish
`unpatentability so you will proceed first. Patent Owner, you will
`then follow. Petitioner, would you like to reserve any time?
`
`MS. MARKS: Yes. I'd like to reserve ten minutes, please.
`
`JUDGE DANG: Ten minutes. Okay. So you will have 35
`minutes to present your primary case. Let me know when you're
`ready and I'll start the clock.
`
`MS. MARKS: I'm ready, Your Honor.
`
`JUDGE DANG: Go ahead please.
`
`MS. MARKS: Thank you, Your Honors. This is Jessica
`Marks for Petitioner Unified Patents, LLC., and let's turn to slide
`4 of Petitioner's demonstratives. On slide 4 we have challenged
`claim 1 of the 706 patent which provides an overview of the
`invention. It's directed to a system for coupling a credit card
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 4
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`reader to a mobile device using the audio port of the mobile
`phone. The system comprises three elements. There's the
`hardware component with a first mechanism for receiving data
`from the credit card reader, a communication controller for
`buffering the data before it gets to the first circuit and the first
`circuit that converts the data into an audio analog signal where
`then the connector coupled to the hardware component to the
`audio port of the mobile device. Then the next two elements are
`on the mobile device. So the second mechanism receives the
`analog audio signal and converts it into binary data and the third
`mechanism that uploads that binary data to a cloud service for
`decoding.
`
`Turning to slide 5, dependent claims 2 through 4 are also
`challenged in this IPR but there's generally been no dispute over
`these claims. Basically they stand or fall with independent claim
`1 and although four additional claims were challenged in the
`petition originally, Patent Owner disclaimed the other claims so
`that only claims 1 through 4 are at issue in this proceeding.
`
`So turning to slide 6, the problem the inventors were trying
`to solve was how to connect devices to mobile phones regardless
`of hardware design limitations and regardless of manufacture,
`and there's a linking background section that goes over the
`various known ways to do this but each of these has drawbacks.
`So the solution that was proposed by the patent was to convert
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 5
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`the output from that first device into audio signals that can then
`be received via the audio port of the mobile device.
`
`Turning to slide 7, during prosecution that concept of
`transferring data via the audio port was actually found not to be
`novel. As shown in slide 7 after rejecting that third mechanism
`as not being novel, the claims were amended to make it clear that
`it was transferring audio data and that the mobile device could
`detect the presence of the connector in the audio port. That's
`what made the claims allowable.
`
`But as slide 8 shows, there's been no dispute that Tang
`receives audio signals. There's no dispute that Kinzalow teaches
`how a mobile device would detect the presence of a connector in
`an audio port and there's no dispute regarding the combination of
`the two. So there's not been a dispute over that element that
`apparently made the claims patentable.
`
`So turning to slide 12, as there's no dispute over the
`examiner's alleged point of novelty that is taught in these
`references, slide 12 shows an overview of the issues in this case.
`We'll go over the first issue. Petitioner has shown that there's no
`support in the provisional application for the correct
`interpretation of the cloud service element. So the 706 patent
`can only claim priority to its own filing data, therefore the Tang
`reference that we've used in our grounds counts as prior art.
`
`So turning to slide 13. Slide 13 is again claim 1 and we've
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 6
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`highlighted the elements relating to that last third mechanism for
`uploading the binary data. So the data is introduced in the first
`mechanism element which explains that the data's provided by
`the credit card reader so it's credit card data. Then the first
`circuit converts the data, the credit card data, into an analog
`signal so it can be transmitted to the mobile device and the
`second mechanism is converts that analog audio signal that's
`been received into binary data so now it's binary credit card data
`that the third mechanism can then upload to the binary -- upload
`that binary data to a cloud service so the cloud service can
`decode that data.
`
`Slide 14 shows the proposed constructions. Now Petitioner
`has proposed consistent with the claim language that cloud
`service should be construed as for decoding the binary data that's
`been uploaded. Patent Owner however advocates a broader
`definition covering remote devices and software that's interactive
`via a network such as the internet. Now these arguments were
`presented to the Board with the Patent Owner's preliminary
`response which was accompanied by an expert declaration and
`Petitioner was granted a reply to that preliminary response.
`After considering the support that was identified by Patent
`Owner, the Institution decision found that the cloud service as
`used in the claims is a service that is capable for decoding the
`uploaded binary data which is consistent with Unified's
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 7
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`positions.
`
`Turning to slide 16. Not only is the claim language
`consistent with these positions, the specification also supports
`these positions. Cloud service is only mentioned in one section
`of the specification and it's the section that was added to the
`specification when it was filed on May 8, 2010. As shown in the
`patent at column 12, lines 15 through 22, a cloud service could
`decode the signal so that the phone could be relatively "dumb".
`This allows the device (phonetic) that's connected to the phone
`to communicate to the cloud through the mobile phone where a
`software vendor would implement a solution on the cloud for
`decoding the data that had been transmitted from the peripheral
`device, and then the phone would be able to then upload that data
`without significant change, that is without decoding it itself and
`in the servers where the data would be decoded.
`
`Turning to slide 17. It shows the prosecution history that
`further supports this same position. The claims had previously
`stated that any peripheral device could be coupled to the mobile
`device and then the mobile device would upload the binary data
`without significant change to any server. But those claims were
`found to be unpatentable, they were rejected. So in response
`Applicant clarified that it was credit card data that was being
`sent and it wasn't just being sent to any server but it was being
`sent to a cloud service for decoding and in their response
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 8
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`Applicant explained that this has demonstrated the inventive
`technique, that by specifying that the data was going to be
`transmitted to a cloud service for decoding the meaning of the
`claims changed and showed that this employs the phone as a
`network and accessory for the peripheral device and Applicant
`cited to the added disclosure of the 706 patent, highlighting how
`the recitation of a cloud service made it clear to a POSITA that
`the phone could be relatively "dumb" so that the software vendor
`solution could decode the binary data.
`
`Now in Patent Owner's surreply, Patent Owner argues that
`the cloud service for the coding language is merely an intended
`use and it's not limiting and they cite to the Boehringer
`Ingleheim case. But in Boehringer Ingleheim the issue was with
`a term that was in the preamble of a method claim. Unlike
`Boehringer Ingleheim, here the cited limitation appears in the
`body of the claims and moreover, even for preamble solemnity
`(phonetic) nature is determined on the facts of each case in light
`of the overall form of the claims, the invention as described in
`the specification and as the illuminated in the prosecution
`history. Here the form of the claim has the element recited in
`the body, not the preamble. The invention in the specification
`indicates that the recitation of a cloud service for decoding is
`relevant to the operation of the mechanism of the mobile phone
`and this is confirmed by Applicant's own statement and the fact
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 9
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`that the element was added during prosecution to overcome the
`rejection. Accordingly, the only support for this element was in
`the information that was added to the March, 2010 filing date
`and another proper interpretation, there is no support for this
`element.
`
`Turning to slide 19. Several of Patent Owner's arguments
`rely on alleged disclosures in the provisional of various network
`servers for the cloud service. But an internet server is not
`equivalent to a cloud service. Phones communicating with
`network servers via the internet was well known at the time but a
`cloud service that allows the phone to merely be relatively
`"dumb" so that way the solution for decoding the data that's
`originally obtained from the peripheral device would then be
`provided by the cloud service, that's what the inventors had
`understood to be their invention. So in this way the disclosure
`of this functionality of the system for uploading the data to the
`cloud service was not added until the 706's filing date and as for
`uploading or downloading packets of information to the internet
`involving, for example the transmission using TCP/IP protocols,
`it's our position that those theories were correctly considered and
`rejected by the Board. Transmission of data packets is not
`decoding of the binary data within the packets and the 706 patent
`itself distinguishes between the two. It states at column 12, lines
`15 through 22 that same section that, at the end it says that the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 10
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`data would then be uploaded without significant change and in
`that uploading process would be the TCP/IP packetization part of
`it, but it's only after it's uploaded without significant change to a
`server it's there where it would then be decoded so it's the
`decoding of that data once it's been received by the server that
`we understand to be the proper interpretation of cloud service.
`
`Now turning to slide 24. Several of Patent Owner's
`arguments rely on what a POSITA would have known, such as
`how DNS query resolves the URL to obtain an IP address or
`various other parts of POSITA knowledge to teach what is
`claimed to be a distinguishing feature of its invention. But even
`assuming that these passing references to access via the internet
`somehow discloses a cloud or some service based on POSITA
`knowledge, there's nothing that would indicate to a POSITA that
`the inventors had possession of the claimed system for uploading
`the data to a cloud service. As explained in Lockwood v.
`American Airlines, Inc., it's not sufficient for purposes of
`written description requirement of Section 112 that the
`disclosure would combine with knowledge in the art would lead
`one to speculate as to the modifications that the inventor might
`have envisioned but failed to disclose.
`
`Moreover, as shown in slide 24, a further reason a POSITA
`would not have understood the inventors to have possession of
`the claimed system for uploading to a cloud service in the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 11
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`provisional application is because the provisional discourages
`the use of intermediary servers and internet websites because
`such use adds delay and complexity of setup.
`Accordingly, as shown on slide 25, the Board properly
`found that the provisional application failed to provide written
`description support so the 706 patent is not entitled to benefit of
`the provisional's filing date, thus the priority date of the
`challenged claims is March 8, 2010 and Tang qualifies as prior
`art.
`
`JUDGE BISK: Can I ask a quick question? This is Judge
`Bisk. So you're saying the provisional basically discourages
`from using the cloud service. Does that change in the later
`amendments or in the actual filing of the application? Is that
`discouragement still in there or how does that change?
`MS. MARKS: I believe it was in the original provisional
`application and the same background section was presented in
`the patent. What was different was -- is the application filed on
`March 8 as they added an explanation that even though it's
`discouraging in the beginning part of it, it presented the new idea
`of presenting a cloud service.
`JUDGE BISK: Okay. Thank you.
`MS. MARKS: So turning to slide 41. We'll turn to the
`next major issue in this case, the three limitations of the
`hardware component and on slide 42 there's claim 1 again with
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 12
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`the three limitations of hardware components that are actually at
`issue.
`Slide 43 shows how those elements have been met. So the
`first mechanism configured to receive data provided by the credit
`card reader. As detailed in the petition, for example on pages 27
`through 29, we cite to Tang's credit card reader controller, it's
`the controller that has MCU 50. It's our position that it
`necessarily would have to have some mechanism to receive the
`data because it does disclose that it received the data but since
`Tang does not provide details of its controller, a POSITA would
`have been motivated to turn to Inoue for implementation details
`and Inoue discloses that its controller includes a port controlling
`block that receives data at port B and the petition goes in great
`detail on how port B is a serial port similar to the one that's
`disclosed in the patent. So it's clear that that qualifies as a port.
`For the second limitation Inoue discloses a microcontroller
`with its port controlling blocks that controls the communication
`between Inoue's input/output ports and the external input device.
`So it's disclosing an input buffer and as we explained in the
`petition, using a controller with a designated input port and input
`buffer as disclosed in Inoue would make the system more
`efficient by temporarily restoring received data while processing
`previously received data simultaneously and finally for the first
`circuit element, Tang disclose MCU 50 that is explicitly
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 13
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`disclosed in converting the received analog for digital
`transaction data into an analog signal for transmission to the
`mobile phone. As noted on page 35 of the petition, Tang's MCU
`50 converts the signal into a DTM that's audio signal, and so
`there is the method of those three components to the prior art
`references.
`Turning to slide 44. Patent Owner has argued that these
`limitations require different devices, but this argument was
`rejected by the Board in the Institution decision because nothing
`in the claim language prohibits the three features from
`encompassing a single device and the language of a hardware
`component including the three limitations suggests the single
`device embodiment. Petitioners map the limitation to Tang and
`Inoue in the same way as they're presented in the 706 patent as a
`single microcontroller unit like Tang's controller with MCU 50
`with the details of the controller provided by Inoue, that is
`Inoue's disclosure of a port and a buffer.
`Turning to slide 45. Since Mobilepay's preliminary
`response it's attacked the combination of Inoue and Tang arguing
`that a POSITA would not make such a combination for a variety
`of reasons. But each of these reasons are based on a
`misunderstanding of Petitioner's combination. As the Board
`recognized, Inoue is not advocating for example the bodily
`incorporation of Inoue's exact single logic gate into Tang's
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 14
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`controller. Inoue's being used for what it would teach a
`POSITA, that a controller either would have or would have
`beneficially had a port with a buffer and when read in context it's
`clear that the petition addresses details like how Inoue's buffer
`operates as a single logic gate in the context of the proposed
`means plus function analysis for the language of mechanism
`configured to receive data. To preemptively prove that Inoue
`qualified as a serial port with a buffer should Patent Owner argue
`that means plus function analysis supplies, we presented details
`on the single logic gate and how the data enters interiorly as
`opposed to a parallel port or some other interpretation. So to
`show that this qualified as disclosing a port we included those
`details but the position has always been, that is the concept of
`the details of a controller having a port and a buffer is what we
`are or what a POSITA would be motivated to make in a
`combination.
`Moreover, this was recognized by the Board in the
`Institution decision and to the extent Patent Owner was confused
`by this they had ample opportunity to depose our expert, and as
`shown on slide 45, are some of the quotes from Exhibit 2008, the
`deposition testimony confirming that that has and continues to be
`our position.
`On Patent Owner's latest argument in its surreply, they're
`arguing that Unified is now arguing for some unknown and
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 15
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`undisclosed buffer but this argument is a red herring. You know,
`upon reviewing the Institution decision Unified attempted to help
`with the understanding of our position and we felt that the
`Board's language for interpreting it was a suitable interpretation.
`It was what we were trying to convey and so in our reply we
`incorporated some of the Board's language to explain that we're
`not advocating bodily incorporation and that there's nothing in
`either references that discredits or otherwise discourages the
`incorporation of a port and a buffer in a controller so there's no
`teaching away, but Patent Owner appears to have misunderstood
`this as some kind of new argument.
`Moreover, we note that Patent Owner's newly cited
`Koninklijke Phillips N.V. v. Google, LLC case in the surreply
`actually supports Unified's positions. While it is true that the
`Federal Circuit admonished that PTAB decision for including a
`new combination of references in the grounds they instituted,
`they noted that the Board can't institute on a ground based on a
`combination of references that wasn't presented in the petition.
`In that case the Federal Circuit also approved of the Board's
`reliance on POSITA knowledge when analyzing the ground that
`was presented in the original petition.
`Similarly in this case, the petition clearly proposes the
`ground currently before the Board. It asserts for example,
`ground 1 is Tang in view of Kinzalow and Inoue and Unified is
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 16
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`appropriately relying on the combination of Tang and Inoue in
`view of POSITA knowledge for this element.
`Turning to slide 57. The next issue is the disclosure of the
`second and third mechanisms by Tang and slide 58 shows claim 1
`again with the second and third mechanisms highlighted. These
`mechanisms are both on the mobile device. The second
`mechanism allows the mobile device to convert the analog audio
`data that is received into binary data so that way the third
`mechanism can upload that binary data to a cloud service for
`decoding.
`Slide 59 presents a visual representation of the combination
`that Petitioner is relying upon. Petitioner's position relies on a
`combination of two embodiments in Tang. In the first
`embodiment on the left illustrated with figure 2 of Tang, there's
`transaction apparatus 12 in yellow that includes credit card
`reader 38 and a controller and there is the controller with MCU
`50 that converts the data from the credit card reader to an analog
`signal before sending the data over the communications link to
`mobile phone 14. So there's the first embodiment, and then we
`proposed the combination with the second embodiment disclosed
`as illustrated with what we call Tang 2 with figures 7 and 8. In
`Tang 2 it discloses that mobile phone 14 now would include a
`controller 51 that corresponds to the second mechanism.
`The second mechanism, as shown on slide 60 which has a
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 17
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`quote of Tang noting that the software application of the
`controller 51, that converts the received signal back to binary
`data, for example as stored on magnetic card 24. So it's clear
`that the data, it explicitly says that it's turning into binary data
`as it was stored on magnetic card 24, that's the credit card. So
`it's binary credit card data. In our arguments we've also
`presented several reasons why a person of ordinary skill in the
`art would meet this combination, for example both embodiments
`use the same mobile phone 14 so it would have been obvious that
`the two could be combined. You would have been motivated to
`transmit binary data instead of analog data of the first
`embodiment over the communications network because the
`digital transmission would be more secure when using binary
`data than when using analog data, and so that brings us to slide
`61 which is the third mechanism that's going to be configured to
`upload the binary data to the cloud service for decoding.
`Slide 62 shows figure 1 which is an overview of the Tang
`system. There it shows there's the transaction device with the
`credit card reader connected to the communications device 14
`and that transmits the data to the remote processor assembly 22
`and highlighted from our petition is the statement where we map
`in the claims being explicit that the disclosed transceiver on the
`mobile phone will transmit the data which happens to be in
`GPRS data, it's no longer the audio DTMF data, over the
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 18
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`communications network to the remote processor assembly 22
`and the first part of that assembly is transaction server 18.
`Transaction server 18 that's going to decode that received data so
`that with the credit card it can be processed by the
`processor/issuer part of the remote processor assembly.
`Slide 63 explains why a POSITA would have been
`motivated to make the combination. As we stated before, for
`example transmitting the binary data to the cloud service for
`decoding would have been more secure than, for example
`transmitting the analog data that was disclosed in the first
`embodiment, and as detailed in Tang controller 51 converts the
`received audio analog signal into binary data, that's the data
`that's stored on the credit card so it's credit card data. Then it
`explicitly says in Tang that the transaction card data and
`transaction data are encoded and sent to transaction server 18 as
`GPRS data and at the remote processor assembly 22, transaction
`server 18 is the first component to receive the data and Tang
`discloses that it decodes the transaction data, reformats it and
`sends it to the processor issuer for approval. So the transaction
`server is not merely unpackaging and reassembling the packets
`of data, it's actually processing the underlying data, decoding
`that binary data, so that way the processor/issuer portion of the
`cloud service can approve the credit card transaction.
`Now contrary to Patent Owner's recent arguments,
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 19
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`Petitioner has maintained the same position throughout this
`proceeding. Tang discloses a cloud service that becomes the
`binary data. The binary data is credit card data obtained from
`the credit card reader of the system and the fact that the cloud
`service is what processes the underlying binary data shows that,
`like the 706 patent, the mobile phone of Tang is relatively
`"dumb" and merely acts as a communications conduit for
`uploading the data to the cloud service for decoding.
`Accordingly, Petitioner has demonstrated that the
`challenged claims are obvious so if there are no questions,
`Petitioner will reserve the remaining time for rebuttal.
`JUDGE DANG: Okay. None for me. You have nine
`minutes and forty five seconds so that would be nineteen minutes
`forty five seconds total. Patent Owner, would you like to reserve
`any time?
`MR. MORT: I don't think I'm going to take all my time.
`I'll reserve ten minutes but I don't think I'm going to use all of it.
`JUDGE DANG: Okay, great. So 35 minutes for you also.
`You can begin any time you're ready.
`MR. MORT: Thank you, Your Honors. A couple of things
`before I get into the principle arguments. Just to respond to
`some of the points that were made. The Petitioner makes several
`claims that there's no dispute regarding, for example some of the
`dependent claims and some of the other elements and so forth, it
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 20
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`appears that Petitioner has the burden flipped (phonetic). We
`don't have the burden to dispute anybody. It's the Petitioner that
`has to establish each element for each ground they're asserting
`beyond a preponderance of the evidence to the Board. We can
`stay silent on everything, so it's simply because we don't know
`and attack at full length (indiscernible) their arguments that does
`not mean that we concede that they have established that
`argument. So I just want to kind of make sure that just because
`they say something and we don't necessarily respond to it, we're
`not conceding that.
`With regard to Your Honor's question regarding whether or
`not the initial application or the provisional application
`discouraged cloud service and so forth, the exact same paragraph
`that's included in the background section for both and it doesn't
`say don't use an internet server, it says it would be awkward and
`so forth. We then identified the problems and provide solutions
`to the problems that we've identified and in particular if you go
`to slide 2 of our demonstratives, so slide 2 of our demonstratives
`is page 17 of Exhibit 1004. This is the 586 application. So this
`is describing one of the embodiments of the invention. So in this
`embodiment what is going on is a user, let's call it
`(indiscernible) on the first mobile device wants to send some
`photographs to Bob and Bob has another mobile device. Now
`we've disclosed the devices were for example iPhones. So this is
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`
`
`
`
`
` 21
`
`
`
`Case IPR2019-00466
`Patent 9,800,706 B2
`
`
`like us wanting to send messages with multiple photos to another
`person.
`So if you look here in the middle of it it talks about that the
`first device, this is Alice's phone, would upload photographs. So
`she's uploading multiple photographs at one time to an internet
`based server. That internet based server receives those
`photographs, stores them and generates a URL, a uniform
`resource locator, and provides that back down to Alice. Alice is
`then able to send to Bob's phone directly the URL. Bob then
`uses that URL to access the photos from the internet phone
`server. So this is much -- in today's world an example of this is
`when we have production and so forth and it's too big to send by
`email so we'll upload it to Drop Box and we'll get a link to our
`folder on Drop Box and we can email it to the other person and
`say here's your link to the files. I've uploaded them, it's too
`cumbersome to send back and forth directly and then it goes to
`the file server. The other person's able to use that link to then
`access a file to download it. We call it Drop Box today, we call
`it SharePoint and so forth. It seems it's undisputed that that is a
`cloud service. It is remote from everybody. It's on the network.
`It provides a service for
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
