EXHIBIT 2 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 1 of 86 PageID #
Page 1 of 85

U.S. Patent No. 9,615,192 (“’192 Patent”)

Accused Devices: Samsung’s push messaging servers (e.g., Samsung’s Knox and Tizen servers), and all versions and variations thereof since the 

issuance of the asserted patent.

Claim 1

Issued Claim(s) Public Documentation

[1pre]. A message link server 

comprising: 

Samsung’s push messaging servers are each “message link server[s].” See, e.g.,

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 2 of 86 PageID #: 2334
Page 2 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 3 of 86 PageID #: 2335
Page 3 of 85

https://docs.tizen.org/application/web/guides/messaging/push/;

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 4 of 86 PageID #: 2336
Page 4 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

On information and belief, Samsung owns and operates its own push messaging servers, 

including servers for communicating with the Samsung Push Service software on its end user 

devices. See, e.g., 

https://play.google.com/store/apps/details?id=com.sec.spp.push&hl=en_US&gl=US&pli=1; 

https://www.lifewire.com/samsung-push-service-4165507. On information and belief, Samsung 

includes applications in its user devices, such as the “Shop Samsung” and “Galaxy Store” 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 5 of 86 PageID #: 2337
Page 5 of 85

applications, which cause notifications (including marketing notifications) to be sent to user 

devices via Samsung’s push messaging servers. See, e.g.:

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 6 of 86 PageID #: 2338
Page 6 of 85

[1a] a transport services stack to maintain 

a respective secure message link through 

an Internet network between the message 

link server and a respective device link 

agent on each of a plurality of wireless 

end-user devices, each of the wireless 

end-user devices comprising multiple 

software components authorized to 

receive and process data from secure 

message link messages received via a 

device link agent on that device; 

Samsung’s push messaging servers comprise “a transport services stack to maintain a respective 

secure message link through an Internet network between the message link server and a 

respective device link agent on each of a plurality of wireless end-user devices, each of the 

wireless end-user devices comprising multiple software components authorized to receive and 

process data from secure message link messages received via a device link agent on that 

device.” 

For example, Samsung’s push messaging server maintains a secure message link between the 

Tizen Push Server and a device link agent (e.g., software in the Accused Products responsible 

for receiving, decrypting, delivering, and displaying messages received by the Accused 

Products, such as the Tizen App and/or Push Service) on a plurality of devices which comprise 

multiple software components (e.g., operating system software and/or applications) and 

receive/process data from messages sent over the secure message link using a transport stack 

(e.g., the software and configurations that allow connections to be established and secured and 

which are used to transmit data from the server to the device). See, e.g.,

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 7 of 86 PageID #: 2339
Page 7 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 8 of 86 PageID #: 2340
Page 8 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 9 of 86 PageID #: 2341
Page 9 of 85

https://docs.tizen.org/application/web/guides/messaging/push/.

As another example, Samsung’s devices operating in the Samsung Knox ecosystem, for example 

mobile phones and other devices enrolled in the Samsung Knox MDM platform and the 

Samsung Knox servers managing those phones and devices, maintains a secure message link 

between the server and a device link agent (e.g., software in the Accused Products responsible 

for receiving, decrypting, delivering, and displaying messages received by the Accused 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 10 of 86 PageID #:

2342
Page 10 of 85

Products, such as the Knox app and/or other software applications) on a plurality of devices 

which comprise multiple software components and receive/process data from messages sent 

over the secure message link using a transport stack (e.g., the software and configurations that 

allow connections to be established and secured and which are used to transmit data from the 

server to the device)..

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 11 of 86 PageID #:

2343
Page 11 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

On information and belief, Samsung owns and operates its own push messaging servers, 

including servers for communicating with the Samsung Push Service software on its end user 

devices. See, e.g., 

https://play.google.com/store/apps/details?id=com.sec.spp.push&hl=en_US&gl=US&pli=1; 

https://www.lifewire.com/samsung-push-service-4165507. On information and belief, Samsung 

includes applications in its user devices, such as the “Shop Samsung” and “Galaxy Store” 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 12 of 86 PageID #:

2344
Page 12 of 85

applications, which cause notifications (including marketing notifications) to be sent to user 

devices via Samsung’s push messaging servers. See, e.g.:

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 13 of 86 PageID #:

2345
Page 13 of 85

As a further example, the communications link Samsung Knox Manage servers or Knox MDM 

platform and devices being managed by such servers or MDM platform, for example including 

the Knox workspace devices, Android devices, iOS devices, Chrome OS devices, and Windows 

devices illustrated above, comprise a “service control link.” Data and messages transmitted over 

the secure message link between the Samsung Knox Manage servers or Knox MDM platform 

and managed devices are encrypted, and commands and notifications transmitted from such 

servers to devices are messages.

As a further example, the communications link between Samsung’s Tizen servers and Tizen OS 

devices, and Firebase messaging servers and Samsung’s Android devices, comprises a “service 

message link.” Notifications, data, and messages transmitted over these service control links 

from such servers to devices are encrypted, as illustrated above, and are messages.

[1b] an interface to a network to receive 

network element messages from a 

plurality of network elements, the 

received network element messages 

comprising respective message content 

and requests for delivery of the 

respective message content to respective 

wireless end-user devices, the respective 

message content including data for, and 

an identification of, a respective one of 

the authorized software components; and

Samsung’s push messaging servers comprise “an interface to a network to receive network 

element messages from a plurality of network elements, the received network element messages 

comprising respective message content and requests for delivery of the respective message 

content to respective wireless end-user devices, the respective message content including data 

for, and an identification of, a respective one of the authorized software components.” 

For example, Samsung’s push messaging servers receive messages from a plurality of network 

elements (e.g., App Servers) which comprise content and delivery requests to devices and 

software components. See, e.g.,

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 14 of 86 PageID #:

2346
Page 14 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 15 of 86 PageID #:

2347
Page 15 of 85

https://docs.tizen.org/application/web/guides/messaging/push/; 

https://docs.tizen.org/application/native/guides/messaging/push-server/; 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 16 of 86 PageID #:

2348
Page 16 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 17 of 86 PageID #:

2349
Page 17 of 85

https://docs.tizen.org/application/native/guides/messaging/push/.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 18 of 86 PageID #:

2350
Page 18 of 85

As another example, Samsung’s receive messages from a plurality of network elements (e.g.,

App Servers) which comprise content and delivery requests to devices and software components 

in the Knox ecosystem.

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 19 of 86 PageID #:

2351
Page 19 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

On information and belief, Samsung owns and operates its own push messaging servers, 

including servers for communicating with the Samsung Push Service software on its end user 

devices. See, e.g., 

https://play.google.com/store/apps/details?id=com.sec.spp.push&hl=en_US&gl=US&pli=1; 

https://www.lifewire.com/samsung-push-service-4165507. On information and belief, Samsung 

includes applications in its user devices, such as the “Shop Samsung” and “Galaxy Store” 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 20 of 86 PageID #:

2352
Page 20 of 85

applications, which cause notifications (including marketing notifications) to be sent to user 

devices via Samsung’s push messaging servers. See, e.g.:

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 21 of 86 PageID #:

2353
Page 21 of 85

As a further example, the App Servers communicating with Tizen and Firebase notification 

servers (each a network element) send messages such as notifications (network element 

messages comprising respective message content and request for delivery of the respective 

message content), which are routed through Samsung’s Tizen and Knox servers and Google’s 

Firebase messaging servers. Alternatively, administrator devices communicating with Knox 

MDM and Knox Manage servers to manage and control devices in the Knox device group are 

also network elements which send to the Knox servers messages that comprise message content 

and requests for delivery of the message content down to the managed devices. Such messages 

can be device commands transmitted from the administrator devices to managed devices via 

Knox servers (e.g., https://docs.samsungknox.com/admin/knox-manage/send-commands-todevices.htm) or readable notifications. Alternatively, each of the managed devices in a Knox 

MDM group can also comprise network elements sending messages and requests for delivery of 

message content, for example when agents on the managed device monitor and trigger alerts to 

be sent to administrator devices via Knox MDM servers ( e.g., 

https://docs.samsungknox.com/admin/knox-manage/configure-alerts.htm). In each example, 

such messages include data for, and identification of, a respective one of the authorized software 

components (e.g., the application to which the notification and message is delivered, whether it 

is the Knox Agent on the devices, the Knox Manage application on the administrator device, or 

the particular application on the Tizen device receiving a notification).

[1c] a message buffer system including a 

memory and logic,

The Accused Devices include “a message buffer system including a memory and logic.”

For example, Samsung’s push messaging servers include memory (e.g., storage or RAM) to 

store messages (e.g., a buffer system to store messages) and logic (e.g., logic to determine when, 

how, and under what circumstances to store and/or deliver messages). See e.g.,

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 22 of 86 PageID #:

2354
Page 22 of 85

https://docs.tizen.org/application/web/guides/messaging/push/;

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 23 of 86 PageID #:

2355
Page 23 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 24 of 86 PageID #:

2356
Page 24 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 25 of 86 PageID #:

2357
Page 25 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 26 of 86 PageID #:

2358
Page 26 of 85

https://docs.tizen.org/application/native/guides/messaging/push/.

As another example, Samsung’s Knox servers include memory (e.g., storage or RAM) to store 

messages (e.g., a buffer system to store messages) and logic (e.g., computer hardware, software, 

and instructions to determine when, how, and under what circumstances to store and/or deliver 

messages).

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 27 of 86 PageID #:

2359
Page 27 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 28 of 86 PageID #:

2360
Page 28 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 29 of 86 PageID #:

2361
Page 29 of 85

https://docs.samsungknox.com/admin/knox-configure/updating-an-existing-device-profile.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 30 of 86 PageID #:

2362
Page 30 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 31 of 86 PageID #:

2363
Page 31 of 85

https://docs.samsungknox.com/admin/knox-manage/set-the-profile-update-schedule.htm. 

On information and belief, Samsung owns and operates its own push messaging servers, 

including servers for communicating with the Samsung Push Service software on its end user 

devices. See, e.g., 

https://play.google.com/store/apps/details?id=com.sec.spp.push&hl=en_US&gl=US&pli=1; 

https://www.lifewire.com/samsung-push-service-4165507. On information and belief, Samsung 

includes applications in its user devices, such as the “Shop Samsung” and “Galaxy Store” 

applications, which cause notifications (including marketing notifications) to be sent to user 

devices via Samsung’s push messaging servers. See, e.g.:

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 32 of 86 PageID #:

2364
Page 32 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 33 of 86 PageID #:

2365
Page 33 of 85

[1d] the memory to buffer content from 

the received network element messages 

for which delivery is requested to a given 

one of the wireless end-user devices,

The Accused Devices include “the memory to buffer content from the received network element 

messages for which delivery is requested to a given one of the wireless end-user devices.”

For example, Samsung’s push messaging servers include memory (e.g., storage or RAM) to 

store content (e.g., a buffer system to store data) from received messages for delivery to a 

device, such as by storing a message until the application is running. See e.g.,

https://docs.tizen.org/application/web/guides/messaging/push/;

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 34 of 86 PageID #:

2366
Page 34 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 35 of 86 PageID #:

2367
Page 35 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 36 of 86 PageID #:

2368
Page 36 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 37 of 86 PageID #:

2369
Page 37 of 85

https://docs.tizen.org/application/native/guides/messaging/push/.

As another example, Samsung’s Knox servers include memory to store content from received 

messages for delivery to a device.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 38 of 86 PageID #:

2370
Page 38 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 39 of 86 PageID #:

2371
Page 39 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 40 of 86 PageID #:

2372
Page 40 of 85

https://docs.samsungknox.com/admin/knox-configure/updating-an-existing-device-profile.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 41 of 86 PageID #:

2373
Page 41 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 42 of 86 PageID #:

2374
Page 42 of 85

https://docs.samsungknox.com/admin/knox-manage/set-the-profile-update-schedule.htm. 

[1e] the logic to determine when one of a 

plurality of message delivery triggers for 

the given one of the wireless end-user 

devices has occurred, wherein for at least 

some of the received network element 

messages, the receipt of such a message 

by the message buffer system is not a 

The Accused Devices include “the logic to determine when one of a plurality of message 

delivery triggers for the given one of the wireless end-user devices has occurred, wherein for at 

least some of the received network element messages, the receipt of such a message by the 

message buffer system is not a message delivery trigger, and for at least one of the message 

delivery triggers, the trigger is an occurrence of an asynchronous event with time-critical 

messaging needs.”

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 43 of 86 PageID #:

2375
Page 43 of 85

message delivery trigger, and for at least 

one of the message delivery triggers, the 

trigger is an occurrence of an 

asynchronous event with time-critical 

messaging needs, and

For example, Samsung’s push messaging servers include logic (e.g., computer hardware, 

software, and instructions to determine when, how, and under what circumstances to store 

and/or deliver messages) to determine whether a delivery trigger that is not based on the receipt 

of the message (e.g., an event other than the arrival of the message) has occurred, such as when 

an event with time-critical messaging needs arises (e.g., when the application is running). See 

e.g.,

https://docs.tizen.org/application/web/guides/messaging/push/;

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 44 of 86 PageID #:

2376
Page 44 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 45 of 86 PageID #:

2377
Page 45 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 46 of 86 PageID #:

2378
Page 46 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 47 of 86 PageID #:

2379
Page 47 of 85

https://docs.tizen.org/application/native/guides/messaging/push/.

As another example, Samsung’s Knox servers include logic (e.g., computer hardware, software, 

and instructions to determine when, how, and under what circumstances to store and/or deliver 

messages) to determine whether a delivery trigger that is not based on the receipt of the message 

(e.g., an event other than the arrival of the message) has occurred, such as when an event with 

time-critical messaging needs arises (e.g., when the application is running) .

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 48 of 86 PageID #:

2380
Page 48 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 49 of 86 PageID #:

2381
Page 49 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 50 of 86 PageID #:

2382
Page 50 of 85

https://docs.samsungknox.com/admin/knox-configure/updating-an-existing-device-profile.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 51 of 86 PageID #:

2383
Page 51 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 52 of 86 PageID #:

2384
Page 52 of 85

https://docs.samsungknox.com/admin/knox-manage/set-the-profile-update-schedule.htm. 

As a further example, Samsung’s Tizen servers and Knox servers are able to deliver commands 

and messages to devices (such as Tizen OS smartwatches and televisions), Knox-managed 

devices, and Knox administrator devices when an asynchronous event with time-critical 

messaging needs is detected within the network. Such events include, for example, the detection 

of specific events monitored by software at a device (e.g., 

https://docs.samsungknox.com/admin/knox-manage/configure-alerts.htm, and purchase or 

billing transactions initiated by one device). As another example, an asynchronous event with 

time-critical messaging needs may be the detection of a device as having been connected to the 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 53 of 86 PageID #:

2385
Page 53 of 85

Internet, Knox servers, or Tizen servers, in which case messages intended for that device are 

delivered to the device at that point. 

[1f] upon determining that one of the 

message delivery triggers has occurred, 

the logic further to supply one or more 

messages comprising the buffered 

content to the transport services stack for 

delivery on the secure message link 

maintained between the transport 

services stack and a device link agent on 

the given one of the wireless end-user 

devices.

The Accused Devices include “upon determining that one of the message delivery triggers has 

occurred, the logic further to supply one or more messages comprising the buffered content to 

the transport services stack for delivery on the secure message link maintained between the 

transport services stack and a device link agent on the given one of the wireless end-user 

devices.”

For example, Samsung’s push messaging servers comprise logic (e.g., computer hardware, 

software, and instructions to determine when, how, and under what circumstances to store 

and/or deliver messages) which supplies buffered content for delivery via the transport services 

stack (e.g., hardware and software responsible for communicating data) on a secure message 

link (e.g., a secure network connection) between the transport services stack and a device link 

agent (operating system software or applications on the device) on the device. See e.g.,

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 54 of 86 PageID #:

2386
Page 54 of 85

https://docs.tizen.org/application/web/guides/messaging/push/;

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 55 of 86 PageID #:

2387
Page 55 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 56 of 86 PageID #:

2388
Page 56 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 57 of 86 PageID #:

2389
Page 57 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 58 of 86 PageID #:

2390
Page 58 of 85

https://docs.tizen.org/application/native/guides/messaging/push/.

As another example, Samsung’s Knox servers comprise logic (e.g., computer hardware, 

software, and instructions to determine when, how, and under what circumstances to store 

and/or deliver messages) which supplies buffered content for delivery via the transport services 

stack (e.g., hardware and software responsible for communicating data) on a secure message 

link (e.g., a secure network connection) between the transport services stack and a device link 

agent (operating system software or applications on the device) on the device.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 59 of 86 PageID #:

2391
Page 59 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 60 of 86 PageID #:

2392
Page 60 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 61 of 86 PageID #:

2393
Page 61 of 85

https://docs.samsungknox.com/admin/knox-configure/updating-an-existing-device-profile.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 62 of 86 PageID #:

2394
Page 62 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 63 of 86 PageID #:

2395
Page 63 of 85

https://docs.samsungknox.com/admin/knox-manage/set-the-profile-update-schedule.htm. 

As a further example, Samsung’s Tizen and Knox products utilize communication layers 

comprising a transport services stack at the servers and devices to which the servers are 

connected. As one example, the secure control link between Knox servers and Knox-managed 

devices communicate through specific software residing on both Knox servers (Knox Manage 

software) and Knox-managed devices (e.g., Knox agent at the devices) which receives, decrypts

and decodes, interprets, and executes commands or messages from other elements in the system. 

Likewise, with Samsung’s Tizen devices, specific software within both Tizen OS and Tizen’s 

push messaging servers operate in a similar fashion. 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 64 of 86 PageID #:

2396
Page 64 of 85

Claim 2

2. The message link server of claim 1, 

further comprising an encrypt function to 

encrypt the one or more messages 

supplied to the transport services stack 

for delivery on the secure message link 

maintained between the message link 

server and the device link agent on the 

given one of the wireless end-user 

devices.

The Accused Devices comprise the “message link server of claim 1, further comprising an 

encrypt function to encrypt the one or more messages supplied to the transport services stack for 

delivery on the secure message link maintained between the message link server and the device 

link agent on the given one of the wireless end-user devices.”

For example, the message link servers of the accused instrumentalities use encryption protocols 

to secure communications between the device and the network system. See e.g.,

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 65 of 86 PageID #:

2397
Page 65 of 85

https://www.samsung.com/us/security/;

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 66 of 86 PageID #:

2398
Page 66 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 67 of 86 PageID #:

2399
Page 67 of 85

https://firebase.google.com/docs/cloud-messaging/fcm-architecture; 

https://firebase.google.com/docs/cloud-messaging/conceptoptions#encryption_for_data_messages. 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 68 of 86 PageID #:

2400
Page 68 of 85

https://docs.samsungknox.com/admin/fundamentals/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 69 of 86 PageID #:

2401
Page 69 of 85

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

The messages passed between servers of the accused instrumentalities and end user devices are 

also secured. As another example, the Tizen Push Server receives encrypted information from 

app servers and transmits such encrypted information on to device messaging agents residing on 

user devices, which in turn decrypt received messages. 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 70 of 86 PageID #:

2402
Page 70 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 71 of 86 PageID #:

2403
Page 71 of 85

https://docs.tizen.org/application/native/guides/messaging/push/#managing-security

As another example, the Firebase framework encrypts messages in transit. See: 

https://firebase.google.com/docs/cloud-messaging/concept-options (“Encryption for data 

messages The Android Transport Layer (see FCM architecture) uses point-to-point 

encryption.”).

Likewise, messages sent with Knox Manage instrumentalities are also encrypted. See 

https://docs.samsungknox.com/admin/fundamentals/whitepaper/core-platform-security/knoxvault/; https://docs.samsungknox.com/admin/fundamentals/whitepaper/network-security/virtualprivate-networks/.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 72 of 86 PageID #:

2404
Page 72 of 85

Claim 3

3. The message link server of claim 2, 

wherein the encrypted one or more 

messages are transported to the device 

link agent on the given one of the 

wireless end-user devices using one or 

more of encryption on the transport 

services stack, IP (Internet Protocol) 

layer encryption, and tunneling.

The accused instrumentalities comprise the “message link server of claim 2, wherein the 

encrypted one or more messages are transported to the device link agent on the given one of the 

wireless end-user devices using one or more of encryption on the transport services stack, IP 

(Internet Protocol) layer encryption, and tunneling.”

See supra claims 1 and 2.

Claim 4

4. The message link server of claim 1, 

wherein the device link agent executes in 

a secure execution environment on at 

least one of the devices, and at least one 

of the software components executes 

outside of the secure execution 

environment on that device.

The accused instrumentalities comprise the “message link server of claim 1, wherein the device 

link agent executes in a secure execution environment on at least one of the devices, and at least 

one of the software components executes outside of the secure execution environment on that 

device.”

See supra claim 1. As just one example, with Knox-managed devices, the Knox agent (e.g., a 

“device link agent”) software residing on the user device executes from a specially protected 

partition of local memory. This specially protected partition is sometimes referred to as the 

Knox Secure Folder. Applications stored in the Secure Folder partition are managed separately 

with respect to push notifications. Other applications on the user device may be run from outside 

of the Knox Secure Folder partition.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 73 of 86 PageID #:

2405
Page 73 of 85

https://www.samsung.com/uk/support/mobile-devices/what-is-the-secure-folder-and-how-do-iuse-it/

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 74 of 86 PageID #:

2406
Page 74 of 85

https://www.samsung.com/us/support/answer/ANS00081123/

Claim 5

5. The message link server of claim 1, 

wherein the transport services stack is 

further to receive, over each of the 

respective secure message links, upload 

messages forwarded by the respective 

device link agents from at least a subset 

of the device software components, each 

of the upload messages identifying a 

corresponding one of the network 

elements to which the device respective 

software component has requested 

delivery, the network server system using 

the interface to a network to deliver 

content from the upload messages to the 

respective identified network elements.

The accused instrumentalities comprise the “message link server of claim 1, wherein the 

transport services stack is further to receive, over each of the respective secure message links, 

upload messages forwarded by the respective device link agents from at least a subset of the 

device software components, each of the upload messages identifying a corresponding one of 

the network elements to which the device respective software component has requested delivery, 

the network server system using the interface to a network to deliver content from the upload 

messages to the respective identified network elements.”

See supra claim 1.

For example, the end user devices of the accused instrumentalities cause their respective device 

link agents of a subset of the software components on the device to send messages to servers 

such as the App Servers (e.g., from Tizen devices), Knox Manage servers (from Knox managed 

devices), and push messaging servers (e.g., from Samsung’s Android devices). These messages 

include those for sending authentication and verification information to servers.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 75 of 86 PageID #:

2407
Page 75 of 85

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 76 of 86 PageID #:

2408
Page 76 of 85

https://docs.tizen.org/application/web/guides/messaging/push/;

https://docs.samsungknox.com/admin/knox-manage/welcome.htm

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 77 of 86 PageID #:

2409
Page 77 of 85

https://docs.samsungknox.com/admin/knox-manage/km-features.htm

Claim 6

6. The message link server of claim 1, 

wherein at least one of the one or more 

messages for delivery by the transport 

The accused instrumentalities comprise a “message link server of claim 1, wherein at least one 

of the one or more messages for delivery by the transport services stack comprises multiple 

identifier/data pairs.”

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 78 of 86 PageID #:

2410
Page 78 of 85

services stack comprises multiple 

identifier/data pairs. See supra claim 1. See, for example, https://firebase.google.com/docs/cloud-messaging/conceptoptions (“Data messages, by contrast, contain only your user-defined custom key-value pairs. 

Notification messages can contain an optional data payload. Maximum payload for both 

message types is 4000 bytes, except when sending messages from the Firebase console, which 

enforces a 1000 character limit.”); 

https://docs.tizen.org/application/native/guides/messaging/push/ (“The message field contains 

not only the message to show in the quick panel on the device, but also the behaviors that the 

device must take when receiving the notification. The message field is a string that consists of 

key-value pairs. The available pair options are given in the following table.”). On information 

and belief, messages transmitted to and from Knox servers also comprise multiple identifier/data 

pairs.

Claim 7

7. The message link server of claim 1, the 

device messaging agent on at least one of 

the wireless end-user devices further to 

initiate the respective secure Internet data 

message link to the transport services 

stack.

The accused instrumentalities comprise a “message link server of claim 1, the device messaging 

agent on at least one of the wireless end-user devices further to initiate the respective secure 

Internet data message link to the transport services stack.”

See supra claim 1, 5. As explained above, the device messaging agents on the devices may 

initiate secure connections to both app servers and the push messaging servers and Knox 

Manage servers to, inter alia, request push messages and other information and initiate 

authentication procedures. 

Claim 8

8. The message link server of claim 1, 

further comprising a secure server to 

provide secure authorization signatures to 

the given one of the wireless end-user 

devices, the secure authorization 

signatures indicating the authorized 

software components that are allowed to 

The accused instrumentalities comprise the “message link server of claim 1, further comprising 

a secure server to provide secure authorization signatures to the given one of the wireless enduser devices, the secure authorization signatures indicating the authorized software components 

that are allowed to receive data from secure message link messages via the message link server.”

See supra claim 1, 5. As explained above, the device messaging agents on the devices may 

initiate secure connections to both app servers and the push messaging servers and Knox 

Manage servers to, inter alia, request push messages and other information and initiate 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 79 of 86 PageID #:

2411
Page 79 of 85

receive data from secure message link 

messages via the message link server.

authentication procedures. Among these communications are transmissions from apps in the 

user devices to push messaging servers to register said applications as being permitted to receive 

messages and data from the servers. Likewise, Knox Manage software components on the user 

device communicate with Knox servers to authenticate the software on the user device to, 

among other things, allow the device to access Knox-related functionality over the network.

Claim 9

9. The message link server of claim 1, 

wherein one of the message delivery 

triggers is the expiration of a periodic 

timer.

The accused instrumentalities comprise the “message link server of claim 1, wherein one of the 

message delivery triggers is the expiration of a periodic timer.”

As explained in claim 1 supra, various triggers cause transmissions to occur between devices 

and push messaging servers and Knox servers. The transmission trigger may be a time period of 

inactivity or the expiration of a periodic timer.

See, e.g., https://docs.tizen.org/application/web/guides/messaging/push/: 

• “Store the notification at the push service database and request it later when the 

application is launched.

This happens when the action is set to ALERT or SILENT in the message field when 

sending the notification from the application server. When such a notification arrives 

at the device, the push service keeps the notification in the database and waits for 

the request from the application.

For more information, see the Retrieving Missed Push Messages use case.

The difference between the ALERT and SILENT actions is that the former shows an 

alert message in the quick panel and changes the badge count, while the latter does 

not. If the user clicks the alert message in the quick panel, the push service forcibly 

launches the application and delivers the notification.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 80 of 86 PageID #:

2412
Page 80 of 85

Store the notification at the push service database and request it later when the application 

is launched.

You need to set the action to ALERT or SILENT in the message field when sending the 

notification from the application server. When such a notification arrives at the device, the 

push service keeps the notification in the database and waits for the request from the 

application.

You can request for unread notifications from the push service. The request can be 

performed after connecting to the push server when the application is launched.

• Request the unread notifications asynchronously. If there is such a notification, it 

can be received through the _noti_cb() function after 

the _on_state_registered() function returns. Once the request for unread 

notifications is successfully delivered, PUSH_SERVICE_ERROR_NONE is returned.”

Claim 11

11. The message link server of claim 1, 

wherein one of the message delivery 

triggers is the receipt of a transmission on 

the respective secure message link from 

the device link agent of the given one of 

the wireless end-user devices, or a 

response generated to a transmission 

received from that device link agent.

The accused instrumentalities comprise the “message link server of claim 1, wherein one of the 

message delivery triggers is the receipt of a transmission on the respective secure message link 

from the device link agent of the given one of the wireless end-user devices, or a response 

generated to a transmission received from that device link agent.”

As explained in claim 1 supra, various triggers cause transmissions to occur between devices 

and push messaging servers and Knox servers. The transmission trigger may be the receipt by 

the messaging server of a notification from a user device that is has started up and/or is 

requesting push messages.

See, e.g., https://docs.tizen.org/application/web/guides/messaging/push/: 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 81 of 86 PageID #:

2413
Page 81 of 85

• “Store the notification at the push service database and request it later when the 

application is launched.

This happens when the action is set to ALERT or SILENT in the message field when 

sending the notification from the application server. When such a notification arrives 

at the device, the push service keeps the notification in the database and waits for 

the request from the application.

For more information, see the Retrieving Missed Push Messages use case.

The difference between the ALERT and SILENT actions is that the former shows an 

alert message in the quick panel and changes the badge count, while the latter does 

not. If the user clicks the alert message in the quick panel, the push service forcibly 

launches the application and delivers the notification.

Store the notification at the push service database and request it later when the application 

is launched.

You need to set the action to ALERT or SILENT in the message field when sending the 

notification from the application server. When such a notification arrives at the device, the 

push service keeps the notification in the database and waits for the request from the 

application.

You can request for unread notifications from the push service. The request can be 

performed after connecting to the push server when the application is launched.

• Request the unread notifications asynchronously. If there is such a notification, it 

can be received through the _noti_cb() function after 

the _on_state_registered() function returns. Once the request for unread 

notifications is successfully delivered, PUSH_SERVICE_ERROR_NONE is returned.”

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 82 of 86 PageID #:

2414
Page 82 of 85

Claim 12

12. The message link server of claim 11, 

wherein the transmission is a heartbeat 

message generated by the given device 

link agent, or a request received from the 

given device link agent.

The accused instrumentalities comprise the “message link server of claim 11, wherein the 

transmission is a heartbeat message generated by the given device link agent, or a request 

received from the given device link agent.”

As explained in claim 1 supra, various triggers cause transmissions to occur between devices 

and push messaging servers and Knox servers. The transmission trigger may be the receipt by 

the messaging server of a notification from a user device that is has started up and/or is 

requesting push messages.

See, e.g., https://docs.tizen.org/application/web/guides/messaging/push/: 

• “Store the notification at the push service database and request it later when the 

application is launched.

This happens when the action is set to ALERT or SILENT in the message field when 

sending the notification from the application server. When such a notification arrives 

at the device, the push service keeps the notification in the database and waits for 

the request from the application.

For more information, see the Retrieving Missed Push Messages use case.

The difference between the ALERT and SILENT actions is that the former shows an 

alert message in the quick panel and changes the badge count, while the latter does 

not. If the user clicks the alert message in the quick panel, the push service forcibly 

launches the application and delivers the notification.

Store the notification at the push service database and request it later when the application 

is launched.

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 83 of 86 PageID #:

2415
Page 83 of 85

You need to set the action to ALERT or SILENT in the message field when sending the 

notification from the application server. When such a notification arrives at the device, the 

push service keeps the notification in the database and waits for the request from the 

application.

You can request for unread notifications from the push service. The request can be 

performed after connecting to the push server when the application is launched.

• Request the unread notifications asynchronously. If there is such a notification, it 

can be received through the _noti_cb() function after 

the _on_state_registered() function returns. Once the request for unread 

notifications is successfully delivered, PUSH_SERVICE_ERROR_NONE is returned.”

Claim 13

13. The message link server of claim 1, 

wherein one of the message delivery 

triggers is the receipt of a particular 

network element message from one of 

the network elements.

The accused instrumentalities comprise the “message link server of claim 1, wherein one of the 

message delivery triggers is the receipt of a particular network element message from one of the 

network elements.”

As explained supra for claim 1, app servers may communicate with push messaging servers to 

cause messages to be sent to user devices.

Claim 15

15. A method of operating a message link 

server, comprising:

See supra claim 1.

maintaining a respective secure message 

link through an Internet network between 

the message link server and a respective 

device link agent on each of a plurality of 

The accused instrumentalities comprise a method including “maintaining a respective secure 

message link through an Internet network between the message link server and a respective 

device link agent on each of a plurality of wireless end-user devices, each of the wireless endCase 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 84 of 86 PageID #:

2416
Page 84 of 85

wireless end-user devices, each of the 

wireless end-user devices comprising 

multiple software components authorized 

to receive and process data from secure 

message link messages received via a 

device link agent on that device;

user devices comprising multiple software components authorized to receive and process data 

from secure message link messages received via a device link agent on that device.”

See supra claim 1[a].

receiving network element messages 

from a plurality of network elements, the 

received network element messages 

comprising respective message content 

and requests for delivery of the 

respective message content to respective 

wireless end-user devices, the respective 

message content including data for, and 

an identification of, a respective one of 

the authorized software components;

The accused instrumentalities comprise a method including “receiving network element 

messages from a plurality of network elements, the received network element messages 

comprising respective message content and requests for delivery of the respective message 

content to respective wireless end-user devices, the respective message content including data 

for, and an identification of, a respective one of the authorized software components.”

See supra claim 1[b].

buffering content from the received 

network element messages for which 

delivery is requested to a given one of the 

wireless end-user devices;

The accused instrumentalities comprise a method including “buffering content from the received 

network element messages for which delivery is requested to a given one of the wireless enduser devices.”

See supra claim 1[c].

determining when one of a plurality of 

message delivery triggers for the given 

one of the wireless end-user devices has 

occurred, wherein for at least some of the 

received network element messages, the 

receipt of such a message is not a 

message delivery trigger, and for at least 

one of the message delivery triggers, the 

trigger is an occurrence of an 

asynchronous event with time-critical 

messaging needs; and

The accused instrumentalities comprise a method including “determining when one of a 

plurality of message delivery triggers for the given one of the wireless end-user devices has 

occurred, wherein for at least some of the received network element messages, the receipt of 

such a message is not a message delivery trigger, and for at least one of the message delivery 

triggers, the trigger is an occurrence of an asynchronous event with time-critical messaging 

needs.”

See supra claim 1[d].

upon determining that one of the message 

delivery triggers has occurred, supplying 

one or more messages comprising the 

The accused instrumentalities comprise a method including “upon determining that one of the 

message delivery triggers has occurred, supplying one or more messages comprising the 

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 85 of 86 PageID #:

2417
Page 85 of 85

buffered content for delivery on the 

secure message link maintained between 

the message link server and a device link 

agent on the given one of the wireless 

end-user devices.

buffered content for delivery on the secure message link maintained between the message link 

server and a device link agent on the given one of the wireless end-user devices.”

See supra claim 1[e].

Case 2:23-cv-00103-JRG-RSP Document 79-2 Filed 03/19/24 Page 86 of 86 PageID #:

2418