Electronic device and message processing method of server

Abstract

This electronic device may comprise: memory for storing instructions; and at least one processor including processing circuitry. The instructions, when executed individually or collectively by the at least one processor, may control the electronic device to: receive a trigger signal for message synchronization from a server on the basis of the occurrence of at least one event among registration of an auxiliary device, performance of message restoration, or a synchronization request of a user; on the basis of the trigger signal, determine a period of messages to be synchronized among messages stored in the electronic device; upload messages corresponding to the determined period to the server; periodically update state information of the auxiliary device by transmitting state information indicating the upload progress state of the messages to the server; and perform message synchronization again on the basis of receiving a new trigger signal from the server.

Description

How electronic devices and servers process messages

[0001] Various embodiments of this document relate to electronic devices and servers, for example, to an electronic device capable of transmitting and receiving messages created by a user and a server capable of transmitting, receiving, and storing messages transmitted from various electronic devices.

[0002] With the advancement of mobile communication technology, portable electronic devices (hereinafter referred to as "electronic devices") can provide user experiences through various data communication functions. Electronic devices can provide messaging services such as SMS (short message service) or MMS (multimedia message service), which allow users to send messages they have composed to others; more recently, messaging services based on RCS (rich communication service), which can replace legacy services such as SMS or MMS, are being provided.

[0003] RCS is a standard for messaging services over cellular wireless communication and includes a communication protocol based on the Internet Protocol Multimedia Subsystem (IMS). Compared to legacy services such as SMS or MMS, RCS is becoming widely used due to various advantages, such as increased message length, read receipts, and ease of integration with other applications. Furthermore, RCS can provide group SMS that allows multiple users to participate in real-time, and it can also support the transmission of large files.

[0004] IMS, which forms the foundation of the RCS service, is a network framework specification adopted by 3GPP to provide multimedia services over IP networks. The IMS specification defines signal connection processing between target terminals wishing to use the service, media processing for transmitting actual service data, and the resulting quality or billing methods. A representative protocol used in IMS is SIP (Session Initiation Protocol), which is a multimedia communication protocol for establishing, modifying, and terminating sessions.

[0005] The information described above may be provided as related art for the purpose of aiding understanding of the present disclosure. No claim or determination is made as to whether any of the foregoing may be applied as prior art related to the present disclosure.

[0006] Conventional message synchronization systems have a problem in that they fail to reflect diverse user requirements because the initial synchronization time and message upload period are fixed. Furthermore, there is no method to recover from message inconsistencies that occur between the primary device (PD, electronic device) and the secondary device (SD, auxiliary device) due to errors in the server or terminal. Additionally, there is a problem of unnecessary network traffic occurring because the secondary device fails to recognize the initial synchronization state, requiring synchronization for each individual message.

[0007] The electronic device and method of operation according to this document are intended to resolve these problems by variably applying the initial synchronization time and message upload period to provide services tailored to the characteristics of each user. Additionally, message inconsistency issues are resolved through forced synchronization in the event of a server or terminal error, and network resources can be utilized efficiently by having a secondary device recognize the initial synchronization status and process messages in batches.

[0008] The electronic device may include at least one processor comprising a memory for storing instructions and processing circuitry. When the instructions are executed individually or collectively by the at least one processor, the electronic device may receive a trigger signal for message synchronization from a server based on the occurrence of at least one event among auxiliary device registration, message restoration, or a user's synchronization request; determine a period of messages to be synchronized among the messages stored in the electronic device based on the trigger signal; upload messages corresponding to the determined period to the server; periodically update the status information of the auxiliary device by transmitting status information indicating the progress of message uploads to the server; and control the electronic device to perform message synchronization again based on the receipt of a new trigger signal from the server.

[0009] The message synchronization method and electronic device of this document can provide a consistent user experience with no significant difference in the number of messages stored and displayed between a primary device and a secondary device by variably applying an initial synchronization time and a message upload period.

[0010] The message synchronization method and electronic device described in this document significantly enhance the stability and reliability of the service by enabling recovery from problematic situations through a forced synchronization function, even when discrepancies in stored messages occur due to issues with the server or terminal. Furthermore, by recognizing the initial synchronization state at the secondary device and processing messages in batches, the number of unnecessary network transactions caused by synchronization operations for individual messages is reduced, leading to the efficient use of network resources and improved synchronization speed.

[0011] The message synchronization method and electronic device of this document can provide differentiated synchronization services based on the user's message usage and service subscription type, thereby increasing user satisfaction and improving the overall quality of the service. In particular, sufficient service quality can be guaranteed even for users with low message usage through additional message synchronization.

[0012] In relation to the description of the drawings, the same or similar reference numerals may be used for identical or similar components.

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

[0014] FIG. 2 is a block diagram of a message transmission and reception system according to one embodiment.

[0015] FIG. 3a illustrates the process in which a secondary device downloads a message from a server and displays it to a user in a message transmission and reception system according to a comparative embodiment.

[0016] FIG. 3b illustrates the process in which a secondary device downloads a message from a server and displays it to a user in a message transmission and reception system according to a comparative embodiment.

[0017] FIG. 4 is a block diagram of an electronic device according to one embodiment.

[0018] FIG. 5 is a block diagram of a server according to one embodiment.

[0019] FIG. 6a illustrates a process of resolving a situation where message uploading is impossible by changing the synchronization time in a message transmission and reception system according to one embodiment.

[0020] FIG. 6b illustrates the process of performing additional message uploads by forcibly performing synchronization in a message transmission and reception system according to one embodiment.

[0021] FIG. 6c illustrates the process of transmitting the synchronization start time and end time to a secondary device in a message transmission and reception system according to one embodiment.

[0022] Figure 7 is a flowchart illustrating how an electronic device and a server process messages.

[0023] Hereinafter, embodiments of the present disclosure are described in detail with reference to the drawings so that those skilled in the art can easily practice them. However, the present disclosure may be embodied in various different forms and is not limited to the embodiments described herein. In relation to 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 brevity.

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

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

[0026] The auxiliary processor (123) may control at least some of the functions or states associated with at least one component of the electronic device (101) (e.g., display module (160), sensor module (176), or communication module (190)) 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. According to one embodiment, the auxiliary processor (123) (e.g., image signal processor or communication processor) may be implemented as part of another functionally related component (e.g., camera module (180) or communication module (190)). According to one embodiment, the auxiliary processor (123) (e.g., neural network processing unit) may include a hardware structure specialized for processing an artificial intelligence model. The artificial intelligence model may be generated through machine learning. Such learning may be performed, for example, on the electronic device (101) itself where the artificial intelligence model is executed, or through a separate server (e.g., server (108)). The learning algorithm may 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 may include a plurality of artificial neural network layers.An artificial neural network may be 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 the hardware structure, the artificial intelligence model may include a software structure, either additionally or substantially.

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

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

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

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

[0031] The display module (160) can visually provide information to an external (e.g., 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 said 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 the force generated by said touch.

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

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

[0034] The interface (177) may support one or more specified protocols that can be used for the electronic device (101) to be connected directly or wirelessly to an external electronic device (e.g., electronic device (102)). According to 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.

[0035] The connection terminal (178) may include a connector through which the electronic device (101) can 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).

[0036] The haptic module (179) can convert an electrical signal into a mechanical stimulus (e.g., vibration or movement) or an electrical stimulus that the user can perceive through tactile or kinesthetic senses. According to one embodiment, the haptic module (179) may include, for example, a motor, a piezoelectric element, or an electric stimulation device.

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

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

[0039] The battery (189) can supply power to at least one component of the electronic device (101). According to one embodiment, the battery (189) may include, for example, a non-rechargeable primary battery, a rechargeable secondary battery, or a fuel cell.

[0040] The communication module (190) can support the establishment of a direct (e.g., wired) communication channel or a wireless communication channel between an 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 include one or more communication processors that operate independently of the processor (120) (e.g., application processor) and 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., cellular communication module, short-range wireless communication module, or GNSS (global navigation satellite system) communication module) or a wired communication module (194) (e.g., LAN (local area network) communication module, or power line communication module). The corresponding communication module among these communication modules can communicate with an external electronic device (104) through a first network (198) (e.g., a short-range communication network such as Bluetooth, WiFi (wireless fidelity) direct, or IrDA (infrared data association)) or a second network (199) (e.g., 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 may 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 identify or authenticate the electronic device (101) within a communication network such as the first network (198) or the second network (199) using subscriber information (e.g., International Mobile Subscriber Identifier (IMSI)) stored in the subscriber identification module (196).

[0041] The wireless communication module (192) can support 5G networks and next-generation communication technologies following 4G networks, for example, new radio access technology. NR access technology can support high-speed transmission of high-capacity data (enhanced mobile broadband (eMBB)), minimization of terminal power and connection of multiple terminals (massive machine type communications (mMTC)), or high reliability and low latency (ultra-reliable and low-latency communications (URLLC)). The wireless communication module (192) can support a high-frequency band (e.g., mmWave band) to achieve a high data transmission rate, for example. The wireless communication module (192) can support various technologies for securing performance in the high-frequency band, such as beamforming, massive MIMO (multiple-input and multiple-output), 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), external electronic device (e.g., electronic device (104)), or network system (e.g., second network (199)). According to one embodiment, the wireless communication module (192) can support a Peak data rate (e.g., 20 Gbps or more) for realizing eMBB, loss coverage (e.g., 164 dB or less) for realizing mMTC, or U-plane latency (e.g., downlink (DL) and uplink (UL) each 0.5 ms or less, or round trip 1 ms or less) for realizing URLLC.

[0042] An antenna module (197) can transmit a signal or power to or from an external source (e.g., an external electronic device). According to one embodiment, the antenna module (197) may include an antenna comprising a radiator made 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 a first network (198) or a second network (199), may be selected from the plurality of antennas, for example, by a communication module (190). A signal or power may be transmitted or received between the communication module (190) and an external electronic device through the selected at least one antenna. According to some embodiments, in addition to the radiator, other components (e.g., a radio frequency integrated circuit (RFIC)) may be additionally formed as part of the antenna module (197).

[0043] 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 to a first surface (e.g., bottom surface) of the printed circuit board and capable of supporting a specified high frequency band (e.g., mmWave band), and a plurality of antennas (e.g., array antennas) disposed on or adjacent to a second surface (e.g., top surface or side surface) of the printed circuit board and capable of transmitting or receiving a signal of the specified high frequency band.

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

[0045] According to one embodiment, commands or data may be transmitted or received between the electronic device (101) and an external electronic device (104) through a server (108) connected to a second network (199). Each of the external electronic devices (102, or 104) may be the same or different type of device as the electronic device (101). According to one embodiment, all or part of the operations performed on the electronic device (101) may be performed on one or more of the external electronic devices (102, 104, or 108). For example, if the electronic device (101) needs to perform a function or service automatically or in response to a request from a user or another device, the electronic device (101) may request one or more external electronic devices to perform at least part of the function or service instead of performing the function or service itself or additionally. One or more external electronic devices that receive the above request may execute at least part of the requested function or service, or 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 provide the result as is or additionally processed as at least part of the response to the request. For this purpose, for example, cloud computing, distributed computing, mobile edge computing (MEC), or client-server computing technology may be used. The electronic device (101) may provide ultra-low latency services using, for example, distributed computing or mobile edge computing. In another embodiment, the external electronic device (104) may include an Internet of Things (IoT) device. The server (108) may be an intelligent server using machine learning and / or neural networks. According to one embodiment, the external electronic device (104) or the server (108) may be included within a 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.

[0046] The electronic device according to the various embodiments disclosed in this document may be of various forms. The electronic device may include, for example, a portable communication device (e.g., a smartphone), a computer device, a portable multimedia device, a portable medical device, a camera, a wearable device, or a consumer electronics device. The electronic device according to the embodiments of this document is not limited to the devices described above.

[0047] The various embodiments of this document and the terms used therein are not intended to limit the technical features described in this document to specific embodiments, and should be understood to include various modifications, equivalents, or substitutions of said 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 said items unless the relevant context clearly indicates otherwise. In this document, phrases such as "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" may each include any one of the items listed together in the corresponding phrase, or all possible combinations thereof. Terms such as "first," "second," or "first" or "second" may be used simply to distinguish said components from other said components and do not limit said components in any other aspect (e.g., importance or order). Where any (e.g., 1st) component is referred to as “coupled” or “connected” to another (e.g., 2nd) component, with or without the terms “functionally” or “communicationly,” it means that said any component may be connected to said other component directly (e.g., via a wire), wirelessly, or through a third component.

[0048] The term “module” as used in the 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, for example. A module may be a component formed integrally, or a minimum unit of said component or a part thereof 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).

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

[0050] According to one embodiment, the method according to the various embodiments disclosed herein may be provided by being included in a computer program product. The computer program product may be traded between a seller and a buyer as a product. The computer program product may be distributed in the form of a device-readable storage medium (e.g., compact disc read-only memory (CD-ROM)), or distributed online (e.g., download or upload) through an application store (e.g., Play Store™) or directly between two user devices (e.g., smartphones). In the case of online distribution, at least a portion of the computer program product may be temporarily stored or temporarily created on a device-readable storage medium, such as the memory of a manufacturer's server, an application store's server, or a relay server.

[0051] According to various embodiments, each component (e.g., module or program) of the components described above may include a singular or multiple entities, and some of the multiple entities may be separated and placed in other components. According to various embodiments, one or more of the components or operations of the aforementioned components may be omitted, or one or more other components or operations may be added. Generally or additionally, multiple components (e.g., module or program) may be integrated into a single component. In this case, the integrated component may perform one or more functions of each of the multiple components in the same or similar manner as those performed by the corresponding component among the multiple components prior to integration. According to various embodiments, operations performed by the module, program, or other components 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.

[0052] According to one embodiment, the number of processors (120) may be one or more. For example, the processor (120) may have the structure of a multi-core processor such as a dual core, a quad core, or a hexa core. The processor (120) can control the operations of the electronic device (101) by executing instructions stored in memory (130). For example, the processor (120) may correspond to a plurality of processors that collectively perform a plurality of operations by dividing them among the processors.

[0053] FIG. 2 is a block diagram of a message transmission and reception system according to one embodiment.

[0054] Referring to FIG. 2, the message transmission and reception system may include a primary device (300), a secondary device (400), a message store server (200), a rich communication services application server (RCS AS) (500), and an xMS infrastructure (550). Each device may be connected to each other via a network. In this document, the primary device (300) may be referred to as a first electronic device. The secondary device (400) may be referred to as a second electronic device. Here, the system may represent a concept that includes both an electronic device (e.g., the electronic device (101) of FIG. 1) and a server (e.g., the server (108) of FIG. 1) as a communication system.

[0055] In the following description, the primary device (300) may be denoted as PD or as an electronic device. The secondary device (400) may be denoted as SD or as an auxiliary device.

[0056] According to one embodiment, the primary device (300) and the secondary device (400) may be various types of electronic devices used by a user. The primary device (300) may refer to the electronic device (101) of FIG. 1, and the secondary device (400) may refer to the external electronic device (104) of FIG. 1. For example, the primary device (300) and the secondary device (400) may be implemented as a portable communication device (e.g., a smartphone, or a tablet PC), a computing device (e.g., a desktop PC, or a laptop PC), or a wearable device (e.g., a smart watch, or a head-mounted device), but are not limited thereto. Hereinafter, both the primary device (300) and the secondary device (400) may be referred to as electronic devices. In FIG. 2, the primary device (300) and the secondary device (400) are devices of the same user, and can be recognized as devices of the same user on the network by using the same or linked identification information (e.g., IMEI, or account).

[0057] According to one embodiment, the primary device (300) may be a device including a native client (360) that supports rich communication service (RCS). The native client (360) of the primary device (300) is a native version of an application that supports RCS and may be installed at the time of manufacturing and / or firmware update of the primary device (300). The primary device (300) may implement a basic messaging application in RCS.

[0058] According to one embodiment, the secondary device (400) may not include a native client (360) but may include a downloadable client (460) that supports RCS. For example, the platform (or operating system) of the secondary device (400) may not natively support RCS, and the user may download and install a downloadable client (460) that supports RCS from an application market and run it. According to one embodiment, a plurality of secondary devices corresponding to one primary device (300) may be used.

[0059] In this document, the native client (360) may be the entity that sends and receives actual messages through the RCS AS (500) or xMS infrastructure (550). Additionally, the downloadable client (460) may synchronize messages sent and received through the native client (360), store them, and provide them to the user, and may also send messages through the message store server (200).

[0060] According to one embodiment, the RCS AS (500) may be an application server responsible for sending and receiving RCS messages in accordance with the GSMA (global system for mobile communications association) standard. The RCS AS (500) may provide various RCS functions such as user registration and authentication related to RCS, message routing, group SMS, and / or file transfer.

[0061] According to one embodiment, the xMS infrastructure (550) may be an infrastructure responsible for sending and receiving legacy messages of the 3GPP standard. In this document, legacy message services prior to RCS, such as SMS (short message service), MMS (multimedia message service), or LMS (long message service), may be referred to as xMS.

[0062] According to one embodiment, an RCS message (or RCS MO (mobile originated) / MT (mobile terminated)) transmitted and received from a native client (360) of a primary device (300) may be transmitted and received with another mobile terminal (or counterpart device) via an RCS AS (500), and an xMS message (or xMS MO / MT) transmitted and received may be transmitted and received with another mobile terminal via an xMS infrastructure (550). A downloadable client (460) of a secondary device (400) may not have direct access to the RCS AS (500) and the xMS infrastructure (550). An RCS message or xMS message transmitted and received from a secondary device (400) may be transmitted and received with another mobile terminal via a message store server (200) (e.g., an API server (270)).

[0063] According to one embodiment, the message store server (200) may be a server that provides an OMA CPM (open mobile alliance converged IP messaging) service environment. The message store server (200) may perform various operations such as routing and storing data related to RCS messages and / or xMS messages. The message store server (200) may provide messages sent and received by a native client (360) to a downloadable client (460). Additionally, the message store server (200) may cause messages sent from the downloadable client (460) to be transmitted through an actual message server.

[0064] According to one embodiment, the message store server (200) may include a common message store (260) and an application programming interface (API) server (270). The common message store (260) may store messages transmitted and received from each electronic device (e.g., primary device (300), secondary device (400)) through the message store server (200). The API server (270) may transmit an RCS message requested by a downloadable client (460) to another mobile terminal via the RCS AS (500), and / or transmit an xMS message requested by a downloadable client (460) to another mobile terminal via the xMS infrastructure (550).

[0065] According to one embodiment, when an RCS message is transmitted from a native client (360) of a primary device (300) to another mobile terminal, it may be transmitted to an RCS AS (500). The RCS AS (500) may fork the RCS message to a common message store (260) of a message store server (200). Forking may refer to the operation of simultaneously transmitting a specific message or data to multiple destinations with a single transmission request. The message store server (200) may synchronize the RCS message forked in the common message store (260) with a downloadable client (460) of a secondary device (400). Additionally, when an xMS message is transmitted from a native client (360) to another mobile terminal, it may be transmitted to an xMS infrastructure (550). The xMS infrastructure (550) may fork the xMS message to a common message store (260) of a message store server (200). The message store server (200) can synchronize xMS messages forked in the common message store (260) to downloadable clients (460) of secondary devices (400).

[0066] According to one embodiment, when an RCS message or xMS message is transmitted from a downloadable client (460) of a secondary device (400) to another mobile terminal, it may be transmitted to an API server (270) of a message store server (200). The API server (270) may store the received RCS message or xMS message and synchronize the stored RCS message or xMS message with a common message store (260). The message store server (200) may synchronize the RCS message or xMS message stored in the common message store (260) with the native client (360) of a primary device (300).

[0067] FIG. 3a illustrates the process in which a secondary device (or auxiliary device) downloads a message from a server and displays it to a user in a message transmission and reception system according to a comparative embodiment.

[0068] In the following, the secondary device may be denoted as SD or as auxiliary device. The primary device may be denoted as PD or as electronic device.

[0069] According to FIG. 3a, an electronic device (PD) (300) (e.g., the electronic device (101) of FIG. 1) can subscribe to a message convergence service (MCS) in the absence of existing messages. The message convergence service (MCS) may refer to a message integration service based on the converged IP messaging (CPM) message store service defined by the Open Mobile Alliance (OMA). The MCS can provide the ability to manage various message types (e.g., SMS, MMS, and / or RCS) in an integrated manner and synchronize them between multiple devices. After subscribing to the MCS, the electronic device (101) can upload messages stored on the terminal to a message store server (200), and subsequently restore the messages using a message restoration tool (e.g., Smart Switch, or S Cloud). The electronic device (101) can enable the secondary device (SD) (400) to download messages stored in the message store server (200) and display them to the user when the user adds a secondary device (400).

[0070] In FIGS. 3a and 3b, the message store server (200) can operate as a server responsible for routing and storing data related to RCS messages. The message store server (200) can function as an entity that transmits messages exchanged by the primary device (300) to the secondary device (400), or enables the secondary device (400) to send messages requested for dispatch through the actual message server. Additionally, the message store server (200) can communicate with an authentication server that performs user authentication for RCS messages and an account server that manages user account information.

[0071] In FIGS. 3a and 3b, the SMSC (SMS center) (510) can operate as a server responsible for sending and receiving SMS messages in accordance with 3GPP standards. The SMSC (510) can deliver SMS messages received from the primary device (300) to the message store server (200), and deliver SMS messages received from the message store server (200) to the terminal of the recipient. Additionally, the SMSC (510) can perform basic functions of SMS services, such as managing message delivery status and attempting retransmission.

[0072] In FIGS. 3a and 3b, the push server (560) may operate as a server that transmits a push message (or push notification) received from the message store server (200) to a client device. The push server (560) may receive recipient information (e.g., account, IMEI, and / or IP address) from the message store server (200) and transmit a push message to the corresponding client. The push message may include information about at least one of the group SMS ID, the sender, or a path (e.g., a URL) through which the message can be obtained. The RCS AS (rich communication services application server) (500) may operate as an application server responsible for sending and receiving RCS messages in accordance with GSMA standards.

[0073] According to one embodiment, an electronic device (101) can communicate with a message store server (200) that performs various operations such as routing and storing data related to RCS messages. The message store server (200) can perform various operations to synchronize messages transmitted and received from the electronic device (101) with an auxiliary device (SD) (400). The message store server (200) can communicate with an authentication server that performs authentication of RCS message users and an account server that manages user account information.

[0074] According to one embodiment, the message store server (200) can perform routing and storage operations for data related to RCS messages. The message store server (200) can perform operations to synchronize messages transmitted and received from the primary device (300) with the secondary device (400). The message store server (200) can communicate with an authentication server that performs authentication of the user of the RCS message (e.g., sender or receiver) and an account server that manages the user's account information.

[0075] According to one embodiment, the primary device (300) can generate a message to be transmitted over a group SMS based on user input. The primary device (300) can transmit the generated group SMS message to an SMSC (SMS center) (510). The native client of the primary device (300) can transmit the group SMS message using the RCS method.

[0076] According to one embodiment, the SMSC (510) can transmit group SMS messages transmitted from the primary device (300) to the message store server (200).

[0077] According to one embodiment, the message store server (200) can identify the connected client in the received group SMS message. For example, the message store server (200) can identify the account information of the participants in the group SMS. The message store server (200) can identify at least one client (e.g., a native client, and / or a downloadable client) connected to the sender's account or the recipient's account.

[0078] According to one embodiment, an electronic device (101) can generate a message to be transmitted over a group SMS based on user input. The electronic device (101) can transmit the generated group SMS message to an SMSC (510). The SMSC (510) can transmit the group SMS message transmitted from the electronic device (101) to a message store server (200). The message store server (200) can identify the connected client in the received group SMS message and, through communication with an account server, can identify at least one client connected to the sender's account or the recipient's account using the account information of the group SMS participants.

[0079] However, a problem may occur where messages restored through the message restoration tool are not uploaded to the message store server (200) and are not displayed on the auxiliary device (SD) (400) but only on the electronic device (101). Also, since the timing of uploading messages from the electronic device (101) to the message store server (200) is fixed, it may be difficult to respond flexibly to user requests or changes in server status. Furthermore, it may be difficult to recover messages that have already been synchronized due to errors in the server or terminal, and since the auxiliary device (SD) (400) must process messages one by one individually at the time of initial synchronization, a problem may arise where the number of server accesses increases and it is difficult to display a clear progress status to the user.

[0080] FIG. 3b illustrates the process in which a secondary device downloads a message from a server and displays it to a user in a message transmission and reception system according to a comparative embodiment.

[0081] According to FIG. 3b, an electronic device (PD) (300) (e.g., the electronic device (101) of FIG. 1) can add an auxiliary device (SD) (400) after subscribing to a message convergence service (MCS) and performing message backup and restoration. The electronic device (101) can receive an initial synchronization trigger push from a message store server (200) and can upload messages corresponding to a predetermined period (e.g., one month) to the server. The auxiliary device (SD) (400) can download the messages from the message store server (200) and display them to the user.

[0082] According to one embodiment, a message store server (200) can transmit a push message (or push notification) to a device of an identified client. The message store server (200) can transmit the push message (or push notification) using a push server (560). The message store server (200) can provide the push server (560) with information about the recipient of the push message (e.g., account, IMEI, and / or IP address) and transmit the push message from the push server (560) to the recipient client. For example, the message store server (200) can transmit the push message to a primary device (300) and a secondary device (400) corresponding to a client connected to the sender's account. The push message may include information such as the ID of a group SMS, the sender, and / or a path (e.g., a URL) through which the message can be obtained.

[0083] According to one embodiment, when a secondary device (400) receives a push message, it can check a group SMS message at a message store server (200) using information included in the push message. The push message may include URL information that can be used to obtain the group SMS message. The secondary device (400) can access the message store server (200) using the URL information to obtain the group SMS message.

[0084] According to one embodiment, the secondary device (400) can store acquired group SMS messages and update the UI of the message application.

[0085] According to one embodiment, an electronic device (101) may communicate with a message store server (200) for routing and storing data related to an RCS message. The message store server (200) may perform various operations to synchronize messages transmitted and received from the electronic device (101) with an auxiliary device (SD) (400), and may communicate with an authentication server and an account server for authentication of RCS message users and management of account information.

[0086] In FIGS. 3a and 3b, the electronic device (101) according to the comparative embodiment has a fixed period for uploading messages, which makes it difficult to respond flexibly to user requests or changes in server status. Additionally, recovery of already synchronized messages may be impossible due to errors in the server (e.g., server (108) of FIG. 1, message store server (200), push server (560)) or the electronic device (101). For example, when an auxiliary device (SD) (400) attempts to read a message from the server (108), if an error occurs due to a problem with the server (108), the message cannot be displayed normally. The server (108) may include a message store server (200) and / or a push server (560).

[0087] According to the comparative embodiment, the electronic device (101) must upload stored messages to the server one by one, and whenever a message is added, the server notifies the auxiliary device (SD) (400) of this, and the auxiliary device (SD) (400) must read the message from the server again. Since this process must be repeated for all messages stored in the electronic device (101), there is a problem of unnecessary network traffic and inefficient use of system resources.

[0088] The electronic device (101) according to the present document can solve the problem of generating unnecessary network traffic and using system resources inefficiently. The electronic device (101) according to the present document can generate a message based on user input and transmit it via an SMSC (510). The message store server (200) can efficiently deliver push messages to relevant clients via a push server (560). The push message may include the ID of the group SMS, sender information, and a message acquisition path.

[0089] FIG. 4 is a block diagram of an electronic device according to one embodiment.

[0090] Referring to FIG. 4, an electronic device (101) according to one embodiment may include a display (440), a communication module (430), a processor (410), and a memory (420). Various embodiments of this document may be implemented even if some of the illustrated configurations are omitted or replaced with other configurations. In addition to the illustrated configurations, the electronic device (101) may further include at least some of the configurations and / or functions of the electronic device (101) of FIG. 1. At least some of each of the illustrated (or unillustrated) components of the electronic device (101) may be operatively, functionally, and / or electrically connected.

[0091] According to one embodiment, the electronic device (101) may not include a native client but may include a downloadable client that supports RCS. For example, the platform (or operating system) of the secondary device may not support RCS by default. The electronic device (101) may download and install a downloadable client that supports RCS from an application market and run it. The electronic device (101) may obtain information related to group chat through a message server (e.g., the message store server (200) of FIG. 2).

[0092] According to one embodiment, an electronic device (101) can access a group chat service through the same account as another electronic device (e.g., an external device (104) of FIG. 1) as a device of the same user. For example, when another electronic device participates in a group chat and sends a message, the electronic device (101) can obtain the corresponding event information from the message server and update the group SMS information.

[0093] According to one embodiment, the display (440) may be implemented as any one of a liquid crystal display (LCD), a light-emitting diode (LED) display, or an organic light-emitting diode (OLED) display, but is not limited thereto. The display (440) may be configured as a touch screen that detects touch and / or proximity touch (or hovering) input using a part of the user's body (e.g., finger) or an input device (e.g., stylus pen). The display (440) may include at least some of the configuration and / or functions of the display module (160) of FIG. 1.

[0094] According to one embodiment, the communication module (430) may include various hardware and / or software configurations to support wireless communication with an external device (e.g., external device (104) of FIG. 1). The communication module (430) may support short-range wireless communication (e.g., Wi-Fi, or Bluetooth) and cellular wireless communication (e.g., 4G LTE, or 5G NR). The communication module (430) may include at least some of the configurations and / or functions of the communication module (190) of FIG. 1.

[0095] According to one embodiment, the memory (420) may include volatile memory and non-volatile memory and may store various data temporarily or permanently. The memory (420) may include at least some of the configuration and / or functions of the memory (130) of FIG. 1 and may store at least some of the program (140) of FIG. 1.

[0096] According to one embodiment, the memory (420) can store various instructions that can be executed by the processor (410). Such instructions may include control commands such as arithmetic and logical operations, data movement, or input / output that can be recognized by the processor (410).

[0097] According to one embodiment, the processor (410) may be composed of one or more processors (410) as a configuration capable of performing operations or data processing regarding the control and / or communication of each component of the electronic device (101). The processor (410) may be electrically, functionally, and / or operatively connected to each component of the electronic device (101), including a display (440), a communication module (430), and a memory (420). The processor (410) may include at least some of the configuration and / or functions of the processor (120) of FIG. 1.

[0098] According to one embodiment, there are no limitations on the computation and data processing functions that the processor (410) can implement on the electronic device (101), but below, various embodiments are described in which a spam function is applied when invited to a group chat and the same spam function is applied to a secondary device (e.g., the secondary device (400) of FIG. 2). The operations of the processor (410) described below can be performed by loading instructions stored in memory (420).

[0099] According to one embodiment, the processor (410) can execute a spam function for group chat using a client stored in memory (420). The electronic device (101) can download and install a downloadable client that supports RCS from an application market and execute it. The processor (410) can display a user interface (UI) representing the group chat through a display (440).

[0100] According to one embodiment, the processor (410) may obtain a conference information object generated upon the occurrence of an event related to a group chat invitation from an external message server (e.g., server (108) of FIG. 1) via a communication module (430). According to one embodiment, the message server may generate a conference information object containing information about the event that occurred in response to the occurrence of an event related to the group chat (e.g., sending a message, or changing participants). The conference information object may include at least one attribute information included in the group status object and the session information object, for example, at least one of a session ID, timestamp, group type, participant information, topic, icon, maximum number of users, and session information. The message server may store information about the event that occurred in the group chat using the attribute information defined in the conference information object without generating the group status object and the session information object.

[0101] According to one embodiment, the processor (410) can receive a push message corresponding to an event from a push server (e.g., the push server (560) of FIG. 4), and can access a message server using information (e.g., a URL) included in the push message to obtain a conference information object.

[0102] FIG. 5 is a block diagram of a server according to one embodiment.

[0103] Referring to FIG. 5, a server (108) according to one embodiment may include a communication interface (230), a processor (210), and a memory (220). Various embodiments of this document may be implemented even if some of the illustrated components are omitted or substituted. At least some of the components of the illustrated (or unillustrated) server (108) may be operatively, functionally, and / or electrically connected. The server (108) may include the configuration and functions of the server (108) of FIG. 1.

[0104] According to one embodiment, the server (108) may be a message store server (e.g., the message store server (200) of FIG. 2) that provides an OMA CPM (open mobile alliance converged IP messaging) service environment.

[0105] According to one embodiment, the communication interface (230) may support communication with various electronic devices over a network. The communication interface (230) may provide various interfaces such as HTTP (hypertext transfer protocol), REST (representational state transfer), MQTT (message queuing telemetry transport), or socket. The server (108) may communicate with clients on the network (e.g., primary device (300), secondary device (400) of FIG. 2), and / or servers (e.g., RCS AS (500) of FIG. 2, push server (560) of FIG. 3a or FIG. 3b) through the communication interface (230).

[0106] According to one embodiment, the memory (220) may store various data temporarily or non-temporarily. The memory (220) may include various types of memory (220), such as random access memory (RAM), virtual memory, cache memory, and / or flash memory.

[0107] According to one embodiment, the processor (210) may be composed of one or more processors, configured to perform operations or data processing regarding the control and / or communication of each component of the server (108). There is no limitation to the operations and data processing functions that the processor (210) can implement on the server (108), but various embodiments are described below that enable spam functions related to group chat to be synchronized in electronic devices (e.g., primary device (300) and secondary device (400)). The operations of the processor (210) described below may be performed by loading instructions stored in memory (220).

[0108] According to one embodiment, the processor (210) can confirm that a group SMS is initiated for a group including a first electronic device (e.g., the electronic device (101) of FIG. 1, the primary device (300) of FIG. 2). Here, the group chat may refer to a group chat that can send and receive messages among multiple participants based on a rich communication service (RCS). The first electronic device (101) may be a primary device including a native client (e.g., the primary device of FIG. 2 to 3b). For example, the native client may be a native version of an application that supports RCS, which may be installed during the manufacture of the primary device and / or during a firmware update. The first electronic device (101) may implement a basic messaging application in RCS. The first electronic device (101) is identical to the electronic device (101) of FIG. 1, but will be referred to as the first electronic device (101) below to distinguish it from the second electronic device (104). The second electronic device (104) may refer to the external electronic device (104) of FIG. 1 or the secondary device (400) of FIG. 2.

[0109] According to one embodiment, a user of the first electronic device (101) may also use group chat through a second electronic device (e.g., an external electronic device (104) of FIG. 1, a secondary device (400) of FIG. 2) using the same account. Here, the second electronic device (104) may be a secondary device (e.g., a secondary device of FIG. 2 to 3b) that does not include a native client and includes a downloadable client that supports RCS. The second electronic device (104) may operate on a different platform (or operating system) than the first electronic device (101).

[0110] FIG. 6a illustrates a process of resolving a situation where message uploading is impossible by changing the synchronization time in a message transmission and reception system according to one embodiment.

[0111] In FIGS. 6a, 6b, and 6c, the message store server (200) can operate as a server responsible for routing and storing data related to RCS messages. The message store server (200) can deliver messages exchanged by the primary device (300) to the secondary device (400), or transmit messages requested by the secondary device (400) through the actual message server. Additionally, the message store server (200) can communicate with an authentication server that performs user authentication for RCS messages and an account server that manages user account information.

[0112] In FIGS. 6a, 6b, and 6c, the SMSC (SMS center) (510) can operate as a server responsible for sending and receiving SMS messages in accordance with 3GPP standards. The SMSC (510) can deliver SMS messages received from the primary device (300) to the message store server (200). The SMSC (510) can deliver SMS messages received from the message store server (200) to the terminal of the recipient. Additionally, the SMSC (510) can perform basic functions of SMS services, such as managing message delivery status and attempting retransmission.

[0113] In FIGS. 6a, 6b, and 6c, the push server (560) may operate as a server that transmits a push message (or push notification) received from the message store server (200) to the corresponding client device. The push server (560) may receive recipient information (e.g., account, IMEI, and / or IP address) from the message store server (200) and transmit the push message to the corresponding client. The push message may include information such as the ID of the group SMS, the sender, and / or a path (e.g., URL) through which the message can be obtained. The RCS AS (500) may operate as an application server responsible for sending and receiving RCS messages in accordance with GSMA standards.

[0114] According to one embodiment, an electronic device (PD) (300) (e.g., electronic device (101) of FIG. 1) may subscribe to a message convergence service (MCS) and perform message backup and restoration functions. The electronic device (PD) (101, 300) may receive a trigger signal for message synchronization from a server (e.g., message store server (200)) based on the occurrence of at least one event among the registration of an auxiliary device (SD) (400), the performance of message restoration, or a user's synchronization request. The electronic device (101) may determine the period of messages to be synchronized based on this trigger signal.

[0115] According to one embodiment, the electronic device (101) may change the message synchronization time to the time of registration of the auxiliary device (400) rather than the time of joining the MCS. The push server (560) may send an initial synchronization push containing a time to life (TTL) value to the electronic device (101) at the time when the message store server (200) detects the registration of the auxiliary device (SD) (400). The electronic device (101) may perform initial synchronization at the time when it detects the addition of the auxiliary device (400).

[0116] According to one embodiment, the electronic device (101) may determine the messages received or sent during the corresponding period as synchronization targets based on the start time and end time information included in the trigger signal. The start time and end time may be individually set on the server according to the user's message usage and service subscription type. Additionally, the electronic device (101) may periodically update the status information of the auxiliary device (400) by uploading messages corresponding to the determined period to the message store server (200) and transmitting status information indicating the upload progress status of the messages to the server.

[0117] According to one embodiment, the electronic device (101) may provide a function that allows the user to directly initiate synchronization through a trigger menu provided via a user interface. The electronic device (101) may also automatically perform initial synchronization by detecting when the message restoration function is executed. In this way, the electronic device (101) may provide a message synchronization function.

[0118] According to one embodiment, the electronic device (101) may re-perform message synchronization based on receiving a new trigger signal from a server. The electronic device (101) may store identification information of the last synchronized message in the event of a problem such as a network error or low battery. Subsequently, when the network is restored or the battery is charged, the electronic device (101) may restart synchronization from the messages following that identification information.

[0119] According to one embodiment, the electronic device (101) may variably apply a message upload period when performing message synchronization. The message store server (200) may include a time to life (TTL) value in the initial synchronization push signal transmitted to the electronic device (101) at the time when the auxiliary device (400) is first registered. The TTL value may be set differently for each user based on the user's message usage or service subscription type.

[0120] According to one embodiment, the electronic device (101) can read messages from a database to be uploaded to the message store server (200). At this time, the electronic device (101) can selectively read messages for a corresponding period based on a TTL value received from the message store server (200), rather than an existing fixed period value. The electronic device (101) can upload messages corresponding to the period determined based on the TTL value to the message store server (200). The push server (560) can send a push instructing the upload of messages to the auxiliary device (SD) (400) based on the upload of messages to the message store server (200). The auxiliary device (SD) (400) can download newly uploaded messages from the message store server (200) based on receiving the push instructing the upload of messages from the push server (560). The auxiliary device (SD) (400) can download and display messages exchanged in the electronic device (101) during the TTL period.

[0121] According to one embodiment, when a plurality of auxiliary devices are registered, the electronic device (101) can perform message synchronization by applying a different synchronization period for each auxiliary device. The electronic device (101) can analyze the frequency of message checks by time of the user during a specified period and prioritize synchronizing messages in time periods where the check frequency exceeds a specified level. The electronic device (101) can synchronize messages in the remaining time periods in chronological order when the system's resource utilization is below a specified level.

[0122] According to one embodiment, the electronic device (101) can dynamically adjust the message compression rate by considering the network status and the storage space of the auxiliary device (400). The electronic device (101) can verify synchronization integrity by comparing the hash values ​​of the compressed message and the original message. The electronic device (101) can classify the content types of the synchronization target messages into text messages, messages containing images, and messages containing videos by analyzing the content types of the synchronization target messages. The electronic device (101) can determine an optimized synchronization order according to the transmission speed of the network.

[0123] FIG. 6b illustrates the process of performing additional message uploads by forcibly performing synchronization in a message transmission and reception system according to one embodiment.

[0124] According to one embodiment, an electronic device (e.g., the electronic device (101) of FIG. 1, primary device (300)) may perform message synchronization again by receiving a trigger signal containing a forced synchronization request from a message store server (200) when additional message synchronization is required. The trigger signal may be transmitted in the form of a push message containing a time to life (TTL) value. Based on the forced synchronization request information included in the trigger signal, the electronic device (101) may delete previously performed synchronization information and perform message synchronization anew. The synchronization direction may be specified as one of a unidirectional upload ("forceUp") from the electronic device (101) to the server, a unidirectional download ("forceDown") from the server to the electronic device (101), or a bidirectional synchronization ("forceAll").

[0125] According to one embodiment, the message store server (200) may transmit a new trigger signal for additional synchronization to the electronic device (101) based on the fact that the number of messages uploaded from the electronic device (101) is less than the minimum number of synchronization messages per user group set by the server. Alternatively, the message store server (200) may transmit a new trigger signal for additional synchronization to the electronic device (101) if an error occurs during the message synchronization process. The electronic device (101) may transmit status information indicating at least one of the start, resume, or done status of message synchronization to the message store server (200) during the synchronization process. Upon receiving the done status information, the message store server (200) may transmit a synchronization completion notification to the auxiliary device (400).

[0126] According to one embodiment, the electronic device (101) can respond to various situations that may occur during message synchronization. For example, if a network error or low battery occurs, the electronic device (101) can store identification information of the most recently synchronized message, and when the network is restored or the battery is charged, it can restart synchronization from the messages after that identification information. Additionally, the electronic device (101) can analyze the content types of the messages to be synchronized and classify them into text, images, or videos. The electronic device (101) can perform synchronization in an optimized order based on the classified content types and network status. The electronic device (101) can dynamically adjust the message compression rate and verify synchronization integrity by considering the storage space of the auxiliary device (400).

[0127] According to one embodiment, the electronic device (101) communicates with a message store server (200) and can perform efficient message synchronization with an auxiliary device (400). The electronic device (101) can provide an optimized synchronization service based on user-specific characteristics and the state of the communication system. The auxiliary device (400) can reliably display messages exchanged from the electronic device (101) during the TTL period. The electronic device (101) can provide a consistent user experience regarding messages across multiple devices to the user.

[0128] FIG. 6c illustrates the process of transmitting the synchronization start time and end time to a secondary device in a message transmission and reception system according to one embodiment.

[0129] According to one embodiment, an electronic device (e.g., the electronic device (101) of FIG. 1, the primary device (300)) can transmit status information to a message store server (200) at the start and end of message synchronization. The status information can be used to periodically update the status of an auxiliary device (400). The electronic device (101) can effectively display the synchronization progress status to the user.

[0130] According to one embodiment, the electronic device (101) can transmit "start" status information when initial synchronization starts, "resume" status information during the process, and "done" status information when completed to the server. This status information can be transmitted via the syncMessage Status API. The API request can have the form of a URL (e.g., "{serverRoot} / nms / v1 / os / {userMDN} / syncMessage / status") and can be transmitted via the POST method. The status information may include a syncType parameter indicating the type of synchronization. The status information may be specified as one of "init", "forceAll", "forceUp", or "forceDown".

[0131] According to one embodiment, when the auxiliary device (400) receives initial synchronization start status information from the message store server (200), it can display through a user interface that synchronization is in progress. Subsequently, when the auxiliary device (400) receives synchronization end status information, it can download and process all messages stored in the message store server (200) in batches. In this way, the auxiliary device (400) can reduce the number of times it accesses the message store server (200) for each individual message and efficiently use network resources.

[0132] According to one embodiment, when the message store server (200) receives synchronization completion status information from the electronic device (101), it can send a synchronization completion notification to the auxiliary device (400). Upon receiving this notification, the auxiliary device (400) can display the downloaded messages to the user and update the user interface of the message application. The electronic device (101) can perform the message synchronization process with the auxiliary device (400) more efficiently and stably. The electronic device (101) can clearly convey the synchronization progress to the user. The electronic device (101) can provide a function to recover from network errors or system problems that may occur during synchronization.

[0133] Figure 7 is a flowchart illustrating how an electronic device and a server process messages.

[0134] The operations described through FIG. 7 may be implemented based on instructions that can be stored in a computer recording medium or memory (e.g., memory (220) of FIG. 5). The illustrated method (700) may be executed by an electronic device (e.g., electronic device (101) of FIG. 1, electronic device (PD) (300) of FIG. 6a) as described above through FIG. 1 to 6c, and the technical features described above will be omitted below. The order of each operation in FIG. 7 may be changed, some operations may be omitted, and some operations may be performed simultaneously.

[0135] According to one embodiment, in operation 710, an electronic device (e.g., electronic device (101) of FIG. 1, primary device (300) of FIG. 2) may receive a trigger signal for message synchronization under the control of a processor (e.g., processor (120) of FIG. 1). The electronic device (101) may receive a trigger signal for message synchronization from a server (108) based on the occurrence of at least one event among registration of an auxiliary device (SD) (e.g., secondary device (400) of FIG. 2), execution of message restoration, or a user's synchronization request.

[0136] According to one embodiment, the electronic device (101) may receive trigger signals at multiple points in time for message synchronization with the auxiliary device (400). The time of receiving these trigger signals may be when the auxiliary device (400) is first registered with the server (108), when a message restoration function is executed on the electronic device, or when message synchronization is requested through a user interface. The trigger signals received from the server (108) may include information regarding the start and end times of the messages to be synchronized. The time information may be individually set by the server (108) according to the user's message usage and service subscription type.

[0137] According to one embodiment, in operation 720, the electronic device (101) can determine the duration of messages to be synchronized based on a trigger signal. The electronic device (101) can determine the duration of messages to be synchronized based on time information included in the received trigger signal. The duration determined therein may be set using a TTL (time to life) value received from the server (108) rather than a fixed value. The electronic device (101) can delete previously performed synchronization information and perform message synchronization anew based on the forced synchronization request information included in the trigger signal.

[0138] According to one embodiment, in operation 730, the electronic device (101) may periodically update the status information of the auxiliary device (SD) (e.g., the secondary device (400) of FIG. 2). The status information may include at least one of a first status information indicating the start of message synchronization, a second status information indicating the resume of message synchronization, and a third status information indicating the done of message synchronization. The electronic device (101) may periodically update the status information of the auxiliary device (400) by uploading messages corresponding to a determined period to the server (108) and transmitting status information indicating the progress status of the upload of messages to the server (108). The electronic device (101) may upload messages corresponding to a determined period during the message synchronization process to the server (108) and periodically report the synchronization progress status to the server (108). This status information may include information indicating the start, resume, or done of message synchronization. The server (108) can transmit this status information to the auxiliary device (SD) (400). The auxiliary device (SD) (400) receives information about the message synchronization status from the server (108) and can display the synchronization progress to the user in real time. When the completion status is transmitted from the server (108), the auxiliary device (400) can download the messages stored in the server (108) in bulk, thereby reducing unnecessary network transactions.

[0139] According to one embodiment, in operation 740, the electronic device (101) may receive a new trigger signal and re-perform message synchronization. The electronic device (101) may re-perform message synchronization by receiving a new trigger signal containing a forced synchronization request from the server (108) based on an error occurring during the message synchronization process or the number of uploaded messages being less than a specified number. For example, if the number of messages synchronized by the electronic device (101) is less than the minimum number of synchronized messages per user group set by the server (108), or if a problem such as a network error or low battery occurs during the synchronization process, the electronic device (101) may receive a new trigger signal from the server (108) and re-perform message synchronization. At this time, the electronic device (101) may store identification information of the last synchronized message and, when the network is restored or the battery is charged, restart synchronization from the messages after that identification information.

[0140] According to one embodiment, the electronic device (101) can perform message synchronization with the server (108) using the method described in operations 710 to 740. The electronic device (101) can also receive and / or send actual messages from the auxiliary device (400) and perform read, delete, or cancel operations on the message. Additionally, if multiple auxiliary devices (e.g., watch, tablet) are registered, message synchronization can be performed by applying different synchronization periods for each auxiliary device (400).

[0141] According to one embodiment, the electronic device (101) can provide a differentiated synchronization service based on the user's message usage and service subscription type. Previously, there was a limitation in that the initial synchronization time and the message storage period were fixed, so only services based on the same standards could be provided to all users. The message transmission method of the electronic device (101) according to this document can provide individual services according to the needs of each user. For example, the electronic device (101) can adjust the total amount of messages initially synchronized according to the user's message usage pattern. If there is User A who exchanges 100 messages and User B who exchanges 1,000 messages in a month, previously only 100 and 1,000 messages, respectively, would be synchronized, which could result in a difference in service quality. However, the electronic device (101) according to this document can upload additional messages if the number of synchronized messages for User A falls below the average number for general users through a changed TTL value received from the server and a forced initialization push. The number of messages mentioned is merely an example and may vary depending on the settings.

[0142] According to one embodiment, the electronic device (101) can provide differentiated services based on the desired synchronization period for each user. For example, if a specific user subscribed to a billing service wants to check messages for a relatively longer period (e.g., 1 year) compared to the existing service period (e.g., 3 months) on both the primary device and the secondary device, the electronic device (101) can receive a forced reset push containing an extended TTL period for that user to synchronize messages for a longer period compared to the existing service period. The electronic device (101) can provide customized synchronization services optimized for the user's requirements and service usage patterns by using the forced reset push containing the extended TTL period. The mentioned periods are merely examples and may vary depending on the settings.

[0143] According to one embodiment, the electronic device (101) receives a trigger signal for message synchronization from the server (108) based on the occurrence of at least one event among the registration of an auxiliary device (400), the performance of message restoration, or a user's synchronization request, and can determine the period of messages to be synchronized among the messages stored in the electronic device based on the trigger signal. The electronic device (101) can upload messages corresponding to the determined period to the server (108) and transmit status information indicating the upload progress status of the messages to the server (108) to periodically update the status information of the auxiliary device (400). The electronic device (101) can perform message synchronization again by receiving a new trigger signal including a forced synchronization request from the server (108) based on an error occurring during the message synchronization process or the number of uploaded messages being less than a specified number.

[0144] According to one embodiment, the electronic device (101) can detect various trigger events for message synchronization. Here, the trigger events may include server registration of the auxiliary device (400), execution of a message restoration function, or a synchronization request through a user interface. When the auxiliary device (400) is first registered with the server (108), the server (108) may transmit a trigger signal to the electronic device (101) after the registration is completed. The trigger signal may include a time to life (TTL) value indicating the period for performing message synchronization, and this value may define the start and end times of the message to be synchronized. The TTL value may be individually set by the server (108) according to each user's message usage or service subscription type. The electronic device (101) may provide a differentiated synchronization service for each user using the TTL value. Based on the TTL value of the received trigger signal, the electronic device (101) may query messages corresponding to the period from an internal database and upload them to the server (108). During the upload process, the electronic device (101) can transmit status information indicating the progress status to the server (108). The status information may include values ​​such as 'start', 'resume', or 'done', and the server (108) can transmit this information to the auxiliary device (400) to display the synchronization progress in real time. Through this, the auxiliary device (400) can receive all messages at once at the time of synchronization completion without repeated requests from the server (108) for individual messages, thereby enabling efficient management of network traffic.

[0145] According to one embodiment, trigger events that may occur in the electronic device (101) may include registering a server (108) of an auxiliary device (400), such as a tablet, restoring a message via a smart switch, or an action in which a user clicks a synchronization button. These trigger events are merely examples and are not limited thereto, and may vary depending on the settings.

[0146] According to one embodiment, the TTL value received by the electronic device (101) may be applied differently depending on the service subscription type, such as the last month for general users and the last three months for premium users. Alternatively, it may be set differently based on usage, such as six months for users with an average monthly message sending volume of less than 100 messages and one month for users with 1,000 or more messages. The setting of such TTL values ​​is merely an example and is not limited thereto, and may vary depending on the settings of the server (108). For example, regarding synchronization status information, when synchronization is first started on the tablet, a 'start' status may be displayed and the progress may start at 0%. When the network is resumed after a temporary interruption, a 'resume' status may be displayed and may continue from the previous progress (e.g., 45%). When synchronization is completed, a 100% progress may be displayed along with a 'done' status. The method of displaying such status information is merely an example and is not limited thereto, and may vary depending on the implementation method.

[0147] According to one embodiment, when synchronizing 1,000 messages from an electronic device (101) (e.g., a smartphone) to an auxiliary device (400) (e.g., a tablet), the server (108) may first specify the last month as the TTL value and transmit it to the electronic device (101). The electronic device (101) uploads messages during this period to the server (108), and can display the progress on the auxiliary device (400) by increasing the progress rate by a certain level (e.g., 10%) every time 100 messages are uploaded. If the uploaded messages stop at 800, the server (108) may transmit a new trigger signal to synchronize the remaining 200 messages as well. This synchronization processing method is merely an example and is not limited thereto, and may vary depending on the network conditions or the performance of the electronic device (101).

[0148] According to one embodiment, the server (108) may transmit a new trigger signal for forced synchronization if an error occurs during the synchronization process or if the number of uploaded messages is less than expected. The forced synchronization signal may include a synchronization type such as 'forceUp', 'forceDown', or 'forceAll', and may specify upload-only, download-only, or bidirectional synchronization, respectively. The electronic device (101) can effectively resolve message inconsistency issues between the server (108) and the electronic device (101) by using the forced synchronization signal and can provide consistent message services to the user. For example, the electronic device (101) may perform forced synchronization when only 800 out of 1000 messages are uploaded due to a network error (e.g., forceUp), when messages from the electronic device (101) need to be downloaded again after recovering the server database (e.g., forceDown), or when full synchronization is required due to message inconsistency between the server and the electronic device (101) (e.g., forceAll). This forced synchronization situation is just one example and is not limited to this, and may vary depending on the state or type of error of the electronic device (101).

[0149] According to one embodiment, the electronic device (101) may perform a synchronization operation by analyzing information (e.g., synchronization type, TTL value, or priority) included in a forced synchronization request received from the server (108). In the process of initializing the existing synchronization state, data in the synchronization-related tables of the database (e.g., sync_status, message_queue, or upload_history) may be deleted and preparations for a new synchronization may be made. This forced synchronization process is merely an example and is not limited thereto, and may vary depending on the system implementation method. Here, the system may refer to the message transmission and reception system described in FIG. 2 as a communication system. Additionally, the system may represent a concept that includes both the electronic device (101) and the server (108).

[0150] According to one embodiment, a trigger signal for message synchronization may be received at the time when the auxiliary device (400) is first registered with the server (108), at the time when the message restoration function is executed on the electronic device (101), or at the time when message synchronization is requested through the user interface. The timing of receiving the trigger signal may include, for example, when a user registers a new tablet, when previous backup data is restored via a smart switch, or when touch input by the user on the synchronization button is detected in the settings menu. Such timing of receiving the trigger signal is merely an example and is not limited thereto, and may vary depending on the user's actions or the time of error occurrence.

[0151] According to one embodiment, the electronic device (101) may transmit information indicating a 'start' state when synchronization starts, transmit a 'resume' state and a progress percentage (e.g., 50%) at the time of suspension when resuming due to a specified situation (e.g., network failure or forced shutdown of the electronic device (101)), and transmit information indicating whether synchronization is complete when synchronization is complete. The auxiliary device (400) may receive this status information and display it to the user as a progress bar, a notification message, or a status icon. This method of processing status information is merely an example and is not limited thereto, and may vary depending on the user interface design.

[0152] According to one embodiment, the electronic device (101) can determine the messages received or sent during the corresponding period as synchronization targets based on the start time and end time information included in the trigger signal. The start time and end time may be individually set by the server (108) according to the user's message usage and service subscription type. The electronic device (101) may additionally provide a function to directly set the synchronization period through a user interface, and may also perform synchronization automatically when the message restoration function is executed. The electronic device (101) can adjust the synchronization time and satisfy various user requirements through period settings, and can efficiently manage messages.

[0153] According to one embodiment, the electronic device (101) may provide functions in a settings menu for selecting a synchronization period (e.g., 1 month, 3 months, 6 months, or set directly), selecting a synchronization target (e.g., synchronizing only text messages, or synchronizing including multimedia messages), and setting an automatic synchronization cycle (e.g., daily, weekly, or monthly). These user interface setting options are merely examples and are not limited thereto, and may vary depending on the functionality of the application or user convenience.

[0154] According to one embodiment, the electronic device (101) can delete previously performed synchronization information and perform message synchronization anew based on the forced synchronization request information included in the trigger signal. The electronic device (101) can process the forced synchronization request information included in the trigger signal received from the server (108). Forced synchronization may mean initializing the status information of a previously performed synchronization operation and starting a new synchronization. At this time, the electronic device (101) can delete the existing synchronization status information from the database and synchronize messages of the corresponding period anew according to the TTL value included in the trigger signal.

[0155] According to one embodiment, the status information may include at least one of a first status information indicating the start of message synchronization, a second status information indicating the resumption of message synchronization, and a third status information indicating the completion of message synchronization. The progress status of message synchronization may be expressed as three stages of status information. The electronic device (101) may transmit a 'start' status when starting a synchronization operation, a 'resume' status when resuming suspended synchronization, and a 'done' status when synchronization is completed to the server (108). The status information is transmitted to the auxiliary device (400) via the server (108) to display the synchronization progress to the user in real time. When the auxiliary device (400) receives the 'done' status, it can download all messages stored in the server (108) in bulk, thereby preventing an inefficient situation where a request is made to the server (108) for each individual message.

[0156] According to one embodiment, the trigger signal may include information specifying the direction of message synchronization. The message synchronization direction may include at least one of unidirectional upload from the electronic device (101) to the server (108), unidirectional download from the server (108) to the electronic device (101), or bidirectional synchronization. The trigger signal may include information specifying the direction of message synchronization. The synchronization direction may be classified into 'forceUp', 'forceDown', or 'forceAll' types, which may respectively mean unidirectional upload from the electronic device (101) to the server (108), unidirectional download from the server (108) to the electronic device (101), and bidirectional synchronization. By specifying this directionality, only the necessary synchronization operations can be selectively performed, thereby enabling efficient utilization of network resources.

[0157] According to one embodiment, when the electronic device (101) receives a 'forceUp' type trigger, it uploads messages from a local database to a server (108) (e.g., sends 1,000 new messages), when it receives a 'forceDown' type trigger, it downloads the latest messages from the server (108) (e.g., receives 200 missing messages), and when it receives a 'forceAll' type trigger, it can synchronize messages in both directions (e.g., simultaneously process 1,000 uploads and 200 downloads). This method of processing in the direction of synchronization is merely an example and is not limited thereto, and may vary depending on network conditions or the requirements of the communication system.

[0158] According to one embodiment, the electronic device (101) can proceed with uploading in stages according to the priority of messages (e.g., importance, chronological order) when performing 'forceUp'. When performing 'forceDown', the electronic device (101) can compare the latest message list of the server (108) with local messages and selectively download only the messages that differ. When performing 'forceAll', the electronic device (101) can efficiently use system resources by adjusting the priority of upload and download operations. These processing methods by synchronization type are merely examples and are not limited thereto, and may vary depending on the implementation method or performance requirements.

[0159] According to one embodiment, the duration of the messages to be synchronized may be differentiated and set by the server (108) for each user. The trigger signal may include information regarding the duration of the messages to be synchronized. The server (108) may determine the duration of the messages to be synchronized by considering the user's message usage pattern and / or service subscription type. Information regarding the duration of the messages to be synchronized may be reflected in the TTL value of the trigger signal and transmitted to the electronic device (101). The electronic device (101) may provide a synchronization service optimized for each user by utilizing the information regarding the duration of the messages to be synchronized.

[0160] According to one embodiment, the electronic device (101) may apply different TTL values ​​depending on the service subscription type (e.g., 1 month for general members, 3 months for premium members) or may set a differential synchronization period depending on message usage (e.g., 6 months for less than 100 messages per month, 3 months for 100 to 1000 messages, or 1 month for more than 1000 messages). In addition, it may be set differently depending on the usage pattern (e.g., 1 month for business hour users, or 2 weeks for 24-hour users) or the type of auxiliary device (400) (e.g., 3 months for tablets, or 2 weeks for smartwatches). The mentioned service subscription type or period setting is merely an example and is not limited thereto, and may vary depending on the service policy or system conditions.

[0161] According to one embodiment, an electronic device (101) can be controlled to receive a new trigger signal for additional synchronization when the number of messages uploaded to the server (108) is less than the minimum number of synchronization messages per user group set by the server (108). The trigger signal may be transmitted from the server (108) in the form of a push message. If the number of messages uploaded by the electronic device (101) to the server (108) does not reach the minimum number of synchronization messages per user group defined by the server (108), the server (108) may transmit a new trigger signal for additional synchronization. This trigger signal may be transmitted in the form of a push message, and the electronic device (101) may receive it and perform additional message synchronization. Through this, a consistent level of message synchronization service can be provided for each user group.

[0162] According to one embodiment, the electronic device (101) may apply differentiated criteria for each group, such as a minimum of 500 messages for a general user group and a minimum of 1,000 messages for a business user group. If the uploaded messages of a general user are limited to 300 messages, the server (108) may send a push message for additional synchronization (e.g., "syncMessage": {"syncType": "forceUp", "cms_data_ttl": "86400"}). These message count criteria are merely examples and are not limited thereto, and may vary depending on the characteristics of the user group or service requirements. Here, 86400 represents a unit of seconds (sec) and is a number corresponding to 24 hours x 60 minutes x 60 seconds, which may represent a day. "cms_data_ttl": "86400" may mean that the CMS data is valid for 86,400 seconds, i.e., a day, after it is generated.

[0163] According to one embodiment, the electronic device (101) may re-perform message synchronization by receiving a trigger signal containing a forced synchronization request from the server (108) based on an error occurring during the message synchronization process with the server (108). The electronic device (101) may handle various error situations that may occur during the message synchronization process with the server (108). Error situations may include, for example, a communication failure with the server (108), a failure to store messages, or a data inconsistency situation. The server (108) may transmit a trigger signal containing a forced synchronization request based on the detection of an error. The electronic device (101) may initialize the existing synchronization state and restart message synchronization based on the reception of a new trigger signal.

[0164] According to one embodiment, the electronic device (101) can detect various error situations including network timeouts (e.g., no response for more than 30 seconds), server errors (e.g., insufficient disk space), or data integrity errors (e.g., checksum mismatch). When an error occurs, the server (108) can transmit a forced synchronization request appropriate to the type of error (e.g., upload after waiting for a certain period in case of a network error, compressed upload in case of a storage error, or resynchronize entirely in case of an integrity error) by including it in the trigger signal. This method of handling errors is merely an example and is not limited thereto, and may vary depending on the system configuration or the severity of the error.

[0165] According to one embodiment, when a plurality of auxiliary devices (400) are registered, the electronic device (101) can control message synchronization by applying different synchronization periods for each auxiliary device. For example, a longer period of message synchronization can be set for an auxiliary device (400) whose usage frequency exceeds a certain level, and only messages from the recent period can be synchronized for an auxiliary device (400) whose usage frequency is below a certain level. Through this, the storage space and network resources of each auxiliary device (400) can be utilized efficiently.

[0166] According to one embodiment, if a network error or low battery occurs during message synchronization, the electronic device (101) stores identification information of the most recently synchronized message and can resume synchronization from messages after that identification information when the network is restored or the battery is charged. For example, unexpected situations such as a network error or low battery may occur during synchronization. The electronic device (101) can record the identifier (ID) of the most recently synchronized message in an internal storage based on the occurrence of a network error or low battery situation. The electronic device (101) can resume synchronization from messages after the stored identifier based on the network being restored or the battery being charged beyond a specified level. The electronic device (101) can prevent duplicate synchronization and perform recovery efficiently.

[0167] According to one embodiment, the electronic device (101) can analyze the frequency of message checks by time zone of a user during a specified period and prioritize synchronizing messages in time zones where the check frequency exceeds a specified level. The electronic device (101) can synchronize messages in chronological order for the remaining time zones when the resource utilization rate of the communication system is below a specified level. The electronic device (101) can track the frequency of message checks by time zone during a specified period and prioritize synchronizing messages in time zones that the user checks frequently. When the system resource utilization rate is below a specified level, messages in the remaining time zones can be synchronized sequentially in chronological order.

[0168] According to one embodiment, the electronic device (101) can dynamically adjust the message compression rate by considering the network status and the storage space of the auxiliary device (400), and verify synchronization integrity by comparing the hash values ​​of the compressed message and the original message. The electronic device (101) can perform a dynamic message compression function based on the network status and the storage space of the auxiliary device (400). The electronic device (101) can adjust the message compression rate according to the network speed and the available storage space of the auxiliary device (400). To ensure the integrity of the compressed message, the data corruption can be verified by comparing the hash values ​​of the original message and the compressed message.

[0169] According to one embodiment, the electronic device (101) may periodically monitor the network connection status with the auxiliary device (400) and perform compression on message data if the network speed is detected to be below a specified threshold (e.g., 1 Mbps). In this case, the compression rate may be applied inversely proportional to the network speed, and if the network condition is very poor (e.g., network speed is less than 100 Kbps), the maximum compression rate (e.g., size less than 20% of the original) may be applied. Additionally, the electronic device (101) may check the storage space status of the auxiliary device (400) and force message compression if the available storage space is below a specified threshold (e.g., 10% of the total capacity). This is intended to prevent synchronization failure due to insufficient storage space of the auxiliary device (400), and may be particularly effective when synchronizing messages containing large multimedia attachments. The figures mentioned are merely examples and may vary depending on the settings.

[0170] According to one embodiment, to ensure data integrity during the compression process, the electronic device (101) may generate and compare hash values ​​of the original message and the compressed message, respectively, using a cryptographic hash function such as SHA-256. In this case, if the hash value of the message after decompression does not match the hash value of the original message, the compression ratio for the message may be lowered and retransmission attempted. In the event of consecutive retransmission failures, the message may be transmitted in its original, uncompressed state. During the transmission process of the compressed message, the electronic device (101) may implement split transmission in chunk units. Each chunk has an independent hash value, and network resources can be utilized efficiently by retransmitting only the corresponding chunk in the event of a transmission failure. Additionally, the electronic device (101) may utilize a sequence number to verify order errors or omissions that may occur during the assembly process of the transmitted chunks.

[0171] According to one embodiment, the electronic device (101) analyzes the content types of messages to be synchronized and classifies them into text messages, messages containing images, and messages containing videos. If the transmission speed of the network is below a specified level, it may synchronize text messages first, and then synchronize messages containing images and videos respectively when the transmission speed is measured to be above the specified level. The electronic device (101) may control the display of the filename, size information, and thumbnail image of the content of a message containing multimedia content that has not been synchronized to an auxiliary device, and to perform synchronization immediately to display the full content when a user selects the message.

[0172] According to one embodiment, the electronic device (101) may apply a differentiated synchronization strategy based on the type of message content. The electronic device (101) may classify messages to be synchronized by type, such as text, images, or videos, and perform synchronization in stages according to network conditions. The electronic device (101) may prioritize synchronizing text messages when the network speed is low, and then sequentially synchronize multimedia content when the speed improves. For multimedia content that has not yet been synchronized, only metadata (e.g., filename, size, thumbnail) may be displayed, and the content may be immediately synchronized and provided when the user selects it.

Claims

1. In an electronic device, Memory for storing instructions; It includes at least one processor comprising processing circuitry, and When the above instructions are executed individually or collectively by the at least one processor, the electronic device Based on the occurrence of at least one event among auxiliary device registration, message restoration, or user synchronization request, a trigger signal for message synchronization is received from the server, and Based on the above trigger signal, the period of messages to be synchronized among the messages stored in the electronic device is determined, and Upload messages corresponding to the above-determined period to the above-determined server, and Status information indicating the upload progress status of the above messages is transmitted to the server to periodically update the status information of the auxiliary device, and An electronic device that controls message synchronization to be performed again based on receiving a new trigger signal from the above server.

2. In Paragraph 1, The trigger signal for the above message synchronization is Received at the time when the above auxiliary device is first registered with the server, or Received at the time when the message restoration function is executed in the above electronic device, or It is received at the time when message synchronization is requested through the user interface, and An electronic device that receives a new synchronization signal based on an error occurring during the message synchronization process or the number of uploaded messages being less than a specified number.

3. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device Control is established to determine messages received or sent during the corresponding period as synchronization targets based on the start and end time information included in the trigger signal above, and The above start and end times are electronic devices individually set by the server according to the user's message usage and service subscription type.

4. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device An electronic device that controls the deletion of previously performed synchronization information and the performance of new message synchronization based on forced synchronization request information included in the above trigger signal.

5. In Paragraph 1, The above status information is, First state information indicating the start of message synchronization, Second state information indicating the resumption of message synchronization and An electronic device comprising at least one of third state information indicating completion (done) of message synchronization.

6. In Paragraph 1, The above trigger signal includes information specifying the message synchronization direction, and The above message synchronization direction is Unidirectional upload from the above electronic device to the above server, Unidirectional download from the above server to the above electronic device or An electronic device comprising at least one of bidirectional synchronization.

7. In Paragraph 1, An electronic device in which information regarding the duration of messages to be synchronized is set differently for each user based on the user's message usage or service subscription type.

8. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device An electronic device that controls receiving a new trigger signal for additional synchronization when the number of messages uploaded to the above server is less than the minimum number of synchronization messages per user group set by the server.

9. In Paragraph 1, The above trigger signal is An electronic device transmitted from the above server in the form of a push message.

10. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device An electronic device that controls message synchronization to be performed again by receiving a trigger signal containing a forced synchronization request from the server based on an error occurring during the message synchronization process with the server.

11. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device An electronic device that controls message synchronization by applying different synchronization periods to each auxiliary device when multiple auxiliary devices are registered.

12. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device If a network error or low battery occurs during message synchronization, save the identification information of the last synchronized message, and An electronic device that controls synchronization to resume from messages following the identification information when the network is restored or the battery is charged.

13. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device Analyze the user's message checking frequency by time of day during a specified period, prioritize synchronizing messages from time periods where the checking frequency exceeds a specified level, and An electronic device that controls messages for the remaining time periods to be synchronized in chronological order when the system's resource utilization is below a specified level.

14. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device An electronic device that controls dynamically adjusting the message compression rate by considering network conditions and the storage space of auxiliary devices, and verifies synchronization integrity by comparing the hash values ​​of the compressed message and the original message.

15. In Paragraph 1, When the above instructions are executed individually or collectively by the at least one processor, the electronic device Analyze the content types of the messages to be synchronized and classify them into text messages, messages containing images, and messages containing videos, and If the network transmission speed is below the specified level, text messages are synchronized first, and then when the transmission speed is measured to be above the specified level, messages containing images and videos are synchronized separately. Messages containing multimedia content that has not been synchronized display the filename, size information, and thumbnail image of the content on the auxiliary device, and An electronic device that controls the display of the entire content by performing immediate synchronization when the user selects the message.

Images