Resource information synchronization method and system, electronic device, storage medium and program product

CN122816933APending Publication Date: 2026-09-25阿里巴巴(中国)网络技术有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202610800501.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2026-06-04
Publication Date
2026-09-25

AI Technical Summary

Technical Problem

由于两个平台之间在数据模型、通信协议、安全机制等方面存在异构性,因此无法直接信息互通,形成了信息孤岛

Benefits of technology

[0009]本申请实施例提供的技术方案中,智能服务平台响应于第一平台针对目标资源的状态查询请求,确定与该状态查询请求相匹配的信息提供方,信息提供方包括第二平台;从信息提供方获取目标资源的状态信息,并向第一平台发送查询结果,以将状态信息同步至所述第一平台。由此,基于智能服务平台,打通了第一平台与第二平台之间的数据通道,解决了因平台割裂造成的信息孤岛问题,不仅能够提升查询效率,而且为第一平台提供了可靠数据,提升了查询的准确性。

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN122816933A_ABST
    Figure CN122816933A_ABST
Patent Text Reader

Abstract

Embodiments of the present application provide a resource information synchronization method and system, electronic equipment, storage medium and program product, relating to the technical field of Internet, the method comprising: an intelligent service platform determines an information provider matched with a state query request of a first platform in response to the state query request for a target resource, the information provider comprising a second platform; obtaining state information of the target resource from the information provider; and sending a query result to the first platform to synchronize the state information to the first platform. In the technical solution of the embodiments of the present application, the data channel between the first platform and the second platform is opened, and the query efficiency and the accuracy of the query result are improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of Internet technology, and in particular to a method, system, electronic device, storage medium and program product for synchronizing resource information. Background Technology

[0002] In a cross-platform service architecture, the first platform provides product or device query services, while the second platform manages detailed product or device information. Due to heterogeneity in data models, communication protocols, and security mechanisms, the two platforms cannot directly exchange information, creating information silos. Therefore, when the first platform receives a query request for a product or device, manual switching and querying between the two platforms is required, resulting in low query efficiency and potential distortion of query results due to manual synchronization delays. Summary of the Invention

[0003] This application provides a resource information synchronization method, system, electronic device, computer-readable storage medium, and computer program product to alleviate or solve one or more technical problems existing in the prior art.

[0004] In a first aspect, embodiments of this application provide a resource information synchronization method applied to an intelligent service platform. The method includes: responding to a status query request for a target resource from a first platform, determining an information provider matching the status query request, the information provider including a second platform; obtaining status information of the target resource from the information provider; and sending a query result to the first platform to synchronize the status information to the first platform.

[0005] In a first aspect, embodiments of this application provide a resource information synchronization system, including: an intelligent service platform, at least one first platform, and at least one second platform; any first platform is configured to send a status query request to the intelligent service platform in response to a status query text for a target resource; any second platform is configured to provide status information of the held resource; the intelligent service platform is configured to implement any method of any embodiment of this application.

[0006] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements any of the methods of embodiments of this application when executing the computer program.

[0007] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method of any one of the embodiments of this application.

[0008] Fifthly, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements any of the methods described in the embodiments of this application.

[0009] In the technical solution provided in this application embodiment, the intelligent service platform responds to the status query request for a target resource from the first platform, determines the information provider matching the status query request, and the information provider includes the second platform; obtains the status information of the target resource from the information provider, and sends the query result to the first platform to synchronize the status information to the first platform. Thus, based on the intelligent service platform, the data channel between the first and second platforms is established, solving the information silo problem caused by platform fragmentation. This not only improves query efficiency but also provides reliable data to the first platform, improving the accuracy of the query.

[0010] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0011] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0012] Figure 1 A schematic diagram of the architecture of the resource information synchronization system according to an embodiment of this application is shown; Figure 2 A flowchart of a resource information synchronization method according to an embodiment of this application is shown; Figure 3 A schematic diagram of a resource information synchronization method according to an embodiment of this application is shown; Figure 4 A schematic diagram of the modules of a resource information synchronization device according to an embodiment of this application is shown; Figure 5 A block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0013] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0014] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0015] In cross-platform, cross-entity service architectures, a common technical challenge exists: an "information gap" between resource status awareness and service request response. This problem is particularly prominent in many-to-many proxy or integration service scenarios, typically manifesting as poor information flow and response delays between the request initiator, resource holder, and service proxy. Specifically, when a user initiates a query request for a product or device on the first platform, the detailed information of the product or device resides on the second platform, and direct information exchange between the first and second platforms creates information silos. Consequently, manual switching and querying between the two platforms is necessary, resulting in low query efficiency and potential inaccurate query results due to manual synchronization delays.

[0016] Currently, two main technical approaches attempt to address the aforementioned issues. The first is to aggregate service requests from different primary platforms through a multi-channel access service system and process them in the background. However, this approach only achieves shallow access to the primary platform and fails to establish deep data connections with secondary platforms holding detailed product or device information. When requests involve querying detailed information, manual intervention is still required. Furthermore, due to the complexity of this system's configuration, it requires personnel with professional operation and maintenance capabilities, resulting in high deployment and maintenance costs. The second approach is a simulated interaction solution based on automated scripts. This involves using robotic process automation tools or writing custom scripts to simulate manual operations to access information from different platforms. However, this approach is often limited for scenarios with high security requirements, thus lacking universality. Moreover, this solution relies on the platform's user page; even minor changes to the user page can cause the preset parsing rules to fail, requiring frequent manual maintenance and resulting in poor stability. Thirdly, this type of solution is essentially a mechanical execution based on fixed rules, lacking a deep understanding of request semantics and intelligent reasoning capabilities. It cannot adapt to flexible and varied natural language queries and complex scenarios, making it difficult to meet the requirements for high-quality, intelligent service responses.

[0017] In view of this, embodiments of this application provide a resource information synchronization method, system, electronic device, storage medium, and program product, which aim to open up the data channel between the first platform and the second platform, improve query efficiency and the accuracy of query results, and will be described in detail below.

[0018] Figure 1 This application provides an embodiment of a resource information synchronization system, which is illustrated in the following diagram. Figure 1As shown, the system includes an intelligent service platform, at least one first platform, and at least one second platform.

[0019] Each primary platform serves as the carrier for access and interaction by the requester. Specifically, the primary platform receives the query text input by the requester regarding the target resource and sends a status query request to the intelligent service platform based on that query text. The primary platform can be a standalone application, a mini-program embedded in other applications, or a web application. When the requester is a user, the primary platform can be configured on the user's terminal device. The primary platform can take different forms depending on the application scenario. For example, in an e-commerce scenario, the primary platform could be an online retail platform or a dialogue service system embedded within an online retail platform, providing product-related query services to the requester. As another example, in an operations and maintenance scenario, the primary platform could be an enterprise's service management system, a robot interface for internal collaboration tools, etc., providing query services related to enterprise resources such as servers, networks, and processors to the requester.

[0020] Any second platform is an entity that registers, manages, and holds status information for resources. Specifically, the second platform provides services such as resource registration, display, and storage of status information for resource providers, and provides the intelligent service platform with the status information of the resources it holds. The second platform can be a standalone application, a mini-program embedded in other applications, or a web application. The second platform can be configured on the resource provider's terminal device. For different application scenarios, the second platform can take different forms. As an example, in an e-commerce scenario, the second platform can be a B2B (Business to Business) platform, a resource supplier management system, etc., and holds status information such as product price, inventory, and delivery time. As another example, in an operations and maintenance scenario, the second platform can be an infrastructure management platform (such as a cloud management platform), a monitoring system, etc., and holds performance indicators, health status, and alarm information for enterprise resources such as servers, networks, and processors.

[0021] The intelligent service platform is a middleware deployment independent of the first and second platforms, used to implement the resource information synchronization method provided in any embodiment of this application. Specifically, the intelligent service platform possesses request parsing capabilities (such as parsing status query requests for target resources from the first platform), cross-platform information acquisition capabilities (such as obtaining status information of target resources from the second platform), query result generation capabilities (such as query results for target resources), and synchronization capabilities (such as sending query results to the first platform).

[0022] It should be noted that this application is not limited to the aforementioned e-commerce and operation and maintenance scenarios, but can be applied to any scenario that requires cross-platform information synchronization.

[0023] Therefore, based on the intelligent service platform, the data channel between the first platform and the second platform is opened up, solving the problem of information silos caused by platform fragmentation. This not only improves query efficiency, but also provides reliable data for the first platform, thereby improving the accuracy of queries.

[0024] It should be noted that the application scenarios or examples provided in the embodiments of this application are for ease of understanding, and the embodiments of this application do not specifically limit the application of the technical solutions. In addition, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0025] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0026] Figure 2 A flowchart of a resource information method according to an embodiment of this application is shown. Figure 2 The method shown can be used by Figure 1 The intelligent service platform in the middle executes, such as Figure 2 As shown, the method may include steps S201, S202 and S203.

[0027] Step S201: In response to the status query request for the target resource from the first platform, determine the information provider that matches the status query request. The information provider includes the second platform.

[0028] In some implementations, upon receiving a query message from a requester regarding a target resource, the first platform sends a status query request containing query text to the intelligent service platform. The query message can be in text format (i.e., the query message is query text) or in voice format. If the query message is in voice format, the first platform can first convert the voice query message into text query text and then send the status query request to the intelligent service platform based on the query text. That is, the query text in the status query request is natural language representing the query intent, and the query text may include the resource identifier of the target resource, or other location information that can locate the target resource, such as location information. If the query text does not contain location information of the target resource, the status query request may also include links corresponding to the target resource (such as links to the target resource's display page, links to orders containing the target resource, etc.), the resource identifier of the target resource, and other location information associated with the target resource. The requester can be a user, or other applications or devices.

[0029] As one example, the target resource is a dress, and the status query request includes a link to the dress's display page and the corresponding query text "Is this dress in size M currently in stock?". As another example, the target resource is a log server, and the status query request includes the query text "Is the host hosting the log database currently under high load?", where the host hosting the log database is information associated with the target resource.

[0030] An information provider is an entity capable of providing status information of a target resource. In some implementations, the information provider may include a second platform, a knowledge base maintained locally by the intelligent service platform, etc., which stores information such as the historical status, static attributes, and preset rules of multiple resources. Accordingly, the information provider can be determined based on preset mapping rules. For example, based on the resource identifier of the target resource, the corresponding information provider can be obtained from the correspondence between resource identifiers and information providers. Alternatively, the information provider can be determined based on semantic analysis of the status query request. For example, the status query request can be parsed to obtain the target keyword, and the information provider corresponding to the target keyword can be obtained from the correspondence between the keyword and information providers.

[0031] Step S202: Obtain the status information of the target resource from the information provider.

[0032] When the information provider is a second platform, the status information of the target resource is obtained from the second platform. When the information provider is the knowledge base of an intelligent service platform, the status information of the target resource is obtained from that knowledge base. The status information of the target resource is used to characterize the current status or attributes of the target resource, and its form can be numbers, text, enumeration values, etc., such as inventory 100, memory utilization 75%, normal operating status, etc.

[0033] Step S203: Send the query results to the first platform to synchronize the status information to the first platform.

[0034] The intelligent service platform can directly use status information as the query result and send the query result to the first platform. Alternatively, the intelligent service platform can generate query results based on status information according to preset result generation rules and send the query result to the first platform.

[0035] In the technical solution provided in this application embodiment, the intelligent service platform responds to the status query request for a target resource from the first platform, determines the information provider matching the status query request, and the information provider includes the second platform; obtains the status information of the target resource from the information provider, and sends the query result to the first platform to synchronize the status information to the first platform. Thus, based on the intelligent service platform, the data channel between the first and second platforms is established, solving the information silo problem caused by platform fragmentation. This not only improves query efficiency but also provides reliable data to the first platform, improving the accuracy of the query.

[0036] To improve query efficiency while ensuring query quality, some implementations can determine the query intent and identify the information provider based on that intent. Specifically, determining the information provider matching the status query request can include: parsing the status query request to obtain the query intent; if the query intent represents dynamic information, determining the information provider matching the status query request as a second platform; if the query intent represents static information, determining the information provider matching the status query request as the knowledge base of the intelligent service platform.

[0037] The intelligent service platform can invoke an intent recognition model to perform semantic analysis on status query requests and determine the query intent. Alternatively, the intelligent service platform can match status query requests with preset templates based on matching rules to determine the query intent. If the query intent represents a query for dynamic information, the second platform is identified as the information provider matching the status query request. If the query intent represents a query for static information, the intelligent service platform's knowledge base is identified as the information provider matching the status query request.

[0038] The query intent characterizes the fundamental purpose of a status query request or the type of information expected to be obtained. For example, the query intent could be to query inventory, the current health of a service, product specifications, or troubleshooting procedures. Dynamic information refers to information that changes rapidly within the current timeframe or a recent time window. Because this information changes rapidly over time, it is obtained from the actual owner or manager of the resource to ensure the accuracy of the query results; that is, the second platform is identified as the information provider. For example, querying the current memory usage of a server or the inventory of product A are both examples of dynamic information. Static information refers to inherent, time-invariant attribute information of a resource, or knowledge formed based on established rules and historical records. Static information typically does not depend on data updates from the second platform and can be pre-organized and stored in a local knowledge base. For example, querying the factory configuration of a server, troubleshooting steps for database connection failures, or querying the origin and composition of a product are all examples of static information.

[0039] As an example, a status query request includes "Is this dress in size M currently in stock?". After parsing, the query intent is determined to be checking product inventory, which is dynamic information. Therefore, the information provider is identified as the platform where the dress is provided, i.e., the second platform. As another example, a status query request includes "What material is the screen of this phone made of?". After parsing, the query intent is determined to be checking the product material, which is a static attribute. Therefore, the information provider is identified as the knowledge base of static attributes stored internally by the intelligent service platform.

[0040] Therefore, by determining the query intent and performing intelligent routing based on that intent, accurate selection of information providers is achieved. By redirecting queries for dynamic information to a second platform, the reliability of the query results is ensured, thus improving the accuracy of the results. By redirecting static queries to a local knowledge base, response speed is improved while maintaining the accuracy of the results. This differentiated approach ensures query quality while optimizing overall performance.

[0041] Considering that different second platforms often have different access methods in practical applications, in order to avoid problems such as difficulties in unified management and system scalability, in some implementations, when the resource provider is a second platform, the status information of the target resource is obtained from the second platform based on a pre-set standardized process. That is, the aforementioned acquisition of the target resource status information from the information provider may include: determining the resource identifier of the target resource; obtaining the access information associated with the target resource based on the resource identifier according to a preset acquisition strategy; and accessing the second platform based on the access information to obtain the target resource status information from the second platform.

[0042] The intelligent service platform can first parse the status query request. If the status query request contains the resource identifier of the target resource, it retrieves the resource identifier from the request. If the status query request does not include the resource identifier, it retrieves the location information of the target resource from the request and determines the resource identifier based on this location information. For example, it can query the resource identifier based on the target resource's link (i.e., location information). Furthermore, according to a preset acquisition strategy, it retrieves the access information associated with the target resource based on the resource identifier. Then, based on this access information, it accesses a second platform to obtain the status information of the target resource from the second platform.

[0043] The resource identifier can be the resource name, a pre-assigned serial number, etc. Access information can be the platform call interface of the second platform, such as the complete API (Application Programming Interface) call address. Access information can also be the service access address of the target resource, such as the URL (Uniform Resource Locator) pointing to the display page of the target resource.

[0044] Therefore, by introducing standardized processes for resource identification, preset acquisition strategies, access information, and execution access, the abstraction and standardization of data acquisition operations on different second platforms are achieved. This reduces the complexity of coupling between the intelligent service platform and the second platform, making the addition of support for new resources or platforms primarily a configuration task rather than a coding task. Consequently, it significantly improves the overall system's scalability, maintainability, and access efficiency to different data sources.

[0045] Considering that in practical applications, the query process may be interrupted due to interface instability, permission changes, etc., in order to ensure that accurate status information can be successfully obtained from the second platform, some implementations use a preset hierarchical fallback acquisition strategy to obtain the status information of the target resource from the second platform. That is, the aforementioned acquisition of access information associated with the target resource based on the resource identifier according to the preset acquisition strategy may include: obtaining the target platform call interface corresponding to the resource identifier of the target resource in the correspondence between resource identifiers and platform call interfaces, and determining the target platform call interface as access information; in the case of failure to access the target platform call interface, determining the service access address of the target resource based on the resource identifier of the target resource and the access address of the second platform, and determining the service access address as access information.

[0046] In some implementations, a pre-established correspondence between the platform call interface of the second platform and the resource identifiers of various resources provided by the second platform can be established. The platform call interface refers to a standardized interface provided by the second platform for programmatically obtaining its resource data. The data returned by such interfaces is usually structured (e.g., JSON), easy to parse, and highly efficient; therefore, the platform access interface is used as the primary acquisition strategy. Specifically, the intelligent service platform first obtains the target platform call interface corresponding to the resource identifier of the target resource from the correspondence between resource identifiers and platform call interfaces, and identifies the target platform call interface as the access information. Furthermore, in the event that access to the target platform call interface fails due to network instability or other factors, it automatically reverts to the secondary acquisition strategy. This involves obtaining the access address corresponding to the resource identifier of the target resource (i.e., the access address of the second platform) from the correspondence between resource identifiers and access addresses, constructing a service access address based on the resource identifier of the target resource and its corresponding access address, and identifying the service access address as the access information.

[0047] The failure to access the target platform's API can be due to any of the following: access timeout, return of an error status code, or return of abnormal data format. The access address of the second platform can be the base address of the web service provided by the second platform, such as the domain name of its official website or console. The service access address can be a URL obtained by combining the access address of the second platform and the resource identifier of the target resource; it can be directly accessed in a browser to view the resource display page of the target resource.

[0048] Therefore, by adopting a tiered rollback data acquisition strategy, it is possible to achieve a flexible response capability to interface access failures while pursuing efficient data acquisition. This significantly improves the reliability of the data channel between the intelligent service platform and the second platform, reduces the risk of service unavailability due to single point of failure, and provides a more stable and reliable status query guarantee for the first platform.

[0049] Corresponding to the content of the access information mentioned above, the aforementioned access to the second platform based on the access information may include: when the access information is a call interface of the target platform, sending a status acquisition message to the second platform through the call interface of the target platform, and receiving status information sent by the second platform; when the access information is a service access address, obtaining the page status data of the resource display page corresponding to the service access address, and determining the status information of the target resource based on the page status data.

[0050] In some implementations, a unified data format can be preset for each second platform. Accordingly, when the intelligent service platform determines that the access information is a target platform call interface, it encapsulates the received status query request to obtain a status acquisition message in the unified data format. In other implementations, different second platforms may correspond to the same or different data formats. Accordingly, when the intelligent service platform determines that the access information is a target platform call interface, it determines the target platform identifier of the second platform corresponding to the target resource, obtains the target data format corresponding to the target platform identifier from the correspondence between the platform identifier and data format of the second platform, encapsulates the received status query request to obtain a status acquisition message in the target data format, and calls the target platform call interface to send the status acquisition message to the second platform. Based on the received status acquisition message, the second platform determines the resource identifier of the target resource and the target category of the status information to be acquired (such as inventory, memory utilization, etc.), obtains the status information of the target category from the status information corresponding to the resource identifier of the target resource, and sends it to the intelligent service platform. The intelligent service platform receives the status information sent by the second platform.

[0051] If accessing the second platform via the API call from the target platform fails, as mentioned earlier, the service access address can be redefined. Accordingly, the intelligent service platform sends a data acquisition request to the server corresponding to the second platform based on this service access address, receives the raw data of the resource display page of the target resource from the server, obtains page status data based on this raw data, and determines the status information of the target resource based on the page status data. The raw data of the resource display page can be HTML (Hypertext Markup Language) source code, JSON data, etc. The page status data can be program documentation obtained by parsing the raw data of the resource display page, or a page image obtained by rendering the corresponding resource display page through a headless browser based on the raw data and performing operations such as screenshotting the resource display page.

[0052] Therefore, by employing different methods to obtain status information for different access scenarios, the intelligent service platform can maintain compatibility with two mainstream external data sources within a unified framework. This fully leverages the efficiency of the access interface while maintaining the flexibility to handle traditional pages. This dual-mode support significantly enhances the applicability and access capabilities of the intelligent service platform, enabling it to adapt to diverse external environments and meet data synchronization needs in different scenarios.

[0053] Because the forms of resource display pages vary, taking the status information to be queried as inventory as an example, some second platforms may configure it in the program document, while others may display it directly as an image on the resource display page. In order to accurately obtain the status information of the target resource, in some implementations, the aforementioned determination of the status information of the target resource based on the page status data may include: when the page status data is the program document of the resource display page, determining the page element in the program document that matches the status query request, and obtaining the status information of the target resource from the attribute information of the page element; when the page status data is a page image of the resource display page, identifying the status information of the target resource from the page image.

[0054] After receiving the raw data from the resource display page, the intelligent service platform first parses the raw data and converts it into a structured program document. This program document includes the attribute information of each page element in the resource display page. When parsing the status query request and determining the query intent, the intelligent service platform can also determine the target category of the status information to be queried. Accordingly, the intelligent service platform matches this target category with each page element in the program document. If a matching page element exists, the platform retrieves the status information of the target category from the attribute information of that matching page element. If no matching page element exists, based on the raw data of the resource display page, the platform renders the resource display page using a headless browser and performs operations such as screenshotting the page to obtain an image. This image is then subjected to OCR (Optical Character Recognition) or an image recognition model is used to identify the page image to obtain the status information of the target category of the target resource.

[0055] In this context, a structured program document can be a DOM (Document Object Model) tree, and the attribute information of any page element can include text content (such as user-visible text) and standard features (such as src, href).

[0056] For example, the target category is product inventory, and the page element in the program documentation that matches the target category is... Elements, from The value of the element's textContent is 100, which means that the status information of the target resource is 100.

[0057] It should be noted that the intelligent service platform can first obtain the status information of the target resource based on the program documentation, and if that is not obtained, then obtain the status information of the target resource based on the page images. Alternatively, it can first obtain the status information of the target resource based on the page images, and if that is not obtained, then obtain the status information of the target resource based on the program documentation.

[0058] Therefore, by providing two processing methods—program document parsing and page image recognition—the intelligent service platform possesses a powerful and adaptive ability to extract page information, effectively addressing the diversity of page implementations on different second platforms, thereby improving the success rate of obtaining data from resource display pages.

[0059] The above describes the process of obtaining status information when the information provider is a second platform. Further, such as... Figure 3 As shown, when the information provider is the knowledge base of an intelligent service platform, the first target knowledge can be obtained from the knowledge base and the status information can be determined. In other words, obtaining the status information of the target resource from the information provider can include: obtaining the first target knowledge matching the status query request from the knowledge base based on the resource identifier of the target resource; and determining the status information of the target resource based on the first target knowledge.

[0060] When the information provider is a knowledge base, the intelligent service platform can query at least one candidate knowledge associated with the resource identifier of the target resource from the knowledge base, and determine the first target knowledge that matches the query intent among the candidate knowledge. The platform can then obtain the query status information from the first target knowledge, or deduce the query status information based on the first target knowledge. The query status information may include, for example, product specifications, device firmware version, historical statistics, etc.

[0061] For example, a status query request includes a link to a shirt and the query text "What fabric is this shirt made of?". The intelligent service platform determines the resource identifier of the target resource based on the link in the status query request. If the knowledge base finds that the fabric information corresponding to the resource identifier is pure cotton, then the status information of the target resource is determined to be pure cotton.

[0062] Therefore, by providing an independent and fast data path for static knowledge queries, not only can the query load be reasonably distributed, but the response latency of static knowledge can also be reduced, thereby increasing the throughput of queries related to static knowledge.

[0063] Furthermore, to ensure the accuracy of the knowledge base, the intelligent service platform can also obtain resource information of each resource from the second platform according to a preset cycle, and update the knowledge base based on the resource information.

[0064] Building upon any of the foregoing embodiments, to enable the requester to obtain not only the desired status data but also information related to that status data, in some implementations, such as... Figure 3 As shown, query results can be generated based on state information and second target knowledge. That is, after obtaining the state information of the target resource from the information provider, it can also include: obtaining second target knowledge that matches the state query request from the knowledge base, the second target knowledge being used to interpret the state information; and calling the result generation model to generate query results based on the state information and the second target knowledge.

[0065] After acquiring the state information of the target resource, the intelligent service system can retrieve knowledge from the knowledge base that is relevant to the state query request or its context, used to aid understanding or supplement the state information. This knowledge serves as the second target knowledge matching the state query request. Based on the acquired state information and the second target knowledge, prompt words are generated. These prompt words are then input into a result generation model, which uses the model to generate query results based on the state information and the second target knowledge. The prompt words indicate the rules for generating the query results. The second target knowledge provides context for the original state data, assesses its impact, or provides further operational guidance.

[0066] As an example, a status query request might ask why the database host is slow. The retrieved status information indicates that the database host's disk usage is 98%. The second objective is to suggest handling high disk usage by checking and cleaning log files and temporary files, assessing and performing disk expansion, and checking for abnormal file growth. The generated query result is: The database host's disk usage has reached 98%, nearing saturation, which is one of the main reasons for the slow database host response. The immediate recommendations are: 1. Log in to the server and check the log file size; 2. Clean up unnecessary temporary files; 3. Contact the system administrator to assess disk expansion.

[0067] As another example, a status query request might ask if size M is still in stock. The retrieved status information would be "Inventory: 0". The second objective could include out-of-stock retention strategies such as informing the user of the shortage, providing an estimated restock time (if any), suggesting alternative products, and offering a notification registration service for arrival. The generated query result could be: "Dear customer, size M is currently very popular and out of stock! A new batch is expected to arrive in 3 days. You can also check out the same style in size L, or I can register it for you now, and we'll notify you as soon as it arrives. Is that okay?" Therefore, by combining the second objective knowledge to generate query results, the query results not only answer what (state), but also attempt to explain why (meaning) and how to do it (suggestion). This not only greatly improves the practicality of the query results and the experience of the requester, but also avoids the rigidity and limitations of responses based on fixed templates.

[0068] Furthermore, to avoid including sensitive information in the query results, in some implementations, such as Figure 3 As shown, the generated query results can also be security verified. That is, before sending the query results to the first platform, the process can include: performing a security verification on the query results based on the verification rules associated with the target resource; and sending the query results to the first platform if the security verification passes.

[0069] In some implementations, different verification rules can be configured for different resource types. Accordingly, the intelligent service platform can determine the resource type of the target resource, obtain the verification rules associated with the resource type of the target resource from the association relationship between resource type and verification rules, perform security verification on the query results according to the obtained verification rules, and send the query results to the first platform if the security verification passes.

[0070] In other implementations, different first platforms can be pre-configured with different verification rules. Accordingly, the intelligent service platform can obtain the verification rules associated with the platform identifier of the first platform from the association relationship between platform identifiers and verification rules, and use these as the verification rules associated with the target resource; based on the obtained verification rules, it performs security verification on the query results; and if the security verification passes, it sends the query results to the first platform. The security verification may include sensitive word filtering, privacy information desensitization, and secondary verification of the status information in the query structure (e.g., whether the status information in the query results is consistent with the status information obtained from the second platform or knowledge base), etc.

[0071] Furthermore, if the security verification fails, the intelligent service platform can also correct the query results or initiate a manual review process.

[0072] Therefore, by performing security verification on the query results, the potential risks to the query results in terms of compliance, security and accuracy are reduced, and the reliability and credibility of the overall system are improved.

[0073] Corresponding to the application scenarios and methods provided in the embodiments of this application, the embodiments of this application also provide a resource information synchronization device, which can be applied to... Figure 1 The intelligent service platform shown, such as Figure 4 As shown, the device includes: The determination module 401 is used to determine, in response to a status query request for a target resource from the first platform, an information provider that matches the status query request, wherein the information provider includes the second platform; The acquisition module 402 is used to acquire the status information of the target resource from the information provider; The sending module 403 is used to send the query result to the first platform to synchronize the status information to the first platform.

[0074] In some implementations, the determining module 401 is specifically used to: parse the status query request to obtain the query intent; if the query intent represents querying dynamic information, determine that the information provider matching the status query request is the second platform; if the query intent represents querying static information, determine that the information provider matching the status query request is the knowledge base of the intelligent service platform.

[0075] In some implementations, when the information provider is a second platform, the acquisition module 402 is specifically used to: determine the resource identifier of the target resource; acquire access information associated with the target resource according to the resource identifier in accordance with a preset acquisition strategy; and access the second platform based on the access information to acquire the status information of the target resource from the second platform.

[0076] In some implementations, the acquisition module 402 is further specifically used to: in the correspondence between resource identifiers and platform call interfaces, acquire the target platform call interface corresponding to the resource identifier of the target resource, and determine the target platform call interface as the access information; in the case of failure to access the target platform call interface, determine the service access address of the target resource according to the resource identifier of the target resource and the access address of the second platform, and determine the service access address as the access information.

[0077] In some implementations, the acquisition module 402 is further specifically used to: when the access information is a target platform call interface, send a status acquisition message to the second platform through the target platform call interface, and receive the status information sent by the second platform; when the access information is a service access address, acquire the page status data of the resource display page corresponding to the service access address, and determine the status information of the target resource based on the page status data.

[0078] In some embodiments, the acquisition module 402 is further specifically used to: when the page status data is a program document of the resource display page, determine the page element in the program document that matches the status query request, and obtain the status information of the target resource from the attribute information of the page element; when the page status data is a page image of the resource display page, identify the status information of the target resource from the page image.

[0079] In some implementations, when the information provider is the knowledge base of the intelligent service platform, the acquisition module 402 is specifically used to: acquire first target knowledge matching the status query request from the knowledge base based on the resource identifier of the target resource; and determine the status information of the target resource based on the first target knowledge.

[0080] In some embodiments, the apparatus further includes a generation module for retrieving second target knowledge from a knowledge base that matches the state query request, the second target knowledge being used to interpret the state information; and invoking a result generation model to generate the query result based on the state information and the second target knowledge.

[0081] The functions of each module in the devices of this application embodiment can be found in the corresponding descriptions of the methods described above, and they have corresponding beneficial effects, which will not be repeated here. Furthermore, the device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separate. The components illustrated as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application solution according to actual needs.

[0082] Figure 5 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 5 As shown, the electronic device includes a memory 501 and a processor 502. The memory 501 stores a computer program that can run on the processor 502. When the processor 502 executes the computer program, it implements the method described in the above embodiments. The number of memories 501 and processors 502 can be one or more. In a specific implementation, the electronic device may also include a communication interface 503 for communicating with external devices and exchanging data.

[0083] In practical implementation, if the memory 501, processor 502, and communication interface 503 are implemented independently, they can be interconnected via a bus to communicate with each other. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0084] Optionally, in a specific implementation, if the memory 501, processor 502 and communication interface 503 are integrated on a single chip, the memory 501, processor 502 and communication interface 503 can communicate with each other through an internal interface.

[0085] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0086] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in this application.

[0087] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0088] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0089] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field-Programmable Gate Arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0090] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0091] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0092] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0093] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0094] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0095] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0096] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0097] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0098] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A resource information synchronization method, applied to an intelligent service platform, the method comprising: In response to a status query request for a target resource from a first platform, an information provider matching the status query request is determined, including a second platform; Obtain the status information of the target resource from the information provider; Send the query results to the first platform to synchronize the status information to the first platform.

2. The method according to claim 1, wherein, The process of determining the information provider that matches the status query request includes: Parse the status query request to obtain the query intent; When the query intent represents a query for dynamic information, the information provider that matches the status query request is determined to be the second platform; When the query intent represents a query for static information, the information provider that matches the status query request is determined to be the knowledge base of the intelligent service platform.

3. The method according to claim 1, wherein, When the information provider is a second platform, obtaining the status information of the target resource from the information provider includes: Determine the resource identifier of the target resource; According to the preset acquisition strategy, the access information associated with the target resource is obtained based on the resource identifier; Access the second platform based on the access information to obtain the status information of the target resource from the second platform.

4. The method according to claim 3, wherein, The step of obtaining access information associated with the target resource according to the resource identifier based on a preset acquisition strategy includes: In the correspondence between resource identifiers and platform call interfaces, the target platform call interface corresponding to the resource identifier of the target resource is obtained, and the target platform call interface is determined as the access information; If the target platform fails to access the interface, the service access address of the target resource is determined based on the resource identifier of the target resource and the access address of the second platform, and the service access address is determined as the access information.

5. The method according to claim 3, wherein, Accessing the second platform based on the access information includes: If the access information is a target platform call interface, a status acquisition message is sent to the second platform through the target platform call interface, and the status information sent by the second platform is received. If the access information is a service access address, obtain the page status data of the resource display page corresponding to the service access address, and determine the status information of the target resource based on the page status data.

6. The method according to claim 5, wherein, Determining the status information of the target resource based on the page status data includes: If the page status data is the program document of the resource display page, determine the page element in the program document that matches the status query request, and obtain the status information of the target resource from the attribute information of the page element; When the page status data is a page image of the resource display page, the status information of the target resource is identified from the page image.

7. The method according to claim 2, wherein, When the information provider is the knowledge base of the intelligent service platform, obtaining the status information of the target resource from the information provider includes: Based on the resource identifier of the target resource, obtain the first target knowledge that matches the status query request from the knowledge base; Based on the first target knowledge, determine the status information of the target resource.

8. The method according to any one of claims 1 to 7, wherein, After obtaining the status information of the target resource from the information provider, the method further includes: Obtain second target knowledge from the knowledge base that matches the state query request, the second target knowledge being used to interpret the state information; The result generation model is invoked to generate the query result based on the state information and the second target knowledge.

9. A resource information synchronization system, comprising: Intelligent service platform, at least one primary platform and at least one secondary platform; Any first platform is used to send a status query request to the intelligent service platform in response to a status query text for a target resource; Any second platform is used to provide status information of the held resources; The intelligent service platform is used to perform the method described in any one of claims 1 to 9.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1 to 8.

11. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

12. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 8.