`9796
`
`EXHIBIT L
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 2 of 42 PageID #:
`9797
`
`Exhibit A21
`U.S. Pat. Pub. No. 2006/0223518 published October 5, 2006 (“Haney ’518”)
`
`U.S. Pat. Pub. No. 2006/0223518 (“Haney ’518”) is entitled “Location Sharing and Tracking
`Using Mobile Phones or Other Wireless Devices.” Haney ’518 was published on October 5, 2006
`from an application filed on April 4, 2005. Haney’518 discloses and/or renders obvious Claims 2
`and 10-13 of U.S. Patent No. 8,213,970 alone and/or in combination with other references, as set
`forth in the chart below. Defendants incorporate in this chart all applicable qualifications,
`clarifications, and other statements made in Defendants’ Invalidity Contentions. This invalidity
`claim chart is based on Defendants’ present understanding of Claims 2 and 10-13 and AGIS’s
`apparent construction of the claims, as set forth in AGIS’s Infringement Contentions. Defendants
`are not adopting AGIS’s apparent constructions, nor do Defendants admit the accuracy of any
`particular construction. To the extent the Court finds that this reference does not expressly disclose
`certain limitations in the asserted claims, such limitations would have been inherent and/or
`obvious. By mapping claim language to this reference, Defendants do not imply or admit that the
`claim language satisfies 35 U.S.C. § 112. To the extent any cell lacks citations to the charted
`reference, this should not be taken as an admission that the reference does not disclose the
`corresponding limitation but rather indicates that Defendants do not presently intend to rely on the
`reference as disclosing the limitation based on Defendants’ present understanding of the claim
`limitation.
`
`
`
`
`
`
`
`1
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 3 of 42 PageID #:
`9798
`
`U.S. Patent No.
`8,213,970
`[2.pre] A
`communication
`system for
`transmitting,
`receiving,
`confirming
`receipt, and
`responding to an
`electronic
`message,
`comprising:;
`
`Haney
`
`Haney ’518 discloses and renders obvious a communication system for
`transmitting, receiving, confirming receipt, and responding to an
`electronic message, comprising:
`
`See e.g., Haney ’518 at Abstract (“A system for exchanging GPS or
`other position data between wireless devices for purposes of group
`activities, child location monitoring, work group coordination,
`dispatching of employees, etc. Cell phones and other wireless devices
`with GPS receivers have loaded therein a Buddy Watch Application
`and a TalkControl application. The Buddy Watch application
`communicates with the GPS receiver and other wireless devices
`operated by buddies registered in the users phone as part of buddy
`groups or individually. GPS position data and historical GPS position
`data can be exchanged between cell phones of buddies and instant
`buddies such as tow truck drivers via a buddy watch server. Emergency
`monitoring services can be set up with notifications to programmable
`individuals in case an individual does not respond. Positions and tracks
`can be displayed. TalkControl simplifies and automates the process of
`joining talk groups for walkie talkie services such as that provided by
`Nextel.”).
`See e.g., id. at FIG. 2A, ¶ 59 (“FIG. 2A is a block diagram of the Buddy
`Watch system. A Buddy Watch or Rubicon server communicates with
`wireless devices 2 through 6 via the internet and wireless carrier
`systems 7 and 8. In the claims, the Buddy Tracker software is called the
`GPS position data sharing software application and it is resident on
`each of wireless devices 2 through 6. Generally, communication
`between the handsets and the Rubicon (Buddy Watch) server occurs as
`follows. Each handset communicates data packets through its local
`cellular carrier network via TCP/IP compliant data packets
`encapsulated in cell system packets. The carrier network tower receives
`the packets and strips off the cellular encapsulation and forwards the
`TCP/IP packet to an appropriate gateways connected to the internet 9.
`Routers in the internet route the packet to its destination, generally the
`Buddy Watch server 1. The receiving server validates the content of the
`IP packet to authenticate the sender as a register Rubicon user and to
`verify that the sending phone EIN matches the phone EIN stored in the
`server. Once authenticated, the packet content is processed by the
`server. A response to the request in the packet is prepared using
`information from a database main-tained by the Rubicon server and any
`associated map needed for the response is requested from a map server.
`The complete response is compiled, including any data needed to
`
`
`
`2
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 4 of 42 PageID #:
`9799
`
`render a map on the recipient wireless device display and packetized
`into a TCP/IP packet and sent back to the originator of the request via
`internet routers and carrier gateways that couple the wireless carrier
`systems to the internet. The gateway of the carrier identifies the correct
`tower for the cell in which the recipient's phone is currently resident
`and the packet is encapsulated in a cell system packet and forwarded to
`the appropriate tower where it is transmitted wirelessly to the cell
`phone or other wireless device of the recipient. The wireless device
`then recovers the data in the TC/IP packet and the port address in the
`TCP/IP packet header causes the packet to be routed to the Buddy
`Watch software where it is processed.”).
`
`[2.a] a
`predetermined
`network of
`participants,
`wherein each
`participant has a
`similarly
`equipped
`PDA/cell phone
`that includes a
`
`
`
`
`Haney ’518 discloses and renders obvious a predetermined network of
`participants, wherein each participant has a similarly equipped
`PDA/cell phone that includes a CPU and a touch screen display a CPU
`and memory.
`
`See e.g., Haney ’518 at Abstract (“A system for exchanging GPS or
`other position data between wireless devices for purposes of group
`activities, child location monitoring, work group coordination,
`dispatching of employees, etc. Cell phones and other wireless devices
`with GPS receivers have loaded therein a Buddy Watch Application
`
`
`
`3
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 5 of 42 PageID #:
`9800
`
`CPU and a touch
`screen display a
`CPU and
`memory;
`
`and a TalkControl application. The Buddy Watch application
`communicates with the GPS receiver and other wireless devices
`operated by buddies registered in the users phone as part of buddy
`groups or individually. GPS position data and historical GPS position
`data can be exchanged between cell phones of buddies and instant
`buddies such as tow truck drivers via a buddy watch server. Emergency
`monitoring services can be set up with notifications to programmable
`individuals in case an individual does not respond. Positions and tracks
`can be displayed. TalkControl simplifies and automates the process of
`joining talk groups for walkie talkie services such as that provided by
`Nextel.”).
`See e.g., id. at FIG. 2A, ¶ 59 (“FIG. 2A is a block diagram of the Buddy
`Watch system. A Buddy Watch or Rubicon server communicates with
`wireless devices 2 through 6 via the internet and wireless carrier
`systems 7 and 8. In the claims, the Buddy Tracker software is called the
`GPS position data sharing software application and it is resident on
`each of wireless devices 2 through 6. Generally, communication
`between the handsets and the Rubicon (Buddy Watch) server occurs as
`follows. Each handset communicates data packets through its local
`cellular carrier network via TCP/IP compliant data packets
`encapsulated in cell system packets. The carrier network tower receives
`the packets and strips off the cellular encapsulation and forwards the
`TCP/IP packet to an appropriate gateways connected to the internet 9.
`Routers in the internet route the packet to its destination, generally the
`Buddy Watch server 1. The receiving server validates the content of the
`IP packet to authenticate the sender as a register Rubicon user and to
`verify that the sending phone EIN matches the phone EIN stored in the
`server. Once authenticated, the packet content is processed by the
`server. A response to the request in the packet is prepared using
`information from a database main-tained by the Rubicon server and any
`associated map needed for the response is requested from a map server.
`The complete response is compiled, including any data needed to
`render a map on the recipient wireless device display and packetized
`into a TCP/IP packet and sent back to the originator of the request via
`internet routers and carrier gateways that couple the wireless carrier
`systems to the internet. The gateway of the carrier identifies the correct
`tower for the cell in which the recipient's phone is currently resident
`and the packet is encapsulated in a cell system packet and forwarded to
`the appropriate tower where it is transmitted wirelessly to the cell
`phone or other wireless device of the recipient. The wireless device
`then recovers the data in the TC/IP packet and the port address in the
`
`
`
`4
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 6 of 42 PageID #:
`9801
`
`[2.b] a data
`transmission
`means that
`facilitates the
`transmission of
`electronic files
`between said
`PDA/cell phones
`in different
`locations;
`
`TCP/IP packet header causes the packet to be routed to the Buddy
`Watch software where it is processed.”).
`
`Haney ’518 discloses and renders obvious a data transmission means
`that facilitates the transmission of electronic files between said
`PDA/cell phones in different locations.
`
`See e.g., id. at ¶¶ 170-176 (“All servers programmed with Buddy Watch
`software will have the functionality to: . . . request and receive
`update[s] and regularly scheduled GPS location data from users who
`have their Buddy Watch application turned on on their phones or PDAs
`and to distribute location data and maplets to the phones and PDA of
`the buddies on buddy lists who have their Buddy Watch capability
`turned on.”).
`See e.g., id. at ¶¶ 179-184 (“The client Buddy Watch application and
`phone or PDA platform genus collectively provide the following
`functionality . . . be able to receive maplets from the Buddy Watch
`server with location data rendered thereon and display the maplets.”).
`See also e.g., id. at ¶ 180 (“The phone or PDA must have a display
`large enough to display maplets and be able to download maplets from
`the Buddy Watch server.”).
`See also e.g., id. at FIG. 2D, ¶ 60 (“FIG. 2D shows the mapit page
`where the positions of active users within the radius set up in the
`preferences of the center point XXX within radius YYY is shown.”).
`
`
`
`5
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 7 of 42 PageID #:
`9802
`
`
`
`
`See also e.g., id. at FIGs. 4-5, ¶ 116 (“The mapit function shown at 22
`in FIG. 4 is a function that can be invoked to map the location of Tracie
`Saka on the phone’s display. If Tracie is within range and the Mapit
`function is clicked, a display such as the one shown in FIG. 5 is
`rendered on the phones display showing the general area and showing
`Tracie’s position at 24 with a text box superimposed on the map with
`Tracie’s name rendered therein.”).
`Haney ’518 discloses and renders obvious a sender PDA/cell phone and
`at least one recipient PDA/cell phone for each electronic message.
`
`See e.g., Haney ’518 at Abstract (“A system for exchanging GPS or
`other position data between wireless devices for purposes of group
`activities, child location monitoring, work group coordination,
`dispatching of employees, etc. Cell phones and other wireless devices
`with GPS receivers have loaded therein a Buddy Watch Application
`and a TalkControl application. The Buddy Watch application
`communicates with the GPS receiver and other wireless devices
`operated by buddies registered in the users phone as part of buddy
`groups or individually. GPS position data and historical GPS position
`data can be exchanged between cell phones of buddies and instant
`
`[2.c] a sender
`PDA/cell phone
`and at least one
`recipient
`PDA/cell phone
`for each
`electronic
`message;
`
`
`
`6
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 8 of 42 PageID #:
`9803
`
`buddies such as tow truck drivers via a buddy watch server. Emergency
`monitoring services can be set up with notifications to programmable
`individuals in case an individual does not respond. Positions and tracks
`can be displayed. TalkControl simplifies and automates the process of
`joining talk groups for walkie talkie services such as that provided by
`Nextel.”).
`See e.g., id. at FIG. 2A, ¶ 59 (“FIG. 2A is a block diagram of the Buddy
`Watch system. A Buddy Watch or Rubicon server communicates with
`wireless devices 2 through 6 via the internet and wireless carrier
`systems 7 and 8. In the claims, the Buddy Tracker software is called the
`GPS position data sharing software application and it is resident on
`each of wireless devices 2 through 6. Generally, communication
`between the handsets and the Rubicon (Buddy Watch) server occurs as
`follows. Each handset communicates data packets through its local
`cellular carrier network via TCP/IP compliant data packets
`encapsulated in cell system packets. The carrier network tower receives
`the packets and strips off the cellular encapsulation and forwards the
`TCP/IP packet to an appropriate gateways connected to the internet 9.
`Routers in the internet route the packet to its destination, generally the
`Buddy Watch server 1. The receiving server validates the content of the
`IP packet to authenticate the sender as a register Rubicon user and to
`verify that the sending phone EIN matches the phone EIN stored in the
`server. Once authenticated, the packet content is processed by the
`server. A response to the request in the packet is prepared using
`information from a database main-tained by the Rubicon server and any
`associated map needed for the response is requested from a map server.
`The complete response is compiled, including any data needed to
`render a map on the recipient wireless device display and packetized
`into a TCP/IP packet and sent back to the originator of the request via
`internet routers and carrier gateways that couple the wireless carrier
`systems to the internet. The gateway of the carrier identifies the correct
`tower for the cell in which the recipient's phone is currently resident
`and the packet is encapsulated in a cell system packet and forwarded to
`the appropriate tower where it is transmitted wirelessly to the cell
`phone or other wireless device of the recipient. The wireless device
`then recovers the data in the TC/IP packet and the port address in the
`TCP/IP packet header causes the packet to be routed to the Buddy
`Watch software where it is processed.”).
`Haney ’518 discloses and renders obvious a forced message alert
`software application program including a list of required possible
`responses to be selected by a participant recipient of a forced message
`response loaded on each participating PDA/cell phone.
`
`7
`
`[2.d] a forced
`message alert
`software
`application
`
`
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 9 of 42 PageID #:
`9804
`
`
`See also e.g., id. at FIGs. 13A-B, ¶ 68 (“In step 116, cell phone 98 puts
`its encrypted GPS location data into a message according to the chosen
`communication protocol (assume short text message – SMS for short)
`and addresses the message packets to the one or more phones of the
`selected persons with which position information is to be shared.”).
`
`
`program
`including a list of
`required possible
`responses to
`be selected by a
`participant
`recipient of a
`forced message
`response loaded
`on each
`participating
`PDA/cell phone;
`
`
`
`8
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 10 of 42 PageID #:
`9805
`
`
`
`
`
`9
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 11 of 42 PageID #:
`9806
`
`
`
`
`Haney ’518 discloses and renders obvious means for attaching a forced
`message alert software packet to a voice or text message creating a
`forced message alert that is transmitted by said sender PDA/cell phone
`to the recipient PDA/cell phone; said forced message alert software
`packet containing a list of possible required responses and requiring the
`forced message alert software on said recipient PDA/cell phone to
`transmit an Automatic acknowledgment to the sender PDA/cell phone
`as soon as said forced message alert is received by the recipient
`PDA/cell phone.
`
`
`10
`
`[2.e] means for
`attaching a
`forced message
`alert software
`packet to a voice
`or text message
`creating a forced
`message alert
`that is
`transmitted by
`said sender
`
`
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 12 of 42 PageID #:
`9807
`
`PDA/cell phone
`to the recipient
`PDA/cell phone,
`said forced
`message alert
`software packet
`containing a list
`of possible
`required
`responses and
`requiring the
`forced message
`alert software on
`said recipient
`PDA/cell
`phone to transmit
`an Automatic
`acknowledgment
`to the sender
`PDA/cell phone
`as soon as said
`forced message
`alert is received
`by the recipient
`PDA/cell phone;
`
`See e.g., Haney ’518 at Abstract (“A system for exchanging GPS or
`other position data between wireless devices for purposes of group
`activities, child location monitoring, work group coordination,
`dispatching of employees, etc. Cell phones and other wireless devices
`with GPS receivers have loaded therein a Buddy Watch Application
`and a TalkControl application. The Buddy Watch application
`communicates with the GPS receiver and other wireless devices
`operated by buddies registered in the users phone as part of buddy
`groups or individually. GPS position data and historical GPS position
`data can be exchanged between cell phones of buddies and instant
`buddies such as tow truck drivers via a buddy watch server. Emergency
`monitoring services can be set up with notifications to programmable
`individuals in case an individual does not respond. Positions and tracks
`can be displayed. TalkControl simplifies and automates the process of
`joining talk groups for walkie talkie services such as that provided by
`Nextel.”).
`See e.g., id. at FIG. 2A, ¶ 59 (“FIG. 2A is a block diagram of the Buddy
`Watch system. A Buddy Watch or Rubicon server communicates with
`wireless devices 2 through 6 via the internet and wireless carrier
`systems 7 and 8. In the claims, the Buddy Tracker software is called the
`GPS position data sharing software application and it is resident on
`each of wireless devices 2 through 6. Generally, communication
`between the handsets and the Rubicon (Buddy Watch) server occurs as
`follows. Each handset communicates data packets through its local
`cellular carrier network via TCP/IP compliant data packets
`encapsulated in cell system packets. The carrier network tower receives
`the packets and strips off the cellular encapsulation and forwards the
`TCP/IP packet to an appropriate gateways connected to the internet 9.
`Routers in the internet route the packet to its destination, generally the
`Buddy Watch server 1. The receiving server validates the content of the
`IP packet to authenticate the sender as a register Rubicon user and to
`verify that the sending phone EIN matches the phone EIN stored in the
`server. Once authenticated, the packet content is processed by the
`server. A response to the request in the packet is prepared using
`information from a database main-tained by the Rubicon server and any
`associated map needed for the response is requested from a map server.
`The complete response is compiled, including any data needed to
`render a map on the recipient wireless device display and packetized
`into a TCP/IP packet and sent back to the originator of the request via
`internet routers and carrier gateways that couple the wireless carrier
`systems to the internet. The gateway of the carrier identifies the correct
`tower for the cell in which the recipient's phone is currently resident
`
`
`
`11
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 13 of 42 PageID #:
`9808
`
`and the packet is encapsulated in a cell system packet and forwarded to
`the appropriate tower where it is transmitted wirelessly to the cell
`phone or other wireless device of the recipient. The wireless device
`then recovers the data in the TC/IP packet and the port address in the
`TCP/IP packet header causes the packet to be routed to the Buddy
`Watch software where it is processed.”).
`
`Haney ’518 discloses and renders obvious means for requiring a
`required manual response from the response list by the recipient in
`order to clear recipient’s response list from recipient’s cell phone
`display.
`
`See, e.g., Haney ’518 at ¶ 134 (“This is an emergency feature which
`allows tracking down children or elderly people who are no longer
`responding to inquiries sent to their phone. This mode is useful for
`children who do not want to be watched but want a safety line to their
`friends and family in case something happens. A user who wishes to
`use this feature sets up their profile such that the Buddy Watch server
`checks in with them via their Buddy Watch enabled phone on a daily
`basis to determine if all is OK. The user must enter their secret code to
`confirm that all is OK. The phone prompts them to enter this code, and
`a certain number of prompts can be ignored before the system raises
`any alarms.”)
`
`See, e.g., ¶ 134 (“Each user of Buddy Watch can define a profile of
`buddies to which an SOS alert is to be sent in the case of emergency.
`The SOS alert message includes location, time and phone number
`(caller ID) and a preset message for email or Instant Message service
`and a prerecorded voice message. This data is sent in packets addressed
`to the Buddy Watch server when the user gives a command to send the
`SOS message. The Buddy Watch server then receives the SOS
`message, determines who it is from, retrieves the SOS profile stored on
`the server for that user and generates packets for email and IM and
`sends them on the internet and generates packets containing the
`digitized voice message and addresses them to the phones listed in the
`SOS profile and sends those packets to the cellular system central
`switching system 102 in FIG. 16 via internet gateway 148.”)
`Haney ’518 discloses and renders obvious means for receiving and
`displaying a listing of which recipient PDA/cell phones have
`automatically acknowledged the forced message alert and which
`recipient PDA/cell phones have not automatically acknowledged the
`forced message alert.
`
`See e.g., Haney ’518 at Abstract (“A system for exchanging GPS or
`other position data between wireless devices for purposes of group
`
`12
`
`[2.f] means for
`requiring a
`required manual
`response
`from the
`response list
`by the recipient
`in order to clear
`recipient’s
`response
`list from
`recipient’s cell
`phone display;
`
`[2.g] means for
`receiving and
`displaying a
`listing of which
`recipient
`PDA/cell phones
`Have
`automatically
`
`
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 14 of 42 PageID #:
`9809
`
`acknowledged
`the forced
`message alert
`and which
`recipient
`PDA/cell phones
`have not
`automatically
`acknowledged
`the forced
`message alert;
`
`activities, child location monitoring, work group coordination,
`dispatching of employees, etc. Cell phones and other wireless devices
`with GPS receivers have loaded therein a Buddy Watch Application
`and a TalkControl application. The Buddy Watch application
`communicates with the GPS receiver and other wireless devices
`operated by buddies registered in the users phone as part of buddy
`groups or individually. GPS position data and historical GPS position
`data can be exchanged between cell phones of buddies and instant
`buddies such as tow truck drivers via a buddy watch server. Emergency
`monitoring services can be set up with notifications to programmable
`individuals in case an individual does not respond. Positions and tracks
`can be displayed. TalkControl simplifies and automates the process of
`joining talk groups for walkie talkie services such as that provided by
`Nextel.”).
`See e.g., id. at FIG. 2A, ¶ 59 (“FIG. 2A is a block diagram of the Buddy
`Watch system. A Buddy Watch or Rubicon server communicates with
`wireless devices 2 through 6 via the internet and wireless carrier
`systems 7 and 8. In the claims, the Buddy Tracker software is called the
`GPS position data sharing software application and it is resident on
`each of wireless devices 2 through 6. Generally, communication
`between the handsets and the Rubicon (Buddy Watch) server occurs as
`follows. Each handset communicates data packets through its local
`cellular carrier network via TCP/IP compliant data packets
`encapsulated in cell system packets. The carrier network tower receives
`the packets and strips off the cellular encapsulation and forwards the
`TCP/IP packet to an appropriate gateways connected to the internet 9.
`Routers in the internet route the packet to its destination, generally the
`Buddy Watch server 1. The receiving server validates the content of the
`IP packet to authenticate the sender as a register Rubicon user and to
`verify that the sending phone EIN matches the phone EIN stored in the
`server. Once authenticated, the packet content is processed by the
`server. A response to the request in the packet is prepared using
`information from a database main-tained by the Rubicon server and any
`associated map needed for the response is requested from a map server.
`The complete response is compiled, including any data needed to
`render a map on the recipient wireless device display and packetized
`into a TCP/IP packet and sent back to the originator of the request via
`internet routers and carrier gateways that couple the wireless carrier
`systems to the internet. The gateway of the carrier identifies the correct
`tower for the cell in which the recipient's phone is currently resident
`and the packet is encapsulated in a cell system packet and forwarded to
`the appropriate tower where it is transmitted wirelessly to the cell
`
`
`
`13
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 15 of 42 PageID #:
`9810
`
`[2.h] means for
`periodically
`resending said
`forced message
`alert to said
`recipient
`PDA/cell
`phones that have
`not automatically
`acknowledged
`the forced
`message alert;
`
`phone or other wireless device of the recipient. The wireless device
`then recovers the data in the TC/IP packet and the port address in the
`TCP/IP packet header causes the packet to be routed to the Buddy
`Watch software where it is processed.”).
`
`Haney ’518 discloses and renders obvious means for periodically
`resending said forced message alert to said recipient PDA/cell phones
`that have not automatically acknowledged the forced message alert.
`
`See e.g., Haney ’518 at Abstract (“A system for exchanging GPS or
`other position data between wireless devices for purposes of group
`activities, child location monitoring, work group coordination,
`dispatching of employees, etc. Cell phones and other wireless devices
`with GPS receivers have loaded therein a Buddy Watch Application
`and a TalkControl application. The Buddy Watch application
`communicates with the GPS receiver and other wireless devices
`operated by buddies registered in the users phone as part of buddy
`groups or individually. GPS position data and historical GPS position
`data can be exchanged between cell phones of buddies and instant
`buddies such as tow truck drivers via a buddy watch server. Emergency
`monitoring services can be set up with notifications to programmable
`individuals in case an individual does not respond. Positions and tracks
`can be displayed. TalkControl simplifies and automates the process of
`joining talk groups for walkie talkie services such as that provided by
`Nextel.”).
`See e.g., id. at FIG. 2A, ¶ 59 (“FIG. 2A is a block diagram of the Buddy
`Watch system. A Buddy Watch or Rubicon server communicates with
`wireless devices 2 through 6 via the internet and wireless carrier
`systems 7 and 8. In the claims, the Buddy Tracker software is called the
`GPS position data sharing software application and it is resident on
`each of wireless devices 2 through 6. Generally, communication
`between the handsets and the Rubicon (Buddy Watch) server occurs as
`follows. Each handset communicates data packets through its local
`cellular carrier network via TCP/IP compliant data packets
`encapsulated in cell system packets. The carrier network tower receives
`the packets and strips off the cellular encapsulation and forwards the
`TCP/IP packet to an appropriate gateways connected to the internet 9.
`Routers in the internet route the packet to its destination, generally the
`Buddy Watch server 1. The receiving server validates the content of the
`IP packet to authenticate the sender as a register Rubicon user and to
`verify that the sending phone EIN matches the phone EIN stored in the
`server. Once authenticated, the packet content is processed by the
`
`
`
`14
`
`
`
`Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 16 of 42 PageID #:
`9811
`
`server. A response to the request in the packet is prepared using
`information from a database main-tained by the Rubicon server and any
`associated map needed for the response is requested from a map server.
`The complete response is compiled, including any data needed to
`render a map on the recipient wireless device display and packetized
`into a TCP/IP packet and sent back to the originator of the request via
`internet routers and carrier gateways that couple the wireless carrier
`systems to the internet. The gateway of the carrier identifies the correct
`tower for the cell in which the recipient's phone is currently resident
`and the packet is encapsulated in a cell system packet and forwarded to
`the appropriate tower where it is transmitted wirelessly to the cell
`phone or other wireless device of the recipient. The wireless device
`then recovers the data in the TC/IP packet and the port address in the
`TCP/IP packet header causes the packet to be routed to the Buddy
`Watch software where it is processed.”).
`Haney ’518 discloses and renders obvious means for receiving and
`displaying a listing of which recipient PDA/cell phones have
`transmitted a manual response to said forced message alert and details
`the response from each recipient PDA/cell phone that responded.
`
`See, e.g., 2.e, 2.g, 2.h above.
`
`See, e.g., Haney ’518 at ¶ 134 (“This is an emergency feature which
`allows tracking down children or elderly people who are no longer
`responding to inquiries sent to their phone. This mode is useful for
`children who do not want to be watched but want a safety line to their
`friends and family in case something happens. A user who wishes to
`use this feature sets up their profile such that the Buddy Watch server
`checks in with them via their Buddy Watch enabled phone on a daily
`basis to determine if all is OK. The user must enter their secret code to
`confirm that all is OK. The phone prompts them to enter this code, and
`a certain number of prompts can be ignored before the system raises
`any alarms.”)
`
`See, e.g., id. ¶ 134 (“Each user of Buddy Watch can define a profile of
`buddies to which an SOS alert is to be sent in the case of emergency.
`The SOS alert message includes location, time and phone number
`(caller ID) and a preset message for email or Instant Message service
`and a prerecorded voice message. This data is sent in packets addressed
`to the Buddy Watch server when the user gives a command to send the
`SOS message. The Buddy Watch server then receives the SOS
`message, determines who it is from, retrieves the SOS profile stored on
`the server for that user and generates packets for email and IM and
`sends them on the internet and generates packets containing the
`digitized voice message and addresses them to the phones listed in the
`15
`
`[2.i] and means
`for receiving and
`displaying a
`listing of which
`recipient
`PDA/cell phones
`have transmitted
`a manual
`response to
`said forced
`message alert
`and details the
`response from
`each recipient
`PDA/cell phone
`that responded.
`
`
`
`
`
`C