DCT

2:24-cv-00035

DAV Sub v. COMMUNICARE Technology

Log In
Key Events
Complaint

I. Executive Summary and Procedural Information

  • Parties & Counsel:
  • Case Identification: 2:24-cv-00035, D. Mont., 05/24/2024
  • Venue Allegations: Plaintiff alleges venue is proper in the District of Montana because Defendant maintains a regular and established place of business in Bozeman, Montana, and has allegedly committed acts of patent infringement within the district.
  • Core Dispute: Plaintiff alleges that Defendant’s Pulsara Platform, a healthcare communication software, infringes a patent related to a generalized framework for processing transactions between disparate information services.
  • Technical Context: The technology relates to service-oriented software architectures that enable interoperability between different applications and data sources, a key challenge in the fragmented healthcare IT landscape.
  • Key Procedural History: The complaint notes that Defendant is the owner of two U.S. patents related to its own products. No other procedural events such as prior litigation or administrative proceedings concerning the patent-in-suit are mentioned.

Case Timeline

Date Event
2001-04-19 '730 Patent Priority Date
2008-09-16 '730 Patent Issue Date
2024-05-24 Complaint Filing Date

II. Technology and Patent(s)-in-Suit Analysis

  • Patent Identification: U.S. Patent No. 7,426,730, "Method and System for Generalized and Adaptive Transaction Processing Between Uniform Information Services and Applications," issued on September 16, 2008 (the “’730 Patent”).
  • The Invention Explained:
    • Problem Addressed: The patent describes the difficulty of integrating information from different, independent online sources, such as combining driving directions with real-time traffic data (’730 Patent, col. 1:63-col. 2:5). It notes that creating custom, one-off software solutions for each integration is inefficient, unscalable, and difficult to manage as the number of services grows (’730 Patent, col. 2:6-14).
    • The Patented Solution: The invention proposes a generalized transaction framework built around a central "Transaction Processing Function" (TPF) that acts as an intermediary between information "consumers" (RSCs) and "providers" (RSPs) (’730 Patent, col. 3:51-56; Fig. 1). This TPF uses a "Uniform Specification Model" (USM) to understand the capabilities of various services based on a standardized classification system, and it processes transaction requests by dynamically selecting and integrating the appropriate services based on the context of the request (’730 Patent, col. 5:12-24). The system is designed to be extensible and adapt to changing conditions without requiring custom code for each new service or transaction type.
    • Technical Importance: The described framework provides a model for a service-oriented architecture (SOA), which was a critical concept for enabling scalable and flexible web services that could interoperate without being tightly coupled. (Compl. ¶40).
  • Key Claims at a Glance:
    • The complaint asserts independent claim 1 and dependent claims 15, 17, and 37 (Compl. ¶¶ 54, 56-57).
    • The essential elements of independent claim 1 are:
      • A networked computer system with a plurality of computer servers for providing a resultant resource.
      • A "resource transaction processing module".
      • A plurality of remote "resource providers" communicatively coupled to the module.
      • A "resource information registry" for storing information about the resources from the providers.
      • The module, in response to a request:
        • constructs a "transaction situation context" using additional information.
        • "dynamically selects" a resource based on the context.
        • "determines" discrete operations to perform on the resource.
        • "obtains" the selected resource.
        • "processes" the resource to generate a resultant resource.

III. The Accused Instrumentality

  • Product Identification: The accused instrumentality is Defendant's "Pulsara Platform," a system that includes the "Pulsara App and its supporting Pulsara infrastructure" (Compl. ¶15).
  • Functionality and Market Context: The Pulsara Platform is a cloud-based, software-as-a-service (SaaS) healthcare communication system designed to connect and coordinate care teams across different organizations (Compl. ¶¶ 15, 26). Its core functionality is a "dedicated patient channel" that allows clinicians to dynamically build a care team for a specific patient event (e.g., stroke, trauma) by adding necessary specialists, departments, or other organizations (Compl. ¶¶ 26, 33, 36). Through this channel, team members can communicate and share various types of information, including images, ECGs, video, and data from external systems (Compl. ¶¶ 32, 34, 37). The platform also uses location information to provide data like estimated time of arrival and to identify available local resources (Compl. ¶¶ 22-23). The complaint presents a flowchart from one of Defendant's own patents, describing a method to establish a dedicated communication channel and share medical information between healthcare entities (Compl. ¶27).

IV. Analysis of Infringement Allegations

  • ’730 Patent Infringement Allegations
Claim Element (from Independent Claim 1) Alleged Infringing Functionality Complaint Citation Patent Citation
A networked computer system having a plurality of computer servers... The Pulsara Platform is described as a cloud-based system utilizing a "cluster of web servers in geographically separated data centers." ¶17, ¶42 col. 5:26-34
a resource transaction processing module The system’s "'patient channel' module" is alleged to be a "software module that processes transaction requests." ¶44 col. 4:47-52
a plurality of resource providers, each resource provider being remotely located...and communicatively coupled... The platform connects and provides access to various remote resources, including different healthcare organizations, EMS teams, clinics, and specialists. ¶34, ¶47 col. 4:18-20
a resource information registry...for storing information about the resources provided by the plurality of resource providers... The platform allegedly includes a "registry of available resources" by presenting users with a list of available teams and individuals that can be assigned to a patient channel. The complaint includes a screenshot showing a list of teams and their on-call status. ¶48 col. 5:5-9
constructs a transaction situation context...that provides additional information...for dynamically selecting...at least one resource The platform allegedly uses "situational contexts (e.g., stroke, cardiac arrest, trauma)" to enable the dynamic selection and building of appropriate care teams for a patient's specific needs. ¶36, ¶49, ¶51 col. 4:56-62
wherein dynamically selects at least one resource to process... The platform is alleged to allow users to "Dynamically Build Your Team" by selecting and adding teams or individuals to a channel as needed for a specific patient event. ¶28, ¶36, ¶50 col. 5:18-24
determines one or more discrete operations to perform on the at least one selected resource... Requests initiated via the "patient channel" are processed, leading to operations such as adding team members, sending alerts, and facilitating data sharing. ¶43-44 col. 6:27-33
obtains the at least one selected resource from the resource provider... The platform provides access to the selected resources (e.g., team members, external data links) via the "patient channel" module. ¶32, ¶47 col. 6:33-41
processes the at least one selected resource...to generate a resultant resource. The platform provides access to resources and facilitates communication "responsive to requests initiated via the 'patient channel' module," with the resulting coordinated care channel being the "resultant resource." ¶43-44 col. 6:33-41
  • Identified Points of Contention:
    • Scope Questions: A central question may be whether the generalized terms in the patent, such as "resource provider" and "resource information registry", which originate from a generic IT context, can be construed to read on the specific, application-focused features of the accused medical platform, such as a "care team member" or a "list of available teams". The complaint includes a screenshot showing a list of available destination hospitals based on location, which may support the allegation that the platform identifies and selects from a list of registered resources (Compl. ¶22).
    • Technical Questions: The infringement theory hinges on the "patient channel" module (Compl. ¶44) functioning as the claimed "resource transaction processing module". The defense may question whether the accused module performs the sophisticated, multi-step processing sequence described for the patent’s TPF (e.g., processing transaction definitions, building a transaction context, atomizing operations), or if it is a more straightforward, hard-coded application.

V. Key Claim Terms for Construction

  • The Term: "resource transaction processing module"
    • Context and Importance: This term defines the core processing engine of the invention (the TPF). The outcome of the case will likely depend on whether the accused "patient channel" module falls within the scope of this term.
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The patent provides a high-level definition of a TPF as "a software component that manages transactions between one or more information services" (’730 Patent, col. 4:47-52), which could support a broad reading covering any software that coordinates interactions.
      • Evidence for a Narrower Interpretation: Figure 12 of the patent depicts the module performing a specific sequence of functions: "Process TD," "Build TSC," "Atomize TD Operations," "Link Services," and "Execute Program." The defense may argue that the term should be limited to a module that performs this particular set of structured, adaptive processing steps.
  • The Term: "resource information registry"
    • Context and Importance: This term defines the repository of available services (the USR). The complaint maps this to the platform’s feature for listing available teams and individuals (Compl. ¶48). Practitioners may focus on whether the accused feature meets the structural requirements of the claimed "registry".
    • Intrinsic Evidence for Interpretation:
      • Evidence for a Broader Interpretation: The patent defines the "Uniform Specification Repository" (USR) as a means "to store and access information" about services (’730 Patent, col. 5:5-9). This language could be interpreted to encompass any database or list of available resources.
      • Evidence for a Narrower Interpretation: The patent states that the "registry" stores "classified specifications" according to a "standard taxonomic structure" defined by the "Uniform Specification Model (USM)" (’730 Patent, col. 5:41-54). The defense may argue that the accused feature, which appears to be a list of team names and availability statuses, does not constitute the formally structured and classified repository required by the claim.

VI. Other Allegations

  • Indirect Infringement: The complaint does not plead a separate count for indirect infringement but alleges that Defendant infringes "directly or through intermediaries" (Compl. ¶15) and that the Pulsara Platform infringes "when used and/or operated in their intended manner or as designed" (Compl. ¶59). The complaint does not, however, allege specific facts to support the elements of knowledge and intent for induced or contributory infringement.
  • Willful Infringement: The complaint alleges willfulness based on notice provided by the filing of the lawsuit itself, requesting enhanced damages for post-filing conduct (Compl., Prayer for Relief ¶d). There are no allegations of pre-suit knowledge of the ’730 Patent.

VII. Analyst’s Conclusion: Key Questions for the Case

  • A core issue will be one of definitional scope: can the abstract terms of the ’730 Patent, which describe a generalized service-oriented architecture (e.g., "resource transaction processing module", "resource information registry"), be construed to cover the concrete, application-specific components of the accused healthcare communication platform?
  • A key evidentiary question will be one of technical operation: does the accused "patient channel" module perform the highly structured, adaptive processing of the claimed invention—which interprets formal service classifications and transaction definitions—or is there a functional mismatch, with the accused product operating as a more conventional, purpose-built application?