DCT
1:20-cv-20970
PayRange Inc v. KioSoft Tech LLC
I. Executive Summary and Procedural Information
- Parties & Counsel:- Plaintiff: PayRange Inc. (Tennessee)
- Defendant: KioSoft Technologies, LLC (Florida) and TechTrex, Inc. (Canada)
- Plaintiff’s Counsel: Fowler White Burnett; Wilson Sonsini Goodrich & Rosati
 
- Case Identification: 1:20-cv-20970, S.D. Fla., 03/03/2020
- Venue Allegations: Venue is alleged to be proper in the Southern District of Florida because Defendant KioSoft has a regular and established place of business in the district and has committed alleged acts of infringement there. Venue is asserted against Defendant TechTrex on the basis that it is a foreign entity.
- Core Dispute: Plaintiff alleges that Defendants’ mobile payment solutions for non-networked, unattended retail machines infringe patents related to presenting transaction events to users and using mobile devices as a bridge for firmware updates.
- Technical Context: The technology enables mobile phone-based payments for machines like laundry or vending units that lack their own internet connection, using short-range wireless communication.
- Key Procedural History: The complaint alleges that Defendants gained knowledge of the patents-in-suit during business meetings with the Plaintiff in February 2019, where a potential licensing relationship was discussed. This allegation forms the basis for claims of willful infringement.
Case Timeline
| Date | Event | 
|---|---|
| 2013-12-18 | Earliest Priority Date for ’296 and ’994 Patents | 
| 2015-09-15 | U.S. Patent No. 9,134,994 Issues | 
| 2017-05-23 | U.S. Patent No. 9,659,296 Issues | 
| 2019-02-12 | Alleged Pre-Suit Knowledge Date (Business Meeting) | 
| 2020-03-03 | Complaint Filing Date | 
II. Technology and Patent(s)-in-Suit Analysis
U.S. Patent No. 9,659,296: Method and system for presenting representations of payment accepting unit events (Issued May 23, 2017)
- The Invention Explained:- Problem Addressed: The patent background describes the proliferation of internet-connected mobile devices and the opportunity to use them for more convenient payments at unattended vending machines, which traditionally rely on cash or have limited user feedback mechanisms (’296 Patent, col. 1:20-33).
- The Patented Solution: The invention is a method performed on a mobile device that enhances the user experience for mobile payments at these machines. After a user initiates a transaction, the mobile device obtains a notification from a payment module on the machine that indicates an "event" (e.g., transaction completion, failure, or abortion) and then provides a "representation" of that event to the user via the mobile device's output capabilities, such as its display, speaker, or vibration mechanism (’296 Patent, Abstract; col. 2:9-33).
- Technical Importance: This approach centralizes user feedback on the personal mobile device, providing clearer and more detailed transaction status information than is typically available from the simple displays on unattended machines.
 
- Key Claims at a Glance:- The complaint asserts independent claim 1 and dependent claims 12 and 18 (Compl. ¶29).
- Independent Claim 1 (Method):- At a mobile device with processors, memory, output devices (including a display), and a radio transceiver:
- Executing a mobile payment application configured to identify one or more vending machines in proximity by detecting predefined radio messages.
- Displaying a user interface for the application, which is configured to accept user input to trigger payment for a transaction.
- Establishing a wireless connection with an available vending machine.
- After connection, presenting an indication on the user interface that the connection is established.
- Sending information via the radio transceiver in conjunction with the vending transaction.
- Obtaining a notification via the radio transceiver, where the notification is based on a message from the vending machine.
- In response to obtaining the notification, providing on the display an updated user interface with a visual representation of the notification.
 
 
U.S. Patent No. 9,134,994: Method and system for updating firmware using a mobile device as a communications bridge (Issued Sep. 15, 2015)
- The Invention Explained:- Problem Addressed: The patent describes the logistical and financial challenge of updating firmware on a large fleet of non-networked hardware, such as payment modules installed in unattended retail machines across many locations (’994 Patent, col. 55:38-54). Physically servicing each machine is inefficient and costly.
- The Patented Solution: The invention leverages a customer's mobile device as a temporary communications bridge. The mobile app receives a firmware image from a central server over a long-range network (e.g., cellular or Wi-Fi). Later, when the mobile device is in proximity to a payment module, it uses a short-range connection (e.g., Bluetooth) to check the module's current firmware version. If an update is needed, the mobile device transmits the new firmware to the module (’994 Patent, Abstract; col. 3:26-44).
- Technical Importance: This system enables scalable, over-the-air firmware updates for offline devices without requiring each device to be equipped with its own costly cellular or Wi-Fi modem, thereby reducing hardware and operational costs.
 
- Key Claims at a Glance:- The complaint asserts independent claim 1 and dependent claims 13 and 19 (Compl. ¶44).
- Independent Claim 1 (Method):- At a first mobile device with two or more distinct communication capabilities (a first and a second):
- While executing an application, receiving from a server an application update and a firmware image for a payment module via the second communication capability.
- After receiving, updating the application and storing the firmware image.
- Subsequent to and independent from the receiving, updating, and storing steps: obtaining an information packet broadcast by the payment module via the first communication capability, the packet including the module's current firmware version.
- Comparing the module's current firmware version with the version of the stored firmware image.
- If they do not match, sending firmware update information to the payment module via the first communication capability to update it to the stored version.
 
 
III. The Accused Instrumentality
- Product Identification: The accused products are Defendants’ "CleanPay Mobile" and "CleanReader Solutions" product lines (Compl. ¶12). This includes the "CleanPayMobile cell phone app," "CleanPay Kiosks," and "CleanReader Solutions terminals" (Compl. ¶21). The complaint also identifies the "CSCPayMobile app" as being "powered by Defendants" and incorporating the allegedly infringing technology (Compl. ¶30).
- Functionality and Market Context: Defendants are alleged to offer a "single-source" solution for mobile payments in the self-help retail sector, including the laundry and vending industries (Compl. ¶21). The system includes mobile applications and payment-collecting kiosks or terminals with built-in mobile payment functionalities, allowing users to pay at unattended machines with their phones (Compl. ¶21). The complaint alleges these products directly compete with PayRange's offerings (Compl. ¶21).
IV. Analysis of Infringement Allegations
No probative visual evidence provided in complaint.
’296 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation | 
|---|---|---|---|
| executing a mobile payment application on the mobile device...the mobile payment application being configured to identify one or more vending machines in proximity to the mobile device | The CSCPayMobile app, powered by Defendants, is executed on a mobile device (e.g., an iPhone 7) and is configured to identify one or more vending machines in proximity. | ¶30 | col. 27:36-41 | 
| the identifying including detecting predefined radio messages broadcast by the one or more vending machines | The identification process includes detecting predefined radio messages broadcast by the vending machines. | ¶30 | col. 11:5-10 | 
| displaying a user interface of the mobile payment application on the display of the mobile device, the user interface being configured to accept user input to trigger payment... | The complaint alleges infringement by performing a "method of presenting representations of vending machine events," which implies the use of a user interface to initiate payment, though this element is not explicitly detailed. | ¶30 | col. 11:11-24 | 
| obtaining, via the radio transceiver, a notification...based on a message from the available vending machine... | The complaint alleges the accused method involves presenting representations of "vending machine events," which presupposes the receipt of a notification corresponding to such an event from the machine. | ¶30 | col. 2:16-20 | 
| in response to obtaining the notification, providing, on the display, an updated user interface of the mobile payment application that provides a visual representation of the notification... | The core allegation is that the accused products perform a "method of presenting representations of vending machine events," fulfilling this final step. | ¶30 | col. 2:20-25 | 
’994 Patent Infringement Allegations
| Claim Element (from Independent Claim 1) | Alleged Infringing Functionality | Complaint Citation | Patent Citation | 
|---|---|---|---|
| receiving, from a server...an update for the application and a firmware image for a payment module...via the second communication capability | While executing an app like the CSCPayMobile app, the mobile device receives application updates and a firmware image for a payment module from a server. | ¶44 | col. 3:26-32 | 
| after receiving...updating the application based on the update; and storing the firmware image for the payment module | After receiving the update and firmware image, the mobile device updates its application and stores the firmware image. | ¶44 | col. 3:33-35 | 
| subsequent to and independent from the receiving, the updating, and the storing, obtaining an information packet broadcast by the payment module via the first communication capability... | The mobile device subsequently and independently obtains a broadcasted information packet from the payment module via a first communication capability. | ¶44 | col. 3:36-41 | 
| comparing the current firmware version of the payment module with a version of the stored firmware image | The mobile device compares the firmware version received from the payment module's broadcast with the version of the firmware image it previously stored. | ¶44 | col. 3:56-59 | 
| in accordance with a first determination that the current firmware version...does not match...sending, to the payment module, firmware update information via the first communication capability... | If the versions do not match, the mobile device sends firmware update information (containing data packets) to the payment module to perform the update. | ¶44 | col. 3:39-44 | 
- Identified Points of Contention:- Scope Questions: For the ’994 patent, a central question may be whether the accused system’s process for checking for firmware updates is truly "independent from the receiving, the updating, and the storing" of the firmware image from the server. The sequence and independence of these steps are specific requirements of the claim that may be a focus of dispute.
- Technical Questions: For the ’296 patent, the complaint alleges the performance of a method for "presenting representations of vending machine events." A key technical question will be what specific "events" (e.g., transaction completion, coin jam, product sold out) the accused system reports and what "representations" (e.g., a banner notification, a dialog box, a balance update) it provides to the user, and whether these functions map directly onto the claim limitations.
 
V. Key Claim Terms for Construction
- ’296 Patent, Claim 1: "presenting representations of vending machine events"- The Term: "presenting representations of...events"
- Context and Importance: This phrase encapsulates the core function of the invention. Its construction will determine what types of user feedback qualify as infringing. A narrow definition could excuse systems providing only simple or implicit status updates, while a broad definition could cover a wider range of user interface changes post-transaction.
- Intrinsic Evidence for Interpretation:- Evidence for a Broader Interpretation: The specification abstract states the invention "provides a representation of the notification to a user...via the one or more output devices," suggesting any form of user-perceptible output (visual, audible, haptic) could be a "representation." (’296 Patent, Abstract).
- Evidence for a Narrower Interpretation: Figures 26A-26D depict specific graphical user interfaces with explicit text messages like "Transaction Complete" or "Transaction Aborted." (’296 Patent, Figs. 26A, 26C). A defendant may argue that a "representation" requires such an explicit, semantic message, rather than a mere change in a displayed account balance.
 
 
- ’994 Patent, Claim 1: "subsequent to and independent from"- The Term: "subsequent to and independent from"
- Context and Importance: This temporal and functional limitation is critical to the claimed method. It requires that the step of checking a local module's firmware version is decoupled from the process of downloading the firmware update from the server. Infringement requires proof of this specific sequence and independence. Practitioners may focus on this term because it creates a high evidentiary bar for the plaintiff.
- Intrinsic Evidence for Interpretation:- Evidence for a Broader Interpretation: The specification describes the overall system as using the mobile device as a "communications bridge," which inherently implies distinct operations of fetching data from a server and delivering it to a local device, supporting the idea of separate, independent steps. (’994 Patent, col. 1:1-3).
- Evidence for a Narrower Interpretation: The flowchart in Figure 26A shows a clear sequence where the firmware update information is sent to the module (step 1306) after a determination is made that an update is needed (step 1304), reinforcing a strict procedural order. A system that, for instance, downloads and pushes a firmware update in a single, continuous session upon connection might not meet this limitation.
 
 
VI. Other Allegations
- Indirect Infringement: The complaint alleges both contributory and induced infringement for both patents. The claims are based on allegations that Defendants provide a "core software module" to third-party service providers (for apps like "CSCPayMobile" and "Wash Connect") knowing it is especially adapted for infringement (Compl. ¶¶32-33, 46-47). Inducement allegations are based on Defendants allegedly encouraging customers to use the infringing products with knowledge of the patents (Compl. ¶¶35, 49).
- Willful Infringement: Willfulness is alleged for both patents. The complaint bases this on Defendants' alleged knowledge of the patents-in-suit and Plaintiff's products since at least a February 12, 2019 business meeting where a potential license was discussed (Compl. ¶¶22, 25, 39, 53).
VII. Analyst’s Conclusion: Key Questions for the Case
The resolution of this dispute may turn on the following central questions:
- Evidentiary Sufficiency: The complaint makes detailed allegations about the inner workings of the accused firmware update system based on "information and belief." A key question for the case will be one of evidentiary proof: can the plaintiff, through discovery and technical analysis, demonstrate that the accused products perform the precise, multi-step, and conditionally independent sequence required by claim 1 of the ’994 patent?
- Definitional Scope: The infringement theory for the ’296 patent hinges on the meaning of "presenting representations of...events." A core issue will be one of functional scope: does a routine update to a user's account balance or a simple status change in the accused app constitute the claimed "representation" of a specific machine "event," or do the claims require a more discrete, event-triggered notification that is functionally distinguishable from a standard UI refresh?