Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 1 of 31 PageID #: 2055
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 1 of 31 PageID #: 2055
`
`
`
`
`EXHIBIT B
`EXHIBIT B
`
`
`
`
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 2 of 31 PageID #: 2056
`
`Methods and systems for determining an unread message count
`Nachman April 27, 2
`
`uspto.report (https://uspto.report/) › / patents (https://uspto.report/patent) › / WhatsApp Inc. (https://uspto.report/company/Whatsapp-Inc) ›
`/ Applicant
`/ Patent 16/237,267 (https://uspto.report/patent/grant/10992633)
`
`Expe U.S. Trademark Aorney
`
`Aorney Available For Your Questions Before And Aer
`Filing
`
`JPG Legal
`
`Open
`
`uspto.report (https://uspto.report/) › / patents (https://uspto.report/patent) › / WHATSAPP INC. (https://uspto.report/company/Whatsapp-Inc) ›
`/ Assignee
`/ Patent 16/237,267 (https://uspto.report/patent/grant/10992633)
`
`uspto.report (https://uspto.report/) › / patents (https://uspto.report/patent) › / Nachman; George (https://uspto.report/company/Nachman-George) ›
`/ Inventors
`/ Patent 16/237,267 (https://uspto.report/patent/grant/10992633)
`
`Patent Grant 10992633
`U.S. patent number 10,992,633 [Application Number 16/237,267] was granted by the patent office on
`2021-04-27 for methods and systems for determining an unread message count. This patent grant is
`currently assigned to WHATSAPP INC.. The grantee listed for this patent is WhatsApp Inc.. Invention is
`credited to George Nachman.
`
`https://uspto.report/patent/grant/10992633
`
`1/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 3 of 31 PageID #: 2057
`
`
`
`View All Diagrams
`
`United States Patent
`Nachman
`
`10,992,633
`April 27, 2021
`
`https://uspto.report/patent/grant/10992633
`
`2/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 4 of 31 PageID #: 2058
`Methods and systems for determining an unread message count
`
`Abstract
`Exemplary embodiments relate to techniques for providing more accurate counts relating to unread
`messages in a communications system. Conventionally, the unread count for an app may be inaccurate,
`because the local application does not synchronize its understanding of the unread messages with the
`server. In the described embodiments, both the server and the application inform each other of what they
`understand the unread count to be. The client also informs the server of when the local application is
`backgrounded and foregrounded. With this information, the server is able to update its badge count more
`accurately, and the local client is able to estimate how far off the server's count is. Using the techniques
`described herein, the server may inform the client of its badge-count understanding in a way that does not
`cause the application to wake up on the local device, thereby resulting in less battery consumption.
`
`Inventors:
`Applicant:
`
`Nachman; George (Sunnyvale, CA)
`Name
`City
`StateCountryType
`
`WhatsApp Inc.Menlo Park
`US
`CA
`Assignee: WHATSAPP INC. (Menlo Park, CA)
`Family ID:
`1000003835216
`Appl. No.:
`16/237,267
`Filed:
`December 31, 2018
`
`Current U.S. Class:
`Current CPC Class:
`Current International Class:
`
`1/1
`H04L 51/24 (20130101); H04L 51/04 (20130101); H04L 51/34 (20130101); H04L 51/22 (20130101)
`H04L 12/58 (20060101)
`
`References Cited [Referenced By] (/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=%2Fnetahtml%2Fsearch-
`adv.htm&r=0&f=S&l=50&d=PALL&Query=ref/10992633)
`
`U.S. Patent Documents
`5966351 (/patent/grant/5966351)
`6065012 (/patent/grant/6065012)
`6230185 (/patent/grant/6230185)
`6662212 (/patent/grant/6662212)
`6785712 (/patent/grant/6785712)
`7031437 (/patent/grant/7031437)
`7231434 (/patent/grant/7231434)
`8723823 (/patent/grant/8723823)
`8917717 (/patent/grant/8917717)
`8949956 (/patent/grant/8949956)
`9081469 (/patent/grant/9081469)
`9100218 (/patent/grant/9100218)
`9166892 (/patent/grant/9166892)
`9591086 (/patent/grant/9591086)
`9772985 (/patent/grant/9772985)
`9830045 (/patent/grant/9830045)
`10021058 (/patent/grant/10021058)
`10109175 (/patent/grant/10109175)
`10324614 (/patent/grant/10324614)
`10574610 (/patent/grant/10574610)
`10754503 (/patent/grant/10754503)
`2004/0266400
`(https://uspto.report/patent/app/20040266400)
`2004/0266403
`(https://uspto.report/patent/app/20040266403)
`2005/0020316
`(https://uspto.report/patent/app/20050020316)
`2005/0120306
`(https://uspto.report/patent/app/20050120306)
`
`October 1999
`May 2000
`May 2001
`December 2003
`August 2004
`April 2006
`June 2007
`May 2014
`December 2014
`February 2015
`July 2015
`August 2015
`October 2015
`March 2017
`September 2017
`November 2017
`July 2018
`October 2018
`June 2019
`February 2020
`August 2020
`
`December 2004
`
`December 2004
`
`January 2005
`
`June 2005
`
`Carleton
`Balsara
`Salas
`Chandhok
`Hogan
`Parsons
`Raghunandan
`Shia
`Riley
`Baldwin
`Scott
`Green
`Prado
`Brezina
`Kahn
`Klassen
`Shan
`Roberts
`Agrawal
`Adkins
`Ho
`
`Boland
`
`Boland
`
`Mahini
`
`Klassen
`
`https://uspto.report/patent/grant/10992633
`
`3/30
`
`

`

`Hlad
`
`Newton
`
`Tarn
`
`Britt
`
`Tseng
`
`Wickman
`
`Merrett
`
`Doudkine
`
`Prikowitsch
`
`Cohen
`
`Ophir
`
`Chakra
`
`Dhere
`
`Mahood
`
`Guo
`
`Mahood
`
`Nakamura
`
`Anakata
`
`Bengochea
`
`Kotamarti
`
`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 5 of 31 PageID #: 2059
`2005/0188320
`August 2005
`Bocking
`(https://uspto.report/patent/app/20050188320)
`2006/0284893
`(https://uspto.report/patent/app/20060284893)
`2007/0115936
`(https://uspto.report/patent/app/20070115936)
`2007/0129112
`(https://uspto.report/patent/app/20070129112)
`2008/0261569
`(https://uspto.report/patent/app/20080261569)
`2008/0295017
`(https://uspto.report/patent/app/20080295017)
`2010/0240402
`(https://uspto.report/patent/app/20100240402)
`2011/0039584
`(https://uspto.report/patent/app/20110039584)
`2011/0086613
`(https://uspto.report/patent/app/20110086613)
`2012/0009916
`(https://uspto.report/patent/app/20120009916)
`2012/0149342
`(https://uspto.report/patent/app/20120149342)
`2012/0254770
`(https://uspto.report/patent/app/20120254770)
`2013/0007481
`(https://uspto.report/patent/app/20130007481)
`2013/0039282
`(https://uspto.report/patent/app/20130039282)
`2013/0159389
`(https://uspto.report/patent/app/20130159389)
`2013/0165185
`(https://uspto.report/patent/app/20130165185)
`2013/0185649
`(https://uspto.report/patent/app/20130185649)
`2013/0326367
`(https://uspto.report/patent/app/20130326367)
`2014/0082065
`(https://uspto.report/patent/app/20140082065)
`2014/0280635
`(https://uspto.report/patent/app/20140280635)
`2014/0297771
`(https://uspto.report/patent/app/20140297771)
`2014/0344711
`(https://uspto.report/patent/app/20140344711)
`2015/0350148
`(https://uspto.report/patent/app/20150350148)
`2016/0028677
`(https://uspto.report/patent/app/20160028677)
`2016/0050307
`(https://uspto.report/patent/app/20160050307)
`2016/0323227
`(https://uspto.report/patent/app/20160323227)
`2017/0331776
`(https://uspto.report/patent/app/20170331776)
`Primary Examiner: Grijalva Lobos; Boris D
`Attorney, Agent or Firm: Kacvinsky Daisak Bluni PLLC
`
`December 2006
`
`May 2007
`
`June 2007
`
`October 2008
`
`November 2008
`
`September 2010
`
`February 2011
`
`April 2011
`
`January 2012
`
`June 2012
`
`October 2012
`
`January 2013
`
`February 2013
`
`June 2013
`
`June 2013
`
`July 2013
`
`December 2013
`
`March 2014
`
`September 2014
`
`October 2014
`
`November 2014
`
`December 2015
`
`January 2016
`
`February 2016
`
`November 2016
`
`November 2017
`
`Hallerstrom Sjostedt
`
`Kenney
`
`Narasimhan
`
`Yan
`
`Avdienkov
`
`Bastide
`
`Claims
`
`https://uspto.report/patent/grant/10992633
`
`4/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 6 of 31 PageID #: 2060
`The invention claimed is:
`
`1. A non-transitory computer-readable medium storing instructions that, when executed by a processor, cause the processor to: run a communication
`application on a client device, the communication application capable of establishing a connection to a server to facilitate an exchange of messages
`between the client device and another client device, the messages each capable of being in a read state or an unread state; determine, at the client
`device, a client estimate of a number of messages that are considered to be unread by the server and an adjustment factor known to the client but
`not the server for a number of messages in the client estimate that are known to be read; determine a corrected unread message count based on the
`client estimate and the adjustment factor; and transmit the corrected unread message count from the client to the server, the transmitting configured
`to cause the server to correct an unread message count maintained at the server.
`
`2. The medium of claim 1, further storing instructions for transmitting a background state of the communication application from the client to the
`server, the transmitting of the background state causing the server to correct the unread message count maintained at the server.
`
`You Have No Excuse
`
`Aorney Available For Your Questions Before And
`Aer Filing
`
`JPG Legal
`
`Open
`
`3. The medium of claim 2, wherein the server defaults to setting the communication application to a backgrounded state.
`
`4. The medium of claim 1, further storing instructions for receiving, from the server, the unread message count in a push notification, and for updating
`the client estimate of the number of messages considered to be unread based on the unread message count.
`
`5. The medium of claim 4, wherein the push notification does not cause the communication application to wake up.
`
`6. The medium of claim 4, further storing instructions for receiving the unread message count in response to the server receiving a message in a
`muted conversation.
`
`Sta Your Free Trial
`
`The complete soware solution for the modern
`event professional. All in one place.
`
`Aisle Planner
`
`Learn More
`
`7. The medium of claim 1, further storing instructions for updating a badge of an icon of the communication application using the estimate of the
`unread message count.
`
`8. A method comprising: running a communication application on a client device, the communication application capable of establishing a connection
`to a server to facilitate an exchange of messages between the client device and another client device, the messages each capable of being in a read
`state or an unread state; determining, at the client device, a client estimate of a number of messages that are considered to be unread by the server
`and an adjustment factor known to the client but not the server for a number of messages in the client estimate that are known to be read;
`determining a corrected unread message count based on the client estimate and the adjustment factor; and transmitting the corrected unread
`message count from the client to the server, the transmitting configured to cause the server to correct an unread message count maintained at the
`server.
`
`https://uspto.report/patent/grant/10992633
`
`5/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 7 of 31 PageID #: 2061
`
`9. The method of claim 8, further comprising transmitting a background state of the communication application from the client to the server, the
`transmitting of the background state causing the server to correct the unread message count maintained at the server.
`
`10. The method of claim 9, wherein the server defaults to setting the communication application to a backgrounded state.
`
`11. The method of claim 8, further comprising receiving, from the server, the unread message count in a push notification, and for updating the client
`estimate of the number of messages considered to be unread based on the unread message count.
`
`12. The method of claim 11, wherein the push notification does not cause the communication application to wake up.
`
`13. The method of claim 11, further comprising receiving the unread message count in response to the server receiving a message in a muted
`conversation.
`
`14. The method of claim 8, further comprising updating a badge of an icon of the communication application using the estimate of the unread
`message count.
`
`15. An apparatus comprising: a processor circuit configured to run a communication application on a client device, the communication application
`capable of establishing a connection to a server to facilitate an exchange of messages between the client device and another client device, the
`messages each capable of being in a read state or an unread state; unread message counting logic executable on the processor circuit and
`configured to determine, at the client device, a client estimate of a number of messages that are considered to be unread by the server and an
`adjustment factor known to the client but not the server for a number of messages in the client estimate that are known to be read; determine a
`corrected unread message count based on the client estimate and the adjustment factor; and a network interface configured to transmit the corrected
`unread message count from the client to the server, the transmitting configured to cause the server to correct an unread message count maintained
`at the server.
`
`16. The apparatus of claim 15, and further storing instructions for transmitting a background state of the communication application from the client to
`the server, the transmitting of the background state causing the server to correct the unread message count maintained at the server.
`
`17. The apparatus of claim 15, wherein the network interface is further configured to receive, from the server, the unread message count in a push
`notification, and for updating the client estimate of the number of messages considered to be unread based on the unread message count.
`
`18. The apparatus of claim 17, wherein the push notification does not cause the communication application to wake up.
`
`19. The apparatus of claim 17, wherein the network interface is further configured to receive the unread message count in response to the server
`
`https://uspto.report/patent/grant/10992633
`
`6/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 8 of 31 PageID #: 2062
`receiving a message in a muted conversation.
`
`20. Apparatus of claim 15, wherein the processor circuit is further configured to update a badge of an icon of the communication application using the
`estimate of the unread message count.
`
`Description
`
`BACKGROUND
`
`A number of messaging and email systems maintain a count of the unread messages that have been received by the system but have not yet been
`reviewed by the recipient. This unread message count may be used in several ways; for instance, FIG. 1 depicts an app icon 102 associated with a
`messaging service and displayed on a main interface 100 of a mobile operating system. The app icon 102 includes a badge 104 showing the number
`of unread messages pending for a user of the app. This allows the user to determine, at a glance, whether they need to open the app to review new
`messages.
`
`Other services may use the unread message count in a similar way. In another example, an email program may display, next to each mailbox, the
`number of messages in that mailbox that have not yet been reviewed. Still further, the number and/or trend of unread messages may be used by
`analytics systems to calculate statistics, make predictions, or perform other actions based on the number of unread messages in a user's account.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 depicts an exemplary interface displaying an unread message count;
`
`FIG. 2 depicts an exemplary environment suitable for use with embodiments described herein.
`
`FIG. 3A is a Venn diagram depicting a relationship between various parameters used in exemplary embodiments.
`
`FIG. 3B is a timing diagram depicting an exemplary exchange of information between components of the environment;
`
`FIG. 4 depicts a flowchart showing an exemplary method for determining an unread message count;
`
`FIG. 5A is a block diagram providing an overview of a system including an exemplary centralized communications service;
`
`FIG. 5B is a block diagram providing an overview of a system including an exemplary distributed communications service;
`
`FIG. 5C depicts the social networking graph of FIGS. 5A-5B in more detail;
`
`FIG. 6 is a block diagram depicting an example of a system for a messaging service;
`
`FIG. 7 is a block diagram illustrating an exemplary computing device suitable for use with exemplary embodiments;
`
`FIG. 8 depicts an exemplary communication architecture; and
`
`https://uspto.report/patent/grant/10992633
`
`7/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 9 of 31 PageID #: 2063
`
`FIG. 9 is a block diagram depicting an exemplary multicarrier communications device.
`
`DETAILED DESCRIPTION
`
`In many cases, a messaging or email system's count of unread messages may be inaccurate. With reference to FIG. 2, a communications system
`200 may include a sending client 202-1, a receiving client 202-2, and a server 204. The client 202 may run a communications application 204, which
`may be (e.g.) a simple message service (SMS) application, another type of synchronous or asynchronous messaging application, a
`telecommunication application (e.g., a voicemail application), an email application, or any other type of communications application that exchanges
`messages between users and/or software constructs.
`
`When a message is sent by the sending client 202-1 and addressed to the receiving client 202-2, it is first transmitted to the server 204. The server
`204 maintains a message queue 206 for each client. When a message designated for the receiving client 202-2 is received at the server 204, the
`message is added to the queue 206 for the receiving client.
`
`Within the queue 206, each message may be associated with one or more statuses. When the message has been received by the server 204 but not
`yet delivered to the receiving client 202-2, the message may be in an "undelivered" state. When the receiving client 202-2 establishes a connection
`208 to the server 204 (in one example, the connection may be an Extensible Messaging and Presence Protocol, or "XMPP", connection), the server
`204 may attempt to send the undelivered messages in the queue 206 using a push message 210. For instance, for messaging applications running
`on the iOS operating system, the push message 210 may be a PUSH NOTIFICATION SERVICE (APNS). For other implementations, other types of
`push messages 210 may be used. When the message is successfully pushed to the receiving client, the messages status in the queue 206 may be
`updated from "undelivered" to "delivered."
`
`The part of the queue 206 containing messages that have not yet been delivered (e.g., because the receiving client 202-2 is not connected to the
`server 204) may be referred to as an offline queue. In some messaging implementations, all the messages received by the server 204 are archived at
`the server 204; in others, messages may be deleted from the server 204 when they are delivered to the receiving client 202-2.
`
`In one embodiment, a communications application 212 on the receiving client 202-2 may communicate with the server 204 to retrieve the messages
`designated for the receiving client 202-2. The communications application 212 may be capable of operating in a foreground state on the receiving
`client 202-2 or in a background state of the receiving client 202-2.
`
`In the communication application, 212, messages may either be "read" or "unread." Typically, a message is considered to be "read" when it is
`selected in a messaging/email application at the receiving client 202-2 and displayed on an interface for review (although messages may become
`"read" in other ways). In the examples described below, it is assumed that bringing an application into the foreground marks all outstanding unread
`messages as read, although other implementations are also possible. Depending on the manner in which messages are marked as read, one of
`
`https://uspto.report/patent/grant/10992633
`
`8/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 10 of 31 PageID #:
`2064
`ordinary skill in the art will understand that the states and procedures described below may need to be adjusted slightly to account for when and how
`messages are marked as read. As noted above, the number of messages having the "unread" status may be used for various purposes, such as
`setting a badge notification on an icon of the communication application 212.
`
`One challenge in this setup is to accurately determine the number of unread messages designated for the receiving client 202-2 while the receiving
`client 202-2 is operating in a background state. Conventionally, the number of unread messages is set to the size of the offline queue at the server
`204; if a message is undelivered, it cannot yet have been read. The server 204 may inform the receiving client 202-2 of the size of the offline queue
`using a push message. However, this strategy tends to undercount the number of unread messages, because it does not consider messages that
`have been delivered to the receiving client 202-2 (and are thus not in the offline queue 206) but have not yet been read on the receiving client 202-2.
`Moreover, not all receiving clients 202-2 are capable of receiving all types of push notifications--for instance, iOS 7 does not receive VOIP push
`messages.
`
`Another problem is that this strategy does not account for messages in communication threads that have been muted. A communication thread
`generally refers to a group of messages transmitted between the same group of users. When a message is received in such a communication thread,
`a notification is typically displayed on the interface of the receiving client 202-2. In some cases, this may be undesirable, and so the user may "mute"
`notifications of incoming messages for one or more groups. However, it may still be desirable to include the number of unread messages from muted
`conversations in the unread message count. However, because push notifications are not always sent for messages in muted groups (because such
`messages may not be loaded into the offline message queue 206), the unread message count may not be updated when messages are received for
`a muted group.
`
`A potential solution to this problem is to send push messages (e.g., VOIP push messages) for muted groups. However, as noted above, certain types
`of clients are not capable of receiving all types of push messages. Still further, this solution would cause the receiving client 202-2 to establish
`unnecessary XMPP connections with the server, which would increase the server load and battery drain at the receiving client 202-2.
`
`Thus, there is a need for an improved technique for estimating the number of unread messages designated for a particular client. As described in
`more detail below, according to exemplary embodiments both the server 204 and the communication application 212 inform each other of what they
`understand the unread count to be. The receiving client 202-2 also informs the server 204 of when the local application 212 is backgrounded and
`foregrounded. With this information, the server 204 is able to update its badge count more accurately, and the local client 202-2 is able to estimate
`how far off the server's count is. In some embodiments, the server 204 may inform the client of its badge-count understanding using a particular kind
`of push notification (APNS) which allows the badge count to be loaded into the payload of the notification but does not cause the application to wake
`up on the local device. The result is a more accurate count with fewer client wakeups (and hence less battery consumption).
`
`For example, consider the (conventional) case where the application is running in the background on the receiving client 202-2, at which time it
`receives a push notification indicating that 10 messages are unread and awaiting on the server. The client application may then be brought into the
`foreground. This action may cause the client's number of unread messages to drop to 0. The client application may then be backgrounded.
`
`After this sequence of events, the client believes the unread message count to be 0, whereas the server believes the unread message count to be
`10. If the server then receives another message, it increments the unread message count to 11, which is incorrect (the correct number, from the
`client's perspective, is the 1 new message just received).
`
`It can be seen from this example that, although the unread message count received from the server is inaccurate, the client has partial information
`about what the server "knows." When the application is backgrounded, the application understands that the server still has an unread count of 10
`(based on the last push message received); thus, when a new unread count is received from the server, the client can subtract 10 from the unread
`count to derive the correct number.
`
`In exemplary embodiments described below, the following changes (among others) are made to the conventional system described above: the client
`informs the server when the client application is foregrounded (which may reset the unread message count); the server informs the client of its own
`understanding of the unread message count; and the client also informs the server of its understanding of the unread message count. With this
`information, both the client and the server can derive a more accurate count and better stay in sync with each other.
`
`This brief summary is intended to serve as a non-limiting introduction to the concepts discussed in more detail below. However, before discussing
`further exemplary embodiments, a brief note on data privacy is first provided. A more detailed description of privacy settings and authentication will
`be addressed in connection with the following Figures.
`
`A Note on Data Privacy
`
`Some embodiments described herein make use of training data or metrics that may include information voluntarily provided by one or more users. In
`such embodiments, data privacy may be protected in a number of ways.
`
`For example, the user may be required to opt in to any data collection before user data is collected or used. The user may also be provided with the
`opportunity to opt out of any data collection. Before opting in to data collection, the user may be provided with a description of the ways in which the
`data will be used, how long the data will be retained, and the safeguards that are in place to protect the data from disclosure.
`
`https://uspto.report/patent/grant/10992633
`
`9/30
`
`

`

`Methods and systems for determining an unread message count Patent Grant Nachman April 27, 2 [WhatsApp Inc.]
`5/4/2021
`Case 2:21-cv-00072-JRG-RSP Document 82-3 Filed 06/08/21 Page 11 of 31 PageID #:
`2065
`Any information identifying the user from which the data was collected may be purged or disassociated from the data. In the event that any identifying
`information needs to be retained (e.g., to meet regulatory requirements), the user may be informed of the collection of the identifying information, the
`uses that will be made of the identifying information, and the amount of time that the identifying information will be retained. Information specifically
`identifying the user may be removed and may be replaced with, for example, a generic identification number or other non-specific form of
`identification.
`
`Once collected, the data may be stored in a secure data storage location that includes safeguards to prevent unauthorized access to the data. The
`data may be stored in an encrypted format. Identifying information and/or non-identifying information may be purged from the data storage after a
`predetermined period of time.
`
`Although particular privacy protection techniques are described herein for purposes of illustration, one of ordinary skill in the art will recognize that
`privacy protected in other manners as well. Further details regarding data privacy are discussed below in the section describing network
`embodiments.
`
`Assuming a user's privacy conditions are met, exemplary embodiments may be deployed in a wide variety of messaging systems, including
`messaging in a social network or on a mobile device (e.g., through a messaging client application or via short message service), among other
`possibilities. An overview of exemplary logic and processes for engaging in synchronous video conversation in a messaging system is next provided.
`
`As an aid to understanding, a series of examples will first be presented before detailed descriptions of the underlying implementations are described.
`It is noted that these examples are intended to be illustrative only and that the present invention is not limited to the embodiments shown.
`
`Counting Unread Messages
`
`Reference is now made to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description,
`for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. However, the novel
`embodiments can be practiced without these specific details. In other instances, well known structures and devices are shown in block diagram form
`in order to facilitate a description thereof. The intention is to cover all modifications, equivalents, and alternatives consistent with the claimed subject
`matter.
`
`In the Figures and the accompanying description, the designations "a" and "b" and "c" (and similar designators) are intended to be variables
`representing any positive integer. Thus, for example, if an implementation sets a value for a=5, then a complete set of components 122 illustrated as
`components 122-1 through 122-a may include components 122-1, 122-2, 122-3, 122-4, and 122-5. The embodiments are not limited in this context.
`
`In order to improve the accuracy of unread message counts, exemplary embodiments incorporate both the client and server, working together, to
`minimize the error associated with estimating the count while the client is offline. The following example, described for illustrative purposes, concerns
`a messaging application in which text or multimedia messages may be exchanged, and users may also engage in video calls. An unread message or
`a missed call may contribute to the unread message count.
`
`In order to estimate the unread message count, the following values may be tracked: S: The server's estimate of what the unread message count
`should be. C: The client's estimate of S. Cq: The client's estimate of the length of the server's offline queue. O: The set of messages on the client that
`have not been handled and count as unread. "Handled," in this context, may mean a message that has been decrypted (in an end-to-end encrypted
`system) and added to a message database; alternatively or in addition, "handled" may refer to a message that has been negatively acknowledged
`("NACKed") or dropped for being malformed. L: The number of already-handled messages counted as unread. OC: The number of messages
`counted by C that also belong to O. LC: The number of messages counted by C that are also counted by L. U: The number of messages in C that are
`known (e.g., by the client) to be read. B: The client's estimate of the correct unread message count. Any time the value of B changes, the client may
`update an icon badge or message count on an interface to the same value.
`
`Each of these values may be initialized to 0. Given these definitions, the following statements are true: C.gtoreq.OC+LC+U All numeric values are
`non-negative B=C+|O|+L-OC-LC-U OC.ltoreq.|O| LC.ltoreq.L When the communication application is in the foreground, C=U When the
`communication application is in the foreground, L=0 When the communication application is in the foreground, O={ } When the communication
`application is connected in the foreground, S=C=U=L=LC=OC=0
`
`With refere