Electronic apparatus for providing application synchronization service

Abstract

This server may comprise a communication circuit, a memory for storing instructions, and a processor. The processor may be configured to: receive, from a first device on which an application is being executed, first client identification information including user identification information about the application via the communication circuit; identify, on the basis of the first client identification information, connection information about one or more devices corresponding to the user identification information and including the first device; determine, on the basis of the connection information, whether the first device is an always-on device required for a user; store data indicating the determination result; receive a first session generation request from the first device via the communication circuit; verify, through the stored data in response to the reception of the first session generation request, whether the first device is registered as the always-on device required for the user; and when the first device is registered as the always-on device required for the user, establish a first session for real-time synchronization between the first device and the application.

Description

Electronic device for providing synchronization services for applications

[0001] The present disclosure relates to an electronic device for providing a synchronization service of an application.

[0002] As electronic device form factors diversify, the number of users who simultaneously own multiple devices, such as smartphones, tablets, desktops, and laptops, is increasing. These users can use the same applications across multiple devices. To meet these needs, applications with synchronization capabilities across multiple devices are being released.

[0003] The above information may be provided as background art to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above is applicable as prior art in connection with the present disclosure.

[0004] According to one embodiment, a server may include a communication circuit, a memory storing instructions, and a processor. The instructions, when executed by the processor, may cause the server to receive, through the communication circuit, first client identification information including user identification information of an application from a first device on which an application is running. The instructions, when executed by the processor, may cause the server to identify, based on the first client identification information, connection information for one or more devices, including the first device, corresponding to the user identification information. The instructions, when executed by the processor, may cause the server to determine, based on the connection information, whether the first device is a user requiring constant access. The instructions, when executed by the processor, may cause the server to store data representing a result of the determination. The instructions, when executed by the processor, may cause the server to receive, through the communication circuit, a first session creation request from the first device. The instructions, when executed by the processor, may cause the server to, in response to receiving the first session creation request, determine, through the stored data, whether the first device is registered as the always-on user. The instructions, when executed by the processor, may cause the server to establish a first session for real-time synchronization of the first device and the application if the first device is registered as the always-on user.

[0005] According to one embodiment, an electronic device may include a communication circuit, a memory storing instructions, and a processor. The instructions, when executed by the processor, may cause the electronic device to determine whether the electronic device is a user requiring constant access based on previously stored user information requiring constant access. The instructions, when executed by the processor, may cause the electronic device, in response to determining that the electronic device is the user requiring constant access, to transmit, to a server through the communication circuit, a request for creating a session for real-time synchronization of an application running on the electronic device. The instructions, when executed by the processor, may cause the electronic device, in response to determining that the user is not the user requiring constant access, to the server through the communication circuit, client identification information including user identification information of the application.

[0006] According to one embodiment, a method performed by a server including a communication circuit may include receiving, through the communication circuit, first client identification information including user identification information of an application from a first device on which an application is running. The method may include identifying, based on the first client identification information, connection information for one or more devices corresponding to the user identification information and including the first device. The method may include determining, based on the connection information, whether the first device is a user requiring constant access. The method may include storing data representing a result of the determination. The method may include receiving, through the communication circuit, a first session creation request from the first device. The method may include determining, in response to receiving the first session creation request, through the stored data whether the first device is registered as the user requiring constant access. The method may include establishing a first session for real-time synchronization of the first device and the application when the first device is registered as the user requiring constant access.

[0007] In one embodiment, a method performed by an electronic device including a communication circuit may include an operation of determining whether the electronic device is a user requiring constant access based on previously stored user information requiring constant access. The method may include an operation of, in response to determining that the electronic device is the user requiring constant access, transmitting to a server, via the communication circuit, a request for creating a session for real-time synchronization of an application running on the electronic device. The method may include an operation of, in response to determining that the user is not the user requiring constant access, transmitting to the server, via the communication circuit, client identification information including user identification information of the application.

[0008] FIG. 1 is a block diagram of an electronic device within a network environment according to various embodiments.

[0009] FIG. 2 illustrates servers and devices within a network environment according to one embodiment.

[0010] FIG. 3 is an exemplary block diagram of a server and clients according to one embodiment.

[0011] Figure 4 is a flowchart illustrating the operation of a client according to one embodiment.

[0012] Figure 5 is a flowchart illustrating the operation of a client according to one embodiment.

[0013] Figure 6 is a flowchart illustrating the operation of a server according to one embodiment.

[0014] Figure 7 is a flowchart illustrating the operation of a server according to one embodiment.

[0015] FIG. 8 is an exemplary block diagram of a client according to one embodiment.

[0016] Hereinafter, embodiments of the present disclosure will be described in detail with reference to the drawings so that those skilled in the art can easily implement the present disclosure. However, the present disclosure may be implemented in various different forms and is not limited to the embodiments described herein. In connection with the description of the drawings, the same or similar reference numerals may be used for identical or similar components. Furthermore, in the drawings and related descriptions, descriptions of well-known functions and configurations may be omitted for clarity and conciseness.

[0017] FIG. 1 is a block diagram of an electronic device (101) within a network environment (100) according to various embodiments. Referring to FIG. 1, in the network environment (100), the electronic device (101) may communicate with the electronic device (102) via a first network (198) (e.g., a short-range wireless communication network), or may communicate with at least one of the electronic device (104) or the server (108) via a second network (199) (e.g., a long-range wireless communication network). According to one embodiment, the electronic device (101) may communicate with the electronic device (104) via the server (108). According to one embodiment, the electronic device (101) may include a processor (120), a memory (130), an input module (150), an audio output module (155), a display module (160), an audio module (170), a sensor module (176), an interface (177), a connection terminal (178), a haptic module (179), a camera module (180), a power management module (188), a battery (189), a communication module (190), a subscriber identification module (196), or an antenna module (197). In some embodiments, the electronic device (101) may omit at least one of these components (e.g., the connection terminal (178)), or may have one or more other components added. In some embodiments, some of these components (e.g., the sensor module (176), the camera module (180), or the antenna module (197)) may be integrated into one component (e.g., the display module (160)).

[0018] The processor (120) may control at least one other component (e.g., a hardware or software component) of the electronic device (101) connected to the processor (120) by executing, for example, software (e.g., a program (140)), and may perform various data processing or calculations. According to one embodiment, as at least a part of the data processing or calculation, the processor (120) may store a command or data received from another component (e.g., a sensor module (176) or a communication module (190)) in a volatile memory (132), process the command or data stored in the volatile memory (132), and store the resulting data in a non-volatile memory (134). According to one embodiment, the processor (120) may include a main processor (121) (e.g., a central processing unit or an application processor) or a secondary processor (123) (e.g., a graphics processing unit, a neural processing unit (NPU), an image signal processor, a sensor hub processor, or a communication processor) that can operate independently or together therewith. For example, if the electronic device (101) includes a main processor (121) and a secondary processor (123), the secondary processor (123) may be configured to use less power than the main processor (121) or to be specialized for a specified function. The secondary processor (123) may be implemented separately from the main processor (121) or as a part thereof.

[0019] The auxiliary processor (123) may control at least a part of functions or states associated with at least one component (e.g., a display module (160), a sensor module (176), or a communication module (190)) of the electronic device (101), for example, on behalf of the main processor (121) while the main processor (121) is in an inactive (e.g., sleep) state, or together with the main processor (121) while the main processor (121) is in an active (e.g., application execution) state. In one embodiment, the auxiliary processor (123) (e.g., an image signal processor or a communication processor) may be implemented as a part of another functionally related component (e.g., a camera module (180) or a communication module (190)). In one embodiment, the auxiliary processor (123) (e.g., a neural network processing unit) may include a hardware structure specialized for processing artificial intelligence models. The artificial intelligence models may be generated through machine learning. This learning can be performed, for example, on the electronic device (101) itself where the artificial intelligence model is executed, or can be performed through a separate server (e.g., server (108)). The learning algorithm can include, for example, supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but is not limited to the examples described above. The artificial intelligence model can include multiple artificial neural network layers.The artificial neural network may be one of a deep neural network (DNN), a convolutional neural network (CNN), a recurrent neural network (RNN), a restricted Boltzmann machine (RBM), a deep belief network (DBN), a bidirectional recurrent deep neural network (BRDNN), a deep Q-network, or a combination of two or more of the above, but is not limited to the examples described above. In addition to, or alternatively to, a hardware structure, an artificial intelligence model may include a software structure.

[0020] The memory (130) can store various data used by at least one component (e.g., processor (120) or sensor module (176)) of the electronic device (101). The data can include, for example, software (e.g., program (140)) and input data or output data for commands related thereto. The memory (130) can include volatile memory (132) or non-volatile memory (134).

[0021] The program (140) may be stored as software in the memory (130) and may include, for example, an operating system (142), middleware (144), or an application (146).

[0022] The input module (150) can receive commands or data to be used in a component of the electronic device (101) (e.g., a processor (120)) from an external source (e.g., a user) of the electronic device (101). The input module (150) can include, for example, a microphone, a mouse, a keyboard, a key (e.g., a button), or a digital pen (e.g., a stylus pen).

[0023] The audio output module (155) can output audio signals to the outside of the electronic device (101). The audio output module (155) can include, for example, a speaker or a receiver. The speaker can be used for general purposes, such as multimedia playback or recording playback. The receiver can be used to receive incoming calls. According to one embodiment, the receiver can be implemented separately from the speaker or as part of the speaker.

[0024] The display module (160) can visually provide information to an external party (e.g., a user) of the electronic device (101). The display module (160) may include, for example, a display, a holographic device, or a projector and a control circuit for controlling the device. According to one embodiment, the display module (160) may include a touch sensor configured to detect a touch, or a pressure sensor configured to measure the intensity of a force generated by the touch.

[0025] The audio module (170) can convert sound into an electrical signal, or vice versa, convert an electrical signal into sound. According to one embodiment, the audio module (170) can acquire sound through the input module (150), output sound through the sound output module (155), or an external electronic device (e.g., electronic device (102)) (e.g., speaker or headphone) directly or wirelessly connected to the electronic device (101).

[0026] The sensor module (176) can detect the operating status (e.g., power or temperature) of the electronic device (101) or the external environmental status (e.g., user status) and generate an electrical signal or data value corresponding to the detected status. According to one embodiment, the sensor module (176) can include, for example, a gesture sensor, a gyro sensor, a barometric pressure sensor, a magnetic sensor, an acceleration sensor, a grip sensor, a proximity sensor, a color sensor, an IR (infrared) sensor, a biometric sensor, a temperature sensor, a humidity sensor, or an illuminance sensor.

[0027] The interface (177) may support one or more designated protocols that may be used to directly or wirelessly connect the electronic device (101) with an external electronic device (e.g., the electronic device (102)). In one embodiment, the interface (177) may include, for example, a high definition multimedia interface (HDMI), a universal serial bus (USB) interface, an SD card interface, or an audio interface.

[0028] The connection terminal (178) may include a connector through which the electronic device (101) may be physically connected to an external electronic device (e.g., electronic device (102)). According to one embodiment, the connection terminal (178) may include, for example, an HDMI connector, a USB connector, an SD card connector, or an audio connector (e.g., a headphone connector).

[0029] A haptic module (179) can convert electrical signals into mechanical stimuli (e.g., vibration or movement) or electrical stimuli that a user can perceive through tactile or kinesthetic sensations. According to one embodiment, the haptic module (179) can include, for example, a motor, a piezoelectric element, or an electrical stimulation device.

[0030] The camera module (180) can capture still images and videos. According to one embodiment, the camera module (180) may include one or more lenses, image sensors, image signal processors, or flashes.

[0031] The power management module (188) can manage power supplied to the electronic device (101). According to one embodiment, the power management module (188) can be implemented as, for example, at least a part of a power management integrated circuit (PMIC).

[0032] A battery (189) may power at least one component of the electronic device (101). In one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0033] The communication module (190) may support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between the electronic device (101) and an external electronic device (e.g., electronic device (102), electronic device (104), or server (108)), and the performance of communication through the established communication channel. The communication module (190) may operate independently from the processor (120) (e.g., application processor) and may include one or more communication processors that support direct (e.g., wired) communication or wireless communication. According to one embodiment, the communication module (190) may include a wireless communication module (192) (e.g., a cellular communication module, a short-range wireless communication module, or a global navigation satellite system (GNSS) communication module) or a wired communication module (194) (e.g., a local area network (LAN) communication module, or a power line communication module). Among these communication modules, the corresponding communication module can communicate with an external electronic device (104) via a first network (198) (e.g., a short-range communication network such as Bluetooth, Wi-Fi (wireless fidelity) direct, or IrDA (infrared data association)) or a second network (199) (e.g., a long-range communication network such as a legacy cellular network, a 5G network, a next-generation communication network, the Internet, or a computer network (e.g., a LAN or WAN)). These various types of communication modules can be integrated into a single component (e.g., a single chip) or implemented as multiple separate components (e.g., multiple chips). The wireless communication module (192) can verify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) by using subscriber information (e.g., an international mobile subscriber identity (IMSI)) stored in the subscriber identification module (196).

[0034] The wireless communication module (192) can support 5G networks and next-generation communication technologies following the 4G network, such as NR access technology (new radio access technology). The NR access technology can support high-speed transmission of high-capacity data (eMBB (enhanced mobile broadband)), minimization of terminal power and connection of multiple terminals (mMTC (massive machine type communications)), or high reliability and low latency (URLLC (ultra-reliable and low-latency communications)). The wireless communication module (192) can support, for example, a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate. The wireless communication module (192) can support various technologies for securing performance in a high-frequency band, such as beamforming, massive multiple-input and multiple-output (MIMO), full dimensional MIMO (FD-MIMO), array antenna, analog beam-forming, or large scale antenna. The wireless communication module (192) can support various requirements specified in the electronic device (101), an external electronic device (e.g., the electronic device (104)), or a network system (e.g., the second network (199)). According to one embodiment, the wireless communication module (192) may support a peak data rate (e.g., 20 Gbps or more) for eMBB realization, a loss coverage (e.g., 164 dB or less) for mMTC realization, or a U-plane latency (e.g., 0.5 ms or less for downlink (DL) and uplink (UL), or 1 ms or less for round trip) for URLLC realization.

[0035] The antenna module (197) can transmit or receive signals or power to or from an external device (e.g., an external electronic device). According to one embodiment, the antenna module (197) may include an antenna including a radiator formed of a conductor or a conductive pattern formed on a substrate (e.g., a PCB). According to one embodiment, the antenna module (197) may include a plurality of antennas (e.g., an array antenna). In this case, at least one antenna suitable for a communication method used in a communication network, such as the first network (198) or the second network (199), may be selected from the plurality of antennas by, for example, the communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device via the selected at least one antenna. According to some embodiments, in addition to the radiator, another component (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as a part of the antenna module (197).

[0036] According to various embodiments, the antenna module (197) may form a mmWave antenna module. According to one embodiment, the mmWave antenna module may include a printed circuit board, an RFIC disposed on or adjacent a first side (e.g., a bottom side) of the printed circuit board and capable of supporting a designated high-frequency band (e.g., a mmWave band), and a plurality of antennas (e.g., an array antenna) disposed on or adjacent a second side (e.g., a top side or a side side) of the printed circuit board and capable of transmitting or receiving signals in the designated high-frequency band.

[0037] At least some of the above components can be interconnected and exchange signals (e.g., commands or data) with each other via a communication method between peripheral devices (e.g., a bus, GPIO (general purpose input and output), SPI (serial peripheral interface), or MIPI (mobile industry processor interface)).

[0038] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) via a server (108) connected to a second network (199). Each of the external electronic devices (102 or 104) may be the same or a different type of device as the electronic device (101). According to one embodiment, all or part of the operations executed in the electronic device (101) may be executed in one or more of the external electronic devices (102, 104, or 108). For example, when the electronic device (101) is to perform a certain function or service automatically or in response to a request from a user or another device, the electronic device (101) may, instead of or in addition to executing the function or service by itself, request one or more external electronic devices to perform the function or at least a part of the service. One or more external electronic devices that receive the request may execute at least a portion of the requested function or service, or an additional function or service related to the request, and transmit the result of the execution to the electronic device (101). The electronic device (101) may process the result as is or additionally and provide it as at least a portion of a response to the request. For this purpose, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used, for example. The electronic device (101) may provide an ultra-low latency service by using distributed computing or mobile edge computing, for example. In another embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server utilizing machine learning and / or a neural network. According to one embodiment, the external electronic device (104) or the server (108) may be included in the second network (199).The electronic device (101) can be applied to intelligent services (e.g., smart home, smart city, smart car, or healthcare) based on 5G communication technology and IoT-related technology.

[0039] Electronic devices according to the various embodiments disclosed in this document may take various forms. Electronic devices may include, for example, portable communication devices (e.g., smartphones), computer devices, portable multimedia devices, portable medical devices, cameras, wearable devices, or home appliances. Electronic devices according to the embodiments disclosed in this document are not limited to the aforementioned devices.

[0040] FIG. 2 illustrates servers and devices within a network environment, according to an embodiment. Referring to FIG. 2, in one embodiment, a server (208) and a plurality of devices (240) communicating with the server (208) are illustrated. In one embodiment, the server (208) may be connected to the plurality of devices (240) based on a communication network including a wired network and / or a wireless network (e.g., the first network (198) and / or the second network (199) of FIG. 1). In addition, the plurality of devices (240) may be connected to each other based on the communication network. In one embodiment, the server (208) may be referred to as an electronic device.

[0041] In one embodiment, the server (208) (e.g., the server (108) of FIG. 1) may include one or more processors including processing circuitry. For example, the server (208) may include a processor (220) (e.g., the processor (120) of FIG. 1). In one embodiment, the server (208) may include a memory (230) (e.g., the memory (130) of FIG. 1) and a communication module (290) including communication circuitry (e.g., the communication module (190) of FIG. 1). In one embodiment, the processor (220) may be electrically and / or operatively connected to the memory (230) and the communication module (290). For example, the processor (220), the memory (230), and the communication module (290) may be electrically and / or operatively connected to one another by an electronic component, such as a communication bus.

[0042] According to one embodiment, one or more instructions representing operations and / or actions to be performed by the processor (220) of the server (208) may be stored in the memory (230) of the server (208). A set of one or more instructions may be referred to as firmware, an operating system, a process, a routine, a sub-routine, and / or an application. For example, the server (208) and / or the processor (220) may perform various operations of the server (208) (e.g., the operations of FIGS. 6 and 7) by executing one or more instructions or a set of multiple instructions.

[0043] In one embodiment, the plurality of devices (240) may include, for example, a first device (201) and a second device (202). The plurality of devices (240) may include various types of electronic devices. For example, the first device (201) may include a smart phone, and the second device (202) may include a tablet, but is not limited to the illustrated example. For example, the plurality of devices (240) may include various types of electronic devices, such as a notebook PC, a desktop, a smart watch, and a head mounted display (HMD) device.

[0044] In one embodiment, each of the plurality of devices (240) may include the electronic device (101) of FIG. 1. For example, each of the devices (201, 202) may include at least some of the components of the electronic device (101) of FIG. 1. For example, each of the plurality of devices (240) may include a processor (e.g., the processor (120) of FIG. 1), a memory (e.g., the memory (130) of FIG. 1) in which one or more instructions are stored, a communication module including a communication circuit (e.g., the communication module (190) of FIG. 1), and a display device such as a display (e.g., the display module (160) of FIG. 1). For example, one or more instructions stored in the memory of the first device (201), when executed by the first device (201) and / or the processor of the first device (201), may cause various operations of the first device (201) (e.g., operations of FIGS. 4 and 5). For example, one or more instructions stored in the memory of the second device (202), when executed by the processor of the second device (202) and / or the first device (201), may cause various operations of the second device (202) (e.g., operations of FIGS. 4 and 5).

[0045] FIG. 3 is an exemplary block diagram of a server and clients according to one embodiment. In FIG. 3, a server (308) (e.g., server (208) of FIG. 2) and a plurality of clients (340) communicating with the server (308) are illustrated.

[0046] In one embodiment, the server (308) may include a device (e.g., a computing device) configured to provide a service of the application. For example, the server (308) may provide a synchronization service of the application. For example, the application may include various applications that require synchronization functionality when used on multiple devices. For example, the application may include at least one of a document application, a messaging application, a phone application, a contact application, a web browser, a gallery application, and / or a calendar application. In a non-limiting embodiment, the server (308) may include a server built on a cloud. For example, the server (308) may include a server hosted and operated in a cloud computing environment.

[0047] In one embodiment, each of the plurality of clients (340) may include a device (e.g., a first device (201)) for utilizing a service provided by the server (308). For example, in one embodiment, each of the plurality of clients (340) may include a processor within the device (e.g., a processor within the first device (201)) capable of executing a software component, such as a program or service.

[0048] In one embodiment, the plurality of clients (340) may include a first client (301) (e.g., the first device (201) of FIG. 2) and a second client (302) (e.g., the second device (202) of FIG. 2). In one embodiment, the first client (301) may include a user information manager (305) and a database (DB) (306). The user information manager (305) may manage user information requiring constant access (or persistent session user information) for the first client (301) within the database (306).

[0049] The above-described user information requiring constant access may include information about the status of the first client (301) and the last check time of the status. For example, the information about the status may include data (e.g., true or false) indicating whether the first client (301) is a user requiring constant access. The user information manager (305) may store or update information about the status of the first client (301). In addition, the user information manager (305) may update the last check time of the user information requiring constant access to the time at which the information about the status was stored or updated.

[0050] In one embodiment, the first client (301) may transmit a session creation request for real-time synchronization of the application to the server (308) based on the user information requiring constant connection.

[0051] In one embodiment, the second client (302) may include a user information manager (307) and a database (309). The user information manager (307) may manage user information requiring constant access for the second client (302) within the database (309). The descriptions for the first client (301), the user information manager (305), and the database (306) may be applied to the second client (302), the user information manager (307), and the database (309) in substantially the same or corresponding manner. For example, the user information manager (307) of the second client (302) may store or update information about the status of the second client (302). In addition, the user information manager (307) may update the last confirmed time of the user information requiring constant access to the time at which the information about the status was stored or updated. For example, the second client (302) may send a session creation request for real-time synchronization of the application to the server (308) based on the user information requiring constant connection.

[0052] In one embodiment, the server (308) may include a user device manager (310), a database (DB) (312), a notification manager (320), a session manager (330), a persistent session validator (350), and a database (DB) (352).

[0053] In one embodiment, the user device manager (310) can manage the client's connection information within the database (DB) (312). For example, the connection information may include information about the client's user information, device information, the time the connection information was created, and the time the connection information was modified. For example, the user device manager (310) can store or update the connection information within the database (DB) (312) based on client identification information received from the client.

[0054] In one embodiment, the notification manager (320) can manage notification messages sent to clients. For example, the notification manager (320) can send notification messages to devices based on the results determined by the persistent session validator (350).

[0055] In one embodiment, the session manager (330) can manage sessions with a client. For example, the session manager (330) can establish a session in response to a session creation request received from a client. For example, the session manager (330) can reject the session request. The session manager (330) can maintain or terminate a session with a client.

[0056] In one embodiment, the persistent session validator (350) can determine whether a client is a user requiring persistent access. For example, the persistent session validator (350) can determine whether a client is a user requiring persistent access based on the connection information transmitted from the user device manager (310). The persistent session validator (350) can store or update the results of the determination in the database (352).

[0057] In order to provide a real-time synchronization service for applications running on clients (301, 302), a process of connecting a network session between the server (308) and the clients (301, 302) may be performed first. When connecting a network session, resources may be consumed on both the clients (301, 302) and the server (308). That is, as the service becomes more active, the infrastructure cost for maintaining the network session may increase. However, users may not own multiple devices or may not need the synchronization function of applications installed on multiple devices. In other words, by connecting a network session every time an application is executed even when it is not necessary, resources and infrastructure costs may be wasted.

[0058] In one embodiment, the server (308) can determine whether a user with multiple devices requires real-time synchronization services and selectively provide real-time synchronization services accordingly. This reduces unnecessary resource waste, providing fast real-time synchronization services to users who require the service. The operations of the electronic device and server for this purpose are described with reference to FIGS. 4 through 7.

[0059] Figures 4 and 5 are flowcharts illustrating the operation of a client according to one embodiment.

[0060] The operations of FIGS. 4 and 5 may be performed by any one of the plurality of devices (240) of FIG. 2. For example, the operations of FIGS. 4 and 5 may be performed by the first device (201). For example, the processor of the first device (201) may perform the operations of FIGS. 4 and 5. The operations of FIGS. 4 and 5 may be performed by any one of the plurality of clients (340) of FIG. 3. For example, the operations of FIG. 4 may be performed by the first client (301). The operations of FIGS. 4 and 5 will be described below based on the first client (301).

[0061] In the following examples, the operations may be performed sequentially, but are not necessarily sequential. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

[0062] Referring to FIG. 4, within operation 410, the first client (301) may execute an application. For example, the first client (301) may execute the application in response to a user input for executing the application. The application may include an application that provides a synchronization function. Although not illustrated, additionally or optionally, the first client (301) may determine whether the application requires the synchronization function when executing the application. In response to determining that the application requires the synchronization function, the first client (301) may perform operation 420.

[0063] Within operation 420, the first client (301) can determine whether the client is a user requiring constant access based on the user information requiring constant access. For example, the user information manager (305) of the first client (301) can check the user information requiring constant access stored in the database (306). Based on the user information requiring constant access, the first client (301) can determine whether the electronic device is a user requiring constant access.

[0064] For example, the first client (301) may determine that the first client (301) is not a user requiring constant connection if the status information included in the user information requiring constant connection has a false value.

[0065] For example, if the last confirmed time of the user information requiring constant access has a null value, the first client (301) may determine that the first client (301) is not a user requiring constant access.

[0066] For example, the first client (301) may determine that the first client (301) is not a user requiring constant access if the status information has a false value or the last confirmation time has a null value.

[0067] For example, the first client (301) can check whether the last confirmation time of the user information requiring constant connection is within a reference time before the current timing. If the last confirmation time is outside the reference time, the first client (301) can determine that the first client (301) is not the user requiring constant connection. For example, even if the status information has a true value, if the last confirmation time is outside the reference time, the first client (301) can determine that the first client (301) is not the user requiring constant connection.

[0068] For example, the first client (301) may determine that the first client (301) is a user requiring constant access if the status information has a true value and the last confirmation time is within the reference time.

[0069] The above reference time may include a predefined period, such as, but not limited to, 7 days, 15 days, or 30 days. For example, the current timing may be November 10, 2023, and the last confirmed time of the always-on user information may be 07:00:00 on November 1, 2023. If the reference time is 7 days, since the last confirmed time is outside the reference time prior to the current timing, the first client (301) may determine that the first client (301) is not a user requiring always-on access, regardless of the value of the status information.

[0070] If it is determined within operation 420 that the first client (301) is an always-on user (operation 430: Yes), operation 440 may be performed. If it is determined within operation 420 that the first client (301) is not an always-on user (operation 430: No), operation 460 may be performed.

[0071] Within operation 440, the first client (301) may transmit a request to the server to create a session for real-time synchronization of the application. For example, in response to determining that the first client (301) is a user requiring constant access, the first client (301) may transmit a session creation request to the server (308) via a communication module of the first client (301) (e.g., the communication module (190) of FIG. 1). For example, the first client (301) may call an application programming interface (API) of the server (308) to create the session.

[0072] Within operation 450, the first client (301) can update user information requiring constant access and synchronize applications through a session established with the server. For example, the first client (301) can update the last confirmed time of the user information requiring constant access in response to establishing the session. In addition, the first client (301) can transmit information about changes in the application running on the first client (301) to the server (308) through the session established with the server. For example, the first client (301) can receive information about changes in an application running on another client (e.g., a second client (302)) corresponding to the user of the first client (301) from the server (308). The first client (301) can synchronize the application running on the first client (301) based on the information about changes received from the server (308).

[0073] Within operation 460, the first client (301) may transmit client identification information to the server. For example, the first client (301) may transmit client identification information of the application to the server via the communication module. The client identification information may include user identification information and device identification information of the application. For example, the first client (301) may call an API of the server (308) for checking the status of the first client (301). Through this, the server (308) may identify the status of the first client (301) (e.g., operation 620 of FIG. 6)). For a non-limiting example, the client identification information may be transmitted together with a request for calling an API of the server (308) for checking the status of the first client (301). For a non-limiting example, the API for checking the status of the first client (301) may be different from the API for creating the session.

[0074] Referring to FIG. 5, within operation 510, the first client (301) may receive a signal from the server indicating whether the client is a user requiring constant connection. For example, the first client (301) may receive the signal from the server (308) through the communication module. The signal may be transmitted to the first client (301) by operation 650 of the server (308) of FIG. 6. Operation 510 may be performed, for example, after operation 460 of FIG. 4. For example, the first client (301) may receive the signal as a result of a determination by the server (308) after transmitting the client identification information to the server (308). For example, the first client (301) may receive a value (e.g., true or false) indicating whether the first client (301) is a user requiring constant connection from the server (308).

[0075] Within operation 520, the first client (301) can update the user information requiring constant access based on the received signal. For example, the user information manager (305) of the first client (301) can store a value (e.g., true or false) indicating whether the user is a user requiring constant access received from the server (308) in the user information requiring constant access within the DB (306). In addition, the time at which the value was generated by the server (308), the time at which the signal was transmitted from the server (308), or the time at which the signal was received can be updated to the last confirmed time of the user information requiring constant access.

[0076] Although not shown, within operation 520, if the first client (301) is a user requiring constant access and updates the user information requiring constant access, operation 440 of FIG. 4 may be performed.

[0077] Figures 6 and 7 are flowcharts showing the operation of a server according to one embodiment.

[0078] The operations of FIGS. 6 and 7 may be performed by the server (308) of FIG. 3. For example, the operations of FIGS. 6 and 7 may be performed by a processor of the server (308) (e.g., the processor (220) of FIG. 2).

[0079] In the following examples, the operations may be performed sequentially, but are not necessarily sequential. For example, the order of the operations may be changed, and at least two operations may be performed in parallel.

[0080] Referring to FIG. 6, within operation 610, the server (308) may receive client identification information from the client. For example, the server (308) may receive the client identification information through a communication module (e.g., the communication module (290) of FIG. 2). For example, the server (308) may receive the client identification information from the first client (301) on which the application is running. The first client identification information may include user identification information and device identification information of the first client (301). The client identification information may be included in information transmitted by the first client (301) within operation 460 of FIG. 4.

[0081] Within operation 620, the server (308) may identify connection information for one or more clients corresponding to user identification information based on client identification information. For example, the user device manager (310) of the server (308) may identify the connection information in the DB (312) based on the client identification information. For example, the user device manager (310) may identify connection information having user identification information and device information of the first client (301). For example, the user device manager (310) may identify connection information of another client (e.g., the second client (302) of FIG. 3) having the same user identification information as the user identification information of the first client (301). The connection information may include user information, device information, the time at which the connection information was generated, and the time at which the connection information was modified. In this respect, the one or more clients may include a first client (301) and, additionally, may further include another client (e.g., a second client (302)) having the same user identification information.

[0082] In one embodiment, if the user device manager (310) cannot identify the connection information corresponding to the client information within the DB (312), the user device manager (310) may record connection information including user information and device information of the first client (301) based on the client information within the DB (312). In addition, the user device manager (310) may store the time at which the connection information was created and the time at which it was last modified together with the connection information.

[0083] In one embodiment, the user device manager (310) may update the last modified time of the connection information of the first client (301) when the connection information corresponding to the client information is identified in the DB (312).

[0084] Within operation 630, the server (308) may determine whether the client is a user requiring constant access based on connection information. For example, the constant session validator (350) of the server (308) may determine whether the first client (301) is a user requiring constant access based on the connection information transmitted by the user device manager (310).

[0085] For example, the persistent session validator (350) may, based on the connection information, determine whether the one or more clients, including at least the first client (301), have connected within a specific period in the past. The specific period may include a predefined period, such as, but not limited to, 7 days, 15 days, or 30 days. For example, the persistent session validator (350) may, based on the connection information, determine whether the number of the one or more clients corresponding to the user identification information is greater than or equal to a threshold. The threshold may be, for example, 2, but is not limited thereto. In one embodiment, the persistent session validator (350) may determine that the first client (301) is a user requiring persistent access if the one or more clients have connected within the specific period and the number of the one or more clients is greater than or equal to the threshold.

[0086] For example, the persistent session validator (350) may, based at least in part on the connection information, determine whether the one or more clients corresponding to the user identification information have used a function related to real-time synchronization of the application. For example, the session validator (350) may determine whether the one or more clients have used a function related to real-time synchronization of the application by using the client's log record, the client's session information, and / or API request information. In one embodiment, the persistent session validator (350) may determine that the first client (301) is a user requiring persistent access if the one or more clients have connected within the specific period, the number of the one or more clients is greater than or equal to the threshold, and the one or more clients have used the function related to real-time synchronization within the specific period.

[0087] For example, the persistent session validator (350) can determine whether the one or more clients support a function related to real-time synchronization of the application, at least in part based on the connection information. For example, the persistent session validator (350) can determine whether the function related to real-time synchronization is supported by checking the version of the one or more clients. In one embodiment, the persistent session validator (350) can determine that the first client (301) is a user requiring persistent access if the one or more clients have connected within the specific period, the number of the one or more clients is greater than or equal to the threshold, and the one or more clients support the function related to real-time synchronization.

[0088] Within operation 640, the server (308) may store data representing the result of the judgment. For example, the permanent session validator (350) of the server (308) may store or update the result data determined in operation 630 within the DB (352).

[0089] Within operation 650, the server (308) may transmit a signal indicating the result of the judgment to one or more clients. For example, the persistent session validator (350) may transmit a signal indicating the result of the judgment to the notification manager (320). The notification manager (320) of the server (308) may transmit a signal indicating the result of the judgment to one or more clients.

[0090] For example, if the one or more clients include only the first client (301), the server (308) may, as a result of the determination, transmit a signal to the first client (301) indicating that the first client (301) is not a user requiring constant connection.

[0091] For example, if the one or more clients include a first client (301) and a second client (302), and the first client (301) is determined to be a user requiring constant access, the notification manager (320) may transmit a signal notifying that the first client (301) has been registered as a user requiring constant access. Additionally or optionally, as the first client (301) is converted to a user requiring constant access, the server (308) may transmit a signal to the second client (302) notifying that the second client (302) having the same user identification information as the first client (301) has been converted to a user requiring constant access. For example, the server (308) may transmit the signal notifying that the second client (302) has been converted to a user requiring constant access from the constant session validator (350) to the notification manager (320). The server (308) may transmit a signal to the second client (302) in the form of a push message, using the notification manager (320), notifying that the user has been converted to a user requiring constant access. The push message may be transmitted by the server (308) or by another server (e.g., a push server) communicating with the server (308).

[0092] For example, if the one or more clients include a first client (301) and a second client (302), and the first client (301) is determined not to be a user requiring constant connection, the notification manager (320) may transmit a signal to the first client (301) to notify that the first client (301) is not a user requiring constant connection. Additionally or optionally, as the first client (301) transitions to not being a user requiring constant connection, the server (308) may transmit a signal to the second client (302) to notify that the second client (302) having the same identification information as the first client (301) is not a user requiring constant connection.

[0093] A signal transmitted by the server (308) within operation 650 may be received by a client (e.g., a first client (301) and / or a second client (302)), as in operation 510 of FIG. 5. In addition, as in operation 520 of FIG. 5, the client may update user information requiring constant connection based on the received signal.

[0094] Referring to FIG. 7, within operation 710, the server (308) may receive a session creation request from a client. For example, the server (308) may receive the session creation request through the communication module.

[0095] Within operation 720, the server (308) may, in response to receiving a session creation request, verify whether the client is registered as a user requiring constant access. For example, the constant session validator (350) of the server (308) may verify whether the client sending the session creation request is registered as a user requiring constant access in the database (352).

[0096] Optionally or alternatively, within operation 710, the session creation request received by the server (308) may be a request sent by the client in response to a push message. In this case, operation 720 may be omitted, and the server (308) may perform operation 740 after performing operation 710.

[0097] Within operation 720, if the client is registered as a user requiring constant access (operation 730: Yes), operation 740 may be performed, otherwise (operation 730: No), operation 760 may be performed.

[0098] Within operation 740, the server (308) may establish a session for real-time synchronization between the client and the application. For example, the persistent session validator (350) of the server (308) may transmit a true value to the session manager (330) as a result of operation 720. The server (308) may establish the session with the client through the session manager (330) to which the true value has been transmitted.

[0099] Within operation 750, the server (308) may update connection information of one or more clients. For example, the session manager (330) of the server (308) may cause the user device manager (310) to update the connection information of the one or more clients in response to the establishment of the session.

[0100] Within operation 760, the server (308) may reject a session creation request. For example, the server (308) may reject the session creation request through the session manager (330).

[0101] Hereinafter, a scenario in which the first client (301) of user A executes the application for the first time at 07:00:00 on November 1, 2023 is described with reference to the operations of FIGS. 4 to 7.

[0102] First, within operation 410, the first client (301) can execute the application.

[0103] Within operation 420, the first client (301) may determine whether the client is a user requiring constant access based on the user information requiring constant access. For example, since the first client (301) has not yet received a signal from the server (308) regarding whether the client is a user requiring constant access, the status information of the user information requiring constant access may be a false value, and the last confirmed time may be a null value. Accordingly, the first client (301) may determine that the first client (301) is not a user requiring constant access (operation 430: No). Within operation 460, the first client (301) may transmit the first client identification information to the server (308).

[0104] Within operation 610, the server (308) may receive the first client identification information. Within operation 620, the server (308) may identify connection information for one or more clients based on the first client identification information. For example, the server (308) may identify that there is no connection information corresponding to the user identification information of the first client (301) in the database (312). Accordingly, the server (308) may record the connection information of the first client (301) in the database (312). The connection information recorded in the database (312) may include, for example, but not limited to, data as shown in Table 1 below.

[0105] User IDDevice IDCreation timeModified timeUser A1st device (201)23-11-01 07:00:0023-11-01 07:00:00

[0106] Within operation 630, the server (308) can determine whether the first client (301) is a user requiring constant access. Since the number of registered clients with the same identification information as the first client (301) is one (e.g., the first client (301) itself), the server (308) can determine that the first client (301) is not a user requiring constant access.

[0107] Within operation 640, the server (308) may store data representing the judgment result for the first client (301). The data may include, for non-limiting examples, the data shown in Table 2 below.

[0108] User ID Number of valid devices Always-on user required Last modified time User A1 False 23-11-01 07:00:00

[0109] Within operation 650, the server (308) may transmit the judgment result regarding the first client (301) to the first client (301). For example, the server (308) may transmit a false value indicating that the first client (301) is not a user requiring constant access to the first client (301).

[0110] Within operation 510, the first client (301) can receive a signal regarding the judgment result transmitted by the server (308) within operation 650. Within operation 520, the first client (301) can update user information requiring constant access within the DB (306) based on the signal regarding the judgment result.

[0111] As a non-limiting example, updated always-on user information may include the data in Table 3 below.

[0112] Always-on required. Last checked time: False23-11-01 07:00:00

[0113] Next, a scenario in which a second client (302) of the same user A as the first client (301) executes the application for the first time at 07:00:00 on November 2, 2023 is described with reference to the operations of FIGS. 4 to 7.

[0114] First, within operation 410, the second client (302) can execute the application.

[0115] Within operation 420, the second client (302) may determine whether the client is a user requiring constant access based on the user information requiring constant access. For example, since the second client (302) has not yet received a signal from the server (308) regarding whether the client is a user requiring constant access, the status information of the user information requiring constant access may be a false value, and the last confirmed time may be a null value. Accordingly, the second client (302) may determine that the second client (302) is not a user requiring constant access (operation 430: No). Within operation 460, the second client (302) may transmit second client identification information to the server (308).

[0116] Within operation 610, the server (308) may receive the second client identification information. Within operation 620, the server (308) may identify connection information for one or more clients based on the second client identification information. For example, the server (308) may identify connection information (e.g., connection information of the first client (301)) corresponding to the user identification information of the second client (302) within the database (DB) (312). Accordingly, the server (308) may record the connection information of the second client (302) within the database (DB) (312). The connection information recorded within the database (312) may include, for non-limiting examples, data as shown in Table 4 below.

[0117] User IDDevice IDCreation timeModified timeUser ADevice 1 (201)23-11-01 07:00:0023-11-01 07:00:00User ADevice 2 (202)23-11-02 07:00:0023-11-02 07:00:00

[0118] Within operation 630, the server (308) can determine whether the second client (302) is a user requiring constant access. Since the number of registered clients with the same identification information as the second client (302) is two, and both the first client (301) and the second client (302) have registered within a reference period (e.g., 7 days), the server (308) can determine that the second client (302) is a user requiring constant access.

[0119] Within operation 640, the server (308) may store data representing the judgment result for the second client (302). The data may include, for non-limiting examples, the data shown in Table 5 below.

[0120] User ID Number of valid devices Always-on user required Last modified time User A2 True 23-11-02 07:00:00

[0121] Within operation 650, the server (308) may transmit the judgment result regarding the second client (302) to the second client (302). For example, the server (308) may transmit a signal to the second client (302) to notify that the second client (302) has been registered as a user requiring constant access. In addition, the server (308) may transmit a signal to the first client (301) to notify that the first client (301) has been converted to a user requiring constant access, in the form of a push message.

[0122] Within operation 510, the second client (302) can receive a signal regarding the judgment result transmitted by the server (308) within operation 650. Within operation 520, the second client (302) can update user information requiring constant access within the DB (309) based on the signal regarding the judgment result.

[0123] For a non-limiting example, the updated always-on required user information in the DB (309) of the second client (302) may include the data in Table 6 below.

[0124] Always-on user required. Last checked at True23-11-02 07:00:00

[0125] Additionally, within operation 510, the first client (301) can receive a signal regarding the judgment result transmitted by the server (308) within operation 650. Within operation 520, the first client (301) can update user information requiring constant access within the DB (306) based on the signal regarding the judgment result.

[0126] For a non-limiting example, the updated always-on required user information in the DB (306) of the first client (301) may include the data in Table 7 below.

[0127] Always-on user required. Last checked time: True23-11-01 07:00:00

[0128] The first client (301) can perform operation 440 because it has updated the user value requiring constant connection to a true value. For example, the first client (301) can send a session creation request for real-time synchronization of the application to the server (308).

[0129] Within operation 710, the server (308) may receive the session creation request from the first client (301). Within operation 720, the server (308) may check whether the first client (301) is registered as a user requiring constant access. As shown in Table 5, since the first client (301) is registered as a user requiring constant access, the server (308) may establish the session in response to the request of the first client (301).

[0130] The second client (302) can perform operation 440 because it has updated the user value requiring constant connection to a true value. For example, the second client (302) can send a session creation request for real-time synchronization of the application to the server (308).

[0131] Within operation 710, the server (308) may receive a session creation request from the second client (302). Within operation 720, the server (308) may check whether the second client (302) is registered as a user requiring constant access. As shown in Table 5, since the second client (302) is registered as a user requiring constant access, the server (308) may establish the session in response to the request of the second client (302).

[0132] Although not shown, the server (308) can synchronize in real time changes in the application running on the first client (301) and the second client (302) with which the session is established. For a non-limiting example, the server (308) can receive information about changes in the application running on the first client (301) through a first session with the first client (301) and transmit the same to the second client (302) through a second session with the second client (302). Conversely, the server (308) can receive information about changes in the application running on the second client (302) through the second session and transmit the same to the first client (301) through the first session. Within operation 450, each of the first client (301) and the second client (302) can synchronize information about the received changes to the application.

[0133] Thereafter, a scenario in which the first client (301) of user A executes the application at 08:00:00 on November 2, 2023 is described with reference to the operations of FIG. 4 and FIG. 7.

[0134] First, within operation 410, the first client (301) can execute the application.

[0135] Within operation 420, the first client (301) may determine whether the client is a user requiring constant access based on the user information requiring constant access. For example, as shown in Table 7, the status information of the user information requiring constant access of the first client (301) may be a true value, and the last confirmed time may be 23-11-01 07:00:00. Since the last confirmed time has not passed the reference period (e.g., 7 days) and the status information is a true value, the first client (301) may be determined to be a user requiring constant access (operation 430: Yes).

[0136] Within operation 440, the first client (301) may send a session creation request for real-time synchronization of the application to the server (308).

[0137] Within operation 710, the server (308) can receive the session creation request from the first client (301). Within operation 720, the server (308) can check whether the first client (301) is registered as a user requiring constant access. As shown in Table 5, since the first client (301) is registered as a user requiring constant access, within operation 740, the server (308) can establish the session in response to the request of the first client (301).

[0138] Within operation 750, the server (308) may update the connection information of the first client (301). For example, but not limited to, the updated connection information of the server (308) may include data of Table 8 below.

[0139] User IDDevice IDCreation timeModified timeUser A1st device (201)23-11-01 07:00:0023-11-02 08:00:00User A2nd device (202)23-11-02 07:00:0023-11-02 07:00:00

[0140] Within operation 450, in response to the session establishment, the first client (301) may update the user information requiring constant access. For a non-limiting example, the updated user information requiring constant access of the first client (301) may include data as shown in Table 9 below.

[0141] Always-on user required. Last checked at True23-11-02 08:00:00

[0142] Afterwards, the first client (301) can perform synchronization of the application of operation 450.

[0143] Next, a scenario in which a second client (302) of the same user A as the first client (301) executes the application at 07:00:00 on November 10, 2023 is described with reference to the operations of FIGS. 4 to 7.

[0144] First, within operation 410, the second client (302) can execute the application.

[0145] Within operation 420, the second client (302) may determine whether the client is a user requiring constant access based on the user information requiring constant access. For example, as shown in Table 6, the status information of the user information requiring constant access of the second client (302) may be a true value. However, the last confirmed time of the second client (302) is 23-11-02 07:00:00, which may be outside the reference period (e.g., 7 days) prior to the current timing (23-11-10 07:00:00). Accordingly, the second client (302) may be determined not to be a user requiring constant access (operation 430: No). Within operation 460, the second client (302) may transmit the second client identification information to the server (308).

[0146] Within operation 610, the server (308) may receive the second client identification information. Within operation 620, the server (308) may identify connection information for one or more clients based on the second client identification information. For example, the server (308) may identify connection information (e.g., connection information of the first client (301) and the second client (302)) corresponding to the user identification information of the second client (302) within the database (DB) (312). Accordingly, the server (308) may update the connection information of the second client (302) within the database (312). The updated connection information may include, for example, data of Table 10 below, without limitation.

[0147] User IDDevice IDCreation timeModified timeUser A1st device (201)23-11-01 07:00:0023-11-02 08:00:00User A2nd device (202)23-11-02 07:00:0023-11-10 07:00:00

[0148] Within operation 630, the server (308) can determine whether the second client (302) is a user requiring constant access. The last modification time (e.g., 08:00:00 on November 2, 2023) of the first client (301) (e.g., the first device (201)) may be outside a reference period (e.g., 7 days) prior to the current timing (07:00:00 on November 10, 2023), and the server (308) may exclude the first client (301) from among clients having the same identification information as the second client (302). Accordingly, since the number of clients whose last modification time has been confirmed within the reference time is only one, the server (308) can determine that the second client (302) is not a user requiring constant access.

[0149] Within operation 640, the server (308) may store data representing the judgment result for the second client (302). The data may include, for non-limiting examples, the data shown in Table 11 below.

[0150] User ID Number of valid devices Always-on user required User modified time User A1 False 23-11-10 07:00:00

[0151] Within operation 650, the server (308) may transmit the judgment result for the second client (302) to the second client (302). For example, the server (308) may transmit a signal to the second client (302) to notify that the second client (302) has been registered as a user requiring emergency access. Additionally or optionally, the server (308) may transmit a signal to the first client (301) to notify that the first client (301) has been converted to a user requiring emergency access. For example, the server (308) may transmit a signal to the first client (301) to notify that the first client (301) has been converted to a user requiring emergency access in the form of a push message.

[0152] Within operation 510, the second client (302) can receive a signal regarding the judgment result transmitted by the server (308) within operation 650. Within operation 520, the second client (302) can update user information requiring constant access within the DB (309) based on the signal regarding the judgment result.

[0153] For a non-limiting example, the updated always-on required user information in the DB (309) of the second client (302) may include the data in Table 12 below.

[0154] Always-on required. Last checked time: False23-11-10 07:00:00

[0155] Additionally, within operation 510, the first client (301) can receive a signal regarding the judgment result transmitted by the server (308) within operation 650. Within operation 520, the first client (301) can update user information requiring constant access within the DB (306) based on the signal regarding the judgment result.

[0156] For a non-limiting example, the updated always-on required user information in the DB (306) of the first client (301) may include the data in Table 13 below.

[0157] Always-on required. Last checked time: False23-11-02 08:00:00

[0158] Afterwards, user A of the first client (301) can use the application without establishing a separate session with the server (308) (e.g., offline mode).

[0159] FIG. 8 is an exemplary block diagram of a client according to an embodiment. Referring to FIG. 8, a client (801) according to an embodiment (e.g., the first client (301) and / or the second client (302) of FIG. 3 ) may include multiple applications. For example, the client (801) may include a first application (811), a second application (812), and a third application (813). For example, but not limited to, the first application (811) may include a document editing application (e.g., a note application). For example, but not limited to, the second application (812) may include a messaging application. For example, but not limited to, the third application (813) may include a calendar application.

[0160] In one embodiment, the client (801) may include a cloud application (810). The cloud application (810) for relaying communication between the plurality of applications and the server may include a user information manager (805) (e.g., the user information manager (305) of FIG. 3), a database (806) (e.g., the database (306) of FIG. 3), a configuration manager (820), a database (821), a software development kit (SDK) (830), and a service interface (840).

[0161] In one embodiment, the service interface (840) may provide an interface for the plurality of applications to utilize services provided by the server (e.g., a backup service and a synchronization service provided through the server (308) of FIG. 3). The service interface (840) may provide API wrapping of the server.

[0162] In one embodiment, the SDK (830) can verify whether an application is a user requiring constant access, similar to the persistent session validator (350) of FIG. 3. In one embodiment, the SDK (830) can perform the function of creating a session, similar to the session manager (330) of FIG. 3. For example, the SDK (830) can provide the functions of verifying whether a user requires constant access and creating a session in the form of a method.

[0163] In one embodiment, the user information manager (805) can manage user information requiring constant access for each application. For example, the user information manager (805) can store and manage user information requiring constant access within a database (806). The user information requiring constant access may include, for non-limiting examples, the data in Table 14 below.

[0164] App ID Always-on required User Last viewed time 1st application (811) False 2023-11-02 08:00:00 2nd application (812) True 2023-11-05 08:00:00 3rd application (813) False 2023-11-06 08:00:00

[0165] In one embodiment, the settings manager (820) can manage the cycle of the last confirmation time for each application and whether the application is supported, stored in the database (821). For a non-limiting example, information regarding the cycle of the last confirmation time for each application may include data as shown in Table 15 below.

[0166] App ID verification cycle (check duration) 1st application (811) 1 subject 2nd application (812) 7 days 3rd application (813) 15 days

[0167] Unlike the example illustrated in FIG. 3, multiple applications of the client (801) can be managed in a unified manner through a cloud application (810). Accordingly, compared to each of the multiple applications including a configuration (e.g., a user information manager (305)) for managing user information requiring constant access, the resources consumed by the client (801) and the implementation costs can be reduced.

[0168] According to one embodiment, a server (e.g., server (208) of FIG. 2) may include a communication circuit (e.g., communication module (290) of FIG. 2); a memory (e.g., memory (230) of FIG. 2) for storing instructions; and a processor (e.g., processor (220) of FIG. 2). The instructions, when executed by the processor, may cause the server to receive, through the communication circuit, first client identification information including user identification information of an application from a first device (e.g., first device (201) of FIG. 2) on which an application is running. The instructions, when executed by the processor, may cause the server to identify, based on the first client identification information, connection information for one or more devices corresponding to the user identification information and including the first device. The instructions, when executed by the processor, may cause the server to determine, based on the connection information, whether the first device is a user requiring constant access. The instructions, when executed by the processor, may cause the server to store data representing a result of the determination. The instructions, when executed by the processor, may cause the server to receive, through the communication circuit, a first session creation request from the first device. The instructions, when executed by the processor, may cause the server to, in response to receiving the first session creation request, determine, through the stored data, whether the first device is registered as the user requiring constant access.The above instructions, when executed by the processor, may cause the server to establish a first session for real-time synchronization of the first device and the application if the first device is registered as the always-on user.

[0169] In one embodiment, the instructions, when executed by the processor, may cause the server to determine, based on the connection information, whether the one or more devices have connected within a specific past period. The instructions, when executed by the processor, may cause the server to determine, based on the connection information, whether the number of the one or more devices corresponding to the user identification information is greater than or equal to a threshold. The instructions, when executed by the processor, may cause the server to determine, if the one or more devices have connected within the specific past period and the number of the one or more devices is greater than or equal to the threshold, that the first device is a user requiring constant connection.

[0170] In one embodiment, the instructions, when executed by the processor, may cause the server to determine, based on the connection information, whether a function related to the real-time synchronization of the application has been used by the one or more devices corresponding to the user identification information. The instructions, when executed by the processor, may cause the server to determine that the first device is a user requiring constant access if the one or more devices have connected within the specific past period, the number of the one or more devices is greater than or equal to the threshold, and the function has been used by the one or more devices.

[0171] In one embodiment, the instructions, when executed by the processor, may cause the server to determine, based on the connection information, whether the one or more devices corresponding to the user identification information support a function related to the real-time synchronization of the application. The instructions, when executed by the processor, may cause the server to determine that the first device is the user requiring constant access if the one or more devices have connected within the specific past period, the number of the one or more devices is greater than or equal to the threshold, and the one or more devices support the function related to the real-time synchronization.

[0172] In one embodiment, the instructions, when executed by the processor, may cause the server to transmit, via the communication circuit, a signal indicating a result of the determination to the first device.

[0173] In one embodiment, the one or more devices may include a second device (e.g., the second device (202) of FIG. 2) corresponding to the user identification information. The instructions, when executed by the processor, may cause the server to, when the first device is determined to be the always-on user, store data indicating that the first device and the second device are the always-on user. The instructions, when executed by the processor, may cause the server to transmit, through the communication circuit, a signal indicating that the first device has been registered as the always-on user to the first device. The instructions, when executed by the processor, may cause the server to transmit, through the communication circuit, a signal indicating that the second device has been registered as the always-on user to the second device.

[0174] In one embodiment, the instructions, when executed by the processor, may cause the server to receive, via the communication circuit, a second session creation request from the second device on which the application is running. The instructions, when executed by the processor, may cause the server, in response to receiving the second session creation request, to determine, through the stored data, whether the second device is registered as the always-on user. The instructions, when executed by the processor, may cause the server, if the second device is registered as the always-on user, to establish a second session for real-time synchronization of the second device and the application. The instructions, when executed by the processor, may cause the server to receive, via the second session, information indicating changes in the application running on the second device. The instructions, when executed by the processor, may cause the server to transmit, to the first device, information indicating changes in the application running on the second device through the first session.

[0175] In one embodiment, the connection information may include first connection information of the first device. The instructions, when executed by the processor, may cause the server to register or update the first connection information of the first device based on the first client identification information.

[0176] In one embodiment, the instructions, when executed by the processor, may cause the server to receive, from the first device, the first session creation request at a first timing. The instructions, when executed by the processor, may cause the server to receive, from the first device, a third session creation request at a second timing subsequent to the first timing. The instructions, when executed by the processor, may cause the server to, in response to receiving the third session creation request, update information about the first timing included in the first connection information with information about the second timing.

[0177] In one embodiment, the instructions, when executed by the processor, may cause the server to receive, through the communication circuit, second client identification information including user identification information of the application from the second device on which the application is running. The instructions, when executed by the processor, may cause the server to register or update second connection information of the second device based on the second client identification information.

[0178] In one embodiment, the first client identification information may include device identification information of the first device.

[0179] In one embodiment, the connection information may include user information, device information, creation time of the connection information, and modification time of the connection information.

[0180] According to one embodiment, an electronic device (e.g., a first device (201) of FIG. 2) may include a communication circuit (e.g., a communication module (190) of FIG. 1), a memory (e.g., a memory (130) of FIG. 1) for storing instructions, and a processor (e.g., a processor (120) of FIG. 1). The instructions, when executed by the processor, may cause the electronic device to determine whether the electronic device is a user requiring always-on access based on previously stored always-on user information. The instructions, when executed by the processor, may cause the electronic device to transmit, through the communication circuit, a request to a server (e.g., a server (208) of FIG. 2) to create a session for real-time synchronization of an application running on the electronic device, in response to determining that the electronic device is the always-on user. The instructions, when executed by the processor, may cause the electronic device to transmit, via the communication circuit, client identification information including user identification information of the application to the server in response to determining that the user is not a user requiring constant access.

[0181] In one embodiment, the instructions, when executed by the processor, may cause the electronic device to, after transmitting the client identification information, receive from the server, via the communication circuit, a signal indicating whether the electronic device is the always-on user. The instructions, when executed by the processor, may cause the electronic device to update the always-on user information based on the received signal.

[0182] In one embodiment, the instructions, when executed by the processor, may cause the electronic device to determine whether the last update time of the user information requiring constant access is within a specific past period. The instructions, when executed by the processor, may cause the electronic device to determine that the user is not a user requiring constant access if the last update time is outside the specific past period.

[0183] In one embodiment, the instructions, when executed by the processor, may cause the electronic device to determine a value indicating whether the user requires constant connectivity. The instructions, when executed by the processor, may cause the electronic device to determine that the user requires constant connectivity if the value is true and the last update time is within the specific past period.

[0184] In one embodiment, the instructions, when executed by the processor, may cause the electronic device to, in response to execution of the application, determine whether the electronic device is a user requiring constant access.

[0185] In one embodiment, the instructions, when executed by the processor, may cause the electronic device to transmit information indicating changes to the application to the server via the session established with the server.

[0186] In one embodiment, the instructions, when executed by the processor, may cause the electronic device to receive, from the server through the session established with the server, information indicating changes in another application corresponding to the application and running within another electronic device (e.g., the second device (202) of FIG. 2). The instructions, when executed by the processor, may cause the electronic device to synchronize the information indicating changes in the other application with the application.

[0187] In one embodiment, the application may include a notes application, a messaging application, or a calendar application.

[0188] According to one embodiment, a method performed by a server including a communication circuit may include receiving, through the communication circuit, first client identification information including user identification information of an application from a first device on which an application is running. The method may include identifying, based on the first client identification information, connection information for one or more devices corresponding to the user identification information and including the first device. The method may include determining, based on the connection information, whether the first device is a user requiring constant access. The method may include storing data representing a result of the determination. The method may include receiving, through the communication circuit, a first session creation request from the first device. The method may include determining, in response to receiving the first session creation request, through the stored data whether the first device is registered as the user requiring constant access. The method may include establishing a first session for real-time synchronization of the first device and the application when the first device is registered as the user requiring constant access.

[0189] In one embodiment, a method performed by an electronic device including a communication circuit may include an operation of determining whether the electronic device is a user requiring constant access based on previously stored user information requiring constant access. The method may include an operation of, in response to determining that the electronic device is the user requiring constant access, transmitting to a server, via the communication circuit, a request for creating a session for real-time synchronization of an application running on the electronic device. The method may include an operation of, in response to determining that the user is not the user requiring constant access, transmitting to the server, via the communication circuit, client identification information including user identification information of the application.

[0190] The various embodiments of this document and the terminology used therein are not intended to limit the technical features described in this document to specific embodiments, but should be understood to include various modifications, equivalents, or substitutes of the embodiments. In connection with the description of the drawings, similar reference numerals may be used for similar or related components. The singular form of a noun corresponding to an item may include one or more of the items, unless the context clearly indicates otherwise. In this document, each of the phrases "A or B", "at least one of A and B", "at least one of A or B", "A, B, or C", "at least one of A, B, and C", and "at least one of A, B, or C" can include any one of the items listed together in the corresponding phrase among those phrases, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used merely to distinguish one component from another, and do not limit the components in any other respect (e.g., importance or order). When a component (e.g., a first component) is referred to as "coupled" or "connected" to another component (e.g., a second component), with or without the terms "functionally" or "communicatively," it means that the component can be connected to the other component directly (e.g., wired), wirelessly, or through a third component.

[0191] The term "module" used in various embodiments of this document may include a unit implemented in hardware, software, or firmware, and may be used interchangeably with terms such as logic, logic block, component, or circuit. A module may be an integral component, or a minimum unit or part of such a component that performs one or more functions. For example, according to one embodiment, a module may be implemented in the form of an application-specific integrated circuit (ASIC).

[0192] Various embodiments of the present document may be implemented as software (e.g., a program (140)) including one or more commands stored in a storage medium (e.g., an internal memory (136) or an external memory (138)) readable by a machine (e.g., an electronic device (101)). For example, a processor (e.g., a processor (120)) of the machine (e.g., an electronic device (101)) may call at least one command among the one or more commands stored from the storage medium and execute it. This enables the machine to operate to perform at least one function according to the at least one command called. The one or more commands may include code generated by a compiler or code executable by an interpreter. The machine-readable storage medium may be provided in the form of a non-transitory storage medium. Here, 'non-transitory' simply means that the storage medium is a tangible device and does not contain signals (e.g., electromagnetic waves), and the term does not distinguish between cases where data is stored semi-permanently or temporarily on the storage medium.

[0193] According to one embodiment, the method according to the various embodiments disclosed in the present document may be provided as included in a computer program product. The computer program product may be traded as a product between a seller and a buyer. The computer program product may be distributed in the form of a machine-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or may be distributed online (e.g., downloaded or uploaded) through an application store (e.g., Play Store) or directly between two user devices (e.g., smart phones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily generated in a machine-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0194] According to various embodiments, each component (e.g., a module or a program) of the above-described components may include one or more entities, and some of the entities may be separated and placed in other components. According to various embodiments, one or more components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Alternatively or additionally, a plurality of components (e.g., a module or a program) may be integrated into a single component. In such a case, the integrated component may perform one or more functions of each of the plurality of components identically or similarly to those performed by the corresponding component among the plurality of components prior to the integration. According to various embodiments, the operations performed by a module, program, or other component may be executed sequentially, in parallel, iteratively, or heuristically, or one or more of the operations may be executed in a different order, omitted, or one or more other operations may be added.

Claims

1. On the server, communication circuit; Memory for storing instructions; and Contains a processor, The above instructions, when executed by the processor, cause the server to: Through the above communication circuit, first client identification information including user identification information of the application is received from a first device on which the application is running, Based on the first client identification information, identify connection information for one or more devices corresponding to the user identification information and including the first device; Based on the above connection information, determine whether the first device is a user requiring constant connection, Store data representing the results of the above judgment, Through the above communication circuit, a first session creation request is received from the first device, In response to receiving the above first session creation request, it is checked through the stored data whether the first device is registered as the user requiring constant access, If the first device is registered as the user requiring constant access, causing a first session to be established for real-time synchronization between the first device and the application. Server.

2. In claim 1, The above instructions, when executed by the processor, cause the server to: Based on the above connection information, check whether one or more of the devices have connected within a specific past period, Based on the above connection information, it is checked whether the number of one or more devices corresponding to the user identification information is greater than or equal to a reference value, If the one or more devices have connected within the specific past period and the number of the one or more devices is greater than or equal to the threshold, causing the first device to be determined to be a user requiring constant connection, Server.

3. In claim 2, The above instructions, when executed by the processor, cause the server to: Based on the above connection information, it is determined whether the function related to the real-time synchronization of the application has been used by the one or more devices corresponding to the user identification information, Causing the first device to be determined to be a user requiring constant connection when said one or more devices have connected within said specific past period, the number of said one or more devices is greater than or equal to the threshold, and the function has been used by said one or more devices. Server.

4. In claim 2, The above instructions, when executed by the processor, cause the server to: Based on the above connection information, it is determined whether the one or more devices corresponding to the user identification information support the function related to the real-time synchronization of the application, If said one or more devices have connected within said specific past period, the number of said one or more devices is greater than or equal to the threshold, and said one or more devices support a function related to said real-time synchronization, causing said first device to be determined to be a user requiring constant connection, Server.

5. In any one of claims 1 to 4, The above instructions, when executed by the processor, cause the server to: Causing a signal indicating the result of the judgment to be transmitted to the first device through the above communication circuit. Server.

6. In any one of claims 1 to 5, The one or more devices include a second device corresponding to the user identification information, The above instructions, when executed by the processor, cause the server to: If the first device is determined to be a user requiring constant connection, data indicating that the first device and the second device are users requiring constant connection are stored, Through the above communication circuit, a signal indicating that the first device has been registered as a user requiring constant connection is transmitted to the first device, Causing the second device to transmit a signal indicating that the second device has been registered as the user requiring constant connection through the above communication circuit. Server.

7. In claim 6, The above instructions, when executed by the processor, cause the server to: Through the above communication circuit, a second session creation request is received from the second device on which the application is running, In response to receiving the second session creation request, it is checked through the stored data whether the second device is registered as the user requiring constant access, If the second device is registered as a user requiring constant access, a second session is established for real-time synchronization between the second device and the application. Through said second session, information indicating changes in said application running on said second device is received, Causing said information, indicating said change in said application running on said second device, to be transmitted to said first device through said first session; Server.

8. In claim 6 or claim 7, The above instructions, when executed by the processor, cause the server to: Through the above communication circuit, second client identification information including user identification information of the application is received from the second device on which the application is running, Causing to register or update second connection information of the second device based on the second client identification information; Server.

9. In any one of claims 1 to 7, The above connection information includes first connection information of the first device, The above instructions, when executed by the processor, cause the server to: Causing to register or update the first connection information of the first device based on the first client identification information; Server.

10. In claim 9, The above instructions, when executed by the processor, cause the server to: At a first timing, a first session creation request is received from the first device, At a second timing after the first timing, a third session creation request is received from the first device, In response to receiving the third session creation request, causing the information about the first timing included in the first connection information to be updated with information about the second timing. Server.

11. In any one of claims 1 to 10, The first client identification information includes device identification information of the first device. Server.

12. In any one of claims 1 to 11, The above connection information includes user information, device information, creation time of the connection information, and modification time of the connection information. Server.

13. In electronic devices, communication circuit; Memory that stores instructions; Contains a processor, The above instructions, when executed by the processor, cause the electronic device to: Based on the stored user information requiring constant access, the electronic device determines whether the user requires constant access, In response to determining that the electronic device is a user requiring constant access, a request is transmitted to a server through the communication circuit to create a session for real-time synchronization of an application running on the electronic device, In response to determining that the user is not a user requiring constant access, causing the client identification information, which includes user identification information of the application, to be transmitted to the server through the communication circuit. Electronic devices.

14. In claim 13, The above instructions, when executed by the processor, cause the electronic device to: After transmitting the above client identification information, the electronic device receives a signal from the server through the communication circuit indicating whether the electronic device is a user requiring constant connection, Based on the received signal, causing the user information requiring constant connection to be updated. Electronic devices.

15. In claim 13 or claim 14, The above instructions, when executed by the processor, cause the electronic device to: Check whether the last update time of the above-mentioned user information requiring constant access is within a specific past period, Causing the electronic device to determine that the user is not a user requiring constant access if the last update time is outside the specified past period; Electronic devices.

Images