Method for cross-platform remote management of electronic equipment

Abstract

The invention relates to a cross-platform remote management method for electronic equipment, which comprises the following steps of: S1, dividing a total monitoring period into a plurality of unit monitoring periods, and circularly monitoring; and S2, when the unit monitoring period expires, triggering a monitoring event, collecting a timestamp interval, using accumulated time increase and using an evaluation state. S3, when the use cumulative increase is not 0, comparing the time stamp interval with the use cumulative increase, and if the unit monitoring period is 0 lt; using accumulated time increase lt; s4, selecting to start use and end use according to the use evaluation state, accumulating the actual use time of all the unit monitoring periods from the start use to the end use, if the actual use time of the unit monitoring period is equal to the use cumulative increase, and if the actual use time of the unit monitoring period is equal to the time stamp interval, obtaining the actual use time, and S4, selecting to start use and end use according to the use evaluation state, and accumulating the actual use time of all the unit monitoring periods from the start use to the end use. And the actual total use time is obtained. According to the method for cross-platform remote management of the electronic equipment, the use data can be checked only by using the official function of the Apple, and any sensitive operation is not needed.

Description

Technical Field

[0001] This invention relates to the field of mobile internet technology, and more specifically to a method for cross-platform remote management of electronic devices. Background Technology

[0002] In real life, controlling children's mobile phone usage time presents numerous problems and is extremely difficult. One major obstacle lies in the fact that children's iOS device usage data needs to be shared via iCloud Family Sharing, which can only be synced to the iOS / macOS devices of the family organizer. This mechanism heavily relies on Apple's end-to-end encryption and FamilyGroup trust chain, and does not provide any official API or interface to authorize data to non-Apple devices (such as Android phones). Therefore, the current technology faces the dilemma that parents must use Apple devices, which would force many Android users to switch phones, making it too costly and impractical. Although there are existing technologies that can achieve cross-platform control, such as the MDM supervision model, these technologies bring the following problems: 1. The operation is extremely complicated: It requires connecting the device to a computer and manually putting the device into "supervised" mode through tools such as Apple Configurator, or registering it to an MDM server. The process is professional and time-consuming, which is a huge hurdle for ordinary parents.

[0003] 2. High risk of privacy leakage: When the device is in "supervised" mode, the administrator of the MDM configuration file (third-party service provider) theoretically has extremely high privileges, which can remotely erase, restrict functions, and install / uninstall applications, raising parents' concerns about their children's privacy.

[0004] 3. High device environment risk: Apple explicitly positions MDM for enterprises and schools to manage their own devices. Using it for consumer-level parental controls falls into a "grey area." Apple has the right to block such applications at any time through system updates, causing the service to suddenly fail.

[0005] 4. Over-controlling: Powerful but may be "too much of a good thing," more like corporate surveillance than a healthy parenting management tool.

[0006] Therefore, a compliant, stable, and user-friendly approach is needed to address the aforementioned pain points in cross-platform parental controls. Summary of the Invention

[0007] This invention provides a method for cross-platform remote management of electronic devices. This technology utilizes a neglected "data interface" (cumulative changes in screen usage time) and, through an original high-precision sampling and error correction algorithm, securely synchronizes key parental control data, which was originally closed within the iOS ecosystem, to non-iOS devices without violating Apple's rules.

[0008] To achieve the above objectives, the present invention provides the following technical solution: A method for remotely managing electronic devices across platforms includes: S1. Divide the total monitoring cycle into several unit monitoring cycles and use a timer to monitor them in a loop; S2. When the unit monitoring cycle expires, a monitoring event will be triggered, and the timestamp interval of the unit monitoring cycle, the cumulative usage increment, and the usage evaluation status will be collected.

[0009] S3. When the cumulative usage time is not 0, compare the timestamp interval with the cumulative usage time. If 0 < cumulative usage time < timestamp interval within a unit monitoring period, then the actual usage time for that unit monitoring period is equal to the cumulative usage time; otherwise, the actual usage time is equal to the timestamp interval. This yields the actual usage time for each unit monitoring period. S4. Select the unit monitoring cycle for the start and end of use based on the usage evaluation status, and sum up the actual usage time of all unit monitoring cycles from the start to the end of use to obtain the total actual usage time.

[0010] Furthermore, in S2, the condition for the expiration of a unit monitoring cycle is to count down in each unit monitoring cycle and trigger a monitoring event after the countdown ends; or, a time threshold is set in each unit monitoring cycle, and a monitoring event is triggered when the countdown reaches the time threshold.

[0011] Furthermore, the timer is calibrated with the system clock each time a monitoring event is triggered.

[0012] Furthermore, in S2, the timestamp when the monitoring event is triggered is collected, and then the interval between the two timestamps is calculated based on the timestamp of the current unit monitoring cycle and the timestamp of the previous adjacent unit monitoring cycle to obtain the timestamp interval of the current unit monitoring cycle; in S2, the total cumulative usage time from the start of the total monitoring cycle to the current unit monitoring cycle is collected, and then the total cumulative usage time of the current unit monitoring cycle is subtracted from the total cumulative usage time of the previous adjacent unit monitoring cycle to obtain the current cumulative usage time increment.

[0013] Furthermore, in S3, a fault tolerance threshold is added. If the difference between the timestamp interval and the cumulative usage time is less than the fault tolerance threshold, then the actual usage time = timestamp interval; conversely, if the difference between the timestamp interval and the cumulative usage time is greater than the fault tolerance threshold, then the actual usage time = cumulative usage time.

[0014] Furthermore, in S4, the timestamp intervals of all unit monitoring cycles from the start to the end of the evaluation status are accumulated to obtain the actual usage timestamp accumulation. Then, the actual usage accumulation time corresponding to the actual usage timestamp accumulation within the same hour interval is statistically output together.

[0015] Furthermore, the start and end times of actual cumulative usage are converted into absolute minutes from the start of the total monitoring cycle; If the usage is continuous and uninterrupted, the actual cumulative usage time = the actual usage timestamp accumulation. The actual cumulative usage time is then allocated according to the hour intervals described by the actual usage timestamp accumulation. If there are continuous interruptions in the usage process, first calculate the proportion of the actual usage accumulated time to the actual usage timestamp accumulated time, and then multiply the quota allocated to the hour interval by the actual usage accumulated time according to the actual usage timestamp accumulated time, and then allocate it to each hour interval.

[0016] The present invention has the following advantages: This invention provides a method for remotely managing electronic devices across platforms that is extremely simple to operate. Parents only need to guide the operation within the App, which is no different from setting up a shared account in a regular family. The binding can be completed in 5 minutes, achieving "consumer-level" ease of use. This makes cross-platform management as simple as using native functions, greatly reducing the user's barrier to entry.

[0017] This invention provides a cross-platform remote management method for electronic devices with zero additional risk. It utilizes only Apple's official "Screen Time" and "Family Sharing" features to view usage data without requiring any sensitive operations (such as viewing specific content, location tracking, or app control). This completely eliminates privacy concerns, as the solution is built upon Apple's native, transparent parental control framework, providing greater peace of mind for both parents and children.

[0018] The present invention provides a method for cross-platform remote management of electronic devices that only "reads" and "utilizes" the functions and data provided to users by Apple, without touching any sensitive interfaces or violating any developer policies. This ensures the long-term stability and sustainability of the solution, is unaffected by changes in Apple's policies, and provides a reliable technical foundation for the product.

[0019] This invention provides a method for remotely managing electronic devices across platforms, perfectly replicating the original intention behind Apple's "Screen Time" design: to provide insights, set agreements, and facilitate communication. Its functions focus on the core need of "time management," which is more in line with modern educational concepts, emphasizing guidance rather than authoritarianism, and helps cultivate children's digital self-discipline. Attached Figure Description

[0020] To more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings in the following description are merely exemplary, and those skilled in the art can derive other embodiments based on the provided drawings without creative effort.

[0021] The structures, proportions, sizes, etc. illustrated in this specification are only for the purpose of assisting those skilled in the art in understanding and reading the content disclosed herein, and are not intended to limit the conditions under which the present invention can be implemented. Therefore, they have no substantial technical significance. Any modifications to the structure, changes in the proportions, or adjustments to the size, without affecting the effects and objectives that the present invention can produce, should still fall within the scope of the technical content disclosed in the present invention.

[0022] Figure 1 A flowchart illustrating a method for cross-platform remote management of electronic devices provided in this embodiment of the invention; Figure 2 for Figure 1 The logic expansion diagram of step S3 in the middle; Figure 3 The present invention provides a cross-platform remote management method for electronic devices, which includes a cross-hour allocation logic diagram. Detailed Implementation

[0023] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0024] like Figure 1-2 As shown, a method for cross-platform remote management of electronic devices includes the following steps: S1. Divide the total monitoring cycle into several unit monitoring cycles and use a timer to monitor them in a loop; S2. When the unit monitoring cycle expires, a monitoring event will be triggered, and the timestamp interval of the unit monitoring cycle, the cumulative usage increment, and the usage evaluation status will be collected.

[0025] S3. When the cumulative usage time is not 0, compare the timestamp interval with the cumulative usage time. If 0 < cumulative usage time < timestamp interval within a unit monitoring period, then the actual usage time for that unit monitoring period is equal to the cumulative usage time; otherwise, the actual usage time is equal to the timestamp interval. This yields the actual usage time for each unit monitoring period. S4. Select the unit monitoring cycle for the start and end of use based on the usage evaluation status, and sum up the actual usage time of all unit monitoring cycles from the start to the end of use to obtain the total actual usage time.

[0026] The implementation method for each step is explained in detail below: In step S1, the total monitoring period is divided into several unit monitoring periods. Based on human time management habits, this technology uses a total monitoring period of 24 hours and a unit monitoring period of 5 minutes (300 seconds), resulting in a total of 288 unit monitoring periods per day. These unit monitoring periods are then sorted chronologically. Example: T0(00:00) → T5(00:05) → T10(00:10) → ... → T1440(24:00).

[0027] The system utilizes a high-precision timer built into iOS. This timer runs continuously regardless of whether the screen is on or off, or whether the application is in the foreground. Even if the device restarts, the timer resumes and compensates for any missed monitoring periods. A cyclical monitoring mechanism is then used to ensure no time period is missed. This involves a countdown within each monitoring unit, triggering a monitoring event upon completion of the countdown; alternatively, a time threshold can be set within each monitoring unit, triggering a monitoring event when the threshold is reached. Each time a monitoring event is triggered, the timer is calibrated with the system clock to prevent timing drift.

[0028] In step S2, after a monitoring event is triggered, the system collects the following information: the timestamp when the monitoring event was triggered, the total cumulative usage time for the total monitoring cycle, and the current device status. Based on the current monitoring event and the monitoring event of the previous monitoring cycle, the timestamp interval for the current monitoring cycle, the cumulative usage time increment, and the usage evaluation status are obtained, as follows: Timestamp Interval: The timestamp data comes from the absolute time of the IOS system, i.e., the Unix timestamp (accurate to milliseconds). The interval between the two timestamps is calculated based on the timestamp of the monitoring event in the current monitoring period and the timestamp of the monitoring event in the previous adjacent monitoring period. This is the timestamp interval for the current monitoring period, i.e., timestampInterval = E[i].timestamp - E[i-1].timestamp, where i is the sequence number of the current monitoring period.

[0029] The system uses cumulative time increments; the data comes from calling Apple's private / public APIs for obtaining screen time, such as querying the "Screen Time" API. It collects the total cumulative usage time from the start of the overall monitoring cycle to the current monitoring cycle, and then subtracts the total cumulative usage time of the previous adjacent monitoring cycle from the current monitoring cycle's total cumulative usage time to obtain the cumulative time increment for the current monitoring cycle. For example, if the total cumulative usage time in the 5th monitoring cycle is 15 minutes and the total cumulative usage time in the 4th monitoring cycle is 12 minutes, then the cumulative time increment for the 5th monitoring cycle is 15 - 12 = 3 minutes.

[0030] Usage Assessment Status: The current device status includes two states: "Used" and "Not Used." This data can accurately reflect the device status in real time, but it only has a binary state and lacks duration information. Therefore, it must be evaluated in conjunction with the aforementioned detection duration data. This technology assesses the start and end points of device use based on adjacent changes in device status. By combining this with the detection duration data, the actual usage duration of the device can be assessed. Specifically, the current device status of the current unit of monitoring light cycle is recorded, and the usage assessment status is obtained based on the current device status of the current unit of monitoring cycle and the current device status of the adjacent previous unit of monitoring cycle. The usage assessment status includes three types: Start of Use, Continued Use, and End of Use, specifically including: If the current device status in the current monitoring cycle is "screen in use," and the current device status in the previous adjacent monitoring cycle is "screen not in use," then the usage evaluation status for the current monitoring cycle is "started in use."

[0031] If the current device status in the current monitoring cycle is "screen in use", and the current device status in the previous adjacent monitoring cycle is "screen in use", then the usage evaluation status for the current monitoring cycle is "continue to use".

[0032] If the current device status in the current monitoring cycle is "screen not in use", and the current device status in the previous adjacent monitoring cycle is "screen in use", then the usage evaluation status of the current monitoring cycle is "end of use".

[0033] However, while system timestamps offer the advantage of objectivity, continuity, and resistance to tampering, this data cannot distinguish between device states such as screen off, screen on, and actual device use. Using cumulative time increments can identify the actual interaction time of the device, but it is prone to delays, resets, and anomalies, leading to numerous data errors. During device use, issues such as system anomalies, application restarts, data resets, clock malfunctions, and interruptions during normal use can also occur.

[0034] To eliminate the aforementioned problems, step S3 compares the timestamp interval and the cumulative time increment within the same monitoring period, evaluates different scenarios, and finally outputs the most accurate actual usage time for that monitoring period. Specific methods include: S31. Handling abnormal situations.

[0035] Abnormal data will pollute all other statistics, so it must be dealt with first. Extreme cases such as system anomalies, application restarts, and data resets must be identified first.

[0036] Abnormal situation judgment method: use cumulative time increment > timestamp interval, or use cumulative time increment < 0.

[0037] Output: Actual usage time = timestamp interval.

[0038] Scenario 1: A sudden surge in the use of cumulative increment (i.e., timestamp interval < cumulative increment). Root cause analysis: System statistics delay: The Screen Usage Time API may have accumulated data for a period of time, which is suddenly reported, causing a significant increase in the cumulative usage time, exceeding the timestamp interval.

[0039] Application restart: The monitoring application was killed and then restarted, reading incorrect cached data, resulting in the cumulative usage time being less than 0.

[0040] Clock jump: The device time has been modified, causing the timestamp interval calculation to be abnormal, that is, the timestamp interval is less than the cumulative time increment.

[0041] Example data: The timestamp of the previous unit's monitoring period = 10:00, and the total cumulative usage time = 30; The timestamp of the current unit's monitoring cycle is 10:05, and the total cumulative usage time is 50. The conclusion is that the cumulative usage time increment is 50 - 30 = 20 minutes, while the timestamp interval is 5 minutes. The system has been running for 5 minutes, resulting in a 20-minute increase in the cumulative usage time, causing the error. The timestamp interval can be used to verify if it's a system delay. Multiple metrics should be checked to determine if it's a system delay. A typical characteristic of delay is that the usage increment is an integer multiple of the time interval. Next, check if the application has restarted. An application restart will reset the total cumulative usage time, making it impossible to accurately calculate the total cumulative usage time. Therefore, a conservative estimate should be used, setting the actual usage time equal to the timestamp interval, i.e., actual usage time = 5 minutes.

[0042] Judgment criteria: Timestamp interval of 5 minutes < cumulative time increment of 20 minutes; Output: Actual usage time = timestamp interval 5 minutes; Scenario 2: Using a negative cumulative time increment (i.e., using a cumulative time increment < 0) Root cause analysis: Reset across days: After midnight, the accumulated value starts from zero again; Statistics Reset: The user manually reset the screen time statistics; System Error: An internal iOS system error has caused data corruption.

[0043] Example data: The timestamp of the previous unit's monitoring period = 10:00, using cumulative time increment = 60; The timestamp for the current unit's monitoring cycle is 10:05, and the cumulative time increment is 40. The conclusion is: the cumulative time increment is 60 - 40 = -20 minutes. Since the cumulative time increment is less than 0, it's necessary to check if it was manually reset. If there's no usage time after a reset, record the reset event, and the system will restart the statistics. In this case, the actual usage time will be equal to the timestamp interval, i.e., actual usage time = 5 minutes. Alternatively, check if it spans multiple days; cases spanning multiple days require special handling.

[0044] S32. After the abnormal situation is handled, the subsequent statistical data is highly reliable. When the results given by two independent time measurement systems (system clock vs. screen usage time statistics) are almost the same, the system can assume that the device usage during this period is normal and there is no obvious fault, and the system statistical function is working normally.

[0045] Judgment condition: 0 < cumulative time increment ≤ timestamp interval.

[0046] Output: Actual usage time = Cumulative usage time.

[0047] Scenario 1: Perfect Match Scenario (using cumulative time increment = timestamp interval) Example data: Users watch videos continuously for 5 minutes from 10:00 to 10:05.

[0048] The timestamp of the previous unit's monitoring period = 10:00, and the cumulative number of minutes = 100; The timestamp for the current unit's monitoring cycle is 10:05, and the cumulative number of minutes is 105. The calculated cumulative time increment is 105 - 100 = 5 minutes; The conclusion is: Since the timestamp interval is 5 minutes, and the cumulative time increment is equal to the timestamp interval of 5 minutes, the actual usage time is 5 minutes.

[0049] Based on data feature analysis: when the timestamp interval equals the cumulative usage increment, the device status remains "in use," the detected power decrease is in line with expectations, and the detected network traffic remains stable, which is consistent with the conclusion of continuous use.

[0050] Scenario 2: Interruption occurs (0 < cumulative time increment < timestamp interval) When the timestamp interval is greater than the cumulative usage time, it indicates that the device was not used continuously during this period, and there were situations such as screen lock, application switching, and device hibernation. The cumulative usage time statistics are closer to the actual usage time.

[0051] Example data: A user watched a video continuously for 3 minutes from 10:00 to 10:05, with a 2-minute interruption.

[0052] The timestamp of the previous unit's monitoring period = 10:00, and the cumulative number of minutes = 100; The timestamp for the current unit's monitoring cycle is 10:05, and the cumulative number of minutes is 103. The calculated cumulative time increment is 103 - 100 = 3 minutes; The conclusion is: since the timestamp interval is 5 minutes, 0 < cumulative usage time (3 minutes) < timestamp interval (5 minutes), then the actual usage time is output as 3 minutes.

[0053] Because interruptions vary in duration and cause, some are interruptions during use, such as device restarts or application crash restarts. These interruptions are relatively short and are generally caused by device issues rather than human intervention; they are not interruptions caused by the user's intention to stop using the device and can therefore be considered as continuous usage. Therefore, this technology adds a fault tolerance threshold to the aforementioned conditions. If the difference between the timestamp interval and the cumulative usage time is less than the fault tolerance threshold, the interruption is considered negligible, and the actual usage time equals the timestamp interval. Conversely, if the difference between the timestamp interval and the cumulative usage time is greater than the fault tolerance threshold, the interruption is considered non-negligible, and the actual usage time equals the cumulative usage time.

[0054] Scenario 1: The difference between the timestamp interval and the cumulative usage time is less than the fault tolerance threshold (timestamp interval - cumulative usage time < fault tolerance threshold). Example data: The fault tolerance threshold is 1. If a user watches a video continuously for 4.5 minutes (4 minutes and 30 seconds) from 10:00 to 10:05, there will be a 30-second interruption.

[0055] The timestamp of the previous unit's monitoring period = 10:00, and the cumulative number of minutes = 100; The current unit's monitoring cycle timestamp = 10:05, cumulative minutes = 104.5; The calculated cumulative time increment is 104.5 - 100 = 4.5 minutes; Recalculate the timestamp interval - cumulative increment = 5 - 4.5 = 0.5 < fault tolerance threshold 1; Conclusion: Output actual usage time = timestamp interval 5 minutes.

[0056] Scenario 2: The difference between the timestamp interval and the cumulative usage time is greater than the fault tolerance threshold (timestamp interval - cumulative usage time > fault tolerance threshold). Example data: The fault tolerance threshold is 1. If a user watches a video continuously for 3 minutes from 10:00 to 10:05, there is a 2-minute interruption.

[0057] The timestamp of the previous unit's monitoring period = 10:00, and the cumulative number of minutes = 100; The timestamp for the current unit's monitoring cycle is 10:05, and the cumulative number of minutes is 103. The calculated cumulative time increment is 103 - 100 = 3 minutes; Recalculate the timestamp interval - use cumulative increment = 5 - 3 = 2 > fault tolerance threshold 1; Conclusion: Output actual usage time = 3 minutes (using cumulative time increment).

[0058] The system contains various errors, such as time synchronization errors (iOS device clock errors are typically <0.5 seconds / day); statistical delay errors (the Screen Time API may have a 30-second delay); sampling errors (5-minute monitoring points may deviate by ±30 seconds); cumulative value rounding (Apple may round the number of seconds); and device restart times between 20-40 seconds. Since all these issues are less than 1 minute, the fault tolerance threshold in this technology is set to less than 1 minute. Furthermore, the fault tolerance threshold is dynamic and can be automatically adjusted based on device status. For example, the base value is 1 minute; considering device performance, the tolerance is increased to 1.5 minutes for low-performance devices; considering network conditions, the fault tolerance is increased for unstable networks; and considering battery status, the frequency of low-power mode may be reduced, thus the maximum is no more than 2 minutes.

[0059] This method features continuous learning and optimization capabilities. It optimizes algorithm parameters based on actual user usage patterns, collects user feedback to analyze algorithm performance, and then dynamically adjusts thresholds. If users report excessive statistical time, it may increase the time interval of the unit monitoring cycle or adjust and reduce the fault tolerance threshold, such as from 2 minutes to 1.5 minutes. If users report insufficient statistical time, it may tighten the anomaly detection conditions, such as shortening the time interval of the unit monitoring cycle or adjusting and increasing the fault tolerance threshold, such as from 1.5 to 2.0.

[0060] The technical value of this method for determining actual usage time lies in: 1. High robustness: It can handle various abnormal situations (system delay, application restart, clock abnormality), maintain stability on different devices and different iOS versions, and adapt to various usage patterns (continuous use, frequent interruptions, long-term idle time).

[0061] 2. High accuracy: It integrates multiple data sources, verifies and complements each other, dynamically adjusts weights to adapt to different scenarios, and has a fault tolerance mechanism so that an error in a single data source does not affect the overall accuracy.

[0062] 3. High credibility: Transparent logic, every step is explainable; confidence score, letting users know the credibility of the statistics; self-verification, continuously monitoring algorithm performance.

[0063] 4. Engineering practicality: The calculation is simple and suitable for real-time processing on mobile devices; it has a small memory footprint, requiring only the storage of the most recent few events; it is highly scalable, allowing for easy addition of new judgment dimensions.

[0064] S4. Select the starting and ending unit monitoring cycles based on the usage evaluation status. Add up the actual usage time of all unit monitoring cycles from the starting to the ending unit monitoring cycle to obtain the actual cumulative usage time.

[0065] The start and end of the unit monitoring cycle are based on the absolute usage evaluation status. If the usage evaluation status of the unit monitoring cycle is "start of use", then the unit monitoring cycle is in use. Similarly, if the usage evaluation status of the unit monitoring cycle is "end of use", then the unit monitoring cycle is in use.

[0066] The start and end of the actual cumulative usage time are determined by the use of the evaluation status. The actual usage time is obtained by summing up the actual usage time of all monitoring cycles from the start to the end of the evaluation status. Although there may be brief interruptions when the child uses the device continuously, the interval between monitoring cycles is very short and the frequency of data collection is high. The interruption time is insufficient to relieve the child's eye fatigue. Therefore, as long as the current monitoring event detects that the device usage status is "continued use", it can be considered that the child is using the device continuously.

[0067] However, simply recording the actual cumulative usage time has limitations. For example, consider the child's phone usage pattern: 15:00-15:30: Played games continuously for 30 minutes, then took a 5-minute break; 15:35-15:50: Continued playing games for 15 minutes, interrupted by the mother; 16:00-16:40: Watched videos for 26 minutes. If only the actual cumulative usage time is recorded: the longest actual cumulative usage time is 30 minutes (the first time playing games), and parents would see that each time it didn't exceed 30 minutes. But in reality, from 15:00-16:00, the child actually used games for 45 minutes; from 16:00-17:00, the child watched videos for 26 minutes; total usage time: 30 + 15 + 26 = 71 minutes. Therefore, simply recording the actual cumulative usage time can only show the longest single usage duration and cannot show the time distribution, which cannot reflect the child's actual mobile phone usage. Therefore, this technology not only outputs the actual cumulative usage time for each instance, but also accumulates multiple timestamp intervals corresponding to each actual cumulative usage time according to the time distribution to obtain the actual usage timestamp accumulation.

[0068] This technology simultaneously reflects both the cumulative actual usage time and the cumulative actual usage timestamps, providing parents with a comprehensive and in-depth understanding of their children's phone usage. However, to better facilitate this understanding, the technology outputs actual usage data in hourly segments, based on human perception of time. This allows parents to clearly see peak usage times and periods of unauthorized device use. For example, if bedtime is at 10 PM, without hourly segments, parents would need to manually identify times after 10 PM using cumulative usage timestamps, and setting alerts based on important time points would be impossible. Therefore, outputting actual usage data in hourly segments is essential.

[0069] like Figure 3 As shown, the timestamp intervals of all monitoring cycles from the start to the end of the usage evaluation period are accumulated to obtain the cumulative actual usage timestamps. Then, divided by hours, the cumulative actual usage time corresponding to the cumulative actual usage timestamps within the same hour interval is statistically output together. For example, if a child uses a mobile phone as follows: 15:00-15:25, plays games continuously for 25 minutes, interrupted for 10 minutes; 15:35-15:50, plays games for 15 minutes; 16:05-16:31, watches videos for 26 minutes; 16:40-16:55, watches videos for another 15 minutes. This technology outputs: 15:00-16:00, device usage 40 minutes; 16:00-17:00, device usage 41 minutes.

[0070] However, there is one exception: a continuous period of actual usage time spanning two or more hours requires precise allocation of the actual usage time by hour. For example, if usage starts at 10:45 and ends at 11:20, with a total usage time of 35 minutes, it needs to be allocated as follows: 10:00-11:00: 15 minutes (10:45-11:00); 11:00-12:00: 20 minutes (11:00-11:20). However, the system has issues with time allocation across hours, including: continuous time periods need to be divided by hourly boundaries; when there are interruptions, allocation needs to be based on the actual usage ratio; minutes are integers, requiring handling of rounding errors; and handling exceptions, such as usage time exceeding a time period.

[0071] To address the aforementioned issues, this technology provides a method for handling situations where the actual cumulative usage time spans multiple hours. This method involves identifying instances of cross-hour usage based on the actual usage timestamps, and then processing the corresponding actual cumulative usage duration as follows: S41. Convert both the start and end times of the actual cumulative usage into absolute minutes from the start of the total monitoring cycle. For example, 10:45-11:20: convert 10:45 to 645 minutes and 11:20 to 680 minutes. The time period is 680 - 645 = 35 minutes. Using absolute minutes simplifies subsequent calculations and ensures the time span is positive. If dealing with cross-day situations (i.e., the end time is less than the start time), add 24 hours to the end time.

[0072] S42. Determine the number of minutes to be allocated, and iterate through the hours to allocate them.

[0073] Before determining the time to be allocated, system errors and anomalies must be ruled out. If the actual cumulative usage time exceeds the actual cumulative usage timestamp, the actual cumulative usage time will be equal to the actual cumulative usage timestamp to ensure that the allocation does not exceed the theoretical maximum value. This situation represents continuous, uninterrupted use; therefore, the actual cumulative usage time allocated for each hour is equal to the actual cumulative usage timestamp for that hour.

[0074] Scenario 1: Example of continuous, uninterrupted use: The actual usage timestamps accumulated from 10:45 to 12:20; The actual cumulative usage time was 95 minutes of continuous use without interruption.

[0075] The actual cumulative usage time starts at 10:45 = 645 minutes.

[0076] The actual accumulated usage time ends at 12:20 = 740 minutes.

[0077] Allocation logic selection criteria: Actual cumulative usage time = Accumulated actual usage timestamps Allocation logic: The actual accumulated usage time is allocated according to the hour intervals specified by the actual usage timestamp, which is simple and direct.

[0078] Based on the start time point accumulated from the actual usage timestamps, the hourly segment 10:00-11:00 is identified as the start hourly segment. Then, the remaining time at the end of the start hourly segment is calculated, which is the end time point of the start hourly segment minus the start time point of the actual usage timestamps = 660-645 (i.e., 11:00-10:45) = 15 minutes. The remaining time at the end is taken as the accumulated actual usage time of the start hourly segment, i.e., 15 minutes.

[0079] b. Based on the accumulated relay time points of the actual usage timestamps, the hourly segment 11:00-12:00 is identified as the relay hourly segment. The relay hourly segment is then used at full capacity, i.e., allocated for 60 minutes.

[0080] c. Based on the end time point of the accumulated timestamps of actual use, the hourly segment 11:00-12:00 is identified as the end hourly segment. Then, the elapsed time of the end hourly segment is calculated, which is the end time point of the actual use timestamp minus the start time point of the end hourly segment = 740-720 (i.e., 12:20-12:00) = 20 minutes. The elapsed time is used as the accumulated actual usage time of the end hourly segment, which is 20 minutes.

[0081] Final allocation: 10:15, 11:60, 12:20.

[0082] Scenario 2: Example of proportional allocation in the event of an interruption: The actual usage timestamps totaled from 10:45 to 12:20, a total of 95 minutes; The actual cumulative usage time was 75 minutes of continuous use, with a 20-minute interruption.

[0083] The actual cumulative usage time starts at 10:45 = 645 minutes.

[0084] The actual accumulated usage time ends at 12:20 = 740 minutes.

[0085] Allocation logic selection criteria: Actual cumulative usage time < Actual cumulative usage timestamps; Allocation logic: Allocation is based on the ratio of actual cumulative usage time to the actual cumulative usage timestamp.

[0086] Proportion calculation: The proportion of actual cumulative usage time to the actual cumulative usage timestamps is 75 / 95=0.789.

[0087] Based on the start time of the accumulated timestamps of actual usage, the hourly segment 10:00-11:00 is identified as the starting hourly segment. The remaining time at the end of the starting hourly segment is calculated as the end time of the starting hourly segment minus the start time of the actual usage timestamps = 660-645 (i.e., 11:00-10:45) = 15 minutes. The remaining time at the end is multiplied by the allocation ratio to obtain the accumulated actual usage time of the starting hourly segment, i.e., 15 minutes x 0.789 = 11.835, which is rounded to 12 minutes.

[0088] b. Based on the accumulated relay time points of the actual usage timestamps, the hourly segment 11:00-12:00 is identified as the relay hourly segment. The relay hourly segment is the full time period of 60 minutes multiplied by the allocation ratio to obtain the accumulated actual usage time of the intermediate hourly segment, that is, 60 minutes x 0.789 = 47.34, which is rounded to 47 minutes.

[0089] c. Based on the end time of the accumulated timestamps of actual usage, the hourly segment 11:00-12:00 is identified as the end hourly segment. The elapsed time of the end hourly segment is then calculated, which is the end time of the actual usage timestamp minus the start time of the end hourly segment = 740-720 (i.e., 12:20-12:00) = 20 minutes. The elapsed time is multiplied by the allocation ratio to obtain the accumulated actual usage time of the end hourly segment, i.e., 20 minutes x 0.789 = 15.78, or 16 minutes.

[0090] Finally, the calculation was verified: 12 minutes + 47 minutes + 16 minutes = 75 minutes. The result was compared with the actual accumulated usage time, and the result was correct. Therefore, the final allocation was 10:12, 11:47, and 12:16.

[0091] If, due to rounding, the calculated total minutes deviate from the actual accumulated usage time (i.e., are greater or less), the deviation will be included in the final hour segment. Specifically, if the calculated total minutes is 76 minutes, which is 1 minute greater than the actual accumulated usage time, then that 1 minute will be subtracted from the 16 minutes in the final hour segment, resulting in a time allocation of 15 minutes for the final hour segment. Conversely, if the calculated total minutes is 74 minutes, which is 1 minute less than the actual accumulated usage time, then that 1 minute will be added to the 16 minutes in the final hour segment, resulting in a time allocation of 17 minutes for the final hour segment. This allocation based on actual usage proportions more comprehensively and accurately reflects the child's usage distribution.

[0092] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system, equipment, device, module or unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0093] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such quantities can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0094] It should be understood that in this application, "at least one (item)" means one or more, and "more than" means two or more. "And / or" is used to describe the relationship between related objects, indicating that three relationships can exist. For example, "A and / or B" can represent three cases: only A exists, only B exists, and both A and B exist simultaneously, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship. "At least one (item) of the following" or similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one (item) of a, b, or c can represent: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0095] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A method for cross-platform remote management of electronic devices, characterized in that, include: S1. Divide the total monitoring cycle into several unit monitoring cycles and use a timer to monitor them in a loop; S2. When the unit monitoring cycle expires, a monitoring event will be triggered, and the timestamp interval of the unit monitoring cycle, the cumulative usage increment, and the usage evaluation status will be collected. S3. When the cumulative usage time is not 0, compare the timestamp interval with the cumulative usage time. If 0 < cumulative usage time < timestamp interval within a unit monitoring period, then the actual usage time of that unit monitoring period is equal to the cumulative usage time; otherwise, the actual usage time is equal to the timestamp interval. This yields the actual usage time for each unit monitoring period. S4. Select the unit monitoring cycle for the start and end of use based on the usage evaluation status, and sum up the actual usage time of all unit monitoring cycles from the start to the end of use to obtain the total actual usage time.

2. The method for cross-platform remote management of electronic devices according to claim 1, characterized in that: The condition for the expiration of the unit monitoring cycle in S2 is that a countdown occurs in each unit monitoring cycle, and a monitoring event is triggered after the countdown ends. Alternatively, a time threshold can be set for each monitoring cycle, and a monitoring event can be triggered when the time threshold is reached.

3. The method for cross-platform remote management of electronic devices according to claim 2, characterized in that: Each time a monitoring event is triggered, the timer is calibrated with the system clock.

4. The method for cross-platform remote management of electronic devices according to claim 1, characterized in that: In S2, the timestamp when the monitoring event is triggered is collected, and then the interval between the two timestamps is calculated based on the timestamp of the current monitoring cycle and the timestamp of the previous adjacent monitoring cycle to obtain the timestamp interval of the current monitoring cycle. In step S2, the total cumulative usage time from the start of the total monitoring cycle to the current monitoring cycle is collected, and then the total cumulative usage time of the previous adjacent monitoring cycle is subtracted from the current total cumulative usage time to obtain the current cumulative usage time increment.

5. The method for cross-platform remote management of electronic devices according to claim 1, characterized in that: In S3, a fault tolerance threshold is added. If the difference between the timestamp interval and the cumulative usage time is less than the fault tolerance threshold, then the actual usage time = timestamp interval. Conversely, if the difference between the timestamp interval and the cumulative usage time is greater than the fault tolerance threshold, then the actual usage time equals the cumulative usage time.

6. The method for cross-platform remote management of electronic devices according to claim 1, characterized in that: In step S4, the timestamp intervals of all unit monitoring cycles from the start to the end of the evaluation status are accumulated to obtain the actual usage timestamp accumulation. Then, the actual usage accumulation time corresponding to the actual usage timestamp accumulation within the same hour interval is statistically output together.

7. The method for cross-platform remote management of electronic devices according to claim 6, characterized in that: The start and end times of actual cumulative usage will be converted into absolute minutes from the start of the total monitoring cycle. If the usage is continuous and uninterrupted, the actual cumulative usage time = the actual usage timestamp accumulation. The actual cumulative usage time is then allocated according to the hour intervals described by the actual usage timestamp accumulation. If there are continuous interruptions in the usage process, first calculate the proportion of the actual usage accumulated time to the actual usage timestamp accumulated time, and then multiply the quota allocated to the hour interval by the actual usage accumulated time according to the actual usage timestamp accumulated time, and then allocate it to each hour interval.

Images