throbber
Case 2:22-cv-00263-JRG-RSP Document 122-13 Filed 09/07/23 Page 1 of 42 PageID #:
`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

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket