Abstract: A data layered architecture (DLA) system includes a front end (FE) server and a common directory (CD). The FE server includes a processing unit which defines an FE time zone (FETZ) based on the FE server's geographical location and that defines a current date and time of the FETZ. The FE server includes a network interfacing unit which obtains from the CD through the network a subscriber default time zone (SDTZ), a subscriber service time zone (SSTZ), a service activation date (SAD) and a service activation time (SAT). The processing unit selects as service time zone (STZ) for executing the service the SSTZ, if a valid SSTZ exists, or the SDTZ, if a valid SSTZ does not exist, or the FETZ, if a valid SDTZ does not exist. Furthermore, the processing unit only executes the service after checking that the SAD and SAT of the STZ correspond to the current date and time of the FETZ.

Abstract: There are services that can be invoked by the subscribers, or triggered by a network entity, and wherein this invocation or trigger may depend on date or time of the day, namely, time-dependent services. Regarding the execution of these time-dependent services, there might be two problems with the determination of the execution time. The first problem is caused by the nature of so called “Data Layered Architectures” where the service execution servers, referred to as “Front-Ends” and the database servers storing the subscriber data, referred to as “Common Directory” are geographically spread over different time zones. As a consequence, the “Front-End” executes the service according to its own time zone rather than at the time zone where the subscriber is currently located or at home. The second problem is cause by the subscriber when he is roaming in an area located in a different time zone than his home time zone.

Abstract: A LDAP collision detection mechanism and a method are described herein that allow a LDAP client to detect and avoid an update operation collision on an entry within a LDAP directory. The method includes the steps of: (a) reading data from the entry in the directory; (b) processing the retrieved data; (c) sending a request to modify the data in the entry in the directory, wherein the client is assured that the requested modification will not be performed by the directory if another client had previously performed a modification on the data within the entry that was originally read by the client. There are several different embodiments of the LDAP collision detection mechanism and the method described herein.

Abstract: A LDAP collision detection mechanism and a method are described herein that allow a LDAP client to detect and avoid an update operation collision on an entry within a LDAP directory. The method includes the steps of: (a) reading data from the entry in the directory; (b) processing the retrieved data; (c) sending a request to modify the data in the entry in the directory, wherein the client is assured that the requested modification will not be performed by the directory if another client had previously performed a modification on the data within the entry that was originally read by the client. There are several different embodiments of the LDAP collision detection mechanism and the method described herein.