Electronic device for managing application by using rollback prevention, operation method thereof, and storage medium

Abstract

According to an embodiment, an electronic device comprises: a memory that stores instructions; and a processor operatively connected to the memory, wherein the instructions, when executed by the processor, may cause the electronic device to: at least identify a request associated with installation of a first application; identify whether or not information associated with a history of the first application is stored in the memory; on the basis of identifying that the information associated with the history of the first application is stored in the memory, identify a first RP policy corresponding to the first application; identify whether or not a value corresponding to version information included in the request is greater than or equal to or a value corresponding to version information included in the first RP policy; and on the basis of identifying that the value corresponding to the version information included in the request is less than the value corresponding to the version information included in the first RP policy, output a response associated with the refusal of the installation of the first application. Other various embodiments are possible.

Description

Electronic device for managing applications using rollback prevention, method of operation thereof, and storage medium

[0001] Embodiments of the present disclosure relate to an electronic device, an operating method thereof, and a storage medium for managing an application using rollback prevention.

[0002] Thanks to remarkable advancements in information and communication technology and semiconductor technology, the proliferation and use of various electronic devices is rapidly increasing. Electronic devices are being developed to enable portability and communication.

[0003] An electronic device may refer to a device that performs a specific function depending on the program installed on it, such as a mobile communication terminal, tablet PC, video / audio device, desktop / laptop computer, or vehicle navigation system.

[0004] As the variety of services and additional features provided through electronic devices such as smartphones increases, the types of applications provided on electronic devices are also diversifying.

[0005] Electronic devices can store and execute basic applications manufactured and installed by the device's manufacturer, as well as additional applications downloaded from application sales websites via the Internet. Accordingly, recent electronic devices can store at least tens, or even hundreds, of applications.

[0006] An electronic device may include rollback prevention (RP). RP is a security solution. RP may be applied, for example, to a binary image or a trusted application (TA) loaded on the electronic device. Based on the RP policy, the electronic device blocks the installation (or update) of software with a version lower than the current version corresponding to the binary image or TA. For example, the electronic device may include a binary image whose RP version corresponds to 3. The electronic device rejects the loading request based on the verification that the binary image being loaded corresponds to RP version 2.

[0007] The above information may be provided as background art to aid in understanding the present disclosure. No claim or determination is made as to whether any of the above-described matters constitute prior art related to the present disclosure.

[0008] According to one embodiment, an electronic device may include a memory storing instructions, and a processor operatively connected to the memory. The instructions, when executed by the processor, may cause the electronic device to verify a request associated with installation of a first application. The instructions, when executed by the processor, may cause the electronic device to verify whether information associated with a history of the first application is stored in the memory. The instructions, when executed by the processor, may cause the electronic device to verify a first RP policy corresponding to the first application based on verifying that information associated with a history of the first application is stored in the memory. The instructions, when executed by the processor, may cause the electronic device to verify whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy. The instructions, when executed by the processor, may cause the electronic device to output a response associated with a rejection of installation of the first application based on determining that a value corresponding to version information included in the request is less than a value corresponding to version information included in the first RP policy.

[0009] According to one embodiment, a method of operating an electronic device may include an operation of verifying a request associated with installation of a first application. The method may include an operation of verifying whether information associated with a history of the first application is stored in a memory of the electronic device. The method may include an operation of verifying a first RP policy corresponding to the first application based on verifying that information associated with the history of the first application is stored in the memory. The method may include an operation of verifying whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy. The method may include an operation of outputting a response associated with a rejection of installation of the first application based on verifying that the value corresponding to the version information included in the request is less than a value corresponding to the version information included in the first RP policy.

[0010] According to one embodiment, a storage medium may store instructions. The instructions, when executed by a processor of an electronic device, may cause the electronic device to perform operations. The operations may include: verifying a request associated with installation of a first application. The operations may include verifying whether information associated with a history of the first application is stored in a memory of the electronic device. The operations may include verifying a first RP policy corresponding to the first application based on verifying that information associated with the history of the first application is stored in the memory. The operations may include verifying whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy. The operations may include outputting a response associated with a rejection of installation of the first application based on verifying that the value corresponding to the version information included in the request is less than a value corresponding to version information included in the first RP policy.

[0011] FIG. 1 is a block diagram of an electronic device within a network environment, according to one embodiment.

[0012] FIG. 2 illustrates a block diagram illustrating an exemplary electronic device according to one embodiment.

[0013] FIG. 3 illustrates a block diagram illustrating an exemplary electronic device according to one embodiment.

[0014] FIG. 4 is a flowchart illustrating an operation of an electronic device according to one embodiment to check whether a first application is installed.

[0015] FIG. 5 is a flowchart illustrating an operation of an electronic device according to one embodiment to determine an RP policy corresponding to multiple applications.

[0016] FIG. 6 is a graph showing a scaled score confirmed by an electronic device according to one embodiment.

[0017] FIG. 7 is a flowchart illustrating an operation of an electronic device according to one embodiment to change an RP policy based on a scaled score.

[0018] FIGS. 8A, 8B, and 8C are flowcharts illustrating an operation of an electronic device according to one embodiment to change an RP policy based on a scaled score.

[0019] FIG. 9 is a flowchart illustrating an operation of an electronic device updating an RP policy according to one embodiment.

[0020] FIG. 10A and FIG. 10B are flowcharts illustrating an operation of an electronic device updating an RP policy according to one embodiment.

[0021] FIG. 11 is a flowchart illustrating an operation of an electronic device according to one embodiment to restrict installation of an application that does not satisfy a condition.

[0022] FIG. 12 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to output a message in response to a deletion request from an application.

[0023] FIGS. 13A and 13B are flowcharts illustrating an operation of an electronic device according to one embodiment of the present invention to update an RP version corresponding to each of a plurality of applications in response to a request for deletion of the application.

[0024] FIG. 14 is a flowchart illustrating an operation of an electronic device according to one embodiment to check a value corresponding to a version of an application based on checking the version system of the application.

[0025] FIG. 15 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to determine whether to install an application based on checking the version system of the application.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0049] FIG. 2 illustrates a block diagram illustrating an exemplary electronic device according to one embodiment.

[0050] Referring to FIG. 2, the electronic device (101) may include a processor (120) and a memory (130). The electronic device (101) of FIG. 2 may be the electronic device (101) of FIG. 1.

[0051] The memory (130) may store data related to a control program for controlling the electronic device (101) and an application provided by the manufacturer or downloaded from an external source. According to one embodiment, the memory (130) may store instructions that, when executed, cause the electronic device (101) or the processor (120) to perform operations. Specific operations performed by the electronic device (101) (or the processor (120)) will be described later.

[0052] According to one embodiment, the processor (120) may perform general operations to determine whether to install an application based on the application version. The processor (120) may include modules for applying RP policies to various user applications. The modules included in the processor (120) and their specific operations will be described below.

[0053] In one embodiment, not all components illustrated in FIG. 2 are essential components of the electronic device (101), and the electronic device (101) may be implemented with more or fewer components than those illustrated in FIG. 2. For example, the electronic device (101) may include a display (e.g., the display module (160) of FIG. 1). The display may simultaneously support data input / output functions and detect touch. According to one embodiment, the display may include a sensing panel (not illustrated), a display panel (not illustrated), and a display control unit (not illustrated). According to one embodiment, the display may be referred to as a “touch screen.” The sensing panel may detect contact or proximity of a finger or an input device (e.g., a stylus pen). When the display is implemented in the form of a touch screen, it may transmit various sensing information acquired according to a user’s touch operation to the processor (120).

[0054] FIG. 3 illustrates a block diagram illustrating an exemplary electronic device according to one embodiment.

[0055] Referring to FIG. 3, the electronic device (101) may include modules (310). The modules (310) may include a package manager (320), a rollback prevention manager (RP manager) (330), a score operator (340), a weight evaluator (350), and a history manager (360).

[0056] In one embodiment, the modules (310) implemented (or stored) in the electronic device (101) may be implemented in the form of an application, a program, a computer code, instructions, a routine, a process, software, firmware, or a combination of at least two or more thereof executable by the processor (120). For example, when the modules (310) are executed, the processor (120) may perform an operation corresponding to each. Therefore, in the present disclosure, the description that “a specific module (or, service) performs an operation” may be understood as “as the specific module is executed, the processor (120) performs an operation corresponding to the specific module.” In one embodiment, at least some of the modules (310) may include multiple programs, but are not limited to what is described. Meanwhile, at least some of the modules (310) may also be implemented in hardware form (e.g., a processing circuit (not shown)). In one embodiment, the modules (310) may be implemented as at least a part of an Android framework in which a user application is installed. When implemented on the Android operating system, the modules (310) may be implemented as services or applications. In one embodiment, the electronic device may include, but is not limited to, the Android OS and a secure OS. The electronic device may be implemented as a device including, for example, another operating system that performs functions corresponding to the modules described in this disclosure.

[0057] In one embodiment, the package manager (320) may be a module that verifies information associated with an application installed on the electronic device (101) and examines the application. According to one embodiment of the present disclosure, the package manager (320) may process a request associated with the RP information of the application.

[0058] In one embodiment, the RP manager (330) may be a module that transfers data between the package manager (320) and the remaining modules (e.g., the score operator (340), the weight evaluator (350), or the history manager (360)). The RP manager (330) may, for example, transmit information associated with an application to the package manager (320). The RP manager (330) may transmit a request associated with a comparison of scores corresponding to applications to the score operator (340). The RP manager (330) may transmit a request associated with an adjustment (or recalculation) of at least one weight to determine a distribution corresponding to applications to the weight evaluator (350). The RP manager (330) may transmit a request associated with an update of a history corresponding to at least one of an installation, deletion, or deactivation of an application to the history manager (360).

[0059] The score operator (340) can calculate a score corresponding to each application installed on the electronic device (101) based on a predetermined procedure. The score corresponding to the application may be related to the security of the electronic device (101) and / or the user convenience of the electronic device (101). The elements referenced by the score operator (340) to calculate the score will be described later.

[0060] In one embodiment, the weight evaluator (350) may adjust the weights corresponding to at least some of the elements referenced for calculating the score. The weight evaluator (350) may change the weights corresponding to at least some of the elements associated with calculating the score in response to an event that triggers the adjustment of the weights.

[0061] In one embodiment, the history manager (360) may transmit score information corresponding to each of the applications installed on the electronic device (101) and / or applications that have been installed on the electronic device (101) in the past to the RP manager (330). The RP manager (330) may check parameters associated with a distribution calculated based on the score information received from the history manager (360). The RP manager (330) may check events associated with weight adjustments based on the parameters associated with the distribution and / or the score information. The RP manager (330) may request the weight evaluator (350) to adjust the weights based on the checked events associated with weight adjustments. The weight evaluator (350) may change weights corresponding to at least some of the elements associated with score calculation based on the information included in the request.

[0062] In one embodiment, when a vulnerability in the application is discovered, the application developer can distribute a patch binary that addresses the vulnerability. The manufacturer of the electronic device can immediately respond to an attack targeting the application by upgrading the RP version of the software through an emergency patch. After installing the patch binary corresponding to the higher RP version, the electronic device can block attempts to restore to software corresponding to a lower RP version based on the RP policy. The electronic device can respond to an external attack by blocking updates to software corresponding to a lower RP version that contains a vulnerability.

[0063] In one embodiment, application developers may distribute updated software to the store at set intervals or at specific points in time to prevent attacks, regardless of whether vulnerabilities in the application are discovered. A policy of distributing updated software to prevent attacks in advance can reduce the time and financial costs associated with discovering (or predicting) software vulnerabilities. Electronic devices can block installation requests for software with lower versions that may contain vulnerabilities by installing software with a higher version.

[0064] In one embodiment, a binary image or TA required to be loaded onto an electronic device may be produced and / or managed by the manufacturer of the electronic device. The manufacturer of the electronic device may increment the RP version of the binary image or TA at any time based on the manufacturer's resources. Since the RP version corresponding to the binary image or TA can be expressed as a simple number, the RP solution applied to the binary image or TA may be relatively easy to manage in version management.

[0065] In one embodiment, a user application (or client application), which is an application that is frequently requested to be installed and / or deleted by a user of an electronic device, may have a relatively difficult time identifying the application version using a simple number. User applications may be produced and / or distributed by various entities (or businesses). Each of the producers and / or distributors of user applications may utilize a different system for application version management.

[0066] In one embodiment, even for the same application developer, the application's version management scheme may differ depending on the application type. For example, the rules for identifying an application's version may vary depending on the environment of the device on which the application is running, the country in which the application is distributed, or the supported features for that device type.

[0067] In one embodiment, a package management solution may be utilized to prevent version downgrades of user applications. The package management solution may cause the electronic device to reject installation requests for applications with versions lower than those corresponding to the applications installed on the electronic device. In one embodiment, the package management solution may relatively freely allow version downgrades of user applications, depending on the settings of installation options. Since the package management solution cannot respond to the deletion or deactivation of user applications, it may be considered a solution for package management within the electronic device, rather than a security solution.

[0068] In one embodiment, the electronic device (101) may calculate scores for various user applications produced and / or distributed by different entities based on the operation of the modules (310), and determine application groups with different security levels based on the calculated scores. The electronic device (101) according to one embodiment of the present disclosure may manage the versions of user applications that are frequently installed, updated, or deleted, in contrast to a method of uniformly managing the versions of binary images or TAs using simple numbers. The electronic device (101) may apply different levels of RP policies to each user application (or user application group) in consideration of the security of the electronic device (101) and / or the user convenience of the electronic device (101). The electronic device (101) may block the deletion of the current version package (e.g., a patched application) of an application with a relatively high level of permission and the installation of a previous version package (e.g., an APK with a vulnerability). The electronic device (101) can reduce the risk of malicious activity attempting to reproduce vulnerabilities of previous versions of applications by applying a more flexible and efficient RP policy.

[0069] FIG. 4 is a flowchart illustrating an operation of an electronic device according to one embodiment to check whether a first application is installed.

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

[0071] According to one embodiment, in operation 401, an electronic device (e.g., electronic device (101) or processor (120) of FIG. 1 or FIG. 2) may verify a request associated with installation of a first application.

[0072] In one embodiment, the electronic device can identify a request associated with the installation of a first application based on user input. The user input may be an input that triggers the installation of the first application based on access to an app store. The user input may also be an input that downloads the installation file for the first application via an Internet browser. The download of the installation file may be performed via wired or wireless communication.

[0073] In one embodiment, an electronic device may receive a request associated with installation of a first application from an external electronic device (e.g., at least one of the electronic device (102), the electronic device (104), or the server (108) of FIG. 1 ). The electronic device may receive the request associated with installation of the first application based on communication with the external electronic device. For example, the electronic device may receive an installation file of the first application from the external electronic device (e.g., the electronic device (102) of FIG. 1) via a short-range wireless communication network (e.g., the first network (198) of FIG. 1 ). The electronic device may confirm the request associated with installation of the first application based on a user input associated with execution of the received installation file.

[0074] In one embodiment, the electronic device may confirm a request associated with installation of a first application from a cloud server based on the establishment of a short-range wireless communication connection with an access point or a network connection with a long-range wireless communication network (e.g., the second network (199) of FIG. 1).

[0075] According to one embodiment, in operation 403, the electronic device may determine whether information associated with the history of the first application is stored in a memory (e.g., memory (130) of FIG. 1 or FIG. 2).

[0076] In one embodiment, an electronic device may store information related to the history of multiple applications installed on the electronic device in memory. In one embodiment, when an installation request for a first application is received, the electronic device may check whether a package installation history corresponding to an application having the same package name as the first application exists. For example, the package installation history may be stored in the form of a table including a history related to the installation, deletion, or update of a package among data managed by a history manager (e.g., the history manager 360 of FIG. 3). The electronic device may check whether a history table for a target package for installation exists. In one embodiment, the history table may include multiple history tables corresponding to applications. The electronic device may manage, for example, a history table corresponding to each of the multiple applications included in the electronic device. In one embodiment, the history table may include a single history table including history information for one or more applications. The electronic device may manage, for example, history information corresponding to multiple applications included in the electronic device within a single history table. The electronic device can, for example, check a history table corresponding to a first application stored in memory.

[0077] Table 1 is an example of a history table associated with the installation and deletion of the first application (PKG1).

[0078]

[0079] In one embodiment, the history manager may store information associated with a date, history type, version, flag, and installation source (SRC) corresponding to each of a plurality of applications installed on an electronic device. Referring to Table 1, it can be confirmed that the first application corresponding to version 12303 was deleted after being installed. Referring to Table 1, it can be confirmed that the packages corresponding to versions 12324 and 12345 were updated after the first application corresponding to version 12313 was reinstalled. The history manager may store information associated with the history of applications installed and / or deleted on an electronic device in the past, in contrast to a package manager (e.g., package manager (320) of FIG. 3) that stores information associated with applications currently installed on an electronic device. The history manager may store a history table corresponding to each of a plurality of applications currently installed on an electronic device and / or that have a history of being installed on an electronic device in the past, as well as the first application.

[0080] In one embodiment, information associated with a date and / or time may include information associated with the date and / or time an installation, update, or deletion was performed. Information associated with a history type may include information associated with an event corresponding to an installation, update, or deletion. Information associated with a version may include version information corresponding to a user application. Information associated with a flag may indicate version information determined based on an RP policy corresponding to the corresponding package. For example, if a flag corresponding to an application is set to T, this may indicate that the version corresponding to the flag T is the RP version that is compared against the version information of the application for which installation is requested. Information associated with a source may indicate whether the RP policy corresponding to the version was determined when the application was installed or was allocated from the cloud and / or the network. The history table associated with installation and deletion may further include additional fields in addition to the fields shown in Table 1.

[0081] Table 2 is an example of an integrated information table associated with the level and score of the first application (PKG1).

[0082]

[0083] Referring to Table 2, the RP score, RP level, and the reference RP version for determining whether to install the first application are described. The values ​​in Table 2 can be determined based on the values ​​of the history table in Table 1. For example, a score operator (e.g., score operator (340) of FIG. 3) can calculate a score corresponding to the first application based on elements corresponding to the first application (e.g., the level of authority declared for the first application, whether the first application is a preloaded application, and the update frequency of the first application). The score operator (340) can associate a plurality of applications (e.g., M applications (M is a natural number)) with one of a plurality of levels (e.g., N levels). The score operator (340) can transmit the score and level corresponding to the first application to the RP manager (330). The history manager (360) can receive and store scores and levels corresponding to an application from the RP manager (330). More specific operations of the score operator will be described later.

[0084] In one embodiment, level 3 may indicate that the value corresponding to the version of the application installed on the electronic device two steps prior to the current version in the history table is determined as the value of the RP version corresponding to the RP policy. Referring to Table 1, since the version of the currently installed first application is 12345, if the level corresponding to the first application is 3, the version corresponding to the first application two steps prior to the first application, 12313, may be determined as the RP version. Based on the determination of the RP version, the history manager may update the flag corresponding to the determined RP version in the history table to T, and store the value corresponding to the RP version in the RP version field of the unified information table. In one embodiment, the tables of Tables 1 and 2 may be stored in different areas of memory. The electronic device (or processor) may refer to Table 2 based on the memory address stored in Table 1. The electronic device may also refer to Table 1 based on the memory address stored in Table 2. In one embodiment, Tables 1 and 2 may be stored in the same area of ​​memory.

[0085] An electronic device according to one embodiment of the present disclosure can easily manage applications, compared to a method that checks whether an application with a package name corresponding to an application whose installation is requested exists. The electronic device can check the history associated with the installation, deletion, or update of multiple applications installed on the electronic device. The electronic device can manage an RP policy corresponding to each user application that is characterized by frequent deletion or reinstallation.

[0086] In one embodiment, if the electronic device determines that information associated with the history of the first application is not stored in the memory (operation 403-No), then in operation 411, the electronic device can update the history of the first application. The electronic device can update the information associated with the history of the first application. For example, the history manager can update the history table and the integrated information table corresponding to the first application. The electronic device can install the first application in operation 413. In one embodiment, the order in which operations 411 and 413 are performed can be changed. For example, the electronic device can install the first application based on determining that information associated with the history of the first application is not stored in the memory (operation 403-No). The electronic device can update the history of the first application after installing the first application.

[0087] In one embodiment, if the electronic device determines that information associated with the history of the first application is stored in the memory (operation 403 - Yes), in operation 405, the electronic device may check the first RP policy corresponding to the first application. For example, the electronic device may check the RP information stored in the history table (e.g., version information with the flag set to T) and / or the level stored in the integrated information table. In one embodiment, the electronic device may check in operation 407 whether the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the version information included in the first RP policy.

[0088] In one embodiment, the electronic device can verify the version information of the first application included in the request. The electronic device can verify whether the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the RP information corresponding to the first RP policy. For example, referring to Table 1, the electronic device can verify that the RP information corresponding to the first application is 12313. Based on verifying that the value corresponding to the version information of the first application included in the request is 12324 or 12345, the electronic device can verify that the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the version information included in the first RP policy.

[0089] In one embodiment, if the electronic device determines that the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the version information included in the first RP policy (operation 407 - Yes), then in operation 411, the electronic device can update the history of the first application. The electronic device can update information associated with the history of the first application. For example, the history manager can update the history table and the integrated information table corresponding to the first application. The electronic device can install the first application in operation 413. In one embodiment, the order in which operations 411 and 413 are performed can be changed. For example, the electronic device can install the first application based on determining that the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the version information included in the first RP policy (operation 407 - Yes). The electronic device can update the history of the first application after installing the first application.

[0090] In one embodiment, if the electronic device determines that the value corresponding to the version information included in the request is less than the value corresponding to the version information included in the first RP policy (operation 407-No), then in operation 409, the electronic device may output a response associated with the rejection of the installation of the first application. For example, referring to Table 1, the electronic device may determine that the RP information corresponding to the first application is 12313. Based on determining that the value corresponding to the version information of the first application included in the request is 12303, the electronic device may determine that the value corresponding to the version information included in the request is less than the value corresponding to the version information included in the first RP policy. Based on determining that the value corresponding to the version information included in the request is less than the value corresponding to the version information included in the first RP policy, the electronic device may output, for example, a message notifying that the first application has failed through a display (e.g., the display module of FIG. 1) or an audio output module (e.g., the audio output module (155) of FIG. 1).

[0091] In one embodiment, an application's version information may be determined based on different standards, depending on the application ecosystem. If the application's version information is determined based on standards that are inappropriate for simple numerical comparison, the electronic device can extract a meaningful numerical value from the version information based on established rules. A specific method for comparing the numerical value extracted from the version information with a value corresponding to the RP information will be described below.

[0092] An electronic device according to one embodiment of the present disclosure can apply different levels of RP policies to each application, compared to a method that uniformly blocks the installation of applications with older version information based on fixed version information. By performing more flexible and efficient application version management, the electronic device can enhance the security of the electronic device while maintaining its usability.

[0093] FIG. 5 is a flowchart illustrating an operation of an electronic device according to one embodiment to determine an RP policy corresponding to multiple applications.

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

[0095] According to one embodiment, in operation 501, an electronic device (e.g., electronic device (101) or processor (120) of FIG. 1 or FIG. 2) may determine a score corresponding to each of the plurality of applications based on information associated with the plurality of applications.

[0096] In one embodiment, the electronic device may identify a score corresponding to each of a plurality of applications to manage the history table (or "package history table") described in Table 1. In one embodiment of the present disclosure, the score corresponding to an application may include an index referenced to determine whether the application is installed. The score corresponding to an application may have a positive correlation with the security level required for the application.

[0097] Mathematical expression 1 is an example of a method for calculating a score corresponding to an application by taking into account several factors.

[0098]

[0099] The above mathematical formula 1 is merely an example to aid understanding, and embodiments of the present disclosure may not be limited thereto. For example, the above mathematical formula 1 may be modified, applied, or expanded in various ways.

[0100] Referring to mathematical expression 1, it can be explained that a score corresponding to an application is calculated based on a weighted sum of multiple factors. w may include a numerical value associated with the weight of the factor. N may include a numerical value associated with the number of permissions allowed to the application. For example, N signature may include a numerical value associated with the number of at least one signature permission set by the manufacturer of the electronic device for the application. The signature permission may include, for example, an install permission. w signature may contain a numerical value associated with the weight for the signature authority. N dangerous The application may include a numerical value associated with at least one permission set by the user for the application. The permissions set by the user may include, for example, permissions associated with system pop-ups or permissions associated with messaging services including short message service (SMS), long message service (LMS), or multimedia message service (MMS). w dangerous may contain a numerical value associated with a weight for a permission set by the user. b preload may contain an index indicating whether the application is a preload application. b preload For example, it can have a value of 1 or 0 depending on whether the application for which the score is to be calculated is a preloaded application. Preloaded applications may include applications provided by the manufacturer of the electronic device. w preload may contain a numerical value associated with the weight for the preload application. Level update may contain a numerical value associated with a level corresponding to the application that wishes to update the score. The level may contain an index indicating the level of security required by the application. Levelupdate For example, it can have a natural number value between 1 and 5, but the specific numerical value is not limited thereto. A method for matching applications to a given level based on the scaled score will be described later.

[0101] Table 3 shows examples of factors considered to derive a score corresponding to an application and the level of RP policy corresponding to the case.

[0102]

[0103] Referring to Table 3, it can be explained that the level of the RP policy is determined according to the elements associated with the application and / or the parameters corresponding to the elements.

[0104] In one embodiment, the electronic device can calculate a score suitable for the characteristics of the application based on the factors described in Table 3 in addition to the factors considered in Equation 1. The electronic device can calculate a score corresponding to the application based on at least some of the factors (or more factors) in Table 3. The electronic device can calculate a score corresponding to the application using a calculation formula based on appropriate factors among the plurality of factors so as to maintain the usability of the application and improve the security of the application.

[0105] In one embodiment, the electronic device may determine the level of RP policy applied to an application based on the application's usage pattern. For example, the electronic device may determine the level of RP policy applied to an application based on at least one of, or a combination of, the application's update frequency, the application's execution frequency, the application's background operation ratio, and the application's battery usage. When the level of RP policy applied to an application is determined based on the application's usage pattern, different levels of RP policy may be applied to the same application depending on the environment (or device) on which the application is executed.

[0106] In one embodiment, the number of signature permissions used by an application may be related to the number of permissions granted to the application by the manufacturer of the electronic device. The number of signature permissions may have a positive correlation with the impact of the application on the resources of the electronic device. Considering that the application has a large number of signature permissions, there is a risk that the application may have a large impact on the resources of the electronic device, a relatively recent version of the application may be required to be associated with the electronic device. The electronic device may apply a relatively high level of RP policy to an application with a relatively high number of signature permissions. A high level of RP policy may be referred to as an "aggressive RP policy." The electronic device may, for example, determine the most recent version corresponding to the application or a version one step older than the most recent version as the RP version corresponding to the application. By applying an aggressive RP policy to an application with a large number of signature permissions, the electronic device can enhance the security of the application.

[0107] In one embodiment, the number of daunting permissions used by an application may be related to the number of permissions set by the user for the application. The number of daunting permissions may have a positive correlation with the impact of the application on the resources of the electronic device. Considering that the application has a large number of daunting permissions, there is a risk that the application will have a large impact on the resources of the electronic device, a relatively recent version of the application may be required to be associated with the electronic device. The electronic device may apply a relatively high level of RP policy to an application with a relatively large number of daunting permissions. The electronic device may, for example, determine the most recent version corresponding to the application or a version that is one step older than the most recent version as the RP version corresponding to the application. By applying an aggressive RP policy to an application with a large number of daunting permissions, the electronic device can enhance the security of the application.

[0108] In one embodiment, if the update frequency of an application is low, even if the security of the application is enhanced, the impact on the usability of the application may be relatively small. The electronic device can determine the update frequency of the application based on the update history corresponding to the application. The electronic device can apply a relatively high level of RP policy to an application with a relatively low update frequency. For example, the electronic device can determine the RP version corresponding to the application as the most recent version or a version one step older than the most recent version. If the update frequency of the application is high, the usability of the application may be relatively reduced due to applying a high level of RP policy to the application. If the update frequency of the application is relatively high, the electronic device can apply a relatively low level of RP policy to the application. By applying a proactive RP policy to an application with a relatively low update frequency, the electronic device can improve the security of the application with a relatively small impact on usability.

[0109] In one embodiment, if an application is a preload application, the impact of the application on the resources of the electronic device may be relatively greater than that of a typical user application. The electronic device may determine whether the application corresponds to a preload application based on information associated with the application (e.g., application identification information). The electronic device may apply a relatively high level of RP policy to the preload application. For example, the electronic device may determine the most recent version corresponding to the application or a version one step older than the most recent version as the RP version corresponding to the application. By applying a proactive RP policy to the preload application, the electronic device can enhance the security of the preload application.

[0110] In one embodiment, the frequency of execution of an application may be related to the impact of applying an RP policy to the application on its usability. For example, if an application is frequently executed, the impact on its usability may be relatively greater due to enhanced security. If an application is frequently executed, the usability of the application may be relatively reduced by applying a high-level RP policy to the application. The electronic device may determine the frequency of execution of an application based on its execution history. The electronic device may apply a relatively low-level RP policy to an application with a relatively high execution frequency. For example, the electronic device may determine a version three steps older than the most recent version of the application as the RP version corresponding to the application. The electronic device may not apply the RP policy to the application. If the frequency of execution of an application is relatively low, the electronic device may apply a relatively high-level RP policy to the application. For example, the electronic device may determine a version one step older than the most recent version of the application as the RP version corresponding to the application. A low-level RP policy can be referred to as a "conservative RP policy." Electronic devices can improve application usability by applying a conservative RP policy to frequently-executed applications.

[0111] In one embodiment, if an application uses sharedUserId, the impact on the resources of the electronic device due to an attack on the application may be relatively greater than that of an application that does not use sharedUserId. The electronic device can determine whether the application uses sharedUserId based on information associated with the application. sharedUserId may be a feature that allows applications to directly share data (e.g., a database or data file) based on assigning the same user ID to two or more applications in the Android operating system, for example. In one embodiment, the name of sharedUserId may change when another operating system is included in the electronic device. The electronic device can apply a relatively high level of RP policy to the application that uses sharedUserId. The electronic device can determine, for example, the most recent version corresponding to the application or a version that is one step older than the most recent version as the RP version corresponding to the application. By applying a proactive RP policy to the application that uses sharedUserId, the electronic device can enhance the security of the application.

[0112] In one embodiment, if the source of an application's installation file (e.g., an .apk file) is not an official store, a relatively high level of RP policy may be required for the application. The electronic device may determine whether the source of the application's installation file is an official store based on information associated with the application. If the information indicating the source of the installation file does not correspond to an official store, the electronic device may apply a relatively high level of RP policy to the application. For example, the electronic device may determine the most recent version corresponding to the application or a version that is one step older than the most recent version as the RP version corresponding to the application. If the information indicating the source of the installation file corresponds to an official store, the electronic device may apply a relatively low level of RP policy to the application. By applying an aggressive RP policy to an application whose installation file is provided from a source other than an official store, the electronic device can enhance the security of the application.

[0113] In one embodiment, if the ratio of the time corresponding to the time that an application runs in the background is relatively high, a relatively high level of RP policy may be required to be applied to the application. The electronic device may determine the background operation time relative to the total execution time of the application based on the execution time of the application. The electronic device may determine the foreground operation time relative to the total execution time of the application. If the ratio of the background operation time corresponding to the application is relatively high, the electronic device may apply a relatively high level of RP policy to the application. For example, the electronic device may determine the most recent version corresponding to the application or a version that is one step older than the most recent version as the RP version corresponding to the application. If the ratio of the background operation time corresponding to the application is relatively low, the electronic device may apply a relatively low level of RP policy to the application. By applying an active RP policy to an application with a relatively high ratio of background operation, the electronic device can improve the security of the application.

[0114] In one embodiment, battery usage by an application may be related to the impact on the usability of the application due to the application's application's application of a RP policy. For example, if the application's operation consumes relatively high current, the impact on the application's usability may be relatively greater due to the application's enhanced security. If the application's battery usage is relatively high, the application's usability may be relatively reduced by applying a high-level RP policy to the application. The electronic device may determine the application's battery usage based on the application's execution history and / or battery usage history. The electronic device may apply a relatively low-level RP policy to an application with relatively high battery usage. For example, the electronic device may determine an RP version that is three steps older than the most recent version corresponding to the application as the application's corresponding RP version. The electronic device may not apply an RP policy to the application. If the application's battery usage is relatively low, the electronic device may apply a relatively high-level RP policy to the application. An electronic device can, for example, determine the RP version corresponding to an application as the most recent version corresponding to the application or a version one step older than the most recent version. By applying a conservative RP policy to applications with relatively low battery consumption, the electronic device can improve the usability of the application.

[0115] In one embodiment, the electronic device can determine the level of the RP policy based on both the battery usage of the application and the background operation ratio of the application. For example, the electronic device can determine the level of the RP policy based on the background operation ratio as a priority. By applying a relatively high level of RP policy to an application with high battery usage and a high background operation ratio, the electronic device can improve the security of the application.

[0116] According to one embodiment, in operation 503, the electronic device may scale a score corresponding to each of the plurality of applications. In one embodiment, the electronic device may perform a scaling operation to normalize the score corresponding to each of the plurality of applications calculated in operation 501. Based on the scaled score, the electronic device may associate each of the plurality of applications with one of the plurality of levels.

[0117] Equation 2 is an example of a method for scaling the score corresponding to an application.

[0118]

[0119] The above mathematical equation (2) is merely an example to aid understanding, and embodiments of the present disclosure may not be limited thereto. For example, the above mathematical equation (1) may be modified, applied, or expanded in various ways.

[0120] score max , may include the maximum score among scores corresponding to multiple applications. score min E may include the minimum score among scores corresponding to multiple applications. max can contain the maximum expected value. E min may contain the minimum expected value.

[0121] In one embodiment, w signature The value of can be set to 10. w dangerous The value of can be set to 5. w preload The value of can be set to 5. Level update can be set to any natural number between 1 and 5. E max The value can be set to 10. E min The value can be set to 1. The parameter values ​​are not limited to the examples described above.

[0122] Table 4 shows examples of parameter values ​​for calculating scores and score values ​​corresponding to applications.

[0123] PKGN signature N dangerous b preload Level update scorePKG#1606113.79PKG#2289041.708PKG#394112.74PKG#429037159.74

[0124] Referring to Table 4, N signature and N dangerous It is explained that can have a significant impact on the increase of the score value corresponding to the application. For example, the score corresponding to PKG#4 is 9.74, and N signature and N dangerousThe scores of applications having all high values ​​may be calculated to be relatively higher than the scores of other applications. According to one embodiment, in operation 505, the electronic device may update at least one of the levels or RP versions corresponding to each of the plurality of applications based on the scaled scores. The electronic device may update at least one of the scores, levels, or RP versions corresponding to applications included in the history table of Table 1 and / or the integrated information table of Table 2. The electronic device may determine an RP policy corresponding to the plurality of applications based on checking at least one of the levels or RP versions corresponding to each of the plurality of applications. The electronic device may calculate scores based on a set cycle, perform scaling, and update at least one RP policy (or RP table) based on the scaled scores. The update of the RP policy may be triggered by the installation of an application, the deletion of an application, or a sudden change in the score distribution. The update cycle of the RP policy may correspond to a time interval including daily, weekly, or monthly. An electronic device can restrict an ecosystem associated with an RP policy to within the electronic device based on calculating a score corresponding to each application included in the electronic device. The electronic device can improve the usability of the electronic device by applying an RP policy based on the usage pattern of the electronic device (or an application included in the electronic device). The risk of attack can be prevented by periodic updates of the RP policy. The electronic device can proactively reduce the risk of an attack attempting to downgrade an application to a vulnerable version by determining different RP policies corresponding to the application. FIG. 6 is a graph showing a scaled score confirmed by an electronic device according to one embodiment.

[0125] In one embodiment, referring to FIG. 6, a scaled score may correspond to any one of a plurality of levels based on the magnitude of the numerical value. The numerical values ​​on the Y-axis displayed on the distribution diagram of FIG. 6 may represent scaled scores corresponding to a plurality of applications included in the electronic device. The numerical values ​​on the X-axis displayed on the distribution diagram of FIG. 6 may represent the number of applications having the same scaled score among the plurality of applications included in the electronic device. The level corresponding to an application may have, for example, five values. Referring to FIG. 6, it is described that most of the applications included in the electronic device correspond to level 1 (610) or level 2 (620). The number of applications of level 3 (630), level 4 (640), or level 5 (650) may be relatively small. A scaled score of 1 or more and less than 2 may correspond to level 1 (610), for example. The electronic device may not apply an RP policy to an application of level 1 (610). A scaled score greater than or equal to 2 and less than 3 may correspond to, for example, level 2 (620). The electronic device may apply a relatively low-level RP policy by setting the RP version to a version (or apk version) that is three steps older than the most recent version for an application at level 2 (620). A scaled score greater than or equal to 3 and less than 5 may correspond to, for example, level 3 (630). The electronic device may set the RP version to a version that is two steps older than the most recent version for an application at level 3 (630). A scaled score greater than or equal to 5 may correspond to, for example, level 4 (640). The electronic device may apply a relatively high-level RP policy by setting the RP version to a version that is one step older than the most recent version for an application at level 4 (640). A scaled score greater than or equal to 7 may correspond to, for example, level 5 (650).An electronic device can apply a relatively high level of RP policy by setting the current version to the RP version for applications of level 5 (650).

[0126] FIG. 7 is a flowchart illustrating an operation of an electronic device according to one embodiment to change an RP policy based on a scaled score.

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

[0128] According to one embodiment, in operation 701, an electronic device (e.g., electronic device (101) or processor (120) of FIG. 1 or FIG. 2) may determine a scaled score corresponding to each of a plurality of applications.

[0129] According to one embodiment, in operation 703, the electronic device may determine whether a change in at least one weight is required. The electronic device may determine whether a change in at least one weight is required based on a scaled score corresponding to each of the plurality of applications. The at least one weight may include a numerical value for determining a score corresponding to each of the plurality of applications. The electronic device may calculate a score corresponding to the application based on the at least one weight. For example, the electronic device may determine that an adjustment of the weight is required if a distribution of the scaled scores is excessively biased, such that a set percentage or more of applications correspond to a single level. The electronic device may determine that a change in the weight is not required if the distribution of the scaled scores is relatively wide. Based on determining that a change in at least one weight is not required (operation 703-No), the electronic device may maintain an RP policy corresponding to each of the plurality of applications in operation 711. The electronic device may maintain a level and / or RP version corresponding to the application.

[0130] According to one embodiment, in operation 705, the electronic device may change at least one weight. Based on determining that a change in at least one weight is required (operation 703 - Yes), the electronic device may change the at least one weight. The electronic device may adjust the size of at least one weight so that the distribution of applications is relatively wide.

[0131] According to one embodiment, in operation 707, the electronic device may determine a score corresponding to each of the plurality of applications based on at least one changed weight. The electronic device may scale the score corresponding to each of the plurality of applications.

[0132] According to one embodiment, in operation 709, the electronic device may change the RP policy corresponding to each of the plurality of applications based on the scaled score. The electronic device may change the RP policy corresponding to each of the plurality of applications based on the scaled score corresponding to each of the plurality of applications. By changing the RP policy based on the weight adjustment, the electronic device may determine an RP policy that better suits the usage pattern of the electronic device.

[0133] FIGS. 8A, 8B, and 8C are flowcharts illustrating an operation of an electronic device according to one embodiment to change an RP policy based on a scaled score.

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

[0135] In one embodiment, referring to FIG. 8A, at operation 801, a package manager (320) (e.g., the package manager (320) of FIG. 3 ) may confirm an installation attempt of a first application. For example, the electronic device may confirm an installation attempt of the first application based on user input.

[0136] In one embodiment, at operation 803, the package manager (320) may request the RP manager (330) (e.g., the RP manager (330) of FIG. 3) to verify the RP version for the first application.

[0137] In one embodiment, at operation 805, the RP manager (330) may request the history manager (360) (e.g., the history manager (360) of FIG. 3) to verify the installation history for the first application. The RP manager (330) may transfer data between the package manager (320) and the remaining modules.

[0138] In one embodiment, based on the confirmation that an installation history for the first application is stored, in operation 807, the history manager (360) may return an RP version corresponding to the first application to the RP manager (330). The history manager (360) may check whether an installation history corresponding to the first application remains in the memory of the electronic device.

[0139] In one embodiment, at operation 809, the RP manager (330) may compare the version of the first application with the RP version. The RP manager (330) may compare the version of the first application for which installation is requested with the RP version corresponding to the first application. In one embodiment, based on determining that no installation record for the first application is stored, at operation 811, the history manager (360) may return to the RP manager (330) that there is no RP version corresponding to the first application. The RP manager (330) may determine that no RP version is stored in the electronic device if the history table corresponding to the first application is entirely blank.

[0140] In one embodiment, at operation 813, the RP manager (330) may return a message to the package manager (320) indicating that there is no problem with the installation of the first application. In one embodiment, at operation 815, the package manager (320) may output a successful installation.

[0141] In one embodiment, referring to FIG. 8B, the RP manager (330) may request a score operator (340) (e.g., the score operator (340) of FIG. 3) to calculate a score for a first application. The RP manager (330) may request the score operator (340) to recalculate the score, for example, based on a change in the score distribution due to a newly installed application.

[0142] In one embodiment, at operation 819, the score operator (340) may return the score calculation result for the first application to the RP manager (330).

[0143] In one embodiment, at operation 821, the RP manager (330) may request a score update for the first application from the history manager (360).

[0144] In one embodiment, at operation 823, the history manager (360) can check the RP version of the first application and update the RP version if an update of the RP version is required.

[0145] In one embodiment, at operation 825, the history manager (360) may return a notification to the RP manager (330) associated with a change in the RP version. The history manager (360) may determine whether the RP version has changed due to the updated score of the first application. The history manager (360) may return a notification if the RP version corresponding to the application has changed.

[0146] In one embodiment, referring to FIG. 8c, at operation 827, the RP manager (330) may request distribution data of RP policies from the history manager (360).

[0147] In one embodiment, at operation 829, the history manager (360) may return distribution data and history information to the RP manager (330).

[0148] In one embodiment, at operation 831, the RP manager (330) may request a weight evaluator (350) (e.g., the weight evaluator (350) of FIG. 3) to recalculate the weights.

[0149] In one embodiment, at operation 833, the weight evaluator (350) may re-evaluate the weights.

[0150] In one embodiment, at operation 835, the weight evaluator (350) may transmit the updated weights to the score operator (340).

[0151] In one embodiment, at operation 837, the score operator (340) may return completion of the weight update to the weight evaluator (350).

[0152] In one embodiment, at operation 839, the weight evaluator (350) may return completion of the weight update to the RP manager (320).

[0153] In one embodiment, at operation 841, the RP manager (320) may request the score operator (340) to calculate a score for each of the packages based on the updated weights.

[0154] In one embodiment, at operation 843, the score operator (340) may return a score for each of the packages to the RP manager (320).

[0155] In one embodiment, at operation 845, the RP manager (320) may request the history manager (360) to update the score for each of the packages.

[0156] In one embodiment, at operation 847, the history manager (360) may check the score distribution for each of the packages and update the RP version.

[0157] In one embodiment, at operation 849, the history manager (360) may return a completion message to the RP manager (330).

[0158] In one embodiment, the electronic device can determine a security level that reflects the characteristics of applications included in the electronic device by adjusting the weights and recalculating the scores when the RP version changes.

[0159] FIG. 9 is a flowchart illustrating an operation of an electronic device updating an RP policy according to one embodiment.

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

[0161] According to one embodiment, in operation 901, an electronic device (e.g., electronic device (101) or processor (120) of FIG. 1 or 2) may receive a request for updating an RP policy corresponding to a second application from a server. The electronic device may receive a request associated with direct enforcement of an RP policy from the server. The electronic device may receive the request for updating an RP policy from a cloud server, for example, based on establishing a communication connection with a short-range wireless communication network. The event of a request associated with a direct RP policy received from the server is not limited to the examples described above.

[0162] According to one embodiment, in operation 903, the electronic device can check whether a second RP policy is stored. The electronic device can check whether a second RP policy corresponding to the second application is stored in a memory (e.g., memory (130) of FIG. 1 or 2). Based on confirmation that the second RP policy is not stored (operation 903-No), the electronic device can determine the version included in the update request of the RP policy as the RP version in operation 909. Based on confirmation that the level and / or RP version corresponding to the second application is not set, the electronic device can determine whether to install the second application by using the direct RP policy received from the server.

[0163] According to one embodiment, at operation 905, the electronic device can determine whether the value corresponding to the RP version included in the update request exceeds the value corresponding to the RP version included in the second RP policy. Based on determining that the second RP policy is stored in the memory (operation 903 - Yes), the electronic device can determine whether the value corresponding to the RP version included in the update request exceeds the value corresponding to the RP version included in the second RP policy. Based on determining that the value corresponding to the RP version included in the update request is less than or equal to the value corresponding to the RP version included in the second RP policy (operation 905 - No), the electronic device can maintain the RP policy at operation 911.

[0164] According to one embodiment, in operation 907, the electronic device may update the second RP policy with a value corresponding to the RP version included in the update request. Based on a determination (operation 905 - Yes) that the value corresponding to the RP version included in the update request exceeds the value corresponding to the RP version included in the second RP policy, the electronic device may update the second RP policy with a value corresponding to the RP version included in the update request. The electronic device may apply a stronger RP policy (or a higher level RP policy) among the received RP policy and the RP policy determined by the electronic device. If the RP version determined by the electronic device is higher than the direct RP version, the electronic device may store the direct RP version and determine whether to install the application using the RP version determined by the electronic device. If the RP version determined by the electronic device is lower than the direct RP version, the electronic device may deactivate the RP version determined by the electronic device and determine whether to install the application based on the direct RP version. The electronic device may immediately respond to an attack on the application based on a method for assigning a direct RP policy.

[0165] FIG. 10A and FIG. 10B are flowcharts illustrating an operation of an electronic device updating an RP policy according to one embodiment.

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

[0167] In one embodiment, at operation 1001, an RP manager (330) (e.g., RP manager (330) of FIG. 3) may receive a request for direct RP version enforcement for a package from a cloud server (1010) (e.g., server (108) of FIG. 1).

[0168] In one embodiment, at operation 1003, the RP manager (330) may request confirmation of the RP version of the second application from the history manager (360) (e.g., the history manager (360) of FIG. 3).

[0169] In one embodiment, based on determining that the RP version of the second application is stored, at operation 1005, the history manager (360) may return to the RP manager (330) that there is no RP version.

[0170] In one embodiment, at operation 1007, the RP manager (330) may request the history manager (360) to enforce an RP policy.

[0171] In one embodiment, at operation 1009, the history manager (360) may store the RP version.

[0172] In one embodiment, at operation 1011, the history manager (360) may return a completion message to the RP manager (330).

[0173] In one embodiment, based on determining that the RP version of the second application is stored, at operation 1013, the history manager (360) may return the RP version corresponding to the second application to the RP manager (330).

[0174] In one embodiment, based on the direct RP version included in the request received from the cloud server (1010) being higher than the stored RP version, in operation 1015, the RP manager (330) may request the history manager (360) to apply the strong RP version.

[0175] In one embodiment, at operation 1017, the history manager (360) may return an application completion response to the RP manager (330).

[0176] In one embodiment, based on the direct RP version included in the request received from the cloud server (1010) being not higher than the stored RP version, in operation 1019, the RP manager (330) may request the history manager (360) to apply a strong RP version history.

[0177] In one embodiment, at operation 1021, the history manager (360) may return a response to the RP manager (330) indicating that the RP version has been maintained and the history has been saved.

[0178] FIG. 11 is a flowchart illustrating an operation of an electronic device according to one embodiment to restrict installation of an application that does not satisfy a condition.

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

[0180] In one embodiment, at operation 1101, the package manager (320) (e.g., the package manager (320) of FIG. 3) may confirm an attempt to install a second application.

[0181] In one embodiment, at operation 1103, the package manager (320) may request the RP manager (330) (e.g., the RP manager (330) of FIG. 3) to verify the RP version for the second application.

[0182] In one embodiment, at operation 1105, the RP manager (330) may request the history manager (360) (e.g., the history manager (360) of FIG. 3) to verify the installation history for the second application.

[0183] In one embodiment, at operation 1107, the history manager (360) may return an RP version corresponding to the second application to the RP manager (330). The RP version corresponding to the second application may be a direct RP version assigned from the server. The RP version corresponding to the second application may also be an RP version calculated by the electronic device. The RP version corresponding to the second application may be a larger value between the RP version calculated by the electronic device and the direct RP version.

[0184] In one embodiment, at operation 1109, the RP manager (330) may compare the version of the second application with the RP version.

[0185] In one embodiment, at operation 1111, the RP manager (330) may request the package manager (320) to block the installation.

[0186] In one embodiment, at operation 1113, the package manager (320) may output an installation block.

[0187] FIG. 12 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to output a message in response to a deletion request from an application.

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

[0189] According to one embodiment, in operation 1201, an electronic device (e.g., electronic device (101) or processor (120) of FIG. 1 or 2) may confirm a request associated with the deletion of a third application. The third application may include an application provided by a manufacturer of the electronic device (or a preloaded application).

[0190] According to one embodiment, in operation 1203, the electronic device may check a third RP policy corresponding to a third application.

[0191] In one embodiment, at operation 1205, the electronic device may determine whether the value corresponding to the initial version of the third application is less than the value corresponding to the RP version included in the third RP policy. In one embodiment, the deletion of the preloaded application may include a method of restoring the initial version of the application included in the binary.

[0192] The electronic device may disable the history table corresponding to the third application based on a determination that the value corresponding to the initial version of the third application is greater than or equal to the value corresponding to the RP version included in the third RP policy (operation 1205-No). According to one embodiment, in operation 1207, the electronic device may output a response associated with the warning. The electronic device may output a response associated with the warning based on a determination that the value corresponding to the initial version of the third application is less than the value corresponding to the RP version included in the third RP policy (operation 1205-Yes). The electronic device may output a guidance message if the initial version of the application corresponds to a version lower than the RP version. In one embodiment, the operation of outputting the response associated with the warning may be replaced with an operation of outputting a guidance message associated with the inability to delete. In one embodiment, the electronic device may not provide an option to delete the preloaded application.

[0193] In one embodiment, the electronic device can retain the installation history corresponding to the application even after the preloaded application is deleted. The electronic device can deactivate the RP policy corresponding to the deleted application. The electronic device can recalculate the scores for the remaining applications other than the deleted application and set up the RP table. Even if the user application is deleted or deactivated, the electronic device can block installation attempts of applications with a lower RP version than the corresponding RP version of the previously installed user application.

[0194] FIGS. 13A and 13B are flowcharts illustrating an operation of an electronic device according to one embodiment of the present invention to update an RP version corresponding to each of a plurality of applications in response to a request for deletion of the application.

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

[0196] In one embodiment, at operation 1301, the package manager (320) (e.g., the package manager (320) of FIG. 3) may confirm a deletion request of a third application (PKG3).

[0197] In one embodiment, at operation 1303, the package manager (320) may check whether the third application corresponds to a preloaded application.

[0198] In one embodiment, based on determining that the third application corresponds to the preload application, at operation 1305, the package manager (320) may compare the initial version of the third application with the RP version.

[0199] In one embodiment, based on determining that the RP version is higher than the initial version of the third application, at operation 1307, the package manager (320) may output a warning pop-up.

[0200] In one embodiment, at operation 1309, the package manager (320) may confirm a deletion request from a third application.

[0201] In one embodiment, at operation 1311, the package manager (320) may notify the RP manager (330) (e.g., the RP manager (330) of FIG. 3) that the third application is a target for deletion.

[0202] In one embodiment, at operation 1313, the RP manager (330) may request the history manager (360) (e.g., the history manager (360) of FIG. 3) to deactivate a table corresponding to a third application.

[0203] In one embodiment, at operation 1315, the history manager (360) may return a response associated with the completion of the deactivation to the RP manager (330).

[0204] In one embodiment, at operation 1317, the RP manager (330) may request a score operator (340) (e.g., the score operator (340) of FIG. 3) to compute a score for each of the packages.

[0205] In one embodiment, at operation 1319, the score operator (340) may return a score for each of the packages.

[0206] In one embodiment, at operation 1321, the RP manager (330) may request the history manager (360) to update a score for each of the packages.

[0207] In one embodiment, at operation 1323, the history manager (360) may check the score distribution for each of the packages and update the RP version.

[0208] In one embodiment, at operation 1325, the history manager (360) may return a completion message to the RP manager (330).

[0209] In one embodiment, at operation 1327, the RP manager (330) may return a message to the package manager (320) indicating that there is no abnormality in the operation in response to the deletion request of the third application.

[0210] In one embodiment, at operation 1329, the package manager (320) may output completion of deletion of the third application.

[0211] FIG. 14 is a flowchart illustrating an operation of an electronic device according to one embodiment to check a value corresponding to a version of an application based on checking the version system of the application.

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

[0213] According to one embodiment, in operation 1401, an electronic device (e.g., electronic device (101) or processor (120) of FIG. 1 or 2) may check a version scheme corresponding to a first application. The electronic device may check the version scheme corresponding to the first application as at least a part of an operation of checking whether a value corresponding to version information included in a request is greater than or equal to a value corresponding to version information included in a first RP policy. In one embodiment, the version scheme corresponding to the application may correspond to one of a plurality of types. The version name may be, for example, " <major> . <minor> . <patch> [. <revision>]" can be set based on the rules of the version system. The version system may differ depending on the type of electronic device, the region in which the electronic device operates, or the resolution supported by the electronic device.

[0214] Table 5 is an example of how to check the pattern of the version code corresponding to the version type and the numerical value for comparison operation.

[0215] TypeVersionCodeNumber01.5.1315130317021.5.13.4515134517031.5.13.14515130314551.5.13.14235151314235

[0216] Referring to Table 5, it is explained that a numerical value for comparison operation can be determined from the version code according to the version type. In one embodiment, "151303170" corresponding to Type 0, "151345170" corresponding to Type 2, "151303145" corresponding to Type 3, and "151314235" corresponding to Type 5 do not indicate whether the application is the latest version and may include numerical values ​​that may vary depending on the distribution region, resolution, and model. An electronic device can determine a meaningful numerical value for determining whether an application is the latest version from the table in Table 5. For example, in the version system of Type 0, the electronic device can determine "1513" corresponding to the version code of "1.5.13" from the numerical value of "151303170" as a meaningful numerical value corresponding to Type 0. In the version system of Type 2, the electronic device can identify "151345" corresponding to the version code of "1.5.13.45" from the numerical value "151345170" as a significant numerical value corresponding to Type 2. In the version system of Type 3, the electronic device can identify "1513145" corresponding to the version code of "1.5.13.145" from the numerical value "151303145" as a significant numerical value corresponding to Type 3. In the version system of Type 5, the electronic device can identify "151314235" corresponding to the version code of "1.5.13.14235" from the numerical value "151314235" as a significant numerical value corresponding to Type 5. In one embodiment, the electronic device can identify the latest version of an application based on identifying a significant numerical value corresponding to an application in the same version system. For example, in a Type 3 versioning scheme, an electronic device can compare version 151305143 with version 151303147. When comparing simple numbers, the electronic device can determine that 151305143 is the larger number.The electronic device can identify 1513143 as a numerical value corresponding to the version of 151305143 based on a pattern corresponding to the version system of Type 3. The electronic device can identify 1513147 as a numerical value corresponding to the version of 151303147 based on the version system of Type 3. The electronic device can identify that the version of 151305143 is a lower version than the version of 151303147 in the version system of Type 3. The electronic device can identify that the application of version 151303147 is a relatively recently distributed application. According to one embodiment, in operation 1403, the electronic device can identify a value corresponding to the version information included in the request and a value corresponding to the version information included in the first RP policy. The electronic device can, at least as part of an operation of determining whether a value corresponding to the version information included in the request is greater than or equal to a value corresponding to the version information included in the first RP policy, verify the value corresponding to the version information included in the request and the value corresponding to the version information included in the first RP policy based on a version scheme corresponding to the first application.

[0217] FIG. 15 is a flowchart illustrating an operation of an electronic device according to one embodiment of the present invention to determine whether to install an application based on checking the version system of the application.

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

[0219] In one embodiment, at operation 1501, a package manager (320) (e.g., package manager (320) of FIG. 3) may verify an APK installation attempt.

[0220] In one embodiment, at operation 1503, the package manager (320) may send an RP policy verification request to the RP manager (330) (e.g., the RP manager (330) of FIG. 3).

[0221] In one embodiment, at operation 1505, the RP manager (330) may send an RP policy request for the package to the history manager (360) (e.g., the history manager (360) of FIG. 3).

[0222] In one embodiment, at operation 1507, the history manager (360) may return the RP policy to the RP manager (330).

[0223] In one embodiment, at operation 1509, the RP manager (330) may check the RP policy.

[0224] In one embodiment, at operation 1511, the RP manager (330) may request the score operator (340) (e.g., the score operator (340) of FIG. 3) to compare the version of the target APK with an RP version corresponding to the RP policy.

[0225] In one embodiment, at operation 1513, the score operator (340) may return a result to the RP manager (330).

[0226] In one embodiment, at operation 1515, the RP manager (330) may return the result to the package manager (320).

[0227] In one embodiment, at operation 1517, the package manager (320) may output an installation failure.

[0228] According to one embodiment, an electronic device (e.g., the electronic device (101) of FIG. 1 or 2) may include a memory (e.g., the memory (130) of FIG. 1 or 2) storing instructions and a processor (e.g., the processor (120) of FIG. 1 or 2) operatively connected to the memory (130). The instructions, when executed by the processor (120), may cause the electronic device (101) to at least verify a request associated with installation of a first application. The instructions, when executed by the processor (120), may cause the electronic device (101) to at least verify whether information associated with a history of the first application is stored in the memory (130). The instructions, when executed by the processor (120), may cause the electronic device (101) to verify a first RP policy corresponding to the first application, at least based on confirming that information associated with a history of the first application is stored in the memory (130). The instructions, when executed by the processor (120), may cause the electronic device (101) to verify whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy. The instructions, when executed by the processor (120), may cause the electronic device (101) to output a response associated with a rejection of installation of the first application, at least based on confirming that a value corresponding to version information included in the request is less than a value corresponding to version information included in the first RP policy.

[0229] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to determine a score corresponding to each of the plurality of applications based at least on information stored in the memory (130) associated with the plurality of applications. The instructions, when executed by the processor (120), may cause the electronic device (101) to scale at least the score corresponding to each of the plurality of applications. The instructions, when executed by the processor (120), may cause the electronic device (101) to update at least one of a level or RP version corresponding to each of the plurality of applications based at least on the scaled score corresponding to each of the plurality of applications.

[0230] In one embodiment, the level may include an index indicating the security level required for the application. The RP version may include version information for determining whether to install the requested application.

[0231] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to update information associated with a history of the first application, at least based on determining that a history associated with installation of the first application is not stored in the memory (130). The instructions, when executed by the processor (120), may cause the electronic device (101) to install the first application at least.

[0232] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to update information associated with the history of the first application based on at least verifying that a value corresponding to the version information included in the request is greater than or equal to a value corresponding to the version information included in the first RP policy. The instructions, when executed by the processor (120), may cause the electronic device (101) to at least install the first application.

[0233] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to, at least as part of an operation of updating information associated with a history of the first application, check a score corresponding to the first application. The instructions, when executed by the processor (120), may cause the electronic device (101) to, at least as part of an operation of updating information associated with a history of the first application, scale a score corresponding to each of a plurality of applications including the first application. The instructions, when executed by the processor (120), may cause the electronic device (101) to, at least as part of an operation of updating information associated with a history of the first application, check at least one of a level or RP version corresponding to the first application based on the scaled score corresponding to each of the plurality of applications. The instructions, when executed by the processor (120), may cause the electronic device (101) to change a first RP policy corresponding to the first application based on at least one of a level or RP version corresponding to the identified first application, at least as part of an operation of updating information associated with a history of the first application.

[0234] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to determine whether a change in at least one weight is required for determining a score corresponding to each of the plurality of applications, based on at least the scaled score corresponding to each of the plurality of applications. The instructions, when executed by the processor (120), may cause the electronic device (101) to change at least one weight based on determining that a change in at least one weight is required. The instructions, when executed by the processor (120), may cause the electronic device (101) to determine a score corresponding to each of the plurality of applications, based on at least the changed at least one weight. The instructions, when executed by the processor (120), may cause the electronic device (101) to scale at least a score corresponding to each of the plurality of applications. The instructions, when executed by the processor (120), may cause the electronic device (101) to change an RP policy corresponding to each of the plurality of applications based on at least the scaled score corresponding to each of the plurality of applications.

[0235] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to receive at least a request for an update of an RP policy corresponding to a second application from a server. The instructions, when executed by the processor (120), may cause the electronic device (101) to at least determine whether a second RP policy corresponding to the second application is stored in the memory (130). The instructions, when executed by the processor (120), may cause the electronic device (101) to determine, based on at least determining that the second RP policy is stored in the memory (130), whether a value corresponding to an RP version included in the update request exceeds a value corresponding to an RP version included in the second RP policy. The instructions, when executed by the processor (120), may cause the electronic device (101) to update the second RP policy with a value corresponding to the RP version included in the update request, based on at least verifying that the value corresponding to the RP version included in the update request exceeds the value corresponding to the RP version included in the second RP policy.

[0236] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to at least verify a request associated with the deletion of a third application. The third application may include an application provided by a manufacturer of the electronic device (101). The instructions, when executed by the processor (120), may cause the electronic device (101) to at least verify a third RP policy corresponding to the third application. The instructions, when executed by the processor (120), may cause the electronic device (101) to at least verify whether a value corresponding to an initial version of the third application is less than a value corresponding to an RP version included in the third RP policy. The above instructions, when executed by the processor (120), may cause the electronic device (101) to output a response associated with a warning based on at least verifying that a value corresponding to an initial version of the third application is less than a value corresponding to an RP version included in the third RP policy.

[0237] According to one embodiment, the instructions, when executed by the processor (120), may cause the electronic device (101) to check a version scheme corresponding to the first application, at least as part of an operation of checking whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy. The instructions, when executed by the processor (120), may cause the electronic device (101) to check, based on the version scheme corresponding to the first application, a value corresponding to version information included in the request and a value corresponding to version information included in the first RP policy, at least as part of an operation of checking whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy.

[0238] According to one embodiment, a method of operating an electronic device (101) may include an operation of confirming a request associated with installation of a first application. The method may include an operation of confirming whether information associated with a history of the first application is stored in a memory (130) of the electronic device (101). The method may include an operation of confirming a first RP policy corresponding to the first application based on confirmation that information associated with the history of the first application is stored in the memory (130). The method may include an operation of confirming whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy. The method may include an operation of outputting a response associated with rejection of installation of the first application based on confirmation that the value corresponding to version information included in the request is less than a value corresponding to version information included in the first RP policy.

[0239] According to one embodiment, the method may further include an operation of checking a score corresponding to each of the plurality of applications based on information stored in the memory (130) associated with the plurality of applications. The method may further include an operation of scaling the score corresponding to each of the plurality of applications. The method may further include an operation of updating at least one of a level or RP version corresponding to each of the plurality of applications based on the scaled score corresponding to each of the plurality of applications.

[0240] In one embodiment, the level may include an index indicating the security level required for the application. The RP version may include version information for determining whether to install the requested application.

[0241] In one embodiment, the method may further include an operation of updating information associated with the history of the first application based on determining that the history associated with the installation of the first application is not stored in the memory (130). The method may further include an operation of installing the first application.

[0242] In one embodiment, the method may further include an operation of updating information associated with the history of the first application based on verifying that the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the version information included in the first RP policy. The method may further include an operation of installing the first application.

[0243] According to one embodiment, the operation of updating information associated with the history of the first application may include an operation of checking a score corresponding to the first application. The operation of updating information associated with the history of the first application may include an operation of scaling a score corresponding to each of a plurality of applications including the first application. The operation of updating information associated with the history of the first application may include an operation of checking at least one of a level or an RP version corresponding to the first application based on the scaled score corresponding to each of the plurality of applications. The operation of updating information associated with the history of the first application may include an operation of changing a first RP policy corresponding to the first application based on at least one of the level or the RP version corresponding to the checked first application.

[0244] According to one embodiment, the method may further include an operation of determining whether a change in at least one weight for determining a score corresponding to each of the plurality of applications is required based on the scaled score corresponding to each of the plurality of applications. The method may further include an operation of changing the at least one weight based on determining that a change in the at least one weight is required. The method may further include an operation of determining a score corresponding to each of the plurality of applications based on the changed at least one weight. The method may further include an operation of scaling the score corresponding to each of the plurality of applications. The method may further include an operation of changing an RP policy corresponding to each of the plurality of applications based on the scaled score corresponding to each of the plurality of applications.

[0245] According to one embodiment, the method may further include an operation of receiving an update request of an RP policy corresponding to a second application from a server. The method may further include an operation of checking whether a second RP policy corresponding to the second application is stored in the memory (130). The method may further include an operation of checking, based on checking that the second RP policy is stored in the memory (130), whether a value corresponding to an RP version included in the update request exceeds a value corresponding to an RP version included in the second RP policy. The method may further include an operation of updating the second RP policy to a value corresponding to an RP version included in the update request, based on checking that the value corresponding to the RP version included in the update request exceeds a value corresponding to the RP version included in the second RP policy.

[0246] According to one embodiment, the method may further include an operation of verifying a request associated with the deletion of a third application. The third application may include an application provided by a manufacturer of the electronic device (101). The method may further include an operation of verifying a third RP policy corresponding to the third application. The method may further include an operation of verifying whether a value corresponding to an initial version of the third application is less than a value corresponding to an RP version included in the third RP policy. The method may further include an operation of outputting a response associated with a warning based on verifying that the value corresponding to the initial version of the third application is less than a value corresponding to an RP version included in the third RP policy.

[0247] According to one embodiment, the operation of checking whether the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the version information included in the first RP policy may include checking a version system corresponding to the first application. The operation of checking whether the value corresponding to the version information included in the request is greater than or equal to the value corresponding to the version information included in the first RP policy may include checking, based on the version system corresponding to the first application, a value corresponding to the version information included in the request and a value corresponding to the version information included in the first RP policy.

[0248] According to one embodiment, a storage medium storing instructions may cause the instructions, when executed by a processor of an electronic device, to cause the electronic device to perform operations. The operations may include an operation of confirming a request associated with installation of a first application. The operations may include an operation of confirming whether information associated with a history of the first application is stored in a memory (130) of the electronic device (101). The operations may include an operation of confirming a first RP policy corresponding to the first application based on confirming that information associated with a history of the first application is stored in the memory (130). The operations may include an operation of confirming whether a value corresponding to version information included in the request is greater than or equal to a value corresponding to version information included in the first RP policy. The operations may include an operation of outputting a response associated with a rejection of installation of the first application based on confirming that the value corresponding to the version information included in the request is less than a value corresponding to version information included in the first RP policy.

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

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

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

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

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

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

Claims

1. In an electronic device (101), Memory (130) for storing instructions; and It includes a processor (120) operatively connected to the above memory (130), The above instructions, when executed by the processor (120), cause the electronic device (101) to at least: Verify the requests associated with the installation of the first application, Check whether information related to the history of the first application is stored in the memory (130), Based on the confirmation that information related to the history of the first application is stored in the memory (130), the first RP policy corresponding to the first application is confirmed, Check whether the value corresponding to the version information included in the above request is greater than or equal to the value corresponding to the version information included in the above first RP policy, An electronic device (101) that causes a response associated with rejection of installation of the first application to be output based on determining that the value corresponding to the version information included in the request is less than the value corresponding to the version information included in the first RP policy.

2. In paragraph 1, The above instructions, when executed by the processor (120), cause the electronic device (101) to at least: Based on the information stored in the memory (130) associated with multiple applications, a score corresponding to each of the multiple applications is checked, Scaling the scores corresponding to each of the above multiple applications, An electronic device (101) that causes at least one of a level or RP version corresponding to each of the plurality of applications to be updated based on the scaled score corresponding to each of the plurality of applications.

3. In paragraph 1 or 2, The above level contains an index indicating the level of security required for the application, The above RP version is an electronic device (101) that includes version information for determining whether to install the application for which installation is requested.

4. In any one of paragraphs 1 to 3, The above instructions, when executed by the processor (120), cause the electronic device (101) to at least: Based on the confirmation that the history associated with the installation of the first application is not stored in the memory (130), the information associated with the history of the first application is updated, An electronic device (101) causing the installation of the first application.

5. In any one of paragraphs 1 to 4, The above instructions, when executed by the processor (120), cause the electronic device (101) to at least: Based on verifying that the value corresponding to the version information included in the above request is greater than or equal to the value corresponding to the version information included in the above first RP policy, the information associated with the history of the first application is updated, An electronic device (101) causing the installation of the first application.

6. In any one of paragraphs 1 to 5, The above instructions, when executed by the processor (120), cause the electronic device (101) to update information associated with the history of the first application, at least as part of: Check the score corresponding to the first application above, Scaling the score corresponding to each of a plurality of applications including the first application, Based on the scaled score corresponding to each of the plurality of applications, at least one of the level or RP version corresponding to the first application is identified, An electronic device (101) that causes a first RP policy corresponding to the first application to be changed based on at least one of a level or RP version corresponding to the first application identified above.

7. In any one of paragraphs 1 to 6, The above instructions, when executed by the processor (120), cause the electronic device (101) to at least: Based on the scaled score corresponding to each of the plurality of applications, it is determined whether a change in at least one weight is required to confirm the score corresponding to each of the plurality of applications, Based on determining that a change of at least one of the above weights is required, changing the at least one weight, Based on at least one of the changed weights, a score corresponding to each of the plurality of applications is determined, Scaling the scores corresponding to each of the above multiple applications, An electronic device (101) that causes an RP policy corresponding to each of the plurality of applications to be changed based on the scaled score corresponding to each of the plurality of applications.

8. In any one of paragraphs 1 to 7, The above instructions, when executed by the processor (120), cause the electronic device (101) to at least: Receive a request for an update of the RP policy corresponding to the second application from the server, Check whether the second RP policy corresponding to the second application is stored in the memory (130), Based on the confirmation that the above second RP policy is stored in the memory (130), it is confirmed whether the value corresponding to the RP version included in the update request exceeds the value corresponding to the RP version included in the second RP policy, An electronic device (101) that causes the second RP policy to be updated to a value corresponding to the RP version included in the update request, based on determining that the value corresponding to the RP version included in the update request exceeds the value corresponding to the RP version included in the second RP policy.

9. In any one of paragraphs 1 to 8, The above instructions, when executed by the processor (120), cause the electronic device (101) to at least: Verify a request associated with the deletion of a third application, wherein the third application comprises an application provided by the manufacturer of the electronic device (101), Check the third RP policy corresponding to the third application above, Check whether the value corresponding to the initial version of the above third application is less than the value corresponding to the RP version included in the above third RP policy, An electronic device (101) that causes a response associated with a warning to be output based on determining that a value corresponding to an initial version of the third application is less than a value corresponding to an RP version included in the third RP policy.

10. In any one of paragraphs 1 to 9, The above instructions, when executed by the processor (120), cause the electronic device (101) to determine whether a value corresponding to the version information included in the request is greater than or equal to a value corresponding to the version information included in the first RP policy, as at least part of the operation of: Check the version system corresponding to the above first application, An electronic device (101) that causes a value corresponding to the version information included in the request and a value corresponding to the version information included in the first RP policy to be verified based on a version system corresponding to the first application.

11. In the operating method of an electronic device (101), Action to verify requests associated with the installation of the first application; An operation of checking whether information associated with the history of the first application is stored in the memory (130) of the electronic device (101); An operation of checking a first RP policy corresponding to the first application based on verifying that information related to the history of the first application is stored in the memory (130); An operation for checking whether a value corresponding to the version information included in the above request is greater than or equal to a value corresponding to the version information included in the first RP policy; and An action of outputting a response associated with rejection of installation of the first application based on verifying that the value corresponding to the version information included in the request is less than the value corresponding to the version information included in the first RP policy; A method comprising:

12. In paragraph 11, An operation of checking a score corresponding to each of the plurality of applications based on information stored in the memory (130) associated with the plurality of applications; An operation of scaling a score corresponding to each of the above multiple applications; and A method further comprising an operation of updating at least one of a level or RP version corresponding to each of the plurality of applications based on the scaled score corresponding to each of the plurality of applications.

13. In clause 11 or 12, The above level contains an index indicating the level of security required for the application, A method wherein the above RP version includes version information for determining whether to install the application for which installation is requested.

14. In any one of paragraphs 11 to 13, An operation of updating information associated with the history of the first application based on verifying that the history associated with the installation of the first application is not stored in the memory (130); and A method further comprising the action of installing the first application.

15. In a storage medium storing instructions, the instructions, when executed by a processor of an electronic device, cause the electronic device to perform operations, the operations being: Action to verify requests associated with the installation of the first application; An operation of checking whether information associated with the history of the first application is stored in the memory (130) of the electronic device (101); An operation of checking a first RP policy corresponding to the first application based on verifying that information related to the history of the first application is stored in the memory (130); An operation for checking whether a value corresponding to the version information included in the above request is greater than or equal to a value corresponding to the version information included in the first RP policy; and A storage medium including an action for outputting a response associated with a rejection of installation of the first application based on verifying that a value corresponding to the version information included in the request is less than a value corresponding to the version information included in the first RP policy.

Images