Aqua Connect Inc, Strategic Technology Partners v. Apple, Patent Infringement Case

Case 8:17-cv-01762-JVS-KES Document 1 Filed 10/10/17 Page 1 of 44 Page ID #:1
1 Gregory S. Dovel (Cal. Bar No. 135387)

greg@dovel.com
2
Rick Lyon (Cal. Bar No. 229288)
3 rick@dovel.com
4 Simon Franzini (Cal. Bar No. 287631)
simon@dovel.com
5 DOVEL & LUNER, LLP
6 201 Santa Monica Blvd., Suite 600
Santa Monica, California 90401
7 Telephone: 310-656-7066
8 Facsimile: 310-657-7069
9
Attorneys for Plaintiffs Aqua Connect, Inc.
10 and Strategic Technology Partners, LLC
11
UNITED STATES DISTRICT COURT
12 CENTRAL DISTRICT OF CALIFORNIA
13
AQUA CONNECT, INC., a Nevada Case No. 8:17-cv-1762
14 corporation,
15 Patent infringement complaint.
STRATEGIC TECHNOLOGY
16 PARTNERS, LLC, a Nevada limited Demand for Jury Trial
17 liability company,
18
Plaintiffs,
19
20 v.
21 APPLE, INC., a California corporation,

22
Defendant.
23
24
25
26
27
28
1 Plaintiffs Aqua Connect, Inc. and Strategic Technology Partners, LLC file this
2 complaint against Apple Inc. and on information and belief allege as follows:
3 Introduction
4 1. A computers operating system includes software that supports certain
5 basic functions of the computer, such as executing software applications.
6 2. Apples computer operating system is macOS. 1 The macOS architecture
7 erects technological barriers to viewing and controlling the user interface (the visually
8 displayed desktop for example) over a network.
9 3. For many years, no one could come up with a good way to overcome
10 these barriers. As a result, there was no secure and efficient way to view and control
11 macOS computers remotely over a network.
12 4. In 2008, inventor Joseph Cohen developed a novel technological solution
13 that overcame these problems for computer systems running macOS and other Mach-
14 derived systems (i.e., ones whose operating system core is based on an operating
15 system core named Mach). Mr. Cohens solution allowed the user interface
16 information of a macOS computer to be securely and efficiently transferred out of the
17 user context (the execution environment where macOS isolates user tasks) to a
18 separate task in the system context (the execution environment for system tasks).
19 His solution also allowed input information received over a network to be efficiently
20 and securely transferred into the user context. This allowed a user to view and control
21 a graphical desktop session on a macOS computer from a remote computer, over a
22 network such as a Local Area Network or the Internet.
23
24
25
26
1
27 Earlier versions of macOS were marketed under the name Mac OS X. For
simplicity and consistency, this complaint refers to all versions of Apples Mac
28 operating system as macOS, whether they were marketed as macOS or Mac OS
X at the time.
1
1 5. Mr. Cohen applied for and was awarded United States patentsincluding
2 the asserted 386 patent and the 502 patent (Asserted Patents)to protect his
3 inventions.
4 6. Mr. Cohen also built his inventions into his company Aqua Connects
5 remote desktop and terminal server application, Aqua Connect Terminal Server
6 (ACTS). The result was ACTS 3.0the first fully functional, secure, and efficient
7 remote desktop and terminal server solution for macOS.
8 7. ACTS 3.0 was released on September 24, 2008, and met with significant
9 industry praise and commercial success. Aqua Connects customers included
10 numerous universities, government agencies, and research facilities, including
11 University of California, University of Texas, Harvard University, Stanford University,
12 Florida State University, Johns Hopkins University, University of Chicago, University
13 of Utah, University of Nebraska, Washington University, Wake Forest University, Los
14 Alamos National Laboratory, Lawrence Livermore National Laboratory, NASA, Mayo
15 Clinic, National Center for Biotechnology Information, National Library of Medicine,
16 and National Oceanic and Atmospheric Administration, among others.
17 8. Initially, ACTS 3.0 had Apples full support. Apples enterprise and
18 government customers (and potential customers) needed a fully-functional, secure,
19 efficient remote desktop and terminal server solution for macOS to be able to use
20 Apple computers for their enterprise or organization. (A terminal server is an
21 application that serves user terminals to other computer systemsi.e., it allows
22 multiple users to remotely control different user sessions on the same computer at the
23 same time). ACTS 3.0 was the only application that could fill this need at the time.
24 As a result, Apple worked closely with Aqua Connect on development and sales.
25 9. In early 2011, however, Appleabruptly and without explanation
26 stopped cooperating with Aqua Connect.
27 10. A few months later, in July of 2011, Apple launched a new major release
28 of macOS, Mac OS X 10.7 (also known as Lion). Lion included a redesigned
2
1 remote desktop and terminal server solution, Screen Sharing. As explained below,
2 Screen Sharing uses Aqua Connects patented technology without Aqua Connects
3 permission. Every macOS release since Lion has included a Screen Sharing feature
4 that uses Aqua Connects patented technology without Aqua Connects permission.
5 11. In addition, around the same time, Apple launched a new major release of
6 its mobile operating system, iOS 5. iOS 5 included a new feature, Airplay
7 Mirroring, which allowed the screen of an iOS device such as an iPhone to be shared
8 with another computing device (such as an Apple TV) over a computer network. As
9 explained below, AirPlay Mirroring uses Aqua Connects patented technology without
10 Aqua Connects permission. Every iOS release since iOS 5 has included an AirPlay
11 Mirroring feature that uses Aqua Connects patented technology without Aqua
12 Connects permission.
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
3
1 12. Furthermore, with Lions release, Apple changed the end user license
2 agreement for its operating system. The new end user license agreement required that
3
4
5
6
7
8
9
10
11
12
13
any connection to control a separate graphical desktop session of macOS (i.e., one
14
other than the one displayed on the screen attached to the computer running it) may
15
only be made through the Screen Sharing feature of the Apple Softwareand not
16
through third-party remote desktop applications offered by Apples competitors (such
17
as Aqua Connect):
18
This requirement has been included in the end user license agreements for each
19
subsequent release of macOS.
20
21
Nature of the Action, Jurisdiction and Venue
22
13. Plaintiffs assert claims for patent infringement against Apple under the
23
patent laws of the United States, including 35 U.S.C. 271 and 281, et seq. The
24
Court has original jurisdiction over Plaintiffs patent infringement claims under 28
25
U.S.C. 1331 and 1338(a).
26
27
28
4
1 14. The Court has personal jurisdiction over Apple. Apple has committed
2 acts of infringement in this district, including selling infringing devices in this district
3 and using infringing devices in this district.
4 15. Venue is proper in this district under 28 U.S.C. 1440. Apple is a
5 California corporation with its principal place of business in California. Accordingly,
6 Apple resides in this district. In addition, Apple has numerous established places of
7 business in this district, including numerous Apple Store retail locations. For example:
8
9
10
11
12
13
14
15
16
17
18
The parties
19
Plaintiff Aqua Connect.
20
16. Plaintiff Aqua Connect, Inc. is a Nevada corporation. Its principal place
21
of business and headquarters is at 1815 E. Heim Ave, Suite 100, Orange, California
22
92865.
23
17. Aqua Connect was established in 2007 by the inventor of the asserted
24
patents, Joseph Cohen. It is the exclusive licensee of the asserted patents and develops
25
and sells remote desktop and terminal server applications for macOS that practice the
26
Asserted Patents, including Ignision Server.
27
Plaintiff Strategic Technology Partners.
28
5
1 18. Strategic Technology Partners, LLC is a wholly-owned subsidiary of

2 Aqua Connect. Aqua Connect formed Strategic Technology Partners on July 31, 2013,
3 for the purpose of holding its patents in a dedicated subsidiary. Strategic Technology
4 Partners principal place of business and headquarters is the same as that of its parent,
5 Aqua Connect.
6 19. Aqua Connect is and always has been the sole Member of Strategic
7 Technology Partners, and has and always has had a 100% ownership stake in Strategic
8 Technology Partners. Strategic Technology Partners is and always has been managed
9 solely by directors and officers of Aqua Connect.
10 20. On February 18, 2014, Aqua Connect assigned its patents to Strategic
11 Technology Partners. Because Strategic Technology Partners is a wholly-owned
12 subsidiary of Aqua Connect, Aqua Connect has always retained a 100% interest in the
13 Asserted Patents through its ownership of Strategic Technology Partners.
14 21. This Complaint refers to the parent company Aqua Connect, Inc. and its
15 wholly-owned subsidiary Strategic Technology Partners, LLC collectively as Aqua
16 Connect.
17 Defendant Apple.
18 22. Defendant Apple, Inc. is a California corporation. Apple makes, imports,
19 markets and sells Mac computers, iPhones, iPads, iPods, and Apple TVs. Apple also
20 develops, imports, markets and sells the macOS and iOS operating systems.
21 The asserted patents.
22 23. United States Patent No. RE46,386 issued on October 1, 2013, as U.S.
23 Patent 8,549,093 and reissued on May 2, 2017. Reissued Claim 1 recites:
24 A computer implemented method for updating a user instance, the method
25 comprising:
26 [a] creating at least one user computer context configured to be executed
27 on a Mach-derived computing device comprising at least one computer
28
6
1 processor, wherein each of the at least one user computer context is

2 configured to incorporate an agent server;
3 [b] associating the agent server with an agent client, wherein the agent
4 client and the agent server are configured to be executed on the Mach-
5 derived computing device, but in separate processes and in separate Mach
6 contexts;
7 [c] generating, by the agent server, data corresponding to an updated user
8 instance, wherein the data corresponding to the updated user instance
9 comprises user computer data,
10 [c1] wherein the user computer data comprises at least one of:
11 display data, audio data, biometric data, input data, image data,
12 output data, video data, streaming data, touch screen data, keypad
13 data, joystick data, touchpad data, keyboard data, mouse data,
14 metadata, smart device data, input device data, data from another
15 device appropriate for receiving input directly or indirectly from the
16 user, computer monitor data, speaker data, projector data, data from
17 another device appropriate for outputting data, or output device
18 data;
19 [d] determining, by the agent server, that any portion of the user computer
20 data has been updated;
21 [e] transferring the data corresponding to the updated user instance
22 between the agent server and the agent client via a computer system
23 communication facility based on said determining,
24 [e1] wherein said transferring comprises: transferring at least one
25 of: the user computer data, or metadata corresponding to a shared
26 memory, wherein said shared memory comprises the any portion of
27 the updated user computer data, between the agent server and the
28 agent client,
7
1 [e2] wherein at least one of the user computer data or the metadata
2 is transmitted via the computer system communication facility,
3 wherein the computer system communication facility comprises at
4 least one of: a socket, a file, a port, a shared computer memory, or a
5 pipe; and
6 [f] transmitting the data corresponding to the updated user instance over a
7 communications network to a remote computer system for update of the
8 user instance based on the data corresponding to the updated user
9 instance,
10 [f1] wherein said transmitting comprises: transmitting at least one
11 of the user computer data, or the metadata, over the
12 communications network to the remote computer system for update
13 of the user instance based on the updated user computer data or
14 metadata.
15 Ex. 1 (386 patent), claim 1. Plaintiffs incorporate the 386 patent into the complaint
16 by reference.
17 24. United States Patent No. 8,924,502 issued on December 30, 2014. Claim
18 1 recites:
19 A method for transmitting data, the method comprising:
20 [a] creating a first context on a Mach-derived system comprising at least
21 one processor, wherein the first context incorporates an agent server;
22 [b] creating a second context on the Mach-derived system, wherein the
23 second context incorporates an agent client;
24 [b1] wherein the agent client and the agent server are executed on
25 the Mach-derived system, but in separate processes;
26 [c] generating, by the agent server, the data corresponding to an updated
27 user instance, wherein the data corresponding to the updated user instance
28 comprises user data,
8
1 [c1] wherein the user data comprises at least one of: display data,
2 audio data, biometric data, input data, image data, output data,
3 video data, streaming data, touch screen data, keypad data, joystick
4 data, touchpad data, keyboard data, mouse data, metadata, smart
5 device data, input device data, data from another device appropriate
6 for receiving input directly or indirectly from the user, computer
7 monitor data, speaker data, projector data, data from another device
8 appropriate for outputting data, or output device data;
9 [d] determining, by the agent server, that any portion of the user data has
10 been updated;
11 [e] transferring the data to or from the agent client via a system
12 communication facility based on said determining,
13 [e1] wherein said transferring comprises transferring at least one of:
14 the user data, or metadata corresponding to a shared memory
15 comprising the any portion of the updated user data, between the
16 agent server and the agent client,
17 [e2] wherein at least one of the user data or the metadata is
18 transmitted via the system communication facility, wherein the
19 system communication facility comprises at least one of: a socket, a
20 file, a port, or a pipe; and
21 [f] transmitting from the agent client the data over a network to a remote
22 system for update of the user instance based on the data,
23 [f1] wherein said transmitting comprises: transmitting at least one
24 of the user data, or the metadata, over the network to the remote
25 system for update of the user instance based on the updated user
26 data or metadata.
27 Ex. 2 (502 patent), claim 1. Plaintiffs incorporate the 502 patent into the complaint
28 by reference.
9
1 25. Each patent has several additional independent claims and a number of
2 dependent claims that are infringed by Apple and relevant to this case.
3
4 The claimed solutions.
5 26. The claims of the asserted patents improve the way Mach-derived
6 computer systems (such as computers running macOS or iOS) operate.
7 27. One aspect of Mach-derived systems that the claims improve is the ability
8 of a Mach-derived computer system to be viewed and controlled over a network.
9 28. One way the claims carry out this improvement is using a specific new
10 system architecture for transferring data between processes running on separate parts
11 of a Mach-derived system: an agent server in one bootstrap context and an
12 associated agent client in a separate bootstrap context which communicate over a
13 system communication facility that includes Mach ports.
14 Mach-derived systems.
15 29. Apples macOS and iOS operating systems are Mach-derived operating
16 systems. Their core, or kernel, is based on the Mach kernel, an operating system
17 core developed at Carnegie Mellon University.
18 Inter-process communication on Mach-derived systems.
19 30. A process or task is a program or subprogram executing on a computer,
20 for example a word processing task. Inter-process communication is communication
21 between two computer processes or tasks. On Mach-derived operating systems, inter-
22 process communication can make use of messages and Mach ports.
23 31. A message can be used to send information to a task. A Mach port is the
24 endpoint of a unidirectional communication channel. A task can be the designated
25 receiver of a Mach port. Other tasks can send messages to that task using that Mach
26 port. To receive messages using a Mach port, the receiving task must have receive
27 rights to that port. And to send messages using a Mach port, a sender must have
28 send rights to that port.
10
1 Bootstrap server.
2 32. When a task creates a Mach port for communication, it gives itself
3 receive rights to that Mach port. As a result, it can receive messages sent to that
4 port.
5 33. To allow other tasks to acquire send rights to a Mach port, the designated
6 receiver of a Mach port can give the port a name and register it with a bootstrap
7 server.
8 34. In software, a server is a software component that provides services to
9 other software components upon request. In macOS, a bootstrap server is a software
10 component that stores and maintains information about Mach ports and provides that
11 information to other tasks upon request.
12 35. When a task registers a named Mach port with a bootstrap server, the
13 bootstrap server saves the Mach ports name (as well as other information about that
14 Mach port) in a data container in memory (for example, a linked list). Another task
15 can look up a Mach port registered with a bootstrap server by its name and, in that
16 manner, acquire send rights to that port.
17 36. A task can communicate with a bootstrap server using a bootstrap port.
18 A bootstrap port is a special Mach port that a task can use to communicate with a
19 bootstrap server. Each task has send rights to at least one bootstrap port and can use it
20 to access at least one bootstrap server or data container in memory for bootstrap ports.
21 A task can create another task, in which case it is sometimes called the parent of the
22 task it created. A task can inherit send rights to a bootstrap port from the tasks
23 parent.
24 Bootstrap contexts.
25 37. Tasks on Mach-derived operating systems run within bootstrap contexts
26 (sometimes simply called contexts). A context is a tasks execution environment,
27 that determines what operating system services (Mach ports) it can access. There can
28 be different contexts on the same computer.
11
1 38. In macOS, there is a top-level bootstrap context when the system starts
2 up. This is sometimes called the startup context or system context. The startup
3 context can have a bootstrap server (and associated data container for bootstrap ports)
4 where tasks can register the named Mach ports that they create (and therefore have
5 receive rights to).
6 39. The system can create additional bootstrap contexts. For example, when a
7 user logs in, a bootstrap context for that user can be created. This is sometimes called
8 a user context. A task in the system context creates the user context; as a result, the
9 user context is sometimes called a child of the system context (and the system
10 context is called a parent of the user context). User tasks, for example, the graphical
11 user interface that allows a user to interact with the computer, can be executed in the
12 user context.
13 40. Tasks in a user context can look up Mach ports registered with the
14 bootstrap task (or stored in the associated data container) for the user context through
15 their bootstrap port. Tasks in a user context also can generally look up Mach ports
16 registered with the bootstrap task (or stored in the data container) for the parent context
17 of the user context, i.e., the system context. 2
18 41. However, tasks in a parent context generally cannot look up Mach ports
19 registered with the bootstrap task (or in the data container) for their child contexts.
20 Similarly, a task in one child context (for example, one user context) cannot look up
21 Mach ports registered with the bootstrap task (or in the data container) for a different
22 child context (for example, another user context).
23 42. One reason for this is that although a task in a child context such as a user
24 context can access the bootstrap task of (or the data container for) the parent context
25 through its bootstrap port, tasks in a parent context (such as a system context) cannot
26
27 2
However, in some implementations, the Mach-derived system can block tasks in
28 the user context from looking up some or all of the Mach ports registered with the
bootstrap task of (or the bootstrap database for) the system context.
12
1 access the bootstrap task (or the data container for) any of its children. Similarly, a
2 task in one child context (such as a user context) cannot access the bootstrap task (or
3 data container) for other children (for example, other user contexts) for the same
4 reasons.
5 43. A system can have multiple user contexts (for example, one user context
6 for a given user, and another user context for a different user who is also using the
7 computer system), which can be children of the system context. Each user context can
8 have its own bootstrap task for named Mach ports registered by tasks in that user
9 context, and/or can have its own data container for named Mach ports registered by
10 tasks in that user context.
11 Benefits of separate contexts.
12 44. Having a separate bootstrap context for each user has a number of
13 benefits. It makes the system more secure. It prevents tasks in the system context or
14 another users context from interfering with a users tasks. It allows the system to
15 shield certain system tasks from user interference. And it segregates each users data
16 in his or her own context.
17 45. Having a separate bootstrap context also improves and facilitates software
18 design. Because each users tasks are segregated in that users context, software
19 programs do not need to design a system to keep track of different program instances
20 and data for each user. Everything in a particular users context belongs to that user.
21 46. Several benefits are described in greater detail below.
22 47. Security: Having separate contexts for each user provides greater security.
23 48. First, if each users tasks are isolated in a user context, then one users
24 tasks cannot look up Mach ports registered by other users tasks. As a result, one
25 users tasks cannot accidentally interfere with, or intentionally gain unauthorized
26 access to, another users tasks or data.
27 49. For example, if there are separate Mach contexts for each user, a task in
28 user 1s context would not be able to look up the Mach port for user 2s clipboard
13
1 service (a service that allows users to copy information from one program and then
2 paste it in a different program). As a result, (a) there is no risk that a task in user 1s
3 context will accidentally obtain the data stored on user 2s clipboard; and (b) it is much
4 more difficult for a virus or other malicious code in user 1s context to obtain
5 unauthorized access to user 2s data (for example, by pretending to be user 1 when
6 accessing the clipboard).
7 50. Second, if each users tasks are isolated in a user context, tasks in the
8 system context generally cannot look up the Mach ports that user tasks register and
9 therefore cannot manipulate them. This protects user tasks from malicious tasks in the
10 system context. This is especially important in a network environment: if an attacker
11 is able to gain access to a computer over a network but only connects to the system
12 context, the attacker has limited ability to attack tasks in the users context because it
13 cannot look up Mach ports registered by those tasks and therefore cannot manipulate
14 them.
15 51. Third, as explained above, users can be restricted from accessing certain
16 Mach ports registered in the system context. This allows tasks in the system context to
17 be protected from user interference, which promotes security (as well as proper
18 functioning of the system.)
19 52. Improved system reliability and software design: Having separate contexts
20 allows user tasks to look up and communicate with other user tasks without keeping
21 track of task ownership. This leads to greater system reliability. It also makes it easier
22 to design user software.
23 53. For example, suppose user 1 has its own user context. If the clipboard
24 service runs in that context, then that users tasks can simply look up the Mach port for
25 the clipboard service and send information to the clipboard service using that Mach
26 portwithout having to keep track of (or even know) which user is accessing the
27 clipboard. This is because if a task in user 1s context looks up the Mach port for the
28 clipboard service, it will receive the Mach port for a clipboard service specific to user
14
1 1, that only contains user 1s data. This ensures that whenever user 1 copies or pastes
2 information to the clipboard, the information copied or pasted will be user 1s
3 informationand not some other users information. If a second user, user 2, logs into
4 the same system and copies something to the clipboard, a different instance of the
5 clipboard service will be created for user 2 and will run in user 2s context. All of
6 user 2s tasks (i.e., the tasks running in user 2s context) will receive the Mach port for
7 user 2s clipboard if they look it up. This eliminates the need for tasks to keep track of
8 which information or tasks belong to which user. And it makes the system more
9 reliable and less susceptible to errors.
10 54. (By contrast, if tasks for different users were running in the same context,
11 then additional programming would be needed to keep track of which tasks and
12 information belong to which user. Moreover, this programming could fail, resulting in
13 data being passed across user boundaries).
14 Challenges with separate bootstrap contexts
15 55. Having a separate bootstrap context for each user also creates certain
16 challenges. Because tasks in the system context cannot look up the Mach ports for
17 tasks in the user context, they cannot easily access user-related data, for example user
18 interface data. This makes it difficult to develop an effective and secure remote
19 desktop or terminal server application for macOS.
20 56. Indeed, a remote desktop or terminal server application running on a
21 computer (the host computer) must be accessible from a remote device (the remote
22 computer), to allow a user on a remote computer to connect to it. The application must
23 also be able to access the user interface of the host computer, so that the application
24 can (a) capture the user interface of the host computer and send the interface to the
25 remote computer and (b) control the user interface of the host computer based on input
26 provided on the remote computer. In addition, a terminal server application must
27 allow users to log into their own sessions, and so must exist and be accessible before a
28
15
1 user logs in. And a terminal server application must be able to support multiple
2 concurrent user sessions that do not affect each other.
3 57. For operating systems without separate bootstrap contexts (such as
4 Microsoft Windows), these requirements did not pose any particular challenges.
5 58. For macOS and other Mach-derived operating systems, however, these
6 requirements gave rise to significant technological challenges.
7 59. To be able to access user tasks and the user interface (for example, to
8 obtain display data to transmit to the remote device, or to control tasks based on input
9 from the remote device), the remote desktop or terminal server application needed to
10 be located in the user context (so it could look up the Mach ports for user tasks to be
11 able to interface with them). But locating a remote desktop or terminal server
12 application in the user context would lead to the following problems:
13 To establish a network connection between the remote computer and the host
14 computer to enable a user on the remote computer to view or control a
15 particular user session, a remote computer would need to know the specific
16 connection information (e.g. TCP/IP address and port) associated with the
17 remote desktop/terminal server application of that user on the host computer.
18 And there would be no way for the remote computer to know this before the
19 user logged into the host computer (which he or she could not do until after a
20 connection was established).
21 If a remote desktop/terminal server application runs only in the user context
22 on the host computer, then for a remote computer to be able to connect, the
23 user must already be logged into the host computer (otherwise there is no
24 user context and therefore no remote desktop/terminal server application
25 running). Accordingly, such a solution would require a user to already be
26 logged into the host computer, and would not allow users to log into the host
27 computer remotely. If, for example, a user wanted to access or control his or
28
16
1 her work computer from home but forgot to log in before leaving the office,
2 he or she would not be able to do so.
3 Allowing multiple users to control their respective user sessions on the host
4 computer at the same time (necessary for a fully functional terminal server
5 application) would require separate connections from each remote computer
6 to each application within each user context. Because these applications
7 would be independent of one another (there would be multiple instances of a
8 remote desktop/terminal server application), they would compete with each
9 other for network resources, potentially in inefficient ways.
10 Apples conventional solution.
11 60. The conventional solution to these problems, which Apple used for many
12 years, was simply to use a single task in the user context, and use workarounds to
13 address some of the shortcomings listed above.
14 61. For example, before the Screen Sharing application was released with
15 macOS 10.7, Apple used a single task in the user context (AppleVNCserver) to
16 provide rudimentary screen sharing functionality for macOS.
17 62. If no user was logged in, then macOS on the host computer would execute
18 an instance of AppleVNCserver in the loginwindow context (the context for the login
19 window). If a remote computer connected, the user operating that remote computer
20 could log into the host computer using his or her credentials. This caused a new user
21 context to be created. At that point, macOS killed the AppleVNCserver process in the
22 loginwindow context and created a new AppleVNCserver process in the user context
23 that had just been created. Because the new process was in the user context, it could
24 access user tasks and therefore (1) access the graphical user interface and send it to the
25 remote computer, and (2) control the user interface based on inputs received on the
26 remote computer.
27 63. Apples solution followed the teachings in the prior art at the time of the
28 invention.
17
1 64. First, the conventional wisdom was that it was not feasible to access or
2 control a task in the user context from the system context. If task 1 in the system
3 context needed to access or control task 2 in the user context, the only way to allow it
4 to do so was run task 1 in the user context. The single task in user context solution
5 followed the conventional wisdom that for one task to send messages to and control
6 another task in the user context, both tasks must be in that same user context.
7 65. Second, it was conventional wisdom that the steps for carrying out a
8 particular functionality (such as sharing the screen) should not be split up into multiple
9 tasks but should instead be executed by a single task if possible. This was because
10 each task is considered a significant expenditure of system resources. As a result, the
11 conventional wisdom taught to minimize the number of tasks (i.e., not break up the
12 steps needed to carry out a single functionality into multiple tasks). Moreover, it was
13 thought especially important to avoid breaking up functions that needed to share large
14 amounts of data with each other into separate tasks. This was because splitting up
15 such functions would require transferring large amounts of data from task to task,
16 which (a) drained system resources and (b) required significant programming attention
17 to ensure that the transfer would be done efficiently. The single task in user context
18 solution followed this conventional wisdom: it allowed a single task to perform a
19 function and it avoided the need for data to be passed between tasks.
20 66. Howeverand despite its use by Apple for many yearsApples
21 conventional solution had a number of drawbacks. For example, running the
22 AppleVNCserver process in the user context exposed the user context directly to the
23 network and therefore to the possibility of malicious code accessing the user context.
24 As a second example, because the AppleVNCserver process existed only in the user
25 context, it did not allow a second user to connect to it and start up his or her own
26 session with its own context. This prevented Apple from offering a terminal server
27 solution (and, indeed, Apple did not offer one for many years, despite significant
28 demand). As a third example, Apples conventional solution also did not allow a user
18
1 to connect to a computer using their own credentials if another user was logged in on
2 the host computereven if that other user was not using the computer at the time. As
3 a fourth example, Apples conventional solution did not allow a remote user session to
4 run in the background on the host computerif a remote user was controlling the user
5 interface remotely, that user interface would also be displayed on the (locally
6 connected) display of the host computer. As a fifth example, connecting to a macOS
7 computer without any user logged on required establishing, tearing down, and then re-
8 establishing a connection with the remote computer, which required additional system
9 resources and which led to delays and connectivity issues.
10 The patented invention.
11 67. In 2008, inventor Joseph Cohen realized that instead of following the
12 conventional wisdom to have a single remote desktop task in a single context like the
13 solutions described above, you could split up the functions carried out by a remote
14 desktop application into two separate but associated tasks in two separate Mach
15 contexts: for example, one in the user context (which he called the agent server), and
16 the other in the system context (which he called the agent client).
17 68. Although a task in the system context cannot look up the Mach port for a
18 task registered in the user context, a task in the user context can look up a Mach port
19 for a task registered in the system context. Accordingly, if:
20 an agent client task exists in the system context of the host computer; and
21 a new agent server task is created in the user context of the host computer
22 after the user logs in,
23 the agent server task can create an association with the agent client task, for
24 example by registering a Mach port with a special data container or server maintained
25 by or accessible to the agent clientas contrasted with registering a Mach port with
26 the bootstrap server in the user context (which the agent client in the system context
27 cannot access). Moreover, because a task in the user context can look up the Mach
28 ports for tasks in the system context, the agent server (in the user context) would be
19
1 able to look up and interact with (send a message to) the agent client (in the system
2 context) in order to set up this association. Once the association was set up, the agent
3 server and agent client could pass user-interface related data to each other, for example
4 using Mach ports, shared memory, or sockets.
5 69. Mr. Cohens invention went against conventional wisdom, which taught
6 that tasks in a parent context cannot interact with tasks in a child context, and that
7 functions should not be split up across multiple tasks (which are expensive resources),
8 especially when they need to pass large amounts of data among them.
9 70. But by doing so, Mr. Cohens invention overcame the limitations of the
10 Mach system architecture: the invention allowed a task in the system context (the agent
11 client) to look up the Mach port for, and therefore be able to interact with, the task in
12 the user context (the agent server), because the agent server task in the user context
13 had registered its Mach port with a data container accessible to the agent client task in
14 the system context.
15 71. This enabled bidirectional communication between two associated
16 processes, one in the user context and one in the system context. At the same time,
17 Mr. Cohens invention overcame the problems with Apples conventional solution, did
18 not rely on any unstable security loopholes, and preserved the benefits of separate user
19 contexts in Mach.
20 72. Mr. Cohens invention also had several additional benefits.
21 73. It allowed a user session that was being controlled by a user on a remote
22 computer to run in the background on the host computer (as opposed to being
23 displayed on the local screen of the host computer).
24 74. It enabled multi-user terminal server functionality: because the agent
25 client remained in the system context and could communicate with an agent server in a
26 user context, any number of users could connect to the agent client and log in (at which
27 point a new agent server for just that user would be created and would interact with the
28 agent client).
20
1 75. In addition: (1) using the agent server as an intermediary allowed the
2 terminal server application to efficiently manage the network connection (for example,
3 by prioritizing connections that are time sensitive) and (2) because this solution
4 allowed for true isolation of user tasks within a user context and did not require access
5 to user tasks from the system context, the data of each terminal server user was more
6 secure than regular multi-user functionality on macOS.
7 First claim for patent infringement (386 patent)
8 76. Plaintiffs incorporate by reference each of the allegations in paragraphs 1-
9 75 above and further allege as follows:
10 The 386 patent.
11 77. The 386 patent, entitled Updating a User Session in a Mach-derived
12 Computer System Environment, issued on May 2, 2017, from reissue Application No.
13 14/191,450, filed February 27, 2014. Ex. 1 (U.S. Patent RE46,386). The 386 patent
14 is a re-issue of U.S. Patent No. 8,549,093, which issued on October 1, 2013, from
15 Application No. 12/586,613, filed September 23, 2009.
16 Validity of the 386 patent.
17 78. Each claim of the 386 patent is valid and enforceable.
18 Patent eligibility of the 386 patent.
19 79. Each claim of the 386 is patent eligible.
20 80. Each claim is directed to a specific improvement in technology, and not
21 an abstract idea.
22 81. For example, the claims improve the way Mach-derived computer
23 systems (such as macOS computers) operate.
24 82. One aspect of Mach-derived systems that the claims improve is the
25 manner in which processes in different parts of the system communicate.
26 83. A second aspect of Mach-derived systems that the claims improve is the
27 ability of Mach-derived systems to be viewed and controlled by users remotely over a
28 network.
21
1 84. In addition, the claims solve technological problems with prior art remote
2 desktop solutions.
3 85. The claimed improvement consists of a specific technological solution.
4 One aspect of this solution is the use of a specific new system architecture for
5 transmitting data between different processes running on separate parts of a Mach-
6 derived system: an agent client in one Mach context and an associated agent server
7 in a separate Mach context, which communicate with each other over a system
8 communication facility.
9 86. This architectureagent client in one context and agent server in a
10 separate contextgenerally improved communication in and out of user contexts on
11 Mach-derived systems. More specifically, it allowed improved access and control of
12 the user interface of the Mach-derived system from a remote computer over a network.
13 And it solved each of the problems associated with prior art remote desktop
14 applications (described above).
15 87. In addition, each claim recites unconventional technical steps.
16 88. For example, each claim recites a technical solution to a technical
17 problem: a software architecture for transferring data in and out of separate Mach
18 contexts and over a network to a remote computer to update the user interface and
19 control the host computer consisting of: (1) an agent client in one Mach context; and
20 (2) at least one (and potentially multiple) agent servers in a separate Mach context (or
21 separate Mach contexts), which is associated with the agent server in a way that allows
22 data to be transferred between the two, and which solves problems with existing
23 solutions for Mach-derived systems.
24 89. Moreover, this combination of components and steps (as well as each
25 individual component or step itself) was unconventional. For example, it was
26 unconventional because it went against the conventional wisdom that tasks in a parent
27 context cannot interact with tasks in a child context, and that functions should not be
28 split up across multiple tasks (which are expensive resources), especially when they
22
1 need to pass large amounts of data among them. As a second example, it was
2 unconventional because the conventional solutions, like Apples conventional solution,
3 did exactly this: they used a single task in the user context (in Apples case, a single
4 instance of AppleVNCserver)not two associated tasks in different contexts as the
5 claims require.
6 90. Each claim recites numerous additional unconventional technical steps,
7 each of which is independently sufficient to confer patent-eligibility.
8 91. In addition, during prosecution of the386 patent, the examiner expressly
9 found that the claims of the 386 patent were patent eligible under the standard set
10 forth in Alice.
11 Ownership of the 386 patent.
12 92. Plaintiff Strategic Technology Partners is owner of the 386 patent.
13 Plaintiff Aqua Connect is the exclusive licensee of the 386 patent with full rights to
14 pursue recovery of royalties and damages for infringement of the patent, including full
15 rights to recover past and future damages.
16 Apples infringement of the 386 patent.
17 93. Defendant Apple has directly infringed the claims of the 386 patent by
18 making, offering to sell, selling, and importing Apple Mac computers running macOS
19 version 10.7 or above (including macOS server installations) that include Screen
20 Sharing, and/or Remote Management (which makes use of Screen Sharing), and/or
21 Apple Remote Desktop (which makes use of Screen Sharing), and/or remote desktop
22 clients that connect to such Apple Mac computers through Screen Sharing (including
23 using Finder, iChat, Share my screen, Back to Mac, and Screen Sharing
24 viewer)3, and by using those products to (a) transmit a user desktop environment of
25
26
3
27 The Apple Mac computers are collectively referred to as the accused Macs.
Screen Sharing and Remote Management are collectively referred to as Screen
28 Sharing. The Apple-branded remote desktop clients that connect to accused Macs
through Screen Sharing are referred to as the accused remote desktop clients.
23
1 an accused Mac to a remote computer over a network (including to Apple branded and
2 third party remote computers), (b) allow a user desktop environment of an accused
3 Mac to be controlled based on input from a remote computer over a network (including
4 from Apple branded and third party remote computers), and/or (c) view and/or control
5 a user desktop environment of an accused Mac from a remote computer over a
6 network.
7 94. Apple has also directly infringed the claims of the 386 patent by making,
8 offering to sell, selling, and importing iPhones, iPads, iPod Touch devices running iOS
9 5 and above that include the Airplay Mirroring function (accused iOS devices), and
10 Apple TVs that are compatible with Airplay Mirroring, and by using those products to
11 transmit data to or receive data from remote computers over a network.
12 95. Apple has also indirectly infringed the claims of the 386 patent.
13 96. Apple has actively induced, and will continue to actively induce, users
14 (including end users and resellers) of its infringing products to infringe the 386 patent.
15 97. Apple offered and continues to offer its infringing products for sale, at
16 both retail Apple Store locations and on its website.
17 98. Apple instructed and continues to instruct its users to use its infringing
18 products in an infringing manner.
19 99. For example, Apple induces its users to use its infringing products in an
20 infringing manner through requiring that any connection to control a separate graphical
21 desktop session of macOS (i.e., one other than the one displayed on the screen attached
22 to the computer) may only be made through the [infringing] Screen Sharing feature of
23 the Apple Software:
24
25
26
27
28
24
1
2
3
4
5
6
7
8
9
10
11
12 100. As a second example, on its website, Apple provides specific instructions
13 on how to set up and use screen sharing in an infringing manner on macOS Sierra:
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
25
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
26
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 101. Apple provides similar instructions for older versions of its macOS
16 operating system. In addition, Apple provides similar instructions for using the
17 AirPlay Mirroring function.
18 102. Furthermore, Apple knew or was willfully blind to the fact that its
19 customers use of Screen Sharing, the accused remote desktop clients, and AirPlay
20 Mirroring would infringe the 386 patent.
21
22
23
24
25
26
27
28
27
1 103. Indeed, Apple was aware of Aqua Connect since at least 2007. Apple
2 acknowledged this, for example, in the following email from Apple to Aqua Connect:
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21 104. In addition, Apple was aware of ACTS 3.0 and other Aqua Connect
22 remote desktop/terminal server products that practice the 386 patent and the 502
23 patent since the time they were released in 2008. Indeed, Apple told Mr. Cohen that it
24 had tried and failed to build a remote desktop solution for macOS with terminal server
25 functionality, and was the one to suggest that Mr. Cohen should build a terminal server
26 application for macOS in the first place. Moreover, Aqua Connect shared the details
27 of its terminal server application with Apple subject to a confidentiality agreement.
28
28
1 105. Furthermore, software developer Dan Crosby was employed by Aqua

2 Connect from 2008-2009 and then left to join Apple. Mr. Crosby was aware of ACTS
3 3.0 and other Aqua Connect products that practice the 386 patent and 502 patent, was
4 aware of the patented solution that those products employed, and was aware that Aqua
5 Connect had filed for patent protection of this solution.
6 106. In addition, at least seven Apple employees requested and were provided
7 with a trial of Aqua Connect Remote Desktop Service after the 093 patent (which
8 reissued as the 386 patent, and is the parent of the 502 patent) issued:
9 Aaron Stanley (astanley@apple.com), February 10, 2014
10 Trea Grillo (trea@apple.com), February 21, 2014
11 Fred Licht (flicht@apple.com), June 11, 2014
12 Tristan Barthe (tristan@apple.com), December 4, 2014
13 Atif Alam (atif.alam@apple.com), February 4, 2015
14 Damon Whitney (dwhitney@apple.com), February 16, 2015
15 Rune Hansen (rune@apple.com), December 29, 2015
16
17
18
19
20
21
22
23
24
25
26
27
28
29
1 As shown below, as of the time of these trials, the installer was marked with the 093
2 patent number (the number of the patent that was reissued as the 386 patent, and is the
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
parent of the 502 patent) and stated that the product is protected by one or more
18
Patents, including U.S. Patent #8,549,093.
19
107. In addition, on June 29, 2017, Aqua Connect sent an email to all of its
20
leads, including each of the Apple employees who had requested trials of Aqua
21
Connect, informing them of a new release of Aqua Connects Ignision product. As
22
shown below, the email was marked with the 386 patent number and informed its
23
recipients (including Apple) that Ignision was protected by one or more Patents,
24
including U.S. Patents RE46,386 and 8,924,502:
25
26
27
28
30
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18 108. In addition, at the time of this email, the Ignision installer stated that
19 Ignision Server was protected by the asserted patents and identified them by their
20 numbers, U.S. Patents RE46,386 and 8,924,502.
21 109. Based on the foregoing, Apple knew that its customers use of the accused
22 products would infringe the 386 patent and 502 patent, or alternatively was aware
23 that there was a high probability that its customers use of the accused products would
24 infringe and took deliberate acts to avoid confirming this.
25 110. As a result, Apple has indirectly infringed and continues to indirectly
26 infringe the 386 patent by inducing its customers to use its accused products in an
27 infringing manner, and knowing or being willfully blind to the fact that such use would
28 infringe the 386 patent.
31
1 111. Apple has contributed and continues to contribute to the infringement of

2 the 386 patent by users (including end users and resellers) of its infringing products.
3 Apple offered to sell, sold, and imported, and continues to offer to sell, sell, and import
4 its infringing products that include components, including Screen Sharing, the accused
5 remote desktop clients, and Airplay Mirroring, that constitute a material part of the
6 invention claimed in the 386 patent, for use in screen sharing and remote desktop
7 control processes that infringe the 386 patent. As shown above, Apple knew of the
8 386 patent and knew that its infringing products were especially made for
9 infringement of the 386 patent and would be used to infringe the 386 patent, or was
10 willfully blind to these facts; and that Screen Sharing, the accused remote desktop
11 clients, and AirPlay Mirroring were not a staple article or commodity of commerce;
12 and that they have no substantial non-infringing use. Indeed, any use of Screen
13 Sharing, the accused remote desktop clients, or AirPlay Mirroring infringes the claims
14 of the 386 patent, as shown for example in exhibit 3; there is no other non-infringing
15 use.
16 112. Apple infringes numerous claims of the 386 patent, including but not
17 limited to representative independent claim 1. A detailed explanation showing one
18 way that the accused Mac devices infringe claim 1 is set forth in exhibit 3. Plaintiffs
19 incorporate exhibit 3 into the complaint by reference.
20 113. Moreover, the Airplay Mirroring feature on the accused iOS devices
21 functions in substantially the same manner as the infringing remote desktop
22 applications charted in exhibit 3, and meets each limitation of claim 1 for the same
23 reasons set forth in the attached chart. See Ex. 3.
24 Willful infringement.
25 114. Apples infringement of the 386 patent has been willful and egregious.
26 115. For the reasons stated in paragraphs 102-113 above, Apple knew that its
27 accused products infringed the 386 patent, or alternatively took deliberate steps to
28
32
1 avoiding confirming this and was therefore willfully blind to these facts. Plaintiffs
2 incorporate by reference each of the allegations in these paragraphs by reference.
3 116. In addition, Apples infringement of the 386 patent was not accidental
4 it resulted from a decision to deliberately copy Aqua Connects patented solution after
5 working closely with Aqua Connect in the 2008-2011 timeframe, and seeing that Aqua
6 Connects technology provided a remote desktop/terminal server solution that its
7 enterprise customers wanted and that overcame problems that Apple could not solve
8 without it.
9 117. Plaintiffs have been damaged by Apples infringement of the 386 Patent
10 and will suffer additional irreparable damage and impairment of the value of their
11 patent rights unless Apple is enjoined from continuing to infringe the 386 patent.
12 Claim for patent infringement (502 patent)
13 118. Plaintiffs incorporate by reference each of the allegations in paragraphs 1-
14 75 above and further allege as follows:
15 The 502 patent.
16 119. On December 30, 2014, the United States Patent and Trademark Office
17 issued U.S. Patent No. 8,924,502 entitled System, Method and Computer Program
18 Product for Updating a User Session in a Mach-Derived System Environment. Ex. 2.
19 Validity of the 502 patent.
20 120. Each claim of the 502 patent is valid and enforceable.
21 Patent eligibility of the 502 patent.
22 121. Each claim of the 502 patent is patent eligible, for the same reasons set
23 forth in paragraphs 79-91 above. Plaintiffs incorporate each of the allegations in those
24 paragraphs.
25 Ownership of the 502 patent.
26 122. Plaintiff Strategic Technology Partners is owner of the 502 patent.
27 Plaintiff Aqua Connect is the exclusive licensee of the 502 patent with full rights to
28
33
1 pursue recovery of royalties and damages for infringement of the patent, including full
2 rights to recover past and future damages.
3 Apples Infringement of the 502 patent
4 123. Defendant Apple has directly infringed the claims of the 502 patent by
5 making, offering to sell, selling, and importing Apple Mac computers running macOS
6 version 10.7 or above (including macOS server installations) that include Screen
7 Sharing, and/or Remote Management (which makes use of Screen Sharing), and/or
8 Apple Remote Desktop (which makes use of Screen Sharing), and/or remote desktop
9 clients that connect to such Apple Mac computers through Screen Sharing (including
10 using Finder, iChat, Share my screen, Back to Mac, and Screen Sharing viewer),
11 and by using those products to (a) transmit a user desktop environment of an accused
12 Mac to a remote computer over a network (including to Apple branded and third party
13 remote computers), (b) allow a user desktop environment of an accused Mac to be
14 controlled based on input from a remote computer over a network (including from
15 Apple branded and third party remote computers), and/or (c) view and/or control a user
16 desktop environment of an accused Mac from a remote computer over a network.
17 Apple has also directly infringed the claims of the 386 patent by making,
18 offering to sell, selling, and importing iPhones, iPads, iPod Touch devices running iOS
19 5 and above that include the Airplay Mirroring function (accused iOS devices), and
20 Apple TVs that are compatible with Airplay Mirroring, and by using those products to
21 transmit data to or receive data from remote computers over a network.
22 126. Apple has also indirectly infringed the claims of the 502 patent.
23 127. Apple has actively induced, and will continue to actively induce, users
24 (including end users and resellers) of its infringing products to infringe the 502 patent.
25 128. Apple offered and continues to offer its infringing products for sale, at
26 both retail Apple Store locations and on its website.
27 129. Apple instructed and continues to instruct its users to use its infringing
28 products in an infringing manner.
34
1 130. For example, Apple induces its users to use its infringing products in an
2 infringing manner through requiring that any connection to control a separate graphical
3 desktop session of macOS (i.e., one other than the one displayed on the screen attached
4 to the computer) may only be made through the [infringing] Screen Sharing feature of
5 the Apple Software:
6
7
8
9
10
11
12
13
14
15
16
17
18
131. As a second example, on its website, Apple provides specific instructions
19
on how to set up and use screen sharing in an infringing manner on macOS Sierra:
20
21
22
23
24
25
26
27
28
35
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
36
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15 132. Apple provides similar instructions for older versions of its macOS
16 operating system. In addition, Apple provides similar instructions for using the
17 AirPlay Mirroring function.
18 133. Furthermore, Apple knew or was willfully blind to the fact that its
19 customers use of the accused products would infringe the 502 patent.
20
21
22
23
24
25
26
27
28
37
1 134. Indeed, Apple was aware of Aqua Connect since at least 2007. Apple
2 acknowledged this, for example, in the following email from Apple to Aqua Connect:
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21 135. In addition, Apple was aware of ACTS 3.0 and other Aqua Connect
22 remote desktop/terminal server products that practice the 502 patent since the time
23 they were released in 2008. Indeed, Apple told Mr. Cohen that it had tried and failed
24 to build a remote desktop solution for macOS with terminal server functionality, and
25 was the one to suggest that Mr. Cohen should build a terminal server application for
26 macOS in the first place. Moreover, Aqua Connect shared the details of its terminal
27 server application with Apple subject to a confidentiality agreement.
28
38
1 136. Furthermore, software developer Dan Crosby was employed by Aqua

2 Connect from 2008-2009 and then left to join Apple. Mr. Crosby was aware of ACTS
3 3.0 and other Aqua Connect products that practice the 502 patent, was aware of the
4 patented solution that those products employed, and was aware that Aqua Connect had
5 filed for patent protection of this solution.
6 137. In addition, at least seven Apple employees requested and were provided
7 with a trial of Aqua Connect Remote Desktop Service after the 093 patent issued:
8 Aaron Stanley (astanley@apple.com), February 10, 2014
9 Trea Grillo (trea@apple.com), February 21, 2014
10 Fred Licht (flicht@apple.com), June 11, 2014
11 Tristan Barthe (tristan@apple.com), December 4, 2014
12 Atif Alam (atif.alam@apple.com), February 4, 2015
13 Damon Whitney (dwhitney@apple.com), February 16, 2015
14 Rune Hansen (rune@apple.com), December 29, 2015
15 As shown below, as of the time of these trials, the installer was marked with the 093
16 patent number (the number of the parent of the 502 patent) and stated that the product
17 is protected by one or more Patents, including U.S. Patent #8,549,093.
18
19
20
21
22
23
24
25
26
27
28
39
1 138. In addition, on June 29, 2017, Aqua Connect sent an email to all of its
2 leads, including each of the Apple employees who had requested trials of Aqua
3 Connect, informing them of a new release of Aqua Connects Ignision product. As
4 shown below, the email was marked with the 502 patent number and informed its
5 recipients (including Apple) that Ignision was protected by one or more Patents,
6 including U.S. Patents RE46,386 and 8,924,502:
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26 139. In addition, at the time of this email, the Ignision installer stated that
27 Ignision Server was protected by the asserted patents and identified them by their
28 numbers, U.S. Patents RE46,386 and 8,924,502.
40
1 140. Based on the foregoing, Apple knew that its customers use of the accused
2 products would infringe the 502 patent, or alternatively was aware that there was a
3 high probability that its customers use of the accused products infringe and took
4 deliberate acts to avoid confirming this.
5 141. As a result, Apple has indirectly infringed and continues to indirectly
6 infringe the 502 patent by inducing its customers to use its accused products in an
7 infringing manner, and knowing or being willfully blind to the fact that such use would
8 infringe the 502 patent.
9 142. Apple has contributed and continues to contribute to the infringement of
10 the 502 patent by users (including end users and resellers) of its infringing products.
11 Apple offered to sell, sold, and imported, and continues to offer to sell, sell, and import
12 its infringing products that include components, including Screen Sharing, the accused
13 remote desktop clients, and AirPlay Mirroring, that constitute a material part of the
14 invention claimed in the 502 patent, for use in screen sharing and remote desktop
15 control processes that infringe the 502 patent. As shown above, Apple knew of the
16 502 patent and knew that its infringing products were especially made for
17 infringement of the 502 patent and would be used to infringe the 502 patent, or was
18 willfully blind to these facts; that Screen Sharing, the accused remote desktop clients,
19 and AirPlay Mirroring were not a staple article or commodity of commerce; and that
20 they have no substantial non-infringing use. Indeed, any use of Screen Sharing, the
21 accused remote desktop clients, and Airplay Mirroring infringes the claims of the 502
22 patent, as shown for example in exhibit 4; there is no other non-infringing use.
23 143. Apple infringes numerous claims of the 502 patent, including but not
24 limited to representative independent claim 1. A detailed explanation showing one
25 way that the accused Mac devices infringe claim 1 is set forth in exhibit 4. Plaintiffs
26 incorporate exhibit 4 into the complaint by reference.
27 144. Moreover, the Airplay Mirroring feature on the accused iOS devices
28 functions in substantially the same manner as the infringing remote desktop
41
1 applications charted in exhibit 4, and meets each limitation of claim 1 for the same
2 reasons set forth in the attached chart. See Ex. 4.
3 Willful infringement.
4 145. Apples infringement of the 502 patent has been willful and egregious.
5 146. For the reasons stated in paragraphs 102-113 above, Apple knew that the
6 accused products infringed the 502 patent, or alternatively took deliberate steps to
7 avoiding confirming this and was therefore willfully blind to these facts. Plaintiffs
8 incorporate by reference each of the allegations in these paragraphs by reference.
9 In addition, Apples infringement of the 502 patent was not accidentalit
10 resulted from a decision to deliberately copy Aqua Connects patented solution after
11 working closely with Aqua Connect in the 2008-2011 timeframe, and seeing that Aqua
12 Connects technology provided a remote desktop/terminal server solution that its
13 enterprise customers wanted and that overcame problems that Apple could not solve
14 without it.
15 Plaintiffs have been damaged by Apples infringement of the 502 Patent and
16 will suffer additional irreparable damage and impairment of the value of their patent
17 rights unless Apple is enjoined from continuing to infringe the 502 patent.
18 Jury demand
19 Plaintiffs demand trial by jury of all issues.
20
21 Relief Requested
22 Plaintiffs pray for the following relief:
23 A. A judgment in favor of Plaintiffs that Apple has infringed the asserted
24 386 and 502 patents and that the patents are valid, enforceable, and patent-eligible;
25 B. A decree preliminarily and permanently enjoining Apple from infringing
26 the 386 and 502 patents.
27
28
42
1 C. A judgment and order requiring Apple to pay Plaintiffs compensatory

2 damages, costs, expenses, and pre- and post-judgment interest for its infringement of
3 the asserted patents, as provided under 35 U.S.C. 284;
4 D. A judgment that Apple has willfully infringed the 386 and 502 patents
5 and that Plaintiffs are entitled to enhanced damages as a result of such willful
6 infringement.
7 E. A finding that this case is exceptional under 35 U.S.C. 285, at minimum
8 due to Apples willful infringement, and an award of Plaintiffs reasonable attorneys
9 fees and costs; and
10 F. Any and all other relief to which Plaintiffs may be entitled.
11 Dated: October 10, 2017 Respectfully submitted,
12
13 By: /s/ Gregory Dovel
Gregory S. Dovel (Cal. Bar No. 135387)
15
greg@dovel.com
16 Rick Lyon (Cal. Bar No. 229288)
17 rick@dovel.com
Simon Franzini (Cal. Bar No. 287631)
18 simon@dovel.com
201 Santa Monica Blvd., Suite 600
20 Santa Monica, California 90401
21 (310) 656-7066
(310) 656-7069 (fax)
22
23 Attorneys for Plaintiffs Aqua Connect,
24 Inc. and Strategic Technology Partners,
LLC
25
26
27
28
43

Aqua Connect Inc, Strategic Technology Partners v. Apple, Patent Infringement Case

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Aqua Connect Inc, Strategic Technology Partners v. Apple, Patent Infringement Case

Uploaded by

Copyright:

Available Formats

Case 8:17-cv-01762-JVS-KES Document 1 Filed 10/10/17 Page 1 of 44 Page ID #:1

1 Gregory S. Dovel (Cal. Bar No. 135387)

21 APPLE, INC., a California corporation,

1 18. Strategic Technology Partners, LLC is a wholly-owned subsidiary of

1 processor, wherein each of the at least one user computer context is

1 105. Furthermore, software developer Dan Crosby was employed by Aqua

1 111. Apple has contributed and continues to contribute to the infringement of

1 136. Furthermore, software developer Dan Crosby was employed by Aqua

1 C. A judgment and order requiring Apple to pay Plaintiffs compensatory

You might also like