Dynamic pre-caching method and system and related equipment

Abstract

The invention discloses a dynamic pre-caching method and system and related equipment, and the method comprises the steps: building a preference matrix through analyzing the historical use habits of multiple pieces of equipment of a user, predicting the future position and time in combination with the historical position and real-time data of the user, evaluating the real-time state of the equipment, selecting target equipment, and generating a pre-caching instruction; and the purposes of improving the cross-device and cross-scene data access efficiency of the user, reducing loading waiting and optimizing the use experience are achieved.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology and relates to a dynamic pre-caching method, system and related equipment. Background Technology

[0002] In the current field of smartphone and other smart device technology, traditional pre-caching methods typically rely solely on historical access data from a single device or fixed rules (such as prioritizing high-frequency data) for caching. This makes it difficult to accurately match the different usage habits of users across multiple devices, and it fails to dynamically adjust based on user location movement patterns, time periodicity, and real-time device status (such as battery level, storage space, and network connectivity). This results in pre-cached content often not matching the user's actual future usage scenarios (such as specific locations or time periods), or failing to execute caching due to temporary unavailability of the target device (such as insufficient battery or storage space), ultimately leading to wasted cache resources. Users still need to wait for data loading when switching devices or entering new scenarios, resulting in a poor user experience. Summary of the Invention

[0003] This invention provides a dynamic pre-caching method, system, and related equipment. By analyzing the user's historical usage habits across multiple devices to construct a preference matrix, combining the user's historical location with real-time data to predict future location and time, evaluating the real-time status of the device to select the target device, and generating pre-caching instructions, the invention aims to improve the efficiency of cross-device and cross-scenario data access, reduce loading wait, and optimize the user experience.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: A dynamic pre-caching method includes the following steps: S1. Based on the historical request data of multiple candidate devices of the user, construct a preference matrix, which is used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in the corresponding location and time period; S2. Obtain user's historical location data and real-time dynamic data, extract multi-dimensional dynamic features based on the user's historical location data and real-time dynamic data, and determine the user's future location and the future time corresponding to the future location based on the multi-dimensional dynamic features; S3. Obtain the status data of the user's candidate devices, and based on the status data and the preference matrix, evaluate the historical usage tendency and real-time availability of each candidate device at the future location and the future time, determine the usage probability of each candidate device, and select the candidate device with the highest usage probability as the target device; S4. Based on the future location, the future time, and the preference matrix, generate a pre-cached instruction to be allocated to the target device; S5. Send the pre-caching instruction to the target device so that the target device performs a pre-caching operation.

[0005] Furthermore, the step of constructing a preference matrix based on historical request data from multiple candidate devices, wherein the preference matrix is ​​used to characterize the frequency distribution of each candidate device accessing the corresponding type of data within a corresponding location and time period, includes the following steps: S11. Obtain request data for multiple candidate devices of the user. The request data includes the device's unique identifier ID, the type of APP requested by the device, the specific data type accessed, the access timestamp, the duration of a single access, and the location information at the time of access. S12. Preprocess the device's unique identifier ID, the type of APP requested by the device, the specific data type accessed, the access timestamp, the duration of a single access, and the location information at the time of access to obtain a set of associated features related to the device identifier, data type, time period, and location; S13. Based on the set of associated features, construct the preference matrix, which is used to characterize the frequency distribution of the candidate device accessing the corresponding type of data in the corresponding location and time period.

[0006] Furthermore, the step of acquiring the status data of the user's candidate devices, evaluating the historical usage tendency and real-time availability of each candidate device at the future location and future time based on the status data and the preference matrix, determining the usage probability of each candidate device, and selecting the candidate device with the highest usage probability as the target device includes the following steps: S21. Obtain the user's historical location data and the real-time dynamic data, and preprocess the user's historical location data and the real-time dynamic data to obtain location dynamic data; S22. Extract location time features, movement features, and environmental association features based on the aforementioned location dynamic data; S23. Based on the location-time features, the movement features, and the environmental association features, determine the probability distribution of the user's location at the target time point, select the location with the highest confidence in the location probability distribution as the future location, and determine the target time period corresponding to the arrival at the future location as the future time.

[0007] Furthermore, generating pre-cached instructions for the target device based on the future location, the future time, and the preference matrix includes the following steps: S31. Obtain the status data, associate the status data with the historical behavior data of the corresponding device in the preference matrix, and form an associated dataset including device information, time information, location information and status information; S32. Based on the future location and the future time, filter out historical related records from the related dataset; S33. Based on the historical association records, determine the candidate device with the highest probability of use at the future location and at the future time as the target device.

[0008] Furthermore, the step of determining the candidate device with the highest probability of use at the future location and at the future time as the target device based on the historical association records further includes: S34. Based on the status data, determine whether the target device can be used; S35. If so, the pre-caching instruction is sent to the target device to cause the target device to perform a pre-caching operation; If not, based on the historical association records, exclude the unusable target devices, re-determine the candidate devices with the highest probability of use at the future location and the future time, and define the re-determined candidate devices as the target devices.

[0009] Furthermore, generating pre-cached instructions for the target device based on the future location, the future time, and the preference matrix includes the following steps: S41. Filter user behavior data associated with the future location, the future time, and the target device from the preference matrix; S42. Obtain the caching capability parameters of the target device, and based on the user behavior data and the caching capability parameters, filter the target data categories that need to be pre-cached and the content identifiers corresponding to the target data categories; S43. Generate the pre-caching instruction based on the target data category, the content identifier, and the cache path pre-configured on the target device.

[0010] Furthermore, it also includes: S6. When a user switches from the currently used target device to another candidate device, the content identifier of the data cached by the target device is matched based on the candidate device after the switch. If the match is successful, the pre-cached data that has been successfully matched is obtained from the target device based on the candidate device after the switch.

[0011] A dynamic pre-caching system for performing the dynamic pre-caching method, comprising: The data processing module is used to construct a preference matrix based on historical request data from multiple candidate devices of a user. The preference matrix is ​​used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in the corresponding location and time period. The time-space prediction module is used to acquire user historical location data and real-time dynamic data, extract multi-dimensional dynamic features based on the user historical location data and the real-time dynamic data, and determine the user's future location and the future time corresponding to the future location based on the multi-dimensional dynamic features. The device selection module is used to acquire the status data of the user's candidate devices, evaluate the historical usage tendency and real-time availability of each candidate device at the future location and the future time based on the status data and the preference matrix, determine the usage probability of each candidate device, and select the candidate device with the highest usage probability as the target device. The instruction generation module is used to generate pre-cached instructions to be allocated to the target device based on the future location, the future time, and the preference matrix. The instruction execution module is used to send the pre-caching instruction to the target device so that the target device performs a pre-caching operation.

[0012] A computer device includes a memory and a processor, the memory storing computer-readable instructions, wherein the processor, when executing the computer-readable instructions, implements the steps of the dynamic pre-caching method.

[0013] A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the dynamic pre-caching method.

[0014] The beneficial effects of this invention are as follows: The dynamic pre-caching method of this invention constructs a multi-device preference matrix to accurately capture the frequency distribution of users accessing corresponding types of data on various devices in different locations and time periods. It combines historical user location data with real-time dynamic data to predict future locations and corresponding times. Then, based on device status data and the preference matrix, it evaluates the usage probability of each candidate device and selects the target device. Finally, it generates and sends a pre-caching instruction. This effectively solves the limitations of traditional pre-caching methods that rely only on historical data or fixed rules of a single device and do not take into account user location movement patterns, time periodicity characteristics, and real-time device status. It avoids the waste of cache resources caused by the mismatch between pre-cached content and the user's future actual usage scenario or the temporary unavailability of the target device. It also reduces the data loading wait time for users when switching devices or arriving at new scenarios. At the same time, through multi-device collaboration and accurate scenario matching, it improves the targeting and effectiveness of pre-caching and optimizes the user experience when using the device across devices and scenarios. Attached Figure Description

[0015] Figure 1 This is a schematic diagram of the method steps of the present invention.

[0016] Figure 2 This is a schematic diagram illustrating the steps of constructing the preference matrix according to the present invention.

[0017] Figure 3 This is a schematic diagram of the steps in the method for determining future time according to the present invention.

[0018] Figure 4 This is a schematic diagram of the method steps for determining the target device according to the present invention.

[0019] Figure 5 This is a schematic diagram of the steps in the method for generating pre-cached instructions according to the present invention. Detailed Implementation

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains; the terminology used herein in the specification is for the purpose of describing particular embodiments only and is not intended to limit the invention; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings are used to distinguish different objects and not to describe a particular order.

[0021] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0022] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. Specific Implementation Example 1 This invention provides an appendix Figures 1-5 In this embodiment of the invention, a dynamic pre-caching method includes the following steps: S1. Based on the historical request data of multiple candidate devices of the user, construct a preference matrix, which is used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in the corresponding location and time period; In this embodiment, multiple candidate devices for a user refer to multiple smart devices owned by the user that may be used in different scenarios, such as smartphones, tablets, and laptops.

[0024] Historical request data refers to records related to data access generated during the past use of these devices, covering the device's unique identifier ID, the type of the requested app (such as social, video, office, etc.), the specific data type accessed (such as short videos, documents, images, etc.), the access timestamp, the duration of a single access, and the location information at the time of access (such as home, office, subway, etc.).

[0025] A preference matrix is ​​constructed by preprocessing historical request data (such as cleaning redundant data, converting timestamps into time period labels, and mapping latitude and longitude to location scene labels) to extract a set of associated features related to device identification, data type, time period, and location. For example, the matrix can be presented as follows: mobile phones access short videos 10 times a day during "home - evening hours," and tablets access documents 5 times a day during "office - morning hours," thus intuitively reflecting the device's access preferences in different scenarios.

[0026] S2. Obtain user's historical location data and real-time dynamic data, extract multi-dimensional dynamic features based on the user's historical location data and real-time dynamic data, and determine the user's future location and the future time corresponding to the future location based on the multi-dimensional dynamic features; In this embodiment, the user's historical location data is the user's location record over a period of time, such as home address, company address, and frequently visited shopping mall locations obtained through the device's GPS.

[0027] Real-time dynamic data includes the user's current location information, movement speed, movement direction, as well as external information that may affect the user's movement, such as real-time traffic conditions and weather conditions.

[0028] Multidimensional dynamic features include location and time features (e.g., users are often at the office at 9 am on weekdays), mobility features (e.g., users' average commuting speed is 30 km / h), and environmental features (e.g., users tend to choose indoor places on rainy days).

[0029] Future location and future time are predicted through analysis of multi-dimensional dynamic features. For example, based on a user's historical record of leaving the company at 6 PM on Friday and arriving at the mall 30 minutes later, and the current real-time traffic conditions, it is predicted that the user will arrive at the mall at 6:30 PM this Friday.

[0030] S3. Obtain the status data of the user's candidate devices, and based on the status data and the preference matrix, evaluate the historical usage tendency and real-time availability of each candidate device at the future location and the future time, determine the usage probability of each candidate device, and select the candidate device with the highest usage probability as the target device; In this embodiment, the status data of the candidate device includes the device's current battery level (e.g., 80% battery on a mobile phone), remaining storage space (e.g., 20GB remaining on a tablet), and network connection status (e.g., a laptop connected to Wi-Fi).

[0031] Historical usage tendency refers to the frequency of device use in scenarios with similar locations and times in the past and future. For example, in a shopping mall setting in the past, users accessed shopping apps more frequently using their mobile phones than their tablets.

[0032] Real-time availability is based on status data to determine whether a device can meet pre-caching and subsequent usage needs. For example, a device with less than 20% battery may not be able to complete caching due to insufficient power, resulting in low real-time availability.

[0033] The probability of use is a quantitative result derived by comprehensively considering historical usage patterns and real-time availability. For example, if a mobile phone has a high historical usage frequency in a shopping mall setting and currently has sufficient battery and storage space, its usage probability is 80%; if the tablet's usage probability is 30%, then the mobile phone is chosen as the target device.

[0034] S4. Based on the future location, the future time, and the preference matrix, generate a pre-cached instruction to be allocated to the target device; In this embodiment, the pre-caching instruction is an instruction that guides the target device to perform a pre-caching operation. Its content is determined based on the future location, future time, and preference matrix. For example, considering that the future location is a shopping mall, the future time is 6:30 PM, and the mobile phone frequently accesses image data from shopping apps in this scenario, the generated instruction may include information such as the data type, quantity (e.g., 5 images), and storage path of the shopping app images that need to be pre-cached.

[0035] S5. Send the pre-caching instruction to the target device so that the target device performs a pre-caching operation.

[0036] In this embodiment, this step involves sending the generated pre-caching instruction to the target device via device-to-device communication methods (such as Bluetooth or Wi-Fi). Upon receiving the instruction, the target device automatically downloads and stores the corresponding data as required, completing the pre-caching operation. For example, after receiving the pre-caching instruction, the mobile phone automatically downloads five images from shopping apps and stores them in a designated folder.

[0037] The dynamic pre-caching method of this invention constructs a multi-device preference matrix to accurately capture the frequency distribution of users accessing corresponding types of data on various devices in different locations and time periods. It combines historical user location data with real-time dynamic data to predict future locations and corresponding times. Then, based on device status data and the preference matrix, it evaluates the usage probability of each candidate device and selects the target device. Finally, it generates and sends a pre-caching instruction. This effectively solves the limitations of traditional pre-caching methods that rely only on historical data or fixed rules of a single device and do not take into account user location movement patterns, time periodicity, and real-time device status. It avoids the waste of cache resources caused by the mismatch between pre-cached content and the user's future actual usage scenario or the temporary unavailability of the target device. It also reduces the data loading wait time for users when switching devices or arriving at new scenarios. At the same time, through multi-device collaboration and accurate scenario matching, it improves the targeting and effectiveness of pre-caching and optimizes the user experience when using the device across devices and scenarios. Specific Implementation Example 2 The step of constructing a preference matrix based on historical request data from multiple candidate devices of a user, wherein the preference matrix is ​​used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in a corresponding location and time period, includes the following steps: S11. Obtain request data for multiple candidate devices of the user. The request data includes the device's unique identifier ID, the type of APP requested by the device, the specific data type accessed, the access timestamp, the duration of a single access, and the location information at the time of access. This step primarily involves acquiring data from multiple candidate devices. Before acquiring the data, multiple devices can be bound to each other, providing conditions for data acquisition. This can be done based on user accounts (such as mobile phone numbers and social media accounts) and near-field communication technologies (such as Bluetooth and NFC), binding multiple devices of the user (such as mobile phone A, tablet B, and laptop C) to establish a relationship between user ID and device ID. This allows devices to exchange data through user accounts or through authorized interconnection via Bluetooth. The interconnection between devices includes, but is not limited to, the methods mentioned above.

[0039] Through the system's backend interface, request data from multiple devices was collected continuously over several days. This request data included the device's unique identifier ID, the type of app requested, the specific data type accessed, the access timestamp, the duration of each access, and the location information at the time of access. User device usage behavior is complex and multi-dimensional; single-dimensional data cannot fully reflect their true needs. For example, knowing only that a user uses a "video app" but not knowing whether they accessed a "short video" or a "long video" prevents the system from accurately determining cached content. Similarly, knowing only that a user uses their device "at night" but not knowing whether their specific location is "at home" or "commuting" makes it impossible to predict needs based on the scenario. Therefore, comprehensive collection of multi-dimensional data (device identifier, app type, data type, time, duration, and location) is necessary to reconstruct a complete profile of user behavior.

[0040] The unique device identifier (ID) distinguishes different devices (such as mobile phones, tablets, and laptops), clearly defining the user of each device and avoiding confusion of behavioral data across different devices. For example, a user might frequently use entertainment apps on a mobile phone and office apps on a laptop. The ID can record the behavioral characteristics of each device separately, providing a basis for subsequently allocating different cached content to different devices. The type of app requested by the device reflects the user's core usage scenario (such as social, video, and office), helping the system identify the user's main needs. For example, "social apps" typically require text or message data, while "office apps" require document or spreadsheet data. The app type can initially define the scope of cached content, avoiding invalid caching. The specific data type accessed refines the granularity of user needs, differentiating different content preferences within the same app. For example, even within "video apps," users might more frequently access "short videos" than "long videos," or be more interested in "food" videos than "technology" videos. Specific data types help the system accurately locate the content the user truly needs, improving the targeting of caching. Access timestamps record the time patterns of user behavior (e.g., morning, evening, weekday, weekend), revealing users' usage time preferences. For example, users may frequently use entertainment apps between 7:00 PM and 9:00 PM and frequently use office apps between 9:00 AM and 11:00 AM on weekdays. Timestamps provide a basis for predicting future user usage time, ensuring that cached content is ready when users need it. Single access duration quantifies a user's level of interest in a particular type of data. For example, users typically spend 60-180 seconds on "short videos" and 30-60 seconds on "text and image messages," indicating that users prefer immersive video viewing. The system can prioritize caching video content to improve the experience. If the access duration for a certain type of data is extremely short (e.g., 5 seconds), it may be a mistake, and the system can lower its caching priority to avoid wasting resources. Location information during access is linked to the user's usage scenario (such as at home, at work, or commuting). Combining location with other data items (time, app type) allows for further refinement of requirements. For example, if a user uses a video app during the evening hours at their "home" location, high-definition short videos may need to be cached; if they use a news app during the morning hours at their "commuting" location, lightweight text and images may need to be cached (to avoid loading issues due to network instability). Location information makes caching strategies more closely aligned with actual usage scenarios.

[0041] By collecting the aforementioned multi-dimensional data, the system can construct a user preference model for data types across different devices, scenarios, and times (i.e., the preference matrix in subsequent steps). This model can accurately predict the devices, apps, and data types that users are most likely to use in the future, thereby caching relevant content to the target device in advance. This avoids impacting the user experience due to waiting for loading and reduces the storage space occupied by invalid caching.

[0042] The above data is exemplified below: Unique Device Identifier ID: DEV-001 (Mobile Phone), DEV-002 (Tablet), DEV-003 (Laptop); The types of apps requested by the devices: Mobile phones frequently request "social apps" (WeChat, QQ) and "video apps" (TikTok); Tablets frequently request "learning apps" (Easy); Laptops frequently request "office apps" (WPS). The specific data types accessed are as follows: mobile phones access "short videos" and "text and image messages"; tablets access "teaching videos" and "electronic courseware"; and laptops access "document templates" and "meeting minutes". Access timestamps: Typical timestamps for mobile phones are "2025-06-01 19:30:00" (evening) and "2025-06-02 12:15:00" (midday); typical timestamps for tablets are "2025-06-01 10:00:00" (morning); typical timestamps for laptops are "2025-06-01 09:00:00" (weekday morning). Duration of a single visit: The duration of a short video on a mobile phone is mostly 60-180 seconds; the duration of an instructional video on a tablet is mostly 300-600 seconds; and the duration of a document template on a laptop is mostly 120-300 seconds. Location information during access: The location coordinates of mobile phones are "30.12°, 120.45°" (corresponding to the "home" scenario) and "31.23°, 121.40°" (corresponding to the "office" scenario); the location of tablets is mostly "30.12°, 120.45°" (home); the location of laptops is mostly "31.23°, 121.40°" (office).

[0043] Based on the above data, we can also obtain the size of the data file corresponding to each request, such as 50MB for short videos and 22KB for document reading, so as to evaluate whether the device's caching capacity can handle the loading of the data.

[0044] S12. Preprocess the device's unique identifier ID, the type of APP requested by the device, the specific data type accessed, the access timestamp, the duration of a single access, and the location information at the time of access to obtain a set of associated features related to the device identifier, data type, time period, and location; In this step, while the raw request data contains key information about user behavior, it suffers from limitations such as data redundancy, unstructured nature, and information dispersion. Data redundancy arises because the raw data may contain duplicate records (e.g., multiple requests for the same data from the same device within a short period) or invalid data (e.g., empty requests when the device is offline). Unstructured nature occurs because timestamps are specific time points (e.g., "2025-06-01 19:30:00") and locations are latitude and longitude coordinates (e.g., "30.12°, 120.45°"). These raw formats cannot be directly used for analysis. Information dispersion occurs because dimensions such as device ID, app type, and data type are independent and lack interrelationships (e.g., a device frequently accessing a certain type of data at a specific time and location). Directly using the raw data to construct a preference matrix would result in an excessively high dimensionality, overlapping information, and even noise interference, failing to accurately reflect the user's true preferences. Therefore, preprocessing is necessary to transform the raw data into structured, relational features.

[0045] The "set of associated features of device identifier, data type, time period, and location" extracted after preprocessing essentially integrates the key dimensions (device, data, time, and location) in the original data into "behavioral pattern labels" through logical association. Its core function and effect are reflected in the following aspects: The preprocessing process cleans the original data (such as removing invalid requests and merging duplicate records) to ensure that subsequent analysis is based on real and valid behavioral data. For example, it filters out "empty requests when the device is offline" to avoid misjudgments of "devices accessing invalid data frequently" in the matrix; it converts timestamps into labels such as "morning time period" and "evening time period", latitude and longitude into scene labels such as "home" and "office", and classifies specific data types into upper-level labels such as "media" and "office", essentially transforming the original data from "scattered points" into "comparable classes". This process reduces the data dimensionality (such as simplifying hundreds or thousands of specific time points into a few time period labels), so that the subsequent construction of the preference matrix does not require processing massive discrete data, significantly improving analysis efficiency; the core of the associated feature set is cross-analysis, that is, discovering the patterns of user behavior through the combination of device, data type, time period, and location. For example, preprocessing might yield a set of associated features such as "Device A frequently accesses 'media' data during the 'home-evening' period." This feature directly reflects the core needs of users using Device A in the "home-evening" scenario, providing a clear basis for predicting "which device is most likely to access media data in the future during the home-evening period." The essence of the preference matrix is ​​a quantitative mapping table of "device-scenario-needs," and its construction relies on a comparable and computable set of associated features. If the original data is not preprocessed, the matrix will fail to effectively reflect patterns due to dimensional inconsistencies (e.g., the time dimension being a specific time point, and the location dimension being latitude and longitude). However, the preprocessed set of associated features (e.g., "home-evening-media") serves as the column labels of the matrix, directly corresponding to the device ID (matrix row labels). The frequency value (e.g., "12 times / week") visually displays user preferences, enabling the system to quickly locate "which device needs to cache which type of data in which scenario," ultimately improving the accuracy of pre-caching.

[0046] The raw data collected was cleaned and structured as follows: Device Identification: Retain a unique ID (such as DEV-001, DEV-002, DEV-003) and filter invalid request records from offline devices; Data types: Categorize specific data types into upper-level tags (e.g., "short videos" and "text / image messages" are categorized as "media"; "teaching videos" and "electronic courseware" are categorized as "education"; "document templates" and "meeting minutes" are categorized as "office"). Time period: Divide the timestamps into 4-hour units (e.g., "08:00-12:00" is the "morning period", "18:00-22:00" is the "evening period"); Location information: Map latitude and longitude to scene labels (e.g., "30.12°, 120.45°" is mapped to "Home", "31.23°, 121.40°" is mapped to "Company"); Feature set extraction: Through cross-analysis, the correlation between devices and data types, time periods, and locations is obtained (e.g., "DEV-001 (mobile phone) frequently accesses 'media' data during the 'home-evening' period" and "DEV-003 (laptop) frequently accesses 'office' data during the 'work-morning' period").

[0047] Through S12's preprocessing and associated feature set extraction, the raw data is transformed from "scattered behavioral records" into "structured behavioral pattern labels." This not only reduces the complexity of subsequent analysis but, more importantly, reveals the inherent patterns of user behavior (such as "a device frequently accesses a certain type of data at a certain time and location"). These patterns are the core basis for constructing the preference matrix and directly determine whether the dynamic pre-caching system can accurately predict future user needs and allocate reasonable cached content to target devices, thereby achieving an efficient experience where "the required data is pre-cached when the user arrives at the target location." In short, S12 is a crucial bridge connecting "raw data acquisition" and "preference model construction," and the quality of its preprocessing and associated feature set extraction directly affects the practicality and effectiveness of the dynamic pre-caching method.

[0048] S13. Based on the set of associated features, construct the preference matrix, which is used to characterize the frequency distribution of the candidate device accessing the corresponding type of data in the corresponding location and time period.

[0049] In this step, although the user's device usage behavior has been preprocessed to extract a set of associated features (such as "Device A frequently accesses media data at home in the evening"), these features are still discrete descriptive conclusions and cannot be directly used for the system's automated decision-making. For example, knowing only that "Device A frequently accesses media data at home in the evening" but not quantifying "how high a frequency is considered 'frequent access'" means the system still cannot determine whether to pre-cache media data for Device A in the evening home scenario. Therefore, it is necessary to transform the set of associated features into a frequency distribution table of "device-scenario-data type" in matrix form, enabling the system to objectively assess the intensity of user demand based on specific values ​​(such as "12 times / week"), thereby making a scientific caching decision.

[0050] While the set of associated features reveals the "patterns" of user behavior (e.g., "a device tends to access a certain type of data in a certain scenario"), it does not reflect the "intensity" (e.g., "the frequency of this tendency"). The preference matrix, through the quantitative indicator of "frequency distribution" (e.g., "times / week"), upgrades user preferences for a certain type of data from qualitative description to quantitative analysis. For example, in the matrix, "Device A accesses media data 12 times / week at home in the evening" is more valuable for decision-making than "Device A frequently accesses media data." The system can determine whether to pre-cache this type of data based on a frequency threshold (e.g., "≥10 times / week"). The core of dynamic pre-caching is "anticipating user needs in advance," and the key to this prediction lies in the "regularity of historical behavior." The preference matrix intuitively shows "which device is most likely to access which type of data in which location and at which time" through frequency distribution. The system can directly prioritize caching the corresponding data to the target device based on the high-frequency entries in the matrix (e.g., "Device A - Home in the evening - Media" has the highest frequency).

[0051] Specifically, the frequency distribution of data types accessed by the device in different locations and time periods is quantified in matrix form: Matrix row: Candidate device IDs (DEV-001, DEV-002, DEV-003); Matrix column: Combined tags (formatted as "location-time period-data type", such as "home-evening-media" or "company-morning-office"). Matrix value: The frequency of access to the corresponding device under this combination tag (unit: times / week).

[0052] Example as follows: Specific Implementation Example 3 The process of acquiring the status data of the user's candidate devices, evaluating the historical usage tendency and real-time availability of each candidate device at the future location and future time based on the status data and the preference matrix, determining the usage probability of each candidate device, and selecting the candidate device with the highest usage probability as the target device includes the following steps: S21. Obtain the user's historical location data and the real-time dynamic data, and preprocess the user's historical location data and the real-time dynamic data to obtain location dynamic data; In this step, the key to dynamic pre-caching lies in predicting the user's future location and time based on the regularity of historical behavior and the real-time nature of the current state. However, the original historical location data and real-time dynamic data have the following limitations and cannot be directly used for analysis: First, data noise, such as anomalies in historical location data due to weak GPS signals or equipment failures (the user is actually at home but the recorded latitude and longitude deviates from the nearby road), and location jumps in real-time dynamic data due to network latency (the recorded location suddenly shifts by 1 kilometer when the user is stationary); Second, data redundancy, such as repeated latitude and longitude records frequently reported by the user when staying at the same location, and temporary irrelevant location points where the user temporarily detoured; Third, unstructured data, as the original data usually exists in the form of discrete latitude and longitude coordinates, timestamps, etc. (e.g., "2025-06-01 08:15:00 30.12°, 120.45°"), lacking the contextual association of "at home" and "commuting", and cannot directly reflect the user's movement patterns or behavior patterns. If raw data is used directly to predict future locations, prediction errors may occur due to noise interference or information dispersion (such as misjudging abnormal locations as new user habits). Therefore, it is necessary to preprocess the data to transform it into high-quality, structured dynamic location data.

[0053] In this embodiment, the preprocessing process mainly transforms the raw data into location dynamic data through the following steps: First, data cleaning is performed to remove abnormal data (such as isolated points whose latitude and longitude deviate from the user's residence by more than 2 kilometers) and merge duplicate records (such as simplifying 10 identical latitude and longitude records reported per minute to 1 record when the user stays in the same location), retaining the true and valid location trajectory; Next, format unification and supplementation are performed to map discrete latitude and longitude coordinates to scene labels such as "home", "office", and "commuting route", and timestamps and movement speeds are supplemented by calculating the time difference and distance between adjacent location points to form a structured record of "time-location-speed" (such as "2025-06-01 08:15:00 Home speed 0km / h"); Finally, historical location data and real-time dynamic data are linked and integrated according to the timeline to form a continuous location trajectory (such as "historical: home → office → home; real-time: current location home, speed 5km / h"), providing a complete context for subsequent analysis of user movement patterns.

[0054] The specific implementation steps for this step are as follows: Data Acquisition: Through the GPS modules of users' mobile phones, tablets, and other devices, historical location data of users is collected continuously for 30 days (e.g., the location trajectory from 8:00 to 9:00 on June 1, 2025 is "Home (30.12°, 120.45°) → Company (31.23°, 121.40°)"); real-time dynamic data is acquired simultaneously (e.g., the user's current location at 7:30 on June 30, 2025 is "Home (30.12°, 120.45°)", and the moving speed is "5km / h").

[0055] Data preprocessing: Historical location data and real-time dynamic data are cleaned (abnormal latitude and longitude points caused by weak signals are removed), format is unified (latitude and longitude are converted into coordinate values ​​in the geographic coordinate system), and timestamps are added (such as marking the specific time for each location point), finally resulting in structured location dynamic data (such as "2025-06-01 08:15:00 Location: 30.12°, 120.45° (home), moving speed: 4km / h").

[0056] S22. Extract location time features, movement features, and environmental association features based on the aforementioned location dynamic data; In this step, the core objective of dynamic pre-caching is to allocate cached content to the target device in advance by predicting the user's future location and time. However, simply having preprocessed location dynamic data (such as structured records of "time-scene-speed") that has been resolved to eliminate noise, redundancy, and unstructured issues is insufficient, as it is essentially the "raw trajectory" of user behavior and cannot be directly used for prediction. Specifically, location dynamic data needs to further answer the following key questions to support prediction: When are users more likely to be in which locations (e.g., "often on commuting routes from 7:30 to 8:30 am on weekdays")? What are the patterns in the user's movement patterns (e.g., "average speed during commuting is 30 km / h, slower speed on weekends")? Do external environmental factors (such as weather and traffic) affect the user's location choices (e.g., "more inclined to take a taxi on rainy days, which may change commuting time")? Extracting location-time features, movement features, and environmental correlation features is the key step in transforming the "raw trajectory" into "predictable behavioral patterns." By quantifying these three types of features, the system can build a user behavior model and thus achieve accurate prediction of future location and time.

[0057] This step of feature extraction mainly focuses on three categories: location-time features, movement features, and environmental association features. It utilizes preprocessed dynamic location data (such as "time-scene-speed" records) for statistical analysis and pattern mining. Location-time features are extracted by analyzing the correlation between time and location. For example, it involves statistically analyzing the user's high-frequency locations at different times (e.g., weekdays / weekends, morning / noon / evening) (e.g., "frequently appearing at the company on weekdays from 8:00-9:00 AM"), identifying location periodicity (e.g., "consistently appearing at the gym every Wednesday evening from 6:00-8:00 PM"), and calculating the distribution of location dwell time (e.g., "average dwell time at home is 12 hours / day, average dwell time at the company is 8 hours / day"). Movement features are extracted by analyzing the user's movement process. Dynamic patterns are extracted, such as movement speed characteristics (e.g., "average speed during commuting is 30km / h, average speed during shopping is 10km / h"), direction change characteristics (e.g., "the route from home to the company is fixed, with very few detours"), and acceleration characteristics (e.g., "speed gradually decreases as you approach the company, indicating that you are about to arrive"). Environmental correlation characteristics are extracted by associating location dynamic data with external environmental information (e.g., weather, traffic, and holidays). For example, the correlation between weather and location (e.g., "users are more likely to postpone their trips and have longer commuting times on rainy days"), the correlation between traffic conditions and movement speed (e.g., "commuting speed during the morning rush hour is 20% lower than during off-peak hours"), and the correlation between holidays and location patterns (e.g., "users spend 2 hours more at home and less time outdoors on weekends").

[0058] The specific implementation steps for this step are as follows: Location and time characteristics: By analyzing historical data, it was found that the user's location and time pattern from Monday to Friday is "07:30-08:30 at home → 08:30-09:00 commuting → 09:00-18:00 at the office"; and the location and time pattern on weekends is "08:00-12:00 at home → 14:00-17:00 shopping mall (30.20°, 120.50°)".

[0059] Mobility characteristics: The average speed of users commuting on weekdays is "15-20km / h" (corresponding to driving), and the average speed of users going to shopping malls on weekends is "5-8km / h" (corresponding to walking); the commuting route is fixed as "home → Route A → company".

[0060] Environmental association features: Within 500 meters of the user's "Company" location (31.23°, 121.40°), there is a subway station (B station) and a convenience store; within 500 meters of the "Shopping Mall" location (30.20°, 120.50°), there are cinemas and restaurants. This environmental information is used to help determine the type of activity the user will engage in after arriving at the target location (e.g., the company scenario may correspond to office needs, and the shopping mall scenario may correspond to entertainment needs).

[0061] S23. Based on the location-time features, the movement features, and the environmental association features, determine the probability distribution of the user's location at the target time point, select the location with the highest confidence in the location probability distribution as the future location, and determine the target time period corresponding to the arrival at the future location as the future time.

[0062] In this step, the ultimate goal of dynamic pre-caching is to allocate cached content to the target device in advance by predicting the user's future location and time. Although S22 has extracted location and time features (such as "frequently at the company at 8 am on weekdays"), movement features (such as "stable commuting speed of 30km / h"), and environmental features (such as "delayed commuting on rainy days"), these features are essentially "regular descriptions" of user behavior. If they are not further transformed into specific "location-time prediction results," the system cannot directly provide a clear target for the pre-caching strategy (such as "the user will arrive at the company at 8:30, and frequently used APP resources near the company need to be cached in advance"). Therefore, the core function of this step is to transform the "regular description" into an "executable prediction result": by quantifying the probability of the user appearing in different locations at the target time, the most likely location and corresponding time period are selected, providing a clear "target location" and "target time" for the pre-caching strategy, ensuring that cached resources can be accurately allocated before the user arrives.

[0063] In this step, determining the probability distribution of user locations and the implementation of future time relies on a hybrid prediction model that integrates multiple features. This model employs a layered fusion architecture, comprising a base probability layer, a dynamic adjustment layer, and a time prediction layer. The base probability layer constructs a statistical model (such as a Hidden Markov Model (HMM) or Bayesian network) based on time features, outputting the base probability for each location at the target time point. The dynamic adjustment layer combines movement features with environmental correlation features, using machine learning models (such as random forests or LSTMs) to correct the base probability. The time prediction layer, for high-confidence locations, uses time series models (such as Prophet) or regression models to output the target time period for reaching that location. These three layers work together to achieve a complete prediction process from pattern analysis to dynamic correction.

[0064] The model input consists of numerical or structured data with three types of features: time, movement, and environment. Time features include periodic patterns (e.g., "90% probability of appearing at the gym on Wednesday at 18:00") and residence duration distribution (e.g., "average residence at home is 12 hours"), which are converted into time window probabilities and statistical distributions. Movement features include speed deviation (e.g., "-5km / h") and path similarity (0-100 points), which are derived from speed, acceleration, and path matching degree. Environmental features include weather (rainy day = 1), congestion level (1-10 points), and holidays (weekend = 1), which are encoded using binary or categorical variables to ensure that multi-dimensional features are adapted to model calculations.

[0065] The implementation process begins with basic probability calculations, using time features to train a statistical model (such as HMM) and output the basic probability of each location at the target time point (e.g., "Company 70%)". Then, a machine learning model (such as random forest) is used to adjust the probability by combining mobility and environmental features (e.g., "Rainy weather + congestion increases the company's probability to 84%)", and the location with the highest confidence is selected as the future location. Finally, for this location, the arrival time is calculated using a time series model, combining mobility and environmental features (e.g., "Base time 8:30 + delay of 5 minutes = 8:35"), and the time window is output (e.g., "8:30-8:40"), completing the end-to-end prediction from probability distribution to location and time.

[0066] The model ultimately outputs a location probability distribution (e.g., "company 84%, gym 10%"), a high-confidence future location (company), and a target time period (e.g., "8:30-8:40"). Through multi-feature fusion and hierarchical prediction, it retains the historical periodicity of user behavior (time features) while dynamically adapting to real-time movement status (movement features) and environmental changes (environmental features), thus improving the accuracy and robustness of location and time prediction. This provides precise target support for dynamic pre-buffering strategies in both location and time dimensions. Specific Implementation Example 4 The step of generating a pre-cached instruction for the target device based on the future location, the future time, and the preference matrix includes the following steps: S31. Obtain the status data, associate the user device status data with the preference matrix to form an associated dataset including device information, time information, location information and status information; In this step, the core objective of dynamic pre-caching is that "the target device has cached the content it needs when the user arrives at the future location." However, relying solely on the preference matrix (which reflects the user's historical behavioral patterns) cannot guarantee the actual availability of the device in the future—for example, a device that the user has used frequently in the past may not be able to receive caching instructions due to insufficient battery power, no network, or insufficient storage space. Therefore, it is necessary to correlate the device's current state (such as battery power, network, and storage space) with historical behavioral preferences to form a comprehensive evaluation basis of "behavioral patterns + real-time state," ensuring that the selected target devices not only conform to user habits but also have actual availability.

[0068] This step is implemented in two steps: First, the core status information of the candidate devices is collected in real time through the device management interface (such as the system API), including battery level (whether it is sufficient to support caching operations), network connection status (whether it can receive caching instructions), and remaining storage space (whether there is enough capacity to store cached content). This data reflects the current "available capacity" of the device. Then, using the device's unique identifier ID as a "bridge", the above device status data is associated with the device's historical behavior data in the preference matrix (such as the frequency distribution of "a device frequently accessing a certain type of data at a certain location and time period"). For example, for a mobile phone with device ID "DEV-001", its preference matrix records "home-evening-media data access frequency 11 times / week", and at the same time, its current "battery level 85%, Wi-Fi connection, remaining storage space 30GB" is obtained. Finally, it is integrated into an associated record containing device information (ID, type), time information (historical high-frequency time period), location information (historical high-frequency location), and status information (current battery level / network / storage).

[0069] The specific implementation of this step is as follows: First, the status data of multiple candidate devices of the user is obtained in real time through the device management interface, including the current battery level of the device (e.g., DEV-001 mobile phone battery 85%, DEV-002 tablet battery 60%, DEV-003 laptop battery 90%), network connection status (e.g., DEV-001 connected to Wi-Fi, DEV-002 connected to mobile data, DEV-003 no network), and remaining storage space (e.g., DEV-001 30GB remaining, DEV-002 15GB remaining, DEV-003 50GB remaining), and other key status information.

[0070] Subsequently, the acquired device status data is associated with the constructed preference matrix (such as the "Device ID-Location-Time Period-Data Type" frequency distribution matrix in Example 1). The association method is as follows: using the device ID as the key, the device status data (battery, network, storage space) is integrated with the access frequency data of the corresponding device in different locations and time periods in the preference matrix (such as "DEV-001 accesses office-related data twice / week in the morning at the company") to form an associated dataset containing device information (ID, type), time information (time period label), location information (scene label), and status information (battery, network, storage space).

[0071] The associated datasets are as follows: S32. Based on the future location and the future time, filter out historical related records from the related dataset; In this step, the core of dynamic pre-caching is "predicting the user's future scenarios (location + time) and allocating cached content for devices in that scenario in advance." However, the associated dataset (containing full-scale associated data of device status and historical behavior) covers all possible historical scenarios of the user (such as home-evening, office-morning, etc.). If the full dataset is used directly to evaluate the probability of device usage, it will introduce a large amount of redundant information unrelated to future scenarios (such as "shopping mall-afternoon" scenario data that the user will not visit in the future), causing device selection to deviate from actual needs. Therefore, it is necessary to filter out historical associated records that only match the predicted future location and time from the full dataset, focusing on the scenario that the user is about to experience, to ensure that subsequent device selection is more in line with actual needs.

[0072] Specifically, the filtering process is achieved through "scene label matching": First, the future scene is clearly predicted through the time-space prediction module, determining the user's future location (e.g., "company") and future time (e.g., "morning period"). Next, each record in the associated dataset contains structured classification labels for the user's historical location and time (e.g., "location label" and "time period label" that map latitude and longitude to "company" and timestamp to "morning period"), and these scene labels need to be matched. Finally, all records with "location label = future location" and "time period label = future time" are filtered out from the associated dataset to form historical associated records containing only the target scene. For example, if the future location is "company" and the future time is "morning period", then all device associated records with the location label "company" and the time period label "morning period" are filtered out.

[0073] Assuming that the user's future location is "company" and the future time is "morning period" based on prediction, records matching "location label = company" and "time period label = morning period" are filtered from the full dataset of S31 to form targeted data for the target scenario.

[0074] This step, by focusing on historical correlation records for future scenarios, enables the dynamic pre-caching system to achieve a dual improvement in "data accuracy" and "computational efficiency": First, it excludes scenario data that users will not encounter in the future (such as "shopping mall - afternoon"), ensuring that the calculation of device usage probability is based only on historical behaviors and states directly related to future scenarios, thus improving the accuracy of the evaluation results; Second, the amount of data after filtering is much smaller than the full dataset, reducing the complexity of subsequent probability calculations (such as not needing to traverse records for all locations and time periods), enabling the system to respond quickly and generate pre-caching instructions; At the same time, the filtered records clearly reflect "the user's historical behavior patterns and device states at the target location and time," providing a targeted basis for "determining the target device with the highest probability of use" and ensuring that the allocation of cached content is more in line with the user's actual needs (such as the company - morning hours are more likely to use office equipment).

[0075] S33. Based on the historical association records, determine the candidate device with the highest probability of use at the future location and at the future time as the target device.

[0076] In this step, the ultimate goal of dynamic pre-caching is to "enable devices to quickly access the required content in future user scenarios," and the key premise is that "cached content must be stored on the devices users are most likely to use." Randomly selecting devices or relying on full data allocation for caching might result in cached content being stored on devices users won't use in the future (e.g., caching office documents on a spare phone the user won't bring to work), wasting storage space and failing to improve user experience. Therefore, selecting the devices with the highest usage probability based on historical association records of the target scenario is essentially "precisely identifying the terminals users are most likely to use in the future," ensuring that cached content highly matches actual usage needs.

[0077] This step is accomplished through "scenario-based probability assessment": First, two key assessment dimensions for devices in the target scenario (future location + time) are extracted from historical association records—historical behavioral data (such as the frequency with which the device accesses a certain type of data, such as office documents, during the "company-morning period," including high-frequency, medium-frequency, and low-frequency) and status information (such as the device's availability in the target scenario, such as whether the battery is sufficient and whether the storage space is sufficient for caching). Next, based on the above dimensions, a probability assessment is performed on the devices in each historical association record. For example, devices that have historically accessed target data frequently and whose current status (battery / storage) can support caching operations will be given a higher probability of use, while those with lower probabilities will have a lower probability. Finally, the device with the highest probability of use is selected from all candidate devices as the final target device for storing pre-cached content.

[0078] The specific implementation of this step is as follows: In the selected historical records, the probability of each candidate device being used in the "company-morning time" scenario is calculated. The calculation logic for the probability of use is as follows: combining the access frequency in the preference matrix (reflecting the user's historical usage tendency) and the device status data (reflecting the device's current availability), and quantifying it through a weighted summation.

[0079] The specific calculation rules are as follows: Access frequency weight 0.6, device status weight 0.4 (device status includes 1 point for battery ≥50%, 1 point for network availability, 1 point for storage space ≥10GB, maximum score 3 points, normalized by 3 times the actual score).

[0080] For example, using sample data: DEV-001 (Mobile Phone): Access frequency 2 times / week (normalized value = 2 / 9 ≈ 0.222), device status score (battery 85% ≥ 50% → 1 point, network Wi-Fi available → 1 point, storage space 30GB ≥ 10GB → 1 point, total score 3 / 3 = 1), overall probability = 0.6 × 0.222 + 0.4 × 1 ≈ 0.533.

[0081] DEV-002 (Tablet): Access frequency 2 times / week (normalized value ≈ 0.222), device status score (battery 60% ≥ 50% → 1 point, network mobile data available → 1 point, storage space 15GB ≥ 10GB → 1 point, total score 3 / 3 = 1), overall probability = 0.6 × 0.222 + 0.4 × 1 ≈ 0.533.

[0082] DEV-003 (Laptop): Access frequency 9 times / week (normalized value = 9 / 9 = 1), device status score (battery 90% ≥ 50% → 1 point, network none → 0 points, storage space 50GB ≥ 10GB → 1 point, total score 2 / 3 ≈ 0.667), overall probability = 0.6 × 1 + 0.4 × 0.667 ≈ 0.867.

[0083] Ultimately, the DEV-003 (laptop) had the highest usage probability (0.867), and was therefore defined as the target device.

[0084] Through the above steps, the system accurately selects the target devices most likely to be used in the future location and time based on the user's historical behavior preferences and the current status of the devices, providing clear device targets for the generation of subsequent pre-cached instructions. Specific Implementation Example 5 Based on the historical association records, the process of determining the candidate device with the highest probability of use at the future location and the future time as the target device further includes: S34. Based on the status data, determine whether the target device can be used; In this step, the ultimate goal of dynamic pre-caching is to "enable devices to quickly access the required content in future user scenarios," and the key premise is that "cached content must be stored on the devices users are most likely to use." Randomly selecting devices or relying on full data allocation for caching might result in cached content being stored on devices users won't use in the future (e.g., caching office documents on a spare phone the user won't bring to work), wasting storage space and failing to improve user experience. Therefore, selecting the devices with the highest usage probability based on historical association records of the target scenario is essentially "precisely identifying the terminals users are most likely to use in the future," ensuring a high degree of match between cached content and actual usage needs.

[0086] This step is accomplished through scenario-based probability assessment: First, two key assessment dimensions of devices in the target scenario (future location + time) are integrated from historical association records—historical behavioral data (reflecting the frequency of a device accessing a certain type of data in the target scenario, such as high frequency, medium frequency, and low frequency) and status information (reflecting the device's availability in the target scenario, such as whether the battery is sufficient and whether the storage space is sufficient for caching). Next, based on historical behavioral data (reflecting user habits) and status information (reflecting device availability), a probability assessment is performed on the devices in each historical association record. For example, devices that have historically accessed target data frequently and whose current status can support caching operations will be given a higher probability of use, while those that do not will have a lower probability. Finally, the device with the highest probability of use is selected from all candidate devices as the final target device for storing pre-cached content.

[0087] The specific implementation steps are as follows: The system obtains real-time status data of the target device (phone A) through a device status interface (such as a system API), including: Battery level: Current battery level is 18% (the system's preset minimum usable threshold is 20%). Storage space: 0.8GB of remaining storage space (minimum space required for pre-cached content is 1GB); Network status: Currently connected to Wi-Fi (system default available network type).

[0088] According to the preset availability judgment rules (which require that the battery level be ≥20%, the storage space be ≥1GB, and the network type be available at the same time), mobile phone A is judged to be "unusable" because the battery level and storage space do not meet the requirements.

[0089] S35. If so, the pre-caching instruction is sent to the target device to cause the target device to perform a pre-caching operation; If not, based on the historical association records, exclude the unusable target devices, re-determine the candidate devices with the highest probability of use at the future location and the future time, and determine the re-determined candidate devices as the target devices.

[0090] The ultimate goal of this dynamic pre-caching step is to ensure that "the required content is cached on the target device when the user arrives at the future location." However, even if the target device with the highest usage probability is selected through "scenario-based probability assessment," the device may still be unable to actually perform the pre-caching operation due to temporary issues (such as sudden battery depletion, network disconnection, or full storage space). If the unavailability of the device is directly ignored, it may result in no response after the pre-caching command is sent, and the user will still have to wait for the content to load when arriving at the target scene, failing to achieve the "ready-to-use" experience. Therefore, S35 ensures that the pre-caching operation is always based on the actual availability of the device through a dynamic mechanism of "execute if available, adjust if unavailable," avoiding caching failures caused by temporary device malfunctions or abnormal states.

[0091] This step is executed in two scenarios: If the target device's status (such as battery level, network connectivity, and storage space) meets the basic conditions for pre-caching (e.g., battery level ≥ 20%, network connectivity, and storage space ≥ 1GB), a pre-caching instruction is sent directly to the device. Upon receiving the instruction, the device initiates caching operations (e.g., downloading target data and storing it to a specified path). If the target device cannot perform caching due to unmet status (e.g., battery level only 15%, no network connectivity), a re-selection process is triggered: First, the current target device is removed from the candidate device list. Then, based on historical association records (historical behavior data and status information of the device in the target scenario), the usage probability of the remaining candidate devices is recalculated (combining historical access frequency and real-time status). Finally, the device with the highest usage probability after re-evaluation is selected as the new target device, and the process of "judging availability → performing caching" is repeated until an available device is found.

[0092] Assuming the initial target device (phone A) is unavailable, the system triggers a re-screening process, which is implemented as follows: First, exclude unavailable devices: remove phone A from the list of candidate devices; Secondly, the probability of use was recalculated: Based on historical correlation records of the "company-morning time period" scenario, the probability of use for the remaining candidate devices (tablet B, laptop C) was reassessed. Tablet B: Historically, the frequency of accessing office files during the "company - morning hours" is high (70%), the current battery is 80% and the storage space is 10GB, which meets the availability threshold; Laptop C: Historical access frequency is medium (accounting for 45%), current battery is 50% and storage space is 15GB, meeting the availability threshold.

[0093] After calculation, the probability of using tablet B increased to 90% (higher than 65% for laptop C), and it was redefined as the new target device.

[0094] Finally, the pre-caching operation is performed: the system sends a pre-caching instruction to tablet B. Since tablet B meets the conditions for both battery level (80% ≥ 20%) and storage space (10GB ≥ 1GB), it receives the instruction and begins caching the target content (such as office documents and meeting materials).

[0095] In this embodiment, step S34 ensures that the target device has the physical conditions (power, storage, network) to perform pre-caching by "acquiring device status data + judging preset thresholds"; step S35 dynamically adjusts the target device by "excluding unavailable devices + recalculating probability" to ensure that the system always selects devices with "high usage probability + available status" to perform pre-caching. These two steps work together to achieve dual protection of "dynamic device selection" and "feasibility of pre-caching operations," avoiding caching failures or resource waste caused by temporary device unavailability. Specific Implementation Example Six The step of generating a pre-cached instruction for the target device based on the future location, the future time, and the preference matrix includes the following steps: S41. Filter user behavior data associated with the future location, the future time, and the target device from the preference matrix; The core objective of dynamic pre-caching is to ensure that the target device has cached the content most likely to be needed by the user when they reach their future location at the target time. However, the preference matrix is ​​essentially a full-scene record of the user's historical behavior (covering all combinations of location, time, and device). If the pre-caching instructions are generated directly using the full dataset, it will contain a large amount of redundant information unrelated to the user's future scenario (such as entertainment data for a "home-evening" scenario that the user will not visit in the future). This redundant information will cause the cached content to deviate from the user's actual needs (such as caching entertainment videos on a laptop that the user will use for work in the future), resulting in wasted storage space and failing to improve the user experience. Therefore, the core objective of S41 is to focus on the user's future scenario, extract behavioral data strongly related to that scenario, and ensure that the subsequent cached content is highly matched with the user's actual needs.

[0097] This step relies on a "scene tag matching" mechanism. The specific process is as follows: First, the time-space prediction module clarifies the user's future scene, determining the future location and future time (e.g., "morning time"). Then, the device selection module associates the selected target device (e.g., "laptop DEV-003"). Finally, in the preference matrix, using "device ID-location tag-time period tag-data type" as the composite key (e.g., "DEV-003-company-morning time period-office type"), the system matches the composite key of future location ("company"), future time ("morning time period"), and target device ("DEV-003") to filter out user behavior data containing only this combination from the full matrix (e.g., the frequency distribution of "DEV-003 frequently accessing office type data in the company-morning time period").

[0098] S42. Obtain the caching capability parameters of the target device, and based on the user behavior data and the caching capability parameters, filter the target data categories and corresponding content identifiers that need to be pre-cached; This process involves two key steps: First, the core caching capability parameters of the target device are obtained, including remaining storage space (determining whether it can accommodate cached content), network connection type (Wi-Fi / mobile data, affecting download speed), maximum cache capacity (the device's preset cache limit), and cache priority strategy (e.g., prioritizing office data over entertainment data). These parameters reflect the "physical limitations" of the device in performing caching operations. Next, based on the filtered user behavior data (e.g., "a certain type of data that the target device will frequently access in future scenarios"), the device's caching capability parameters are matched. For example, if the user frequently accesses "office data" but the device's storage space is limited, then smaller, most frequently accessed content in that category is prioritized. If the device's network speed is slow, lightweight data (such as text and images rather than high-definition videos) is selected to ensure that the cached content can be downloaded before the user arrives.

[0099] This step, combining device storage space and network speed parameters, preemptively excludes content exceeding the device's processing capacity (such as large files exceeding storage space or high-definition videos failing to download promptly due to slow networks), ensuring the caching operation can actually be completed. Simultaneously, it prioritizes content with high-frequency user demand and device compatibility (such as small-sized, high-priority data), reducing the occupation of device storage space and network resources by invalid caching and improving resource utilization efficiency. Furthermore, the cached content aligns with users' future usage habits (high-frequency access) and can be efficiently processed by the device (adaptability), allowing users to access the content directly without waiting for loading, significantly improving the smoothness of the experience. In summary, this step is a crucial balancing act between "demand-driven" and "capability-constrained" dynamic pre-caching methods. By combining user behavior data with device caching capabilities, it ensures the "executability" and "practicability" of the pre-caching strategy, providing a vital guarantee for achieving a "ready-to-use" user experience.

[0100] S43. Generate a pre-caching instruction based on the target data category, the content identifier, and the cache path rules pre-configured by the target device.

[0101] This step requires combining three pieces of information: the target data category (e.g., "office-related") to match the device's preset cache path rules (e.g., the device may be pre-configured to "store office-related data uniformly in the ' / user / cache / office' directory"); the content identifier (e.g., "DOC-001") to generate a unique filename for the specific content (e.g., combining the identifier to generate "office_DOC-001.dat" to avoid name conflicts with other files); and the device's cache path rules (e.g., "store by data type directory" and "prioritize storing high-frequency data in high-speed storage area") to define the cache's storage location, naming conventions, priority, and other operational details. By integrating these three pieces of information, a device-recognizable instruction is finally generated (e.g., "cache path: / user / cache / office; filename: office_DOC-001.dat; priority: high"), which the device can then use to complete data download, storage, and tagging.

[0102] This step, generated through standardized instructions, provides a clear "execution guide" for pre-caching operations. Specifically, storing data according to preset path rules prevents different types of data from being mixed (such as office and entertainment data), facilitating quick retrieval and access later. Generating unique filenames based on content identifiers avoids new caches overwriting important user or system files (such as user-stored documents). Priority rules included in the instructions (such as prioritizing high-frequency data in high-speed storage areas) allow the device to allocate resources on demand, accelerating the caching process. Standardized storage paths and naming rules enable the system to quickly locate and read cached content when users access data in future scenarios (such as opening office files on a laptop at the office), truly achieving "ready to use." Specific Implementation Example 7 Also includes: S6. When a user switches from the currently used target device to another candidate device, the switched candidate device matches the content identifier of the data cached by the target device. If the match is successful, the switched candidate device obtains the successfully matched pre-cached data from the target device.

[0104] In scenarios where users switch devices, the target device (such as a previously used device) may have pre-cached frequently used or recently accessed data (such as documents and images). Retrieving this data directly from the server or original storage source would increase network latency, repeatedly consume server resources, and potentially cause excessively long waiting times for users. Therefore, matching cached data and retrieving it from the target device essentially leverages existing cache resources across devices, avoiding redundant work and enabling data reuse based on proximity.

[0105] The following is a specific example of a successful match in this step: The user regularly uses both a mobile phone (target device) and a tablet (candidate device) and logs into the same user account. The mobile phone has pre-cached the frequently accessed document "Meeting Minutes.docx" (cache identifier "doc_001"). The tablet has also previously used this document, and "doc_001" is recorded in its local cache identifier library. When the user switches to the tablet, the tablet triggers a cache matching process: it directly retrieves the cached data list from the mobile phone, checks the local cache identifier library to confirm the existence of "doc_001" (successful match), and then sends a data request to the mobile phone. After verifying the source of the request, the mobile phone directly transmits the cached data of "Meeting Minutes.docx" to the tablet. The tablet receives and stores it in its local cache, and the user can open the document directly without delay.

[0106] The specific example of this step failing to match is as follows: The user regularly uses both a mobile phone (target device) and a tablet (candidate device) and logs into the same user account. The mobile phone has a pre-cached cache of the frequently accessed document "Project Planning Document.pdf" (cache identifier "pdf_002"). However, the tablet has not used this document, so there is no record of "pdf_002" in its local cache identifier library. When the user switches to using the tablet, the tablet triggers a cache matching process: it directly retrieves the cache data list from the mobile phone, checks the local cache identifier library to confirm that "pdf_002" does not exist (match failed), then retrieves the original data of "Project Planning Document.pdf" from the original data storage location, generates a new cache identifier (such as "pdf_003"), and stores it in the local cache directory. Subsequent times when the user accesses the document again, they can directly access the tablet's local cache. Specific Implementation Example 8 A dynamic pre-caching system for performing the dynamic pre-caching method, comprising: The data processing module is used to construct a preference matrix based on historical request data from multiple candidate devices of a user. The preference matrix is ​​used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in the corresponding location and time period. The time-space prediction module is used to acquire user historical location data and real-time dynamic data, extract multi-dimensional dynamic features based on the user historical location data and the real-time dynamic data, and determine the user's future location and the future time corresponding to the future location based on the multi-dimensional dynamic features. The device selection module is used to acquire the status data of the user's candidate devices, evaluate the historical usage tendency and real-time availability of each candidate device at the future location and the future time based on the status data and the preference matrix, determine the usage probability of each candidate device, and select the candidate device with the highest usage probability as the target device. The instruction generation module is used to generate pre-cached instructions to be allocated to the target device based on the future location, the future time, and the preference matrix. The instruction execution module is used to send the pre-caching instruction to the target device so that the target device performs a pre-caching operation. Specific Implementation Example Nine A computer device includes a memory and a processor, the memory storing computer-readable instructions, wherein the processor, when executing the computer-readable instructions, implements the steps of the dynamic pre-caching method. Specific Implementation Example 10 A computer-readable storage medium storing computer-readable instructions, which, when executed by a processor, implement the steps of the dynamic pre-caching method.

[0110] This invention can be used in a wide range of general-purpose or special-purpose computer system environments or configurations.

[0111] Examples include: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, and distributed computing environments that include any of the above systems or devices.

[0112] This invention can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules.

[0113] Generally, program modules include routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. This invention can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via communication networks.

[0114] In a distributed computing environment, program modules can reside on local and remote computer storage media, including storage devices.

[0115] Specifically, those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0116] It should be understood that although the steps in the flowcharts in the accompanying drawings are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise expressly stated herein, there is no strict order in which these steps are performed, and they may be performed in other orders.

[0117] Moreover, at least some steps in the flowchart of the attached figure may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. Their execution order is not necessarily sequential, but can be executed in turn or alternately with other steps or at least some of the sub-steps or stages of other steps.

[0118] Obviously, the embodiments described above are only some embodiments of the present invention, and not all embodiments. The accompanying drawings show preferred embodiments of the present invention, but do not limit the scope of the invention. The present invention can be implemented in many different forms; rather, these embodiments are provided to provide a thorough and complete understanding of the disclosure of the present invention.

[0119] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this specification and drawings, whether directly or indirectly applied to other related technical fields, are similarly within the scope of protection of this patent.

Claims

1. A dynamic pre-caching method, characterized in that, Includes the following steps: S1. Based on the historical request data of multiple candidate devices of the user, construct a preference matrix, which is used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in the corresponding location and time period; S2. Obtain user's historical location data and real-time dynamic data, extract multi-dimensional dynamic features based on the user's historical location data and real-time dynamic data, and determine the user's future location and the future time corresponding to the future location based on the multi-dimensional dynamic features; S3. Obtain the status data of the user's candidate devices, and based on the status data and the preference matrix, evaluate the historical usage tendency and real-time availability of each candidate device at the future location and the future time, determine the usage probability of each candidate device, and select the candidate device with the highest usage probability as the target device; S4. Based on the future location, the future time, and the preference matrix, generate a pre-cached instruction to be allocated to the target device; S5. Send the pre-caching instruction to the target device so that the target device performs a pre-caching operation.

2. The dynamic pre-caching method according to claim 1, characterized in that, The step of constructing a preference matrix based on historical request data from multiple candidate devices of a user, wherein the preference matrix is ​​used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in a corresponding location and time period, includes the following steps: S11. Obtain request data for multiple candidate devices of the user. The request data includes the device's unique identifier ID, the type of APP requested by the device, the specific data type accessed, the access timestamp, the duration of a single access, and the location information at the time of access. S12. Preprocess the device's unique identifier ID, the type of APP requested by the device, the specific data type accessed, the access timestamp, the duration of a single access, and the location information at the time of access to obtain a set of associated features related to the device identifier, data type, time period, and location; S13. Based on the set of associated features, construct the preference matrix, which is used to characterize the frequency distribution of the candidate device accessing the corresponding type of data in the corresponding location and time period.

3. The dynamic pre-caching method according to claim 1, characterized in that, The process of acquiring the status data of the user's candidate devices, evaluating the historical usage tendency and real-time availability of each candidate device at the future location and future time based on the status data and the preference matrix, determining the usage probability of each candidate device, and selecting the candidate device with the highest usage probability as the target device includes the following steps: S21. Obtain the user's historical location data and the real-time dynamic data, and preprocess the user's historical location data and the real-time dynamic data to obtain location dynamic data; S22. Extract location time features, movement features, and environmental association features based on the aforementioned location dynamic data; S23. Based on the location-time features, the movement features, and the environmental association features, determine the probability distribution of the user's location at the target time point, select the location with the highest confidence in the location probability distribution as the future location, and determine the target time period corresponding to the arrival at the future location as the future time.

4. The dynamic pre-caching method according to claim 1, characterized in that, The step of generating a pre-cached instruction for the target device based on the future location, the future time, and the preference matrix includes the following steps: S31. Obtain the status data, associate the status data with the historical behavior data of the corresponding device in the preference matrix, and form an associated dataset including device information, time information, location information and status information; S32. Based on the future location and the future time, filter out historical related records from the related dataset; S33. Based on the historical association records, determine the candidate device with the highest probability of use at the future location and at the future time as the target device.

5. The dynamic pre-caching method according to claim 4, characterized in that, Based on the historical association records, the process of determining the candidate device with the highest probability of use at the future location and the future time as the target device further includes: S34. Based on the status data, determine whether the target device can be used; S35. If so, the pre-caching instruction is sent to the target device to cause the target device to perform a pre-caching operation; If not, based on the historical association records, exclude the unusable target devices, re-determine the candidate devices with the highest probability of use at the future location and the future time, and determine the re-determined candidate devices as the target devices.

6. The dynamic pre-caching method according to claim 1, characterized in that, The step of generating a pre-cached instruction for the target device based on the future location, the future time, and the preference matrix includes the following steps: S41. Filter user behavior data associated with the future location, the future time, and the target device from the preference matrix; S42. Obtain the caching capability parameters of the target device, and based on the user behavior data and the caching capability parameters, filter the target data categories that need to be pre-cached and the content identifiers corresponding to the target data categories; S43. Generate the pre-caching instruction based on the target data category, the content identifier, and the cache path pre-configured on the target device.

7. The dynamic pre-caching method according to claim 1, characterized in that, Also includes: S6. When a user switches from the currently used target device to another candidate device, the content identifier of the data cached by the target device is matched based on the candidate device after the switch. If the match is successful, the pre-cached data that has been successfully matched is obtained from the target device based on the candidate device after the switch.

8. A dynamic pre-caching system for executing the dynamic pre-caching method according to any one of claims 1 to 7, characterized in that, include: The data processing module is used to construct a preference matrix based on historical request data from multiple candidate devices of a user. The preference matrix is ​​used to characterize the frequency distribution of each candidate device accessing the corresponding type of data in the corresponding location and time period. The time-space prediction module is used to acquire user historical location data and real-time dynamic data, extract multi-dimensional dynamic features based on the user historical location data and the real-time dynamic data, and determine the user's future location and the future time corresponding to the future location based on the multi-dimensional dynamic features. The device selection module is used to acquire the status data of the user's candidate devices, evaluate the historical usage tendency and real-time availability of each candidate device at the future location and the future time based on the status data and the preference matrix, determine the usage probability of each candidate device, and select the candidate device with the highest usage probability as the target device. The instruction generation module is used to generate pre-cached instructions to be allocated to the target device based on the future location, the future time, and the preference matrix. The instruction execution module is used to send the pre-caching instruction to the target device so that the target device performs a pre-caching operation.

9. A computer device, characterized in that, The device includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor, when executing the computer-readable instructions, implements the steps of the dynamic pre-caching method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions that, when executed by a processor, implement the steps of the dynamic pre-caching method as described in any one of claims 1 to 7.

Images