System and method for data synchronization

: SYSTEM ANOMETHOD FORDATAS YNCHRON1ZATION

TliisapplicationciaimsthebcncfitofU:S.ftqvisionaiApplic^o0!Sr0.62/l5£,384,Tifa1 on May 07, 2015.

TECHNJCALRELD

The present invention i^IàtesgcncraJlytocdmiriûnicâtionsovarà.tetecorùrnunicâtioiis network, and in particular embodiments, lo tcchniques andincchanisms for asyslem and method for data synchronization.

liACKGROUN'D

I>atabasesynchrcmizatipn.tcclmplogiesmaylKusedbyiro^ applications on a client device) to allow a ussrto create aud/or modily data locally orilheclicnt device even when tlte client dcviccis notconriectedrpa.neiwotk. Thus;an enriched. user experiencdcan be provided, which allows themaniptikitiGnofdata without being affected by t he network r^r^tiyity statusofa device. Mrdûlédatabaœsynchrbnizatiqnmechanisnis arc usedto synchronize user data with abackcnd database when a netwenkepnn^ti^ device andthe backcnddatabaseis available. Mobile database synchronization mecltànisnismay alsp be used to provide the client data on multiple iniérfac^,(e.g^iultiplçcl«^ deyices), to back-up (c.g.,createredundantcopiCs) iheclient data.andtlie like. Themser-friendliness.of mobile database synchronization mechanisms: ts lcading to Mfliàredsmgadoption.

As with many asynchronous synchronization mechanisms (e.g„ riot in rçal lime xSynchroni.zationXnibbiledatabascsynchrorjzarionmechanismsnmyrelyonlongpollingbased logic or tcti ve notification based Jogiç. ,Hpwever;thcse methods may not be cfficicnt in terms of network rcsoürce utilization. For example, foiig polling methods ΪΗνοΙνβ^ niobite implication periodically. ppUingaseryerjtp detect.changesindie clirmtdaUimd^ggicsynchronization; Thus, longpolling methods may be inefficient fdrmanaging data that changes infrequently. As another example, active notification based synchronization methods involve the mobile application maintaining a connection with die server to recei ve^notificationsofia-çbangeün client data. Furthermore, notifications may be delivered even when thcmobile application.is nol.io active use.

SUMMARY

Technical ad vantages are «encrally achieved, byembodiments of this disctesure which describe systems rmd medii^Si for provi^ng;datasya<d^izationjati PIT cnviraimcnt

Th accordance, with an embodiment; a method iifdudes jàiéiViâ^bYn cI«miWacIi&ti device, a dalkchangenotification. Tile data change .notificationindicatcsachartge tn data relating, to tlte client ata client data store. The meihodfurther includes de termin i n g.bythëcl ien t,a typeof

-ICA 2971107 2018-12-04

CA 02*7110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231 the data relating to the client changed at the client data store and determining, by the client, a data synchronization mechanism in accordance with the type of the data relating to the client changed at the client data store. Determining the data synchronization mechanism includes determining when to attempt, by the client, a data synchronization to synchronize data on the client device with the data relating to the client changed at the client data store.

Ln accordance with an embodiment, a method includes receiving, by a notification server in a telecommunications services platform, a data change notification. The data change notification indicates a change to data relating to a client at a client data store by one or more services provided by the telecommunications services platform. The method further includes maintaining, by the notification server, a data change notification queue for the client, determining, by the notification server, a state of the data change notification queue, and determining, by the notification server, whether to transmit the data change notification to the client in accordance with the state of the data change notification queue.

In accordance with an embodiment, a telecommunications services platform includes a client data store storing data relating to a push-to-talk (PTT) client on a client device, one or more processors, and a computer readable storage medium storing programming for execution by the one or more processors. The programming includes instructions to provide one or more PTT services to the PTT client and provide a notification server. The notification server is configured to receive a data change notification indicating a change to the data relating to the PTT client by the one or more PTT services, transmit the data change notification to the PTT client when the notification server determines no data change notifications have been transmitted to the PTT client since a most recent time the PTT client successfully synchronized data with the client data store, and not transmit the data change notification to the PTT client when the notification server determines a previous data change notification has been transmitted to the PTT client since the most recent time the PTT client successfully synchronized data with the client data store.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of various example embodiments, and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

Figure 1 illustrates a diagram of an embodiment communications network according to some embodiments;

Figure 2A illustrates a block diagram notification delivery channels a telecommunications services platform according to some embodiments;

-2CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231

Figure 2B illustrates a process flow of notification delivery according to some embodiments;

Figure 3 illustrates a block diagram of notification triggered data synchronization mechanism in a telecommunications services platform according to some embodiments;

Figures 4 through 5 illustrate logic flows for device and server operations according to some embodiments;

Figure 6 illustrates a diagram of an embodiment processing system; and

Figure 7 illustrates a diagram of an embodiment transceiver.

Corresponding numerals and symbols in the different figures generally refer to corresponding parts unless otherwise indicated. The figures are drawn to clearly illustrate the relevant aspects of the embodiments and are not necessarily drawn to scale.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

The making and using of embodiments of this disclosure are discussed in detail below. It should be appreciated, however, that the concepts disclosed herein can be embodied in a wide variety of specific contexts, and that the specific embodiments discussed herein arc merely illustrative and do not serve to limit the scope of the claims. Further, it should be understood that various changes, substitutions and alterations can be made herein without departing from the spirit and scope of this disclosure as defined by the appended claims.

Various embodiments are described within a specific context, namely, data synchronization in a push-to-talk (PTT) system. Various embodiments may, however, be applied to other systems and networks, where data synchronization between a backend client data store and client devices is desired.

Various embodiments as described below provide real-time and non-real-time data synchronization for data across one or more client devices and a backend client data store. Various embodiments allow for the flexibility of receiving data in real-time as well as providing network resource savings when using an asynchronous data synchronization mechanism.

Figure 1 illustrates a communications system 100, which provides an architecture for supporting a telecommunications solution (e.g., a push-to-talk (PTT) communications solution) in accordance with some embodiments. Communications system 100 includes client devices 102, a communications network 104, and a telecommunications services platform 106. As used herein, the term “client device” refers to any component (or collection of components) capable of establishing a connection with a communications network, such as a user equipment (UE), a mobile station (STA), a cellular phone, a tablet, a laptop, and other wired/wirelessly enabled

-3CA 0297110? 2017-06-14

WO 2016/179502

PCT/US2016/031231 devices. Applications (referred to hereinafter as “clients ) reside on client devices 102 for accessing various functions, such as PTT functions, provided by the telecommunications solution.

Client devices 102 may communicate with telecommunications services platform 106 over network 104, which may be accessed by client devices 102 through a cellular network deployed by a carrier, a WiFi network, a radio access network (RAN), other wireless networks, a wired internet protocol (IP) network, combinations thereof, or the like. Network 104 may include one or more components configured to provide wireless or wired network access, such as an enhanced base station (eNB), a macro-cell, a femtocell, a Wi-Fi access point (AP), combinations thereof, or the like. Furthermore, network 104 may operate in accordance with one or more wireless communication protocols, e.g., open mobile alliance (OMA), long term evolution (LTE), LTE advanced (LTE-A), High Speed Packet Access (HSPA), Wi-H 802.1 la/b/g/n/ac, etc. In some embodiments, network 104 may comprise various other devices, such as relays, low power nodes, etc. Network 104 may further include backhaul network components, such as various gateways, routers, controllers, schedulers, and the like.

In an embodiment where telecommunications services platform 106 is a PTT-overCellular (PoC) platform, subscribers to a PTT solution (e.g., users operating client devices 102) may be provisioned onto system 100 via interfaces to carriers (e.g., cellular carriers). PTT customers (e.g., enterprises) can administer these subscribers to form closed groups for PTT communications. The PTT solution may interface with the carrier, for example, by including connectivity to the carrier’s core network, billing interfaces, provisioning interfaces, lawful intercept interfaces, customer care interfaces, and the like. The PTT platform may provide a plurality of PTT functions to client devices 102 through the PTT clients on client devices 102 as described in greater detail below.

In some embodiments, telecommunications services platform 106 uses container technology for virtualization of a telecommunications system architecture, such as, the virtualization of provided PTT services. Example container technologies may include Docker, Rocket, LXD, and the like although the architecture is not limited to a specific container technology. Virtualization using container technology may allow telecommunications services platform 106 to adopt a micro-services model in which service clusters are considered the building blocks of the system architecture. For example, each function provided by telecommunications services platform 106 may be virtualized in a unique service cluster, and each service cluster may perform a different function in telecommunications services platform 106. Service clusters are hosted on virtual machines of an embodiment cloud network. An embodiment cloud network may include a plurality of geographically diverse deployment sites (e.g., data centers) where various virtual machines are physically deployed. Decomposition of the system into a set of services allows each service (e.g., each function provided by the telecommunications

-4o> oï'niioy 20pM>s-i<

WO 2016/179502

PCT/IJS2016/031231 services platform) lo be independently deployed and managed. Thus, system resiliertM may be iijiptoyedas failure,s æelocalizedioiijtli vi&lt;lualservicœ.Furthermore,^apidand agitedeployment ofservices may also.Ireachteyed.

In some embodiments, télécommunications ser vices platform ÏOôîncorporates distributed 5 databases, clustering technologies, data ânaly tics toOlsj imdrhessagingmiddicwarcto provide a robiistrsealable plaiforn)- Teleconimunteations services]>ïatC(>cni jÔ6 niay use fully virtualized componcpts.wifliiaîayeœd approach to-servlce orehcstraiipn; whtetealiowstelecomiimnicadpnsr scrvicespIaiformlOéto bcintegràtcd into vin tous cloud-environments, such as a carrierlsprivate clou4 jnfrastR^utc,.ad^caledT^'d.pudihfrastntcturc, combinationsthereof, andihe.like; A_:10 nwfedeiaileddesert piionof an embodinvmt telecommunications services platformmay befdund incômriyarûy-âSSrgtiéd U.S:.Patent Application. jfo.. 14/994,757jfilcdon January 13,2016, entitled. “System andMethodforEiasliicScaiing. using, a Containcr-BascdPiatform”.

Other telecommunication services platforms, including other- PTT platforms, niay be uscd in other embodiments.

Various embodiments allowdifferent typés of data synchronization mechanismsfori different typcspfdaia.Forcxatnple,sometyj>esofdat;imayl>esynchroiuzed.usingrcal-limedaia synchronization while other typesof data maybe synchronized using non-realdimcdata syncltronizaiion (alsorefeTOdio|s;a^ç<to^u5.d^ herein, ‘‘real.-ttime synchroni^icn’’ refers to a synchronization mechanism whereaefient on a, 20 client device attempts lo synchronize data when a data change notification is received regardless of whcthcr.the client’-is operating passiveiy in the back^pund.ofthe.dientdeyke or actiyelÿïn the foreground of.the.client device. Furthermore, '‘non-real-time. synciirOTization” refens to when a client on acltentdevicewaiis.tobccomeactiveifi the foregroundofa client device before attempting to synchronize data wlien a data change notification is received. Although referred to asanon-re.al-t.iine.^:sytfchromzatiprimeclianiSm.throughoubin practicc_rariembodinx:ht;i«jn-icaltimé synchronization mechanism may include specific instances ofreal-time sÿnchronizaiion.For example, when aclientreceiyesra data change„notification while the client isactive tn the foreground ofiheclient .devicc, lheclient may syncb.ronize data in real-time even for typcs éf data usinga non-real-jimc.syiichronization mechanism; Thus;the useof terms “real-time” and“hon30 real-time”is.not meant to implicitly limit-the actual timing:ofsyndratizatfon. Rather, these terms are used to describe different types of data Synchronization mechanisms, which include different

A ^-pcs .of clicnt behayior upon receipt of a dataehangc notification.

In an embodiment, the type of synchronization is determined by a’t!scr e'xperiencc. desircd for a particular service, and the typo of synchronization typefor a particular service may be configured differently for diflerent types of users; For example, presence and locatfon npdatcs notifications may. bc dclivcrcd in ηοπ-reàl timçi mode foi users al a construction site pr a School .-5CA 2971107 2018-12-04

CA 92971107 Z017-34-14

WO 2016/179502

PCT/US2016/031231 campus whô^iheiitamëreal time focusers In the logistics industry. Thctypcs of data, syncliropizatiiTn mechanisms for types of data maybeepniiguredby a u-ser.a, group administrator, g network administrator, a serviceoperaior/asiandard, combinations thereof, or the like,Different typesofdatamay alsoresuitindifferent typesofiiotiriciilion mechanisms for indicating-a change in data. For example, a nomreai-time synebronizaiion mechanism'mayor may not require real-time data changonotificatiohs 'dcpehding on 1he. typc.0f data as explained tn greater detail below.

FigureZAillustrate different types of notification facchanisms in an embodiment PTT platform .106. When. a.service 202 provided by (he tc!ecomntatücatipns.scryiççs.plàtfonii,106,:

creates or modifies dation ftebtilf of.â.ciient, a data changénotificalKin ànd/w thédàta niayhe transmitted to a cliciit.204 (e.g^, a,client on a clicntdcvicc 1Q2), The tiatadiangenotiGcation, indicates a changelp data relating to client204. was made at the client datastore. is an.

embodiment PTT platform, savices 202 includës a calling serviced» presence service, a messaging service, an extensible markup language (XML) data management (XDM) service, a location service, combi nations thereof, or the like. Other ci.nhodhnenu.inay include other ser vices in addition to oritrlicu of Ihc illustrated services.

Furthermore, PTT platform 106 may include different notification channels, such as, realtime notification channel 206 and non-real-lime notification channel 208. Red-time tiotification channel 206 may be provided through a notifiration service. 210. for example,as described in U.S.

Patent Application No. 15/013/718 filed on February 2,.2016, enlitled/'SessiohManagcmcnl and Notification Mechanisms for.Piish-ft)-Talk (PTT) ”.

Oilier real-time noli ficaiionmochani sins may bcusedj.n other.cmbodiinents.Non-rcal-time notificatiônchànnél 208 may be provided through a data sjTnchTOnizationserver212 which may provide notification-triggered synchronization mechaaisms as dcscribed în grçater detail with respect to Figures 3 through^ below. An embodiment nonriealrtjmè ndtifiéaticm metlÎpdâs described below in greater detail with regards to Figurc2B. Other rtôn_Ti^l-trm'ôn^ifîcàüôri mechanisms may be used as well.

In some embodiments. differerit types ordata changes by dilTerent typcs of services may result, in different types of data syndmmizatfon mechanisms as dctailed in Table !. Different types of data changes may further result in different types of notifications and/or different «•P*!*®¹?·? W.$* corresponding notification. Table I betow provides some exainple typcs of data and corresponding types of noiifications and data synchronization mechanisms iri a PIT platform. In. other embodiments, the types of data chunees niay fesult jn olher types of n<>tificati<>ns/daia synchronization jnecbanfcms, and othcr types of data changes with corresponding types of hotificàiSons/data synciiromzation mcchanisms’may. also cxist in other embodiments. Πιΰ. types of notifications corresponding io differèiittypcspf notifiâittqns/dataTiyïichronization mcchaniiMns

-6CA 2971107 2018-12-04

CA 0297110? 2017-06-14

WO 2016/179502

PCT/US2016/031231 may be configured by a user, a group administrator, a network administrator, a service operator, a standard, combinations thereof, or the like.

Table 1. Types of Data Changes and Corresponding Notification Types

<td> Type of Data Change</td><td> Real-Time Notification Required?</td><td> Contents in Notification (e.g., data change notification)</td><td> Client Synchronization Immediately on Notification?</td><td> Expected Synchronization Invocation on Client Device?</td>

<td> Presence changes</td><td> Not necessary</td><td> Pending change indication</td><td> No; Client marks there is a data change pending for synchronization</td><td> When the client comes to the foreground</td>

<td> XDM changes (contact data and/or group management data changes)</td><td> Not necessary</td><td> Pending change indication</td><td> No; Client marks there is a data change pending for synchronization</td><td> When the client comes to the foreground</td>

<td> Push-to-X text messaging notification</td><td> Yes</td><td> Pending change indication with contents</td><td> No; Client marks there is a data change pending for synchronization</td><td> When the client comes to the foreground</td>

<td> Push-to-X multimedia messaging service (MMS) notification</td><td> Yes</td><td> With meta contents (no attachment contents)</td><td> Conditional. If the user has automatic download for message attachments enabled, data synchronization is done immediately (e.g., in real-time upon receipt of the notification). Otherwise, the data synchronization is invoked when the user requests download of the attachment.</td><td> Meta content is synchronized when the client comes to the foreground. Attachmcnt/multimcdia contents synchronized when the client/user requests content download.</td>

<td> PTT over Cellular (PoC) instant personal alert (IPA); PoC call received data; PoC call sent data (e.g., for tracking call history)</td><td> Yes</td><td> Pending change indication with contents</td><td> No; Client marks there is a data change pending for synchronization</td><td> No explicit synchronization. Synchronization when client invokes data synchronization for other types of data.</td>

<td> Location tracking (e.g., Monitoring device locations of other client devices, such</td><td> Not applicable</td><td> Not applicable</td><td> Devices reporting location or tracking the location continuously are synchronized continuously with a location server (e.g., watcher). Devices that</td><td> Continuous synchronization when location service is active in client.</td>

-7CA 0297110? 2017-06-14

WO 2016/179502

PCT/US2016/031231

<td> as, client devices of contacts and/or groups of client 204)</td><td></td><td></td><td> publish locations periodically synchronizes location data periodically (or using other criteria) with other watcher devices.</td><td></td>

As indicated by Table 1.0, some notifications (e.g., data change notifications) may include at least a portion of the contents of the changed data (e.g., text message contents, meta content, PTT IP A, PTT call status data, and the like) along with a pending change indication for certain types of data. In such embodiments, the contents are received in the notification and further synchronized as described above for archival purposes.

As an example regarding text messages, the data change notification may include a pending change indication as well as contents of the text messages. The notification alerts a user of the existence and contents of a new text message. However, the client may also store the text message as part of text message history (e.g., an archive to allow a user to access threaded message history, to search past text messages, and the like). A master of copy of archive may be maintained by a server (e.g., a client data store). In instances where text message data is synchronized using a non-real-time synchronization mechanism, the client will synchronize archival text message history with the server when the client comes to the foreground when the data change notification for text messages is received.

As another example regarding MMS messages, the data change notification may include a pending change indication as well as meta contents (e.g., sender information, rccipicnt(s) information, subject lines, thumbnails of a MMS attachment, and the like) of the MMS message. The notification alerts a user of the existence and meta contents of the MMS message. However, the client may also store the meta contents of the MMS message history (c.g., an archive to allow a user to access threaded message history, to search past MMS messages, and the like). A master of copy of archive may be maintained by a server (e.g., a client data store). In instances where MMS meta content is synchronized using a non-rcal-timc synchronization mechanism, the client will synchronize archival text message history with the server when the client comes to the foreground when the data change notification for MMS messages is received. The attachment of the MMS message may be synchronized based on client configuration. For example, when the client is configured to automatically download MMS message attachments, data synchronization is done immediately (e.g., in real-time upon receipt of the notification). Otherwise, the data synchronization for the attachment is invoked when the user requests download of the attachment. The above two examples of synchronizing archival data may further be applied for other types of data, such as. IP As, call history data (e.g., call received data, call sent data, call duration data, and the like), combinations thereof, and the like.

-8CA 02*7110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231

Figure 2B illustrates a flow chart 250 for notification delivery in an embodiment platform. The steps in flow chart 250 may be performed by a notification service 210 (e.g., for real-time notifications) in combination with a data synchronization server 212 (e.g., for offline delivery handling). In step 252, a message is received for delivery to a client (e.g., client 204) on a client device (e.g., client device 102). In step 254, a determination is made regarding whether the client is registered. If the client is not registered, the message is transferred for offline delivery handling in step 256. In an embodiment, data in offline delivery handling is synchronized with the client when the client comes online. If the client is registered, an attempt to deliver the message over a session initiation protocol (SIP) session (or other real-time delivery mechanism) is made in step 258. Tn step 260, a determination is made as to whether the message was delivered successfully. If the message was delivered successfully, the process ends in step 280.

If the message was not successfully delivered, a determination is made regarding the type of notification being delivered in step 262. Depending on the type of notification, different notification mechanisms may be used when a message is not successfully delivered. For example, in Figure 2B, Type 1 notifications require real-time delivery. For Type 1 notifications, the transaction is held in step 262 and a secondary notification service is used to trigger the client to reconnect with the primary real-time delivery channel in step 266. If the client successfully reconnects within a timeout period, the message is delivered to the client in step 270 and the process ends. If the client does not successfully reconnect within the timeout period, the message is sent to offline delivery handing (step 256) after tracking the message delivery failure for identifying temporarily unreachable (TU) devices (e.g., devices that are temporarily disconnected from the network and/or the server) and/or offline purposes (step 274). As another example, Type 2 notifications simply trigger clients to reconnect. Thus, for a Type 2 notification, the server uses a secondary notification channel to notify the client to reconnect with the primary real-time notification channel in step 272. Subsequently, the message is sent to offline delivery handing (step 256) after tracking the message delivery failure for TL7offline purpose (step 274). Type 3 notifications are for non-urgent notifications. For delivery failure of Type 3 notifications, the message is sent to offline delivery handing (step 256) after tracking the message delivery failure for TU/offline purpose (step 274) without using the secondary notification channel.

Various embodiments provide mechanisms for real-time and non-real-time data synchronization with improved network resource management. For example, network resources may be wasted on data synchronization of certain types of data when a client is running as a background process. As another example, network resources may be wasted if the client performs a data synchronization check (e.g., check for data changes) every time the client is brought to foreground. Resources used to poll a server for data changes may be especially wasteful for types of data that do not change frequently. For example, configuration change notifications, group list

-9CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231 updates, contact list updates, presence statuses for some types of users, and the like may be examples types of data that do not change frequently. Other types of data may also change infrequently.

In an embodiment, a notification server (e.g., as part of data synchronization server 212 and/or notification service 210) notifies the client when there is a change to data. Subsequently, the notification server may not send any further notifications to the client regarding non-real-time synchronization type data until the client successfully synchronizes data with a backend client data store even when there are additional changes to data relating to the client. In such embodiments, the notification server may or may not transmit subsequent notifications for realtime synchronization type data between an initial notification and when a client successfully synchronizes data with a backend client data store. Thus, network resources may be saved by transmitting a single notification, which indicates to the client that there are data changes at the client data store and triggers the client to synchronize its data with the network. Additional network resources to transmit additional notifications (e.g., for additional changes in data) between a data change notification and data synchronization may be saved. After the client synchronizes data, the notification server may transmit another notification to the client when a subsequent data change occurs. Various notifications from the notification server (including data change notifications) may further be throttled to reduce network resource congestion (e.g., RAN resource congestion) as explained in greater detail below.

Furthermore, for non-real-time synchronization types of data, a client may only perform data synchronization when the user brings the client to the foreground (e.g., when the user opens the client for use). Data synchronization may not be triggered each time the client is brought to the foreground. Rather, the client determines if a data change notification was received since a most recent successful data synchronization to trigger a subsequent data synchronization. In some embodiments, the client may not actively poll the server for changes and relies on data change notifications to determine when a change in data has occurred. The client may further synchronize data with the platform when the client regains network connectivity with the platform after the client was offline. In this way, missed data change notifications (e.g., while the client was offline) does not result in a delay or loss in synchronizing data. Thus, network resources for polling the server for data change (particularly for data that changes infrequently) can be saved.

Figure 3 illustrates a portion of telecommunications services platform 106, which may be used to provide a notification-triggered data synchronization mechanism, which allows real-time and non-real-time dala synchronization for a client 204 on a client device (e.g., client device 102 in Figure 1). Client 204 may use a data synchronization enabled backend client data store 306 (e.g., an electronic database, such as a cloud storage system, or the like) to manage data pertaining to one or more services 202 provided by telecommunications services platform 106. In an

-10CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231 embodiment, client data store 306 may be part of data synchronization server 212 or a separate entity from data synchronization server 212. Data stored in client data store 306 may be created and/or modified by client 204 directly. Any changes initiated by a user (e.g., an operator of the corresponding client device) may be synchronized with client data store 306 when a network connection between client 204 and client data store 306 is available. Backend services 202 may also create and/or modify data in client data store 306 on behalf of client 204. Changes to client data performed in the backend (e.g., performed by services 202) are synchronized to the client through a real-time synchronization mechanism and/or a notification-triggered data synchronization mechanism for non-real-time synchronization depending on the type of data changed. A mobile datasync gateway (GW) 316 facilitates access to client data store 306 by client 204. In an embodiment, mobile datasync GW 316 may be part of data synchronization server 212 or a separate entity from data synchronization server 212. For example, client 204 may back-up data and synchronize changes to data performed by other devices (e.g., services 202 and/or other client devices operated by the user) through mobile datasync GW 316.

In an embodiment, client 204 uses various services 202, and data used for the operation of these services is stored in client data store 306. In an embodiment PTT platform, services 202 may include PTT call servers (e.g., for providing PTT calls), presence servers (e.g., for tracking availability and status of contacts and/or groups), messaging servers (e.g., for text messages, multimedia messages, and/or the like), XDM servers (e.g., for contact data and/or group management data), location services, and the like. Services 202 may transmit client data changes to client data store 306.

When a service 202 creates or modifies data in client data store 306, the service 202 transmits a data change notification to notification server 308. In an embodiment, notification server 308 may be part of notification service 210 or a separate entity (e.g., part of data synchronization server 212). Notification server 308 delivers data change notifications sent by services 202 to client 204. Data change notifications for non-real-time data synchronization types of data may or may not be delivered to a client depending on whether a previous data change notification was delivered and whether a client has completed data synchronization after the previous data change notification and the type of data changed. For example, if a data change notification has already been transmitted to client 204 since the most recent time client 204 successfully performed data synchronization, notification server 308 does not deliver the subsequent data change notification to client 204. As another example, if a data change notification has not been transmitted to client 204 since the most recent time client 204 successfully performed data synchronization, notification server 308 does deliver the data change notification to client 204. Furthermore, a user (or other operator) may designate certain types of data for real-time notifications, and a data change notification may be transmitted for these types

-11CA 02*7110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231 of data each time a change occurs regardless of whether a previous notification was sent since a most recent successful synchronization.

In some embodiments, notification server 308 may further interact with location server 310 and analytics system 312 to determine network resource (e.g., RAN resource) congestion status at the location of client 204 (e.g., the location of the client device on which client 204 resides). Notification server 308 may determine whether to throttle messages (e.g., notifications) when delivering the data change notifications to client 204 in accordance with interactions with location server 310 and analytics system 312.

Location server 310 tracks the RAN location for active clients (e.g., client 204) in the telecommunications services platform. For example, location server 310 may track which cells (e.g., base stations, macro-cells, femtocells, Wi-Fi APs, combinations thereof, and the like) serve clients (e.g., client 204) in the telecommunications services platform. Location information is collected through location updates sent by clients (e.g., client 204). In some embodiments, the client transmits location updates piggy-backed on other messages between the client and the various components of the telecommunications services platform. For example, location updates may be piggy-backed on service requests sent by various clients when accessing services 202.

Various services 202 report user activity to analytics system 312. This user activity data is used by analytics system 312 to create a system wide network resource utilization map (e.g., a RAN utilization map). The network resource utilization map may continuously track and monitor what network resources are being used by different cells in a network.

Notification server 308 may use the network resource utilization map and the location information to determine whether to throttle delivery of data change notifications to clients in congested areas. For example, notification server 308 may ensure that the number of notifications delivered by any cell in the network is below a maximum threshold within a certain time period. For example, notification server 308 allows delivery of data change notifications to clients served by a first cell within a first time period until a maximum number of notifications threshold is reached. The maximum number of notifications threshold and/or time periods may be configurable and set by the telecommunications system operator, a standard, a combination thereof, or the like. Once the maximum number of notifications threshold is reached, notification server 308 may hold additional notifications for delivery by the first cell until the next time period. Thus, network resources arc not overwhelmed by notification delivery.

Various embodiments include real-time and non-real-time data synchronization mechanisms, which advantageously provide data synchronization with improved efficiency in network resource utilization. In an embodiment platform, a client (e.g., a client 204 on client device 102) waits to receive a data change notification from a telecommunications services

-12CA 0297110? 2017-06-14

WO 2016/179502

PCT/US2016/031231 platform to determine when data change(s) has occurred instead of periodically polling a client data store to detect data changes. The client is not required to keep an active connection with the telecommunications services platform to receive pushed data changes in real-time. Instead, as described above with respect to Figure 2B, types of data changes configured for real-time notifications may be pushed to the client when a network connection is available, and the realtime notifications may be queued for delivery while the client is offline. Upon receiving a data change notification, the client may immediately synchronize with a client data store (e.g., sometimes referred to as real-time synchronization) or wait until the client is brought to the foreground of the client device by the user (e.g., non-real-time synchronization). In an embodiment, the data change notification indicates the type of data changed, and the client determines whether to perform real-time or non-real-time synchronization may be in accordance with the type of data changed (e.g.. as configured by a user operating the client device). For example, in an embodiment PTT service as described in Table 1, presence changes, contact data changes, group management data changes, push-to-X text message notifications, push-to-X multimedia message service notifications, PoC IPAs, call-rclatcd notifications (e.g., changes to a PTT call in progress notification, a PTT call completed notification, and the like), combinations thereof, or the like may be synchronized using a non-real-time synchronization mechanism while location tracking data changes (e.g., location tracking of a client’s contacts and/or groups) may use real-time synchronization. In other embodiments, any of the above example types of data (e.g., client data store is presence data, contact data, group management data, a push-to-X text message notification, a push-to-X multimedia message service notification, a push-to-talk (PTT) over cellular (PoC) IPAs, location tracking data, call-related notifications, or a combination thereof) may be synchronized using real-time or non-real-time data synchronization mechanisms as configured by a user, a group administrator, a network administrator, a service operator, a standard, combinations thereof, and the like.

Furthermore, whenever the client is brought to the foreground, the client may not automatically trigger data synchronization. For example, the client may initiate data synchronization if at least one data change notification was received while the client was in the background. As another example, the client may initiate data synchronization if the client temporarily lost network connectivity for at least a configurable interval of time to catch missed data change notifications during the lost network connectivity.

Figure 4 illustrates a logic flow 400 of a client (e.g., client 204) on a client device (e.g., client device 102) implementing an embodiment non-rcal-time data synchronization mechanism. Figure 4 may illustrate interactions between the client, a notification server (e.g., notification server 308), and a data synchronization server (e.g., data synchronization server 212). Logic flow 400 may be used by the client on the client device to determine whether to attempt data

-13CA 0297110? 2017-04-14

WO 2016/179502

PCT/IJS2016/031231 synchronization with a backend server (e.g., data synchronization server 212). A client implementing logic flow 400 may be one of the following three states: inactive state 402, no-datapending state 404, or data-pending state 406.

The client may enter inactive state 402 on startup of the client device and when client loses network connectivity/becomes temporarily unavailable. In inactive state 402, the client attempts to synchronize client data on the client device with data on the client data store (step 408A) as a result of a login attempt (e.g., attempt to re-connect with the client data store) and/or when the client is brought to the foreground (e.g., when the client switches from a background process to an active process). When the client successfully synchronizes data between the client device and the client data store, the client transitions to no-data-pending state 404. If the attempt to synchronize data (step 408A) is unsuccessful, the client determines whether to retry data synchronization (step 408B). For example, the client may retry the attempt to synchronize data until a maximum number of retries (designated MaxRetry) is exhausted. The maximum number of retries may be a configurable number set by the telecommunications services platform, the user, a standard, a combination thereof, or the like. When the maximum number of retries for data synchronization has been exhausted, the client may enter data-pending state 406.

Furthermore, when the client receives a data change notification (e.g., from a notification server) while in inactive state 402, the client determines whether it is running active in the foreground of the client device or passively in the background of the client device (step 408D). For example, the client determines whether it is actively running on the client device or running as a background process of the client device. When the client application is active in the foreground of the client device, client attempts data synchronization (step 408A). Success or failure of the data synchronization procedure may result in transitioning into no-data-pending state 404, data synchronization procedure retries, and/or transitioning into data pending state 406 as discussed above. When the client application is passive in the background of the client device, the client transitions to data-pending state 406 upon receiving the data change notification in inactive state 402.

The client enters no-data-pending state 404 when the client successfully completes data synchronization. When the client receives a data change notification from the server when in nodata-pending state, the client determines whether it is active in the foreground of the client device or passive in the background (step 408C). For example, the client determines whether it is actively running on the client device or running as a background process of the client device. When the client application is active in the foreground of the client device, client attempts data synchronization with the server (step 408A). When the client application is passive in the background of the client device, the client transitions to data-pending state 406 upon receiving the data change notification in no-data-pending state 404.

-14CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231

Success or failure of the data synchronization procedure may result in staying in no-datapending state 404, data synchronization procedure retries, and/or transitioning into data pending state 406 as discussed above. For example, upon successfully synchronizing data in no-datapending state 404, the client remains in no-data-pending state 404. If data synchronization fails in no-data-pending state 404, client retries data synchronization until a maximum number of retry attempts is exhausted. When the maximum number of retry attempts is exhausted, the client enters data-pending state 406. If the client loses network connectivity (e.g., becomes temporarily unavailable to the server) when the client is in no-data-pending state 404, then client transitions to inactive state 402.

The client enters data-pending state 406 when the client has received a data change notification from the server while the client application is passive in the background. The client may further enter data-pending state 406 when attempts at data synchronization have failed more than the maximum number of retry attempts.

In data-pending state 406, the client ignores all subsequent data change notifications received from the notification server. Furthermore, in data-pending state 406, when the client loses network connectivity (e.g., becomes temporarily unavailable to the telecommunications services platform), the client may remain in data-pending state 406.

When the client becomes active (e.g., brought to the foreground by a user or the client device’s operating system), the client attempts data synchronization (step 408A) with a data synchronization server. Success or failure of the data synchronization procedure may result in transitioning into no-data-pending state 404, data synchronization procedure retries, and/or remaining into data-pending state 406 as discussed above. For example, upon successfully synchronizing data in data-pending state 406, the client transitions to no-data-pending state 404. If the data synchronization attempt fails in data-pending state 406, the client retries data synchronization until a maximum number of retry attempts is exhausted. When the maximum number of retry attempts is exhausted, the client remains in data-pending state 406.

Figure 5 illustrates a logic flow 500 of notification server logic for non-real-time data synchronization. When data is created or updated in a client data store (c.g., client data store 306), the notification server sends a data change notification to a client on a client device. The notification server may not send subsequent notifications to the client for subsequent data changes until the client successfully synchronizes data with the client data store. When sending data change notifications to the client, the server may further use location information and real-time service usage data determine network resource (e.g., RAN resource) capacity utilization status. The notification server may determine whether to throttle data change notifications (e.g., to

-15CA 0297110? 2017-06-14

WO 2016/179502

PCT/US2016/031231 reduce RAN congestion) in accordance with the network resource capacity utilization status as described above.

In an embodiment, the notification server maintains a data change notification queue for each mobile client served by the notification server, such as, each client relying on the notification server to deliver notifications, figure 5 illustrate various states of a data change notification queue maintained by notification server for a client device. The data change notification queue may be in any one of the following states: closed state 502, init state 504, no-data-pending state 506, and data-pending state 508.

Data change notification queue is in closed state 502 when the client is offline. In closed state 502, the notification server ignores data changes notifications by the client data store and/or the various services provided by the platform. For example, the notification server may discard all data change notifications relating to the client received while the data change notification queue is in closed state 502. When the client comes online and is connected to the server, the notification server attempts to transmit an initial dala change notification to the client. This notification may be sent regardless of whether any data changes occurred while the client was offline. If the initial data change notification is delivered successfully to the client, the notification server transitions the data change notification queue to data-pending state 508. The initial data change notification triggers the client to attempt data synchronization. If the initial data change notification is not delivered successfully, the notification server transitions the data change notification queue to init state 504.

When a data change notification queue is in init state 504, the notification server may retry sending the initial data change notification to the client one or more times. The data change notification queue stays in init state 504 until the initial data change notification is delivered to the client successfully or the client successfully completes a data synchronization attempt. Upon successful delivery of the initial data change notification, the state of the data change notification queue is transitioned to no-data-pending state 506. Similarly, when the client successfully completes data synchronization while the data change notification queue is in init state 504, the state of the data change notification queue is transitioned to no-data-pending state 506. If the client goes offline when the data change notification queue is in init state 504, the state of the data change notification queue is transitioned to closed state 502. Transitioning to closed stale 502 may further include clearing the data change notification queue.

The data change notification queue enters dala-pending state 508 after at least one data change notification has been delivered to the client. This can occur when the initial data change notification is delivered to the client; at the time of client login; or when a data change

-16CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231 notification is received by the notification server while the data change notification queue is in no-data-pending state 506.

In data-pending state 508, the notification server enqueues subsequent data change events until the client successfully completes data synchronization with a client data store. In an embodiment, the subsequent data change events are determined by the notification server from subsequent data change notifications transmitted to the notification server by the client data store and/or various services in the platform. The notification server may further determine when a client successfully completes data synchronization from a notification transmitted by, for example, a data synchronization server (e.g., data synchronization server 212). In some embodiments, the notification server may optionally transmit data change notifications while in data-pending state 508 for certain types of data (e.g., data where real-time notifications arc desired). When the client retrieves pending data by successfully completing data synchronization, the data change notification queue is transitioned to no-data-pending state 506 and the enqueued data change events may be cleared.

If the client goes offline when the data change notification queue is in data-pending state 508, the data change notification queue is cleared and the state of the data change notification queue is transitioned to closed state 502.

The data change notification queue enters no-data-pending state 506 when the client successfully synchronizes data with the client data store. In no-data-pending state 506, the notification server waits for a data change event to occur (e.g., as reported by a service) and sends a data change notification to the mobile client when the data change event occurs. After sending the data change notification to the client, data change notification queue state is transitioned to data-pending state 508. If the client goes offline when the data change notification queue is in nodata-pending state 506, the state of the data change notification queue is transitioned to closed state 502. Transitioning to closed state 502 may further include clearing the data change notification queue.

In various embodiments, the notification server may also throttle data change notifications based on client location and network resource utilization at the client location. For example, a client reports its location information to a location server as part of its login and login session refresh procedures. The location information may also be piggy-backed in service requests sent by the client. This location information is processed by an analytics system in realtime and a network resource utilization map is generated and maintained by the analytics system. For example, the network resource utilization map may be maintained and updated continuously in real-time to track network resource utilization and/or capacity at various locations in the network. When sending data change notifications to various clients, the notification server may

-17CA 02*7110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231 use of the network resource utilization map to throttle the notifications and not exceed a maximum configured threshold for the network utilization level at any given network location (e.g., any cell).

Figure 6 illustrates a block diagram of an embodiment processing system 600 for performing methods described herein, which may be installed in a host device. As shown, the processing system 600 includes a processor 604, a memory 606, and interfaces 610-614, which may (or may not) be arranged as shown in Figure 6. The processor 604 may be any component or collection of components adapted to perform computations and/or other processing related tasks, and the memory 606 may be any component or collection of components adapted to store programming and/or instructions for execution by the processor 604. In an embodiment, the memory 606 includes a non-transitory computer readable medium. The interfaces 610,612, 614 may be any component or collection of components that allow the processing system 600 to communicate with other devices/components and/or a user. For example, one or more of the interfaces 610,612,614 may be adapted to communicate data, control, or management messages from the processor 604 to applications installed on the host device and/or a remote device. As another example, one or more of the interfaces 610,612,614 may be adapted to allow a user or user device (e.g., personal computer (PC), etc.) to interact/communicate with the processing system 600. The processing system 600 may include additional components not depicted in Figure 6, such as long term storage (e.g., non-volatile memory, etc.).

In some embodiments, the processing system 600 is included in a network device that is accessing, or part otherwise of, a telecommunications network. In one example, the processing system 600 is in a network-side device in a wireless or wireline telecommunications network, such as a base station, a relay station, a scheduler, a controller, a gateway, a router, an applications server, or any other device in the telecommunications network. In other embodiments, the processing system 600 is in a user-side device accessing a wireless or wireline telecommunications network, such as a mobile station, a user equipment (UE), a personal computer (PC), a tablet, a wearable communications device (e.g., a smartwatch, etc.), or any other device adapted to access a telecommunications network.

In some embodiments, one or more of the interfaces 610,612,614 connects the processing system 600 to a transceiver adapted to transmit and receive signaling over the telecommunications network. Figure 7 illustrates a block diagram of a transceiver 700 adapted to transmit and receive signaling over a telecommunications network. The transceiver 700 may be installed in a host device. As shown, the transceiver 700 comprises a network-side interface 702, a coupler 704, a transmitter 706, a receiver 708, a signal processor 710, and a device-side interface 712. The network-side interface 702 may include any component or collection of components adapted to transmit or receive signaling over a wireless or wireline telecommunications network.

-18CA 0297110? 2017-04-14

WO 2016/179502

PCT/IJS2016/031231

The coupler 704 may include any component or collection of components adapted to facilitate bidirectional communication over the network-side interface 702. The transmitter 706 may include any component or collection of components (e.g., up-converter, power amplifier, etc.) adapted to convert a baseband signal into a modulated carrier signal suitable for transmission over the network-side interface 702. The receiver 708 may include any component or collection of components (e.g., down-converter, low noise amplifier, etc.) adapted to convert a carrier signal received over the network-side interface 702 into a baseband signal. The signal processor 710 may include any component or collection of components adapted to convert a baseband signal into a data signal suitable for communication over the device-side interface(s) 712, or vice-versa. Tiie device-side interface(s) 712 may include any component or collection of components adapted to communicate data-signals between the signal processor 710 and components within the host device (e.g., the processing system 600, local area network (LAN) ports, etc.).

The transceiver 700 may transmit and receive signaling over any type of communications medium. In some embodiments, the transceiver 700 transmits and receives signaling over a wireless medium. For example, the transceiver 700 may be a wireless transceiver adapted to communicate in accordance with a wireless telecommunications protocol, such as a cellular protocol (e.g., long-term evolution (LTE), etc.), a wireless local area network (WLAN) protocol (e.g., Wi-Fi, etc.), or any other type of wireless protocol (e.g., Bluetooth, near field communication (NFC), etc.). In such embodiments, the network-side interface 702 comprises one or more antenna/radiating elements. For example, the network-side interface 702 may include a single antenna, multiple separate antennas, or a multi-antenna array configured for multi-layer communication, e.g., single input multiple output (SIMO), multiple input single output (MISO), multiple input multiple output (MIMO), etc. In other embodiments, the transceiver 700 transmits and receives signaling over a wireline medium, e.g., twisted-pair cable, coaxial cable, optical fiber, etc. Specific processing systems and/or transceivers may utilize all of the components shown, or only a subset of the components, and levels of integration may vary from device to device.

In accordance with an embodiment, a method includes receiving, by a client on a client device, a data change notification. The data change notification indicates a change in data relating to the client at a client data store. The method further includes determining, by the client, a type of the data relating to the client changed at the client data store and determining, by the client, a data synchronization mechanism in accordance with the type of the data relating to the client changed at the client data store. Determining the data synchronization mechanism includes determining when to attempt, by the client, a data synchronization to synchronize data on the client device with the data relating to the client changed at the client data store.

-19CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231

In an embodiment, the data synchronization mechanism is a non-real-time data synchronization mechanism. The non-real-time data synchronization mechanism includes determining, by the client, whether the client is running in a foreground of the client device or running in a background of the client device and attempting, by the client, to synchronize the data on the client device with the data relating to the client changed at the client data store when the client device is running in the foreground of the client device. The non-real-time data synchronization mechanism further includes waiting, by the client, until the client is running in the foreground to attempt to synchronize the data on the client device with the data relating to the client changed at the client data store when the client device is running in the background of the client device.

In an embodiment, the type of the data relating to the client changed at the client data store is presence data, contact data, group management data, a push-to-X text message notification, a push-to-X multimedia message service notification, a push-to-talk (PTT) over cellular (PoC) instant personal alert, location tracking data, changes to PTT call in progress notification, a PTT call completed notification, or a combination thereof.

In an embodiment, the data synchronization mechanism is a real-time data synchronization mechanism. The real-time data synchronization mechanism includes attempting, by the client, to synchronize the data on the client device with the data relating to the client changed at the client data store after the data change notification is received regardless of whether the client is running in a foreground of the client device or running in a background of the client device.

In an embodiment, different types of data synchronization mechanisms are selected for different types of data by a user operating the client device, a group administrator, a network administrator, a service operator, a standard, or a combination thereof.

An embodiment method further includes determining, by the client device, whether the data change notification was received after a most recent successful data synchronization on the client device when the client transitions from running in a background of the client device to running in a foreground of the client device and attempting, by the client, to synchronize the data on the client device with the data relating to the client changed at the client data store when the data change notification was received after the most recent successful data synchronization on the client device. The method may further include not attempting, by the client, to synchronize the data on the client device with the data relating to the client changed at the client data store when the data change notification was not received after the most recent successful data synchronization on the client device and the client did not lose network connectivity after the most recent successful data synchronization on the client device.

-20CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231

An embodiment method further includes losing, by the client, network connectivity for at least an interval of time; and attempting, by the client, to synchronize data on the client device with data at the client data store when the client regains network connectivity after losing network connectivity for at least the interval of time.

In an embodiment, the client does not poll the client data store for changes in data relating to the client, and the client is not required to maintain an active connection with the client data store for receiving changes in data relating to the client.

In an embodiment, the data change notification includes at least a portion of the data relating to the client changed at the client data store. The client maintains a first archive of data for the type of the data relating to the client changed at the client data store. The client data store maintains a second archive of data for the type of the data relating to the client changed at the client data store. The data synchronization mechanism is used, by the client, to synchronize the first archive of data with the second archive of data.

In an embodiment, a method includes receiving, by a notification server in a telecommunications services platform, a data change notification. The data change notification indicates a change to data relating to a client at a client data store by one or more services provided by the telecommunications services platform. The method further includes maintaining, by the notification server, a data change notification queue for the client, determining, by the notification server, a state of the data change notification queue, and determining, by the notification server, whether to transmit the data change notification to the client in accordance with the state of the data change notification queue.

In an embodiment, the method further includes further, transmitting, by the notification server, the data change notification to the client when the data change notification queue is in a no-data-pending state. The data change notification queue transitions into the no-data-pending state when the client successfully synchronizes data with the client data store. The method may further include after transmitting the data change notification, transitioning the data change notification queue to a data-pending state.

In an embodiment, the method further includes receiving, by the notification server, one or more additional data change notifications while the data change notification queue is in a datapending state. The one or more additional data change notifications indicates one or more additional changes to data relating to the clienl at the client data store by the one or more services. The method further includes enquequing, by the notification server, the one or more additional data change notifications until the client successfully synchronizes data with the client data store. The method further includes not transmitting, by the notification server, the one or more

-21CA 0297110? 2017-06-14

WO 2016/179502

PCT/IJS2016/031231 additional data change notifications while the data change notification queue is in the datapending state.

In an embodiment, the method further includes ignoring, by the notification server, the data change notification when the data change notification queue is in a closed state. The data change notification queue is in the closed state when the client loses network connectivity. The method further includes transmitting, by the notification server, an initial data change notification to the client when the client regains network connectivity.

In an embodiment, the method further includes throttling, by the notification server, the data change notification in accordance with a location of the client and a network resource utilization map.

In an embodiment, determining, by the notification server, whether to transmit the data change notification to the client in accordance with the state of the data change notification queue includes transmitting the data change notification to the client when the notification server determines no data change notifications have been transmitted to the client since a most recent time the client successfully synchronized data with the client data store and not transmitting the data change notification to the client when the notification server determines a previous data change notification has been transmitted to the client since the most recent time the client successfully synchronized data with the client data store.

In accordance with an embodiment, a telecommunications services platform includes a client data store storing data relating to a push-to-talk (PTT) client on a client device, one or more processors, and a computer readable storage medium storing programming for execution by the one or more processors. The programming includes instructions to provide one or more PIT services to the PTT client and provide a notification server. The notification server is configured to receive a data change notification indicating a change to the data relating to the PTT client by the one or more PIT services, transmit the data change notification to the PIT client when the notification server determines no data change notifications have been transmitted to the PTT client since a most recent time the PTT client successfully synchronized data with the client data store, and not transmit the data change notification to the PTT client when the notification server determines a previous data change notification has been transmitted to the PTT client since the most recent time the PTT client successfully synchronized data with the client data store.

In an embodiment, the telecommunications services platform further includes a location server tracking a geographic location of the PTT client. The notification server is further configured to throttle the data change notification in accordance with the geographic location of the PTT client.

-22CA 0297110? 2017-06-14

WO 2016/179502 PCT/US2016/031231

In an embodiment, the programming includes further instructions to provide an analytics system. The analytics system is configured to receive user activity reports from the one or more PTT services and maintain a network resources utilization map in accordance with the user activity reports. The notification server is further configured to throttle the data change notification in accordance with the network resources utilization map

In an embodiment, the telecommunications services platform further includes a mobile datasync gateway configured to provide access to the client data store by the PTT client.

While this invention has been described with reference to illustrative embodiments, this description is not intended to be construed in a limiting sense. Various modifications and combinations of the illustrative embodiments, as well as other embodiments of the invention, will be apparent to persons skilled in the art upon reference to the description. It is therefore intended that the appended claims encompass any such modifications or embodiments.