An intelligent water card information dynamic publishing method and system based on a ladder medium large screen

Abstract

This invention discloses a method and system for dynamically publishing smart signage information based on elevator media screens. The method includes: a mini-program client generating a signage update request containing the target building identifier and updated signage content based on editing operations, and sending it to a backend server via HTTPS; the backend server filtering the update content for sensitive words, writing it into a message queue after approval, and querying the large-screen devices associated with the target building; the backend server pushing incremental update instructions to the target large-screen device via a WebSocket long connection, and the target large-screen device updating its local cache and refreshing the interface upon receiving the instruction; the backend server writing the update record to a database, synchronously updating the distributed cache, and returning a success response to the mini-program client. This invention achieves closed-loop control of the entire signage information process, improves the real-time performance of publishing and system response efficiency, reduces network resource consumption, and ensures data consistency and reliability.

Description

Technical Field

[0001] This invention relates to the field of intelligent building information display technology, and in particular to a method and system for dynamically publishing intelligent signage information based on elevator media screens. Background Technology

[0002] With the acceleration of urbanization, the number of high-rise buildings such as office buildings and commercial complexes is constantly increasing, leading to increasingly complex needs for information guidance and management within these buildings. Floor signs (or floor navigation signs) serve as important information carriers within buildings, displaying basic information such as company names, room numbers, and floor layouts to visitors. Currently, the vast majority of office buildings still use traditional physical floor signs, typically made of acrylic, metal, or paper, and fixedly installed in elevator lobbies, lobbies, or floor corridors.

[0003] However, with increased business liquidity, faster information updates, and higher demand from visitors for real-time information, traditional physical signs have revealed the following technical shortcomings: (1) Information updates are lagging behind and cannot meet the needs of dynamic management.

[0004] Traditional signage updates rely on manual operation, requiring a complete "disassembly-production-installation" process, typically taking 3 to 7 business days to complete. For office buildings with frequent business moves, relocations, or name changes, this lag means signage content remains "outdated" for extended periods, impacting visitor experience and building management efficiency. Furthermore, ad-hoc notices (such as elevator maintenance, impromptu meetings, and holiday greetings) cannot be instantly disseminated via physical signage, limiting the building's dynamic responsiveness.

[0005] (2) Limited information carrying capacity, unable to achieve multimedia integrated display.

[0006] Physical signboards are limited to static text, resulting in low information density due to size constraints and an inability to integrate dynamic content such as weather, visitor appointments, advertisements, and announcements. While the elevator media industry has rapidly developed, large-screen devices with multimedia playback capabilities have been widely deployed in buildings. However, these devices currently primarily serve advertising purposes and fail to integrate with signboard systems, leading to a waste of hardware resources.

[0007] (3) High operation and maintenance costs and lack of unified management and content review mechanism.

[0008] In complex scenarios involving multiple buildings and floors, maintaining signage content requires property management staff to operate floor by floor, which is time-consuming, labor-intensive, and prone to errors or version inconsistencies. The lack of a unified back-end management system prevents property management companies from centrally publishing and reviewing content across buildings, increasing security risks and compliance costs. Especially in scenarios involving company name changes or sensitive word detection, the lack of automated review mechanisms can easily lead to legal or brand risks.

[0009] (4) Existing technologies have not yet achieved deep integration of elevator media and water sign functions.

[0010] Although some electronic signboards or information display systems have emerged in recent years, their designs still primarily focus on information display on a single terminal, lacking deep integration with elevator media screens and failing to fully utilize existing hardware resources to achieve a unified display of signboard information and value-added services. Furthermore, existing systems still have significant shortcomings in terms of real-time information delivery, flexibility in content rendering, and multi-tenant data isolation, making it difficult to meet the actual needs of modern intelligent building management.

[0011] In summary, traditional physical water signs and their derivative electronic solutions suffer from technical bottlenecks in terms of information update efficiency, content carrying capacity, system integration, and operation and maintenance costs. There is an urgent need for an intelligent system that can fully utilize existing elevator media screen resources and achieve dynamic release of water sign information and integrated multimedia content display to improve the real-time performance, flexibility, and scalability of building information management. Summary of the Invention

[0012] The main objective of this invention is to provide a method and system for dynamically publishing intelligent water sign information based on elevator media screens, aiming to solve the technical problems of traditional physical water sign information updates being lagging, content carrying capacity being limited, operation and maintenance costs being high, and the inability to deeply integrate with elevator media screen resources in the prior art.

[0013] To achieve the above objectives, the present invention provides a method for dynamically publishing intelligent water sign information based on elevator media screens. The method includes the following steps: Based on the editing operations of the target user, the mini-program generates a water sign update request containing the target building identifier and the updated water sign content, and sends the water sign update request to the backend server via the HTTPS protocol; After receiving the water sign update request, the backend server calls the content review engine to filter sensitive words in the updated water sign content. After the review is passed, the water sign update request is written to the message queue, and the pre-stored association relationship between buildings and large screen devices is queried to determine at least one target large screen device corresponding to the target building identifier. The backend server pushes an incremental update instruction containing the updated watermark content to the target large screen device through a pre-established WebSocket long connection. After receiving the incremental update instruction, the target large screen device parses and updates the locally cached watermark data, and completes the interface refresh within a preset time. The backend server writes the water sign update record to the persistent database, updates the corresponding building's water sign data in the distributed cache, and returns a success update response to the mini-program client.

[0014] Optionally, the method for dynamically publishing smart signage information based on elevator media screens, wherein the mini-program generates a signage update request containing the target building identifier and the updated signage content based on the editing operation of the target user, and sends the signage update request to the backend server via HTTPS protocol, specifically including: In response to the login operation of the target person, the mini-program obtains the company identifier of the property management company to which the target person belongs, and sends a query request for the list of manageable buildings to the backend server based on the company identifier. The backend server queries the list of manageable buildings corresponding to the company identifier based on the pre-configured permission matrix of the binding relationship between the property management company and the buildings, and returns the list of manageable buildings to the mini-program for display. In response to the target user's selection of a target building from the list of manageable buildings, the mini-program sends a request to the backend server to load the current signage data. The backend server queries the current signage data from a multi-level caching architecture based on the target building identifier and returns it to the mini-program. The mini-program loads the current signage data and renders a visual editing interface. In response to the target user's modification of the signboard content on the visual editing interface, the mini-program obtains the updated signboard content and encapsulates the target building identifier and the updated signboard content into a signboard update request. The mini-program then sends the signboard update request to the backend server via the HTTPS protocol.

[0015] Optionally, the method for dynamically publishing smart sign information based on elevator media screens, wherein after the backend server receives the sign update request, it calls a content review engine to filter sensitive words in the updated sign content. After the review is passed, the sign update request is written to a message queue, and the pre-stored association between buildings and screen devices is queried to determine at least one target screen device corresponding to the target building identifier, specifically including: After receiving the water sign update request, the backend server parses the target building identifier and the updated water sign content from the water sign update request; The backend server calls the content review engine to perform word-by-word matching and detection between the updated water sign content and the preset sensitive word library. If the updated water sign content is found to contain words from the sensitive word library, the backend server returns a review failure response to the mini-program. If the updated watermark content passes the sensitive word filter, the backend server encapsulates the watermark update request into a message body and writes it into a message queue, which is then processed asynchronously by the message queue consumer. The backend server extracts the target building identifier from the water sign update request, and queries the device identifier list of at least one target large screen device corresponding to the target building identifier according to the building and large screen device association table stored in the database in advance; The backend server records the list of device identifiers as the targets to be pushed to in the context of this update task.

[0016] Optionally, in the method for dynamically publishing smart water sign information based on elevator media screens, the backend server pushes an incremental update instruction containing the updated water sign content to the target screen device via a pre-established WebSocket long connection. Upon receiving the incremental update instruction, the target screen device parses and updates the locally cached water sign data and completes a screen refresh within a preset time. Specifically, this includes: The backend server maintains a set of mapping relationships between device identifiers and WebSocket session channels. The backend server iterates through the list of device identifiers to query whether there is an active session channel corresponding to each target large screen device in the set of mapping relationships. For a target large-screen device with an active session channel, the backend server encapsulates the updated watermark content into an incremental update instruction in JSON format and pushes it to the target large-screen device through the WebSocket long connection; The target large-screen device receives the incremental update instruction through a WebSocket client, parses the updated water sign content carried in the incremental update instruction, and writes the updated water sign content into a local persistent storage medium. The target large-screen device re-renders the water sign information area in the display interface according to the updated water sign content and completes the interface refresh within a preset time.

[0017] Optionally, the method for dynamically publishing smart water sign information based on elevator media screens, wherein the step of traversing and querying the mapping relationship set to see if there is an active session channel corresponding to each target screen device, further includes: For target large-screen devices that do not have an active session channel or whose push fails, the backend server writes the incremental update instruction into the retry queue. When the target large-screen device is detected to have re-established a WebSocket long connection, the backend server reads the incremental update instruction from the retry queue and pushes it again.

[0018] Optionally, the method for dynamically publishing smart water sign information based on elevator media screens, wherein the backend server writes the water sign update record to a persistent database, updates the corresponding building's water sign data in the distributed cache, and returns a successful update response to the mini-program, specifically includes: The backend server assembles the operation records corresponding to this water sign update request, including operation time, target personnel identifier, target building identifier, and updated water sign content, into historical record entries and writes them into the operation log table of the persistent database. The backend server generates a cache key corresponding to the distributed cache based on the target building identifier, and serializes the updated sign content and writes it into the distributed cache system. At the same time, the backend server triggers the invalidation operation of the local cache, marking the local cache entry corresponding to the target building identifier as expired. After completing the database write and cache update operations, the backend server returns an HTTP response containing an update success identifier to the mini-program client. Upon receiving the update success response, the mini-program client displays an update completion prompt message in the visual editing interface.

[0019] Optionally, the method for dynamically publishing intelligent water sign information based on elevator media screens further includes: After the target large screen device is powered on and started, it initiates a WebSocket long connection request to the backend server to establish a persistent bidirectional communication channel with the backend server. The target large screen device sends an initialization data retrieval request containing the device identifier to the backend server through the WebSocket long connection. The backend server queries the associated building identifier based on the device identifier, and obtains the water sign information data corresponding to the building identifier from the multi-level caching architecture. The backend server also calls a third-party weather forecast interface to obtain real-time weather data, synchronously obtains elevator maintenance notification data from the property management system, and matches holiday greeting data from a preset text library based on the system date. The backend server encapsulates the water sign information data, the real-time weather data, the elevator maintenance notification data, and the holiday greeting data into an initialization data packet, and pushes it to the target large screen device through the WebSocket long connection. The target large screen device receives and parses the initialization data packet, and writes the water sign information data, the real-time weather data, the elevator maintenance notification data, and the holiday greeting data into the local storage medium respectively; According to the preset template configuration, the target large screen device will divide the display area into a main content layer, a top information layer, and a bottom information layer. The water sign information data will be rendered on the main content layer, the real-time weather data will be rendered on the top information layer, and the elevator maintenance notification data and the holiday greeting data will be rendered in a priority carousel on the bottom information layer.

[0020] Optionally, the method for dynamically publishing intelligent water sign information based on elevator media screens further includes: After receiving a water sign data query request, the backend server extracts the target building identifier from the water sign data query request and checks whether there is water sign data corresponding to the target building identifier in the local cache. If the data exists in the local cache and has not expired, the data will be read directly from the local cache and returned. If the corresponding watermark data does not exist in the local cache or the data has expired, the backend server generates a distributed cache key based on the target building identifier and sends a query request to the distributed cache system. If the corresponding water sign data exists in the distributed cache system, the backend server writes the water sign data read from the distributed cache system into the local cache and returns it to the query request client. If the corresponding sign data does not exist in the distributed cache system, the backend server initiates a query request to the persistent database, reads the sign data corresponding to the target building identifier from the sign information table, writes the sign data read from the database into the distributed cache system and the local cache, and returns the sign data to the query request end. When the backend server performs the watermark information update operation, after completing the database write, the backend server generates a distributed cache key corresponding to the target building identifier and performs a deletion operation, while triggering the invalidation operation of the local cache. In subsequent query requests, the backend server reloads the latest data to each level of cache through the cache miss mechanism.

[0021] Optionally, the method for dynamically publishing intelligent water sign information based on elevator media screens further includes: The backend server has a variety of pre-set sign layout templates, including single-column layout templates, double-column layout templates, and mixed text and graphic layout templates. The backend server establishes an association between the sign layout templates and building signs or floor signs, and stores the template configuration data in the database. During the initialization phase or after receiving a signboard update instruction, the target large-screen device sends a template retrieval request to the backend server. The backend server queries the corresponding signboard layout template based on the building identifier or floor identifier associated with the target large-screen device and returns the template configuration data to the target large-screen device. The target large-screen device parses the template configuration data to obtain the position coordinates, size parameters, and rendering attributes of each content area. During operation, the target large screen device continuously listens to notification messages pushed by the background server. When it receives a push message containing elevator maintenance notifications or visitor appointment information, the target large screen device parses the notification type field and priority field in the push message. If the notification type field is a high-priority notification, the target large-screen device will insert the notification message at the beginning of the carousel queue in the bottom information layer and display it immediately in the next carousel cycle, pausing the current carousel's advertising content until the high-priority notification is finished being displayed.

[0022] Furthermore, to achieve the above objectives, the present invention also provides a smart water sign information dynamic publishing system based on an elevator media screen, wherein the smart water sign information dynamic publishing system based on an elevator media screen includes: The mini-program is configured on mobile terminal devices to respond to the editing operations of the target personnel, generate a water sign update request containing the target building identification and the updated water sign content, and send the water sign update request to the backend server via the HTTPS protocol; The backend server, which communicates with the mini-program client, is used to receive the water sign update request, filter the updated water sign content for sensitive words, and after approval, query the pre-stored association relationship between buildings and large screen devices to determine at least one target large screen device corresponding to the target building identifier. The backend server is also used to push an incremental update instruction containing the updated water sign content to the target large screen device through a pre-established WebSocket long connection, write the water sign update record to the persistent database, update the water sign data of the corresponding building in the distributed cache, and return an update success response to the mini-program client. The target large-screen device is configured in the building elevator or lobby and establishes a persistent bidirectional communication connection with the backend server via the WebSocket protocol. It is used to receive incremental update instructions pushed by the backend server, parse and update the locally cached sign data, and complete the interface refresh within a preset time.

[0023] In this invention, the mini-program generates a water sign update request containing the target building identifier and the updated water sign content based on the editing operation of the target user, and sends the water sign update request to the backend server via HTTPS protocol. After receiving the water sign update request, the backend server calls the content review engine to filter sensitive words in the updated water sign content. After the review is passed, the water sign update request is written to the message queue, and the pre-stored association relationship between buildings and large screen devices is queried to determine at least one target large screen device corresponding to the target building identifier. The backend server pushes an incremental update instruction containing the updated water sign content to the target large screen device through a pre-established WebSocket long connection. After receiving the incremental update instruction, the target large screen device parses and updates the locally cached water sign data, and completes the interface refresh within a preset time. The backend server writes this water sign update record to the persistent database, updates the water sign data of the corresponding building in the distributed cache, and returns an update success response to the mini-program. This invention achieves closed-loop control of the entire process from content editing to terminal display, significantly improving the real-time performance of information release and system response efficiency, reducing network resource consumption, and ensuring data consistency and reliability. Attached Figure Description

[0024] Figure 1 This is a flowchart of a preferred embodiment of the intelligent water sign information dynamic release method based on elevator media screen of the present invention; Figure 2 This is a structural diagram of a preferred embodiment of the intelligent water sign information dynamic release system based on a large elevator media screen according to the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer and more explicit, 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 of the invention and are not intended to limit the invention.

[0026] The preferred embodiment of the present invention describes a method for dynamically publishing intelligent water sign information based on a large elevator media screen, such as... Figure 1 As shown, the method for dynamically publishing smart water sign information based on elevator media screens includes the following steps: Step S10: Based on the editing operation of the target personnel, the mini-program generates a water sign update request containing the target building identification and the updated water sign content, and sends the water sign update request to the backend server via the HTTPS protocol.

[0027] Specifically, the mini-program (management level) provides a visual water sign content editing interface, supporting form-based entry of fields such as company name, room number, and contact information; it achieves data isolation based on the company dimension, ensuring that property company A can only modify the water sign information of the buildings under its jurisdiction through the permission matrix configured in the backend management system; it integrates a template configuration function, with multiple preset water sign layout styles (such as single column, double column, and mixed text and graphics), and property management can choose a template according to the characteristics of the floor.

[0028] In response to a user's login, the mini-program obtains the company identifier of the property management company to which the user belongs and sends a request to the backend server to query the list of manageable buildings based on the company identifier. The backend server, based on a pre-configured permission matrix of the binding relationship between property management companies and buildings, queries the list of manageable buildings corresponding to the company identifier and returns the list to the mini-program for display. In response to a user selecting a target building from the list of manageable buildings, the mini-program sends a request to the backend server to load the current signage data. The backend server, based on the target building identifier, queries the current signage data from a multi-level caching architecture and returns it to the mini-program. The mini-program loads the current signage data and renders a visual editing interface. In response to a user modifying the signage content on the visual editing interface, the mini-program obtains the updated signage content and encapsulates the target building identifier and the updated signage content into a signage update request. The mini-program then sends the signage update request to the backend server via HTTPS.

[0029] Step S20: After receiving the water sign update request, the backend server calls the content review engine to filter sensitive words in the updated water sign content. After the review is passed, the water sign update request is written to the message queue, and the pre-stored association relationship between buildings and large screen devices is queried to determine at least one target large screen device corresponding to the target building identifier.

[0030] Specifically, the backend server (control layer) includes: Content moderation engine: Based on a sensitive word database, the submitted sign text is filtered in real time to block inappropriate content.

[0031] Multi-level caching architecture: Redis is used to cache hot watermark data, and Caffeine local caching is used to reduce database queries, reducing the interface response time from an average of 200ms to less than 30ms.

[0032] WebSocket Push Service: Maintains long-term connections with all online dashboards. When the mini-program submits an update request, the backend processes it asynchronously through a message queue (Kafka) and pushes incremental update instructions (instructions that need to be updated synchronously when the information on the signboard changes) to the target dashboard via WebSocket.

[0033] Group Management Module: Supports grouping large screens by building, floor, and device ID, enabling three push strategies: single-screen update, batch update, and network-wide update.

[0034] After receiving the signboard update request, the backend server parses the target building identifier and the updated signboard content from the request. The backend server then invokes a content moderation engine to perform word-by-word matching of the updated signboard content against a pre-set sensitive word library. If the updated signboard content contains words from the sensitive word library, the backend server returns a disapproval response to the mini-program. If the updated signboard content passes the sensitive word filtering, the backend server encapsulates the signboard update request into a message body and writes it to a message queue for asynchronous processing by a message queue consumer. The backend server extracts the target building identifier from the signboard update request and, based on a pre-stored building-to-large-screen device association table in the database, queries a list of device identifiers for at least one target large-screen device corresponding to the target building identifier. The backend server records this list of device identifiers as targets to be pushed to in the context of this update task.

[0035] Step S30: The backend server pushes an incremental update instruction containing the updated watermark content to the target large screen device through a pre-established WebSocket long connection. After receiving the incremental update instruction, the target large screen device parses and updates the locally cached watermark data, and completes the interface refresh within a preset time.

[0036] Specifically, large-screen terminals or large-screen devices (display layer) include: Hybrid content rendering engine: Uses signboard information as the main content layer, overlaying auxiliary information layers such as weather forecasts, elevator maintenance notices, holiday greetings, visitor appointments, and advertising content.

[0037] Offline caching mechanism: The large screen stores the most recently successfully received watermark data locally. When the WebSocket connection is disconnected, the cached content continues to be displayed to avoid a black screen.

[0038] Heartbeat keep-alive mechanism: A heartbeat packet is sent to the backend every 30 seconds. The backend judges the online status of the device based on the heartbeat status. If the device goes offline, a corresponding notification mechanism will be set up. Then, the backend administrator will confirm and contact the device administrator for on-site handling until all problems are resolved and the device is back online and the normal heartbeat is restored.

[0039] The backend server maintains a mapping set of device identifiers and WebSocket session channels. Based on the device identifier list, the backend server iterates through the mapping set to query for active session channels corresponding to each target large-screen device. For target large-screen devices with active session channels, the backend server encapsulates the updated watermark content into an incremental update instruction in JSON format and pushes it to the target large-screen device via the WebSocket long connection. The target large-screen device receives the incremental update instruction via a WebSocket client, parses the updated watermark content carried in the instruction, and writes the updated watermark content to local persistent storage. Based on the updated watermark content, the target large-screen device re-renders the watermark information area in the display interface and refreshes the interface within a preset time. For target large-screen devices without active session channels or where the push fails, the backend server writes the incremental update instruction to a retry queue. When the target large-screen device re-establishes a WebSocket long connection, the backend server reads the incremental update instruction from the retry queue and re-pushes it.

[0040] Step S40: The backend server writes the water sign update record to the persistent database, updates the corresponding building's water sign data in the distributed cache, and returns a success update response to the mini-program.

[0041] Specifically, the backend server assembles the operation records corresponding to this water sign update request, including the operation time, target personnel identifier, target building identifier, and updated water sign content, into a historical record entry and writes it into the operation log table of the persistent database. The backend server generates a cache key corresponding to the distributed cache based on the target building identifier, serializes the updated water sign content, and writes it into the distributed cache system. At the same time, the backend server triggers the invalidation operation of the local cache, marking the local cache entry corresponding to the target building identifier as expired. After completing the database write and cache update operations, the backend server returns an HTTP response containing an update success identifier to the mini-program client. After receiving the update success response, the mini-program client displays an update completion prompt message in the visual editing interface.

[0042] Furthermore, after the target large-screen device powers on, it initiates a WebSocket long connection request to the backend server to establish a persistent bidirectional communication channel. The target large-screen device sends an initialization data retrieval request containing a device identifier to the backend server via the WebSocket long connection. The backend server queries the associated building identifier based on the device identifier and retrieves the signboard information data corresponding to the building identifier from a multi-level caching architecture. Simultaneously, the backend server calls a third-party weather forecast interface to obtain real-time weather data, synchronously retrieves elevator maintenance notification data from the property management system, and matches holiday greeting data from a preset document library based on the system date. The backend server then stores the signboard information data... The real-time weather data, elevator maintenance notification data, and holiday greeting data are encapsulated into an initialization data packet and pushed to the target large-screen device via the WebSocket long connection. The target large-screen device receives and parses the initialization data packet, and writes the sign information data, real-time weather data, elevator maintenance notification data, and holiday greeting data into the local storage medium respectively. According to the preset template configuration, the target large-screen device divides the display area into a main content layer, a top information layer, and a bottom information layer, and renders the sign information data on the main content layer, the real-time weather data on the top information layer, and renders the elevator maintenance notification data and holiday greeting data in a priority carousel on the bottom information layer.

[0043] Furthermore, after receiving a water sign data query request, the backend server extracts the target building identifier from the query request and checks if water sign data corresponding to the target building identifier exists in its local cache. If the data exists in the local cache and has not expired, the server directly reads the water sign data from the local cache and returns it. If the corresponding water sign data does not exist in the local cache or the data has expired, the backend server generates a distributed cache key based on the target building identifier and initiates a query request to the distributed cache system. If the corresponding water sign data exists in the distributed cache system, the backend server writes the water sign data read from the distributed cache system into its local cache and returns it to the query request client. If the corresponding signboard data does not exist in the distributed caching system, the backend server initiates a query request to the persistent database, reads the signboard data corresponding to the target building identifier from the signboard information table, writes the signboard data read from the database into the distributed caching system and the local cache, and returns the signboard data to the query request client. When the backend server performs a signboard information update operation, after completing the database write, the backend server generates a distributed cache key corresponding to the target building identifier and performs a deletion operation, while simultaneously triggering the invalidation operation of the local cache. In subsequent query requests, the backend server reloads the latest data into each level of cache through a cache miss mechanism.

[0044] Furthermore, the backend server pre-configures various signboard layout templates, including single-column layout templates (suitable for floors with a small number of businesses (1-5), double-column layout templates (suitable for floors with a medium number of businesses (6-12), and mixed text and graphic layout templates (supporting company logo display, suitable for high-end office buildings). The backend server establishes an association between the signboard layout templates and building or floor identifiers, and stores the template configuration data in the database. During the initialization phase or after receiving a signboard update instruction, the target large-screen device sends a template retrieval request to the backend server. The backend server then queries the corresponding building or floor identifier associated with the target large-screen device. The system generates a water sign layout template and returns the template configuration data to the target large-screen device. The target large-screen device parses the template configuration data to obtain the position coordinates, size parameters, and rendering attributes of each content area. During operation, the target large-screen device continuously listens for notification messages pushed by the background server. When it receives a push message containing elevator maintenance notifications or visitor appointment information, the target large-screen device parses the notification type field and priority field in the push message. If the notification type field indicates a high-priority notification, the target large-screen device inserts the notification message at the beginning of the carousel queue in the bottom information layer and displays it immediately in the next carousel cycle, pausing the current carousel's advertising content until the high-priority notification is fully displayed.

[0045] Furthermore, to address the need for data access performance optimization in high-concurrency scenarios, this invention designs and implements a multi-level caching architecture. During peak morning hours, when a large number of property management personnel simultaneously initiate requests for water level information, this architecture effectively reduces system response time and alleviates database access pressure through a layered caching mechanism.

[0046] The multi-level caching architecture includes three layers: a local caching layer (L1 cache - Caffeine), a distributed caching layer (L2 cache - Redis), and a persistent storage layer (L3 storage, MySQL).

[0047] The local caching layer is implemented using the Caffeine caching framework and configured as an L1-level cache. This layer is primarily used to cache frequently accessed data, including the homepage building list, commonly used floor information, and other frequently accessed content. The local caching layer is set to a maximum of 1000 cached entries and a cache expiration time of 5 minutes. In high-concurrency query scenarios, the local caching layer achieves a hit rate of over 80%, with a query response time of less than 1 millisecond, enabling it to quickly respond to the vast majority of query requests and significantly reducing the frequency of access to downstream cache and storage layers.

[0048] The distributed caching layer is implemented using Redis and configured as an L2 cache. This layer caches all water sign data, storing it in shards according to building dimensions, with each building's water sign data stored independently in a different cache key. The distributed caching layer sets the cache expiration time to 30 minutes and employs an Least Recently Used (LRU) eviction policy, automatically evicting data that has not been accessed for a long time when cache space is insufficient. When the local cache layer misses a data point, the system sends a query request to the distributed caching layer, whose query response time is less than 10 milliseconds.

[0049] The persistent storage layer is implemented using a MySQL relational database and configured as Level 3 storage. This layer stores complete historical data of the nameplates and supports auditing and traceability. The system only sends a query request to the persistent storage layer to read the target nameplate data from the database when neither the local cache nor the distributed cache layer is found. The query response time of the persistent storage layer is less than 50 milliseconds. After reading the data from the database, the system writes the data back to both the distributed cache layer and the local cache layer in sequence, so that subsequent queries can directly hit the cache.

[0050] Through the collaborative work of the above three-level caching architecture, this invention achieves the technical effect of reducing the average response time of the water sign information query interface from 200 milliseconds to less than 30 milliseconds while ensuring data consistency. At the same time, it significantly reduces the query pressure of the persistent storage layer and improves the overall concurrent processing capability of the system.

[0051] Furthermore, to achieve data security isolation and refined access control in multi-tenant scenarios, this invention configures the binding relationship between property management companies and buildings through a back-end management system, and constructs an access control matrix based on the company dimension to ensure that different property management companies can only operate the watermark data within their jurisdiction.

[0052] The access control mechanism specifically includes the following design: Permission Matrix Configuration: The backend management system provides a visual configuration interface for establishing a mapping of management relationships between property management companies and buildings. System administrators can assign a list of buildings under the jurisdiction of each property management company in this interface, forming a permission matrix. For example, if property management company A is configured to manage buildings B1, B2, and B3, then that company can edit the floor signs for all floors in these buildings. If property management company B is configured to manage buildings B4 and B5, then that company can only edit the floor sign information within its jurisdiction. For buildings not under its jurisdiction (such as B1, B2, and B3), property management company B only has viewing permissions and cannot perform editing, deletion, or other change operations.

[0053] Data isolation is achieved by associating building information with property management company identifiers at the data storage level. Each building record contains a unique identifier for its managing property management company. When a property management company user logs into the system, their identity information is authenticated, and the company identifier is parsed out. All subsequent data query requests are automatically appended with this identifier as a filter condition. When executing database queries, the system dynamically constructs the query statement based on the current user's company identifier, ensuring that only the signage data of the buildings managed by that company is returned, achieving natural isolation of cross-company data.

[0054] Operation permission verification: When a user initiates a watermark update request, the system executes permission verification logic before business processing. The backend server parses the target building identifier and the current user's company identifier from the request, and then queries the pre-stored permission matrix to verify whether the company identifier has editing permissions for the target building. If the verification passes, subsequent sensitive word filtering, message queue writing, and push processes are allowed to continue; if the verification fails, the system immediately intercepts the request and returns an error response indicating unauthorized operation to the client to prevent unauthorized operations.

[0055] Audit traceability support: The system fully records all operations, including fields such as operation time, operator's company ID, operator's account, target building ID, operation type, and operation content. These operation logs are stored in a persistent database and support multi-dimensional querying and tracing by time, company, building, and other dimensions. When data anomalies or compliance reviews occur, administrators can reconstruct the operation history through the audit logs, identify the responsible party, and meet the company's compliance management requirements.

[0056] Through the above-mentioned permission matrix design, data isolation storage, operation permission verification and audit traceability mechanism, this invention realizes data security isolation when multiple property companies share the same system, effectively prevents the risk of cross-company data leakage, and provides each property company with flexible and controllable building water sign management capabilities.

[0057] In this invention, the process for publishing water sign information is as follows: Step 1: Property staff select the target building (e.g., "Building A, 5th Floor") in the mini-program and click "Edit Signboard"; Step 2: The system loads the current watermark data for this floor and displays a visual editing interface; Step 3: The property management office modifies the company name field (e.g., changes "Room 501-XX Technology Company" to "Room 501-YY Consulting Company") and clicks "Submit"; Step 4: The mini-program sends the update request to the backend server via an HTTPS interface; Step 5: The backend content review engine performs sensitive word detection on "YY Consulting Company". Once it passes the detection, the message enters the message queue. Step 6: Query the list of large screen device IDs associated with this floor in the background (e.g., device A, device B, device C). Step 7: The backend pushes incremental update commands in JSON format to devices A, B, and C via WebSocket: { "type": "watermark_update", "floor": "Building A, 5th Floor", "room": "501", "company": "YY Consulting Company", "timestamp": 1678886400 } Step 8: After receiving the command, the large screen updates the local cache and refreshes the interface within 3 seconds; Step 9: The background process writes the update record to the MySQL database and updates the Redis cache simultaneously.

[0058] In this invention, the multi-information fusion and display process is as follows: Step 1: When the large screen starts, connect to the backend via WebSocket and pull the initialization data packet, which includes: water sign information (company list), weather forecast (obtained from local real-time weather via third-party API), elevator maintenance notice (synchronized from the property management system), holiday greetings (automatically matched with preset copy based on system date), and advertising content (obtained from the advertising delivery system). Step 2: The large-screen rendering engine displays the content in layers: Main area (occupies 60% of the screen): Displays information about the signboard using a scrolling list method; Top area (occupies 15% of the screen): Displays weather forecast and date and time; Bottom area (occupies 25% of the screen): Carousel displaying elevator notifications, holiday greetings, and advertisements; Step 3: When a new elevator maintenance notification is pushed from the background, the notification will be immediately inserted into the bottom area of ​​the large screen, with higher priority than advertising content.

[0059] Step 4: When a visitor makes an appointment to visit a company through the mini-program, the backend pushes the visitor information to the large screen on that floor, and the large screen displays "Welcome Zhang San, visitor from XX company" at the top of the main area.

[0060] The technical effects that this invention can bring are as follows: (1) Significantly improved update timeliness: By remotely editing the mini-program terminal and pushing the WebSocket long connection to the backend server, the traditional manual disassembly and production of physical water signs is replaced, shortening the update cycle of water sign information from the traditional 3-7 working days to within 3 seconds to complete the synchronous update of the entire network screen, realizing the real-time dynamic release of building information.

[0061] (2) Significantly expanded information carrying capacity: Using hybrid content layered rendering technology, the display area of ​​the large screen terminal is divided into the main content layer, the top information layer and the bottom information layer. While displaying the basic information of the signboard, it integrates a variety of value-added information such as weather forecast, elevator maintenance notice, holiday greetings, visitor appointments and advertising content, thus expanding the single-function signboard into a multimedia information publishing platform.

[0062] (3) Reduced operation and maintenance costs and resource consumption: Property staff can remotely change the content of the water sign through the mini program without disassembling and making it on-site, and the cost of a single update is close to zero; at the same time, the use of WebSocket long connection to replace the traditional polling mechanism reduces 99% of invalid network requests, significantly reducing server pressure and network bandwidth usage.

[0063] (4) System response performance optimization: Design a multi-level caching architecture (local cache Caffeine, distributed cache Redis, persistent storage MySQL), and reduce the interface response time from an average of 200ms to less than 30ms through a three-level cache penetration query mechanism. The cache hit rate is more than 80%, which effectively supports the data access needs in high-concurrency scenarios.

[0064] (5) Enhanced data security and management standardization: Based on the company-level data isolation and permission verification mechanism, it ensures that the property management company can only operate the water sign information of the buildings under its jurisdiction, and prevents cross-company data leakage; the built-in content review engine filters sensitive words in the submitted content and intercepts illegal information; complete operation logs are recorded, supporting audit traceability and meeting compliance management requirements.

[0065] To fully disclose the technical concept of this invention and to address potential design circumvention by competitors, this invention further provides alternative implementations of several core technical features. These variations do not depart from the scope of protection of this invention; they are merely adjustments to specific technical selections or implementation methods.

[0066] I. Alternatives to push protocols.

[0067] The original solution of this invention uses the WebSocket protocol to achieve real-time push between the backend server and the target large-screen device. In practical applications, other communication protocols with long-connection characteristics can also be used to achieve the same function: (1) MQTT Protocol Solution: The MQTT (Message Queuing Telemetry Transport) protocol is used instead of WebSocket. MQTT is based on the publish / subscribe model, is lightweight, and is suitable for IoT scenarios. The backend server acts as an MQTT Broker to publish messages, and the target large-screen device acts as an MQTT Client to subscribe to the corresponding topic. When the information on the watermark is updated, the backend publishes an incremental update command to the specific topic, and the large-screen device that has subscribed to the topic receives and processes the message in real time.

[0068] (2) Server-Sent Events Solution: One-way push is implemented using the SSE protocol. The backend server establishes an HTTP long connection to the target large-screen device. When the information on the signboard is updated, the backend pushes data to the large screen device one-way through this connection. This solution is suitable for pure push scenarios where the large screen does not need to send data to the backend.

[0069] (3) Long Polling Solution: Employs a Long Polling mechanism to simulate real-time push. The target large-screen device sends an HTTP request to the backend. The backend immediately returns a response when there is data update; otherwise, the connection remains suspended until timeout. Upon receiving the response, the large-screen device immediately initiates the next request. This solution has good compatibility and can be deployed on older devices that do not support WebSocket.

[0070] The above solutions all use "real-time push protocol based on long connection" as the overarching concept and are all within the scope of protection of the claims of this invention.

[0071] II. Alternatives to caching architecture.

[0072] The original solution of this invention uses a three-level caching architecture of Caffeine (local cache) + Redis (distributed cache) + MySQL (persistent storage). In actual deployment, alternative components can be selected according to the technology stack or performance requirements. (1) Guava Cache + Memcached + PostgreSQL solution: Guava Cache is used as the local cache implementation, Memcached is used as the distributed cache to replace Redis, and PostgreSQL is used as the persistent database to replace MySQL. This solution also achieves three-level cache penetration query and data consistency maintenance.

[0073] (2) Ehcache + Hazelcast + MongoDB solution: Ehcache is used as a local cache, Hazelcast is used as a distributed in-memory data grid to replace Redis, and MongoDB is used as a NoSQL database to replace MySQL. This solution is suitable for unstructured data storage scenarios.

[0074] (3) Two-level caching scheme: In scenarios with low performance requirements or limited budget, the local caching layer can be omitted, and only a two-level architecture of Redis as a distributed cache and MySQL as a persistent storage can be used. Query requests first access Redis, and if no match is found, the database is queried and the cache is written back.

[0075] The above solutions all embody the core design concept of "multi-level caching architecture," which reduces database access pressure and improves query response speed through layered caching. They are all equivalent implementations of the technical solutions of this invention.

[0076] III. Alternatives to content moderation.

[0077] The original solution of this invention uses text filtering based on a sensitive word database to achieve content moderation. In practical applications, more advanced or stricter moderation mechanisms can be adopted: (1) Machine learning semantic analysis scheme: The natural language processing model is used to perform semantic analysis on the submitted water sign content to identify sensitive intentions, illegal expressions or inappropriate information. This scheme can detect illegal content such as variant words and homophones that are difficult to cover by traditional sensitive word databases.

[0078] (2) Manual Review Process: A manual review process is introduced on top of the automatic review. After property staff submit a request to update the water sign, the system first performs preliminary filtering, then pushes the updated content to the platform administrator's review interface. After the administrator manually confirms and approves it, the incremental update instruction is then pushed to the target large screen. This solution is suitable for scenarios with extremely high content security requirements.

[0079] (3) Blockchain Evidence Storage Solution: Blockchain technology is used to record the entire content review process. Each review operation (including submission, review, approval, rejection, etc.) generates an immutable blockchain transaction record to ensure the transparency and traceability of the review process and meet the needs of judicial auditing.

[0080] The above solutions are all described in abstract as "content compliance verification module". Their core function is to perform compliance checks and filtering on submitted content, and they are all equivalent technical features of this invention.

[0081] IV. Alternatives to access control.

[0082] The original solution of this invention uses company-level data isolation to achieve multi-tenant access control. In practical applications, different access control models can be selected based on the complexity of the organizational structure: (1) Role-based access control scheme: The RBAC model is adopted, with preset roles such as super administrator, building administrator, and ordinary user. The super administrator can configure permissions for all buildings; the building administrator can only operate the water signs of the specified buildings; ordinary users only have viewing permissions and no editing permissions. Permission allocation is based on user roles rather than company dimensions.

[0083] (2) Attribute-based access control scheme: The ABAC model is adopted to dynamically calculate access permissions based on the user's multi-dimensional attributes (such as department, job level, region, etc.). For example, if a user belongs to the "Operations Department" and has the job level of "Manager", then the user can edit the signs of all buildings in the user's region; if the job level is "Employee", then the user only has viewing permissions.

[0084] (3) Region-based access control scheme: permissions are divided according to city, region, and building level. For example, the North China region administrator can operate the water signs of all buildings in Beijing and Tianjin, but cannot operate the buildings in the East China region; the building-level administrator can only operate the water signs of a single building.

[0085] The above solutions are all described in general as "multi-tenant data isolation mechanism". Their core objective is to achieve data security isolation and differentiated access control between different users or organizations. They are all reasonable variations of the technical solution of this invention.

[0086] Furthermore, such as Figure 2 As shown, based on the above-mentioned method for dynamically publishing intelligent water sign information using elevator media screens, this invention also provides a corresponding intelligent water sign information dynamic publishing system based on elevator media screens, wherein the intelligent water sign information dynamic publishing system based on elevator media screens includes: The mini-program is configured on mobile terminal devices to respond to the editing operations of the target personnel, generate a water sign update request containing the target building identification and the updated water sign content, and send the water sign update request to the backend server via the HTTPS protocol; The backend server, which communicates with the mini-program client, is used to receive the water sign update request, filter the updated water sign content for sensitive words, and after approval, query the pre-stored association relationship between buildings and large screen devices to determine at least one target large screen device corresponding to the target building identifier. The backend server is also used to push an incremental update instruction containing the updated water sign content to the target large screen device through a pre-established WebSocket long connection, write the water sign update record to the persistent database, update the water sign data of the corresponding building in the distributed cache, and return an update success response to the mini-program client. The target large-screen device is configured in the building elevator or lobby and establishes a persistent bidirectional communication connection with the backend server via the WebSocket protocol. It is used to receive incremental update instructions pushed by the backend server, parse and update the locally cached sign data, and complete the interface refresh within a preset time.

[0087] In summary, this invention provides a method and system for dynamically publishing smart signage information based on elevator media screens. The method includes: a mini-program client generating a signage update request containing the target building identifier and the updated signage content based on the editing operation of the target user, and sending the signage update request to a backend server via HTTPS protocol; upon receiving the signage update request, the backend server calls a content review engine to filter sensitive words in the updated signage content, and after approval, writes the signage update request to a message queue, and queries the pre-stored association relationship between buildings and large screen devices to determine at least one target large screen device corresponding to the target building identifier; the backend server pushes an incremental update instruction containing the updated signage content to the target large screen device through a pre-established WebSocket long connection; upon receiving the incremental update instruction, the target large screen device parses and updates the locally cached signage data, and completes the interface refresh within a preset time; the backend server writes the signage update record to a persistent database, updates the signage data of the corresponding building in the distributed cache, and returns an update success response to the mini-program client. This invention achieves closed-loop control of the entire process from content editing to terminal display, significantly improving the real-time performance of information release and system response efficiency, reducing network resource consumption, and ensuring data consistency and reliability.

[0088] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal that includes that element.

[0089] Of course, those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware (such as a processor, controller, etc.). The program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The computer-readable storage medium can be a memory, magnetic disk, optical disk, etc.

[0090] It should be understood that the application of the present invention is not limited to the examples above. Those skilled in the art can make improvements or modifications based on the above description, and all such improvements and modifications should fall within the protection scope of the appended claims.

Claims

1. A method for dynamically publishing intelligent water sign information based on a large elevator media screen, characterized in that, The method for dynamically publishing smart watermark information based on elevator media screens includes: Based on the editing operations of the target user, the mini-program generates a water sign update request containing the target building identifier and the updated water sign content, and sends the water sign update request to the backend server via the HTTPS protocol; After receiving the water sign update request, the backend server calls the content review engine to filter sensitive words in the updated water sign content. After the review is passed, the water sign update request is written to the message queue, and the pre-stored association relationship between buildings and large screen devices is queried to determine at least one target large screen device corresponding to the target building identifier. The backend server pushes an incremental update instruction containing the updated watermark content to the target large screen device through a pre-established WebSocket long connection. After receiving the incremental update instruction, the target large screen device parses and updates the locally cached watermark data, and completes the interface refresh within a preset time. The backend server writes the water sign update record to the persistent database, updates the corresponding building's water sign data in the distributed cache, and returns a success update response to the mini-program client.

2. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 1, characterized in that, The mini-program generates a water sign update request, containing the target building identifier and the updated water sign content, based on the editing operation of the target user. This request is then sent to the backend server via HTTPS. Specifically, this includes: In response to the login operation of the target person, the mini-program obtains the company identifier of the property management company to which the target person belongs, and sends a query request for the list of manageable buildings to the backend server based on the company identifier. The backend server queries the list of manageable buildings corresponding to the company identifier based on the pre-configured permission matrix of the binding relationship between the property management company and the buildings, and returns the list of manageable buildings to the mini-program for display. In response to the target user's selection of a target building from the list of manageable buildings, the mini-program sends a request to the backend server to load the current signage data. The backend server queries the current signage data from a multi-level caching architecture based on the target building identifier and returns it to the mini-program. The mini-program loads the current signage data and renders a visual editing interface. In response to the target user's modification of the signboard content on the visual editing interface, the mini-program obtains the updated signboard content and encapsulates the target building identifier and the updated signboard content into a signboard update request. The mini-program then sends the signboard update request to the backend server via the HTTPS protocol.

3. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 1 or 2, characterized in that, After receiving the water sign update request, the backend server calls the content review engine to filter sensitive words in the updated water sign content. Once approved, the update request is written to a message queue, and the server queries the pre-stored association between buildings and large-screen devices to determine at least one target large-screen device corresponding to the target building identifier. Specifically, this includes: After receiving the water sign update request, the backend server parses the target building identifier and the updated water sign content from the water sign update request; The backend server calls the content review engine to perform word-by-word matching and detection between the updated water sign content and the preset sensitive word library. If the updated water sign content is found to contain words from the sensitive word library, the backend server returns a review failure response to the mini-program. If the updated watermark content passes the sensitive word filter, the backend server encapsulates the watermark update request into a message body and writes it into a message queue, which is then processed asynchronously by the message queue consumer. The backend server extracts the target building identifier from the water sign update request, and queries the device identifier list of at least one target large screen device corresponding to the target building identifier according to the building and large screen device association table stored in the database in advance; The backend server records the list of device identifiers as the targets to be pushed to in the context of this update task.

4. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 3, characterized in that, The backend server pushes an incremental update command containing the updated watermark content to the target large-screen device via a pre-established WebSocket long connection. Upon receiving the incremental update command, the target large-screen device parses and updates the locally cached watermark data, and completes a screen refresh within a preset time, specifically including: The backend server maintains a set of mapping relationships between device identifiers and WebSocket session channels. The backend server iterates through the list of device identifiers to query whether there is an active session channel corresponding to each target large screen device in the set of mapping relationships. For a target large-screen device with an active session channel, the backend server encapsulates the updated watermark content into an incremental update instruction in JSON format and pushes it to the target large-screen device through the WebSocket long connection; The target large-screen device receives the incremental update instruction through a WebSocket client, parses the updated water sign content carried in the incremental update instruction, and writes the updated water sign content into a local persistent storage medium. The target large-screen device re-renders the water sign information area in the display interface according to the updated water sign content and completes the interface refresh within a preset time.

5. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 4, characterized in that, The step of traversing and querying the mapping relationship set to see if there is an active session channel corresponding to each target large screen device, followed by: For target large-screen devices that do not have an active session channel or whose push fails, the backend server writes the incremental update instruction into the retry queue. When the target large-screen device is detected to have re-established a WebSocket long connection, the backend server reads the incremental update instruction from the retry queue and pushes it again.

6. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 4, characterized in that, The backend server writes the water sign update record to the persistent database, updates the corresponding building's water sign data in the distributed cache, and returns a success update response to the mini-program client, specifically including: The backend server assembles the operation records corresponding to this water sign update request, including operation time, target personnel identifier, target building identifier, and updated water sign content, into historical record entries and writes them into the operation log table of the persistent database. The backend server generates a cache key corresponding to the distributed cache based on the target building identifier, and serializes the updated sign content and writes it into the distributed cache system. At the same time, the backend server triggers the invalidation operation of the local cache, marking the local cache entry corresponding to the target building identifier as expired. After completing the database write and cache update operations, the backend server returns an HTTP response containing an update success identifier to the mini-program client. Upon receiving the update success response, the mini-program client displays an update completion prompt message in the visual editing interface.

7. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 4, characterized in that, The method for dynamically publishing smart watermark information based on elevator media screens also includes: After the target large screen device is powered on and started, it initiates a WebSocket long connection request to the backend server to establish a persistent bidirectional communication channel with the backend server. The target large screen device sends an initialization data retrieval request containing the device identifier to the backend server through the WebSocket long connection. The backend server queries the associated building identifier based on the device identifier and obtains the water sign information data corresponding to the building identifier from the multi-level caching architecture. The backend server also calls a third-party weather forecast interface to obtain real-time weather data, synchronously obtains elevator maintenance notification data from the property management system, and matches holiday greeting data from a preset text library based on the system date. The backend server encapsulates the water sign information data, the real-time weather data, the elevator maintenance notification data, and the holiday greeting data into an initialization data packet and pushes it to the target large screen device through the WebSocket long connection. The target large screen device receives and parses the initialization data packet, and writes the water sign information data, the real-time weather data, the elevator maintenance notification data, and the holiday greeting data into the local storage medium respectively; According to the preset template configuration, the target large screen device will divide the display area into a main content layer, a top information layer, and a bottom information layer. The water sign information data will be rendered on the main content layer, the real-time weather data will be rendered on the top information layer, and the elevator maintenance notification data and the holiday greeting data will be rendered in a priority carousel on the bottom information layer.

8. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 1, characterized in that, The method for dynamically publishing smart watermark information based on elevator media screens also includes: After receiving a water sign data query request, the backend server extracts the target building identifier from the water sign data query request and checks whether there is water sign data corresponding to the target building identifier in the local cache. If the data exists in the local cache and has not expired, the data will be read directly from the local cache and returned. If the corresponding watermark data does not exist in the local cache or the data has expired, the backend server generates a distributed cache key based on the target building identifier and sends a query request to the distributed cache system. If the corresponding water sign data exists in the distributed cache system, the backend server writes the water sign data read from the distributed cache system into the local cache and returns it to the query request client. If the corresponding sign data does not exist in the distributed cache system, the backend server initiates a query request to the persistent database, reads the sign data corresponding to the target building identifier from the sign information table, writes the sign data read from the database into the distributed cache system and the local cache, and returns the sign data to the query request end. When the backend server performs the watermark information update operation, after completing the database write, the backend server generates a distributed cache key corresponding to the target building identifier and performs a deletion operation, while triggering the invalidation operation of the local cache. In subsequent query requests, the backend server reloads the latest data to each level of cache through the cache miss mechanism.

9. The method for dynamically publishing intelligent water sign information based on a large elevator media screen according to claim 7, characterized in that, The method for dynamically publishing smart watermark information based on elevator media screens also includes: The backend server has a variety of pre-set sign layout templates, including single-column layout templates, double-column layout templates, and mixed text and graphic layout templates. The backend server establishes an association between the sign layout templates and building signs or floor signs, and stores the template configuration data in the database. During the initialization phase or after receiving a signboard update instruction, the target large-screen device sends a template retrieval request to the backend server. The backend server queries the corresponding signboard layout template based on the building identifier or floor identifier associated with the target large-screen device and returns the template configuration data to the target large-screen device. The target large-screen device parses the template configuration data to obtain the position coordinates, size parameters, and rendering attributes of each content area. During operation, the target large screen device continuously listens to notification messages pushed by the background server. When it receives a push message containing elevator maintenance notifications or visitor appointment information, the target large screen device parses the notification type field and priority field in the push message. If the notification type field is a high-priority notification, the target large-screen device will insert the notification message at the beginning of the carousel queue in the bottom information layer and display it immediately in the next carousel cycle, pausing the current carousel's advertising content until the high-priority notification is finished being displayed.

10. A smart water sign information dynamic publishing system based on a large elevator media screen, characterized in that, The intelligent water sign information dynamic release system based on elevator media screens includes: The mini-program is configured on mobile terminal devices to respond to the editing operations of the target personnel, generate a water sign update request containing the target building identification and the updated water sign content, and send the water sign update request to the backend server via the HTTPS protocol; The backend server, which communicates with the mini-program client, is used to receive the water sign update request, filter the updated water sign content for sensitive words, and after approval, query the pre-stored association relationship between buildings and large screen devices to determine at least one target large screen device corresponding to the target building identifier. The backend server is also used to push an incremental update instruction containing the updated water sign content to the target large screen device through a pre-established WebSocket long connection, write the water sign update record to the persistent database, update the water sign data of the corresponding building in the distributed cache, and return an update success response to the mini-program client. The target large-screen device is configured in the building elevator or lobby and establishes a persistent bidirectional communication connection with the backend server via the WebSocket protocol. It is used to receive incremental update instructions pushed by the backend server, parse and update the locally cached sign data, and complete the interface refresh within a preset time.

Images