KR100689116B1 - Daemon for executing the wipi in smartphone - Google Patents

Abstract

A daemon for executing WIPI(Wireless Internet Platform Interoperability) in a smart phone is provided to operate the WIPI on an OS(Operating System) of the smart phone by calling the WIPI if a WIPI operation condition occurs while monitoring the WIPI operation condition in the smart phone. An event dispatcher(41) orders a smart phone kernel(20) to call the WIPI(30) if a WIPI event occurs while monitoring the WIPI event by accessing the smart phone kernel. An agent manager(42) orders the smart phone kernel to call the WIPI if a WIPI based agent execution request or condition is generated while monitoring the WIPI based agent execution request or condition by accessing the smart phone kernel. An alarm manager(43) orders the smart phone kernel to call the WIPI if a WIPI alarm time is approached while monitoring the WIPI alarm time by accessing the smart phone kernel. A WIPI interface(44) transfers data and a message between the smart phone kernel and the WIPI by the event dispatcher, the event manager and the alarm manager.

Description

Daemon For Executing The WIPI In Smartphone

1 is a diagram illustrating an embodiment of a process of mounting a Wi-Fi on a typical smartphone.

Figure 2 is an embodiment configuration for the daemon for driving the epithelium in accordance with the present invention.

3 is a schematic diagram of a Wi-Fi driving service according to the present invention.

* Explanation of symbols on the main parts of the drawing

41: event dispatcher 42: agent manager

43: Alarm Manager 44: Wifi Interface

The present invention relates to a daemon for driving the epithelium in a smartphone, and more specifically, using a daemon to monitor whether the epithelial driving condition is generated in the smartphone, and when the epithelial driving condition occurs, the daemon calls the epiphysis. It relates to a daemon for driving the Wi-Fi in the smartphone, which allows the Wi-Fi to run on the operating system of the smartphone.

Recently, smart phones that combine the functions of a mobile phone and a PDA have been in the spotlight. These smartphones are equipped with a larger memory and a higher performance CPU than conventional mobile phones, and are equipped with an operating system (OS) to support various application execution, voice / data communication, and PC interworking. Smartphone operating systems include the "symbian OS" developed by the British Symbian company and the "WindowsCE OS" developed by the Microsoft company of the United States.

Meanwhile, South Korea has adopted Wireless Internet Platform for Interoperability (WIPI) as the wireless Internet platform standard for mobile phones. Accordingly, each mobile communication company and each terminal manufacturer has installed (porting) portie in the middle of the operating system (eg, REX) layer and the application layer of the mobile phone.

As mentioned earlier, while existing mobile phones have Wipy on top of existing operating systems, such as REX, recently launched smart phones do not have Wipy on them. We are working on developing Wi-Fi on smartphones so that applications (eg, browsers, wireless Internet menus, games, ringtones, videos, document creation programs, etc.) can run smoothly on smartphones.

In order to install Wi-Fi on the smartphone as above, it is necessary to add / change some specifications of Wi-Fi in consideration of the specifications of symbian OS or Windows CE OS and upload Wi-Fi on the operating system of the smartphone. In particular, one of these considerations is how the operating system of a smartphone treats Wi-Fi. The operating system of a smartphone treats Wi-Fi as an application, for example, Windows File Explorer ("Explorer. exe ") and other types of applications, such as the Wiki. This will be described with reference to FIG. 1.

1 is a diagram illustrating an embodiment of a process of mounting a Wi-Fi on a typical smartphone.

As shown at the top of FIG. 1, since the operating system of the smartphone treats Wi-Fi as an application, the specifications of the operating system of the smartphone, for example, APIs, compilers, and executable binary formats provided by the operating system of the smartphone Code the Wi-Fi related application, Wi-Fi library, HAL library, etc. and make it as an executable file ("Wcewipi.exe") through the linker. Then, as shown at the bottom of Figure 1, when installed in the smartphone Wipy ("Wcewipi.exe") in the form of executable files Wipy will run as a single application on the operating system of the smartphone, like the existing Windows file explorer .

As we saw above, in Wi-Fi, Wi-Fi does not work as a platform, but as a single application, which handles Wi-Fi-based applications such as SMS push service, idle screen service, swap browser, and call forwarding. In order to keep your smartphone running, you should always have Wipy enabled.

However, in smartphones, as well as applications based on existing mobile phones, such as Wi-Fi, the functions of PDAs and various services already installed in smart phones must be frequently performed. Etc.) and software (e.g., each service process, etc.) are often occupied, and thus a unique service cannot be performed due to a lack of terminal resources. In other words, if the Wi-Fi is always driven in the smartphone, terminal resources such as memory and processes are wasted by Wi-Fi, and thus there is a problem that the terminal resources for driving other applications are insufficient.

Therefore, in order to prevent terminal resources from being wasted by smartphones in the smartphone, a technology for driving the stomach is only required when the smartphone is needed in consideration of the fact that the smartphone cannot be always driven.

In addition, the existing mobile phone has been developed by the terminal manufacturer to raise the corresponding event when the operating system is related to Wi-Fi, but in the smart phone as described above, there was no consideration of the Wi-Fi by the terminal manufacturer or operating system developer 'S operating system is not posting the event to Wippy.

Therefore, even if the operating system of the smartphone does not inform the Wi-Fi related events, etc., Wi-Fi notifies the Wi-Fi-related events generated in the operating system of the smartphone without applying a load to the smart phone using a specific application, for example, a lightweight process. There is an urgent need for a technology that allows WiPie to handle the event.

The present invention has been proposed in order to solve the above problems and to meet the above requirements, using a daemon to monitor whether the Wi-Fi driving conditions are generated in the smart phone and when the Wi-Fi driving conditions occur, the daemon detects Wi-Fi Its purpose is to provide a daemon for driving the Wi-Fi on a smartphone, by calling the Wi-Fi on the operating system of the smartphone.

In order to achieve the above object, the present invention monitors whether a Wi-Fi driving condition is generated in a smartphone, and when the Wi-Fi driving condition is generated, the daemon is configured to drive the Wi-Fi on an operating system of the smartphone. An event dispatcher for accessing the phone's kernel to monitor whether a Wi-Fi-related event occurs and instructing the smartphone kernel to call a Wi-Fi call when a Wi-Fi-related event occurs; Approaching the kernel of the smartphone to monitor whether the Wi-Fi-based agent execution request is generated and whether the Wi-Fi-based agent execution condition is generated, and when the Wi-Fi-based agent execution request or Wi-Fi-based agent execution condition occurs An agent manager for invoking a call; An alarm manager for accessing the kernel of the smartphone to monitor the Wi-Fi alarm time and instructing the Wi-Fi call to the smartphone kernel when the Wi-Fi alarm time arrives; And a Wi-Fi interface for transferring data and messages between the smartphone kernel and the Wi-Fi by the event dispatcher, the agent manager, and the alarm manager.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings. In the following description of the present invention, detailed descriptions of well-known functions or configurations will be omitted if it is determined that the detailed description of the present invention may unnecessarily obscure the subject matter of the present invention. Terms to be described later are terms defined in consideration of functions in the present invention, and may be changed according to intentions or customs of users or operators. Therefore, the definition should be made based on the contents throughout the specification.

Figure 2 is a configuration diagram for one embodiment of a daemon for driving the epithelium according to the present invention.

In a typical smartphone, various hardware (e.g., mobile communication module, CPU, memory, display, keypad, GPS receiver module, etc.) 10 are mounted at the lowest layer, and the Windows CE OS 20 is mounted at the operating system layer. Various applications that are run based on the WindowsCE OS in the layer, for example, WIPI ("Wcewipi.exe") 30, Windows File Explorer ("Explorer.exe"), and freecell games ("freecell.exe") mentioned in FIG. Etc. are mounted. On the other hand, in the following embodiment of the present invention will be described as an example that the Windows CE OS is mounted as a basic OS of the smartphone, it will be readily understood by those skilled in the art that the present invention is applied to the operating system of other smartphones, such as symbian OS.

The Windows CE OS 20 is a smartphone kernel (“Smartphone Kernel”) that generally performs terminal resource allocation and process control on various hardware and various software mounted on the smartphone, and the user can access the smartphone kernel [ WindowsCE OS] based on a variety of smartphone API ("Smartphone API") provided to the application that is running. Hereinafter, in describing the present invention, since the actual subject of the WindowsCE OS 20 is a smartphone kernel, the same reference numerals as "20" will be given to the WindowsCE OS and the smartphone kernel.

The Wi-Fi 30 is an application in the form of an executable file produced in accordance with the OS specification of the smart phone mentioned in FIG. 1, and the application (eg, browser, wireless Internet menu, LBS service, Wi-Fi API ("WIPI API") provided to idle screen service, mobile payment service, multimedia message service Java-virtual machine, etc., Wi-Fi Core ("WIPI Core"), and Wi-Fi HAL ("Handset adaptation layer") WIPI HAL ").

A feature of the present invention is that when the Wipy driving condition is generated in the WindowsCE OS 20, the Wipy 30 does not always drive the Wipy 30 in an application form on the WindowsCE OS 20. To be driven from above.

To this end, the present invention monitors whether the Wi-Fi driving condition is generated in the WindowsCE OS 20 by using a daemon (aka WIPI On Smartphone Agent) 40 in the form of a background process that takes up a small amount of terminal resources. When the driving condition is generated to call the wickie 30 to drive the wickie 30.

And, in the present invention so that the Wipy-related events, such as generated in the WindowsCE OS 20 can be processed in the Wiffy (30), the daemon (40) Wipy related data, messages, etc. generated by the WindowsCE OS (20) To 30). In addition, in the present invention, so that the Wipy 30 can send specific data, messages, and the like to the smartphone kernel 20, the daemon 40 to the data, messages, etc. generated in the Wipy 30, the smartphone kernel 20 To pass.

As mentioned above, in the present invention, the WiPi 30 is not driven at the time of initializing the WindowsCE OS 20, and only the daemon 40 is started at the time of initializing the WindowsCE OS 20 and is smart until the end of the WindowsCE OS 20. While monitoring the smartphone kernel 20 while using the phone API, when the Wipy driving condition occurs, the Wippy 30 is called.

The daemon 40 of the present invention as described above includes an event dispatcher (“Event Dispatcher”) 41, an agent manager (“Agent Manager”) 42, an alarm manager (“Alarm Manager”) 43, and a Wi-Fi interface ( &Quot; WIPI Interface "

The event dispatcher 41 accesses the smartphone kernel 20 by using the smartphone API to monitor whether a Wi-Fi related event occurs in the smart phone, and when a specific Wi-Fi-related event occurs, the smart phone kernel 20 Instructs the call to Wipy, and the smartphone kernel 20 calls the Wipy 30 to run on the WindowsCE OS.

In addition, the event dispatcher 41 instructs the smartphone kernel 20 to return data, messages, and the like corresponding to the Wi-Fi related event to itself. As described above, the event dispatcher 41 receives data, messages, and the like corresponding to the Wi-Fi related event returned from the smartphone kernel 20 while the Wi-Fi 30 is driven on the Windows CE OS through the Wi-Fi interface 44. The Wipy 30 is delivered to the Wipy 30, and the Wipy 30 processes the corresponding Wipy related event using the received data and message.

Here, the Wi-Fi related events handled by the event dispatcher 41 include call reception, SMS reception [general text], Java-virtual machine execution request, multimedia message creation request, specific key button press (e.g., wireless Internet connection menu) events that must be handled in the Wi-Fi, such as when a "nate key" is pressed, etc., or an OEM interlocking service request (e.g., when a browser is connected to an LBS server in response to a map data update request). have. In addition, according to the event implementation processed in the known Wipy 30, the Wipy-related event handled by the event dispatcher 41 may be variously designated.

The agent manager 42 accesses the smartphone kernel 20 using the smartphone API to monitor whether the Wi-Fi-based agent execution request is generated from the smartphone and whether the Wi-Fi-based agent execution condition is generated from the smartphone. When Wiwi-based agent execution request or Wipi-based agent execution condition occurs, the smart phone kernel 20 commands the Wi-Fi call, and the smart phone kernel 20 calls the Wi-Fi 30 to run on the Windows CE OS.

In addition, the agent manager 42 instructs the smartphone kernel 20 to return data, messages, and the like corresponding to the Wipy-based agent execution request or the Wifi-based agent execution condition. As described above, the agent manager 42 delivers data, messages, and the like, which are returned from the smartphone kernel 20 to the wickie 30 through the wickie interface 44 while the wickie 30 is driven on the WindowsCE OS. In response to the Wipy 30, the Wi-Fi 30 uses the data, messages, and the like to perform the corresponding work through the Wiki-based agent.

The Wi-Fi-based agent handled by the agent manager 42 may include an SMS push agent, a mobile payment agent, and an idle screen agent. For example, in the lost terminal service, the terminal lock command is sent to the lost mobile phone by SMS. When the terminal lock command SMS is received by the smartphone, the agent manager 42 monitors the SMS push agent. You will be running a process to drive the Wi-Fi for execution. As another example, the idle screen agent displays a standby screen such as a flash on the display when the terminal mode is in the idle state, and when the smartphone mode is in the idle state, the agent manager 42 monitors this to execute the idle screen agent. The process of driving the epithelium is performed. In addition, the agent handled by the agent manager 42 may be variously assigned to an agent implementation based on the known Wipy 30.

The alarm manager 43 approaches the smartphone kernel 20 using the smartphone API to monitor the Wi-Fi alarm time registered in the smart phone, and when the corresponding Wi-Fi alarm time arrives, the smart phone kernel 20 is sent to the smartphone kernel 20. Instructs the call to Wipy, the smartphone kernel 20 calls the Wipy 30 to run on the WindowsCE OS.

In addition, the alarm manager 43 instructs the smart phone kernel 20 to return to the self, the data, messages, and the like related to the Wi-Fi alarm time. As described above, the alarm manager 43 delivers data, messages, and the like, which are returned from the smartphone kernel 20 to the wickie 30 through the wickie interface 44 while the wickie 30 is driven on the WindowsCE OS. In response to this, the Wipy 30 performs a task corresponding to the corresponding alarm time using the received data and message.

Here, the alarm manager 43 handles the Wi-Fi alarm time registered in the smartphone, the Wi-Fi alarm time refers to the reservation time registered in the smartphone kernel 20 Wiwi (30). For example, if a user has scheduled to download some content at a few hours and a few minutes via a Wi-Fi-based content downloader, the Wi-Fi 30 may be configured to meet the user's requirements at a time appropriate to the WindowsCE OS. The Wi-Fi alarm time is registered to wake yourself, and the Wi-Fi alarm time is registered in the alarm scheduling of the smartphone kernel 20. Such a Wipe alarm time may include a specific agent execution reservation time, a specific job reservation time, and a wake-up call reservation time.

The Wi-Fi interface 44 is a communication library in which the above-described event dispatcher 41, the agent manager 42, and the alarm manager 43 may transmit Wi-Fi-related data, messages, and the like, generated from a smartphone to the Wi-Fi 30. Etc., the Wipy 30 provides a communication library for delivering specific data, messages, and the like to the smartphone kernel 20.

That is, an instance used by the daemon 40 running in one process form on the WindowsCE OS 20 of the smart phone and Wipy 30 running in one process form on the WindowsCE OS 20 of the smart phone. The interprocess communication (IPC) is ensured through the Wi-Fi interface 44, since the instances used by each other are different. For example, such a Wi-Fi interface 44 is responsible for conversion between the communication API of the smartphone and the Communication API of the Wi-Fi.

As described above, each component of the daemon 40 has been described in detail. Hereinafter, with reference to FIG. 3, the event dispatcher 41, the agent manager 42, the alarm manager 43, and the WIPI interface 44 will be described. It will be described in detail how to implement the daemon (40) made of Windows CE OS (20).

3 is a conceptual diagram of a Wi-Fi driving service according to the present invention. Referring to FIG. 3, the operation of the daemon 40 will be described first.

First, the daemon 40 is called under the management of the WindowsCE OS_Service.exe process at the start of the WindowsCE OS 20 to perform an initialization operation [WOS_Init], and generates various data sync objects.

Subsequently, the daemon 40 runs in the form of a background process on the WindowsCE OS 20 and monitors whether an event such as a key press or SMS reception occurs using the super daemon service [IOCTL_Service_Connection], and then the corresponding event occurs. When the Windows CE OS (20) is commanded to call the Wi-Fi, IPC (represented as "IOCTL (IOCTL) in Figure 3 implemented this IPC") through a variety of data interworking between the Windows CE OS 20 and Wiwi 30 and Handles sending and receiving messages.

Then, the daemon 40 terminates together at the end of the Windows CE OS 20, and terminates all used object handles and resources [WOS_Deinit].

On the other hand, as mentioned in Figure 2, the Wi-Fi on the operating system of the smart phone as other applications are driven as one application. Therefore, in the present invention, Wipy is treated as an application in a smartphone, but implements a daemon 40 for interaction between the WindowsCE OS 20 and Wipy 30 so as to produce the same operation as the platform.

In the present invention, in consideration of the fact that a general Unix system daemon cannot be implemented in the WindowsCE OS 20, the WindowsCE OS specification for implementing a daemon in the form of a background process occupying a small amount of terminal resources on the WindowsCE OS 20. We focused on WindowsCE OS_Service, which is modeled after the WindowsCE OS_Driver model. Here, WindowsCE OS_Service is to ensure that the services of the third party's features are always stable and managed by the Service.exe process, just as the existing Device Driver is stable under the management of the Device.exe process.

In particular, since the operation of the daemon 40 is to make the Wipy 30 run on the WindowsCE OS 20 when the Wippy driving condition occurs, customizing only the necessary part of the basic operation concept of the WindowsCE OS_Service to the daemon 40 (customizing). )do.

In other words, WindowsCE OS_Service consists of a file in the form of a Dynamic Linked Library with 10 entry points exposed in the same promise as the existing Device Driver. Among these, in the present invention, an entry point that is automatically called when the service is started / stopped, an entry point that is called when there is a power-related change, and a service is directly started / stopped / refreshed / installed / installed / uninstalled. Set the command entry point [execution of external control commands] to allow the defined operation [IOCTL_Service_Start / Stop / Refresh / Install / Uninstall / Status] to be an implementation point. Here, "IOCTL (IoControl)" means IPC, which will be described later.

In addition, the daemon 40, for example, the event dispatcher 41 monitors whether a Wi-Fi related event is generated, and the agent manager 42 monitors whether a Wi-Fi-based agent execution request is generated and whether a Wi-Fi-based agent execution condition is generated. In the alarm manager 43 for monitoring the Wi-Fi alarm time, it is necessary to consider the operation method between the daemon process and the smartphone kernel process.

Thus, in the present invention, the "internet super daemon service (inetd)" is implemented in the daemon 40 [IOCTL_Service_Connection] so as not to burden the terminal on inter-process communication. For example, the number of processes that can be run simultaneously on the WindowsCE OS is limited to 32. The daemon 40 accesses the smartphone kernel process using a super daemon service and monitors whether a specific event occurs. [Table 1] below shows the contents of the super daemon service and message transmission and reception described below among some codes of the daemon.

Daemon () {while (1) {if (eventWOS.IsSignaled ()) // When an event message occurs to deliver to the Wiffy {DoCommand (); eventWOS.ResetEvent (); // Release set event}}} / * Analyze the contents of the message stored in the global area and deliver it to Wipy if it is related to Wipy. * / void DoCommand () {WOS_PARAM * pReq = (WOS_PARAM *) filemapWOS.Use (); if (pReq-> szCommand == "RUN_WIPI_APP") OnRunWIPIApp (pReq); else if (pReq-> szCommand == "RUN_OEM_APP") OnRunOEMApp (pReq); … … … … … }

As can be seen from Table 1, the daemon 40 monitors whether the Wi-Fi driving condition is generated in the smartphone kernel 20 using the super daemon service, and when the Wi-Fi related event occurs, IPC [i.e., IOCTL ] To call the smartphone kernel 20 to drive the Wi-Fi (30), and the Wiki-related messages of the message content stored in the global area of the smartphone kernel 20 through the IPC smartphone kernel (20) From to the epithelium (30). Hereinafter, the IPC will be described.

As mentioned above, the present invention implements data communication and message transmission and reception, that is, IPC between the smartphone kernel process and the Wi-Fi process in the daemon 40, preferably the Wi-Fi interface 44.

That is, in a typical mobile phone, the operating system (REX), the OEM application running on the operating system, the Wipy, and the applications running on the WiFi are one-binary / one-process / single thread. Because it operates in (One-Thread) mode, it does not need a separate communication interface, so data communication and message delivery are possible using only simple API calls.

However, in smartphones, the operating system (WindowsCE OS), OEM applications running on the WindowsCE OS, WiPy, and applications running on the WiPI all operate as independent processes, so shared objects that can be shared between processes ( Shared Objects) must be used for event forwarding and data processing.

In particular, since smartphones 30, daemons 40, and other applications (OEM applications) all run in an independent process form, a general rule for data communication and message transfer between them is required. In the present invention, IOCTL is used. These IOCTLs employ events such as Event, MuteX, Semaphore, Severe Section, Critical Section, File Mapping, and Registered Message. This will be described in more detail as follows.

In smartphones, when data is requested from Wi-Fi or Wi-Fi requires data from the operating system of the smartphone, it is a structure that sends and receives data to each other, not just a structure to deliver a message. This structure takes the form of "Send Data-> Wait Result-> Recv Data", which requires a data space that can be shared between two different processes, and commands must be defined to understand each other's requests. do.

Accordingly, in the present invention, the inter-process communication command and the data communication method are defined as IOCTL to perform inter-process communication (IPC). Examples of such IOCTLs are shown in Table 2 below.

1. RegisteredMessage / System: The daemon needs to interface with the device level, which takes into consideration the difficulty of processing it as a simple message and sets a certain specification by using the terminal manufacturer in consultation with the terminal manufacturer [Application example; Call reception, data communication status, etc.]. 2. Mutex / MessageLock: This Mutex / MessageLock is created to prevent other messages from being delivered during the processing of one message, considering that Wipy cannot handle two messages at the same time. 3. Event / WOS: When there is a message to be delivered to Windows CE OS from WindowsCE OS or when there is a message to be delivered to Windows CE OS from Wifi, SignalSignal) occurs. 4. FileMap / WOS: Global memory to be used when there is data to be delivered before signaling Event / WOS.

While the content of the present invention has been described by way of examples, the embodiments of the present invention are merely illustrative of the present invention and should not be construed as limiting the scope of the present invention. Those skilled in the art to which the present invention pertains may modify or alter the present invention in various forms within the principles and scope described in the claims herein.

The present invention as described above is to drive the Wi-Fi whenever the Wi-Fi is required in the smart phone to prevent the terminal resources such as memory and processes to be wasted compared to always driving the Wi-Fi in accordance with the existing smartphone drive, There is an effect that the application can be run efficiently on the smartphone.

In addition, the present invention has the effect of allowing the Wi-Fi to be properly driven in the smartphone in accordance with the Wi-Fi driving conditions by using a daemon in the form of a background process that takes up a small amount of terminal resources even without any restrictions on the operating system of the existing smartphone.

In addition, the present invention by using the daemon to ensure the transmission and reception of data, messages between the smartphone kernel and Wi-Fi, there is an effect that can be properly processed Wi-Fi-related tasks in the smart phone.

Claims (8)

As a daemon that monitors whether the Wi-Fi driving condition is generated in the smartphone and then runs the Wi-Fi on the operating system of the smartphone when the Wi-Fi driving condition occurs, The daemon, An event dispatcher that monitors whether a Wi-Fi related event occurs by accessing the kernel of the smart phone and instructs the Wi-Fi call to the smart phone kernel when a Wi-Fi-related event occurs; Approaching the kernel of the smartphone to monitor whether the Wi-Fi-based agent execution request is generated and whether the Wi-Fi-based agent execution condition is generated, and when the Wi-Fi-based agent execution request or Wi-Fi-based agent execution condition occurs An agent manager for invoking a call; An alarm manager for accessing the kernel of the smartphone to monitor the Wi-Fi alarm time and instructing the Wi-Fi call to the smartphone kernel when the Wi-Fi alarm time arrives; And Wifi interface for transferring data and messages between the smartphone kernel and Wiwi by the event dispatcher, agent manager and alarm manager Daemon for driving the Wiffy in a smartphone consisting of. The method of claim 1, The Wi-Fi related event is a daemon for driving Wi-Fi in a smart phone, characterized in that the call generation, SMS reception, Java-virtual machine execution request, multimedia message creation request, specific key button press and OEM interworking service request. The method of claim 1, The Wi-Fi-based agent is a daemon for driving Wi-Fi in a smartphone, characterized in that it comprises an SMS push agent, mobile payment agent and idle screen agent. The method of claim 1, The Wipy alarm time is registered on the operating system of the smart phone by Wipy, the daemon for driving the Wipy in the smartphone, characterized in that it includes a specific agent execution reservation time, a specific task reservation time and the wake-up call reservation time. The method according to any one of claims 1 to 4, The daemon is called under the management of the service process [Service.exe] of the smartphone operating system daemon to drive the Wi-Fi in the smartphone, characterized in that executed in the form of a background process in accordance with the operating system operating smartphone. The method according to any one of claims 1 to 4, The daemon, the daemon for driving the Wi-Fi in a smartphone, characterized in that for monitoring the Wi-Fi operating conditions on the smartphone operating system using a super daemon service [inetd]. The method according to any one of claims 1 to 4, The daemon, through inter-process communication [IPC], grasps the data and message contents stored in the global area [shared object] of the smartphone kernel process, among which Wipy-related data and messages are saved from the smartphone kernel process. Daemon for driving Wiffy on a smartphone, characterized in that the delivery to the process. The method of claim 7, wherein The interprocess communication [IPC] includes at least one of Event [Event], MuteX [MuteX], Semaphore [Semaphore], Critical Section [Critical Section], File Mapping [Register Message]. Daemon for driving the wickie in the smartphone, characterized in that.

Images